本実施形態に係る端末管理システムは、Smart Phone、PDA、ノートPC等、可搬性を有し、ネットワークとの接続が可能なモバイル端末(以下、端末装置)を対象として、管理グループ(法人における管理者等)が端末装置の状態等を把握することによって適切な遠隔管理を実現する。以下、図面参照しつつ、本発明の実施形態について説明する。
具体的には、(1)端末管理システムの構成例、(2)メッセージシーケンス、(3)端末管理サーバの構成例、(4)端末管理サーバの動作例、(5)端末管理サーバの構成要素の実装例、(6)端末装置の構成例、(7)端末装置の動作例、(8)端末装置の構成要素の実装例、(9)作用・効果及び(10)その他の実施形態について説明する。
なお、以下の図面の記載において、同一または類似の部分には、同一または類似の符号を付している。ただし、図面は模式的なものであり、各寸法の比率などは現実のものとは異なることに留意すべきである。
したがって、具体的な寸法などは以下の説明を参酌して判断すべきものである。また、図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることは勿論である。
(1)端末管理システムの構成例
図1は、本実施形態に係る端末管理システム500の概略構成図である。端末管理システム500は、端末管理サーバ1、端末装置2、端末情報提供サーバ3及び管理者用端末4を含む。
端末管理サーバ1は、携帯電話端末やPDA等のモバイル端末である端末装置2を管理する。端末装置2は、端末管理サーバ1から受信した初期メッセージ(例えば、初期メッセージ300)に基づいて、端末装置2を説明するメタ情報を端末管理サーバ1に送信する。
端末情報提供サーバ3は、端末装置2がネットワーク5への接続認可の処理を実行する際に、端末装置2を説明するメタ情報である端末情報(DevInfo)を収集する。また、端末情報提供サーバ3は、端末管理サーバ1の要求に従って端末装置2の端末情報を端末管理サーバ1に通知する。
管理者用端末4は、端末管理サーバ1を利用して端末装置2を管理する管理者によって利用される。
端末管理サーバ1、端末装置2、端末情報提供サーバ3及び管理者用端末4は、ネットワーク5を介して接続されている。なお、ネットワーク5には、異なるネットワーク間に介在するゲートウェイノードや、プロキシサーバ、ルータ等の装置が存在してもよい。また、端末管理サーバ1と端末情報提供サーバ3が同一のサーバ装置(ハードウェア)によって構成されてもよい。
本実施形態では、端末管理サーバ1は、Open Mobile Alliance Device Management WG(以下、OMA-DM)が標準規格化しているDMサーバソフトを搭載する。また、端末装置2は、OMA-DMが標準規格化しているDMクライアントソフトを搭載する。
また、本実施形態では、端末管理サーバ1は、端末装置2を呼び出す初期メッセージ及び端末装置2を遠隔管理する端末管理命令、具体的には、端末管理メッセージを生成する。
(2)メッセージシーケンス
図2は、端末管理システム500を構成する各装置間におけるメッセージシーケンス図である。
図2に示すように、端末装置2は、利用者による電源投入等のタイミングにおいて、ネットワーク5への接続認可を受けるため、接続認可取得処理を実行する(ステップS101)。
さらに、端末装置2は、接続認可を取得後、端末情報を端末情報提供サーバ3に通知する(ステップS102)。端末情報提供サーバ3は、端末情報と、接続認可を受けた利用者を識別する利用者識別情報とを結びつけて管理する。
端末管理システム500の管理者は、管理者用端末4を介して端末管理サーバ1に対して管理要求を実行する(ステップS103)。管理要求には、端末装置2を保有する利用者の利用者識別情報と、端末管理サーバ1が提供する管理サービスへのサービス要求情報が含まれる。
端末管理サーバ1は、管理要求に含まれた利用者識別情報を含む端末情報要求を端末情報提供サーバ3に通知する(ステップS104)。例えば、端末管理サーバ1は、図3に示すような端末情報要求メッセージ100を端末情報提供サーバ3に通知する。
端末情報要求メッセージ100は、HTTP Post Requestを利用して生成され、利用者識別情報として利用者の電話番号を含んでいる。本実施形態では、通信ベアラとしてHTTP Postが採用されるが、端末情報要求であること及び利用者識別情報を通知できればよく、これに限るものではない。
また、本実施形態では、利用者識別情報として電話番号が用いられるが、利用者を識別できる情報であればこれに限るものではない。例えば、ネットワーク接続のログインIDや、通信事業者が保持している加入者識別情報でもよい。
端末情報提供サーバ3は、端末情報提供サーバ3が管理する端末情報と利用者識別情報とを参照し、端末情報要求に含まれる利用者識別情報に基づいて端末情報を抽出する。さらに、端末情報提供サーバ3は、抽出した端末情報を端末管理サーバ1に提供する(ステップS105)。
例えば、端末情報提供サーバ3は、図4に示すような端末情報応答メッセージ200を端末管理サーバ1に通知する。端末情報応答メッセージ200は、図3に示した端末情報要求メッセージ100に対する応答メッセージである。端末情報応答メッセージ200は、HTTP Responseを用いて生成され、端末情報として端末識別子(IMEI)を含む。本実施形態では、端末情報として端末識別子が採用されるが、端末装置2のメーカとモデルを識別できればよく、これに限るものではない。例えば、端末情報は、端末メーカ識別子と端末モデル識別子を含む情報であってもよい。
端末情報応答メッセージ200を受理した端末管理サーバ1は、端末情報応答メッセージ200から端末情報を取り出し、端末装置2を管理するための処理であるDevice Description Framework(DDF)の選択処理を実行する。端末管理サーバ1は、当該選択処理後、初期メッセージを生成し、端末装置2に通知する(ステップS106)。
具体的には、端末管理サーバ1は、図5に示すような初期メッセージ300を生成する。初期メッセージ300は、OMA-DMが標準規格化しているDM Notificationのデータフォーマットで生成され、特にTrigger Body304内に、端末管理セッションにおけるシーケンスを圧縮するためのパラメータ303を含む。パラメータ303は、端末管理セッションにおけるシーケンスを圧縮するか否かを示す圧縮フラグ305を含む。例えば、端末管理サーバ1は、端末情報提供サーバ3から端末情報を正常に受理できた場合、圧縮フラグ305を真とし、シーケンスを圧縮する旨を端末装置2に通知する。一方、端末管理サーバ1は、端末情報提供サーバ3から端末情報を正常に受理できなかった場合、圧縮フラグ305を偽とし、シーケンスを圧縮しない旨を端末装置2に通知する。
初期メッセージ300を受理した端末装置2は、端末管理のための初期化処理、及び初期応答を実行する(ステップS107)。端末装置2は、初期応答を生成する際に、初期メッセージ300に含まれる圧縮フラグ305を確認し、端末装置2が管理する端末情報を初期応答に含めるか否かを決定する。
例えば、端末装置2は、圧縮フラグ305が真である場合、端末情報を初期応答に含めない。一方、端末装置2は、圧縮フラグ305が偽である場合、端末情報を初期応答に含める。圧縮フラグ305が真である場合、端末装置2は、図6に示すような初期応答400を端末管理サーバ1に通知する。初期応答400では、端末情報が含まれず、代わりに端末情報を含めない旨を通知する情報410を含む。
OMA-DMにて標準規格化されているプロトコルでは、初期応答に端末情報(DevInfo)を含めることが必須となっている。そのため、OMA-DMを準拠とする場合は、端末情報を含めてもよい。ただし、端末情報を含めた場合でも、端末管理サーバ1は、情報410を取得したことに基づいて、DDFの選択処理をしないことで、端末管理全体の処理時間を軽減することができる。
一方、端末情報を初期応答に含める場合、端末装置2は、図7に示すような初期応答450を端末管理サーバ1に通知する。初期応答450は、初期応答400と異なり、端末情報(DevInfo)をアップロードするための情報451を含む。
初期応答を受理した端末管理サーバ1は、ステップS104~105を経て取得した端末情報、及び選択したDDFを用い、管理要求に含まれるサービス要求情報に基づいて端末管理メッセージを生成し、端末管理セッションを介して端末装置2を管理する(ステップS108)。
なお、ステップS106において端末管理サーバ1が端末装置2に送付する初期メッセージは、図26に示す初期メッセージ310のように、ステップS105にて取得した端末情報、具体的には、第1のメタ情報312を含むパラメータ311付加してもよい。
例えば、初期メッセージをShort Message Service(SMS)等、端末装置の利用者を特定してメッセージが通知される伝送ベアラが用いられる端末管理システムでは、端末管理サーバ1が端末情報提供サーバ3から端末情報を取得してから初期メッセージを端末装置2に通知するまでの間に、端末装置2に挿入されていたICカード、具体的には、Subscriber Identity Module(SIM)カードが他の端末装置に差し換えられることが考えられる。この場合、管理対象の端末装置は、初期メッセージを送信する前に想定していた端末装置と異なることとなる。端末管理サーバ1は、DDFの選択処理において選択されたDDFから端末管理メッセージを生成するが、上述したSIMカードの差し換えが発生すると、初期応答を実行した端末装置に適した端末管理メッセージを生成することができない。
そこで、ステップS105において取得した端末情報を初期メッセージに付加することによって、端末装置2が管理している端末情報と、初期メッセージに付加されている端末情報とを比較させることができる。この結果、端末情報のうち、不一致の情報を抽出でき、端末装置2から当該不一致の情報を含む初期応答を端末管理サーバ1に通知することができる。この場合、端末管理サーバ1は、当該不一致の情報を、ステップS105にて取得した端末情報に上書きする等して、端末情報を生成し、生成した端末情報を用いてDDFの選択処理を再度実行する。
なお、本実施形態では、端末情報、具体的には、第1のメタ情報を初期メッセージに含めていたが、第1のメタ情報のうち、管理要求を実行するために必要な情報のみを抽出して初期メッセージに含めてもよい。このようにすることによって、管理要求を実行するために必要最小限の情報のみが通知されるため、ネットワーク負荷が軽減できる。
また、第1のメタ情報の代わりに、管理要求を実行するために必要最小限の情報を端末装置2に要求するための情報(要求端末情報)を初期メッセージに付加してもよい。管理要求の内容によっては、端末装置2の利用者に対して管理実行の是非を確認するメッセージをユーザインタフェースに表示することが考えられる。この場合、端末装置2に設定している言語設定情報を端末装置2から端末管理サーバ1に通知させ、端末装置2の利用者が理解できる言語で上述のメッセージを作成する必要がある。
本実施形態では、端末装置2は、ネットワーク5への接続認可の取得処理時に端末情報を端末情報提供サーバ3に通知しているが、この際、言語設定情報を含む端末情報を通知している場合は問題ない。しかし、言語設定情報を含む端末情報通知していない場合、端末管理サーバ1は、言語設定情報を利用できず、的確なメッセージを生成することができない。
OMA-DMが標準規格化しているプロトコルでは、言語設定情報を含む端末情報を初期応答に含めることによって、上述した問題を回避できるが、端末装置2において管理されている端末情報がすべて通知されてしまう。初期メッセージに要求端末情報を含めることによって、端末情報提供サーバ3を利用して取得できた情報や、管理要求を実行するために必要十分な情報だけを通知でき、ネットワーク負荷を軽減することができる。
図27は、要求端末情報、想定管理端末の識別子、想定言語設定を含んだ初期メッセージ例を示す。図27に示すように、初期メッセージ320は、パラメータ321を含む。パラメータ321は、ポリシー情報322を含む。
なお、要求端末情報323、想定管理端末識別子324及び想定言語設定情報325を含むポリシー情報322や、第1のメタ情報312の代わりに、実のポリシー情報や第1のメタ情報312の所在場所を示すポリシーURIを初期メッセージに含めてもよい。
SMSは、送信対象データのサイズがSMSの分割サイズ上限を超えると、複数のSMSメッセージに分割する機能を有している。初期メッセージをSMSによって伝送する場合、メッセージ分割が発生してしまうと、余分なSMSのヘッダがネットワーク5に向けて送信されることによってネットワーク5における負荷が増大する。また、端末装置2の管理処理に関する全体処理時間の遅延に繋がる。
つまり、可能な限りメッセージ分割が発生しないように、初期メッセージを生成する際には送信対象データのデータサイズに注意する必要がある。しかし、ポリシー情報322や第1のメタ情報312は内容によっては送信対象データのデータサイズが分割サイズ上限を超えることも考えられる。
そこで、ポリシー情報322や第1のメタ情報312の代わりに、これらの情報よりもデータのサイズが小さいポリシーURIを初期メッセージに含めることによって、メッセージ分割を避けることが可能である。ポリシーURIを含む初期メッセージを受理した端末装置2は、ポリシーURIによって示された所在場所に基づいて、ポリシー情報322や第1のメタ情報312をダウンロードする。
図28は、ポリシーURIを含む初期メッセージ例を示す。図28に示すように、初期メッセージ330のパラメータ331には、ポリシーURI333と、ポリシーURI333が含まれるか否かを伝えるためのURIフラグ332が含まれる。例えば、URIフラグ332が真である場合、端末装置2は、URIフラグ332以降のデータをポリシーURI333として利用する。
(3)端末管理サーバの構成例
図8は、端末管理サーバ1の機能ブロック図である。図8に示すように、端末管理サーバ1は、端末管理要求処理部10、初期メッセージ生成部11、メタ情報取得部12、端末管理命令生成部13、初期メッセージ送信部14、通信プロトコル処理部15、DDF選択部16及びDDF格納部17を備える。
端末管理要求処理部10は、管理者用端末4からの管理要求を受理し、第1のメタ情報取得要求、DDF選択要求、及び初期メッセージ生成要求を生成する。
特に、本実施形態では、端末管理要求処理部10は、端末装置2の遠隔管理の際に、端末情報提供サーバ3から取得した第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む第2のメタ情報の送信を端末装置2に要求するポリシー情報322(メタ情報送信ポリシー)を生成する。また、端末管理要求処理部10は、ポリシー情報322の所在場所を示すURIフラグ332を含む初期メッセージ330を端末装置に送信することができる。
初期メッセージ生成部11は、初期メッセージ生成要求を受理し、管理対象の端末装置を起動するための初期メッセージを生成する。
メタ情報取得部12は、第1のメタ情報取得要求を受理し、端末情報提供サーバ3から端末情報(DevInfo)を取得する。また、メタ情報取得部12は、端末装置2が保有しているメタ情報を含む端末情報(第2のメタ情報)を端末装置2から受信することができる。本実施形態において、メタ情報取得部12は、第2のメタ情報受信部を構成する。
端末管理命令生成部13は、端末装置2から初期応答を受理し、管理要求に従って端末管理メッセージを生成する。特に、本実施形態では、端末管理命令生成部13は、第1のメタ情報または第2のメタ情報に基づいて端末管理メッセージを生成する。
具体的には、端末管理命令生成部13は、端末装置2から第2のメタ情報を受信した場合、受信した第2のメタ情報に基づいて端末管理メッセージを生成する。また、端末管理命令生成部13は、端末装置2から第2のメタ情報を受信しない場合、第1のメタ情報に基づいて端末管理メッセージを生成する。
初期メッセージ送信部14は、初期メッセージ生成部11によって生成された初期メッセージを受理し、管理対象の端末装置(端末装置2)に向けて初期メッセージを送信する。
特に、本実施形態では、初期メッセージ送信部14は、端末情報提供サーバ3が保有しているメタ情報である第1のメタ情報を端末情報提供サーバ3から取得済みであるか否かを示すフラグ情報、具体的には、圧縮フラグ305を含む初期メッセージ(例えば、初期メッセージ300)を端末装置2に送信する。また、初期メッセージ送信部14は、端末情報提供サーバ3から取得した第1のメタ情報を含む初期メッセージ310を端末装置2に送信することができる。
通信プロトコル処理部15は、管理対象の端末装置からの初期応答を受理し、端末管理の実行に用いられる端末管理セッションを確立する。通信プロトコル処理部15は、端末装置2と端末管理サーバ1との間における各種メッセージを伝送するためのプロトコルに関する処理を実行する。
DDF選択部16は、DDF選択要求を受理し、DDF格納部17に格納されているDDFの中から、管理対象の端末装置のDDFを選択する。
なお、端末管理要求処理部10は、さらにポリシー情報322の生成を要求するポリシー生成要求を生成してもよい。また、端末管理サーバ1は、当該ポリシー生成要求を受理し、端末装置2が初期応答にて含める端末情報を決定するためのポリシーを生成するポリシー生成部18を備えてもよい。
(4)端末管理サーバの動作例
次に、端末管理サーバ1の動作例、具体的には、端末管理サーバ1が端末装置2の遠隔管理を実行する動作例について説明する。
(4.1)動作例1
図10は、端末管理サーバ1を構成する各構成要素間において送受信されるメッセージシーケンスを示す。
図10に示すように、端末管理要求処理部10は、端末装置2の利用者を識別する利用者識別情報と、端末管理サーバ1が提供する管理サービスへのサービス要求情報を含む管理要求を管理者用端末4から受信する(ステップS200)。端末管理要求処理部10は、管理要求に含まれる利用者識別情報から、第1のメタ情報取得要求を生成する(ステップS210)。
第1のメタ情報取得要求を受理したメタ情報取得部12は、端末情報提供サーバ3から第1のメタ情報を取得する(ステップS220)。ステップS220では、端末情報要求メッセージ100(図3参照)が端末情報提供サーバ3に送信される。
メタ情報取得部12は、端末情報を第1のメタ情報として端末管理要求処理部10に通知する(ステップS230)。
第1のメタ情報を取得した端末管理要求処理部10は、第1のメタ情報を含むDDF選択要求を生成する(ステップS240)。
DDF選択要求を受理したDDF選択部16は、DDF選択要求に含まれた第1のメタ情報から端末メーカ及び端末モデルを特定し、DDF格納部17に格納されているDDFの中から当該端末装置に適したDDFをから取得する。さらに、DDF選択部16は、取得したDDFの所在場所を含むDDF選択応答を生成する(ステップS250)。
DDF選択応答を受理した端末管理要求処理部10は、圧縮したシーケンスを利用することを端末装置2に通知するためのフラグ情報(圧縮フラグ305)を含む初期メッセージ生成要求を生成する(ステップS260)。
初期メッセージ生成要求を受理した初期メッセージ生成部11は、初期メッセージ生成要求に含まれる圧縮フラグ305を内容に含む初期メッセージを生成する(ステップS270)。また、初期メッセージ生成部11は、初期メッセージ送信要求を初期メッセージ送信部14に送信する(ステップS280)。
初期メッセージ送信要求を受理した初期メッセージ送信部14は、管理対象の端末装置(端末装置2)に向けて初期メッセージを送信する(ステップS290)。
通信プロトコル処理部15は、初期メッセージに応答をした端末装置2から初期応答を受信する(ステップS300)。通信プロトコル処理部15は、受信した初期応答を端末管理命令生成部13に通知する(ステップS310)。
初期応答を受理した端末管理命令生成部13は、サービス要求情報要求を生成する(ステップS320)。また、端末管理命令生成部13は、端末管理要求処理部10からサービス要求情報応答及びDDFを取得する(ステップS330)。さらに、端末管理命令生成部13は、サービス要求情報応答及びDDFに従って管理命令を生成し、管理命令を含む端末管理メッセージの送信要求を通信プロトコル処理部15に送信する(ステップS340)。
端末管理メッセージを受理した通信プロトコル処理部15は、端末管理メッセージを端末装置2へ送信する。
(4.2)動作例2
図12は、端末管理サーバ1がポリシー生成部18を備える場合において、端末管理サーバ1を構成する各構成要素間において送受信されるメッセージシーケンスを示す。なお、以下、動作例1と異なる部分について主に説明する。
図12に示すように、ステップS250においてDDF選択応答を受理した端末管理要求処理部10は、端末装置2が初期応答に含める端末情報の決定に用いられるポリシー情報(メタ情報送信ポリシー)を生成するためのポリシー生成要求を生成する(ステップS2000)。ポリシー生成要求は、ステップS220において取得された端末情報や、管理要求を実現するために必要最小限の端末情報等を含む。
ポリシー生成要求を受理したポリシー生成部18は、ポリシー生成要求に含まれる情報に基づいてメタ情報送信ポリシーを生成し、ポリシー生成応答を生成する(ステップS2100)。
ポリシー生成応答を受理した端末管理要求処理部10は、メタ情報送信ポリシーを含む初期メッセージ生成要求を生成する(ステップS2200)。
初期メッセージ生成要求を受理した初期メッセージ生成部11は、メタ情報送信ポリシーを内容に含む初期メッセージを生成する(ステップS2300)。また、初期メッセージ生成部11は、初期メッセージ送信要求を初期メッセージ送信部14に送信する(ステップS280)。
初期メッセージ送信要求を受理した初期メッセージ送信部14は、管理対象の端末装置(端末装置2)に向けて初期メッセージを送信する(ステップS290)。
(5)端末管理サーバの構成要素の実装例
次に、端末管理サーバ1の主な構成要素の実装例について説明する。具体的には、端末管理要求処理部10、メタ情報取得部12、初期メッセージ生成部11、端末管理命令生成部13及びポリシー生成部18の実装例について説明する。
(5.1)端末管理要求処理部10
図14は、端末管理要求処理部10の動作フローチャートである。図14に示すように、端末管理要求処理部10は、管理者用端末4から管理要求を受信する(ステップS200)。
端末管理要求処理部10は、受信した管理要求に含まれる利用者識別情報を含む第1のメタ情報生成要求を生成する。また、端末管理要求処理部10は、端末情報提供サーバ3から端末情報、具体的には、第1のメタ情報を取得する(ステップS202)。
端末管理要求処理部10は、取得した第1のメタ情報を含むDDF選択要求を生成し、生成したDDF選択要求をDDF選択部16に通知する。また、端末管理要求処理部10は、DDFの所在場所を示す情報を取得する(ステップS203)。
DDFは、独自の構成を備える端末装置を端末管理システム500に収容するための枠組みである。そのため、本実施形態では、端末メーカ、端末モデルごとにDDF格納部17において管理されていることを想定する。第1のメタ情報にIMEIが含まれる場合、IMEIの構成要素であるType Approval Code(TAC)から端末メーカと端末のモデルを特定することができる。すなわち、DDF選択要求に端末情報としてIMEIを含めることによって、DDF選択部16は、DDFを特定することができる。
さらに、端末管理要求処理部10は、端末情報を既に取得済みであってシーケンス圧縮を行うことを通知するための情報であるフラグ情報(圧縮フラグ305)を真にするよう、初期メッセージ生成要求を生成する(ステップS260)。
また、端末管理要求処理部10は、端末管理命令生成部13より、サービス要求情報要求を受信する(ステップS320)。端末管理要求処理部10は、管理要求に含まれるサービス要求情報と、DDFの所在場所を示す情報を含むサービス要求情報応答を生成する(ステップS330)。
(5.2)メタ情報取得部12
図15は、メタ情報取得部12の動作フローチャートである。図15に示すように、メタ情報取得部12は、端末管理要求処理部10から第1のメタ情報取得要求を受理する(ステップS210)。メタ情報取得部12は、第1のメタ情報取得要求に含まれる利用者識別情報を用いて、端末情報要求を生成し、端末情報提供サーバ3から端末情報を取得する(ステップS220)。
さらに、メタ情報取得部12は、取得した端末情報を第1のメタ情報として端末管理要求処理部10に通知する(ステップS230)。
(5.3)初期メッセージ生成部11
図16は、初期メッセージ生成部11の動作フローチャートである。なお、本実施形態では、OMA-DMが標準規格化したDM Notificationのデータフォーマットに従った初期メッセージが生成されるものとする。
図16に示すように、初期メッセージ生成部11は、端末管理要求処理部10から初期メッセージ生成要求を受理する(ステップS260)。初期メッセージ生成部11は、端末装置2を起動するため、Trigger Header302(図5等を参照)を生成する(ステップS271)。さらに、初期メッセージ生成部11は、初期メッセージ生成要求に含まれる圧縮フラグ305のとるべき値を用いて、圧縮フラグ305の内容を設定する(ステップS272)。
初期メッセージ生成部11は、圧縮フラグ305を含むTrigger Body304(図5等参照)を生成し、Trigger Header302及びTrigger Body304のDigest301(図5等参照)を生成する(ステップS273)。さらに、初期メッセージ生成部11は、生成されたDigest301、Trigger Header302及びTrigger Body304を含む初期メッセージ(例えば、初期メッセージ300)を端末装置2に送信する初期メッセージ送信要求を初期メッセージ送信部14に送信する(ステップS280)。
(5.4)端末管理命令生成部13
図17は、端末管理命令生成部13の動作フローチャートである。図17に示すように、端末管理命令生成部13は、端末装置2から初期応答を受理する(ステップS311)。端末管理命令生成部13は、管理要求に含まれたサービス要求情報と端末装置2のDDFとを取得するためのサービス要求情報要求を端末管理要求処理部10に送信し、端末管理要求処理部10からサービス要求情報とDDFとを取得する(ステップS312)。
端末管理命令生成部13は、取得したサービス要求情報とDDFとに基づいて端末管理メッセージを生成する(ステップS313)。端末管理命令生成部13は、生成した端末管理メッセージを端末装置2に送信させる送信要求を通信プロトコル処理部15に送信する(ステップS340)。
(5.5)ポリシー生成部18
図18は、ポリシー生成部18の動作フローチャートである。図18に示すように、ポリシー生成部18は、端末管理要求処理部10からポリシー生成要求を受理する(ステップS2001)。ポリシー生成部18は、ポリシー生成要求に含まれる第1のメタ情報と、管理要求に必要な端末情報とを比較する(ステップS2002)。
ポリシー生成部18は、当該管理要求を実行するためには不足している端末情報を同定し、同定された端末情報を端末装置2に要求するためのポリシー情報322(図27参照)を生成する(ステップS2003)。ポリシー生成部18は、ポリシー情報を含むポリシー生成応答を生成する(ステップS2004)。
図19は、ポリシー生成部18の他の動作フローチャートである。ここでは、ポリシー生成部18は、管理対象端末(端末装置2)の条件を端末装置2に通知するためのポリシー情報322を生成する機能を備える。
図19に示すように、ステップS2001、S2003及びS2004は、図18に示した処理と同様である。
ポリシー生成部18は、第1のメタ情報に含まれる情報の中から端末情報の一部を抽出する(ステップS2005)。抽出する情報は、例えば、想定管理端末識別子324(図27参照)である。
また、ポリシー生成部18は、管理要求に必要な端末情報の中から端末情報の一部を抽出する(ステップS2008)。抽出する情報は、例えば、想定言語設定情報325(図27参照)である。
図20は、ポリシー生成部18のさらに他の動作フローチャートである。ここでは、ポリシー生成部18において生成されたポリシー情報のサイズ(データサイズ)が、用いられる伝送媒体(例えば、SMS)のデータサイズ上限値を超える場合に対応する機能を備える。
図20に示すように、ステップS2003は、図18に示した処理と同様である。ポリシー生成部18は、ポリシー情報322のデータサイズがあらかじめ定めたデータサイズ上限値を超えるか否かを確認する(ステップS2006)。
ポリシー生成部18は、ポリシー情報322のデータサイズがデータサイズ上限値を超える場合、URIフラグ332(図28参照)を真にする(ステップS2007)。
また、ポリシー生成部18は、実のポリシー情報の代わりに、実のポリシー情報の所在場所を示す情報(URIなど)を初期メッセージに含むようポリシー生成応答を生成する(ステップS2004)。
(6)端末装置の構成例
図9は、端末装置2の機能ブロック図である。図9に示すように、端末装置2は、初期メッセージ処理部20、端末管理処理部21、第2のメタ情報生成部22、初期メッセージ受信部23、通信プロトコル処理部24及び端末情報格納部26を備える。
初期メッセージ処理部20は、初期メッセージ受信部23を介して端末管理サーバ1によって送信された初期メッセージ(例えば、初期メッセージ300)を処理する。具体的には、初期メッセージ処理部20は、初期メッセージに従って第2のメタ情報生成要求、及び端末管理処理要求を生成する。
端末管理処理部21は、初期メッセージ処理部20から端末管理処理要求を受理する。端末管理処理部21は、受理した端末管理処理要求に従って、初期応答を生成し、生成した初期応答を端末管理サーバ1に通知する。また、端末管理処理部21は、端末管理サーバ1によって送信された端末管理メッセージに従って管理処理を実行する。
第2のメタ情報生成部22は、第2のメタ情報生成要求に従って、初期応答に含める第2のメタ情報を生成する。具体的には、第2のメタ情報生成部22は、端末管理サーバ1から受信した初期メッセージに含まれるフラグ情報に基づいて第2のメタ情報を端末管理サーバ1に送信する。本実施形態では、初期メッセージ処理部20と第2のメタ情報生成部22とによって、第2のメタ情報送信部が構成される。
第2のメタ情報生成部22は、端末管理サーバ1が第1のメタ情報を取得済みでないことがフラグ情報によって示されている場合のみ、第2のメタ情報を端末管理サーバ1に送信することができる。
また、第2のメタ情報生成部22は、端末管理サーバ1から受信した初期メッセージに含まれる第1のメタ情報と、端末情報格納部26に格納されている端末装置2の端末情報、すなわち、端末装置2が保有しているメタ情報である第3のメタ情報とを比較することができる。第2のメタ情報生成部22は、第1のメタ情報に含まれる情報要素と、第3のメタ情報に含まれる情報要素とが一致しない場合、一致しない情報要素を含む第2のメタ情報を端末管理サーバ1に送信する。
さらに、第2のメタ情報生成部22は、端末管理サーバ1から受信したポリシー情報322(メタ情報送信ポリシー)に基づいて、第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む第2のメタ情報を端末管理サーバ1に送信することができる。また、第2のメタ情報生成部22は、ポリシー情報の所在場所を示すURIフラグ332(図28参照)を端末管理サーバ1から受信し、受信したURIフラグ332を用いてポリシー情報を取得することもできる。
初期メッセージ受信部23は、端末管理サーバ1によって送信された初期メッセージを受信する。
通信プロトコル処理部24は、端末管理の実行に用いられる端末管理セッションを確立する。通信プロトコル処理部24は、端末装置2と端末管理サーバ1との間における各種メッセージを伝送するためのプロトコルに関する処理を実行する。
端末情報格納部26は、端末装置2を説明する端末情報(第3のメタ情報)を格納する。
なお、初期メッセージ処理部20は、受信した初期メッセージに従って、さらにポリシー処理要求を生成してもよい。また、端末装置2は、当該ポリシー処理要求に従って、第2のメタ情報を生成するための処理を実行するポリシー処理部25を備えてもよい。
また、端末装置2は、端末装置2の利用者を識別する利用者識別情報が格納された記憶媒体(ICカード)、具体的には、SIMカードの接続履歴を記録する履歴管理部27を備えてもよい。すなわち、端末装置2は、利用者識別情報及び端末装置2自体を識別する識別情報を含む耐タンパ性を有するICカードの着脱履歴を管理する。
(7)端末装置の動作例
次に、装置の動作例、具体的には、端末装置2が端末管理サーバ1から送信された初期メッセージ及び端末管理メッセージに基づいて遠隔管理を実行する動作例について説明する。
(7.1)動作例1
図11は、端末装置2を構成する各構成要素間において送受信されるメッセージシーケンスを示す。
図11に示すように、初期メッセージ受信部23は、端末管理サーバ1によって送信された初期メッセージを受信する(ステップS400)。初期メッセージ受信部23は、初期メッセージを初期メッセージ処理部20に通知する(ステップS410)。
初期メッセージ処理部20は、初期メッセージ受信部23から通知された初期メッセージに含まれるパラメータを確認し、当該パラメータにフラグ情報(圧縮フラグ305)が有るか否かを判定する(ステップS420)。さらに、初期メッセージ処理部20は、圧縮フラグ305の値を含む第2のメタ情報生成要求を生成する(ステップS430)。
第2のメタ情報生成要求を受理した第2のメタ情報生成部22は、第2のメタ情報生成要求に含まれる圧縮フラグ305の値に従って、第2のメタ情報の生成方法を決定する。例えば、圧縮フラグ305の値が真である場合、第2のメタ情報生成部22は、端末情報を含めない旨を通知する情報を第2のメタ情報として生成する。一方、圧縮フラグの値が偽である場合、第2のメタ情報生成部22は、端末情報格納部26に格納されている端末装置2の端末情報を第2のメタ情報として生成する(ステップS440)。
第2のメタ情報を受理した初期メッセージ処理部20は、第2のメタ情報を初期応答に含むことを要求する初期応答要求を生成する(ステップS450)。
初期応答要求を受理した端末管理処理部21は、初期応答を生成する(ステップS460)。
初期応答を受理した通信プロトコル処理部24は、端末管理サーバ1に初期応答を送信する(ステップS470)。
(7.2)動作例2
図13は、端末装置2がポリシー処理部25を備える場合において、端末装置2を構成する各構成要素間において送受信されるメッセージシーケンスを示す。なお、以下、動作例1と異なる部分について主に説明する。
図13に示すように、ステップS420においてパラメータを確認した初期メッセージ処理部20は、当該パラメータに含まれるポリシー情報(メタ情報送信ポリシー)を抽出し、ポリシー処理要求を生成する(ステップS4000)。
ポリシー処理要求を受理したポリシー処理部25は、ポリシー処理要求に含まれるポリシー情報に従って第2のメタ情報を生成するためのポリシー処理を実行し、ポリシー処理応答を生成する(ステップS4100)。
ポリシー処理応答を受理した初期メッセージ処理部20は、第2のメタ情報生成要求を生成する(ステップ430)。なお、本実施形態では、端末装置2は、初期メッセージに対して必ず初期応答を端末管理サーバ1に返すこと(図2のステップS107参照)を想定しているが、ポリシー処理の結果によっては、初期応答を端末管理サーバ1に返さなくてもよい。
例えば、初期メッセージに含まれるポリシーとして想定管理端末識別子324が含まれている場合、初期応答を端末管理サーバ1に返さないようにしてもよい。すなわち、想定管理端末識別子324は、端末管理サーバ1が想定する管理対象の端末を一意に特定するための識別子である。初期メッセージに含まれる想定管理端末識別子324と、端末装置2自体が管理している端末情報(第3のメタ情報)とを比較した結果、内容が不一致である場合、端末装置2は、端末管理サーバ1が想定している端末装置ではないと判定し、初期応答を返さない。
端末装置2がこのように動作することによって、ネットワーク5における負荷を軽減できる。なお、端末装置2が初期応答を端末管理サーバ1に返さない場合、端末管理サーバ1は、端末装置2における初期メッセージの処理状態を正確に把握できない。そこで、端末装置2は、第2のメタ情報生成部22によって生成された第2のメタ情報をエラー応答用の情報として用いてもよい。
(7.3)動作例3
図29は、端末装置2が履歴管理部27を備える場合において、端末装置2を構成する各構成要素間において送受信されるメッセージシーケンスを示す。なお、以下、動作例1と異なる部分について主に説明する。
図29に示すように、ステップS420においてパラメータを確認した初期メッセージ処理部20は、当該パラメータにポリシー情報が含まれている場合、履歴取得要求を生成する(ステップS4010)。
履歴取得要求を受理した履歴管理部27は、SIMカードの接続履歴を初期メッセージ処理部20に通知する(ステップS4020)。
SIMカードの接続履歴を取得した初期メッセージ処理部20は、通知された接続履歴に基づいて、SIMカードの接続経過時間を算出する。初期メッセージ処理部20は、算出した接続経過時間と、あらかじめ定められた閾値と比較をし、算出した接続経過時間が閾値を下回る場合、ポリシー処理要求を生成する(ステップS4000)。
一方、算出した接続経過時間が閾値以上の場合、初期メッセージ処理部20は、ステップS4000及びS4010の処理を実行せず、第2のメタ情報生成要求を生成する(ステップS430)。
(8)端末装置の構成要素の実装例
次に、端末装置2の主な構成要素の実装例について説明する。具体的には、初期メッセージ処理部20、端末管理処理部21、第2のメタ情報生成部22、ポリシー処理部25及び履歴管理部27の実装例について説明する。
(8.1)初期メッセージ処理部20(実装例1)
図21は、初期メッセージ処理部20の動作フローチャートである。図21に示すように、初期メッセージ処理部20は、初期メッセージ(例えば、初期メッセージ300)を受理する(ステップS410)。初期メッセージ処理部20は、Boolean変数iを初期化(Falseを代入)する(ステップS411)。
初期メッセージ処理部20は、初期メッセージ300に含まれるパラメータ303の内容を確認する(ステップS420)。具体的には、初期メッセージ処理部20は、圧縮フラグ305の有無を確認する(ステップS421)。
初期メッセージ処理部20は、パラメータ303に圧縮フラグ305が含まれている場合、変数iに圧縮フラグ305の値を代入する(ステップS422)。一方、初期メッセージ処理部20は、パラメータ303に圧縮フラグ305が含まれていない場合、変数iの値を変更することなく、変数iを引数に持つ第2のメタ情報生成要求を生成し、生成した第2のメタ情報生成要求を第2のメタ情報生成部22に通知する(ステップS430)。
さらに、初期メッセージ処理部20は、第2のメタ情報生成部22から第2のメタ情報生成応答を受理する(ステップS440)。初期メッセージ処理部20は、第2のメタ情報を含む初期応答要求を生成し、生成した初期応答要求を端末管理処理部21に通知する(ステップS450)。
(8.2)端末管理処理部21
図22は、端末管理処理部21の動作フローチャートである。なお、端末管理処理部21の機能は、初期メッセージ処理部20から初期応答要求を受理し、初期応答を生成する機能と、端末管理メッセージを受理し、管理処理を実行する機能とを有するが、ここでは、初期応答を生成する機能に関する動作について説明する。管理処理を実行する機能は、OMA-DMの標準規格に準拠したデバイス管理クライアントを利用するによって実現できる。
図22に示すように、端末管理処理部21は、初期メッセージ処理部20から初期応答要求を受理する(ステップS450)。端末管理処理部21は、受理した初期応答要求に含まれる第2のメタ情報を含む初期応答を生成する(ステップS451)。
さらに、端末管理処理部21は、生成した初期応答を端末管理サーバ1に送信するため、初期応答送信要求を通信プロトコル処理部24に送信する(ステップS460)。
(8.3)第2のメタ情報生成部22
図23は、第2のメタ情報生成部22の動作フローチャートである。図23に示すように、第2のメタ情報生成部22は、Boolean変数iを引数に持つ第2のメタ情報生成要求を受理する(ステップS430)。第2のメタ情報生成部22は、変数iの値がTrueであるかを確認する(ステップS431)。
第2のメタ情報生成部22は、変数iの値がTrueである場合、端末情報を初期応答に含めないことを示す情報を生成する(ステップS432)。一方、第2のメタ情報生成部22は、変数iの値がFalseである場合、端末情報格納部26に格納されている端末情報(第3のメタ情報)を取得する(ステップS433)。
第2のメタ情報生成部22は、ステップS432で生成した情報、または第3のメタ情報の内容を第2のメタ情報とした端末情報を生成する(ステップS434)。さらに、第2のメタ情報生成部22は、生成した第2のメタ情報を含む第2のメタ情報生成応答を生成する(ステップS440)。
(8.4)初期メッセージ処理部20(実装例2)
図24は、ポリシー処理部25を含む場合における初期メッセージ処理部20の動作フローチャートである。なお、ステップS440以降の処理は、図21と同様であるため、説明を省略する。
図24に示すように、初期メッセージ処理部20は、初期メッセージ(例えば、初期メッセージ320)を受理する(ステップS410)。初期メッセージ処理部20は、Boolean変数iを初期化(Falseを代入)するとともに、文字列を格納する変数Pを初期化(Nullを代入)する(ステップS412)。
初期メッセージ処理部20は、初期メッセージ320に含まれるパラメータ321の内容を確認する(ステップS420)。具体的には、初期メッセージ処理部20は、圧縮フラグ305の有無を確認する(ステップS421)。
初期メッセージ処理部20は、パラメータ321に圧縮フラグ305が含まれている場合、変数iに圧縮フラグ305の値を代入する(ステップS422)。一方、初期メッセージ処理部20は、パラメータ303に圧縮フラグ305が含まれていない場合、変数iの値を変更することなく、変数iを引数に持つ第2のメタ情報生成要求を生成し、生成した第2のメタ情報生成要求を第2のメタ情報生成部22に通知する(ステップS430)。
初期メッセージ処理部20は、パラメータ321にポリシー情報322が含まれるか否かを確認する(ステップS423)。初期メッセージ処理部20は、ポリシー情報322が存在する場合、変数Pにポリシー情報322を代入する(ステップS424)。さらに、初期メッセージ処理部20は、Pを引数とするポリシー処理要求を生成し、生成したポリシー処理要求をポリシー処理部25に通知する(ステップS425)。
初期メッセージ処理部22は、ポリシー処理部よりポリシー処理応答を受理すると(ステップS426)、変数iを引数に持つ第2のメタ情報生成要求を生成する(ステップS430)。ポリシー情報が存在しない場合は、変数iを引数に持つ第2のメタ情報生成要求を生成する(ステップS430)。
(8.5)ポリシー処理部25
図25は、ポリシー処理部25の動作フローチャートである。図25に示すように、ポリシー処理部25は、文字列を格納するPを引数に持つポリシー処理要求を受理する(ステップS4000)。ポリシー処理部25は、変数Pに基づいてポリシー情報を取得する(ステップS4001)。
さらに、ポリシー処理部25は、取得したポリシー情報の構成要素を抽出する(ステップS4002)。例えば、図27に示すポリシー情報322を受理した場合、ポリシー処理部25は、要求端末情報323、想定管理端末識別子324及び想定言語設定情報325を抽出する。また、ポリシー処理部25は、端末情報格納部26に格納されている端末情報(例えばOMA-DMで標準規格化されているDevInfo)を取得し、取得した端末情報に基づいて、端末識別子及び言語設定を抽出する(ステップS4003)。
ポリシー処理部25は、ステップS4002において抽出した構成要素の値と、ステップS4003において抽出した構成要素の値とを比較し、不一致である情報を端末情報格納部26に格納されている端末情報(第3のメタ情報)に追加する。本実施形態では、ポリシー処理部25は、端末識別子と想定管理端末識別子324とを比較する(ステップS4004)。ポリシー処理部25は、端末識別子と想定管理端末識別子324とが不一致である場合に限り端末情報格納部26に格納されている端末情報に端末識別子を追加する(ステップS4005)。
また、ポリシー処理部25は、言語設定と想定言語設定情報325とを比較する(ステップS4006)。ポリシー処理部25は、言語設定と想定言語設定情報325とが不一致である場合に限り端末情報格納部26に格納されている端末情報に言語設定を追加する(ステップS4007)。
さらに、ポリシー処理部25は、ポリシー情報に要求端末情報が含まれている場合、要求端末情報に従って、ステップS4003において取得した端末情報に基づいて、要求端末情報に記載された端末情報を抽出し、抽出した端末情報を端末情報格納部26に格納されている端末情報に追加する(ステップS4008)。ポリシー処理部25は、追加された端末情報を端末情報格納部26に格納する(ステップS4009)。さらに、ポリシー処理部25は、ポリシー処理応答を生成する(ステップS4010)。
なお、図28に示すような初期メッセージ330によってポリシー情報、具体的には、URIフラグ332及びポリシーURI333が送信された場合、ポリシー処理部25は、変数Pに基づいてポリシー情報を取得し、URIフラグ332を確認する。ポリシー処理部25は、URIフラグ332の値が真である場合、URIフラグ332以降の情報、つまり、ポリシーURI333を抽出し、ポリシーURI333に従って実のポリシー情報をダウンロードする。
(8.6)初期メッセージ処理部20(実装例3)
図30は、ポリシー処理部25及び履歴管理部27を含む場合における初期メッセージ処理部20の動作フローチャートである。以下、図24に示した動作フローチャートと異なる部分について主に説明する。
初期メッセージ処理部20は、ポリシー情報が存在する場合、履歴管理部27からICカード(SIMカード)の接続履歴を取得し、ICカードの接続経過時間と、あらかじめ定められた閾値を比較する(ステップS4010)。
初期メッセージ処理部20は、ICカードの接続経過時間が当該閾値を下回る場合に限り、変数Pにポリシー情報322を代入する(ステップS424)。
(8.7)履歴管理部27
図31は、履歴管理部27の動作フローチャートである。図31に示すように、履歴管理部27は、SIMカードの利用者を識別する識別子と、SIMカード自体を識別するIC識別情報を含むSIMカードの接続、具体的には、スロットへのSIMカードの挿入を検知する(ステップS500)。履歴管理部27は、履歴管理部27がスロットに挿入されたことを検知した検知時刻を保存する(ステップS501)。
また、履歴管理部27は、初期メッセージ処理部20によって送信された履歴取得要求を受理する(ステップS510)。初期メッセージ処理部20は、受理した履歴取得要求に応じて、ステップS501において保存した検知時刻を初期メッセージ処理部20に通知する(ステップS511)。
(9)作用・効果
端末管理システム500によれば、第1のメタ情報を取得済みであるか否かを示す圧縮フラグ305を含む初期メッセージ(例えば、初期メッセージ300)が端末管理サーバ1から端末装置2に送信される。また、端末管理サーバ1は、端末装置2から第2のメタ情報を受信した場合、第2のメタ情報に基づいて端末管理メッセージを生成する。
すなわち、端末管理システム500によれば、端末装置2は、端末管理セッションの確立時に、第2のメタ情報を端末管理サーバ1に常時アップロードする必要がない。このため、端末管理サーバ1と端末装置2との端末管理セッションの確立までの時間を短縮することができる。また、端末管理システム500によれば、圧縮フラグ305を確認する機能を有していない端末装置は、従来のように第2のメタ情報を端末管理サーバ1にアップロードする。端末管理サーバ1は、アップロードされた第2のメタ情報に基づいて端末管理メッセージを生成することができる。このため、端末管理サーバ1の機能改修に伴う開発コストの増大を抑制しつつ、端末装置の最新状態に基づいた適切な遠隔管理を実現できる。
本実施形態では、端末装置2(第2のメタ情報生成部22)は、端末管理サーバ1から受信した初期メッセージに含まれる第1のメタ情報に含まれる情報要素と、端末装置2に格納されている第3のメタ情報に含まれる情報要素とが一致しない場合、一致しない情報要素を含む第2のメタ情報を端末管理サーバ1に送信する。このため、端末装置2に装着されていたICカード(SIMカード)が端末装置2の利用者によって差し換えられた場合等でも、端末装置の最新状態に基づいた適切な遠隔管理を実現できる。
本実施形態では、端末装置2(第2のメタ情報生成部22)は、端末管理サーバ1から受信したポリシー情報(メタ情報送信ポリシー)に基づいて、端末情報提供サーバ3から取得した第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む第2のメタ情報を端末管理サーバ1に送信する。このため、端末情報提供サーバ3から取得できなかった端末情報(DevInfo)の情報要素、例えば、端末装置2に設定されている言語を示す想定言語設定情報325をさらに取得できる。
さらに、端末装置2(第2のメタ情報生成部22)は、URIフラグ332を含む初期メッセージ330を端末管理サーバ1から受信し、URIフラグ332を用いてメタ情報送信ポリシーをダウンロードすることができる。このため、OMA-DM Notificationのように自由記述が許されるフィールドサイズが小さい場合でも、端末装置2にメタ情報送信ポリシーを通知できる。
(10)その他の実施形態
上述したように、本発明の一実施形態を通じて本発明の内容を開示したが、この開示の一部をなす論述及び図面は、本発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態が明らかとなろう。
例えば、上述した本発明の実施形態では、端末装置2(第2のメタ情報生成部22)は、端末管理サーバ1から受信した初期メッセージに含まれる第1のメタ情報に含まれる情報要素と、端末装置2に格納されている第3のメタ情報に含まれる情報要素とが一致しない場合、一致しない情報要素を含む第2のメタ情報を端末管理サーバ1に送信したが、端末装置2は、必ずしも一致しない情報要素を含む第2のメタ情報を端末管理サーバ1に送信しなくてもよい。
上述した実施形態では、ポリシー情報322は、要求端末情報323、想定管理端末識別子324及び想定言語設定情報325によって構成されていたが、ポリシー情報322は、さらに他の情報要素を含んでもよい。
このように、本発明は、ここでは記載していない様々な実施の形態などを含むことは勿論である。したがって、本発明の技術的範囲は、上述の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
1…端末管理サーバ、2…端末装置、3…端末情報提供サーバ、4…管理者用端末、5…ネットワーク、10…端末管理要求処理部、11…初期メッセージ生成部、12…メタ情報取得部、13…端末管理命令生成部、14…初期メッセージ送信部、15…通信プロトコル処理部、16…DDF選択部、17…DDF格納部、18…ポリシー生成部、20…初期メッセージ処理部、21…端末管理処理部、22…第2のメタ情報生成部、23…初期メッセージ受信部、24…通信プロトコル処理部、25…ポリシー処理部、26…端末情報格納部、27…履歴管理部、100…端末情報要求メッセージ、200…端末情報応答メッセージ、300…初期メッセージ、301…Digest、302…Trigger Header、303…パラメータ、304…Trigger Body、305…圧縮フラグ、310…初期メッセージ、311…パラメータ、312…第1のメタ情報、320…初期メッセージ、321…パラメータ、322…ポリシー情報、323…要求端末情報、324…想定管理端末識別子、325…想定言語設定情報、330…初期メッセージ、331…パラメータ、332…URIフラグ、333…ポリシーURI、400…初期応答、410…情報、450…初期応答、451…情報、500…端末管理システム