SSブログ

鍵を購入する [オーディオ]

ここ最近の日記の連投で、25年前の記憶が、徐々に蘇ってきた。
昔々、一生懸命PCのパワポで図面を書いて勉強していました。
同じような図面を何枚も何枚も書いたね。


だから脳裏の深いところにしっかりと刻まれているから、絶対忘れられないんですよね。久しぶりに書いてみたら、全然悩むことなくスラスラと10分くらいで書けました。


IBM配信システム Vol.1.jpg




当時、”インターネット音楽配信”と呼んでいた配信ビジネスの黎明期のブロック概念図。インターネットで音楽を配信するなんてどうやるんだ、という手引書みたいなもの。


ネットの配信システムのほうはIBMのシステムで、ユーザーホームネットワークが家電メーカーが提供するというような役割分担。


もう音楽配信ビジネスなんていまのご時世、当たり前のコンコンチキだから、もうこのブロック図は全然秘匿性もないからオープンにしてもよいだろう。


役割分担は、


コンテンツプロバイダ:レーベル(レコード会社)
サービスプロバイダ:配信事業者
第三者機関(クリアリングハウス):著作権権利団体
ユーザホームネットワーク


コンテンツプロバイダは、たとえばこのように複数考えられるだろう。


レーベル1:ソニーミュージック
レーベル2:ビクターエンターティメント
レーベル3:ワーナー・ミュージック
レーベル4:ユニバーサルミュージック
レーベル5:ワーナー・ブラザーズ


などなど多数。


サービスプロバイダは、たとえばこのように複数考えられるだろう。ただし当時は、ファイルダウンロードのみの発想でいまのようにストリーミングはなかったけど(あったとしても地下に潜っていた。)わかりやすく、いまのストリーミング配信事業者を割り付けよう。


配信事業者1:Amazon Music HD
配信事業者2:mora qualitas
配信事業者3:Spotify
配信事業者4:Apple Muisc
配信事業者5:Line Music


などなどこれまた多数。


第三者機関(クリアリングハウス)というのは、いわゆるJASRACのような音楽の著作権を管理する権利団体のようなところが担うものという発想だった。


そしてユーザーホームネットワークである。Gatewayというのは外のインターネットとつながる窓口、ゲートウエイだ。まぁ普通に考えればPC(パソコン)ですね。


まず、コンテンツプロバイダは、クリアリングハウスにコンテンツを提供して、配信用コンテンツをオーサリングする。配信用コンテンツというのは、いわゆる暗号化コンテンツである。ある鍵で暗号をかけ、そして暗号を復号するときはその鍵で復号する。もちろんコンテンツ単位で鍵はひとつひとつ違う。


そしてその暗号化コンテンツにコンテンツIDを付与して、コンテンツDBに格納する。


つぎにサービスプロバイダは、クリアリングハウスから、自分のショップで販売したい配信用コンテンツをよりどり好みでたくさん取り寄せる。


サービスプロバイダというのは、つまり商品の棚に、いろいろなレーベルのいろいろなアーティストのコンテンツを並べる、といういわゆるお店、販売ショップという立場ですね。つまりWEBデザインされた自分のショップのHPにジャケ写を羅列して、展示する、そんな感じです。


サービスプロバイダというのはレーベルのコンテンツを売る販売ショップの方々のことですね。もちろんレーベル自身が売る場合もあるから、そのときはコンテンツプロバイダとサービスプロバイダを兼務することになる。


そしてユーザは自分の好みのサービスプロバイダにサービス登録して、そこからコンテンツを買う。(ユーザーはコンテンツをサービスプロバイダから買います。)


そのとき、ユーザはクリアリングハウスに対して課金決済をして、その暗号化コンテンツを復号化する鍵を購入するわけだ。


”暗号化コンテンツを視聴するために、課金決済してその鍵を購入する。”というのが、システムの大前提の発想だ。


いまの時代の感覚でいえば、ふつうはサービスプロバイダが、こういう課金決済、鍵配信などをやるのがふつうですよね。ユーザーはサービス販売ショップに対して課金決済している感覚のはず。


でもこの当時はJASRACのような著作権権利団体が、こういうクリアリングハウスのようなDB集合体を第三者的な立場で管理して、各々のコンテンツプロバイダ、サービスプロバイダを登録して全体を一元管理するという考え方だったんですよね。


