(57)【要約】【課題】  移動機の種別毎に異なる更新用データをサーバ装置がプッシュ配信する際における、トラフィック量の抑制を図ることである。【解決手段】  本発明に係る移動機１０は、配信サーバ２０から送信され移動機の種別毎に異なる更新用データを取得するために、送信要否判定部１４と種別情報送信部１５とを備える。送信要否判定部１４は、移動機１０の起動時または通信準備時に、移動機１０の最新の種別情報が配信サーバ２０に通知されているか否かを示すフラグに基づいて、種別情報の通知の要否を判定する。種別情報送信部１５は、上記種別情報の通知が必要と判定された場合に、配信サーバ２０宛に上記種別情報を送信する。【選択図】  図１
2006013951.tif 000002
【特許請求の範囲】
【請求項１】
サーバ装置から送信され、移動機の種別毎に異なる更新用データを取得可能な移動機であって、
前記移動機の起動時または通信準備時に、当該移動機の最新の種別情報が前記サーバ装置に通知されているか否かを示す情報に基づいて、前記種別情報の通知の要否を判定する判定手段と、
前記種別情報の通知が必要と前記判定手段により判定された場合には、前記サーバ装置宛に前記種別情報を送信する送信手段と
を備えることを特徴とする移動機。
【請求項２】
前記サーバ装置に通知されているか否かを示す情報はフラグであり、
前記移動機の種別情報を保持する保持手段と、
当該移動機の種別情報が、前記保持手段に保持されている前回の種別情報と同一であるか否かに基づいて、前記フラグをオン若しくはオフに設定する設定手段と
を更に備えることを特徴とする請求項１に記載の移動機。
【請求項３】
前記移動機に挿入されたＵＩＭの識別情報を保持する保持手段を更に備え、
前記判定手段は、前記移動機へのＵＩＭの挿入時に、当該ＵＩＭの識別情報が、前記保持手段に保持されている前回の識別情報と同一であるか否かに基づいて、前記種別情報の通知の要否を判定することを特徴とする請求項１に記載の移動機。
【請求項４】
移動機が、起動時または通信準備時に、当該移動機の最新の種別情報がサーバ装置に通知されているか否かを示す情報に基づいて、前記種別情報の通知の要否を判定する判定ステップと、
この判定ステップにて前記種別情報の通知が必要と判定した場合には、前記サーバ装置宛に前記種別情報を送信する送信ステップと、
この送信ステップにて送信された前記種別情報を参照して前記サーバ装置が取得した更新用データを受信する受信ステップと
を含むことを特徴とするデータ取得方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動機が、サーバ装置から配信される更新用データを取得する技術に関する。
【背景技術】
【０００２】
近年、携帯電話を始めとする移動機においても、パーソナルコンピュータと同様に、コンピュータウィルスによる攻撃が懸念されている。かかる懸念に対応する手段の一つとして、不具合修正用データ（パッチデータ）を使用して、ソフトウェア自体をバージョンアップすることが有効である。あるいは、攻撃を防止するためのアンチウィルスソフトウェアやＩＤＳ（Intrusion Detection System）のパターンデータの追加といった処理も効果的である。以下の説明では、上述の不具合修正用データとパターンデータとに、通常のソフトウェアバージョンアップ用のデータを加えて、“更新用データ”と記す。
【０００３】
移動機は、メーカや機種に応じて、多種多様なソフトウェア及びハードウェアから構成されており、その脆弱性に適確に対応するためには、移動機の種別毎に異なる更新用データが提供される必要がある。しかし、一般的には、移動体通信業者は、ユーザの顧客情報（契約者氏名、ＩＭＳＩ（International Mobile Subscriber Identifier）、電話番号、メールアドレス、住所、契約形態など）は管理しているものの、各ユーザの所有する移動機の種別に関しては充分に管理していない。このため、更新用データを配信するサーバ装置において、移動機の種別（例えば、ハードウェアやソフトウェアのバージョン）を精確に把握する仕組みが必要とされている。
【０００４】
上述の状況下において、例えば特許文献１には、以下に説明する更新用データの取得方法が開示されている。この方法では、新しい更新用データがリリースされたことに伴い、サーバ装置は、登録されている全ての移動機に対して、その旨の通知をプッシュ配信する。同時に、サーバ装置は、上記更新用データが適用されるべき移動機の種別を通知する。これらの通知を受けた移動機は、更新用データの要否を判断し、必要であれば更新用データの送信をサーバ装置に要求する。不要であれば、移動機は、これらの通知を無視する。
【０００５】
更に別の手法として、更新用データがリリースされた時点で、サーバ装置が、登録された全移動機に種別の問合せを行い、各移動機からの応答を基に、ユーザ情報と移動機種別情報とを関連付けたＤＢ（DataBase）を作成する、ことも考え得る。この手法では、サーバ装置は、新たな更新用データがリリースされた時に、上記ＤＢを参照して、登録されている個々の移動機に適した更新用データをプッシュ配信する。
【特許文献１】特開２００３−４１８４８２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述した従来技術には、以下のような問題点がなお懸念される。すなわち、特許文献１に開示されている技術では、更新用データがリリースされる度に、全ての移動機にその旨が通知されるため、データを更新する必要の無い移動機に対してまで通知が行われることになる。この結果、無駄な通信が発生しトラフィック量が増大する。
【０００７】
上記別の手法では、サーバ装置は、各移動機に対して種別の問合せを１度（最初の更新用データのリリース時）しか行わない。このため、移動機の買替えやソフトウェアのバージョンアップにより、ユーザの移動機種別に変更があった場合には、サーバ装置側のＤＢを更新する仕組みが依然として必要になる。更に、問合せ時における移動機の状態によっては、通信圏外や電源ＯＦＦが要因で再度の問合せが必要となり、トラフィック量の増大が懸念される。
【０００８】
無線リソースの許容量、あるいは、移動機の処理能力やバッテリの駆動時間に鑑みると、移動体通信におけるトラフィック量の抑制は、効率的なデータ更新を行う上で、特に重要な課題である。
そこで、本発明の課題は、移動機の種別毎に異なる更新用データをサーバ装置がプッシュ配信する際における、トラフィック量の抑制を図ることである。
【課題を解決するための手段】
【０００９】
上記課題を解決すべく、本発明に係る移動機は、サーバ装置から送信され、移動機の種別毎に異なる更新用データを取得可能な移動機であって、前記移動機の起動時または通信準備時に、当該移動機の最新の種別情報が前記サーバ装置に通知されているか否かを示す情報に基づいて、前記種別情報の通知の要否を判定する判定手段と、前記種別情報の通知が必要と前記判定手段により判定された場合には、前記サーバ装置宛に前記種別情報を送信する送信手段とを備える。
【００１０】
ここで、移動機の種別毎に異なる更新用データとは、移動機の種別に依存して生成されるデータである。移動機の種別は、メーカ名、モデル名、ＲＯＭ（Read Only Memory）のバージョンといったハードウェア種別に基づくものに加えて、ＯＳ（Operating System）やアプリケーションプログラムのバージョンといったソフトウェアに基づく種別を含む。更新用データは、その目的を問わず、移動機に既存のデータを修正（追加や削除を含む）するためのデータである。更新用データは、上述した通り、不具合の修正用データ、ウィルスのパターンデータ、ソフトウェアの通常のバージョンアップ用データ等である。
【００１１】
本発明によれば、移動機は、自機の状態変化を契機として、最新の種別情報がサーバ装置に通知済であるか否かの判定を行い、通知が必要な場合、すなわちサーバ装置の種別情報が最新状態にない場合にのみ、これを通知する。このように、移動機は、サーバ装置からの通知や問合せを待つこと無く、自機の種別情報の変化を自発的に通知するので、サーバ装置側において、この通知を基に常に最新の種別情報が保持され得ることになる。また、サーバ装置に対する通知が不要な場合には種別情報は送信されず、更には、移動機の状態に起因してサーバ装置からの再問合せが行われるといった懸念も解消される。つまり、最小限のトラフィック量で、移動機に対する更新用データのプッシュ配信が実現される。
【００１２】
本発明に係る移動機においては、前記サーバ装置に通知されているか否かを示す情報はフラグであり、前記移動機の種別情報を保持する保持手段と、当該移動機の種別情報が、前記保持手段に保持されている前回の種別情報と同一であるか否かに基づいて、前記フラグをオン若しくはオフに設定する設定手段とを更に備えるものとしてもよい。
【００１３】
本発明によれば、移動機は、種別情報の通知の要否を判断するための情報としてフラグを参照することで、本発明の課題であるトラフィック量の低減を容易に実現することができる。すなわち、移動機は、自機の種別情報を保持手段に保持しており、起動時または通信の準備時に、現在の種別情報と、前回の（更新用データの取得前における）種別情報との同一性を判定する。判定の結果、同一であればフラグをオンに設定し、異なればオフに設定した上で種別情報を送信する。これにより、移動機は、最新の種別情報がサーバ装置に登録されているにも関わらず、種別情報の送信が行われるという事態を、簡易な手段で未然に回避する。その結果、限られた無線リソースやバッテリを効率的に使用することが可能となる。
【００１４】
本発明に係る移動機において、より好ましくは、前記移動機に挿入されたＵＩＭの識別情報を保持する保持手段を更に備え、前記判定手段は、前記移動機へのＵＩＭの挿入時に、当該ＵＩＭの識別情報が、前記保持手段に保持されている前回の識別情報と同一であるか否かに基づいて、前記種別情報（ＵＩＭの識別情報を含む）の通知の要否を判定する。
【００１５】
ここで、上記ＵＩＭ（User Identity Module）には、その別名であるＵＳＩＭ（Universal Subscriber Identity Module）、Ｒ−ＵＩＭ（Removable UIM）、ＳＩＭ（Subscriber Identity Module）を含む。
本発明は、異なる複数のＵＩＭで一台の移動機を兼用する場合を想定して為されたものである。更新の内容によっては、ＵＩＭの種別に合わせて、提供されるべき更新用データを適宜変える必要性が生じる。そこで、移動機にＵＩＭが挿入された時点で、移動機は、今回挿入されたＵＩＭ（現在のＵＩＭ）と差し替えられたＵＩＭ（前回のＵＩＭ）との同一性を判定する。判定の結果、異なる場合にのみ種別情報の送信を行う。このようにして、移動機は、最新の種別情報が既にサーバ装置に通知されている場合における種別情報の送信処理を省略する。その結果、無駄なデータ通信に伴う無線リソースやバッテリの浪費が、可能な限り低減される。
【００１６】
本発明に係るデータ取得方法は、移動機が、起動時または通信準備時に、当該移動機の最新の種別情報がサーバ装置に通知されているか否かを示す情報に基づいて、前記種別情報の通知の要否を判定する判定ステップと、この判定ステップにて前記種別情報の通知が必要と判定した場合には、前記サーバ装置宛に前記種別情報を送信する送信ステップと、この送信ステップにて送信された前記種別情報を参照して前記サーバ装置が取得した更新用データを受信する受信ステップとを含む。
【００１７】
本発明によれば、移動機は、自機の状態変化を契機として、最新の種別情報がサーバ装置に通知済であるか否かの判定を行い、通知が必要な場合、すなわちサーバ装置の種別情報が最新状態にない場合にのみ、これを通知する。したがって、サーバ装置は、移動機から自発的に通知された最新の種別情報を保持しながら、データベースを常に最新状態で管理することができる。サーバ装置は、この種別情報を基に、これに対応する更新用データの配信を行う。そして、移動機は、配信された更新用データを受信して格納する。これにより、更新用データのプッシュ配信が必要最小限の通信量で実現される。
【発明の効果】
【００１８】
これらの発明によれば、移動機の種別毎に異なる更新用データをサーバ装置がプッシュ配信する際における、トラフィック量の抑制を図ることが可能となる。
【発明を実施するための最良の形態】
【００１９】
［第１の実施形態］
以下、添付図面を参照して、本発明の一実施形態におけるデータ取得システムについて説明する。
まず、図１を参照して、本実施の形態における移動機１０、及び配信サーバ２０（サーバ装置に対応）の機能的構成を説明する。図１に示すように、移動機１０は、ＵＩＭ１１と、種別情報保持部１２（保持手段に対応）と、フラグ設定部１３（設定手段に対応）と、送信要否判定部１４（判定手段に対応）と、種別情報送信部１５（送信手段に対応）と、データ受信部１６と、データ格納部１７とを備えて構成されている。これら各構成部分は、バスを介して、相互に信号の入出力が可能なように接続されている。
【００２０】
ＵＩＭ１１は、移動機１０のカードスロットに着脱自在に実装されるＩＣカードである。ＵＩＭ１１には、契約者である移動機のユーザのＩＤや電話番号、通話料金を始めとするユーザに固有の情報が格納される。このＵＩＭ１１を、上記ユーザとは別のユーザの所有するＵＩＭに差し替えることにより、１台の移動機１０を複数の人が兼用することができる。
【００２１】
種別情報保持部１２は、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）を始めとする不揮発性の半導体メモリにより構成される。種別情報保持部１２には、移動機１０の種別を表す、ハードウェアやソフトウェアの情報（種別情報に対応）が保持される。この種別情報は、フラグの設定に際して参照されるとともに、後述の種別情報送信部１５からの指示に従って配信サーバ２０宛に送信される。更に、種別情報保持部１２は、ＵＩＭ１１のＵＩＭＩＤを保持するＵＩＭ情報保持部１２ｆを内部に有する。種別情報保持部１２に保持されるデータの一例を図２に示す。図２に示すように、種別情報保持部１２は、メーカ名、モデル名、ＲＯＭのバージョン、ハードウェアのバージョン、ＯＳ種別等の種別情報を保持するデータ格納領域１２ａ〜１２ｅを有する。また、これらのデータ領域とは独立に、装着されているＵＩＭを一意に識別可能なデータとしてＵＩＭＩＤを保持するためのデータ格納領域であるＵＩＭ情報保持部１２ｆを有する。ＵＩＭＩＤは、例えば“Ｕ０１”であり、ＵＩＭの識別情報に対応する。
【００２２】
フラグ設定部１３は、種別情報保持部１２に保持されている種別情報（ＵＩＭＩＤを含む）を参照して、フラグをオン若しくはオフに設定する。このフラグは、移動機１０の最新の種別情報が配信サーバ２０に既に通知されているか否かを示すフラグであり、未通知の場合には“０”が設定される。また、通知済の場合には、“１”が設定される。フラグを変更する基準とそのタイミングに関しては、動作説明において詳述するが、フラグ設定部１３は、現在の種別情報と前回の種別情報とが同一である場合には、フラグは、オンを表す“１”に設定され、異なる場合にはオフを表す“０”に設定されるような制御を行う。
【００２３】
送信要否判定部１４は、移動機１０の起動時または通信準備時に、フラグ設定部１３により設定された上記フラグに基づいて、種別情報の送信の要否を判定する。判定の結果、フラグに“０”が設定されている場合には、種別情報送信部１５に種別情報の送信を指示し、“１”が設定されている場合には種別情報を送信することなく通常の処理を継続する。また、送信要否判定部１４は、移動機１０へのＵＩＭの挿入時に、この挿入されたＵＩＭのＩＤと、種別情報保持部１２に事前に保持されているＵＩＭＩＤ（前回の識別情報に対応）との同一性に基づいて、種別情報の送信の要否を判定する。異なれば種別情報の送信、すなわちＵＩＭＩＤの送信を指示し、同一であればこれを送信することなく通常の処理に移行する。
【００２４】
種別情報送信部１５は、送信要否判定部１４からの指示に従い、種別情報保持部１２から最新の種別情報を取得して、配信サーバ２０宛に送信する。種別情報の送信は、無線基地局Ｂ及び公衆通信網Ｎを経由して行われる。なお、一部の種別情報が変更されている場合には、その変更部分に関してのみ種別情報を送信してもよいし、全部の種別情報を送信してもよい。
【００２５】
データ受信部１６は、最新の種別情報が反映された更新用データを配信サーバ２０から受信する。
データ格納部１７には、データ受信部１６により受信された更新用データが格納される。この更新用データは、その目的と内容に応じて、ウィルスパターンデータの追加や、ソフトウェアのバージョンアップ、不具合の修正などに使用される。
【００２６】
続いて、配信サーバ２０の構成を説明する。図１に戻り、配信サーバ２０は、種別情報受信部２１と、種別情報ＤＢ２２と、配信データ指示部２３と、更新用データ格納部２４と、データ配信部２５とを備えて構成される。これら各構成部分は、バスを介して、相互に信号の入出力が可能なように接続されている。
【００２７】
種別情報受信部２１は、移動機１０から無線基地局Ｂ、公衆通信網Ｎ経由で送信された種別情報を受信する。受信された種別情報は、種別情報ＤＢ２２に出力される。
【００２８】
種別情報ＤＢ２２は、種別情報受信部２１から種別情報が入力される度に、この情報を所定のデータ領域に格納する。これにより、データベースを常時最新の状態に維持する。種別情報ＤＢ２２は、物理的には、ＨＤＤ（Hard Disc Drive）を始めとする不揮発性の磁気ディスクにより構成可能であるが、データの秘匿性及び安全性が充分に確保された記憶装置であることが望ましい。図３は、種別情報ＤＢ２２内部のデータ格納例を示す図である。図３に示すように、種別情報ＤＢ２２には、上述した種別情報（例えば、“Ａ”，“900ｉ”，“1.2”，・・・）が、その送信元である移動機のアドレス（例えば、“0001”，“0002”，“0003”，）に対応付けて格納される。アドレスは、例えば、インターネットの電子メールアドレスやＳＭＳ（Short Message Service）のアドレスである。
【００２９】
配信データ指示部２３は、更新用データが新規に登録されたことを契機として、該更新用データに適した種別情報を特定する。更に、種別情報ＤＢ２２を参照することで、上記種別情報に対応するアドレスを有する移動機を、更新用データの配信対象に決定する。その後、配信データ指示部２３は、決定された配信対象のアドレスを種別情報ＤＢ２２から取得し、そのアドレスへの上記更新用データの配信をデータ配信部２５に指示する。
【００３０】
更新用データ格納部２４には、更新用データが、これに適合する種別情報と対応付けて格納されている。この更新用データは、新しい更新用データのリリースに伴って追加され、修正に伴って更新されていく。
データ配信部２５は、配信データ指示部２３からの指示に応じて、指定されたアドレス宛に上記更新用データを配信する。
【００３１】
続いて、図４〜図６を参照して、移動機１０と配信サーバ２０との連携により実現されるデータ取得システム１の動作を説明する。併せて、本発明に係るデータ取得方法を構成する各ステップについて説明する。
まず、電源投入に伴う起動、通信制御プログラムの起動による通信準備完了といった移動機１０側の動作を契機として（図４のＳ１）、移動機１０の状態は、通信可能状態に遷移する（Ｓ２）。一般的には、この後、移動機１０の表示装置に、いわゆる待ち受け画面が表示される。
【００３２】
Ｓ３では、フラグ設定部１３により、種別情報保持部１２に保持されている前回のＵＩＭＩＤと現在のＵＩＭＩＤとの同一性に基づいて、ＵＩＭが従前のものから変更されていないか否かの判定が行われる。
なお、Ｓ３では、ＵＩＭ１１が移動機１０に事前に挿入されていることを前提としたが、挿入されていないことも想定される。この場合には、移動機１０は、移動機種別情報を常に配信サーバ２０宛に送信しない、あるいは、移動機種別情報を常に配信サーバ２０宛に送信する、ものとしてもよい。
【００３３】
Ｓ３における判定の結果、ＵＩＭが変更されていない場合には（Ｓ３；ＹＥＳ）、Ｓ４に移行し、更に、移動機種別の変更の有無が判定される。すなわち、フラグ設定部１３は、種別情報保持部１２に保持されている前回の種別情報と現在の種別情報との同一性に基づいて、ＵＩＭが従前のものから変更されていないか否かの判定を行う（Ｓ４）。
【００３４】
上記判定の結果、種別情報に変更がない場合（Ｓ４；ＹＥＳ）、すなわちＵＩＭと種別情報の双方に変更の無いことが確認された場合には、Ｓ５に移行する。Ｓ５では、送信要否判定部１４が、フラグを参照して、種別情報の送信の要否を判定する。フラグが“０”に設定されている場合には（Ｓ５；ＹＥＳ）、移動機１０の最新の移動機種別が未だ通知されていないものと判断できるので、送信要否判定部１４は、種別情報送信部１５に種別情報の送信を指示する。
【００３５】
送信要否判定部１４から上記送信指示を受けた種別情報送信部１５は、移動機種別情報を配信サーバ２０宛に送信する（Ｓ６）。送信後は、種別情報送信部１５は、フラグ設定部１３に送信完了の旨を通知する。フラグ設定部１３は、この通知を受けると、配信サーバ２０のデータベースに最新の種別情報が反映されていることを確認できるように、“０”が設定されていたフラグを“１”に変更する（Ｓ７）。
なお、フラグが“０”に設定されていない場合（“１”に設定されている場合）には（Ｓ５；ＮＯ）、前述のＳ６及びＳ７の各処理は省略され、通常の処理に移行する。
【００３６】
一方、Ｓ３における判定の結果、ＵＩＭが変更されている場合には（Ｓ３；ＮＯ）、移動機１０の使用者が別のユーザに変わったと推定できるので、種別情報の送信を必要とすべく、フラグを“０”に設定する（Ｓ８）。同様に、Ｓ４における判定の結果、移動機１０の種別情報が前回と異なる場合には（Ｓ４；ＮＯ）、ハードウェア若しくはソフトウェアに何らかの変更があったものと推定できるので、種別情報の送信を必要とすべく、フラグを“０”に設定する（Ｓ８）。Ｓ８の処理終了後は、Ｓ６以降の処理に移行する。
【００３７】
以上の処理を以って、起動または通信準備完了を契機とした種別情報の通知の未完確認が、移動機１０において可能となる。また、最新の移動機種別情報が未通知の場合には、かかる情報がネットワーク経由で配信サーバ２０に通知されるので、配信サーバ２０においても移動機１０の最新の種別情報が常時参照可能となる。すなわち、配信サーバ２０の管理者は、移動機のユーザに種別情報を確実に修正してもらうことができる。
【００３８】
上記一連の処理は、ＵＩＭの挿入を契機として実行されるものとしてもよい。かかる態様では、図５のフローチャートに示すように、フラグ設定部１３によるフラグの参照処理を経ることなく、送信要否判定部１４が、ＵＩＭＩＤの変更の有無に基づいて、種別情報の通知を決定することもできる。すなわち、送信要否判定部１４は、ＵＩＭの挿入を検知すると（Ｓ１１）、挿入されたＵＩＭのＩＤを取得し、該ＩＤと種別情報保持部１２内に既存の前回のＵＩＭＩＤとの比較を行う。
【００３９】
上記比較の結果、これらのＵＩＭＩＤが一致している場合には（Ｓ１２；ＹＥＳ）、ＵＩＭの差替えが無かったものと判断できる。したがって、送信要否判定部１４は、種別情報の通知を指示することなく、通常処理への移行が行われる。これにより、最新の種別情報が配信サーバ２０側で既に把握されているにも関わらず、これと同一の種別情報が再度送信されるといった事態が回避される。
【００４０】
これに対して、挿入されたＵＩＭのＩＤが前回のＵＩＭＩＤと異なる場合には（Ｓ１２；ＮＯ）、ＵＩＭの差替えが行われたものと判断できる。したがって、送信要否判定部１４は、新しいユーザのＵＩＭＩＤ（種別情報の一部）を通知するために、移動機１０の種別情報の送信を種別情報送信部１５に指示する。送信指示を受けた種別情報送信部１５は、新たに挿入されたＵＩＭのＩＤ（最新のＵＩＭＩＤ）を少なくとも含む種別情報を配信サーバ２０宛に送信する（Ｓ１３）。送信後、移動機１０は通常処理に移行する。これにより、配信サーバ２０は、移動機１０のユーザの変更を簡易迅速に検知することができる。
【００４１】
最後に、図６のフローチャートを参照しながら、配信サーバ２０から複数の移動機宛に更新用データを配信する処理について説明する。
図４のＳ６あるいは図５のＳ１３にて送信された移動機種別情報は、配信サーバ２０の種別情報受信部２１により受信され、その送信元アドレスとともに種別情報ＤＢ２２に蓄積されていく（Ｔ１）。この処理は、移動機１０に限らず、更新用データの配信対象となる全ての移動機に関して行われ、その結果、種別情報ＤＢ２２は、常に最新の種別情報が反映された状態に保たれる。
【００４２】
配信データ指示部２３は、新規に登録された更新用データの有無を監視しており（Ｔ２）、更新用データの新規登録を検知すると（Ｔ２；ＹＥＳ）、Ｔ３以降の処理を実行する。Ｔ３では、配信データ指示部２３は、更新用データの配信対象となる移動機の特定を行う。すなわち、配信データ指示部２３は、登録された更新用データに対応する種別情報を更新用データ格納部２４の参照により特定し、更に、当該種別情報が現在通知されている移動機を、更新用データの配信対象として特定する。
【００４３】
その後、配信データ指示部２３は、Ｔ３で特定された全移動機のアドレスを種別情報ＤＢ２２から取得する（Ｔ４）。このとき、各移動機の契約形態をチェックすることにより、移動機アドレスを更に絞り込むこともできる。
そして、配信データ指示部２３は、Ｔ２で新規登録が検知された更新用データを、Ｔ４で取得されたアドレス宛にプッシュ配信する。
【００４４】
つまり、配信サーバ２０は、最新の種別情報が反映されたデータベースを基に、この種別情報に適合する更新用データを、その登録とほぼ同時に配信することができる。このため、更新用データが配信されたにも関わらず、種別情報と適合しないために移動機側において使用されないといった事態は、未然に回避される。その結果、必要最小限の更新用データのみを迅速にユーザに提供するという効率的なデータ配信が可能となる。
【００４５】
以上説明したように、本実施の形態におけるデータ取得システム１によれば、移動機１０と配信サーバ２０とが連携して動作することにより、移動機１０による通信トラフィック量と、配信サーバ２０による通信トラフィック量とをともに低減する。すなわち、移動機１０においては、種別情報が未通知であれば“０”を示し既通知であれば“１”を示すフラグを参照することで、種別情報の通知の要否を判定する。そして、必要と判定した場合にのみ種別情報を通知する。一方、配信サーバ２０においては、更新用データ配信の必要性が生じた場合に、この更新用データを必要とする移動機に対してのみ、その配信を行う。したがって、移動機依存の更新用データの提供に伴うデータ通信量、ひいては処理負荷、通信負荷が節減される。その結果、サーバ設備あるいはネットワーク設備の軽減を図ることができる。
【００４６】
［第２の実施形態］
次に、図７を参照して、本発明の第２の実施形態について説明する。第１の実施形態における移動機１０では、種別情報の通知の要否を判断するための情報として、オンオフの可変設定が可能なフラグを使用するものとしたが、移動機の種別情報をこれに代用することもできる。すなわち、上記第１の実施形態では、出荷後最初の種別情報の送信を主に想定し、移動機１０はフラグを参照するものとしたが、本実施の形態では、フラグを必ずしも必要としない態様を採る。
【００４７】
第２の実施形態における移動機の構成は、フラグ設定部を備えない点を除き、第１の実施形態において詳述した移動機１０の構成と同様である。したがって、各構成要素には同一の符号を付し、図示及びその説明は省略すると共に、以下、第１の実施形態との動作上の差異について詳述する。
【００４８】
図７は、第２の実施形態における移動機の種別情報通知処理を説明するためのフローチャートである。図７を参照しながら、動作を説明する。併せて、本発明に係るデータ取得方法を構成する各ステップについて説明する。なお、図７に示す移動機１０の動作は、第１の実施形態にて詳述した移動機の動作と共通するステップを複数含む。具体的には、図７のＳ２１〜Ｓ２４は、図４に示したＳ１〜Ｓ４に相当する。
【００４９】
以下、各種別情報通知処理の差異であるＳ２５，Ｓ２６について説明する。動作説明の前提として、移動機１０の出荷時には、種別情報（ＵＩＭＩＤを含む）として、通知される種別情報と確実に合致しないもの（例えば、ＮＵＬＬ若しくは００・・・００など）が種別情報保持部１２ｆに保持されている。
ＵＩＭ、移動機種別の何れかに変更の有る場合には、Ｓ２５の処理に移行し、移動機１０は、移動機種別情報を配信サーバ２０宛に送信する。送信後は、移動機１０は、種別情報保持部１２内の種別情報を新しい値に更新する（Ｓ２６）。以降、移動機１０は、この種別情報の同一性を基に、最新の種別情報が配信サーバ２０に通知されているか否かの判定を行う。
【００５０】
このように、第２の実施形態における移動機１０によれば、種別情報保持部１２に保持されている種別情報を用いることで、換言すればフラグを用いることなく、種別情報の通知を必要最小限に行うことができる。これにより、本発明の課題であるトラフィック量の抑制を、より簡易な構成と動作で実現することが可能となる。
【００５１】
なお、上記各実施の形態に記載の態様は、本発明に係る移動機及び配信サーバの好適な例であり、本発明は、かかる態様に限定されるものではない。
例えば、本実施の形態では、移動機として携帯電話を想定して説明したが、これに限らず、ＰＤＡ（Personal Digital Assistance）やパーソナルコンピュータ等、通信機能を備えた端末であればよい。更に、インターネット家電など、普段ユーザが操作することの少ない装置であれば、本発明を特に効果的に適用することができる。
【００５２】
また、更新用データは、配信サーバ自体の有する格納手段に格納されるものとしたが、配信サーバとは別体に構成された外部装置（例えば、サーバ管理業者の運用するＤＢ専用装置）の格納手段に格納されるものとしてもよい。前者の場合には、配信サーバは、更新用データの配信を所望する度に、外部装置に対してその送信を要求する必要がなく、通信負荷低減や応答速度向上の観点から好適である。これに対して、後者の場合には、配信サーバは、取得が要求される可能性のある全ての更新用データを事前に保持しておく必要がないので、格納手段のデータ容量を節減できるというメリットがある。
【図面の簡単な説明】
【００５３】
【図１】本発明に係るデータ取得システムの機能的構成を示す図である。
【図２】種別情報保持部に保持される種別情報の一例を示す図である。
【図３】更新用データ格納部におけるデータ格納例を示す図である。
【図４】第１の実施形態において、起動時または通信準備完了時に実行が開始される移動機の処理を説明するためのフローチャートである。
【図５】ＵＩＭの挿入時に実行が開始される移動機の処理を説明するためのフローチャートである。
【図６】配信サーバの実行する更新用データ配信処理を説明するためのフローチャートである。
【図７】第２の実施形態において、起動時または通信準備完了時に実行が開始される移動機の処理を説明するためのフローチャートである。
【符号の説明】
【００５４】
１…データ取得システム、１０…移動機、１１…ＵＩＭ、１２…種別情報保持部、１３…フラグ設定部、１４…送信要否判定部、１５…種別情報送信部、１６…データ受信部、１７…データ格納部、２０…配信サーバ、２１…種別情報受信部、２２…種別情報ＤＢ、２３…配信データ指示部、２４…更新用データ格納部、２５…データ配信部、Ｂ…無線基地局、Ｎ…公衆通信網
【図１】
2006013951.tif 000003
【図２】
2006013951.tif 000004
【図３】
2006013951.tif 000005
【図４】
2006013951.tif 000006
【図５】
2006013951.tif 000007
【図６】
2006013951.tif 000008
【図７】
2006013951.tif 000009