JP2007151109A - 多重客体伝送プロトコル支援方法及びその装置 - Google Patents

Abstract

【課題】 多重客体伝送プロトコル支援方法及びその装置を提供する。
【解決手段】 所定のアプリケーションの要請によって第１客体伝送プロトコルに基づいた第１要請メッセージを生成する段階、生成された第１要請メッセージをスレーブデバイスが支援する第２客体伝送プロトコルに基づいた第２要請メッセージに変換する段階、及び第２要請メッセージをスレーブデバイスに伝送する段階を含む。
【選択図】 図２

Description

本発明は、客体伝送プロトコルに係り、さらに詳細には、多重客体伝送プロトコル支援方法及びその装置に関する。

相異なる２つの装置間にデータを伝送するために使われる方法であって、ファイルシステム間の相互互換方式やネットワークプロトコルを使用する方式がある。しかし、ファイルシステムやネットワークプロトコルなどを用いた方法は、装置や伝送媒体に依存的である。

一方、両装置間のデータを伝送して制御するために共通の通信方式が使われることもあるが、このような共通の通信方式を使用すれば、前述したファイルシステムやネットワークプロトコルより上位レベルで装置や伝送媒体に独立的にデータを伝送しうる。このような共通の通信方式の例として、ＭＴＰ（メディアトランスファプロトコル）やＰＴＰ（ピクチャトランスファプロトコル）を挙げられる。これらの特徴を説明すれば、相手の装置を制御しうる汎用の方法を定義しているために、装置依存的な方法を使用せずとも、他の装置を制御する方案が提供される。ところが、演算能力や保存能力が比較的低い低性能の装置は、ＭＴＰやＰＴＰのような装置独立的なプロトコルを使用するのに無理がある。

特に、最近には、ＤＲＭ分野で暗号化されたデジタルコンテンツや権利客体の保管及び配布を簡便にするために、メモリスティックやマルチメディアカード（ＭＭＣ）のような携帯用保存装置を使用する技術が普及している。ところが、携帯用保存装置は、デジタルコンテンツを再生させるデバイスに比べて演算能力が非常に低いために、デバイスで駆動されるアプリケーションがＰＴＰやＭＴＰのような装置独立的なプロトコルを使用する場合、携帯用保存装置がデバイスのアプリケーションと適切な通信を行いにくい問題点がある。

本発明は、客体伝送プロトコルに関係なく、低性能装置との客体処理作業を円滑にするところにその目的がある。

本発明の技術的課題は、以上で言及した技術的課題に制限されず、言及されていない他の技術的課題は下の記載から当業者に明確に理解されうる。

前記目的を達成するための本発明の実施形態による多重客体伝送プロトコル支援方法は、所定のアプリケーションの要請によって第１客体伝送プロトコルに基づいた第１要請メッセージを生成する段階、前記生成された第１要請メッセージをスレーブデバイスが支援する第２客体伝送プロトコルに基づいた第２要請メッセージに変換する段階、及び前記第２要請メッセージを前記スレーブデバイスに伝送する段階を含む。

前記目的を達成するための本発明の実施形態によるマスターデバイスは、第１客体伝送プロトコルに基づいた第１要請メッセージを生成するアプリケーションモジュール、前記生成された第１要請メッセージをスレーブデバイスが支援する第２客体伝送プロトコルに基づいた第２要請メッセージに変換する変換モジュール、及び前記第２要請メッセージを前記スレーブデバイスに伝送するデバイスインターフェースモジュールを備える。

その他の実施例の具体的な事項は詳細な説明及び図面に含まれている。

本発明の多重客体伝送プロトコル支援方法及びその装置によれば、客体伝送プロトコルに関係なく低性能装置との客体処理作業を円滑にできる。

本発明の利点及び特徴、そしてこれを達成する方法は添付された図面に基づいて詳細に後述されている実施例を参照すれば明確になる。しかし、本発明は以下で開示される実施例に限定されるものではなく、この実施例から外れて多様な形に具現でき、本明細書で説明する実施例は本発明の開示を完全にし、本発明が属する技術分野で当業者に発明の範ちゅうを完全に報せるために提供されるものであり、本発明は請求項及び発明の詳細な説明により定義されるだけである。一方、明細書全体に亙って同一な参照符号は同一な構成要素を示す。

以下、添付された図面を参照して本発明の望ましい実施形態を詳細に説明する。

