JP2009038420A - コンテンツ評価ソフトウェア及びサービス提供システム - Google Patents

Abstract

【課題】本願発明の目的は、ダウンロードしたコンテンツを動作させるソフトウェアにシーンごとの投票機能を与え、視聴者たるユーザが高い評価を与えたコンテンツの特定のシーンがどこかをコンテンツ評価サーバに送信し、逐次更新し、フィードバックすることで、視聴しているコンテンツでいつごろ面白い場面がくるかを事前に知ることができるようにすることにある。
【解決手段】携帯端末４１上では再生されるコンテンツのシーン（再生単位時間）ごとに再生単位時間評価の入力が可能なソフトウェアをインストールする。該携帯端末ではコンテンツ再生中の処理の空き時間等を利用して、入力された再生単位時間評価の集計を行い、コンテンツ配信サーバ１１に集計された自端末内の再生単位時間評価を送信する。複数の端末の再生単位時間評価を一定周期ごとに評価集計サーバ１２は集計し、再生単位時間総合評価データとしてコンテンツ視聴中の各携帯端末に送り返す。
【選択図】図６

Description

本発明は、動画等の配信を行うサーバ側ソフトウェア及びその再生を行う携帯端末側ソフトウェアにおいて、携帯端末側ソフトウェア操作者による評価をサーバ側ソフトウェアに送り返すこと、及びその評価をサーバ側ソフトウェアで集計し、再度配信する技術に関する。

携帯電話機は国内で９０００万台以上普及し、生活基盤のひとつとして認識されている携帯用電子デバイス（携帯端末）である。現在では、回線交換方式による音声データのみならず、パケット交換方式によるデジタルデータのやり取りもごく一般的なものとなってきている。そして、このやり取りされるデジタルデータの一つとして動画データがあげられる。

携帯電話機においてこのような動画データのやり取りを可能にしたのは、Ｗ−ＣＤＭＡ及びＨＳＤＰＡ、ＨＳＵＰＡなどの高速データ通信を想定した通信方式が普及したことによる。これらの通信方式を用いることでデータを逐次送信していくストリーミング再生の実行が可能になる。これによって、ダウンロード直後から動画データを再生することで快適な動画再生環境が整備されたといえる。

上記のような、Ｗ−ＣＤＭＡ等の通信方式の下では、基地局側あるいはサーバ側から端末側への一方向通信だけでなく、端末側から基地局側・サーバ側への通信も可能である。

携帯電話機等に対して蓄積型コンテンツを配信する技術としては、特開２００２−１３３３５２号公報（以下特許文献１）記載の発明があげられる。これは、携帯電話端末から蓄積型コンテンツ（たとえば映像によるニュースなど）をサーバに対して要求し、これを受けてサーバが要求元の携帯電話端末に該コンテンツを送信することが記載されている。
特開２００２−１３３３５２号公報

しかし、受信したデータを逐次再生していくストリーミング再生可能なコンテンツは容量が大きい場合が多い。これは短時間のコンテンツの場合、ストリーミングを行わなくても、全てのデータをダウンロードして、それから再生すればよいからである。

従ってストリーミング再生可能なコンテンツを最初から見ていく場合が多く、コンテンツの途中から見ようとする場合には、不具合な場合が多かった。

本願発明の目的は、この上記の問題を鑑み、ダウンロードしたコンテンツを動作させるソフトウェアにシーンごとの投票機能を与え、視聴者たるユーザが高い評価を与えたコンテンツの特定のシーンがどこかをコンテンツ評価サーバに送信し、逐次更新し、フィードバックすることで、視聴しているコンテンツでいつごろ面白い場面がくるかを事前に知ることができるようにすることにある。これにより、視聴者たるユーザの視聴性を向上させ、より積極的な蓄積型コンテンツの視聴が可能となる。

