(57)【要約】【課題】ＵＳＢインターフェースを介して接続するコンピュータのＣＰＵに対して低負荷で大量のエンコードデータの転送が可能であり、更に、ＣＰＵ種類毎に専用のドライバを開発する必要がないＵＳＢデバイスのエンコード装置を提供すること。【解決手段】エンコード装置が、ＵＳＢストレージクラスにおいてはＣＰＵに対して低負荷で大量のデータを転送できるよう仕様が標準規格として定められていることを利用して、ＰＣとの接続を確立する際に、ＵＳＢ規格で規定されたＵＳＢストレージクラスのデバイスであると、ＰＣが備えるＯＳに認識させるとともに、ＰＣからのセクタ読み込みコマンドが伝送されてきた場合に、定義処理として、データと解釈したセクタ番号それぞれに予め設定された情報のうち、セクタ読み込みコマンド中に含まれるセクタ番号に対応する情報を選択してＰＣへ返信する。【選択図】図１２
2010157819.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータとはＵＳＢ（Universal Serial Bus）インターフェースを介して接続可能なＵＳＢデバイスのエンコード装置であって、
前記コンピュータとの接続を確立する際に、ＵＳＢ規格で規定されたＵＳＢストレージクラスのデバイスであると、前記コンピュータが備えるＯＳ（Operating System）に認識させるための情報を出力するデバイス情報出力手段と、
前記コンピュータからのセクタ読み込みコマンドが伝送されてきた場合に、前記セクタ読み込みコマンドに含まれるセクタ番号をデータと解釈し、前記データに基づいて、予め設定した各種定義処理を実行する制御手段と、を備え、
前記制御手段は、前記コンピュータからのセクタ読み込みコマンドが伝送されてきた場合に、前記定義処理として、前記データと解釈したセクタ番号それぞれに予め設定された情報のうち、前記セクタ読み込みコマンド中に含まれる前記セクタ番号に対応する情報を選択して前記コンピュータへ返信すること
を特徴とするＵＳＢデバイスのエンコード装置。
【請求項２】
請求項１に記載のＵＳＢデバイスのエンコード装置において、
前記デバイス情報出力手段は、データストレージ機能を有することを前記コンピュータが備えるＯＳに認識させるための情報として、ＳＣＳＩ規格で規定されたリムーバブルＨＤである旨の情報を出力すること
を特徴とするＵＳＢデバイスのエンコード装置。
【請求項３】
請求項２に記載のＵＳＢデバイスのエンコード装置において、
前記デバイス情報出力手段は、さらに、データストレージ機能を有することを前記コンピュータが備えるＯＳに認識させるための情報として、前記リムーバブルＨＤにパーティションが設定されておらず、且つ書き込み禁止である旨の情報を出力すること
を特徴とするＵＳＢデバイスのエンコード装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＳＢ（Universal Serial Bus）インターフェースを介して接続するコンピュータのＣＰＵに対して低負荷で大量のエンコードデータの転送が可能であり、専用のドライバをＣＰＵ種類毎に開発する必要がないエンコード装置に関する。
【背景技術】
【０００２】
従来より、コンピュータとＵＳＢ（Universal Serial Bus）インターフェースを介して接続可能なエンコード装置が知られている。
【０００３】
例えば、特許文献１に記載のシステムでは、ＵＳＢプロトコルでＰＣなどのＵＳＢホストから、ＭＰＥＧエンコーダなどのＵＳＢデバイスを制御し、ＭＰＥＧデータをＵＳＢホストに転送している。
【０００４】
ところで、この種のエンコード装置としては、シリアルポートを利用して動画などのエンコードデータを転送するシリアルポート型や、ベンダーが独自にエンコード装置の仕様を設定するいわゆるベンダー独自型が採用されることが多い。
【特許文献１】特開２００１−１６８９４１号公報（第５，６頁、図１，４，５）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上述のようなエンコード装置においては、上述のようなシリアルポート型やベンダー独自型である場合に、次のような理由によりＣＰＵに対して高負荷となってしまい、大量のデータを高速で転送できないという問題があった。
【０００６】
すなわち、エンコード装置がシリアルポート型である場合には、ＲＳ−２３２Ｃ装置のソフトウェア・エミュレーションで有るため、エンコード装置のような大容量データのエンコード装置からＰＣへ高速のデータ転送には本来向いていない。一般的にエミュレーションした場合は、バッファの１データ単位が２５６バイト程度で有るため、例えば１Ｍバイト／秒程度のデータを流すと、１秒間に４０００回もＰＣ側のＣＰＵに割り込みが掛かってしまい、非力なＣＰＵにとっては非常に大きな処理負担となるという問題があった。特に、動画エンコードデータを転送する際には、データ量が膨大となるために顕著である。
【０００７】
また、エンコード装置がベンダー独自型である場合には、特に定められたフォーマットは無いためにＰＣのＣＰＵ負荷に関してはベンダー側の仕様設計次第ということになるが、この場合にはベンダーがＰＣ側のドライバを独自に設計することとなり、エンコード装置がその設計されたドライバとセットで使用されることとなるため、様々なタイプのＣＰＵにも対応するということが困難である。特に、ｘ８６系以外のＣＰＵはサポートされないことが多い。また、エンコード装置がベンダー独自型である場合には、ＵＳＢデバイス側の都合が良い仕様でドライバが決まることが多く、その結果、ＵＳＢホストであるＰＣ側のＣＰＵに対して高負荷となってしまうことが多いという問題があった。
【０００８】
本発明は、このような課題に鑑みなされたものであり、その目的とするところは、ＵＳＢ（Universal Serial Bus）インターフェースを介して接続するコンピュータのＣＰＵに対して低負荷で大量のエンコードデータの転送が可能であり、更に、ＣＰＵ種類毎に専用のドライバを開発する必要がないＵＳＢデバイスのエンコード装置を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するためになされた請求項１に係るＵＳＢデバイスのエンコード装置は、コンピュータとはＵＳＢ（Universal Serial Bus）インターフェースを介して接続可能であり、デバイス情報出力手段が、コンピュータとの接続を確立する際に、ＵＳＢ規格で規定されたＵＳＢストレージクラスのデバイス（以下、ＵＳＢストレージ型）であると、コンピュータが備えるＯＳ（Operating System）に認識させるための情報を出力する。また、制御手段が、コンピュータからのセクタ読み込みコマンドが伝送されてきた場合に、セクタ読み込みコマンドに含まれるセクタ番号をデータと解釈し、前記データに基づいて、予め設定した各種定義処理を実行する。また、制御手段が、コンピュータからのセクタ読み込みコマンドが伝送されてきた場合に、定義処理を実行する。より具体的には、制御手段は、コンピュータからのセクタ読み込みコマンドが伝送されてきた場合に、定義処理として、データと解釈したセクタ番号それぞれに予め設定された情報のうち、セクタ読み込みコマンド中に含まれるセクタ番号に対応する情報を選択してコンピュータへ返信する。
【００１０】
このように構成された本発明のＵＳＢデバイスのエンコード装置によれば、ＵＳＢストレージクラスにおいてはＣＰＵに対して低負荷で大量のデータを転送できるよう仕様が標準規格として定められていることを利用して、コンピュータとの接続を確立する際に、ＵＳＢ規格で規定されたＵＳＢストレージクラスのデバイスであると、コンピュータが備えるＯＳ（Operating System）に認識させるとともに、コンピュータからのセクタ読み込みコマンドが伝送されてきた場合に、定義処理として、データと解釈したセクタ番号それぞれに予め設定された情報のうち、セクタ読み込みコマンド中に含まれるセクタ番号に対応する情報を選択してコンピュータへ返信することにより、ＵＳＢ（Universal Serial Bus）インターフェースを介して接続するコンピュータのＣＰＵに対して低負荷で大量の動画エンコードデータを転送できる。
【００１１】
また  本発明のＵＳＢデバイスのエンコード装置によれば、既存のリソースを利用できるので、ＣＰＵ種類毎に専用のドライバを開発する必要がない。また  本発明のＵＳＢデバイスのエンコード装置によれば、ＵＳＢストレージクラスのデバイスに対応するＯＳが多く存在するため、対応ＯＳが多いという利点がある。
【００１２】
この場合、デバイス情報出力手段が、データストレージ機能を有することをコンピュータが備えるＯＳに認識させるための情報として、ＳＣＳＩ規格で規定されたリムーバブルＨＤである旨の情報を出力することが考えられる（請求項２）。
【００１３】
ところで、当該エンコード装置が、ＳＣＳＩ規格で規定されたリムーバブルＨＤである旨をコンピュータが備えるＯＳによって認識された場合には、コンピュータが備えるＯＳからの指示により、上述のリムーバブルＨＤにパーティションが設定されたりリムーバブルＨＤへの書き込みが許可されたりするおそれがある。このうちパーティションが設定された場合には、パーティション“ｓｄａ１”が自動的にファイルシステム“／ｍｅｄｉａ／ｕｓｂｄｉｓｋ”と接続され、ユーザから操作可能となる。この場合、ユーザが“／ｍｅｄｉａ／ｕｓｂｄｉｓｋ”を操作すると、ＵＳＢデバイスへのアクセスが発生し、エンコード中の場合にはデバイス側に不要な負担が掛かり、データ落ちなどの原因になるという問題がある。また、その他にも、ファイルシステムとして動作可能な最低限の記憶容量が必要になる。また、リムーバブルＨＤへの書き込みが許可された場合には、ユーザ操作により、パーティションを追加されたりパーティションを切り直されたりして、予約したはずのエリアをファイルシステムエリアに組み入れられてしまうおそれがある。この場合、リードセクタアドレスで制御する場合には誤動作の原因となるという問題がある。
【００１４】
そこで、上述のリムーバブルＨＤが、パーティションが設定されておらず、且つ書き込みが禁止されている状態であるとコンピュータが備えるＯＳに認識させることが考えられる。具体的には、請求項３のように、デバイス情報出力手段が、さらに、データストレージ機能を有することをコンピュータが備えるＯＳに認識させるための情報として、リムーバブルＨＤにパーティションが設定されておらず、且つ書き込み禁止である旨の情報を出力することが考えられる。
【００１５】
このように構成された本発明のＵＳＢデバイスのエンコード装置によれば、エンコード装置が自らを、パーティションが設定されていない状態且つ書き込み禁止状態であるメディアが挿入されているカードリーダなどの読込装置として、コンピュータが備えるＯＳに認識させることができる。このことにより、ディスクとして動作するための容量が不要であるから、パーティションが設定されなくてもよく、記憶容量が少なくてもよい。また、ディスクとして認識されないことからコンピュータが備えるＯＳからのアクセスを受けず、誤動作を生じにくくすることができる。つまり、パーティションが設定されていないことにより、ユーザ操作でデバイス側に不要な負担が掛からず、ファイルシステムとして動作可能な最低限の記憶容量も必要無くなるという利点がある。また、リムーバブルＨＤへの書き込みを禁止にした場合には、予約したエリアは、ユーザが操作してもファイルシステムエリアに組み入れられる心配が無い。また、パーティション追加やパーティション切り直しは、セクタ“０”への書き込みとなるため、リムーバブルＨＤへの書き込みを禁止にすればこれらは失敗するから問題がない。
【発明を実施するための最良の形態】
【００１６】
以下に本発明の実施形態を図面とともに説明する。なお、本発明はこの実施形態に限定されるものではなく、様々な態様にて実施することが可能である。
［第一実施形態］
［１．情報処理装置の内部構造の説明］
図１は、実施形態として例示するエンコードシステム１００の構成、情報処理装置１およびエンコード装置２７の各内部構造を示すブロック図である。
【００１７】
以下に説明するコンピュータとしての情報処理装置１は、電源投入後に自動的に所定のプログラム群を実行することで、この情報処理装置１が備える特定の機能が作動するように構成された特定機能専用の装置である。より具体的には、本実施形態の場合、情報処理装置１はカラオケコマンダーとして構成されたものであり、電源投入後に自動的に所定のプログラム群を実行することで、カラオケコマンダーとして各種機能が作動するように構成されている。
【００１８】
なお、以下の説明および図面において、情報処理装置１をパーソナルコンピュータ（ＰＣ）と適宜表現することとする。
【００１９】
この情報処理装置１は、ＣＰＵ１１、ＲＯＭ１３、ＲＡＭ１５、ハードディスク装置１７、およびＵＳＢインターフェース２０などを備えている。また、ＵＳＢインターフェース２０は、外部ＵＳＢポート２３を備えている。
【００２０】
さらに、これらのハードウェアを制御するため、情報処理装置１には、ＯＳが搭載されている。本実施形態において、ＯＳとしてはＬｉｎｕｘ（登録商標）が搭載されている。ただし、一般的なＬｉｎｕｘ（登録商標）が備える機能のみでは、本発明を実施する上で必要となる機能が十分に揃っていないため、一部独自の機能を追加してある。この追加機能の具体的な内容に関しては後から詳述するが、その他一般的なＬｉｎｕｘ（登録商標）と差異のない機能については、その説明を省略する。
【００２１】
また、本実施形態では、外部ＵＳＢポート２３には、エンコード装置２７が接続されている。エンコード装置２７も同様に、ＣＰＵ２７ｂ、ＲＯＭ２７ｃ、ＲＡＭ２７ｄ、ＭＰＥＧエンコーダ２７ｅ、およびＵＳＢインターフェース２７ａなどを備えており、ＭＰＥＧエンコーダ２７ｅには、ビデオカメラなどが接続され、オーディオ・ビデオの動画信号が入力されたり、各種記録メディアに記憶される動画データがＩ／Ｃカードスロット２７ｆなどを介して入力されたりする。
【００２２】
情報処理装置１およびエンコード装置２７がエンコードシステム１００を構成する。
【００２３】
このエンコード装置２７は、オーディオ・ビデオ信号をエンコードしてエンコードデータを作成する機能、各種記録メディアに記憶される動画データからエンコードデータを作成する機能、および作成したエンコードデータをストレージするデータストレージ機能を有する公知のものである。なお、上述の各種機能についてはエンコード装置２７が備えるＣＰＵ２７ｂによって実行される。なお、エンコード装置２７が備えるＣＰＵ２７ｂがデバイス情報出力手段および制御手段に該当する。
【００２４】
［２．情報処理装置の起動時に実行される処理］
次に、上記情報処理装置１の起動時に実行される処理について説明する。
【００２５】
図２は、情報処理装置１の電源ＯＮに伴って実行される処理のフローチャートである。
【００２６】
情報処理装置１の電源がＯＮにされると、情報処理装置１では、まず、ＯＳのカーネルがＣＰＵ１１のメモリにロードされる（Ｓ１０５）。ＯＳのカーネルはＲＯＭ１３内に格納されていて、Ｓ１０５では、ＣＰＵ１１がＲＡＭ１５の一部をＲＡＭディスクとして確保し、このＲＡＭディスクにカーネルをロードする。これにより、このＲＡＭディスクがルートボリュームとなってＯＳが起動し、ＯＳの備える少なくとも一部の機能が作動を開始する。
【００２７】
こうしてＯＳの少なくとも一部が機能し始めると、続いて、情報処理装置１は、ＩＤＥ方式で接続されたハードディスク装置１７を認識する（Ｓ１１０）。このＳ１１０において、ハードディスク装置１７にはドライブ名が割り当てられ、本実施形態の場合、ハードディスク装置１７のドライブ名は“ｈｄａ”となる。
【００２８】
続いて、情報処理装置１では、ＳＣＳＩドライブ接続監視が開始される（Ｓ１１５）。本実施形態の場合、このＳ１１５では、ＳＣＳＩドライブ接続監視プロセスが起動され、以降、このプロセスが常駐することにより、情報処理装置１の電源がＯＦＦにされるまで、概ね６秒周期でＳＣＳＩドライブの接続／切断が監視される。
【００２９】
このＳＣＳＩドライブ接続監視の処理内容は、詳しくは図３に示すような処理となる。
【００３０】
すなわち、図３に示す「ＯＳ内ＳＣＳＩドライブ接続監視」を開始すると、情報処理装置１は、まず、「ＳＣＳＩ−Ｉ／Ｆ接続テーブル（以下、ＳＩＴＢと称する。）」の初期化を行う（Ｓ２０５）。ＳＩＴＢは、情報処理装置１において現在接続中のＳＣＳＩインターフェース（以下、ＳＣＳＩ−Ｉ／Ｆと称する。）を登録するためのテーブルである。Ｓ２０５では、例えばハードウェアとして装着されているＳＣＳＩ−Ｉ／Ｆが存在する場合に、その情報がＳＩＴＢに登録する処理などが実行される。
【００３１】
そして、Ｓ２０５で登録したＩ／Ｆに接続されているドライブが存在する場合は、そのドライブをシステムに登録する（Ｓ２１０）。このＳ２１０により、登録されたドライブには“ｓｄａ”，“ｓｄｂ”，…といったドライブ名が割り当てられる。
【００３２】
続いて、情報処理装置１は、一定時間（例えば６秒）が経過したか否かを判断し（Ｓ２１５）、経過していなければ（Ｓ２１５：いいえ）、Ｓ２１５へと戻ることにより、時間経過を待つ。そして、一定時間が経過したら（Ｓ２１５：はい）、現在接続中のＳＣＳＩ−Ｉ／Ｆを確認する（Ｓ２２０）。
【００３３】
その後、情報処理装置１は、新しく接続されたＳＣＳＩ−Ｉ／Ｆの有無を判断し（Ｓ２２５）、新しく接続されたＳＣＳＩ−Ｉ／Ｆが無い場合は（Ｓ２２５：無い）、今回切断されたＳＣＳＩ−Ｉ／Ｆの有無を判断する（Ｓ２３０）。そして、今回切断されたＳＣＳＩ−Ｉ／Ｆが無い場合は（Ｓ２３０：無い）、Ｓ２１５へ戻る。これにより、Ｓ２１５〜Ｓ２３０は、概ね６秒ごとに繰り返し実行されることになる。
【００３４】
そして、このようなＳ２１５〜Ｓ２３０の繰り返し処理が実行される中で、新しく接続されたＳＣＳＩ−Ｉ／Ｆが有った場合（Ｓ２２５：有る）、情報処理装置１は、新規ＳＣＳＩ−Ｉ／Ｆを上述のＳＩＴＢに登録し、そのＩ／Ｆに接続されているドライブをシステムに登録する（Ｓ２３５）。
【００３５】
このＳ２３５により、登録されたドライブには“ｓｄａ”，“ｓｄｂ”，…といったドライブ名が割り当てられる。また、ドライブの登録時には、そのドライブの容量に関する情報も必要となるので、その情報を取得するため、ＳＣＳＩ規格で規定されたＳＣＳＩコマンドの１種であるリードキャパシティコマンドを発行する。
【００３６】
このとき、この情報処理装置１では、リードキャパシティコマンドの発行対象となったドライブ名が、ＳＣＳＩ−Ｉ／Ｆ毎に用意された記憶領域に格納される。このような処理は、一般的なＬｉｎｕｘ（登録商標）では実施されていない特殊な処理であり、この情報処理装置１特有の処理である。
【００３７】
ちなみに、一つのＳＣＳＩ−Ｉ／Ｆに複数のＳＣＳＩドライブが接続されている場合、上述のリードキャパシティコマンドは、複数のＳＣＳＩドライブに対して順に発行されてゆく。そのため、リードキャパシティコマンドの発行対象となったドライブ名も、順に変わってゆくので、ＳＣＳＩ−Ｉ／Ｆ毎に用意された記憶領域には、最後にリードキャパシティコマンドの発行対象となったドライブ名が格納されることになる。
【００３８】
ただし、一つのＳＣＳＩ−Ｉ／Ｆに一つのＳＣＳＩドライブが接続されている場合であれば、上述のリードキャパシティコマンドは、一つのＳＣＳＩドライブに対してしか発行されない。そのため、リードキャパシティコマンドの発行対象となるドライブ名が変わることはなく、ＳＣＳＩ−Ｉ／Ｆ毎に用意された記憶領域には、そのＳＣＳＩ−Ｉ／Ｆに接続されたドライブ名が格納されることになる。
【００３９】
さて、Ｓ２３５を終えたら、情報処理装置１は、今回接続の全ＳＣＳＩ−Ｉ／Ｆの処理が終了したか否かを判断し（Ｓ２４０）、終了していなければ（Ｓ２４０：いいえ  次のＩ／Ｆへ）、Ｓ２３５へと戻ることにより、残りのＳＣＳＩ−Ｉ／ＦについてもＳ２３５を繰り返す。そして、今回接続の全ＳＣＳＩ−Ｉ／Ｆの処理が終了したら（Ｓ２４０：はい）、Ｓ２３０へと進む。
【００４０】
また、Ｓ２１５〜Ｓ２３０の繰り返し処理が実行される中で、今回切断されたＳＣＳＩ−Ｉ／Ｆが有った場合（Ｓ２３０：有る）、情報処理装置１は、切断ＳＣＳＩ−Ｉ／ＦをＳＩＴＢから削除し、そのＩ／Ｆに接続されているドライブをシステムから削除する（Ｓ２４５）。このＳ２４５により、削除されたドライブに対応するドライブ名はシステムから消滅する。
【００４１】
そして、情報処理装置１は、今回切断の全ＳＣＳＩ−Ｉ／Ｆの処理が終了したか否かを判断し（Ｓ２５０）、終了していなければ（Ｓ２５０：いいえ  次のＩ／Ｆへ）、Ｓ２４５へと戻ることにより、残りのＳＣＳＩ−Ｉ／ＦについてもＳ２４５を繰り返す。そして、今回切断の全ＳＣＳＩ−Ｉ／Ｆの処理が終了したら（Ｓ２４０：はい）、Ｓ２１５へと戻る。
【００４２】
さて、以上説明したような処理がＳ１１５によって開始される処理となるが、ここで再び図２に戻り、Ｓ１１５を終えた時点からの説明を続ける。Ｓ１１５を終えると、情報処理装置１では、ＵＳＢ接続監視が開始される（Ｓ１２０）。本実施形態の場合、このＳ１２０では、ＵＳＢ接続監視プロセスが起動され、以降、このプロセスが常駐することにより、情報処理装置１の電源がＯＦＦにされるまで、概ね１００ミリ秒周期でＵＳＢデバイスの接続／切断が監視される。
【００４３】
このＵＳＢ接続監視の処理内容は、詳しくは図４に示すような処理となる。
【００４４】
すなわち、図３に示す「ＯＳ内ＵＳＢ接続監視」を開始すると、情報処理装置１は、まず、「ＵＳＢデバイス接続テーブル（以下、ＵＤＴＢと称する。）」の初期化を行う（Ｓ３０５）。ＵＤＴＢは、情報処理装置１において現在接続中のＵＳＢデバイスを登録するためのテーブルである。なお、Ｓ３０５では、ＵＳＢデバイスは何も接続されていない状態として扱われる。
【００４５】
続いて、情報処理装置１は、一定時間（例えば１００ミリ秒）が経過したか否かを判断し（Ｓ３１５）、経過していなければ（Ｓ３１５：いいえ）、Ｓ３１５へと戻ることにより、時間経過を待つ。そして、一定時間が経過したら（Ｓ３１５：はい）、現在接続中のＵＳＢデバイスを確認する（Ｓ３２０）。
【００４６】
その後、情報処理装置１は、新しく接続されたＵＳＢデバイスの有無を判断し（Ｓ３２５）、新しく接続されたＵＳＢデバイスが無い場合は（Ｓ３２５：無い）、今回切断されたＵＳＢデバイスの有無を判断する（Ｓ３３０）。そして、今回切断されたＵＳＢデバイスが無い場合は（Ｓ３３０：無い）、Ｓ３１５へ戻る。これにより、Ｓ３１５〜Ｓ３３０は、概ね６秒ごとに繰り返し実行されることになる。
【００４７】
そして、このようなＳ３１５〜Ｓ３３０の繰り返し処理が実行される中で、新しく接続されたＵＳＢデバイスが有った場合（Ｓ３２５：有る）、情報処理装置１は、新規ＵＳＢデバイスを上述のＵＤＴＢに登録し、デバイスドライバをシステムに登録する（Ｓ３３５）。このＳ３３５は、詳しくは図５に示すような処理となる。
【００４８】
すなわち、情報処理装置１は、図５に示すように、まず、ＵＳＢデバイスの種類を判断する（Ｓ４０５）。ここで、ＵＳＢストレージクラスのデバイスであると判断されれば（Ｓ４０５：ＵＳＢストレージクラス）、仮想ＳＣＳＩ−Ｉ／Ｆ（仮想ＳＣＳＩホストアダプタ）をシステムに登録し、“ＳＣＳＩｍ”のシンボルをシステムから与えられる（Ｓ４１０）。なお、上記“ＳＣＳＩｍ”中にある“ｍ”は「０」からの通し番号で、切断後は再利用される番号である。
【００４９】
また、情報処理装置１は、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ”に情報公開手段をシステム登録、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／ｎ”のシンボルをシステムから与えられる（Ｓ４１５）。なお、上記“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／ｎ”中にある“ｎ”は「０」からの通し番号で、こちらは切断後の再利用はされない番号である。
【００５０】
一方、Ｓ４０５において、ＵＳＢストレージクラス以外のデバイスであると判断されれば（Ｓ４０５：ＵＳＢストレージクラス以外）、情報処理装置１は、各ＵＳＢデバイス用の登録処理を行う（Ｓ４２０）。このＳ４２０の処理は、ＵＳＢデバイスの種類によってさらに何通りかの処理にわかれるが、この処理の詳細は本発明の要部ではないので、これ以上の説明は省略する。
【００５１】
以上説明したようなＳ４０５〜Ｓ４２０の処理（図５参照）を終えると、図４に示したＳ３３５を終えたことになり、その場合、情報処理装置１は、今回接続の全ＵＳＢデバイスの処理が終了したか否かを判断する（Ｓ３４０）。
【００５２】
ここで、今回接続の全ＵＳＢデバイスの処理が終了していなければ（Ｓ３４０：いいえ  次のＩ／Ｆへ）、Ｓ３３５へと戻ることにより、残りのＵＳＢデバイスについてもＳ３３５を繰り返す。そして、今回接続の全ＵＳＢデバイスの処理が終了したら（Ｓ３４０：はい）、Ｓ３３０へと進む。
【００５３】
また、Ｓ３１５〜Ｓ３３０の繰り返し処理が実行される中で、今回切断されたＵＳＢデバイスが有った場合（Ｓ３３０：有る）、情報処理装置１は、切断ＵＳＢデバイスをＵＤＴＢから削除し、そのＩ／Ｆに接続されているドライブをシステムから削除する（Ｓ３４５）。このＳ３４５は、詳しくは図６に示すような処理となる。
【００５４】
すなわち、情報処理装置１は、図６に示すように、まず、ＵＳＢデバイスの種類を判断する（Ｓ５０５）。ここで、ＵＳＢストレージクラスのデバイスであると判断されれば（Ｓ５０５：ＵＳＢストレージクラス）、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／ｎ”の情報公開手段をシステムから削除する（Ｓ５１０）。なお、既に説明した通り、この番号“ｎ”が再利用されることはない。
【００５５】
また、“ＳＣＳＩｍ”の仮想ＳＣＳＩ−Ｉ／Ｆ（仮想ＳＣＳＩホストアダプタ）をシステムから削除する（Ｓ５１５）。なお、既に説明した通り、この番号“ｍ”は以降も必要に応じて再利用されることがある。
【００５６】
一方、Ｓ５０５において、ＵＳＢストレージクラス以外のデバイスであると判断されれば（Ｓ５０５：ＵＳＢストレージクラス以外）、情報処理装置１は、各ＵＳＢデバイス用の削除処理を行う（Ｓ５２０）。このＳ５２０の処理は、ＵＳＢデバイスの種類によってさらに何通りかの処理にわかれるが、この処理の詳細は本発明の要部ではないので、これ以上の説明は省略する。
【００５７】
以上説明したようなＳ５０５〜Ｓ５２０の処理（図６参照）を終えると、図４に示したＳ３４５を終えたことになり、その場合、情報処理装置１は、今回切断の全ＵＳＢデバイスの処理が終了したか否かを判断する（Ｓ３５０）。ここで、今回切断の全ＵＳＢデバイスの処理が終了していなければ（Ｓ３５０：いいえ  次のＩ／Ｆへ）、Ｓ３４５へと戻ることにより、残りのＵＳＢデバイスについてもＳ３４５を繰り返す。そして、今回切断の全ＵＳＢデバイスの処理が終了したら（Ｓ３４０：はい）、Ｓ３１５へと戻る。
【００５８】
さて、以上説明したような処理が、Ｓ１２０によって開始される処理となるが、ここで再び図２に戻り、Ｓ１２０を終えた時点からの説明を続ける。Ｓ１２０を終えると、情報処理装置１では、電源ＯＮ時に接続されているＵＳＢデバイスが一括で認識される（Ｓ１２５）。このような認識が行われるのは、上記Ｓ１２０により、ＵＳＢ接続監視の処理を開始しているからである。
【００５９】
そして、認識されたＵＳＢデバイスの中に、ＵＳＢストレージデバイスが有る場合は、その中に存在するドライブがＳＣＳＩドライブと認識される（Ｓ１３０）。このような認識が行われるのは、上記Ｓ１１５により、ＳＣＳＩドライブ接続監視の処理を開始しているからである。
【００６０】
続いて、情報処理装置１では、カーネルの初期化を終了し、最初のスクリプトが実行される（Ｓ１３５）。そして、メインで使用するボリュームのマウント処理を実行する（Ｓ１４０）。
【００６１】
このＳ１４０は、詳しくは図７に示すような処理となる。すなわち、図７に示す処理を開始すると、情報処理装置１は、“／ｄｅｖ／ｈｄａ１”のファイルシステムを、所定のマウントポイント“／ｍａｉｎ”にマウントする（Ｓ６０５）。ここで、ドライブ名が“ｈｄａ”になること、および、ファイルシステム名が“ｈｄａ１”になることは、情報処理装置１の構成上、事前に決まっている事項である。
【００６２】
そして、Ｓ６０５を終えたら、マウント成功か否かを判断する（Ｓ６１０）。ここで、マウント成功であれば（Ｓ６１０：成功）、マウントしたボリューム内のスクリプト“／ｍａｉｎ／ｐｒｏｇ／ｓｔａｒｔｕｐ．ｓｈ”を実行する（Ｓ６１５）。
【００６３】
一方、Ｓ６１０において、マウント失敗であれば（Ｓ６１０：成功）、このままではスクリプト“／ｍａｉｎ／ｐｒｏｇ／ｓｔａｒｔｕｐ．ｓｈ”を実行できず、情報処理装置１は通常通りに起動できなくなる。
【００６４】
そこで、この場合は、バックアップ動作用ＵＳＢポートからＳＣＳＩドライブ名を割り出す（Ｓ６２０）。このＳ６２０は、詳しくは図８に示すような処理となる。すなわち、図８に示す処理を開始すると、情報処理装置１は、まず、“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ”の下のファイルを検索する（Ｓ７０５）。
【００６５】
そして、ファイルが有るかどうかを判断する（Ｓ７１０）。ここで、ファイルが有る場合は（Ｓ７１０：はい）、見つかったファイルをリードする（Ｓ７１５）。ここでリード対象となるファイル“／ｐｒｏｃ／ｓｃｓｉ／ｕｓｂ−ｓｔｏｒａｇｅ／ｎ”は、ＵＳＢストレージデバイスおよびＵＳＢポートに関する情報を提供する情報公開手段である。
【００６６】
Ｓ７１５では、上記ファイルをリードすることにより、ＵＳＢポートの情報やＵＳＢストレージデバイスの情報などを取得することができる。また、こうしたＵＳＢポートの情報やＵＳＢストレージデバイスの情報などは、一般的なＬｉｎｕｘ（登録商標）でも取得可能な情報であるが、この情報処理装置１において、Ｓ７１５では、ＵＳＢストレージデバイスに割り当てられたドライブ名をも取得することができる。
【００６７】
このドライブ名は、上記Ｓ２３５の処理により、ＳＣＳＩ−Ｉ／Ｆ毎に用意された記憶領域に格納されたドライブ名そのものである。一般的なＬｉｎｕｘ（登録商標）の場合、ＳＣＳＩ−Ｉ／Ｆを利用する際に、ＳＣＳＩ−Ｉ／Ｆにドライブ名が通知されることはないので、ＳＣＳＩ−Ｉ／Ｆに接続されたＳＣＳＩドライブに、どのようなドライブ名が割り当てられているのかを、ＳＣＳＩ−Ｉ／Ｆ側で知る術はない。
【００６８】
しかし、この情報処理装置１では、上述の通り、リードキャパシティコマンドが発行される毎に、コマンドの発行対象となったドライブ名がＳＣＳＩ−Ｉ／Ｆ側に伝達されて、そのドライブ名がＳＣＳＩ−Ｉ／Ｆ側の記憶領域に残される。
【００６９】
したがって、この記憶領域に残された情報を見れば、ＳＣＳＩ−Ｉ／Ｆに接続されたＳＣＳＩドライブに、どのようなドライブ名が割り当てられているのかを、ＳＣＳＩ−Ｉ／Ｆ側で知ることができる。
【００７０】
また、ＳＣＳＩ−Ｉ／Ｆに複数のＳＣＳＩドライブが接続されている場合、上記ＳＣＳＩ−Ｉ／Ｆ側の記憶領域には、その内の一つのＳＣＳＩドライブに割り当てられた名前だけしか残されない。しかし、ＵＳＢストレージデバイスの場合、一つのＵＳＢストレージデバイスに対して一つの仮想ＳＣＳＩ−Ｉ／Ｆが生成される。そのため、このＳＣＳＩ−Ｉ／Ｆに対応する記憶領域に残されるのは、必ず一つのドライブ名のみとなるので、ＵＳＢストレージデバイスに割り当てられたドライブ名を問題なく特定できる。
【００７１】
つまり、Ｓ７１５で取得した情報を見れば、一般的なＬｉｎｕｘ（登録商標）同様、その情報がどのＵＳＢポートに対応する情報なのかを特定できる。しかも、一般的なＬｉｎｕｘ（登録商標）とは異なり、その情報がどのようなドライブ名に対応する情報なのかをも特定できるのである。
【００７２】
そこで、Ｓ７１５を終えたら、情報処理装置１は、まず、接続ポートを判断して（Ｓ７２０）、内部ＵＳＢポート２１に対応する情報か否かを確認する。ここで、内部ＵＳＢポート２１に対応する情報でなければ（Ｓ７２０：ＵＳＢポートが違う）、Ｓ７１０へと戻る。ちなみに、このようにＳ７１０へと戻ることになるのは、外部ＵＳＢポート２２，２３のいずれかにもＵＳＢストレージデバイスが接続されている場合である。
【００７３】
一方、Ｓ７２０において、内部ＵＳＢポート２１に対応する情報であれば（Ｓ７２０：探していたＵＳＢポート）、最後にリードキャパシティを実行したドライブ名を取得する（Ｓ７２５）。すなわち、Ｓ７１５でリードした情報の中からドライブ名を抽出する。
【００７４】
このドライブ名は、“ｓｄａ”，“ｓｄｂ”，…といったドライブ名であるが、その末尾の文字“ａ”，“ｂ”，…は、どのような文字になるのか保証がない。具体的には、内部ＵＳＢポート２１にＵＳＢストレージデバイス２５が接続され、さらに外部ＵＳＢポート２２，２３にもＵＳＢストレージデバイスが接続されている場合、先に認識されたデバイスにはドライブ名“ｓｄａ”が付与される。また、その後に認識されたデバイスにはドライブ名“ｓｄｂ”が付与される。しかし、どのデバイスが先に認識されるかは不定であるため、例えばドライブ名“ｓｄａ”が付与されたデバイスがＵＳＢストレージデバイス２５なのかどうかは不定となる。
【００７５】
この点、Ｓ７１０〜Ｓ７２０により、内部ＵＳＢポート２１に対応する情報を探し出し、Ｓ７２５により、ドライブ名を抽出すれば、内部ＵＳＢポート２１に接続されたＵＳＢストレージデバイス２５に割り当てられたドライブ名を確実に取得できるのである。
【００７６】
なお、Ｓ７１０で、所期のＵＳＢポートが見つかる前にリード対象となるファイルが無くなった場合は（Ｓ７１０：いいえ）、図８に示す処理を終了する。これは、内部ＵＳＢポート２１にＵＳＢストレージデバイス２５が接続されていない場合の処理に相当する。
【００７７】
さて、以上説明したような処理を終えると、図７に示したＳ６２０の処理を終えたことになるので、その場合、情報処理装置１は、“／ｄｅｖ／ｓｄｘ１”のファイルシステムを、所定のマウントポイント“／ｍａｉｎ”にマウントする（Ｓ６２５）。ここで、“ｓｄｘ”は、Ｓ７２５で取得したドライブ名である。つまり、Ｓ７２５までの処理で割り出したＳＣＳＩドライブのドライブ名を利用して、ＳＣＳＩドライブ上のパーティション（ファイルシステム）を指定し、そのパーティションを“／ｍａｉｎ”にマウントしているのである。
【００７８】
そして、Ｓ６２５を終えたら、マウントに成功したか否かを判断し（Ｓ６３０）、成功していれば（Ｓ６３０：成功）、既に説明したＳ６１５へと進むことにより、マウントしたボリューム内のスクリプト“／ｍａｉｎ／ｐｒｏｇ／ｓｔａｒｔｕｐ．ｓｈ”を実行する（Ｓ６１５）。また、マウントに失敗した場合は（Ｓ６３０：失敗）、図７に示す処理を終了する。
【００７９】
さて、以上説明したような処理を終えると、図２に示すＳ１４０を終えたことになるので、続いて、情報処理装置１では、メインで使用するボリューム内のスタートアッププログラムが起動する（Ｓ１４５）。すなわち、“／ｍａｉｎ”に“ｈｄａ１”または“ｓｄｘ１”のいずれがマウントされるかは、状況によって分かれるものの、いずれにしても、いずれかのボリューム内のスタートアッププログラムが起動するのである。
【００８０】
そして、情報処理装置１では、システムが専用装置として動作し（Ｓ１５０）、以降は、利用者からのシャットダウン指示が有るまで（Ｓ１５５：いいえ）、専用装置としての動作を継続する。一方、利用者からのシャットダウン指示があった場合は（Ｓ１５５：はい）、シャットダウン処理を実行し（Ｓ１６０）、電源ＯＦＦに至る。
【００８１】
［３．動画エンコードアプリケーション処理の説明］
次に、上記情報処理装置１が実行する動画エンコードアプリケーション処理について説明する。なお、図９は、動画エンコードアプリケーション処理のフローチャートである。また、図１３は、エンコードシステム１００が実行する処理のタイムチャートである。
【００８２】
本処理は、スタートアッププログラムが起動してシステムが専用装置として動作し始めた際に（Ｓ１５０）、利用者からのシャットダウン指示が有るまで（Ｓ１５５：いいえ）繰り返し実行される。
【００８３】
情報処理装置１では、まず、動画エンコードボードを探す処理を実行する（Ｓ８０５）。この動画エンコードボードを探す処理の処理内容は、詳しくは図１０に示すような処理となる。
【００８４】
すなわち、図１０に示す動画エンコードボードを探す処理を開始すると、情報処理装置１は、まず、対象ドライブを“／ｄｅｖ／ｓｄａ”に設定する（Ｓ９０５）。そして、情報処理装置１は、対象ドライブをオープンにする（Ｓ９１０）。なお、オープンエラーの場合には、情報処理装置１は、次の対象ドライブに設定するための処理を行うために後述するＳ９３５に移行する。
【００８５】
続いて、情報処理装置１は、セクタ“０”をリードする（Ｓ９１５）。なお、リードエラーの場合には、情報処理装置１は、次の対象ドライブに設定するための処理を行うために後述するＳ９３５に移行する。
【００８６】
続いて、情報処理装置１は、パーティションテーブルを確認し、パーティションが無い状態のパーティションテーブルであるか否かを判断する（Ｓ９２０）。パーティションが無い状態のパーティションテーブルではない、すなわちパーティションがある状態のパーティションテーブルであると判断された場合には（Ｓ９２０：いいえ）、情報処理装置１は、次の対象ドライブに設定するための処理を行うために後述するＳ９３５に移行する。
【００８７】
一方、パーティションが無い状態のパーティションテーブルであると判断された場合には（Ｓ９２０：はい）、情報処理装置１は、セクタ“０ｘ００ｆ３００００”をリードする（Ｓ９２５）。すなわち、ステータスをリードする。
【００８８】
続いて、情報処理装置１は、セクタデータの３バイト目以降がチェックデータであるか否かを判断する（Ｓ９３０）。セクタデータの３バイト目以降がチェックデータである場合には（Ｓ９３０：はい）、情報処理装置１は、動画エンコードボードが見つかったと判断して本処理を終了する。
【００８９】
一方、セクタデータの３バイト目以降がチェックデータではない場合には（Ｓ９３０：いいえ）、情報処理装置１は、対象ドライブが“／ｄｅｖ／ｓｄｚ”であるか否かを判断する。なお、 “ｓｄｚ”の中にある“ｚ”は最後尾のドライブであることを示す。対象ドライブが“／ｄｅｖ／ｓｄｚ”ではない場合には（Ｓ９３５：いいえ）、情報処理装置１は、対象ドライブを次のドライブに変更する（Ｓ９４０）。一例を挙げると、“／ｄｅｖ／ｓｄａ”を“／ｄｅｖ／ｓｄｂ”に変更したり“／ｄｅｖ／ｓｄｂ”を“／ｄｅｖ／ｓｄｃ”に変更したりするといった具合である。そして、情報処理装置１は、Ｓ９４０にて対象ドライブに設定したドライブが動画エンコードボードであるか否かを確認するためにＳ９１０に戻る。
【００９０】
一方、対象ドライブが“／ｄｅｖ／ｓｄｚ”である場合には（Ｓ９３５：はい）、全てのドライブを確認したがセクタデータの３バイト目以降がチェックデータではなかったため、情報処理装置１は、動画エンコードボードが見つからなかったと判断して本処理を終了する。
【００９１】
さて、以上説明したような処理がＳ８０５によって開始される処理となるが、ここで再び図９に戻り、Ｓ８０５を終えた時点からの説明を続ける。Ｓ８０５を終えると、情報処理装置１では、このＳ８０５を実行した結果、動画エンコードボードが見つからなかったら、本処理をエラー終了する。一方、動画エンコードボードが見つかったら、情報処理装置１は、動画エンコードボードの設定ファイルからエンコード設定をリードする（Ｓ８１０）。
【００９２】
続いて、情報処理装置１は、セクタ“０ｘ００ｆ４ｘｘｘｘ”をリードして、その内容に従ってエンコード設定を変更する（Ｓ８１５）。
【００９３】
続いて、情報処理装置１は、ユーザからの操作があるまで待機し（Ｓ８２０：いいえ）、ユーザからの操作があったときには（Ｓ８２０：はい）、ユーザからの操作の内容を判断する（Ｓ８２５）。
【００９４】
まず、ユーザからの操作の内容が終了を要求する旨である場合には（Ｓ８２５：終了要求）、本処理を終了する。
【００９５】
また、ユーザからの操作の内容が設定変更を要求する旨である場合には（Ｓ８２５：設定変更）、情報処理装置１は、設定ファイルに変更内容を書き込み（Ｓ８３０）、セクタ“０ｘ００ｆ４ｘｘｘｘ”をリードして、その内容に従ってエンコード設定を変更し、Ｓ６２５に戻る。
【００９６】
また、ユーザからの操作の内容が録画開始を要求する旨である場合には（Ｓ８２５：録画開始）、情報処理装置１は、“ｅｄｓｅｃ”（エンコードデータセクタ）を“０ｘ００１０００００”とし（Ｓ８４０）、セクタ“０ｘ００ｆ１００００”をリードしてエンコード開始を指示する（Ｓ８４５）。さらに、ユーザから処理の終了を要求する旨の操作があったか否かを判断する（Ｓ８５０）。
【００９７】
ユーザから処理の終了を要求する旨の操作があった場合には（Ｓ８５０：有り）、情報処理装置１は、セクタ“ｅｄｓｅｃ”をリードしてエンコード結果をリードし、そのリードしたエンコード結果をファイルに格納し（Ｓ８７０）、セクタ“０ｘ００ｆ２００００”をリードしてエンコード終了を指示し（Ｓ８７５）、次のユーザからの操作があるまで待機するためにＳ８２０に戻る。一方、ユーザから処理の終了を要求する旨の操作がない場合には（Ｓ８５０：無し）、情報処理装置１は、セクタ“ｅｄｓｅｃ”をリードしてエンコード結果をリードし、そのリードした分だけ“ｅｄｓｅｃ”の値を増加させ、リードしたエンコード結果をファイルに格納する（Ｓ８５５）。そして、セクタ“０ｘ００ｆ３００００”をリードしてステータスをリードし（Ｓ８６０）、さらに、リードしたステータスからエラーが発生したか否かを判断する（Ｓ８６５）。
【００９８】
エラーが発生したと判断された場合には（Ｓ８６５：あり）、情報処理装置１は、エンコード終了を指示するためにＳ８７５に移行する。一方、エラーが発生していないと判断された場合には（Ｓ８６５：なし）、ユーザから処理の終了を要求する旨の操作を待つためにＳ８５０に戻る。
【００９９】
［４．ＳＣＳＩコマンド処理の説明］
次に、上記エンコード装置が実行するＳＣＳＩコマンド処理について説明する。
【０１００】
図１１はＳＣＳＩコマンド処理のフローチャートである。
【０１０１】
エンコード装置２７では、まず、ＰＣからＳＣＳＩコマンドを到着したか否かを判断する（Ｓ１００５）。ＰＣからＳＣＳＩコマンドを到着していない場合には（Ｓ１００５：来ない）、ＰＣからＳＣＳＩコマンドを到着るまで待機し、情報処理装置１からのＳＣＳＩコマンドを到着した場合には（Ｓ１００５：来た）、その到着したコマンドの内容を判断する（Ｓ１０１０）。
【０１０２】
まず、到着したコマンドの内容がリードキャパシティである場合には、最終セクタ番号“０ｘ００ｆｆｆｆｆｆ”であり、容量が８Ｇバイトであることを示すものであると判断し（Ｓ１０２０）、次のＳＣＳＩコマンドが到着するまで待機するためにＳ１００５に戻る。
【０１０３】
また、到着したコマンドの内容がセクタライトである場合には、書き込み禁止エラーであることを示すものであると判断し（Ｓ１０２５）、次のＳＣＳＩコマンドが到着するまで待機するためにＳ１００５に戻る。
【０１０４】
また、到着したコマンドの内容がモードセンスである場合には、書き込み禁止のエラーが挿入されていることを示すものであると判断し（Ｓ１０３０）、次のＳＣＳＩコマンドが到着するまで待機するためにＳ１００５に戻る。
【０１０５】
また、到着したコマンドの内容が上述の各内容以外（その他）である場合には、各コマンドに応答するよう指示するものであると判断し（Ｓ１０３５）、次のＳＣＳＩコマンドが到着するまで待機するためにＳ１００５に戻る。
【０１０６】
また、到着したコマンドの内容がセクタリードである場合には、エンコード装置は、リードアドレスを判断する（Ｓ１０１５）。
【０１０７】
まず、リードアドレスが“０ｘ００００００００”である場合には、エンコード装置は、パーティションが無い状態のパーティションテーブルを返信し（Ｓ１０４０）、次のＳＣＳＩコマンドが到着するまで待機するためにＳ１００５に戻る。
【０１０８】
また、リードアドレスが“０ｘ００１０００００”〜“０ｘ００ｅｆｆｆｆｆ”である場合には、エンコード装置は、エンコード結果のデータをセクタデータとして返信し（Ｓ１０４５）、次のＳＣＳＩコマンドが到着するまで待機するためにＳ１００５に戻る。なおこの場合、１データの上限が７Ｇバイトとなる。
【０１０９】
また、リードアドレスが“０ｘ００ｆｘｘｘｘｘ”である場合には、エンコード装置は、リードアドレスのうちの“ｘｘｘｘｘ”の部分に応じて動作する（Ｓ１０５０）。この処理の処理内容は、詳しくは図１２に示すような処理となる。すなわち、図１２に示す処理を開始すると、エンコード装置は、まず、セクタアドレスを判断する（Ｓ１１０５）。
【０１１０】
まず、セクタアドレスが“０ｘ００ｆ１００００”である場合には、エンコードを開始し（Ｓ１１１０）、コール元に戻る。このとき、エラーコードをセクタデータの１バイト目または２バイト目で返信する。
【０１１１】
また、セクタアドレスが“０ｘ００ｆ２００００”である場合には、エンコードを終了し（Ｓ１１１５）、コール元に戻る。このとき、エラーコードをセクタデータの１バイト目または２バイト目で返信する。
【０１１２】
また、セクタアドレスが“０ｘ００ｆ３００００”である場合には、ステータスをセクタデータの１バイト目または２バイト目で返信し（Ｓ１１２０）、コール元に戻る。
【０１１３】
また、セクタアドレスが“０ｘ００ｆ４ｘｘｘｘｘ”である場合には、セクタアドレスのうちの“ｘｘｘｘｘ”の部分に従ってエンコード設定を変更し（Ｓ１１２５）、コール元に戻る。
【０１１４】
また、セクタアドレスが上記内容以外（その他）である場合には、全て“０ｘ００”となっているセクタデータを返信し（Ｓ１１３０）、コール元に戻る。
【０１１５】
さて、以上説明したような処理がＳ１０５０によって開始される処理となるが、ここで再び図１１に戻り、Ｓ１０５０を終えた時点からの説明を続ける。Ｓ１０５０を終えると、エンコード装置は、次のＳＣＳＩコマンドが到着するまで待機するためにＳ１００５に戻る。なお、必要な場合にはセクタデータとして実行結果を返信する。
【０１１６】
また、リードアドレスが上記内容以外（その他）である場合には、全て“０ｘ００”となっているセクタデータを返信し（Ｓ１０５５）、次のＳＣＳＩコマンドが到着するまで待機するためにＳ１００５に戻る。
【０１１７】
［５．実施形態の効果］
このように本実施形態のエンコードシステム１００によれば、ＵＳＢストレージクラスにおいてはＣＰＵに対して低負荷で大量のデータを転送できるよう仕様が標準規格として定められていることを利用して、エンコード装置２７が、情報処理装置１との接続を確立する際に、ＵＳＢ規格で規定されたＵＳＢストレージクラスのデバイスであると、情報処理装置１が備えるＯＳに認識させるとともに、情報処理装置１からのセクタ読み込みコマンドが伝送されてきた場合に、定義処理として、データと解釈したセクタ番号それぞれに予め設定された情報のうち、セクタ読み込みコマンド中に含まれるセクタ番号に対応する情報を選択して情報処理装置１へ返信することにより、ＵＳＢインターフェース２０を介して接続する情報処理装置１のＣＰＵ１１に対して低負荷で大量の動画エンコードデータを転送できる。
【０１１８】
また  本実施形態のエンコードシステム１００によれば、既存のリソースを利用できるので、ＣＰＵ種類毎に専用のドライバを開発する必要がない。また  本実施形態のエンコードシステム１００によれば、ＵＳＢストレージクラスのデバイスに対応するＯＳが多く存在するため、対応ＯＳが多いという利点がある。
【０１１９】
また、本実施形態のエンコードシステム１００によれば、エンコード装置２７が、データストレージ機能を有することを情報処理装置１が備えるＯＳに認識させるための情報として、ＳＣＳＩ規格で規定されたリムーバブルＨＤである旨の情報およびリムーバブルＨＤにパーティションが設定されておらず、且つ書き込み禁止である旨の情報を出力する。このことにより、エンコード装置２７が自らを、パーティションが設定されていない状態且つ書き込み禁止状態であるメディアが挿入されているカードリーダなどの読込装置として、情報処理装置１が備えるＯＳに認識させることができる。このことにより、ディスクとして動作するための容量が不要であるから、パーティションが設定されなくてもよく、記憶容量が少なくてもよい。また、ディスクとして認識されないことから情報処理装置１が備えるＯＳからのアクセスを受けず、誤動作を生じにくくすることができる。つまり、パーティションが設定されていないことにより、ユーザ操作でデバイス側に不要な負担が掛からず、ファイルシステムとして動作可能な最低限の記憶容量も必要無くなるという利点がある。また、リムーバブルＨＤへの書き込みを禁止にした場合には、予約したエリアは、ユーザが操作してもファイルシステムエリアに組み入れられる心配が無い。また、パーティション追加やパーティション切り直しは、セクタ“０”への書き込みとなるため、リムーバブルＨＤへの書き込みを禁止にすればこれらは失敗するから問題がない。
【図面の簡単な説明】
【０１２０】
【図１】エンコードシステムの構成、情報処理装置およびエンコード装置２７の各内部構造を示すブロック図。
【図２】情報処理装置の電源ＯＮに伴って実行される処理のフローチャート。
【図３】ＯＳ内ＳＣＳＩドライブ接続監視のフローチャート。
【図４】ＯＳ内ＵＳＢデバイス接続監視のフローチャート。
【図５】Ｓ３３５の詳細を示すフローチャート。
【図６】Ｓ３４５の詳細を示すフローチャート。
【図７】Ｓ１４０の詳細を示すフローチャート。
【図８】Ｓ６２０の詳細を示すフローチャート。
【図９】動画エンコードアプリケーション処理のフローチャート。
【図１０】Ｓ８０５の詳細を示すフローチャート
【図１１】ＳＣＳＩコマンド処理のフローチャート。
【図１２】Ｓ１０５０の詳細を示すフローチャート
【図１３】エンコードシステムが実行する処理のタイムチャート。
【符号の説明】
【０１２１】
１…情報処理装置、１１…ＣＰＵ、１３…ＲＯＭ、１５…ＲＡＭ、１７…ハードディスク装置、２０…ＵＳＢインターフェース、２３…外部ＵＳＢポート、２７…エンコード装置、２７ａ…ＵＳＢインターフェース、２７ｂ…ＣＰＵ、２７ｃ…ＲＯＭ、２７ｄ…ＲＡＭ、２７ｅ…ＭＰＥＧエンコーダ、２７ｆ…Ｉ／Ｃカードスロット、３１…筐体、１００…エンコードシステム
【図１】
2010157819.tif 000003
【図２】
2010157819.tif 000004
【図３】
2010157819.tif 000005
【図４】
2010157819.tif 000006
【図５】
2010157819.tif 000007
【図６】
2010157819.tif 000008
【図７】
2010157819.tif 000009
【図８】
2010157819.tif 000010
【図９】
2010157819.tif 000011
【図１０】
2010157819.tif 000012
【図１１】
2010157819.tif 000013
【図１２】
2010157819.tif 000014
【図１３】
2010157819.tif 000015