(57)【特許請求の範囲】
【請求項１】
端末装置を呼び出す初期メッセージ、及び前記端末装置を遠隔管理する端末管理命令を生成する端末管理サーバと、
前記端末管理サーバから受信した前記初期メッセージに基づいて、前記端末装置を説明するメタ情報を前記端末管理サーバに送信する端末装置と
を含む端末管理システムであって、
前記端末管理サーバは、
端末情報提供サーバが保有している前記メタ情報である第1のメタ情報を前記端末情報提供サーバから取得済みであるか否かを示すフラグ情報を含む前記初期メッセージを前記端末装置に送信する初期メッセージ送信部と、
前記端末装置が保有している前記メタ情報を含む第２のメタ情報を前記端末装置から受信する第２のメタ情報受信部と、
前記第1のメタ情報または前記第２のメタ情報に基づいて前記端末管理命令を生成する端末管理命令生成部と
を備え、
前記端末装置は、
前記端末管理サーバから受信した前記初期メッセージに含まれる前記フラグ情報に基づいて、前記第２のメタ情報を前記端末管理サーバに送信する第２のメタ情報送信部を備え、
前記端末管理命令生成部は、前記端末装置から前記第２のメタ情報を受信した場合、前記第２のメタ情報に基づいて前記端末管理命令を生成する端末管理システム。
【請求項２】
前記第２のメタ情報送信部は、前記端末管理サーバが前記第1のメタ情報を取得済みでないことが前記フラグ情報によって示されている場合のみ、前記第２のメタ情報を前記端末管理サーバに送信する請求項１に記載の端末管理システム。
【請求項３】
前記初期メッセージ送信部は、前記端末情報提供サーバから取得した前記第1のメタ情報を含む前記初期メッセージを前記端末装置に送信し、
前記第２のメタ情報送信部は、
前記端末管理サーバから受信した初期メッセージに含まれる前記第1のメタ情報と、前記端末装置が保有している前記メタ情報である第３のメタ情報とを比較し、
前記第1のメタ情報に含まれる情報要素と、前記第３のメタ情報に含まれる情報要素とが一致しない場合、一致しない前記情報要素を含む前記第２のメタ情報を前記端末管理サーバに送信する請求項１に記載の端末管理システム。
【請求項４】
前記端末管理サーバは、前記端末装置の遠隔管理の際に、前記端末情報提供サーバから取得した前記第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む前記第２のメタ情報の送信を前記端末装置に要求するメタ情報送信ポリシーを生成する端末管理要求処理部を備え、
前記第２のメタ情報送信部は、前記端末管理サーバから受信した前記メタ情報送信ポリシーに基づいて、前記不足情報要素を含む前記第２のメタ情報を前記端末管理サーバに送信する請求項１に記載の端末管理システム。
【請求項５】
前記端末管理要求処理部は、前記メタ情報送信ポリシーの所在場所を示すURIフラグを前記端末装置に送信し、
前記第２のメタ情報送信部は、前記URIフラグを前記端末管理サーバから受信し、受信した前記URIフラグを用いて前記メタ情報送信ポリシーを取得する請求項４に記載の端末管理システム。
【請求項６】
前記メタ情報は、Open Mobile Alliance Device Management WGにおけるOMA-DM Standardized Objectにおいて規定されるDevInfoに従った情報要素を含み、
前記初期メッセージは、前記Open Mobile Alliance Device Management WGにおけるOMA-DM Protocolにおいて規定されるSetup Phaseにおいて、前記端末管理サーバから前記端末装置に送信される請求項１に記載の端末管理システム。
【請求項７】
端末装置を呼び出す初期メッセージ、及び前記端末装置を説明するメタ情報に基づいて前記端末装置を遠隔管理する端末管理命令を生成する端末管理サーバであって、
端末情報提供サーバが保有している前記メタ情報である前記第1のメタ情報を端末情報提供サーバから取得済みであるか否かを示すフラグ情報を含む前記初期メッセージを前記端末装置に送信する初期メッセージ送信部と、
前記端末装置が保有している前記メタ情報を含む第２のメタ情報を前記端末装置から受信する第２のメタ情報受信部と、
前記第1のメタ情報または前記第２のメタ情報に基づいて前記端末管理命令を生成する端末管理命令生成部と
を備え、
前記端末管理命令生成部は、前記端末装置から前記第２のメタ情報を受信した場合、前記第２のメタ情報に基づいて前記端末管理命令を生成する端末管理サーバ。
【請求項８】
前記初期メッセージ送信部は、前記端末情報提供サーバから取得した前記第1のメタ情報を含む前記初期メッセージを前記端末装置に送信する請求項７に記載の端末管理サーバ。
【請求項９】
前記端末装置の遠隔管理の際に、前記端末情報提供サーバから取得した前記第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む前記第２のメタ情報の送信を前記端末装置に要求するメタ情報送信ポリシーを生成する端末管理要求処理部を備える請求項７に記載の端末管理サーバ。
【請求項１０】
前記端末管理要求処理部は、前記メタ情報送信ポリシーの所在場所を示すURIフラグを前記端末装置に送信する請求項９に記載の端末管理サーバ。
【請求項１１】
端末管理サーバから送信される初期メッセージ及び端末管理命令に基づいて、前記端末管理サーバによって遠隔管理される端末装置であって、
前記初期メッセージは、前記端末装置を説明するメタ情報であって端末情報提供サーバが保有している第1のメタ情報を端末管理サーバが前記端末情報提供サーバから取得済みであるか否かを示すフラグ情報を含み、
前記端末管理サーバから受信した前記初期メッセージに含まれる前記フラグ情報に基づいて、前記端末装置を説明する第２のメタ情報を前記端末管理サーバに送信する第２のメタ情報送信部を備える端末装置。
【請求項１２】
前記第２のメタ情報送信部は、前記端末管理サーバが前記第1のメタ情報を取得済みでないことが前記フラグ情報によって示されている場合のみ、前記第２のメタ情報を前記端末管理サーバに送信する請求項１１に記載の端末装置。
【請求項１３】
前記第２のメタ情報送信部は、
前記端末管理サーバから受信した前記初期メッセージに含まれる前記第1のメタ情報と、前記端末装置が保有している前記メタ情報である第３のメタ情報とを比較し、
前記第1のメタ情報に含まれる情報要素と、前記第３のメタ情報に含まれる情報要素とが一致しない場合、一致しない前記情報要素を含む前記第２のメタ情報を前記端末管理サーバに送信する請求項１２に記載の端末装置。
【請求項１４】
前記端末装置の利用者を識別する利用者識別情報が格納された記憶媒体の接続履歴を記録する履歴管理部と、
前記第２のメタ情報送信部は、前記履歴管理部において記録された前記接続履歴に基づいて、前記記憶媒体が接続されている時間が所定時間を上回る場合、前記第1のメタ情報と前記第３のメタ情報との比較を中止する請求項１３に記載の端末装置。
【請求項１５】
前記第２のメタ情報送信部は、前記端末管理サーバから受信したメタ情報送信ポリシーに基づいて、前記端末装置の遠隔管理に際に、前記端末管理サーバが前記端末情報提供サーバから取得した前記第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む前記第２のメタ情報を前記端末管理サーバに送信する請求項１１に記載の端末装置。
【請求項１６】
前記第２のメタ情報送信部は、前記メタ情報送信ポリシーの所在場所を示すURIフラグを前記端末管理サーバから受信し、受信した前記URIフラグを用いて前記メタ情報送信ポリシーを取得する請求項１５に記載の端末装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末装置を説明するメタ情報に基づいて初期メッセージ及び端末管理命令を生成する端末管理システム、端末管理サーバ、及び当該端末管理サーバによって遠隔管理される端末装置に関する。
【背景技術】
【０００２】
携帯電話端末やＰＤＡ等のモバイル端末、つまり、携帯可能な端末装置の高性能化、高機能化に伴い、端末装置上で取り扱われるデータの重要性が高まっている。例えば、端末装置と連携した業務システムでは、顧客の個人情報等、重要度及び機密度が極めて高いデータが端末装置において取り扱われる。
【０００３】
このような端末装置が紛失したり、盗難されたりすると、当該端末装置を不正に入手した第三者によって重要なデータが漏洩するリスクがある。このような背景から、端末装置に格納されたデータをリアルタイムに遠隔管理する方法が提案されている。
【０００４】
例えば、モバイル端末に関連する技術の標準化団体であるOpen Mobile Alliance（OMA）では、端末装置（端末管理クライアント）と端末管理サーバとの間における端末管理を実施するためのプロトコルが提案されている（非特許文献１参照）。
【０００５】
具体的には、当該プロトコルでは、端末管理サーバと端末管理クライアントとの管理セッションの初期化を実施するSetup Phaseと、端末管理サーバが端末管理クライアントに端末管理命令を送信することによって管理処理を実施するManagement Phaseが存在する。
【０００６】
Setup Phaseでは、端末管理サーバが管理対象の端末管理クライアントを特定して端末管理命令を生成するために、端末管理クライアントが端末識別子（IMEI）などを含む端末情報（DevInfo）を端末管理サーバにアップロードする。端末情報を受信した端末管理サーバは、管理対象の端末管理クライアントの端末識別子等から、端末管理クライアント上の管理対象リソースを抽象化したデータオブジェクト、具体的には、Management Object（MO）のデータ構造を解決し、端末管理命令を生成する。
【非特許文献１】OMA Device Management Protocol  OMA - TS - DM - Protocol- V1_2-20070209-A、［online］、２００７年２月、OMA、［２００７年１０月２２日検索］インターネット＜URL：http: //www. openmobilealliance.org /release_program /docs/DM/V1_2-20070209-A/OMA-TS-DM_Protocol-V1_2-20070209-A.pdf＞
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上述した従来の方法には、次のような問題があった。すなわち、端末管理クライアントは、Setup Phaseにおいて端末情報を端末管理サーバにアップロードするため、端末管理サーバと端末管理クライアントとの端末管理セッションの確立までの時間が長い。このため、端末管理クライアントの管理処理に要する時間が長くなる問題がある。
【０００８】
一方、端末管理セッションの確立までの時間を短縮するため、当該プロトコルに従った通信シーケンスを圧縮した独自方式を導入すると、当該独自方式に対応していない端末装置の管理処理を実施することができない。或いは、端末管理サーバは、当該プロトコルに従った方式、及び当該プロトコルに従った通信シーケンスを圧縮した独自方式の両方式に対応する必要がある。このような対応は、端末管理サーバの開発コストを増大させる。
【０００９】
そこで、本発明は、このような状況に鑑みてなされたものであり、端末管理サーバの開発コストの増大を抑制しつつ、端末装置の管理処理に要する時間、特に、端末管理サーバと端末装置との端末管理セッションの確立までの時間を短縮することができる端末管理システム、端末管理サーバ及び端末装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上述した問題を解決するため、本発明は、次のような特徴を有している。まず、本発明の第１の特徴は、端末装置を呼び出す初期メッセージ（例えば、初期メッセージ300）、及び前記端末装置を遠隔管理する端末管理命令（端末管理メッセージ）を生成する端末管理サーバ（端末管理サーバ1）と、前記端末管理サーバから受信した前記初期メッセージに基づいて、前記端末装置を説明するメタ情報を前記端末管理サーバに送信する端末装置（端末装置2）とを含む端末管理システム（端末管理システム500）であって、前記端末管理サーバは、端末情報提供サーバ（端末情報提供サーバ3）が保有している前記メタ情報である第1のメタ情報（端末情報）を前記端末情報提供サーバから取得済みであるか否かを示すフラグ情報（圧縮フラグ305）を含む前記初期メッセージを前記端末装置に送信する初期メッセージ送信部（初期メッセージ送信部14）と、前記端末装置が保有している前記メタ情報を含む第２のメタ情報を前記端末装置から受信する第２のメタ情報受信部（メタ情報取得部12）と、前記第1のメタ情報または前記第２のメタ情報に基づいて前記端末管理命令を生成する端末管理命令生成部（端末管理命令生成部13）とを備え、前記端末装置は、前記端末管理サーバから受信した前記初期メッセージに含まれる前記フラグ情報に基づいて、前記第２のメタ情報を前記端末管理サーバに送信する第２のメタ情報送信部（初期メッセージ処理部20及び第2のメタ情報生成部22）を備え、前記端末管理命令生成部は、前記端末装置から前記第２のメタ情報を受信した場合、前記第２のメタ情報に基づいて前記端末管理命令を生成することを要旨とする。
【００１１】
このような端末管理システムによれば、端末装置を説明する第1のメタ情報を取得済みであるか否かを示すフラグ情報を含む初期メッセージが端末管理サーバから端末装置に送信される。また、端末管理サーバは、端末装置から第２のメタ情報を受信した場合、第２のメタ情報に基づいて端末管理命令を生成する。
【００１２】
すなわち、このような端末管理システムによれば、端末装置は、端末装置を説明するメタ情報（端末情報）を端末管理サーバに常時アップロードする必要がない。このため、端末管理サーバと端末装置との端末管理セッションの確立までの時間を短縮することができる。また、このような端末管理システムによれば、フラグ情報を確認する機能を有していない端末装置は、従来のように、当該端末装置が保有しているメタ情報、具体的には、第２のメタ情報を端末管理サーバにアップロードする。端末管理サーバは、アップロードされた第２のメタ情報に基づいて端末管理命令を生成することができる。このため、端末管理サーバの機能改修に伴う開発コストの増大を抑制しつつ、端末装置の最新状態に基づいた適切な遠隔管理を実現できる。
【００１３】
本発明の第２の特徴は、本発明の第１の特徴に係り、前記第２のメタ情報送信部は、前記端末管理サーバが前記第1のメタ情報を取得済みでないことが前記フラグ情報によって示されている場合のみ、前記第２のメタ情報を前記端末管理サーバに送信することを要旨とする。
【００１４】
本発明の第３の特徴は、本発明の第１の特徴に係り、前記初期メッセージ送信部は、前記端末情報提供サーバから取得した前記第1のメタ情報を含む前記初期メッセージを前記端末装置に送信し、前記第２のメタ情報送信部は、前記端末管理サーバから受信した初期メッセージに含まれる前記第1のメタ情報と、前記端末装置が保有している前記メタ情報である第３のメタ情報とを比較し、前記第1のメタ情報に含まれる情報要素と、前記第３のメタ情報に含まれる情報要素とが一致しない場合、一致しない前記情報要素を含む前記第２のメタ情報を前記端末管理サーバに送信することを要旨とする。
【００１５】
本発明の第４の特徴は、本発明の第１の特徴に係り、前記端末管理サーバは、前記端末装置の遠隔管理に際に、前記端末情報提供サーバから取得した前記第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む前記第２のメタ情報の送信を前記端末装置に要求するメタ情報送信ポリシー（ポリシー情報322）を生成する端末管理要求処理部（端末管理要求処理部10）を備え、前記第２のメタ情報送信部は、前記端末管理サーバから受信した前記メタ情報送信ポリシーに基づいて、前記不足情報要素を含む前記第２のメタ情報を前記端末管理サーバに送信することを要旨とする。
【００１６】
本発明の第５の特徴は、本発明の第４の特徴に係り、前記端末管理要求処理部は、前記メタ情報送信ポリシーの所在場所を示すURIフラグ（URIフラグ332）を前記端末装置に送信し、前記第２のメタ情報送信部は、前記URIフラグを前記端末管理サーバから受信し、受信した前記URIフラグを用いて前記メタ情報送信ポリシーを取得することを要旨とする。
【００１７】
本発明の第６の特徴は、本発明の第１の特徴に係り、前記メタ情報は、Open Mobile Alliance Device Management WGにおけるOMA-DM Standardized Objectにおいて規定されるDevInfoに従った情報要素を含み、前記初期メッセージは、前記Open Mobile Alliance Device Management WGにおけるOMA-DM Protocolにおいて規定されるSetup Phaseにおいて、前記端末管理サーバから前記端末装置に送信されることを要旨とする。
【００１８】
本発明の第７の特徴は、端末装置を呼び出す初期メッセージ、及び前記端末装置を説明するメタ情報に基づいて前記端末装置を遠隔管理する端末管理命令を生成する端末管理サーバであって、端末情報提供サーバが保有している前記メタ情報である前記第1のメタ情報を端末情報提供サーバから取得済みであるか否かを示すフラグ情報を含む前記初期メッセージを前記端末装置に送信する初期メッセージ送信部と、前記端末装置が保有している前記メタ情報を含む第２のメタ情報を前記端末装置から受信する第２のメタ情報受信部と、前記第1のメタ情報または前記第２のメタ情報に基づいて前記端末管理命令を生成する端末管理命令生成部とを備え、前記端末管理命令生成部は、前記端末装置から前記第２のメタ情報を受信した場合、前記第２のメタ情報に基づいて前記端末管理命令を生成することを要旨とする。
【００１９】
本発明の第８の特徴は、本発明の第７の特徴に係り、前記初期メッセージ送信部は、前記端末情報提供サーバから取得した前記第1のメタ情報を含む前記初期メッセージを前記端末装置に送信することを要旨とする。
【００２０】
本発明の第９の特徴は、本発明の第７の特徴に係り、記端末装置の遠隔管理の際に、前記端末情報提供サーバから取得した前記第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む前記第２のメタ情報の送信を前記端末装置に要求するメタ情報送信ポリシーを生成する端末管理要求処理部を備えることを要旨とする。
【００２１】
本発明の第１０の特徴は、本発明の第９の特徴に係り、前記端末管理要求処理部は、前記メタ情報送信ポリシーの所在場所を示すURIフラグを前記端末装置に送信することを要旨とする。
【００２２】
本発明の第１１の特徴は、端末管理サーバから送信される初期メッセージ及び端末管理命令に基づいて、前記端末管理サーバによって遠隔管理される端末装置であって、前記初期メッセージは、前記端末装置を説明するメタ情報であって端末情報提供サーバが保有している第1のメタ情報を端末管理サーバが前記端末情報提供サーバから取得済みであるか否かを示すフラグ情報を含み、前記端末管理サーバから受信した前記初期メッセージに含まれる前記フラグ情報に基づいて、前記端末装置を説明する第２のメタ情報を前記端末管理サーバに送信する第２のメタ情報送信部を備えることを要旨とする。
【００２３】
本発明の第１２の特徴は、本発明の第１１の特徴に係り、前記第２のメタ情報送信部は、前記端末管理サーバが前記第1のメタ情報を取得済みでないことが前記フラグ情報によって示されている場合のみ、前記第２のメタ情報を前記端末管理サーバに送信することを要旨とする。
【００２４】
本発明の第１３の特徴は、本発明の第１２の特徴に係り、前記第２のメタ情報送信部は、前記端末管理サーバから受信した前記初期メッセージに含まれる前記第1のメタ情報と、前記端末装置に格納されている第３のメタ情報とを比較し、前記第1のメタ情報に含まれる情報要素と、前記第３のメタ情報に含まれる情報要素とが一致しない場合、一致しない前記情報要素を含む前記第２のメタ情報を前記端末管理サーバに送信することを要旨とする。
【００２５】
本発明の第１４の特徴は、本発明の第１３の特徴に係り、前記端末装置の利用者を識別する利用者識別情報が格納された記憶媒体（ＩＣカード）の接続履歴を記録する履歴管理部（履歴管理部27）と、前記第２のメタ情報送信部は、前記履歴管理部において記録された前記接続履歴に基づいて、前記記憶媒体が接続されている時間が所定時間を上回る場合、前記第1のメタ情報と前記第３のメタ情報との比較を中止することを要旨とする。
【００２６】
本発明の第１５の特徴は、本発明の第１１の特徴に係り、前記第２のメタ情報送信部は、前記端末管理サーバから受信したメタ情報送信ポリシーに基づいて、前記端末装置の遠隔管理に際に、前記端末管理サーバが前記端末情報提供サーバから取得した前記第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む前記第２のメタ情報を前記端末管理サーバに送信することを要旨とする。
【００２７】
本発明の第１６の特徴は、本発明の第１５の特徴に係り、前記第２のメタ情報送信部は、前記メタ情報送信ポリシーの所在場所を示すURIフラグを前記端末管理サーバから受信し、受信した前記URIフラグを用いて前記メタ情報送信ポリシーを取得することを要旨とする。
【発明の効果】
【００２８】
本発明の特徴によれば、端末管理サーバの開発コストの増大を抑制しつつ、端末装置の管理処理に要する時間、特に、端末管理サーバと端末装置との端末管理セッションの確立までの時間を短縮することができる端末管理システム、端末管理サーバ及び端末装置を提供することができる。
【発明を実施するための最良の形態】
【００２９】
本実施形態に係る端末管理システムは、Smart Phone、PDA、ノートPC等、可搬性を有し、ネットワークとの接続が可能なモバイル端末（以下、端末装置）を対象として、管理グループ（法人における管理者等）が端末装置の状態等を把握することによって適切な遠隔管理を実現する。以下、図面参照しつつ、本発明の実施形態について説明する。
【００３０】
具体的には、（１）端末管理システムの構成例、（２）メッセージシーケンス、（３）端末管理サーバの構成例、（４）端末管理サーバの動作例、（５）端末管理サーバの構成要素の実装例、（６）端末装置の構成例、（７）端末装置の動作例、（８）端末装置の構成要素の実装例、（９）作用・効果及び（１０）その他の実施形態について説明する。
【００３１】
なお、以下の図面の記載において、同一または類似の部分には、同一または類似の符号を付している。ただし、図面は模式的なものであり、各寸法の比率などは現実のものとは異なることに留意すべきである。
【００３２】
したがって、具体的な寸法などは以下の説明を参酌して判断すべきものである。また、図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることは勿論である。
【００３３】
（１）端末管理システムの構成例
図1は、本実施形態に係る端末管理システム500の概略構成図である。端末管理システム500は、端末管理サーバ1、端末装置2、端末情報提供サーバ3及び管理者用端末4を含む。
【００３４】
端末管理サーバ1は、携帯電話端末やＰＤＡ等のモバイル端末である端末装置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は、端末管理システム500を構成する各装置間におけるメッセージシーケンス図である。
【００４１】
図２に示すように、端末装置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として利用する。
【００６９】
（３）端末管理サーバの構成例
図8は、端末管理サーバ1の機能ブロック図である。図8に示すように、端末管理サーバ1は、端末管理要求処理部10、初期メッセージ生成部11、メタ情報取得部12、端末管理命令生成部13、初期メッセージ送信部14、通信プロトコル処理部15、DDF選択部16及びDDF格納部17を備える。
【００７０】
端末管理要求処理部10は、管理者用端末4からの管理要求を受理し、第1のメタ情報取得要求、DDF選択要求、及び初期メッセージ生成要求を生成する。
【００７１】
特に、本実施形態では、端末管理要求処理部10は、端末装置2の遠隔管理の際に、端末情報提供サーバ3から取得した第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む第２のメタ情報の送信を端末装置2に要求するポリシー情報322（メタ情報送信ポリシー）を生成する。また、端末管理要求処理部10は、ポリシー情報322の所在場所を示すURIフラグ332を含む初期メッセージ330を端末装置に送信することができる。
【００７２】
初期メッセージ生成部11は、初期メッセージ生成要求を受理し、管理対象の端末装置を起動するための初期メッセージを生成する。
【００７３】
メタ情報取得部12は、第1のメタ情報取得要求を受理し、端末情報提供サーバ3から端末情報（DevInfo）を取得する。また、メタ情報取得部12は、端末装置2が保有しているメタ情報を含む端末情報（第２のメタ情報）を端末装置2から受信することができる。本実施形態において、メタ情報取得部12は、第２のメタ情報受信部を構成する。
【００７４】
端末管理命令生成部13は、端末装置2から初期応答を受理し、管理要求に従って端末管理メッセージを生成する。特に、本実施形態では、端末管理命令生成部13は、第1のメタ情報または第２のメタ情報に基づいて端末管理メッセージを生成する。
【００７５】
具体的には、端末管理命令生成部13は、端末装置2から第２のメタ情報を受信した場合、受信した第２のメタ情報に基づいて端末管理メッセージを生成する。また、端末管理命令生成部13は、端末装置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を備えてもよい。
【００８１】
（４）端末管理サーバの動作例
次に、端末管理サーバ1の動作例、具体的には、端末管理サーバ1が端末装置2の遠隔管理を実行する動作例について説明する。
【００８２】
（４．１）動作例１
図10は、端末管理サーバ1を構成する各構成要素間において送受信されるメッセージシーケンスを示す。
【００８３】
図10に示すように、端末管理要求処理部10は、端末装置2の利用者を識別する利用者識別情報と、端末管理サーバ1が提供する管理サービスへのサービス要求情報を含む管理要求を管理者用端末4から受信する（ステップS200）。端末管理要求処理部10は、管理要求に含まれる利用者識別情報から、第1のメタ情報取得要求を生成する（ステップS210）。
【００８４】
第1のメタ情報取得要求を受理したメタ情報取得部12は、端末情報提供サーバ3から第1のメタ情報を取得する（ステップS220）。ステップS220では、端末情報要求メッセージ100（図３参照）が端末情報提供サーバ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へ送信する。
【００９４】
（４．２）動作例２
図12は、端末管理サーバ1がポリシー生成部18を備える場合において、端末管理サーバ1を構成する各構成要素間において送受信されるメッセージシーケンスを示す。なお、以下、動作例１と異なる部分について主に説明する。
【００９５】
図12に示すように、ステップS250においてDDF選択応答を受理した端末管理要求処理部10は、端末装置2が初期応答に含める端末情報の決定に用いられるポリシー情報（メタ情報送信ポリシー）を生成するためのポリシー生成要求を生成する（ステップS2000）。ポリシー生成要求は、ステップS220において取得された端末情報や、管理要求を実現するために必要最小限の端末情報等を含む。
【００９６】
ポリシー生成要求を受理したポリシー生成部18は、ポリシー生成要求に含まれる情報に基づいてメタ情報送信ポリシーを生成し、ポリシー生成応答を生成する（ステップS2100）。
【００９７】
ポリシー生成応答を受理した端末管理要求処理部10は、メタ情報送信ポリシーを含む初期メッセージ生成要求を生成する（ステップS2200）。
【００９８】
初期メッセージ生成要求を受理した初期メッセージ生成部11は、メタ情報送信ポリシーを内容に含む初期メッセージを生成する（ステップS2300）。また、初期メッセージ生成部11は、初期メッセージ送信要求を初期メッセージ送信部14に送信する（ステップS280）。
【００９９】
初期メッセージ送信要求を受理した初期メッセージ送信部14は、管理対象の端末装置（端末装置2）に向けて初期メッセージを送信する（ステップS290）。
【０１００】
（５）端末管理サーバの構成要素の実装例
次に、端末管理サーバ1の主な構成要素の実装例について説明する。具体的には、端末管理要求処理部10、メタ情報取得部12、初期メッセージ生成部11、端末管理命令生成部13及びポリシー生成部18の実装例について説明する。
【０１０１】
（５．１）端末管理要求処理部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）。
【０１０７】
（５．２）メタ情報取得部12
図15は、メタ情報取得部12の動作フローチャートである。図15に示すように、メタ情報取得部12は、端末管理要求処理部10から第1のメタ情報取得要求を受理する（ステップS210）。メタ情報取得部12は、第1のメタ情報取得要求に含まれる利用者識別情報を用いて、端末情報要求を生成し、端末情報提供サーバ3から端末情報を取得する（ステップS220）。
【０１０８】
さらに、メタ情報取得部12は、取得した端末情報を第1のメタ情報として端末管理要求処理部10に通知する（ステップS230）。
【０１０９】
（５．３）初期メッセージ生成部11
図16は、初期メッセージ生成部11の動作フローチャートである。なお、本実施形態では、OMA-DMが標準規格化したDM Notificationのデータフォーマットに従った初期メッセージが生成されるものとする。
【０１１０】
図16に示すように、初期メッセージ生成部11は、端末管理要求処理部10から初期メッセージ生成要求を受理する（ステップS260）。初期メッセージ生成部11は、端末装置2を起動するため、Trigger Header302（図５等を参照）を生成する（ステップS271）。さらに、初期メッセージ生成部11は、初期メッセージ生成要求に含まれる圧縮フラグ305のとるべき値を用いて、圧縮フラグ305の内容を設定する（ステップS272）。
【０１１１】
初期メッセージ生成部11は、圧縮フラグ305を含むTrigger Body304（図５等参照）を生成し、Trigger Header302及びTrigger Body304のDigest301(図５等参照)を生成する（ステップS273）。さらに、初期メッセージ生成部11は、生成されたDigest301、Trigger Header302及びTrigger Body304を含む初期メッセージ（例えば、初期メッセージ300）を端末装置2に送信する初期メッセージ送信要求を初期メッセージ送信部14に送信する（ステップS280）。
【０１１２】
（５．４）端末管理命令生成部13
図17は、端末管理命令生成部13の動作フローチャートである。図17に示すように、端末管理命令生成部13は、端末装置2から初期応答を受理する（ステップS311）。端末管理命令生成部13は、管理要求に含まれたサービス要求情報と端末装置2のDDFとを取得するためのサービス要求情報要求を端末管理要求処理部10に送信し、端末管理要求処理部10からサービス要求情報とDDFとを取得する（ステップS312）。
【０１１３】
端末管理命令生成部13は、取得したサービス要求情報とDDFとに基づいて端末管理メッセージを生成する（ステップS313）。端末管理命令生成部13は、生成した端末管理メッセージを端末装置2に送信させる送信要求を通信プロトコル処理部15に送信する（ステップS340）。
【０１１４】
（５．５）ポリシー生成部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）。
【０１２４】
（６）端末装置の構成例
図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のメタ情報生成部22は、端末管理サーバ1から受信した初期メッセージに含まれるフラグ情報に基づいて第２のメタ情報を端末管理サーバ1に送信する。本実施形態では、初期メッセージ処理部20と第2のメタ情報生成部22とによって、第２のメタ情報送信部が構成される。
【０１２８】
第2のメタ情報生成部22は、端末管理サーバ1が第1のメタ情報を取得済みでないことがフラグ情報によって示されている場合のみ、第２のメタ情報を端末管理サーバ1に送信することができる。
【０１２９】
また、第2のメタ情報生成部22は、端末管理サーバ1から受信した初期メッセージに含まれる第1のメタ情報と、端末情報格納部26に格納されている端末装置2の端末情報、すなわち、端末装置2が保有しているメタ情報である第３のメタ情報とを比較することができる。第2のメタ情報生成部22は、第1のメタ情報に含まれる情報要素と、第３のメタ情報に含まれる情報要素とが一致しない場合、一致しない情報要素を含む第２のメタ情報を端末管理サーバ1に送信する。
【０１３０】
さらに、第2のメタ情報生成部22は、端末管理サーバ1から受信したポリシー情報322（メタ情報送信ポリシー）に基づいて、第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む第２のメタ情報を端末管理サーバ1に送信することができる。また、第2のメタ情報生成部22は、ポリシー情報の所在場所を示すURIフラグ332（図28参照）を端末管理サーバ1から受信し、受信したURIフラグ332を用いてポリシー情報を取得することもできる。
【０１３１】
初期メッセージ受信部23は、端末管理サーバ1によって送信された初期メッセージを受信する。
【０１３２】
通信プロトコル処理部24は、端末管理の実行に用いられる端末管理セッションを確立する。通信プロトコル処理部24は、端末装置2と端末管理サーバ1との間における各種メッセージを伝送するためのプロトコルに関する処理を実行する。
【０１３３】
端末情報格納部26は、端末装置2を説明する端末情報（第３のメタ情報）を格納する。
【０１３４】
なお、初期メッセージ処理部20は、受信した初期メッセージに従って、さらにポリシー処理要求を生成してもよい。また、端末装置2は、当該ポリシー処理要求に従って、第２のメタ情報を生成するための処理を実行するポリシー処理部25を備えてもよい。
【０１３５】
また、端末装置2は、端末装置2の利用者を識別する利用者識別情報が格納された記憶媒体（ＩＣカード）、具体的には、SIMカードの接続履歴を記録する履歴管理部27を備えてもよい。すなわち、端末装置2は、利用者識別情報及び端末装置2自体を識別する識別情報を含む耐タンパ性を有するＩＣカードの着脱履歴を管理する。
【０１３６】
（７）端末装置の動作例
次に、装置の動作例、具体的には、端末装置2が端末管理サーバ1から送信された初期メッセージ及び端末管理メッセージに基づいて遠隔管理を実行する動作例について説明する。
【０１３７】
（７．１）動作例１
図11は、端末装置2を構成する各構成要素間において送受信されるメッセージシーケンスを示す。
【０１３８】
図１１に示すように、初期メッセージ受信部23は、端末管理サーバ1によって送信された初期メッセージを受信する（ステップS400）。初期メッセージ受信部23は、初期メッセージを初期メッセージ処理部20に通知する（ステップS410）。
【０１３９】
初期メッセージ処理部20は、初期メッセージ受信部23から通知された初期メッセージに含まれるパラメータを確認し、当該パラメータにフラグ情報（圧縮フラグ305）が有るか否かを判定する（ステップS420）。さらに、初期メッセージ処理部20は、圧縮フラグ305の値を含む第2のメタ情報生成要求を生成する（ステップS430）。
【０１４０】
第2のメタ情報生成要求を受理した第2のメタ情報生成部22は、第2のメタ情報生成要求に含まれる圧縮フラグ305の値に従って、第２のメタ情報の生成方法を決定する。例えば、圧縮フラグ305の値が真である場合、第2のメタ情報生成部22は、端末情報を含めない旨を通知する情報を第２のメタ情報として生成する。一方、圧縮フラグの値が偽である場合、第2のメタ情報生成部22は、端末情報格納部26に格納されている端末装置2の端末情報を第２のメタ情報として生成する（ステップS440）。
【０１４１】
第２のメタ情報を受理した初期メッセージ処理部20は、第２のメタ情報を初期応答に含むことを要求する初期応答要求を生成する（ステップS450）。
【０１４２】
初期応答要求を受理した端末管理処理部21は、初期応答を生成する（ステップS460）。
【０１４３】
初期応答を受理した通信プロトコル処理部24は、端末管理サーバ1に初期応答を送信する（ステップS470）。
【０１４４】
（７．２）動作例２
図13は、端末装置2がポリシー処理部25を備える場合において、端末装置2を構成する各構成要素間において送受信されるメッセージシーケンスを示す。なお、以下、動作例１と異なる部分について主に説明する。
【０１４５】
図13に示すように、ステップS420においてパラメータを確認した初期メッセージ処理部20は、当該パラメータに含まれるポリシー情報（メタ情報送信ポリシー）を抽出し、ポリシー処理要求を生成する（ステップS4000）。
【０１４６】
ポリシー処理要求を受理したポリシー処理部25は、ポリシー処理要求に含まれるポリシー情報に従って第２のメタ情報を生成するためのポリシー処理を実行し、ポリシー処理応答を生成する（ステップS4100）。
【０１４７】
ポリシー処理応答を受理した初期メッセージ処理部20は、第2のメタ情報生成要求を生成する（ステップ430）。なお、本実施形態では、端末装置2は、初期メッセージに対して必ず初期応答を端末管理サーバ1に返すこと（図２のステップS107参照）を想定しているが、ポリシー処理の結果によっては、初期応答を端末管理サーバ1に返さなくてもよい。
【０１４８】
例えば、初期メッセージに含まれるポリシーとして想定管理端末識別子324が含まれている場合、初期応答を端末管理サーバ1に返さないようにしてもよい。すなわち、想定管理端末識別子324は、端末管理サーバ1が想定する管理対象の端末を一意に特定するための識別子である。初期メッセージに含まれる想定管理端末識別子324と、端末装置2自体が管理している端末情報（第３のメタ情報）とを比較した結果、内容が不一致である場合、端末装置2は、端末管理サーバ1が想定している端末装置ではないと判定し、初期応答を返さない。
【０１４９】
端末装置2がこのように動作することによって、ネットワーク5における負荷を軽減できる。なお、端末装置2が初期応答を端末管理サーバ1に返さない場合、端末管理サーバ1は、端末装置2における初期メッセージの処理状態を正確に把握できない。そこで、端末装置2は、第2のメタ情報生成部22によって生成された第２のメタ情報をエラー応答用の情報として用いてもよい。
【０１５０】
（７．３）動作例３
図29は、端末装置2が履歴管理部27を備える場合において、端末装置2を構成する各構成要素間において送受信されるメッセージシーケンスを示す。なお、以下、動作例１と異なる部分について主に説明する。
【０１５１】
図29に示すように、ステップS420においてパラメータを確認した初期メッセージ処理部20は、当該パラメータにポリシー情報が含まれている場合、履歴取得要求を生成する（ステップS4010）。
【０１５２】
履歴取得要求を受理した履歴管理部27は、SIMカードの接続履歴を初期メッセージ処理部20に通知する（ステップS4020）。
【０１５３】
SIMカードの接続履歴を取得した初期メッセージ処理部20は、通知された接続履歴に基づいて、SIMカードの接続経過時間を算出する。初期メッセージ処理部20は、算出した接続経過時間と、あらかじめ定められた閾値と比較をし、算出した接続経過時間が閾値を下回る場合、ポリシー処理要求を生成する（ステップS4000）。
【０１５４】
一方、算出した接続経過時間が閾値以上の場合、初期メッセージ処理部20は、ステップS4000及びS4010の処理を実行せず、第2のメタ情報生成要求を生成する（ステップS430）。
【０１５５】
（８）端末装置の構成要素の実装例
次に、端末装置2の主な構成要素の実装例について説明する。具体的には、初期メッセージ処理部20、端末管理処理部21、第2のメタ情報生成部22、ポリシー処理部25及び履歴管理部27の実装例について説明する。
【０１５６】
（８．１）初期メッセージ処理部20（実装例１）
図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は、第２のメタ情報を含む初期応答要求を生成し、生成した初期応答要求を端末管理処理部21に通知する（ステップS450）。
【０１６０】
（８．２）端末管理処理部21
図22は、端末管理処理部21の動作フローチャートである。なお、端末管理処理部21の機能は、初期メッセージ処理部20から初期応答要求を受理し、初期応答を生成する機能と、端末管理メッセージを受理し、管理処理を実行する機能とを有するが、ここでは、初期応答を生成する機能に関する動作について説明する。管理処理を実行する機能は、OMA-DMの標準規格に準拠したデバイス管理クライアントを利用するによって実現できる。
【０１６１】
図22に示すように、端末管理処理部21は、初期メッセージ処理部20から初期応答要求を受理する（ステップS450）。端末管理処理部21は、受理した初期応答要求に含まれる第２のメタ情報を含む初期応答を生成する（ステップS451）。
【０１６２】
さらに、端末管理処理部21は、生成した初期応答を端末管理サーバ1に送信するため、初期応答送信要求を通信プロトコル処理部24に送信する（ステップS460）。
【０１６３】
（８．３）第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に格納されている端末情報（第３のメタ情報）を取得する（ステップS433）。
【０１６５】
第2のメタ情報生成部22は、ステップS432で生成した情報、または第３のメタ情報の内容を第２のメタ情報とした端末情報を生成する（ステップS434）。さらに、第2のメタ情報生成部22は、生成した第２のメタ情報を含む第2のメタ情報生成応答を生成する（ステップS440）。
【０１６６】
（８．４）初期メッセージ処理部20（実装例２）
図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）。
【０１７２】
（８．５）ポリシー処理部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に格納されている端末情報（第３のメタ情報）に追加する。本実施形態では、ポリシー処理部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に従って実のポリシー情報をダウンロードする。
【０１７８】
（８．６）初期メッセージ処理部20（実装例３）
図30は、ポリシー処理部25及び履歴管理部27を含む場合における初期メッセージ処理部20の動作フローチャートである。以下、図24に示した動作フローチャートと異なる部分について主に説明する。
【０１７９】
初期メッセージ処理部20は、ポリシー情報が存在する場合、履歴管理部27からICカード（SIMカード）の接続履歴を取得し、ICカードの接続経過時間と、あらかじめ定められた閾値を比較する（ステップS4010）。
【０１８０】
初期メッセージ処理部20は、ICカードの接続経過時間が当該閾値を下回る場合に限り、変数Pにポリシー情報322を代入する（ステップS424）。
【０１８１】
（８．７）履歴管理部27
図31は、履歴管理部27の動作フローチャートである。図31に示すように、履歴管理部27は、SIMカードの利用者を識別する識別子と、SIMカード自体を識別するIC識別情報を含むSIMカードの接続、具体的には、スロットへのSIMカードの挿入を検知する（ステップS500）。履歴管理部27は、履歴管理部27がスロットに挿入されたことを検知した検知時刻を保存する（ステップS501）。
【０１８２】
また、履歴管理部27は、初期メッセージ処理部20によって送信された履歴取得要求を受理する（ステップS510）。初期メッセージ処理部20は、受理した履歴取得要求に応じて、ステップS501において保存した検知時刻を初期メッセージ処理部20に通知する（ステップS511）。
【０１８３】
（９）作用・効果
端末管理システム500によれば、第1のメタ情報を取得済みであるか否かを示す圧縮フラグ305を含む初期メッセージ（例えば、初期メッセージ300）が端末管理サーバ1から端末装置2に送信される。また、端末管理サーバ1は、端末装置2から第２のメタ情報を受信した場合、第２のメタ情報に基づいて端末管理メッセージを生成する。
【０１８４】
すなわち、端末管理システム500によれば、端末装置2は、端末管理セッションの確立時に、第２のメタ情報を端末管理サーバ1に常時アップロードする必要がない。このため、端末管理サーバ1と端末装置2との端末管理セッションの確立までの時間を短縮することができる。また、端末管理システム500によれば、圧縮フラグ305を確認する機能を有していない端末装置は、従来のように第２のメタ情報を端末管理サーバ1にアップロードする。端末管理サーバ1は、アップロードされた第２のメタ情報に基づいて端末管理メッセージを生成することができる。このため、端末管理サーバ1の機能改修に伴う開発コストの増大を抑制しつつ、端末装置の最新状態に基づいた適切な遠隔管理を実現できる。
【０１８５】
本実施形態では、端末装置2（第2のメタ情報生成部22）は、端末管理サーバ1から受信した初期メッセージに含まれる第1のメタ情報に含まれる情報要素と、端末装置2に格納されている第３のメタ情報に含まれる情報要素とが一致しない場合、一致しない情報要素を含む第２のメタ情報を端末管理サーバ1に送信する。このため、端末装置2に装着されていたＩＣカード（SIMカード）が端末装置2の利用者によって差し換えられた場合等でも、端末装置の最新状態に基づいた適切な遠隔管理を実現できる。
【０１８６】
本実施形態では、端末装置2（第2のメタ情報生成部22）は、端末管理サーバ1から受信したポリシー情報（メタ情報送信ポリシー）に基づいて、端末情報提供サーバ3から取得した第1のメタ情報に含まれる情報要素では不足している不足情報要素を含む第２のメタ情報を端末管理サーバ1に送信する。このため、端末情報提供サーバ3から取得できなかった端末情報（DevInfo）の情報要素、例えば、端末装置2に設定されている言語を示す想定言語設定情報325をさらに取得できる。
【０１８７】
さらに、端末装置2（第2のメタ情報生成部22）は、URIフラグ332を含む初期メッセージ330を端末管理サーバ1から受信し、URIフラグ332を用いてメタ情報送信ポリシーをダウンロードすることができる。このため、OMA-DM Notificationのように自由記述が許されるフィールドサイズが小さい場合でも、端末装置2にメタ情報送信ポリシーを通知できる。
【０１８８】
（１０）その他の実施形態
上述したように、本発明の一実施形態を通じて本発明の内容を開示したが、この開示の一部をなす論述及び図面は、本発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態が明らかとなろう。
【０１８９】
例えば、上述した本発明の実施形態では、端末装置2（第2のメタ情報生成部22）は、端末管理サーバ1から受信した初期メッセージに含まれる第1のメタ情報に含まれる情報要素と、端末装置2に格納されている第３のメタ情報に含まれる情報要素とが一致しない場合、一致しない情報要素を含む第２のメタ情報を端末管理サーバ1に送信したが、端末装置2は、必ずしも一致しない情報要素を含む第２のメタ情報を端末管理サーバ1に送信しなくてもよい。
【０１９０】
上述した実施形態では、ポリシー情報322は、要求端末情報323、想定管理端末識別子324及び想定言語設定情報325によって構成されていたが、ポリシー情報322は、さらに他の情報要素を含んでもよい。
【０１９１】
このように、本発明は、ここでは記載していない様々な実施の形態などを含むことは勿論である。したがって、本発明の技術的範囲は、上述の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【図面の簡単な説明】
【０１９２】
【図１】本発明の実施形態に係る端末管理システム500の概略構成図である。
【図２】本発明の実施形態に係る端末管理システム500を構成する各装置間におけるメッセージシーケンス図である。
【図３】本発明の実施形態に係る端末情報要求メッセージ100の例を示す図である。
【図４】本発明の実施形態に係る端末情報応答メッセージ200の例を示す図である。
【図５】本発明の実施形態に係る初期メッセージ300の例を示す図である。
【図６】本発明の実施形態に係る初期応答400の例を示す図である。
【図７】本発明の実施形態に係る初期応答450の例を示す図である。
【図８】本発明の実施形態に係る端末管理サーバ1の機能ブロック図である。
【図９】本発明の実施形態に係る端末装置2の機能ブロック図である。
【図１０】本発明の実施形態に係る端末管理サーバ1を構成する各構成要素間において送受信されるメッセージシーケンスを示す図である。
【図１１】本発明の実施形態に係る端末装置2を構成する各構成要素間において送受信されるメッセージシーケンスを示す図である。
【図１２】本発明の実施形態に係る端末管理サーバ1がポリシー生成部18を備える場合において、端末管理サーバ1を構成する各構成要素間において送受信されるメッセージシーケンスを示す図である。
【図１３】本発明の実施形態に係る端末装置2がポリシー処理部25を備える場合において、端末装置2を構成する各構成要素間において送受信されるメッセージシーケンスを示す図である。
【図１４】本発明の実施形態に係る端末管理要求処理部10の動作フローチャートである。
【図１５】本発明の実施形態に係るメタ情報取得部12の動作フローチャートである。
【図１６】本発明の実施形態に係る初期メッセージ生成部11の動作フローチャートである。
【図１７】本発明の実施形態に係る端末管理命令生成部13の動作フローチャートである。
【図１８】本発明の実施形態に係るポリシー生成部18の動作フローチャートである。
【図１９】本発明の実施形態に係るポリシー生成部18の他の動作フローチャートである。
【図２０】本発明の実施形態に係るポリシー生成部18のさらに他の動作フローチャートである。
【図２１】本発明の実施形態に係る初期メッセージ処理部20の動作フローチャートである。
【図２２】本発明の実施形態に係る端末管理処理部21の動作フローチャートである。
【図２３】本発明の実施形態に係る第2のメタ情報生成部22の動作フローチャートである。
【図２４】本発明の実施形態に係るポリシー処理部25を含む場合における初期メッセージ処理部20の動作フローチャートである。
【図２５】本発明の実施形態に係るポリシー処理部25の動作フローチャートである。
【図２６】本発明の実施形態に係る第1のメタ情報を含む初期メッセージ310の例を示す図である。
【図２７】本発明の実施形態に係る要求端末情報、想定管理端末の識別子、想定言語設定を含んだ初期メッセージ320の例を示す図である。
【図２８】本発明の実施形態に係るポリシーURIを含む初期メッセージ330の例を示す図である。
【図２９】本発明の実施形態に係る端末装置2が履歴管理部27を備える場合において、端末装置2を構成する各構成要素間において送受信されるメッセージシーケンスを示す図である。
【図３０】本発明の実施形態に係るポリシー処理部25及び履歴管理部27を含む場合における初期メッセージ処理部20の動作フローチャートである。
【図３１】本発明の実施形態に係る履歴管理部27の動作フローチャートである。
【符号の説明】
【０１９３】
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…端末管理システム
【図１】
0004989440.tif 000002
【図２】
0004989440.tif 000003
【図３】
0004989440.tif 000004
【図４】
0004989440.tif 000005
【図５】
0004989440.tif 000006
【図６】
0004989440.tif 000007
【図７】
0004989440.tif 000008
【図８】
0004989440.tif 000009
【図９】
0004989440.tif 000010
【図１０】
0004989440.tif 000011
【図１１】
0004989440.tif 000012
【図１２】
0004989440.tif 000013
【図１３】
0004989440.tif 000014
【図１４】
0004989440.tif 000015
【図１５】
0004989440.tif 000016
【図１６】
0004989440.tif 000017
【図１７】
0004989440.tif 000018
【図１８】
0004989440.tif 000019
【図１９】
0004989440.tif 000020
【図２０】
0004989440.tif 000021
【図２１】
0004989440.tif 000022
【図２２】
0004989440.tif 000023
【図２３】
0004989440.tif 000024
【図２４】
0004989440.tif 000025
【図２５】
0004989440.tif 000026
【図２６】
0004989440.tif 000027
【図２７】
0004989440.tif 000028
【図２８】
0004989440.tif 000029
【図２９】
0004989440.tif 000030
【図３０】
0004989440.tif 000031
【図３１】
0004989440.tif 000032