JP2008140344A - 情報処理方法、情報処理装置、及びコンピュータプログラム - Google Patents

Abstract

【課題】ネットワーク経由でコンテンツを取得する際、コンテンツ取得終了からサブシステム起動までの時間がボトルネックとなっていた。
【解決手段】サーバ側より、サーバが提供するコンテンツのメディアタイプのリストを取得（ステップＳ４０１〜Ｓ４０３）し、必要となるサブシステムを、コンテンツをリクエストする（ステップＳ４０５）前に起動しておく（ステップＳ４０４）。このようにすることで、コンテンツ取得前の利用されていなかった計算資源をサブシステムの起動に当てることができ、コンテンツ取得後のサブシステム起動の待ち時間が不要となる。メディアタイプのリストを記述する手段として、ＷＳＤＬやＸＨＴＭＬなどを利用する。
【選択図】 図４

Description

本発明は、Ｗｅｂコンテンツを表示するブラウザにおいて、コンテンツのデータ形式に応じて適切な処理プログラムを呼び出す情報処理方法、情報処理装置、及びコンピュータプログラムに関する。

Ｗｅｂ上で公開されているコンテンツを利用するアプリケーション、主にＷｅｂブラウザと呼ばれるアプリケーションは、取得したコンテンツの種類を識別する事で、その表示方法を変更している。

コンテンツを提供するサーバは、コンテンツ提供時にメディアタイプと呼ばれるコンテンツの種類を識別するための文字列を合わせて提供する。ＨＴＭＬデータであれば、text/html、ＪＰＥＧ画像データであれば、image/jpeg、ＳＶＧ画像データであれば、image/svg+xmlといった、一般的に公開された仕様に従った文字列を利用し、コンテンツの種類を明示している。

そのために、Ｗｅｂブラウザはコンテンツの中身を解析することなくコンテンツの種類を識別することができ、それぞれのメディアタイプに最適なプラグインを動的に起動し、コンテンツを表示するといった処理が可能となる。この場合、プラグインの起動はメディアタイプ取得後となる。

また、コンテンツを再生する前にプログラムを起動しておき、コンテンツ再生時の遅延を短くする技術もある。例えば、ストレージに保存されている各ファイルの種類を、ファイルの拡張子などを利用して認識し、事前に起動するプログラムを判断する技術（特許文献１参照）などが挙げられる。

特開平８−２８６９２５号公報 "Ｗ３Ｃ"、インターネット（ＵＲＬ：http://www.w3.org/2002/ws）

しかしながら、Ｗｅｂ上のコンテンツの場合、コンテンツはサーバ上で管理、又は動的に生成される。このために、ブラウザ側は各コンテンツの実体取得するまでは取得するコンテンツの種類を認識する事ができない。そのため、特許文献１のように事前にコンテンツの実体を利用してコンテンツの種類を認識することができないという問題があった。

そこで本発明は、コンテンツの種類の識別をコンテンツ取得前に行うことを目的とする。

