(57)【要約】【課題】処理コストや通信コストの増大を抑制しつつ、不特定多数のデバイス管理クライアントの中からデバイス管理を実行させるデバイス管理クライアントを判別可能とする。【解決手段】デバイス管理サーバ１００は、デバイス管理クライアントを呼び出す初期メッセージと、初期メッセージに応答すべきデバイス管理クライアントの条件を示す条件判定情報とを生成する初期メッセージ生成部１２０と、デバイス管理クライアントからの応答に基づき、デバイス管理を実行させるデバイス管理クライアントを特定するデバイス特定部１６０とを備える。デバイス管理クライアント２００Ａは、初期メッセージ及び条件判定情報を受信する初期メッセージ受信部２１０と、条件判定情報に基づき、初期メッセージに応答するか否かを判定する条件判定部２２０と、初期メッセージに応答すると判定された場合、初期メッセージに応答する初期メッセージ応答部２３０とを備える。【選択図】  図３
2008205629.tif 000002
【特許請求の範囲】
【請求項１】
デバイス管理を実行するデバイス管理クライアントと、前記デバイス管理クライアントと通信するデバイス管理サーバとを備えるデバイス管理システムであって、
前記デバイス管理サーバは、
前記デバイス管理クライアントを呼び出す初期メッセージと、前記初期メッセージに応答すべきデバイス管理クライアントの条件を示す条件判定情報とを生成する初期メッセージ生成部と、
前記デバイス管理クライアントからの応答に基づき、前記デバイス管理を実行させるデバイス管理クライアントを特定するデバイス特定部とを備え、
前記デバイス管理クライアントは、
前記初期メッセージ及び前記条件判定情報を受信する初期メッセージ受信部と、
前記条件判定情報に基づき、前記初期メッセージに応答するか否かを判定する条件判定部と、
前記初期メッセージに応答すると判定された場合、前記初期メッセージに応答する初期メッセージ応答部と
を備えることを特徴とするデバイス管理システム。
【請求項２】
デバイス管理を実行するデバイス管理クライアントと通信するデバイス管理サーバであって、
前記デバイス管理クライアントを呼び出す初期メッセージと、前記初期メッセージに応答すべきデバイス管理クライアントの条件を示す条件判定情報とを生成する初期メッセージ生成部と、
前記デバイス管理クライアントからの応答に基づき、前記デバイス管理を実行させるデバイス管理クライアントを特定するデバイス特定部と
を備えることを特徴とするデバイス管理サーバ。
【請求項３】
前記初期メッセージの生成を要求するデバイス管理要求を受信する管理要求受信部をさらに備え、
前記デバイス管理要求は、前記条件を指定する情報を含み、
前記初期メッセージ生成部は、前記デバイス管理要求に応じて前記条件判定情報を生成することを特徴とする請求項２に記載のデバイス管理サーバ。
【請求項４】
前記初期メッセージと前記条件判定情報とを前記デバイス管理クライアントに送信する初期メッセージ送信部をさらに備え、
前記デバイス特定部は、前記条件を満たすデバイス管理クライアントからの応答に応じて、前記デバイス管理を実行させるデバイス管理クライアントを特定することを特徴とする請求項２に記載のデバイス管理サーバ。
【請求項５】
前記デバイス管理を指示するデバイス管理命令を生成する管理命令生成部をさらに備え、
前記管理命令生成部は、前記初期メッセージ送信部によって前記初期メッセージが送信されてから一定時間内に前記応答を受信しない場合、前記デバイス管理命令を破棄することを特徴とする請求項４に記載のデバイス管理サーバ。
【請求項６】
前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信可能であるか否かを判定する送信判定部をさらに備え、
前記初期メッセージ送信部は、前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信不可能であると判定された場合、前記初期メッセージを前記デバイス管理クライアントに送信すると共に、前記条件判定情報を前記デバイス特定部に通知し、
前記デバイス特定部は、前記条件判定情報及び前記応答に基づいて、前記デバイス管理を実行させるデバイス管理クライアントを特定することを特徴とする請求項４に記載のデバイス管理サーバ。
【請求項７】
前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信可能であるか否かを判定する送信判定部と、
前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信不可能であると判定された場合、前記条件判定情報のデータ形式を変換する変換部と
をさらに備えることを特徴とする請求項４に記載のデバイス管理サーバ。
【請求項８】
前記送信判定部は、前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信不可能である場合、前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信可能なデータ形式を前記変換部に通知し、
前記変換部は、前記条件判定情報を、前記初期メッセージ送信部によって通知されたデータ形式に変換することを特徴とする請求項７に記載のデバイス管理サーバ。
【請求項９】
前記変換部は、前記条件判定情報を圧縮することを特徴とする請求項７に記載のデバイス管理サーバ。
【請求項１０】
前記変換部は、前記条件判定情報を、前記デバイス管理クライアントに予め設けられた条件判定モジュールを呼び出すデータ形式に変換し、
前記条件判定モジュールは、前記条件を満たすか否かを判定するモジュールであることを特徴とする請求項７に記載のデバイス管理サーバ。
【請求項１１】
デバイス管理サーバと通信するデバイス管理クライアントであって、
前記デバイス管理サーバからの呼び出しを示す初期メッセージと、前記初期メッセージに応答する条件を示す条件判定情報とを受信する初期メッセージ受信部と、
前記条件判定情報に基づき、前記初期メッセージに応答するか否かを判定する条件判定部と、
前記初期メッセージに応答すると判定された場合、前記初期メッセージに応答する初期メッセージ応答部と
を備えることを特徴とするデバイス管理クライアント。
【請求項１２】
前記条件判定部は、前記初期メッセージに応答すると判定された場合、前記初期メッセージに応答するためのデバイス管理の実行を指示するデバイス管理命令を生成し、
前記初期メッセージ応答部は、前記デバイス管理命令に従ったデバイス管理を実行することで前記初期メッセージに応答することを特徴とする請求項１１に記載のデバイス管理クライアント。
【請求項１３】
前記初期メッセージ受信部によって受信された前記条件判定情報のデータ形式が変換されている場合、前記条件判定情報のデータ形式を逆変換する逆変換部をさらに備えることを特徴とする請求項１２に記載のデバイス管理クライアント。
【請求項１４】
前記条件判定部は、予め規定された複数種類の条件判定を実行する複数の条件判定モジュールを備え、
前記逆変換部は、前記条件判定情報のデータ形式が前記複数の条件判定モジュールのいずれかを指定するデータ形式である場合、指定された条件判定モジュールを呼び出すことを特徴とする請求項１３に記載のデバイス管理クライアント。
【請求項１５】
前記逆変換部は、前記条件判定情報のデータ形式が圧縮されたデータ形式である場合、前記条件判定情報を復号することを特徴とする請求項１３に記載のデバイス管理クライアント。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイス管理を実行するデバイス管理クライアントと、デバイス管理クライアントと通信するデバイス管理サーバと、デバイス管理クライアント及びデバイス管理サーバを備えるデバイス管理システムとに関する。
【背景技術】
【０００２】
Smart Phone、ＰＤＡ、ノートＰＣなど、可搬性があり、かつネットワークとの接続が可能なモバイルデバイスに対して、管理グループ（法人における管理者など）が、デバイスの状態やデバイスの設定などを把握し、適切な管理を行えるようにするシステム、すなわちデバイス管理システムが、ＯＭＡ Device Management（ＤＭ）として、Open Mobile Alliance（ＯＭＡ）で規定されている。
【０００３】
ＯＭＡ ＤＭでは、デバイス管理サーバとデバイスに導入されたデバイス管理クライアントとの通信によってデバイス管理が実現される（非特許文献１参照）。例えば、デバイス管理クライアントは、デバイスに記憶されているファームウェアのバージョンをデバイス管理サーバに通知する。
【０００４】
デバイス管理サーバは、デバイス管理クライアントからの通知に基づき、バージョンの低いファームウェアを持つデバイスを発見する。そして、デバイス管理サーバは、発見されたデバイスのファームウェアをアップデートするために、デバイス管理命令をデバイス管理クライアントに送信する。
【０００５】
デバイス管理の利用シーンとして考えられる様々なシナリオのうち、デバイス管理サーバが不特定多数のデバイスとの間でデバイス管理を実行するようなシナリオが想定される。例えば、法人端末の管理者が、特定の地域に存在するデバイスに対して一斉に遠隔設定を行ったり、携帯電話のオペレータが特定地域に存在するデバイスから一斉にＱｏＳ情報を収集したりするなどといったシナリオが想定される。
【０００６】
上記のシナリオが、通常のデバイス管理と異なる点は、最初から遠隔設定やＱｏＳ情報収集のためのデバイス管理を実行できないという点である。特に、デバイスが携帯電話等の移動体である場合には、使用環境が時々刻々と変化するため、任意の時刻に「特定の条件を満たすデバイス」のデバイスＩＤを知ることが難しい。
【０００７】
従って、上記のシナリオでは、特定の条件を満たすデバイスＩＤを知るためのデバイス管理と、当該デバイスＩＤに対して本来のデバイス管理を実行するという、二段階のデバイス管理が実行される必要がある。
【０００８】
ＯＭＡ ＤＭでは、単一のデバイスに関するデバイス管理の実行と複数のデバイスに関するデバイス管理の実行について別々にプロトコルを規定していないため、上記のようなシナリオであっても、全てのデバイスに対して逐次同一のデバイス管理を実行していくこととなる。このため、上記のシナリオをＯＭＡ標準シーケンスに従って実行した場合には、デバイス、ネットワーク、サーバのそれぞれに対して、無駄な、あるいは大きなオーバヘッドが発生する可能性がある。
【０００９】
図１は、特定地域に存在するデバイスに対して一律の遠隔設定を行うというデバイス管理をＯＭＡ ＤＭ標準に従って実行する場合のシーケンス図である。
【００１０】
ステップＳ１０１において、デバイス管理サーバ（ＤＭ Server）は、管理対象候補となる全てのデバイス（Device１，Device２）に対して、呼び出し（起動）を通知するメッセージであるＤＭ Notificationメッセージを送信する。以下では、複数デバイスへのＤＭ Notificationメッセージ送信を「Bulk Push」と呼ぶ。
【００１１】
ステップＳ１０２において、Bulk Pushを受信したデバイス上のデバイス管理クライアントは、デバイス管理サーバに対してデバイス情報（以下、「DevInfo」）を送信する。
【００１２】
ステップＳ１０３において、デバイス管理サーバは、DevInfoへの返信として、位置情報収集のためのデバイス管理命令を送信する。
【００１３】
ステップＳ１０４において、デバイス管理クライアントは、ステップＳ１０３で受信した位置情報収集のデバイス管理命令を実行し、位置情報をデバイス管理サーバへ送信する。
【００１４】
ステップＳ１０５において、デバイス管理サーバは、ステップＳ１０４で受信した位置情報を元に条件判定を行う。具体的には、デバイス管理サーバは、特定地域に存在するデバイスを管理対象デバイスとして特定する。
【００１５】
ステップＳ１０６において、デバイス管理サーバは、ステップＳ１０５の条件判定に合致したデバイス（ここではDevice２）に対して、遠隔設定のデバイス管理命令を送信する。
【００１６】
ステップＳ１０７において、デバイス管理クライアントは、ステップＳ１０６で受信した遠隔設定のデバイス管理命令を実行し、実行結果をデバイス管理サーバへ送信する。
【００１７】
ステップＳ１０８において、デバイス管理サーバは、ステップＳ１０７で受信した実行結果に対する確認応答（Ack）を送信する。
【００１８】
図１の例では、Bulk Pushとそれに対する応答をＤＭ１、位置情報取得をＤＭ２、遠隔設定の実行をＤＭ３とした場合に、ＤＭ１やＤＭ２は、本来のＤＭ３の管理対象デバイスではないとは関係ないデバイスとの間でも発生する。上述したように、ＤＭ１やＤＭ２の段階では、実際の管理対象であるＤＭ３を実行すべきデバイスを判断できないためである。
【００１９】
特に、管理対象候補となるデバイスが多数あり、その中でＤＭ３の対象となるデバイスが小数であるような場合には、本来実行する必要が無いＤＭ１とＤＭ２の処理により、多数のデバイスに対して無駄な処理コストが発生してしまう。また、ＤＭ１とＤＭ２の実行時に、多数のデバイスからサーバへのアクセスが一斉に発生する可能性があり、サーバやネットワークに一時的に大きな負荷が発生してしまう可能性がある。
【００２０】
一方で、不特定多数のデバイスがサーバへアクセスする際のオーバヘッドを削減する技術としては、特許文献１がある。特許文献１では、デバイスが監視情報を取得した場合に、それをすぐにサーバにアップロードせずにデバイス上に蓄積する。そして、予め定められたスケジュールに基づいて、蓄積した監視情報をサーバへアップロードする。
【００２１】
また、複数のデバイスに対してデバイス設定を行う技術として、特許文献２がある。特許文献２では、あるデバイスが設定変更をしたことにより、同一ネットワークに属する他のデバイスにも設定の変更が必要となった場合に、各デバイスは、設定変更を検知し、設定変更が行われた場合にはサーバへ設定変更を通知する。サーバは、デバイスからの通知に従って、各デバイスに対して設定変更の命令を送信する。
【非特許文献１】OMA Enabler Releases and Specifications - OMA Device Management, ［online］，＜URL：http://www.openmobilealliance.org/release_program/dm_v1_2.html＞
【特許文献１】特開２００６−２１５９７４号公報
【特許文献２】特開２００６−９９３００号公報
【発明の開示】
【発明が解決しようとする課題】
【００２２】
しかしながら、特許文献１では、いくつかの前提が必要となる。第一に、監視情報をアップロードするスケジュールが予め決定されていなければならない。第二に、周囲のデバイス同士がお互いの状態を相互に通知する必要がある。
【００２３】
しかし、特定地域に存在するデバイスに対して一律の遠隔設定を行うというデバイス管理では、サーバからデバイスに対する位置情報収集の要求は、全く非同期に発生する可能性があり、位置情報の報告を予めスケジュールすることは不可能である。
【００２４】
また、遠隔設定が緊急性を要する場合には、サーバからの位置情報収集のデバイス管理命令を受信した場合には、即座に応答する必要があるため、スケジューリングして応答するという手段をとることはできない。
【００２５】
さらに、デバイス同士の連携を実行した場合には、サーバやサーバ付近のネットワーク負荷については削減可能であるが、デバイス側では、上記第二の前提により通信頻度が逆に増加してしまう。特に、携帯電話を想定した場合には、通信の発生は電池消費に大きな影響を与えるため、このようなデバイス同士の連携による解決手段をとることは難しい。
【００２６】
上述した特許文献２では、特定地域に存在するデバイスに対して一律の遠隔設定を行うというデバイス管理に当てはめた場合、遠隔設定すべき位置情報が予め決定されているならば、設定変更の検知を位置情報変化の検知とすることで適用可能である。この場合、デバイス上の監視エージェントは、特定地域にデバイスが入った場合に、デバイス管理サーバへそれを報告し、しかるべきデバイス管理命令（ここでは遠隔設定）を受信・実行すれば良い。
【００２７】
しかし、任意の場所に存在するデバイスに対して遠隔設定を実行する場合、監視エージェントは予め定められたポリシーに従って位置情報の変化を監視するため、固定的な位置情報にしか対応できない。
【００２８】
以上述べたように、ＯＭＡ標準シーケンスに従って特定の条件を満たすデバイスに対して一律の遠隔設定を行うといったデバイス管理は、処理コストや通信コストが増大するという問題点があった。また、従来提案されている他の技術によっても、当該問題点を解決することができなかった。
【００２９】
デバイス管理の実行には、デバイス側ではデバイス管理命令の処理コストや通信コストが必要となる。特に、デバイスが携帯電話であった場合、電池消費の問題があるため、これらの処理の発生は極力避けなければならない。
【００３０】
また、デバイス管理が不特定多数のデバイスを対象としている場合には、多くのデバイスがサーバへアクセスすることによる、ネットワークやサーバの負荷についても考慮する必要がある。
【００３１】
上記問題点に鑑み、本発明は、処理コストや通信コストの増大を抑制しつつ、不特定多数のデバイス管理クライアントの中からデバイス管理を実行させるデバイス管理クライアントを判別可能なデバイス管理システム、デバイス管理サーバ及びデバイス管理クライアントを提供することを目的とする。
【課題を解決するための手段】
【００３２】
上記目的を達成するために、本発明の第１の特徴は、デバイス管理を実行するデバイス管理クライアントと、前記デバイス管理クライアントと通信するデバイス管理サーバとを備えるデバイス管理システムであって、前記デバイス管理サーバは、前記デバイス管理クライアントを呼び出す初期メッセージと、前記初期メッセージに応答すべきデバイス管理クライアントの条件を示す条件判定情報とを生成する初期メッセージ生成部と、前記デバイス管理クライアントからの応答に基づき、前記デバイス管理を実行させるデバイス管理クライアントを特定するデバイス特定部とを備え、前記デバイス管理クライアントは、前記初期メッセージ及び前記条件判定情報を受信する初期メッセージ受信部と、前記条件判定情報に基づき、前記初期メッセージに応答するか否かを判定する条件判定部と、前記初期メッセージに応答すると判定された場合、前記初期メッセージに応答する初期メッセージ応答部とを備えることを要旨とする。
【００３３】
このような特徴によれば、デバイス管理クライアントが、条件判定情報に応じて、デバイス管理サーバに応答すべきかを自律的に判定するので、処理コストや通信コストの増大を抑制しつつ、不特定多数のデバイス管理クライアントの中から管理対象のデバイス管理クライアントを判別可能なデバイス管理システムを実現できる。
【００３４】
本発明の第２の特徴は、デバイス管理を実行するデバイス管理クライアントと通信するデバイス管理サーバであって、前記デバイス管理クライアントを呼び出す初期メッセージと、前記初期メッセージに応答すべきデバイス管理クライアントの条件を示す条件判定情報とを生成する初期メッセージ生成部と、前記デバイス管理クライアントからの応答に基づき、前記デバイス管理を実行させるデバイス管理クライアントを特定するデバイス特定部とを備えることを要旨とする。
【００３５】
このような特徴によれば、デバイス管理サーバが初期メッセージと共に条件判定情報とを生成することによって、不特定多数のデバイス管理クライアントの中からデバイス管理を実行させるデバイス管理クライアントを判別可能となる。
【００３６】
本発明の第３の特徴は、本発明の第２の特徴に係り、前記初期メッセージの生成を要求するデバイス管理要求を受信する管理要求受信部をさらに備え、前記デバイス管理要求は、前記条件を指定する情報を含み、前記初期メッセージ生成部は、前記デバイス管理要求に応じて前記条件判定情報を生成することを要旨とする。
【００３７】
このような特徴によれば、デバイス管理サーバは、デバイス管理要求に含まれる情報に応じた条件判定情報を生成可能となる。
【００３８】
本発明の第４の特徴は、本発明の第２の特徴に係り、前記初期メッセージと前記条件判定情報とを前記デバイス管理クライアントに送信する初期メッセージ送信部をさらに備え、前記デバイス特定部は、前記条件を満たすデバイス管理クライアントからの応答に応じて、前記デバイス管理を実行させるデバイス管理クライアントを特定することを要旨とする。
【００３９】
このような特徴によれば、デバイス管理サーバは、初期メッセージと条件判定情報とをデバイス管理クライアントに送信する。このため、デバイス管理クライアントは、デバイス管理サーバに応答すべきかを判定可能となる。
【００４０】
本発明の第５の特徴は、本発明の第４の特徴に係り、前記デバイス管理を指示するデバイス管理命令を生成する管理命令生成部をさらに備え、前記管理命令生成部は、前記初期メッセージ送信部によって前記初期メッセージが送信されてから一定時間内に前記応答を受信しない場合、前記デバイス管理命令を破棄することを要旨とする。
【００４１】
このような特徴によれば、デバイス管理サーバは、初期メッセージが送信されてから一定時間内に応答を受信しない場合にデバイス管理命令を破棄するので、デバイス管理命令がリソースを無駄に消費することが回避される。
【００４２】
本発明の第６の特徴は、本発明の第４の特徴に係り、前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信可能であるか否かを判定する送信判定部をさらに備え、前記初期メッセージ送信部は、前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信不可能であると判定された場合、前記初期メッセージを前記デバイス管理クライアントに送信すると共に、前記条件判定情報を前記デバイス特定部に通知し、前記デバイス特定部は、前記条件判定情報及び前記応答に基づいて、前記デバイス管理を実行させるデバイス管理クライアントを特定することを要旨とする。
【００４３】
このような特徴によれば、条件判定情報を初期メッセージと共にデバイス管理クライアントに送信不可能であっても、デバイス管理サーバは、不特定多数のデバイス管理クライアントの中からデバイス管理を実行させるデバイス管理クライアントを判別できる。
【００４４】
本発明の第７の特徴は、本発明の第４の特徴に係り、前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信可能であるか否かを判定する送信判定部と、前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信不可能であると判定された場合、前記条件判定情報のデータ形式を変換する変換部とをさらに備えることを要旨とする。
【００４５】
このような特徴によれば、デバイス管理サーバは、条件判定情報を初期メッセージと共にデバイス管理クライアントに送信不可能である場合には条件判定情報のデータ形式を変換する。これにより、条件判定情報を初期メッセージと共にデバイス管理クライアントに送信可能となる。
【００４６】
本発明の第８の特徴は、本発明の第７の特徴に係り、前記送信判定部は、前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信不可能である場合、前記条件判定情報を前記初期メッセージと共に前記デバイス管理クライアントに送信可能なデータ形式を前記変換部に通知し、前記変換部は、前記条件判定情報を、前記初期メッセージ送信部によって通知されたデータ形式に変換することを要旨とする。
【００４７】
このような特徴によれば、デバイス管理サーバは、条件判定情報を初期メッセージと共にデバイス管理クライアントに送信不可能である場合に、条件判定情報を初期メッセージと共にデバイス管理クライアントに確実に送信可能とすることができる。
【００４８】
本発明の第９の特徴は、本発明の第７の特徴に係り、前記変換部は、前記条件判定情報を圧縮することを要旨とする。
【００４９】
このような特徴によれば、条件判定情報を初期メッセージと共にデバイス管理クライアントに送信可能となる。
【００５０】
本発明の第１０の特徴は、本発明の第７の特徴に係り、前記変換部は、前記条件判定情報を、前記デバイス管理クライアントに予め設けられた条件判定モジュールを呼び出すデータ形式に変換し、前記条件判定モジュールは、前記条件を満たすか否かを判定するモジュールであることを要旨とする。
【００５１】
このような特徴によれば、条件判定情報のデータ量をより少なくすることができる。
【００５２】
本発明の第１１の特徴は、デバイス管理サーバと通信するデバイス管理クライアントであって、前記デバイス管理サーバからの呼び出しを示す初期メッセージと、前記初期メッセージに応答する条件を示す条件判定情報とを受信する初期メッセージ受信部と、前記条件判定情報に基づき、前記初期メッセージに応答するか否かを判定する条件判定部と、前記初期メッセージに応答すると判定された場合、前記初期メッセージに応答する初期メッセージ応答部とを備えることを要旨とする。
【００５３】
このような特徴によれば、デバイス管理クライアントは、条件判定情報に応じてデバイス管理サーバに応答すべきかを判定するので、処理コストや通信コストの増大を抑制することができる。
【００５４】
本発明の第１２の特徴は、本発明の第１１の特徴に係り、前記条件判定部は、前記初期メッセージに応答すると判定された場合、前記初期メッセージに応答するためのデバイス管理の実行を指示するデバイス管理命令を生成し、前記初期メッセージ応答部は、前記デバイス管理命令に従ったデバイス管理を実行することで前記初期メッセージに応答することを要旨とする。
【００５５】
このような特徴によれば、デバイス管理クライアントは、デバイス管理を利用してデバイス管理サーバに応答することが可能となる。
【００５６】
本発明の第１３の特徴は、本発明の第１２の特徴に係り、前記初期メッセージ受信部によって受信された前記条件判定情報のデータ形式が変換されている場合、前記条件判定情報のデータ形式を逆変換する逆変換部をさらに備えることを要旨とする。
【００５７】
このような特徴によれば、条件判定情報のデータ形式が変換されている場合であっても、逆変換により元の条件判定情報を得ることができる。
【００５８】
本発明の第１４の特徴は、本発明の第１３の特徴に係り、前記条件判定部は、予め規定された複数種類の条件判定を実行する複数の条件判定モジュールを備え、前記逆変換部は、前記条件判定情報のデータ形式が前記複数の条件判定モジュールのいずれかを指定するデータ形式である場合、指定された条件判定モジュールを呼び出すことを要旨とする。
【００５９】
このような特徴によれば、条件判定情報が単に条件判定モジュールを呼び出す情報となるので、条件判定情報のデータサイズがより削減される。
【００６０】
本発明の第１５の特徴は、本発明の第１３の特徴に係り、前記逆変換部は、前記条件判定情報のデータ形式が圧縮されたデータ形式である場合、前記条件判定情報を復号することを要旨とする。
【００６１】
このような特徴によれば、圧縮された条件判定情報に対応することで条件判定情報のデータサイズが削減される。
【発明の効果】
【００６２】
本発明によれば、処理コストや通信コストの増大を抑制しつつ、不特定多数のデバイス管理クライアントの中からデバイス管理を実行させるデバイス管理クライアントを判別可能なデバイス管理システム、デバイス管理サーバ及びデバイス管理クライアントを提供できる。
【発明を実施するための最良の形態】
【００６３】
次に、図面を参照して、本発明の第１及び第２実施形態を説明する。以下の第１及び第２実施形態における図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
【００６４】
＜第１実施形態＞
（デバイス管理システムの概略構成）
まず、本実施形態に係るデバイス管理システムの概略構成について説明する。図２は、本実施形態に係るデバイス管理システムの概略構成図である。
【００６５】
図２に示すデバイス管理システムは、デバイス管理サーバ１００及び複数のデバイス管理クライアント２００Ａ，２００Ｂを備える。
【００６６】
デバイス管理サーバ１００と、デバイス管理クライアント２００Ａ，２００Ｂとは、ネットワーク（ＮＷ）３００を介して通信を行う。デバイス管理クライアント２００Ａは、デバイス２０Ａ内に設けられる。デバイス管理クライアント２００Ｂは、デバイス２０Ｂ内に設けられる。デバイス２０Ａ，２０Ｂとしては、例えば携帯電話端末等の移動体が使用できるが、移動体に限らず、固定された通信端末であっても良い。
【００６７】
デバイス管理クライアント２００Ａ，２００Ｂは、デバイス管理サーバ１００から送信される初期メッセージにより起動し、デバイス管理サーバ１００にアクセスする。この結果、デバイス管理サーバ１００とデバイス管理クライアント２００Ａ，２００Ｂとの間にデバイス管理セッションが確立される。
【００６８】
デバイス管理セッションが確立されると、デバイス管理サーバ１００は、デバイス２０Ａ，２０Ｂの状態や設定などを把握し、デバイス２０Ａ，２０Ｂの適切な管理を行う。また、デバイス管理クライアント２００Ａ，２００Ｂは、デバイス２０Ａ，２０Ｂに保持されているファームウェアの更新等のデバイス管理を実行する。
【００６９】
デバイス管理サーバ１００は、初期メッセージの生成を要求するデバイス管理要求を受信し、受信したデバイス管理要求に応じて初期メッセージ及び条件判定情報をデバイス管理クライアント２００Ａ，２００Ｂに送信する。
【００７０】
デバイス管理要求は、管理者や外部システムにより生成される。初期メッセージは、デバイス管理クライアントを呼び出すメッセージである。条件判定情報は、初期メッセージに応答すべきデバイス管理クライアントの条件を示す情報である。
【００７１】
本実施形態では、条件判定とは、例えばデバイス２０Ａ，２０Ｂの位置情報に基づく判定である。特に、デバイス２０Ａ，２０Ｂが移動体である場合には、デバイス管理サーバ１００が予め位置情報を知るのが困難であるため、管理対象デバイスを予め把握して初期メッセージを送信することができない。従って、デバイス管理サーバ１００は、候補となる全てのデバイス２０Ａ，２０Ｂに対して初期メッセージを送信する。これをBulk Pushと呼ぶ。
【００７２】
デバイス管理クライアント２００Ａ，２００Ｂは、受信した条件判定情報の内容によりデバイス管理サーバ１００へアクセスするか否かを判定する。デバイス管理サーバ１００へアクセスする場合、デバイス管理クライアント２００Ａ，２００Ｂは、デバイス管理サーバ１００からデバイス管理命令を受信し、受信したデバイス管理命令を実行する。
【００７３】
例えば、デバイス管理クライアント２００Ａ，２００Ｂは、デバイス２０Ａ，２０Ｂが位置情報を取得可能な状態で、位置情報を指定する条件判定情報を含む初期メッセージを受信した場合には、自身の位置情報を参照することにより、デバイス管理サーバ１００へアクセスするか否かを決定する。尚、デバイス管理クライアント２００Ａ，２００Ｂは条件判定情報を解析するためのＤＴＤ（Document Type Definition）を予め保持しているものとする。
【００７４】
（デバイス管理サーバの構成）
次に、図３を用いて、デバイス管理サーバ１００の構成について説明する。
【００７５】
図３に示すように、デバイス管理サーバ１００は、管理要求受信部１１０、初期メッセージ生成部１２０、管理命令生成部１３０、初期メッセージ送信部１４０、応答受信部１５０、デバイス特定部１６０及び管理命令送信部１７０を備える。
【００７６】
管理要求受信部１１０は、デバイス管理要求を受信し、当該デバイス管理要求に応じて初期メッセージ生成要求を初期メッセージ生成部１２０に通知すると共に、管理命令生成要求を管理命令生成部１３０に通知する。
【００７７】
初期メッセージ生成部１２０は、管理要求受信部１１０によって通知された初期メッセージ生成要求に応じて、デバイス管理クライアント２００Ａ，２００Ｂを呼び出すための初期メッセージ、及び当該初期メッセージにデバイス管理クライアント２００Ａ，２００Ｂが応答する条件を示す条件判定情報を生成する。
【００７８】
管理要求受信部１１０は、デバイス管理要求を受けて、初期メッセージ生成部１２０に対して初期メッセージの生成要求を行い、管理命令生成部１３０に対してデバイス管理命令の生成要求を行う。
【００７９】
初期メッセージ送信部１４０は、初期メッセージ生成部１２０によって生成された初期メッセージ及び条件判定情報をデバイス管理クライアント２００Ａに送信する。
【００８０】
応答受信部１５０は、初期メッセージに対する応答を、デバイス管理クライアント２００Ａから受信する。
【００８１】
デバイス特定部１６０は、応答受信部１５０が受信した応答に基づいて、デバイス管理を実行させるデバイス管理クライアントを特定する。
【００８２】
管理命令送信部１７０は、管理命令生成部１３０によって生成されたデバイス管理命令をデバイス管理クライアント２００Ａに送信する。
【００８３】
（デバイス管理クライアントの構成）
引き続き、図３を用いて、デバイス管理クライアント２００Ａの構成について説明する。デバイス管理クライアント２００Ｂは、デバイス管理クライアント２００Ａと同様の構成を有するため、デバイス管理クライアント２００Ａについてのみ説明する。
【００８４】
デバイス管理クライアント２００Ａは、初期メッセージ受信部２１０、条件判定部２２０、初期メッセージ応答部２３０及びデバイス管理部２４０を備える。
【００８５】
初期メッセージ受信部２１０は、初期メッセージ及び条件判定情報をデバイス管理サーバ１００から受信する。
【００８６】
条件判定部２２０は、初期メッセージ受信部２１０が受信した条件判定情報の示す条件に自身が合致するか否かを判定する。例えば、条件判定部２２０は、場合にのみデバイス管理サーバへ応答する。
【００８７】
初期メッセージ応答部２３０は、条件判定部２２０によって初期メッセージに応答すると判定された場合に限り、デバイス管理サーバ１００にアクセスする。
【００８８】
デバイス管理部２４０は、デバイス管理サーバ１００によって送信されたデバイス管理命令に従ったデバイス管理を実行する。具体的には、デバイス管理部２４０は、Management Objectにアクセスしてデバイス管理命令を実際に実行する処理を担当する。なお、Management Objectは、上記“OMA Enabler Releases and Specifications”で標準として定義されている。
【００８９】
尚、デバイス管理クライアント２００Ａが設けられるデバイス２０Ａは、位置情報を取得する位置情報取得部や、ＮＷ３００と通信する通信部等を備えている。
【００９０】
（デバイス管理要求）
次に、デバイス管理サーバ１００が管理者や外部システムから受信するデバイス管理要求について説明する。図４は、デバイス管理要求を説明するための図である。
【００９１】
図４に示すように、デバイス管理要求は、デバイス識別子、命令実行条件、及び管理対象デバイスが実行するデバイス管理命令を生成するための情報を含む。
【００９２】
デバイス識別子は、デバイス管理命令を実行する候補となるデバイスを一意に識別するための識別子である。デバイス識別子としてはＩＭＥＩ等が使用される。
【００９３】
命令実行条件は、デバイス管理命令を実行するためにデバイスが満たすべき条件（例えば、特定地域に存在、あるいは特定ネットワークを利用等）を指定する情報である。
【００９４】
デバイス管理命令は、上記識別子を持ち、かつ命令実行条件を満たすデバイス上のデバイス管理クライアント２００Ａ，２００Ｂが実行するデバイス管理命令を生成するための情報である。
【００９５】
（初期メッセージ）
次に、デバイス管理サーバ１００が送信する初期メッセージについて説明する。図５は、初期メッセージとしてＯＭＡ ＤＭのＤＭ Notificationメッセージを使用する場合のフォーマットを示す図である。
【００９６】
ＯＭＡ ＤＭでは、ＤＭ Notificationメッセージを受信したデバイス管理クライアントは、自身のデバイス基本情報（DevInfo）を収集し、デバイス管理サーバ１００へアクセスすることが規定されている。
【００９７】
デバイス管理サーバ１００は、上述したデバイス管理要求に含まれるデバイス識別子により特定された全てのデバイス上のデバイス管理クライアントに対して初期メッセージを送信する。
【００９８】
初期メッセージには、条件判定情報が埋め込まれる。図５では、<vendor-specific>領域が自由に使用可能であるため、<vendor-specific>領域に条件判定情報を埋め込むことが可能である。
【００９９】
（条件判定情報）
次に、初期メッセージに埋め込まれる条件判定情報について説明する。図６は、条件判定情報の一例を示す図である。
【０１００】
デバイス管理クライアント２００Ａ，２００Ｂは、一般にデバイス管理メッセージを解析するためのＸＭＬ解析機能を備える。このため、本実施形態では、条件判定情報もＸＭＬ形式で記述するものとする。
【０１０１】
図７は、図６の各タグを説明するための図である。図７に示すように、“Condition”で定義された特定の条件において、“Action”で定義された処理を実行する基本的なスケジュール処理が記述されている。
【０１０２】
“Condition”の“Value”は、条件判定に用いる値を格納している。“Value”は、初期メッセージ生成部１２０が、命令実行条件を元に埋め込む。“Items”では、実際にValueで定義された値と、Management Objectで参照可能な位置情報とが等しいかという条件判定を行っている。
【０１０３】
“Action”の“Reply_Actions”は、真である場合に、デバイス管理サーバ１００へ応答を返す条件を“Items”を用いて列挙する。各“Items”は属性値を以って、“Condition”で設定した条件判定を参照しており、リストされた条件判定が真であれば、デバイス管理サーバ１００への応答が実行されることとなる。
【０１０４】
図６の例では、デバイスの位置情報がManagement Objectの“/DevDetails/ Ext/ Location/ location_id”に関連付けられており、この値とサーバが指定した“server_specified_location”が合致する場合に、デバイス管理クライアント２００Ａ，２００Ｂはデバイス管理サーバ１００に応答することとなる。
【０１０５】
図６で示したように、条件判定情報の解析にManagement Objectの参照が必要となる場合には、条件判定部２２０は、デバイス管理部２４０へデバイス管理命令の実行要求を出力し、結果を取得する。
【０１０６】
この例では、“/DevDetails/Ext/Location/location_id”に関連付けられた位置情報を取得する必要があるため、条件判定部２２０は、位置情報を取得するための実行要求を出力する。実行要求は、例えばＯＭＡ ＤＭ標準のメッセージそのもので良い（図１７参照）。  
（デバイス管理命令）
次に、デバイス管理サーバ１００がデバイス管理クライアント２００Ａ，２００Ｂに送信するデバイス管理命令について説明する。図８は、デバイス管理命令の一例を示す図である。
【０１０７】
図８の例では、デバイス管理命令は、ＯＭＡ ＤＭに従いSyncＭＬで記述されている。デバイス管理命令を受信した場合には、デバイス管理クライアント２００Ａ，２００Ｂは、“MapApp”という予めインストール済みのアプリケーションを実行可能状態に設定する。
【０１０８】
（デバイス管理システムの概略動作）
次に、上述したデバイス管理システムの概略動作について説明する。図９は、デバイス管理サーバ１００、及びデバイス管理クライアント２００Ａ，２００Ｂの概略動作を示すシーケンス図である。
【０１０９】
ステップＳ２０１において、デバイス管理サーバ１００は、管理対象候補となる全てのデバイス上（ここではデバイス管理クライアント２００Ａ，２００Ｂ）に対して、条件判定情報が埋め込まれたBulk Pushを送信する。
【０１１０】
ステップＳ２０２において、デバイス管理クライアント２００Ａ，２００Ｂは、ステップＳ２０１で受信したBulk Pushに埋め込まれている条件判定情報に基づいて条件判定処理を行う。すなわち、デバイス管理クライアント２００Ａ，２００Ｂは、標準のＯＭＡ ＤＭとは異なり、初期メッセージを受信した時点で、デバイス管理サーバ１００へ応答すべきかの条件判定を実行する。
【０１１１】
ここでは、デバイス管理クライアント２００Ａは、自身が応答条件を満たしていると判定したものとする。一方、デバイス管理クライアント２００Ｂは、自身が応答条件を満たしていないと判定したものとする。
【０１１２】
ステップＳ２０２において、応答条件を満たすデバイス管理クライアント２００Ａは、DevInfoをデバイス管理サーバ１００に送信する。
【０１１３】
ステップＳ２０４において、デバイス管理サーバ１００は、デバイス管理クライアント２００Ａからのアクセスに応じて、例えば遠隔設定のデバイス管理命令をデバイス管理クライアント２００Ａに送信する。
【０１１４】
ステップＳ２０５において、デバイス管理クライアント２００Ａは、ステップＳ２０４で受信したデバイス管理命令を実行し、実行結果をデバイス管理サーバ１００へ送信する。
【０１１５】
ステップＳ２０６において、デバイス管理サーバ１００は、実行結果に対するAckをデバイス管理クライアント２００Ａに送信する。
【０１１６】
（デバイス管理サーバの動作）
次に、図３に示したデバイス管理サーバ１００の動作について説明する。図１０は、デバイス管理サーバ１００の動作を示すフローチャートである。
【０１１７】
ステップＳ３０１において、管理要求受信部１１０は、デバイス管理要求を受信する。
【０１１８】
ステップＳ３０２において、初期メッセージ生成部１２０は、ステップＳ３０１で受信されたデバイス管理要求に応じて初期メッセージ及び条件判定情報を生成する。
【０１１９】
また、管理命令生成部１３０は、デバイス管理要求に応じてデバイス管理命令を生成する。尚、生成されたデバイス管理命令は、デバイス管理クライアントに送信されるまでの間、例えば管理命令送信部１７０内の送信バッファに保持される。
【０１２０】
ステップＳ３０３において、初期メッセージ送信部１４０は、ステップＳ３０２で生成された条件判定情報を初期メッセージに埋め込むとともに、初期メッセージをデバイス管理クライアント２００Ａ，２００Ｂに送信する。
【０１２１】
ステップＳ３０４において、応答受信部１５０は、ステップＳ３０３で送信した初期メッセージに対する応答があったか否かを判定する。初期メッセージに対する応答があった場合、ステップＳ３０５に進む。一方、初期メッセージに対する応答が無い場合、ステップＳ３０６に進む。
【０１２２】
ステップＳ３０５において、デバイス特定部１６０は、ステップＳ３０４で受信した応答に応じて、管理対象となるデバイスを特定する。管理対象となるデバイスが特定されると、デバイス特定部１６０は、特定されたデバイスに対して、ステップＳ３０２で生成されたデバイス管理命令を送信するよう要求する。
【０１２３】
ステップＳ３０７において、管理命令送信部１７０は、ステップＳ３０５で特定されたデバイス（デバイス管理クライアント）に対してデバイス管理命令を送信する。
【０１２４】
一方、ステップＳ３０６においては、管理命令生成部１３０は、ステップＳ３０３で初期メッセージが送信されてから一定時間経過したか否かを判定する。初期メッセージが送信されてから一定時間経過した場合、ステップＳ３０８に進む。初期メッセージが送信されてから一定時間経過していない場合、ステップＳ３０４に戻る。
【０１２５】
ステップＳ３０８において、管理命令生成部１３０は、ステップＳ３０２で生成された管理命令を破棄する。
【０１２６】
尚、ステップＳ３０６で判定される一定時間（タイムアウト時間）は、デバイス管理要求に含めることで、デバイス管理者等が指定しても良い
（デバイス管理クライアントの動作）
次に、図３に示したデバイス管理クライアント２００Ａの動作について説明する。図１１は、デバイス管理クライアント２００Ａの動作を示すフローチャートである。
【０１２７】
ステップＳ４０１において、初期メッセージ受信部２１０は、初期メッセージと条件判定情報を受信し、条件判定情報を条件判定部２２０へ出力する。
【０１２８】
ステップＳ４０２において、条件判定部２２０は、対応するＤＴＤを以って条件判定情報を解析し、条件判定結果を初期メッセージ応答部２３０に出力する。
【０１２９】
ステップＳ４０３において、条件判定部２２０は、ステップＳ４０２で得られた条件判定結果から、初期メッセージに応答するか否かを判定する。初期メッセージに応答すると判定された場合、ステップＳ４０４に進む。一方、初期メッセージに応答しない場合には、デバイス管理部２４０は、初期メッセージを無視する。
【０１３０】
ステップＳ４０４において、初期メッセージ応答部２３０及びデバイス管理部２４０は、DevInfoを収集し、DevInfoを含む応答メッセージを生成する。尚、応答メッセージについては、例えばＯＭＡ ＤＭ標準のSyncＭＬで記述可能である。
【０１３１】
ステップＳ４０５において、初期メッセージ応答部２３０は、ステップＳ４０４で生成された応答メッセージをデバイス管理サーバ１００に送信する。
【０１３２】
ステップＳ４０６において、デバイス管理部２４０は、デバイス管理サーバ１００からデバイス管理命令を受信する。
【０１３３】
ステップＳ４０７において、デバイス管理部２４０は、ステップＳ４０６で受信したデバイス管理命令を実行する。
【０１３４】
（作用・効果）
本実施形態によれば、前記デバイス管理サーバは、デバイス管理クライアント２００Ａ，２００Ｂを呼び出す初期メッセージと、当該初期メッセージに応答する条件を示す条件判定情報とをデバイス管理クライアント２００Ａ，２００Ｂに送信する。
【０１３５】
デバイス管理クライアント２００Ａ，２００Ｂは、受信した条件判定情報に基づき、受信した初期メッセージに応答するか否かを判定する。そして、デバイス管理サーバ１００は、初期メッセージに応答したデバイス管理クライアント２００Ａに対してデバイス管理命令を送信する。
【０１３６】
従って、特定地域に存在するデバイスに対して一律の遠隔設定を行うといったデバイス管理を、ＯＭＡ標準シーケンスに従って実行した場合と比較して、デバイス２０Ａ，２０Ｂ、ＮＷ３００及びデバイス管理サーバ１００の処理負荷や通信コストを大幅に削減できる。
【０１３７】
また、デバイス管理サーバ１００は、初期メッセージが送信されてから一定時間内に応答を受信しない場合にデバイス管理命令を破棄するので、不要なデバイス管理命令がリソースを消費することが回避される。
【０１３８】
＜第２実施形態＞
本実施形態では、デバイス管理サーバ１００が、ＳＭＳ(Short Message Service)を利用して初期メッセージをデバイス２０Ａ，２０Ｂに送信する構成について説明する。
【０１３９】
携帯電話等に設けられたデバイス管理クライアントを遠隔から起動するためのPushメッセージ送信プロトコルの一つにＳＭＳがある。携帯電話は、通常はトランスポートの全てのポート番号をクローズしており、トランスポート層のサービスを遠隔から呼び出すＲＰＣ（Remote Procedure Call）のような形でのプログラム起動は不可能である。現在の携帯電話では、遠隔からプログラムを起動する唯一の選択肢がＳＭＳであると言っても良い。
【０１４０】
しかし、ＳＭＳを利用したプログラム起動時には、厳しいメッセージ制限が存在する。図１２に示す通り、ＤＭ NotificationメッセージのTrigger-bodyに使用可能なデータサイズは、わずかに５２バイトとなってしまう。このため、５２バイト以内で条件判定情報を生成する必要がある。
【０１４１】
そこで、本実施形態では、Bulk Pushにデータサイズの限られたプロトコル（ＳＭＳ等）を利用する際の問題点を解決する。  
（デバイス管理システムの概略構成）
まず、本実施形態に係るデバイス管理システムについて説明する。本実施形態に係るデバイス管理システムは、図２に示したデバイス管理システムの構成に加えて、ＷＡＰ（Wireless Application Protocol) ＰｕｓｈゲートウェイやＳＭＳサーバを備える。
【０１４２】
すなわち、デバイス管理サーバ１００は、ＷＡＰ  ＰｕｓｈゲートウェイやＳＭＳサーバを介して、デバイス２０Ａ，２０Ｂに初期メッセージを送信する。
【０１４３】
（デバイス管理サーバの構成）
次に、図１３を用いて、本実施形態に係るデバイス管理サーバ１００について説明する。
【０１４４】
図１３に示すように、デバイス管理サーバ１００には、送信判定部１８０及び変換部１９０が追加されている点で、図３とは異なっている。
【０１４５】
初期メッセージ生成部１２０は、Bulk Pushを実行するプロトコルを決定し、それにより条件判定情報に利用可能なデータサイズを特定する。例えばＳＭＳでは５２バイトである。
【０１４６】
送信判定部１８０は、条件判定情報を初期メッセージと共にデバイス管理クライアント２００Ａに送信可能であるか否かを判定する。つまり、送信判定部１８０は、初期メッセージ生成部１２０によって生成された条件判定情報のデータサイズが、利用可能なデータサイズを超えているか否かを判定する。
【０１４７】
条件判定情報が５２バイト以下であれば、第１実施形態と同様に、条件判定情報がそのまま初期メッセージに埋め込まれる。
【０１４８】
一方、条件判定情報が５２バイトを超える場合、変換部１９０が、条件判定情報を変換することで要求されたデータサイズ以下の、変換済み条件判定情報を生成し、これを初期メッセージに埋め込んでデバイス管理クライアント２００へ送信する。
【０１４９】
ここで、データ形式の変換としては、まず単純にバイナリＸＭＬによるＸＭＬ文書の圧縮が考えられる。この場合、各ＸＭＬのタグを１バイトにすることができるため、条件判定情報のデータサイズを大幅に削減できる。しかし、図６に示した例では、タグを１バイトにした場合でも５２バイト以下にはならず、ＳＭＳを利用したBulk Pushを実行することはできない。
【０１５０】
別のデータ形式の変換手法は、デバイス管理クライアント２００Ａの条件判定部２２０に、予め定められた条件判定を実行する条件判定モジュールを複数備えておき、条件判定情報によって条件判定モジュールを呼び出す。条件判定モジュールの詳細については後述する。
【０１５１】
尚、送信判定部１８０には、各デバイス管理クライアントが逆変換可能なデータ形式（プロトコル）を示す逆変換情報を記憶している。図１４は、逆変換情報の一例を示す図である。
【０１５２】
図１４の例では、デバイスＩＤ“１０００”のデバイスは、バイナリＸＭＬ圧縮をサポートしている。デバイスＩＤ“１００１”のデバイスは、バイナリＸＭＬ圧縮をサポートし、かつ位置判定モジュールを有している。デバイスＩＤ“１００２”のデバイスは、ＮＷ判定モジュール及び位置判定モジュールを有している。尚、逆変換情報を得るためには、例えば、ＯＭＡ ＤＭのＳＣＯＭＯ（http://member.openmobilealliance.org/ftp/public_documents/dm/SCOMO/参照）を利用することで実現される。
【０１５３】
（デバイス管理クライアントの構成）
引き続き、図１３を用いて、デバイス管理クライアント２００Ａの構成について説明する。
【０１５４】
図１３に示すように、デバイス管理クライアント２００Ａには、逆変換部２５０が追加されている点で、図３とは異なっている。
【０１５５】
条件判定部２２０は、変換済み条件判定情報を逆変換部２５０へ渡し、元の条件判定情報を得る。
【０１５６】
逆変換部２５０は、変換済み条件判定情報のデータ形式に応じた逆変換を実行する。具体的には、条件判定情報がバイナリＸＭＬ圧縮されている場合には、復号処理を実行する。また、逆変換部２５０は、条件判定情報のデータ形式が複数の条件判定モジュールのいずれかを指定するデータ形式である場合、指定された条件判定モジュールを呼び出す。
【０１５７】
（条件判定モジュール）
次に、条件判定モジュールについて説明する。図１５は、条件判定モジュールを説明するための図である。
【０１５８】
図１５（ａ）は、上述した第１実施形態の場合の条件判定処理を示す概要図である。
【０１５９】
条件判定情報は、様々な条件やそれに対するアクションを記述し、さらに条件判定情報の中にはManagement Objectへの参照文も含まれるため、サイズが増大することとなる。図６の例においても、Management ObjectのＵＲＩ指定がかなりのサイズを占めている。
【０１６０】
具体的には、図１５（ａ）では、Management Treeのルート“Ａ”からManagement Objectの“Ｊ”までを順に辿る必要があるため、“ＥＸＥＣ／Ａ／Ｃ／Ｆ／Ｊ”といった記述になる。
【０１６１】
図１５（ｂ）は、条件判定処理をモジュール化した場合の概要図である。デバイス管理クライアント２００Ａは、ネットワーク判定用モジュールＭ２や位置判定用モジュールＭ１を備え、それぞれ判定時に必要となるManagement Objectに直接関連付ける。
【０１６２】
これにより、条件判定情報内では、起動するモジュールの指定と、モジュールに渡す引数のみ指定すれば良い。
【０１６３】
例えば、図６の例では、位置判定モジュールは、デバイスの位置情報と引数で与えられた位置情報とが等しいかどうかの条件判定を行うモジュールであり、条件判定情報は当該モジュールを識別するＩＤと、引数としてサーバが指定する位置情報（図６のserver_specified_location）を含めば良い。
【０１６４】
このようなメッセージをＤＭ  Notificationメッセージに埋め込む場合の例を図１６に示す。図１６の例では、Trigger-body部分を拡張し、モジュール呼び出しのために必要な情報を埋め込んでいる。
【０１６５】
具体的には、<protocol>、<id>及び<size>から構成される<module-hdr>と、<module-body>とが含まれる。<protocol>及び<id>は、モジュールを一意に識別するためのものである。<size>は、<module-body>のサイズを指定する。<module-body>では、<size>で指定された分だけの引数を埋め込む。
【０１６６】
このようなデータ形式では、５２バイトのほとんどを引数に利用することが可能であるため、条件判定モジュールさえ存在すれば、様々な条件判定情報をサイズ制限以内に変換可能である。
【０１６７】
逆変換部２５０は、<protocol>と<id>から呼び出すべきモジュールを特定し、<module-body>で指定された引数を元にモジュールを実行し、実行結果を条件判定部２２０へ出力する。出力された結果は、デバイス管理サーバ１００へ応答すべきか否かを判定するための情報そのものであり、条件判定部２２０は、その結果をそのまま初期メッセージ応答部２３０へ出力する。
【０１６８】
（作用・効果）
本実施形態によれば、デバイス管理サーバ１００は、条件判定情報を初期メッセージに埋め込むことが不可能である場合には条件判定情報のデータ形式を変換することで、条件判定情報を初期メッセージに埋め込むことを可能としている。
【０１６９】
デバイス管理サーバ１００は、データ形式の変換手法として、バイナリＸＭＬによる圧縮を行うことで、条件判定情報のデータサイズを削減することができる。
【０１７０】
さらに、デバイス管理サーバ１００は、データ形式の変換手法として、条件判定モジュールを呼出す情報を条件判定情報とすることで、条件判定情報のデータサイズをより削減することができる。
【０１７１】
＜第２実施形態の変形例＞
本変形例では、第２実施形態において、条件判定情報を初期メッセージに含めることができなかった場合のエラー処理について説明する。このようなエラーが発生する原因として、いかなる変換処理を以ってしても条件判定情報がサイズ超過した場合等が考えられる。
【０１７２】
このような場合、図１３に示す初期メッセージ送信部１４０は、初期メッセージのみをデバイス管理クライアント２００Ａ，２００Ｂへ送信するとともに、デバイス特定部１６０に対して、条件判定情報を通知する。
【０１７３】
また、管理命令生成部１３０は、例えばデバイス管理クライアントに位置情報を送信させるデバイス管理命令を生成する。生成されたデバイス管理命令は、管理命令送信部１７０によってデバイス管理クライアント２００Ａ，２００Ｂに送信される。当該デバイス管理命令は、図１７に示すように、条件判定をサーバ側で実行するために必要となるデバイス管理命令である。
【０１７４】
応答受信部１５０は、位置情報を含む応答メッセージをデバイス管理クライアント２００Ａ，２００Ｂから受信する。
【０１７５】
デバイス特定部１６０は、初期メッセージ送信部１４０によって通知された条件判定情報と、応答受信部１５０が受信した応答メッセージとに基づいてデバイス管理クライアントを特定する。
【０１７６】
（作用・効果）
本変形例によれば、第２実施形態で説明した変換手法によっても条件判定情報を初期メッセージに埋め込むことができない場合には、デバイス管理サーバ１００は、図１と同様の手順で不特定多数のデバイス管理クライアントの中からデバイス管理を実行させるデバイス管理クライアントを判別する。
【０１７７】
したがって、デバイス管理サーバ１００は、デバイス管理を実行させるデバイス管理クライアントを確実に判別することができる。
【０１７８】
＜その他の実施形態＞
上記のように、本発明は第１及び第２実施形態によって記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施形態、実施例及び運用技術が明らかとなる。
【０１７９】
上述した実施形態では、応答条件として位置情報やネットワーク情報を指定していたが、位置情報やネットワーク情報以外の応答条件も指定可能である。例えば、管理対象デバイスから一斉に応答されるのを防ぐために、確率的に応答するような条件を記述することにより、デバイスからサーバへの応答を削減するような目的にも利用可能である。
【０１８０】
このように本発明は、ここでは記載していない様々な実施形態等を包含するということを理解すべきである。従って、本発明はこの開示から妥当な特許請求の範囲の発明特定事項によってのみ限定されるものである。
【図面の簡単な説明】
【０１８１】
【図１】特定地域に存在するデバイスに対して一律の遠隔設定を行うというデバイス管理をＯＭＡ ＤＭ標準に従って実行した場合のシーケンス図である。
【図２】本発明の第１実施形態に係るデバイス管理システムの概略構成図である。
【図３】本発明の第１実施形態に係るデバイス管理サーバ及びデバイス管理クライアントの構成を示す機能ブロック図である。
【図４】本発明の第１実施形態に係るデバイス管理サーバが受信するデバイス管理要求を説明するための図である。
【図５】本発明の第１実施形態に係る初期メッセージとしてＤＭ Notificationメッセージを使用する場合のフォーマットを示す図である。
【図６】本発明の第１実施形態に係る条件判定情報の一例を示す図である。
【図７】図７は、図６の各タグを説明するための図である。
【図８】本発明の第１実施形態に係るデバイス管理命令の一例を示す図である。
【図９】本発明の第１実施形態に係るデバイス管理システムの概略動作を示すシーケンス図である。
【図１０】本発明の第１実施形態に係るデバイス管理サーバの動作を示すフローチャートである。
【図１１】本発明の第１実施形態に係るデバイス管理クライアントの動作を示すフローチャートである。
【図１２】ＳＭＳを利用した初期メッセージの構成を示す図である。
【図１３】本発明の第２実施形態に係るデバイス管理サーバ及びデバイス管理クライアントの構成を示す機能ブロック図である。
【図１４】本発明の第２実施形態に係る逆変換情報の一例を示す図である。
【図１５】本発明の第２実施形態に係る条件判定モジュールを説明するための図である。
【図１６】本発明の第２実施形態に係る初期メッセージの一例を示す図である。
【図１７】本発明の第２実施形態の変形例に係るデバイス管理命令を示す図である。
【符号の説明】
【０１８２】
２０Ａ，２０Ｂ…デバイス、１００…デバイス管理サーバ、１１０…管理要求受信部、１２０…初期メッセージ生成部、１３０…管理命令生成部、１４０…初期メッセージ送信部、１５０…応答受信部、１６０…デバイス特定部、１７０…管理命令送信部、１８０…送信判定部、１９０…変換部、２００Ａ，２００Ｂ…デバイス管理クライアント、２１０…初期メッセージ受信部、２２０…条件判定部、２３０…初期メッセージ応答部、２４０…デバイス管理部、２５０…逆変換部、３００…ＮＷ
【図１】
2008205629.tif 000003
【図２】
2008205629.tif 000004
【図３】
2008205629.tif 000005
【図４】
2008205629.tif 000006
【図５】
2008205629.tif 000007
【図６】
2008205629.tif 000008
【図７】
2008205629.tif 000009
【図８】
2008205629.tif 000010
【図９】
2008205629.tif 000011
【図１０】
2008205629.tif 000012
【図１１】
2008205629.tif 000013
【図１２】
2008205629.tif 000014
【図１３】
2008205629.tif 000015
【図１４】
2008205629.tif 000016
【図１５】
2008205629.tif 000017
【図１６】
2008205629.tif 000018
【図１７】
2008205629.tif 000019