JP5317835B2 - コンテンツ属性情報提供装置、コンテンツ属性情報提供方法、及びコンピュータプログラム - Google Patents
コンテンツ属性情報提供装置、コンテンツ属性情報提供方法、及びコンピュータプログラム Download PDFInfo
- Publication number
- JP5317835B2 JP5317835B2 JP2009134412A JP2009134412A JP5317835B2 JP 5317835 B2 JP5317835 B2 JP 5317835B2 JP 2009134412 A JP2009134412 A JP 2009134412A JP 2009134412 A JP2009134412 A JP 2009134412A JP 5317835 B2 JP5317835 B2 JP 5317835B2
- Authority
- JP
- Japan
- Prior art keywords
- content
- attribute information
- metadata
- storage area
- providing apparatus
- 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
- 238000000034 method Methods 0.000 title claims description 56
- 238000004590 computer program Methods 0.000 title claims description 6
- 230000005540 biological transmission Effects 0.000 claims description 5
- 230000004044 response Effects 0.000 abstract description 19
- 238000006243 chemical reaction Methods 0.000 description 81
- 230000008569 process Effects 0.000 description 29
- 230000009471 action Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 14
- 238000004891 communication Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 8
- 239000000284 extract Substances 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 1
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/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
- G06F16/48—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Library & Information Science (AREA)
- Multimedia (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
Description
本発明は、コンテンツ属性情報提供装置、コンテンツ属性情報提供方法、及びコンピュータプログラムに関し、特に、ネットワーク上にコンテンツに関するコンテンツ属性情報を提供するために用いて好適なものである。
ＵＰｎＰ（Universal Plug and Play）を利用したＤＬＮＡ（Digital Living Network Alliance）では、次のような仕組みが規定されている。すなわち、デジタルメディアサーバ（ＤＭＳ：Digital Media Server）を用いて、コンテンツを蓄積し、ホームネットワーク内の他の機器に対してコンテンツや、コンテンツに付随するメタデータを提供する仕組みが規定されている。ＤＭＳの例としては、撮影したコンテンツを蓄積するカメラ装置や、放送コンテンツを蓄積する放送コンテンツ記録再生装置等が挙げられる。
一方、インターネット上の写真共有サイトやビデオ共有サイト等のＷｅｂサービスが注目されている。これもインターネット上のコンテンツ提供装置にコンテンツを蓄積し、当該コンテンツやコンテンツメタデータ（コンテンツ属性情報）を提供するサービスである。
一方、インターネット上の写真共有サイトやビデオ共有サイト等のＷｅｂサービスが注目されている。これもインターネット上のコンテンツ提供装置にコンテンツを蓄積し、当該コンテンツやコンテンツメタデータ（コンテンツ属性情報）を提供するサービスである。
しかし、ＵＰｎＰ／ＤＬＮＡにおいて規定されているコンテンツメタデータと、インターネット上のコンテンツ提供装置で利用されるコンテンツメタデータとでは、形式、及び提供方法が異なる。そのため、コンテンツ提供装置は、ホームネットワーク内の機器に対して、インターネット上のコンテンツ提供装置で利用されるコンテンツメタデータをホームネットワーク内の機器に提供することができなかった。
そこで、コンテンツ提供装置に代わり、メタデータ提供装置がコンテンツ提供装置からコンテンツメタデータをホームネットワーク内の機器が解釈できる形式に変換した上で事前に収集し、ホームネットワーク内の機器に提供する技術がある（特許文献１を参照）。このメタデータ提供装置は、コンテンツ提供装置からコンテンツメタデータを収集、変換した後、ディレクトリ構造に展開した上でメタデータ提供装置の内部に保持する。そして、ホームネットワーク内の機器からのコンテンツメタデータの取得要求に対して、メタデータ提供装置はメタデータ提供装置の内部に保持した変換済みのコンテンツメタデータをホームネットワーク内の機器に提供する。
そこで、コンテンツ提供装置に代わり、メタデータ提供装置がコンテンツ提供装置からコンテンツメタデータをホームネットワーク内の機器が解釈できる形式に変換した上で事前に収集し、ホームネットワーク内の機器に提供する技術がある（特許文献１を参照）。このメタデータ提供装置は、コンテンツ提供装置からコンテンツメタデータを収集、変換した後、ディレクトリ構造に展開した上でメタデータ提供装置の内部に保持する。そして、ホームネットワーク内の機器からのコンテンツメタデータの取得要求に対して、メタデータ提供装置はメタデータ提供装置の内部に保持した変換済みのコンテンツメタデータをホームネットワーク内の機器に提供する。
しかしながら、前述した従来技術でも、メタデータ提供装置は、コンテンツ提供装置から取得できないコンテンツメタデータについてはホームネットワーク内の機器に提供することはできないという問題点があった。
本発明は、このような問題点に鑑みてなされたものであり、取得要求のあったコンテンツ属性情報を確実に提供できるようにすることを目的とする。
本発明は、このような問題点に鑑みてなされたものであり、取得要求のあったコンテンツ属性情報を確実に提供できるようにすることを目的とする。
本発明のコンテンツ属性情報提供装置は、コンテンツ提供装置が管理している階層分けされた記憶領域の中のコンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得する第１の取得手段と、前記第１の取得手段により取得されたコンテンツ属性情報に基づいて、前記階層分けされた記憶領域の中のコンテンツを示す識別子と、当該コンテンツが記憶された記憶領域を示す識別子と、を記憶媒体に記憶する記憶手段と、コンテンツに関する所定の形式のコンテンツ属性情報を受信する受信装置からコンテンツ属性情報の取得要求を受信した場合に、前記取得要求のあったコンテンツ属性情報に対応するコンテンツが記憶された記憶領域を示す識別子を前記記憶媒体から取得するとともに、前記取得要求のあったコンテンツ属性情報を前記コンテンツ提供装置から取得する第２の取得手段と、前記受信装置から前記コンテンツに関するコンテンツ属性情報の取得要求を受信した場合に、前記第２の取得手段により取得された前記コンテンツが記憶された記憶領域を示す識別子と、前記コンテンツ属性情報と、前記コンテンツを示す識別子と、前記コンテンツが記憶された記憶領域を示す識別子とを、前記所定の形式で前記受信装置に送信する送信手段と、を備え、前記コンテンツを示す識別子は、当該コンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得するための第１のアドレスであり、前記コンテンツが記憶された記憶領域を示す識別子は、当該記憶領域に関する属性情報を前記コンテンツ提供装置から取得するための第２のアドレスであり、前記第２の取得手段は、前記第１のアドレスを用いて、前記取得要求のあったコンテンツ属性情報を前記コンテンツ提供装置から取得することを特徴とする。
本発明によれば、取得要求のあったコンテンツ属性情報を従来よりも確実に提供することができる。
以下、図面を参照して、本発明に関わる一実施形態を説明する。
図１は、本実施形態によるメタデータ提供システムの構成例を示す図である。
ＬＡＮ１０は、ホームネットワークとしての有線ＬＡＮ（Local Area Network）又は無線ＬＡＮ（Wireless LAN）である。尚、本実施形態では、ホームネットワークとして有線ＬＡＮ又は無線ＬＡＮを利用しているが、ホームネットワークはこれらに限られない。ホームネットワークは、例えば、ＷＡＮ（Wide Area Network）、アドホックネットワーク、Bluetooth（登録商標）、Zigbee、ＵＷＢ等でもよい。
メタデータ提供装置２０は、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツメタデータの取得要求に対して、コンテンツ提供装置５０のコンテンツメタデータを取得し、所定のDIDL-Lite形式に変換して、ＤＬＮＡ機器３０に提供する。本実施形態において、メタデータ提供装置２０は、ＤＬＮＡにおけるＤＭＳとしての機能を有する。メタデータ提供装置２０が有するメタデータ提供サービスは、ＤＭＳにおけるＣＤＳ（Content Directory Service）が挙げられる。メタデータ提供装置２０の具体的な例としては、ステーション装置、クレードル装置、ネットワーク中継装置、ＰＣ装置が挙げられる。尚、本実施形態では、メタデータ提供装置２０としてＤＬＮＡにおけるＤＭＳの機能を有する装置を挙げた。しかし、メタデータ提供装置は、メタデータ提供装置２０と同様にホームネットワーク内にコンテンツメタデータを提供する機能等を有する装置であればどのような装置であってもよい。
図１は、本実施形態によるメタデータ提供システムの構成例を示す図である。
ＬＡＮ１０は、ホームネットワークとしての有線ＬＡＮ（Local Area Network）又は無線ＬＡＮ（Wireless LAN）である。尚、本実施形態では、ホームネットワークとして有線ＬＡＮ又は無線ＬＡＮを利用しているが、ホームネットワークはこれらに限られない。ホームネットワークは、例えば、ＷＡＮ（Wide Area Network）、アドホックネットワーク、Bluetooth（登録商標）、Zigbee、ＵＷＢ等でもよい。
メタデータ提供装置２０は、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツメタデータの取得要求に対して、コンテンツ提供装置５０のコンテンツメタデータを取得し、所定のDIDL-Lite形式に変換して、ＤＬＮＡ機器３０に提供する。本実施形態において、メタデータ提供装置２０は、ＤＬＮＡにおけるＤＭＳとしての機能を有する。メタデータ提供装置２０が有するメタデータ提供サービスは、ＤＭＳにおけるＣＤＳ（Content Directory Service）が挙げられる。メタデータ提供装置２０の具体的な例としては、ステーション装置、クレードル装置、ネットワーク中継装置、ＰＣ装置が挙げられる。尚、本実施形態では、メタデータ提供装置２０としてＤＬＮＡにおけるＤＭＳの機能を有する装置を挙げた。しかし、メタデータ提供装置は、メタデータ提供装置２０と同様にホームネットワーク内にコンテンツメタデータを提供する機能等を有する装置であればどのような装置であってもよい。
ＤＬＮＡ機器３０は、ホームネットワーク内の機器である。ＤＬＮＡ機器３０は、メタデータ提供装置２０が提供するコンテンツメタデータを閲覧する。ＤＬＮＡ機器３０の具体的な例としては、ＤＭＣ（Digital Media Controller）、ＤＭＰ（Digital Media Player）が挙げられる。尚、本実施形態では、受信装置の一例としてＤＬＮＡ機器を挙げた。しかし、受信装置は、ＤＬＮＡ機器３０と同様に、ホームネットワーク内でコンテンツメタデータを取得する機能等を有していればどのような装置であってもよい。
インターネット４０は、インターネットとしてのＷＡＮである。尚、本実施形態では、インターネットとしてＷＡＮを利用しているが、ＷＡＮの代わりに、ＬＡＮ、アドホックネットワーク、公衆回線、ＮＧＮ（Next Generation Network）等を用いてもよい。
コンテンツ提供装置５０は、インターネット４０上において、コンテンツ及びコンテンツメタデータを提供する。尚、本実施形態では、コンテンツ提供装置５０が提供するコンテンツメタデータの形式及び提供方法は、メタデータ提供装置２０がＤＬＮＡ機器３０に提供するコンテンツメタデータの形式及び提供方法と異なるものとする。コンテンツ提供装置５０の具体的な例としては、ＰＣ装置、サーバ装置が挙げられる。
尚、図１では、メタデータ提供装置２０、ＤＬＮＡ機器３０、及びコンテンツ提供装置５０が夫々１つずつ配置された場合を例に挙げて説明した。しかしながら、メタデータ提供装置２０、ＤＬＮＡ機器３０、及びコンテンツ提供装置５０の少なくとも何れか１つが複数あってもよい。
インターネット４０は、インターネットとしてのＷＡＮである。尚、本実施形態では、インターネットとしてＷＡＮを利用しているが、ＷＡＮの代わりに、ＬＡＮ、アドホックネットワーク、公衆回線、ＮＧＮ（Next Generation Network）等を用いてもよい。
コンテンツ提供装置５０は、インターネット４０上において、コンテンツ及びコンテンツメタデータを提供する。尚、本実施形態では、コンテンツ提供装置５０が提供するコンテンツメタデータの形式及び提供方法は、メタデータ提供装置２０がＤＬＮＡ機器３０に提供するコンテンツメタデータの形式及び提供方法と異なるものとする。コンテンツ提供装置５０の具体的な例としては、ＰＣ装置、サーバ装置が挙げられる。
尚、図１では、メタデータ提供装置２０、ＤＬＮＡ機器３０、及びコンテンツ提供装置５０が夫々１つずつ配置された場合を例に挙げて説明した。しかしながら、メタデータ提供装置２０、ＤＬＮＡ機器３０、及びコンテンツ提供装置５０の少なくとも何れか１つが複数あってもよい。
図２は、メタデータ提供装置２０のハードウェア構成例を示すブロック図である。尚、メタデータ提供装置２０は、ＰＣ等のコンピュータシステム以外の装置であっても実現することができる。すなわち、メタデータ提供装置２０は、他のネットワーク制御装置と通信するための通信機能を有する各種端末、又は、これらの組合せによっても実施可能である。端末としては、例えば、ワークステーション、ノートブックＰＣ、パームトップＰＣ、コンピュータを内蔵したテレビ等の各種家電製品、通信機能を有するゲーム機、携帯電話、ＰＨＳ等が挙げられる。
図２において、ＣＰＵ（Central Processing Unit）２０１は、メタデータ提供装置２０全体を制御する。ＲＯＭ（Read Only Memory）２０２は、変更を必要としないプログラムやパラメータを格納する。ＲＡＭ（Random Access Memory）２０３は、外部装置等から供給されるプログラムやデータを一時的に記憶する。外部記憶装置２０４は、メタデータ提供装置２０に固定して設置されたハードディスクやメモリカード、或いはメタデータ提供装置２０から着脱可能なフレキシブルディスク（ＦＤ）、コンパクトディスク（ＣＤ）等の光ディスク等である。また、外部記憶装置２０４として、磁気カードや光カード、ＩＣカード、メモリカード等を用いてもよい。ＬＡＮインタフェース２０５は、ＬＡＮ１０に接続するための通信制御を行う。システムバス２０６は、２０１〜２０５の各ユニットを通信可能に接続する。
図２において、ＣＰＵ（Central Processing Unit）２０１は、メタデータ提供装置２０全体を制御する。ＲＯＭ（Read Only Memory）２０２は、変更を必要としないプログラムやパラメータを格納する。ＲＡＭ（Random Access Memory）２０３は、外部装置等から供給されるプログラムやデータを一時的に記憶する。外部記憶装置２０４は、メタデータ提供装置２０に固定して設置されたハードディスクやメモリカード、或いはメタデータ提供装置２０から着脱可能なフレキシブルディスク（ＦＤ）、コンパクトディスク（ＣＤ）等の光ディスク等である。また、外部記憶装置２０４として、磁気カードや光カード、ＩＣカード、メモリカード等を用いてもよい。ＬＡＮインタフェース２０５は、ＬＡＮ１０に接続するための通信制御を行う。システムバス２０６は、２０１〜２０５の各ユニットを通信可能に接続する。
図３は、メタデータ提供装置２０のモジュール構成例を示すブロック図である。
ＬＡＮ通信制御部３０１は、ＬＡＮ１０に接続するための通信制御を行う。
ＳＳＤＰ処理部３０２は、ＬＡＮ通信制御部３０１から、対応するパケットを受信し、ＵＰｎＰのＳＳＤＰ（Simple Service Discovery Protocol）処理を行う。ＳＳＤＰ処理は、メタデータ提供装置２０がＤＭＳとしてＬＡＮ１０上に存在することをＬＡＮ１０上のＤＬＮＡ機器３０を含む他のＤＬＮＡ機器に広告する。これは、ＳＳＤＰにおけるaliveメッセージと呼ばれる。また、ＳＳＤＰ処理は、ＬＡＮ１０上の他のＵＰｎＰサービスを発見したり、他のＤＬＮＡ機器からのＵＰｎＰサービスの発見に関する応答を行ったりする。尚、本実施形態ではＳＳＤＰ処理を利用しているが、ＳＳＤＰ処理の代わりに、WS-DiscoveryやＭＡＣ（Media Access Control）アドレス等を用いた別の手段を利用してもよい。
ＬＡＮ通信制御部３０１は、ＬＡＮ１０に接続するための通信制御を行う。
ＳＳＤＰ処理部３０２は、ＬＡＮ通信制御部３０１から、対応するパケットを受信し、ＵＰｎＰのＳＳＤＰ（Simple Service Discovery Protocol）処理を行う。ＳＳＤＰ処理は、メタデータ提供装置２０がＤＭＳとしてＬＡＮ１０上に存在することをＬＡＮ１０上のＤＬＮＡ機器３０を含む他のＤＬＮＡ機器に広告する。これは、ＳＳＤＰにおけるaliveメッセージと呼ばれる。また、ＳＳＤＰ処理は、ＬＡＮ１０上の他のＵＰｎＰサービスを発見したり、他のＤＬＮＡ機器からのＵＰｎＰサービスの発見に関する応答を行ったりする。尚、本実施形態ではＳＳＤＰ処理を利用しているが、ＳＳＤＰ処理の代わりに、WS-DiscoveryやＭＡＣ（Media Access Control）アドレス等を用いた別の手段を利用してもよい。
ＳＯＡＰ処理部３０３は、ＬＡＮ通信制御部３０１から、対応するパケットを受信し、ＵＰｎＰのＳＯＡＰ（Simple Access Object Protocol）処理を行う。ＳＯＡＰ処理は、他のＵＰｎＰサービスへの要求を行ったり、他のＤＬＮＡ機器からのＵＰｎＰサービスの要求を受け付けたり、その要求に対する応答を行ったりする。特に、ＳＯＡＰ処理部３０３は、ＬＡＮ１０上のＤＬＮＡ機器３０から、コンテンツ属性情報の一例であるコンテンツメタデータの取得要求を受け付ける。さらに、ＳＯＡＰ処理部３０３は、コンテンツメタデータの取得要求に対する応答をＤＬＮＡ機器３０に送信する。尚、本実施形態ではＳＯＡＰ処理を利用しているが、ＳＯＡＰ処理の代わりに、リモートプロシージャコール等、遠隔のオブジェクトを実行する別の手段を利用してもよい。
ＧＥＮＡ処理部３０４は、ＬＡＮ通信制御部３０１から、対応するパケットを受信し、ＵＰｎＰのＧＥＮＡ（General Event Notification Architecture）処理を行う。ＧＥＮＡ処理は、ＬＡＮ１０上の他のＤＬＮＡ機器へイベントの通知を行ったり、他のＤＬＮＡ機器が有するＵＰｎＰサービスのイベントの購読を行ったりする。尚、本実施形態ではＧＥＮＡ処理を利用しているが、ＧＥＮＡ処理の代わりに、WS-Eventing、WS-Notification等を用いた別の手段を利用してもよい。
制御部３０５は、メタデータ提供装置２０の全体の制御を行う。制御部３０５は、３０１〜３１４の各モジュールを管理、制御する。
ＧＥＮＡ処理部３０４は、ＬＡＮ通信制御部３０１から、対応するパケットを受信し、ＵＰｎＰのＧＥＮＡ（General Event Notification Architecture）処理を行う。ＧＥＮＡ処理は、ＬＡＮ１０上の他のＤＬＮＡ機器へイベントの通知を行ったり、他のＤＬＮＡ機器が有するＵＰｎＰサービスのイベントの購読を行ったりする。尚、本実施形態ではＧＥＮＡ処理を利用しているが、ＧＥＮＡ処理の代わりに、WS-Eventing、WS-Notification等を用いた別の手段を利用してもよい。
制御部３０５は、メタデータ提供装置２０の全体の制御を行う。制御部３０５は、３０１〜３１４の各モジュールを管理、制御する。
要求メタデータ判別部３０６は、ＳＯＡＰ処理部３０３で受け付けた"ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツメタデータの取得要求"に対して、要求対象のコンテンツ識別子と、要求メタデータ種別を判別する。本実施形態では、判別する要求メタデータ種別として、ＣＤＳのBrowseアクションにおいてメタデータ種別を示すBrowseFlagパラメータを用いる。
具体的に、BrowseFlagパラメータは、BrowseMetadataと、BrowseDirectChildren、の２種類から構成される。BrowseMetadataは、対象コンテンツ自身に関するコンテンツメタデータの取得要求を示す。一方、BrowseDirectChildrenは、対象コンテンツのクラスがDIDL-Liteにおけるコンテナ（Container）の場合、そのコンテナに含まれるコンテンツのリストの取得要求を示す。コンテナはいわばディレクトリである。また、BrowseDirectChildrenは、ディレクトリ内のコンテンツのリスト（コンテンツリスト）のコンテンツメタデータの取得要求を意味する。
具体的に、BrowseFlagパラメータは、BrowseMetadataと、BrowseDirectChildren、の２種類から構成される。BrowseMetadataは、対象コンテンツ自身に関するコンテンツメタデータの取得要求を示す。一方、BrowseDirectChildrenは、対象コンテンツのクラスがDIDL-Liteにおけるコンテナ（Container）の場合、そのコンテナに含まれるコンテンツのリストの取得要求を示す。コンテナはいわばディレクトリである。また、BrowseDirectChildrenは、ディレクトリ内のコンテンツのリスト（コンテンツリスト）のコンテンツメタデータの取得要求を意味する。
前述したように、コンテンツメタデータには２種類存在する。以後、本実施形態では、コンテンツ自身に関するコンテンツメタデータを、コンテンツ情報メタデータと称する。一方、コンテンツリストに関するコンテンツメタデータを、コンテンツリストメタデータと称する。
メタデータ取得アドレス決定部３０７は、要求メタデータ判別部３０６の要求メタデータ種別の判別結果に基づき、コンテンツ提供装置５０から取得するコンテンツメタデータのアドレスを決定する。本実施形態におけるコンテンツメタデータのアドレスとは、ＵＲＩ（Uniform Resource Identifier）である。より具体的に、要求メタデータ判別部３０６の要求メタデータ種別の判別結果がBrowseMetadataである場合、メタデータ取得アドレス決定部３０７は、コンテンツ情報メタデータ取得アドレスをコンテンツメタデータのアドレスとして決定する。一方、要求メタデータ判別部３０６の要求メタデータ種別の判別結果がBrowseDirectChildrenである場合、メタデータ取得アドレス決定部３０７は、コンテンツリストメタデータ取得アドレスをコンテンツメタデータのアドレスとして決定する。
メタデータ取得アドレス決定部３０７は、要求メタデータ判別部３０６の要求メタデータ種別の判別結果に基づき、コンテンツ提供装置５０から取得するコンテンツメタデータのアドレスを決定する。本実施形態におけるコンテンツメタデータのアドレスとは、ＵＲＩ（Uniform Resource Identifier）である。より具体的に、要求メタデータ判別部３０６の要求メタデータ種別の判別結果がBrowseMetadataである場合、メタデータ取得アドレス決定部３０７は、コンテンツ情報メタデータ取得アドレスをコンテンツメタデータのアドレスとして決定する。一方、要求メタデータ判別部３０６の要求メタデータ種別の判別結果がBrowseDirectChildrenである場合、メタデータ取得アドレス決定部３０７は、コンテンツリストメタデータ取得アドレスをコンテンツメタデータのアドレスとして決定する。
メタデータ取得部３０８は、メタデータ取得アドレス決定部３０７で決定したアドレスに基づき、コンテンツ提供装置５０からコンテンツメタデータを取得する。
変換テーブル作成部３０９は、メタデータ取得部３０８で取得したコンテンツメタデータから、DIDL-Liteに変換する際に必要となる情報を抽出し、変換レコードを作成する。変換テーブル作成部３０９は、作成した変換レコードを、記憶部３１４を介して、図２に示したメタデータ提供装置２０の外部記憶装置２０４内に用意した変換テーブル内に記憶する。変換テーブルの内容については後述する。
メタデータ変換部３１０は、メタデータ取得部３０８で取得したコンテンツメタデータを、変換テーブル作成部３０９で作成した変換テーブルを用いて、所定のDIDL-Lite形式のコンテンツメタデータに変換する。
メタデータ提供部３１１は、メタデータ変換部３１０で変換したコンテンツメタデータを、ＳＯＡＰ処理部３０３を介して、ＣＤＳのBrowseアクションの応答として、ＬＡＮ１０上のＤＬＮＡ機器３０に返す。
ユーザ情報管理部３１２は、記憶部３１４を介して、図２に示したメタデータ提供装置２０の外部記憶装置２０４内に記憶したユーザ情報テーブルの管理を行う。ユーザ情報テーブルは、コンテンツ提供装置５０を利用する際のユーザアカウント情報から構成される。
コンテンツ提供装置管理部３１３は、コンテンツ提供装置５０へのログインを行う。
記憶部３１４は、対象となる情報を、図２に示したメタデータ提供装置２０の外部記憶装置２０４内の記憶領域に記憶する。記憶部３１４は、例えば、変換テーブル作成部３０９が作成した変換テーブルや、ユーザ情報管理部３１２が作成したユーザ情報テーブルを外部記憶装置２０４内の記憶領域に記憶する。
変換テーブル作成部３０９は、メタデータ取得部３０８で取得したコンテンツメタデータから、DIDL-Liteに変換する際に必要となる情報を抽出し、変換レコードを作成する。変換テーブル作成部３０９は、作成した変換レコードを、記憶部３１４を介して、図２に示したメタデータ提供装置２０の外部記憶装置２０４内に用意した変換テーブル内に記憶する。変換テーブルの内容については後述する。
メタデータ変換部３１０は、メタデータ取得部３０８で取得したコンテンツメタデータを、変換テーブル作成部３０９で作成した変換テーブルを用いて、所定のDIDL-Lite形式のコンテンツメタデータに変換する。
メタデータ提供部３１１は、メタデータ変換部３１０で変換したコンテンツメタデータを、ＳＯＡＰ処理部３０３を介して、ＣＤＳのBrowseアクションの応答として、ＬＡＮ１０上のＤＬＮＡ機器３０に返す。
ユーザ情報管理部３１２は、記憶部３１４を介して、図２に示したメタデータ提供装置２０の外部記憶装置２０４内に記憶したユーザ情報テーブルの管理を行う。ユーザ情報テーブルは、コンテンツ提供装置５０を利用する際のユーザアカウント情報から構成される。
コンテンツ提供装置管理部３１３は、コンテンツ提供装置５０へのログインを行う。
記憶部３１４は、対象となる情報を、図２に示したメタデータ提供装置２０の外部記憶装置２０４内の記憶領域に記憶する。記憶部３１４は、例えば、変換テーブル作成部３０９が作成した変換テーブルや、ユーザ情報管理部３１２が作成したユーザ情報テーブルを外部記憶装置２０４内の記憶領域に記憶する。
ここで、図３に示したメタデータ提供装置２０のユーザ情報管理部３１２が管理するユーザ情報テーブルの例を説明する。本実施形態では、ユーザ情報テーブルは、ユーザＩＤ、パスワード、及びルートコンテンツ情報メタデータ取得アドレスをレコードとするテーブルにより構成される。
ユーザＩＤ及びパスワードは、コンテンツ提供装置５０を利用するために必要なユーザ単位の認証情報である。尚、本実施形態では、ユーザ情報テーブルに記憶されている"ユーザＩＤ及びパスワード"をユーザ認証に利用する場合を例に挙げて説明したが、認証トークン等の別の手段を利用してユーザ認証を行うようにしてもよい。
ルートコンテンツ情報メタデータ取得アドレスは、現在のコンテンツ提供装置５０の利用ユーザについて、ルートディレクトリにおけるコンテンツ情報メタデータを取得するためのアドレスである。これは、コンテンツ提供装置５０の利用ユーザ毎に異なる。通常、ユーザがコンテンツ提供装置５０にアカウントを開設する際、コンテンツ提供装置５０がこのルートコンテンツ情報メタデータ取得アドレスを決定する。よって、このルートコンテンツ情報メタデータ取得アドレスは静的に一意なアドレスとなる。本実施形態では、ルートコンテンツ情報メタデータ取得アドレスは、コンテンツ提供装置５０が規定する方式に基づき、ベースアドレスとユーザＩＤとの組合せから事前に決定されるものとする。
尚、本実施形態では、ユーザ情報テーブルに保持されているルートコンテンツ情報メタデータ取得アドレスを利用するが、必ずしもこのようにする必要はない。例えば、ユーザ情報テーブルにルートコンテンツ情報メタデータ取得アドレスを保持せず、コンテンツ提供装置５０が規定するベースアドレスとユーザＩＤの組合せからルートコンテンツ情報メタデータ取得アドレスを動的に決定する等の別の手段を利用してもよい。
ユーザＩＤ及びパスワードは、コンテンツ提供装置５０を利用するために必要なユーザ単位の認証情報である。尚、本実施形態では、ユーザ情報テーブルに記憶されている"ユーザＩＤ及びパスワード"をユーザ認証に利用する場合を例に挙げて説明したが、認証トークン等の別の手段を利用してユーザ認証を行うようにしてもよい。
ルートコンテンツ情報メタデータ取得アドレスは、現在のコンテンツ提供装置５０の利用ユーザについて、ルートディレクトリにおけるコンテンツ情報メタデータを取得するためのアドレスである。これは、コンテンツ提供装置５０の利用ユーザ毎に異なる。通常、ユーザがコンテンツ提供装置５０にアカウントを開設する際、コンテンツ提供装置５０がこのルートコンテンツ情報メタデータ取得アドレスを決定する。よって、このルートコンテンツ情報メタデータ取得アドレスは静的に一意なアドレスとなる。本実施形態では、ルートコンテンツ情報メタデータ取得アドレスは、コンテンツ提供装置５０が規定する方式に基づき、ベースアドレスとユーザＩＤとの組合せから事前に決定されるものとする。
尚、本実施形態では、ユーザ情報テーブルに保持されているルートコンテンツ情報メタデータ取得アドレスを利用するが、必ずしもこのようにする必要はない。例えば、ユーザ情報テーブルにルートコンテンツ情報メタデータ取得アドレスを保持せず、コンテンツ提供装置５０が規定するベースアドレスとユーザＩＤの組合せからルートコンテンツ情報メタデータ取得アドレスを動的に決定する等の別の手段を利用してもよい。
図４は、コンテンツ提供装置５０内のディレクトリ構造の一例を示す図である。具体的に図４は、ユーザ情報テーブルにおけるユーザＩＤ"User1"のディレクトリ構造の一例を示す図である。
図４におけるルートディレクトリ内の"User1"は、コンテンツ提供装置５０内の"User1"に対するルートディレクトリである。"［diretory］"はこのコンテンツがディレクトリであることを示す。上段の"User1RootInfoURI"は、ルートディレクトリ"User1"に対するコンテンツ情報メタデータ取得アドレスである。"User1"のルートディレクトリに対するコンテンツ情報メタデータ取得アドレスは、ユーザ情報管理部３１２が管理するユーザ情報テーブルのルートコンテンツ情報メタデータ取得アドレスである。下段の"User1RootContentListURI"は、ルートディレクトリ"User1"に対するコンテンツリストメタデータ取得アドレスである。
図４におけるルートディレクトリ内の"User1"は、コンテンツ提供装置５０内の"User1"に対するルートディレクトリである。"［diretory］"はこのコンテンツがディレクトリであることを示す。上段の"User1RootInfoURI"は、ルートディレクトリ"User1"に対するコンテンツ情報メタデータ取得アドレスである。"User1"のルートディレクトリに対するコンテンツ情報メタデータ取得アドレスは、ユーザ情報管理部３１２が管理するユーザ情報テーブルのルートコンテンツ情報メタデータ取得アドレスである。下段の"User1RootContentListURI"は、ルートディレクトリ"User1"に対するコンテンツリストメタデータ取得アドレスである。
図４の１階層目のディレクトリ１内の"Album1"は、ルートディレクトリ"User1"内に含まれるディレクトリ（サブディレクトリ）である。上段の"User1Album1InfoURI"は、ディレクトリ"Album1"に対するコンテンツ情報メタデータ取得アドレスである。下段の"User1Album1ContentListURI"は、ディレクトリ"Album1"に対するコンテンツリストメタデータ取得アドレスである。
図４の２階層目のディレクトリ２内の"Photo1"は、ディレクトリ"Album1"内に含まれるメディアである。"［media］"はこのコンテンツがメディアであることを示す。上段の"User1Photo1InfoURI"は、メディア"Photo1"に対するコンテンツ情報メタデータ取得アドレスである。なお、メディア"Photo1"はディレクトリではないため、コンテンツリストメタデータ取得アドレスは存在しない。
図４のその他の欄も以上と同様の内容であるため、その詳細な説明を省略する。
尚、本実施形態では、２階層のディレクトリ構造の場合を例に挙げたが、ディレクトリ構造は２層に限らず、３階層以上のディレクトリ構造や、同一ディレクトリ内にディレクトリコンテンツとメディアコンテンツとが混在していてもよい。
図４の２階層目のディレクトリ２内の"Photo1"は、ディレクトリ"Album1"内に含まれるメディアである。"［media］"はこのコンテンツがメディアであることを示す。上段の"User1Photo1InfoURI"は、メディア"Photo1"に対するコンテンツ情報メタデータ取得アドレスである。なお、メディア"Photo1"はディレクトリではないため、コンテンツリストメタデータ取得アドレスは存在しない。
図４のその他の欄も以上と同様の内容であるため、その詳細な説明を省略する。
尚、本実施形態では、２階層のディレクトリ構造の場合を例に挙げたが、ディレクトリ構造は２層に限らず、３階層以上のディレクトリ構造や、同一ディレクトリ内にディレクトリコンテンツとメディアコンテンツとが混在していてもよい。
図５は、図３に示したメタデータ提供装置２０の変換テーブル作成部３０９において作成された変換テーブルの一例を示す図である。具体的に図５は、図４に示したコンテンツ提供装置５０内のディレクトリ構造に対する変換テーブルの一例を示す図である。本実施形態では、変換テーブルは、コンテンツ情報メタデータ取得アドレス、親ディレクトリコンテンツ情報メタデータ取得アドレス、及びコンテンツリストメタデータ取得アドレスをレコードとするテーブルである。
図５のコンテンツ情報メタデータ取得アドレスは、コンテンツ提供装置５０内からコンテンツ情報メタデータ（コンテンツ自身に関するコンテンツメタデータ）を取得するためのアドレスである。コンテンツ情報メタデータ取得アドレスは、コンテンツ提供装置５０から提供されたコンテンツメタデータをDIDL-Liteに変換される際、DIDL-Liteの各コンテンツにおけるコンテンツ識別子（ＩＤ）として利用される。
ただし、ＤＬＮＡの仕様において、DIDL-Liteのルートコンテナ（ルートディレクトリ）におけるコンテンツ識別子は、"０"で固定されている。そのため、本実施形態では、図５に示した変換テーブルの最初のレコードにおいて、ルートディレクトリ"User1"に対するコンテンツ情報メタデータ取得アドレスを"０"とする。ルートディレクトリ"User1"におけるコンテンツ情報メタデータ取得アドレスは、ユーザ情報テーブル内のユーザＩＤ"User1"におけるルートコンテンツ情報メタデータ取得アドレスを用いる。
図５のコンテンツ情報メタデータ取得アドレスは、コンテンツ提供装置５０内からコンテンツ情報メタデータ（コンテンツ自身に関するコンテンツメタデータ）を取得するためのアドレスである。コンテンツ情報メタデータ取得アドレスは、コンテンツ提供装置５０から提供されたコンテンツメタデータをDIDL-Liteに変換される際、DIDL-Liteの各コンテンツにおけるコンテンツ識別子（ＩＤ）として利用される。
ただし、ＤＬＮＡの仕様において、DIDL-Liteのルートコンテナ（ルートディレクトリ）におけるコンテンツ識別子は、"０"で固定されている。そのため、本実施形態では、図５に示した変換テーブルの最初のレコードにおいて、ルートディレクトリ"User1"に対するコンテンツ情報メタデータ取得アドレスを"０"とする。ルートディレクトリ"User1"におけるコンテンツ情報メタデータ取得アドレスは、ユーザ情報テーブル内のユーザＩＤ"User1"におけるルートコンテンツ情報メタデータ取得アドレスを用いる。
親ディレクトリコンテンツ情報メタデータ取得アドレスは、同一レコード中におけるコンテンツ情報メタデータ取得アドレスが示すコンテンツの親ディレクトリ（上の階層のディレクトリ）に関するコンテンツ情報メタデータ取得アドレスである。親ディレクトリコンテンツ情報メタデータ取得アドレスは、コンテンツ提供装置５０から提供されたDIDL-Liteに変換される際、DIDL-Liteの各コンテンツにおける親ディレクトリコンテンツ識別子（ParentID）として利用される。コンテンツの親ディレクトリコンテンツ情報メタデータ取得アドレスは、そのコンテンツが記憶された記憶領域を示す識別子である。
ディレクトリである"Album1"（"User1Album1InfoURI"）の親ディレクトリコンテンツ情報メタデータ取得アドレスは、親ディレクトリであるルートディレクトリのコンテンツ情報メタデータ取得アドレス"０"である。
ただし、ＤＬＮＡの仕様において、DIDL-Liteのルートコンテナ（ルートディレクトリ）における親コンテンツ識別子は、"−１"で固定されている。そのため、本実施形態では、図５に示した変換テーブルの最初のレコードにおいて、ルートディレクトリに対応する親ディレクトリコンテンツ情報メタデータ取得アドレスは"−１"となる。
コンテンツリストメタデータ取得アドレスは、同一レコード中におけるコンテンツ情報メタデータ取得アドレスが示すコンテンツが所属するリストに関するコンテンツリストメタデータを取得するためのアドレスである。つまり、コンテンツリストメタデータ取得アドレスは、同一レコード中におけるコンテンツ情報メタデータ取得アドレスが示すコンテンツがコンテナ（ディレクトリ）の場合にのみ有効となる。そのため、図５に示した変換テーブルの４レコード目において、メディア"Photo1"に対するコンテンツリストメタデータ取得アドレスは存在しない。変換テーブルの４レコード目と同様に、変換テーブルの５レコード目以降についてもコンテンツリストメタデータ取得アドレスは存在しない。
ディレクトリである"Album1"（"User1Album1InfoURI"）の親ディレクトリコンテンツ情報メタデータ取得アドレスは、親ディレクトリであるルートディレクトリのコンテンツ情報メタデータ取得アドレス"０"である。
ただし、ＤＬＮＡの仕様において、DIDL-Liteのルートコンテナ（ルートディレクトリ）における親コンテンツ識別子は、"−１"で固定されている。そのため、本実施形態では、図５に示した変換テーブルの最初のレコードにおいて、ルートディレクトリに対応する親ディレクトリコンテンツ情報メタデータ取得アドレスは"−１"となる。
コンテンツリストメタデータ取得アドレスは、同一レコード中におけるコンテンツ情報メタデータ取得アドレスが示すコンテンツが所属するリストに関するコンテンツリストメタデータを取得するためのアドレスである。つまり、コンテンツリストメタデータ取得アドレスは、同一レコード中におけるコンテンツ情報メタデータ取得アドレスが示すコンテンツがコンテナ（ディレクトリ）の場合にのみ有効となる。そのため、図５に示した変換テーブルの４レコード目において、メディア"Photo1"に対するコンテンツリストメタデータ取得アドレスは存在しない。変換テーブルの４レコード目と同様に、変換テーブルの５レコード目以降についてもコンテンツリストメタデータ取得アドレスは存在しない。
図６は、コンテンツ提供装置５０のコンテンツメタデータを、ＬＡＮ１０上のＤＬＮＡ機器３０に提供するために必要な初期動作を行う際のメタデータ提供装置２０の処理の一例を説明するフローチャートである。
ステップＳ６０１において、ユーザ情報管理部３１２は、コンテンツ提供装置５０を利用する利用ユーザを決定する。この利用ユーザは、ユーザ情報テーブルのユーザＩＤ内から決定する。利用ユーザの決定は、メタデータ提供装置２０に対してユーザが行った設定に基づいて事前に行う方法等によって行われる。
次に、ステップＳ６０２において、コンテンツ提供装置管理部３１３は、ステップＳ６０１で決定した利用ユーザの情報に基づいて、コンテンツ提供装置５０にログインする。このとき、コンテンツ提供装置管理部３１３は、ユーザ情報テーブル中の当該利用ユーザに対応する"ユーザＩＤとパスワード"を用いて、コンテンツ提供装置５０に対して認証処理を依頼する。
ステップＳ６０１において、ユーザ情報管理部３１２は、コンテンツ提供装置５０を利用する利用ユーザを決定する。この利用ユーザは、ユーザ情報テーブルのユーザＩＤ内から決定する。利用ユーザの決定は、メタデータ提供装置２０に対してユーザが行った設定に基づいて事前に行う方法等によって行われる。
次に、ステップＳ６０２において、コンテンツ提供装置管理部３１３は、ステップＳ６０１で決定した利用ユーザの情報に基づいて、コンテンツ提供装置５０にログインする。このとき、コンテンツ提供装置管理部３１３は、ユーザ情報テーブル中の当該利用ユーザに対応する"ユーザＩＤとパスワード"を用いて、コンテンツ提供装置５０に対して認証処理を依頼する。
次に、ステップＳ６０３において、コンテンツ提供装置管理部３１３は、ユーザ情報テーブル中の当該利用ユーザに対応するルートコンテンツ情報メタデータ取得アドレスを取得する。
次に、ステップＳ６０４において、メタデータ取得部３０８は、ステップＳ６０３で取得したルートコンテンツ情報メタデータ取得アドレスを用いて、コンテンツ提供装置５０からルートディレクトリのコンテンツ情報メタデータを取得する。
次に、ステップＳ６０５において、変換テーブル作成部３０９は、ルートディレクトリのコンテンツリストメタデータ取得アドレスを決定する。コンテンツリストメタデータ取得アドレスの決定方法には、次の２つの方法がある。１つ目は、ステップＳ６０４で取得したコンテンツ情報メタデータ内にコンテンツリストメタデータ取得アドレスが直接記載されている場合である。２つ目は、コンテンツ提供装置５０が規定する方式に基づき、コンテンツリストメタデータ取得アドレスに関するベースアドレスと、ルートコンテンツに関する情報との組合せから一意に決定可能な場合である。ルートコンテンツに関する情報とは、例えばコンテンツ識別子等であり、ステップＳ６０４で取得したコンテンツ情報メタデータ内に記載されている。これらの決定方法は、コンテンツ提供装置５０によって異なるが、本実施形態では以後、前者の場合を仮定する。当然、後者の場合でも実施できる。
次に、ステップＳ６０４において、メタデータ取得部３０８は、ステップＳ６０３で取得したルートコンテンツ情報メタデータ取得アドレスを用いて、コンテンツ提供装置５０からルートディレクトリのコンテンツ情報メタデータを取得する。
次に、ステップＳ６０５において、変換テーブル作成部３０９は、ルートディレクトリのコンテンツリストメタデータ取得アドレスを決定する。コンテンツリストメタデータ取得アドレスの決定方法には、次の２つの方法がある。１つ目は、ステップＳ６０４で取得したコンテンツ情報メタデータ内にコンテンツリストメタデータ取得アドレスが直接記載されている場合である。２つ目は、コンテンツ提供装置５０が規定する方式に基づき、コンテンツリストメタデータ取得アドレスに関するベースアドレスと、ルートコンテンツに関する情報との組合せから一意に決定可能な場合である。ルートコンテンツに関する情報とは、例えばコンテンツ識別子等であり、ステップＳ６０４で取得したコンテンツ情報メタデータ内に記載されている。これらの決定方法は、コンテンツ提供装置５０によって異なるが、本実施形態では以後、前者の場合を仮定する。当然、後者の場合でも実施できる。
次に、ステップＳ６０６において、変換テーブル作成部３０９は、ステップＳ６０５で決定したコンテンツリストメタデータ取得アドレスを用いて、ルートディレクトリに対する変換レコードを作成する。そして、変換テーブル作成部３０９は、作成した変換レコードを、記憶部３１４を介して、図２に示したメタデータ提供装置２０の外部記憶装置２０４内に用意した変換テーブル内に記憶する。
このステップＳ６０６で作成される"ルートディレクトリに対する変換レコード"とは、具体的に、図５に示した変換テーブルの最初のレコードである。前述したように、ルートディレクトリにおけるコンテンツ情報メタデータ取得アドレスは"０"、親ディレクトリコンテンツ情報メタデータ取得アドレスは"−１"である。また、コンテンツリストメタデータ取得アドレスは、ステップＳ６０５で決定したものであり、この例では"User1RootContentListURI"である。
このステップＳ６０６で作成される"ルートディレクトリに対する変換レコード"とは、具体的に、図５に示した変換テーブルの最初のレコードである。前述したように、ルートディレクトリにおけるコンテンツ情報メタデータ取得アドレスは"０"、親ディレクトリコンテンツ情報メタデータ取得アドレスは"−１"である。また、コンテンツリストメタデータ取得アドレスは、ステップＳ６０５で決定したものであり、この例では"User1RootContentListURI"である。
図７は、ＬＡＮ１０上のＤＬＮＡ機器３０からコンテンツメタデータの取得要求を受信した際のメタデータ提供装置２０におけるメタデータ提供動作の一例を説明するフローチャートである。
ステップＳ７０１において、制御部３０５は、ＬＡＮ１０上のＤＬＮＡ機器３０からコンテンツメタデータの取得要求を受信したか否かを判定する。具体的には、制御部３０５は、ＳＯＡＰ処理部３０３がＣＤＳのBrowseアクションを受信したかどうかを判定する。この判定の結果、コンテンツメタデータの取得要求を受信していなければ、制御部３０５は再びステップＳ７０１の処理を繰り返す。一方、コンテンツメタデータの取得要求を受信したならば、ステップＳ７０２に進む。
ステップＳ７０２において、要求メタデータ判別部３０６は、ステップＳ７０１で受信したコンテンツメタデータの取得要求から、要求対象のコンテンツの識別子（要求対象コンテンツ識別子）を取得する。具体的には、要求メタデータ判別部３０６は、ステップＳ７０１においてＳＯＡＰ処理部３０３が取得したＣＤＳのBrowseアクションの第１パラメータであるObjectIDを取得する。
ステップＳ７０１において、制御部３０５は、ＬＡＮ１０上のＤＬＮＡ機器３０からコンテンツメタデータの取得要求を受信したか否かを判定する。具体的には、制御部３０５は、ＳＯＡＰ処理部３０３がＣＤＳのBrowseアクションを受信したかどうかを判定する。この判定の結果、コンテンツメタデータの取得要求を受信していなければ、制御部３０５は再びステップＳ７０１の処理を繰り返す。一方、コンテンツメタデータの取得要求を受信したならば、ステップＳ７０２に進む。
ステップＳ７０２において、要求メタデータ判別部３０６は、ステップＳ７０１で受信したコンテンツメタデータの取得要求から、要求対象のコンテンツの識別子（要求対象コンテンツ識別子）を取得する。具体的には、要求メタデータ判別部３０６は、ステップＳ７０１においてＳＯＡＰ処理部３０３が取得したＣＤＳのBrowseアクションの第１パラメータであるObjectIDを取得する。
次に、ステップＳ７０３において、要求メタデータ判別部３０６は、ステップＳ７０２で取得した要求対象コンテンツ識別子が、変換テーブルに存在するか否かを判定する。具体的には、要求メタデータ判別部３０６は、ステップＳ７０２で取得したObjectIDが、図５に示した変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在するか否かを判定する。この判定の結果、ステップＳ７０２で取得したObjectIDが、変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在するならば、ステップＳ７０４に進む。一方、ステップＳ７０２で取得したObjectIDが、変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在しなければ、後述するステップＳ７０７に進む。
通常、図６に示した初期動作のフローチャートの直後の場合、変換テーブル中にはルートディレクトリに対する変換レコードのみが存在する。つまり、図５に示した変換テーブルの最初のレコードのみが、変換テーブル中に存在する。一方、ＬＡＮ１０上のＤＬＮＡ機器３０が、メタデータ提供装置２０に対して、最初のコンテンツメタデータの取得要求を行う際には、通常、ルートディレクトリに対するコンテンツメタデータの取得要求を行う。よって、ステップＳ７０３の判定結果は"存在する"となるのが通常である。
通常、図６に示した初期動作のフローチャートの直後の場合、変換テーブル中にはルートディレクトリに対する変換レコードのみが存在する。つまり、図５に示した変換テーブルの最初のレコードのみが、変換テーブル中に存在する。一方、ＬＡＮ１０上のＤＬＮＡ機器３０が、メタデータ提供装置２０に対して、最初のコンテンツメタデータの取得要求を行う際には、通常、ルートディレクトリに対するコンテンツメタデータの取得要求を行う。よって、ステップＳ７０３の判定結果は"存在する"となるのが通常である。
ステップＳ７０４において、要求メタデータ判別部３０６は、変換テーブル中からステップＳ７０２で取得した要求対象コンテンツ識別子が含まれるレコード（変換レコード）を取得する。
次に、ステップＳ７０５において、要求メタデータ判別部３０６は、ステップＳ７０１で受信したコンテンツメタデータの取得要求に含まれる要求メタデータ種別がBrowseDirectChildrenであるか否かを判定する。具体的には、要求メタデータ判別部３０６は、ステップＳ７０１でＳＯＡＰ処理部３０３が取得したＣＤＳのBrowseアクションの第２パラメータが、BrowseDirectChildrenであるか否かを判定する。この判定の結果、要求メタデータ種別がBrowseDirectChildrenであるならば、後述する図８のステップＳ８０１に進む。一方、要求メタデータ種別がBrowseDirectChildrenと異なるならば、ステップＳ７０６に進む。
ステップＳ７０６において、要求メタデータ判別部３０６は、ステップＳ７０１で受信したコンテンツメタデータの取得要求に含まれる要求メタデータ種別がBrowseMetadataであるか否かを判定する。具体的には、要求メタデータ判別部３０６は、ステップＳ７０１でＳＯＡＰ処理部３０３が取得したＣＤＳのBrowseアクションの第２パラメータが、BrowseMetadataであるか否かを判定する。この判定の結果、要求メタデータ種別がBrowseMetadataであるならば、後述する図９のステップＳ９０１に進む。一方、要求メタデータ種別がBrowseMetadataと異なるならば、後述するステップＳ７０７に進む。
次に、ステップＳ７０５において、要求メタデータ判別部３０６は、ステップＳ７０１で受信したコンテンツメタデータの取得要求に含まれる要求メタデータ種別がBrowseDirectChildrenであるか否かを判定する。具体的には、要求メタデータ判別部３０６は、ステップＳ７０１でＳＯＡＰ処理部３０３が取得したＣＤＳのBrowseアクションの第２パラメータが、BrowseDirectChildrenであるか否かを判定する。この判定の結果、要求メタデータ種別がBrowseDirectChildrenであるならば、後述する図８のステップＳ８０１に進む。一方、要求メタデータ種別がBrowseDirectChildrenと異なるならば、ステップＳ７０６に進む。
ステップＳ７０６において、要求メタデータ判別部３０６は、ステップＳ７０１で受信したコンテンツメタデータの取得要求に含まれる要求メタデータ種別がBrowseMetadataであるか否かを判定する。具体的には、要求メタデータ判別部３０６は、ステップＳ７０１でＳＯＡＰ処理部３０３が取得したＣＤＳのBrowseアクションの第２パラメータが、BrowseMetadataであるか否かを判定する。この判定の結果、要求メタデータ種別がBrowseMetadataであるならば、後述する図９のステップＳ９０１に進む。一方、要求メタデータ種別がBrowseMetadataと異なるならば、後述するステップＳ７０７に進む。
図８は、図７に続くフローチャートである。具体的に図８は、図７のステップＳ７０５において、要求メタデータ判別部３０６によって、要求メタデータ種別がBrowseDirectChildrenであると判定された場合の処理を説明するフローチャートである。
ステップＳ８０１において、メタデータ取得アドレス決定部３０７は、図７のステップＳ７０４において要求メタデータ判別部３０６が取得した変換レコードから、コンテンツリストメタデータ取得アドレスを取得する。
次に、ステップＳ８０２において、メタデータ取得アドレス決定部３０７は、ステップＳ８０１で取得したコンテンツリストメタデータ取得アドレスが有効であるか否かを判定する。この判定の結果、コンテンツリストメタデータ取得アドレスが有効であれば、ステップＳ８０３に進む。一方、コンテンツリストメタデータ取得アドレスが無効でなければ、後述する図７のステップＳ７０７に進む。ここで、コンテンツリストメタデータ取得アドレスが無効となる場合の典型的な例としては、要求対象コンテンツがディレクトリ（コンテナ）ではなくメディア（アイテム）である場合である。
ステップＳ８０１において、メタデータ取得アドレス決定部３０７は、図７のステップＳ７０４において要求メタデータ判別部３０６が取得した変換レコードから、コンテンツリストメタデータ取得アドレスを取得する。
次に、ステップＳ８０２において、メタデータ取得アドレス決定部３０７は、ステップＳ８０１で取得したコンテンツリストメタデータ取得アドレスが有効であるか否かを判定する。この判定の結果、コンテンツリストメタデータ取得アドレスが有効であれば、ステップＳ８０３に進む。一方、コンテンツリストメタデータ取得アドレスが無効でなければ、後述する図７のステップＳ７０７に進む。ここで、コンテンツリストメタデータ取得アドレスが無効となる場合の典型的な例としては、要求対象コンテンツがディレクトリ（コンテナ）ではなくメディア（アイテム）である場合である。
ステップＳ８０３において、メタデータ取得部３０８は、ステップＳ８０１で取得したコンテンツリストメタデータ取得アドレスを用いて、コンテンツ提供装置５０から、コンテンツリストメタデータを取得する。
次に、ステップＳ８０４において、変換テーブル作成部３０９は、ステップＳ８０３で取得したコンテンツリストメタデータから、各コンテンツに関するメタデータを抽出する。以降、対象となる１つのコンテンツのメタデータに対してステップＳ８０５〜ステップＳ８０９の処理を行う。
次に、ステップＳ８０５において、変換テーブル作成部３０９は、ステップＳ８０４で抽出したコンテンツのメタデータに基づき、コンテンツ情報メタデータ取得アドレスを決定する。これは、図６のステップＳ６０５の説明において述べたコンテンツリストメタデータ取得アドレスの決定方法と同様に、次の２つの方法がある。１つ目は、ステップＳ８０４で抽出したコンテンツに関するメタデータ内にコンテンツ情報メタデータ取得アドレスが直接記載されている場合である。２つ目は、コンテンツ提供装置５０が規定する方式に基づき、コンテンツ情報メタデータ取得アドレスに関するベースアドレスと、該当する（取得要求のあった）コンテンツに関する情報との組み合せから一意に決定可能な場合である。該当するコンテンツに関する情報とは、例えばコンテンツ識別子等であり、ステップＳ８０４で抽出したコンテンツのメタデータ内に記載されている。これらの決定方法は、コンテンツ提供装置５０によって異なるが、本実施形態では図６のステップＳ６０５と同様に、前者の場合を仮定する。
次に、ステップＳ８０４において、変換テーブル作成部３０９は、ステップＳ８０３で取得したコンテンツリストメタデータから、各コンテンツに関するメタデータを抽出する。以降、対象となる１つのコンテンツのメタデータに対してステップＳ８０５〜ステップＳ８０９の処理を行う。
次に、ステップＳ８０５において、変換テーブル作成部３０９は、ステップＳ８０４で抽出したコンテンツのメタデータに基づき、コンテンツ情報メタデータ取得アドレスを決定する。これは、図６のステップＳ６０５の説明において述べたコンテンツリストメタデータ取得アドレスの決定方法と同様に、次の２つの方法がある。１つ目は、ステップＳ８０４で抽出したコンテンツに関するメタデータ内にコンテンツ情報メタデータ取得アドレスが直接記載されている場合である。２つ目は、コンテンツ提供装置５０が規定する方式に基づき、コンテンツ情報メタデータ取得アドレスに関するベースアドレスと、該当する（取得要求のあった）コンテンツに関する情報との組み合せから一意に決定可能な場合である。該当するコンテンツに関する情報とは、例えばコンテンツ識別子等であり、ステップＳ８０４で抽出したコンテンツのメタデータ内に記載されている。これらの決定方法は、コンテンツ提供装置５０によって異なるが、本実施形態では図６のステップＳ６０５と同様に、前者の場合を仮定する。
次に、ステップＳ８０６において、変換テーブル作成部３０９は、ステップＳ８０５で決定したコンテンツ情報メタデータ取得アドレスが、変換テーブルに存在するか否かを判定する。具体的には、変換テーブル作成部３０９は、ステップＳ８０５で決定したコンテンツ情報メタデータ取得アドレスが、図５に示した変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在するか否かを判定する。この判定の結果、コンテンツ情報メタデータ取得アドレスが、変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在すれば、変換テーブル作成部３０９は、該当するコンテンツが変換テーブルに登録済みと判断する。そして、ステップＳ８０７〜Ｓ８０９を省略してステップＳ８１０に進む。一方、コンテンツ情報メタデータ取得アドレスが、変換テーブルのコンテンツ情報メタデータ取得アドレスのフィールドに存在しなければ、変換テーブル作成部３０９は、該当するコンテンツが変換テーブルに未登録と判断して、ステップＳ８０７に進む。
ステップＳ８０７において、変換テーブル作成部３０９は、該当するコンテンツがディレクトリであるか否かを判定する。具体的には、変換テーブル作成部３０９は、ステップＳ８０４で抽出したコンテンツのメタデータの属性情報を基に、当該コンテンツがディレクトリであるか否かを判定する。この判定の結果、該当するコンテンツがディレクトリであるならば、ステップＳ８０８に進む。一方、該当するコンテンツがディレクトリでなければ、ステップＳ８０８を省略してステップＳ８０９に進む。
ステップＳ８０８において、変換テーブル作成部３０９は、ディレクトリであると判断した当該コンテンツの、コンテンツリストメタデータ取得アドレスを決定する。ここでのコンテンツリストメタデータ取得アドレスの決定方法は、図６のステップＳ６０５の説明において述べたコンテンツリストメタデータ取得アドレスの決定方法と同様であるので、その詳細な説明を省略する。
ステップＳ８０８において、変換テーブル作成部３０９は、ディレクトリであると判断した当該コンテンツの、コンテンツリストメタデータ取得アドレスを決定する。ここでのコンテンツリストメタデータ取得アドレスの決定方法は、図６のステップＳ６０５の説明において述べたコンテンツリストメタデータ取得アドレスの決定方法と同様であるので、その詳細な説明を省略する。
次に、ステップＳ８０９において、変換テーブル作成部３０９は、ステップＳ８０５で決定したコンテンツ情報メタデータ取得アドレスを用いて、該当するコンテンツの変換レコードを作成する。ステップＳ８０８からステップＳ８０９に進んだ場合、変換テーブル作成部３０９は、ステップＳ８０８で決定したコンテンツリストメタデータ取得アドレスを更に用いて、該当するコンテンツの変換レコードを作成する。尚、親ディレクトリコンテンツ情報メタデータ取得アドレスは、図７のステップＳ７０２で取得した要求対象コンテンツ識別子（ObjectID）である。そして、変換テーブル作成部３０９は、作成した変換レコードを、記憶部３１４を介して、図２に示したメタデータ提供装置２０の外部記憶装置２０４内に用意した変換テーブル内に追加する。
次に、ステップＳ８１０において、変換テーブル作成部３０９は、ステップＳ８０４で抽出した各コンテンツに関するメタデータを全て処理対象としたか否かを判定する。この判定の結果、各コンテンツに関するメタデータを全て処理対象としていなければ、ステップＳ８０４に戻る。一方、各コンテンツに関するメタデータを全て処理対象としたならば、ステップＳ８１１に進む。
次に、ステップＳ８１０において、変換テーブル作成部３０９は、ステップＳ８０４で抽出した各コンテンツに関するメタデータを全て処理対象としたか否かを判定する。この判定の結果、各コンテンツに関するメタデータを全て処理対象としていなければ、ステップＳ８０４に戻る。一方、各コンテンツに関するメタデータを全て処理対象としたならば、ステップＳ８１１に進む。
ステップＳ８１１において、メタデータ変換部３１０は、図８のステップＳ８０３で取得したコンテンツリストメタデータを、所定のDIDL−Lite形式のメタデータに変換する。変換の際、コンテンツリスト中に含まれる各コンテンツに対して、コンテンツ識別子（ＩＤ）として、図８のステップＳ８０５で決定したコンテンツ情報メタデータ取得アドレスを用いる。更に、親ディレクトリコンテンツ識別子（ParentID）として、図７のステップＳ７０２で取得した要求対象コンテンツ識別子（ObjectID）を用いる。
次に、ステップＳ８１２において、メタデータ提供部３１１は、ステップＳ８１１で変換されたコンテンツリストメタデータを、ＬＡＮ１０上のＤＬＮＡ機器３０に送信する。具体的には、メタデータ提供部３１１は、ステップＳ８１１で変換された変換したコンテンツリストメタデータを、ＳＯＡＰ処理部３０３を介して、ＣＤＳのBrowseアクションの応答として、ＬＡＮ１０上のＤＬＮＡ機器３０に返す。
そして、制御部３０５は、図７に示したメタデータ提供動作を終了する。尚、メタデータ提供動作を繰り返すために、制御部３０５は図７の開始へ処理を戻しても良い。
次に、ステップＳ８１２において、メタデータ提供部３１１は、ステップＳ８１１で変換されたコンテンツリストメタデータを、ＬＡＮ１０上のＤＬＮＡ機器３０に送信する。具体的には、メタデータ提供部３１１は、ステップＳ８１１で変換された変換したコンテンツリストメタデータを、ＳＯＡＰ処理部３０３を介して、ＣＤＳのBrowseアクションの応答として、ＬＡＮ１０上のＤＬＮＡ機器３０に返す。
そして、制御部３０５は、図７に示したメタデータ提供動作を終了する。尚、メタデータ提供動作を繰り返すために、制御部３０５は図７の開始へ処理を戻しても良い。
図９は、図７に続くフローチャートである。具体的に図９は、図７のステップＳ７０６において、要求メタデータ判別部３０６によって、要求メタデータ種別がBrowseMetadataであると判定された場合の処理を説明するフローチャートである。
ステップＳ９０１において、要求メタデータ判別部３０６は、図７のステップＳ７０２で取得した要求対象コンテンツ識別子が"０"、つまり要求対象のコンテンツがルートディレクトリであるか否かを判定する。この判定の結果、要求対象コンテンツ識別子が"０"でないならば、ステップＳ９０２に進む。一方、要求対象コンテンツ識別子が"０"ならば、ステップＳ９０３に進む。
ステップＳ９０２において、メタデータ取得アドレス決定部３０７は、図７のステップＳ７０４で要求メタデータ判別部３０６が取得した変換レコードから、コンテンツ情報メタデータ取得アドレスを取得する。そして、ステップＳ９０４に進む。
ステップＳ９０３において、メタデータ取得アドレス決定部３０７は、当該利用ユーザのユーザ情報テーブルからルートコンテンツ情報メタデータ取得アドレスを取得する。そして、ステップＳ９０４に進む。
ステップＳ９０１において、要求メタデータ判別部３０６は、図７のステップＳ７０２で取得した要求対象コンテンツ識別子が"０"、つまり要求対象のコンテンツがルートディレクトリであるか否かを判定する。この判定の結果、要求対象コンテンツ識別子が"０"でないならば、ステップＳ９０２に進む。一方、要求対象コンテンツ識別子が"０"ならば、ステップＳ９０３に進む。
ステップＳ９０２において、メタデータ取得アドレス決定部３０７は、図７のステップＳ７０４で要求メタデータ判別部３０６が取得した変換レコードから、コンテンツ情報メタデータ取得アドレスを取得する。そして、ステップＳ９０４に進む。
ステップＳ９０３において、メタデータ取得アドレス決定部３０７は、当該利用ユーザのユーザ情報テーブルからルートコンテンツ情報メタデータ取得アドレスを取得する。そして、ステップＳ９０４に進む。
ステップＳ９０４において、メタデータ取得部３０８は、ステップＳ９０２、Ｓ９０３で取得したコンテンツ情報メタデータ取得アドレスを用いて、コンテンツ提供装置５０から、コンテンツ情報メタデータを取得する。
次に、ステップＳ９０５において、メタデータ変換部３１０は、ステップＳ９０４で取得したコンテンツ情報メタデータを、所定のDIDL-Lite形式のメタデータに変換する。変換の際、コンテンツ識別子（ＩＤ）として、ステップＳ９０２、Ｓ９０３で取得したコンテンツ情報メタデータ取得アドレスを用いる。更に、親ディレクトリコンテンツ識別子（ParentID）として、図７のステップＳ７０４において要求メタデータ判別部３０６が取得した変換レコード中の、親ディレクトリコンテンツ情報メタデータ取得アドレスを用いる。
次に、ステップＳ９０６において、メタデータ提供部３１１は、ステップＳ９０５で変換されたコンテンツ情報メタデータを、ＬＡＮ１０上のＤＬＮＡ機器３０に送信する。具体的には、メタデータ提供部３１１は、ステップＳ９０５で変換されたコンテンツ情報メタデータを、ＳＯＡＰ処理部３０３を介して、ＣＤＳのBrowseアクションの応答として、ＬＡＮ１０上のＤＬＮＡ機器３０に返す。
そして、制御部３０５は、図７に示したメタデータ提供動作を終了する。尚、メタデータ提供動作を繰り返すために、制御部３０５は図７の開始へ処理を戻しても良い。
次に、ステップＳ９０５において、メタデータ変換部３１０は、ステップＳ９０４で取得したコンテンツ情報メタデータを、所定のDIDL-Lite形式のメタデータに変換する。変換の際、コンテンツ識別子（ＩＤ）として、ステップＳ９０２、Ｓ９０３で取得したコンテンツ情報メタデータ取得アドレスを用いる。更に、親ディレクトリコンテンツ識別子（ParentID）として、図７のステップＳ７０４において要求メタデータ判別部３０６が取得した変換レコード中の、親ディレクトリコンテンツ情報メタデータ取得アドレスを用いる。
次に、ステップＳ９０６において、メタデータ提供部３１１は、ステップＳ９０５で変換されたコンテンツ情報メタデータを、ＬＡＮ１０上のＤＬＮＡ機器３０に送信する。具体的には、メタデータ提供部３１１は、ステップＳ９０５で変換されたコンテンツ情報メタデータを、ＳＯＡＰ処理部３０３を介して、ＣＤＳのBrowseアクションの応答として、ＬＡＮ１０上のＤＬＮＡ機器３０に返す。
そして、制御部３０５は、図７に示したメタデータ提供動作を終了する。尚、メタデータ提供動作を繰り返すために、制御部３０５は図７の開始へ処理を戻しても良い。
図７のステップＳ７０３、Ｓ７０６、図８のステップＳ８０２からステップＳ７０７に進むと、メタデータ提供部３１１は、要求パラメータが不正であることを旨とするエラー応答を、ＬＡＮ１０上のＤＬＮＡ機器３０に送信する。具体的には、メタデータ提供部３１１は、要求パラメータが不正であることを旨とするエラー応答を、ＳＯＡＰ処理部３０３を介して、ＣＤＳのBrowseアクションの応答として、ＬＡＮ１０上のＤＬＮＡ機器３０に返す。
そして、制御部３０５は、図７に示したメタデータ提供動作を終了する。尚、メタデータ提供動作を繰り返すために、制御部３０５は図７の開始へ処理を戻しても良い。
そして、制御部３０５は、図７に示したメタデータ提供動作を終了する。尚、メタデータ提供動作を繰り返すために、制御部３０５は図７の開始へ処理を戻しても良い。
図１０は、ＬＡＮ１０上のＤＬＮＡ機器３０が、メタデータ提供装置２０に送信した、ルートディレクトリに対するコンテンツリストメタデータの取得要求メッセージの一例を示す図である。これは、ＣＤＳのBrowseアクションのＳＯＡＰ要求メッセージである。ＣＤＳのBrowseアクションの第１パラメータである要求対象コンテンツ識別子は、ルートディレクトリを示す"０"である。そして、その第２パラメータである要求メタデータ種別は、コンテンツリストメタデータを示す"BrowseDirectChildren"である。
図１１（Ａ）は、図１０に示したルートディレクトリに対するコンテンツリストメタデータの取得要求に対して、メタデータ提供装置２０がコンテンツ提供装置５０から取得したコンテンツリストメタデータの一例を示す図である。この例では、コンテンツ提供装置５０のメタデータ形式が、The Atom Publishing Protocolであるとする。尚、本実施形態では、コンテンツ提供装置５０のメタデータ形式がThe Atom Publishing Protocolである場合を例に挙げている。しかしながら、コンテンツ提供装置５０のメタデータ形式はこれに限らず、例えば、ＲＥＳＴ（Representational State Transfer）形式メタデータや独自形式メタデータ等でも良い。
この例では、ルートディレクトリ"User1"に２つのディレクトリ"Album1"、"Album2"が含まれている。また、コンテンツがディレクトリであることは、category要素の属性情報等から判断することができる。
この例では、ルートディレクトリ"User1"に２つのディレクトリ"Album1"、"Album2"が含まれている。また、コンテンツがディレクトリであることは、category要素の属性情報等から判断することができる。
図１１（Ｂ）は、図１１（Ａ）に示したコンテンツ提供装置５０から取得したコンテンツリストメタデータを、図５に示した変換テーブルを用いて所定のDIDL-Lite形式のメタデータに変換した結果の一例を示す図である。この例では、ディレクトリ"Album1"のコンテンツ識別子（ＩＤ）は"User1Album1InfoURI"、親ディレクトリコンテンツ識別子（ParentID）は"０"である。同様に、ディレクトリ"Album2"のコンテンツ識別子（ＩＤ）は"User1Album2InfoURI"、親ディレクトリコンテンツ識別子（ParentID）は"０"である。
図１２は、ＬＡＮ１０上のＤＬＮＡ機器３０が、メタデータ提供装置２０に送信した、ディレクトリ"Album1"に対するコンテンツリストメタデータの取得要求メッセージの一例を示す図である。これは、ＣＤＳのBrowseアクションのＳＯＡＰ要求メッセージである。ＣＤＳのBrowseアクションの第１パラメータである要求対象コンテンツ識別子は、ディレクトリ"Album1"を示す"User1Album1InfoURI"である。そして、その第２パラメータである要求メタデータ種別は、コンテンツリストメタデータを示す"BrowseDirectChildren"である。
図１３（Ａ）は、図１２に示したディレクトリ"Album1"に対するコンテンツリストメタデータ取得要求に対して、メタデータ提供装置２０がコンテンツ提供装置５０から取得したコンテンツリストメタデータの一例を示す図である。この例も、図１１と同様に、コンテンツ提供装置５０のメタデータ形式が、The Atom Publishing Protocolであるとする。また、この例では、ディレクトリ"Album1"に２つのメディア"Photo1"、"Photo2"が含まれている。また、コンテンツがメディアであることは、category要素の属性情報や、content要素の属性情報等から判断することができる。
図１３（Ｂ）は、図１３（Ａ）に示したコンテンツ提供装置５０から取得したコンテンツリストメタデータを、図５に示した変換テーブルを用いて所定のDIDL-Lite形式のメタデータに変換した結果の一例を示す図である。この例では、メディア"Photo1"のコンテンツ識別子（ＩＤ）は"User1Photo1InfoURI"、親ディレクトリコンテンツ識別子（ParentID）は"User1Album1InfoURI"である。同様に、メディア"Photo2"のコンテンツ識別子（ＩＤ）は"User1Photo2InfoURI"、親ディレクトリコンテンツ識別子（ParentID）は"User1Album1InfoURI"である。
図１４は、ＬＡＮ１０上のＤＬＮＡ機器３０が、メタデータ提供装置２０に送信した、メディア"Photo1"に対するコンテンツ情報メタデータの取得要求メッセージの一例を示す図である。これは、ＣＤＳのBrowseアクションのＳＯＡＰ要求メッセージである。ＣＤＳのBrowseアクションの第１パラメータである要求対象コンテンツ識別子は、メディア"Photo1"を示す"User1Photo1InfoURI"である。そして、その第２パラメータである要求メタデータ種別は、コンテンツ情報メタデータを示す"BrowseMetadata"である。
図１５（Ａ）は、図１４に示したメディア"Photo1"に対するコンテンツ情報メタデータの取得要求に対して、メタデータ提供装置２０がコンテンツ提供装置５０から取得したコンテンツ情報メタデータの一例を示す図である。この例も、図１１、図１３と同様に、コンテンツ提供装置５０のメタデータ形式が、The Atom Publishing Protocolであるとする。この場合、メディア"Photo1"のコンテンツ情報メタデータ中に親ディレクトリである"Album1"に関する情報は含まれていない。
図１５（Ｂ）は、図１５（Ａ）に示したコンテンツ提供装置５０から取得したコンテンツ情報メタデータを、図５に示した変換テーブルを用いて所定のDIDL-Lite形式のメタデータに変換した結果の一例を示す図である。この例では、メディア"Photo1"のコンテンツ識別子（ＩＤ）は"User1Photo1InfoURI"、親ディレクトリコンテンツ識別子（ParentID）は"User1Album1InfoURI"である。
以上のように本実施形態では、ＤＬＮＡ機器３０からコンテンツリストメタデータの取得要求があると、メタデータ提供装置２０は、該当するコンテンツについて、変換テーブルのレコードを追加する。この変換テーブルのレコードには、コンテンツメタデータ取得アドレス（コンテンツ情報（コンテンツリスト）メタデータ取得アドレス）と、親ディレクトリコンテンツ情報メタデータ取得アドレスとが含まれている。ＤＬＮＡ機器３０からコンテンツメタデータの取得要求があると、メタデータ提供装置２０は、変換テーブルに記憶されているコンテンツ情報（コンテンツリスト）メタデータ取得アドレスを用いて、コンテンツ提供装置５０からコンテンツメタデータを取得する。そして、メタデータ提供装置２０は、取得したコンテンツメタデータをＤＬＮＡ機器３０が処理できる所定の形式に変換する。この際、コンテンツ識別子として、該当するコンテンツ情報メタデータ取得アドレスを用いると共に、親ディレクトリコンテンツ識別子として、該当する親ディレクトリコンテンツ情報メタデータ取得アドレスを用いる。そして、メタデータ提供装置２０は、変換したコンテンツメタデータをＤＬＮＡ機器３０に送信する。
したがって、メタデータ提供装置２０は、コンテンツ提供装置５０のコンテンツメタデータを、正しいディレクトリ情報を付加して動的に変換し、ＬＡＮ１０上のＤＬＮＡ機器３０に提供することができる。したがって、コンテンツ提供装置５０のコンテンツの内容がリアルタイムに更新されても、メタデータ提供装置２０は更新内容が反映されたメタデータを直ちにＬＡＮ１０上のＤＬＮＡ機器３０に提供することができる。これにより、ユーザの利便性が向上する。
また、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツリストメタデータの取得要求があった場合に限り、メタデータ提供装置２０は変換テーブルを作成する。一方、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツ情報メタデータの取得要求があった場合には、メタデータ提供装置２０は変換テーブルを作成しない。これにより、メタデータ提供装置２０は、変換テーブルの作成に伴う処理コストを削減することできる。
また、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツリストメタデータの取得要求があった場合に限り、メタデータ提供装置２０は変換テーブルを作成する。一方、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツ情報メタデータの取得要求があった場合には、メタデータ提供装置２０は変換テーブルを作成しない。これにより、メタデータ提供装置２０は、変換テーブルの作成に伴う処理コストを削減することできる。
また、メタデータ提供装置２０は、コンテンツ提供装置５０から取得したコンテンツメタデータをDIDL-Liteに変換する際、コンテンツ識別子（ＩＤ）としてコンテンツ情報メタデータ取得アドレスを用いる。これにより、メタデータ提供装置２０は、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツ情報メタデータの取得要求に対して、直ちにコンテンツ提供装置５０からコンテンツ情報メタデータを取得することできる。本来ならば、メタデータ提供装置２０は、コンテンツ識別子からコンテンツ情報メタデータを取得するためのアドレスを解決する必要がある。しかし、本実施形態では、この必要がないため、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツ情報メタデータの取得要求に対する応答速度が向上し、ユーザの利便性を向上することができる。
また、メタデータ提供装置２０は、変換テーブルにコンテンツリストメタデータ取得アドレスを保持している。これにより、メタデータ提供装置２０は、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツリストメタデータ取得要求に対して、直ちにコンテンツ提供装置５０からコンテンツリストメタデータを取得することできる。本来ならば、メタデータ提供装置２０は、コンテンツ識別子からコンテンツリストメタデータを取得するためのアドレスを解決する必要がある。しかし、本実施形態では、この必要がないため、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツリストメタデータの取得要求に対する応答速度が向上し、ユーザの利便性を向上することができる。
尚、コンテンツ提供装置が管理している階層型の記憶領域がディレクトリである場合を例に挙げて説明したが、例えば、ディレクトリに相当するフォルダを当該記憶領域としてもよい。
また、メタデータ提供装置２０は、変換テーブルにコンテンツリストメタデータ取得アドレスを保持している。これにより、メタデータ提供装置２０は、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツリストメタデータ取得要求に対して、直ちにコンテンツ提供装置５０からコンテンツリストメタデータを取得することできる。本来ならば、メタデータ提供装置２０は、コンテンツ識別子からコンテンツリストメタデータを取得するためのアドレスを解決する必要がある。しかし、本実施形態では、この必要がないため、ＬＡＮ１０上のＤＬＮＡ機器３０からのコンテンツリストメタデータの取得要求に対する応答速度が向上し、ユーザの利便性を向上することができる。
尚、コンテンツ提供装置が管理している階層型の記憶領域がディレクトリである場合を例に挙げて説明したが、例えば、ディレクトリに相当するフォルダを当該記憶領域としてもよい。
（本発明の他の実施形態）
本発明は、実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのコンピュータが記録媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。すなわち、前述した本発明の実施形態におけるコンテンツ属性情報提供装置を構成する各手段、並びにコンテンツ属性情報提供方法の各ステップは、コンピュータのＲＡＭやＲＯＭ等に記憶されたコンピュータプログラムが動作することによって実現できる。また、このコンピュータプログラムプログラム及びコンピュータプログラムプログラムを記録したコンピュータ読み取り可能な記録媒体も本発明に含まれる。
本発明は、実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのコンピュータが記録媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。すなわち、前述した本発明の実施形態におけるコンテンツ属性情報提供装置を構成する各手段、並びにコンテンツ属性情報提供方法の各ステップは、コンピュータのＲＡＭやＲＯＭ等に記憶されたコンピュータプログラムが動作することによって実現できる。また、このコンピュータプログラムプログラム及びコンピュータプログラムプログラムを記録したコンピュータ読み取り可能な記録媒体も本発明に含まれる。
尚、前述した各実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
２０ メタデータ提供装置、３０ ＤＬＮＡ機器、５０ コンテンツ提供装置
Claims (9)
- コンテンツ提供装置が管理している階層分けされた記憶領域の中のコンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得する第１の取得手段と、
前記第１の取得手段により取得されたコンテンツ属性情報に基づいて、前記階層分けされた記憶領域の中のコンテンツを示す識別子と、当該コンテンツが記憶された記憶領域を示す識別子と、を記憶媒体に記憶する記憶手段と、
コンテンツに関する所定の形式のコンテンツ属性情報を受信する受信装置からコンテンツ属性情報の取得要求を受信した場合に、前記取得要求のあったコンテンツ属性情報に対応するコンテンツが記憶された記憶領域を示す識別子を前記記憶媒体から取得するとともに、前記取得要求のあったコンテンツ属性情報を前記コンテンツ提供装置から取得する第２の取得手段と、
前記受信装置から前記コンテンツに関するコンテンツ属性情報の取得要求を受信した場合に、前記第２の取得手段により取得された前記コンテンツが記憶された記憶領域を示す識別子と、前記コンテンツ属性情報と、前記コンテンツを示す識別子とを、前記所定の形式で前記受信装置に送信する送信手段と、
を備え、
前記コンテンツを示す識別子は、当該コンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得するための第１のアドレスであり、
前記コンテンツが記憶された記憶領域を示す識別子は、当該記憶領域に関する属性情報を前記コンテンツ提供装置から取得するための第２のアドレスであり、
前記第２の取得手段は、前記第１のアドレスを用いて、前記取得要求のあったコンテンツ属性情報を前記コンテンツ提供装置から取得することを特徴とするコンテンツ属性情報提供装置。 - 前記第２の取得手段は、
前記受信装置から受信した取得要求の要求対象コンテンツの識別子がルートディレクトリを示す特定の値である場合、所定のアドレスからルートディレクトリにおけるコンテンツ属性情報を取得することを特徴とする請求項１に記載のコンテンツ属性情報提供装置。 - 前記記憶手段は、
前記受信装置から、前記記憶領域の中のコンテンツに関するコンテンツ属性情報の取得要求を受信した場合に、前記記憶領域を示す識別子と、前記記憶領域の中のコンテンツを示す識別子とを前記記憶媒体に記憶することを特徴とする請求項１又は２に記載のコンテンツ属性情報提供装置。 - 第１の取得手段が、コンテンツ提供装置が管理している階層分けされた記憶領域の中のコンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得する第１の取得ステップと、
記憶手段が、前記第１の取得ステップにより取得されたコンテンツ属性情報に基づいて、前記階層分けされた記憶領域の中のコンテンツを示す識別子と、当該コンテンツが記憶された記憶領域を示す識別子と、を記憶媒体に記憶する記憶ステップと、
第２の取得手段が、コンテンツに関する所定の形式のコンテンツ属性情報を受信する受信装置からコンテンツ属性情報の取得要求を受信した場合に、前記取得要求のあったコンテンツ属性情報に対応するコンテンツが記憶された記憶領域を示す識別子を前記記憶媒体から取得するとともに、前記取得要求のあったコンテンツ属性情報を前記コンテンツ提供装置から取得する第２の取得ステップと、
送信手段が、前記受信装置から前記コンテンツに関するコンテンツ属性情報の取得要求を受信した場合に、前記第２の取得手段により取得された前記コンテンツが記憶された記憶領域を示す識別子と、前記コンテンツ属性情報と、前記コンテンツを示す識別子とを、前記所定の形式で前記受信装置に送信する送信ステップと、
を備え、
前記コンテンツを示す識別子は、当該コンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得するための第１のアドレスであり、
前記コンテンツが記憶された記憶領域を示す識別子は、当該記憶領域に関する属性情報を前記コンテンツ提供装置から取得するための第２のアドレスであり、
前記第２の取得ステップは、前記第１のアドレスを用いて、前記取得要求のあったコンテンツ属性情報を前記コンテンツ提供装置から取得することを特徴とするコンテンツ属性情報提供方法。 - 前記第２の取得ステップは、
前記受信装置から受信した取得要求の要求対象コンテンツの識別子がルートディレクトリを示す特定の値である場合、所定のアドレスからルートディレクトリにおけるコンテンツ属性情報を取得することを特徴とする請求項４に記載のコンテンツ属性情報提供方法。 - 前記記憶ステップは、
前記受信装置から、前記記憶領域の中のコンテンツに関するコンテンツ属性情報の取得要求を受信した場合に、前記記憶領域を示す識別子と、前記記憶領域の中のコンテンツを示す識別子とを前記記憶媒体に記憶することを特徴とする請求項４又は５に記載のコンテンツ属性情報提供方法。 - コンテンツ提供装置が管理している階層分けされた記憶領域の中のコンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得する第１の取得手順と、
前記第１の取得手段により取得されたコンテンツ属性情報に基づいて、当該コンテンツを示す識別子と、前記階層分けされた記憶領域の中のコンテンツが記憶された記憶領域を示す識別子と、を記憶媒体に記憶する記憶手順と、
コンテンツに関する所定の形式のコンテンツ属性情報を受信する受信装置からコンテンツ属性情報の取得要求を受信した場合に、前記取得要求のあったコンテンツ属性情報に対応するコンテンツが記憶された記憶領域を示す識別子を前記記憶媒体から取得するとともに、前記取得要求のあったコンテンツ属性情報を前記コンテンツ提供装置から取得する第２の取得手順と、
前記受信装置から前記コンテンツに関するコンテンツ属性情報の取得要求を受信した場合に、前記第２の取得手段により取得された前記コンテンツが記憶された記憶領域を示す識別子と、前記コンテンツ属性情報と、前記コンテンツを示す識別子とを、前記所定の形式で前記受信装置に送信する処理を行う送信手順と、
をコンピュータに実行させ、
前記コンテンツを示す識別子は、当該コンテンツに関するコンテンツ属性情報を前記コンテンツ提供装置から取得するための第１のアドレスであり、
前記コンテンツが記憶された記憶領域を示す識別子は、当該記憶領域に関する属性情報を前記コンテンツ提供装置から取得するための第２のアドレスであり、
前記第２の取得手順は、前記第１のアドレスを用いて、前記取得要求のあったコンテンツ属性情報を前記コンテンツ提供装置から取得することを特徴とするコンピュータプログラム。 - 前記第２の取得手順は、
前記受信装置から受信した取得要求の要求対象コンテンツの識別子がルートディレクトリを示す特定の値である場合、所定のアドレスからルートディレクトリにおけるコンテンツ属性情報を取得することを特徴とする請求項７に記載のコンピュータプログラム。 - 前記記憶手順は、
前記受信装置から、前記記憶領域の中のコンテンツに関するコンテンツ属性情報の取得要求を受信した場合に、前記記憶領域を示す識別子と、前記記憶領域の中のコンテンツを示す識別子とを前記記憶媒体に記憶することを特徴とする請求項７又は８に記載のコンピュータプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009134412A JP5317835B2 (ja) | 2009-06-03 | 2009-06-03 | コンテンツ属性情報提供装置、コンテンツ属性情報提供方法、及びコンピュータプログラム |
| US12/789,279 US20100312789A1 (en) | 2009-06-03 | 2010-05-27 | Attribute data providing apparatus and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009134412A JP5317835B2 (ja) | 2009-06-03 | 2009-06-03 | コンテンツ属性情報提供装置、コンテンツ属性情報提供方法、及びコンピュータプログラム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2010282374A JP2010282374A (ja) | 2010-12-16 |
| JP2010282374A5 JP2010282374A5 (ja) | 2012-07-12 |
| JP5317835B2 true JP5317835B2 (ja) | 2013-10-16 |
Family
ID=43301491
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2009134412A Expired - Fee Related JP5317835B2 (ja) | 2009-06-03 | 2009-06-03 | コンテンツ属性情報提供装置、コンテンツ属性情報提供方法、及びコンピュータプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20100312789A1 (ja) |
| JP (1) | JP5317835B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012213111A (ja) * | 2011-03-31 | 2012-11-01 | Sony Corp | 通信システム、通信装置並びに通信方法 |
| JP5117599B1 (ja) | 2011-06-30 | 2013-01-16 | 株式会社東芝 | 制御端末およびネットワークシステム |
| EP2566177B1 (en) | 2011-08-31 | 2020-10-07 | Samsung Electronics Co., Ltd. | Electronic apparatus and method for transferring contents on cloud system to device connected to DLNA |
| KR102079339B1 (ko) * | 2011-08-31 | 2020-02-19 | 삼성전자주식회사 | 클라우드 시스템상의 컨텐츠를 디엘엔에이로 연결된 디바이스로 전달하는 전자 장치 및 방법 |
| US11010782B2 (en) * | 2015-10-16 | 2021-05-18 | International Business Machines Corporation | Payment for a service utilizing information |
| JP7463130B2 (ja) | 2020-02-28 | 2024-04-08 | キヤノン株式会社 | 情報処理システム、情報処理装置、情報処理方法、及びプログラム |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6226788B1 (en) * | 1998-07-22 | 2001-05-01 | Cisco Technology, Inc. | Extensible network management system |
| US7506034B2 (en) * | 2000-03-03 | 2009-03-17 | Intel Corporation | Methods and apparatus for off loading content servers through direct file transfer from a storage center to an end-user |
| JP2004102767A (ja) * | 2002-09-11 | 2004-04-02 | Nippon Hoso Kyokai <Nhk> | メタデータ収集分配システム、メタデータ収集サーバ、メタデータ収集方法、メタデータ収集プログラム、及びメタデータ収集プログラムを記録した記録媒体 |
| JP2004185456A (ja) * | 2002-12-05 | 2004-07-02 | Hitachi Ltd | カスタマイズされたコンテンツの配信システム |
| JP2004234158A (ja) * | 2003-01-29 | 2004-08-19 | Sony Corp | 情報処理装置、およびコンテンツ管理方法、コンテンツ情報管理方法、並びにコンピュータ・プログラム |
| US7603335B2 (en) * | 2003-09-30 | 2009-10-13 | Sony Corporation | Acquisition of attribute and accounting information with communication interruption |
| JP2006039814A (ja) * | 2004-07-26 | 2006-02-09 | Hitachi Ltd | ネットワークストレージシステム及び複数ネットワークストレージ間の引継方法 |
| JP2006165650A (ja) * | 2004-12-02 | 2006-06-22 | Matsushita Electric Ind Co Ltd | メタデータ管理装置 |
| US8229985B2 (en) * | 2005-02-07 | 2012-07-24 | Cisco Technology, Inc. | Arrangement for a distributed file system having data objects mapped independent of any data object attribute |
| JPWO2007046446A1 (ja) * | 2005-10-18 | 2009-04-23 | 株式会社ジャストシステム | データ管理装置及び端末装置 |
| EP1963958B1 (en) * | 2005-12-21 | 2019-04-24 | Digimarc Corporation | Rules driven pan id metadata routing system and network |
| CN101438256B (zh) * | 2006-03-07 | 2011-12-21 | 索尼株式会社 | 信息处理设备、信息通信***、信息处理方法 |
| JP2007257047A (ja) * | 2006-03-20 | 2007-10-04 | Sony Corp | 情報処理装置および情報処理方法、プログラム格納媒体、プログラム、データ構造、並びに、記録媒体の製造方法 |
| US20070233972A1 (en) * | 2006-03-28 | 2007-10-04 | Emc Corporation | Methods and apparatus for transferring content to multiple destinations |
| MX2009000687A (es) * | 2006-12-12 | 2009-03-05 | Panasonic Corp | Aparato de emision de informacion de contenido, aparato de recepcion de informacion de contenido, metodo de emision de informacion de contenido y metodo de recpcion de informacion de contenido. |
| US8239351B2 (en) * | 2007-06-07 | 2012-08-07 | Apple Inc. | Methods and systems for managing permissions data |
| JP5252854B2 (ja) * | 2007-08-15 | 2013-07-31 | キヤノン株式会社 | アダプタ装置及びその制御方法、コンピュータプログラム |
| US9654328B2 (en) * | 2007-10-15 | 2017-05-16 | Viasat, Inc. | Methods and systems for implementing a cache model in a prefetching system |
| EP2377089A2 (en) * | 2008-12-05 | 2011-10-19 | Social Communications Company | Managing interactions in a network communications environment |
-
2009
- 2009-06-03 JP JP2009134412A patent/JP5317835B2/ja not_active Expired - Fee Related
-
2010
- 2010-05-27 US US12/789,279 patent/US20100312789A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| US20100312789A1 (en) | 2010-12-09 |
| JP2010282374A (ja) | 2010-12-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4624701B2 (ja) | ネットワークを介した機器情報の管理装置およびその方法 | |
| JP5624525B2 (ja) | 情報処理装置、リソース提供装置および情報処理システム | |
| RU2448362C2 (ru) | Отображение обнаруженных элементов универсального режима "подключай и работай" на местоположение smb | |
| US8560497B2 (en) | Inter-home sharing apparatus and method using home network device | |
| CN101385020B (zh) | 同步内容目录服务装置的方法、内容目录服务装置和*** | |
| JP5317835B2 (ja) | コンテンツ属性情報提供装置、コンテンツ属性情報提供方法、及びコンピュータプログラム | |
| US20100115053A1 (en) | Method and apparatus for managing state information of remote user interface | |
| KR101469540B1 (ko) | 리소스 정보를 이용하여 ＵＰｎＰ 디바이스를 발견하는방법 및 장치 | |
| EP2738992B1 (en) | Method and device for controlling digital living network alliance contents | |
| JP2003330825A (ja) | ネットワークを通した機器情報の提供装置及びその方法 | |
| JP2011248732A (ja) | 情報処理装置、情報処理方法および情報処理システム | |
| JP5448489B2 (ja) | 情報処理装置及びその制御方法、情報処理システム、及び、プログラム | |
| JP2004348455A (ja) | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム | |
| JP4799005B2 (ja) | 情報処理装置 | |
| KR100724940B1 (ko) | Ｄｌｎａ 시스템에서의 ｄｍｓ의 컨텐츠 업데이트 방법 | |
| JP4808122B2 (ja) | 内部ネットワーク上の内部端末に外部ネットワーク上の外部サーバからコンテンツを取得して送信する方法、内部サーバ、及び外部サーバ | |
| JP4886712B2 (ja) | アクセス制御システム、アクセス制御方法、アクセス制御装置およびアクセス制御プログラム | |
| CN101068252B (zh) | 将提供与不提供内容目录服务的装置同步的方法和设备 | |
| JP5733927B2 (ja) | 送信装置、送信方法、送信システム、及び、プログラム | |
| KR100965458B1 (ko) | 유비쿼터스 서브네트워크 연동을 위한 브로커 | |
| KR100501899B1 (ko) | 범용 플러그앤플레이를 지원하기 위한 프록시 장치 및 그동작방법 | |
| KR20080000310A (ko) | 홈네트워크 간의 정보 공유 시스템 및 정보 공유 방법,그리고 정보 공유 생성 방법 | |
| EP1862919B1 (en) | Method and apparatus for synchronizing device providing content directory service with device not providing content directory service | |
| KR100513291B1 (ko) | 네트워크간의 연결을 지원하는 네트워크 시스템 및 그 방법 | |
| CN101989980A (zh) | 多媒体共享方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20120528 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120528 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130221 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130312 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130507 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20130611 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130709 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 5317835 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| LAPS | Cancellation because of no payment of annual fees |