本発明の情報処理方法は、サーバが公開しているサービスへのリンクと共に各サービスが提供するコンテンツの種類を記述したリンク記述を取得するリンク記述取得工程と、前記リンク記述より前記サーバから得られる提供するコンテンツの種類一覧を生成する提供可能データ種類取得工程と、データ取得前に必要なサブシステムの起動を開始するサブシステム起動工程と、ネットワークを介して前記サーバよりデータを取得するデータ取得工程と、前記取得したデータの種類を識別するデータ種類識別工程と、前記データ取得工程により取得した前記データを、前記サブシステム起動工程において起動済みの前記サブシステムへ渡すデータ受け渡し工程と、前記データの種類に関連付けられたサブシステムにより前記取得したデータを処理するデータ処理工程とを有し、前記データ受信終了からサブシステムによるデータの処理開始までの時間を短縮することを特徴とする。
また、本発明の情報処理装置は、ネットワークを介してサーバよりデータを取得するデータ取得手段と、前記取得したデータの種類を識別するデータ種類識別手段と、前記データの種類に関連付けられたサブシステムにより前記取得したデータを処理するデータ処理手段と、前記サーバが公開しているサービスへのリンクと共に各サービスが提供するコンテンツの種類を記述したリンク記述を取得するリンク記述取得手段と、前記リンク記述より前記サーバから得られる提供するコンテンツの種類一覧を生成する提供可能データ種類取得手段と、データ取得前に必要なサブシステムの起動を開始するサブシステム起動手段と、前記データ取得装置により取得した前記データを、前記サブシステム起動装置において起動済みの前記サブシステムへ渡すデータ受け渡し手段とを備え、前記データ受信終了からサブシステムによるデータの処理開始までの時間を短縮することを特徴とする。
また、本発明のコンピュータプログラムは、サーバが公開しているサービスへのリンクと共に各サービスが提供するコンテンツの種類を記述したリンク記述を取得するリンク記述取得ステップと、前記リンク記述より前記サーバから得られる提供するコンテンツの種類一覧を生成する提供可能データ種類取得ステップと、データ取得前に必要なサブシステムの起動を開始するサブシステム起動ステップと、ネットワークを介して前記サーバよりデータを取得するデータ取得ステップと、前記取得したデータの種類を識別するデータ種類識別ステップと、前記データ取得ステップで取得した前記データを、前記サブシステム起動ステップにおいて起動済みの前記サブシステムへ渡すデータ受け渡しステップと、前記データの種類に関連付けられたサブシステムにより前記取得したデータを処理するデータ処理ステップとをコンピュータに実行させて、前記データ受信終了からサブシステムによるデータの処理開始までの時間を短縮することを特徴とする。

本発明によれば、サーバから取得したコンテンツを処理する際の遅延時間が短くなり、操作性が向上する。

（第１の実施の形態）
本発明の情報処理方法を実行するサーバ装置やクライアント装置を構成するコンピュータ装置の構成について、図１のブロック図を用いて説明する。サーバ装置やクライアント装置はそれぞれ単一のコンピュータ装置で実現してもよいし、必要に応じた複数のコンピュータ装置に各機能を分散して実現するようにしてもよい。複数のコンピュータ装置で構成される場合は、互いに通信可能なようにLocal Area Network（ＬＡＮ）などで接続されている。

図１において、１０１はコンピュータ装置全体を制御するCentral Processing Unit（ＣＰＵ）である。１０２は変更を必要としないプログラムやパラメータを格納するRead Only Memory（ＲＯＭ）である。１０３は外部装置などから供給されるプログラムやデータを一時記憶するRandom Access Memory（ＲＡＭ）である。１０４はコンピュータ装置に固定して設置された外部記憶装置である。なお、外部記憶装置１０４は、ハードディスクやメモリカード、あるいはコンピュータ装置から着脱可能なフレキシブルディスク（ＦＤ）やCompact Disk（ＣＤ）等の光ディスク、磁気や光カード、ＩＣカード、メモリカードなどを含む。

１０５はユーザの操作を受け、データを入力するポインティングデバイスやキーボードなどの入力デバイスとのインタフェースである。１０６はコンピュータ装置の保持するデータや供給されたデータを表示するためのモニタとのインタフェースである。

１０７はＬＡＮ２０３などのネットワーク回線に接続するためのネットワークインタフェースである。１０８は１０１〜１０７の各ユニットを通信可能に接続するシステムバスである。

次に、本発明を利用するクライアントがサーバから提供されるコンテンツに対応したアプリケーションを起動する手順を説明する。まず、図２に本実施形態におけるネットワーク構成図を示す。

サーバ２０１は図１で説明したサーバ装置である。外部ストレージ２０２は記憶部１０４に相当し、クライアントへ渡すコンテンツ、またはコンテンツを生成するために必要なデータなどが格納されている。

プリンタ２０４は図１で説明したクライアント装置である。プリンタ２０４はネットワーク越しにサーバ２０１へコンテンツの送信を要求し、サーバ２０１がストレージ２０２から取得、又は生成したコンテンツを受け取る。また、サーバ２０１は、ＷＳＤＬファイルの配信も行う。

ＷＳＤＬはＷｅｂ上で公開しているサービスへアクセスするインタフェースの仕様を記述する言語仕様で、Ｗ３Ｃ（非特許文献１参照）により標準化が行われている。

