JP2004227559A

JP2004227559A - ユーザ・アプリケーション・プログラムの制御方法

Info

Publication number: JP2004227559A
Application number: JP2003206626A
Authority: JP
Inventors: Sang Won Chung; 翔元鄭
Original assignee: Nexon Corp
Current assignee: Nexon Korea Corp
Priority date: 2003-01-22
Filing date: 2003-08-08
Publication date: 2004-08-12
Also published as: US20040143586A1; CN1517916A; KR100408758B1; HK1068702A1; CN100416558C

Abstract

【課題】ネットワークを通じてサーバと連結を維持することによって外部からのハッキング及びクラッキングを効果的に放止して不法なソフトウェアの使用を防止すること。
【解決手段】ユーザ・アプリケーション・プログラムからのファイルに対するファイル読出し要請を受信し、ファイルがクライアントコンピュータに格納されているかを判断し、ファイルがクライアントコンピュータに格納されていれば、ファイルのデータをユーザ・アプリケーション・プログラムへ伝達し、ファイルがクライアントコンピュータに格納されていなければ、ファイルが格納されている所定のサーバ（該所定のサーバはクライアントコンピュータとネットワークを通じて連結される）からファイルのデータの中で一部のデータを受信してユーザ・アプリケーション・プログラムに伝達する。
【選択図】図３

Description