本発明に関わるソフトウェアは、表示部を有する携帯端末上で動作し、サーバに対して携帯端末における単位再生時間評価を出力すると共に、サーバから配信されるコンテンツ及び該コンテンツの単位再生時間総合評価を表示部上で再生表示し、携帯端末の表示部に表示する表示面には、コンテンツを表示する動画再生部と単位再生時間総合評価を表示する評価表示部を含み、コンテンツ及び単位再生時間総合評価を受信するコンテンツ受信モジュールと、コンテンツを表示面に、単位再生時間総合評価を評価表示部に表示するコンテンツ再生モジュールと、コンテンツ再生中、コンテンツ評価の入力を受け付ける評価入力モジュールと、入力されたコンテンツ評価から単位再生時間評価を生成する自端末評価集計モジュールと、単位再生時間評価をサーバに送信する単位再生時間評価送信モジュールを含むことを特徴とする。

このソフトウェアは、評価表示部には単位再生時間総合評価を時間的な変化が把握できるよう表示することを特徴としても良い。

このソフトウェアは、単位再生時間評価は２値以上の評価であることを特徴としても良い。

本発明に関わるサービス提供システムは、多数の携帯端末の要求に応じてコンテンツ及び該コンテンツの単位再生時間総合評価を出力すると共に、多数の携帯端末から送信される単位再生時間評価を受信し該コンテンツの単位再生時間総合評価を生成するものであって、携帯端末の要求に応じて該コンテンツのデータ及び該コンテンツの単位再生時間総合評価を要求・取得し逐次携帯端末に送信するとともに、送信される単位再生時間評価を受信するコンテンツ配信サーバと、送信される単位再生時間評価を一定周期で集計し該コンテンツの単位再生時間総合評価を作成するとともに該コンテンツの単位再生時間総合評価を出力する評価集計サーバを含むことを特徴とする。

本発明の適用により、コンテンツのシーンごと、コマごとに感想を付加することができ、各シーン、各コマの他の視聴者の反応を知ることができる。たとえば、単位再生時間総合評価を時間的な変化で把握できるような評価表示部と連動した、コンテンツの早送り、巻き戻しなどの機能を利用し、反応の高いシ−ンだけを拾い読みするような視聴スタイルが可能になる。この応用により、各シーンとそのシーンに出ている場所や人物、商品などを関係付けることにより、それらの人気度調査が可能になったり、感想が多く付加されているシーンを切り出し、サムネイル表示したり、あるいは、それらのシーンをつなぎあわせ長尺の動画を短く編集するなどが容易に実現可能になる。

また、感想の評価集計期間を区切ることで、同一コンテンツにおける年代ごとの人気シーンの違いなどを把握することが可能となり、視聴者の好みの推移を分析するマーケティングツールとしても利用可能である。

以下図を用いて本発明の実施の形態を説明する。

（第１の実施の形態）
図１は本発明の実施の形態におけるサービス提供システムの構成を表す概略図である。

本図の構成では、サービス提供者側の環境としてヴューワ・アプリケーション提供サーバ１０、コンテンツ配信サーバ１１、評価集計サーバ１２より構成される。これらの３つのサーバはそれぞれ分散して構築することも、１つのサーバ中に一括して構築することも可能であるが、本願発明においては実際の構成は特にこだわらない。以下、これら３つのサーバをサービス提供システムという。

また、携帯電話事業者のネットワーク及びそれに接続するまでのネットワークである網２１、無線制御局３１、３１´、無線基地局３２を包括して事業者網と称呼する。

さらに実際にユーザがコンテンツ再生を行う携帯端末４１、４２が存在する。

ヴューワ・アプリケーション提供サーバ１０は、各携帯端末の求めに応じて端末上で動作するヴューワ・アプリケーションを提供するサーバである。実際の送信処理等については既存の技術（ＨＴＴＰなど）を使用しているため、本書においてはヴューワ・アプリケーション提供サーバ１０関連の技術の説明は省略する。