ＷＳＤＬ内では、サービスをアクセスする際の接続先、各サービスの名前、サービスを利用する際のパラメータ及びその結果の型などを記述する事ができる。

本実施形態では、ＷＳＤＬファイルはサーバ毎に同一のパス（http://[サーバ名]/services.wsdl）よりＨＴＴＰプロトコルを介して取得することができる。この場合、クライアントはサーバを利用する前にＷＳＤＬファイルの取得と提供サービスの確認を行う必要がある。

ＷＳＤＬファイルにはサーバ２０１が外部へ公開している各サービスのインタフェース定義が記述されており、サーバ２０１が公開しているサービスに関する情報は全て、即ちその種類一覧が一つのＷＳＤＬファイル中に記述されている。

図３にサーバ２０１が配信するＷＳＤＬファイルの一部を示す。図３ではサービスのインタフェースに与えるデータの型、及び、サービスのインタフェースから得られるデータの型を定義している。

operation要素によりサービスのインタフェースが定義されている。また、子要素であるoutput要素により、メディアタイプ（本実施形態では、ＭＩＭＥメディアタイプ）がimage/svg+xml、application/xhtml+xml、image/jpegのいずれかのコンテンツが取得できる事が分かる。即ち、識別される。

これは、それぞれＳＶＧ画像データ、ＸＨＴＭＬデータ、ＪＰＥＧ画像データである事を意味する。ＷＳＤＬファイルは通常、サブシステムの開発時に取得され、コンテンツを取得する際には利用されないものである。

なお、プリンタ２０４は上記３種類の画像をそれぞれレンダリングできるプログラムを内部に保持している。

図４はプリンタ２０４がサーバ２０１へコンテンツ取得のリクエストを出す際の処理フローを示している。

プリンタ２０４はコンテンツをリクエストするサーバ２０１を決定（ステップＳ４０１）すると、実際にコンテンツ取得要求を発行（ステップＳ４０５）する前にサーバ２０１よりサーバ２０１が提供するサービスに関するＷＳＤＬファイルを取得する。詳しくは、ステップＳ４０２にて、サーバ２０１よりサーバ２０１が提供するサービスに関するＷＳＤＬファイルを取得し（リンク記述取得工程、及び提供可能データ種類取得工程）、サーバ２０１が提供するサービスのインタフェースを確認する。

ステップＳ４０２の結果、図３に示すＷＳＤＬファイルが取得できるので、output要素より取得可能な３種類のメディアタイプを認識する（ステップＳ４０３）。さらに、ＳＶＧ画像ビューア、ＸＨＴＭＬビューア、ＪＰＥＧ画像ビューアの３種類のサブシステムの起動を開始する（ステップＳ４０４、サブシステム起動工程）。

この処理により、プリンタ２０４がサーバ２０１に対するリクエストの内容を決定するまでの間に余ってしまう計算資源をサブシステムの起動に割り当てる事ができる。

なお、ＷＳＤＬファイルは一般的なキャッシュアルゴリズムなどを利用し、以前に取得していたＷＳＤＬファイルを再利用しても良い。ＷＳＤＬファイルをキャッシュする事で、ＷＳＤＬファイルの解析を終了するまでの待ち時間を更に短くする事ができる。

続いてコンテンツのリクエスト発行処理（ステップＳ４０５）を行うが、これは各サブシステム起動の完了を待つ事なく実行する。この事により、コンテンツ取得までの待ち時間に余ってしまう計算資源をサブシステムの起動に割り当てる事ができる。

以降、コンテンツの受信（ステップＳ４０６、データ取得工程）し、メディアタイプの識別（ステップＳ４０７、データ種類識別工程）は通常のコンテンツ取得処理と同様に行う。最後に取得したコンテンツのメディアタイプに対応したビューアサブシステムを利用し（データ受け渡し工程）、コンテンツを表示する（データ処理工程）。サブシステムの起動が完了していない場合、起動の完了（起動済み）を待ってコンテンツを表示する事になる。

