リッチメディアコンテンツの送受信方法及び装置
本発明は、リッチメディアコンテンツを送受信する方法及び装置を提供する。生成部は、階層構造で形態された各ノードの構成情報を駆動器が変更可能な形態で生成し、各ノードの構成情報を含むコンテンツを前記駆動器に伝送する。駆動器は、生成部からコンテンツを受信し、受信されたコンテンツの階層構造で形成される各ノードの構成情報が駆動器にて変更可能な形態で生成されたか否かを判定し、構成情報が変更可能な形態で生成された場合、駆動器の判断条件によって各ノードを再構成し、再構成されたノードに対してアプリケーションを遂行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的にはリッチメディアコンテンツの送受信方法及び装置に関するものであって、特にリッチメディアアプリケーションのオブジェクトを送受信する方法及び装置に関する。
【背景技術】
【０００２】
リッチ(rich)メディアアプリケーションは、オーディオ、ビデオ、及びテキストのようなマルチメディアコンテンツ及びサーバとクライアントとの間のインタラクティブな情報交換及び制御、ユーザーとのインタラクティブな情報交換及び制御、及びこれら要素間の時間及び空間的配置を含むアプリケーションである。リッチメディアは、一般的に双方向性(interactivity)の観点からマルチメディアと区別されることが最も大きな特徴である。すなわち、リッチメディアは、メディアデータ、グラフィック要素データ、及び各要素値の属性データに加えて、時空間的な関係を示すデータ、双方向性を表現するためのイベント、及び動作データのような情報で記述される構造で生成され、これらは、各々特定のリッチメディアエンジンによって提供される言語で表現される。多様な方法で適用することができる言語は、例えばＭＰＥＧ４ ＬＡＳｅＲ(Lightweight Application of Scene Representation)、ＭＰＥＧ４ ＢＩＦＳ(Binary Format for Scene)、Ｗ３Ｃ(World Wide Web Consortium)のＳＶＧ(Scalable Vector Graphics）などを含む。
【０００３】
このアプリケーションを駆動するために、上記情報を階層構造に変換する動作が必要である。この動作は、リッチメディア要素を駆動される要素の時空間的な順にルート(root)要素(最上位ノード)からルートの子(child)要素(最下位ノード)まで階層化する作業である。階層構造は、ツリー(tree)構造で形成される。一つのルートは複数の子ノードを有することができ、各ノードは、ノードを構成する要素、各要素を表現する属性のタイプ、及び各属性値で構成される。アプリケーションを駆動するリッチメディアエンジンは、その関連属性タイプと属性値を用いて階層構造の各要素を実現する。ここで、属性タイプは、“属性”と称する。
【０００４】
従来のリッチメディアアプリケーションは、コンテンツオブジェクトの生成時に構成されたコンテンツオブジェクトの階層構造情報を用いてリッチメディアサービスを提供する。すなわち、リッチメディアアプリケーションは、生成されたリッチメディア情報の完了した階層構造情報をそのまま実現する。その理由は、リッチメディアサービスを実現するための階層構造のノード情報、すなわち要素、属性、及び属性値のうち少なくとも一つが定義されていないと、このリッチメディアサービスは実現できないためである。そのため、従来の駆動器(driver)は、生成器によって生成されたアプリケーションのみを駆動するという問題があった。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
したがって、本発明は上記した従来技術の問題点に鑑みてなされたものであって、その目的は、リッチメディアアプリケーションを利用する生成器は、要素、属性、及び属性値のうち少なくとも一つは定義されていない階層構造情報、あるいは指定されたデフォルト要素のみで構成された階層構造情報を駆動器に送信し、駆動器は、階層構造情報を認識して定義されていない要素、属性、及び属性値のうち少なくとも一つで構成された階層構造を完成した階層構造に変更することで、アプリケーションを遂行する装置及び方法を提供することにある。
【０００６】
また、本発明の目的は、駆動器が要素、属性、及び属性値のうち少なくとも一つは定義されていない階層構造情報を受信し、階層を形成する各ノードを構成する情報を確認し、未完成あるいは変更可能なノード情報に関して生成器によって表示された条件に基づいて新たな要素又は属性値を用いて完成した階層構造を生成する装置及び方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記のような目的を達成するために、本発明の一態様によれば、生成部におけるコンテンツを送信する方法であって、階層構造で形態された各ノードの構成情報を駆動器が変更可能な形態で生成するステップと、各ノードの構成情報を含むコンテンツを前記駆動器に伝送するステップとを有する。
【０００８】
本発明の他の態様によれば、駆動器におけるコンテンツを受信する方法であって、生成部からコンテンツを受信するステップと、受信されたコンテンツの階層構造で形成される各ノードの構成情報が駆動器にて変更可能な形態で生成されたか否かを判定するステップと、構成情報が変更可能な形態で生成された場合、駆動器の判断条件によって各ノードを再構成するステップと、再構成されたノードに対してアプリケーションを遂行するステップとを有する。
【０００９】
また、本発明の他の態様によれば、生成部におけるコンテンツを送信する装置であって、駆動器が変更可能な形態を有する階層構造で形成される各ノードの構成情報を生成するコンテンツ生成部と、各ノードの構成情報を含むコンテンツを駆動器に送信する送信部とを含む。
【００１０】
さらに、本発明の他の態様によれば、駆動器におけるコンテンツを受信する装置であって、生成部からコンテンツを受信する受信部と、受信されたコンテンツの階層構造で形成される各ノードの構成情報が駆動器にて変更可能な形態で形成されたか否かを判定し、構成情報が変更可能な形態で生成された場合に、駆動器の判断条件によって各ノードを再構成する階層構造生成部と、再構成されたノードに対してアプリケーションを遂行するコンテンツ実行部とを含む。
【発明の効果】
【００１１】
本発明は、アプリケーション生成器が完成されない階層構造を有するコンテンツを構成して伝送し、駆動器が完成されない階層構造を有するコンテンツを完成して駆動し、それによって生成器の生成負荷を減少させることができる。
また、本発明は、生成器によって作られた一つの共通アプリケーションを用いて複数の駆動器間の差別化されたサービスを提供することができる。
本発明による実施形態の上記及び他の態様、特徴、及び利点は、添付の図面と共に述べる以下の詳細な説明から、一層明らかになるはずである。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態による生成部の動作を示すフローチャートである。
【図２】本発明の一実施形態による駆動器の動作を示すフローチャートである。
【図３】本発明の一実施形態による生成部装置を示すブロック構成図である。
【図４】本発明の一実施形態による駆動器装置を示すブロック構成図である。
【発明を実施するための形態】
【００１３】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
本発明の範囲及び精神を逸脱することなく、以下に説明される本発明の様々な変形及び変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。なお、公知の機能または構成に関する具体的な説明は、明瞭性と簡潔性のために省略する。
【００１４】
通常、アプリケーション駆動器は生成部によって生成された階層構造のノード情報を用いて実現されるが、生成部は、完成した階層構造のノードを生成する。しかしながら、本発明の実施形態によって、アプリケーション生成部が完成されない階層構造を有するコンテンツを構成して伝送し、駆動器が完成されない階層構造のコンテンツを完成して駆動する方法及び装置を提供する。
【００１５】
本発明は、完成されない階層構造でも駆動器がアプリケーションを駆動する場合に誤りを発生させず、生成部が完成された階層構造を提供しなくても生成部の意図を表現できる方式をサポートする。すなわち、階層構造値が指定できなくても、生成部は、その意図が完成したアプリケーションで反映されるように条件又は制限事項を駆動器に提供する。すると、駆動器は、定義された条件下でアプリケーションのオブジェクトの構成を完了できる。このような方式で、駆動器は、該当アプリケーションのすべての階層構造情報を駆動器に提供しなくても、生成部によって所望するアプリケーションを生成することができる。
【００１６】
また、従来の駆動器は、生成部によって生成されたアプリケーションのみを駆動する。しかしながら、本発明は、駆動器が生成部から未完成階層構造の復号化に成功し、関連オブジェクト値に対する条件が存在する場合に、駆動部がこの条件を分析し、駆動器の判断による適切なオブジェクト構成を完成する機能をさらに提供する。
【００１７】
以下、本発明の実施形態では、ＭＰＥＧ４ ＬＡＳｅＲ言語を用いて説明する。しかしながら、本発明は、この特定言語に限定されるものではなく、他の適切な言語が使用可能であることは当該技術分野で通常の知識を持つ者には明らかなことである。
リッチメディアアプリケーションのオブジェクト構成が階層構造で表現される場合に、各オブジェクトは、上述したように、一つのノードで表現され、各ノードは３個の情報、すなわち要素、属性、及び属性値を含む。したがって、本発明の実施形態によって、生成部は、これら３個の情報のうちいずれか一つを指定せずに階層構造を生成でき、本発明は、要素、属性、及び属性値に対して各々提案を提供する。
【００１８】
下記の＜表１＞は、属性値が指定されていない場合の一実施形態を示す。
【００１９】
【表１】
【００２０】
＜表１＞において、“＜ｇ＞”及び“＜ｒｅｃｔ＞”は、ＬＡＳｅＲで定義されたリッチメディアオブジェクトを表す命令語である。例えば、所定の属性である“＜ｒｅｃｔ＞”は、長方形の描写を表す命令語である。また、“ｉｄ”、“ｆｉｌｌ”、“ｗｉｄｔｈ”、及び“ｈｅｉｇｈｔ”は、各リッチメディアオブジェクトの要素値の属性を意味し、各々ｉｄ(identification)、特定色又はパターンの表現、幅、及び高さを示す。本発明の実施形態によって提案される“＜ｃｈａｎｇｅ＞”要素値は、“ａｄａｐｔａｔｉｏｎ０２”ｉｄ属性値を有するリッチメディアオブジェクトの“ｆｉｌｌ”属性の値が生成部によって未指定とされ、あるいは駆動器によって新たに生成可能な属性値であることを示す。
【００２１】
下記の＜表２Ａ＞は、属性値が指定されていない場合の他の実施形態を示す。
【００２２】
【表２Ａ】
【００２３】
＜表２Ａ＞によると、駆動器は、“ａｄａｐｔａｔｉｏｎ０２”ｉｄ属性値を有するリッチメディアオブジェクトの“ｆｉｌｌ”属性の値を“ｒｅｄ”及び“ｙｅｌｌｏｗ”のうちいずれか一つとして選択することができる。
【００２４】
下記の＜表２Ｂ＞は、属性値が未指定とされた場合に駆動器が選択できる値を示すためのｒｅｃｏｍｍｅｎｄＶａｌｕｅを定義する一例を示す。
【００２５】
【表２Ｂ】
【００２６】
下記の＜表３＞は、要素値が未指定とされた場合の一実施形態を示す。
【００２７】
【表３】
【００２８】
＜表３＞によると、“ｅｍｐｔｙ”は、該当要素を駆動器が生成することを示し、駆動器は、どのアルゴリズムを通じて要素値を選択するかを判断する固有権限を有する。
また、＜表３＞は、“ｄｅｆａｕｌｔＥｌｅｍｅｎｔＮａｍｅ”を用いて、駆動器がその固有権限による選択を通じてシーンを完成するための要素を選択しない場合に、生成部は、駆動器がシーンを完成させるデフォルト要素を指定する一実施形態を示す。ここで、“ｅｍｐｔｙ”要素は、その要素を参照とする“ｃｈａｎｇｅ”要素と共に動作し、あるいは独立的に動作することができる。
【００２９】
下記の＜表４＞は、駆動器が変更又は生成できない要素及び属性値を生成部が指定する場合の一実施形態を示す。
【００３０】
【表４】
【００３１】
＜表４＞によると、“ａｄａｐｔａｔｉｏｎ０２”ｉｄ属性値を有するリッチメディアオブジェクトである“ｒｅｃｔ”は、生成部によって指定された値に対するすべての属性値に関して駆動器による変更又は生成が不可能である。
【００３２】
下記の＜表５＞は、駆動器が変更又は生成できない要素及び属性値を生成部が指定する場合の他の一実施形態を示す。
【００３３】
【表５】
【００３４】
＜表５＞によると、“ａｄａｐｔａｔｉｏｎ０３”ｉｄ属性値を有するリッチメディアオブジェクトである“ｒｅｃｔ”の属性の中で、“ＵｎＣｈａｎｇｅ”要素で指定された“ｗｉｄｔｈ”と“ｈｅｉｇｈｔ”は、駆動器によって変更及び生成されることができない。しかしながら、“ｒｅｃｔ”の“ｆｉｌｌ”属性が“ＵｎＣｈａｎｇｅ”要素で指定されなかったので、駆動器によって変更可能である。
【００３５】
下記の＜表６＞は、生成部によって完成された階層構造を有するオブジェクトを示す要素と、駆動器が変更又は生成可能なオブジェクトの階層構造を示す要素を定義する場合の一実施形態を示す。
【００３６】
【表６】
【００３７】
＜表６＞を参照すると、＜ｉｎｆｒａ＞要素は駆動器が生成又は変更できない要素及び属性を含み、＜ＤｅｖｉｃｅＤｅｐ＞要素は、駆動器が生成又は変更できる要素及び属性を列挙又は指定する。
図１及び図２は、本発明の一実施形態による生成部と駆動器の動作を示すフローチャートである。
図１は、本発明の一実施形態による生成部の動作を示すフローチャートである。生成部及び駆動器の物理的位置は、変更される可能性がある。例えば、サーバ及びクライアントデバイスは、各々生成部と駆動器として機能を遂行し、あるいはクライアントデバイスは、生成部と駆動器すべての機能を遂行することができる。
【００３８】
図１を参照すると、生成部は、ステップ１０１で、リッチメディアアプリケーションのオブジェクト構成を開始し、ステップ１０３で、各オブジェクトの要素値、属性、及び属性値を定義する。生成部は、ステップ１０５で、未完成状態でオブジェクトを伝送するか否かを判定する。未完成状態でオブジェクトを伝送しないと判定された場合に、生成部は、従来技術のようにステップ１０３で定義したオブジェクトを構成し、ステップ１１１でこの構成されたオブジェクトを駆動器に伝送する。しかしながら、未完成状態でオブジェクトを伝送すると判定された場合に、生成部は、ステップ１０７で、未完成状態で残される要素、属性、又は属性値を確認又は定義する。未完成状態で残される要素、属性、又は属性値は、＜表１＞〜＜表３＞の実施形態を通じて指定することができる。また、駆動器は、生成又は変更可能なオブジェクトの要素、属性、又は属性値を指定できる。
【００３９】
以後、生成部は、ステップ１０９で、オブジェクト値に対するその要求条件を定義して挿入する。ここで、要求条件は、＜表４＞〜＜表６＞の実施形態を通じて定義又は挿入することができる。しかしながら、要求条件が存在しない場合には、ステップ１０９は遂行しなくてもよい。その後、生成部は、ステップ１１１で、オブジェクト構成を完了し、この構成されたオブジェクトを駆動器に伝送する。
【００４０】
図２は、本発明の一実施形態による駆動器の動作を示すフローチャートである。
図２を参照すると、駆動器は、ステップ２０１で、リッチメディアアプリケーションの復号化を開始する。駆動器は、ステップ２０３で、アプリケーションを構成するオブジェクトの階層構造で要素値、属性、及び属性値を確認する。駆動器は、ステップ２０５で、未完成状態で伝送されたオブジェクトが存在するか否かを判定する。未完成状態で伝送されたオブジェクトが存在しない場合、駆動器は、ステップ２１７で、従来のリッチメディアアプリケーションを遂行する。しかしながら、未完成状態で伝送されたオブジェクトが存在する場合には、駆動器は、ステップ２０７で、未完成状態で伝送されたオブジェクトの要素、属性、及び属性値の詳細を確認する。すなわち、駆動器は、生成又は変更可能なオブジェクトの要素、属性、及び属性値を確認する。その後、駆動器は、ステップ２０９で、オブジェクトに対する生成部の要求条件が存在するかを確認する。ステップ２１１で、駆動器は、要求条件内で生成及び変更可能な要素、属性、又は属性値のリストを確認する。その結果は、駆動器のリソース及び要求条件内での選択に対する基準に基づく。すなわち、その結果は、同一の要求条件下でも駆動器によって、あるいは同一の駆動器でも場合によって変更され得る。
【００４１】
ステップ２１３で、駆動器は、その特定条件によってリストから要素、属性、又は属性値を選択する。ここで、“駆動器の特定条件”とは、要求条件内で又は要求条件が存在しない状態で未完成された要素、属性、及び属性値を完成する駆動器の判断条件を意味する。例えば、判断条件は、駆動器のリソース能力、リッチメディアアプリケーションユーザーの選好度のうちいずれか一つを含み、ここではこれらに対する詳細な説明を提供しない。
【００４２】
駆動器は、ステップ２１５で、選択された値でリッチメディアアプリケーションを構成するオブジェクトの階層構造を完成し、ステップ２１７でリッチメディアアプリケーションを遂行する。
【００４３】
図３は、本発明の一実施形態による生成部装置を示すブロック構成図である。
図３を参照すると、生成部は、メディアオブジェクト３０１を受信した後に、リッチメディアコンテンツ生成部３１０でリッチメディアアプリケーションのコンテンツを構成する。このリッチメディアコンテンツ生成部３１０で、各構成オブジェクトを生成するプロセスは、メディアオブジェクト間の双方向性、時空間配置、イベント、及び命令語といったリッチメディア機能を用いて遂行される。
【００４４】
未完成オブジェクト及び未完成要素設定部３２０は、未完成オブジェクト及び未完成要素の設定情報を用いて構成オブジェクトを生成する。未完成オブジェクト及び未完成要素設定部３２０は、＜表４＞〜＜表６＞の実施形態に記載された生成部の要求条件を定義して構成オブジェクトを生成する。
リッチメディアコンテンツ送信部３４０は、構成オブジェクトを含むリッチメディアコンテンツを駆動器に伝送する。リッチメディアコンテンツを符号化するプロセスは、リッチメディアコンテンツ生成部３１０にさらに含まれることができる。上述したように生成部及び駆動器が物理的に一つのデバイスで存在するので、リッチメディアコンテンツ送信部３４０は、他のデバイスへの伝送だけでなく、生成部の論理的エンティティから駆動器の論理的エンティティへの伝送も含むことに注意すべきである。
【００４５】
図４は、本発明の一実施形態による駆動器装置を示すブロック構成図である。
図４を参照すると、駆動器のリッチメディア受信部４０１は、リッチメディアアプリケーションを受信し、受信されたリッチメディアアプリケーションを階層構造生成部４２０に伝送する。階層構造生成部４２０は、該当アプリケーションの階層構造を構成し、階層構造生成部４２０内に提供される未完成オブジェクト及び未完成要素制御部４１０は、各オブジェクトの階層構造で未完成オブジェクト及び未完成要素を確認する。選択部４３０は、生成部の要求条件と駆動器の選択によって未完成要素、属性、及び属性値を選択する。選択プロセスは、多様なアルゴリズムとリソースを用いて達成でき、ここではその具体的な説明は簡潔さのために提供しない。
リッチメディアコンテンツ実行部４４０は、完成した階層構造を用いてリッチメディアコンテンツを実行する。ここで、リッチメディアコンテンツの実行は、リッチメディアコンテンツを駆動器で再生することを含む。
【００４６】
上記した本発明による実施形態は、コンピュータ読み取り可能な記録媒体上のコンピュータ読み取り可能なコードとして実施されることができる。このコンピュータ読み取り可能な記録媒体は、コンピュータシステムによって読み取り可能なデータを格納するデータストレージデバイスとなり得る。コンピュータ読み取り可能な記録媒体の例としては、ＲＯＭ(Read-Only Memory)、ＲＡＭ(Random-Access Memory)、ＣＤ-ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光データ格納装置、及び搬送波(有無線伝送経路を介してインターネットを経由するデータ伝送のような)を含むが、これに限定されることではない。また、このコンピュータ読み取り可能な記録媒体は、ネットワーク接続されたコンピュータシステムにわたって分散されることによって、コンピュータ読み取り可能なコードは分散形態で格納及び遂行される。また、本発明を達成するための機能(function)プログラム、コード、及びコードセグメントは、当該技術分野における熟練されたプログラマにとっては容易に理解できることである。
【００４７】
以上、本発明を具体的な実施形態に関して図示及び説明したが、添付した特許請求の範囲及びこれと均等なものに基づいて規定されるような本発明の精神及び範囲を外れることなく、形式や細部の様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。
【符号の説明】
【００４８】
３０１ ・・・メディアオブジェクト
３１０ ・・・リッチメディアコンテンツ生成部
３２０ ・・・未完成オブジェクト及び未完成要素設定部
３４０ ・・・リッチメディアコンテンツ送信部
４０１ ・・・リッチメディア受信部
４１０ ・・・未完成オブジェクト及び未完成要素制御部
４２０ ・・・階層構造生成部
４３０ ・・・選択部
４４０ ・・・リッチメディアコンテンツ実行部
【技術分野】
【０００１】
本発明は一般的にはリッチメディアコンテンツの送受信方法及び装置に関するものであって、特にリッチメディアアプリケーションのオブジェクトを送受信する方法及び装置に関する。
【背景技術】
【０００２】
リッチ(rich)メディアアプリケーションは、オーディオ、ビデオ、及びテキストのようなマルチメディアコンテンツ及びサーバとクライアントとの間のインタラクティブな情報交換及び制御、ユーザーとのインタラクティブな情報交換及び制御、及びこれら要素間の時間及び空間的配置を含むアプリケーションである。リッチメディアは、一般的に双方向性(interactivity)の観点からマルチメディアと区別されることが最も大きな特徴である。すなわち、リッチメディアは、メディアデータ、グラフィック要素データ、及び各要素値の属性データに加えて、時空間的な関係を示すデータ、双方向性を表現するためのイベント、及び動作データのような情報で記述される構造で生成され、これらは、各々特定のリッチメディアエンジンによって提供される言語で表現される。多様な方法で適用することができる言語は、例えばＭＰＥＧ４ ＬＡＳｅＲ(Lightweight Application of Scene Representation)、ＭＰＥＧ４ ＢＩＦＳ(Binary Format for Scene)、Ｗ３Ｃ(World Wide Web Consortium)のＳＶＧ(Scalable Vector Graphics）などを含む。
【０００３】
このアプリケーションを駆動するために、上記情報を階層構造に変換する動作が必要である。この動作は、リッチメディア要素を駆動される要素の時空間的な順にルート(root)要素(最上位ノード)からルートの子(child)要素(最下位ノード)まで階層化する作業である。階層構造は、ツリー(tree)構造で形成される。一つのルートは複数の子ノードを有することができ、各ノードは、ノードを構成する要素、各要素を表現する属性のタイプ、及び各属性値で構成される。アプリケーションを駆動するリッチメディアエンジンは、その関連属性タイプと属性値を用いて階層構造の各要素を実現する。ここで、属性タイプは、“属性”と称する。
【０００４】
従来のリッチメディアアプリケーションは、コンテンツオブジェクトの生成時に構成されたコンテンツオブジェクトの階層構造情報を用いてリッチメディアサービスを提供する。すなわち、リッチメディアアプリケーションは、生成されたリッチメディア情報の完了した階層構造情報をそのまま実現する。その理由は、リッチメディアサービスを実現するための階層構造のノード情報、すなわち要素、属性、及び属性値のうち少なくとも一つが定義されていないと、このリッチメディアサービスは実現できないためである。そのため、従来の駆動器(driver)は、生成器によって生成されたアプリケーションのみを駆動するという問題があった。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
したがって、本発明は上記した従来技術の問題点に鑑みてなされたものであって、その目的は、リッチメディアアプリケーションを利用する生成器は、要素、属性、及び属性値のうち少なくとも一つは定義されていない階層構造情報、あるいは指定されたデフォルト要素のみで構成された階層構造情報を駆動器に送信し、駆動器は、階層構造情報を認識して定義されていない要素、属性、及び属性値のうち少なくとも一つで構成された階層構造を完成した階層構造に変更することで、アプリケーションを遂行する装置及び方法を提供することにある。
【０００６】
また、本発明の目的は、駆動器が要素、属性、及び属性値のうち少なくとも一つは定義されていない階層構造情報を受信し、階層を形成する各ノードを構成する情報を確認し、未完成あるいは変更可能なノード情報に関して生成器によって表示された条件に基づいて新たな要素又は属性値を用いて完成した階層構造を生成する装置及び方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記のような目的を達成するために、本発明の一態様によれば、生成部におけるコンテンツを送信する方法であって、階層構造で形態された各ノードの構成情報を駆動器が変更可能な形態で生成するステップと、各ノードの構成情報を含むコンテンツを前記駆動器に伝送するステップとを有する。
【０００８】
本発明の他の態様によれば、駆動器におけるコンテンツを受信する方法であって、生成部からコンテンツを受信するステップと、受信されたコンテンツの階層構造で形成される各ノードの構成情報が駆動器にて変更可能な形態で生成されたか否かを判定するステップと、構成情報が変更可能な形態で生成された場合、駆動器の判断条件によって各ノードを再構成するステップと、再構成されたノードに対してアプリケーションを遂行するステップとを有する。
【０００９】
また、本発明の他の態様によれば、生成部におけるコンテンツを送信する装置であって、駆動器が変更可能な形態を有する階層構造で形成される各ノードの構成情報を生成するコンテンツ生成部と、各ノードの構成情報を含むコンテンツを駆動器に送信する送信部とを含む。
【００１０】
さらに、本発明の他の態様によれば、駆動器におけるコンテンツを受信する装置であって、生成部からコンテンツを受信する受信部と、受信されたコンテンツの階層構造で形成される各ノードの構成情報が駆動器にて変更可能な形態で形成されたか否かを判定し、構成情報が変更可能な形態で生成された場合に、駆動器の判断条件によって各ノードを再構成する階層構造生成部と、再構成されたノードに対してアプリケーションを遂行するコンテンツ実行部とを含む。
【発明の効果】
【００１１】
本発明は、アプリケーション生成器が完成されない階層構造を有するコンテンツを構成して伝送し、駆動器が完成されない階層構造を有するコンテンツを完成して駆動し、それによって生成器の生成負荷を減少させることができる。
また、本発明は、生成器によって作られた一つの共通アプリケーションを用いて複数の駆動器間の差別化されたサービスを提供することができる。
本発明による実施形態の上記及び他の態様、特徴、及び利点は、添付の図面と共に述べる以下の詳細な説明から、一層明らかになるはずである。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態による生成部の動作を示すフローチャートである。
【図２】本発明の一実施形態による駆動器の動作を示すフローチャートである。
【図３】本発明の一実施形態による生成部装置を示すブロック構成図である。
【図４】本発明の一実施形態による駆動器装置を示すブロック構成図である。
【発明を実施するための形態】
【００１３】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
本発明の範囲及び精神を逸脱することなく、以下に説明される本発明の様々な変形及び変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。なお、公知の機能または構成に関する具体的な説明は、明瞭性と簡潔性のために省略する。
【００１４】
通常、アプリケーション駆動器は生成部によって生成された階層構造のノード情報を用いて実現されるが、生成部は、完成した階層構造のノードを生成する。しかしながら、本発明の実施形態によって、アプリケーション生成部が完成されない階層構造を有するコンテンツを構成して伝送し、駆動器が完成されない階層構造のコンテンツを完成して駆動する方法及び装置を提供する。
【００１５】
本発明は、完成されない階層構造でも駆動器がアプリケーションを駆動する場合に誤りを発生させず、生成部が完成された階層構造を提供しなくても生成部の意図を表現できる方式をサポートする。すなわち、階層構造値が指定できなくても、生成部は、その意図が完成したアプリケーションで反映されるように条件又は制限事項を駆動器に提供する。すると、駆動器は、定義された条件下でアプリケーションのオブジェクトの構成を完了できる。このような方式で、駆動器は、該当アプリケーションのすべての階層構造情報を駆動器に提供しなくても、生成部によって所望するアプリケーションを生成することができる。
【００１６】
また、従来の駆動器は、生成部によって生成されたアプリケーションのみを駆動する。しかしながら、本発明は、駆動器が生成部から未完成階層構造の復号化に成功し、関連オブジェクト値に対する条件が存在する場合に、駆動部がこの条件を分析し、駆動器の判断による適切なオブジェクト構成を完成する機能をさらに提供する。
【００１７】
以下、本発明の実施形態では、ＭＰＥＧ４ ＬＡＳｅＲ言語を用いて説明する。しかしながら、本発明は、この特定言語に限定されるものではなく、他の適切な言語が使用可能であることは当該技術分野で通常の知識を持つ者には明らかなことである。
リッチメディアアプリケーションのオブジェクト構成が階層構造で表現される場合に、各オブジェクトは、上述したように、一つのノードで表現され、各ノードは３個の情報、すなわち要素、属性、及び属性値を含む。したがって、本発明の実施形態によって、生成部は、これら３個の情報のうちいずれか一つを指定せずに階層構造を生成でき、本発明は、要素、属性、及び属性値に対して各々提案を提供する。
【００１８】
下記の＜表１＞は、属性値が指定されていない場合の一実施形態を示す。
【００１９】
【表１】
【００２０】
＜表１＞において、“＜ｇ＞”及び“＜ｒｅｃｔ＞”は、ＬＡＳｅＲで定義されたリッチメディアオブジェクトを表す命令語である。例えば、所定の属性である“＜ｒｅｃｔ＞”は、長方形の描写を表す命令語である。また、“ｉｄ”、“ｆｉｌｌ”、“ｗｉｄｔｈ”、及び“ｈｅｉｇｈｔ”は、各リッチメディアオブジェクトの要素値の属性を意味し、各々ｉｄ(identification)、特定色又はパターンの表現、幅、及び高さを示す。本発明の実施形態によって提案される“＜ｃｈａｎｇｅ＞”要素値は、“ａｄａｐｔａｔｉｏｎ０２”ｉｄ属性値を有するリッチメディアオブジェクトの“ｆｉｌｌ”属性の値が生成部によって未指定とされ、あるいは駆動器によって新たに生成可能な属性値であることを示す。
【００２１】
下記の＜表２Ａ＞は、属性値が指定されていない場合の他の実施形態を示す。
【００２２】
【表２Ａ】
【００２３】
＜表２Ａ＞によると、駆動器は、“ａｄａｐｔａｔｉｏｎ０２”ｉｄ属性値を有するリッチメディアオブジェクトの“ｆｉｌｌ”属性の値を“ｒｅｄ”及び“ｙｅｌｌｏｗ”のうちいずれか一つとして選択することができる。
【００２４】
下記の＜表２Ｂ＞は、属性値が未指定とされた場合に駆動器が選択できる値を示すためのｒｅｃｏｍｍｅｎｄＶａｌｕｅを定義する一例を示す。
【００２５】
【表２Ｂ】
【００２６】
下記の＜表３＞は、要素値が未指定とされた場合の一実施形態を示す。
【００２７】
【表３】
【００２８】
＜表３＞によると、“ｅｍｐｔｙ”は、該当要素を駆動器が生成することを示し、駆動器は、どのアルゴリズムを通じて要素値を選択するかを判断する固有権限を有する。
また、＜表３＞は、“ｄｅｆａｕｌｔＥｌｅｍｅｎｔＮａｍｅ”を用いて、駆動器がその固有権限による選択を通じてシーンを完成するための要素を選択しない場合に、生成部は、駆動器がシーンを完成させるデフォルト要素を指定する一実施形態を示す。ここで、“ｅｍｐｔｙ”要素は、その要素を参照とする“ｃｈａｎｇｅ”要素と共に動作し、あるいは独立的に動作することができる。
【００２９】
下記の＜表４＞は、駆動器が変更又は生成できない要素及び属性値を生成部が指定する場合の一実施形態を示す。
【００３０】
【表４】
【００３１】
＜表４＞によると、“ａｄａｐｔａｔｉｏｎ０２”ｉｄ属性値を有するリッチメディアオブジェクトである“ｒｅｃｔ”は、生成部によって指定された値に対するすべての属性値に関して駆動器による変更又は生成が不可能である。
【００３２】
下記の＜表５＞は、駆動器が変更又は生成できない要素及び属性値を生成部が指定する場合の他の一実施形態を示す。
【００３３】
【表５】
【００３４】
＜表５＞によると、“ａｄａｐｔａｔｉｏｎ０３”ｉｄ属性値を有するリッチメディアオブジェクトである“ｒｅｃｔ”の属性の中で、“ＵｎＣｈａｎｇｅ”要素で指定された“ｗｉｄｔｈ”と“ｈｅｉｇｈｔ”は、駆動器によって変更及び生成されることができない。しかしながら、“ｒｅｃｔ”の“ｆｉｌｌ”属性が“ＵｎＣｈａｎｇｅ”要素で指定されなかったので、駆動器によって変更可能である。
【００３５】
下記の＜表６＞は、生成部によって完成された階層構造を有するオブジェクトを示す要素と、駆動器が変更又は生成可能なオブジェクトの階層構造を示す要素を定義する場合の一実施形態を示す。
【００３６】
【表６】
【００３７】
＜表６＞を参照すると、＜ｉｎｆｒａ＞要素は駆動器が生成又は変更できない要素及び属性を含み、＜ＤｅｖｉｃｅＤｅｐ＞要素は、駆動器が生成又は変更できる要素及び属性を列挙又は指定する。
図１及び図２は、本発明の一実施形態による生成部と駆動器の動作を示すフローチャートである。
図１は、本発明の一実施形態による生成部の動作を示すフローチャートである。生成部及び駆動器の物理的位置は、変更される可能性がある。例えば、サーバ及びクライアントデバイスは、各々生成部と駆動器として機能を遂行し、あるいはクライアントデバイスは、生成部と駆動器すべての機能を遂行することができる。
【００３８】
図１を参照すると、生成部は、ステップ１０１で、リッチメディアアプリケーションのオブジェクト構成を開始し、ステップ１０３で、各オブジェクトの要素値、属性、及び属性値を定義する。生成部は、ステップ１０５で、未完成状態でオブジェクトを伝送するか否かを判定する。未完成状態でオブジェクトを伝送しないと判定された場合に、生成部は、従来技術のようにステップ１０３で定義したオブジェクトを構成し、ステップ１１１でこの構成されたオブジェクトを駆動器に伝送する。しかしながら、未完成状態でオブジェクトを伝送すると判定された場合に、生成部は、ステップ１０７で、未完成状態で残される要素、属性、又は属性値を確認又は定義する。未完成状態で残される要素、属性、又は属性値は、＜表１＞〜＜表３＞の実施形態を通じて指定することができる。また、駆動器は、生成又は変更可能なオブジェクトの要素、属性、又は属性値を指定できる。
【００３９】
以後、生成部は、ステップ１０９で、オブジェクト値に対するその要求条件を定義して挿入する。ここで、要求条件は、＜表４＞〜＜表６＞の実施形態を通じて定義又は挿入することができる。しかしながら、要求条件が存在しない場合には、ステップ１０９は遂行しなくてもよい。その後、生成部は、ステップ１１１で、オブジェクト構成を完了し、この構成されたオブジェクトを駆動器に伝送する。
【００４０】
図２は、本発明の一実施形態による駆動器の動作を示すフローチャートである。
図２を参照すると、駆動器は、ステップ２０１で、リッチメディアアプリケーションの復号化を開始する。駆動器は、ステップ２０３で、アプリケーションを構成するオブジェクトの階層構造で要素値、属性、及び属性値を確認する。駆動器は、ステップ２０５で、未完成状態で伝送されたオブジェクトが存在するか否かを判定する。未完成状態で伝送されたオブジェクトが存在しない場合、駆動器は、ステップ２１７で、従来のリッチメディアアプリケーションを遂行する。しかしながら、未完成状態で伝送されたオブジェクトが存在する場合には、駆動器は、ステップ２０７で、未完成状態で伝送されたオブジェクトの要素、属性、及び属性値の詳細を確認する。すなわち、駆動器は、生成又は変更可能なオブジェクトの要素、属性、及び属性値を確認する。その後、駆動器は、ステップ２０９で、オブジェクトに対する生成部の要求条件が存在するかを確認する。ステップ２１１で、駆動器は、要求条件内で生成及び変更可能な要素、属性、又は属性値のリストを確認する。その結果は、駆動器のリソース及び要求条件内での選択に対する基準に基づく。すなわち、その結果は、同一の要求条件下でも駆動器によって、あるいは同一の駆動器でも場合によって変更され得る。
【００４１】
ステップ２１３で、駆動器は、その特定条件によってリストから要素、属性、又は属性値を選択する。ここで、“駆動器の特定条件”とは、要求条件内で又は要求条件が存在しない状態で未完成された要素、属性、及び属性値を完成する駆動器の判断条件を意味する。例えば、判断条件は、駆動器のリソース能力、リッチメディアアプリケーションユーザーの選好度のうちいずれか一つを含み、ここではこれらに対する詳細な説明を提供しない。
【００４２】
駆動器は、ステップ２１５で、選択された値でリッチメディアアプリケーションを構成するオブジェクトの階層構造を完成し、ステップ２１７でリッチメディアアプリケーションを遂行する。
【００４３】
図３は、本発明の一実施形態による生成部装置を示すブロック構成図である。
図３を参照すると、生成部は、メディアオブジェクト３０１を受信した後に、リッチメディアコンテンツ生成部３１０でリッチメディアアプリケーションのコンテンツを構成する。このリッチメディアコンテンツ生成部３１０で、各構成オブジェクトを生成するプロセスは、メディアオブジェクト間の双方向性、時空間配置、イベント、及び命令語といったリッチメディア機能を用いて遂行される。
【００４４】
未完成オブジェクト及び未完成要素設定部３２０は、未完成オブジェクト及び未完成要素の設定情報を用いて構成オブジェクトを生成する。未完成オブジェクト及び未完成要素設定部３２０は、＜表４＞〜＜表６＞の実施形態に記載された生成部の要求条件を定義して構成オブジェクトを生成する。
リッチメディアコンテンツ送信部３４０は、構成オブジェクトを含むリッチメディアコンテンツを駆動器に伝送する。リッチメディアコンテンツを符号化するプロセスは、リッチメディアコンテンツ生成部３１０にさらに含まれることができる。上述したように生成部及び駆動器が物理的に一つのデバイスで存在するので、リッチメディアコンテンツ送信部３４０は、他のデバイスへの伝送だけでなく、生成部の論理的エンティティから駆動器の論理的エンティティへの伝送も含むことに注意すべきである。
【００４５】
図４は、本発明の一実施形態による駆動器装置を示すブロック構成図である。
図４を参照すると、駆動器のリッチメディア受信部４０１は、リッチメディアアプリケーションを受信し、受信されたリッチメディアアプリケーションを階層構造生成部４２０に伝送する。階層構造生成部４２０は、該当アプリケーションの階層構造を構成し、階層構造生成部４２０内に提供される未完成オブジェクト及び未完成要素制御部４１０は、各オブジェクトの階層構造で未完成オブジェクト及び未完成要素を確認する。選択部４３０は、生成部の要求条件と駆動器の選択によって未完成要素、属性、及び属性値を選択する。選択プロセスは、多様なアルゴリズムとリソースを用いて達成でき、ここではその具体的な説明は簡潔さのために提供しない。
リッチメディアコンテンツ実行部４４０は、完成した階層構造を用いてリッチメディアコンテンツを実行する。ここで、リッチメディアコンテンツの実行は、リッチメディアコンテンツを駆動器で再生することを含む。
【００４６】
上記した本発明による実施形態は、コンピュータ読み取り可能な記録媒体上のコンピュータ読み取り可能なコードとして実施されることができる。このコンピュータ読み取り可能な記録媒体は、コンピュータシステムによって読み取り可能なデータを格納するデータストレージデバイスとなり得る。コンピュータ読み取り可能な記録媒体の例としては、ＲＯＭ(Read-Only Memory)、ＲＡＭ(Random-Access Memory)、ＣＤ-ＲＯＭ、磁気テープ、フロッピー（登録商標）ディスク、光データ格納装置、及び搬送波(有無線伝送経路を介してインターネットを経由するデータ伝送のような)を含むが、これに限定されることではない。また、このコンピュータ読み取り可能な記録媒体は、ネットワーク接続されたコンピュータシステムにわたって分散されることによって、コンピュータ読み取り可能なコードは分散形態で格納及び遂行される。また、本発明を達成するための機能(function)プログラム、コード、及びコードセグメントは、当該技術分野における熟練されたプログラマにとっては容易に理解できることである。
【００４７】
以上、本発明を具体的な実施形態に関して図示及び説明したが、添付した特許請求の範囲及びこれと均等なものに基づいて規定されるような本発明の精神及び範囲を外れることなく、形式や細部の様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。
【符号の説明】
【００４８】
３０１ ・・・メディアオブジェクト
３１０ ・・・リッチメディアコンテンツ生成部
３２０ ・・・未完成オブジェクト及び未完成要素設定部
３４０ ・・・リッチメディアコンテンツ送信部
４０１ ・・・リッチメディア受信部
４１０ ・・・未完成オブジェクト及び未完成要素制御部
４２０ ・・・階層構造生成部
４３０ ・・・選択部
４４０ ・・・リッチメディアコンテンツ実行部
【特許請求の範囲】
【請求項１】
生成部におけるコンテンツを送信する方法であって、
階層構造で形態された各ノードの構成情報を駆動器が変更可能な形態で生成するステップと、
前記各ノードの構成情報を含むコンテンツを前記駆動器に伝送するステップと、
を有することを特徴とする方法。
【請求項２】
前記各ノードの構成情報を生成するステップは、各ノードの構成情報に前記生成部の要求条件を含むステップを有することを特徴とする請求項１に記載の方法。
【請求項３】
駆動器におけるコンテンツを受信する方法であって、
生成部から前記コンテンツを受信するステップと、
前記受信されたコンテンツの階層構造で形成される各ノードの構成情報が駆動器にて変更可能な形態で生成されたか否かを判定するステップと、
前記構成情報が変更可能な形態で生成された場合、前記駆動器の判断条件によって各ノードを再構成するステップと、
前記再構成されたノードに対してアプリケーションを遂行するステップと、
を有することを特徴とする方法。
【請求項４】
前記生成部の要求条件が要素、属性、及び属性値のうち少なくとも一つが定義されていないノードに含まれているか否かを判定するステップと、
前記生成部の要求条件が前記ノードに含まれた場合に、前記生成部の要求条件によって各ノードを生成するステップと、
前記生成されたノードに対してアプリケーションを遂行するステップと、
をさらに有することを特徴とする請求項３に記載の方法。
【請求項５】
生成部におけるコンテンツを送信する装置であって、
駆動器が変更可能な形態を有する階層構造で形成される各ノードの構成情報を生成するコンテンツ生成部と、
前記各ノードの構成情報を含むコンテンツを前記駆動器に送信する送信部と、
を含むことを特徴とする装置。
【請求項６】
前記各ノードの構成情報は前記生成部の要求条件を含むことを特徴とする請求項５に記載の装置。
【請求項７】
駆動器におけるコンテンツを受信する装置であって、
生成部から前記コンテンツを受信する受信部と、
前記受信されたコンテンツの階層構造で形成される各ノードの構成情報が前記駆動器にて変更可能な形態で形成されたか否かを判定し、前記構成情報が変更可能な形態で生成された場合に、駆動器の判断条件によって各ノードを再構成する階層構造生成部と、
前記再構成されたノードに対してアプリケーションを遂行するコンテンツ実行部と、
を含むことを特徴とする装置。
【請求項８】
前記階層構造生成部は、前記生成部の要求条件が要素、属性、及び属性値のうち少なくとも一つが定義されていないノードに含まれているか否かを判定し、前記生成部の要求条件が前記ノードに含まれた場合に、前記生成部の要求条件によって各ノードを生成することを特徴とする請求項７に記載の装置。
【請求項９】
前記駆動器の判断条件は、前記駆動器のリソース能力及びリッチメディアアプリケーションユーザーの選好度のうち少なくとも一つを含むことを特徴とする請求項３に記載の方法及び請求項７に記載の装置。
【請求項１０】
各ノードの構成情報は、要素、属性、及び属性値のうち少なくとも一つを含むことを特徴とする請求項１、３に記載の方法及び請求項５、７に記載の装置。
【請求項１１】
前記変更可能な形態は、前記要素、属性、及び属性値のうち少なくとも一つが定義されていない形態、及び
前記駆動器が固有権限に基づいた選択を通じてシーンを完成するための要素を選択しない場合、駆動器が前記シーンを完成するように生成部がデフォルト要素を指定する形態のうちいずれか一つであることを特徴とする請求項１、３に記載の方法及び請求項５、７に記載の装置。
【請求項１２】
前記生成部の要求条件は、前記駆動器が変更できない要素及び属性値のうち少なくとも一つを前記生成部が指定することを示すことを特徴とする請求項１、３に記載の方法及び請求項５、７に記載の装置。
【請求項１３】
前記生成部の要求条件は、前記駆動器が生成できない要素及び属性値のうち少なくとも一つを前記生成部が指定することを示すことを特徴とする請求項１、３に記載の方法及び請求項５、７に記載の装置。
【請求項１４】
前記生成部の要求条件は、前記駆動器が選択可能な値を前記生成部が指定することを示すことを特徴とする請求項１、３に記載の方法及び請求項５、７に記載の装置。
【請求項１】
生成部におけるコンテンツを送信する方法であって、
階層構造で形態された各ノードの構成情報を駆動器が変更可能な形態で生成するステップと、
前記各ノードの構成情報を含むコンテンツを前記駆動器に伝送するステップと、
を有することを特徴とする方法。
【請求項２】
前記各ノードの構成情報を生成するステップは、各ノードの構成情報に前記生成部の要求条件を含むステップを有することを特徴とする請求項１に記載の方法。
【請求項３】
駆動器におけるコンテンツを受信する方法であって、
生成部から前記コンテンツを受信するステップと、
前記受信されたコンテンツの階層構造で形成される各ノードの構成情報が駆動器にて変更可能な形態で生成されたか否かを判定するステップと、
前記構成情報が変更可能な形態で生成された場合、前記駆動器の判断条件によって各ノードを再構成するステップと、
前記再構成されたノードに対してアプリケーションを遂行するステップと、
を有することを特徴とする方法。
【請求項４】
前記生成部の要求条件が要素、属性、及び属性値のうち少なくとも一つが定義されていないノードに含まれているか否かを判定するステップと、
前記生成部の要求条件が前記ノードに含まれた場合に、前記生成部の要求条件によって各ノードを生成するステップと、
前記生成されたノードに対してアプリケーションを遂行するステップと、
をさらに有することを特徴とする請求項３に記載の方法。
【請求項５】
生成部におけるコンテンツを送信する装置であって、
駆動器が変更可能な形態を有する階層構造で形成される各ノードの構成情報を生成するコンテンツ生成部と、
前記各ノードの構成情報を含むコンテンツを前記駆動器に送信する送信部と、
を含むことを特徴とする装置。
【請求項６】
前記各ノードの構成情報は前記生成部の要求条件を含むことを特徴とする請求項５に記載の装置。
【請求項７】
駆動器におけるコンテンツを受信する装置であって、
生成部から前記コンテンツを受信する受信部と、
前記受信されたコンテンツの階層構造で形成される各ノードの構成情報が前記駆動器にて変更可能な形態で形成されたか否かを判定し、前記構成情報が変更可能な形態で生成された場合に、駆動器の判断条件によって各ノードを再構成する階層構造生成部と、
前記再構成されたノードに対してアプリケーションを遂行するコンテンツ実行部と、
を含むことを特徴とする装置。
【請求項８】
前記階層構造生成部は、前記生成部の要求条件が要素、属性、及び属性値のうち少なくとも一つが定義されていないノードに含まれているか否かを判定し、前記生成部の要求条件が前記ノードに含まれた場合に、前記生成部の要求条件によって各ノードを生成することを特徴とする請求項７に記載の装置。
【請求項９】
前記駆動器の判断条件は、前記駆動器のリソース能力及びリッチメディアアプリケーションユーザーの選好度のうち少なくとも一つを含むことを特徴とする請求項３に記載の方法及び請求項７に記載の装置。
【請求項１０】
各ノードの構成情報は、要素、属性、及び属性値のうち少なくとも一つを含むことを特徴とする請求項１、３に記載の方法及び請求項５、７に記載の装置。
【請求項１１】
前記変更可能な形態は、前記要素、属性、及び属性値のうち少なくとも一つが定義されていない形態、及び
前記駆動器が固有権限に基づいた選択を通じてシーンを完成するための要素を選択しない場合、駆動器が前記シーンを完成するように生成部がデフォルト要素を指定する形態のうちいずれか一つであることを特徴とする請求項１、３に記載の方法及び請求項５、７に記載の装置。
【請求項１２】
前記生成部の要求条件は、前記駆動器が変更できない要素及び属性値のうち少なくとも一つを前記生成部が指定することを示すことを特徴とする請求項１、３に記載の方法及び請求項５、７に記載の装置。
【請求項１３】
前記生成部の要求条件は、前記駆動器が生成できない要素及び属性値のうち少なくとも一つを前記生成部が指定することを示すことを特徴とする請求項１、３に記載の方法及び請求項５、７に記載の装置。
【請求項１４】
前記生成部の要求条件は、前記駆動器が選択可能な値を前記生成部が指定することを示すことを特徴とする請求項１、３に記載の方法及び請求項５、７に記載の装置。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２０１１−５２８２１１（Ｐ２０１１−５２８２１１Ａ）
【公表日】平成２３年１１月１０日（２０１１．１１．１０）
【国際特許分類】
【出願番号】特願２０１１−５１８６５２（Ｐ２０１１−５１８６５２）
【出願日】平成２１年７月１６日（２００９．７．１６）
【国際出願番号】ＰＣＴ／ＫＲ２００９／００３９２７
【国際公開番号】ＷＯ２０１０／００８２２０
【国際公開日】平成２２年１月２１日（２０１０．１．２１）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【出願人】（５１１０１０２００）ユニヴァーシティー−インダストリー・コーペレーション・グループ・オブ・キュン・ヒー・ユニヴァーシティー (1)
【Ｆターム（参考）】
【公表日】平成２３年１１月１０日（２０１１．１１．１０）
【国際特許分類】
【出願日】平成２１年７月１６日（２００９．７．１６）
【国際出願番号】ＰＣＴ／ＫＲ２００９／００３９２７
【国際公開番号】ＷＯ２０１０／００８２２０
【国際公開日】平成２２年１月２１日（２０１０．１．２１）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【出願人】（５１１０１０２００）ユニヴァーシティー−インダストリー・コーペレーション・グループ・オブ・キュン・ヒー・ユニヴァーシティー (1)
【Ｆターム（参考）】
[ Back to top ]