コンテンツ配信サーバ１１は各携帯端末からの求めに応じて、コンテンツを送信するサーバである。この際、本願発明においては音声データ及び動画像データよりなるコンテンツを別個にストリーミング方式で逐次送信する。

評価集計サーバ１２は各携帯端末から寄せられる評価を集計し、コンテンツ配信サーバ１１に送付するサーバである。

網２１は既述の通り、携帯電話事業者のネットワーク及びそれに接続するまでのネットワークである。

無線制御局３１、３１´は携帯端末のハンドオーバ等の制御を行う携帯事業者側の設備である。また、無線基地局３２は実際に携帯端末との送受信を無線経路で行う携帯事業者側の設備である。これらについても本願発明では既存の技術を用いており、説明は省略する。

携帯端末４１、４２はヴューワ・アプリケーション提供サーバ１０より送付されたヴューワ・アプリケーションを実行し、コンテンツ配信サーバ１１から配信されるコンテンツを表示する端末である。

携帯端末４１、４２はヴューワ・アプリケーション提供サーバ１０から送信されるヴューワ・アプリケーションが動作すればよく、こちらも通常のハードウェアから構成されていれば良い。一般的に、ヴューワ・アプリケーションはＪＡＶＡ（登録商標）バイトコード等で記述されていると考えられるが、それらが動作すればよい。

図２は、ヴューワ・アプリケーション提供サーバ１０、コンテンツ配信サーバ１１、評価集計サーバ１２の内部構成の模式図である。以下図２を用いてサーバの内部構成に付いて説明する。

基本的に、これらのサーバの構成は一般のサーバ用コンピュータ（ないしはその相当品）で動作することを想定しており、ハードウェアの構成上特記することは無い。これらのサーバはバス７で互いに接続された、ＣＰＵ１、メモリ２、ＨＤＤ３、入力部４、ネットワークＩＦ５、表示部６より構成される。

ＣＰＵ１はサーバ内の動作の制御を行う中央処理制御部である。

メモリ２はサーバ動作のための一時的な記憶領域を確保するための揮発性メモリのことである。

ＨＤＤ３は不揮発性のハードディスクドライブ、又はその相当品である。近年ではフラッシュＲＯＭ等をハードディスクドライブの代替品として使うことも多いが、本発明においてもそのような代替品の使用に障害は無い。

入力部４はマウス、キーボードと言った入力装置、または、フロッピー（登録商標）ディスクドライブ等の外部記憶の接続環境全般を意味する包括的な概念である。この図では直接入力装置がＣＰＵ１の接続されているバス７につながっているが、実際にはバスブリッジを介して接続されている場合が多い。

ネットワークＩＦ（インターフェイス）５はサーバ外部の機器と接続するためのネットワークインターフェイス部である。

表示部６は、サーバの状態を表すためのＬＣＤ等の表示部である。

次に、携帯端末４１、４２上でヴューワ・アプリケーションを動作させたときに、その端末の画面表示がどのようになるか、図３を用いて説明する。

図３はヴューワ・アプリケーション実行時の携帯端末４１、４２の様子を示す概観図である。

この携帯端末は大きく画面５０と操作部６０から構成される。さらに、操作部６０中にはスクロールキー６１を含む。

図４は、このスクロールキー６１の拡大図である。スクロールキー６１には４方向または８方向へのスクロールを可能とする方向キーだけでなく、確定キー６２も含まれる。

ヴューワ・アプリケーション動作時の画面５０の表示は大きく分けると、動画再生部５１、投票ボタン部５２、評価表示部５３に分けられる。

動画再生部５１はコンテンツ配信サーバ１１より送信されたコンテンツを再生した際にその動画像を表示するエリアである。

投票ボタン部５２は現在再生中のコンテンツの１シーンが高評価若しくは低評価である場合に、操作者によって評価をされるソフトウェアキーである。実際の操作は端末４１、４２の操作部のスクロールキー６１によって、投票ボタン部５２の「好き」もしくは「嫌い」にカーソル（図中の黒枠）が合わされる。いずれかにカーソルがあった状態で、確定ボタン６２を押下すると、その評価が該携帯端末中のメモリに蓄積される。

