(57)【要約】【課題】ネットワークサーバにおいて、コンテンツ再生装置に対してレジューム再生を行うコンテンツを送信するときに、コンテンツ再生装置が、レジューム再生を行うコンテンツの再生位置を記録しておく必要をなくすと共に、コンテンツのレジューム再生に使用されるコンテンツ再生装置が制限されないようにする。【解決手段】制御用マイコンは、ネットワークサーバとＰＣ（コンテンツ再生装置）とのＴＣＰコネクションが切断されたことを検知した場合、ＰＣにより要求されたコンテンツの再生停止位置の情報を含むコンテンツＵＲＩを有するレジューム用コンテンツ情報を生成して、ＨＤＤに記録する（Ｓ６）。ＰＣから、レジューム用コンテンツ情報に含まれるコンテンツＵＲＩを指定したコンテンツの要求が行われると、制御用マイコン３１は、ＨＤＤから、このコンテンツＵＲＩに指定された再生停止位置以降のコンテンツを取得し、ＰＣに送信する（Ｓ１０）。【選択図】図３
2007228205.tif 000002
【特許請求の範囲】
【請求項１】
動画等のコンテンツデータ（以下、コンテンツという）に対応するコンテンツＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒｓ）を指定したＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）−ＧＥＴメソッドに基づくＨＴＴＰリクエストメッセージを送信することによりコンテンツを要求するコンテンツ再生装置にネットワークを介して接続され、
前記コンテンツ再生装置に対して、コンテンツ等の送受信を行うためのネットワークインタフェースと、
コンテンツと、このコンテンツの名前やサイズ等の情報を有するコンテンツ情報とを記録する記録部と、
前記コンテンツ再生装置から送信されたＨＴＴＰリクエストメッセージを受信するリクエスト受信手段と、
前記リクエスト受信手段が受信したＨＴＴＰリクエストメッセージに基づき、前記記録部からコンテンツ、又はコンテンツ情報を取得するコンテンツ取得手段と、
前記ＨＴＴＰリクエストメッセージに応答するＨＴＴＰレスポンスメッセージとして、前記コンテンツ取得手段が取得したコンテンツ等のデータを前記コンテンツ再生装置に送信するレスポンス送信手段と、
装置各部を制御する制御手段とを備えたネットワークサーバにおいて、
装置本体と前記コンテンツ再生装置とのＴＣＰコネクションの接続／切断を検知するコネクション検知手段と、
コンテンツの再生停止位置情報を含んだコンテンツＵＲＩをさらに有する前記コンテンツ情報を生成して、前記記録部に記録するコンテンツ情報生成手段とをさらに備え、
前記コンテンツ再生装置からコンテンツを要求するためのＨＴＴＰリクエストメッセージを前記リクエスト受信手段により受信すると、前記制御手段が、前記コンテンツ取得手段により、前記コンテンツ再生装置から要求があったコンテンツを前記記録部より取得した後、前記レスポンス送信手段により、取得したコンテンツを該コンテンツ再生装置に送信し、
前記レスポンス送信手段により送信されたコンテンツを前記コンテンツ再生装置が再生しているときに、前記制御手段が、前記コネクション検知手段により、装置本体と前記コンテンツ再生装置とのＴＣＰコネクションが切断されたことを検知した場合、該コンテンツ再生装置が前記要求したコンテンツの再生を停止したと判断して、前記制御手段が、前記コンテンツ情報生成手段により、前記要求されたコンテンツの再生停止位置の情報を含むコンテンツＵＲＩを有するコンテンツ情報（以下、レジューム用コンテンツ情報という）を生成して、前記記録部に記録した後、
前記コンテンツ再生装置により前記要求したコンテンツの前回の再生停止位置からの再生の要求が行われた場合、前記制御手段が、前記コンテンツ取得手段により、前記記録部から前記レジューム用コンテンツ情報を取得した後、前記レスポンス手段により、該コンテンツ再生装置に該レジューム用コンテンツ情報を送信し、
前記コンテンツ再生装置により、前記レジューム用コンテンツ情報に含まれるコンテンツＵＲＩを指定したコンテンツの要求が行われると、前記制御手段が、前記コンテンツ取得手段により、前記記録部から、該レジューム用コンテンツ情報に含まれるコンテンツＵＲＩに指定された再生停止位置以降のコンテンツを取得し、前記レスポンス手段により、この取得したコンテンツを該コンテンツ再生装置に送信することを特徴とするネットワークサーバ。
【請求項２】
動画等のコンテンツデータ（以下、コンテンツという）に対応するコンテンツＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒｓ）を含むリクエストメッセージを送信することによりコンテンツを要求するコンテンツ再生装置にネットワークを介して接続され、
前記コンテンツ再生装置に対して、コンテンツ等の送受信を行うためのネットワークインタフェースと、
コンテンツと、このコンテンツの名前やサイズ等の情報を有するコンテンツ情報とを記録する記録部と、
前記コンテンツ再生装置から送信されたリクエストメッセージを受信するリクエスト受信手段と、
前記リクエスト受信手段が受信したリクエストメッセージに基づき、前記記録部からコンテンツ、又はコンテンツ情報を取得するコンテンツ取得手段と、
前記リクエストメッセージに応答するレスポンスメッセージとして、前記コンテンツ取得手段が取得したコンテンツ等のデータを前記コンテンツ再生装置に送信するレスポンス送信手段と、
装置各部を制御する制御手段とを備えたネットワークサーバにおいて、
コンテンツの再生停止位置情報を含んだコンテンツＵＲＩをさらに有する前記コンテンツ情報を生成して、前記記録部に記録するコンテンツ情報生成手段をさらに備え、
前記コンテンツ再生装置からコンテンツを要求するためのリクエストメッセージを前記リクエスト受信手段により受信すると、前記制御手段が、前記コンテンツ取得手段により、前記コンテンツ再生装置から要求があったコンテンツを前記記録部より取得した後、取得したコンテンツを前記レスポンス送信手段により該コンテンツ再生装置に送信し、前記レスポンス送信手段により送信されたコンテンツを該コンテンツ再生装置が再生することを停止した場合、
前記制御手段が、前記コンテンツ情報生成手段により、前記要求されたコンテンツの再生停止位置の情報を含むコンテンツＵＲＩを有するコンテンツ情報を生成することを特徴とするネットワークサーバ。
【請求項３】
装置本体と前記コンテンツ再生装置とのＴＣＰコネクションの接続／切断を検知するコネクション検知手段をさらに備え、
前記制御手段が、前記コネクション検知手段により、装置本体と前記コンテンツ再生装置とのＴＣＰコネクションが切断されたことを検知した場合、該コンテンツ再生装置が前記要求したコンテンツの再生を停止したと判断することを特徴とする請求項２に記載のネットワークサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークサーバに関し、特に動画等のコンテンツデータの再生に関する。
【背景技術】
【０００２】
従来から、動画等のコンテンツデータ（以下、コンテンツという）を再生可能なＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）に、ネットワークを介して、コンテンツを送信するネットワークサーバが知られている。ＰＣは、コンテンツを要求する、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）−ＧＥＴメソッドに基づくＨＴＴＰリクエストメッセージを、ネットワークサーバに送信し、このＨＴＴＰリクエストメッセージを受信したネットワークサーバが、要求されたコンテンツをＰＣに送信するものである。
【０００３】
ＰＣによるコンテンツの再生停止後、ユーザが、再生停止位置からコンテンツの再生（以下、レジューム再生という）を開始したいという要望がある。これに対して、従来から、ＰＣが、コンテンツの再生位置情報が指定されたＲＡＮＧＥヘッダを含んだＨＴＴＰ−ＧＥＴリクエストメッセージをネットワークサーバに送信し、このＨＴＴＰ−ＧＥＴリクエストメッセージを受信したネットワークサーバが、ＲＡＮＧＥヘッダに指定されたコンテンツの再生位置情報を解析して、ＰＣにＲＡＮＧＥヘッダに指定された再生位置からコンテンツを送信するようにしたものが知られている。これにより、ＰＣがレジューム再生を行うことができる。
【０００４】
しかし、上記方法では、コンテンツのレジューム再生を行うＰＣが、レジューム再生を行うコンテンツの再生位置を記録しておく必要がある。また、ＰＣがコンテンツのレジューム再生位置を記録しているため、ユーザが、前回コンテンツの再生に使用したＰＣと異なるＰＣから、コンテンツのレジューム再生を行うことができず、レジューム再生を行うことができるＰＣが制限されるという問題がある。
【０００５】
ところで、この種のネットワークサーバにおいて、特許文献１の発明は、ＰＣが、コンテンツの再生を一時停止しているとき、ネットワークサーバがＰＣにＨＴＴＰ  ＨＥＡＤリクエストメッセージを定期的に送信するものである。そのため、このネットワークサーバによれば、ＰＣとネットワークサーバとのＴＣＰコネクションが切断されないため、ＰＣが、一時停止を終了した後、再生を再開することができる。
【０００６】
また、特許文献２の発明は、テレビやラジオなどのブロードキャストチャンネルに接続され、動画等のコンテンツ、及びテレビやラジオ等のコンテンツを、ＰＣに送信することができるネットワークサーバである。そのため、テレビやラジオ等のデータも、コンテンツのアイテムとして表示することができるので、ネットワークサーバは、動画等のコンテンツだけではなく、テレビやラジオ等のコンテンツをＰＣに送信することができる。
【０００７】
また、特許文献３の発明は、ＰＣが、ネットワークサーバに対して変速再生されたコンテンツデータを要求した場合、ネットワークサーバが、変速再生コンテンツデータを生成してＰＣに送信するものである。そのため、ＰＣは、ネットワークサーバからの受信コンテンツに対して、通常のコンテンツ再生と同様の処理を実行することのみで、コンテンツを変速再生することができる。
【０００８】
また、特許文献４の発明は、ネットワークを介して受信したコンテンツのコンテンツ情報を、固有のコンテンツのコンテンツ情報にマッピングするマッピング手段と、ネットワークを介して受信したコンテンツのコンテンツ情報内の番組ごとに割り当てられた固有の識別子とを使用して所定の方法でコンテンツにアクセスするコンテンツアクセス手段とを備えたネットワークサーバである。そのため、コンテンツを再生可能なＰＣが、固有のコンテンツ情報を使用して、ネットワークサーバに、コンテンツの送信要求を行うことができる。
【０００９】
しかし、上記特許文献１乃至特許文献４に記載された発明には、コンテンツ再生装置が、コンテンツの再生位置を記録することなく、コンテンツのレジューム再生を行うことができる旨の概念は示されていない。
【特許文献１】特開２００５−１６７８９１号公報
【特許文献２】特開２００５−１５１５６９号公報
【特許文献３】特開２００４−３５００４３号公報
【特許文献４】特開２００４−３２０７５２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明は、上記問題を解決するためになされたものであり、コンテンツ再生装置に対してレジューム再生を行うコンテンツを送信するときに、コンテンツ再生装置が、レジューム再生を行うコンテンツの再生位置を記録しておく必要がなくなると共に、コンテンツのレジューム再生に使用されるコンテンツ再生装置が制限されることが少ないネットワークサーバを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するために請求項１の発明は、動画等のコンテンツデータ（以下、コンテンツという）に対応するコンテンツＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒｓ）を指定したＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）−ＧＥＴメソッドに基づくＨＴＴＰリクエストメッセージを送信することによりコンテンツを要求するコンテンツ再生装置にネットワークを介して接続され、前記コンテンツ再生装置に対して、コンテンツ等の送受信を行うためのネットワークインタフェースと、コンテンツと、このコンテンツの名前やサイズ等の情報を有するコンテンツ情報とを記録する記録部と、前記コンテンツ再生装置から送信されたＨＴＴＰリクエストメッセージを受信するリクエスト受信手段と、前記リクエスト受信手段が受信したＨＴＴＰリクエストメッセージに基づき、前記記録部からコンテンツ、又はコンテンツ情報を取得するコンテンツ取得手段と、前記ＨＴＴＰリクエストメッセージに応答するＨＴＴＰレスポンスメッセージとして、前記コンテンツ取得手段が取得したコンテンツ等のデータを前記コンテンツ再生装置に送信するレスポンス送信手段と、装置各部を制御する制御手段とを備えたネットワークサーバにおいて、装置本体と前記コンテンツ再生装置とのＴＣＰコネクションの接続／切断を検知するコネクション検知手段と、コンテンツの再生停止位置情報を含んだコンテンツＵＲＩをさらに有する前記コンテンツ情報を生成して、前記記録部に記録するコンテンツ情報生成手段とをさらに備え、前記コンテンツ再生装置からコンテンツを要求するためのＨＴＴＰリクエストメッセージを前記リクエスト受信手段により受信すると、前記制御手段が、前記コンテンツ取得手段により、前記コンテンツ再生装置から要求があったコンテンツを前記記録部より取得した後、前記レスポンス送信手段により、取得したコンテンツを該コンテンツ再生装置に送信し、前記レスポンス送信手段により送信されたコンテンツを前記コンテンツ再生装置が再生しているときに、前記制御手段が、前記コネクション検知手段により、装置本体と前記コンテンツ再生装置とのＴＣＰコネクションが切断されたことを検知した場合、該コンテンツ再生装置が前記要求したコンテンツの再生を停止したと判断して、前記制御手段が、前記コンテンツ情報生成手段により、前記要求されたコンテンツの再生停止位置の情報を含むコンテンツＵＲＩを有するコンテンツ情報（以下、レジューム用コンテンツ情報という）を生成して、前記記録部に記録した後、前記コンテンツ再生装置により前記要求したコンテンツの前回の再生停止位置からの再生の要求が行われた場合、前記制御手段が、前記コンテンツ取得手段により、前記記録部から前記レジューム用コンテンツ情報を取得した後、前記レスポンス手段により、該コンテンツ再生装置に該レジューム用コンテンツ情報を送信し、前記コンテンツ再生装置により、前記レジューム用コンテンツ情報に含まれるコンテンツＵＲＩを指定したコンテンツの要求が行われると、前記制御手段が、前記コンテンツ取得手段により、前記記録部から、該レジューム用コンテンツ情報に含まれるコンテンツＵＲＩに指定された再生停止位置以降���コンテンツを取得し、前記レスポンス手段により、この取得したコンテンツを該コンテンツ再生装置に送信するものである。
【００１２】
請求項２の発明は、動画等のコンテンツデータ（以下、コンテンツという）に対応するコンテンツＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒｓ）を含むリクエストメッセージを送信することによりコンテンツを要求するコンテンツ再生装置にネットワークを介して接続され、前記コンテンツ再生装置に対して、コンテンツ等の送受信を行うためのネットワークインタフェースと、コンテンツと、このコンテンツの名前やサイズ等の情報を有するコンテンツ情報とを記録する記録部と、前記コンテンツ再生装置から送信されたリクエストメッセージを受信するリクエスト受信手段と、前記リクエスト受信手段が受信したリクエストメッセージに基づき、前記記録部からコンテンツ、又はコンテンツ情報を取得するコンテンツ取得手段と、前記リクエストメッセージに応答するレスポンスメッセージとして、前記コンテンツ取得手段が取得したコンテンツ等のデータを前記コンテンツ再生装置に送信するレスポンス送信手段と、装置各部を制御する制御手段とを備えたネットワークサーバにおいて、コンテンツの再生停止位置情報を含んだコンテンツＵＲＩをさらに有する前記コンテンツ情報を生成して、前記記録部に記録するコンテンツ情報生成手段をさらに備え、前記コンテンツ再生装置からコンテンツを要求するためのリクエストメッセージを前記リクエスト受信手段により受信すると、前記制御手段が、前記コンテンツ取得手段により、前記コンテンツ再生装置から要求があったコンテンツを前記記録部より取得した後、取得したコンテンツを前記レスポンス送信手段により該コンテンツ再生装置に送信し、前記レスポンス送信手段により送信されたコンテンツを該コンテンツ再生装置が再生することを停止した場合、前記制御手段が、前記コンテンツ情報生成手段により、前記要求されたコンテンツの再生停止位置の情報を含むコンテンツＵＲＩを有するコンテンツ情報を生成するものである。
【００１３】
請求項３の発明は、請求項２に記載のネットワークサーバにおいて、装置本体と前記コンテンツ再生装置とのＴＣＰコネクションの接続／切断を検知するコネクション検知手段をさらに備え、前記制御手段が、前記コネクション検知手段により、装置本体と前記コンテンツ再生装置とのＴＣＰコネクションが切断されたことを検知した場合、該コンテンツ再生装置が前記要求したコンテンツの再生を停止したと判断するものである。
【発明の効果】
【００１４】
本発明によれば、コンテンツ再生装置が、送信されたコンテンツを再生することを停止した場合、制御手段が、コンテンツ再生装置から要求されたコンテンツの再生停止位置の情報を含むコンテンツＵＲＩを有するコンテンツ情報（以下、レジューム用コンテンツ情報という）を生成する。そして、コンテンツ再生装置により、要求したコンテンツの前回の再生停止位置からの再生の要求が行われた場合、制御手段が、コンテンツ再生装置に、レジューム用コンテンツ情報を送信し、レジューム用コンテンツ情報を受信したコンテンツ再生装置は、レジューム用コンテンツ情報に含まれるコンテンツＵＲＩを指定したコンテンツの要求を行うことができる。
【００１５】
そのため、制御手段は、レジューム用コンテンツ情報に含まれるコンテンツＵＲＩに指定された再生停止位置以降のコンテンツを、記録部から取得し、コンテンツ再生装置に送信することができる。従って、従来のように、コンテンツ再生装置が、前回要求したコンテンツの再生停止位置を記録する必要がないので、コンテンツ再生装置の処理負荷を軽減させることができる。
【００１６】
また、ユーザが、前回コンテンツの要求を行ったコンテンツ再生装置とは別のコンテンツ再生装置を利用して、要求したコンテンツの前回の再生停止位置からの再生の要求を行った場合であっても、制御手段が、コンテンツ再生装置に、レジューム用コンテンツ情報を送信するので、コンテンツ再生装置は、コンテンツの再生停止位置の情報を指定したコンテンツの要求を行うことができる。従って、要求したコンテンツの前回の再生停止位置からの再生（レジューム再生）に使用されるコンテンツ再生装置が、ほとんど制限されない。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の一実施形態について、図面を参照して説明する。図１は、ＰＣ１（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ：請求項におけるコンテンツ再生装置）と、このＰＣ１とネットワークケーブル２を介して接続されたネットワークサーバ３とを含むホームネットワークの構成を示し、図２は、ネットワークサーバ３の内部構成を示す。なお、ここでは、本発明におけるコンテンツ再生装置がＰＣ１である場合の例について説明する。また、ＰＣ１、及びネットワークサーバ３は、ＵＰｎＰ  ＡＶ（ユニバーサルプラグアンドプレイの仕様に基づくＡＶ機器用の相互接続規格）対応機器とする。
【００１８】
ＵＰｎＰ対応機器は、互いの機器間で、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）に準拠したメタデータを交換し、各機器の操作方法や、お互いに連携する際の手順を規格として定め、その規格に従って動作する。そのため、ネットワークに、ＵＰｎＰ対応機器を、容易に追加、又は削除することができるという利点がある。また、ネットワークサーバ３は、ＵＰｎＰ  ＡＶ仕様に基づくメディアサーバ等のデバイス、及びコンテンツ一覧の取得等の制御を行うコンテンツディレクトリとして機能するものとする。ＰＣ１は、ＵＰｎＰ  ＡＶ仕様に基づくコンテンツの場所の特定等を行うコントロールポイントとして機能するものとし、ＰＣ１は、ネットワークサーバ３のコンテンツディレクトリに対してＢｒｏｗｓｅコマンド等を送信するものとする。
【００１９】
ＰＣ１は、ネットワークケーブル２が接続されるネットワークインタフェース（図示せず）と、ユーザに各種の情報を表示するディスプレイ１１と、音声を出力するスピーカ１２と、ユーザが操作するためのボタン等を有する操作部１３とを備えている。
【００２０】
ＰＣ１は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）−ＧＥＴメソッドに基づくＨＴＴＰリクエストメッセージを、ネットワークケーブル２を介して、ネットワークサーバ３に送信することにより、動画等のコンテンツデータ（以下、コンテンツという）を要求することができる。そして、ＰＣ１は、ネットワークサーバ３から、要求したコンテンツを受信することにより、このコンテンツの映像、及び音声をディスプレイ１１、及びスピーカ１２に出力することができる。なお、ＰＣ１は、ＨＴＴＰリクエストメッセージに、要求するコンテンツに対応するコンテンツＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒｓ）を含むことができる（詳細は後述する）。
【００２１】
図２に示すように、ネットワークサーバ３は、ＰＣ１に対してコンテンツ等の送受信を行うためのネットワークインタフェース３５と、コンテンツと、このコンテンツの名前やサイズ等の情報を有するコンテンツ情報とを記録するハードディスク３３（以下、ＨＤＤ：請求項において記録部）と、ユーザが操作するためのボタン等を有する操作部３４と、装置各部を制御する制御用マイコン３１と、制御用マイコン３１の動作プログラムを格納するメモリ３２とを備えている。
【００２２】
制御用マイコン３１は、ＰＣ１から送信されたＨＴＴＰリクエストメッセージを受信するリクエスト受信手段、リクエスト受信手段が受信したＨＴＴＰリクエストメッセージに基づき、ＨＤＤ３３からコンテンツ、又はコンテンツ情報を取得するコンテンツ取得手段、ＨＴＴＰリクエストメッセージに応答するＨＴＴＰレスポンスメッセージとして、コンテンツ取得手段が取得したコンテンツ等のデータをＰＣ１に送信するレスポンス送信手段、ネットワークサーバ３とＰＣ１とのＴＣＰコネクションの接続／切断を検知するコネクション検知手段、コンテンツの再生停止位置情報を含んだコンテンツＵＲＩをさらに有するコンテンツ情報を生成して、ＨＤＤ３３に記録するコンテンツ情報生成手段として機能する。また、制御用マイコン３１は、ＵＰｎＰ  ＡＶ仕様に基づくコンテンツディレクトリ、及び各種ＨＴＴＰメッセージの送受信を行うＨＴＴＰサーバとして機能する。
【００２３】
次に、ＰＣ１より前回の再生停止位置からのコンテンツの再生（以下、レジューム再生という）の要求が行われた場合のネットワークサーバ３の処理について、図３を参照して説明する。まず、ユーザがＰＣ１の操作部１３を操作することにより、ネットワークサーバ３に対して、ＨＤＤ３３に記録されているコンテンツのコンテンツ情報の要求を行うと（Ｓ１）、この要求を受信した制御用マイコン３１は、ＨＤＤ３３に記録されているコンテンツ情報をＰＣ１に送信する（Ｓ２）。
【００２４】
ＰＣ１は、ネットワークサーバ３からコンテンツ情報を受信すると、ディスプレイ１１に、このコンテンツ情報を表示する。ユーザが、操作部１３を操作することにより、コンテンツの再生を選択した場合、ＰＣ１がネットワークサーバ３に対してＴＣＰコネクションの接続要求を行う。そして、ＰＣ１とネットワークサーバ３との間にＴＣＰコネクション接続が確立されると、ＰＣ１は、コンテンツを要求するためのＨＴＴＰリクエストメッセージを、ネットワークサーバ３に送信する（Ｓ３）。制御用マイコン３１は、ＰＣ１から送信されたＨＴＴＰリクエストメッセージを受信すると、ＰＣ１から要求があったコンテンツをＨＤＤ３３より取得した後、取得したコンテンツをＰＣ１に送信する（Ｓ４）。
【００２５】
ＰＣ１は、ネットワークサーバ３から受信したコンテンツを再生し、映像をディスプレイ１１に、音声をスピーカ１２に出力する。受信したコンテンツをＰＣ１が再生しているときに、ユーザが、操作部１３を操作することにより、受信したコンテンツの再生を停止すると、ＰＣ１とネットワークサーバ３との間のＴＣＰコネクションが切断される（Ｓ５）。
【００２６】
制御用マイコン３１は、ネットワークサーバ３とＰＣ１とのＴＣＰコネクションが切断されたことを検知した場合、ＰＣ１が要求したコンテンツの再生を停止したと判断して、ＰＣ１により要求されたコンテンツについて再生停止位置の情報を含むコンテンツＵＲＩを有するコンテンツ情報（以下、レジューム用コンテンツ情報という）を生成して、ＨＤＤ３３に記録する（Ｓ６）。
【００２７】
そして、ユーザがＰＣ１の操作部１３を操作することにより、ネットワークサーバ３に対して、ＨＤＤ３３に記録されているコンテンツ情報の要求を行うと（Ｓ７）、制御用マイコン３１は、ＨＤＤ３３に記録されているレジューム用コンテンツ情報をＰＣ１に送信する（Ｓ８）。
【００２８】
ネットワークサーバ３から送信されたレジューム用コンテンツ情報を受信したＰＣ１は、ディスプレイ１１に、このレジューム用コンテンツ情報を表示する。ユーザが、操作部１３を操作することにより、上述したＳ３で要求したコンテンツと同じコンテンツに対して、前回の再生停止位置からの再生を選択した場合、ＰＣ１がネットワークサーバ３に対してＴＣＰコネクションの接続要求を行う。そして、ＰＣ１とネットワークサーバ３との間にＴＣＰコネクション接続が確立されると、ＰＣ１は、レジューム用コンテンツ情報に含まれるコンテンツＵＲＩを指定したコンテンツ要求のためのＨＴＴＰリクエストメッセージをネットワークサーバ３に送信する（Ｓ９）。
【００２９】
上記コンテンツの要求が行われると、制御用マイコン３１は、ＨＤＤ３３から、レジューム用コンテンツ情報に含まれるコンテンツＵＲＩに指定された再生停止位置以降のコンテンツを取得し、この取得したコンテンツをＰＣ１に送信する（Ｓ１０）。
【００３０】
そのため、ネットワークサーバ３から送信されたコンテンツを受信したＰＣ１は、前回の再生停止位置以降のコンテンツを受信するので、コンテンツのレジューム再生を容易に行うことができる。
【００３１】
次に、上述したコンテンツ情報、及びレジューム用コンテンツ情報に含まれるコンテンツＵＲＩについて説明する。コンテンツ情報は、ＸＭＬによるＤＩＤＬ−Ｌｉｔｅ  Ｓｃｈｅｍａで表現されたメタデータである。ＰＣ１は、ネットワークサーバ３から、ＤＩＤＬ−Ｌｉｔｅ情報を受信し、このＤＩＤＬ−Ｌｉｔｅ情報を解析することにより、コンテンツに対応するコンテンツＵＲＩを取得する。ＵＲＩの割り当てルールについて、以下に示す。なお、ＵＲＩの割り当てルールは、以下の例に限られない。下記は、コンテンツの再生位置をバイト単位で指定したものについて、ＢＮＦ記法を用いて記述したものである。
・ bytePlay = filename “!byte” first-pos”〜”[time-pos]（コンテンツＵＲＩの書式）
・ filename = （再生位置を指定しないときのファイル名）
・ first-pos = 1*DIGIT（再生開始バイト位置）
・ last-pos = 1*DIGIT（再生終了バイト位置）
上記の例において、ファイル名が「abcd.mpeg」であるコンテンツに対して、再生開始から1000バイトの位置から再生を行う場合、コンテンツＵＲＩは、「abcd.mpeg!byte1000〜」となる。また、再生開始から1000バイトの位置から再生を開始して、2000バイトの位置で終了する場合、コンテンツＵＲＩは、「abcd.mpeg!byte1000〜2000」となる。
【００３２】
また、以下の例は、コンテンツの再生位置を時間単位で指定したものについて、ＢＮＦ記法を用いて記述したものである。
・ timePlay = filename “!time” time-pos “〜”[time-pos]（コンテンツＵＲＩの書式）
・ filename = 再生位置を指定しないときのファイル名
・ time-pos = time-sec|time-hhmmss（時間を指定）
・ time-sec = 1*DIGIT（秒を指定）
・ time-hhmmss = time-hh “_” time-mm “_” time-ss[“.”1*3DIGIT]（時間分秒を指定）
・ time-hh = 1*DIGIT（時間を指定）
・ time-mm = 1*2DIGIT; 0-59（分を指定）
・ time-ss = 1*2DIGIT; 0-59（秒を指定）
上記の例において、ファイル名が「abcd.mpeg」であるコンテンツに対して、再生開始から６０．５秒経過後の位置から再生を行う場合、コンテンツＵＲＩは、「abcd.mpeg!time60.5〜」となる。また、再生開始から６０．５秒経過後の位置から再生を開始して、１２０秒後で終了する場合、コンテンツＵＲＩは、「abcd.mpeg!time60.5〜120」となる。また、再生開始から１時間３０分２９．３秒経過後の位置から再生を行う場合、コンテンツＵＲＩは、「abcd.mpeg!time1_30_29.3〜」となる。また、再生開始から１時間３０分２９．３秒経過後の位置から再生を開始して、２時間で再生を終了する場合、コンテンツＵＲＩは、「abcd.mpeg!time1_30_29.3〜2_00_00」となる。
【００３３】
また、ネットワークサーバ３のＨＴＴＰサーバに対するＵＲＩが「http://192.168.0.27:30001」である場合、ファイル名が「abcd.mpeg」であるコンテンツに対して、コンテンツの再生開始から３０分経過後の位置から再生を行う場合、レジューム用コンテンツ情報に含まれるコンテンツＵＲＩは、「http://192.168.0.27:30001/adcd.mpeg!time0_30_0〜」となる。
【００３４】
上記実施形態によれば、ＰＣ１が、コンテンツを再生することを停止した場合、制御用マイコン３１が、このコンテンツのレジューム用コンテンツ情報を生成する。そして、ＰＣ１により、このコンテンツの前回の再生停止位置からの再生の要求が行われた場合、制御用マイコン３１が、ＰＣ１に、レジューム用コンテンツ情報を送信し、レジューム用コンテンツ情報を受信したＰＣ１は、レジューム用コンテンツ情報に含まれるコンテンツＵＲＩで再生開始位置を指定したコンテンツの要求を行うことができる。
【００３５】
そのため、制御用マイコン３１は、レジューム用コンテンツ情報に含まれるコンテンツＵＲＩで指定された再生停止位置以降のコンテンツを、ＨＤＤ３３から取得し、ＰＣ１に送信することができる。従って、従来のように、ＰＣ１が、前回要求したコンテンツの再生停止位置を記録する必要がないので、ＰＣ１の処理負荷を軽減させることができる。
【００３６】
また、ユーザが、前回コンテンツの要求を行ったＰＣ１とは別のＰＣを操作することにより、このコンテンツの前回の再生停止位置からの再生の要求を行った場合であっても、制御用マイコン３１が、この別のＰＣに、レジューム用コンテンツ情報を送信するので、この別のＰＣは、コンテンツの再生停止位置（再生開始位置）の情報を指定したコンテンツの要求を行うことができる。従って、コンテンツの前回の再生停止位置からの再生（レジューム再生）に使用されるＰＣが、ほとんど制限されない。
【００３７】
なお、上記実施形態では、請求項におけるコンテンツ再生装置が、ＰＣである場合の例について示したが、コンテンツ再生装置は、これに限られず、ＵＰｎＰ  ＡＶ規格に対応した機器であり、かつ、ネットワークを介して受信したコンテンツを再生することができる装置であればよい。
【図面の簡単な説明】
【００３８】
【図１】本発明の一実施形態に係るＰＣと、このＰＣに接続されたネットワークサーバとのネットワーク構成を示す図。
【図２】上記ネットワークサーバの内部構成を示す図。
【図３】上記ネットワークサーバのレジューム再生時の処理の手順を示すフロチャート。
【符号の説明】
【００３９】
１  ＰＣ（コンテンツ再生装置）
３  ネットワークサーバ
３１  制御用マイコン（制御手段、リクエスト受信手段、コンテンツ取得手段、レスポンス送信手段、コネクション検知手段コンテンツ情報生成手段）
３３  ＨＤＤ（記録部）
３４  操作部（操作手段）
３５  ネットワークインタフェース
【図１】
2007228205.tif 000003
【図２】
2007228205.tif 000004
【図３】
2007228205.tif 000005