まず、本発明で使われる用語について概略的に説明する。用語の説明は、本発明の理解を助けるためのものである。したがって、本発明の詳細な説明において明示的に限定しない限り、以下で説明される用語が、本発明の技術的思想を限定する意味で使われるものではないという点に注意せねばならない。

−マスターデバイス
マスターデバイスは、スレーブデバイスと連結可能であり、特定客体の伝送、検索、獲得などのためにスレーブデバイスに質疑を伝送するデバイスである。マスターデバイスの例として、携帯電話、ＰＤＡ、ＭＰ３プレーヤーなどの携帯用コンテンツ再生装置や、デスクトップコンピュータ、デジタルＴＶのような固定型コンテンツ再生装置を挙げられる。マスターデバイスがＤＲＭ機能を行う場合、マスターデバイスは、権利客体を消費してコンテンツを再生させうる。

−スレーブデバイス
スレーブデバイスは、フラッシュメモリのようにデータの読出し、書込み、及び消去可能な性質を有する不揮発性メモリを含み、データについての所定の演算能力を有し、マスターデバイスとの連結及び分離が容易な保存装置を意味する。望ましくは、スレーブデバイスは、スマートメディア、メモリスティック、ＣＦカード、ＸＤカード、マルチメディアカードのような携帯用保存装置であり得る。しかし、本発明は、これに限定されず、スレーブデバイスは、マスターデバイスと類似した類型の装置であり得る。スレーブデバイスは、マスターデバイスから伝送された質疑に対する作業を行って応答しうる。

−客体（ｏｂｊｅｃｔ）
客体は、デバイスに保存され、デバイス間に伝送しうる多様な形態のデータであり、動映像、静止映像、オーディオ、ゲームなどの各種コンテンツ、テキストや文書、ＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）で使われる権利客体（Ｒｉｇｈｔｓ Ｏｂｊｅｃｔ）などその種類に制限されない。

−客体伝送プロトコル
客体伝送プロトコルは、マスターデバイスやスレーブデバイスが客体処理作業（例えば、客体の伝送、検索、獲得など）を行うために使用するプロトコルである。客体伝送プロトコルは、装置依存的な客体伝送プロトコルと装置独立的な客体伝送プロトコルとに区分されうる。

−モジュール
モジュールは、ソフトウェアまたはＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）または注文型半導体（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ；ＡＳＩＣ）のようなハードウェア構成要素を意味し、モジュールは所定の役割を行う。しかし、モジュールはソフトウェアまたはハードウェアに限定されるものではない。モジュールは、アドレッシング可能な保存媒体に存在すべく構成されても良く、１つまたはそれ以上のプロセッサーを実行させるように構成されても良い。したがって、一例としてモジュールは、ソフトウェア構成要素、客体指向ソフトウェア構成要素、クラス構成要素及びタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。構成要素とモジュールから提供される機能は、より少数の構成要素及びモジュールで結合されるか、追加的な構成要素とモジュールにさらに分離されうる。

以上で説明されていない用語は、以下で必要に応じて別途に説明する。

図１は、本発明の一実施形態によるマスターデバイス１００とスレーブデバイス２００との概略的なスタック構造を示す図面である。

図示されたマスターデバイス１００の構造は、物理的装置１０４、物理的装置に対する接近を担当する装置ドライバ１０３、スレーブデバイス２００に対するメッセージやデータ送受信を担当する伝送階層１０２、及びスレーブデバイス２００に客体送信や客体受信を要請してスレーブデバイス２００から伝送された応答を処理するアプリケーション１０１を備える。

スレーブデバイス２００の構造は、物理的装置２０４、装置ドライバ２０３、伝送階層２０２、及びアプリケーション２０１を備え、これらは各々マスターデバイス２００の物理的装置１０４、装置ドライバ１０３、伝送階層１０２、及びアプリケーション１０１と対応する役割を行う。しかし、マスターデバイス１００とスレーブデバイス２００の対応する構造が互いに同一であるということを意味するものではない。

ここで、マスターデバイス１００のアプリケーション１０１は、第１客体伝送プロトコル１０５を使用し、第１客体伝送プロトコル１０５は、装置独立的である。もし、第１客体伝送プロトコル１０５を支援する他のデバイスが存在するならば、アプリケーション１０１は他のデバイスとマスターデバイス１００の下位構造の差に関係なく第１客体伝送プロトコル１０５の処理を担当することによって、両デバイス間の客体伝送作業を処理しうる。すなわち、マスターデバイス１００が他のデバイスと各々異なる形のデータ形式で客体を保存していても、第１客体伝送プロトコル１０５を通じて統一された形のデータを相互間に提供可能となる。第１客体伝送プロトコル１０５の例として、ＭＴＰ（Ｍｅｄｉａ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＰＴＰ（Ｐｉｃｔｕｒｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などを挙げられる。