【０００１】
【発明の属する技術分野】
本発明は、ユーザ端末機で実行されるユーザ・アプリケーション・プログラムの制御方法に関するものであって、より詳細にはユーザ・アプリケーション・プログラムの実行中に必要なデータを所定のサーバからダウンロードしながらユーザ・アプリケーション・プログラムを行うことができるようにするユーザ・アプリケーション・プログラムの制御方法に関するものである。
【０００２】
【従来の技術】
従来技術におけるパッケージゲーム（オフラインゲーム）は、ゲームプログラム及び該ゲームに必要なデータを全てＣＤ（コンパクトディスク）などの格納媒体に格納してユーザに配布される。しかし、このようなパッケージゲームを含むパッケージ形態のソフトウェア製品は不法複製されて正当な権限のないユーザによって使用される場合が多い。従って、このようなパッケージ形態のソフトウェア製品をオンライン化すればこのような不法複製を防げるだけでなく、自動アップデートのようなオンラインソフトウェアの様々な長所を用いることができる。このような理由でパッケージ形態のソフトウェア製品を手軽にオンラインソフトウェアに切り替えるようにする方法が要求されている。
【０００３】
また、オンラインゲームの場合にも該オンラインゲームのプレーに必要な全てのファイルをユーザコンピュータにダウンロードするまでは前記オンラインゲームをプレーできない。しかも、オンラインゲームがさらに発展して複雑になるほどユーザが初期にダウンロードしなければならない量は更に増加している．最近は、オンラインゲームを行うために初期にダウンロードしなければならないデータの量が２００Ｍｂｙｔｅを超える場合も頻繁に発生している。このように初期にダウンロードしなければならないデータの量があまりにも大きいため、オンラインゲームの最初のユーザが手軽にオンラインゲームに参加することができないという短所があった。従って、オンラインゲーム全体を行うために必要なデータのサイズが大きくても、その内の一部の少ないデータだけをダウンロードした後、オンラインゲームをプレーできる方法が要求されている。
【０００４】
【発明が解決しようとする課題】
本発明は、前記のような従来技術の問題点を解決するために案出されたものであって、従来のパッケージ形態のソフトウェア製品を手軽にオンラインソフトウェア化してオンラインストリーミング（ｏｎ−ｌｉｎｅｓｔｒｅａｍｉｎｇ）の効果をもたらし、ネットワークを通じてサーバとの連結を維持することによって外部からのハッキング及びクラッキング及び不法なソフトウェアの使用を効果的に防止することを目的とする。
【０００５】
また、本発明は従来のパッケージソフトウェアを手軽にオンライン化することによって、周期的に前記パッケージソフトウェアの不法複製の可否を監視することができ、もし不法複製製品である場合には前記パッケージソフトウェアの動作を停止させることによって、不法複製を防ぐことを目的とする。また、本発明の目的はパッケージソフトウェアをオンライン化することによってパッケージソフトウェアの課金を使用時間当りでできるようにすることである。
【０００６】
また、本発明の目的はオンラインソフトウェアでファイル全体ではなくファイルのブロック単位にダウンロードして、初期にダウンロードしなければならないデータのサイズを最小化することによって、ユーザが初期に手軽にゲームを楽しめるようにすることである。
【０００７】
また、本発明はオンラインソフトウェアが要求するデータのパターンを調査してこれによってダウンロードされるデータを最適化し、ユーザ・アプリケーション・プログラムがデータの読出しを要請しない場合にも、前記調査されたデータのパターンによって既にバッグラウンドＰ２Ｐを通じて必要なデータを予めダウンロードを受けることでユーザがデータのダウンロードのために待つ時間を最小化し、またサーバの帯域幅使用を最小化することを目的としている。
【０００８】
【課題を解決するための手段】
上記目的を達成するため、本発明の一実施例によれば、クライアントコンピュータで実行されるユーザ・アプリケーション・プログラムを制御するための方法であって、ユーザ・アプリケーション・プログラムからのファイルに対するファイル読出し要請を受信する段階と、前記ファイルが前記クライアントコンピュータに格納されているかを判断する段階と、前記ファイルが前記クライアントコンピュータに格納されていれば前記ファイルのデータを前記ユーザ・アプリケーション・プログラムへ伝達する段階と、前記ファイルが前記クライアントコンピュータに格納されていなければ、前記ファイルが格納されている所定のサーバ（該所定のサーバは前記クライアントコンピュータとネットワークを通じて連結される）から前記ファイルのデータの中で一部のデータを受信して前記ユーザ・アプリケーション・プログラムに伝達する段階とを含むことを特徴とするユーザ・アプリケーション・プログラム制御方法が提供される。
【０００９】
【発明の実施の形態】
以下、図面を参照しながら本発明に係る実施の形態について詳細に説明する。
【００１０】
図１は、本発明におけるクライアントコンピュータとファイルサーバのネットワーク連結を示した図面である。
【００１１】
ユーザはオンラインゲームをプレーするために自身のクライアントコンピュータ１０２、１０３でインターネットを通じて所定のオンラインゲームサーバ１０４に接続する。従来のパッケージ形態のゲームソフトウェアの場合には、本発明によって簡単にオンライン化されてゲームのプレー中にゲームサーバ１０４に接続してゲームを行えるようになる。即ち、従来のパッケージゲームの場合にもユーザがＣＤなどを購入せず、単にゲームサーバ１０４だけに接続して本発明によってゲームの全体ファイルまたはデータだけをダウンロードした後、直ぐにゲームを始めることができる。
【００１２】
図２は本発明によってクライアントコンピュータに含まれたユーザ・アプリケーション・プログラム、オンラインストリーミングファイルライブラリー及びネットワークインターフェースの関係を示したブロック図である。ユーザ・アプリケーション・プログラム２０１は従来のパッケージソフトウェアそのままであるか、或いは本発明によって従来のパッケージソフトウェアが一部修正されたプログラムである。またはユーザ・アプリケーション・プログラム２０１は従来のオンラインソフトウェアであることも有り得る。本発明は従来のパッケージソフトウェアをオンライン化して様々な有用な効果を得るためのものであるが、本発明の思想のいくつかは従来のオンラインソフトウェアにも容易に適用されて有用な効果を得ることができる。
【００１３】
オンラインストリーミングファイルライブラリー（ｏｎｌｉｎｅｓｔｒｅａｍｉｎｇｆｉｌｅｌｉｂｒａｒｙ）２０２はユーザ・アプリケーション・プログラム２０１のファイル読出し要請及びファイル書込み要請をフッキング（ｈｏｏｋｉｎｇ）し、このようなファイル読出し要請及びファイル書込み要請を行い、またサーバ１０４との連結維持、不法的なソフトウェア使用のモニタリングなどの機能を行う。また、オンラインストリーミングファイルライブラリーは必要なデータをサーバまたはネットワーク上に隣接した他のクライアントコンピュータからダウンロードする機能を行う。オンラインストリーミングファイルライブラリーはライブラリー以外の異なる形態で具備することもできる。
【００１４】
オンラインストリーミングファイルライブラリー２０２は既存の運営体制水準のファイル入出力ＡＰＩ（アプリケーション・プログラム・インターフェース）をフッキングする。既存運営体制水準のファイル入出力ＡＰＩの例ではマイクロソフト社のウィンドー運営体制におけるＣｒｅａｔｅＦｉｌｅ（）、ＲｅａｄＦｉｌｅ（）、ＷｒｉｔｅＦｉｌｅ（）などの関数がある。ウィンドー運営体制ではすべてのＷｉｎ３２ＡＰＩ関数に対してインポートセクション（ＩｍｐｏｒｔＳｅｃｔｉｏｎ）を有する。インポートセクションは一種のジャンプベクトルテーブル（ＪｕｍｐＶｅｃｔｏｒＴａｂｌｅ）である。例えば、ＣｒｅａｔｅＦｉｌｅ（）関数の場合、インポートセクションに前記ＣｒｅａｔｅＦｉｌｅ（）関数に対するポインタが格納される。従って、実行ファイル（ウィンドー運営体制では．ｅｘｅの拡張子を有するファイル）でＣｒｅａｔｅＦｉｌｅ（）関数を用いる場合、前記実行ファイルは前記インポートセクションを参照してＣｒｅａｔｅＦｉｌｅ（）関数のポインタを得るようになり、このポインタが指す関数を行うことになる。ＡＰＩフッキング（ＡＰＩＨｏｏｋｉｎｇ）とは、前記インポートセクションでの各入出力関数のアドレスを他の関数のアドレスに変更することによって行われる。例えば、インポートセクションでＣｒｅａｔｅＦｉｌｅ（）関数のポインタを運営体制が提供するＣｒｅａｔｅＦｉｌｅ（）関数のアドレスを指すものではなく、異なる関数のアドレスを指すように変更すれば、ユーザ・アプリケーション・プログラムでＣｒｅａｔｅＦｉｌｅ（）を行う場合、運営体制が提供するＣｒｅａｔｅＦｉｌｅ（）関数ではない前記異なる関数を行うようになる。
【００１５】
このようなＡＰＩフッキングを行うためにユーザ・アプリケーション・プログラムのメイン関数（ｍａｉｎｆｕｎｃｔｉｏｎ）（例えば、ウィンドーシステムではｗｉｎｍａｉｎ（）関数）の開始と終了にフッキング初期化関数及びＡＰＩフッキング終了関数を追加してＡＰＩフッキングを行う。ＡＰＩフッキング初期化関数は本発明によって提供される関数であって、前記ユーザ・アプリケーション・プログラムのインポートセクションでの各入出力ＡＰＩ関数のポインタを本発明による入出力関数のポインタに変更する機能を行う。ＡＰＩフッキング終了関数では前記変更されたインポートセクションを元に復旧させる機能を行う。沿って、本発明によれば従来のパッケージソフトウェアのメイン関数に２つの関数だけを追加することによってパッケージソフトウェアのオンライン化が行われる。本発明の他の実施例によれば、メイン関数のエントリーポイント（ｅｎｔｒｙｐｏｉｎｔ）自体をフッキングする。この方法は一例としてはコンピュータウィルスプログラムが自身のコードを実行ファイルに付加することと類似な方法である。本実施例によれば、応用プログラムを全く修正しなくてもパッケージソフトウェアのオンライン化が可能であるという長所がある。
【００１６】
図３は、本発明によってクライアントコンピュータで行われるユーザ・アプリケーション・プログラムからのファイル読出し要請を処理する順序を示したフローチャートである。
まず本発明によってＡＰＩフッキングのための入出力ＡＰＩ関数のジャンプベクトルテーブルが本発明の入出力ＡＰＩ関数を行うように変更されている。段階３０１でユーザ・アプリケーション・プログラム２０１からファイル読出し要請を受信し、これをフッキング（ｈｏｏｋｉｎｇ）する。即ち、ユーザ・アプリケーション・プログラム２０１の中のＲｅａｄＦｉｌｅ（）関数を行うようになるが、前記ＲｅａｄＦｉｌｅ（）関数の実行がフッキングされて本発明によるオンラインストリーミングファイル入出力ＡＰＩ関数（ｏｎｌｉｎｅｓｔｒｅａｍｉｎｇＦｉｌｅＩ／ＯＡＰＩｆｕｎｃｔｉｏｎ）が実行される。本発明によるオンラインストリーミングファイル入出力ＡＰＩ関数はオンラインストリーミングファイルライブラリー２０２に格納される。
【００１７】
本発明によるオンラインストリーミングファイル入出力ＡＰＩ関数は、段階３０２で、前記ユーザ・アプリケーション・プログラム２０１が要求したファイルが前記ユーザ・アプリケーション・プログラム２０１が格納されているクライアントコンピュータに格納されているのか判断する。もし、前記ユーザ・アプリケーション・プログラム２０１が要求したファイルが前記クライアントコンピュータに格納されていれば、段階３０３で前記ファイルのデータを読出して前記ファイルのデータを読出して前記ファイルのデータをユーザ・アプリケーション・プログラム２０１へ伝達する。前記ファイルのデータはファイル全体のデータであることも、前記ファイルに含まれたデータの中の一部のデータであることも有り得る。例えば、ユーザ・アプリケーション・プログラムが所定のゲームプログラムである場合、前記ゲームプログラムが行われるために必要なグラフィックデータを格納しているファイルがあり、前記ゲームプログラムが前記グラフィックデータを必要として読出し要請をしたが、前記グラフィックデータを格納しているファイルがクライアントコンピュータに格納されていればこれを読み出してゲームプログラムに伝達することである。
【００１８】
段階３０２でローカルクライアントコンピュータにユーザ・アプリケーション・プログラム２０１が要求したデータが格納されていなければ、オンラインストリーミングファイルの入出力ＡＰＩ関数は段階３０４でネットワークのインターフェース２０３を介して所定のサーバ１０４に接続する。前記所定のサーバは前記クライアントコンピュータとネットワークを介して連結される。前記所定のサーバは前記ユーザ・アプリケーション・プログラム２０１が必要とする全てのデータを格納している。
【００１９】
段階３０５でオンラインストリーミングファイル入出力ＡＰＩ関数はサーバ１０４からファイルのデータを受信し、段階３０６で前記受信されたデータをローカルクライアントコンピュータにキャッシングする。このようなキャッシングを介して同一のデータを重複してダウンロードしないだけでなく後述する優先ファイルの概念を用いてこれからダウンロードされるものと予想されるデータを予めダウンロードして置く利点がある。例えば現在必要なデータがファイル１のブロック５である場合、以前にユーザ・アプリケーション・プログラム２０１を実行しながらその動作を調査してみた結果、ブロック５とブロック６とを共にユーザ・アプリケーション・プログラム２０ｌが使用すると判断すると、ブロック５とブロック６とを共にサーバ１０４からダウンロードしてこれをキャッシングして置いておく。
【００２０】
段階３０７でオンラインストリーミングファイル入出力ＡＰＩ関数はサーバ１０４から受信したファイルのデータをユーザ・アプリケーション・プログラム２０１へ伝達する。そうすると、ユーザ・アプリケーション・プログラム２０１は引続きプレーされるようになる。
【００２１】
例えば、ゲームソフトウェアの全体実行に必要なデータファイルの全体サイズが２００Ｍｂｙｔｅであるが、ゲームソフトウェアが現在の場面をディスプレーするために必要なグラフィックデータは３Ｍｂｙｔｅであり、このグラフィックデータがローカルクライアントコンピュータに格納されていなければ、これを格納しているサーバに接続して前記必要なグラフィックデータをダウンロードしてこれを用いることである。従って、本発明によればユーザは初期に大容量のデータファイルをダウンロードしなくても手軽にオンラインゲームを楽しむことができる。またパッケージゲームソフトウェアを本発明によってオンライン化した場合にも、必要なデータの一部だけを適時サーバからダウンロードしてゲームをプレーすることができる。即ち、本発明によれば、ユーザ・アプリケーション・プログラムの実行に必要な全体データを予めローカルクライアントのコンピュータに格納しなくてもユーザ・アプリケーション・プログラムを実行することができる。
【００２２】
また、本発明のもう一つの実施例によれば、ファイルのデータ読出し及び受信をファイルのデータ中の一部のデータを受信して行い、このような一部のデータの受信は前記ファイルのオフセット及び前記一部のデータのサイズを用いて行われる。これに関しては図５及び図６を参照して後に詳細に説明する。
【００２３】
本発明のもう一つの実施例によれば、一つのクライアントコンピュータ１０２上で実行されているユーザ・アプリケーション・プログラム２０１がファイル読出し要請をしていない間にネットワーク上で隣接して位置した他のクライアントコンピュータ１０３にユーザ・アプリケーション・プログラム２０１を実行するのに必要なデータが格納されているかどうかを識別し、もし、他のクライアントコンピュータ１０３に必要なデータが格納されていればこれを受信してクライアントコンピュータ１０２に格納しておく。他のクライアントコンピュータ１０３も同じようにクライアントコンピュータ１０２からデータを受信することもできる。このような実行のためのプログラムはユーザ・アプリケーション・プログラム２０１が始まると同時にバックグラウンドで始まることもでき、またはユーザ・アプリケーション・プログラム２０１の開始及び終了とは関係なくクライアントコンピュータ１０２、１０３から開始されて実行されることもできる。本発明によれば、ユーザ・アプリケーション・プログラムがデータを要求する前に予め必要なデータをダウンロードしてローカルクライアントコンピュータに格納して置くため、ユーザ・アプリケーション・プログラムを効率的に実行できるだけでなくサーバ１０４に対する負荷も軽減させる。
【００２４】
本発明のもう一つの実施例によれば、ユーザ・アプリケーション・プログラム２０１からデータ読出し要請をフッキングし、前記データがローカルクライアントコンピュータに格納されていればこれをユーザ・アプリケーション・プログラム２０１へ伝達し、ローカルクライアントコンピュータに格納されていなければネットワーク上で隣接した他のクライアントコンピュータに格納されているのかを判断する。もし他のクライアントコンピュータに格納されていればＰ２Ｐを用いてこれをダウンロードする。もしクライアントコンピュータに格納されていなければサーバに接続してダウンロードする。
【００２５】
本発明のもう一つの実施例によれば、ユーザ・アプリケーション・プログラム２０１からデータ読出し要請をフッキングし、前記ファイル読出し要請に応答して、クライアントコンピュータに格納されたユーザ・アプリケーション・プログラム２０１及びユーザ・アプリケーション・プログラム２０１と関連されたデータを検査する。もし、前記ユーザ・アプリケーション・プログラム２０１または前記データが変調された場合には前記ユーザ・アプリケーション・プログラム２０１またはデータがハッキングまたはクラッキングされたものと認められるためこれをサーバ１０４へ報告する。前記変調の可否の判断はＣＲＣチェック（周期冗長検査）等データの変調可否をチェックする多様な方法が用いられる。従って、本発明によれば、ユーザ・アプリケーション・プログラムのハッキングまたはクラッキングの如何を確認してこれに対する適切な対応ができる。本発明によるユーザ・アプリケーション・プログラム及びデータの検査は一定の時間間隔で行われることもできる。
【００２６】
本発明のもう一つの実施例によれば、ユーザ・アプリケーション・プログラム２０１からのファイル読出し要請をフッキングし、所定の時間間隔でサーバ１０４に接続して所定の認証を行う。前記所定の時間間隔は一定の時間間隔の場合もあり、一定でない時間間隔である場合もある。前記認証は前記ユーザ・アプリケーション・プログラムのユーザが適法なユーザであるのかに関する認証である。もし、前記認証が失敗すればそれ以後のユーザ・アプリケーション・プログラムのファイル読出し要請に対してオンラインストリーミングファイル入出力ＡＰＩ関数は如何なる処理も行わないか、またはエラーをユーザディスプレイに表示してユーザ・アプリケーション・プログラムが適切に行われることができないようにする。本実施例によれば、ユーザの不法複製等による不法なプログラムの使用を防ぐことができる。また、本発明によればパッケージプログラムを手軽にオンライン化して使用時間に比例した課金を行うことができる。即ち、パッケージプログラムは使用時間による課金が困難であるが、これを本発明によってオンライン化し、ユーザ・アプリケーション・プログラムの使用時間をサーバ１０４で管理することによって、使用者に対して使用時間による課金を行うことができる。普通のパッケージゲームの場合、１ヶ月程度でゲームを全て終わらせてそれ以上ゲームをしない場合が多いため、１ヶ月程度の使用料金だけをユーザが支払えば前記ゲームを楽しむことができる。従って、ユーザは低廉な費用でゲームプログラムが楽しめるという長所がある。
【００２７】
図４は本発明によってクライアントコンピュータで行われるユーザ・アプリケーション・プログラムからのファイル書込み要請を処理する順序を示したフローチャートである。
【００２８】
段階４０１でユーザ・アプリケーション・プログラム２０１からファイル書込み要請を受信し、これをフッキング（ｈｏｏｋｉｎｇ）する。即ち、ユーザ・アプリケーション・プログラム２０１ＷｒｉｔｅＦｉｌｅ（）関数を実行することになるが、前記ＷｒｉｔｅＦｉｌｅ（）関数の実行がフッキングされて本発明によるオンラインストリーミングファイル入出力ＡＰＩ関数が実行される。前記ＷｒｉｔｅＦｉｌｅ（）関数に対応するオンラインストリーミングファイル入出力ＡＰＩ関数はオンラインストリーミングファイルライブラリー２０２に格納される。
【００２９】
本発明によるオンラインストリーミングファイル入出力ＡＰＩ関数は、段階４０２で、前記ユーザ・アプリケーション・プログラム２０１が書込み要請したファイルをサーバ１０４へアップロード（Ｕｐｌｏａｄ）する必要があるのか否かを判断する。もし、前記ユーザ・アプリケーション・プログラム２０１が書込み要請したファイルをサーバ１０４にアップロードする必要がなければ、段階４０４で前記ユーザ・アプリケーション・プログラム２０１は前記書込み要請したファイルをローカルクライアントコンピュータに格納する。例えば、ユーザに依存するデータの中でサーバ１０４で管理する必要のないデータはローカルクライアントコンピュータにのみ格納されて管理されることができる。このように如何なるデータがサーバにアップロードされる必要があるのかの可否は本発明によるコンピュータプログラムの提供者が決定してそれにともなうロジックが前記オンラインストリーミングファイル入出力ＡＰＩ関数に含まれる。
【００３０】
もし、前記ユーザ・アプリケーション・プログラム２０１が書込み要請したファイルがサーバ１０４にアップロードする必要があれば、オンラインストリーミングファイル入出力ＡＰＩ関数段階４０３でネットワークインターフェース２０３を介して所定のサーバ１０４に接続する。前記所定のサーバ１０４は前記クライアントコンピュータとネットワークを介して連結される。
【００３１】
段階４０５でオンラインストリーミングファイル入出力ＡＰＩ関数はサーバ１０４にアップロードするファイルのデータをローカルクライアントコンピュータにキャッシングする。このようなキャッシングを介して同一のデータを読み出せるようになる場合、再びサーバ１０４からダウンロードしなくても良いため、プログラムの実行の効率性を高める。
【００３２】
段階４０６でオンラインストリーミングファイル入出力ＡＰＩ関数はアップロードするファイルのデータをサーバ１０４にアップロードする。
【００３３】
図５は本発明によってユーザ・アプリケーション・プログラムが接近するファイル内のデータブロックをプロファイルリング（ｐｒｏｆｉｌｉｎｇ）して優先ファイル（ｐｒｉｏｒｉｔｙｆｉ１ｅ）を構成する場合、データブロックと優先ファイルの関係を示した図面である。
【００３４】
本実施例の説明を容易にするために、ユーザ・アプリケーション・プログラムはゲームをプレーするプログラムでプログラム名をｇａｍｅ．ｅｘｅと仮定し、前記ｇａｍｅ．ｅｘｅが必要とするデータファイルの中の一つをｄａｔａｌ．ｄａｔと仮定する。前記ｄａｔａｌ．ｄａｔは１０Ｍｂｙｔｅのサイズのデータファイルである。前記ｇａｍｅ．ｅｘｅのメイン関数は一部修正されてファイル入出力ＡＰＩ関数はオンラインストリーミングファイル入出力ＡＰＩ関数によってフッキングされる。
【００３５】
まず、ユーザ・アプリケーション・プログラムが順番に参照するデータを探すためにプロファイルリング（ｐｒｏｆｉｌｉｎｇ）する段階を説明する。
【００３６】
ユーザ・アプリケーション・プログラム２０１を実行させながら、前記ユーザ・アプリケーション・プログラム２０１が参照するデータを識別する。本発明の一実施例によれば、前記ユーザ・アプリケーション・プログラム２０１が実行されながら一定時間の間に参照されるデータを纏めて一つのファイルに格納するが、これは本発明での優先ファイル（ｐｒｉｏｒｉｔｙｆｉｌｅ）の一つの例である。優先ファイルは一つのファイル内に格納された一部のデータまたは複数のファイル内に格納された一部のデータの組合わせであることも有り得る。即ち、ファイル１に含まれたデータブロックＡ、ファイル２に含まれたデータブロックＢを組み合わせて優先ファイルの一つを生成することができる。このようにすると、ユーザ・アプリケーション・プログラムを実行しながらダウンロードされるデータの構造を把握することが困難であるため、ハッキング及びクラッキングが更に難しくなるという長所がある。
【００３７】
Ｇａｍｅ．ｅｘｅを実行しながら５秒単位で参照されたデータを纏めて一つの優先ファイルを生成する。例えば、ｇａｍｅ．ｅｘｅを実行して０秒から５秒内に読み出し要請が発生したデータがｄａｔａ１．ｄａｔファイルのオフセット１００から１０２４バイトのサイズのデータであれば、前記ｄａｔａ１．ｄａｔファイルのオフセット１００から１０２４バイトのサイズのデータを優先ファイル０の５０２へ格納する。次のｇａｍｅ．ｅｘｅが実行されて５秒から１０秒の間に読出し要請が発生したデータは優先ファイル１に格納される。図５の実施例はｇａｍｅ．ｅｘｅが実行されて５秒から１５秒の間に発生した読出し要請がない場合である。Ｇａｍｅ．ｅｘｅが実行されて１５秒から２０秒の間に読出し要請が発生したデータがｄａｔａ１．ｄａｔファイルのオフセット２０００から４０９６バイトのサイズのデータであるが、これは優先ファイル３の５０３に格納される。本実施例では５秒単位で読出し要求が発生したデータを一つずつのファイルに格納し、読出し要求がない場合には、優先ファイルを生成せず、優先ファイルの番号だけを増加させたが、本発明のもう一つの実施例によれば、前記時間単位を異にするか、優先ファイルの生成方法を異にすることもできる。例えば、優先ファイル０の生成後、その後に生成される優先ファイルは優先ファイル１、２などの順にして中間に空いている優先ファイルが無いようにすることもできる。いずれの場合にもユーザ・アプリケーション・プログラムが実行されればまず要求される可能性の高いデータを優先順位の高いデータとして指定して用いる。即ち、優先順位別に別途のファイルとして管理することもでき、一つのファイル内で各データブロック別に優先順位だけを与え、この優先順位だけを管理して必要なデータブロックを読み出してユーザ・アプリケーション・プログラムへ提供することもできる。このように生成された優先ファイルはサーバ１０４に格納される。
【００３８】
本発明のもう一つの実施例によれば、プログラムの実行中に要求される可能性の高いデータブロックの順に優先順位を与えるのではなく、データのサイズなど異なる要素を考慮して優先順位を定めることができる。ユーザ・アプリケーション・プログラムからのデータ読出し要求がある場合に優先順位の異なるデータが要求された場合には優先順位の高いデータの順にデータ読出し要求を処理し、同一の優先順位に対しては先に要求されたデータ読出し要求を行う。
【００３９】
また、本発明のもう一つの実施例によれば、このような優先順位によって優先順位の高い場合にはユーザ・アプリケーション・プログラムからのデータ読出し要求を受信して直ぐに該当データをサーバ１０４から受信するが、優先順位が低い場合には隣接した他のクライアントコンピュータからバックグラウンドＰ２Ｐを用いてダウンロードする。
【００４０】
このように優先ファイルを生成しておけば、ユーザ・アプリケーション・プログラムが始まると、必要なデータの順に優先ファイルが生成されることになる。従って、統計的にユーザ・アプリケーション・プログラムが優先ファイル０の次には優先ファイル３のデータを要求することが予想されるため、ユーザ・アプリケーション・プログラムが読出し要求をしていない間、例えば前記実施例でｇａｍｅ．ｅｘｅ開始の後、５秒から１５秒の間に、優先ファイル３をバックグラウンドで予めローカルクライアントコンピュータにダウンロードしておけば、ユーザがユーザ・アプリケーション・プログラムを実行する時に必要なデータが予めローカルクライアントコンピュータにダウンロードされているために、必要時になってダウンロードを待つ必要がない。
【００４１】
また、各ユーザによってユーザ・アプリケーション・プログラムを実行しながら互いに異なる命令を先に行うことができるために、各ユーザ・アプリケーション・プログラムが要請するデータの順序が互いに異なることが有り得る。本発明のもう一つの実施例によれば、このような場合を対比して多数のユーザのユーザ・アプリケーション・プログラム使用パターンを分析してこれを反映し、優先ファイルを生成する。このために従来技術による多様な統計学的方法が用いられる。例えば、多数のユーザにユーザ・アプリケーション・プログラムを実行させるようにし、各ユーザによる要請データを分析して先に要求されるデータであればあるほど一定の加重値を与え、各時間帯別に最も多く要請されたデータをその時間帯の優先ファイルとして格納することができる。本発明のもう一つの実施例によれば、最初にはまず任意に優先ファイルを生成した後、ユーザがユーザ・アプリケーション・プログラムを使用しながらサーバ１０４に要請するデータの頻度を見て、最も多く要求されるデータの順に優先順位を与えて優先ファイルを生成しておく。
【００４２】
図６は、本発明の一実施例によって構成されたインデックステーブルを示した図面である。
【００４３】
インデックステーブル（ｉｎｄｅｘｔａｂｌｅ）６００は優先ファイルが如何なるオフセットから如何なるサイズのデータブロックに対応するのかに関する情報を含み、前記プロファイリング時に生成される。図６のインデックステーブルはデータファイルが一つであると仮定し、データファイルに関する情報が含まれていないが、データファイルが複数の個人の場合には優先ファイルに対応するデータファイルが何であるかに関する情報も含む。図６は図５のプロファイリングによって構成された優先ファイルに対するインデックステーブル６００である。
【００４４】
ここで、図６のインデックステーブル６００及び図３を参照してユーザプログラムがデータ読出し要請をした場合の処理について詳細に説明する。
【００４５】
ユーザ・アプリケーション・プログラムであるｇａｍｅ．ｅｘｅがデータファイルであるｄａｔａ１．ｄａｔのオフセット２５００から１０２４バイトのデータを要求するファイル読出し要請をした場合を例に挙げて説明する。ユーザ・アプリケーション・プログラムはＲｅａｄＦｉｌｅ（）関数を使用して特定ファイルの特定オフセットから一定のサイズのデータの読出しを要請することができる。このようなユーザ・アプリケーション・プログラムのＲｅａｄＦｉｌｅ（）関数はオンラインストリーミングファイル入出力ＡＰＩ関数によってフッキングされる。
【００４６】
オンラインストリーミングファイル入出力ＡＰＩ関数は前記要求されるデータがどの優先ファイルに格納されているのかを判断するためにインデックステーブル６００を参照する。インデックステーブル６００を参照した結果、前記データに対応する優先ファイルは優先ファイル３であることが識別される。オンラインストリーミングファイル入出力ＡＰＩ関数は前記優先ファイル３がローカルクライアントコンピュータに格納されているのかを確認する。
【００４７】
もし、前記優先ファイル３が前記ローカルクライアントコンピュータに格納されていれば、前記ファイルのデータを読み出してｇａｍｅ．ｅｘｅが要請した１０２４バイトの大きさのデータだけをｇａｍｅ．ｅｘｅへ伝達する。
【００４８】
もし、優先ファイル３がローカルクライアントコンピュータに格納されていなければ、オンラインストリーミングファイル入出力ＡＰＩ関数はネットワークインターフェース２０３を介して所定のサーバ１０４に接続する。前記所定のサーバは前記クライアントコンピュータとネットワークを介して連結されて全ての優先ファイルを格納している。本発明の一実施例によれば前記サーバ１０４は優先ファイルに含まれていないデータも全て格納する。
【００４９】
オンラインストリーミングファイル入出力ＡＰＩ関数はサーバ１０４から優先ファイル３を受信し、前記受信された優先ファイル３をローカルクライアントコンピュータにキャッシングする。このようなキャッシングを通じてユーザ・アプリケーション・プログラムが優先ファイル３に含まれた異なるデータを要請する場合に再び優先ファイル３をダウンロードする必要がなくなる。
【００５０】
オンラインストリーミングファイル入出力ＡＰＩ関数はサーバ１０４から受信した優先ファイル３を読み出してその中のｇａｍｅ．ｅｘｅが要求したデータをユーザ・アプリケーション・プログラム２０１へ伝達する。そうすれば、ユーザ・アプリケーション・プログラム２０１は引続き行われるようになる。
【００５１】
以上の実施例において、ユーザ・アプリケーション・プログラムからファイルに対する読出し要請を受信する構成はユーザ・アプリケーション・プログラムからのファイル読出し要請をフッキング（ｈｏｏｋｉｎｇ）する方法として説明された。しかし、本記載によって、本発明が属する技術分野で通常の知識を有する者はフッキングだけでなく、ファイル入出力関数を他の関数でマッピングする関数再マッピング（ｆｕｎｃｔｉｏｎｒｅ−ｍａｐｐｉｎｇ）方法を用いて本発明を具現することもでき、他の均等範囲内の他の方法を採用することもできる。
【００５２】
また、本発明の実施例は多様なコンピュータで具現化される動作を行うためのプログラム命令を含むコンピュータ読出し可能媒体を含む。前記コンピュータ読出し可能媒体はプログラム命令、データファイル、データ構造などを単独または組み合わせで含むことができる。前記媒体はプログラム命令は本発明のために特別に設計されて構成されたものであるか或いはコンピュータソフトウェア当業者に公知されて使用可能なものである場合もある。コンピュータ読出し可能書込み媒体の例にはハードディスク、フロッピー（登録商標）ディスク及び磁気テープのような磁気媒体（ｍａｇｎｅｔｉｃｍｅｄｉａ）、ＣＤ−ＲＯＭ、ＤＶＤのような光書込み媒体（ｏｐｔｉｃａｌｍｅｄｉａ）、フロップティカルディスク（ｆｌｏｐｔｉｃａｌｄｉｓｋ）のような磁気−光媒体（ｍａｇｎｅｔｏ−ｏｐｔｉｃａ１ｍｅｄｉａ）、及びＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を格納して行うように特別に構成されたハードウェア装置が含まれる。前記媒体はプログラム命令、データ構造などを指定する信号を伝送する搬送波を含む光または金属線、導波管などの伝送媒体の場合もある。プログラム命令の例にはコンパイラ−によって作られるもののような機械語コ−ドだけでなく、インタプリ−タ等を使用してコンピュータによって行われることのできる高級言語コ−ドを含む。
【００５３】
上記において、本発明の好適な実施の形態について説明したが、本発明の請求範囲を逸脱することなく、当業者は種々の改変をなし得るであろう。
【００５４】
【発明の効果】
本発明によれば、従来のパッケージ形態のソフトウェア製品を手軽にオンラインソフトウェア化してオンラインストリーミングの効果をもたらし、ネットワークを通じてサーバとの連結を維持することによって外部からのハッキング及びクラッキングを効果的に防止し、不法的なソフトウェアの使用を防止することができる。
【００５５】
また、本発明は従来のパッケージソフトウェアを手軽にオンライン化することによって、周期的に前記パッケージソフトウェアの不法複製の可否を監視することができ、もし不法複製製品である場合には前記パッケージソフトウェアの動作を停止させることによって、不法複製を防ぐことができる。また、本発明によれば、パッケージソフトウェアをオンライン化することによってパッケージソフトウェアの課金を使用時間当り課金を可能にする。
【００５６】
また、本発明によれば、オンラインソフトウェアでファイル全体ではなく、ファイルのブロック単位でダウンロードして初期にダウンロードすべきデータを最小化することによって、ユーザが初期に手軽にゲームを楽しむようにする。即ち、本発明によれば、プログラムの開始前に全てのプログラムデータがローカルコンピュータに格納されていなくても実行できるし、オンデマンドなデータ要求を可能にする。
【００５７】
また、本発明によれば、オンラインソフトウェアが要求するデータのパターンを調査し、これによってダウンロードされるデータを最適化し、ユーザ・アプリケーション・プログラムがデータの読出しを要請しない場合にも、前記調査されたデータのパターンによって予めダウンロードすることによってユーザがデータのダウンロードのために待つ時間を最小化し、且つサーバの帯域幅使用を最小化する。
【図面の簡単な説明】
【図１】本発明に係るクライアントコンピュータとファイルサーバのネットワーク連結を示した図である。
【図２】本発明に係るクライアントコンピュータに含まれたユーザ・アプリケーション・プログラム、オンラインストリーミングファイルライブラリー及びネットワークインターフェースの関係を示したブロック図である。
【図３】本発明に係るクライアントコンピュータで行われるユーザ・アプリケーション・プログラムからのファイル読出し要請を処理する順序を示したフローチャートである。
【図４】本発明に係るクライアントコンピュータで行われるユーザ・アプリケーション・プログラムからのファイル書込み要請を処理する順序を示したフローチャートである。
【図５】本発明に係るユーザ・アプリケーション・プログラムが接近するファイル内のデータブロックをプロファイリングして優先ファイルを構成する場合、データブロックと優先ファイルとの関係を示した図である。
【図６】本発明の一実施例によって構成されたインデックステーブルを示した図である。
【符号の説明】
１０２、１０３：クライアントコンピュータ
１０４：サーバ
２０１：ユーザ・アプリケーション・プログラム
２０２：オンラインストリーミングファイルライブラリー
２０３：ネットワークインターフェース
５０１：データファイル
５０２、５０３、５０４：優先ファイル