以上の処理により、従来コンテンツ取得後に必要になっていたサブシステムの起動時間をコンテンツ取得前に割り当て、コンテンツ取得後の待ち時間を短くする事が可能となる。即ち、データ受信終了からサブシステムによるデータの処理開始までの時間を短縮する。

（第２の実施の形態）
第２の実施の形態では、本発明を利用するクライアントが複数のサーバからコンテンツの提供を受ける手順を説明する。図５に本実施形態におけるネットワーク構成図を示す。

本実施形態では、第１の実施形態に加え、サーバ２台（５１１，５２１）と、追加された各サーバに対し外部ストレージが各1台（５１２、５２２）追加されている。本実施形態における各サーバ（２０１、５１１、５２１）に対するコンテンツリクエスト時のフォーマットは統一されているが、それにより得られるコンテンツのメディアタイプはそれぞれのサーバで異なっている。各サーバが提供可能なメディアタイプは、第１の実施形態と同様にＷＳＤＬファイルにより定義され、クライアントへ提供される。なお、サーバ５１１、５２１の構成は、図１で説明したものと同様である。

各サーバ２０１、５１１、５２１の定義しているＷＳＤＬファイルをそれぞれ図３、図６、図７に示す。サーバ２０１からは第１の実施形態と同様、ＳＶＧ画像データ、ＸＨＴＭＬデータ、ＪＰＥＧ画像データを取得する事ができる。

サーバ５１１からは図６で定義されるようにapplication/xhtml+xml、又はimage/jpegのメディアタイプを持つコンテンツが取得でき、これはＸＨＴＭＬデータとＪＰＥＧ画像データが取得できることを意味する。

また、サーバ５２１からは図７で定義されるようにapplication/pdf、image/jpegの２種類のメディアタイプを持つコンテンツが取得でき、これはＰＤＦドキュメントデータ、ＪＰＥＧ画像データが取得できることを意味する。

図８は本実施形態におけるプリンタ２０４が各サーバ２０１、５１１、５２１へコンテンツ取得のリクエストを出す際の処理フローを示している。以下、図８を用い、プリンタ２０４が各サーバへコンテンツ取得のリクエストを出すプロセスを説明する。

本実形態では、プリンタ２０４が各サーバをサーバ２０１、サーバ５１１、サーバ５２１の順でアクセスする。

まず、プリンタ２０４がサーバ２０１を接続対象とすると（ステップＳ４０１）、第１の実施形態と同様ＷＳＤＬファイルを取得（ステップＳ４０２）し、予想されるコンテンツのメディアタイプの情報を取得する（ステップＳ４０３）。

次に、現在起動中のサブシステムから不要となったものを終了する処理（ステップＳ８０１）を行うが、現時点では何も起動していないので次のステップへ進む。

更に必要となるサブシステムのうち起動していないものを起動する処理を行う。ここで、現在はサブシステムが一つも起動していないため、第１の実施形態と同様、ＳＶＧ画像ビューア、ＸＨＴＭＬビューア、ＪＰＥＧ画像ビューアの３種類のサブシステムを起動する（ステップＳ８０２）。

以降の処理は第２の実施形態と同様、コンテンツを実際に取得し（ステップＳ４０５、４０６）、メディアタイプに対応したサブシステムを用いてコンテンツを表示させる（ステップＳ４０７、Ｓ４０８）。

次に、プリンタ２０４がサーバ５１１へ接続対象を変更すると（ステップＳ４０１）、サーバ５１１からＷＳＤＬファイルの取得し（ステップＳ４０２）、予想されるコンテンツのメディアタイプの情報を識別する（ステップＳ４０３）。

サーバ５１１からは、図６で定義されるＷＳＤＬファイルを取得できるので、予想されるコンテンツはＸＨＴＭＬデータとＪＰＥＧ画像である事が分かる。

次に、ステップＳ８０１では、不要となったサブシステムの終了処理を行う。現在起動しているサブシステムはＳＶＧ画像ビューア、ＸＨＴＭＬビューア、ＪＰＥＧ画像ビューアの３つのサブシステムだが、そのうち次に必要なサブシステムはＸＨＴＭＬビューアとＪＰＥＧ画像ビューアのみとなる。そのため、このステップで不要となったＳＶＧ画像ビューアを終了し、機器の資源を解放する。