評価表示部５３は、評価集計サーバ１２からコンテンツ配信サーバ１１を経由して送られる該コンテンツの評価結果を可視的に表示する箇所である。図３ではグラフで表示されているが、特にこの形式にこだわるものではない。

なお、図５のように「好き」から「嫌い」に切り替えたとき、評価表示部５３もそれに応じた表示になるようにすべきである。ただし、必ずしもこれにこだわらず、常時「好き」「嫌い」について表示するようにしても良い。

また、図では携帯端末として、携帯電話を想定しているが、必ずしもこれには限らない。たとえばＰＤＡなどに適用しても問題は無い。

次に、本発明の実施に際し、携帯端末４１、コンテンツ配信サーバ１１、評価集計サーバ１２でどのような処理がなされるかについて図６を用いて説明する。図６はこれらの間でのデータのやり取りを示すシーケンスチャートである。なお、本図においてはデータの流れだけ捉えており、いわゆるＳｙｎｃパケット、Ａｃｋパケットといった制御用パケットは省略する。

まず、携帯端末４１から希望するコンテンツのダウンロード要求がコンテンツ配信サーバ１１に対して送信される（ステップＳ１００１）。これを受け、コンテンツ配信サーバ１１は要求を受けたコンテンツの評価を自身のＨＤＤ３から読み出す。

コンテンツ配信サーバ１１は単位時間総合評価データとコンテンツデータ（動画データ＋音声データ）を、逐次携帯端末４１に送信する（ステップＳ１００２＆ステップＳ１０３０）。本図では単位時間総合評価データの送信をステップＳ１００２として破線で表し、一方、コンテンツデータの送信をＳ１０３０として実線で表す。実装上は動画データと音声データは異なるタイミングで要求し、異なるデータストリームとして受信する。このように、コンテンツデータは既述の通りストリーム再生に対応したものであり、そのデータは連続して送信されるため、図面では「Ｓ１０３０」の記載を一部省略している。

該コンテンツの単位時間総合評価データを受領すると、携帯端末４１の評価表示部５３に、該コンテンツのコンテンツダウンロード要求時点での最新の評価結果が可視的に表示される。また、携帯端末４１は、コンテンツデータを一定量バッファリングを行い、視聴可能な形にまとめコンテンツの再生を開始する（ステップＳ１００３）。

コンテンツの再生が開始されると、携帯端末４１の操作者は投票ボタン部５２を介してコンテンツのシーン毎の評価を行うことが可能になる（ステップＳ１００４）。このとき、逐次携帯端末４１のＣＰＵ（中央処理装置）が、この評価が「好き」「嫌い」のいずれにあたるか、また再生開始（ステップＳ１００３）からどの程度の時間が経過しているか（再生経過時間）を単位再生時間評価として自端末内のメモリに記憶する。このステップＳ１００４の処理は投票ボタン部５２で選択されたボタンと確定ボタン６２の押下が行われるごとに処理される。

ある程度の時間が経過すると又はステップＳ１００４の記録件数（記録容量）が蓄積されると、あるいは受信しているコンテンツ（及びその単位時間総合評価データ）の処理に関する負荷が軽くなると、現在蓄積中の単位再生時間評価の集計を行い、端末評価データを生成する（ステップＳ１００５）。その後、端末評価データをコンテンツ配信サーバ１１に送信する形式（端末評価送信データ）に情報源符号化を行う。

この端末評価送信データは、コンテンツ配信サーバ１１へコンテンツの取得要求を行うと共に、コンテンツ配信サーバ１１に送信する（ステップＳ１００６）。この端末評価送信データの送信は、ステップＳ１００６のようにコンテンツ取得要求を行うタイミングとは別に、負荷の軽いタイミング等で送信することも可能である。端末側からの送信データ容量に制限が有る場合もあり、一度に送信できる量を測りながらどのタイミングで送信するかは設計事項である。

