JP4752137B2 - 入力データの変換方法、入力データの変換プログラム、および入力データの変換システム - Google Patents
入力データの変換方法、入力データの変換プログラム、および入力データの変換システム Download PDFInfo
- Publication number
- JP4752137B2 JP4752137B2 JP2001158607A JP2001158607A JP4752137B2 JP 4752137 B2 JP4752137 B2 JP 4752137B2 JP 2001158607 A JP2001158607 A JP 2001158607A JP 2001158607 A JP2001158607 A JP 2001158607A JP 4752137 B2 JP4752137 B2 JP 4752137B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- module
- data conversion
- input
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
- G06F16/258—Data format conversion from or to a database
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、多様な形式のメディアデータの処理が可能な入力データの動的変換方法、入力データの動的変換プログラム、および入力データの動的変換システムに関する。
【０００２】
【従来の技術】
コンピュータを利用したデータの通信形態、データの保存形態が多様化し、また、データの種類がマルチメディア化してくると、データの受信側、復号側においてデータ変換（デコード）の柔軟性が必要になってくる。例えば、入力データが、「.zip」の拡張子で表される圧縮データの場合には、データの受信側においては、「.zip」の形式の圧縮ファイルを展開するためのデータ変換モジュール（プログラム）が必要になる。また、例えば、特定の形式で暗号化されている入力データを復号化する時には、データの受信側においては、その特定形式に対応した復号化のためのデータ変換モジュールが必要になる。この場合、多くの閉じたシステムでは、入力データを固定のデータ変換形式に設計することが可能であるために、受信側においては、そのデータ変換形式に対応する特定のデータ変換モジュールだけを用意しておけばよい。しかし、インターネット等のオープン状態のシステムや、複数種類のデータ変換形式を扱うシステムでは、データ変換モジュールを固定しておくと、入力されてくる全てのデータに対応できなくなってしまう。
【０００３】
そこで、従来は、次の（Ａ）または（Ｂ）の方式が採用されていた。
【０００４】
（Ａ）図１１に示すシステムでは、入力デバイスからの入力データを、入力モジュール５０に入力し、さらにその出力をデータ変換モジュール５１に入力し、さらにその出力を出力モジュール５２に入力して、この出力モジュール５２から出力デバイスに対してデータを出力する。
【０００５】
各モジュールは、後から自由に組み込むことのできるプラグインモジュールである。入力モジュール５０は、指定した入力デバイスから入力データを取り込み、データ変換モジュール５１は、入力モジュール５１からの入力データを所定のデータ変換形式に変換する。また、出力モジュール５２は、データ変換されたデータを指定した出力デバイスに対して出力する。通常、各モジュールはパイプライン接続され、各モジュールでのデータ処理が並列的に行われるようにして、入力データのストリーミング処理が可能となっている。
【０００６】
以上の構成において、入力データのファイルが多重化されていない場合、すなわち、一度だけのデータ変換（エンコード）によって、目的の出力データが得られるファイルの場合、たとえばデータが特定の形式で圧縮されているだけの入力データの場合は、データ変換モジュール５１は、入力データを伸長するための１つのデータ変換モジュールからなる。また、入力データが２重にエンコードされた多重ファイルとなっている場合、たとえば、データが圧縮されてさらに暗号化されている場合には、データ変換モジュール５１は暗号化データを復号化するためのデータ変換モジュールと、圧縮データを伸張するためのデータ変換モジュールとの２つからなる。このように、入力デバイスから入力されるデータの種類に応じて、すなわち、エンコードされた数と各エンコードの形態に対応するデータ変換モジュール５１をプラグインモジュールとして任意に組み込むことにより、任意の入力データに対してデータ変換（デコード）を実現することが可能である。
【０００７】
（Ｂ）図１２は、「特開２０００−２３６３８６号」に示されるシステムの構成図である。変換前のソースデータは、方式変換制御器６０によって、そのソースデータ内に含まれている宛て先データフォーマットを読み取られ、そのフォーマットにデータ変換するために必要なストリーミング変換モジュール６１〜６３が選択され、且つそれらが最適に配列される。ソースデータであるストリーミングデータはこの配列された変換モジュールにより、パイプライン制御によってデータ変換（デコード）される。
【０００８】
【発明が解決しようとする課題】
上記（Ａ）のシステムでは、データ処理を行うパイプラインの処理ステージ（プラグインモジュール）が一旦設定された段数に固定されるために、データ処理の柔軟性に欠ける問題がある。すなわち、図１１のデータ変換モジュール５１を一旦、決めてしまうと、その入力データ形式と出力データ形式が決まってしまうため、他の形式の入力データが入力したときには正しくデータ変換（デコード）することが出来ない。また上記（Ａ）（Ｂ）のシステムとも、実行時でないと出力データ形式が判明しない入力データに対しては対応することができない問題がある。実行時でないと出力データ形式が判明しない入力データとは、データを複数の変換形式で多重にエンコードして多重ファイルとし、且つその変換形式が事前に分かっていない入力データをいう。このような入力データでは、そのデータのデータ変換を実際に実行しなければ、少なくとも最初にエンコードしたときのデータ変換形式を知ることができない。したがって、データ変換の実行前では、たとえば図１１においては、どうような変換モジュール５１を配置してよいか分からず、また図１２では、どのようなストリーミング変換モジュールを選択していいかを判断することができない。
【０００９】
本発明の目的は、データ変換実行時でないと出力データ形式が判明しないような入力データに動的に対応する入力データの変換方法、入力データの変換プログラム、および入力データの変換システムを提供することにある。
【００１０】
【課題を解決するための手段】
本発明に係る入力データの変換方法は、エンコードされたデータをデコードするデータ処理装置で実行する入力データの変換方法において、データが複数の変換方式でｎ（ｎは２以上の整数）回エンコードされたファイルである入力データの出力データ形式を判定し、前記形式に基づいて、前記ファイルのデコードに必要なデータ変換モジュールを選択するステップと、ｎ回エンコードされたファイルのデコードに必要なデータ変換モジュールが、前記ファイルのヘッダを参照して、（ｎ−１）回エンコードされたファイルの出力データ形式を判定する第１ステップと、モジュールマネージャーが前記形式に基づいて、（ｎ−１）回エンコードされたファイルのデコードに必要なデータ変換モジュールを選択する第２ステップと、前記第１及び第２ステップを順次ｎ回繰り返すステップと、選択された全データ変換モジュールを、選択された順に結合する結合ステップと、前記データ変換モジュールが結合されてなるデータ変換モジュール群で入力データの変換処理を実行するステップとを実行することを特徴とする。
【００１４】
本発明では、データボディの変換（デコード）処理は行わない。多重ファイルの極く一部のデータであるヘッダのみを参照して各ファイルの出力データ形式を判定し、該形式への変換に必要なデータ変換モジュールを選択する。このため、データ変換を実行するまでに、データ変換（デコート）に必要なすべてのデータ変換モジュールを選択することが出来る。そして、これらの選択されたデータ変換モジュールを選択された順に結合する。このようにして結合したデータ変換モジュール群に対し、入力データの変換処理を実行する。したがって、たとえば、拡張子「.zip」の圧縮ファイルを、さらに拡張子「.mrm」の暗号化ファイル（「.mrm」は特定の暗号化拡張子）として２重のファイルとした入力データをデータ変換処理する場合、本発明では、最初に出力データ形式が「.mrm」であることを判定して、そのデータ変換形式に対応するデータ変換モジュールを選択し、次に、出力データ形式が「.zip」であることを判定して、そのデータ変換形式に対応するデータ変換モジュールを選択し、この選択した順にそれらのデータ変換モジュールを結合する。同様に、たとえば、上記の拡張子「.mrm」のファイルを、さらに、暗号化して３重のファイルとした場合には、その暗号化のデータ変換形式に対応するデータ変換モジュールを最初の位置に結合する。
【００１５】
このように、本発明では、データを複数の変換形式で多重にエンコードして多重ファイルとした入力データに対し、各ファイルのヘッダの出力データ形式を次々と読み込んでいって、その入力データを最終の出力データに変換するまでに必要なデータ変換モジュールを自動的に選択して結合することができる。これにより、入力データに対応して、動的にデータ変換モジュールを結合することができる。
【００１６】
また、本発明では、上記選択可能な全てのデータ変換モジュール群をあらかじめ定義しておき、この中から必要なデータ変換モジュールを選択する。このようにしておけば、あらかじめ、多数のデータ変換モジュールをプラグインファイルとして用意しておき、その中から自動的にデータ変換に必要なデータ変換モジュールが選択されるようになる。
【００１７】
また、本発明では、上記のようにして結合されたデータ変換モジュールの入力側に入力モジュールを結合し、出力側に出力モジュールを結合する。入力モジュールは、入力デバイスから入力データを入力する。また、入力データのＵＲＬ（Uniform Resource Locator) や、通信の際のプロトコルのレスポンスヘッダを参照して（例えば、ＨＴＴＰプロトコルにおけるレスポンドヘッダ中のコンテンツタイプヘッダを参照する）ファイルの出力データ形式を判定する。また、出力モジュールは、結合されているモジュール分の最後段にあるデータ変換モジュールに結合して、最終の変換後のデータを出力する。さらに、各モジュールを管理するモジュールマネージャーに対して、この出力マネージャーが終端であることを通知する。
【００１８】
本発明によれば、入力モジュールを結合することによって、入力データを取り込むための入力デバイスを任意のデバイスから選択することができる。たとえば、ローカルファイル（コンピュータ内のファイルシステムに存在するファイル）をソースとして指定することもできるし、ＵＲＬによって、インターネットからダウンロード可能なファイルをソースとして指定することもできる。また、出力モジュールを結合することによって、出力デバイス適合するデータを出力することが可能になる。
【００１９】
【発明の実施の形態】
図１は、本発明に係る入力データの動的変換方法が実施されるデータ処理装置の構成図である。このデータ処理装置は、たとえば、パーソナルコンピュータ、携帯電話などの携帯型データ処理装置からなり、データ変換の対象となる入力データは、動画、静止画、音声、文字などの多様なメディアデータを含むことが可能である。データ処理装置本体１は、データ処理を行うＣＰＵ１０、メインメモリ１１、ビデオコントローラ１２、ネットワークコントローラ１３、オーディオコントローラ１４、ローカルストレージ１５、Ｉ／Ｏデバイス１６を含んでいる。メインメモリ１１には、本発明に係る入力データの動的変換プログラムが搭載される。ビデオコントローラ１２には，ディスプレイモニタ２が接続され、入力データを処理した結果としての画像データを表示したり、ユーザとのインターフェイスをすることができる。ネットワークコントローラ１３には、インターネットなどのネットワーク３が接続されている。オーディオコントローラ１４には、スピーカー４が接続され、入力データを処理した結果としての音声データを出力することができる。Ｉ／Ｏデバイス１６には、キーボード、マウスなどを含むユーザインターフェイス５が接続されている。
【００２０】
上記メインメモリ１１に記憶される入力データの動的変換プログラムは、ＨＤＤ等のローカルストレージ１５に保存しておくことが可能であり、ネットワーク３を介して、任意のリソースからも取得することが可能である。また、ＣＤ−ＲＯＭやフロッピィ（Ｒ）ディスクなどの任意の記憶媒体を介して取得することも可能である。このデータ処理装置では、ネットワーク３を介して取得可能な入力データファイル、または、ローカルストレージ１５に記憶されているローカルファイルをソースとして、これを上記の動的変換プログラムによって動的にデータ変換処理する。そして、その処理の結果をディスプレイ２に映像、文字などとして出力し、または、スピーカー４に音声として出力する。後述のように、動的変換プログラムによるデータ変換モジュールの選択と結合は一瞬で行うことが出来、その後は、データ変換処理がストリーミング処理される。
【００２１】
図２は、上記入力データの動的変換プログラムを構成するモジュール（単位プログラム）群を示している。
【００２２】
このモジュール群は、アプリケーションモジュール２０、単位処理モジュールマネージャー（以下、モジュールマネージャーという）２１、一つ以上の単位処理モジュール（以下、モジュールという）２２とで構成される。アプリケーションモジュール２０は、ユーザとのインターフェイスを行うユーザインターフェイスモジュールを含み、また、特定の入力データファイルのデータ変換処理を行うことをモジュールマネージャー２１に対して通知する。このアプリケーションモジュールは、たとえば、Windows(R) 98 などのＯＳにおいては、拡張子が「.exe」の実行モジュールとして表現される。
【００２３】
モジュールマネージャー２１は、モジュール２２を管理する。具体的には、プラグインモジュールとしてあらかじめ用意されている複数のモジュール２２の情報、すなわち、各モジュールが処理可能なデータ変換形式（入力データと出力データの各々のデータ形式）を収集してリスト上に各モジュールを定義し、アプリケーションモジュール２０で指定された入力データファイルをデータ変換( デコード) するために必要なモジュール２２を結合する。なお、この実施形態では、結合されたモジュール２２は、図３に示すように順次結合されてパイプラインとして構築され、入力データファイルのパイプライン処理が可能となっている。図３に示す例では、モジュール２２内の入力モジュール３０がまず選択され、次いで、この後段に第１番目のデータ変換モジュール３１が結合され、次いで、この後段に第２番目のデータ変換モジュール３２が結合され、次いで、この後段に第３番目のデータ変換モジュール３３が結合され、最後に出力モジュール３４が結合される。このようにしてパイプラインが構築されると、次に、入力データが入力モジュール３０に入力されて入力データのデータ変換（デコード）処理が行われる。このとき、パイプラインにより、実時間でストリーミング変換処理を行うことができる。
【００２４】
なお、上記モジュールマネージャー２１は、ＯＳとしてWindows( R) 98などを採用した場合に、拡張子「.dll」のモジュールとして表現され、モジュール２２は、プラグインフォルダーに拡張子「.dll」のモジュールとして格納される。
【００２５】
図４は、入力データの構成例を示している。図に示すように、入力データファイルは、3 重の多重ファイルとなっている。ファイルＦ３は、元のデータであり、ファイルＦ２はＦ３のエンコードファイル、ファイルＦ１はＦ２のエンコードファイルである。各ファイルのヘッダ（Ａ１、Ａ２、Ａ３）に、そのファイルをデコードしたときの出力データ形式が記憶されている。例えば、ファイルＦ１のヘッダＡ１には、ファイルＦ２の出力データ形式が記憶され、ファイルＦ２のヘッダＡ２には、ファイルＦ３の出力データ形式が記憶されている。同図に示す入力データをデータ変換（デコード）処理するには、図３に示すように、入力モジュール３０、出力モジュール３４と、その間に結合される３つのデータ変換モジュール３１〜３３が必要である。最初のデータ変換モジュール３１は、入力モジュールにより通知された出力データ形式によるデータ変換処理を行い、２番目のデータ変換モジュール３２は、ヘッダＡ１に記憶されている出力データ形式によるデータ変換処理を行い、３番目のデータ変換モジュール３３は、ヘッダＡ２に記憶されている出力データ形式のデータ変換処理を行う。なお、ヘッダＡ３に記憶されている情報は、ファイルＦ３に固有なものであってデータボディの実質的な変換処理は行われない。そして、実際のデータ変換処理を行う前に、各ヘッダＡ１〜Ａ３に記憶されている出力データ形式が読み取られて、図３に示すようなパイプラインが構築される。パイプラインが構築されると、入力データは入力モジュール３０に読み込まれて、ストリーム処理が行われていく。
【００２６】
上記のように、モジュール２２の選択と結合は、入力モジュール３０と出力モジュール３４間に入力データをデータ変換（デコード）するのに必要な複数のデータ変換モジュールを選択して結合することである。これを図示すると図５のようになる。
【００２７】
まず、ソースとなる入力データをネットワーク３またはローカルストレージ１５のどちらから取得するかを設定して入力データが適正に入力させるようにする入力モジュール３０を選択する。次に、この入力モジュール３０によって入力データのＵＲＬやＨＴＴＰプロトコルにおけるレスポンスヘッダ中のコンテンツタイプヘッダを参照して出力データ形式を判定し、これをモジュールマネージャー２１に通知する。モジュールマネージャー２１は、この最外郭のファイルの出力データ形式を判定すると、その変換に必要な最初のデータ変換モジュール３１をプラグインフォルダーの中に記憶されている複数のデータ変換モジュール群から選択する。且つ、その選択したデータ変換モジュールを入力モジュール３０に結合する。次に、データ変換モジュール３１は、入力データのファイルのヘッダＡ１に記憶されている出力データ形式を判定し、この出力データ形式をモジュールマネージャー２１に通知する。モジュールマネージャー２１は、この出力データ形式を判定して、そのデータ変換に必要なデータ変換モジュール３２をプラグインフォルダーの中に記憶されているデータ変換モジュール群から選択し、且つ、データ変換モジュール３１の末尾に結合する。さらに同様にして、データ変換モジュール３２の末尾にデータ変換モジュール３３を結合し、最後に、出力デバイスに対してデータを出力するための出力モジュール３４をデータ変換モジュール３３に結合する。そして、このようにして結合したパイプラインに対し、モジュールマネージャー２１は、入力データの入力を開始し、データ変換（デコード）を実行する。
【００２８】
次に、具体的な例について、図６〜図８を参照して説明する。
【００２９】
図６は、入力データの形式例である。この例では、入力データが3 重ファイルとなっている。元のデータのエンコード順は、拡張子「.zip」による圧縮と、「.mrm」による暗号化の順である。元のデータはＭＩＤＩデータである。したがって、この多重ファイルは、ＭＩＤＩファイルＦ３と、圧縮ファイルＦ２と暗号化ファイルＦ１を多重化したものである。
【００３０】
暗号化ファイルＦ１のヘッダＡ１には、出力データ形式として拡張子「.zip」が指定されている。また、圧縮ファイルＦ２のヘッダＡ２には、出力データ形式として拡張子「.mid」が指定されている。また、ＭＩＤＩファイルＦ３のヘッダＡ３には、ＭＩＤＩフォーマットに関する情報が指定されている。なお、ＭＩＤＩファイルＦ３はＭＩＤＩデータであるために、他のフォーマットにデータ変換する必要は本来ないが、本実施形態では、ＭＩＤＩファイルをより扱い易い内部独自フォーマットに変換し、最終段である出力モジュールに渡すようにしている関係上、その内部独自フォーマットの出力データ形式をモジュールマネージャーに対して通知している。
【００３１】
図７は、各モジュールからモジュールマネージャーに対して出力データ形式を通知したり、モジュールマネージャーから各モジュールに対して動作指定を行う時に使う通知データ形式を示している。図７に示すように、この通知データ形式は、領域１〜領域５を備えており、領域１から順に、「タグ」、「ＵＲＬ」、「ＭＩＭＥ」、「ＥＸＴ」、「付加情報」を記憶する。「タグ」は、モジュールマネージャーから各モジュールに対する動作の種類を指定する。「ＵＲＬ」は、モジュールマネージャーから入力モジュールに対してＵＲＬを指定する。「ＭＩＭＥ」は、ＭＩＭＥ（Multipurpose Internet Mail Extensions)タイプを指定する。「ＥＸＴ」は拡張子を指定する。「付加情報」は、必要に応じて付ける付加情報を指定する。このうち、「ＭＩＭＥ」と「ＥＸＴ」でモジュールからモジュールマネージャーに対する出力データ形式の通知を行う。なお、出力データ形式は、拡張子「ＥＸＴ」かＭＩＭＥタイプ「ＭＩＭＥ」によって行うことができる。通常、拡張子が指定されている時には、ＭＩＭＥタイプは不要であるが、拡張子は、誤操作によって、または意図的に変更される可能性があるために、ＭＩＭＥタイプの方が信頼性が高いとされる。モジュールマネージャーからは、「タグ」または「ＵＲＬ」が各モジュールに対して通知される。入力モジュールに対しては、「ＵＲＬ」が通知される。この「ＵＲＬ」は、たとえば、「file://c:/test.mrm」であったり、または、「http://...... 」であったりする。前者は、ローカルストレージ１５（図１参照）のファイル格納場所を指定し、後者はネットワーク３に接続されるファイル格納場所を示す。一般に、これらの「file」や「http」あるいは「ftp 」はプロトコルと称され、このプロトコルに「パス」と「ファイル名」が結合されることによって取得ファイルを指定することができる。
【００３２】
図８は、図６に示す入力データに対し、パイプラインを構築するステップを説明する図である。
【００３３】
Ｔ１：モジュールマネージャー２１が、アプリケーションモジュール２０（図２参照）からファイル（入力データ）オープン要求を受信する。
【００３４】
Ｔ２：プロトコルが適合する入力モジュール３０を生成する。ここでは、プロトコルを「file」とする。したがって、入力データ( ファイル) は、ローカルストレージ１５（図１参照）からロードされる。
【００３５】
Ｔ３：モジュールマネージャー２１は、通知データＤ１により、ファイル「test.mrm」を指定して、入力モジュール３０をオープンする。
【００３６】
Ｔ４：入力モジュール３０は、指定されたファイルの拡張子を参照して出力データ形式を判定する。指定されたファイルがコンテンツファイルそのものではなく、ＨＴＴＰプロトコルでコンテンツファイルを送信するためのサーバサイドスクリプトである場合もあるので、拡張子で出力データを特定できない場合にはＨＴＴＰプロトコルにおけるレスポンスヘッダ中のコンテンツタイプヘッダを参照し、出力データ形式を判定する。この場合は、「test.mrm」の拡張子「.mrm」により、出力データ形式が拡張子「.mrm」で表現される暗号化データであることがわかるので、これをモジュールマネージャー２１に通知する。この通知は、通知データＤ２の領域４において行う。
【００３７】
Ｔ５：拡張子「.mrm」の暗号化データをデコード（変換）するためのデータ変換モジュール３１を生成する。
【００３８】
Ｔ６：モジュールマネージャー２１は、生成したデータ変換モジュール３１をパイプラインの末尾に結合する（ここでは、入力マネージャー３０に結合する）。
【００３９】
Ｔ７：モジュールマネージャー２１は、データ変換モジュール３１をオープンする。この動作は、通知データＤ２の領域１によって指定する。
【００４０】
Ｔ８：データ変換モジュール３１がオープンされることによって、パイプラインを介してこのデータ変換モジュール３１にデータの一部が入力される。この時、データ変換モジュール３１は、暗号化ファイルＦ１のヘッダＡ１を参照して、次にデコード（変換）すべき圧縮ファイルＦ２の出力データ形式を判定してモジュールマネージャー２１に通知する。この通知は、通知データＤ３の領域４によって行う。
【００４１】
Ｔ９：モジュールマネージャー２１は、上記Ｔ８で通知された出力データ形式に対応するデータ変換モジュール３２を生成する。この時の出力データ形式は拡張子「.zip」で表現されるものであるから、このデータ変換モジュール３２は、拡張子「.zip」の圧縮データをデコード（変換）するものである。
【００４２】
Ｔ１０：モジュールマネージャー２１は、データ変換モジュール３２をパイプラインの末尾に結合する。ここでは、データ変換モジュール３２はその前段のデータ変換モジュール３１に結合される。
【００４３】
Ｔ１１：データ変換モジュール３２をオープンする。このオープン動作は、通知データＤ３の領域１で指定される。
【００４４】
Ｔ１２：データ変換モジュール３２がオープンされることによって、パイプラインを介してこのデータ変換モジュール３２にデータの一部が入力される。この時、データ変換モジュール３２は、多重化されている入力データの圧縮ファイルＦ２のヘッダＡ２を参照する。ヘッダＡ２にはデータ変換モジュール３２でデコード（変換）した時の出力データ形式が記憶されている。この出力データ形式は、この例では、拡張子「.mid」で表されるＭＩＤＩデータを表す。そして、このデータ変換モジュール３２は、その出力データ形式を通知データＤ４の領域４によってモジュールマネージャー２１に通知する。
【００４５】
Ｔ１３：モジュールマネージャー２１は、上記Ｔ１２での通知を受けると、拡張子「.mid」で表されるＭＩＤＩデータをデコード（変換）するためのデータ変換モジュール３３を生成する。
【００４６】
Ｔ１４：モジュールマネージャー２１は、上記Ｔ１３で生成したデータ変換モジュール３３をパイプラインの末尾に結合する。この例では、データ変換モジュール３３をデータ変換モジュール３２に結合する。
【００４７】
Ｔ１５：モジュールマネージャー２１は、データ変換モジュール３３をオープンする。
【００４８】
Ｔ１６：データ変換モジュール３３がオープンすることによって、入力データの一部がパイプラインを通過してデータ変換モジュール３３に入力される。この時、データ変換モジュール３３は、受け取ったＭＩＤＩファイルをより扱い易い内部独自フォーマットに変換する。ここでは、その出力データ形式は「application/x-midi2 」で表されている。データ変換モジュール３３は、このようにして判定した出力データ形式をモジュールマネージャー２１に通知する。なお、「application/x-midi2 」の出力データ形式は、拡張子ではなくＭＩＭＥタイプによって指定される。したがって、通知データＤ５の領域３を使用してモジュールマネージャー２１に通知される。
【００４９】
Ｔ１７：モジュールマネージャー２１は、上記Ｔ１６の通知を受けると、出力モジュール３４を生成する。
【００５０】
Ｔ１８：モジュールマネージャー２１は、出力モジュール３４をパイプラインの末尾に結合する。ここでは、出力モジュール３４をデータ変換モジュール３３に結合する。
【００５１】
Ｔ１９：モジュールマネージャー２１は、出力モジュール３４をオープンする。このオープン動作は、通知データＤ５の領域１によって行う。
【００５２】
Ｔ２０：出力モジュール３４がオープンされることによって、入力データの一部はパイプラインを通過し、出力モジュール３４において自らがパイプラインの終端位置にあることを判定する。そこで、出力モジュール３４は、モジュールマネージャー２１に対して通知データＤ６の領域１により、自らが終端であることを通知する。
【００５３】
以上のＴ１〜Ｔ２０の処理において、各モジュールが読み込むデータは、多重化された入力データのヘッダのデータだけである。このため、パイプラインの構築に必要な処理時間は、一瞬である。また、この例では、図６に示すように３重に多重化された入力データに対するパイプライン構築を示したが、４重に多重化された入力データであれば、入力モジュール３０と出力モジュール３４間に、データ変換モジュールがもう１つ追加されることになる。このように、本実施形態では、多重化された入力データのエンコードと逆順に各ファイルのヘッダのみを参照して各ファイルの出力データ形式を判定し、該形式への変換（デコード）に必要なデータ変換モジュールを選択してパイプラインを結合していくために、入力データの多重化数やエンコード方式を知らなくても、正しくデコード（変換）するためのパイプラインを動的に構築することができる。なお、パイプラインを構築した後は、入力モジュール３０に入力データが入力され、パイプラインによってストリーミング処理されていく。
【００５４】
図９は、パイプラインによって入力データのデコード（変換）処理が行われていく時の状態を示している。入力モジュール３０に入力された入力データは、データ変換モジュール３１で復号化され、次のデータ変換モジュール３２で伸長され、次のデータ変換モジュール３３で、特定のＭＩＤＩデータに変換され、最後の出力モジュール３４で、出力デバイスに出力される。
【００５５】
なお、図２において、各モジュール２２は、プラグインモジュールとして特定のプラグインフォルダーに収納されている。モジュールマネージャー２１は、パイプラインを構築する前に、このプラグインフォルダー内の各モジュールの情報を収集し、リストを作成して各モジュールを定義しておく。モジュールの定義とは、そのモジュールがどのような処理を行うことができるかなどの機能を判定してリスト上に記憶しておくことである。モジュールマネージャー２１は、事前にこのようにして定義したデータ変換モジュール群の中から適切なものを選択し、パイプライン構築のために生成する。ここで言う生成とは、オブジェクト指向言語において、クラスの実体（インスタンス）を生成するという意味合いである。たとえば、入力モジュール３０を生成するとは、メモリ上に入力モジュール３０の実体が生成されることをいう。
【００５６】
図１０は、本実施形態によって、パイプラインを構築するための手順を示すフローチャートである。
【００５７】
ステップＳＴ１において、モジュールマネージャー２１は、プラグインフォルダーに置かれている全てのモジュールの情報を収集する。ＳＴ２では、モジュールマネージャー２１が、アプリケーションモジュール２０からファイル（入力データ）のオープン要求を受信する。モジュールマネージャー２１は、要求されたプロトコルに適合する入力モジュール３０をオープンしパイプラインの先頭に追加する（ＳＴ３）。さらに、モジュールマネージャー２１は、ＳＴ４において入力モジュール３０をオープンする。
【００５８】
オープンした入力モジュール３０は、最外郭のファイルの出力データ形式をＵＲＬやＨＴＴＰプロトコルにおけるレスポンスヘッダ中のコンテンツタプヘッダから判定してモジュールマネージャー２１に通知する。モジュールマネージャー２１は、この通知を受けて出力データ形式を得るとともに（ＳＴ５）、パイプラインの終端でないことを判定して（ＳＴ６）、出力データ形式に適合するモジュール（データ変換モジュールか出力モジュール）を生成し、パイプラインの末尾に追加する（ＳＴ７）。また、そのモジュールをオープンして（ＳＴ８）、ＳＴ５に戻る。モジュールマネージャー２１は、パイプラインの終端であることを知ると、それ以後のパイプライン構築動作を停止し、以下、続いてデータボディのデコード（変換）処理が行われる。
【００５９】
以上の処理において、ＳＴ１〜ＳＴ８のパイプライン構築動作は、ヘッダのデータのみで処理される。したがって、入力データ全体を全て受け取っていなくても、入力データを正しく変換（デコード）するのに必要で十分なパイプラインの構築が出来る。そして、パイプラインによるデータボディの変換処理はストリーミングにより可能である。
【００６０】
本実施形態では、多重にエンコードした多重ファイルの入力データに有効であるが、多重でない１回のみエンコードした入力データであっても対応することが可能である。この場合は、入力モジュールと出力モジュール間に１つのデータ変換モジュールが結合されることになる。また、各モジュールをパイプライン接続することによって、入力データのストリーミング処理を可能としたが、各モジュールを単にカスケード（従属）接続して、各段階で１ファイル毎に、順にデコード（変換）処理を行うようにしてもよい。
【００６１】
また、本発明は、複数のデータ変換モジュールの前後に入力モジュールと出力モジュールを結合してパイプラインを構築したが、入力モジュールと出力モジューは必ずしもなくてもよく、これらの機能をデータ変換モジュールに持たせることも可能である。
【００６２】
【発明の効果】
本発明によれば、データ変換（デコード）を実行する時でないと最終出力データ形式が判明しないような入力データ、すなわち、データのエンコード処理が多重化された多重ファイルを扱うことができる。また、データ変換モジュールの段数は固定されずに動的に作成されるために、多様なデータフォーマットに対応することができる。
【図面の簡単な説明】
【図１】本発明の実施形態であるデータ処理装置の構成図
【図２】本発明の実施形態である入力データの動的変換プログラムのモジュール群を示す図
【図３】パイプラインが構築される様子を示す図
【図４】データを複数の変換方式で多重にエンコードして作成した多重ファイルの概念構成図
【図５】パイプラインの構築手順を示す図
【図６】入力データの形式例を示す図
【図７】通知データの形式を示す図
【図８】パイプラインの構築動作を具体的に説明する図
【図９】構築されたパイプラインによって入力データがデコード（変換）処理される状態を示す図
【図１０】パイプライン構築の手順を示すフローチャート
【図１１】従来の入力データ変換システムの概略構成図
【図１２】従来の他の入力データ変換システムの概略構成図
【発明の属する技術分野】
本発明は、多様な形式のメディアデータの処理が可能な入力データの動的変換方法、入力データの動的変換プログラム、および入力データの動的変換システムに関する。
【０００２】
【従来の技術】
コンピュータを利用したデータの通信形態、データの保存形態が多様化し、また、データの種類がマルチメディア化してくると、データの受信側、復号側においてデータ変換（デコード）の柔軟性が必要になってくる。例えば、入力データが、「.zip」の拡張子で表される圧縮データの場合には、データの受信側においては、「.zip」の形式の圧縮ファイルを展開するためのデータ変換モジュール（プログラム）が必要になる。また、例えば、特定の形式で暗号化されている入力データを復号化する時には、データの受信側においては、その特定形式に対応した復号化のためのデータ変換モジュールが必要になる。この場合、多くの閉じたシステムでは、入力データを固定のデータ変換形式に設計することが可能であるために、受信側においては、そのデータ変換形式に対応する特定のデータ変換モジュールだけを用意しておけばよい。しかし、インターネット等のオープン状態のシステムや、複数種類のデータ変換形式を扱うシステムでは、データ変換モジュールを固定しておくと、入力されてくる全てのデータに対応できなくなってしまう。
【０００３】
そこで、従来は、次の（Ａ）または（Ｂ）の方式が採用されていた。
【０００４】
（Ａ）図１１に示すシステムでは、入力デバイスからの入力データを、入力モジュール５０に入力し、さらにその出力をデータ変換モジュール５１に入力し、さらにその出力を出力モジュール５２に入力して、この出力モジュール５２から出力デバイスに対してデータを出力する。
【０００５】
各モジュールは、後から自由に組み込むことのできるプラグインモジュールである。入力モジュール５０は、指定した入力デバイスから入力データを取り込み、データ変換モジュール５１は、入力モジュール５１からの入力データを所定のデータ変換形式に変換する。また、出力モジュール５２は、データ変換されたデータを指定した出力デバイスに対して出力する。通常、各モジュールはパイプライン接続され、各モジュールでのデータ処理が並列的に行われるようにして、入力データのストリーミング処理が可能となっている。
【０００６】
以上の構成において、入力データのファイルが多重化されていない場合、すなわち、一度だけのデータ変換（エンコード）によって、目的の出力データが得られるファイルの場合、たとえばデータが特定の形式で圧縮されているだけの入力データの場合は、データ変換モジュール５１は、入力データを伸長するための１つのデータ変換モジュールからなる。また、入力データが２重にエンコードされた多重ファイルとなっている場合、たとえば、データが圧縮されてさらに暗号化されている場合には、データ変換モジュール５１は暗号化データを復号化するためのデータ変換モジュールと、圧縮データを伸張するためのデータ変換モジュールとの２つからなる。このように、入力デバイスから入力されるデータの種類に応じて、すなわち、エンコードされた数と各エンコードの形態に対応するデータ変換モジュール５１をプラグインモジュールとして任意に組み込むことにより、任意の入力データに対してデータ変換（デコード）を実現することが可能である。
【０００７】
（Ｂ）図１２は、「特開２０００−２３６３８６号」に示されるシステムの構成図である。変換前のソースデータは、方式変換制御器６０によって、そのソースデータ内に含まれている宛て先データフォーマットを読み取られ、そのフォーマットにデータ変換するために必要なストリーミング変換モジュール６１〜６３が選択され、且つそれらが最適に配列される。ソースデータであるストリーミングデータはこの配列された変換モジュールにより、パイプライン制御によってデータ変換（デコード）される。
【０００８】
【発明が解決しようとする課題】
上記（Ａ）のシステムでは、データ処理を行うパイプラインの処理ステージ（プラグインモジュール）が一旦設定された段数に固定されるために、データ処理の柔軟性に欠ける問題がある。すなわち、図１１のデータ変換モジュール５１を一旦、決めてしまうと、その入力データ形式と出力データ形式が決まってしまうため、他の形式の入力データが入力したときには正しくデータ変換（デコード）することが出来ない。また上記（Ａ）（Ｂ）のシステムとも、実行時でないと出力データ形式が判明しない入力データに対しては対応することができない問題がある。実行時でないと出力データ形式が判明しない入力データとは、データを複数の変換形式で多重にエンコードして多重ファイルとし、且つその変換形式が事前に分かっていない入力データをいう。このような入力データでは、そのデータのデータ変換を実際に実行しなければ、少なくとも最初にエンコードしたときのデータ変換形式を知ることができない。したがって、データ変換の実行前では、たとえば図１１においては、どうような変換モジュール５１を配置してよいか分からず、また図１２では、どのようなストリーミング変換モジュールを選択していいかを判断することができない。
【０００９】
本発明の目的は、データ変換実行時でないと出力データ形式が判明しないような入力データに動的に対応する入力データの変換方法、入力データの変換プログラム、および入力データの変換システムを提供することにある。
【００１０】
【課題を解決するための手段】
本発明に係る入力データの変換方法は、エンコードされたデータをデコードするデータ処理装置で実行する入力データの変換方法において、データが複数の変換方式でｎ（ｎは２以上の整数）回エンコードされたファイルである入力データの出力データ形式を判定し、前記形式に基づいて、前記ファイルのデコードに必要なデータ変換モジュールを選択するステップと、ｎ回エンコードされたファイルのデコードに必要なデータ変換モジュールが、前記ファイルのヘッダを参照して、（ｎ−１）回エンコードされたファイルの出力データ形式を判定する第１ステップと、モジュールマネージャーが前記形式に基づいて、（ｎ−１）回エンコードされたファイルのデコードに必要なデータ変換モジュールを選択する第２ステップと、前記第１及び第２ステップを順次ｎ回繰り返すステップと、選択された全データ変換モジュールを、選択された順に結合する結合ステップと、前記データ変換モジュールが結合されてなるデータ変換モジュール群で入力データの変換処理を実行するステップとを実行することを特徴とする。
【００１４】
本発明では、データボディの変換（デコード）処理は行わない。多重ファイルの極く一部のデータであるヘッダのみを参照して各ファイルの出力データ形式を判定し、該形式への変換に必要なデータ変換モジュールを選択する。このため、データ変換を実行するまでに、データ変換（デコート）に必要なすべてのデータ変換モジュールを選択することが出来る。そして、これらの選択されたデータ変換モジュールを選択された順に結合する。このようにして結合したデータ変換モジュール群に対し、入力データの変換処理を実行する。したがって、たとえば、拡張子「.zip」の圧縮ファイルを、さらに拡張子「.mrm」の暗号化ファイル（「.mrm」は特定の暗号化拡張子）として２重のファイルとした入力データをデータ変換処理する場合、本発明では、最初に出力データ形式が「.mrm」であることを判定して、そのデータ変換形式に対応するデータ変換モジュールを選択し、次に、出力データ形式が「.zip」であることを判定して、そのデータ変換形式に対応するデータ変換モジュールを選択し、この選択した順にそれらのデータ変換モジュールを結合する。同様に、たとえば、上記の拡張子「.mrm」のファイルを、さらに、暗号化して３重のファイルとした場合には、その暗号化のデータ変換形式に対応するデータ変換モジュールを最初の位置に結合する。
【００１５】
このように、本発明では、データを複数の変換形式で多重にエンコードして多重ファイルとした入力データに対し、各ファイルのヘッダの出力データ形式を次々と読み込んでいって、その入力データを最終の出力データに変換するまでに必要なデータ変換モジュールを自動的に選択して結合することができる。これにより、入力データに対応して、動的にデータ変換モジュールを結合することができる。
【００１６】
また、本発明では、上記選択可能な全てのデータ変換モジュール群をあらかじめ定義しておき、この中から必要なデータ変換モジュールを選択する。このようにしておけば、あらかじめ、多数のデータ変換モジュールをプラグインファイルとして用意しておき、その中から自動的にデータ変換に必要なデータ変換モジュールが選択されるようになる。
【００１７】
また、本発明では、上記のようにして結合されたデータ変換モジュールの入力側に入力モジュールを結合し、出力側に出力モジュールを結合する。入力モジュールは、入力デバイスから入力データを入力する。また、入力データのＵＲＬ（Uniform Resource Locator) や、通信の際のプロトコルのレスポンスヘッダを参照して（例えば、ＨＴＴＰプロトコルにおけるレスポンドヘッダ中のコンテンツタイプヘッダを参照する）ファイルの出力データ形式を判定する。また、出力モジュールは、結合されているモジュール分の最後段にあるデータ変換モジュールに結合して、最終の変換後のデータを出力する。さらに、各モジュールを管理するモジュールマネージャーに対して、この出力マネージャーが終端であることを通知する。
【００１８】
本発明によれば、入力モジュールを結合することによって、入力データを取り込むための入力デバイスを任意のデバイスから選択することができる。たとえば、ローカルファイル（コンピュータ内のファイルシステムに存在するファイル）をソースとして指定することもできるし、ＵＲＬによって、インターネットからダウンロード可能なファイルをソースとして指定することもできる。また、出力モジュールを結合することによって、出力デバイス適合するデータを出力することが可能になる。
【００１９】
【発明の実施の形態】
図１は、本発明に係る入力データの動的変換方法が実施されるデータ処理装置の構成図である。このデータ処理装置は、たとえば、パーソナルコンピュータ、携帯電話などの携帯型データ処理装置からなり、データ変換の対象となる入力データは、動画、静止画、音声、文字などの多様なメディアデータを含むことが可能である。データ処理装置本体１は、データ処理を行うＣＰＵ１０、メインメモリ１１、ビデオコントローラ１２、ネットワークコントローラ１３、オーディオコントローラ１４、ローカルストレージ１５、Ｉ／Ｏデバイス１６を含んでいる。メインメモリ１１には、本発明に係る入力データの動的変換プログラムが搭載される。ビデオコントローラ１２には，ディスプレイモニタ２が接続され、入力データを処理した結果としての画像データを表示したり、ユーザとのインターフェイスをすることができる。ネットワークコントローラ１３には、インターネットなどのネットワーク３が接続されている。オーディオコントローラ１４には、スピーカー４が接続され、入力データを処理した結果としての音声データを出力することができる。Ｉ／Ｏデバイス１６には、キーボード、マウスなどを含むユーザインターフェイス５が接続されている。
【００２０】
上記メインメモリ１１に記憶される入力データの動的変換プログラムは、ＨＤＤ等のローカルストレージ１５に保存しておくことが可能であり、ネットワーク３を介して、任意のリソースからも取得することが可能である。また、ＣＤ−ＲＯＭやフロッピィ（Ｒ）ディスクなどの任意の記憶媒体を介して取得することも可能である。このデータ処理装置では、ネットワーク３を介して取得可能な入力データファイル、または、ローカルストレージ１５に記憶されているローカルファイルをソースとして、これを上記の動的変換プログラムによって動的にデータ変換処理する。そして、その処理の結果をディスプレイ２に映像、文字などとして出力し、または、スピーカー４に音声として出力する。後述のように、動的変換プログラムによるデータ変換モジュールの選択と結合は一瞬で行うことが出来、その後は、データ変換処理がストリーミング処理される。
【００２１】
図２は、上記入力データの動的変換プログラムを構成するモジュール（単位プログラム）群を示している。
【００２２】
このモジュール群は、アプリケーションモジュール２０、単位処理モジュールマネージャー（以下、モジュールマネージャーという）２１、一つ以上の単位処理モジュール（以下、モジュールという）２２とで構成される。アプリケーションモジュール２０は、ユーザとのインターフェイスを行うユーザインターフェイスモジュールを含み、また、特定の入力データファイルのデータ変換処理を行うことをモジュールマネージャー２１に対して通知する。このアプリケーションモジュールは、たとえば、Windows(R) 98 などのＯＳにおいては、拡張子が「.exe」の実行モジュールとして表現される。
【００２３】
モジュールマネージャー２１は、モジュール２２を管理する。具体的には、プラグインモジュールとしてあらかじめ用意されている複数のモジュール２２の情報、すなわち、各モジュールが処理可能なデータ変換形式（入力データと出力データの各々のデータ形式）を収集してリスト上に各モジュールを定義し、アプリケーションモジュール２０で指定された入力データファイルをデータ変換( デコード) するために必要なモジュール２２を結合する。なお、この実施形態では、結合されたモジュール２２は、図３に示すように順次結合されてパイプラインとして構築され、入力データファイルのパイプライン処理が可能となっている。図３に示す例では、モジュール２２内の入力モジュール３０がまず選択され、次いで、この後段に第１番目のデータ変換モジュール３１が結合され、次いで、この後段に第２番目のデータ変換モジュール３２が結合され、次いで、この後段に第３番目のデータ変換モジュール３３が結合され、最後に出力モジュール３４が結合される。このようにしてパイプラインが構築されると、次に、入力データが入力モジュール３０に入力されて入力データのデータ変換（デコード）処理が行われる。このとき、パイプラインにより、実時間でストリーミング変換処理を行うことができる。
【００２４】
なお、上記モジュールマネージャー２１は、ＯＳとしてWindows( R) 98などを採用した場合に、拡張子「.dll」のモジュールとして表現され、モジュール２２は、プラグインフォルダーに拡張子「.dll」のモジュールとして格納される。
【００２５】
図４は、入力データの構成例を示している。図に示すように、入力データファイルは、3 重の多重ファイルとなっている。ファイルＦ３は、元のデータであり、ファイルＦ２はＦ３のエンコードファイル、ファイルＦ１はＦ２のエンコードファイルである。各ファイルのヘッダ（Ａ１、Ａ２、Ａ３）に、そのファイルをデコードしたときの出力データ形式が記憶されている。例えば、ファイルＦ１のヘッダＡ１には、ファイルＦ２の出力データ形式が記憶され、ファイルＦ２のヘッダＡ２には、ファイルＦ３の出力データ形式が記憶されている。同図に示す入力データをデータ変換（デコード）処理するには、図３に示すように、入力モジュール３０、出力モジュール３４と、その間に結合される３つのデータ変換モジュール３１〜３３が必要である。最初のデータ変換モジュール３１は、入力モジュールにより通知された出力データ形式によるデータ変換処理を行い、２番目のデータ変換モジュール３２は、ヘッダＡ１に記憶されている出力データ形式によるデータ変換処理を行い、３番目のデータ変換モジュール３３は、ヘッダＡ２に記憶されている出力データ形式のデータ変換処理を行う。なお、ヘッダＡ３に記憶されている情報は、ファイルＦ３に固有なものであってデータボディの実質的な変換処理は行われない。そして、実際のデータ変換処理を行う前に、各ヘッダＡ１〜Ａ３に記憶されている出力データ形式が読み取られて、図３に示すようなパイプラインが構築される。パイプラインが構築されると、入力データは入力モジュール３０に読み込まれて、ストリーム処理が行われていく。
【００２６】
上記のように、モジュール２２の選択と結合は、入力モジュール３０と出力モジュール３４間に入力データをデータ変換（デコード）するのに必要な複数のデータ変換モジュールを選択して結合することである。これを図示すると図５のようになる。
【００２７】
まず、ソースとなる入力データをネットワーク３またはローカルストレージ１５のどちらから取得するかを設定して入力データが適正に入力させるようにする入力モジュール３０を選択する。次に、この入力モジュール３０によって入力データのＵＲＬやＨＴＴＰプロトコルにおけるレスポンスヘッダ中のコンテンツタイプヘッダを参照して出力データ形式を判定し、これをモジュールマネージャー２１に通知する。モジュールマネージャー２１は、この最外郭のファイルの出力データ形式を判定すると、その変換に必要な最初のデータ変換モジュール３１をプラグインフォルダーの中に記憶されている複数のデータ変換モジュール群から選択する。且つ、その選択したデータ変換モジュールを入力モジュール３０に結合する。次に、データ変換モジュール３１は、入力データのファイルのヘッダＡ１に記憶されている出力データ形式を判定し、この出力データ形式をモジュールマネージャー２１に通知する。モジュールマネージャー２１は、この出力データ形式を判定して、そのデータ変換に必要なデータ変換モジュール３２をプラグインフォルダーの中に記憶されているデータ変換モジュール群から選択し、且つ、データ変換モジュール３１の末尾に結合する。さらに同様にして、データ変換モジュール３２の末尾にデータ変換モジュール３３を結合し、最後に、出力デバイスに対してデータを出力するための出力モジュール３４をデータ変換モジュール３３に結合する。そして、このようにして結合したパイプラインに対し、モジュールマネージャー２１は、入力データの入力を開始し、データ変換（デコード）を実行する。
【００２８】
次に、具体的な例について、図６〜図８を参照して説明する。
【００２９】
図６は、入力データの形式例である。この例では、入力データが3 重ファイルとなっている。元のデータのエンコード順は、拡張子「.zip」による圧縮と、「.mrm」による暗号化の順である。元のデータはＭＩＤＩデータである。したがって、この多重ファイルは、ＭＩＤＩファイルＦ３と、圧縮ファイルＦ２と暗号化ファイルＦ１を多重化したものである。
【００３０】
暗号化ファイルＦ１のヘッダＡ１には、出力データ形式として拡張子「.zip」が指定されている。また、圧縮ファイルＦ２のヘッダＡ２には、出力データ形式として拡張子「.mid」が指定されている。また、ＭＩＤＩファイルＦ３のヘッダＡ３には、ＭＩＤＩフォーマットに関する情報が指定されている。なお、ＭＩＤＩファイルＦ３はＭＩＤＩデータであるために、他のフォーマットにデータ変換する必要は本来ないが、本実施形態では、ＭＩＤＩファイルをより扱い易い内部独自フォーマットに変換し、最終段である出力モジュールに渡すようにしている関係上、その内部独自フォーマットの出力データ形式をモジュールマネージャーに対して通知している。
【００３１】
図７は、各モジュールからモジュールマネージャーに対して出力データ形式を通知したり、モジュールマネージャーから各モジュールに対して動作指定を行う時に使う通知データ形式を示している。図７に示すように、この通知データ形式は、領域１〜領域５を備えており、領域１から順に、「タグ」、「ＵＲＬ」、「ＭＩＭＥ」、「ＥＸＴ」、「付加情報」を記憶する。「タグ」は、モジュールマネージャーから各モジュールに対する動作の種類を指定する。「ＵＲＬ」は、モジュールマネージャーから入力モジュールに対してＵＲＬを指定する。「ＭＩＭＥ」は、ＭＩＭＥ（Multipurpose Internet Mail Extensions)タイプを指定する。「ＥＸＴ」は拡張子を指定する。「付加情報」は、必要に応じて付ける付加情報を指定する。このうち、「ＭＩＭＥ」と「ＥＸＴ」でモジュールからモジュールマネージャーに対する出力データ形式の通知を行う。なお、出力データ形式は、拡張子「ＥＸＴ」かＭＩＭＥタイプ「ＭＩＭＥ」によって行うことができる。通常、拡張子が指定されている時には、ＭＩＭＥタイプは不要であるが、拡張子は、誤操作によって、または意図的に変更される可能性があるために、ＭＩＭＥタイプの方が信頼性が高いとされる。モジュールマネージャーからは、「タグ」または「ＵＲＬ」が各モジュールに対して通知される。入力モジュールに対しては、「ＵＲＬ」が通知される。この「ＵＲＬ」は、たとえば、「file://c:/test.mrm」であったり、または、「http://...... 」であったりする。前者は、ローカルストレージ１５（図１参照）のファイル格納場所を指定し、後者はネットワーク３に接続されるファイル格納場所を示す。一般に、これらの「file」や「http」あるいは「ftp 」はプロトコルと称され、このプロトコルに「パス」と「ファイル名」が結合されることによって取得ファイルを指定することができる。
【００３２】
図８は、図６に示す入力データに対し、パイプラインを構築するステップを説明する図である。
【００３３】
Ｔ１：モジュールマネージャー２１が、アプリケーションモジュール２０（図２参照）からファイル（入力データ）オープン要求を受信する。
【００３４】
Ｔ２：プロトコルが適合する入力モジュール３０を生成する。ここでは、プロトコルを「file」とする。したがって、入力データ( ファイル) は、ローカルストレージ１５（図１参照）からロードされる。
【００３５】
Ｔ３：モジュールマネージャー２１は、通知データＤ１により、ファイル「test.mrm」を指定して、入力モジュール３０をオープンする。
【００３６】
Ｔ４：入力モジュール３０は、指定されたファイルの拡張子を参照して出力データ形式を判定する。指定されたファイルがコンテンツファイルそのものではなく、ＨＴＴＰプロトコルでコンテンツファイルを送信するためのサーバサイドスクリプトである場合もあるので、拡張子で出力データを特定できない場合にはＨＴＴＰプロトコルにおけるレスポンスヘッダ中のコンテンツタイプヘッダを参照し、出力データ形式を判定する。この場合は、「test.mrm」の拡張子「.mrm」により、出力データ形式が拡張子「.mrm」で表現される暗号化データであることがわかるので、これをモジュールマネージャー２１に通知する。この通知は、通知データＤ２の領域４において行う。
【００３７】
Ｔ５：拡張子「.mrm」の暗号化データをデコード（変換）するためのデータ変換モジュール３１を生成する。
【００３８】
Ｔ６：モジュールマネージャー２１は、生成したデータ変換モジュール３１をパイプラインの末尾に結合する（ここでは、入力マネージャー３０に結合する）。
【００３９】
Ｔ７：モジュールマネージャー２１は、データ変換モジュール３１をオープンする。この動作は、通知データＤ２の領域１によって指定する。
【００４０】
Ｔ８：データ変換モジュール３１がオープンされることによって、パイプラインを介してこのデータ変換モジュール３１にデータの一部が入力される。この時、データ変換モジュール３１は、暗号化ファイルＦ１のヘッダＡ１を参照して、次にデコード（変換）すべき圧縮ファイルＦ２の出力データ形式を判定してモジュールマネージャー２１に通知する。この通知は、通知データＤ３の領域４によって行う。
【００４１】
Ｔ９：モジュールマネージャー２１は、上記Ｔ８で通知された出力データ形式に対応するデータ変換モジュール３２を生成する。この時の出力データ形式は拡張子「.zip」で表現されるものであるから、このデータ変換モジュール３２は、拡張子「.zip」の圧縮データをデコード（変換）するものである。
【００４２】
Ｔ１０：モジュールマネージャー２１は、データ変換モジュール３２をパイプラインの末尾に結合する。ここでは、データ変換モジュール３２はその前段のデータ変換モジュール３１に結合される。
【００４３】
Ｔ１１：データ変換モジュール３２をオープンする。このオープン動作は、通知データＤ３の領域１で指定される。
【００４４】
Ｔ１２：データ変換モジュール３２がオープンされることによって、パイプラインを介してこのデータ変換モジュール３２にデータの一部が入力される。この時、データ変換モジュール３２は、多重化されている入力データの圧縮ファイルＦ２のヘッダＡ２を参照する。ヘッダＡ２にはデータ変換モジュール３２でデコード（変換）した時の出力データ形式が記憶されている。この出力データ形式は、この例では、拡張子「.mid」で表されるＭＩＤＩデータを表す。そして、このデータ変換モジュール３２は、その出力データ形式を通知データＤ４の領域４によってモジュールマネージャー２１に通知する。
【００４５】
Ｔ１３：モジュールマネージャー２１は、上記Ｔ１２での通知を受けると、拡張子「.mid」で表されるＭＩＤＩデータをデコード（変換）するためのデータ変換モジュール３３を生成する。
【００４６】
Ｔ１４：モジュールマネージャー２１は、上記Ｔ１３で生成したデータ変換モジュール３３をパイプラインの末尾に結合する。この例では、データ変換モジュール３３をデータ変換モジュール３２に結合する。
【００４７】
Ｔ１５：モジュールマネージャー２１は、データ変換モジュール３３をオープンする。
【００４８】
Ｔ１６：データ変換モジュール３３がオープンすることによって、入力データの一部がパイプラインを通過してデータ変換モジュール３３に入力される。この時、データ変換モジュール３３は、受け取ったＭＩＤＩファイルをより扱い易い内部独自フォーマットに変換する。ここでは、その出力データ形式は「application/x-midi2 」で表されている。データ変換モジュール３３は、このようにして判定した出力データ形式をモジュールマネージャー２１に通知する。なお、「application/x-midi2 」の出力データ形式は、拡張子ではなくＭＩＭＥタイプによって指定される。したがって、通知データＤ５の領域３を使用してモジュールマネージャー２１に通知される。
【００４９】
Ｔ１７：モジュールマネージャー２１は、上記Ｔ１６の通知を受けると、出力モジュール３４を生成する。
【００５０】
Ｔ１８：モジュールマネージャー２１は、出力モジュール３４をパイプラインの末尾に結合する。ここでは、出力モジュール３４をデータ変換モジュール３３に結合する。
【００５１】
Ｔ１９：モジュールマネージャー２１は、出力モジュール３４をオープンする。このオープン動作は、通知データＤ５の領域１によって行う。
【００５２】
Ｔ２０：出力モジュール３４がオープンされることによって、入力データの一部はパイプラインを通過し、出力モジュール３４において自らがパイプラインの終端位置にあることを判定する。そこで、出力モジュール３４は、モジュールマネージャー２１に対して通知データＤ６の領域１により、自らが終端であることを通知する。
【００５３】
以上のＴ１〜Ｔ２０の処理において、各モジュールが読み込むデータは、多重化された入力データのヘッダのデータだけである。このため、パイプラインの構築に必要な処理時間は、一瞬である。また、この例では、図６に示すように３重に多重化された入力データに対するパイプライン構築を示したが、４重に多重化された入力データであれば、入力モジュール３０と出力モジュール３４間に、データ変換モジュールがもう１つ追加されることになる。このように、本実施形態では、多重化された入力データのエンコードと逆順に各ファイルのヘッダのみを参照して各ファイルの出力データ形式を判定し、該形式への変換（デコード）に必要なデータ変換モジュールを選択してパイプラインを結合していくために、入力データの多重化数やエンコード方式を知らなくても、正しくデコード（変換）するためのパイプラインを動的に構築することができる。なお、パイプラインを構築した後は、入力モジュール３０に入力データが入力され、パイプラインによってストリーミング処理されていく。
【００５４】
図９は、パイプラインによって入力データのデコード（変換）処理が行われていく時の状態を示している。入力モジュール３０に入力された入力データは、データ変換モジュール３１で復号化され、次のデータ変換モジュール３２で伸長され、次のデータ変換モジュール３３で、特定のＭＩＤＩデータに変換され、最後の出力モジュール３４で、出力デバイスに出力される。
【００５５】
なお、図２において、各モジュール２２は、プラグインモジュールとして特定のプラグインフォルダーに収納されている。モジュールマネージャー２１は、パイプラインを構築する前に、このプラグインフォルダー内の各モジュールの情報を収集し、リストを作成して各モジュールを定義しておく。モジュールの定義とは、そのモジュールがどのような処理を行うことができるかなどの機能を判定してリスト上に記憶しておくことである。モジュールマネージャー２１は、事前にこのようにして定義したデータ変換モジュール群の中から適切なものを選択し、パイプライン構築のために生成する。ここで言う生成とは、オブジェクト指向言語において、クラスの実体（インスタンス）を生成するという意味合いである。たとえば、入力モジュール３０を生成するとは、メモリ上に入力モジュール３０の実体が生成されることをいう。
【００５６】
図１０は、本実施形態によって、パイプラインを構築するための手順を示すフローチャートである。
【００５７】
ステップＳＴ１において、モジュールマネージャー２１は、プラグインフォルダーに置かれている全てのモジュールの情報を収集する。ＳＴ２では、モジュールマネージャー２１が、アプリケーションモジュール２０からファイル（入力データ）のオープン要求を受信する。モジュールマネージャー２１は、要求されたプロトコルに適合する入力モジュール３０をオープンしパイプラインの先頭に追加する（ＳＴ３）。さらに、モジュールマネージャー２１は、ＳＴ４において入力モジュール３０をオープンする。
【００５８】
オープンした入力モジュール３０は、最外郭のファイルの出力データ形式をＵＲＬやＨＴＴＰプロトコルにおけるレスポンスヘッダ中のコンテンツタプヘッダから判定してモジュールマネージャー２１に通知する。モジュールマネージャー２１は、この通知を受けて出力データ形式を得るとともに（ＳＴ５）、パイプラインの終端でないことを判定して（ＳＴ６）、出力データ形式に適合するモジュール（データ変換モジュールか出力モジュール）を生成し、パイプラインの末尾に追加する（ＳＴ７）。また、そのモジュールをオープンして（ＳＴ８）、ＳＴ５に戻る。モジュールマネージャー２１は、パイプラインの終端であることを知ると、それ以後のパイプライン構築動作を停止し、以下、続いてデータボディのデコード（変換）処理が行われる。
【００５９】
以上の処理において、ＳＴ１〜ＳＴ８のパイプライン構築動作は、ヘッダのデータのみで処理される。したがって、入力データ全体を全て受け取っていなくても、入力データを正しく変換（デコード）するのに必要で十分なパイプラインの構築が出来る。そして、パイプラインによるデータボディの変換処理はストリーミングにより可能である。
【００６０】
本実施形態では、多重にエンコードした多重ファイルの入力データに有効であるが、多重でない１回のみエンコードした入力データであっても対応することが可能である。この場合は、入力モジュールと出力モジュール間に１つのデータ変換モジュールが結合されることになる。また、各モジュールをパイプライン接続することによって、入力データのストリーミング処理を可能としたが、各モジュールを単にカスケード（従属）接続して、各段階で１ファイル毎に、順にデコード（変換）処理を行うようにしてもよい。
【００６１】
また、本発明は、複数のデータ変換モジュールの前後に入力モジュールと出力モジュールを結合してパイプラインを構築したが、入力モジュールと出力モジューは必ずしもなくてもよく、これらの機能をデータ変換モジュールに持たせることも可能である。
【００６２】
【発明の効果】
本発明によれば、データ変換（デコード）を実行する時でないと最終出力データ形式が判明しないような入力データ、すなわち、データのエンコード処理が多重化された多重ファイルを扱うことができる。また、データ変換モジュールの段数は固定されずに動的に作成されるために、多様なデータフォーマットに対応することができる。
【図面の簡単な説明】
【図１】本発明の実施形態であるデータ処理装置の構成図
【図２】本発明の実施形態である入力データの動的変換プログラムのモジュール群を示す図
【図３】パイプラインが構築される様子を示す図
【図４】データを複数の変換方式で多重にエンコードして作成した多重ファイルの概念構成図
【図５】パイプラインの構築手順を示す図
【図６】入力データの形式例を示す図
【図７】通知データの形式を示す図
【図８】パイプラインの構築動作を具体的に説明する図
【図９】構築されたパイプラインによって入力データがデコード（変換）処理される状態を示す図
【図１０】パイプライン構築の手順を示すフローチャート
【図１１】従来の入力データ変換システムの概略構成図
【図１２】従来の他の入力データ変換システムの概略構成図
Claims (7)
- エンコードされたデータをデコードするデータ処理装置で実行する入力データの変換方法において、
データが複数の変換方式でｎ（ｎは２以上の整数）回エンコードされたファイルである入力データの出力データ形式を判定し、前記形式に基づいて、前記ファイルのデコードに必要なデータ変換モジュールを選択するステップと、
ｎ回エンコードされたファイルのデコードに必要なデータ変換モジュールが、前記ファイルのヘッダを参照して、（ｎ−１）回エンコードされたファイルの出力データ形式を判定する第１ステップと、
モジュールマネージャーが前記形式に基づいて、（ｎ−１）回エンコードされたファイルのデコードに必要なデータ変換モジュールを選択する第２ステップと、
前記第１及び第２ステップを順次ｎ回繰り返すステップと、
選択された全データ変換モジュールを、選択された順に結合する結合ステップと、
前記データ変換モジュールが結合されてなるデータ変換モジュール群で入力データの変換処理を実行するステップと
を実行することを特徴とする入力データの変換方法。 - 選択可能な全てのデータ変換モジュールを予め定義し、
前記データ変換モジュールは、
定義してあるデータ変換モジュールの中から選択される
請求項１に記載の入力データの変換方法。 - 前記結合ステップは、
入力データを入力デバイスから入力する入力モジュールに、前記データ変換モジュール群を結合し、前記データ変換モジュール群に、出力データを出力デバイスに出力する出力モジュールを結合する
請求項１または２に記載の入力データの変換方法。 - エンコードされたデータをデコードするＣＰＵに実行させる入力データの変換プログラムにおいて、
データが複数の変換方式でｎ（ｎは２以上の整数）回エンコードされたファイルである入力データの出力データ形式を判定し、前記形式に基づいて、前記ファイルのデコードに必要なデータ変換モジュールを選択するステップと、
ｎ回エンコードされたファイルのデコードに必要なデータ変換モジュールが、前記ファイルのヘッダを参照して、（ｎ−１）回エンコードされたファイルの出力データ形式を判定する第１ステップと、
モジュールマネージャーが前記形式に基づいて、（ｎ−１）回エンコードされたファイルのデコードに必要なデータ変換モジュールを選択する第２ステップと、
前記第１及び第２ステップを順次ｎ回繰り返すステップと、
選択された全データ変換モジュールを、選択された順に結合する結合ステップと、
前記データ変換モジュールが結合されてなるデータ変換モジュール群で入力データの変換処理を実行するステップと
をＣＰＵに実行させることを特徴とする入力データの変換プログラム。 - 選択可能な全てのデータ変換モジュールを予め定義し、
ＣＰＵに、
定義してあるデータ変換モジュールの中から前記データ変換モジュールを選択させる
請求項４に記載の入力データの変換プログラム。 - 前記結合ステップは、
入力データを入力デバイスから入力する入力モジュールに、前記データ変換モジュール群を結合し、前記データ変換モジュール群に、出力データを出力デバイスに出力する出力モジュールを結合する
請求項４または５に記載の入力データの変換プログラム。 - データが複数の変換方式でｎ（ｎは２以上の整数）回エンコードされたファイルである入力データを入力デバイスから入力する処理を行う入力モジュールと、
入力されたデータをデコードするｎ個のデータ変換モジュールと、
ｎ個の前記データ変換モジュールでｎ回デコードされたデータを出力デバイスに出力する出力モジュールと、
前記入力モジュール、前記データ変換モジュール、前記出力モジュールの順に各モジュールを結合し、結合したモジュール群の先頭の入力モジュールに入力データを入力してデータ変換処理を行わせるモジュールマネージャーと
を備え、
前記データ変換モジュールは、
ｎ回エンコードされたファイルのヘッダのみを参照して、（ｎ−１）回エンコードされたファイルの出力データ形式を判定して前記モジュールマネージャーに通知し、
前記モジュールマネージャーは、
通知された出力データ形式に対応したデータ変換モジュールを選択して、直前に選択したデータ変換モジュールに結合する処理を行う
ことを特徴とする入力データの変換システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001158607A JP4752137B2 (ja) | 2001-05-28 | 2001-05-28 | 入力データの変換方法、入力データの変換プログラム、および入力データの変換システム |
| US10/155,498 US6844832B2 (en) | 2001-05-28 | 2002-05-24 | Input data conversion method, input data conversion program, and input data conversion system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001158607A JP4752137B2 (ja) | 2001-05-28 | 2001-05-28 | 入力データの変換方法、入力データの変換プログラム、および入力データの変換システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002351709A JP2002351709A (ja) | 2002-12-06 |
| JP4752137B2 true JP4752137B2 (ja) | 2011-08-17 |
Family
ID=19002296
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001158607A Expired - Fee Related JP4752137B2 (ja) | 2001-05-28 | 2001-05-28 | 入力データの変換方法、入力データの変換プログラム、および入力データの変換システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6844832B2 (ja) |
| JP (1) | JP4752137B2 (ja) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8259121B2 (en) * | 2002-10-22 | 2012-09-04 | Broadcom Corporation | System and method for processing data using a network |
| US7523221B2 (en) * | 2003-05-17 | 2009-04-21 | Microsoft Corporation | Mechanism for applying transforms to multi-part files |
| US7594170B2 (en) * | 2003-10-24 | 2009-09-22 | Microsoft Corporation | Mechanism for providing data driven command line output |
| US8566806B2 (en) | 2005-03-04 | 2013-10-22 | Microsoft Corporation | Command-line data-type discovery and conversion |
| JP4652090B2 (ja) * | 2005-03-15 | 2011-03-16 | 富士通株式会社 | 事象通知管理プログラム、事象通知管理装置及び事象通知管理方法 |
| ITTV20090017A1 (it) * | 2009-02-17 | 2010-08-18 | B & B Holding S R L | Metodo e sistema per lo scambio di documenti digitali. |
| JP5391844B2 (ja) * | 2009-06-05 | 2014-01-15 | 株式会社リコー | 印刷制御プログラム、記憶媒体および情報処理装置 |
| JP5725812B2 (ja) | 2010-11-25 | 2015-05-27 | キヤノン株式会社 | 文書処理装置、文書処理方法、及びプログラム |
| CN102129443A (zh) * | 2010-12-30 | 2011-07-20 | 中国民航信息网络股份有限公司 | 基于usas主机的实时数据传输通道及其实时数据传输方法 |
| JP5348166B2 (ja) * | 2011-03-30 | 2013-11-20 | ブラザー工業株式会社 | 中継装置、通信方法、および通信システム |
| JP5927950B2 (ja) * | 2012-02-03 | 2016-06-01 | ブラザー工業株式会社 | 制御装置 |
| JP5935515B2 (ja) | 2012-05-31 | 2016-06-15 | ブラザー工業株式会社 | 制御装置 |
| KR102009419B1 (ko) * | 2017-07-20 | 2019-08-09 | 라인 가부시키가이샤 | 실행 가능한 압축 파일을 보호하기 위한 파일 보호 방법 및 시스템 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| NL8500841A (nl) * | 1985-03-22 | 1986-10-16 | Philips Nv | Kodeer- of dekodeerschakeling voor tijdmultiplex en simultane signalen. |
| JPH06251073A (ja) * | 1993-02-24 | 1994-09-09 | Nippon Telegr & Teleph Corp <Ntt> | データ流通装置 |
| US5701452A (en) * | 1995-04-20 | 1997-12-23 | Ncr Corporation | Computer generated structure |
| JPH0969059A (ja) * | 1995-08-31 | 1997-03-11 | Nec Corp | ファイル形態変換システム |
| JP2001103386A (ja) * | 1999-09-28 | 2001-04-13 | Sanyo Electric Co Ltd | デジタル放送受信装置 |
-
2001
- 2001-05-28 JP JP2001158607A patent/JP4752137B2/ja not_active Expired - Fee Related
-
2002
- 2002-05-24 US US10/155,498 patent/US6844832B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20020175841A1 (en) | 2002-11-28 |
| JP2002351709A (ja) | 2002-12-06 |
| US20030146857A9 (en) | 2003-08-07 |
| US6844832B2 (en) | 2005-01-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7730047B2 (en) | Analysis of media content via extensible object | |
| US7609653B2 (en) | Resolving partial media topologies | |
| US7613767B2 (en) | Resolving a distributed topology to stream data | |
| JP3969654B2 (ja) | Ｓｏａｐメッセージ作成方法並びに処理方法、情報処理方法、情報処理装置及びプログラム | |
| JP4752137B2 (ja) | 入力データの変換方法、入力データの変換プログラム、および入力データの変換システム | |
| US9954862B2 (en) | System and method for using resources of a computer system in conjunction with a thin media client | |
| KR101016465B1 (ko) | 콘텐츠 제공 서버 및 클라이언트에서의 정보 처리 장치, 콘텐츠 제공 서버 및 클라이언트에서의 정보 처리 방법 및 그 정보 처리 방법을 실행하는 컴퓨터 프로그램이 기록된 기록매체 | |
| JP2004046789A (ja) | 情報処理装置、情報処理方法、およびコンテンツ配信装置、コンテンツ配信方法、並びにコンピュータ・プログラム | |
| US8184692B2 (en) | Distributed and automated video encoding and delivery system | |
| WO2004068353A1 (ja) | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム | |
| JP2007523524A (ja) | マルチメディアデータを記録した情報保存媒体、その再生方法及び再生装置 | |
| JP2010539742A (ja) | マルチメディアメッセージングサービス（ｍｍｓ）の動画への適合のための方法およびシステム | |
| JP2006339855A (ja) | ネットワーク制御装置、符号化方式変換装置、及びコンテンツデータ再生システム | |
| US20070239780A1 (en) | Simultaneous capture and analysis of media content | |
| WO2001077897A2 (en) | System and method using a web catalog with dynamic multimedia data using java | |
| US20140141875A1 (en) | Temporary modification for extending functionality of computer games and software applications. | |
| JP4249569B2 (ja) | デマルチプレクサのアプリケーションプログラムインターフェイス | |
| US7539292B2 (en) | Contents distribution system, contents server, contents receiving apparatus, contents distribution method, program and storage media | |
| JP2005110024A (ja) | データ送信装置、データ送受信システム、及びデータ送受信方法 | |
| JP2003271406A (ja) | データ処理装置およびデータ処理方法ならびにそのプログラム | |
| JP2002297494A (ja) | データ配信システム、端末装置、シナリオプロキシサーバおよびデータ配信方法 | |
| WO2009130446A1 (en) | Remote use of computer games and software applications | |
| Chon et al. | An approach of dynamically forming an acceptable transcoding path by a search algorithm based on a context-free grammar in a MPEG21 DIA | |
| AU2003259937A1 (en) | Resolving a distributed topology to stream data |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080321 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20101005 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20101130 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20101130 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110215 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110317 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20110426 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110509 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140603 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |