(57)【要約】【課題】配信サーバから複数の端末に情報を配信する場合に、複数のユーザの間で情報のダウンロードにつき公平を図ることができるようにする。【解決手段】配信システムは、インターネットを介して配信サーバおよび複数の端末が接続されて構成される。ユーザＸ，Ｙ，Ｚが、それぞれの端末から、それぞれ３曲（５００円分）、１曲（１５０円分）、７曲（９００円分）の楽曲の購入を同時に申し込んだ場合、配信サーバは、ユーザＺの端末との間の通信速度を最も高速にし、ユーザＸの端末との間の通信速度を中程度とし、ユーザＹの端末との間の通信速度を最も低速にして、それぞれの端末に、それぞれの端末から要求された楽曲データを配信する。【選択図】図４
2005094557.tif 000002
【特許請求の範囲】
【請求項１】
端末からの購入申込に応じて端末に情報を送信する方法であって、
情報の購入額または購入量である購入高が大きいほど段階的または連続的に通信容量を高くするように、購入高に応じて通信容量を変えて情報を送信する配信方法。
【請求項２】
請求項１の配信方法において、
前記購入高は、購入申込時の購入額または購入量とする配信方法。
【請求項３】
請求項１の配信方法において、
前記購入高は、過去の購入実績の購入額または購入量とする配信方法。
【請求項４】
請求項１の配信方法において、
前記購入高は、購入申込時の購入額または購入量に過去の購入実績の購入額または購入量を加味したものとする配信方法。
【請求項５】
端末に配信すべき情報が格納された情報格納手段と、
端末からの購入申込を受信し、前記情報格納手段に格納されている情報を端末に送信する通信手段と、
この通信手段によって端末からの購入申込が受信されたとき、情報の購入額または購入量である購入高が大きいほど段階的または連続的に通信容量を高くするように、購入高に応じて通信容量を変える制御手段と、
を備える配信サーバ。
【請求項６】
請求項５の配信サーバにおいて、
前記制御手段は、購入申込時の購入額または購入量を前記購入高として通信容量を決定する配信サーバ。
【請求項７】
請求項５の配信サーバにおいて、
過去の購入実績の購入額または購入量が記録されたデータベースを備え、
前記制御手段は、このデータベースに記録されている過去の購入実績の購入額または購入量を前記購入高として通信容量を決定する配信サーバ。
【請求項８】
請求項５の配信サーバにおいて、
過去の購入実績の購入額または購入量が記録されたデータベースを備え、
前記制御手段は、購入申込時の購入額または購入量に前記データベースに記録されている過去の購入実績の購入額または購入量を加味したものを前記購入高として通信容量を決定する配信サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ユーザの購入申込に応じて配信元からユーザ側に、音楽データや映像データなどの情報を配信し、ダウンロードする方法および装置に関する。
【背景技術】
【０００２】
インターネットなどのネットワークを利用して、各種のデータやコンピュータプログラムを配信するサービスが普及しつつある。例えば、音楽配信サービスでは、ユーザが、楽曲リスト、楽曲検索機能や、お勧め情報などによって、希望する楽曲を選択し、配信元に購入の申し込みをすると、配信元のサーバからユーザの端末に楽曲データが送信され、楽曲データをダウンロードすることができる。
【０００３】
しかし、このような配信サービスが普及するにつれて、同じ時間に、多くのユーザからの購入申込が集中し、多くのユーザに情報を配信しなければならないことが多くなっている。
【０００４】
そのため、例えば、一度に数曲購入するユーザは、一度に１曲しか購入しないユーザに比べて、ダウンロードに要する時間が数倍になり、多額の代金を支払って多くの楽曲を購入するユーザほど、ダウンロードに時間がかかってしまう結果となる。
【０００５】
特許文献１（特開平１１−３５５３４６号公報）には、データの配信が時間的に集中して配信サーバの負荷が増大するのを避けるため、端末から配信サーバに、配信要求と配信希望時刻の情報を送信し、配信サーバでは、伝送路の状態などに応じて配信予定時刻を決定して端末に通知し、その時刻にデータを配信する方法が示されている。
【０００６】
また、特許文献２（特開平１１−４５２３０号公報）には、複数のサーバと複数のクライアント（端末）とを複数のルータを介して接続するネットワークシステムにおいて、クライアント側で、各サーバから各サーバの送信帯域を示す情報を受信して、ルータに対してサーバの送信帯域を分散させて予約し、その予約した送信帯域のサーバからデータの配信を受けるように構成することによって、サーバが過負荷状態に陥ることなく、かつデータの品質を低下させることなく、データを配信する方法が示されている。
【０００７】
上に挙げた先行技術文献は、以下の通りである。
【特許文献１】特開平１１−３５５３４６号公報
【特許文献２】特開平１１−４５２３０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１または特許文献２に記載された方法でも、同じ時間に同じサーバから多くの端末に配信せざるを得ない場合があり、その場合には、上述したように、一度に数曲購入するユーザは、一度に１曲しか購入しないユーザに比べて、ダウンロードに要する時間が数倍になり、多額の代金を支払って多くの楽曲を購入するユーザほど、ダウンロードに時間がかかってしまう不公平な結果となる。
【０００９】
そこで、この発明は、配信サーバから複数の端末に情報を配信する場合に、複数のユーザの間で情報のダウンロードにつき公平を図ることができるようにしたものである。
【課題を解決するための手段】
【００１０】
この発明の配信方法は、
端末からの購入申込に応じて端末に情報を送信する方法であって、
情報の購入額または購入量である購入高が大きいほど段階的または連続的に通信容量を高くするように、購入高に応じて通信容量を変えて情報を送信するものである。
【００１１】
上記の構成の、この発明の配信方法では、例えば、配信サーバから端末に楽曲データを配信する音楽配信サービスの場合、購入金額または購入曲数もしくは購入データ量が多い端末（ユーザ）に対してほど、通信容量（通信速度）を高くして楽曲データを配信するので、例えば、一度に５００円分または３曲を購入するユーザと、一度に１５０円分または１曲しか購入しないユーザとの間で、例えば、ダウンロードに要する時間が同じになるというように、購入額または購入量が多いユーザほどダウンロードに要する時間が長くなるという不合理・不公平を解消することができ、複数のユーザの間で情報のダウンロードにつき公平を図ることができる。
【発明の効果】
【００１２】
以上のように、この発明によれば、購入高が大きいユーザほどダウンロードに要する時間が長くなるという不合理・不公平を解消することができ、複数のユーザの間で情報のダウンロードにつき公平を図ることができる。また、このように通信容量を変えるので、通信負荷を分散させることもできる。
【発明を実施するための最良の形態】
【００１３】
図１は、この発明の配信方法を実行する配信システムの一例を示す。
【００１４】
この例の配信システムは、インターネット１に配信サーバ２および複数の端末３ｘ，３ｙ，３ｚ…が接続されて構成される。
【００１５】
端末３ｘ，３ｙ，３ｚ…を端末３とすると、この端末３は、例えば、図２に示すように、ＣＰＵ１１を備え、そのバス１２に、プログラムやデータが展開されるメモリ（ＲＡＭ）１３、インターネット１を介して配信サーバ２との間で通信を行う通信部１４、内蔵の記憶装置としてのハードディスク１５をドライブするＨＤＤ（ハードディスクドライブ）１６、各種キーなどからなる操作部１８、液晶ディスプレイなどのディスプレイからなる表示部１９、および再生処理部２１などが接続される。
【００１６】
配信サーバ２からインターネット１を介して配信され、通信部１４によって受信された、圧縮符号化された楽曲データは、ハードディスク１５に記録された後、ハードディスク１５から読み出されて、再生処理部２１で伸長復号され、その復号後の楽曲データが、再生処理部２１でアナログ信号に変換されて、音声増幅回路２２を通じてスピーカ２３に供給されることによって、端末３において配信サーバ２から配信された楽曲を再生することができる。
【００１７】
ただし、再生処理部２１、音声増幅回路２２、スピーカ２３などの再生出力装置は、端末３とは別の装置として端末３に接続されるように構成してもよい。
【００１８】
一方、配信サーバ２は、例えば、図３に示すように、ＣＰＵ３１を備え、そのバス３２に、プログラムやデータが展開されるメモリ（ＲＡＭ）３３、インターネット１を介して端末３との間で通信を行う通信部３４、ソフトウエア格納部３５、データ格納部３６および会員情報データベース３７が接続される。
【００１９】
ソフトウエア格納部３５には、端末３にホームページを提示するためのホームページ提示機構３５ａ、端末３において後述のようにホームページ上でダウンロードボタンが押されたとき、端末３に楽曲データをダウンロードするためのダウンロード機構３５ｂ、および、後述のように端末３との間の通信容量（通信速度）を調整する通信容量調整機構３５ｃなどのソフトウエア（プログラム）が格納される。
【００２０】
データ格納部３６には、ホームページを構成する基本データ３６ａや、配信する楽曲データ３６ｂなどが格納される。
【００２１】
会員情報データベース３７には、会員として当該の配信システムを利用するユーザごとに、ユーザの氏名、年齢、住所、電子メールアドレス、決済情報などの基本的なデータ、ユーザが過去にダウンロードした楽曲のタイトルやジャンル、および、後述のポイント制度のもとでの累計ポイントや残存ポイントなどが、会員データ３７ａとしてデータベース化される。
【００２２】
上述した配信システムでは、ユーザが、端末３で所定のブラウザによって、配信元の楽曲購入用のポータルサイトのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）アドレスを入力すると、配信サーバ２では、ホームページ提示機構３５ａによって、端末３に楽曲購入用のポータルサイトを提示する。
【００２３】
ユーザは、楽曲リスト、楽曲検索機能や、お勧め情報などによって、購入する楽曲を選択して、ダウンロード用のホームページに遷移させる。これによって、端末３の表示部１９には、図４に示すようなホームページが表示される。
【００２４】
具体的に、この場合のホームページ５では、購入曲リスト５ａとして、ユーザが選択した楽曲のタイトルが表示され、合計購入金額５ｂとして、「合計：３曲  ￥５００」などというように購入曲数および購入金額が表示され、その下に、ユーザが購入した楽曲データを一括してダウンロードするためのダウンロードボタン５ｃが表示されるとともに、通信容量表示５ｄとして、「４００円以下は『低』、４０１円から８００円までは『中』、８０１円以上は『高』」というように、合計購入金額に応じて通信容量が変わる旨が表示され、ダウンロード時間５ｅとして、当該の購入の場合に楽曲データのダウンロードに要する時間の目安が表示される。
【００２５】
なお、図４の例は、合計購入金額が５００円であるので、通信容量表示５ｄ中の「￥４０１〜￥８００  中」の欄に対して、該当することを示す矢印５ｆが付されている。
【００２６】
図４のようにホームページ５が表示されている状態で、ユーザがダウンロードボタン５ｃを押すと、配信サーバ２は、通信容量調整機構３５ｃによって、配信サーバ２の全通信容量、そのとき配信サーバ２に接続されていて楽曲データをダウンロードする端末３の総数、それぞれの端末３の通信容量、および、それぞれの端末３（ユーザ）の購入金額をもとに、それぞれの端末３との間の通信容量（通信速度）を決定し、ダウンロード機構３５ｂによって、その決定した通信容量に従って、それぞれの端末３に楽曲データを送信する。
【００２７】
なお、それぞれの端末３の通信容量は、あらかじめユーザが配信サーバ２に会員登録する際に配信サーバ２の会員情報データベース３７に登録され、または楽曲購入時に端末３と配信サーバ２との間の通信によって配信サーバ２で検出されるようにする。
【００２８】
図５に、配信サーバ２および端末３が行う配信ダウンロード処理の一例を示す。
【００２９】
まず、端末３では、ステップ５１で、ユーザの操作によって、上述したように配信サーバ２のポータルサイトのＵＲＬアドレスを入力し、これによって、配信サーバ２では、ステップ６１で、ポータルサイトを提示する。
【００３０】
次に、端末３では、ステップ５２で、表示部１９にポータルサイトを表示し、さらに、ユーザが購入する楽曲を選択することによって、ステップ５３で、ホームページ５に遷移する。
【００３１】
さらに、ステップ５４で、ユーザがホームページ５上のダウンロードボタン５ｃを選択すると、配信サーバ２は、ステップ６４で、上述したように端末３との間の通信容量を調整し、ステップ６５で、その決定した通信容量に従って、端末３に楽曲データを送信する。
【００３２】
端末３では、ステップ５５で、その配信サーバ２から送信された楽曲データを受信し、ハードディスク１５に記録する。
【００３３】
なお、有料の配信サービスに伴う決済処理は、図５では省略したが、ホームページに遷移する前に、または、ダウンロードボタン５ｃが押された後で、かつダウンロードが始まる前に、実行されるようにする。
【００３４】
通信容量（通信速度）の調整は、具体的には、単位時間あたりの送信パケット数を制御することによって行う。
【００３５】
例えば、図６に示すように、端末３ｘのユーザＸが楽曲Ａ，Ｂ，Ｃの３曲を購入し、端末３ｙのユーザＹが楽曲Ｅの１曲のみを購入したとする。合計購入金額は、ユーザＸが５００円、ユーザＹが１５０円とする。
【００３６】
この場合、配信サーバ２は、基本的には、図４に示したホームページ５上の通信容量表示５ｄにあるように、端末３ｘに対しては中程度の通信速度とし、端末３ｙに対しては低速の通信速度とするが、具体的には、配信サーバ２の全通信容量、そのとき配信サーバ２に接続されていて楽曲データをダウンロードする端末３の総数、および、それぞれの端末３の通信容量も考慮して、それぞれの端末３との間の通信速度を決定する。
【００３７】
その結果、図６の例は、端末３ｘとの間の通信速度が端末３ｙとの間の通信速度の３倍にされ、配信サーバ２から端末３ｘに楽曲Ａ，ＢまたはＣのパケットデータＰａ，ＰｂまたはＰｃを３パケット分送信する間に、配信サーバ２から端末３ｙに楽曲ＥのパケットデータＰｅを１パケット分送信する場合である。
【００３８】
これによって、楽曲Ａ，Ｂ，Ｃ，Ｅのデータ量が同じであれば、ユーザＸが購入した楽曲Ａ，Ｂ，Ｃの全データが端末３ｘにダウンロードされるのに要する時間と、ユーザＹが購入した楽曲Ｅの全データが端末３ｙにダウンロードされるのに要する時間とは、同一となる。
【００３９】
実際上、各曲のデータ量は同じでないので、楽曲Ａ，Ｂ，Ｃの全データが端末３ｘにダウンロードされるのに要する時間が、楽曲Ｅの全データが端末３ｙにダウンロードされるのに要する時間より長くなることもあるが、それでも、それぞれの端末３との間の通信速度を同じにする場合に比べて、楽曲Ａ，Ｂ，Ｃの全データが端末３ｘにダウンロードされるのに要する時間を大幅に短縮することができ、購入金額が多いユーザほどダウンロードに要する時間が長くなるという不合理・不公平を解消することができる。
【００４０】
以上の例は、合計購入金額が多いほど通信容量を高くする場合であるが、購入曲数が多いほど通信容量を高くしてもよい。１曲の価格は必ずしも同じではないが、購入曲数が多いほど購入金額も多くなる傾向にあるので、購入曲数を基準に通信容量を決定する場合でも、上述したように購入金額を基準に通信容量を決定する場合と同様の効果が得られる。
【００４１】
さらに、過去の購入実績の購入金額または購入曲数を加味して、または過去の購入実績の購入金額または購入曲数を基準に、通信容量を決定してもよい。以下に、ポイント制度との関連で、その場合の例を示す。
【００４２】
ポイント制度にも、幾つかある。第１は、ある金額を１点として、ユーザの過去の購入実績を記録しておき、所定の点数に達したとき、ユーザに対して無償で商品やサービスを提供する制度である。
【００４３】
この場合、例えば、その商品やサービスの提供と共に、または商品やサービスの提供に代えて、過去の購入実績の点数Ｐｏを加味して通信容量を決定する。具体的に、今回の購入金額をポイントに換算したときの点数をＰｎとすると、ユーザの購入額を、
Ｐ＝Ｋｎ・Ｐｎ＋Ｋｏ・Ｐｏ  …（１）
として、その購入額Ｐを基準に通信容量を決定する。
【００４４】
係数Ｋｎは、Ｋｎ≧０とする。Ｋｎ＝０は、今回の購入金額の点数Ｐｎを加味しないで、過去の購入実績の点数Ｐｏのみを基準に通信容量を決定する場合である。一方、Ｋｏ＝０は、上述した過去の購入実績を加味しない場合であるので、係数Ｋｏは、Ｋｏ＞０とする。
【００４５】
ポイント制度の第２は、ある金額を１点として、ユーザの過去の購入金額の一定割合を今回の購入代金に充当できる制度である。この制度では、例えば、ユーザが、前回初めて１万円分購入したことによって１０００点（千円分）を獲得した状態で、今回千円分購入するときは、蓄積されている１０００点の一部または全部を、今回の千円の購入代金の一部または全部に充当することができる。当然ながら、充当した点数は蓄積ポイントから控除される。
【００４６】
この第２のポイント制度では、過去の購入実績を、どう捉えるかが問題となる。これを残存しているポイントで計ると、購入の都度、残存しているポイントを充当するユーザは、過去の累計の購入金額が多くても、残存ポイントが少なくなるために、通信容量の点で不利益を受けることになる。
【００４７】
そこで、この場合には、例えば、過去の累計の購入金額をポイントに換算したときの点数として累計ポイントを考え、その累計ポイントを加味して通信容量を決定する。具体的に、今回の購入金額の換算ポイントをＰｎとし、過去の累計ポイントをＰｒとし、残存ポイントをＰｓとすると、ユーザの購入額を、
Ｐ＝Ｋｎ・Ｐｎ＋Ｋｒ・Ｐｒ  …（２）
として、その購入額Ｐを基準に通信容量を決定する。
【００４８】
係数Ｋｎは、Ｋｎ≧０とする。Ｋｎ＝０は、今回の購入金額の点数Ｐｎを加味しないで、過去の累計ポイントＰｒのみを基準に通信容量を決定する場合である。一方、Ｋｒ＝０は、上述した過去の購入実績を加味しない場合であるので、係数Ｋｒは、Ｋｒ＞０とする。
【００４９】
なお、今回の購入の際、残存ポイントＰｓの一部または全部を購入代金の一部または全部に充当する場合には、今回の購入によって獲得するポイントＰｕは、購入代金から充当分を控除した残代金の一定割合、例えば１０％となるが、上記の換算ポイントＰｎは、今回の購入金額そのものをポイントに換算したときの点数である。
【００５０】
図７に、具体例を示す。これは、購入金額の１０％がポイントとして認められる場合で、ユーザＸ（端末３ｘ）は、累計ポイントＰｒが５００点（過去の累計の購入金額が５千円）、残存ポイントＰｓが５００点（５００円分、充当可能）であり、ユーザＹ（端末３ｙ）は、累計ポイントＰｒが５０００点（過去の累計の購入金額が５万円）、残存ポイントＰｓが１００点（１００円分、充当可能）であり、ユーザＺ（端末３ｚ）は、累計ポイントＰｒが８０００点（過去の累計の購入金額が８万円）、残存ポイントＰｓが４０００点（４千円分、充当可能）である。
【００５１】
この状態で今回、ユーザＸは、３曲、５００円分を購入し、購入代金全額に残存ポイントを充当するものとし、ユーザＹは、１曲、１５０円分を購入し、残存ポイントを利用しないで（そのまま残して）、購入代金を支払うものとし、ユーザＺは、何も購入しないものとする。今回の購入によって獲得するポイントＰｕは、ユーザＸが０点、ユーザＹが１５点であるが、上記の換算ポイントＰｎは、ユーザＸが５０点、ユーザＹが１５点である。
【００５２】
この場合、ユーザＸの購入額Ｐｘは、
Ｐｘ＝５０×Ｋｎ＋５００×Ｋｒ  …（２ｘ）
であり、ユーザＹの購入額Ｐｙは、
Ｐｙ＝１５×Ｋｎ＋５０００×Ｋｒ…（２ｙ）
である。
【００５３】
今回の購入金額を含むトータルの購入実績の多寡を見る観点から、Ｋｎ＝Ｋｒ＝１とすると、ユーザＸの購入額Ｐｘは、５５０点（５５００円分）となり、ユーザＹの購入額Ｐｙは、５０１５点（５０１５０円分）となる。
【００５４】
したがって、この場合には、配信サーバ２では、図６に示した例とは逆に、ユーザＸの端末３ｘとの間の通信速度を、ユーザＹの端末３ｙとの間の通信速度より速くする。
【００５５】
なお、配信サーバは、物理的に一つのサーバによって構成する必要はなく、端末からの配信要求を受け付けるメインサーバと、端末との間の通信容量を決定し、端末に楽曲データを送信する一つまたは複数のサブサーバとによって構成し、または、端末からの配信要求を受け付け、端末との間の通信容量を決定するメインサーバと、端末に楽曲データを送信する一つまたは複数のサブサーバとによって構成してもよい。この場合、サブサーバについては、ある複数の端末の近くに配置された一つのサブサーバが、その複数の端末に楽曲データを送信するように構成することができる。
【００５６】
また、上述した例は、楽曲データを配信する場合であるが、この発明は、楽曲データに限らず、映像やニュースなどのデータを、またはゲームソフトなどのプログラムを、有料で配信する場合にも適用することができる。
【図面の簡単な説明】
【００５７】
【図１】この発明の配信方法を実行する配信システムの一例を示す図である。
【図２】端末の一例を示す図である。
【図３】配信サーバの一例を示す図である。
【図４】楽曲購入用のホームページの一例を示す図である。
【図５】配信サーバおよび端末が行う配信ダウンロード処理の一例を示す図である。
【図６】通信容量の変え方の一例を示す図である。
【図７】ポイント制度のもとで通信容量を決定する場合の説明に供する図である。
【符号の説明】
【００５８】
主要部については図中に全て記述したので、ここでは省略する。
【図１】
2005094557.tif 000003
【図２】
2005094557.tif 000004
【図３】
2005094557.tif 000005
【図４】
2005094557.tif 000006
【図５】
2005094557.tif 000007
【図６】
2005094557.tif 000008
【図７】
2005094557.tif 000009