コンテンツ配信サーバ１１は、受領した端末評価送信データを評価集計サーバ１２に送信する（ステップＳ１００７）。この際、複数の端末から送られてくる自端末送信データを一括して送信するか、あるいは、逐次送信するかは設計事項である。

一方、評価集計サーバ１２のＣＰＵ１においては、受領した端末評価送信データから端末評価データを抽出し、評価集計サーバ１２のＨＤＤ３に格納する（ステップＳ１０１０）。ただし、この抽出、格納の過程はステップＳ１００７において、コンテンツ配信サーバ１１が端末評価送信データを抽出し、評価集計サーバ１２に送信し、ステップＳ１０１０では評価集計サーバ１２のＨＤＤ３に格納するステップだけで代替することも可能で、これは設計事項の範囲となる。

評価集計サーバ１２では一定周期ごとに、あるいは投票総数などに応じ負荷が高くならない一定の決められた条件などで、受信した端末評価送信データを集計する（ステップＳ１０２０）。評価集計サーバ１２から見れば、複数の携帯端末から端末評価送信データは送信されてくるが、これらをまとめて、単位時間総合評価データを生成する。

ステップＳ１０２０の評価後、評価集計サーバ１２はコンテンツ配信サーバ１１に集計した該コンテンツの単位時間総合評価データを送信する（ステップＳ１０２１）。これにより、コンテンツ配信サーバ１１のＨＤＤ３に記録されるコンテンツの評価は絶えずアップデートされることになり、ステップＳ１００２での携帯端末４１への評価の送信に際しても最新の評価が渡ることとなる。

コンテンツ配信サーバ１１は該評価対象のコンテンツを視聴している全ての携帯端末に対し、携帯端末４１からコンテンツのダウンロード要求を受け、時間当たりの送信データ密度の低いタイミング、例えば音声データが送信されているタイミング、等で、最新のコンテンツの単位時間総合評価データを送信する（ステップＳ１００２）。この評価を受領すると携帯端末は評価表示部５３の表示を更新し、操作者に対して該コンテンツのシーンごとの全視聴者の関心度を定量的に表示する。

図７は第１の実施の形態におけるコンテンツ再生中にステップＳ１００４に関わる操作が携帯端末４１、４２上で行われた際に、どのように携帯端末４１、４２のメモリに記憶されるかの一例を表す説明用の概念図である。

この図では再生期間１秒を５つのコマ（単位再生時間）に分割している（ここでは各コマを分割シーンと呼称）。そして、このコマ単位でメモリ中にどのような操作がなされたか記録する。

具体的に本図では、３番目の分割シーケンスで携帯端末４１の「好き」ボタンが１回、押下されている。ここで、また、１４番目で「好き」ボタンが３回押下されている。ここで「押下」とは図６でいう、単位再生時間評価の入力（ステップＳ１００４）のことである。

同様に、３番目及び１６番目の分割シーケンスで携帯端末４１の「嫌い」一度ずつ、押下されている。

本願発明の第１の実施の形態に関わるヴューワ・アプリケーションはこの分割シーンごとに評価を記録する。具体的には上記の例では、
＃３：０
＃６：１
＃１４：０
＃１４：０
＃１４：０
＃１６：１
と言った形で経時的に携帯端末自身のメモリに再生単位時間ごとの評価（再生単位時間評価）が格納される。ここで１つのデータは２つの項目で構成されており、１番目の項目が分割シーンの番号、２番目がコンテンツ評価の内容（この実施例では「好き」か「嫌い」か）である。なお、ここでは「好き」を０、「嫌い」を１で表している。このまとめられたデータが既述の端末評価データであり、このデータが情報源符号化の対象となる。

ここでは、コンテンツ評価の内容を２値的なデータとして表現しているが必ずしもこれには限られない。またデータの項目数も、ここでは２つとしているがこれに限定されるものではない。実際の項目数は実装上必要に応じて変化する設計事項である。

