以下、本発明を実施するための最良の形態について、実施形態として図を用いて説明を行なう。なお、本発明はこれら実施形態に何ら限定されることなく、その要旨を逸脱しない範囲において種々なる態様で実施し得る。
(実施形態1)
実施形態1として、クライアント識別情報を格納するために確保されたクライアント識別情報格納領域を備えたデータを受信などして取得してから蓄積に至るまでの受信蓄積工程において、受信蓄積工程において実行される生成モジュールが、そのクライアントのクライアント識別情報を取得するサブモジュールと、取得したクライアント識別情報を受信などされたデータの備えるクライアント識別情報格納領域に書込むサブモジュールと、を有するように構成されたクライアントから構成されるダウンロードシステムについて説明を行なう。
図1は、実施形態に1に係るダウンロードシステムの機能ブロック図を例示する。ダウンロードシステム100は、サーバ101とクライアント102とからなる。サーバ101とクライアント102とは、インターネットなどに代表される通信網103によって通信を行なうのが可能である。なお、サーバ101とクライアント102とは、通信を行なうことは必須ではなく、例えば、サーバ101でデータを媒体に書込み、その媒体がクライアント102で読み取り可能になっていてもよい。サーバ101とクライアント102の実装の方法の一つとしては、電子計算機を用い、以下に説明する部、手段を実現するためのプログラムを動作させるものがある。
サーバ101は、送信データ蓄積部104と、送信部105とを有する。
「送信データ蓄積部」104は、クライアント識別情報格納領域を備えたデータを蓄積する。ここに「データ」とは、デジタルデータを主に意味する。デジタルデータの例としては、音楽を再生するためのデータ、映像や静止画像を再生するためのデータ、プログラムなどがある。また、プログラムという場合、それ自体で実行可能なデータもあれば、他のモジュールと組み合わせて実行可能となる形式のデータもある。例えば、「o」、「obj」などの拡張子を持つオブジェクトや、「a」、「lib」、「lo」、「dll」などの拡張子を持つライブラリなどがある。本実施形態では、このようなデータは、クライアント識別情報格納領域を備えるものとする。「クライアント識別情報格納領域」とは、クライアント識別情報を格納するために確保された領域である。例えば、送信データ蓄積部104にデータが蓄積されるときに、そのデータにクライアント識別情報格納領域を付加する。例えば、データの開始部分、データの途中部分、データの終わり部分に付加する。また、クライアント識別情報格納領域は、複数の部分に分散されるようになっていてもよい。また、新たに領域を付加することなく、例えば、画像データに電子透かしなどのデータを付加する部分をクライアント識別情報格納領域と呼んでもよい。また、header領域などの空き領域をクライアント識別情報格納領域として用いてもよい。
ここに、「クライアント識別情報」とは、クライアントを識別するために用いることができる情報を言い、クライアントが異なるとクライアント識別情報も異なる蓋然性が高い情報である。クライアント識別情報の例としては、クライアントの製造番号や、クライアントが備える通信インターフェースのMAC(Media Access Control)アドレスや、クライアントがCPU(Central Processing Unit)を備える場合には、CPUの名称、コードネーム、CPUの個数、CPUが動作するクロック数、オーバークロックの有無、CPUに固有の製造番号や、マザーボードの名称、クライアントがハードディスクドライブを備える場合には、ハードディスクのフォーマット時のシリアル番号や、クライアントで動作するオペレーティングシステムのバージョン番号やそのオペレーティングシステムを動作させる場合のシリアルキーや、インストールされているソフトウェアの種類、利用するユーザ名、ユーザの生体認証情報、を含んで生成される情報や、また、これらの組み合わせを含んで生成される情報がある。なお、クライアント識別情報は、以上の例示に限定されるものではない。
サーバ101を電子計算機を用いて実装する場合には、送信データ蓄積部104は、電子計算機の主メモリやディスク装置により実現される。
「送信部」105は、蓄積されたデータを送信する。「蓄積されたデータ」には、送信データ蓄積部104に蓄積されたデータが含まれる。送信は、通信網103を介してクライアント102などに向けて行なわれることが想定される。それ以外には、脱着可能な媒体にデータを書込むことも挙げられる。
サーバ101を電子計算機を用いて実装する場合には、送信部105は、電子計算機の通信インターフェースや、その通信インターフェースを動作させるためのデバイスドライバや、通信のためのプログラムモジュールなどを用いて実現される。また、媒体に書込むためのデバイスドライバなどで実現されてもよい。
クライアント102は、受信部106と、蓄積部107と、生成モジュール保持部108とを有する。
「受信部」106は、サーバ101からデータを受信する。すなわち、サーバ101の送信部105から通信網103を介して送信されるデータを受信する。したがって、ここで受信されるデータには、クライアント識別情報格納領域を備えたデータが含まれる。また、サーバ101によりデータが書込まれた媒体をクライアント102に装着し、その媒体を読み取ることで、データをクライアント102に導入するようになっていてもよい。通信網103は、このように媒体を経由してデータが導入されることも含んで表現しているものとする(他の機能ブロック図においても同様である)。
クライアント102を電子計算機を用いて実装する場合には、受信部106は通信インターフェースや、その通信インターフェースを動作させるためのデバイスドライバや、通信のためのプログラムモジュールなどを用いて実現される。また、媒体を読み取るデバイスドライバを用いて実現されていてもよい。
「蓄積部」107は、蓄積用データを蓄積する。「蓄積用データ」とは、受信したデータに基づいて生成されるデータである。「基づいて」とは、受信したデータを用いて蓄積用データが生成されることを意味しており、後に説明するように、受信したデータにクライアント識別情報格納領域が備えられていれば、そのクライアント識別情報格納領域にクライアント識別情報を格納して得られるデータが蓄積用データとなる。また、受信したデータにクライアント識別情報格納領域がなければ、受信したデータがそのまま蓄積用データとなる。
クライアント102を電子計算機を用いて実装する場合には、蓄積部107は、ハードディスクや主メモリなどを用いて実現される。特に、クライアントの各部を実現するプログラムのうち、ユーザモードで動作するプログラムが参照可能な主メモリの一部やハードディスクの一部であることが主に想定される。
「生成モジュール保持部」108は、生成モジュールを保持する。「生成モジュール」とは、受信部106による受信から蓄積部107による蓄積に至る受信蓄積工程において、蓄積用データのために実行されるモジュールである。すなわち、受信部106が通信網103を介してデータを受信し、その受信されたデータから蓄積部107に蓄積するためのデータである蓄積用データを生成する間に実行されるモジュールである。
生成モジュールは、プログラムのモジュールとして提供されることが主に想定される。したがって、生成モジュール保持部108は、電子計算機の主メモリにより実現され得る。
生成モジュールは、クライアント識別情報取得サブモジュールと、クライアント識別情報書込サブモジュールとを有する。
「クライアント識別情報取得サブモジュール」は、クライアント102の有するクライアント識別情報を取得する。例えば、クライアント102のMACアドレスなどを取得する。クライアントが電子計算機を用いて実現される場合には、取得されたクライアント識別情報は、メモリやレジスタに保持される。
「クライアント識別情報書込サブモジュール」は、クライアント識別情報取得サブモジュールにより取得されたクライアント識別情報を、受信部106により受信したデータの備えるクライアント識別情報格納領域に書込む。例えば、データの開始部分にクライアント識別情報格納領域が備えられているのであれば、そこに、メモリやレジスタに保持されているクライアント識別情報を書込む。また、クライアント識別情報格納領域に格納されるクライアント識別情報が、画像データの電子透かしなどのデータとして格納されるのであれば、そのような電子透かしなどとして、クライアント識別情報を格納する。クライアント識別情報格納領域がデータのどの位置に存在するかは、例えば、前もって、サーバ101との通信プロトコルなどにより規定する。また、データの種類に応じて、その位置が異なるようになっていてもよい。また、データ中の位置を決めておくのではなく、データ中に特定のビットパターンなどの特定の値(例えば、通常のデータに現れる頻度が低いと考えられるAFAFAFAFという16進数)の存在する場所が、クライアント識別情報が書込まれる場所であると定めておいてもよい。
生成モジュールは、クライアント102が電子計算機を用いて実装される場合においては、通信インターフェースのデバイスドライバや通信のためのプログラムモジュールの一部として実現することができる。
図2は、生成モジュールをデバイスドライバなどとして実現する場合での生成モジュールの処理の流れを説明するフローチャートである。この場合、生成モジュールは、サーバ101によりデータが送信されるためのバケットなどが受信あるいは取得される都度、呼び出されるようになっていてもよい。もしそのようになっているのであれば、サーバ101からパケットなどが受信されたり、媒体を読み取るためのブロックデータが得られたりした都度、ステップS201へ処理が移行され、サーバ101からパケットやブロックデータを受け取る。次に、ステップS202へ処理が移行され、受け取ったパケットやブロックデータの表わす部分データの位置がクライアント識別情報格納領域を含むかどうかを判断する。もし、クライアント識別情報格納領域を含めば、ステップS203へ処理が移行され、そうでなければ、ステップS205へジャンプする。ステップS203では、クライアント識別情報の取得がされる。この処理は、クライアント識別情報取得サブモジュールで行なわれる。次のステップS204では、クライアント識別情報格納領域へのクライアント識別情報の書込みが行なわれる。この処理は、クライアント識別情報書込サブモジュールで行なわれる。次のステップでは、読み出しバッファにパケットの表わす部分データを読み出しバッファに追記する。読み出しバッファというのは、通信などのためのプログラムモジュールは上下に階層化されているので、生成モジュールの上位階層のモジュールが入力するデータを一時的に蓄えるバッファである。
図3は、クライアントが電子計算機を用いて実装される場合のデバイスドライバの位置を示す一例図である。ハードウェア301が最下位の層にあり、その上の階層として、ハードウェア301を抽象化するためのオペレーティングシステム302が動作する。このオペレーティングシステム302と、その上で実行される実行プログラム303とにより、クライアントを実現するためのプログラムが構成される。デバイスドライバ304は、オペレーティングシステムの内部で動作し、ハードウェアを抽象化し、ハードウェア301の機能を実行プログラム303からシステムコールAPI(Application Interface)を通じて操作可能にする。なお、実行プログラム303の例としては、データをダウンロードするためのftpクライアントや、ブラウザなどが挙げられる。なお、実行プログラム303は、これらに限定されるものではない。
図4は、ハードウェア301の構成の一例図である。ハードウェア400は、CPU401、RAM402、ハードディスクなどの外部記憶媒体403、ROM404、入出力インターフェース405、通信インターフェース406からなり、これらがバスにより相互に結合された形態となっている。電源が投入されると、ROM404に格納された初期起動プログラム(例えば、BIOS)の所定アドレスからの処理がCPU401により開始される。その初期起動プログラムは、例えば、ハードディスクの最初のセクタに格納されているブートプログラムをRAM402に読込み、ブートプログラムへ制御を移す。ブートプログラムは、例えば、ハードディスクの所定位置に記録されているオペレーティングシステムをRAMに展開し、オペレーティングシステムに制御を移す。オペレーティングシステムは、実行プログラム303をハードディスクから読み取り実行を行なう。実行プログラム303は、例えば、マウスやキーボード、ディスプレイが接続された入出力インターフェース405からのクライアント102の利用者からの指示を読み取り、通信インターフェース406などを用いてサーバとの通信を行ない、データの受信を行なう。このとき、デバイスドライバなどして実現される生成モジュールが動作して、蓄積用データが生成されて、RAM402や外部記憶媒体403に格納される。
なお、近年開発されているオペレーティングシステムでは、デバイスドライバは、動的ライブラリとして提供が可能であり、生成モジュールも、そのような動的ライブラリとして提供が可能である。また、生成モジュールはオペレーティングシステムのカーネル内で動作するように実現されるものではなく、例えば、システムコールAPIの中に組み込まれたり、システムコールAPIを用いたライブラリに組み込まれるようになっていてもよい。また、実行プログラム303の中に組み込まれるなどしてもよい。例えば、実行プログラム303がブラウザであれば、実行モジュールは、そのブラウザに対するプラグインとして提供されてもよい。
(実施形態1:別の構成)
図5は、実施形態1の別の構成における機能ブロック図を例示する。ダウンロードシステム500は、サーバ501と、クライアント502とからなる。サーバ501と、クライアント502とは、インターネットなどに代表される通信網503により通信が可能である。
サーバ501は、送信データ蓄積部504と、送信部505とを有する。上述のサーバ101との違いは、送信データ蓄積部504が、送信プログラム蓄積手段509を有している点である。
「送信プログラム蓄積手段」509は、判断モジュールを備えたプログラムを全体または一部とするデータを蓄積する。「判断モジュール」とは、クライアントの生成モジュールによりクライアント識別情報格納領域にそのクライアントのクライアント識別情報が格納された後に、プログラムの実行処理がされる際に、その格納されたクライアント識別情報と、実行処理を行なうクライアントのクライアント識別情報と、を比較して実行処理を許可するか判断をするためのモジュールである。すなわち、この構成では、プログラムとしてのデータをサーバからダウンロードなどして導入したクライアント以外のクライアントへ、データをコピーしても、そのデータであるプログラムは実行されなくなる。なぜならば、ダウンロードしたクライアントのクライアント識別情報と、コピーを行ないプログラムを実行しようとするクライアントのクライアント識別情報と、が異なる蓋然性が高いからである。
なお、判断モジュールの無いプログラムに、後から判断モジュールを追加することも可能である。この追加のために用いられるプログラムを変換プログラムと呼ぶと、変換プログラムは、サーバ501で動作し、変換プログラムの結果として得られたプログラムを送信プログラム蓄積手段509に蓄積するようになっていてもよい。また、変換プログラムは、サーバ501以外のサーバである変換サーバで動作して、いわゆるアプリケーションサービスプロバイダ的に構成されていてもよい。すなわち、一旦、サーバ501は、判断モジュールのないプログラムを変換サーバに送信し、変換サーバでは、変換プログラムを動作させて、判断モジュールの追加されたプログラムを返信する。サーバ501は、返信されたプログラムを送信プログラム蓄積手段509に蓄積する。
図6は、クライアント識別情報格納領域を備えないプログラムの構造と、そのような構造のプログラムがクライアント識別情報格納領域を備えた構造と、の一例を示す。図6(A)は、クライアント識別情報格納領域を備えないプログラムの構造の一例を示し、プログラムは、header領域601と、.text領域602と、.data領域603とからなる。header領域601は、実行形式であることを示すマジックナンバ、.text領域602などの領域のサイズ、エントリポイントのアドレスなどを保持する。.text領域602は、インストラクションが格納された領域である。.data領域603は、初期化されたデータを含む領域である。なお、プログラムの構造は、オペレーティングシステムごとに異なり、本明細書の例に限定されるものではない。例えば、.data領域が先にあり、次に.text領域があり、.rsrc領域などがその後に続いてもよい。
図6(B)は、図6(A)に例示された構造のプログラムに、クライアント識別情報格納領域604が備えられた構造の一例を示す。ここでは、クライアント識別情報格納領域604は、.text領域602に続けて配置され、.text領域602の一部として備えられている。もちろん、クライアント識別情報格納領域604の配置は、図6(B)に例示されるものに限定されない。例えば、header領域601の空き領域に確保されたり、header領域601と.text領域と、の間に配置されてもよい。また、.data領域603に続けて配置されるようになっていてもよい。
クライアント502は、受信部506と、蓄積部507と、受信モジュール保持部508と、クライアント識別情報生成部510と、を有する。上述のクライアント102との違いは、クライアント識別情報生成部510をさらに有する点である。
「クライアント識別情報生成部」510は、判断モジュールにより利用可能にクライアント識別情報を生成する部である。例えば、クライアント識別情報がMACアドレスであれば、そのMACアドレスを読み出すハードウェアやソフトウェアのモジュールにより構成されている。また、クライアント識別情報が、MACアドレスとCPUの名称などとの組み合わせなどの、複数の情報の組み合わせとして算出されるのであれば、それぞれの情報を読み出して、組み合わせを算出するモジュールにより構成される。読み出されたクライアント識別情報や、算出されたクライアント識別情報は、判断モジュールにより利用可能となるように、レジスタやメモリの領域などに格納される。
図7は、送信プログラム蓄積手段509に蓄積されたプログラムがクライアントにダウンロードなどされ導入された後に実行される場合の判断モジュールの処理の流れを説明するフローチャートを例示する。まず、ステップS701として、プログラムに備えられたクライアント識別情報格納領域に格納されたクライアント識別情報の読み出しを行なう。例えば、.text領域602に続けてクライアント識別情報格納領域が備えられている場合には、.text領域の終わりから所定の大きさの領域に格納されたクライアント識別情報を読み出す。次にステップS702として、プログラムの実行処理を行なうクライアントのクライアント識別情報を、クライアント識別情報生成部510で生成して取得する。次に、ステップS704において、ステップS701で読み出されたクライアント識別情報と、ステップS702で取得されたクライアント識別情報と、の比較を行なう。ステップS705において、比較の結果を判断する。もし、比較の結果が等しい、あるいは、二つのクライアント識別情報が所定の条件で適合するものである場合には、ステップS706へ処理を移行して、プログラムの実行処理を許可する。例えば、判断モジュールの実行の次に実行されるべきプログラムの部分の処理を継続する。もし、比較の結果が異なり、二つのクライアント識別情報が所定の条件で適合しないものである場合には、ステップS707へ処理を移行して、プログラムの実行処理を許可しない。例えば、プログラムの実行を強制的に終了させる。
図8は、サーバとクライアントにおける処理の流れをクライアント側から説明するフローチャートを例示する。ステップS801において、サーバとの通信セッションなどの確立を行なう。サーバ側では、例えば、listenシステムコールなどを実行して、通信セッションの確立を待ち、クライアントでは、connectシステムコールなどを実行して通信セッションを確立させる。ステップS802においては、生成モジュールを介して所定量の情報の読み出しを行なう。所定量というのは、例えばreadシステムコールにより読み出しを行なうためのバッファのサイズである。クライアントでのreadシステムコールは、サーバの送信データ蓄積部に蓄積されたデータのwriteに対応して処理がされる。すなわち、ハードウェア301の通信インターフェース406から実行プログラム303へデータが渡される際に、生成モジュールが動作して、クライアント識別情報格納領域にクライアント識別情報が書込まれるなどして、読み出しバッファに書込まれたデータがreadシステムコールにより読み出される。読み出しが終了すると、ステップS803で、EOF(End of File)かどうかを判断し、もしそうならば、処理を終了し、EOFでなければ読み出したデータをハードディスク等へ追記してステップS802へ戻る。
多くのオペレーティングシステムでは、上述したように、サーバとの通信によるデータの読み出しは、ファイルの読み出しとほぼ同じように行なわれる。したがって、本実施形態では、データはサーバから送信されるとして説明したが、サーバによりプログラムが記録されたCD−ROMなどの媒体に記録されたデータをクライアントが読み取る際に、生成モジュールが実行されるようになっていてもよい。すなわち、媒体には、クライアント識別情報格納領域を備えたデータが記録されており、そのように記録されたデータを読み取り、蓄積に至る工程において、生成モジュールが実行されて、データに備えられたクライアント識別情報格納領域に、クライアントのクライアント識別情報が書込まれるようになっていてもよい。
本実施形態によれば、データのダウンロードなどによる取得から蓄積までの工程で、そのデータが備えるクライアント識別情報格納領域にクライアント識別情報が、クライアントの利用者から透過的に書込まれ、そのクライアントのみで利用可能とすることができるので、不正コピーによるデータの不正利用を防止することができる。
(実施形態2)
実施形態2として、ダウンロードなどにより取得されるデータが備えるクライアント識別情報格納領域には、そのデータのクライアント識別情報格納領域以外の部分を参照して算出された値である格納領域初期値が格納されており、前記生成モジュールは、受信蓄積工程において、受信したデータのクライアント識別情報格納領域以外の部分を参照して格納領域初期値を算出するサブモジュールと、その算出された格納領域初期値を用いて、ダウンロードなどにより取得されるデータの格納領域の有無を検出するサブモジュールを用いて構成される実施形態を説明する。
本実施形態では、サーバの送信データ蓄積部に蓄積されたデータのクライアント識別情報格納領域は、格納領域初期値を格納する。ここに、「格納領域初期値」とは、そのデータのクライアント識別情報格納領域以外の部分を参照して算出された値である。
図9は、格納領域初期値の算出の一例を示す。図9の左のようにheader領域、.text領域、.data領域からなるプログラムがデータであり、.text領域に続けてクライアント識別情報格納領域(図9では、「格納領域」と略してある)が備えられる場合には、格納領域に格納される値である格納領域初期値は、格納領域以外の領域であるheader領域、.text領域、.data領域を参照して算出される。なお、格納領域初期値は、header領域、.text領域、.data領域の全ての部分を参照して算出される必要はなく、その一部を参照して算出されるものであってもよい。
図10は、header領域、.text領域、.data領域の一部であるheader領域、.text領域を参照して格納領域初期値が算出され、格納領域に格納される様子を例示している。このように、格納領域より前の部分を参照して格納領域初期値を算出すると、格納領域の有無の検出が、データの全てを読込まずに行なうことができるという利点がある。また、格納領域より後ろの部分であっても、データの送信、受信などの入出力の単位である同じバッファサイズで示される大きさ程度以内の距離に離れている部分(例えば、ある読込みにより、格納領域と同じバッファに読込まれる部分(具体的な数字を用いて例を挙げると、次のようになる。すなわち、バッファサイズが1024バイトであり、格納領域がデータの1030バイトから50バイトまでの部分である場合には、1080バイトから2048バイトまでの部分を参照して格納領域初期値を算出してもよい))を算出しても同じような利点を得ることができる。
本実施形態では、図11に例示されるように、クライアントの生成モジュール保持部が保持する生成モジュール1101は、クライアント識別情報取得サブモジュール1102と、クライアント識別情報書込サブモジュール1103に加えて、格納領域初期値算出サブモジュール1104と、格納領域検出サブモジュール1105と、を有する。
「格納領域初期値算出サブモジュール」1104は、受信蓄積工程において、クライアント識別情報格納領域以外のデータ部分を参照して格納領域初期値を算出する。格納領域初期値算出サブモジュールが格納領域初期値を算出するアルゴリズムは、サーバの送信データ蓄積部に格納されたデータのクライアント識別情報格納領域に格納されている格納領域初期値を算出するアルゴリズムと実質的に同等になっている。「実質的に同等」とは、アルゴリズムを具現化するプログラムの表現が同じか、異なっていたとしても、同じ入力(ここでは、クライアント識別情報格納領域以外のデータ部分)に対して同じ出力(ここでは、格納領域初期値)を与えることをいう。
ここで、格納領域初期値を算出するアルゴリズムとしては、例えば、可変長の情報を一定のサイズの情報に変換するハッシュ値算出アルゴリズムを用いることができる。より具体的は、SHAやMD5を用いることができる。また、このようなアルゴリズムで算出された値を更にサーバの秘密鍵などを用いて暗号化してもよい。これにより、格納領域初期値と同じ値がクライアント識別情報格納領域以外に現れて、誤った書込みがされるのを防止することが可能となる。
「格納領域検出モジュール」1105は、受信されたデータの中のクライアント識別情報格納領域の有無を検出する。例えば、格納領域初期値算出サブモジュールにより算出された格納領域初期値と同じ値が、クライアント識別情報格納領域に格納されているかどうかを判断して、もし、格納されていれば、クライアント識別情報格納領域が有ると判断し、そうでなければ無いと判断する。クライアント識別情報格納領域が有ると判断されれば、クライアント識別情報書込モジュールにより、有ると判断されたクライアント識別情報格納領域にクライアント識別情報を書込む。
また、図10のようにクライアント識別情報格納領域より前、あるいは、後ろの部分があってもクライアント識別情報格納領域と同じバッファに読込まれる部分などから、格納領域初期値が算出される場合には、生成モジュールは、データの受信を行ないつつ、格納領域初期値の算出を行ない、それまでに算出された格納領域初期値が、新たに受信を行なった部分に現れるかどうかを判断して、クライアント識別情報格納領域の有無を検出してもよい。
本実施形態では、格納領域を持たない一般のデータであってもダウンロードなどして取得されてもデータが改変されることなくダウンロードなどが可能であり、また、クライアント識別情報格納領域を持つデータであっても、そのクライアント識別情報格納領域の位置を可変にできるという効果が得られる。例えば、ダウンロードの都度、あるいは、送信データ蓄積部にデータが蓄積される都度、クライアント識別情報格納領域の位置が変わるようにでき、データの不正コピーを困難にできる。
(実施形態3)
実施形態3として、生成モジュールは、取得されたデータにクライアント識別情報格納領域が有ることを検出した場合に、検出されたクライアント識別情報格納領域に格納領域初期値以外の値が格納されているかどうかを検出するサブモジュールから構成されている場合について説明する。
図12は、本実施形態での生成モジュールの構成の一例図である。本実施形態では、生成モジュール1201は、クライアント識別情報取得サブモジュール1202と、クライアント識別情報書込サブモジュール1203に加えて、格納領域初期値算出サブモジュール1204と、格納領域検出サブモジュール1205と、更に、不正検出サブモジュール1206と、を有する。
「不正検出サブモジュール」1206は、受信したデータにクライアント識別情報格納領域が有ることが検出された場合、検出されたクライアント識別情報格納領域に格納領域初期値以外の値が格納されているかどうかを検出する。データの構造や、クライアント識別情報格納領域のデータ中での位置が予め定められていたり、データのheader領域などに格納されている情報から位置を算出できる場合には、クライアント識別情報格納領域以外の部分を参照して、格納領域初期値を算出することが可能である。そして、算出された格納領域初期値が、クライアント識別情報格納領域に格納されているかどうかを判断することができる。
もし、算出された格納領域初期値が、クライアント識別情報格納領域に格納されていなければ、受信したデータは、サーバから正規に受信されたものではなく、途中で改変がされたり、あるいは、サーバから別のクライアントに受信され、それが受信されたりしたものであることが判明し、何らかの不正が行なわれていることを検出することができる。このように不正が検出された場合には、データの取得を中止したり、データを破壊などするようになっていてもよい。あるいは、クライアントの利用者に不正が介在した旨を入出力インターフェース405を介して表示などを行なってもよい。
このように、本実施形態では、あるクライアントに取得されてクライアント識別情報格納領域にそのクライアントのクライアント識別情報が書込まれたデータが、別のクライアントにダウンロードなどされたことを検出することができ、不正行為などが行なわれたことを検出することが可能となる。
(実施形態4)
実施形態4として、サーバに任意のデータを入力可能とし、入力されたプログラムにクライアント識別情報格納領域を確保する機能を備えさせたダウンロードシステムについて説明する。
図13は、実施形態4に係るダウンロードシステムの機能ブロック図を例示する。ダウンロードシステムは、サーバ1301と、クライアント1302と、からなる。サーバ1301と、クライアント1302と、は、通信網1303などを介して通信が可能である。
サーバ1301は、送信データ蓄積部1304と、送信部1305と、データ入力部1309と、格納領域確保部1310と、を有する。なお、送信データ蓄積部1304は、送信プログラム蓄積手段を更に有していてもよい。
クライアント1302は、受信部1306と、蓄積部1307と、生成モジュール保持部1308と、を有する。なお、クライアント1302は、クライアント識別情報生成部を更に有していてもよい。
したがって、本実施形態に係るダウンロードシステムの構成は、実施形態1に係るダウンロードシステムにおいて、サーバが更にデータ入力部1309と格納領域確保部1310とを有する構成となっている。
「データ入力部」1309は、任意のデータを入力する。例えば、データを生成した企業などからデータを所定のプロトコルで受信したり、データを生成した企業などから送付された媒体に記録されたデータを読み取ったりする。
「格納領域確保部」1310は、データ入力部1309に入力されたデータに、クライアント識別情報格納領域を確保する。例えば、データの開始部分、データの途中部分、データの終わり部分のうち、予め定められた位置にクライアント識別情報格納領域を確保する。また、クライアント識別情報格納領域が、画像データなどの電子透かしなどのデータとして付加される部分であれば、付加される電子透かしなどのデータの初期値を設定するようになっていてもよい。この初期値により、例えば、どのサーバへいつ誰によってデータが入力されたかが示されるようになっていてもよい。
図14は、実施形態4に係るダウンロードシステムでのサーバの処理の流れを説明するフローチャートである。ステップS1401において、データ入力部1309により、任意のデータを入力する。続くステップS1402において、入力されたデータに、格納領域確保部1310により、クライアント識別情報格納領域を確保する。そして、ステップS1403において、送信データ蓄積部1304により、データを蓄積する。
このようにダウンロードシステムのサーバが構成されることにより、配信先のクライアントでのみ利用可能なデータの配信を容易に行なうことができる。
(実施形態5)
実施形態5として、プログラムを全体または一部とするデータが入力された場合に、そのプログラムに判断モジュールを追加するサーバからなるダウンロードシステムについて説明を行なう。
図15は、実施形態5に係るダウンロードシステムの機能ブロック図を例示する。ダウンロードシステム1500は、サーバ1501と、クライアント1502と、からなる。サーバ1501と、クライアント1502と、は、通信網1503などを介して通信が可能である。
サーバ1501は、送信データ蓄積部1504と、送信部1505と、データ入力部1509と、格納領域確保部1510と、判断モジュール追加部1511と、を有する。なお、送信データ蓄積部1504は、送信プログラム蓄積手段を更に有していてもよい。
クライアント1502は、受信部1506と、蓄積部1507と、生成モジュール保持部1508と、を有する。なお、クライアント1502は、クライアント識別情報生成部を更に有していてもよい。
したがって、本実施形態に係るダウンロードシステムの構成は、実施形態4に係るダウンロードシステムにおいて、サーバが更に判断モジュール追加部1511を有する構成となっている。
「判断モジュール追加部」1511は、データ入力部1509に入力されたデータに判断モジュールを追加する部である。なお、この場合、データ入力部1509に入力されたデータは、プログラムであることが好ましい。ただし、プログラムでなくてもよい。例えば、音楽再生用のデータである場合には、その再生プログラムが、データに追加された判断モジュールを読み込み、判断モジュールを実行するようになっていてもよい。
図16は、判断モジュールを追加の一例を示す。図16(A)のようにheader領域と、.text領域と、.data領域からなるプログラムが入力されたとする。この場合、図16(B)に例示されるように、格納領域確保部1510により、クライアント識別情報格納領域が確保され、次いで、判断モジュール追加部により判断モジュールがクライアント識別情報格納領域の前に追加される。
なお、クライアント識別情報格納領域が確保され、次いで、判断モジュールが追加されると説明したが、判断モジュールの追加が先に行なわれてもよい。また、図15では、判断モジュールが追加されてから、送信データ蓄積部1504にプログラムが蓄積されるようになっているが、送信データ蓄積部1504に蓄積されるプログラムには、判断モジュールは追加されず、送信部1505による送信時にプログラムに判断モジュールが追加されるようになっていてもよい。
本実施形態では、判断モジュールがサーバ側において追加されるので、プログラムの制作者などは、判断モジュールの追加を行なってプログラムを製作する必要がない。また、判断モジュールのソースコードや判断モジュールのリンクの際に必要なシンボルテーブル付きのオブジェクトコードがプログラムの制作者などの手に渡って判断モジュールでの処理が解析されて、どのようにクライアント識別情報の比較などが行なわれるかが公知になってしまうことを防止することができる。
(実施形態6)
実施形態6として、サーバに配信などのために蓄積されるデータやサーバにより配信されるデータが暗号化される実施形態について説明する。
図17は、実施形態6に係るダウンロードシステムの機能ブロック図を例示する。ダウンロードシステム1700は、サーバ1701と、クライアント1702と、からなる。サーバ1701と、クライアント1702と、は通信網1703などを介して通信が可能である。
サーバ1701は、送信データ蓄積部1704と、送信部1705と、データ入力部1709と、格納領域確保部1710と、暗号化部1711と、を有する。なお、サーバ1701は、判断モジュール追加部を更に有してもよい。また、送信データ蓄積部1704は、送信プログラム蓄積手段を更に有していてもよい。
クライアント1702は、受信部1706と、蓄積部1707と、生成モジュール保持部1708と、を有する。なお、クライアント1702は、クライアント識別情報生成部を更に有していてもよい。
したがって、本実施形態に係るダウンロードシステムの構成は、実施形態5に係るダウンロードしシステムにおいて、サーバが更に暗号化部1711を有している構成となっている。
「暗号化部」1711は、入力されたデータを暗号化する。この際、好ましくは、データに格納領域確保部1710により確保されたクライアント識別情報格納領域以外の部分を暗号化する。なぜならば、クライアントで復号化を行なう際に、クライアント識別情報格納領域に格納された値を復号化することにより、その値が変更されてしまい、実施形態2のように格納領域初期値の存在の有無を検出することが困難か不可能になってしまう可能性があるからである。
暗号化は、例えば、サーバ1701の秘密鍵により行なう。また、暗号化は、送信データ蓄積部にデータを蓄積する前に行なうのではなく、送信部1705によりデータが送信される直前に行なうようになっていてもよい。これにより、サーバ1701とクライアント1702との間で決められた共有鍵で暗号化することができ、サーバで必要になるデータの暗号化のコスト、クライアントで必要となる復号化のコストを下げることができる。
サーバ1701で暗号化を行なう目的は、クライアントにおける、あるいは、クライアントによるデータの取得経路上におけるデータの難読化であり、例えば、どのようなデータの構造になっており、その構造上でのクライアント識別情報格納領域の位置の解析を困難としたりする。
本実施形態では、データは、汎用データであってもよいが、その全体または一部がプログラムであることとが好ましい。この場合、暗号化されたデータの全体または一部である暗号化されたプログラムは、クライアントで自己復号化されるようになっているのが好ましい。
図18は、このような場合のダウンロードシステムの機能ブロック図を例示する。ダウンロードシステム1800は、サーバ1801と、クライアント1802と、からなる。サーバ1801と、クライアント1802と、は、通信網1803などを介して通信が可能である。
サーバ1801は、送信データ蓄積部1804と、送信部1805と、データ入力部1809と、格納領域確保部1810と、判断モジュール追加部1811と、暗号化部1812と、を有する。暗号化部1812は、復号化モジュール追加手段1813を有する。なお、データの全体または一部がプログラムであれば、送信データ蓄積部1804は、送信プログラム蓄積手段を更に有しているものとする。
クライアント1802の構成は、図17のクライアント1702のそれと同じである。
「復号化モジュール追加手段」1813は、復号化モジュールを追加する。「復号化モジュール」は、暗号化部1812により暗号化された部分を復号化して実行するモジュールである。ここでいう「復号化」とは、クライアントでの実行処理に先立って行なわれる復号化の処理を意味する。
図19は、サーバ1801に入力されたデータの全体または一部がプログラムである場合におけるプログラムの変化の様子の一例を示す。図19(A)に示すように、header領域と、.text領域と、.data領域と構成されるプログラムが入力されたとする。この場合、格納領域確保部1810と、判断モジュール追加部1811と、により、図19(B)に示されるように、クライアント識別情報格納領域が確保され、判断モジュールが.text領域に追加される。次いで、図19(C)に示されるように、暗号化部1812により、.text領域、.data領域が暗号化され、暗号化.text領域、暗号化.data領域になる。そして、復号化モジュール追加手段により、図19(D)に示されるように復号化モジュールが追加される。headerから復号化モジュールへ延びる矢印線は、エントリポイントが書き換えられ、まず、復号化モジュールが実行されるようになっていることを示す。これにより、図19(D)に示されるプログラムが実行されると、符号化モジュールが最初に実行され、暗号化.text、暗号化.dataが復号化され、暗号化される前の.data領域のデータを用いて暗号化前の.text領域の命令が実行がされる。なお、復号化された.data領域のデータ、.text領域の命令は、プログラムを実行するプロセスのヒープ領域に配置されるようになっていてもよい。以上の技術については、出願人が既に出願を行なった特願二00四−九七0八七に開示されている。
本実施形態では、判断モジュールが暗号化されるので、判断モジュールのアルゴリズムの解析が困難となり、クライアント識別情報をどのように取得し、クライアント識別情報の比較などを行なうかを他人が知ることが困難となり、より一層プログラムの不正利用を防止することができる。
(実施形態7)
実施形態7として、受信蓄積工程によりダウンロードなどされたプログラムが、インストールなどのためのプログラムを展開して起動する例について説明する。
図20は、「インストールなどのためのプログラム」と説明したプログラムの構造を例示する。このプログラムを仮に「Setup.exe」と呼ぶとすると、このプログラムには、「チェックモジュール」が含まれ、このチェックモジュールは、Setup.exeの実行の途中に実行される。
図21は、チェックモジュールの処理の流れを説明するフローチャートを例示する。チェックモジュールは、まず、ステップS2101において、所定の領域に格納されているデータを読み出す。「所定の領域」とは、後述のように、Setup.exeと、受信蓄積工程によりダウンロードなどされたプログラムと、の両方がアクセス可能な予め定められた領域のことである。この領域は、例えば、Setup.exeを実行するプロセスと、受信蓄積工程によりダウンロードなどされたプログラムを実行するプロセスと、により共有される共有メモリに設けられてもよい。あるいは、ハードディスクなどの記憶媒体の所定の位置に設けられてもよい。また、外部に設置されているファイルサーバなどのネットワーク通信などによりアクセスが可能なサーバにその領域が設けられてもよい。なお、「読み出す」には、例えば、所定の領域に格納されているデータを取得して、復号化などの処理を行なうことをも含んでもよい。
ステップS2102として、ステップS2101で読み出されたデータが所定の値に等しいかどうかを判断する。「所定の値」とは、受信蓄積工程によりダウンロードなどされたプログラムを実行するプロセスが設定したと判断できる値であり、例えば、固定値や、そのプロセスが実行されるクライアントなどの識別情報やそれを用いて算出される値などである。
もし、ステップS2101で読み出されたデータが所定の値に等しいと判断されれば、ステップS2103へ処理を移行する。すなわち、チェックモジュールの次に実行されるモジュールなどへ処理を続行する。また、もし、ステップS2101で読み出されたデータが所定の値に等しいと判断されなければ、ステップS2104へ処理を移行する。ステップS2104へ処理が移行されることにより、処理が中断される。すなわち、Setup.exeの実行がステップS2104にて中断される。
これにより、Setup.exeが、受信蓄積工程によりダウンロードなどされたプログラムを実行するプロセスにより起動された場合に、限り、Setup.exeの処理が続行されることになる。
なお、チェックモジュールは、例えば、Setup.exeを製作などする企業などにライブラリとして渡しておいてもよい。あるいは、動的実行ライブラリとして提供され、呼び出し方をその企業などに伝えておき、動的実行ライブラリの本体は、クライアントにインストールしておいてもよい。
図22は、受信蓄積工程によりダウンロードなどされたプログラムの構造の一例図を示す。このプログラムを「HTSetup.exe」と呼ぶことにすると、HTSetup.exeは、判断モジュールと、クライアント識別情報格納領域を有し、また、Setup.exeを展開可能な形式で有する。「展開可能な形式」とは、C:\temp などの一時フォルダなどにSetup.exeを格納するファイルやフォルダを作成できる形態をいう。例えば、HTSetup.exeのデータ領域に、Setup.exeのプログラムコードがそのまま格納される。あるいは、Setup.exeのプログラムコードが、HTSetup.exeにより復号化できる形態で、HTSetup.exeのデータ領域に格納される。
このような構造により、Setup.exeを製作などする企業などと、HTSetup.exeなどを製作などする企業と、を異なるようにさせることができる。すなわち、Setup.exeの提供を他の企業などから受け、HTSetup.exeを製作することに専念する企業などを設立できる。
図23は、HTSetup.exeがクライアントに蓄積された後に、HTSetup.exeが起動されたことにより行なわれる処理の流れを説明するフローチャートである。
ステップS2301において、判断モジュールを実行する。もし、実行のクライアントが、HTSetup.exeが受信蓄積工程により蓄積されたクライアントであれば、判断モジュールの処理の後には、ステップS2302へ処理が続行される。しかし、実行のクライアントが、HTSetup.exeが受信蓄積工程により蓄積されたクライアントと異なれば、ステップS2301で処理が中断し、ステップS2302へ処理が続行しなくなる。
ステップS2302において、所定の領域に所定のデータを格納する。例えば、あらかじめ決められた固定値のデータや、HTSetup.exeが起動されたクライアントなどの識別情報やそれを用いて算出される値などを、予め定められた領域に格納する。
ステップS2303において、一時フォルダなどに、Setup.exeを展開し、Setup.exeを起動する。これにより、図21に示された処理がされることになる。
ステップS2304において、Setup.exeの終了を待つ。
ステップS2305において、所定の領域をクリア、あるいは削除などする。
以上をまとめると、次のようになる。(1)例えば、A社がインストーラなどのプログラム(例えば、Setup.exeという)を生成する場合に、共有メモリなどの所定の領域に特定の所定のデータ(例えば、特定の文字列)があるかどうかをチェックするライブラリなどのモジュールを埋め込む。(2)例えば、B社は、クライアント識別情報格納領域を有し、なおかつ、共有メモリなどの所定の領域に所定のデータを書込む機能を持ったプログラム(例えば、HTSetup.exeという)をバイナリレベルでSetup.exeと結合する。ここに結合するとは、HTSetup.exeの実行時にSetup.exeを生成可能にHTSetup.exeに取り入れることをいう。例えば、HTSetup.exeのデータ領域に、Setup.exeのファイルの内容を取り入れる。必要に応じて、Setup.exeのファイルの内容を暗号化しておき、HTSetup.exeの実行時にその暗号化された内容を復号化するようになっていてもよい。(3)HTSetup.exeをダウンロードなどして、クライアントに導入する際に、クライアント識別情報がSetup.exeのクライアント識別情報格納領域に書込まれる。(4)HTSetup.exeを起動すると、HTSetup.exeの判断モジュールが、クライアント識別情報格納領域に書込まれたクライアント識別情報と、HTSetup.exeが起動されたクライアントのクライアント識別情報とが比較され、おなじあるいは、適合するものであれば、HTSetup.exeの他の処理が行なわれる。これにより、共有メモリなどの所定の領域に所定のデータが書込まれる。(5)また、HTSetup.exeは、Setup.exeを展開して、一時フォルダに格納し、Setup.exeを起動する。(6)Setup.exeは、所定の領域に所定のデータが書込まれていることを確認すると、そのまま処理を続行し、また、所定の領域がアクセス不可能であったり、所定のデータが書込まれていなかったりすれば、処理を中止する。(7)Setup.exeのプロセスが終了するなどして、所定の領域が不要になれば、所定の領域をクリアしたり、破棄したりする。
以上のような構成により、HTSetup.exeは、受信蓄積工程が行なわれたクライアントでのみ実行可能となる。また、Setup.exeは、HTSetup.exeから起動された場合のみ、実行がされる。