そして課金DBで権利者に対して契約で決まっているパーセンテージで配分率を計算し、その料金をコンテンツプロバイダやサービスプロバイダに利益分配する、という段取り。


これが黎明期のインターネット音楽配信のブロック図だ。


やっぱり黎明期だけあって、古いというか、こなれていないね。(笑)まずJASRACのような著作権権利団体がこんな複雑で大規模なDBを管理できるはずもなし。(笑)


現在は、間違いなくサービスプロバイダの中で、課金決済などの処理を全部完結させてしまうはず。ショップ単位で課金して、権利者に払っているという感じでしょうか。


さもないと、レーベルなんて世界中に存在するわけだし、ネット配信業者だって世界中に乱立している。それをクリアリングハウスで一元管理なんて事実上無理な問題だ。


ペーパー上での理論図と実際のビジネス様態は違う、ということですね。


万が一、クリアリングハウスで一元管理する、としよう。そうするとクリアリングハウス内でコンテンツオーサリングで配信用コンテンツを作成するわけだが、そうなると音声Codecやいっしょに内包するメタデータの形式など、どのサービスプロバイダでも共通になってしまい、サービスの差異化、差別化ができなくなってしまう。おれっちのところはDSD配信に限定とか、おれっちのところはPCM192KHzでしかもなんと32bitだぞ!
というような他社との差別化ができない。やっぱり伝送フォーマットのCodecはサービスに応じてグレード差異化したいですよね。


メタデータだってそうだ。メタデータというのは音楽データの付帯情報などが記載されているデータのことなのだが、ROONのようにこのメタデータの仕掛けでシームレスに検索できるような仕掛けも作るわけだから、このメタデータの作り方でおらっちだけの差別化はしたいはず。


ということで、上の図のクリアリングハウスの中にある数々のDBは、ほとんどサービスプロバイダ自身の中で各々持っていてショップ自身で完結してしまっている、と思っていいと思う。そしてショップ単位で権利者に利益分配しているんだろう。


ちなみにインターネットでの通信では、かならずセキュリティ上、暗号化、認証をおこなって通信する。公開鍵暗号による認証と、共通鍵暗号によるコンテンツ暗号である。


上の図のコンテンツプロバイダ、サービスプロバイダ、クリアリングハウス、ユーザーホームネットワークの間の通路パスでの通信のことである。


クリアリングハウスの中にあるDB集合体。


コンテンツDB
メタデータDB
顧客管理DB
鍵DB
認証DB
個人嗜好DB


はコンテンツ電子データのEC(E-Commerce):電子商取引で最低限必要なDBたちである。


いまのご時世では、サービスプロバイダのそれぞれにこれらのDB集合体を持っていると思われる。この黎明期のときと、いまのご時世の違いといえば、


たとえばいまはファイルダウンロードじゃなく、ストリーミングが主体。そうするとストリーミングの暗号化ってどうやるんだろう。どういう鍵の受け渡しをするんだろう?


そして課金決済も、サブスクリプションである。
定額の少額決済。そうすると再生回数をカウントする必要がある。


それに応じて、再生1回あたり何円と決まっているから、その再生回数に応じて総額が決まり、それを各権利者に利益分配するということだろう。


たしかに時代に流れに応じて、この黎明期の頃から、随分と紆余曲折してきたけれど、でも骨子となる屋台骨、考え方の基本はそんなに違ってないと思うんですよね。


ボクの青春時代の熱中していたテーマでした。


当時は、ネット配信なんて音楽ビジネスの根本を壊すということで、ずいぶん白い目で見られていた。あれから25年経過したわけだが、ものごとがちゃんとモノになるというのはずいぶん時間のかかることだな、とProject Xのオヤジのような想いにふけっています。(笑)



これから新しい取り組みとしては、コンサートホールでのライブストリーミング配信ということになると思われるが、このプラットフォームに合わせると、オーケストラの楽団がコンテンツプロバイダで、ライブストリーミングをするサービスがサービスプロバイダになるのであろうか?ライブストリーミングというビジネスは比較的新しい分野なので、注目だ。





nice!(0)  コメント(0) 

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。