一方、ステップＳ８０２では、新たに必要となるサブシステムがないため、サブシステムの起動は行わない。以降、他の場合と同様にコンテンツの取得（ステップＳ４０５、４０６）と表示（ステップＳ４０７，Ｓ４０８）を行う。

以上の処理を行うことで、コンテンツ処理の高速化に効果のないサブシステムを適宜終了させ、プリンタ２０４の資源を節約する事が可能となる。

最後に、プリンタ２０４がサーバ５２１への接続対象の変更（ステップＳ４０１）と、メディアタイプの識別（ステップＳ４０２、４０３）を行うと、図７の定義よりＰＤＦドキュメントデータ、ＪＰＥＧ画像データが予想される事が分かる。

現在起動しているサブシステムはＸＨＴＭＬビューア、ＪＰＥＧ画像ビューアなので、不要になったＸＨＴＭＬビューアを終了し（ステップＳ８０１）、新たに必要となるＰＤＦビューアを起動する（ステップＳ８０２）。

以降、同様にコンテンツの取得（ステップＳ４０５、Ｓ４０６）と表示（ステップＳ４０７，Ｓ４０８）を行う。以上の処理を行うことで、高速化のために新たに必要となるアプリのみを適宜選択して起動させておく事が可能となる。

なお、第１の実施形態、第２の実施の形態で用いたメディアタイプの記述方法は、ＸＭＬ名前空間（Ｎａｍｅｓｐａｃｅ ｉｎ ＸＭＬ）を用いてもよい。図９に実際の記述例を示す。

図９では図３等とは異なり、output要素の子要素として独自仕様であるns:content要素を持たせる。

ns:content要素の属性としてuri属性が定義されており、属性値として記述されているURIからコンテンツの種類を識別する事ができる。

図９では、ＳＶＧの名前空間として定義されている http://www.w3.org/2000/svg と、ＸＨＴＭＬの名前空間として定義されている http://www.w3.org/1999/xhtml がuri属性の属性値として記述されている。これにより、ここからコンテンツの種類を識別することができる。

また、メディアタイプの記述方法は、ＷＳＤＬに限定されない。ＸＨＴＭＬ内に記述した例を図１０に示す。図１０ではＸＨＴＭＬにおけるリンク要素 a に対し、独自仕様であるns:type属性を追加している。

ns:type属性の属性値にはリンク先より取得できるコンテンツのメディアタイプが列挙されている。図１０では、ＪＰＥＧ画像データとＳＶＧ画像データが取得できる事が分かる。

Ｗｅｂブラウザが取得したＸＨＴＭＬデータにこのようなns:type属性があった場合、Ｗｅｂブラウザは実際にコンテンツ取得のリクエストを発行する前に、ＪＰＥＧ画像データをレンダリングできるプラグイン、ＳＶＧ画像データをレンダリングできるプラグインをそれぞれ起動しておく。

以上の処理を行うことでコンテンツ取得後のプラグイン起動プロセスが不要となり、ユーザが実際にリンク先のコンテンツ取得をリクエストしてから実際にデータを表示させるまでの時間を短縮する事が可能となる。

なお、本発明は、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を用いても良い。この場合には記憶媒体をシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによって本発明の目的が達成される。

この場合、記憶媒体から読み出されたプログラムコード自体が上述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。

また、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（基本システム或いはオペレーティングシステム）等が実際の処理の一部又は全部を行う場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれてもよい。この場合には、書き込まれたプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行ってもよい。

本発明の実施の形態に係る機器内部の構成を示すブロック図である。 本発明の第１の実施の形態に係るネットワーク構成図である。 本発明の実施の形態に係るサーバの提供するＷＳＤＬファイルの一例を示す図である。 本発明の第１の実施の形態に係るプリンタの処理のフローチャートである。 本発明の第２の実施の形態に係るネットワーク構成図である。 本発明の第２の実施の形態に係るサーバの提供するＷＳＤＬファイルの一例を示す図である。 本発明の第２の実施の形態に係るサーバの提供するＷＳＤＬファイルの一例を示す図である。 本発明の第２の実施の形態に係るプリンタの処理のフローチャートである。 本発明の実施の形態に係るサーバの提供するＷＳＤＬファイルの一例を示す図である。 本発明の実施の形態に係るサーバの提供するＸＨＴＭＬファイルの一例を示す図である。