Claims

クライアントコンピュータで実行されるユーザ・アプリケーション・プログラムを制御するための方法であって、
ユーザ・アプリケーション・プログラムからのファイルに対するファイル読出し要請を受信する段階と、
前記ファイルが前記クライアントコンピュータに格納されているかを判断する段階と、
前記ファイルが前記クライアントコンピュータに格納されていれば、前記ファイルのデータを前記ユーザ・アプリケーション・プログラムへ伝達する段階と、
前記ファイルが前記クライアントコンピュータに格納されていなければ、前記ファイルが格納されている、前記クライアントコンピュータとネットワークを通じて連結された所定のサーバから前記ファイルのデータの中で一部のデータを受信して前記クライアントコンピュータに格納されて前記受信されたデータを前記ユーザ・アプリケーション・プログラムへ伝達する段階とを含むことを特徴とする、ユーザ・アプリケーション・プログラム制御方法。
前記ファイルのデータの中で一部のデータの受信は、前記ファイルのオフセット及び前記一部のデータのサイズを用いて行われることを特徴とする、請求項１に記載のユーザ・アプリケーション・プログラム制御方法。
前記一部のデータだけを受信し、前記ファイルの全てのデータを受信していない状態で前記ユーザ・アプリケーション・プログラムを継続して実行する段階を更に含む、請求項１に記載のユーザ・アプリケーション・プログラム制御方法。
前記ユーザ・アプリケーション・プログラムからのファイルに対するファイル読出し要請を受信する段階は、前記ユーザ・アプリケーション・プログラムからの前記ファイルに対する前記ファイル読出し要請をフッキングするかまたは前記ファイル読出し要請を処理する本来の関数を他の関数にマッピングする段階を含む、請求項１に記載のユーザ・アプリケーション・プログラム制御方法。
前記ファイルが格納されている所定のサーバから前記ファイルのデータを受信して前記クライアントコンピュータにキャッシングする段階を更に含む、請求項１に記載のユーザ・アプリケーション・プログラム制御方法。
前記ファイルを格納している第２のクライアントコンピュータを識別する段階と、
前記第２のクライアントコンピュータから前記ファイルを受信して前記ユーザ・アプリケーション・プログラムに伝達する段階とを更に含むことを特徴とする、請求項１に記載のユーザ・アプリケーション・プログラム制御方法。
前記ユーザ・アプリケーション・プログラムからのファイルに対するファイル読出し要請を受信しない場合、前記ユーザ・アプリケーション・プログラムが必要とするものと予想されるデータを前記データを格納している第２のクライアントコンピュータから受信して格納する段階を更に含むことを特徴とする、請求項１に記載のユーザ・アプリケーション・プログラム制御方法。
前記ユーザ・アプリケーション・プログラムが必要とすると予想されるデータの判断は以前に前記ユーザ・アプリケーション・プログラムを実行した場合、前記ユーザ・アプリケーション・プログラムが要求していたデータに基づいて決定されることを特徴とする、請求項７に記載のユーザ・アプリケーション・プログラム制御方法。
クライアントコンピュータで行われるユーザ・アプリケーション・プログラムを制御するための方法であって、
ユーザ・アプリケーション・プログラムからのファイルに対するファイル書込み要請を受信する段階と、
前記ファイルが前記クライアントコンピュータとネットワークを通じて連結された所定のサーバにアップロードされる必要があるかどうかを判断する段階と、
前記ファイルが前記所定のサーバにアップロードされる必要があれば、前記ファイルを前記所定のサーバにアップロードする段階と、
前記ファイルが前記所定のサーバにアップロードされる必要がなければ、前記クライアントコンピュータに前記ファイルを書込む段階とを含むことを特徴とする、ユーザ・アプリケーション・プログラム制御方法。
ユーザ・アプリケーション・プログラムを制御するための方法であって、
前記ユーザ・アプリケーション・プログラムからのファイルに対するファイル読出し要請を受信する段階と、
前記ファイル読出し要請に応じてクライアントコンピュータに格納された前記ユーザ・アプリケーション・プログラム及び前記ユーザ・アプリケーション・プログラムと関連されたデータを検査する段階と、
前記検査の結果、前記ユーザ・アプリケーション・プログラム及び前記データが変調された場合、これを前記クライアントコンピュータとネットワークを介して連結された所定のサーバに報告する段階とを含むことを特徴とする、ユーザ・アプリケーション・プログラム制御方法。
前記検査する段階は周期冗長検査を用いる検査をすることを特徴とする、請求項１０に記載のユーザ・アプリケーション・プログラム制御方法。
ユーザ・アプリケーション・プログラムを制御するための方法であって、
前記ユーザ・アプリケーション・プログラムからのファイルに対するファイル読出し要請を受信する段階と、
所定の時間間隔で所定のサーバに接続して所定の認証を行う段階と、
前記認証が行われない場合、前記ファイル読出し要請を処理しないことによって前記ユーザ・アプリケーション・プログラムが行われないようにする段階
とを含む、ユーザ・アプリケーション・プログラム制御方法。
前記ユーザ・アプリケーション・プログラムのユーザに対する課金を前記ユーザの前記ユーザ・アプリケーション・プログラムの使用時間に基づいて行うことを特徴とする、請求項１２に記載のユーザ・アプリケーション・プログラム制御方法。
クライアントコンピュータで実行されるユーザ・アプリケーション・プログラムを制御するための方法であって、
ユーザ・アプリケーション・プログラムが接近するデータファイル内の複数のデータブロックのうち少なくとも一つを所定のサーバに優先ファイルとして格納する段階と、
前記複数のデータブロックに対するオフセット、データブロックのサイズ及び前記データブロックに関連される優先ファイル識別子をインデックス格納手段に格納する段階と、
前記ユーザ・アプリケーション・プログラムからの前記データファイルの中の任意のデータブロックに対する読出し要求を受信する段階と、
インデックス格納手段を参照して前記任意のブロックに対応する優先ファイルを識別する段階と、
前記所定のサーバから前記優先ファイルを受信して前記ユーザ・アプリケーション・プログラムに伝達する段階とを含むことを特徴とする、ユーザ・アプリケーション・プログラム制御方法。
前記優先ファイルを格納している第２のクライアントコンピュータを識別する段階と、
前記第２のクライアントコンピュータから前記優先ファイルを受信する段階とを更に含むことを特徴とする、請求項１４に記載のユーザ・アプリケーション・プログラム制御方法。
前記ユーザ・アプリケーション・プログラムからのファイルに対するファイル読出し要請を受信しない場合、前記ユーザ応答プログラムが必要とするものと予想される優先ファイルを前記優先ファイルを格納している第２のクライアントコンピュータから受信して格納する段階を更に含むことを特徴とする、請求項１４に記載のユーザ・アプリケーション・プログラム制御方法。
前記ユーザ・アプリケーション・プログラムが必要とするものと予想される優先ファイルの判断は、以前に前記ユーザ・アプリケーション・プログラムを実行した場合に、前記ユーザ・アプリケーション・プログラムが要求していた優先ファイルに基づいて決定されることを特徴とする、請求項１６に記載のユーザ・アプリケーション・プログラム制御方法。
請求項１乃至１７の中のいずれか一つに記載の方法を実行するプログラムを書込んだコンピュータ読出し可能な書込み媒体。