図６のステップＳ１００５では、携帯端末のＣＰＵがこれらの情報を送信可能な形式に編集する。

なお、ここでは「好き」「嫌い」といった２値的な評価を上げたが、必ずしもこれには限らない。たとえば、５段階評価なども入力手段（投票ボタン部５２のボタン表示の複数化など）を確保すれば適用可能である。

次に、ステップＳ１０２０に関わる受信評価の集計及びステップＳ１０１２に関わるコンテンツ配信サーバ１１から携帯端末４１、４２に送られるコンテンツの評価（再生単位時間総合評価データ）のデータ形式について説明する。

ヴューワ・アプリケーションでは、その実行されている端末の情報だけ管理すればよいが、評価集計サーバ１２では多数の端末の情報が集中する。たとえば、携帯端末４１からは、上述の説明であげた、
＃３：０
＃６：１
＃１４：０
＃１４：０
＃１４：０
＃１６：１
が送信され、一方携帯端末４２からは
＃４：０
＃６：１
＃１４：０
が送られたとする。この場合、評価集計サーバ１２のＨＤＤ３中で一定期間保持された後、評価集計サーバ１２のＣＰＵ１が以下のように集計する（ステップＳ１０１０）。

＃３：０：１
＃４：０：１
＃６：１：２
＃１４：０：４
＃１６：１：１
すなわち、サーバ側では、１つのデータは３つの項目から構成される。すなわち、１番目の項目が分割シーンの番号、２番目が評価の内容であることは端末側と違いは無いが、３番目の項目として、評価の入力回数が追加される。なお、端末側のデータ同様このデータも設計仕様により評価が２値的以上のもの、データの構成項目が３つ以外であっても良い。

この方式だと累積期間が長い、または視聴端末数が多い、と評価の累積量も多くなり、すぐに変数の多くが上限に達する。

よって、評価の入力側と、評価の集計側のスケールの違いに対応すべく、所定の期間に評価集計期間を制限する等の対応が必要である。

また、各携帯端末上では、相対的な評価が分かればよい。従って、集計後に各携帯端末の評価表示部５３の表現形式に合わせて投票結果が表現できるような形式にデータを調整して各携帯端末にデータを送信できることが重要である。例えば、投票結果をグラフで表示する場合、分割シーンごとの投票集計数の最大数をグラフの縦軸の高さの１００％として表現し最大数以下の投票数を０%から１００%の範囲内で相対的に割り当てるような手法が考えられる。

（第２の実施の形態）
本発明の第２の実施の形態を説明する。第２の実施の形態は、各携帯端末のデータの管理方法をより軽減するように変更する点にある。

図８は本願発明の第２の実施の形態における、コンテンツ再生中にステップＳ１００４に関わる操作が携帯端末４１、４２上で行われた際に、どのように携帯端末４１、４２のメモリに記憶されるかの一例を表す説明用の概念図である。なお、入力条件は図７と同一のものとすることで理解しやすいようにしている。

第２の実施の形態では、評価の入力（ステップＳ１００４）を再生開始（ステップＳ１００３）からの時間でデータ管理する点に特徴がある。すなわち第１の実施の形態では、再生中のコマ数で管理していた。これに対し、本実施の形態では、時間により管理する。

すなわち、本願発明の第２の実施の形態に関わるヴューワ・アプリケーションは評価入力時の再生開始時間からの経過時間を基準として端末評価送信データを記録する。この際は以下の形式で格納される。

０．００４５：０
０．０１１０：１
０．０２６５：０
０．０２７０：０
０．０２７５：０
０．０３１０：１
ここで端末評価送信データの１番目の項目は入力時間（再生開始からの相対時間）であり、２番目の項目は評価の内容である。なお、評価の内容については第1の実施の形態と同様であるので、説明は省略する。

そして、コマに割り当てることなく、携帯端末４１はコンテンツ配信サーバ１１にこの端末評価送信データを送信する。

コンテンツ配信サーバ１１経由で上記データを受け取った評価集計サーバ１２のＣＰＵ１は、上記データに記録された時間から該当するコマ数ごとに入力された回数を割り出す。すなわち、評価集計サーバ１２で上記データは以下のように変換される。

＃３：０：１
＃６：１：１
＃１４：０：１
＃１４：０：１
＃１４：０：１
＃１６：１：１
このデータの構成は第１の実施の形態の評価集計サーバ１２のもの同様、１番目の項目が分割シーンの番号、２番目の項目が評価の内容、３番目の項目が評価の入力回数、である。

そしてこのデータを以下のように集計し、データの圧縮を図る。

＃３：０：１
＃６：１：１
＃１４：０：３
＃１６：１：１
評価集計サーバ１２のＣＰＵ１は、送信される全ての端末評価送信データを変換・圧縮する。その後、評価集計サーバ１２のＨＤＤ３中で一定期間保持された後、評価集計サーバ１２のＣＰＵ１が集計する。

これにより、各携帯端末での負荷が軽減できる。また、配信する携帯端末の処理能力に差があり、この処理能力に応じて同一のコンテンツに複数種類のデータ（たとえば１５ｆｐｓ用、３０ｆｐｓ用と６０ｆｐｓ用（ｆｐｓ＝ｆｒａｍｅ ｐｅｒ ｓｅｃ））を用意する場合でも、サーバ側で評価を一元管理し、各種のデータに評価を水平展開することが容易となる。

（第３の実施の形態）
第３の実施の形態は第２の実施の形態の変形である。

すなわち、第２の実施の形態では、受信した端末評価送信データごとにコマの割り当てをサーバで行い、その後、複数端末から送信されるコマの割り当てが終わった複数の端末評価送信データを集計するやり方が取られていた。

第３の実施の形態では、受信した端末評価送信データを変換することなく評価集計サーバ１２のＨＤＤ３に保存する。これにより、変換処理に関する処理回数を低減することを思慮する。

以下具体例を説明する。なお、本実施の形態は第２の実施の形態の変形であることから、端末評価送信データは第２の実施の形態のそれに順ずる。

携帯端末４１から、以下のような端末評価送信データが送信されたとする。

０．００４５：０
０．０１１０：１
０．０２６５：０
０．０２７０：０
０．０２７５：０
０．０３１０：１
同様に携帯端末４２からは以下のような端末評価データが送信されたものとする。

０．００７０：０
０．０１３０：１
０．０２７０：０
これらを受信した際、評価集計サーバ１２のＣＰＵ１は自身のＨＤＤ３に以下のようにデータを格納する。

０．００４５：０
０．０１１０：１
０．０２６５：０
０．０２７０：０
０．０２７５：０
０．０３１０：１
０．００７０：０
０．０１３０：１
０．０２７０：０
すなわちＣＰＵ１はこの時点では単純にデータの結合のみを行ってＨＤＤ３に格納する。

ステップＳ１０１０により集計を開始する際に、あわせてコマの割り当てを行う。この際のコマの割り当ては、以下の様になされる。

＃３：０：１
＃６：１：１
＃１４：０：１
＃１４：０：１
＃１４：０：１
＃１６：１：１
＃４：０：１
＃６：１：１
＃１４：０：１
これを、コマごとマージすることで、
＃３：０：１
＃４：０：１
＃６：１：１
＃６：１：１
＃１４：０：１
＃１４：０：１
＃１４：０：１
＃１４：０：１
＃１６：１：１
となる。評価集計サーバ１２のＣＰＵ１は、このマージ後のものを集計し、以下のようなデータにする。

＃３：０：１
＃４：０：１
＃６：１：２
＃１４：０：４
＃１６：１：１
このように集計することで、評価集計サーバ１２側での処理対象、コマの割り当てやマージに関する処理呼び出し回数の減少が図れる。これにより、各携帯端末側だけでなく評価集計サーバ１２の処理も軽減される。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲、例えば、携帯端末側で分割シーンごとの集計を行い、サーバ側の集計負荷軽減を行ったり、あるいは携帯端末側では分割シーンごとの投票数の累計数だけを持ち、サーバ側に最終値をオフセット値として送ることで、サーバ側で前回からの差分を投票数として認識したりするなどして送信データの容量を軽減するなど、種々変更が可能であることは言うまでもない。

本実施の形態の説明では、コンテンツ配信サーバ１１が配信するコンテンツが動画であることを想定して説明したが、必ずしも動画にはこだわらない。複数の静止画をパッケージにしたコンテンツや、音楽に関わるコンテンツであっても本発明の適用は可能である。

本発明の実施の形態におけるサービス提供システムの構成を表す概略図である。 各サーバの内部構成を表す模式図である。 ヴューワ・アプリケーション実行時の携帯端末の様子を示す概観図である。 スクロールキー６１の拡大図である。 画面を切り替えたときの携帯端末の表示部の変化を表す図である。 本発明の実施の形態におけるシーケンスチャートである。 携帯端末上での評価入力時の記録形式を説明するための概念図である。 携帯端末上での評価入力時の記録形式を説明するための別の概念図である。

符号の説明

１…ＣＰＵ、２…メモリ、３…ＨＤＤ、４…入力部、５…ネットワークＩＦ、
６…表示部、１０…ヴューワ・アプリケーション提供サーバ、
１１…コンテンツ配信サーバ、１２…評価集計サーバ、２１…網、
３１、３１´…無線制御局、３２…無線基地局、４１、４２…携帯端末、
５０…画面、５１…動画再生部、５２…投票ボタン部、５３…評価表示部、
６０…操作部、６１…スクロールキー、６２…確定キー

Claims (4)

1. 表示部を有する携帯端末上で動作し、サーバに対して前記携帯端末における端末評価データを出力すると共に、前記サーバから配信されるコンテンツ及び該コンテンツの単位再生時間総合評価を前記表示部上で再生表示するソフトウェアであって、
   前記携帯端末の前記表示部に表示する表示面には、前記コンテンツを表示する動画再生部と前記単位再生時間総合評価を表示する評価表示部を含み、
   前記コンテンツ及び前記単位再生時間総合評価を受信するコンテンツ受信モジュールと、
   前記コンテンツを前記表示面に、前記単位再生時間総合評価を前記評価表示部に表示するコンテンツ再生モジュールと、
   前記コンテンツ再生中、単位再生時間評価の入力を受け付ける評価入力モジュールと、
   入力された前記単位再生時間評価から前記端末評価データを生成する自端末評価集計モジュールと、
   前記端末評価データを前記サーバに送信する単位再生時間評価送信モジュールを含むことを特徴とするソフトウェア。
2. 請求項１記載のソフトウェアにおいて、前記評価表示部には前記単位再生時間総合評価を時間的な変化が把握できるよう表示することを特徴とするソフトウェア。
3. 請求項１記載のソフトウェアにおいて、前記単位再生時間評価は２値以上の評価であることを特徴とするソフトウェア。
4. 多数の携帯端末の要求に応じてコンテンツ及び該コンテンツの単位再生時間総合評価を出力すると共に、多数の携帯端末から送信される端末評価データを受信し該コンテンツの単位再生時間総合評価を生成するサービス提供システムにおいて、
   前記携帯端末の要求に応じて該コンテンツのデータ及び該コンテンツの前記単位再生時間総合評価を要求・取得し逐次前記携帯端末に送信するとともに、送信される前記端末評価データを受信するコンテンツ配信サーバと、
   １又は２以上の携帯端末から送信された前記端末評価データを一定周期で集計し該コンテンツの前記単位再生時間総合評価を作成すると共に、該コンテンツの前記単位再生時間総合評価を出力する評価集計サーバを含むことを特徴とするサービス提供システム。

Images