一方、スレーブデバイス２００のアプリケーション２０１は、第２客体伝送プロトコル２０５を使用する。第２客体伝送プロトコル２０５は、装置依存的であり得る。しかし、本発明はこれに限定されず、第２客体伝送プロトコル２０５は、装置独立的な場合もある。スレーブデバイス２００は、マスターデバイス１００に比べて演算能力や保存能力などのシステムリソースが低い装置であって、この場合、スレーブデバイス２００は、マスターデバイス１００が使用する第１客体伝送プロトコル１０５を支援できなくなり得る。第２客体伝送プロトコル２０５は、このようなスレーブデバイス２００の客体処理作業のためのプロトコルであり、第２客体伝送プロトコル２０５の例として、三星電子が２００４年に提案した‘ＳｅｃｕｒｅＭＭＣ Ｓｐｅｃｉｆｉｃａｔｉｏｎ’を挙げられる。

このような場合、マスターデバイス１００のアプリケーション１０１の要請メッセージがスレーブデバイス２００に伝送されても、スレーブデバイス２００は、要請メッセージによる作業を処理できなくなる。したがって、マスターデバイス１００の伝送階層１０２は、プロトコル変換階層１０６をさらに含む。プロトコル変換階層１０６は、第１客体伝送プロトコル１０５と第２客体伝送プロトコル２０５のメッセージを変換する。すなわち、プロトコル変換階層１０６は、第１客体伝送プロトコル基盤のメッセージを第２客体伝送プロトコル基盤のメッセージに変換し、第２客体伝送プロトコル基盤のメッセージを第１客体伝送プロトコル基盤のメッセージに変換する。これを通じてマスターデバイス１００のアプリケーション１０１とスレーブデバイス２００のアプリケーションとの間の客体処理作業が行われ得る。

図２は、本発明の一実施形態によるマスターデバイス１００をさらに具体的に示すブロック図である。図示されたマスターデバイス１００は、アプリケーションモジュール１１０、変換モジュール１２０、デバイスインターフェースモジュール１３０、及び制御モジュール１４０を含む。

アプリケーションモジュール１１０は、第１客体伝送プロトコルを使用して所定客体に対する処理作業を行う。例えば、アプリケーションモジュール１１０は、第１客体伝送プロトコルとしてＰＴＰを使用して他のデバイスとイメージファイルを交換する作業を行える。客体処理作業の例として、客体の伝送、検索、獲得、管理、制御などを挙げられる。このために、アプリケーションモジュール１１０は、第１客体伝送プロトコルに基づいた要請メッセージと応答メッセージを生成しうる。

デバイスインターフェースモジュール１３０は、他のデバイス（例えば、スレーブデバイス２００）にメッセージやデータを送信するか、他のデバイスからメッセージやデータを受信する。マスターデバイス１００は、デバイスインターフェースモジュール１３０を通じて他のデバイスと連結することができる。ここで、‘連結’とは、マスターデバイス２００が他のデバイスと有線媒体を通じて電気的に接触することを意味するが、これは例示的なものであって、‘連結’という意味は、マスターデバイス２００と他のデバイスとが非接触状態で無線媒体を介して互いに通信できる状態にあるということも意味すると解釈せねばならない。

変換モジュール１２０は、デバイスインターフェースモジュール１３０を通じて連結されたデバイスがアプリケーションモジュール１１０が使用する第１客体伝送プロトコルを支援していないスレーブデバイス２００である場合、アプリケーションモジュール１１０が生成した要請メッセージをスレーブデバイス２００が支援する第２客体伝送プロトコルに基づいた要請メッセージに変換する。また、変換モジュール１２０は、スレーブデバイス２００から受信された応答メッセージを第１客体伝送プロトコルに基づいた応答メッセージに変換する。このために変換モジュール１２０は、第１客体伝送プロトコルと第２客体伝送プロトコルについての情報など所定の変換情報を保存しうる。

例えば、変換モジュール１２０は、第１客体伝送プロトコルで使われる各種メッセージと第２客体伝送プロトコルで使われる各種メッセージとを保存し、両者間に対応するメッセージについてのマッピング情報を含みうる。この場合、変換モジュール１２０は、いずれか１つの客体伝送プロトコルに基づいたメッセージが入力されれば、それに対応する他の客体伝送プロトコルに基づいたメッセージを出力しうる。

