(57)【要約】【課題】  既存のコンテンツ情報データに基づいて再生対象のコンテンツが蓄積型かライブ型かを精度よく判別し、再生対象のコンテンツの型に応じて適した処理動作を行うことである。【解決手段】  本ストリーミングデータ受信再生端末の制御手段は、操作手段により再生操作を受け付けたら、ストリーミングサーバに対してコンテンツ送信要求を送信する処理を行い、この要求に係るコンテンツ情報データをストリーミングサーバから受信した後、ストリーミングサーバから送信されてくるコンテンツのストリーミングデータを受信してこれを再生するための受信再生処理を行う。そして、制御手段は、コンテンツ情報データの中に、コンテンツの総再生時間情報を記述するための項目が含まれているか否かを判断し、項目が含まれていると判断したときと項目が含まれていないと判断したときとで、当該コンテンツについて互いに異なる受信再生処理を行う。【選択図】  図１
2006094336.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してストリーミングサーバとデータ通信を行うデータ通信手段と、
コンテンツを再生するための再生操作を受け付ける操作手段と、
該操作手段によりコンテンツの再生操作を受け付けたら、該データ通信手段により該ストリーミングサーバに対してコンテンツ送信要求を送信する処理を行い、かつ、該コンテンツ送信要求に係るコンテンツの情報が項目分けして記述されたコンテンツ情報データを該ストリーミングサーバから該データ通信手段により受信し、その後該コンテンツ情報データを用いて該ストリーミングサーバから送信されてくる該コンテンツのストリーミングデータを該データ通信手段により受信してこれを再生するという受信再生処理を行う制御手段とを備えたストリーミングデータ受信再生端末において、
上記制御手段は、上記コンテンツ情報データの中に、該コンテンツ情報データに対応したコンテンツの総再生時間情報を記述するための項目が含まれているか否かを判断し、該項目が含まれていると判断したときと該項目が含まれていないと判断したときとで、該コンテンツについて互いに異なる受信再生処理を行うことを特徴とするストリーミングデータ受信再生端末。
【請求項２】
ネットワークを介してストリーミングサーバとデータ通信を行うデータ通信手段と、
コンテンツを再生するための再生操作を受け付ける操作手段と、
該操作手段によりコンテンツの再生操作を受け付けたら、該データ通信手段により該ストリーミングサーバに対してコンテンツ送信要求を送信する処理を行い、かつ、該コンテンツ送信要求に係るコンテンツの情報が項目分けして記述されたコンテンツ情報データを該ストリーミングサーバから該データ通信手段により受信し、その後該コンテンツ情報データを用いて該ストリーミングサーバから送信されてくる該コンテンツのストリーミングデータを該データ通信手段により受信してこれを再生するという受信再生処理を行う制御手段とを備えたストリーミングデータ受信再生端末において、
上記制御手段は、上記コンテンツ情報データ中に含まれる、該コンテンツ情報データに対応したコンテンツの再生開始時間と再生終了時間とからなる総再生時間情報を記述するための項目に、再生終了時間が記述されているか否かを判断し、該再生終了時間が記述されていると判断したときと該再生終了時間が記述されていないと判断したときとで、該コンテンツについて互いに異なる受信再生処理を行うことを特徴とするストリーミングデータ受信再生端末。
【請求項３】
請求項１又は２のストリーミングデータ受信再生端末において、
ストリーミングデータの再生が中断したときの該ストリーミングデータに対応するコンテンツデータ中の中断箇所を特定するための中断箇所特定情報を記憶するデータ記憶手段を有し、
上記制御手段は、ストリーミングデータの再生が中断したときに行われる、該中断箇所特定情報を該データ記憶手段に保存するための保存処理について、上記項目が含まれていると判断した場合又は上記再生終了時間が記述されていると判断した場合には該保存処理を行い、上記項目が含まれていないと判断した場合又は上記再生終了時間が記述されていないと判断した場合には該保存処理を行わないように動作するとともに、中断したコンテンツの再生操作を受け付けたとき、該データ記憶手段に該中断箇所特定情報が記憶されている場合には上記ストリーミングサーバに対して該中断箇所特定情報を上記データ通信手段により送信し、該中断箇所特定情報が記憶されていない場合には該ストリーミングサーバに対して該中断箇所特定情報を送信しないように動作することを特徴とするストリーミングデータ受信再生端末。
【請求項４】
請求項１又は２のストリーミングデータ受信再生端末において、
ストリーミングデータの再生が中断したときの該ストリーミングデータに対応するコンテンツデータ中の中断箇所を特定するための中断箇所特定情報を記憶するデータ記憶手段を有し、
上記制御手段は、ストリーミングデータの再生が中断したときに該中断箇所特定情報を該データ記憶手段に保存するための保存処理を行うように動作するとともに、中断したコンテンツの再生操作を受け付けたとき、上記項目が含まれていると判断した場合又は上記再生終了時間が記述されていると判断した場合には上記ストリーミングサーバに対して該中断箇所特定情報を上記データ通信手段により送信し、上記項目が含まれていないと判断した場合又は上記再生終了時間が記述されていないと判断した場合には該ストリーミングサーバに対して該中断箇所特定情報を送信しないように動作することを特徴とするストリーミングデータ受信再生端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介してサーバから送信されるストリーミングデータを受信してこれを再生するストリーミングデータ受信再生端末に関するものである。
【背景技術】
【０００２】
特許文献１には、データ受信端末によりストリーミング再生を行っている途中でサーバとの接続が切断して再生が中断したとき、再接続時に切断時からストリーミング再生を再開するための方法が開示されている。この方法は、サーバとの中断時点の時刻情報（中断箇所特定情報）をデータ受信端末で保持しておき、再接続の際にデータ受信端末からサーバへ送信される再生要求にその時刻情報を含ませる。そして、サーバは、その再生要求に係るコンテンツデータの中の当該時刻情報に対応する箇所からストリーミングデータの送信を開始する。これにより、あるコンテンツの再生を中断した後にそのコンテンツを再び再生する場合でも、データ受信端末はその中断時点から当該コンテンツを再生することができるようになる。
【０００３】
ストリーミング配信がなされるコンテンツには、録画放送コンテンツのように過去に生成した蓄積型コンテンツと、生放送コンテンツのように同時刻に生成されるライブ型コンテンツの２種類がある。蓄積型コンテンツにおいて、上記特許文献１に記載の方法により、再生を中断した後にその中断時点から当該コンテンツを再び再生できることは、利用者の利便性を向上させる。しかし、ライブ型コンテンツでは、再生を中断した後にその中断時点から当該コンテンツを再び再生するという概念自体がそもそも存在しない。もし、中断時点から当該コンテンツを再生できるとすれば、そのコンテンツはもはやライブ型コンテンツではなく、蓄積型コンテンツだからである。したがって、ライブ型コンテンツにおいて再生中断後に再度当該コンテンツを再生する場合には、その再度の再生時点から当該コンテンツを再生することになる。
【０００４】
【特許文献１】特開２００２−３３０３８１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところが、上記特許文献１に記載のデータ受信端末（ストリーミングデータ受信再生端末）は、再生対象であるコンテンツが蓄積型なのかライブ型なのかを把握するための構成を備えていない。そのため、コンテンツの再生中断後の再接続時にサーバへ送信する再生要求の中には、そのコンテンツが蓄積型であるかライブ型であるかの区別なく、一律に上記時刻情報が含まれることになる。したがって、このストリーミングデータ受信再生端末を用いてライブ型コンテンツに基づくストリーミングデータを受信再生する場合にも、その再生中断後の再接続時には、サーバに対する再生要求の中に上記時刻情報が含まれることになる。上述したように、ライブ型コンテンツについては再生中断後に、その中断時点から当該コンテンツを再び再生するという概念が存在しない。そのため、上記ライブ型コンテンツを配信するサーバにとって、受信した再生要求中に上記時刻情報が含まれることは想定外である。したがって、当該サーバが実行するコンテンツ配信用プログラムの内容によっては、このような想定外の時刻情報を含む再生要求を受信することにより、当該サーバが正常動作できないおそれがあるという問題があった。
一方で、コンテンツの再生中断後の再接続時にサーバへ送信する再生要求の中に一律に上記時刻情報を含ませないようにすれば、上記問題は発生しない。しかし、この場合には、蓄積型コンテンツの再生中断後これを再び再生する際にその中断時点から当該コンテンツを再生することができなくなり、利用者の利便性が低下してしまうという問題が発生する。
【０００６】
なお、上記の問題を解決するには、ストリーミングデータ受信再生端末において、再生対象のコンテンツが蓄積型なのかライブ型なのかを把握できるようにすることが必要である。この把握を行う方法としては、例えば、ストリーミングデータ通信用の接続を確立するのに先立って事前にサーバからストリーミングデータ受信再生端末へ送信されるＳＤＰ（Session Description Protocol）データ等のコンテンツ情報データに新たな項目を設け、その項目に蓄積型とライブ型の区別をするための識別情報を記述するという方法が考えられる。この方法によれば、ストリーミングデータ受信再生端末がその識別情報に基づいて蓄積型かライブ型かを識別する識別手段を備えていることで、上記問題を解決することが可能となる。すなわち、ストリーミングデータ受信再生端末が、その識別手段の識別結果に基づき、そのコンテンツが蓄積型であれば再接続時の再生要求に上記時刻情報を含ませ、そのコンテンツがライブ型であれば再接続時の再生要求に上記時刻情報を含ませないという処理を行うことで、上記問題を解決することが可能となる。
しかし、コンテンツ情報データに付加できる情報は、一般に規格化されている。そのため、コンテンツ情報データに規格外の新たな識別情報を付加すると、規格に対応した既存のストリーミングデータ受信再生端末が正常動作できなくなる不具合が生じる可能性がある。
【０００７】
また、再生対象のコンテンツが蓄積型かライブ型かによってストリーミングデータ受信再生端末で互いに異なる処理を行わせたい場合は、上述したように、再接続時の再生要求に上記時刻情報を含ませる又は含ませないという処理以外の受信再生処理でも想定される。すなわち、コンテンツ情報データをサーバから受信し、その後サーバから送信されてくるコンテンツのストリーミングデータをこのコンテンツ情報データを用いて受信してこれを再生するという受信再生処理においては、再生対象のコンテンツが蓄積型かライブ型かによって互いに異なる処理を行いたい場合が想定される。この場合も、ストリーミングデータ受信再生端末が再生対象のコンテンツが蓄積型かライブ型かを把握することが必要となるが、上述したようにコンテンツ情報データに上記識別情報を新たに付加する方法を採用すると、同様に上記不具合が生じる可能性がある。
【０００８】
本発明は、以上の背景に鑑みなされたものであり、その目的とするところは、既存のコンテンツ情報データに基づいて再生対象のコンテンツが蓄積型かライブ型かを精度よく判別し、再生対象のコンテンツの型に応じて適した受信再生処理を行うことが可能なストリーミングデータ受信再生端末を提供することである。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、請求項１の発明は、ネットワークを介してストリーミングサーバとデータ通信を行うデータ通信手段と、コンテンツを再生するための再生操作を受け付ける操作手段と、該操作手段によりコンテンツの再生操作を受け付けたら、該データ通信手段により該ストリーミングサーバに対してコンテンツ送信要求を送信する処理を行い、かつ、該コンテンツ送信要求に係るコンテンツの情報が項目分けして記述されたコンテンツ情報データを該ストリーミングサーバから該データ通信手段により受信し、その後該コンテンツ情報データを用いて該ストリーミングサーバから送信されてくる該コンテンツのストリーミングデータを該データ通信手段により受信してこれを再生するという受信再生処理を行う制御手段とを備えたストリーミングデータ受信再生端末において、上記制御手段は、上記コンテンツ情報データの中に、該コンテンツ情報データに対応したコンテンツの総再生時間情報を記述するための項目が含まれているか否かを判断し、該項目が含まれていると判断したときと該項目が含まれていないと判断したときとで、該コンテンツについて互いに異なる受信再生処理を行うことを特徴とするものである。
既存のコンテンツ情報データに含ませることができると規格により定められた項目の中には、当該コンテンツ情報データに対応したコンテンツの総再生時間情報を記述するための項目（以下、「総再生時間項目」という。）が存在する。ライブ型コンテンツの場合、送信時刻と同時刻に生成されるコンテンツデータを順次ストリーミングデータとして送信するため、そのストリーミングデータの送信開始時点ではそのコンテンツデータの終わりが存在していない。そのため、ライブ型コンテンツについては、送信開始時点において再生終了時間を特定できない結果、総再生時間情報をコンテンツ情報データ中に付加することができない。よって、ライブ型コンテンツに対応する既存のコンテンツ情報データにおいては、その総再生時間項目を省略することが多い。これに対し、蓄積型コンテンツの場合は、過去に生成されたものであるので、そのストリーミングデータの送信開始時点ではそのコンテンツデータの終わりが存在している。そのため、コンテンツの総再生時間情報を送信開始時点において予め把握することができる。よって、蓄積型コンテンツに対応する既存のコンテンツ情報データにおいては、総再生時間情報が記述された総再生時間項目が含まれている。したがって、コンテンツ情報データの中に総再生時間項目が含まれているか否かを判断することにより、再生対象のコンテンツが蓄積型コンテンツであるのかライブ型コンテンツであるのかを、精度よく判別できる。
【００１０】
また、請求項２の発明は、ネットワークを介してストリーミングサーバとデータ通信を行うデータ通信手段と、コンテンツを再生するための再生操作を受け付ける操作手段と、該操作手段によりコンテンツの再生操作を受け付けたら、該データ通信手段により該ストリーミングサーバに対してコンテンツ送信要求を送信する処理を行い、かつ、該コンテンツ送信要求に係るコンテンツの情報が項目分けして記述されたコンテンツ情報データを該ストリーミングサーバから該データ通信手段により受信し、その後該コンテンツ情報データを用いて該ストリーミングサーバから送信されてくる該コンテンツのストリーミングデータを該データ通信手段により受信してこれを再生するという受信再生処理を行う制御手段とを備えたストリーミングデータ受信再生端末において、上記制御手段は、上記コンテンツ情報データ中に含まれる、該コンテンツ情報データに対応したコンテンツの再生開始時間と再生終了時間とからなる総再生時間情報を記述するための項目に、再生終了時間が記述されているか否かを判断し、該再生終了時間が記述されていると判断したときと該再生終了時間が記述されていないと判断したときとで、該コンテンツについて互いに異なる受信再生処理を行うことを特徴とするものである。
上述したように、ライブ型コンテンツについては、送信開始時点において再生終了時間を特定できない。そのため、ライブ型コンテンツに対応する既存のコンテンツ情報データにおいては、その総再生時間項目を省略せずにその項目中に再生終了時間を記述しないものも多く存在する。これに対し、蓄積型コンテンツに対応する既存のコンテンツ情報データにおいては、その総再生時間項目に再生開始時間及び再生終了時間が記述される。したがって、コンテンツ情報データの中の総再生時間項目に再生終了時間が記述されているか否かを判断することにより、再生対象のコンテンツが蓄積型コンテンツであるのかライブ型コンテンツであるのかを、精度よく判別できる。特に、本ストリーミングデータ受信再生端末は、規格上、コンテンツ情報データ中の総再生時間項目を省略できない場合でも精度よく判別できるという利点がある。
【００１１】
また、請求項３の発明は、請求項１又は２のストリーミングデータ受信再生端末において、ストリーミングデータの再生が中断したときの該ストリーミングデータに対応するコンテンツデータ中の中断箇所を特定するための中断箇所特定情報を記憶するデータ記憶手段を有し、上記制御手段は、ストリーミングデータの再生が中断したときに行われる、該中断箇所特定情報を該データ記憶手段に保存するための保存処理について、上記項目が含まれていると判断した場合又は上記再生終了時間が記述されていると判断した場合には該保存処理を行い、上記項目が含まれていないと判断した場合又は上記再生終了時間が記述されていないと判断した場合には該保存処理を行わないように動作するとともに、中断したコンテンツの再生操作を受け付けたとき、該データ記憶手段に該中断箇所特定情報が記憶されている場合には上記ストリーミングサーバに対して該中断箇所特定情報を上記データ通信手段により送信し、該中断箇所特定情報が記憶されていない場合には該ストリーミングサーバに対して該中断箇所特定情報を送信しないように動作することを特徴とするものである。
このストリーミングデータ受信再生端末においては、再生対象のコンテンツがそのコンテンツ情報データに基づいて蓄積型であると判別した場合にだけ、ストリーミングデータの再生が中断したときに、中断箇所特定情報をデータ記憶手段に保存するための保存処理が行われる。したがって、ライブ型コンテンツについては、再生が中断しても、中断箇所特定情報がデータ記憶手段に保存されることがない。そして、中断したコンテンツの再生操作を受け付けたときには、データ記憶手段に中断箇所特定情報が記憶されている場合にだけ、ストリーミングサーバへ中断箇所特定情報が送信される。すなわち、蓄積型コンテンツの場合にだけ、中断したコンテンツの再生操作を受け付けたときにストリーミングサーバへ中断箇所特定情報が送信される。
なお、上記保存処理、及び、ストリーミングサーバに対して中断箇所特定情報を送信する処理は、上記受信再生処理の一部である。
【００１２】
また、請求項４の発明は、請求項１又は２のストリーミングデータ受信再生端末において、ストリーミングデータの再生が中断したときの該ストリーミングデータに対応するコンテンツデータ中の中断箇所を特定するための中断箇所特定情報を記憶するデータ記憶手段を有し、上記制御手段は、ストリーミングデータの再生が中断したときに該中断箇所特定情報を該データ記憶手段に保存するための保存処理を行うように動作するとともに、中断したコンテンツの再生操作を受け付けたとき、上記項目が含まれていると判断した場合又は上記再生終了時間が記述されていると判断した場合には上記ストリーミングサーバに対して該中断箇所特定情報を上記データ通信手段により送信し、上記項目が含まれていないと判断した場合又は上記再生終了時間が記述されていないと判断した場合には該ストリーミングサーバに対して該中断箇所特定情報を送信しないように動作することを特徴とするものである。
このストリーミングデータ受信再生端末においては、再生対象のコンテンツが蓄積型でもライブ型でも、ストリーミングデータの再生が中断したときには中断箇所特定情報をデータ記憶手段に保存するための保存処理が行われる。そして、中断したコンテンツの再生操作を受け付けたときには、そのコンテンツがコンテンツ情報データに基づいて蓄積型であると判別した場合にだけ、ストリーミングサーバへ中断箇所特定情報が送信される。
なお、上記保存処理、及び、ストリーミングサーバに対して中断箇所特定情報を送信する処理は、上記受信再生処理の一部である。
【００１３】
なお、上記「ストリーミングデータ受信再生端末」には、移動体通信端末、携帯型情報端末（ＰＤＡ：Personal Digital Assistance）、ディスクトップパソコン等の非携帯型情報端末等も含まれる。また、上記「移動体通信端末」には、ＰＤＣ（Personal Digital Cellular）方式、ＧＳＭ（Global System for Mobile Communication）方式、ＴＩＡ（Telecommunications Industry Association）方式等の携帯電話機、ＩＭＴ（International Mobile Telecommunications）−２０００で標準化された携帯電話機、ＴＤ−ＳＣＤＭＡ（Time Division ynchronous Code Division Multiple Access）方式の一つであるＴＤ−ＳＣＤＭＡ（ＭＣ：Multi Carrier）方式の携帯電話機、ＰＨＳ（Personal Handyphone Service）などが挙げられる。また、上記「移動体通信端末」には、ＰＨＳ（Personal Handyphone System）、自動車電話等の電話機のほか、ネットワークを介してサーバから送信されるストリーミングデータを受信してこれを再生することが可能なあらゆる移動体通信端末も含まれる。
また、上記ストリーミングデータ受信再生端末における制御は、これに設けられたコンピュータで所定のプログラムを実行することによって実現することもできる。このコンピュータで用いるプログラムの受け渡しは、デジタル情報としてプログラムを記録したＦＤ，ＣＤ−ＲＯＭ等の記録媒体を用いて行ってもいいし、コンピュータネットワーク等の通信ネットワークを用いて行ってもよい。
【発明の効果】
【００１４】
以上、請求項１乃至４の発明によれば、既存のコンテンツ情報データに基づいて再生対象のコンテンツが蓄積型かライブ型かを精度よく判別でき、再生対象のコンテンツの型に応じて適した受信再生処理を行うことが可能となるという優れた効果が奏される。
特に、請求項２によれば、規格上、コンテンツ情報データ中の総再生時間項目を省略できない場合でも再生対象のコンテンツが蓄積型かライブ型かを精度よく判別できるという優れた効果が奏される。
また、請求項３及び４によれば、ライブ型コンテンツを配信するストリーミングサーバにとって想定外である中断箇所特定情報が当該サーバに送信されるのを防止して当該サーバが正常動作できないという不具合の発生を防止しつつ、蓄積型コンテンツを中断時点から再生することが可能となるという優れた効果が奏される。
【発明を実施するための最良の形態】
【００１５】
以下、本発明をストリーミングデータ受信再生端末としての移動体通信端末である携帯電話機に適用した一実施形態について、図面を参照しながら説明する。
図２は、本実施形態に係る携帯電話機が利用可能な移動体通信システムの全体構成を説明するための説明図である。
この移動体通信システムにおいて、ユーザーが使用する携帯電話機２０は、ユーザーによって登録されたアプリケーションプログラムを実行可能な構成を有している。本実施形態において、このアプリケーションプログラムは、プラットフォームに依存しないオブジェクト指向プログラミング等によって開発されたものである。このようなアプリケーションプログラムとしては、ＪＡＶＡ（登録商標。以下同様。）で記述されたアプリケーションプログラム、Ｃ＋＋言語で記述されたアプリケーションプログラム、ＢＲＥＷ（登録商標。以下同様。）のアプリケーション実行環境上で動作するアプリケーションプログラムなどが挙げられる。また、アプリケーションプログラムは、Ｃ言語やアセンブリ言語等で記述された構造化プログラムであってもよい。この携帯電話機２０は、ネットワークとしての携帯電話通信網１０に接続可能である。また、この携帯電話通信網１０には、コンテンツデータを配信するストリーミングサーバ１１が接続されている。このストリーミングサーバ１１は、携帯電話機２０からの要求に応じて、コンテンツデータに基づくストリーミングデータを携帯電話機２０に対して送信する。
【００１６】
ストリーミングサーバ１１で配信されるコンテンツデータは、コンテンツ開発事業者等のコンテンツ開発元から提供される。具体的には、コンテンツが蓄積型コンテンツの場合、例えば、コンテンツ開発元側のパーソナルコンピュータ等から、専用回線や公衆回線を介してストリーミングサーバ１１にアップロードして提供する。なお、その蓄積型コンテンツのデータを記録した光ディスクや磁気ディスク等の記録媒体を、コンテンツ開発元からストリーミングサーバ１１を管理・運営する通信事業者に送り、その記録媒体内のコンテンツデータをストリーミングサーバ１１で読み取るようにして、提供してもよい。このようにして提供された蓄積型コンテンツのデータは、携帯電話機２０から携帯電話通信網１０を介してストリーミング配信可能な状態でストリーミングサーバ１１に登録される。一方、ライブ型コンテンツにおいては、コンテンツ開発元側で撮影したリアルタイムの映像等のデータを、専用回線や公衆回線を介してストリーミングサーバ１１に送信する。このようにして提供されたライブ型コンテンツのデータは、ストリーミングサーバ１１で受信されると同時に携帯電話通信網１０を介して携帯電話機２０へストリーミング配信される。なお、「コンテンツデータ」としては、画像と音を組合せた映画等の映像コンテンツのデータ、音楽等の音のみからなるコンテンツのデータ、画像のみからなるコンテンツのデータなどが含まれる。
【００１７】
図３は、上記ストリーミングサーバ１１のハードウェア構成を示す概略構成図である。
このストリーミングサーバ１１は、システムバス１００、ＣＰＵ１０１、内部記憶装置、外部記憶装置１０４、入力装置１０５及び出力装置１０６を備えている。上記内部記憶装置は、ＲＡＭ１０２やＲＯＭ１０３等で構成されている。上記外部記憶装置１０４は、ハードディスクドライブ（ＨＤＤ）や光ディスクドライブ等で構成されている。上記入力装置１０５は、マウスやキーボード等で構成されている。上記出力装置１０６は、ディスプレイやプリンタ等で構成されている。更に、このストリーミングサーバ１１は、携帯電話通信網１０を介して各ユーザーの携帯電話機２０と通信するための通信手段としての携帯電話用通信装置１０７を備えている。
【００１８】
上記ＣＰＵ１０１やＲＡＭ１０２等の構成要素は、システムバス１００を介して、互いにデータやプログラムの命令等のやり取りを行う。このストリーミングサーバ１１を所定の手順に従って動作させるための各種プログラムは、ＲＯＭ１０３や外部記憶装置１０４に記憶されており、必要に応じてＣＰＵ１０１やＲＡＭ１０２上の作業エリアに呼び出されて実行される。また、このストリーミングサーバ１１には、携帯電話機２０に対して送信するコンテンツデータが外部記憶装置１０４に記憶されている。ストリーミングサーバ１１は、携帯電話機２０からの要求に応じ、ＣＰＵ１０１、ＲＡＭ１０２、携帯電話通信網用通信装置１０７等が協働して、外部記憶装置１０４に記憶されているコンテンツデータを、携帯電話通信網１０を介して携帯電話機２０にストリーミングデータ送信する機能を有している。また、外部記憶装置１０４に記憶されているコンテンツデータを紹介するためのＷｅｂサイトを提供するＷｅｂサーバとしての機能も有している。本実施形態では、携帯電話機２０のユーザーは、コンテンツデータをストリーミング再生しようとする場合、まず、Ｗｅｂサイトにアクセスして再生対象のコンテンツデータを選択し、その後、選択したコンテンツデータに基づくストリーミングデータを受信して再生することになる。なお、このストリーミングサーバ１１は、専用装置として構成してもいいし、汎用のコンピュータシステムを用いて構成してもよい。また、１台のコンピュータで構成してもいいし、複数の機能をそれぞれ受け持つ複数台のコンピュータをネットワークで結んで構成してもよい。
【００１９】
図４は、上記携帯電話機２０の外観を示す正面図であり、図５は、その携帯電話機２０のハードウェア構成を示す概略構成図である。
この携帯電話機２０は、クラムシェル（折り畳み）タイプの携帯電話機であり、システムバス２００、ＣＰＵ２０１、ＲＡＭ２０２やＲＯＭ２０３等からなる内部制御装置、入力装置２０４、出力装置２０５及び携帯電話用通信装置２０６を備えている。ＣＰＵ２０１やＲＡＭ２０２等の構成要素は、システムバス２００を介して、互いに各種データや後述のアプリケーションプログラムの命令等のやり取りを行っている。上記入力装置２０４は、データ入力キー（テンキー、＊キー、＃キー）２１、通話開始キー２２、終話キー２３、スクロールキー２４、多機能キー２５、マイク２６などから構成されている。上記出力装置２０５は、表示手段としての液晶ディスプレイ（ＬＣＤ）２７、通話用スピーカ２８、図示しない外部スピーカ等から構成されている。上記携帯電話用通信装置２０６は、携帯電話通信網１０を介して他の携帯電話機や上記ストリーミングサーバ１１と通信するためのものである。また、ＲＡＭ２０２内には、後述する電話機プラットフォームが管理する第１の記憶手段としてのプラットフォーム用記憶領域と、後述するアプリケーション実行環境上で管理される第２の記憶手段としてのアプリケーション用記憶領域とが存在する。本実施形態において、ＲＡＭ２０２及びＲＯＭ２０３は、データ記憶手段として機能する。
【００２０】
図６は、上記携帯電話機２０の主要部を抽出して示したブロック図であり、図７は、その携帯電話機２０におけるソフトウェア構造の説明図である。
この携帯電話機２０は、電話通信部２１１及びデータ通信手段としてのデータ通信部２１２、操作手段としての操作部２１３、アプリケーションプログラム実行手段としてのアプリケーションプログラム実行管理部２１４、主制御部２１５、出力部２１６等により構成される。
【００２１】
上記電話通信部２１１は、他の携帯電話機や固定電話機と電話通信を行うために、携帯電話通信網１０の基地局と無線通信を行うものであり、上述のハードウェア構成上の携帯電話用通信装置２０６等に対応する。
上記データ通信部２１２は、上記電話通信部２１１と同様に、上述のハードウェア構成上の携帯電話用通信装置２０６等に対応する。このデータ通信部２１２は、携帯電話通信網１０を介して他の携帯電話機とメールのやり取りを行ったり、携帯電話通信網１０からゲートウェイサーバを介して、インターネット等の外部のネットワークに接続し、インターネット上での電子メールのやり取りやＷｅｂページの閲覧等を行ったりするためのものである。また、このデータ通信部２１２は、携帯電話通信網１０を介して、ストリーミングサーバ１１が提供するアプリケーションプログラムをダウンロードするためにも用いられる。
【００２２】
上記操作部２１３は、ユーザーにより操作される上述のテンキー２１、通話開始キー２２、終話キー２３等で構成されている。この操作部２１３の各種キーを操作することにより、ユーザーは、携帯電話機２０に対してＵＲＬ等のデータを入力したり、電話着信の際に通話の開始及び終了を行ったり、アプリケーションプログラムの選択、起動及び停止を行ったりすることができる。また、ユーザーは操作部２１３の各種キーを操作することにより、上記ストリーミングサーバ１１が提供するＷｅｂサイトにアクセスしてコンテンツデータに基づくストリーミングデータを受信してこれを再生することもできる。
【００２３】
上記アプリケーションプログラム実行管理部２１４は、上述のシステムバス２００、ＣＰＵ２０１やＲＡＭ２０２の一部等で構成されている。このアプリケーションプログラム実行管理部２１４は、図７のソフトウェア構造上において中央の「アプリケーション実行環境」に対応しており、オブジェクト指向プログラミングで開発されたアプリケーションプログラムに利用されるクラスライブラリ、実行環境管理ライブラリ、アプリケーション管理等のソフトウェアを提供し、アプリケーションプログラムの実行環境を管理する。このアプリケーション実行環境は、実行するアプリケーションプログラムに応じて適宜選定される。例えば、実行するアプリケーションプログラムがＪＡＶＡで記述されたものである場合には、ＪＡＶＡのアプリケーション実行環境を選定する。また、実行するアプリケーションプログラムがＢＲＥＷの実行環境上で動作するＣ言語で記述されたものである場合には、ＢＲＥＷのアプリケーション実行環境を選定する。なお、実行するアプリケーションプログラムがＪＡＶＡで記述されたものである場合には、ＢＲＥＷのアプリケーション実行環境上に更にＪＡＶＡのアプリケーション実行環境を構築することで、これを実行することができる。
【００２４】
ここで、アプリケーションプログラムは、クラスライブラリＡＰＩ（アプリケーションインターフェース）を介して上記アプリケーション実行環境内にある関数等のクラスライブラリを呼び出して使用できるようになっている。この関数等のクラスライブラリの呼び出しの履歴は、アプリケーションプログラムの仮想的な実行環境（仮想マシン：ＶＭ）が終了するまで、ＲＡＭ２０２内におけるアプリケーション用記憶領域に記憶される。また、アプリケーション実行環境は、アプリケーションプログラムの実行に際して用いる各種データも、そのアプリケーション用記憶領域に保存する。そして、この各種データを用いるときには、このアプリケーション用記憶領域から読み出したり、書き込んだりする。また、アプリケーション実行環境内の実行環境管理ライブラリは、電話機プラットフォームＡＰＩを介して後述の電話機プラットフォーム内の電話機プラットフォームライブラリを呼び出して使用できるようになっている。
【００２５】
上記主制御部２１５は、電話通信部２１１、データ通信部２１２、出力部２１６を制御するものであり、上述のシステムバス２００、ＣＰＵ２０１やＲＡＭ２０２等で構成されている。この主制御部２１５は、アプリケーションプログラム実行管理部２１４との間で制御命令や各種データのやりとりを行い、これと協働して制御を行うことで、制御手段として機能する。主制御部２１５は、図７のソフトウェア構造上において最下部の「電話機プラットフォーム」に対応しており、上記電話通信部２１１等を制御するための制御用プログラムやユーザインターフェースを実行したり、電話機プラットフォームライブラリを提供したりする。この電話機プラットフォームは、上記アプリケーション実行環境内の実行環境管理ライブラリに対してイベントを送ることにより、アプリケーションプログラムにおいて各種処理を実行したり、アプリケーション管理ＡＰＩを介して上記アプリケーション実行環境内のアプリケーション管理のソフトウェアを呼び出して使用したりできるようになっている。また、アプリケーション実行環境が電話機プラットフォームＡＰＩを介して電話機プラットフォームライブラリを呼び出して使用したとき、電話機プラットフォームは、その電話機プラットフォームライブラリに応じた処理を実行する。例えば、電話機プラットフォームは、電話機プラットフォームライブラリを利用したアプリケーション実行環境からの指示に基づき、ＲＡＭ２０２内における電話機プラットフォームが管理するプラットフォーム用記憶領域に記憶されたデータを読み出して、これをアプリケーション用記憶領域に移行することができる。
【００２６】
上記出力部２１６は、上述の液晶ディスプレイ２７、通話用スピーカ２８、外部スピーカ等からなる出力装置２０５等で構成されている。この出力部２１６は、上記データ通信部２１２で受信したＷｅｂページ画面を液晶ディスプレイ２７に表示する。また、この出力部２１６の液晶ディスプレイ２７は、上記電話通信部２１１やデータ通信部２１２で情報を着信した旨をユーザーに報知するときに用いられる。具体的には、その情報を着信すると、主制御部２１５により、出力部２１６の液晶ディスプレイ２７に着信報知画像を表示したり、外部スピーカから着信音を出力させたりする。更に、この出力部２１６は、アプリケーション実行環境で実行される後述のコンテンツ再生用アプリケーションプログラムを実行中には、再生されたコンテンツデータの映像や音などの出力にも用いられる。
【００２７】
携帯電話機２０を所定の手順に従って動作させる電話機プラットフォームを構築するための制御用プログラムは、ＲＡＭ２０２やＲＯＭ２０３に記憶されている。また、基本ＯＳ（オペレーティングシステム）のプログラムや、上記アプリケーション実行環境を構築するためのプログラム及びアプリケーションプログラムも、ＲＡＭ２０２やＲＯＭ２０３に記憶されている。そして、これらのプログラムは、必要に応じてＣＰＵ２０１やＲＡＭ２０２中の作業エリアに呼び出されて実行される。
【００２８】
次に、本発明の特徴部分であるコンテンツデータのストリーミング再生処理について説明する。なお、本実施形態では、画像（動画像）と音とを組合せた映像コンテンツをストリーミング再生する場合について説明するが、他のコンテンツについても同様である。
【００２９】
図１は、コンテンツデータを携帯電話機２０でストリーミング再生する際の携帯電話機２０の処理動作の最初の部分の流れを示すフローチャートである。なお、このフローチャートは、そのコンテンツが蓄積型かライブ型かに関係ない共通処理部分（ストリーミング再生フローの最初の処理部分）を示すものである。
図８は、コンテンツデータを携帯電話機２０でストリーミング再生する際の、再生対象のコンテンツが蓄積型かライブ型かに関係ない共通処理部分の通信手順を示すシーケンスフロー図である。
【００３０】
コンテンツデータを再生しようとする場合、まず、ユーザーは、操作部２１３のキーを操作し、ブラウザを起動する（Ｓ１）。そして、操作部２１３のキーを操作して、ストリーミングサーバ１１のコンテンツ選択サイトのＵＲＬを入力し、アクセスする（Ｓ２）。これにより、ブラウザを実行する主制御部２１５は、そのＵＲＬによって特定されるストリーミングサーバ１１に対してリクエストを送信する。このリクエストを受けたストリーミングサーバ１１は、そのリクエストの送信元である携帯電話機２０に向けて、そのリクエストに係るコンテンツ選択サイトの画面（コンテンツリスト画面）をレスポンスとして送信する。その後、ユーザーは、操作部２１３のキーを操作して、ＬＣＤ２７上に表示された画面のコンテンツリストの中から自分が希望するコンテンツを選択する（Ｓ３）。これを受けて、図７に示した電話機プラットフォームすなわち図６に示した主制御部２１５に、アプリケーションプログラムの実行指示が入力される。これにより、主制御部２１５は、コンテンツ再生用アプリケーションプログラムを読み出してこれを起動する（Ｓ４）。アプリケーションプログラムが起動すると、図７に示したアプリケーション実行環境すなわち図６に示したアプリケーションプログラム実行管理部２１４上で、そのアプリケーションプログラムが動作する。なお、このアプリケーションプログラムは、予め携帯電話機２０のＲＯＭ２０３に記憶されたものでも、外部からダウンロードしてＲＡＭ２０２に記憶されたものでもよい。
【００３１】
アプリケーションプログラムが起動すると、アプリケーションプログラム実行管理部２１４は、上記Ｓ３で選択したコンテンツについて、ストリーミングサーバ１１に対し、そのコンテンツデータを配信するコンテンツ配信サイトへＳＤＰデータ（コンテンツ情報データ）の取得要求を主制御部２１５を介して送信する。本実施形態において、携帯電話機２０とストリーミングサーバ１１との間は、主に、ＲＴＳＰ（Real Time Streaming Protocol）及びＲＴＰ（Real-time Transport Protocol）を用いてデータ通信を行う。したがって、ここでは、ＳＤＰデータの取得要求として、ＤＥＳＣＲＩＢＥコマンドを送信する。ＳＤＰデータの取得要求を受けたストリーミングサーバ１１は、その応答としてＳＤＰデータを携帯電話機２０に送信する。このＳＤＰデータを受信した携帯電話機２０のアプリケーションプログラム実行管理部２１４は、そのＳＤＰデータをＲＡＭ２０２に保存する（Ｓ５）。
【００３２】
このＳＤＰデータには、対応するコンテンツのストリーミングデータを本携帯電話機２０で再生するために携帯電話機側で設定すべき設定項目及び設定内容を示す各種端末設定情報とともに、当該コンテンツの名前（題名）や当該コンテンツの総再生時間などのコンテンツ情報がそれぞれ項目分けして記述されている。本実施形態におけるコンテンツの総再生時間については、ＳＤＰデータ中の総再生時間項目（ａ＝ｒａｎｇｅ：）に記述された再生開始時間と再生終了時間の情報（ｎｔｐ値）である。具体的には、例えば「ａ＝ｒａｎｇｅ：  ｎｔｐ＝０−１８０」というように記述され、この例では「０」が再生開始時間を示し、「１８０」が再生終了時間を示す。
【００３３】
ＳＤＰデータをＲＡＭ２０２に保存した後、アプリケーションプログラム実行管理部２１４は、以後、ライブ型コンテンツに適したライブ型動作モードか、蓄積型コンテンツに適した蓄積型動作モードのいずれの動作モードで動作するかの選択を行う。具体的には、まず、そのＳＤＰデータに含まれる項目の中に、コンテンツの総再生時間情報を記述するための総再生時間項目（ａ＝ｒａｎｇｅ：）があるか否かを判断する（Ｓ６）。この総再生時間項目がないと判断した場合、アプリケーションプログラム実行管理部２１４は、当該コンテンツをライブ型コンテンツとして把握し、その再生を停止させるまで後述するライブ型動作モードで動作することになる。一方、総再生時間項目があると判断した場合、次に、アプリケーションプログラム実行管理部２１４は、その総再生時間項目に、コンテンツの再生終了時間が記述されているか否かを判断する（Ｓ７）。この再生終了時間がないと判断した場合、アプリケーションプログラム実行管理部２１４は、当該コンテンツをライブ型コンテンツとして把握し、その再生を停止させるまで後述するライブ型動作モードで動作することになる。他方、この再生終了時間があると判断した場合、アプリケーションプログラム実行管理部２１４は、当該コンテンツを蓄積型コンテンツとして把握し、その再生を停止させるまで後述する蓄積型動作モードで動作することになる。
【００３４】
このようにして、動作モードの選択を終えたら、アプリケーションプログラム実行管理部２１４は、ＳＤＰデータに含まれる端末設定用の項目を参照し、その設定内容に従ってストリーミングセッション（ストリーミング通信用の接続）の確立要求（ＳＥＴＵＰコマンド）を主制御部２１５を介してストリーミングサーバ１１へ送信する。この要求に応じて、ストリーミングサーバ１１は、本携帯電話機２０との間のストリーミングセッションを確立し、ストリーミングセッションが確立した旨の応答を携帯電話機２０へ送信する。なお、本実施形態では、コンテンツ選択サイトとコンテンツ配信サイトが同じストリーミングサーバ１１によって提供されているが、別々のサーバで提供するようにしてもよい。
【００３５】
〔動作例１〕
次に、ライブ型動作モード及び蓄積型動作モードの処理動作の一例（以下、本例を「動作例１」という。）について説明する。
【００３６】
［ライブ型動作モード］
図９は、本動作例１のライブ型動作モードに係る携帯電話機２０の処理動作の流れを示すフローチャートである。図１０は、本動作例１のライブ型動作モード時の通信手順を示すシーケンスフロー図である。
コンテンツ再生用アプリケーションプログラムが起動すると、ＬＣＤ２７上にコンテンツ再生用画面が表示される。ユーザーが操作部２１３のキーに対してコンテンツを再生するための操作を行うと（Ｓ１１）、アプリケーションプログラム実行管理部２１４は、ストリーミングサーバ１１に対してコンテンツ再生要求（ＰＬＡＹコマンド）を主制御部２１５を介して送信する（Ｓ１２）。このコンテンツ再生要求（ＰＬＡＹコマンド）には、ｒａｎｇｅヘッダは付加されない。このｒａｎｇｅヘッダは、再生開始時間及び再生終了時間の情報（ｎｔｐ値）が記述されるものであって、これを付加するか否かは任意である。このコンテンツ再生要求がストリーミング１１に受信されると、ストリーミングサーバ１１は、この要求を受け付けた旨の応答を携帯電話機２０へ送信する。また、ストリーミングサーバ１１のＣＰＵ１０１は、コンテンツ再生要求に係るライブ型コンテンツについて、現時刻からストリーミングデータの送信を開始する（Ｓ１３）。なお、ここでは、コンテンツ再生要求（ＰＬＡＹコマンド）にｒａｎｇｅヘッダは付加していないが、ｎｔｐ値が「０−」であるｒａｎｇｅヘッダを付加した場合、ｎｔｐ値が「ｎｏｗ−」であるｒａｎｇｅヘッダを付加した場合も、同様である。
【００３７】
携帯電話機２０のアプリケーションプログラム実行管理部２１４は、受信したストリーミングデータをＲＡＭ２０２内の所定のバッファリング領域に順次保存する。そして、規定量のストリーミングデータがバッファリング領域に保存されたら（Ｓ１４）、アプリケーションプログラム実行管理部２１４は、ＲＡＭ２０２内のバッファリング領域からストリーミングデータを順次読み出して再生を開始する（Ｓ１５）。具体的には、アプリケーションプログラム実行管理部２１４は、主制御部２１５を介して、出力部２１６に対してストリーミングデータの再生命令を出力する。これにより、出力部２１６のＬＣＤ２５にはストリーミングデータに基づく画像が表示されるとともに、出力部２１６の外部スピーカからストリーミングデータに基づく音声が出力され、ユーザーは、コンテンツを視聴することができる。
【００３８】
その後、電話通信部２１１を介して主制御部２１５が音声着信等を受けた場合など、コンテンツの再生よりも優先して処理すべき競合イベントが発生した場合（Ｓ１６）、その旨を主制御部２１５から知らされたアプリケーションプログラム実行管理部２１４は、主制御部２１５を介して出力部２１６に対してコンテンツの再生を停止させる命令を出力する。また、アプリケーションプログラム実行管理部２１４は、ストリーミングサーバ１１に対して再生停止要求（ＴＥＡＲＤＯＷＮコマンド）を主制御部２１５を介して送信する。この要求に応じて、ストリーミングサーバ１１は、本携帯電話機２０との間のストリーミングセッションを切断し、ストリーミングセッションを切断した旨の応答を携帯電話機２０へ送信する。
【００３９】
このようにしてコンテンツの再生を中断した後、発生した競合イベントが終了し、そのコンテンツをもう一度再生する場合、ユーザーは、上記と同様に、操作部２１３のキーを操作して、ストリーミングサーバ１１のコンテンツ選択サイトにアクセスし、中断したコンテンツを再び選択する（Ｓ１〜Ｓ３）。この場合も、当該コンテンツはライブ型コンテンツであると把握されるので、上述の場合と同様に、そのコンテンツ再生要求（ＰＬＡＹコマンド）には、ｒａｎｇｅヘッダが付加されない。したがって、コンテンツ再生要求に係るライブ型コンテンツについて、現時刻からのストリーミングデータがストリーミングサーバ１１から携帯電話機２０に対して送信される。
【００４０】
［蓄積型動作モード］
図１１は、本動作例１の蓄積型動作モードに係る携帯電話機２０の処理動作の流れを示すフローチャートである。図１２は、本動作例１の蓄積型動作モード時の通信手順を示すシーケンスフロー図である。
ユーザーが操作部２１３のキーに対してコンテンツを再生するための操作を行うと（Ｓ２１）、アプリケーションプログラム実行管理部２１４は、当該コンテンツに対応する中断箇所特定情報としての再生中断時間情報がＲＡＭ２０２に記憶されているか否かの判断を行う（Ｓ２２）。ここでは、当該コンテンツを本携帯電話機２０で初めて再生するので、当該コンテンツに対応する再生中断時間情報はＲＡＭ２０２内に存在しない。したがって、アプリケーションプログラム実行管理部２１４は、ストリーミングサーバ１１に対し、上記ライブ型動作モードの場合と同様にｒａｎｇｅヘッダが付加されていないコンテンツ再生要求（ＰＬＡＹコマンド）を主制御部２１５を介して送信する（Ｓ２３）。このコンテンツ再生要求がストリーミング１１に受信されると、ストリーミングサーバ１１は、この要求を受け付けた旨の応答を携帯電話機２０へ送信する。また、ストリーミングサーバ１１のＣＰＵ１０１は、コンテンツ再生要求に係る蓄積型コンテンツを外部記憶装置１０４から読み出し、コンテンツの最初からのストリーミングデータを携帯電話機２０に対して送信を開始する（Ｓ２５）。なお、ここでは、コンテンツ再生要求（ＰＬＡＹコマンド）にｒａｎｇｅヘッダは付加していないが、ｎｔｐ値が「０−」であるｒａｎｇｅヘッダを付加した場合も、同様である。
【００４１】
ストリーミングサーバ１１から送信されるストリーミングデータの再生処理については、上記ライブ型動作モードの場合と同様である（Ｓ２６，Ｓ２７）。このコンテンツの再生中に競合イベントが発生した場合（Ｓ２８）、本蓄積型動作モードでは、その旨を主制御部２１５から知らされたアプリケーションプログラム実行管理部２１４は、主制御部２１５を介して出力部２１６に対してコンテンツの再生を停止させる命令を出力するとともに、現時点（中断時点）までのコンテンツ再生時間をＲＡＭ２０２に記憶する（Ｓ２９）。また、アプリケーションプログラム実行管理部２１４は、ストリーミングサーバ１１に対して再生停止要求（ＴＥＡＲＤＯＷＮコマンド）を主制御部２１５を介して送信する。この要求に応じて、ストリーミングサーバ１１は、本携帯電話機２０との間のストリーミングセッションを切断し、ストリーミングセッションを切断した旨の応答を携帯電話機２０へ送信する。
【００４２】
このようにしてコンテンツの再生を中断した後、発生した競合イベントが終了し、そのコンテンツをもう一度再生する場合、ユーザーは、上記と同様に、操作部２１３のキーを操作して、ストリーミングサーバ１１のコンテンツ選択サイトにアクセスし、中断したコンテンツを再び選択する（Ｓ１〜Ｓ３）。この場合も、当該コンテンツは蓄積型コンテンツであると把握されるので、再生指示を受けたら（Ｓ２１）、アプリケーションプログラム実行管理部２１４は、当該コンテンツに対応する再生中断時間情報がＲＡＭ２０２に記憶されているか否かの判断を行う（Ｓ２２）。ここでは、当該コンテンツに対応する再生中断時間情報が上記Ｓ２９においてＲＡＭ２０２内に保存されている。したがって、アプリケーションプログラム実行管理部２１４は、ストリーミングサーバ１１に対し、再生中断時間情報を再生開始時間として含んだｒａｎｇｅヘッダが付加されたコンテンツ再生要求（ＰＬＡＹコマンド）を主制御部２１５を介して送信する（Ｓ２４）。具体的には、上記競合イベントが、コンテンツの最初からの再生が行われてから６０秒が経過したときに発生した場合、コンテンツ再生要求（ＰＬＡＹコマンド）には、「ｒａｎｇｅ：ｎｔｐ＝６０−」というｒａｎｇｅヘッダが付加される。なお、この例では、再生終了時間を省略しているが、ＳＤＰデータの総再生時間項目に記述された再生終了時間（例えば「１８０秒」）も含め、「ｒａｎｇｅ：ｎｔｐ＝６０−１８０」というｒａｎｇｅヘッダを付加してもよい。このコンテンツ再生要求を受信したストリーミングサーバ１１のＣＰＵ１０１は、その要求に係る蓄積型コンテンツを外部記憶装置１０４から読み出し、コンテンツの最初から６０秒後の箇所からストリーミングデータの送信を開始する（Ｓ２５）。
【００４３】
〔動作例２〕
次に、ライブ型動作モード及び蓄積型動作モードの処理動作の他の例（以下、本例を「動作例２」という。）について説明する。
上記動作例１では、コンテンツの再生中断の原因が競合イベントの発生である場合を例に挙げて説明したが、本動作例２では、ユーザーが一時停止操作を行った場合を例に挙げて説明する。なお、上記動作例１と同じ処理部分については、説明を省略する。
【００４４】
［ライブ型動作モード］
図１３は、本動作例２のライブ型動作モードに係る携帯電話機２０の処理動作の流れを示すフローチャートである。図１４は、本動作例２のライブ型動作モード時の通信手順を示すシーケンスフロー図である。
ユーザーがコンテンツ再生中に操作部２１３のキーに対してコンテンツの再生を一時停止するための操作を行うと（Ｓ１６’）、アプリケーションプログラム実行管理部２１４は、主制御部２１５を介して出力部２１６に対してコンテンツの再生を停止させる命令を出力する。また、アプリケーションプログラム実行管理部２１４は、ストリーミングサーバ１１に対して一時停止要求（ＰＡＵＳＥコマンド）を主制御部２１５を介して送信する。この要求に応じて、ストリーミングサーバ１１は、本携帯電話機２０との間のストリーミングセッションを維持しつつ、ストリーミングデータの送信を停止し、その旨の応答を携帯電話機２０へ送信する。
【００４５】
このようにしてコンテンツの再生を中断した後、そのコンテンツをもう一度再生する場合、ユーザーは、一時停止を解除すべく、操作部２１３のキーに対してコンテンツを再生するための操作を行う（Ｓ１１）。これにより、ｒａｎｇｅヘッダが付加されていないコンテンツ再生要求（ＰＬＡＹコマンド）がストリーミングサーバ１１へ送信される。したがって、コンテンツ再生要求に係るライブ型コンテンツについて、現時刻からのストリーミングデータがストリーミングサーバ１１から携帯電話機２０に対して送信される。
【００４６】
［蓄積型動作モード］
図１５は、本動作例２の蓄積型動作モードに係る携帯電話機２０の処理動作の流れを示すフローチャートである。図１６は、本動作例２の蓄積型動作モード時の通信手順を示すシーケンスフロー図である。
ユーザーがコンテンツ再生中に操作部２１３のキーに対してコンテンツの再生を一時停止するための操作を行うと（Ｓ２８’）、本蓄積型動作モードでは、アプリケーションプログラム実行管理部２１４は、主制御部２１５を介して出力部２１６に対してコンテンツの再生を停止させる命令を出力するとともに、現時点（中断時点）までのコンテンツ再生時間をＲＡＭ２０２に記憶する（Ｓ２９）。また、アプリケーションプログラム実行管理部２１４は、ストリーミングサーバ１１に対して一時停止要求（ＰＡＵＳＥコマンド）を主制御部２１５を介して送信する。この要求に応じて、ストリーミングサーバ１１は、本携帯電話機２０との間のストリーミングセッションを維持しつつ、ストリーミングデータの送信を停止し、その旨の応答を携帯電話機２０へ送信する。
【００４７】
このようにしてコンテンツの再生を中断した後、そのコンテンツをもう一度再生する場合、ユーザーは、一時停止を解除すべく、操作部２１３のキーに対してコンテンツを再生するための操作を行う（Ｓ２１）。この再生指示を受けたら、アプリケーションプログラム実行管理部２１４は、当該コンテンツに対応する再生中断時間情報がＲＡＭ２０２に記憶されているか否かの判断を行う（Ｓ２２）。ここでは、当該コンテンツに対応する再生中断時間情報が上記Ｓ２９においてＲＡＭ２０２内に保存されている。したがって、アプリケーションプログラム実行管理部２１４は、上記動作例１の場合と同様に、ストリーミングサーバ１１に対し、再生中断時間情報を再生開始時間として含んだｒａｎｇｅヘッダが付加されたコンテンツ再生要求（ＰＬＡＹコマンド）を主制御部２１５を介して送信する（Ｓ２４）。
【００４８】
以上、本実施形態においては、ライブ型コンテンツのＳＤＰデータは、総再生時間項目（ａ＝ｒａｎｇｅ：）が省略されているか、省略されていなくてもその項目中に再生終了時間が記述されていないことを利用し、再生対象のコンテンツが蓄積型かライブ型かを判別する。そして、再生中断後にそのコンテンツについてもう一度再生操作を受け付けたときには、当該コンテンツが蓄積型の場合にだけ、再生時間情報を含むｒａｎｇｅヘッダを付加したコンテンツ再生要求がストリーミングサーバ１１へ送信される。これにより、蓄積型コンテンツについては、一旦再生を中断した後にこれをもう一度再生する場合でも、その中断時点からコンテンツの再生がされる。しかも、本実施形態では、再生時間情報を含むｒａｎｇｅヘッダを付加したコンテンツ再生要求が、ライブ型コンテンツの再生要求としてストリーミングサーバ１１へ送信されることはない。したがって、ストリーミングサーバ１１がライブ型コンテンツを配信する際に正常動作できない事態の発生が防止される。
【００４９】
なお、上述した実施形態では、ライブ型動作モードの場合、再生中断時には再生経過時間を保存しないように動作する場合について説明したが、蓄積型動作モードと同様に、再生中断時に再生経過時間を保存するように動作させてもよい。この場合でも、ライブ型動作モードでは再開時には常にｒａｎｇｅヘッダが付加されていないコンテンツ再生要求を送信するように動作するため、その再生経過時間に基づく再生時間情報を含んだｒａｎｇｅヘッダを有するコンテンツ再生要求が、ライブ型コンテンツの再生要求としてストリーミングサーバ１１へ送信されることはない。
また、上述した実施形態では、ＳＤＰデータ中の総再生時間項目（ａ＝ｒａｎｇｅ：）の有無と、その項目内の再生終了時間情報の有無の両方について判断し、再生対象のコンテンツがライブ型か蓄積型かを判別する場合について説明したが、いずれか一方の判断だけで判別を行ってもよい。例えば、ライブ型コンテンツのＳＤＰデータでは総再生時間項目（ａ＝ｒａｎｇｅ：）を省略することが、規格によって決められている場合や業界標準となっている場合には、上記Ｓ７の判断を省略し、ＳＤＰデータ中の総再生時間項目の有無だけで、精度よく判別を行うことができる。また、規格上又は業界標準によって、ライブ型コンテンツのＳＤＰデータの総再生時間項目（ａ＝ｒａｎｇｅ：）が省略できない場合には、上記Ｓ６の判断を省略し、その総再生時間項目内の再生終了時間情報の有無だけを判断しても、精度よく判別を行うことができる。
また、本発明は、上述した携帯電話機２０に限らず、ストリーミング再生が可能な他のストリーミング受信再生端末に対しても有用である。
【図面の簡単な説明】
【００５０】
【図１】実施形態における携帯電話機でコンテンツデータをストリーミング再生する際の処理動作の最初の部分（共通部分）の流れを示すフローチャート。
【図２】同携帯電話機が利用可能な移動体通信システムの全体構成を説明するための説明図。
【図３】同移動体通信システムを構成するストリーミングサーバのハードウェア構成を示す概略構成図。
【図４】同携帯電話機の外観を示す正面図。
【図５】同携帯電話機のハードウェア構成を示す概略構成図。
【図６】同携帯電話機の主要部を抽出して示したブロック図。
【図７】同携帯電話機におけるソフトウェア構造の説明図。
【図８】同携帯電話機でコンテンツデータをストリーミング再生する際の共通部部における通信手順を示すシーケンスフロー図。
【図９】動作例１のライブ型動作モードに係る同携帯電話機の処理動作の流れを示すフローチャート。
【図１０】動作例１のライブ型動作モード時の通信手順を示すシーケンスフロー図。
【図１１】動作例１の蓄積型動作モードに係る同携帯電話機の処理動作の流れを示すフローチャート。
【図１２】動作例１の蓄積型動作モード時の通信手順を示すシーケンスフロー図。
【図１３】動作例２のライブ型動作モードに係る同携帯電話機の処理動作の流れを示すフローチャート。
【図１４】動作例２のライブ型動作モード時の通信手順を示すシーケンスフロー図。
【図１５】動作例２の蓄積型動作モードに係る同携帯電話機の処理動作の流れを示すフローチャート。
【図１６】動作例２の蓄積型動作モード時の通信手順を示すシーケンスフロー図。
【符号の説明】
【００５１】
１０  携帯電話通信網
１１  ストリーミングサーバ
２０  携帯電話機
２１  テンキー
２７  液晶ディスプレイ
２１３  操作部
２１４  アプリケーションプログラム実行管理部
２１５  主制御部
２１６  出力部
【図１】
2006094336.tif 000003
【図２】
2006094336.tif 000004
【図３】
2006094336.tif 000005
【図４】
2006094336.tif 000006
【図５】
2006094336.tif 000007
【図６】
2006094336.tif 000008
【図７】
2006094336.tif 000009
【図８】
2006094336.tif 000010
【図９】
2006094336.tif 000011
【図１０】
2006094336.tif 000012
【図１１】
2006094336.tif 000013
【図１２】
2006094336.tif 000014
【図１３】
2006094336.tif 000015
【図１４】
2006094336.tif 000016
【図１５】
2006094336.tif 000017
【図１６】
2006094336.tif 000018