符号の説明

１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ 記憶部
１０５ 操作部
１０６ 表示部
１０７ ネットワークインタフェース
１０８ システムバス
２０１ サーバ
２０２ 外部ストレージ
２０３ ＬＡＮ
２０４ プリンタ
５１１ サーバ
５１２ 外部ストレージ
５２１ サーバ
５２２ 外部ストレージ

Claims (7)

1. サーバが公開しているサービスへのリンクと共に各サービスが提供するコンテンツの種類を記述したリンク記述を取得するリンク記述取得工程と、
   前記リンク記述より前記サーバから得られる提供するコンテンツの種類一覧を示す提供可能データを生成する提供可能データ種類取得工程と、
   データ取得前に必要なサブシステムの起動を開始するサブシステム起動工程と、
   ネットワークを介して前記サーバよりデータを取得するデータ取得工程と、
   前記取得したデータの種類を識別するデータ種類識別工程と、
   前記データ取得工程により取得した前記データを、前記サブシステム起動工程において起動済みの前記サブシステムへ渡すデータ受け渡し工程と、
   前記データの種類に関連付けられたサブシステムにより前記取得したデータを処理するデータ処理工程とを有し、
   前記データ受信終了からサブシステムによるデータの処理開始までの時間を短縮することを特徴とする情報処理方法。
2. 前記提供可能データは、ＷＳＤＬで記述することを特徴とする請求項１に記載の情報処理方法。
3. 前記提供可能データは、ＸＨＴＭＬで記述することを特徴とする請求項１に記載の情報処理方法。
4. 前記データ種類取得工程は、ＭＩＭＥメディアタイプによりデータの種類を識別することを特徴とする請求項１に記載の情報処理方法。
5. 前記データ種類取得工程は、ＸＭＬ名前空間（Ｎａｍｅｓｐａｃｅ ｉｎ ＸＭＬ）によりデータの種類を識別することを特徴とする請求項１に記載の情報処理方法。
6. ネットワークを介してサーバよりデータを取得するデータ取得手段と、
   前記取得したデータの種類を識別するデータ種類識別手段と、
   前記データの種類に関連付けられたサブシステムにより前記取得したデータを処理するデータ処理手段と、
   前記サーバが公開しているサービスへのリンクと共に各サービスが提供するコンテンツの種類を記述したリンク記述を取得するリンク記述取得手段と、
   前記リンク記述より前記サーバから得られる提供するコンテンツの種類一覧を生成する提供可能データ種類取得手段と、
   データ取得前に必要なサブシステムの起動を開始するサブシステム起動手段と、
   前記データ取得装置により取得した前記データを、前記サブシステム起動装置において起動済みの前記サブシステムへ渡すデータ受け渡し手段とを備え、
   前記データ受信終了からサブシステムによるデータの処理開始までの時間を短縮することを特徴とする情報処理装置。
7. サーバが公開しているサービスへのリンクと共に各サービスが提供するコンテンツの種類を記述したリンク記述を取得するリンク記述取得ステップと、
   前記リンク記述より前記サーバから得られる提供するコンテンツの種類一覧を生成する提供可能データ種類取得ステップと、
   データ取得前に必要なサブシステムの起動を開始するサブシステム起動ステップと、
   ネットワークを介して前記サーバよりデータを取得するデータ取得ステップと、
   前記取得したデータの種類を識別するデータ種類識別ステップと、
   前記データ取得ステップで取得した前記データを、前記サブシステム起動ステップにおいて起動済みの前記サブシステムへ渡すデータ受け渡しステップと、
   前記データの種類に関連付けられたサブシステムにより前記取得したデータを処理するデータ処理ステップとをコンピュータに実行させて、前記データ受信終了からサブシステムによるデータの処理開始までの時間を短縮することを特徴とするコンピュータプログラム。

Images