一方、変換モジュール１２０は、複数の客体伝送プロトコルについての変換情報を含む事も出来る。この場合、変換モジュール１２０は、スレーブデバイス２００が使用する客体伝送プロトコルに対応する変換情報を使用して第１客体伝送プロトコルメッセージに対する変換作業を行える。

制御モジュール１４０は、デバイスインターフェースモジュール１３０を通じて連結された他のデバイスが、アプリケーションモジュール１１０が使用する第１客体伝送プロトコルを支援しているか否かを確認する。例えば、制御モジュール１４０は、アプリケーションモジュール１１０が使用する第１客体伝送プロトコルの識別情報をデバイスインターフェースモジュール１３０を通じて他のデバイスに伝送し、他のデバイスから受信される応答を通じて他のデバイスが第１客体伝送プロトコルを支援しているか否かを確認しうる。このような確認作業は、アプリケーションモジュール１１０の介入なしに行われ得る。

一方、制御モジュール１４０は、マスターデバイス１００を構成する各モジュール１１０ないし１３０の動作過程を制御しうる。

以下、マスターデバイス１００の動作過程について図３を参照して説明する。

図３は、本発明の一実施形態による多重客体伝送プロトコル支援方法を示すフローチャートである。

まず、デバイスインターフェースモジュール１３０がスレーブデバイス２００と連結されれば（Ｓ３１０）、制御モジュール１４０は、デバイスインターフェースモジュール１３０を通じてスレーブデバイス２００にアプリケーションモジュール１１０が使用する第１客体伝送プロトコルの支援如何について質疑する（Ｓ３１５）。例えば、制御モジュール１４０は、デバイスインターフェースモジュール１３０を通じて第１客体伝送プロトコルを識別しうるコード値をスレーブデバイス２００に伝送しうる。

次いで、デバイスインターフェースモジュール１３０が、スレーブデバイス２００から第１客体伝送プロトコルを支援するという応答を受信すれば（Ｓ３２０）、制御モジュール１４０は、変換モジュール１２０を経ない一般的な通信を行わせる（Ｓ３２５）。

しかし、デバイスインターフェースモジュール１３０がスレーブデバイス２００から第１客体伝送プロトコルを支援しないという応答を受信すれば、変換モジュール１２０を経る通信が行われる。実施形態によっては、過程Ｓ３１５の質疑に対する応答として、スレーブデバイス２００からスレーブデバイス２００が支援する客体伝送プロトコルを識別しうる情報が受信されることもある。

この際、アプリケーションモジュール１１０が第１客体伝送プロトコルに基づいた第１要請メッセージを生成すれば（Ｓ３３０）、変換モジュール１２０は、第１要請メッセージをスレーブデバイス２００が支援する第２客体伝送プロトコルに基づいた第２要請メッセージに変換する（Ｓ３３５）。ここで、第１要請メッセージと第２要請メッセージは、相互対応する意味の情報を含む。

次いで、デバイスインターフェースモジュール１３０は、第２要請メッセージをスレーブデバイス２００に伝送する（Ｓ３４０）。

スレーブデバイス２００から第２要請メッセージに対する第１応答メッセージが受信されれば（Ｓ３４５）、変換モジュール１２０は、第１応答メッセージを第１客体伝送プロトコルに基づいた第２応答メッセージに変換し（Ｓ３５０）、変換された第２応答メッセージをアプリケーションモジュール１１０に伝達する（Ｓ３５５）。

これにより、相異なる客体伝送プロトコルを支援するアプリケーション間の客体処理作業のための通信が行われる。

一方、図３では、スレーブデバイス２００が第１客体伝送プロトコルを支援しているか否かについての質疑が、アプリケーションモジュール１１０が第１要請メッセージを生成する以前に行われると説明しているが、本発明はこれに限定されない。したがって、図３で、過程Ｓ３１０ないしＳ３２０は、過程Ｓ３３０以後に行われても良い。

また、本発明の一実施形態によれば、変換モジュール１２０は、複数の客体伝送プロトコルについての変換情報を含みうる。この場合、過程Ｓ３１５の質疑に対するスレーブデバイス２００の応答には、スレーブデバイス２００が支援する客体伝送プロトコルを識別できる情報が含まれうる。この際、変換モジュール１２０は、複数の変換情報のうち、スレーブデバイス２００が使用する客体伝送プロトコルに対応する変換情報を使用して第１客体伝送プロトコルメッセージに対する変換作業を行える。

以上、添付図を参照して本発明の実施例を説明したが、 本発明が属する技術分野で当業者ならば本発明がその技術的思想や必須特徴を変更せずとも他の具体的な形に実施されうるということが理解できるであろう。したがって、前述した実施例は全ての面で例示的なものであって、限定的なものではないと理解せねばならない。

本発明は、多重客体伝送プロトコル支援方法及びその装置に関連した技術分野に好適に適用されうる。

本発明の一実施形態によるマスターデバイスとスレーブデバイスとの概略的なスタック構造を示す図である。 本発明の一実施形態によるマスターデバイスを示すブロック図である。 本発明の一実施形態による多重客体伝送プロトコル支援方法を示すフローチャートである。

符号の説明

１１０ アプリケーションモジュール
１２０ 変換モジュール
１３０ デバイスインターフェースモジュール
１４０ 制御モジュール

Claims (12)

1. 所定のアプリケーションの要請によって第１客体伝送プロトコルに基づいた第１要請メッセージを生成する段階と、
   前記生成された第１要請メッセージをスレーブデバイスが支援する第２客体伝送プロトコルに基づいた第２要請メッセージに変換する段階と、
   前記第２要請メッセージを前記スレーブデバイスに伝送する段階と、を含む多重客体伝送プロトコル支援方法。
2. 前記スレーブデバイスから前記第２要請メッセージに対する第１応答メッセージを受信する段階と、
   前記第１応答メッセージを前記第１客体伝送プロトコルに基づいた第２応答メッセージに変換する段階と、
   前記第２応答メッセージを前記アプリケーションに提供する段階と、を含む請求項１に記載の多重客体伝送プロトコル支援方法。
3. 前記第１客体伝送プロトコルは、前記アプリケーションが所定の客体に対する処理作業を行うためのプロトコルである請求項１に記載の多重客体伝送プロトコル支援方法。
4. 前記客体は、ビデオデータ、オーディオデータ、イメージデータ、ゲーム、テキスト、文書、権利客体のうち少なくとも１つを含む請求項３に記載の多重客体伝送プロトコル支援方法。
5. 前記客体に対する処理作業は、前記客体の伝送、検索、獲得、管理、及び制御のうち少なくとも１つを含む請求項３に記載の多重客体伝送プロトコル支援方法。
6. 前記第１客体伝送プロトコルは、ＭＴＰとＰＴＰのうちいずれか１つであり、前記第２客体伝送プロトコルは、ＳｅｃｕｒｅＭＭＣ Ｓｐｅｃｉｆｉｃａｔｉｏｎによるプロトコルである請求項１に記載の多重客体伝送プロトコル支援方法。
7. 第１客体伝送プロトコルに基づいた第１要請メッセージを生成するアプリケーションモジュールと、
   前記生成された第１要請メッセージをスレーブデバイスが支援する第２客体伝送プロトコルに基づいた第２要請メッセージに変換する変換モジュールと、
   前記第２要請メッセージを前記スレーブデバイスに伝送するデバイスインターフェースモジュールと、を備えるマスターデバイス。
8. 前記デバイスインターフェースモジュールは、前記スレーブデバイスから前記第２要請メッセージに対する第１応答メッセージを受信し、前記変換モジュールは、前記第１応答メッセージを前記第１客体伝送プロトコルに基づいた第２応答メッセージに変換し、前記第２応答メッセージを前記アプリケーションモジュールに提供する請求項７に記載のマスターデバイス。
9. 前記第１客体伝送プロトコル及び前記アプリケーションモジュールが所定の客体に対する処理作業を行うためのプロトコルである請求項７に記載のマスターデバイス。
10. 前記客体は、ビデオデータ、オーディオデータ、イメージデータ、ゲーム、テキスト、文書、権利客体のうち少なくとも１つを含む請求項９に記載のマスターデバイス。
11. 前記客体に対する処理作業は、前記客体の伝送、検索、獲得、管理、及び制御のうち少なくとも１つを含む請求項９に記載のマスターデバイス。
12. 前記第１客体伝送プロトコルは、ＭＴＰとＰＴＰのうちいずれか１つであり、前記第２客体伝送プロトコルは、ＳｅｃｕｒｅＭＭＣ Ｓｐｅｃｉｆｉｃａｔｉｏｎによるプロトコルである請求項７に記載のプロトコルのマスターデバイス。

Images