(57)【要約】      （修正有）【課題】デジタル音楽コンテンツを、携帯無線コンピューティング装置にダウンロードし且つ使用するこが可能な、無線コンピューティング装置を提供する。【解決手段】無線コンピューティング装置上で実行するアプリケーションは、エンドユーザの入力なしで無線装置と関連するパラメータに自動的に適応されている。このアプリケーションは、エンドユーザが無線ネットワークを使用してリモートサーバ上の音楽コンテンツを閲覧及び探索し、無線ネットワークを使用してリモートサーバから音楽コンテンツをダウンロードし且つそのダウンロードした音楽コンテンツを再生及び管理することを可能にする。アプリケーションは、加入サービスが終了していない限り、装置への種々の音楽トラックの無制限の合法的なダウンロードを可能にし且つ装置に格納されたトラックのうち任意のトラックの再生を可能にするデジタル権利管理システムを更に含む。【選択図】図７１
2014195274.tif 000002
【特許請求の範囲】
【請求項１】
デジタル音楽コンテンツを携帯無線コンピューティング装置にダウンロードし、使用することを可能にする方法であって：
（ａ）エンドユーザの入力なしで前記無線装置と関連するパラメータに自動的に適応されたソフトウェアアプリケーションを前記無線コンピューティング装置上で実行するステップと；
（ｂ）無線ネットワークを使用してリモートサーバ上の音楽コンテンツを閲覧及び探索し、前記無線ネットワークを使用して前記リモートサーバから音楽コンテンツをダウンロードし且つ前記ダウンロードした音楽コンテンツを再生及び管理することを、前記アプリケーションがエンドユーザに可能にするステップと；
（ｃ）加入サービスが終了していない限り、前記装置への種々の音楽トラックの無制限の合法的なダウンロードを可能にし且つ前記装置に格納された前記トラックのうち任意のトラックの再生を可能にするデジタル権利管理システムを前記アプリケーションが含むステップと
を備えることを特徴とする方法。
【請求項２】
前記デジタル権利管理システムは、前記加入サービスが終了した場合でも音楽トラックが依然として再生可能であるように前記音楽トラックの購入を可能とすることを特徴とする請求項１記載の方法。
【請求項３】
前記加入サービスのための課金インフラストラクチャは、前記無線ネットワークを制御するネットワークオペレータにより提供される前記課金インフラストラクチャの一部であることを特徴とする請求項１又は２記載の方法。
【請求項４】
前記無線装置と関連する前記パラメータは、前記無線装置の製造業者及び機種により異なることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記パラメータは、Ｊａｖａの特定のバージョンを規定することを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記パラメータは、実現されたＪａｖａプラットフォームの特定の部分を規定することを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記パラメータは、オペレーティングシステム及びファームウェアのリリースを規定することを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記パラメータは、前記装置を提供した特定のモバイルネットワークオペレータを規定することを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記パラメータは、画面の大きさ、画素数、色の深み、キーボード制御、ソフトキー特性のうち１つ以上を含む前記装置の物理特性を規定することを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
前記パラメータは、前記装置の計算能力を規定することを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記パラメータは、前記装置上のオーディオ、写真、ビデオ及びアニメーションを含むＪａｖａを介して示されるメディアファイル及び形式の集合を規定することを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記パラメータは、前記装置のメモリの制限を規定することを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記パラメータは、前記装置のオペレーティングシステムが対処できるメディアファイル及び形式の集合を規定することを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
前記パラメータは、前記装置がネットワーク接続を処理する方法を規定することを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
【請求項１５】
前記パラメータは、ＣＳＤ、ＧＰＲＳ、２Ｇ、２．５Ｇ、３Ｇ、ＷＡＰ、ＳＭＳ、Ｂｌｕｅｔｏｏｔｈ、赤外線、ＷｉＦｉ、ＷｉＭＡＸのうち１つ以上を含む前記装置のネットワーク化能力及び処理を規定することを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
【請求項１６】
前記携帯無線装置は移動電話であることを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
【請求項１７】
前記移動電話は２．５Ｇ装置であることを特徴とする請求項１６記載の方法。
【請求項１８】
前記移動電話は３Ｇ装置であることを特徴とする請求項１６記載の方法。
【請求項１９】
前記アプリケーションは、各々が前記アプリケーションの基本的な機能と関連付けられる複数のユーザ選択可能なタブを示すグラフィカルユーザインタフェースを提示することを特徴とする請求項１乃至１８のいずれか１項に記載の方法。
【請求項２０】
各タブは、前記アプリケーションが実行中は常に可視であることを特徴とする請求項１９記載の方法。
【請求項２１】
１つのタブは、全ての入手可能なコンテンツ及び探索機能へのアクセスを可能にするホーム機能と関連付けられることを特徴とする請求項１９又は２０記載の方法。
【請求項２２】
１つのタブは、選択された場合、現在再生中のトラックの詳細を与えることを特徴とする請求項１９乃至２１のいずれか１項に記載の方法。
【請求項２３】
１つのタブは、選択された場合、コミュニティ及びニュース機能へのアクセスを可能にすることを特徴とする請求項１９乃至２２のいずれか１項に記載の方法。
【請求項２４】
１つのタブは、選択された場合、聴くか、あるいはダウンロードするトラックの現在のキューを表示することを特徴とする請求項１９乃至２３のいずれか１項に記載の方法。
【請求項２５】
前記アプリケーションは、状況依存の「more」メニュー項目を複数の画面が示すグラフィカルユーザインタフェースを提示し、選択された場合には現在選択されている項目と現在表示されている画面との少なくともいずれかに関連する更なる機能へのアクセスを可能にすることを特徴とする請求項１乃至２４のいずれか１項に記載の方法。
【請求項２６】
前記アプリケーションは、マルチタスク状況依存のジョイスティックを使用して制御されることを特徴とする請求項１乃至２５のいずれか１項に記載の方法。
【請求項２７】
前記ジョイスティックの特定の機能は、その上の画面上のアイコンにより示されることを特徴とする請求項２６記載の方法。
【請求項２８】
前記ジョイスティックの操作は、前記キーパッドの数字キーを代用して実現されることを特徴とする請求項２７記載の方法。
【請求項２９】
数字キー５は上、０は下、７は左、９は右の操作にそれぞれ対応することを特徴とする請求項２８記載の方法。
【請求項３０】
前記アプリケーションは、「新しいアーティストを取得する」のと等価な機能がメニューにおいて「アーティスト」と同一レベルにある、状況に適した取得機能を提供することを特徴とする請求項１乃至２９のいずれか１項に記載の方法。
【請求項３１】
「新しい曲を取得する」のと等価な機能は、メニューにおいてアーティストのトラックのメニューリストと同一レベルにあることを特徴とする請求項３０記載の方法。
【請求項３２】
前記アプリケーションは、無線接続された他の携帯無線装置が時間的に同期して同一の音楽トラックを再生するように、１つの装置がマスタ再生装置としての役割を果たすことを可能にすることを特徴とする請求項１乃至３１のいずれか１項に記載の方法。
【請求項３３】
前記無線接続は、Ｂｌｕｅｔｏｏｔｈ等の近距離無線接続であることを特徴とする請求項３２記載の方法。
【請求項３４】
前記アプリケーションは、現在再生中のトラックを示す前記再生画面に常に切り替える専用「再生」数字キーを提供することを特徴とする請求項１乃至３３のいずれか１項に記載の方法。
【請求項３５】
前記アプリケーションは可変のタイムアウトを提供し、種々の画面は種々のタイムアウトを有することを特徴とする請求項１乃至３４のいずれか１項に記載の方法。
【請求項３６】
探索画面に戻ることはないことを特徴とする請求項３５記載の方法。
【請求項３７】
前記アプリケーションは、前記エンドユーザの再生の習慣に応じてフィルタリングされた対象のニュースを表示することを特徴とする請求項１乃至３６のいずれか１項に記載の方法。
【請求項３８】
前記アプリケーションは詳細なエンドユーザリスニングデータを追跡し、リモートサーバにフィードバックすることを特徴とする請求項１乃至３７のいずれか１項に記載の方法。
【請求項３９】
前記データは、トラックが聴かれた時間の長さを含むことを特徴とする請求項３８記載の方法。
【請求項４０】
前記データは、スキップされたトラック及びスキップされた時期を含むことを特徴とする請求項３８記載の方法。
【請求項４１】
前記データは、前記装置上にローカルにキャッシュされ、いずれ行なわれる通信を介してピギーバックとしてサーバに送出されることを特徴とする請求項３８乃至４０のいずれか１項に記載の方法。
【請求項４２】
前記ユーザが設定時間を越えてダウンロードしていない場合にのみ、前記装置は、いずれ行なわれると推測される通信を待たずにデータを先に送出し返すことを特徴とする請求項４１記載の方法。
【請求項４３】
前記データは、前記装置上に表示する音楽トラック推奨を提供する音楽推奨エンジンを充実させるために使用されることを特徴とする請求項３８乃至４２のいずれか１項に記載の方法。
【請求項４４】
前記アプリケーションは共有プレイリストを表示することを特徴とする請求項１乃至４３のいずれか１項に記載の方法。
【請求項４５】
前記アプリケーションは、ユーザにより生成されたプレイリストチャートを表示することを特徴とする請求項１乃至４４のいずれか１項に記載の方法。
【請求項４６】
前記アプリケーションの全ての機能は、音楽再生中に利用可能であることを特徴とする請求項１乃至４５のいずれか１項に記載の方法。
【請求項４７】
再生中に利用可能な前記機能は、ニュースの取得、並びに音楽トラックの探索、閲覧及び取得を含むことを特徴とする請求項４６記載の方法。
【請求項４８】
デジタル音楽コンテンツをダウンロードし、使用することを可能にする携帯無線コンピューティング装置であって：
（ａ）前記無線装置上で実行され、エンドユーザの入力なしで前記無線装置と関連するパラメータに自動的に適応されたソフトウェアアプリケーションを具備し、
（ｂ）前記アプリケーションは、無線ネットワークを使用してリモートサーバ上の音楽コンテンツを閲覧及び探索し、前記無線ネットワークを使用して前記リモートサーバから音楽コンテンツをダウンロードし、かつ、前記ダウンロードした音楽コンテンツを再生及び管理することを、エンドユーザに可能にし、
（ｃ）前記アプリケーションは、前記装置への種々の音楽トラックの無制限の合法的なダウンロードを可能にし、かつ、加入サービスが終了していない限り前記装置に格納された前記トラックのうち任意のトラックの再生を可能にするデジタル権利管理システムを含む
ことを特徴とする携帯無線コンピューティング装置。
【請求項４９】
デジタル音楽コンテンツを携帯無線コンピューティング装置にダウンロードし、使用することを可能にするソフトウェアアプリケーションであって、
（ａ）前記無線装置上で実行し、エンドユーザの入力なしで前記無線装置と関連するパラメータに自動的に適応されたソフトウェアアプリケーションであって：
（ｂ）前記アプリケーションは、無線ネットワークを使用してリモートサーバ上の音楽コンテンツを閲覧及び探索し、前記無線ネットワークを使用して前記リモートサーバから音楽コンテンツをダウンロードし、かつ、前記ダウンロードした音楽コンテンツを再生及び管理することを、エンドユーザに可能にし；
（ｃ）前記アプリケーションは、加入サービスが終了していない限り、前記装置への種々の音楽トラックの無制限の合法的なダウンロードを可能にし、かつ、前記装置に格納された前記トラックのうち任意のトラックの再生を可能にするデジタル権利管理システムを含む
ことを特徴とするソフトウェアアプリケーション。
【請求項５０】
請求項４９記載のソフトウェアアプリケーションを使用してダウンロードされた音楽トラック。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタル音楽コンテンツを携帯無線コンピューティング装置にダウンロードし且つ使用することを可能にする方法に関する。本発明の明細書で使用される用語「携帯無線コンピューティング装置」は、双方向無線通信機能を有する任意の種類の携帯装置を範囲に含むように広範に解釈されるべきであり、無線電話、移動電話、スマートフォン、通信機、パーソナルコンピュータ、コンピュータ及び特定用途向け装置を含むがそれらに限定されない。携帯無線コンピューティング装置は、ＧＳＭ（登録商標）又はＵＭＴＳ、ＣＤＭＡ及びＷＣＤＭＡ（登録商標）移動無線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩｒＤＡ等の任意の種類のネットワークを介して任意の方法で通信可能な装置を含む。
【背景技術】
【０００２】
過去数年間に音楽の配信及び購入方法が大きく変化してきている。消費者が物理的製品を店で購入し、それを自宅で聴くという従来の方法は衰退し、音楽業界の世界的な収益は、２０００年の４００億ドルから２００５年の３１０億ドルに僅かに落ちている。その間に、インターネットを介するデジタル音楽の配信が急増した。最初は不法なファイル共有の形式であったが、最近は有償のダウンロードが益々増加している。AppleのiPodO等の携帯デジタルオーディオプレーヤ（ＤＡＰ）は、地球規模の音楽市場に非常に大きな影響を与えてきた。最初の携帯デジタルオーディオプレーヤが投入されてからたった５年で、世界でのデジタル音楽の売り上げは２００５年で既に５０億ドルを優に超えるまでに成長した。
【０００３】
それら傾向を逆転させるために、音楽レーベルは、音楽が移動電話（又は他の種類の携帯無線装置）を介して販売され且つセルラ無線ネットワークを介して配信されるモバイル市場を探求することに現在関心を向けている。潜在的な価値は、着メロ（登録商標）市場の爆発的な成長から既に明らかであり、音楽レーベル及びモバイルネットワークオペレータＭＮＯは、モバイル向けフルトラック音楽がＰＣ上でのデジタル音楽と比較してより多くの収益をもたらし、より良いセキュリティを提供し且つ価格が向上すると確信している。
【０００４】
移動電話は、iPod及び他のＤＡＰと比較していくつかの明かな利点を有する。音楽の再生の他に、移動電話は、益々高速でセキュリティ保護された無線ネットワークに接続され、ユーザは、移動中に音楽を特定及び共有し、ＭＮＯの組み込まれた便利な課金機能を使用してコンテンツの支払いを行なえる。益々増加しているモバイルハンドセットの製造業者による革新は、市場の進歩を助長している。
【０００５】
しかし、今後、更に大きな課題がある。フル音楽コンテンツを販売する主な手段であるモバイルインターネット技術ＷＡＰ（無線アプリケーションプロトコル）に依存するのには限界がある。その技術は、ユーザにとって使用しづらく、速度が遅く且つ煩雑である。実際に、世界最大の移動電話グループであるVodafone Globalは、ＷＡＰがエンドユーザにとって困難であるため、最新の３Ｇ電話以外の電話へのフル音楽ダウンロードの販売を回避している。多くの他のオペレータも同様の対処法を取らざるを得なくなっている。これにより、フル音楽ダウンロードサービスの購入率は制限されており、少数の移動電話加入者のみが３Ｇを使用又は３Ｇにアクセスできる。相対的に成熟した２００５年の英国の市場においては、Vodafoneの１，４４０万人の顧客のうち５０万人未満が３Ｇを有しており、市場浸透率は約３％である。多くの他のオペレータの３Ｇの浸透率は、０であるか又は非常に限定される。
【０００６】
ＭＮＯは、現在の最新の３Ｇハンドセット上であっても可能な音楽再生体験が乏しいことについて関心を持っている。装置が最新の音楽電話として販売された場合でも、一般にそれら装置は平凡なＭＰ３プレーヤと同様のユーザ体験を配布できない。
【０００７】
現在、ＷＡＰを使用するフル音楽コンテンツの取得方法が２つ支持されている：
・ユーザのハンドセットにストリームされる個人専用の無線サービスをユーザに提供するストリームサービス
・移動電話上でローカルに実行し、音楽トラック及びアルバムを移動電話から直接購入できる機能をユーザに提供するミュージックショップアプリケーション
しかし、ストリーミング無線解決策は隙間市場である。常時データ接続の要求及びユーザが聴く音楽の完全なユーザ制御の欠如は、消費者の申し込み及び人気が制限されることを意味する。また、ストリーミング解決策は、制限されるハンドセットの使用範囲及び高速（通常、３Ｇ）データ接続の要求により悪影響を受ける。そのようなサービスを実現するオペレータは、ネットワークの大きな負担に対して計画及び投資する必要がある。これは、全ての音楽トラックが再生される度に再ダウンロードされる必要があるためである。
【０００８】
ミュージックショップアプリケーションは、更にユーザの申し込みの関心を引くが、３Ｇ及び隙間的なSymbianのハンドセットを重視することにより制限されるハンドセットの使用範囲の悪影響を受ける。現在、そのような装置上でのユーザ体験は、トラックサービス毎に限定された支払いを請求する競合会社の製品及び高品質のＤＡＰの音質に近づけない限定された機能性により限定される。相対的に小型の音楽カタログと組み合わされるこの限定された機能性は、現在までにそれら解決策の魅力を非常に限定してきた。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明は、ユーザが携帯無線コンピューティング装置上で音楽を容易に取得し、聴き且つ管理することを可能にする十分に発達した信頼性のある便利な解決策を提供する。
【課題を解決するための手段】
【００１０】
一実現例は、MusicStation（登録商標）と呼ばれる。MusicStationは、デジタル音楽コンテンツを携帯無線コンピューティング装置にダウンロードし且つ使用することを可能にする方法を提供する。方法は：
（ａ）エンドユーザの入力なしで無線装置と関連するパラメータに自動的に適応されたソフトウェアアプリケーションが無線装置上で実行するステップと；
（ｂ）エンドユーザが無線ネットワークを使用してリモートサーバ上の音楽コンテンツを閲覧及び探索し、無線ネットワークを使用してリモートサーバから音楽コンテンツをダウンロードし、ダウンロードした音楽コンテンツを再生及び管理することをアプリケーションが可能にするステップと；
（ｃ）加入サービスが終了していない限り、装置への種々の音楽トラックの無制限の合法的なダウンロードを可能にし且つ装置に格納されたトラックのうち任意のトラックの再生を可能にするデジタル権利管理システムをアプリケーションが含むステップとから成る。
【発明の効果】
【００１１】
本発明は、ユーザがデジタル音楽を取得し且つ聴く方法を実際に変形できる可能性がある。本発明は、共に動作する複数の技術を初めて組み合わせ、各部の合計より非常に優れた総合的な解決策を提供する。例えば、アプリケーションがエンドユーザの入力なしで無線コンピューティング装置と関連するパラメータに自動的に適応されるため、非常に多くの携帯無線装置にアプリケーションを自動的に提供することが実行可能になる（例えば、単純に正確な携帯無線装置の製造及び機種番号をリモートサーバに与えることにより、販売の前か又はユーザがアプリケーションをダウンロード及びインストールするのを可能にする前に）。例えば移動電話のインストールされた基盤は、数億とまではいかなくても容易に数千万に達するだろう。これは、ＤＡＰよりはるかに大きい。また、アプリケーションにより、エンドユーザは無線ネットワークを使用してリモートサーバ上の音楽コンテンツを閲覧及び探索し、無線ネットワークを使用してそのリモートサーバから音楽コンテンツをダウンロードし、そのダウンロードした音楽コンテンツを再生及び管理できる。従って、インストールされた基盤がＤＡＰ解決策に非常に勝るだけでなく、機能性は、無線ネットワークを介して新しい音楽を装置から直接探索及び取得できるため任意のＤＡＰより優れているだろう（これは、デスクトップマシンを使用してウェブのオンラインカタログを介して音楽を取得し且つその後ＤＡＰをデスクトップマシンと同期させるより非常に自然な処理である）。最後に、アプリケーションは、加入サービスが終了していない限り、装置への種々の音楽トラックの無制限の合法的なダウンロードを可能にし且つ装置に格納されたトラックのうち任意のトラックの再生を可能にするデジタル権利管理システムを含む。これにより、ユーザは以前よりはるかに効果的に新しい音楽を調査でき、メモリコストが急速に安価になっているため平均的な装置にも数千個の音楽トラックを格納できる。頑強なＤＲＭモデル、インストールされた大きなユーザ基盤、並びに新しい音楽の調査及び取得の容易さのために、音楽会社は入手可能な音楽のカタログ全体を作成しようとするだろう。これにより、より多くのより優れたコンテンツがより多くのユーザを引きつけ、それがより多くのコンテンツを引きつけて、前向きな反応が得られる。
【００１２】
MusicStationは、競合会社と比較して多くの重要な利点を有する：
・全ての音楽機能を含む包括的で理解し易いユーザ体験。
【００１３】
・ソフトウェアアプリケーションが略全ての音楽対応ハンドセット（機種又は製造業者に関係なく）で実行し、それらハンドセットの全てにおいて実質的に同一に見え且つ同様に動作することを保証するデバイス適応アーキテクチャ（ＤＡＡ−更なる詳細は以下を参照）によって得られる他の競合会社より広範な種類のハンドセットとの互換性。
【００１４】
MusicStationは、移動電話の利点を最大限にする。音楽が自宅でのみ入手可能であるＤＡＰと異なり、MusicStationのユーザは新しい音楽をどこでも発見し入手できる；
・MusicStationは、動作させるのにＰＣ、ブロードバンド、iTunes又はクレジットカードを必要としない。
【００１５】
・MusicStationは、ＡＹＣＥ（ダウンロードし放題−すなわち無制限のダウンロード）、並びに友人を作ること及びプレイリストを共有すること等のユーザコミュニティ機能のように革新的な新しいモデルをサポートする。
MusicStationの製品
MusicStationは、非接続デジタルオーディオプレーヤ（ＤＡＰ）の後継である移動電話を大量に採用することを可能にする重要な使用可能な技術となるように設計されている。成功を確実にするために、設計／開発チームは、次世代の大衆市場音楽製品を配布するために以下の重要な要求を重視してきた。
【００１６】
・最良のＤＡＰに勝るユーザ体験
移動電話上での従来のプレーヤは、最良のＤＡＰと比較すると劣っていた。MusicStationは、市場の主要なＤＡＰと同等に完全であり且つ接続された装置の利点に対しても最適化されたインタフェースを提供する。
【００１７】
・接続性の利点を最大限に活用
移動電話は「略常に接続された」（ＡＡＣ）装置であるため、ハンドセットを使用した音楽製品は、インターネット接続されたＰＣに物理的に接続されている時だけでなく、移動中にも音楽を直接購入することを可能にできる。
【００１８】
・ＰＣへの非依存を保証
組み込みハンドセット製品は、ユーザがブロードバンド接続ＰＣを有することを全く必要としない。これは、一般に移動電話のユーザがそのような技術を利用できず且つ実際にクレジットカードを利用できない市場を発展させる際に特に重要である。ユーザは、ＰＣにアクセスできる場合、机上であっても移動中であっても音楽及びプレイリストにアクセス可能であるべきである。しかし、パーソナルコンピュータ、ブロードバンド又はクレジットカード技術に依存すべきではない。
【００１９】
・直接課金が可能
モバイル音楽アプリケーションは、消費者とＭＮＯとの課金の関係に影響を与えられるべきである。コンテンツの購入に対して更に便利なワンタッチ課金方法を提供することにより、すなわち場所に関係なく、音楽の売り上げは、特に机上でウェブを使用するクレジットカードアプリケーションと比較して、携帯装置との困難な同期要求を必要とする煩雑な登録処理を使用して実際に最大限にされる。
【００２０】
・無線で聴くことが可能
ハンドセット上の音楽アプリケーションは、多くのモバイルハンドセットで利用可能なＢｌｕｅｔｏｏｔｈ機能性を使用して、音楽を再生し且つ無線ヘッドフォン、車載ステレオ及びハイファイシステム等の他のＢｌｕｅｔｏｏｔｈ対応装置と共有することを可能にする必要がある。
【００２１】
・毎日１日２４時間の使用可用性の利用
移動電話は、１日２４時間毎日ユーザと共に存在する可能性の高い電子装置であるため、音楽を聴いたり、購入したり又は管理するための消費者対話に対してはるかに広範な機会を与える。従って、音楽アプリケーションは、初めてハンドセット機能性を探求している時に偶然発見した加入者に対しても魅力的で且つ使用が容易なように設計されることが重要である。
【００２２】
・ユーザへのコミュニティ機能の提供
略常に接続される（ＡＡＣ）装置として、移動電話は移動中にコミュニティ対話機能を配布でき、それは、共有されたプレイリスト及びユーザにより生成されたプレイリストチャートにおいて消費者による音楽の発見を改善するために重要である。これは、未接続のＤＡＰに対する重要な利点である。
【００２３】
・偶発的なハンドセットロードマップの最大限の利用
殆どのハンドセットは、ＭＮＯ又は製造業者により音楽電話として積極的に宣伝又は販売促進していない場合でもＱ１ ２００７により音楽対応となるだろう。潜在的な収益を最大にするために、任意の音楽アプリケーションは、製造業者に関わらず２．５Ｇ又は３Ｇである全ての音楽対応ハンドセットに対して利用可能であるべきであり、初めてＭＮＯが大衆市場の機会としてフルダウンロード音楽を考慮することを可能にする。
【００２４】
MusicStationは、それら重要な要求を中核に設計された。その結果、実際に殆どの音楽対応ハンドセットを「スーパーＤＡＰ」にすることができる。重要なことは、MusicStationがＤＡＰの全ての性能及びユーザ体験品質を与え（音楽の再生及び管理に関して）、ＰＣに基づく主要なオンライン音楽店の閲覧、探索、取得、プレイリスト及び有名人のプレイリスト機能の全てを提供することである。更に、MusicStationは同種のコミュニティ機能を音楽ユーザに提供し、それにより音楽発見処理、並びに個人専用のニュース及びビュー（いずれもＤＡＰ上で利用可能ではない）を改善できる。
【００２５】
他の重要な機能は以下を含む：
・全ての音楽の再生／プレイリストの管理／コンテンツの取得／ニュース／コミュニティ機能性を含むユーザが理解しやすい単一のインタフェース。
【００２６】
・音楽の再生中に利用可能な全ての機能の可用性（ニュースの取得、探索／閲覧等）。
【００２７】
・お気に入りのコンテンツの知的キャッシングを可能にする高度な並列ダウンロード技術。
【００２８】
・組込みネットワークアウェアネス（機能及びインタフェースは、利用可能なネットワーク接続性のレベルに依存して知的に適応される−３Ｇ／２．５Ｇ／０Ｇ）。
【００２９】
・直接課金の統合化（クレジットカード又は口座に対する要求なしで非常に便利なワンタッチ課金を可能にする）−加入サービスに対する課金インフラストラクチャは、無線ネットワークを制御するネットワークオペレータにより提供される課金インフラストラクチャの一部である。
【００３０】
・ＤＲＭによる業界標準の音楽ファイル保護。加入サービスが終了してもトラックが依然として再生可能であるように、ＤＲＭは音楽トラックの購入を可能にする。
【００３１】
MusicStationは、ＤＡＰとは異なり接続アプリケーションであるため、ダウンロードし放題（ＡＹＣＥ）の週毎又は日毎の加入パッケージを初めてハンドセットから直接提供できる。ＡＹＣＥの加入者毎の平均的な音楽収益は、従来のＰＰＴ（トラック毎に支払う）ユーザからの収益より実質的に高いという証拠が多く存在する。現在までの殆どのＡＹＣＥの実現例は、接続された移動装置で販売されることではなく、デスクトップを使用する加入である。
デバイス適応アーキテクチャ（ＤＡＡ）
現在までのモバイルアプリケーションの最大の問題の１つは、新しいハンドセットにアプリケーションを移植すること、並びに複数のハンドセット製造業者及び機種にわたり動作するアプリケーションを配布することの困難さであった。この課題を解決することは、MusicStationが対処する最も重要な技術的問題のうちの１つである。デバイス適応アーキテクチャ（ＤＡＡ）はその解決策である。
【００３２】
実質上、ＤＡＡにより、MusicStationは競合会社より多くの移動電話に展開されることが可能になる。更にMusicStationは、各例において製造業者及びハンドセットの機種別のアプリケーションバージョンを作成することにより、数週間又は数ヶ月ではなく数時間で新しいハンドセットに移植されるのが可能になる。
【００３３】
ＤＡＡを利用するまで、音楽専用又はより一般化されたアプリケーションであっても、全てのモバイルアプリケーションは制限されたハンドセットの使用範囲の悪影響を受けた。典型的な妨害は以下を含む：
・ハンドセット設計／記憶容量の製造業者毎の相違
・ＯＳ及びファームウェアリリース及び関連するバグ
・画面の大きさ、画素数、色の深さ、キーパッド制御及びソフトウェアキーの相違
・物理的な大きな
・メディアファイル及び形式のサポート（例えば、オーディオ、写真、ビデオ、アニメーション）
・Ｊａｖａ（登録商標）のバージョン及びプラットフォーム実現例の差
・ハンドセット別セキュリティモデル
・接続処理及び機能
・公開された仕様に準拠できない
・計算馬力及び他の計算資源
・メモリ
・ＣＳＤ、ＧＰＲＳ、２Ｇ、２．５Ｇ、３Ｇ、ＷＡＰ、ＳＭＳ、Ｂｌｕｅｔｏｏｔｈ、赤外線、ＷｉＦｉ、ＷｉＭＡＸのうち１つ以上を含む装置のネットワーク機能及び処理。
【００３４】
実質上、機能はハンドセット及び製造業者により大きく異なり、更にネットワークオペレータ及び多くのハンドセットは実現例におけるバグの悪影響を受ける可能性がある。デバイス適応アーキテクチャ（ＤＡＡ）はそれら課題を解決し、製品が記録的な速さで大多数の音楽対応２．５Ｇ及び３Ｇハンドセットに自動的に移植されるのを可能にする。ＤＡＡは、種々の機能に関連するパラメータを取り込み、アプリケーションがエンドユーザの入力なしで特定のハンドセット／ネットワークオペレータの組合せに対して自動的に特注されるのを可能にする。ＤＡＡに関する更なる詳細は国際特許第ＷＯ２００６／０６１５９５号に示され、その内容は参考として取り入れられている。
【００３５】
尚、MusicStationの参照プラットフォームはＪａｖａであることが特に重要である。いくつかの競合する製品は、容易にアドレス指定可能なSymbianプラットフォームに構築されている。そのプラットフォームに対してアプリケーションを構築することは相対的に容易であるが、大衆市場の音楽の提案に対する機会を提供しない。世界で１０％未満のハンドセットがSymnbianを搭載しており、それらの多くがビジネスに重点をおいたハンドセットである。Ｊａｖａは、最も広範に採用されたモバイルプラットフォームであり、ハンドセットの使用範囲に非常に重要である。Ｊａｖａは、略全ての媒体及び高性能なハンドセットにおいて利用可能である。Ｊａｖａ及びＤＡＡ技術の組合せは、MusicStationが他の技術より多くの消費者に配布され、特に製造業者又は機種に関係なく略同一に動作し、略同一に見え且つ略同一に知覚することを意味する。MusicStationは、Ｊａｖａ、Symbian、Windows(登録商標) Mobile、Linux（登録商標）及びBREWにおいて利用可能となるだろう。
【００３６】
他の機能は以下を含む：
・アプリケーションは、各々がアプリケーションの基本的な機能と関連付けられる複数のユーザ選択可能なタブを示すグラフィカルユーザインタフェースを提示する。
【００３７】
・各タブは、アプリケーションが実行している時は常に可視である。
【００３８】
・１つのタブは、全ての入手可能なコンテンツ及び探索機能にアクセスできるようにするホーム機能と関連付けられる。
【００３９】
・１つのタブは、選択された場合、現在再生中のトラックの詳細を与える。
【００４０】
・１つのタブは、選択された場合、コミュニティ及びニュース機能へのアクセスを可能にする。
【００４１】
・１つのタブは、選択された場合、聴き且つ／又はダウンロードするトラックの現在のキューを表示する。
【００４２】
・アプリケーションは、複数の画面が状況依存する「more」メニュー項目を示すグラフィカルユーザインタフェースを提示し、選択された場合には現在選択されている項目及び／又は現在表示されている画面に関連する更なる機能へのアクセスを可能にする。
【００４３】
・アプリケーションは、マルチタスク状況依存ジョイスティックを使用して制御され、ジョイスティックの特定の機能はその上の画面上のアイコンにより示される。ジョイスティックの操作は、キーパッドの数字キーを代用して実現される。例えば、数字キー５は上、０は下、７は左且つ９は右である。
【００４４】
・アプリケーションは、「Get New Artist（新しいアーティストを取得する）」と等価な機能がメニューにおいて「Artist（アーティスト）」と同一レベルにある状況に適した取得機能を提供する。Get New Track（新しいトラック（曲）を取得する）と等価な機能は、メニューにおいてアーティストのトラックのメニューリストと同一レベルにある。
【００４５】
・アプリケーションは、無線接続された他の携帯無線装置が時間的に同期して同一の音楽トラックを再生するように、１つの装置がマスタ再生装置としての役割を果たすことを可能にする。無線接続は、Ｂｌｕｅｔｏｏｔｈ等の近距離無線接続でもよい。
【００４６】
・アプリケーションは、現在再生中のトラックを示す再生画面に常に切り替える専用の「再生」数字キーを提供する。
【００４７】
・アプリケーションは可変のタイムアウトを提供し、種々の画面は種々のタイムアウトを有する。例えば、７秒後に戻る標準のナビゲーション画面と比較して、探索画面に戻ることはないが、ニュース画面には２０秒後に戻る。
【００４８】
・アプリケーションは、エンドユーザの再生の習慣に従ってフィルタリングされた対象のニュースを表示する。
【００４９】
・アプリケーションは追跡し、詳細なエンドユーザリスニングデータをリモートサーバに戻す。データは、トラックが聴かれた長さ、スキップされたトラック及びスキップされた時期を含む。データは、装置上にローカルにキャッシュされ、いずれにしても行なわれる通信を介してピギーバックとしてサーバに送出される。ユーザが設定時間を越えてダウンロードしていない場合、装置は、いずれにしても行なわれると推測される通信を待たずにデータを先に送出し返す。このデータは、装置に表示する音楽トラック推奨を提供する音楽推奨エンジンを充実させるために使用される。
【００５０】
・アプリケーションは、共有プレイリストを表示する。
【００５１】
・アプリケーションは、ユーザにより生成されたプレイリストチャートを表示する。
【００５２】
・アプリケーションの全ての機能は、音楽再生中に利用可能である。
【００５３】
・再生中に利用可能な機能は、ニュースの取得、並びに音楽トラックの探索、閲覧及び取得を含む。
【００５４】
別の面は、デジタル音楽コンテンツをダウンロードし且つ使用することを可能にする携帯無線コンピューティング装置である。装置は、
（ａ）無線装置上で実行し、エンドユーザの入力なしで無線装置と関連するパラメータに自動的に適応されたソフトウェアアプリケーションを具備し、
（ｂ）アプリケーションは、エンドユーザが無線ネットワークを使用してリモートサーバ上の音楽コンテンツを閲覧及び探索し、無線ネットワークを使用してリモートサーバから音楽コンテンツをダウンロードし且つダウンロードした音楽コンテンツを再生及び管理することを可能にし；
（ｃ）アプリケーションは、加入サービスが終了していない限り、装置への種々の音楽トラックの無制限の合法的なダウンロードを可能にし且つ装置に格納されたトラックのうち任意のトラックの再生を可能にするデジタル権利管理システムを含む。
【００５５】
第３の面は、デジタル音楽コンテンツを携帯無線コンピューティング装置にダウンロードし且つ使用することを可能にするソフトウェアアプリケーションであり、
（ａ）無線装置上で実行し、エンドユーザの入力なしで無線装置と関連するパラメータに自動的に適応されたソフトウェアアプリケーションである。
【００５６】
（ｂ）アプリケーションは、エンドユーザが無線ネットワークを使用してリモートサーバ上の音楽コンテンツを閲覧及び探索し、無線ネットワークを使用してリモートサーバから音楽コンテンツをダウンロードし且つダウンロードした音楽コンテンツを再生及び管理することを可能にし；
（ｃ）アプリケーションは、加入サービスが終了していない限り、装置への種々の音楽トラックの無制限の合法的なダウンロードを可能にし且つ装置に格納されたトラックのうち任意のトラックの再生を可能にするデジタル権利管理システムを含む。
【００５７】
最後の面は、第３の面により規定されたソフトウェアアプリケーションを使用してダウンロードされた音楽トラックである。
【００５８】
定義
移動電話：物理的なワイヤ又は他の物理的な接続、あるいはケーブルの形式ではなく大気を介する無線技術により電話網に接続される電話の種類。
【００５９】
移動電話、電話、モバイル、モバイルハンドセット又はハンドセット：移動電話の種類。
【００６０】
モバイルネットワーク：移動電話が動作でき且つ電話をかけたり、あるいはネットワーク常駐データ又はサービスにアクセスするような機能を提供できるように、移動電話に対して無線接続性を提供するネットワーク。
【００６１】
モバイルネットワークオペレータ（ＭＮＯ）：モバイルネットワーク及びそのネットワーク上で移動電話を使用する加入者又はユーザを動作させる会社又は組織。
【００６２】
グローバルモバイルネットワーク又は移動電話網：世界のモバイルネットワークオペレータにより動作される全てのモバイルネットワークの統合。
【００６３】
無線ネットワーク：クライアントコンピューティング装置に無線接続性を提供するネットワーク。そのようなネットワークは、ＷｉＦｉ、ＷｉＭＡＸ及びグローバルモバイルネットワークを含む。
【００６４】
サーバ：接続を行ない且つそこからサービスの要求を行なう１つ以上のクライアントコンピューティング装置に対する情報供給、データベース探索及びトランザクション等のネットワーク化アプリケーションサービス、特性及び機能を提供するために存在するネットワーク化コンピューティング装置。一般に、各サーバに対して多くのクライアントが存在し、通常、各クライアントはサーバよりサイズが小さく且つ計算能力も低い。
【００６５】
サービス：通常、サーバにより１つ以上のネットワーク接続クライアントコンピューティング装置に提供されるネットワーク化計算サービス、特性及び機能。サービスは、情報供給、データベース探索及びトランザクションを含む。そのようなサービスは、ネットワークの中央に展開することは構造的に実現可能であり、通常、クライアントの大きさ及び電力のためにクライアントコンピュータ上に展開することは実現不可能である。
【００６６】
クライアント：ネットワーク中心のアプリケーションの特性及び機能をアプリケーションのユーザ又は消費者に配布するネットワークに接続されるコンピューティング装置。通常、クライアントはサーバに接続し且つサービスを要求する。
【００６７】
ネットワークアプリケーション：ネットワーク中心のアプリケーション又はサービスの種類。ネットワークアプリケーションは、サーバ上のソフトウェアにより提供され且つネットワークを介してクライアントによりアクセスされるサービスによりサポート及び補完されるエンドユーザ又は消費者に対するアプリケーションのインタフェースの機能を実行するクライアント上で実行するソフトウェアの組合せにより配布される。
【００６８】
無線コンピューティング装置：無線ネットワークを介してネットワークに接続するクライアントの種類。そのような装置は、移動電話、パーソナルデジタルアシスタント（ＰＤＡ）、ゲームコンソール（例えば、SonyのPSP）又は他の無線ネットワーク接続クライアントコンピューティング装置を含む。無線コンピューティング装置の種類は、その製造業者、型、バージョン、オペレーティングシステム、ファームウェアバージョンにより更に規定される。
【００６９】
無線装置又は無線クライアント：無線コンピューティング装置の種類。
【００７０】
ソフトウェアアプリケーション：無線コンピューティング装置に無線配布されるか又はプリインストールされるクライアントソフトウェアアプリケーション。
【００７１】
ソフトウェアコンポーネント：無線コンピューティング装置に対して及びデバイス適応アーキテクチャ（ＤＡＡ）ソフトウェアライブラリの一部に対してカスタム化されるソフトウェアアプリケーションのコンポーネントを形成するソフトウェアの個々のユニット。
【００７２】
モバイルコンテンツ：移動電話上で使用、購入、再生、閲覧又はレンダリングされる電子製品を表すデジタルファイル及びデータ。例には、呼出音／着メロ、壁紙／写真、スクリーンセーバ／アニメーション、リアルトーン／トュルートーン、フル音楽ダウンロード、ビデオ、ＳＭＳ＆ＭＭＳアラート、モバイルゲーム、並びに多くの他の現在の又は今後登場する移動電話が購入可能なエンターテイメント及び情報製品が含まれる。
【００７３】
メタデータ：無線コンピューティング装置、無線ネットワーク、ソフトウェアコンポーネント、ネットワークアプリケーション又はモバイルコンテンツの属性又は挙動を記述する潜在的に階層関係にあるデータの個々の項目又はデータの集合。
【図面の簡単な説明】
【００７４】
【図１】Schedulerクラスを示す図である。
【図２】クライアントがタスクをスケジュールすることを示す図である。
【図３】ＵＩスレッドがキューにタスクを追加することを示す図である。
【図４】バイナリヒープの一例を示す図である。
【図５】配列に格納されたバイナリヒープを示す図である。
【図６】タスクの状態を示す状態図である。
【図７】データオブジェクトの各種類に対するキャッシュの上限及び下限を示す表である。
【図８】例外を設定するために使用されるデータオブジェクトを示す図である。
【図９】装置別の例外を示す図である。
【図１０】画面キャプチャ−Get new...オプションを示す図である。
【図１１】個人専用のメニュー項目及び含まれる推薦を示す表である。
【図１２】画面キャプチャ−項目の評価を示す図である。
【図１３】画面キャプチャ−Newsを示す図である。
【図１４】画面キャプチャ−Buzzメンバの推薦を示す図である。
【図１５】Cool Members及びBuzz Playlistsの個人専用のメニュー項目及び含まれる推薦を示す表である。
【図１６】トラック間の相関関係のマトリクスを示す図である。
【図１７】マトリクスの重み付けを示す図である。
【図１８】０〜１の正規化された重みの集合を示す図である。
【図１９】評価及び顧客の再生に基づいて、どの程度密接に関連付けられたアーティストの対がシステム中にあるかを表す相関関係のマトリクスである関連アーティストマトリクスを示す図である。
【図２０】評価及び顧客の再生に基づいて、どの程度密接に関連付けられた顧客の対がシステム中にあるかを表す相関関係のマトリクスである関連顧客マトリクスを示す図である。
【図２１】関係マトリクスのプロパティ、推薦への入力及び結果として得られる機構の表の一部を示す図である。
【図２２】関係マトリクスのプロパティ、推薦への入力及び結果として得られる機構の表の一部を示す図である。
【図２３】関係マトリクスのプロパティ、推薦への入力及び結果として得られる機構の表の一部を示す図である。
【図２４】関係マトリクスのプロパティ、推薦への入力及び結果として得られる機構の表の一部を示す図である。
【図２５】関係マトリクスのプロパティ、推薦への入力及び結果として得られる機構の表の一部を示す図である。
【図２６】黙示評価値の計算を示す図である。
【図２７】メッセージのプロパティを示す図である。
【図２８】画像のプロパティを示す図である。
【図２９】クライアントバージョンのプロパティを示す図である。
【図３０】翻訳されたメッセージを示す図である。
【図３１】装置メッセージのプロパティを示す図である。
【図３２】装置メッセージ／ヘルプメッセージのプロパティを示す図である。
【図３３】サービスメッセージを示す図である。
【図３４】サービス及び装置別メッセージを示す図である。
【図３５】クライアントビルドメッセージを示す図である。
【図３６】画面キャプチャ−Roaming optionsを示す図である。
【図３７】MusicStationのローミング挙動の構成を示す表である。
【図３８】画面キャプチャ−Roaming Warnings（ローミング警告）を示す図である。
【図３９】画面キャプチャ−Roaming Warnings−Ask prompt（プロンプトの要求）を示す図である。
【図４０】画面キャプチャ−Roaming Warnings−Ask promptを示す図である。
【図４１】画面キャプチャ−Onに設定されたRoaming Optionsを示す図である。
【図４２】画面キャプチャ−Offに設定されたRoaming Optionsを示す図である。
【図４３】タイトル、コンテンツ及び応答の結果を示す表である。
【図４４】クライアントとサーバとの間の要求／応答の流れを示す図である。
【図４５】サーバがクライアントに要求を送出することを示す図である。
【図４６】[major].[minor].[micro]、可変名及びプラットフォーム識別子の詳細を示す表である。
【図４７】エラーデータの詳細を示す表である。
【図４８】エラーデータをサーバに送出するクライアントの一例を示す図である。
【図４９】エラーデータ及び写真をサーバに送出するクライアントの一例を示す図である。
【図５０】単一のパラメータを含むＪｐｅｇの写真を送出するサーバの一例を示す図である。
【図５１】状態コードを示す表である。
【図５２】サーバがnews1.dataファイルを送出することを示す図である。
【図５３】サーバがnews2.dataファイル及びnews3.dataファイルを送出することを示す図である。
【図５４】送出されたデータの範囲を示すサーバ応答を示す図である。
【図５５】クライアントが要求において対応するGet行を送出しなかったSent行をサーバが送出することを示す図である。
【図５６】Releaseの集合を含むArtistデータオブジェクトを示す図である。また、ReleaseはTrackの集合を含む。
【図５７】別の方法が自身のファイルにオブジェクトの各集合を格納することであることを示す図である。本発明の「My Artists」の例において、アーティストのリストはファイル（userartists.data）に格納されるが、各アーティストのアルバムのリストは格納されない。アルバムのリストはアーティスト毎に１つのファイルである別個のアーティストファイル（例えば、artist.123.data）に格納される。各アルバムは、トラックを含む自身のファイル（release.4567.data）に格納される。
【図５８】オブジェクトグループがデータを複製する必要なく同一のデータオブジェクトを使用できる方法を示す図である。
【図５９】「My artists」データファイルにアーティスト名及びＩＤを格納できることを示す図である。
【図６０】クライアントがオブジェクトを設定し且つ変更された全てのオブジェクトを取得することを示す図である。
【図６１】クライアントがオブジェクトを要求し且つ変更された全てのオブジェクトを取得することを示す図である。
【図６２】クライアントがオフラインモードで変更されたオブジェクトを送出することを示す図である。
【図６３】object_change_logを示す図である。
【図６４】customer_objectを示す図である。
【図６５】customer_object_change_logを示す図である。
【図６６】ChangeLogRecordオブジェクトを示す図である。
【図６７】object_change_logテーブルを示す図である。
【図６８】customer_object_change_logテーブルを示す図である。
【図６９】クライアントログ毎にLogRecordを含むLoggerを示す図である。
【図７０】customer_loggerテーブルを示す図である。
【図７１】ＤＲＭの概要を示す図である。
【図７２】Service Registration Request（サービス登録要求）のパラメータを示す図である。
【図７３】ＭＮＯ追加メタデータを示す図である。
【図７４】Service Registration Response（サービス登録応答）のパラメータを示す図である。
【図７５】MusiStation RI Registration Request（MusicStation ＲＩ登録要求）のパラメータを示す図である。
【図７６】RI Registration Response（ＲＩ登録応答）のパラメータを示す図である。
【図７７】MusicStation RO Acquisition Request（MusicStation ＲＯ取得要求）のパラメータを示す図である。
【図７８】MusicStation RO Acquisition Response（MusicStation ＲＯ取得応答）のパラメータを示す図である。
【図７９】Content Acquisition Request（コンテンツ取得要求）のパラメータを示す図である。
【図８０】MusicStationの実現例の画面ショットを示す図である。
【図８１】MusicStationの実現例の画面ショットを示す図である。
【図８２】MusicStationの実現例の画面ショットを示す図である。
【図８３】MusicStationの実現例の画面ショットを示す図である。
【図８４】MusicStationの実現例の画面ショットを示す図である。
【図８５】MusicStationの実現例の画面ショットを示す図である。
【図８６】MusicStationの実現例の画面ショットを示す図である。
【図８７】MusicStationの実現例の画面ショットを示す図である。
【図８８】MusicStationの実現例の画面ショットを示す図である。
【図８９】MusicStationの実現例の画面ショットを示す図である。
【図９０】MusicStationの実現例の画面ショットを示す図である。
【図９１】MusicStationの実現例の画面ショットを示す図である。
【図９２】MusicStationの実現例の画面ショットを示す図である。
【図９３】MusicStationの実現例の画面ショットを示す図である。
【図９４】MusicStationの実現例の画面ショットを示す図である。
【図９５】MusicStationの実現例の画面ショットを示す図である。
【図９６】MusicStationの実現例の画面ショットを示す図である。
【図９７】MusicStationの実現例の画面ショットを示す図である。
【図９８】MusicStationの実現例の画面ショットを示す図である。
【図９９】MusicStationの実現例の画面ショットを示す図である。
【図１００】MusicStationの実現例の画面ショットを示す図である。
【図１０１】MusicStationの実現例の画面ショットを示す図である。
【図１０２】MusicStationの実現例の画面ショットを示す図である。
【図１０３】MusicStationの実現例の画面ショットを示す図である。
【図１０４】MusicStationの実現例の画面ショットを示す図である。
【図１０５】MusicStationの実現例の画面ショットを示す図である。
【図１０６】MusicStationの実現例の画面ショットを示す図である。
【図１０７】MusicStationの実現例の画面ショットを示す図である。
【図１０８】MusicStationの実現例の画面ショットを示す図である。
【図１０９】MusicStationの実現例の画面ショットを示す図である。
【図１１０】MusicStationの実現例の画面ショットを示す図である。
【図１１１】MusicStationの実現例の画面ショットを示す図である。
【図１１２】MusicStationの実現例の画面ショットを示す図である。
【図１１３】MusicStationの実現例の画面ショットを示す図である。
【図１１４】MusicStationの実現例の画面ショットを示す図である。
【図１１５】MusicStationの実現例の画面ショットを示す図である。
【図１１６】MusicStationの実現例の画面ショットを示す図である。
【図１１７】MusicStationの実現例の画面ショットを示す図である。
【図１１８】MusicStationの実現例の画面ショットを示す図である。
【図１１９】MusicStationの実現例の画面ショットを示す図である。
【図１２０】MusicStationの実現例の画面ショットを示す図である。
【図１２１】MusicStationの実現例の画面ショットを示す図である。
【図１２２】MusicStationの実現例の画面ショットを示す図である。
【図１２３】MusicStationの実現例の画面ショットを示す図である。
【図１２４】MusicStationの実現例の画面ショットを示す図である。
【図１２５】MusicStationの実現例の画面ショットを示す図である。
【図１２６】MusicStationの実現例の画面ショットを示す図である。
【図１２７】MusicStationの実現例の画面ショットを示す図である。
【図１２８】MusicStationの実現例の画面ショットを示す図である。
【図１２９】MusicStationの実現例の画面ショットを示す図である。
【図１３０】MusicStationの実現例の画面ショットを示す図である。
【図１３１】MusicStationの実現例の画面ショットを示す図である。
【図１３２】MusicStationの実現例の画面ショットを示す図である。
【図１３３】MusicStationの実現例の画面ショットを示す図である。
【図１３４】MusicStationの実現例の画面ショットを示す図である。
【図１３５】MusicStationの実現例の画面ショットを示す図である。
【図１３６】MusicStationの実現例の画面ショットを示す図である。
【図１３７】MusicStationの実現例の画面ショットを示す図である。
【図１３８】MusicStationの実現例の画面ショットを示す図である。
【図１３９】MusicStationの実現例の画面ショットを示す図である。
【図１４０】MusicStationの実現例の画面ショットを示す図である。
【図１４１】MusicStationの実現例の画面ショットを示す図である。
【図１４２】MusicStationの実現例の画面ショットを示す図である。
【図１４３】MusicStationの実現例の画面ショットを示す図である。
【図１４４】MusicStationの実現例の画面ショットを示す図である。
【図１４５】MusicStationの実現例の画面ショットを示す図である。
【図１４６】MusicStationの実現例の画面ショットを示す図である。
【図１４７】MusicStationの実現例の画面ショットを示す図である。
【図１４８】MusicStationの実現例の画面ショットを示す図である。
【図１４９】MusicStationの実現例の画面ショットを示す図である。
【図１５０】MusicStationの実現例の画面ショットを示す図である。
【図１５１】MusicStationの実現例の画面ショットを示す図である。
【図１５２】MusicStationの実現例の画面ショットを示す図である。
【図１５３】MusicStationの実現例の画面ショットを示す図である。
【図１５４】MusicStationの実現例の画面ショットを示す図である。
【図１５５】MusicStationの実現例の画面ショットを示す図である。
【図１５６】MusicStationの実現例の画面ショットを示す図である。
【図１５７】MusicStationの実現例の画面ショットを示す図である。
【図１５８】MusicStationの実現例の画面ショットを示す図である。
【図１５９】MusicStationの実現例の画面ショットを示す図である。
【図１６０】MusicStationの実現例の画面ショットを示す図である。
【図１６１】MusicStationの実現例の画面ショットを示す図である。
【図１６２】MusicStationの実現例の画面ショットを示す図である。
【図１６３】MusicStationの実現例の画面ショットを示す図である。
【図１６４】MusicStationの実現例の画面ショットを示す図である。
【図１６５】システムの概要を示す図である。
【発明を実施するための形態】
【００７５】
アーキテクチャ
１．１．マルチ・スレッディング
プレーヤの重要な面は、同時に複数のスレッドを実行することである。主なスレッドは３つ存在する：
・ユーザインタフェース（ＵＩ）スレッド
・アニメーション・スレッド
・スケジューラ・スレッド
実際にデータをダウンロードし且つそれをバッファにロードするＨＴＴＰ接続スレッドが更に存在し、スケジューラスレッドは接続によりブロックされないようにそのデータをバッファから読み出す。
【００７６】
通常、ＵＩスレッドは、ローカルのファイルシステムから又はＨＴＴＰ接続を介してリモートから、新しい画面を表示し、画面の背後でデータをロードするためにタスクをスケジュールすることにより、その新しい画面へのユーザナビゲーションに迅速に応答する。
【００７７】
ロードタスクは、タスクキューに追加される。キューは、タスクの優先度、タスクの種類及びスケジュールされた実行時間により順序付けられる。殆どのタスクは、迅速に実行されるようにスケジュールされる。その場合、実行時間は、タスクがキューに追加された時間に設定される。タスクによっては、少しの遅延を伴ってスケジュールされる。例えばトラックの再生は、プレイリスト上のトラックの迅速なスキップを可能にするために１秒の遅延を伴ってスケジュールされる。
【００７８】
新しいタスクがタスクキューに追加されると、その優先度を現在実行中のタスク（存在する場合）と比較する。その優先度が現在のタスクより高い場合、現在のタスクの取消しを試みる。完了するのに過度な時間を要するタスクのみが取り消される。これは、他の優先度の高いタスクが待っている間にタスクが実行スレッドを独占することを回避するためである。過度な時間とは数秒を超える時間である。取り消されたタスクは再スケジュールされる。実行時間は、タスクが最初にキューに追加された時間に設定される。
【００７９】
１．１．１．Scheduler
Schedulerは、バックグラウンドスレッドで迅速に実行又は後で実行するようにタスクをスケジュールするためのスレッドに対する機能である。タスクは、１度実行されるようにスケジュールされてもよく、あるいは定期的な間隔で繰り返し実行されるされるようにスケジュールされてもよい。
【００８０】
Schedulerオブジェクトは、スケジューラの全てのタスクを順番に実行するために使用される単一のバックグラウンドスレッドを有する。スケジューラタスクが完了するのに過度な時間を要する場合、タスクはタイマのタスク実行スレッドを「独占」する。その結果、後続するタスクの実行を遅延させる可能性があり、タスクは「蓄積」するだろう。実行するのに数秒を超える時間を要する可能性のあるタスクは、interrupt()を実行する必要がある。
【００８１】
interrupt()メソッドは、より高い優先度のタスクがタスクキューに追加された時に呼び出され且つタスクを追加するスレッドにより現在実行中のタスク上で呼び出される。スケジューラスレッドにより呼び出されるrun()メソッドは、最も早い機会にInterruptedExceptionをスローする必要がある。Schedulerはその例外をキャッチし、割込まれたタスクの優先度及びそれがキューに最初に追加された時間に基づいてその割込まれたタスクの実行を再スケジュールする。新しく追加されたタスクは受信され且つ実行される。
【００８２】
このクラスはスレッドセーフである。すなわち、複数のスレッドは外部同期を必要とせずに単一のSchedulerオブジェクトを共有できる。Schedulerクラスを示す図１及びクライアントがタスクをスケジュールすることを示す図２を参照。
【００８３】
１．１．１．１．TaskQueue
このクラスは、priority、taskType及びexecutionTimeにより順序付けされるTaskの優先度キューであるスケジューラのタスクキューを表す。
【００８４】
タスクの優先度は、ＣＬＤＣスレッドの優先度に基づく。そのため、３つの優先度が規定される：
・MAX_PRIORITYは、タスクが有することのできる最高優先度である。
【００８５】
・NORM_PRIORITYは、タスクに割り当てられるデフォルトの優先度である。
【００８６】
・MIN_PRIORITYは、タスクが有することのできる最低優先度である。
【００８７】
同一のpriorityを有するタスクは、taskTypeにより更に分割される。例えばこれにより、画面に対するデータを画像の前にスケジュールできる。これは、種々の優先度を使用することにより達成されるが、種類を変更せずにタスク（例えば、ユーザが異なる画面にナビゲートする）の優先度を下げたいと考える場合が多い。priority及びtaskTypeの概念を分離することにより、設計はより融通性を有し、理解し易くなる。まず、重要さにより順序付けられる３つの種類は以下の通りである：
・DATAは、オブジェクトデータファイルを要求するタスクに対して使用される。
【００８８】
・AUDIOは、オーディオファイルを要求するタスクに対して使用される。
【００８９】
・IMAGEは、画像ファイルを要求するタスクに対して使用される。
【００９０】
executionTimeは、同一のpriority及びtaskTypeを有するタスクがキューに追加された順番で実行されることを保証する。ＵＩスレッドがタスクをキューに追加することを示す図３を参照。
【００９１】
キューは内部でバイナリヒープとして格納されるため、タスクをスケジュールするためのコストはlog nである。ここで、nは同時にスケジュールされるタスクの数である。スケジュールされた大量（数千）のタスクは問題にならない。次にスケジュールされたタスクは常にルートにあるため、それを検索するのにコストはかからない。バイナリヒープの一例を示す図４を参照。
【００９２】
常に要素をヒープの末尾に追加し、ヒープ中のその場所を見つけるためにfixUp()メソッドを呼び出す。fixUp()メソッドは、追加された要素をその親と比較し、適切な順番でない場合はそれらを入れ替える。
【００９３】
ヒープを格納するために配列が使用され、ヒープは常に完全である（木には隙間はない）ため、コンパクトに格納される。ポインタに対して空間は必要ない。その代わり添え字i毎に、要素a[i]は２つの子a[2i+1]及びa[2i+2]の親である。配列に格納されたバイナリヒープを示す図５を参照。
【００９４】
１．１．１．２．タスク
タスクは、１度実行するように又は繰り返して実行するようにスケジュールされる。タスクは、３つの状態のうちの１つの状態となる：
・SCHEDULED：このタスクは、実行するようにスケジュールされる。非繰り返しのタスクである場合、まだ実行されていない。
【００９５】
・EXECUTED：この非繰り返しのタスクは、既に実行されており（又は現在実行中であり）、キャンセルされていない。
【００９６】
・CANELLED：このタスクはキャンセルされた（Task.cancelの呼び出しにより）。
【００９７】
タスクの状態図を示す図６を参照。
【００９８】
MusicStationのクライアントは、ローカルファイルシステムから又はＨＴＴＰ接続を介してリモートから単一のSchedulerを使用して全てのファイル接続をスケジュールする。全てのファイル接続が連続して処理されるように、スケジューラは単一のスレッドを使用する。タスクは、EXECUTED状態である場合にオープン接続のみを有することを保証する必要がある。１つのタスクのみがEXECUTED状態であるため、接続を１つのみ開くことを保証できる。更にinterrupt()メソッドをサポートする任意のタスクは、書き込みをしていたファイルに関する状態情報を格納せずに再開できる必要がある。これは、タスクが割り込まれたことにより別のタスクがファイルを変更した可能性があるため重要である。
【００９９】
１．１．２．ユースケース
１．１．２．１．ユーザがPlaylistsを開く
ユーザはアプリケーションを開き、迅速にPlaylistsメニューを開く。Playlistsメニューは、PlaylistSetが２つのフィルタ「My Private Playlists」及び「My Public Playlists」を使用してフィルタリングした「My Playlists」を表示する。
【０１００】
画面が表示されると、LoadTaskはTaskQueueに追加され、「My Playlists」をロードする。LoadTask.taskTypeはDATAであり、LoadTask.priorityはMAX_PRIORITYである。
【０１０１】
LoadTaskがTaskQueueに追加されると、キューで待っているスケジューラスレッドは通知される。スレッドは、キューからタスクを取得し、Task.run()メソッドを呼び出すことによりそのタスクを実行する。タスクは、「My Playlists」オブジェクトデータファイルがファイルシステム上に存在するかを確認する。この場合、存在しないため、HttpConnectionは開かれ、ファイルはストリームにわたり読み出される。ファイルはバッファ（６５ｋ）に読み込まれ、バッファがいっぱいになる度に、メモリカードに書き込まれ、データオブジェクトの一部又は全てをポピュレートするために使用される（尚、バッファより大きいデータファイルは殆どない）。
【０１０２】
PlaylistSetデータオブジェクトはPlaylistsにポピュレートされるため、それらPlaylistsは画像参照を含む。各画像参照が読み出されるため、ImageLoadTaskは作成され且つTaskQueueに追加される。ImageLoadTask.taskTypeはIMAGEであり、ImageLoadTask.priorityはMAX_PRIORITYである。
【０１０３】
「My Playlists」がロードを終了すると、スケジューラはキューから第１のImageLoadTaskを取得する。画像はローカルファイルシステム上に存在しないため、HTTPを介してロードされる。これは、全ての画像がロードされるまで継続する。
【０１０４】
１．１．２．２．ユーザがPlaylistsを開き、New Playlistsを迅速に選択する
ユーザはアプリケーションを開き、Playlistsメニューを開く。「My Playlists」がロードされる前に、ユーザは「Get New Playlists」を選択する。
【０１０５】
上述のように、ユーザがPlaylistsを開くと、LoadTaskは迅速にTaskQueueに追加され、「My Playlists」をロードする。LoadTask.taskTypeはDATAであり、LoadTask.priorityはMAX_PRIORITYである。
【０１０６】
LoadTaskが終了する前に、ユーザは「Get New Playlists」を選択する。これは、画面を変更しているため、TaskQueue.changePriority()を迅速に呼び出し、全てのMAX_PRIORITYタスクをNORM_PRIORITYに格下げする。前の画面の任意の未処理のタスクは、新しい画面のタスクより低い優先度を有する必要がある。
【０１０７】
LoadTaskは、TaskQueueに追加され、「New Playlists」をロードする。LoadTask.taskTypeはDATAであり、LoadTask.priorityはMAX_PRIORITYである。新しいタスクを追加することにより、「My Playlists」LoadTask上でinterrupt()が呼び出される。一般にデータオブジェクトが小さい（４ｋ未満）ため、割り込みは無視される。しかし、「My Playlists」LoadTaskがNORM_PRIORITYに下げられた優先度を有するため、作成する任意のageLoadTasksはNORM_PRIORITYで作成される。
【０１０８】
「My Playlists」LoadTaskがロードを終了すると、スケジューラは「New Playlists」LoadTaskをキューから取得し、それを実行する。「New Playlists」がロードされると、「My Playlists」画面の画像がバックグラウンドにロードされる。
【０１０９】
１．１．２．３．ユーザがPlaylistを開始する
ユーザが「My Playlists」からPlaylistを選択し、Playオプションを選択する。
【０１１０】
そのPlaylist中の全てのTrackは再生キューに追加される。StartTaskは第１のトラックのTaskQueueに追加される。StartTask.taskTypeはAUDIOであり、StartTask.priorityはMAX_PRIORITYである。その後、Track毎にFetchTaskをTaskQueueに追加する。FetchTask.taskTypeはAUDIOであり、FetchTask.priorityはMIN_PRIORITYである。尚、FetchTaskは第１のトラックを含むTrack毎に追加される。これは、タスクが終了する前にユーザがNextを選択することにより、StartTaskが取り消されるからである。FetchTaskは、ファイルが存在し、HttpConnectionを行なう前に完全にダウンロードされたかをまず確認する。
【０１１１】
StartTaskが終了する（且つトラックが再生を開始する）と、PrefetchTaskは第２のトラックに対して追加される。PrefetchTask.taskTypeはAUDIOであり、PrefetchTask.priorityはMAX_PRIORITYである。接続率に依存して、第２のトラックは、第１のトラックが終了する前に先読みされるべきである。その場合、第１のFetchTask及び第２のFetchTaskは廃棄され（ファイルは既に存在する）、第３のトラックのFetchTaskはロードを開始する。
【０１１２】
１．１．２．４．ユーザがPlaylistを開始し、Inboxを開く
ユーザは「My playlists」からPlaylistを選択し、Playオプションを選択する。第１のトラックのダウンロード中に、ユーザはInboxタブを開く。
【０１１３】
上述のように、StartTaskは第１のトラックに対して追加され、FetchTasksはトラック毎に追加される。ユーザがInboxを開くと、LoadTaskは「Inbox」StorySetに対して作成される。LoadTask.taskTypeはDATAであり、LoadTask.priorityはMAX_PRIORITYである。
【０１１４】
StartTaskの優先度は、MAX_PRIORITYからNORM_PRIORITYに変更され、「Inbox」LoadTaskはTaskQueueに追加される。interrupt()メソッドは、次にread()が戻る時（６５ｋバッファがいっぱいになった時）にStartTask.run()メソッドにInterruptedExceptionをスローさせるStartTask上で呼び出される。スケジューラはInterruptedExceptionをキャッチし、StartTaskは「Inbox」LoadTask後に実行するように再スケジュールされる。
【０１１５】
「Inbox」LoadTaskは実行され、記事毎にImageLoadTasksを作成する。それらは、MAX_PRIORITYで作成され、StartTaskが再開される前に全て実行される。画像がロードされると、StartTaskは、まずファイルが存在するか及び既に読み出された量を確認することにより再開する。タスクはオーディオファイルの残りの部分を要求する。ファイルがダウンロードされると、トラックは再生し、PrefetchTaskは次のトラックに対して追加される。
【０１１６】
１．１．３．バックグラウンドダウンロード
１．１．４．動的プレイリスト管理
１．２．高度なメモリ管理
MusicStationは、各ハンドセット及び／又はメモリカード上で利用可能なメモリを高度に管理する。
【０１１７】
・オブジェクトのダウンロードの前に、MusicStationはオブジェクトに対して利用可能なメモリが十分あることを確認する。
【０１１８】
・十分なメモリ空間がない場合、MusicStationはオブジェクトを削除する前に一連のチェックを実行する。
【０１１９】
・MusicStationは、最後に変更されたのが最も古いデータを含むオブジェクトを削除し、削除されるオブジェクトが頻繁に使用されてないファイルか又は全く使用されていないファイルであることを確認する。
【０１２０】
１．２．１．ダウンロード可能なオブジェクト
MusicStation内には３種類のダウンロード可能なオブジェクトが存在する。それらは以下を含む：
・データ−メニュー項目、チャート、ニュース記事内のテキスト等の更新が必要な任意のデータ
・画像−MusicStation内の任意の画像。これらには、アーティスト及びアルバムプロファイル上の画像、並びに新しい記事に関連する画像が含まれる
・オーディオ−オーディオファイル
キャッシュ
Optionsメニュー上のMax memory card useオプションを使用すると、ユーザは、MusicStationが格納に使用するメモリカードの最大のパーセント値を規定できる。この設定により、MusicStationに対して割り当てられたメモリが判定される。割り当てられたメモリは、データオブジェクトの種類毎のキャッシュに分割される。
【０１２１】
キャッシュは、ダウンロード可能なオブジェクト毎に存在する。各キャッシュは上限及び下限を有する：
・上限は、キャッシュが利用できる最大メモリ容量である。これは、ユーザが割り当てられたメモリを超えないことを保証するために存在する。
【０１２２】
・下限は、キャッシュが利用できる最小メモリ容量である。下限は、メモリが種々のデータオブジェクト間で均一に分配されることを保証するために存在する。
【０１２３】
上限及び下限は、割り当てられたメモリのパーセント値で規定される。データオブジェクトの種類毎のキャッシュの上限及び下限は、図７に示すように規定されている。
【０１２４】
１．２．２．オブジェクトのダウンロード
オブジェクトがダウンロードされる前に、MusicStationは一連のチェックを実行して、ファイルをダウンロードすることにより下限及び上限に違反することがないことを確認する。MusicStatonは、最後に使用された順にソートされるオブジェクトの各種類のリストを維持する。最も最近使用されたオブジェクトはリストの最上部にあり、最後に使用された日付が最も古いデータを含むオブジェクトはリストの最下部にある。
【０１２５】
オブジェクトのダウンロードがオブジェクトのキャッシュの上限を超える場合、以下の処理が行なわれる：
・DELETE_WITHOUT_CHECK−MusicStationは「最後に使用された」日付が最も古いデータを有する同一の種類のデータオブジェクトを削除する。
【０１２６】
オブジェクトをダウンロードするのに利用可能なメモリがない場合、以下の処理が行なわれる：
・DELETE_WITH_CHECK−DELETE_WITH_CHECKは、「最後に使用された」日付が最も古いデータを有する同一の種類のデータオブジェクトの位置を特定し、そのオブジェクトの削除を試行する。下限を下回ってキャッシュを使用しない場合、削除を開始する。
【０１２７】
削除により下限を下回ってキャッシュを使用する場合、DELETE_WITH_CHECKは「最後に使用された」日付が最も古いデータを有するオーディオオブジェクトの位置を特定し、そのオーディオオブジェクトを削除する。
【０１２８】
DELETE_WITH_CHECKがオーディオオブジェクトを削除できない場合、ステップ１に進む。「最後に使用された」日付が最も古いデータを有する同一の種類のデータオブジェクトの位置を特定し、そのオブジェクトを削除する。
【０１２９】
１．３．装置別媒体配布
各コンテンツは、コンテナ、形式、ビットレート及びサンプルレート（例えば、m4a、acc+、48kbps、44.1kHz）で「タグ付け」される。コンテンツの再生は、全ての種類のコンテナ、形式、ビットレート、サンプルレート及びmime形式に符号化される基本コンテンツの１つ（ピンクノイズ）を使用して装置上でテストされる。それらテストの結果は、テストクライアントを介してサーバに送出されて格納される。各コンテナ、形式、ビットレート、サンプルレート及びmime形式は、サーバに格納された他のものより好ましい。クライアントが追加のコンテンツを要求すると、サーバは、再生されるコンテナ、形式、ビットレート、サンプルレート及びmime形式の種類に符号化されるそのコンテンツへのリンクのリストを返す。これは、再生されたコンテンツの「タグ」を追加のコンテンツの利用可能な「タグ」とマッチングすることにより行なわれる。このリストは、好みにより順序付けられる。最も好ましい符号化で符号化されるコンテンツへのリンク。オーディオ再生品質テストは、このオーディオ選択項目に対して実行され、許容される品質であることを確認する。許容される品質でない場合、２番目に好ましいものが検査され、リストを下がっていく。オーディオ品質テストは、オーディオソフトウェアを使用して、電話のヘッドフォンソケットの出力を解析する。
【０１３０】
２．ユーザ体験機能
２．１．クライアント例外処理
顧客がアプリケーションを使用している間、MusicStationのクライアントは、バックグラウンドで定期的にファイルをダウンロードし且つ更新している。エラーが発生した場合、実行されているタスク及びスローされたエラーに依存して、再試行したいか、ユーザに通知するか又は何もしない。本明細書において、エラーが発生した場合に行なう動作を決定する方法を説明する。
【０１３１】
２．１．１．Exception Listener
MusicStationのクライアントを制御する主なスレッドは３つ存在する。ＵＩスレッドは全てのキー押下を処理し、ペイントスレッドは全ての画面の再描画を処理し、タスクスレッドはデータのロードを処理する。例外は、それらスレッドのうち任意のスレッドにおいてスローされるが、ExceptionListener exceptionThrown()メソッドに常に渡される。
【０１３２】
ExceptionListenerは、以下に基づいて例外の処理方法を決定する：
スローされた例外
例外の原因となった事象
事象の優先度
例外のスーパークラス
それらパラメータは、この例外に対するExceptionConfigをルックアップするのに使用される。ExceptionConfigは、例外の処理方法を決定するのに必要な全ての情報を含む。
【０１３３】
２．１．２．Exception Config
ExceptionConfigは、例外の原因となった事象を自動的に再試行するか又はエラーメッセージをユーザに示すかを決定するのに使用される。
以下のオブジェクトは、例外を設定するのに使用される：
ExceptionConfig：この例外に対するデフォルトの挙動を含む
ExceptionEvent：特定の事象及び優先度に対するデフォルトの挙動を無効にする
ExceptionLang：装置によりサポートされる各言語のエラーメッセージを含む
例外を設定するために使用されるデータオブジェクトを示す図８を参照。
【０１３４】
タスクスレッドで発生する例外のみが再試行を行なう。以下の属性は、タスクを再試行するか否か及び再試行の方法を決定するのに使用される：
firstRetryInterval：最初に要求を迅速に再試行したい
firstRetryCount：再試行の回数又は再試行しない場合は０
secondRetryInterval：再試行の間隔をあけてより長い期間をおきたい
secondRetryCount：再試行の回数又は再試行しない場合は０
allowSessionRetry：サーバエラーがあるか又はファイルが見つからなかった場合、このセッション間にサーバへの同一要求を許可したくない
deleteLocalFile：ファイルが破損した場合、ローカルファイルを削除してサーバからのファイルのロードを再試行したい。
【０１３５】
任意の例外がエラーメッセージをユーザに表示できる。以下の属性は、ユーザに表示するか否か及びユーザへの表示方法を決定するのに使用される。
【０１３６】
showAlert：真である場合、１つ以上のオプションと共にエラーメッセージをユーザに表示する
continueOption：前の画面に戻る
retryOption：タスクを再試行する
upgradeOption：新しいバージョンのアプリケーションをインストールする
closeOption：アプリケーションを閉じる
openBrowserOption：モバイルのＷＡＰブラウザで要求を再試行する
exceptionLangs：各サポート言語のエラーメッセージ
いかなる例外の場合も、これら値を特定の事象に対して無効にでき、あるいは例外のスーパークラスに対して定義された値にフォールバックできる。
【０１３７】
２．１．３．装置別例外
装置の中には、予想される例外をスローしない装置もある。例えば、Nokia N70は、より特定的なConnectionNotFoundExceptionではなく、サーバが応答しない場合にメッセージ「-34」と共にIOExceptionをスローする。DeviceExceptionConfigオブジェクトは、装置別例外と予想される例外とのマッピングを指定することを可能にする。
【０１３８】
以下のフィールドは、装置別例外を予想される例外にマップする：
exceptionClassName：装置によりスローされる例外
exceptionString：Exception.toString()メソッドの結果
exceptionId：これがマップする周知の例外
装置別例外を示す図９を参照。
【０１３９】
２．１．４．データベースの必要条件
client_build
event_type_set_idFKnumber(10) not NULL
exception_set_idFKnumber(10) not NULL
事象及び例外の集合はビルド時に作成され、指標はクライアントとサーバとの間で送出される事象及び例外をマップするために実行時に使用される。
【０１４０】
event_type
priorityvarchar(12) DEFAULT NORMAL, in (MIN, NORMAL, MAX)
優先度は、クライアントからサーバに最初に送出される事象を判定するために使用される。優先度及び重大さレベルの双方が、サーバによりクライアント上で更新される。
【０１４１】
event_type_set
idPKnumber(10)
automaticnumber(1) not NULL, default 0
countnumber(12) not NULL, default 0
guidvarchar(32) not NULL
namevarchar(96) not NULL
data_classification
created
inserted
modified
クライアントビルドに対して作成された事象の集合。この集合は、クライアントにより送出された事象をデータベースの事象の種類にマップするために実行時に使用される。
【０１４２】
event_type_set_item
event_type_set_idPKnumber(10) not NULL
event_type_idPKnumber(10) not NULL
event_type_namevarchar(96) not NULL
event_type_indexnumber(10) not NULL, UNIQUE INDEX
data_classification
created
inserted
modified
指標は、クライアント事象とサーバ上の事象の種類との間のマッピングである。指標は、EventTypeデータオブジェクトにおいて定数として定義される。クライアントコードにおける事象に対する全ての参照は、この定数を使用する。
【０１４３】
exception_set
idPKnumber(10)
automaticnumber(1) not NULL, DEFAULT 0
countnumber(12) not NULL, DEFAULT 0
guidvarchar(32) not NULL
namevarchar(96) not NULL
data_classification
created
inserted
modified
クライアントビルドに対して作成された例外の集合。この集合は、クライアントにより送出された例外をデータベースの例外にマップするために実行時に使用される。
【０１４４】
exception_set_item
exception_set_id PKnumber(10) not NULL
exception_idPKnumber(10) not NULL
exception_namevarchar(96) not NULL
exception_indexnumber(10) not NULL, UNIQUE INDEX
data_classification
created
inserted
modified
指標は、クライアントの例外とサーバ上の例外とのマッピングである。指標は、ExceptionConfigデータオブジェクトの定数として定義される。クライアントコードにおける事象に対する全ての参照は、この定数を使用する。
【０１４５】
exception
idPKnumber(10) not NULL
guidvarchar(32) not NULL
namevarchar(96) not NULL
event_type_idFKnumber(10) not NULL
class_namevarchar(128) not NULL
superclass_namevarchar(128)
first_retry_intervalnumber(10)
first_retry_countnumber(10)
second_retry_intervalnumber(10)
second_retry_countnumber(10)
allow_session_retrynumber(1)
delete_local_filenumber(1)
show_alertnumber(1)
continue_optionnumber(1)
retry_optionnumber(1)
upgrade_optionnumber(1)
close_optionnumber(1)
open_browser_optionnumber(1)
message_key_idFKnumber(1)
descriptionvarchar(256)
commentsvarchar(256)
data_classification
created
inserted
modified
クライアント上でスローされた例外を処理する方法を制御するフィールドを含む。例外の設定はビルド時にＪＡＲに含まれ、サーバにより実行時にクライアント上で更新される。
【０１４６】
exception_event
exception_idPKnumber(10)
caused_by_event_type_idPKnumber(10)
event_priorityPKnumber(10) in (All, MIN, NORMAL or MAX)
first_retry_intervalnumber(10)
first_retry_countnumber(10)
second_retry_intervalnumber(10)
second_retry_countnumber(10)
allow_session_retrynumber(1)
delete_local_filenumber(1)
show_alertnumber(1)
continue_optionnumber(1)
retry_optionnumber(1)
upgrade_optionnumber(1)
close_optionnurnber(1)
open_browser_optionnumber(1)
message_key_idFKnumber(1)
event_indexnumber(10)
descriptionvarchar(256)
commentsvarchar(256)
data_classification
created
inserted
modified
例外処理は、特定の事象及び特定の事象の優先度に対して無効にされる。
【０１４７】
device_exception
device_idPKnumber(10)
exception_class_namePKvarchar(128)
exception_stringPKvarchar(256)
exception_idFKnumber(10)
automaticnumber(1) not NULL, DEFAULT 0
data_classification
created
inserted
modified
装置別例外を周知の例外にマップする。このテーブルは、装置の稼動中に検出することによりポピュレートされる。
【０１４８】
２．２．推薦
本明細書において、MusicStationアプリケーション内から顧客に対して推薦するのに利用される方法を説明する。omnifoneは、MusicStationアプリケーションに対する忠誠心を築く戦略の鍵として常に変化する妥当な最新の推薦を行なう能力を考察する。適切に実現される推薦は探索及び発見を促進し、その結果、新しい音楽を更に購入させる。更にそれにより、制限されるモバイル環境におけるMusicStationの体験を最適化できる。
【０１４９】
２．２．１．MusicStation内の推薦
MusicStationは、顧客に個人専用の推薦を推進するために設計されたいくつかの機能を含む。それら機能は、Homeタブ、Inboxタブ及びBuzzタブにわたり、以下の節において詳細に説明する。
【０１５０】
２．２．１．１．Homeタブにおける推薦
画面キャプチャ−Get new...オプションを示す図１０を参照する。
【０１５１】
顧客がHomeタブからGet new playlists、Get new artists、Get new albums又はGet new tracksオプションを選択すると必ず、顧客の最近の音楽の聴き方に基づく個人専用の提案する推薦であるメニューオプションを含むメニューオプションのリストが提示される。
【０１５２】
個人専用の推薦を含むメニュー項目を図１１に示す。
【０１５３】
２．２．１．２．音楽の推薦に影響を及ぼす情報
Homeタブの音楽の推薦は、顧客に特有の２つの要因の相互作用に基づいて行なわれる：
黙示要因：これは、顧客の音楽の聴き方（すなわち、顧客が聴く音楽の種類及び顧客が音楽を聴く頻度）に基づく
明示的要因：聴く音楽に対する顧客の実際の評価の仕方
また、黙示要因に対する計数は、Inboxのコンテンツに対して顧客が行なうクリック数である（更なる情報は、第２．２．１．４節のBuzzタブにおける推薦を参照）。
【０１５４】
画面キャプチャ−項目の評価を示す図１２を参照する。明示的要因に関して、顧客は、Love itと評価した他の音楽に類似する音楽に対する推薦をプッシュされ、Hate itと評価した音楽に類似すると規定された任意のコンテンツは推薦されない。
【０１５５】
２．２．１．３．音楽の推薦を行なう
各顧客に対するこれら黙示要因及び明示的要因は組み合わされ、アーティストと他のアーティストとの周知の関係及びトラックと他のトラックとの周知の関係等と混合される。その結果、顧客に対する個人専用の推薦のリストが得られる。
【０１５６】
ある期間にわたり、人気のある（又は人気のない）アーティスト、アルバム、トラック及びプレイリストに関する情報を収集するため、それら推薦は、顧客が妥当であると考える可能性が最も高いものに更に厳しく適合されるだろう。システムは、顧客が聴くか又は購入する上位のアーティスト／アルバム及びトラックと直接関係のある最も人気のあるアーティスト、アルバム又はトラックを顧客に自動的にプッシュする。
【０１５７】
２．２．１．３．１．「最近であること」の重要性
全ての時間にわたる顧客の音楽の聴き方ではなく最近の音楽の聴き方にのみ基づいて推薦を行なうのが重要である。これにより、提案が作成時の顧客に最も関連し、例えば非常に変化しやすい種々の好みを有する可能性のある顧客により影響を受ける非常に広範な提案の曖昧な集まりから構成されないことを保証する。
【０１５８】
MusicStationに関しては、最近とは、顧客が最も最近聴いたか又は購入したＮ個のアーティスト／アルバム／トラック又はプレイリストにより規定される。Ｎの実際の値は観察に基づいて設定可能であり、それにより推薦処理の時間にわたり精細な調整が可能になる。
【０１５９】
２．２．１．４．Buzzタブにおける推薦
２．２．１．４．１．Newsを介する推薦
画面キャプチャ−Newsを示す図１３を参照する。全てのNewsのコンテンツ（ニュース記事、イベント通知、特定のアーティストの広告等）は、Homeタブに関して説明したのと同一の黙示要因及び明示的要因に基づいて顧客に対して個人専用にされる。更に、上述したように、ユーザがアーティストのホームページにリンクする広告等のNewsのコンテンツをクリックする場合、その事象は追跡され、推薦処理全体においてそのアーティストへの「肯定的な票」として使用される。
【０１６０】
２．２．１．４．２．Buzzメンバを介する推薦
画面キャプチャ−Buzzメンバの推薦を示す図１４を参照する。
【０１６１】
Buzzタブは、個々の顧客向けの推薦を含む２つの主な要素を含む。それらを図１５の表で説明する。
【０１６２】
メンバ（すなわち、MusicStationの顧客）に対する推薦は、音楽を聴き且つ評価した履歴が類似する顧客をリンクすることにより行なわれる（内部では、システムが全ての他の顧客に対する顧客の「好み」を測定し、顧客の好みの最高レベルを有する顧客を選択する）。
【０１６３】
顧客が推薦されたメンバを選択する場合、顧客はShared Playlists（共有プレイリスト）を聴いて評価できる。
【０１６４】
２．２．２．推薦するための論理構造のサポート
それら推薦を行なうことをサポートする主な構造は３つある。
【０１６５】
・関連トラックマトリクス
・関連アーティストマトリクス
・関連顧客マトリクス
後述の節においてシステムの物理インフラストラクチャを説明する。現在のところ、それら構造が２４時間毎に頻繁にリフレッシュされることを考慮することで十分である。
【０１６６】
２．２．２．１．構造のサポート１−関連トラックマトリクス
関連トラックマトリクスは、評価及び顧客の再生に基づいてどの程度密接に関連付けられたトラックの対がシステム中にあるかを表す相関関係のマトリクスである。
【０１６７】
２．２．２．１．１．段階１−トラックの関連付けのカウントの生成
トラックに対して、上記のようなマトリクスを構築する。これは以下のことを表す：
対のトラックを全て再生したか又はLove It!と評価した顧客のカウント。
重要な注釈及び規則
図１６のマトリクスは、５つのトラックの領域のみを考慮する。go-liveに対して５００，０００を考慮することになるだろう。
【０１６８】
１）でカウントとして含まれるために、当該ユーザは少なくとも２回全て聴く（使用許諾契約書により規定されるように）必要がある。その根本的な理由は、顧客が２回以上トラックを聴いた場合、そのトラックを好きな可能性が高いからである。１度だけしか聴かない場合、新しい音楽を探索しているだけである可能性があり、それを再び聴くという印象を十分に与えられない。
【０１６９】
顧客がトラックの２つの対を高く評価して３回以上聴く場合、その結果としてマトリクスの対応する交点に２を加算する効果がある。これは、ユーザが交差するトラックの対に与えられる最大の影響である。
【０１７０】
Love It!と評価されるが再生されないトラックは、関連付けに対してカウントされる。
【０１７１】
このマトリクスは、世界的なMusicStationの提供内で全てのサービスにわたる全てのトラック、全ての評価及び再生を範囲に含む。同様のことが後述されるアーティスト関連マトリクスにも当てはまる。
【０１７２】
尚、マトリクスの半分は対角線の反対側に複製される。従って、理論的にはマトリクスの半分のみが必要である。
【０１７３】
２．２．２．１．２．段階２−トラックの関連付けの重み付け
ここで、段階１からマトリクスを取得する必要があり、重みを適用し、いくつかのトラックが全ての顧客に単に人気がある（従って、個々の関連付けられた対に対して密接に関連付けられる必要はない）ということを考慮する相関関係を生成する。
【０１７４】
これを行うために適用する式は、TF・IDF法として周知である。
【０１７５】
文献又はウェブ検索に属するキーワードの説明において、TF・IDF法が動作する方法の概略を説明する。
【０１７６】
TF = Term Frequency（単語の出現頻度）
文献の集合において用語が見つけられる頻度の測定値。ＴＦは、問い合わせに最も関連する文献を判定する手段であるＩＤＦ（逆文献出現頻度）と組み合わされる。ＴＦは、特定の文献にある単語が現れる頻度を測定するのにも使用されることがある。
【０１７７】
IDF = inverse document frequency（逆文献出現頻度）
用語が集合にある希少さの測定値であり、用語を含む文献の数で集合の合計サイズを除算することにより計算される。非常に一般的な用語（「the」、「and」等）は、非常に低いＩＤＦを有し、そのため探索結果から除外されることが多い。それらＩＤＦの低い単語は、一般に「ストップワード」と呼ばれる。
【０１７８】
【数１】
2014195274.tif 000003
【０１７９】
この式に対する注釈：
・TF = 頻度（又は段階１のマトリクスの交点の値）
・ＩＤＦは、式の後半（log）部分で表され、２を底とする対数である
・P(T1)は、マトリクスの種々の対において少なくとも１度現れるTrack1の総合的な確率を表す（すなわち、一対において発生する回数をトラックの合計数で除算したもの）
・ＩＤＦは３乗される。これは定数ではないが、推薦を向上させるために共に実験されるものである。周知のオンライン音楽推薦機能は、この定数に対して値３を使用するため、その知識及び先例に追従するのが賢明だろう。
【０１８０】
式の使用の一例として、段階１のマトリクスからのTrack1及びTrack2の重みを計算したい場合、以下の計算を実行する：
【０１８１】
【数２】
2014195274.tif 000004
【０１８２】
これにより、Track1及びTrack2の重み３４が得られる。図１７に示す新しい重み付けマトリクスを生成できる。これは、各行及び各列の末尾に全ての重みの合計を含む。
【０１８３】
２．２．２．１．３．段階３−重みの正規化
ここで、重みを正規化する必要がある。実質的にこれは、マトリクスの重み付けされた全ての相関関係が行又は列の相関関係の合計により除算される新しいマトリクスを作成することを意味する。
【０１８４】
Track1及びTrack2の例を再度使用すると、単純に３４を１１０．５で除算し、正規化された重み０．３１を提供する。
【０１８５】
その結果、図１８に示すように０と１との間の正規化された重みの集合を有する。
【０１８６】
結果として得られる表において、値が１に近いほど、トラック間の相関関係は密である。
【０１８７】
多くの推薦において、表の値は、規則的に再生成される（しかし、含まれるナンバクランチングの量のために実行中の方法で更新されない）際に相関関係を有するという利点により、事前計算済み関連付け（ＰＣＡ）と呼ばれる。
【０１８８】
２．２．２．２．構造のサポート２−関連アーティストマトリクス
例えば図１９に示すように、関連アーティストマトリクスは、評価及び顧客の再生に基づいて、どの程度密接に関連付けられたアーティストの対がシステム中にあるかを表す相関関係のマトリクスである。
【０１８９】
ＰＣＡの関連アーティストマトリクスは、実質的にトラックに対する方法と全く同一の方法で構築される。
【０１９０】
アーティスト再生マトリクスに含まれるための基準は、顧客がアーティストの少なくとも１つのトラックを少なくとも２回全て再生する必要があることである。単一の顧客がマトリクスに対して与えられる最大の影響は、値２を加算することである（一対のアーティストを双方ともLove It!と評価し、双方のアーティストの少なくとも１つのトラックを少なくとも２回全て聴いた場合）。
【０１９１】
尚、そのアーティストによるトラック又はアルバムの評価は、関連アーティストマトリクスに影響しない。
【０１９２】
２．２．２．３．構造のサポート３−関連顧客マトリクス
関連顧客マトリクスは、評価及び消費者の再生に基づいて、どの程度密接に関連付けられた顧客の対がシステム中にあるかを表す相関関係のマトリクスである。例えば図２０を参照。
【０１９３】
ＰＣＡの関連顧客マトリクスは、関連アーティストマトリクスを生成するのと同一の処理の一部として構築される。
【０１９４】
関連顧客マトリクスに含まれるための基準は、顧客が同一のアーティスト*の少なくとも１つのトラックを少なくとも２回全て再生する必要があることである。単一の顧客がマトリクスに対して与えられる最大の影響は、値２を加算することである（同一の一対のアーティストを双方ともLove It!と評価し、双方のアーティストの少なくとも１つのトラックを少なくとも２回全て聴いた場合）。
【０１９５】
尚、ここで共通のアーティストを選択することは、計算及び処理電力の影響を低減するため、共通のトラックを選択するより有益である可能性が高い。
【０１９６】
２．２．３．推薦を行なう
この節において、以下に対する推薦を生成するために上記構造を使用する方法を説明する：
・「More like this」トラック、アルバム又はアーティスト
・トラック「You might like」
・アルバム「You might like」
・アーティスト「You might like」
・プレイリスト「You might like」
・Buzz Cool Members画面に一覧表示されるような「Recommended Members」
・Buzz Cool Playlists画面に一覧表示されるようなRecommended Playlists−これはプレイリストyou might likeと同一のリストであるか？
「Find in Playlists?」
・Inbox−編集者によるもの及び宣伝のためのもの
説明する全ての機能性は、計算されたＰＣＡに基づいて要求毎*の実行時に実行する。
【０１９７】
図２１、図２２、図２３、図２４及び図２５を参照。
【０１９８】
２．２．４．星評価の生成
この節では、アーティスト／アルバム／トラック／プレイリストに対する５つ星評価を生成する方法を説明する。
【０１９９】
２．２．４．１．評価システムへの入力
星評価システムへの入力は、明示的評価（すなわち、Love It!及びHate it!）及び黙示評価（すなわち、アーティスト／アルバム／トラックを聴いた回数、特に顧客がそのアーティスト／アルバム又はトラックを全て聴いた回数及び少なくとも２回）の２つがある。
【０２００】
可能であれば、評価は明示的測定値及び黙示測定値の５０／５０の部分で構成されることが推奨される。*
*これは、顧客が高い星評価又は低い星評価と共に表すために単に酷評できない時に有利である。
【０２０１】
２．２．４．２．アーティスト／アルバム／トラック／プレイリストに対する５つ星評価の計算
２．２．４．２．１．明示的評価値の計算
アーティスト／アルバム／トラック／プレイリストの明示的評価は、単純にアーティスト／アルバム／トラックをLove It!と評価した顧客とHate It!と評価した顧客との比率に基づく。これは、以下のように計算される：
１）アーティスト／アルバム／トラック／プレイリストをLove It!と評価した顧客の数を取得する
２）（１）の値をアーティスト／アルバム／トラック／プレイリストを評価した顧客（すなわち、Love It!又はHate It!のいずれかに評価した顧客）の総数で除算する
３）５を乗算して、５つのうちの１つの評価値を提供する
例えば、Angels-Robbie Williamsに対して４５個のLove It!評価及び１８個のHate It!評価を有する場合を考慮する。評価値は以下のようになる：
Ｒａｔｉｎｇ＿ｖａｌｕｅ ＝ {４５／(４５＋１８)}×５＝３．５７
２．２．４．２．２．少ない評価数を処理するための評価値の調整
酷評を回避するため及び数人の顧客のみがアーティスト／アルバム／トラック／プレイリストを評価した状況において多くの０又は５つ星評価がシステムに現れるのを防止するため、Love It!及びHate It!の２つの架空の評価を常に計算に含むべきである。従って、最終的な計算は以下のようになる：
Ｒａｔｉｎｇ＿ｖａｌｕｅ ＝ ［(４５＋１)／{(４５＋１）＋（１８＋１)}］×５＝３．５３
２．２．４．２．３．黙示評価値の計算
黙示評価値を計算するために、比較の基準を作成する必要がある。最も賢明な基準は、個々の顧客により少なくとも１回全てが再生された全てのアーティスト／アルバム／トラック／プレイリストに対する顧客１人あたりの平均再生回数を表す基準である（すなわち、１度も聴いたことのないアーティスト／アルバム／トラック／プレイリストを計算に含めるのは公平ではない）。この基準を利用してシステム内で２．５の評価を表せ、２．５の評価値前後の分布を正規化することにより全ての他の評価を上下に調整できる。
【０２０２】
一例として、トラックAngels-Robbie Williamsに対する顧客１人あたりの平均*再生回数が１２．９０であり、全てのトラック（少なくとも１回全てが再生された）に対する顧客１人あたりの平均再生回数が４．６６であり、標準偏差が４．２３である場合、以下のことを行なう：
Angels-Robbie Williamsに対する顧客１人あたりの平均再生回数＝１２．９０
正規化された再生回数（平均は約０）＝（平均再生回数−全体の平均再生回数）／（標準偏差）
従って、正規化された再生回数（平均は約０）＝(12.90 - 4.66)／4.23 = 1.95
従って、正規化された再生回数（平均の星は約２．５個）＝2.5 + 1.95 = 4.45
（尚、非常に極端な状況において、この値は＜０又は＞５にもなる可能性がある。この場合、値を０又は５に制限する。）
これが６つのトラックの領域において動作する方法の全体的な表現を図２６に表す。*尚、最初に平均値を使用したが、中央値で実験すべきである。これは、中央値が執拗に１つのアーティスト／アルバム／トラック／プレイリストを再生する個々の顧客の影響を除く効果を有するためである。
【０２０３】
２．２．４．２．４．全体の評価値の計算
全体の５つ星評価は、単純に黙示評価及び明示的評価の平均値を得て、最近接の半星に切り上げる（提示するものに対して肯定的にしたいため切り上げる）ことにより計算される。
Angels-Robbie Williamsの全体的な評価＝(３．５３ ＋ ４．４５)／２ = ３．９９
従って、Angels-Robbie Williamsは４つ星の評価を受ける。
【０２０４】
２．２．４．３．顧客に対する評価の計算
顧客に対する評価は、以下の２つの５０／５０平均に基づく：
１）顧客が共有プレイリストを聴いた回数及び評価
２）メンバが有する友人の数
前者は、第２．２．４．２節で説明した方法と同様の方法で計算され、同様に黙示部分に対しては、他の顧客が少なくとも２回聴いたプレイリストのみを考慮する。全ての顧客のプレイリストに対する全体の評価を有すると、単純にそれら全ての平均値を取得して、最終的な評価（５つ星又は他の更に望ましい表現）を生成する。
【０２０５】
第２の部分は、全体のサービスデータセットに対する友人の平均数に対する友人の平均数として計算される。すなわち：
正規化された友人の数（平均は約２．５）＝２．５＋（平均再生回数−全体の平均再生回数）／（標準偏差）
２．３．探索機能
本明細書において、MusicStationの音楽探索を構成する探索インタフェース、処理及び結果の集合について説明する。モバイル動作環境の特性のために、MusicStation内の探索機構は、使用するのに単純で直感的であり、それと同時に非常に強力な機能となるように設計されている。該当する正確な結果をMusicStationの顧客の基盤に迅速に提供することを重視している。
【０２０６】
それと同時に、You might like、Recently Added及びFeatured Artists／Albums／Tracks／Playlistsメニューオプションの下、該当するアーティスト、アルバム、トラック及びプレイリストを顧客にプッシュするために進行中の多くの自動化動作がバックグラウンドで行なわれることに留意すべきである。それらのメニューオプションのコンテンツは定期的に更新され、顧客の固有の好み、並びにその購買の仕方及び音楽の聴き方に基づく。
【０２０７】
２．３．１．探索インタフェース
２．３．１．１．基本探索
基本探索は、MusicStationの音楽データベースへの迅速で強力なアクセスを可能にする。探索は、顧客がキーワード（又はキーワードの集合）を入力し、以下の１つで探索を更に向上することにより行なわれる： 
・アーティスト
・アルバム
・トラック
更に、探索をクラシック音楽以外のみ又はクラシック音楽のみに更に制限できる。デフォルトは先に使用された選択である。制限しない場合には、システムは双方を探索する。
【０２０８】
２．３．１．２．Advanced Search（高度な探索）
Advanced Search画面は、探索処理において広範でより精細な制御の採用を可能にする。Advanced Search画面を使用すると、以下により結果の集合をフィルタリングできる：
・アーティスト、アルバム又はトラック
・ジャンル
・チャートの位置（１位）
・最低の顧客評価
・言語
・国
更に、クラシック音楽に対して以下のフィールドを探索できる：
・作品タイトル
・アルバムのタイトル
・作曲者
・ソリスト／演奏者
・指揮者
・オーケストラ／合奏団
・レコード会社
２．３．２．MusicStationにおける探索をサポートする一般的原理
MusicStationの探索を作成する際に準拠する基本原理が１０個ある。本明細書において、それら原理はいくつかの例と共に適宜提供される。
【０２０９】
２．３．２．１．非英数字への非依存性
種々の顧客は、種々の方法で非英数字を使用する。例えば、顧客によってはアーティストのタイトルにおいて分離記号としてハイフンを使用するだろう。単純にスペースを使用する顧客もいる。モバイル環境において、非英数字を入力することは、扱いにくい場合があり、エラーを起こす傾向がある。従って、探索のために非英数字に依存せず、例として以下の全てが等価であると考える：
・s club 7
・s-club-7
・sclub7
２．３．２．２．大文字／小文字への非依存性
これは、単純に例えば以下のものが等価であることを意味する：
・s club 7
・S CLUB 7
・S Club 7
２．３．２．３．多国間の文字の種類を等価物として扱う
種々の顧客は、種々の方法で英語以外の文字を使用する。例えば、実際には以下を探索すべきである場合：
・Bjork
イギリス人は以下を探索するだろう：
・Bjork
MusicStationにおいて、探索システムが多国間の英字の種類を英語のアルファベットの等価物に対応させる（及びその逆も同様）ため、そのような不一致は問題ではない。
【０２１０】
２．３．２．４．数字を書かれた対応する数と同一として扱う（及びその逆も同様）
アーティストの探索において、顧客は、例えば「50 Cent」又は「Fifty Cent」と入力してもよい。双方ともシステムにより処理される。
【０２１１】
２．３．２．５．略語及び種々の単語の書き方は重要でない
内部マッピングテーブルにより、共通に使用される略語及び等価な表現が理解されることが保証される。従って、システムは、以下の全てのキーワードが等価であると考える：
・Boys to Men
・Boys 2 Men
・Boys II Men
同様に、「and」及び「&」は等価であると考えられる。
【０２１２】
２．３．２．６．「The」の正確な位置への非依存性
「The」が使用される方法に関して考慮しない。例えばシステムにとって、以下のキーワードは等価であるように見え、正確な結果が返される：
・The Rolling Stones
・Rolling Stones, The、又は単純に：
・Rolling Stones
２．３．２．７．顧客はキーワードの完全な集合を入力するとは限らない
「Rage Against the Machine」を探索する人は、キーワードとして単純に「Rage」と入力し、MusicStationが選択するのに賢明な結果の集合を返すことを期待するだろう。
【０２１３】
２．３．２．８．顧客は正確に単語を綴るとは限らない
主に完全に一致するものを探すが、顧客が単語の綴りを誤ることが多いことを理解している。他が全て失敗した場合、ファジー理論及び発音一致技術を使用して、アーティスト、アルバム又はトラックの探索を顧客に提案する。
【０２１４】
２．３．２．９．希望することを認識している場合、そこへ案内する
顧客が「rage against the machine」を探索し、その結果、１つの結果が返される場合、「Rage Against the Machine」のアーティストホームページに自動的に進む。クリックする必要がある単一のアーティストを含む結果の集合を顧客に提示しない。
【０２１５】
２．３．２．１０．システムの使用状況を学び、それに従ってシステムを最適化する
顧客が探索しているアーティスト名、アルバム名又はトラック名にはいくつかの形態が存在する可能性があり、それらは、データベースに格納される名前とは非常に異なる。新しい形態を探索キーワードにおいて見つけた時、それを目的のアーティスト名、アルバム名又はトラック名と対応させることができることを保証する構造が存在し、それにより、その形態を使用して後で行なわれる全ての探索が成功することを保証する。
【０２１６】
同様に、ソートする際、探索結果はその結果（顧客により再生される）の人気の知識を使用して、最も人気のあるもの（及び意図する探索に対して最適な結果）が最上位により近くなることを保証する。これは正確でないことがあるが、その場合、顧客は代わりにアルファベット順にソートされたビューを選択してもよい。
【０２１７】
２．３．３．探索処理
以下において、顧客がアーティスト探索に対する探索キーワードを入力する時点から探索処理を説明する。
【０２１８】
尚、以下の同一の原理がアルバム又はトラック探索に適用可能である。
【０２１９】
１）入力された探索キーワードの完全一致が探索されるが、第２．３．２節−MusicStationにおける探索をサポートする一般的原理−においてその概要が説明された基礎となる原理に基づく。
【０２２０】
２）アーティスト名内で探索キーワードの例を探索する。例えば、探索キーワード「BOB MARLEY」を仮定すると、有効な一致するものは以下の通りである：
ａ）「BOB MARLEY*」
ｂ）「*BOB MARLEY*」
ｃ）「*BOB MARLEY」
（ここで、*は任意の文字列を表す「ワイルドカード」である）
種類（ａ）の一致するものは、返される結果リストにおいて種類（ｂ）及び（Ｃ）の一致するものより高い優先度で表示される。
【０２２１】
（１）及び（２）が一致するものを１つのみ返す場合、アーティストのホームページ（並びにアルバムの場合はアルバムのホームページ及びトラックの場合はNow Playing画面）に直接移動する。
【０２２２】
あるいは、人気により及びその後アルファベット順に並べられた１）の一致するもの、次に２）の一致するものを一覧表示する。
【０２２３】
上記から一致するものを見つけた場合、探索ルーチンを抜ける。あるいは略一致するものに移る：
ステップ１）から４）を繰り返すが、ここではキーワードと同様に聞こえるか又は綴りが僅かに異なるものを見つけるために、発音及びファジー理論マッチングを使用してそれらステップを繰り返す。探索結果が厳密に一致したものではないことを顧客に明らかにするために、この処理から返される任意の一致するものの前にヘッダ「No exact matches found. Did you mean:」がある。結果の集合は、人気により及びその後アルファベット順に並べられる。
【０２２４】
２．３．４．結果から見つける
結果リストが大きい例において、顧客は「More popup」メニューの「Find」オプションを使用して更に特定の項目を探索し、リストをナビゲートして特定の文字列を探してもよい。顧客が実行依頼すると、その最初の存在が見つけられる。左側のソフトキーの「Next」オプションを使用することにより、次の結果に迅速に移動できる。
【０２２５】
２．３．５．探索の向上
「More popup」メニューのオプションを使用して、結果の集合のページから探索を向上できる。これが意味することは、ユーザが再び探索してもよい（基本探索又は高度な探索のいずれかで）が、探索キーワードボックス及び維持される事前に選択された全てのフィルタを使用して探索し、迅速な向上を可能にすることである。
【０２２６】
２．３．６．探索結果の集合の形式
探索の結果、探索結果の集合が返される場合、その集合の要素のカウントはページの右上に提示される。
【０２２７】
実際の結果自体の形式は、探索がアーティストに対するものか、アルバムに対するものか又はトラックに対するものかに依存して異なる。それら形式については、この節において更に詳細に説明する。
【０２２８】
２．３．６．１．アーティスト探索
上位のアーティスト名に一致したものが返され、システムにより測定されたアーティストの人気によりソートされる。同様の（しかし、より低い）人気の更なる一致するものが追従し、アルファベット順にソートされる。
【０２２９】
２．３．６．２．アルバム探索
アルバム探索は以下の形式で結果を返す：
アルバム名−アーティスト名（発売された年）
「発売された年」を有することにより、例えば再発売されたアルバム（特典又は最新のトラックを含む）が元のアルバムと容易に区別できることを保証する。
【０２３０】
上位の一致するものが返され、システムにより測定されたアルバムの人気によりソートされる。同様の（しかし、より低い）人気の更なる一致するものが追従し、アルファベット順にソートされる。
【０２３１】
２．３．６．３．トラックの探索
トラックの探索は、以下の形式で結果を返す：
トラック名−アーティスト名（トラックの長さ）
「トラックの長さ」（mm:ss）を有することにより、同一名の（しかし、長さが異なる）トラックを区別できることを保証する。これは、種々のアルバムにおいてミキシングし直した場合に発生することが多い。
【０２３２】
尚、ここでアルバム名を有することは、厳しく制限された環境において結果として得られる文字列の全長のために不必要で望ましくないと考えられる。また、同一のトラックが種々のアルバムに現れる場合、そのトラックは１度のみ返される。
【０２３３】
上位の一致するものが返されて、システムにより測定されたトラックの人気によりソートされる。同様の（しかし、より低い）人気の更なる一致するものが追従し、アルファベット順にソートされる。
【０２３４】
２．３．７．Find in playlists（プレイリストから見つける）
システムの適切な時点で、トラックが参照されている時、顧客は「More popup」オプション「Find in playlists」を使用することにより、プレイリスト内のそのトラックを探索できる。他のMusicStationの顧客と共有される（又はシステムが公開する他のプレイリストに含まれる）プレイリストのリストが返され、人気によりソートされる。
【０２３５】
２．４．複数言語のサポート
本明細書において、特定の装置、サービス及びクライアントバージョンに対してクライアントビルドを構築するためにメッセージを管理及び使用する方法を説明する。
【０２３６】
２．４．１．開発
開発によりリリースされた各クライアントバージョンは、クライアントにより使用されるデフォルトのメッセージの集合を有する。このメッセージ集合は、開発者によるリリースの開発中保持される。メッセージ集合の各メッセージは、クライアントのいずれかの場所に現れるテキスト又はラベルである。メッセージのプロパティを示す図２７を参照する。
【０２３７】
メッセージは、次に利用可能なmessage_indexを有するmessage_set_itemにレコードを追加することによりデフォルトのメッセージ集合に追加される。メッセージの指標は、メッセージ集合のメッセージにアクセスするためにソースコードにおいて使用される。指標は、Messageオブジェクトの定数として定義される。
【０２３８】
public static int OPEN_LABEL_INDEX = 104;
この定数は、現在選択されている言語のメッセージを取得するために使用される。
openCommand.setLabel(messageSet.getMessage(OPEN_LABEL_INDEX));
このメッセージ集合は、クライアントバージョンのデフォルトのメッセージ集合としての集合である。ビルドにパッケージされた画像は、デフォルトの画像集合において定義される。画像は、画像の役割に基づいてその集合から選択される。画像のプロパティを示す図２８を参照。クライアントバージョンは、デフォルトのメッセージ集合及び画像集合を含んでリリースされる。クライアントバージョンのプロパティを示す図２９を参照。
【０２３９】
２．４．２．クライアントバージョンリリース
以下のレコードは、開発からビルドシステムまでクライアントバージョンリリースにパッケージされる：
・デフォルトのメッセージ集合及びメッセージ集合の項目
・デフォルトのメッセージ集合により使用されるメッセージ及びメッセージキー
・英語のメッセージ言語及び任意の他のテスト言語
・デフォルトの画像集合及び画像集合の項目
・デフォルトの画像集合により使用される画像
２．４．３．メッセージの翻訳
翻訳されたメッセージは、随時ビルドシステムにロードされる。言語は、デフォルトのメッセージ集合の各メッセージがその言語に対するメッセージ言語を有する時にビルドユーザにより選択可能である。翻訳されたメッセージを示す図３０を参照。
【０２４０】
サービスメッセージにメッセージを追加する時、メッセージ言語レコードがサービスによりサポートされる全ての言語に対して存在することを実現する。同様に、ビルドユーザがそのサービスと共に使用する装置を選択する場合、全ての装置メッセージがサービスによりサポートされる全ての言語に対してメッセージ言語を有することを保証する。
【０２４１】
クライアントビルドが複数の言語に対して構築されるが、ＪＡＲには１つのアイコン、ロゴ及びスプラッシュスクリーンしか含めることができないため、画像の翻訳は必要ない。サービスに対して規定された画像は、そのサービスに対するデフォルトの言語の画像である。
【０２４２】
２．４．４．装置メッセージ
メッセージ集合は装置に対して規定される。これにより、選択された装置に対するデフォルトメッセージ集合のメッセージを無効にできる。装置メッセージのプロパティを示す図３１を参照。
【０２４３】
例えば、ヘルプメッセージは特定の装置に固有であってもよい。装置メッセージ／ヘルプメッセージのプロパティを示す図３２を参照。ビルド時、選択された装置に対して規定されるメッセージは、同一のメッセージキーを有するデフォルトメッセージ集合のメッセージより優先される。
【０２４４】
２．４．５．サービスメッセージ
メッセージはサービスに対して規定される。実際にはメッセージが装置及びサービスの双方ではなく装置別であるか又はサービス別であるべきであるが、それらメッセージはデフォルト及び装置メッセージ集合より優先される。サービスメッセージを示す図３３を参照。
【０２４５】
サービスは、デフォルト言語及びサービス言語の集合を更に有する。それらは、クライアントビルドに対してサポートされる言語及びデフォルト言語として設定されるが、ビルドが異なるデフォルト言語又は言語の部分集合のみを必要とする場合、ビルドユーザはビルドを行なう前にそれら言語を編集できる。
【０２４６】
２．４．６．サービス及び装置別メッセージ及び画像
いくつかの例においては、メッセージ又は画像が特定の装置及び特定のサービスに固有であることを指定したい。例えば、装置の集合において手動でサイズ変更されたサービスアイコンを使用したい場合がある。サービス及び装置別メッセージを示す図３４を参照。
【０２４７】
２．４．７．メッセージの代入
データベースにおいて参照されるサービス又は装置の任意のプロパティが、デフォルトのメッセージ集合に代入可能である。例えば、カスタマーサポート電話番号を代入することである。
To get help please call $ {service.company.companyAddress.customerSupportTelephone}
デフォルトのメッセージ集合は代入をサポートし、これはビルドユーザから隠蔽される。デフォルトメッセージを閲覧する場合、電話番号が既に代入されている。装置及びサービスメッセージも代入をサポートする。装置及びサービスメッセージを管理するツールは、ビルドユーザから構文を隠蔽すべきである。代入された値が装置又はサービスに対して定義されていない場合、ビルドユーザは、ビルドが開始する前に値を設定する必要がある。
【０２４８】
２．４．８．クライアントビルド
ユーザは、クライアントバージョン、装置及びサービスを選択している。バージョンに対するデフォルトのメッセージ集合は、ビルドに対して選択されるメッセージに基礎を提供する。装置及びサービスメッセージ集合は、それらメッセージより優先される。従って、service_deviceメッセージ集合において指定された任意のメッセージは、それらメッセージより優先される。
【０２４９】
このビルドに対して選択された言語は、サポートされる言語に対するメッセージ言語レコードをフィルタリングするのに使用される。クライアントビルドメッセージは、各言語の各メッセージに対して作成され、このビルドに対するクライアントビルドメッセージテーブルにコピーされる。クライアントビルドメッセージを示す図３５を参照。
【０２５０】
ビルド時にメッセージのコピーをとることにより、以下のことが可能なる：
・行われた代入のレコードを保持する
・ロックされたメッセージを複製する必要なくメッセージを更新する
クライアントビルド画像はデフォルトの画像集合の各画像に対して作成され、サービス画像集合の任意の画像はそれら画像より優先される。従って、service_device画像集合において指定された任意の画像はそれら画像より優先される。それら画像はサイズ変更され、名前が変更され、ＪＡＲにパッケージされる。クライアントビルドメッセージ及び画像は、クライアントビルド定義の一部を形成し、クライアントビルドがプロダクションサーバに対して発行される時にプロダクションサーバに発行される。
【０２５１】
２．４．９．クライアントビルドの発行
各クライアントビルドに対して、以下のメッセージ関連テーブルがプロダクションシステムにリリースされる：
・Client_build：このクライアントビルドに対するレコード
・Client_build_message：このクライアントビルドに対するレコード
・Message：client_build_messageにおいて参照される各メッセージ
・Message_key：各メッセージに対するキー
・Message_lang：サポートされる各言語の各メッセージに対するmessage_lang
・Client_build_image：このクライアントビルドに対するレコード
・Source image files：client_build_imageにおいて参照される各画像ファイル
２．５．ローミングネットワークの選択
電話機が「Roaming」である場合、ユーザには、MusicStationを使用する時に追加の課金がなされる。それら課金は、電話がローミング中にユーザがトラックをダウンロードした時又はMusicStationがメニュー項目及び画像を更新した時に適用される。ユーザは、MusicStationに対するローミング挙動を設定できる。
【０２５２】
２．５．１．ローミング挙動の設定
画面キャプチャ−Roaming optionsを示す図３６を参照する。MusicStation内で、ユーザはMusicStationに対するローミング挙動を設定できる。図３７を参照。Menu & picture updatesに対するローミング挙動がAskに設定される場合、所定のセッション中にローミングしている間のダウンロード、更新及び追加の課金を許可／拒否するかを問う警告メッセージが示される。画面キャプチャ−Roaming Warningsを示す図３８を参照。
【０２５３】
ユーザがローミング中にトラックをダウンロードしようとし、トラックに対するローミング挙動がAskに設定される場合、ローミング中のダウンロード、更新及び追加の課金を許可／拒否するかを問う警告メッセージが示される。許可／拒否のこの動作は、現在のセッションに対する設定値を設定する。画面キャプチャ−Roaming Warnings−Ask promptを示す図３９を参照。
【０２５４】
２．５．２．Roaming Warnings and Errors（ローミング警告及びエラー）
有料動作は、以下の２つのカテゴリに分類される：
・Track Downloads−オーディオファイルのダウンロード
・Menu and picture updates−メニューの更新は、Chart listings、You might like recommendations、Cool members及びBuzz playlists等の項目を含む。Buzzプロファイル上の変更画像等の写真の更新又はアーティスト及びアルバムプロファイルに対する新しい画像のダウンロード。
【０２５５】
以下の処理は、MusicStationの新しいセッション毎に接続された各有料動作に対して行なわれる。
・サーバは、クライアントから到着する全ての要求の応答ヘッダを検査する必要がある。
・ローミングが検出され、ユーザが有料動作を選択する場合、Optionsメニューのその種の動作に対するローミングオプションの集合を検査する。
・その動作がRoaming optionsメニューにおいてOn（許可）とマーク付けされる場合、動作は通常通り実行される。
・その動作がRoaming optionsメニューにおいてOff（未許可）とマーク付けされる場合、ポップアップが表示され、ブロックされたことを説明する。
・その種の動作がRoaming optionsにおいてAskとマーク付けされる場合、セッションにおいて初めてその種の動作が選択されると、Roaming Warningが表示される。後続する動作は、ユーザが提供される回答に基づいて処理される。
【０２５６】
２．５．３．Roaming Warnings（ローミング警告）
２．５．３．１．Askに設定されたRoaming Options
有料動作がRoaming OptiosメニューにおいてAskに設定される場合、以下のRoaming Warningが表示される。ユーザは、ローミング中のその種の有料動作に対する設定値を選択するように指示される。画面キャプチャ−Roaming Warning−Ask promptを示す図４０を参照。
・ユーザがDon't Allowを選択した場合、この領域の全ての後続する動作は、このセッションの残りの間又はReset Locationが選択されるまでローミングエラーを表示する。
・ユーザがAllowを選択した場合、この領域の全ての後続する動作は、このセッションの残りの間又はReset Locationが選択されるまで更なる指示なしで進む。
・ユーザがTerms & Conditionsを選択した場合、ＷＡＰページはMusicStationの使用に関する条件を表示する。ＷＡＰブラウザを閉じることにより、上記指示の際のMusicStationに戻る。
ユーザがホームネットワークに戻ると迅速に、この警告は表示されなくなる。
【０２５７】
２．５．３．２．Onに設定されたRoaming Options
有料動作がRoaming OptionsメニューにおいてOnに設定される場合、ユーザがローミングセッション中に有料動作を初めて実行した時に以下のRoaming Warningが表示される。ユーザは、過去にローミング基本設定を設定してあり、それら有料動作を許可したことを忘れている可能性がある。画面キャプチャ−Onに設定されたRoaming Optionsを示す図４１を参照。
【０２５８】
ユーザは、トラックのダウンロード又はメニュー及び写真の更新に対して課金されることを警告される。トラックのダウンロード及び／又はメニュー及び写真の更新が開始する。これらオプションは、Roaming optionsメニューにおいて変更できる。
【０２５９】
２．５．３．３．Offに設定されたRoaming Options
有料動作がRoaming optionsメニューにおいてOffに設定される場合、ユーザがローミングセッション中に有料動作を初めて実行した時に以下のRoaming Warningが表示される。画面キャプチャ−Offに設定されたRoaming Optionsを示す図４２を参照。
【０２６０】
ユーザは、トラックのダウンロード及び／又はメニュー及び写真の更新が開始されないことを警告される。これらオプションは、Roaming optionsメニューにおいて変更できる。
【０２６１】
２．５．４．ローミングの検出
以下の処理は、電話がローミングしていることをMusicStationが検出する方法を記述する。
・MusicStationのクライアントからサーバへの全てのＨＴＴＰ要求は、ＭＮＯのゲートウェイを通過する。
・特定の情報をヘッダに追加するようにゲートウェイを設定した。例えば：
X-WSB-Identity:$(MSISDN); X-TELENOR-SGSN:$(RADIUS:SGSN-IP-Address); X-bearer:$(BEARER_TYPE)
・ここでは、第２のフィールドはＳＧＳＮのＩＰアドレスである。それは、ハンドセットが通信する時に介するゲートウェイのＩＰアドレスである。
・このＩＰアドレスとＭＮＯネットワーク上のゲートウェイのＩＰアドレスのリストとを比較する。
・ＩＰアドレスがそのリストにない場合、それはハンドセットがローミングしていることを意味する。
サーバは、リストのＩＰアドレスをルックアップすることによりその評価を行なう。サーバは、ローミングしていると決定した場合、クライアントにその状態をプッシュし、クライアントは規則及び２．５．２．Roaming Warnings and Errorsで説明したユーザ指示により実行する。
【０２６２】
３．コミュニティ機能
個々の能力でサーバと対話するというエンドユーザの能力に加え、クライアント及びサーバは、ユーザが他のユーザと対話できる特定のコミュニティ機能性を更に提供する。各ユーザは、個々のプロファイルを作成し、「友人」要求を他のユーザに送出し、その後アーティスト、アルバム又は個々のトラックによるプレイリスト又は推薦を確定された「友人」に送出する能力を有する。
【０２６３】
３．１．登録
コミュニティ機能に参加する第１のステップは、コミュニティ環境（Buzzとしても周知である）内に固有のプロファイルを登録するようにユーザに要求することである。
【０２６４】
３．１．１．規定されたメンバ名なし
ユーザがコミュニティ機能にアクセスを試みるが、ユーザがBuzzユーザ名を登録していない場合、Buzzホームページは、Buzzに登録するようにユーザに招待状を表示する。メンバ名のみが必須フィールドである：
・customer_preference.nickname
更に、ユーザはオプションでキャッチフレーズを入力でき且つ／又はアバターとして画像を選択できる：
・customer_preference.catchphrase
・customer_preference.avatar_image_id
メンバ名がそのサービスにおいて一意であり、罵倒語のフィルタを通過した場合、Buzzホームページはそのメンバに対して新しく規定された詳細を示す。
【０２６５】
メンバ名がそのサービスにおいて一意でない場合、クライアントは画面に戻り、ユーザが入力したメンバ名をそのユーザに対して提案されたメンバ名で置換し、受け入れるか又は変更する。ユーザがメンバ名を提供した場合、Buzzホームページは、そのメンバに対する先の詳細、並びにユーザの確定された友人のカウント及び共有プレイリストを聴いた回数を示す：
・Customer_count.friend_count
・playlist_count.play_count
３．１．２．規定されたメンバ名
ユーザがメンバ名を提供した場合、Buzzホームページはそのメンバに対する詳細を示す。
・customer_preference.nickname
・customer_preference.avatar_image_id
・customer_preference.catchphrase
・customer_data.calculated_rating
・Customer_count.friend_count（customer_to_customerのカウント。ここで、customer_id = ${customerId}且つcustomer_to_customer.friend_status = APPROVEDである）
・play_count_otherplaylist（playlist_count.play_countの合計。ここで、playlist.owning_customer_id = ${customerId}である）
評価は、人気から算出される。アルゴリズムは、２．２．推薦に含まれる。
【０２６６】
メニューオプションは、共有プレイリスト及びこのメンバにとって興味のある評価されたコミュニティメンバ（３．４．Buzz Cool Members）にアクセスできるようにする。更にメニューオプションは、ユーザ自身のプレイリスト及び友人（３．６．１．Buzz Friends）にアクセスできるようにする。
【０２６７】
３．２．Edit My Profile
ユーザがプロファイルを編集することを可能にする状況依存メニューを介するオプションが存在する。これは、Buzzプロファイル画面に表示され、適切なオプションが設定された場合に他のメンバにより閲覧可能である。そのオプションは、ユーザがBuzz Main画面内の状況依存メニューから「Edit My Profile」オプションを選択した時に表示される。ユーザは、メンバ名、キャッチフレーズ、画像及び以下の閲覧オプションを編集できる：
・Show Profile−これは、このメンバのプロファイルが他のメンバに対して可視であるかを制御する。デフォルトはYesである。
・Show my top tracks−これは、このユーザのお気に入りのアーティストがメンバプロファイル画面に一覧表示されるかを制御する。デフォルトはYesである。
【０２６８】
３．３．Shared Playlists（共有プレイリスト）
メニューオプションにより、このユーザにとって興味のある共有プレイリストにアクセスできる。「You Might Like」プレイリストは、推薦エンジンによりこのユーザのために選択された他のユーザの共有プレイリストである。２．２．推薦を参照。クライアントは、共有プレイリスト毎に共有プレイリスト名、星評価及びプレイリストを作成したメンバを表示する：
・playlist.name
・playlist.owning_customer_id
・customer_info.recommend_playlist_set_id
・playlist.image_set_id
・playlist_data.calculated_rating
３．４．Buzz Cool Members
メニューオプションにより、このメンバにとって興味のあるメンバにアクセスできる。「You Might Like」メンバは、このメンバに類似する他のメンバである。このリストが作成される方法の詳細は、２．２．推薦を参照。ここで、Edit My Profile画面上で「Show Profile」オプションを設定し且つユーザの既に確定された友人でないメンバのみが、以下の詳細と共に一覧表示される：
・customer_preference.nickname
・customer_preference.avatar_image_id
・customer_info.recommend_customer_set_id
・customer_data.calculated_rating
・所有するcustomer_id = ${recommendedCustomerId}であるプレイリストのカウント
３．５．別のメンバプロファイル
ユーザは、MusicStatonサービスの別のメンバの詳細を閲覧できる。メンバがメンバのリスト（例えば、３．４．Cool Members画面）から開かれる場合、プロファイルの面が表示される。この画面は、Buzzにまだ加入しておらず且つ少なくともメンバ名を設定していないメンバに対して示されることはない。ビューは、共有しているメンバの全てのプレイリストのリストを含む。それらのうち１つを開くことにより、プレイリストを表示する。
【０２６９】
画面は、プレイリスト毎に、そのプレイリストのトラックが予備再生されて聴かれた回数及び評価を示す。共有プレイリストがない場合、メッセージ「This member has not yet shared any playlists（このメンバは共有プレイリストを持ってません）」がShared Playlistsの表題の下でこのセクションに表示される。
【０２７０】
更に、他のメンバの上位のトラックのリストが表示される。このセクション（タイトルを含む）は、この画面に表示されているメンバが３．２．Edit My Profile画面上で「Show my top tracks」フラグを設定した場合にのみ示される。リストは、このメンバの上位５つのトラックを表示する。これは、このメンバにより過去最も再生された上位５つのトラックであり、最も人気のあるものが最上部に表示される。ユーザは、それらトラックの任意のトラック上でPlayを選択できる。含まれるフィールドは以下の通りである：
・customer_preference.nickname
・customer_preference.avatar_image_id
・customer_preference.catchphrase
・customer_data.calculated_rating
・play_count_otherplaylist（playlist_count.play_countの合計。ここで、playlist.owning_customer_id = ${customerId}である）
・Customer_count.friend_count（customer_to_customerのカウント。ここで、customer_id = ${customerId}且つcustomer_to_customer.friend_status = APPROVEDである）
・playlist.name
・playlist_data.calculated_rating
・playlist_count.play_count
・playlist.image_set_id
３．６．Buzz Add as Friend
この画面は、メンバが選択された任意の状況依存メニューから「Add as Friend」をユーザが選択した時に表示される。ユーザは、友人要求の一部としてメッセージを送出できる。
【０２７１】
Add as Friendオプションがメンバに対して選択され、メンバがこのユーザの友人でない場合、友人要求の画面は、友人要求の送出先のメンバの名前に対するフィールド及びメンバが誰でであるかの紹介として他のメンバに送出されるテキストを入力できるテキスト本文に対するフィールドと共に表示される。フィールドは以下を含む：
・customer_preference.nickname
・customer_to_customer_request.body
３．６．１．My Friends
「My Friends」メニューオプションは、このメンバの友人のリストを表示する。ユーザが友人を有さない場合、これはメッセージ「Your list of friends will be shown here（友人のリストはここに表示されます）」を表示する。更に、このメンバの保留中の友人要求のリストが表示される。このタイトル及びリストは、保留中の要求がない場合には示されない。フィールドは以下を含む：
・customer_to_customerのカウンタ。ここで、customer_id = ${customerId}且つcustomer_to_customer.friend_status = APPROVEDである。
【０２７２】
・from customer_to_customer_request。ここで、friend_status = REQUESTEDである。
【０２７３】
３．６．２．Add Friend by Name（名前による友人の追加）
ユーザは、「Add Friend by Name」メニューオプションを選択して、プロファイル名で別のユーザを追加できる。このオプションは、このユーザがBuzz登録を行ない且つメンバ名を登録した場合にのみ利用可能である。ユーザは、友人のメンバ名を入力して友人要求を送出する必要がある。フィールドは以下を含む：
・customer_preference.nickname
・customer_to_customer_request.body
メンバが「send」を選択し、その名前のメンバが見つかった場合（そのメンバがShow Profileオプションを設定しているか否かに関わらず）、確認メッセージが表示される。メンバが「send」を選択し、その名前のメンバが見つからない場合、ユーザは通知され、メンバ名を再入力するように要求される。メンバが「send」を選択し、そのメンバが既にこのユーザの友人である場合、ユーザはその結果を再び通知される。
【０２７４】
３．６．３．Add Friend by Telephone Number（電話番号による友人の追加）
この画面は、ユーザが「Add Friend by Number」オプションを選択した時に表示される。ユーザは、友人要求を送出する送出先の友人の電話番号を入力する必要がある。ユーザは国番号なしで入力すると仮定され、デフォルトの国番号はサービスが関連付けられている国の国番号である。フィールドは以下を含む：
・customer_person.mobile_msisdn
・customer_to_customer_request.body
メンバが「send」を選択し、その名前のメンバが見つかった場合（そのメンバがShow Profileオプションを設定しているか否かに関わらず）、確認メッセージが表示される。メンバが「send」を選択し、その名前のメンバが見つからない場合、ユーザは通知され、メンバ名を再入力するように要求される。メンバが「send」を選択し、そのメンバが既にこのユーザの友人である場合、ユーザはその結果を再び通知される。
【０２７５】
３．７．トラック又はプレイリストの送出
この画面は、ユーザが状況依存メニューのいずれかにおいて「Send to Friend」オプションをトラック又はプレイリストに対して選択した時に表示される。ユーザは、トラック又はプレイリストを送出する送出先の１人以上の友人を選択してもよい。ユーザは、自身のメンバ名を設定し、Send to Friendオプションに対して少なくとも１人の友人を有効にする。フィールドは以下を含む：
・mail_attachment.track_id
・customer_preference.nickname
・customer_mail.customer_id
・mail.body
このメンバの友人のリストが表示される。ユーザは、選択するために友人をクリックし、選択解除するために再びクリックする。任意の数の友人が選択されてもよい。評価、友人の数及び聴いた回数が友人毎に表示される。sendを選択すると、確認メッセージが表示され、ユーザは初期画面に戻る。
【０２７６】
３．８．メッセージの送出
クライアントは、コンテンツＩＤの追加なしでメッセージを送出する機能を更に有する。メッセージ画面は以下のフィールドを表示する：
customer_mail.customer_id
customer_preference.nickname
mail.body
３．９．Who's Listening
この画面は、ユーザがメニューのいずれかにおいてトラック、アルバム、アーティスト又はプレイリストに対してMoreメニューから「Who's Listening」オプションを選択した時に表示される。画面は、このユーザがWho's Listeningオプションを選択した項目を最も最近再生したBuzz登録済みの１０人のメンバを表示する。表示されるものは、以下のようにオプションが選択されたオブジェクトの種類に依存する：
・トラック−そのトラックを最も最近再生した１０人のメンバ
・アルバム−そのアルバム中のトラックを再生した１０人のメンバ
・アーティスト−そのアーティストによるトラックを最も最近再生した１０人のメンバ
・プレイリスト−そのプレイリストのトラックを最も最近再生した１０人のメンバ
フィールドは以下の通りである：
・customer_track order by last_play_date
・customer_release order by last_play_date
・customer_artist order by last_play_date
・customer_playlist order by last_play_date
３．１０．Inbox
他のユーザからのメッセージ及び推薦を含むユーザに対する全てのメッセージを表示する「Inbox」がコミュニティビューに含まれる。
【０２７７】
３．１０．１．到着するInboxトラック推薦メッセージ
メンバがこのユーザにトラックを送出した時、以下の定義されたフィールドを含むメッセージがInboxに現れる：
・mail.kind = MESSAGE
・mail.from_customer_id
・mail.sent_date
・mail.kind = TRACK RECOMMENDATION
・mail.from_customer_id
ユーザがメッセージを選択することにより開くと、メッセージ画面は以下のフィールドを含んで表示される：
・mail.from_customer_id
・customer_preference.avatar_image_id
・mail.sent_date
・mail_attachment.track_id
推薦されたトラック名、アルバム名、アーティスト名又はプレイリスト名がメッセージ中に強調表示され、ユーザがメッセージをスクロールすると、後続する各々が強調表示される。トラック名をクリックすると、ユーザがトラックリストのトラックに対してAdd to Playingを選択した時と同様の挙動を行なう。すなわち、トラックは現在のプレイリストの末尾に追加され、表示されるポップアップはユーザにそのことを通知する。
【０２７８】
３．１０．２．到着するInboxプレイリスト推薦メッセージ
メンバがこのユーザにプレイリストを送出した時、以下を含むメッセージがInboxに現れる：
mail.from_customer_id
mail.kind = PLAYLIST RECOMMENDATION
mail_attachment.playlist_id
ユーザがメッセージを選択することにより開くと、メッセージ画面は以下のフィールドを含んで表示される：
・mail.from_customer_id
・customer_preference.avatar_image_id
・mail.sent_date
・mail.body
・mail_attachment.playlist_id
３．１０．３．到着するInbox友人要求メッセージ
別のメンバがこのメンバに対して友人要求を行なった場合、メッセージがこのメンバのInboxに現れる。開かれた時に、承認又は否認する機会を得る。ユーザが対話を要求されているため、これはポップアップ内で行なわれる。メッセージの表題は以下を表示する：
・customer_to_customer_request.to_customer_id
・customer_to_customer_request.friend_status = REQUESTED
メッセージを開くことにより、以下が表示される：
customer_to_customer_request.to_customer_id
customer_to_customer_request.body
継続することを選択すると、以下のオプションを含むポップアップが表示される：
・Approve−友人要求の場合にのみ強調表示される（殆どのInboxの項目に対してこのオプションが関連していないため淡色表示しない）
・Deny−友人要求の場合にのみ強調表示される
・Block−友人要求の場合にのみ強調表示される
・Report Abuse−友人要求の場合にのみ強調表示される
ユーザ応答は以下に格納される：
・customer_to_customer_request.response（APPROVED, DENIED, BLOCKED, ABUSED）
３．１０．４．到着するInbox友人要求応答
メンバがこのユーザからの友人要求に応答する場合、応答はこのメンバのinboxに現れる。他方のメンバが友人要求を受け入れたか、拒否したか又はブロックしたかに依存して、このメンバが見る可能性のある応答は３つある：
・customer_to_customer_request.friend_status
図４３の表は、応答のタイトル、コンテンツ及び結果を示す。
【０２７９】
３．１０．５．到着するInboxテキストメッセージ
テキストメッセージは、Inboxに同様に表示され、関連するフィールドは以下の通りである：
・mail.from_customer_id
・customer_preference.avatar_image_id
・mail.sent_date
・mail.body
３．１１．一般的なメッセージ警告及び有効期限
３．１１．１．メッセージ警告
１つ以上のメッセージがメンバに対して到着した場合、画面の下部に１つの小さなポップアップを表示する。ポップアップは、到着したメッセージのグループ毎に１度表示され、サーバがそれらメッセージをクライアントに渡すと迅速に表示される。次のメッセージはチェックされ、ユーザフローを中断しないようにクライアントがNow Playing画面に戻ってから２秒後に表示される。現在のプレイリストが存在しない場合、ポップアップは、現在のプレイリストがあった場合にクライアントが戻ると考えられる時から２秒後に表示される。１つのポップアップが読まれ且つ確認された後、このセッション中にそれ以上メッセージが到着する場合は別のポップアップが表示される。従って、このメンバがオフラインの時に送出されたメッセージは、アプリケーションを開始した後迅速に表示される可能性が高い。
【０２８０】
３．１１．２．メッセージの有効期限
読まれたメッセージは、読まれた後１日で期限切れとなる。未読のメッセージは、ユーザがその存在を警告された後５日で期限切れとなる。未読のメッセージは、ユーザがアプリケーションにおらず且つそのためにその存在を警告されない場合は３０日で期限切れとなる。期限切れとなったメッセージは、適宜Inboxから除去される。有効期限が正確に守られるかは重要ではない。例えば、期限が切れた後の次のセッション開始時にそれらメッセージがInboxから除去されてもよい。従って、追加のフィールドは、メールが受信される日付に対して定義される：
・customer_mail.received_date
４．グラフィカルユーザインタフェース（ＧＵＩ）機能
付録１において、ＧＵＩを説明する。
【０２８１】
５．通信アーキテクチャ
５．１．mCom
５．１．１．概要
MusicStationのクライアントアプリケーションは、種々のデータをダウンロード及びアップロードするためにMusicStationサーバに接続するように要求される。MusicStationがサーバに接続するために使用するプロトコルは、Java、Symbian及びWindows(登録商標) Mobile等の種々のクライアント技術において実現可能である必要がある。また、文献「Connected MusicStaton Issues and Requirements」で説明される課題を解決する必要がある。
【０２８２】
５．１．１．１．プロトコルの歴史
MyFoneは、データを転送するためにＨＴＴＰを使用していた。この経験は、ＨＴＴＰ要求及び応答がオペレータゲートウェイを介して渡される必要があるといういくつかの課題を明らかにした。オペレータゲートウェイ及び種々の移動電話は、通常はＨＴＴＰヘッダの転送の失敗によりＨＴＴＰヘッダに度々妨害を与えた。これは、このプロトコルを作成することになった重要な要因の１つである。
【０２８３】
１つの応答でいくつかのファイルを転送するために、このプロトコルはＭＩＭＥから名案を得た。この文献の初期の改訂版は、応答の中の種々のファイルを分離するためにＭＩＭＥのような境界を使用した。これは、ヘッダ中のオフセット及び長さ表記を使用するように変更された。これにより、クライアントはデータオブジェクトに迅速にアクセスできる。本文のコンテンツではなく、ヘッダのみが解析される必要がある（第３．２．７節を参照）。
【０２８４】
以前、状態コードは、年配のクライアントにより理解され且つ拡張可能にするためにバイナリ表現を使用していた。これは、それらクライアントだけでなく人間により容易に理解できる整数値を使用するように簡略化された。最適な状態コードをクライアントに送出するサーバは、新しい状態コードを導入するという課題に対処する。サーバは、接続されたクライアントバージョンが理解する状態コードのみを送出する。
【０２８５】
以前は、同一ファイルがセッション中に数回要求された場合、あるいはデータファイルが送出されたセッションと異なるセッションで肯定応答が送出された場合、肯定応答を一意に識別することは不可能であった。Sent行及びPut行で使用される肯定応答ＩＤ原理はこの課題を解決する。
【０２８６】
５．１．１．２．プロトコルの概要
クライアントは、移動電話がインターネットに接続する方法のために全ての通信を開始する必要がある。移動電話が固定ＩＰアドレスを有さず、通常はモバイルオペレータゲートウェイを介して接続するため、サーバが通信を開始することはできない。ＭＩＤＰ２．０ハンドセットは、クライアントがサーバに要求を行なうことを要求するアプリケーションにＳＭＳを送出するためにPush Registry機能性を使用できる。しかし、この機能性は全ての対象のハンドセット及びクライアントプラットフォームにおいて利用可能でない可能性があるため、MusicStationプロトコルは通信を開始するクライアントに基づくべきである。
【０２８７】
プロトコルは、ＨＴＴＰ及びＴＣＰ／ＩＰソケット接続を介して実行可能である必要がある。それらは、クライアントプラットフォームにより利用可能にされた最も一般的な利用可能な２つの接続である。プロトコルは、高信頼トランスポート層を仮定する。プロトコルは、特定の応答の個々のパケットを再要求できる必要はない。従って、ＵＤＰソケット接続はサポートされる転送機構ではない。低信頼トランスポート層をサポートするには、MusicStationプロトコルにおいて多くの追加の機能性が必要であり、ＴＣＰはＵＤＰを有する全てのクライアントで利用可能である。
【０２８８】
プロトコルは、サーバにデータを転送するクライアント及びサーバからのデータに対する要求を行なうクライアントをサポートできる必要がある。これは、エラーデータ、ログデータ、使用データ、プレイリスト情報及びユーザ関連データがクライアントからサーバに転送可能になるために必要とされる。
【０２８９】
MusicStationは、要求／応答プロトコルであるためＨＴＴＰにおいて厳密にモデル化され、ＨＴＴＰ機能のいくつかを流用する。MusicStationプロトコルは、ＡＳＣＩＩ文字セットのみを使用するテキストを使用し、そのため、バイナリデータに関連する符号化の問題なく、多くの種々のクライアントプラットフォームにおいて実現される。
【０２９０】
以下の図は、クライアントとサーバとの間の要求／応答フローを示す。これは、サーバにより実行されるクライアントからの単純な要求の一例である。全てのクライアント／サーバ通信は、この同一の基本的な方法で行なわれる。クライアントとサーバとの間の要求／応答フローを示す図４４を参照。
【０２９１】
次の図は、サーバがクライアントに要求を送出する方法を示す。クライアント／サーバ通信が常にクライアント要求によりトリガされるため、サーバがクライアントから要求を行なう唯一の方法は、サーバがクライアントに送出する応答において要求をピギーバックすることである。サーバがクライアントに要求を送出することを示す図４５を参照。
【０２９２】
尚、通常の動作において、応答にデータがない場合でも、サーバはクライアント要求に常に応答する。応答は、状態コードのみを含んでもよい（「サーバ「応答」プロトコル」の節を参照）。要求数／分の閾値を超える要求及びロボットクライアントは通常の動作ではなく、サーバは、それら要求に応答する義務はない。サーバ応答を受信しない実際のクライアントは、適当な時間後に要求を再試行すると予想される。
【０２９３】
ＨＴＴＰと同様に、MusicStationプロトコルは、転送される実際のデータを含むメッセージの本文に関するメタデータを保持するのにヘッダを使用する。本明細書において、それらヘッダに関してプロトコルを説明する。メッセージの本文は、種々のクライアントの実現によって異なる。ＨＴＴＰと同様に、ヘッダ及び本文は空行により分離される。
【０２９４】
５．１．２．クライアント要求プロトコル
５．１．２．１．ヘッダ
５．１．２．１．１．プロトコル識別子
任意の要求の第１の部分は、プロトコル識別子である。そのため、その要求を受信するサーバは、受信したデータが実際にクライアントからのものであることを確認できる。プロトコル識別子は短いため、要求に対してオーバヘッドを与えない。MusicStationにより使用されるプロトコル識別子は以下の通りである：
MSTP
これは、MusicStation伝送プロトコルを意味する。
【０２９５】
５．１．２．１．２．プロトコルバージョン番号
プロトコル識別子の他にプロトコルバージョン番号がある。このプロトコル識別子は、クライアントバージョン番号、サーババージョン番号及びクライアントバージョン番号により使用されるデータオブジェクトとは完全に分離される。
【０２９６】
同一のプロトコルバージョン番号を使用するクライアントアプリケーションのバージョンは多く存在する。
【０２９７】
プロトコルバージョン番号は、major.minorの形式である。minor番号は、プロトコルに対する漸進的な変更に対して増加され、major番号は、プロトコルに対する大幅な変更と共に増加する。プロトコルの初期の開発バージョンは、major番号０を有する。これは、プロトコルが最初に生産販売される時に１に増分される。サーバソフトウェアは、全ての旧クライアントバージョンと下位互換性があるように、販売される全てのバージョンのプロトコルを必ず処理できるべきである。
【０２９８】
プロトコルバージョン番号は、プロトコル識別子と同一行にあり、フォワードスラッシュでプロトコル識別子と分離される。
MSTP／0.1
この行は、これがバージョン０．１のMusicStationプロトコルであることを示す。
【０２９９】
５．１．２．１．３．要求識別子
MusicStatoinのクライアントにより送出される各要求は識別子を含む。この識別子は、現在のセッションにおいてその要求に一意である必要がある。要求識別子がグローバルで一意である必要はない。この要求識別子は、最長３２文字の任意の文字列である。
【０３００】
これは、１で開始する整数として実現されてもよく、クライアントが要求を行なう度に増分される。この要求識別子は、サーバがクライアントからの重複する要求を識別できるようにするために必要とされる。MyFoneの経験は、移動電話のクライアント要求が非常に信頼できないことがあることを示している。これは、クライアントが適度な時間内に応答を受信しない場合に要求を自動的に再試行できる必要があることを意味する。
【０３０１】
クライアントが応答を受信していない場合、その理由は、要求がサーバまで到達していないからであるか、あるいはサーバの応答がクライアントに返される途中でオペレータゲートウェイにおいて損失したからである。要求識別子を含むことにより、サーバが重複する要求を識別することは容易である。クライアントは、任意の再試行された要求に対して同一の要求識別子を送出する必要がある。
【０３０２】
要求識別子は、要求識別子及び要求バージョン番号の下側の任意の場所にある。
MSTP／0.1
RequestId: 123456
これは、そのクライアントによる要求を識別する。クライアントがその要求を再試行する場合、エントリ中の要求ＩＤは123456である。
【０３０３】
５．１．２．１．４．クライアント名及びバージョン番号
全ての要求は、クライアント名及びバージョン番号を含む必要がある。この情報は、そのクライアントの能力のルックアップを実行するためにサーバ上で使用される。これは、新しい能力がプロトコルで与えられた情報を変更する必要なく随時クライアントに追加されることを意味する。
【０３０４】
例えばクライアントが自身をＭＩＤＰバージョン０．４．６クライアントと識別する場合、サーバはどの形式でデータオブジェクトを返す必要があるかを認識する。更にサーバは、そのクライアントによりサポートされる音楽符号化を認識する。サーバは、そのクライアントが暗号化音楽ファイルをサポートしないことを認識する。
【０３０５】
MSTP／0.1
RequestId: 123457
Client: MusicStation 0.4.6 MIDP Nokia／N70
これは、クライアントをNokia N70ハンドセット上で実行するＪａｖａクライアントバージョン０．４．６と識別する。サーバは、そのクライアントが有する能力をルックアップできる。
【０３０６】
この文字列の形式は以下の通りである：
"MusicStation" [major].[minor].[micro] "Variant name" "Platform identifier"
詳細については図４６を参照。
【０３０７】
５．１．２．１．５．グローバルで一意のユーザの識別子
全ての要求は、グローバルで一意のユーザの識別子を含む必要がある。これに対する１つの例外は、初期登録要求である。要求がグローバルで一意のユーザの識別子を含まない場合、サーバは、クライアントが登録する必要があることの通知により応答する。
【０３０８】
このグローバルで一意の識別子により、サーバはユーザに関する種々の情報をルックアップできる。クライアントは、グローバルで一意の識別子を構成すべきではない。識別子は、登録処理中にサーバにより作成され、クライアントに割り当てられる。クライアントは、後続する各要求にその識別子を含める必要がある。
MSTP／0.1
RequestId: 123458
Client: MusicStation 0.4.6 MIDP Nokia／N70
UserGUID: AB12YZ
これは、グローバルで一意の識別子AB12YZを有するユーザを識別する。サーバは、好適な言語、領域、オペレータ及びブランド等のユーザの詳細をルックアップするためにその情報を使用できる。
【０３０９】
５．１．２．２．データ要求
５．１．２．２．１．基本的なデータ要求
クライアントからの殆どの要求は、クライアントからのデータに対する要求である。例えばクライアントは、サーバからの最新のニュースを要求してもよい。
MSTP／0.1
RequestId: 123459
Client: MusicStation 0.4.6 MIDP Nokia／N70
UserGUID: AB12YZ
Get: inbox.data
これは、inbox.dataデータオブジェクトファイルに対する要求の一例である。
【０３１０】
５．１．２．２．２．パス情報を含むデータ要求
データ要求は、それら要求に関連するパス情報を更に有してもよい。これは、ＨＴＴＰ ＵＲＬに類似する構文を使用する。記号／（フォワードスラッシュ）は、ディレクトリ分離記号として使用される。
MSTP／0.1
RequestId: 123459
Client: MusicStation 0.4.6 MIDP Nokia／N70
UserGUID: AB12YZ
Get: games／namethattune／question.data
これは、パスgames／namethattuneを有するquestion.dataデータオブジェクトファイルに対する要求の一例である。
【０３１１】
５．１．２．２．３．クエリを含むデータ要求
データ要求は、サーバがクライアントに返されるデータオブジェクトを構成するのに使用するパラメータをオプションとして含んでもよい。この要求データは、ＨＴＴＰクエリ文字列構文を使用することにより含まれる。
MSTP／0.1
RequestId: 123460
Client: MusicStation 0.4.6 MIDP Nokia／N70
UserGUID: AB12YZ
Get: advncedSearch.data?type=artist&query=artist%20name&country=uk&language=en
これは、高度な探索の結果に対する要求の一例である。要求されたリソースは記号?（疑問符）を有し、要求されたリソースの名前をそのリソースに対するパラメータと分離する。パラメータは、名前／値の対である。名前／値の各対は記号&（アンド記号）により区切られ、名前及び値の部分は=（等号）により分離される。値はＵＲＬ符号化されるため、探索用語「artist name」の間隔文字はＵＲＬ符号化バージョン％20により置換される。
【０３１２】
５．１．２．２．４．複数の要求を含むデータ要求
クライアントは、サーバからの複数のリソースを同時に要求してもよい。これを行なうために、クライアントはいくつかのGET行を送出する。各Get行は、要求される各リソースに対するものである。
MSTP／0.1
RequestId: 123461
Client: MusicStation 0.4.6 MIDP Nokia／N70
UserGUID: AB12YZ
Get: inbox.data
Get: charts.data
これは、inbox.dataファイルに対する要求及びcharts.dataファイルに対する要求の一例である。このような状況は、クライアントが迅速に必要とするリソース（この例においてはinbox.data）に対する要求を行なっており且つバックグラウンドでリソース（この例においてはcharts.data）を更新するように要求された時に発生する可能性がある。
【０３１３】
GET行は、クライアントがサーバ応答においてリソースを受信したい優先度で配列されるべきである。場合によっては、クライアントは部分応答をキャッシュし、サーバから返されるデータの一部のみを要求してもよい。このような場合、クライアントはデータの特定の部分に対してのみ要求を行ないたいだろう。クライアントは、GET行の範囲パラメータを使用してこれを行なえる。範囲パラメータは、記号;（セミコロン）により要求されたリソース名と分離される。２つ以上の範囲パラメータが存在する場合、それら範囲パラメータは記号;（セミコロン）により分離される。範囲パラメータは、from及びtoである。双方とも、記号=（等号）及び整数のバイト数が後続する。
【０３１４】
５．１．２．２．５．部分データ要求
以下は、inbox.dataファイルに対する部分要求の一例である。クライアントは、inbox.dataファイルの３４バイト目以降の全てを要求している。
MSTP／0.1
RequestId: 123462
Client: MusicStation 0.4.6 MIDP Nokia／N70
UserGUID: AB12YZ
Get: inbox.data; from=34
以下は、inbox.dataファイルに対する部分要求の一例である。クライアントは、inbox.dataファイルの１２８バイト目から２５６バイト目までの全てを要求している。
MSTP／0.1
RequestId: 123463
Client: MusicStation 0.4.6 MIDP Nokia／N70
UserGUID: AB12YZ
Get: charts.data; from=128; to=256
範囲要求を行なう時、クライアントは、返されるデータが要求した範囲であることを期待すべきではない。サーバ応答は返される範囲の詳細を含み、クライアントは、更なる処理に対して自身の要求の範囲情報ではなくサーバ応答の範囲情報を使用すべきである。これは、サーバには異なる範囲のデータを返す理由があるからである。例えば、クライアントが最後に要求してからデータが変更された場合である。
【０３１５】
５．１．２．３．サーバへのデータの送出
場合によっては、クライアントはサーバにデータを送出する必要があるだろう。例えば、エラー情報をサーバに送出するためである。クライアントはput行を使用することによりこれを行なえる。
【０３１６】
Put行はいくつかの部分を有する。各部分は;（セミコロン）で分離される。
【０３１７】
Put: error.data; ackId=1; offset=0; length=160; type="application／octet-stream"
ここで、エラーデータの詳細については図４７を参照。
【０３１８】
これは、エラーデータをサーバに送出するクライアントの一例である。図４８を参照。０及び１のブロックはメッセージの本文を示す。これは、このプロトコルにより転送されるバイナリデータである。このデータの形式は、クライアント実現技術に依存して異なるためこのプロトコルの範囲外である。本文のデータは、位置０から開始し、１６０バイトの長さを有する。Put行のオフセット値及び長さ値はこの情報を反映する。Put行のコンテンツの種類は、このデータを解釈する方法をサーバに知らせる。
【０３１９】
５．１．２．３．１．複数のputを含むデータの送出
クライアントは、複数のリソースをサーバに同時に送出するように要求されてもよい。複数のGet行を使用する方法と同様の方法で、クライアントは複数のPut行を送出してもよい。エラーデータ及び写真をサーバに送出するクライアントの一例に関しては図４９を参照。要求の本文において、エラーデータは、写真データより太字のテキストで示される。要求の長さの位置及びオフセットの位置は、このデータのオフセット及びデータの長さをサーバに知らせる。
【０３２０】
５．１．２．３．２．パラメータを含むデータの送出
Get行と同様に、Put行はPut上のパラメータをサポートする。これに対する構文は、Get行の構文と同様であり、ＨＴＴＰクエリ文字列構文でモデル化される。図５０において、単一のパラメータ（name="Fave Tracks"）を含むＪｐｅｇの写真を送出するサーバの一例を示す。尚、Put行はGet行と非常に類似するが、Put行は範囲値From及びToをサポートしない。失敗したPutはデータを全て再送出することを要求する。クライアントは、サーバから肯定応答受信を受けないため、Putが失敗したかを認識する（節「サーバ「応答」プロトコル」を参照）。
【０３２１】
５．１．２．３．３．クライアント肯定応答
サーバが各クライアント上に存在するデータに関する完璧な知識を常に有することができるように、クライアントはサーバにより送出された各データの受信を通知するように要求される。これは、正常に受信及び格納された各データファイルに対してAck行を１行送出することにより行なわれる。Ack行のパラメータは、サーバがファイルを送出した時にサーバにより割り当てられるackIDである。
MSTP／0.1
RequestId: 123466
Client: MusicStation 0.4.6 MIDP Nokia／N70
UserGUID: AB12YZ
Ack: 2006061911030001CHARTS
この要求は、クライアントが割り当てられた肯定応答ＩＤ2006061911030001CHARTSを有するデータファイルを正常に受信及び格納したことを通知することを示す。クライアントは、完全に受信したファイルのみ通知する必要がある。クライアントは部分的に受信したファイルを通知することはない。クライアントは、ファイルを部分的に受信した場合、データの残りの部分に対してGet範囲要求を行なうべきである。全てのデータが受信及び格納されると、クライアントはそのデータに対する肯定応答を送出できる。
【０３２２】
５．１．２．３．４．複数のackを含むクライアント肯定応答
要求は複数の肯定応答行を含んでもよい。
MSTP／0.1
RequestId: 123466
Client: MusicStation 0.4.6 MIDP Nokia／N70
UserGUID: AB12YZ
Ack: 2006061911030001CHARTS
Ack: 2006061911030001INBOX
この要求は、クライアントが肯定応答ＩＤ2006061911030001CHARTS及び2006061911030001INBOXを含むデータファイルを正常に受信及び格納したことを通知することを示す。
【０３２３】
５．１．２．３．５．否定応答の通知
クライアントは、要求したデータファイルを正常に受信及び格納しなかった場合、否定応答の通知をサーバに送出すべきである。
MSTP／0.1
RequestId: 123466
Client: MusicStation 0.4.6 MIDP Nokia／N70
UserGUID: AB12YZ
Nak: 2006061911030001CHARTS
この要求は、肯定応答ＩＤ2006061911030001CHARTSのデータファイルの受信又は格納に関する問題があったことをクライアントがサーバに知らせることを示す。この時点でサーバは、このファイルがクライアント上に存在しないことを認識する。
【０３２４】
通常、クライアントがNakを送出する場合、Nakの理由を説明する添付のエラーデータを有する可能性が非常に高い。サーバがNakを受信し、エラーデータがない場合、サーバはログファイルの詳細を送出するようにクライアントに要求したいだろう。クライアントが永続的にNakをサーバに送出する場合、サーバは原因の識別を助長するためにクライアント上のログレベルを上げたいだろう。
【０３２５】
５．１．２．４．セッション識別子
クライアントがサーバに送出する各要求は、セッション識別子を含むべきである。クライアントは、再起動間でこのセッション識別子を記憶していない。クライアントは、起動後の最初の要求にセッション識別子を含むべきではない。サーバは、新しいセッション識別子を送出し返すことにより応答する。クライアントは、ユーザがクライアントを閉じるまで後続する全ての要求にこの識別子を含めるべきである。
MSTP／0.1
RequestId: 123467
Client: MusicStation 0.4.6 MIDP Nokia／N70
UserGUID: AB12YZ
SessionId: FJSKNBKSKSDKFLSH
Get: inbox.data
この要求は、クライアントがセッション識別子FJSKNBKSKSDKFLSHを事前に割り当てられたことを示す。クライアントがこのセッション識別子を取得する方法に関する更なる詳細については、節「サーバ「応答」プロトコル」を参照。
【０３２６】
５．１．３．サーバ応答プロトコル
５．１．３．１．ヘッダ
５．１．３．１．１．プロトコル識別子
サーバ応答において使用されるプロトコル識別子は、クライアント要求のプロトコル識別子と同一であるべきである。クライアントは、MusicStationのプロトコル形式である場合に応答を認識するためにその識別子をチェックすべきである。
MusicStationにより使用されるプロトコル識別子は以下の通りである：
MSTP
５．１．３．１．２．プロトコルバージョン番号
サーバは、種々のバージョンのプロトコルを同時にサポートできる。サーバは、要求において使用されたクライアントと同一のプロトコルバージョン番号で常に応答するべきである。これは、クライアントがサポートすることをサーバが確信できる唯一のプロトコルバージョン番号だからである。クライアントは、使用されるプロトコルバージョンが理解できるバージョンであることを認識するために、プロトコル識別子と共に応答のプロトコルバージョン番号をチェックする必要がある。
MSTP／0.1
これは、サーバがMusicStation伝送プロトコル識別子を送出し且つプロトコルバージョン番号０．１を使用することの一例である。
【０３２７】
５．１．３．１．３．応答状態コード
サーバは、各応答と共に状態コードを送出する。状態コードを図５１に示す。状態コードは常に４桁である。これは、十分なコードを今後拡張可能にするためである。３桁のコードは、ＨＴＴＰ状態コードとの混同を回避するために使用されない。状態コードは拡張可能であり、新しいコードは随時追加される。サーバは、クライアントが理解する状態コードのみがクライアントに送出されることを確認する。状態コードは、２つの部分にグループ化される。数字1で開始するコード（すなわち、1000〜1999）は、正常な動作に関連するコードに対して使用される。数字２で開始するコード（すなわち、4000〜5999）は、障害を起こした動作に対して使用される。
【０３２８】
コードの障害の範囲内で、２つの更なるグループが存在する。数字4で開始するコード（すなわち、4000〜4999）は、クライアントに障害があった場合の障害に対して使用される。数字5で開始するコード（すなわち、5000〜5999）は、サーバに障害があった場合の障害に対して使用される。以下において、この例はサーバからの正常な応答を示す。
MSTP／0.1
StatusCode: 1000
５．１．３．１．４．応答識別子
クライアントが受信した応答が行なった要求に応答するものであることを確認できるため、サーバからの各応答はクライアントの要求識別子をエコーする。
MSTP／0.1
StatusCode: 1000
ResponseId: 234567
この例は、要求ＩＤ234567のクライアント要求に対するサーバ応答を示す。
【０３２９】
５．１．３．２．セッション識別子の設定
クライアントが起動される度にクライアントから行なわれる第１の要求は、セッション識別子を含まない。サーバは、新しく割り当てたセッション識別子によりこの要求に対して応答すべきである。
MSTP／0.1
StatusCode: 1000
ResponseId: 234568
SetSessionId: FJSKNBKSKSDKFLSR
この応答は、サーバがセッションＩＤをFJSKNBKSKSDKFLSRに設定することを示す。クライアントがSetSessionId行を含む任意の応答を受信する場合、クライアントは新しいセッションＩＤを使用して迅速に開始する必要がある。サーバが既にセッションＩＤを有するクライアントに新しいセッションＩＤを割り当てる場合がある。例えばこれは、セッションがサーバ上でタイムアウトになった場合に起こる。
【０３３０】
５．１．３．３．データの送出
サーバからの殆どの応答は、少なくとも１つのデータオブジェクトファイルを含む可能性が高い。それらのデータファイルは、応答の本文において送出される。クライアントにより要求において送出されるGet行毎に、サーバはSent行を返すべきである。サーバは、データと共に送出する肯定応答ＩＤを生成する必要がある。これは、サーバがAck行を受信した時に確認されるデータを認識するためである。送出されたデータファイルを一意に識別するようにそれら肯定応答ＩＤを生成することは、サーバの役割である。
【０３３１】
Sent行は、クライアントがデータを見つけられるデータの本文にバイトオフセット位置を含む必要があり、更にデータの長さ及びデータのコンテンツの種類を含む必要がある。バイトオフセット及び長さは、処理を相対的に容易にするためMusicStationのプロトコルにおいて使用される。マルチパートＭＩＭＥにおいて使用されるような境界パラメータよりも優先的にこれが使用されてきた。図５２のこの応答は、サーバがnews1.dataファイルを送出することを示す。
【０３３２】
５．１．３．３．１．応答における複数のデータファイルの送出
サーバは、単一の応答で複数のデータファイルを送出してもよい。これは、クライアントが複数のPut行を使用してリソースをサーバに送出するのと同様に複数のSent行を使用して行なわれる。
図５３の応答は、サーバがnews2.dataファイル及びnews3.dataファイルを送出することを示す。
応答の本文において、データを太字のテキストで示す。クライアントは、Sent行のオフセットパラメータ及び長さパラメータのためにどの本文データがどのデータファイルに対するものかを認識する。
【０３３３】
５．１．３．３．２．部分データ要求
クライアント要求が特定の範囲のデータに対するものであり、サーバがその範囲のデータのみを送出する場合、サーバ応答は送出されたデータの範囲を示す必要がある。図５４を参照。この応答は、返されたデータが１６０バイト目から末尾までのデータであることを示す。このデータは４０バイトあり、０バイト目（すなわち本文の開始）からデータの本文中に位置付けられる。尚、オフセット値はデータの本文中の指標であり、範囲値とは関係ない。
【０３３４】
値の範囲は、応答のデータがデータファイルの末尾までではないことを示すためにSent行において使用されてもよい。クライアントは、常に応答ヘッダを読み、クライアント送出要求ヘッダではなく応答ヘッダを使用してデータを処理すべきである。これは、サーバがデータファイル全体を返す理由がある場合に要求された範囲が返された範囲ではないことがあるためである。
【０３３５】
５．１．３．３．３．クライアントへのデータのプッシュ
サーバは、クライアントにプッシュしたいデータに対するSent行を送出してもよい。これは、クライアントが要求において対応するGet行を送出しなかったSent行をサーバが送出することにより行なわれる。図５５を参照。この応答は、サーバがnews1.dataファイル及びcommand.dataファイルを送出することを示す。プッシュされた任意のデータは、常に、応答本文において要求されたデータに追従すべきである。
【０３３６】
５．１．３．４．肯定応答
５．１．３．４．１．受信データの確認
クライアントがサーバにデータを送出した場合（例えば、エラーデータ）、サーバがそのデータを正常に受信したことをクライアントが認識するために、サーバはそのデータを受信したことを通知する必要がある。
MSTP／0.1
StatusCode: 1000
ResponseId: 234569
Ack: 3
この応答は、クライアントがPut行で送出し且つ肯定応答ＩＤ３を割り当てたデータファイルをサーバが受信したことを通知することを示す。
【０３３７】
５．１．３．４．２．否定応答通知の送出
同様に、サーバはデータの受信又は格納に関する課題がある場合にデータの受信の否定応答を通知できる。これにより、クライアントはデータを再送出できる。
MSTP／0.1
StatusCode: 1000
ResponseId: 234569
Nak: 4
この応答は、クライアントが肯定応答ＩＤ４を割り当てたデータファイルの受信が失敗したことをサーバが通知することを示す。
【０３３８】
５．１．３．４．３．肯定応答要求
サーバがクライアントにデータを送出し、クライアントからの異なる要求ＩＤの次の要求において、サーバがそのデータに対する肯定応答を受信しなかった場合、サーバはデータを受信したか否かを通知するようにクライアントに要求できる。これは、サーバが応答においてAckRequired行を送出することにより行なわれる。
MSTP／0.1
StatusCode: 1000
ResponseId: 234574
AckRequired: 20060619111230NEWS2
これは、肯定応答ＩＤ20060619111230NEWS2で先に送出されたデータファイルを確認するようにサーバがクライアントに要求することの一例である。尚、サーバはデータファイルの肯定応答を要求する必要はなく、クライアントは自動的に送出すべきである。AckRequired行は、接続が完全でなく、先にクライアントから送出された肯定応答が何らかの理由でサーバに到達していない場合に使用される。
【０３３９】
５．１．４．接続レベル
クライアントは、種々のレベルの接続速度、信頼度、帯域幅及び待ち時間を有する。各クライアントデータオブジェクト要求は、関連付けられた事前定義済み優先順位を有する。クライアントは、利用可能な帯域幅及び正常な接続数に基づいて接続性レベルの閾値を動的に変更する。
【０３４０】
優先順位は以下の通りである：
・IMMEDIATE−クライアントは、この要求を迅速に送出するべきであり、この要求をキュー登録するべきではない。これは、ユーザにより要求された画面を示すために必要とされるデータオブジェクトを要求するのに使用されるべきである。
・SOON−このクライアントは、ネットワーク速度／帯域幅が利用可能である場合にこの要求を迅速に送出してもよい。この情報は、クライアントにプッシュするデータオブジェクトを決定する際にサーバにとって有用である。
・WHENEVER−クライアントは、重要な期間にこの情報をサーバに送出する必要はない。サーバは、この情報を通知される必要があるが、データは次の要求と共に送出できる。
【０３４１】
クライアントは、大量のデータを転送するのにかかる時間に基づいて帯域幅を計算できる。これは、オーディオファイルを転送する時に行なわれるのが最適だろう。クライアントは、帯域幅及び正常な接続数、並びに優先度がより高い要求を送出するために割り込まれる接続数に基づいて接続性閾値を計算できる。適切な接続性を有するクライアントは、優先度SOON又はそれ以上の全てのメッセージが迅速に送出されることを可能にする接続性閾値を有する。低い接続性を有するクライアントは、IMMEDIATEメッセージのみが迅速に送出されることを可能にする接続性閾値を有する。
【０３４２】
５．１．５．コマンドデータオブジェクト
MusicStation MIDP 0.4.6において、存在するデータオブジェクトのみがコンテンツデータオブジェクトである。新しい種類のデータオブジェクトは、接続されたMusicStationバージョンにおいて必要とされる。それらは、サーバが種々のデータを要求できるようにするため又はクライアントに送出できるようにするために必要とされる。それらデータオブジェクトは、MusicStation伝送プロトコルにより送出されるが、MusicStation伝送プロトコルの一部ではない。種々のコマンドオブジェクトが種々のクライアントの実現に対して使用されるが、同一の伝送プロトコルが全ての実現に対して使用されるため、それらデータオブジェクトはプロトコルの一部ではない。
【０３４３】
５．１．５．１．サーバコマンドデータオブジェクト
コンテンツデータオブジェクト及び画像ファイルに加え、サーバは以下のコマンドをクライアントに送出できる必要がある：
・Please send total file space size to the server.
・Please send remaining file space size to the server.
・Please send log file to the server.
・Please send errors to the server.
・Please change client logging level.
・Set property.
・Get property.
・Please delete a file.
・Please send details of what files you have.
・Please send bandwidth details.
・Please change connection level.
・Please request data file.
・Please request audio file.
・Registration data.
新しい機能性がクライアント及びサーバに追加されると、項目はこのリストに追加される可能性が高い。
【０３４４】
尚、サーバはクライアントよりクライアントの接続詳細を認識している場合が多い。例えば、Nokia N80のＭＩＤＰクライアントは、ＨＴＴＰ接続がオペレータゲートウェイを介するか又は無線ＬＡＮを介するかを認識する手段を有さない。サーバは、クライアント接続が周知のオペレータＩＰアドレス範囲からのものであるため、その接続がオペレータゲートウェイを介するかを認識する。
【０３４５】
５．１．５．２．クライアントコマンドデータオブジェクト
クライアントは、以下のデータをサーバに送出できる必要がある：
・プレイリストデータ
・画像ファイル
・全体のファイル空間
・利用可能なファイル空間
・ログファイルデータ
・現在のロギングレベル
・エラー情報
・他のファイルのための空間を解放するために削除されたファイルに関する情報
・現在の帯域幅レベル
・使用されるデータファイル
・示される画面
・プロパティ値
・現在のクライアント時間
・登録データ
５．１．５．３．タイミング
サーバは、種々のクライアント事象が発生した時間を記録する。クライアントは、グリニッジ標準時の１９７０年１月１日の午前０時からの秒数で時間をサーバに報告すべきである。例えばMIDP1.0において、これは以下により取得される：
Calendar.getInstance(TimeZone.getTimeZone("GMT")).getTime().getTime()
ＭＩＤＰの仕様書において、ＧＭＴ時間帯がサポートされる必要があるが、何らかの理由によりサポートされない場合にハンドセットがクライアント時間を得るために単純に以下を使用できることが示される：
(newDate()).getTime()
各クライアントは、自身の時間設定を使用してタイミングデータを格納する。このデータがサーバに転送される場合、サーバはそれら事象タイミングを自身の形式に変換して格納できる。
【０３４６】
サーバは、クライアントローカル時間を自身の時間と比較することによりそれを行なう。クライアント報告時間とサーバ時間とのデルタが計算される。現在のクライアント時間コマンドオブジェクトは、サーバが計算した時間が可能な限り正確になるようにデータがサーバに送出された時間を含む必要がある。
【０３４７】
５．２．クライアントデータの同期
５．２．１．概要
MusicStationの殆どの画面はデータによりポピュレートされる。このデータは、サーバから転送され、クライアント上のファイルにローカルに格納される。サーバ上のデータが変更される場合、クライアント上のファイルはそれら変更を反映するために更新される必要がある。更に、ユーザはクライアント上のファイルを作成及び変更できる。例えば、プレイリストにトラックを追加する。それら変更は、確実にサーバに通信される必要がある。ユーザは、MusicMateを介してデータに対して変更を行なえる。それら変更は、装置上で行なわれた変更と矛盾する可能性がある。クライアント及びサーバはデータを同期させる必要があり、サーバは任意の矛盾解決策を処理する。
【０３４８】
５．２．２．データオブジェクト
データオブジェクトは、サーバ／クライアント間及びクライアント／サーバ間で渡されるオブジェクトの基本単位である。それらオブジェクトは、クライアントインタフェース内で表示されるあるエンティティ（アーティスト、アルバム等）又はデータの表現をカプセル化し、サーバに送出し返される必要がある（ユーザが規定したプレイリストのように）。それらは、サーバとクライアントとの間で渡され、セキュリティ上安全に電話機に格納される。データオブジェクトは、クライアント上で何かを更新する必要がある時にサーバによりクライアントに配布される。
【０３４９】
データオブジェクトは、自身をファイルに書き込むことができ、クライアントとサーバとの間でデータを転送するために使用される。ファイルヘッダは、ファイルを書き込むのに使用されるデータオブジェクトバージョンを含む。データオブジェクトの最新のバージョンは、サポートされる全てのバージョンでファイルを読み出すことができ且つ書き込むことができる。バージョンは読み出し／書き込み方法の各々に渡され、それにより、バージョンに基づいて読み出されたものか又は書き込まれたものを切り替えることが可能になる。
【０３５０】
この方法を使用すると、サーバは古いバージョンのクライアントに対してデータオブジェクトファイルを書くことができる。対象バージョンはファイルヘッダに設定され、各書き込み方法は、出力がそのバージョンに対する形式であることを保証する。
【０３５１】
サーバは、同一の方法を使用して古いクライアントにより書き込まれたファイルを読み出せる。ファイルがデータオブジェクトに読み込まれた場合、読み出し方法はバージョンを使用してファイルから読み出された属性を切り替える。
【０３５２】
データオブジェクトは、MusicStationにおいて画面をポピュレートするのに使用されたデータを含む。それらは、ファイル又はストリームへの書き込み及びファイル又はストリームからの読み出しを可能にする方法を使用する。それらオブジェクトは、クライアントとサーバとの間でデータを転送するため、並びにメモリカード上のファイルにローカルにデータをロード及び格納するために使用される。
【０３５３】
５．２．２．１．データオブジェクトグループ
データオブジェクトは、他のデータオブジェクトの集合を含むことができる。例えば、ArtistデータオブジェクトはReleaseの集合を含む。同様に、ReleaseはTrackの集合を含む。図５６を参照。データオブジェクトは、オブジェクトのリストを格納できる。例えば、ArtistGroupはアーティストのリストを格納する。「My Artists」画面は、ArtistGroupデータオブジェクトを使用して、ユーザが所有する全てのアーティストを表示する。ArtistがReleaseを含み、ReleaseがTrackを含むため、Artist及びReleaseもまたデータオブジェクトグループである。
【０３５４】
５．２．２．２．データオブジェクトビュー
データオブジェクトビューは、データオブジェクトグループのソート及びフィルタリングされたビューを提供する。データによりポピュレートされるMusicStationの全ての画面は、１つ以上のビューにより支持される。データオブジェクトグループに対する任意の変更がビューに伝播され、ビューはそれら変更を反映するために画面を更新する役割を有する。
これにより、データオブジェクトがロードされる直前に画面を表示できる。データオブジェクトがバックグラウンドでロードされるため、それら変更の結果として画面が更新される。例えば「My Artists」画面のアーティストのリストは、各アーティストがロードされると増加する。
【０３５５】
５．２．３．データオブジェクトファイル
各データオブジェクトグループは、ファイルにローカルに格納される。例えば「My Artists」ArtistGroupは自身のファイルに格納される。各々が平均で１０個のトラックを含む２個のアルバム（ユーザは２つのアルバムを所有する必要はないが、これら２つのアルバムはアーティストデータオブジェクトに存在する。）を有する１００人のアーティストをユーザがが所有する場合、このデータオブジェクトは迅速に非常に大きくなってしまう。このArtistGroupオブジェクトが書き込まれる場合、大きなファイルを作成し、ファイルから再び読み込まれる場合、ポピュレートするのに時間がかかる。
【０３５６】
別の方法は、オブジェクトの各集合を自身のファイルに格納することである。従って、「My Artists」の例において、アーティストのリストはファイル（userartists.data）に格納されるが、各アーティストのアルバムのリストは格納されない。アルバムのリストは、各々が各アーティストに対するものである別個のアーティストファイル（例えば、artist.123.data）に格納される。各アルバムは、トラックを含む自身のファイル（release.4567.data）に格納される。図５７を参照。
【０３５７】
各データオブジェクトが自身のファイルに格納されるため、オブジェクトグループはデータを複製する必要なく同一のデータオブジェクトを使用できる。例えば、「Snow Patrol」は「My Artists」グループ及び「Popular Artists」グループに存在する。ユーザが「Eyes Open」アルバムから「Chasing Cars」を購入する場合、「Eyes Open」アルバムデータファイルのみを更新する必要がある。ユーザが「Popular Artists」にナビゲートし、その後「Snow Patrol」にナビゲートする場合、画面は、ユーザが「Chasing Cars」を購入したことを示す。図５８を参照。
【０３５８】
しかし、この方法は自身の課題を提示する。「My Artists」データファイルがアーティストＩＤのリストのみを含むため、「My Artists」画面をポピュレートするために各アーティストファイルを開き、各アーティストの名前を読み出す必要がある。この方法に関していくつかの重要な問題が存在する。第１に、ローカルに格納された全てのアーティストファイルが必要であるため、欠落しているファイルはサーバからダウンロードされる必要がある。それらファイルなしでは、アーティスト名を表示できない。第２に、リスト中の各アーティストに対して新しいファイル接続を開くことは相対的に費用がかかるため、この方法は遅くなる。
【０３５９】
これを回避するために、「My Artists」データファイルにアーティスト名及びＩＤを格納できる。これは、「My Artists」リストを迅速に構築できることを意味する。しかし、ここでは名前がアーティストグループデータファイル及びアーティストデータファイルの双方に格納されるため冗長性が与えられる。図５９を参照。
【０３６０】
また、別のプロパティのリストをソート又はフィルタリングしたい場合がある。例えば「Search Results」はユーザが所有するアーティストをリストの上部に示す。そのためには、リストを表示するのに名前だけでなく所有者プロパティも必要である。これは、グループデータファイルに追加する更なる冗長データである。
【０３６１】
オブジェクトが多くのグループに格納されるため、その冗長性を認識する必要があり、クライアント又はサーバが更新の役割を有することを確認する必要がある。一般に、サーバはそれら更新の役割を果たし、それら更新はクライアント要求に応答してクライアントに転送される。クライアントがオフラインの時にそれら変更が行なわれることが可能である場合は常に、クライアントはそれら変更を伝播する役割を有する。これらの例において、クライアントはオンラインであってもオフラインであってもローカルファイルを更新する。例えば顧客がプレイリスト画像を変更する場合、そのプレイリストを含む任意のプレイリストグループが更新される必要がある。
【０３６２】
５．２．４．データオブジェクトの転送
データオブジェクトは、接続されたMusicStationプロトコルを使用してクライアントとサーバとの間で転送される。クライアントとの殆どの通信はＨＴＴＰを介すると予想されるため、クライアントは初期要求を行なう役割がある。
【０３６３】
５．２．４．１．クライアント要求
クライアントは、オブジェクトが複製されるメモリカード上の場所を認識しているとは限らない。例えば「Popular Artists」グループはクライアントにプッシュされたが、クライアントは「Popular Artists」を開いておらず、ユーザが「Snow Patrol」による「Chasing Cars」を購入した時にそのことを反映するために「Popular Artists」データファイルが更新される必要があることを認識していない。しかし、サーバは、「Popular Artists」データファイルを構築し且つそのファイルをクライアントに送出したためその知識を有している。
【０３６４】
そのため、サーバはサーバ上のレコードが変更された時にクライアント上のファイルを更新する役割を有する。顧客が「Chasing Cars」を購入した時、サーバはクライアント上のどのデータファイルが「Chasing Cars」を含むかを計算し、更新する必要がある。サーバは、購入応答と共にそれら更新オブジェクトをプッシュするか又は可能な時にそれらファイルを更新するようにクライアントにコマンドを送出する。応答は、要求の結果として変更された全てのデータオブジェクトを含むのが好ましい。クライアントがオブジェクトを設定し且つ変更された全てのオブジェクトを取得することを示す図６０を参照。
【０３６５】
５．２．４．２．データオブジェクトのプッシュ
クライアントがオフラインの間にレコードがサーバ上で更新され、それら変更がクライアントに伝播される必要がある場合、サーバは次の要求においてそれら変更をクライアントにプッシュする。例えば顧客がMusicMateから「Chasing Cars」を購入する場合、クライアントが次にサーバに接続した時に、更新される必要がある任意のオブジェクトはクライアントにプッシュされる。クライアントがオブジェクトを要求し且つ変更された全てのオブジェクトを取得することを示す図６１を参照。
【０３６６】
５．２．４．３．オフラインモード
クライアントがオフラインの時、顧客はデータを変更できる殆どの動作を実行できない。例えば、トラックを購入できない。しかし、顧客はプレイリストを作成、編集及び共有できるべきである。クライアントは、クライアント上で編集されたがサーバに送出されていないファイルのリストを維持する必要がある。クライアントが次に接続した時、クライアントはそれらファイルをサーバに送出する必要がある。クライアントにより行なわれた全ての変更は、クライアントが次に接続した時にサーバに送出される。サーバは、任意の変更ファイルをクライアントに返す。クライアントがオフラインモードで変更されたオブジェクトを送出することを示す図６２を参照。
【０３６７】
５．２．５．変更ログ
サーバは、クライアントに送出されたオブジェクトのリストを維持する。それらオブジェクトの１つ以上がサーバにおいて変更された場合、変更されたオブジェクトは可能な限り早くクライアントに配布される必要がある。同様に、クライアントはクライアント上で作成又は変更され且つサーバにおいて更新される必要があるオブジェクトのリストを維持する。
【０３６８】
object_change_logテーブルには、迅速に送出される必要のない変更が格納される。これは、新しいアーティストの追加等の一般のシステムの広範な変更に対するものである。このテーブルは、いくつかのデータベースから行なわれた変更のマージを処理する。それら変更は、ユーザセッションが次に作成された時に通信される。顧客別変更は、customer_object_change_logで行なわれる。それら変更は、迅速にクライアントに通信される。
【０３６９】
５．２．５．１．サーバオブジェクト
サーバ上でのオブジェクトに対する変更はobject_change_logテーブルに格納される。１つ以上のオブジェクトデータファイルに影響を及ぼす可能性のあるレコードが挿入、更新又は削除されると必ず、１つ以上のレコードがこのテーブルに挿入される。このテーブルにより、変更は例えばステージングサーバ上で別個のデータベースにおいて行なうことができ、変更がインポートされると、object_change_logもインポートされる。object_change_logを示す図６３を参照。
【０３７０】
クライアント上に存在するデータオブジェクトのリストは、サーバにおいてcustomer_objectテーブルに格納される。セッションがクライアントに対して作成されると必ずcustomer_objectテーブル及びobject_change_logテーブルをクエリして、この顧客に対して変更されたオブジェクトを判定する。このクエリは、単一のオブジェクトに対していくつかの変更レコードを返すことが可能である。この場合、最後の変更レコードのみを考慮する必要がある。変更されたオブジェクトは、クライアントに返される必要がある。customer_objectを示す図６４を参照。
【０３７１】
クライアントに返される必要のあるオブジェクトは、customer_object_change_logテーブルに挿入される。１人の顧客にのみ影響を与えるオブジェクトに対して変更が行なわれる場合、レコードはそのテーブルに挿入されてもよい。例えば、顧客がトラックを購入する場合、そのトラックを参照するオブジェクトデータファイルを更新する必要がある。customer_object_change_logを示す図６５を参照。
【０３７２】
クライアントから要求を受信すると、応答において全ての変更オブジェクトを返したい。状況によっては（帯域幅が制限されるか又はオブジェクトが大きい場合）、後で変更オブジェクトを要求するようにクライアントにコマンドを送出してもよい。多くのオブジェクトがクライアントに返される必要がある状況においては、最初に送出されるオブジェクトを判定するためにpriorityフィールドが使用される。
【０３７３】
クライアントに対する変更オブジェクトのリストを取得するために、acknowledgement_dataがヌルであるcustomer_object_change_logテーブルから選択する。最初は、object_modified_dateは各object_guidに対して複製され、別のテーブルに分離されるように見える。しかし、性能の理由から、クライアント上のオブジェクトデータファイルは２つ以上のテーブルのデータを含み、オブジェクトは１つのクライアント上で更新を必要とし、別のクライアント上では必要としなくてもよい。例えば、アーティストリストは、ユーザが所有するアーティストを上部にしてソートされるように各アーティストに対する所有権情報を含む。顧客があるアーティストによるトラックを購入する場合、その顧客のアーティストリストのみが変更され、更新される必要がある。
【０３７４】
object_change_logテーブル及びcustomer_object_change_logテーブルを更新するために、１つ以上の以下の方法が使用できる：
・テーブルにおけるデータベーストリガは、データが追加、更新又は削除された時にobject_change_logテーブルをポピュレートできる。
・バッチ処理は、例えば新しいコンテンツデータのインポート時にobject_change_logテーブルをポピュレートする。
・エンティティリスナ又はコールバック方法は、ＥＪＢ永続(persist)、更新(update)及び除去(remove)事象において使用される。
殆どの場合、コールバック方法が最適であるが、データロード等の大きな挿入の場合には別の方法を使用する方が効率的だろう。
【０３７５】
５．２．５．２．クライアントオブジェクト
クライアントは、サーバに送出される必要のある変更のログを更に保持する必要がある。クライアントはこのリストをＲＭＳに保持する。各変更は、ChangeLogRecordオブジェクトに格納される。図６６を参照。objectGUIDは、クライアントがオブジェクトを追加していない限りサーバ上のそのオブジェクトを識別するために使用される同一のＧＵＩＤである。その場合、クライアントは、サーバが生成した新しいＧＵＩＤを有するオブジェクトをサーバが更新するまで使用される一時的なＧＵＩＤを割り当てる。クライアントがサーバに接続すると必ず、クライアントは変更ログの全てのオブジェクトを送出する。サーバは、各オブジェクトに対する肯定応答で応答すべきである。クライアントは肯定応答を受信すると、対応するChangeLogRecordを削除する。
５．２．６．矛盾の解決策
同一のオブジェクトがクライアント及びサーバにおいて変更されたために矛盾が発生した場合、サーバはその矛盾を解決する役割を有する。サーバは、更新オブジェクトを送出することにより解決策をクライアントに通信する。殆どの更新をサーバに管理させることにより、矛盾が発生する状況の数を最小限にしようとする。いくつかの場合においてのみ、クライアントがオブジェクトを変更し、その変更をサーバに送出できる。
【０３７６】
プロトタイプにおいて、クライアントの変更は以下に制限される：
１．プレイリストの作成
２．プレイリストの編集
３．プレイリストの削除
４．顧客プロファイル（キャッチフレーズ、アイコン）の編集
５．トラックの評価
矛盾解決戦略を設計する場合、以下の種類の矛盾を考慮する必要がある：
・レコードに対する更新が別の更新と矛盾する場合、更新の矛盾が発生する。
・レコードに対する更新が矛盾するレコードにより一意性制約に違反する場合、一意性の矛盾が発生する。
・削除されたレコードが更新される場合、削除の矛盾が発生する。
【０３７７】
５．２．７．ユースケース
オブジェクトが更新又は削除されると必ず、object_change_logテーブル又はcustomer_object_change_logテーブルはその変更を反映するために更新される必要がある。クライアント上のオブジェクトデータファイルが冗長データを含むため、変更は２つ以上のオブジェクトに影響を及ぼす可能性が高い。
【０３７８】
５．２．７．１．サーバ変更
５．２．７．１．１．アーティストによる新しいアルバムの発売
アーティスト「Snow Patrol」は、アルバム「Eyes Open」を発売する。「Snow Patrol」に対するアーティストデータファイルを含む全てのクライアントが更新される必要がある。まず、「Snow Patrol」及び「Eyes Open」に対する変更レコードをobject_change_logテーブルに挿入する。図６７を参照。
【０３７９】
「Snow Patrol」アーティストファイルを有する顧客がサーバに接続し、セッションが作成されると、customer_data_objectテーブルはobject_change_logテーブルと結合され、その顧客に対して変更されたオブジェクトを見つける。
SELECT FROM customer_object, object_change_log
WHERE customer_object.object_guid = object_change_log.object_guid AND
customer_object.deleted_date IS NOT NULL AND
customer_object.object_modified_date ＜ object_change_log.object_modified_date;
このクエリは、「Snow Patrol」object_change_logレコードを返す。このレコードは、customer_object_change_logテーブルに挿入される。図６８を参照。
customer_object.modified_dateフィールドは、「18／07／2006 13:16:33」に更新される。
「Snow Patrol」データファイルはクライアントに送出され、customer_object_change_log.acknowledgement_idフィールドは設定される。クライアントがファイルを確認すると、customer_object_change_log.acknowledgement_dateフィールドは設定される。
【０３８０】
５．２．７．１．２．アーティストの除去
アーティスト「Cliff Richard」は、MusicStationから除去される。「Cliff Richard」データファイルを格納しているか又は「Cliff Richard」を含むリストを有する全てのクライアントは、更新される必要がある。
【０３８１】
object_change_logテーブルは更新され、削除レコードは以下のオブジェクトに対して挿入される：
Artist
Artist.getAlbums()
Artist.getLists()
Artist.getAlbums().getLists()
Artist.getPlaylists()
５．２．７．１．３．顧客によるプレイリストの共有
顧客は、新しいプレイリスト「Sunday Stroll」を作成して共有することを決定する。クライアントは、新しいプレイリストをサーバに送出する。任意の変更は、次の要求でサーバに送出される。プレイリストに追加するトラックを閲覧している時、サーバと通信している可能性が高く、変更は毎回送出される。
【０３８２】
Playlistオブジェクトが作成されると、object_change_logテーブルは更新され、レコードは顧客のデータオブジェクトファイルを有する全てのクライアントに対するcustomer_object_change_logに挿入される。
【０３８３】
５．２．７．１．４．顧客によるプレイリストの変更及び共有
顧客は、新しいプレイリスト「Sunday Stroll」を作成して共有することを決定する。クライアントは、新しいプレイリストをサーバに送出する。任意の変更は、次の要求でサーバに送出される。プレイリストに追加するトラックを閲覧している時、サーバと通信している可能性が高く、変更は毎回送出される。
【０３８４】
Playlistオブジェクトが作成されると、object_change_logテーブルは更新され、レコードは、顧客のデータオブジェクトファイルを有する全てのクライアントに対するcustomer_object_change_logに挿入される。
【０３８５】
５．２．７．１．５．顧客によるプレイリストの共有
顧客は、新しいプレイリスト「Sunday Stroll」を作成して共有することを決定する。クライアントは、新しいプレイリストをサーバに送出する。任意の変更は、次の要求でサーバに送出される。プレイリストに追加するトラックを閲覧している時、サーバと通信している可能性が高く、変更は毎回送出される。Playlistオブジェクトが作成されると、object_change_logテーブルは更新され、レコードは、顧客のデータオブジェクトファイルを有する全てのクライアントに対するcustomer_object_change_logに挿入される。
【０３８６】
５．２．７．１．６．顧客による言語の変更
顧客は、異なる言語を選択する。言語別データを含む全てのファイルを更新したい。メッセージプロパティファイル及びエディタキャプションの双方が、その変更を反映するために更新される必要がある。プレイリストのみがクライアント上にエディタキャプションを表示するため、エディタキャプションを有するクライアント上の任意のプレイリストに対して、レコードがcustomer_object_change_logに挿入される。
【０３８７】
５．２．７．１．７．サーバがトラックを削除中に顧客がトラックをプレイリストに追加
ユーザは、オフライン中にトラックＴをプレイリストに追加する。その間に、サーバはトラックＴを削除する。Ｔが削除された場合、レコードがobject_change_logに挿入される。クライアントが更新プレイリストを送出すると、object_change_logのレコードとその変更とを比較し、プレイリストからトラックを削除して送出し返す。顧客はそのことを通知されず、単にトラックが消える。
【０３８８】
５．２．７．１．８．サーバがトラックの名前を変更中に顧客がトラックをプレイリストに追加
ユーザは、オフライン中にトラックＴをプレイリストに追加する。その間に、サーバはトラックＴの名前を変更する。Ｔの名前が変更された場合、レコードがobject_change_logに挿入される。クライアントが更新プレイリストを送出すると、object_change_logのレコードとその変更とを比較し、プレイリストのトラックの名前を変更して送出し返す。
【０３８９】
５．２．８．装置メモリ管理
装置は、格納するために残された記憶容量をサーバに通信できる。サーバはその情報を使用して、更新を配布する時に任意のファイルがクライアントから削除されるべきかを決定する。customer_objectテーブルのobject_last_usedフィールドは、クライアントが特定のオブジェクトを最後に使用した日付を格納する。このフィールドは、クライアントからサーバに送出されたログデータからポピュレートされる。サーバはこのデータを使用して、削除されるべきファイルを判定する。サーバは他の方法を更に使用して、削除されるべきファイル、例えばいずれのリストにも存在しない記事等を予想してもよい。
【０３９０】
クライアントは、最後に使用したファイルのリストを更に維持し、メモリが枯渇する前にそれらファイルを削除できる。このリストはＲＭＳに格納され、相対パス及びファイル名によりファイルを参照する。ファイル名から任意の意味を除去することを意図しているため、パス及びファイル名は短くなる。これは、サーバ上での削除論理に問題がある場合に安全弁としての役割を果たす。
【０３９１】
５．３．不完全なダウンロード
５．４．クライアントロギング
クライアント上でユーザ動作、事象及び例外をログ記録し、以下の目的でそれらをサーバに送出する必要がある：
・テスト中の情報のデバッグ
・顧客のサポートのための情報の提供
・報告及び推薦のための使用データの収集
５．４．１．Logger
Loggerオブジェクトは、クライアント上でのロギングを制御するために使用される。それは、DataObjectSetであり、ＭＳＴＰを使用してサーバと同期される。
【０３９２】
Loggerは以下の属性を含む：
・Level：ログが格納されるレベル、より低いレベルの事象は破棄される。
＊DEBUG：アプリケーションをデバッグするのに有用な事象
＊INFO：アプリケーションの進捗を強調表示する情報メッセージ
＊WARN：潜在的な問題が存在することを示す
＊ERROR：エラーが発生したが、アプリケーションは継続するように管理される
＊OFF：何もログ記録されない。
【０３９３】
・Priority：ログがサーバに送出される頻度を制御する
＊MIN：クライアントがサーバに対して次に要求を行なう時又はmaxSizeに到達した時
＊NORMAL：５分毎（又はMINと同様）
＊MAX：３０秒毎（又はMINと同様）
この挙動は、プロパティにより制御され且つ調整される
・MaxSize：クライアント上に格納する最大レコード数
・TimeOffset：サーバとクライアントとの時間差
・LogRecordes：ログ自体
Loggerは、クライアントログ毎にLogRecordを含む。LogRecordは、以下の属性を含む：
・Message：起こったことに関する信頼できる説明
・Level：このログのレベル
・Date：クライアント時間及びTimeOffsetを使用して計算されたサーバ時間
・SessionId：この事象（ある場合には）が発生した時のサーバsessionId
・EventTypeGuid：この事象（ある場合には）に対するevent_typeテーブルにおける識別子
・Parameters：この事象に対して関連するパラメータ
図６９を参照。
【０３９４】
５．４．２．クライアントのデバッグ
クライアントがテストしている間、エラーが発生した時に起こっていることを理解でき且つそれらをMantisバグ報告に含めることができるように、テスタがクライアントログを容易に閲覧できるようにする必要がある。
クライアントは以下をログ記録する：
・タスクを実行するのに必要とされる全てのパラメータを含むタスク
・コマンドを実行するのに必要とされる全てのパラメータを含むコマンド
・全ての関連する情報を含む例外
各LogRecordは、インシデントとしてログ記録され、インシデントモニタのウェブインタフェースを使用してテスタにより閲覧される。各レコードがサーバ時間を使用してログ記録されるため、インシデントは日付で順序付けされ、クライアント及びサーバ動作のリストを行なわれた順で与える。
【０３９５】
５．４．３．カスタマーサポート
顧客がカスタマーサポートと連絡を取る場合、カスタマーサポートがクライアントにより生成された最後のLogRecordを見られるように、クライアントからサーバにLoggerオブジェクトをプッシュする必要がある。クライアントはプッシュを開始する必要があるが、これは、ログ優先度がMINに設定されている場合にはしばらく行なうことができない可能性がある。従って、Loggerオブジェクトを掲示するようにクライアントに命令する方法を必要とする。
【０３９６】
ユーザの状況を再作成するために十分な情報をログ記録する必要がある。この情報は、LogRecord.parametersハッシュテーブルに格納される。eventTypeGuid属性が設定される場合、レコードはcustomer_eventテーブルに挿入され、パラメータはcustomer_event_valに挿入される。事象ロギングがクライアントに対する応答を遅延させないように、customer_event及びcustomer_event_valに挿入するためにキューを使用する。例外は、customer_logger.priorityがMAXに設定される場合である。この場合、ユーザは事象が発生した時にその事象の認識を希望し、それらレコードはデータベースに直接挿入される。
【０３９７】
５．４．４．使用データ
クライアント使用データは、事象テーブルにおいてトリガを使用してポピュレートされる。従って、例えば顧客がトラックを再生する事象を受信した場合、customer_track.play_countが増分される。
【０３９８】
５．４．５．データベース必要条件
カスタマーサポートは、クライアントにより生成されるロギング及びそれがサーバに送出される頻度を制御できる必要がある。これは、customer_loggerテーブルを使用して制御される。図７０を参照。更新されたLoggerオブジェクトがクライアントにプッシュされるように、このテーブルが変更される度にレコードはcustomer_object_logに挿入される。
【０３９９】
６．ＤＲＭ
６．１．概要
MusicStationは、移動電話を使用するソフトウェアアプリケーションであり、これによりユーザは、モバイルネットワークを使用して移動中に電話機において音楽を発見及び管理でき且つ聴くことができる。Omnifoneは、特にモバイルネットワークオペレータ（ＭＮＯ）と協力してMusicStationを販売し、MusicStationのユーザが最大で最良の範囲の音楽を入手可能であることを保証するために音楽業界と密接に協力している。そのようなデジタル音楽メディアの膨大なライブラリは非常に貴重であり、支払いを行なう適正なユーザがシームレスなアクセスができるようにする一方で盗用及び悪用から保護される必要がある。デジタル権利管理（ＤＲＭ）は、デジタルメディアの合法的な配信及び使用を制御し且つ容易にする方法を提供する。
【０４００】
MusicStationに対する主なハンドセット技術プラットフォームは、Ｊ２ＭＥ（Java 2 Platform Micro Edition）である。このプラットフォームは、移動電話ハンドセットの最大の使用範囲を提供するため選択された。本明細書において、保護コンテンツを配信し且つそのコンテンツを使用する権利をセキュリティ上安全に発行するために、OmnifoneのＪ２ＭＥ MusicStationハンドセットアプリケーション及び関連するネットワークサービスにより使用される方法を説明する。
【０４０１】
MusicStationのＤＲＭは、ＯＭＡ（オープンモバイルアライアンス）ＤＲＭ ｖ２の仕様の実現例である。この仕様は、移動装置に対してコンテンツを保護する好適な方法としてモバイル業界及び音楽業界の双方により広く採用されている。ＯＭＡ ＤＲＭ ｖ１はハンドセットメーカにより広く採用されているが、書き込み時には、ＯＭＡ ＤＲＭ ｖ２をサポートするハンドセットは殆どない。このため、本明細書で説明するＯＭＡ ＤＲＭ ｖ２の実現例は、OmnifoneがMusicStationハンドセットアプリケーション及び関連するMusicStationネットワークサービスに内蔵したものである。
【０４０２】
６．１．１．ＤＲＭの概要
コンテンツが配布される前に、無許可のアクセスから保護するためにコンテンツはパッケージ化される。コンテンツサーバ（ＣＳ）はＤＲＭコンテンツを配布し、権利発行器（ＲＩ）は関連するRightsオブジェクトを生成し且つ配布する。コンテンツサーバ及び権利発行器は、システムにおける役割を取り入れる。それらは、展開に依存して同一のアクター又は異なるアクターにより提供されてもよく、また同一のネットワークノード又は異なるネットワークノードにより実現されてもよい。例えば、事前にパッケージ化された保護コンテンツはコンテンツの効率的な配布のために複数のコンテンツサーバを介して配信される。ＤＲＭの概要を示す図７１を参照。
【０４０３】
Rightsオブジェクトは、ＤＲＭコンテンツが使用される方法を管理する。これは、１つのＤＲＭコンテンツに関連付けられる許可及び制約を指定する文書である。ＤＲＭコンテンツは、関連するRightsオブジェクトなしで使用できず、Rightsオブジェクトにおいて指定される許可及び制約にのみ従って使用されてもよい。
【０４０４】
全てのＯＭＡ ｖ２システムのように、MusicStationのＤＲＭはRightsオブジェクトからＤＲＭコンテンツを論理的に分離する。これは、「分離配信」として周知である。ＤＲＭコンテンツ及びRightsオブジェクトは、別個に又は一緒に要求されてもよく、それらは別個に又は同時に配布されてもよい。例えばユーザは、同一のトランザクションにおいて１つのコンテンツを選択し、支払いをして、ＤＲＭコンテンツ及びRightsオブジェクトを受信できる。その後、Rightsオブジェクトが期限切れになった場合、ユーザは、ＤＲＭコンテンツを再びダウンロードする必要なく、戻り且つ新しいRightsオブジェクトを取得できる。
【０４０５】
ＤＲＭコンテンツと関連付けられるRightsオブジェクトは、購入時点で施行される必要がある。MusicStationハンドセットアプリケーション内のＤＲＭエージェントは、ＤＲＭコンテンツに対する許可及び制約を装置上で実行する役割を有するアプリケーションの信頼できる要素を取り込み、それにより装置上のＤＲＭコンテンツへのアクセスを制御する。
【０４０６】
Rightsオブジェクトは、特定のＤＲＭエージェントに暗号化結合されるため、そのＤＲＭエージェントのみがそのオブジェクトにアクセスできる。ＤＲＭコンテンツは、有効なRightsオブジェクトによってのみアクセスされるため、自由に配信される。例えばこれにより、ユーザはユーザ間でＤＲＭコンテンツを自由に渡せるため、「超流通」が可能になる。新しい装置上のＤＲＭコンテンツにアクセスするために、新しいRightsオブジェクトは要求され且つ装置上のＤＲＭエージェントに配布される必要がある。
【０４０７】
６．１．１．１．コンテンツオブジェクトの保護
ＤＲＭコンテンツフォーマット（ＤＣＦ）は、自身のＭＩＭＥコンテンツタイプを含むＤＲＭコンテンツに対する安全なコンテンツパッケージである。これは、暗号化コンテンツに加え、コンテンツ記述（元のコンテンツタイプ、メーカ、バージョン等）及び権利発行器ＵＲＩ（Rightsオブジェクトが取得される可能性のある場所）等の追加の情報を含む。この追加の情報は暗号化されず、Rightsオブジェクトが検索される前にユーザに提示されてもよい。メディアコンテンツ（例えば、音楽ファイル）のみがＤＣＦファイルに暗号化される。
【０４０８】
ＤＣＦ内のＤＲＭコンテンツをアンロックするのに必要なコンテンツ暗号鍵（ＣＥＫ）は、関連するRightsオブジェクトに含まれる。従って、RightsオブジェクトなしでＤＲＭコンテンツにアクセスするのは不可能である。ＤＲＭコンテンツは、Rightsオブジェクトに指定されるようにのみ使用される。MusicStationのＤＲＭは、ＤＲＭエージェントがＤＣＦの整合性を検査することを可能にする機構を含み、それによりある無許可のエンティティによるコンテンツの変更から保護する。
【０４０９】
６．１．１．２．Rightsオブジェクトの保護
Rightsオブジェクトは、権利暗号鍵（ＲＥＫ）を使用して保護される。ＲＥＫは、コンテンツ暗号鍵等のRightsオブジェクトの機密部分を暗号化するために使用される。配布中、ＲＥＫは、対象のＤＲＭエージェントに暗号化結合される。このように、対象のＤＲＭエージェントのみがRightsオブジェクト及びＣＥＫにアクセスできる。従って、Rightsオブジェクトは本質的に安全である。
【０４１０】
６．２．ハンドセット上のMusicStation
使用された提供方法に関わらず、最終的にMusicStationアプリケーションはユーザの移動電話ハンドセットに常駐する。MusicStationハンドセットアプリケーションの各インストールは、異なる電話の機種及びハンドセットファームウェアバージョンの各々に潜在的に固有のソフトウェアのカスタム化ビルドである。ソフトウェアビルドは、Omnifoneの特許取得済みのデバイス適応アーキテクチャ（ＤＡＡ）により作成及び管理され、以下に説明するOmnifoneの高度アプリケーション提供ソフトウェアを使用して適切なハンドセットに配布される。
【０４１１】
６．２．１．MusicStationの提供
ＭＮＯと協力し、MusicStationモバイルハンドセットアプリケーションが電話機に「提供」される方法が２つある。この章において、それら双方について詳細に説明する。MusicStationアプリケーションをハンドセットに配信する好適な方法は、エンドユーザに到達する前にアプリケーションを装置に事前にインストール（プリインストール）することである。この種のアプリケーションを配信する経験により、サービスを開始する電話機のハードキー（音楽ボタン）による最も望ましい方法で事前にインストールされる場合、エンドユーザによる発見は９３％もの割合になることが示される。ＭＮＯによるこの種のアプリケーションのＯＴＡ提供の同様の経験では、成功の割合（すなわち、要求者に対する正常に接続されたユーザの割合）は、アプリケーションが事前にインストールされる時より１桁少ないことが示される。
【０４１２】
６．２．１．１．アプリケーションの事前インストール（プリインストール）
通常、この種の装置のカスタム化は、ＭＮＯの要求時にハンドセットメーカにより行なわれ、ハンドセットがメーカの敷地を離れる前に実行される。更にこれは、サプライチェーンにおいてカスタム化機能を有するか又はＭＮＯの倉庫でセルにおいて同様のことを実行するMobiltron等のハンドセットメーカにより実行される。
【０４１３】
この事前インストールが実行される場合は必ず、Omnifoneの事前インストール提供ツールであるPreloaderによりサポートされる。Preloaderは、事前インストールの施設において作業者により使用されるネットワーク接続デスクトップアプリケーションである。Preloaderへのアクセスは、Software License（ソフトウェアライセンス）、userid（ユーザＩＤ）及びpassword（パスワード）により制御され、許可されたＩＰアドレスのリストによりフィルタリングされる。Preloaderへのアクセスは、ユーザ、Software Licenseにより又は組織により随時無効にされる。
【０４１４】
Preloaderにより、許可されたユーザは最新の最適なMusicStationクライアントソフトウェアビルドにアクセスできる。Omnifoneは、Preloaderがアクセスできるソフトウェアビルドをメーカ及び機種により制御できる。Preloaderにより、ハンドセットカスタム化ツールへの組込み及びインストールするユーザの処理のための適切なMusicStationクライアントソフトウェアビルドの位置の特定、ダウンロード及びローカルでの格納が容易になる。
Preloaderには、新しいソフトウェアビルドがダウンロードできることをインストーラに警告できる通知システムが内蔵される。
【０４１５】
６．２．１．２．無線配布（ＯＴＡ）
オープンＯＴＡ ＡＰＩのため、Omnifoneは、ユーザがMusicStationのＯＴＡを取得する際に使用する機構及びタッチポイントを複数サポートする。これは以下を含むが、それらに限定されない：
・（ＭＮＯ）ＷＡＰポータル要求
・要求におけるＳＭＳテキスト
・Ｗｅｂを使用する要求
・ＩＶＲの取得
・Ｗｅｂサービスリンク
・ＳＩＭがネットワークに最初に現れた場合等の困難なＭＮＯネットワーク統合
要求の機構に関わらず、MusicStationアプリケーションは、既に見ているＷＡＰポータル内で直接又はアプリケーションが別の方法を介して要求された場合はＷＡＰプッシュを介して、エンドユーザにＷＡＰダウンロードページを提供することにより配布される。
【０４１６】
６．２．１．３．アプリケーションの再インストール
MusicStationアプリケーションは、サーバに指示された場合にアプリケーションを完全に再インストールすることを強制する能力を含む。この例において、MusicStationアプリケーションはＯＴＡ ＷＡＰダウンロードを使用して再度ダウンロードされる。アプリケーションの再インストールがサーバにより命令される場合、旧バージョンのアプリケーションは実行しない。
【０４１７】
６．２．２．MusicStationハンドセットアプリケーション埋め込みメタデータ
各MusicStationハンドセットアプリケーション内には、情報及びメタデータの集合が自動的に挿入され、本明細書で説明されるような種々の目的で使用される。
【０４１８】
６．２．２．１．ハンドセットのメーカ、機種、バージョン及びファームウェアの改訂
全てのMusicStationハンドセットアプリケーションは、特定のハンドセットのメーカ、機種、バージョン及びファームウェアの改訂の組合せに対してビルドされる。この組合せを識別するメタデータは、全てのMusicStationアプリケーションビルドに埋め込まれる。従って、サーバは、各MusicStationアプリケーションが実行しているハンドセット構成の種類を正確に認識する。これは、サーバがこの特定のMusicStationアプリケーションと以前に通信したことがない場合でも当てはまる。
【０４１９】
６．２．２．２．Software License（ソフトウェアライセンス）
全てのMusicStationハンドセットアプリケーションは、特に特定のMusicStationサービスに対してビルドされる。これに影響を及ぼすために、全てのMusicStationハンドセットアプリケーションは、「Software License」を内部に埋め込む。Software Licenseは５１２ビットの乱数であり、サーバに提示されると、このアプリケーションインスタンスを特定のMusicStationサービスに関連付けるために使用される。各サービスはロック又はアンロックされ、アンロックされたサービスのみがエンドユーザにより使用可能である。
【０４２０】
６．２．２．３． MusicStationルートＣＡ証明書
各MusicStationアプリケーションは、アプリケーション内にMusicStationルートＣＡ証明書を埋め込む。この証明書については本明細書の後の節で更に詳細に説明するが、この証明書は、MusicStationハンドセットアプリケーションとサーバとの間で送出されるメッセージに署名し且つ検査するために使用される。
【０４２１】
６．２．３．アプリケーションの許可及び署名
Ｊ２ＭＥは、セキュリティモデルを実現し、これは、一般にソフトウェアアプリケーションがアクセスできると予想される特定の機能（例えば、メモリ／ファイルシステムへのアクセス又はネットワークへのアクセス）が実際には制約されることを意味する。MusicStationのようなアプリケーションは、そのような機能を広範に利用するため、ハンドセットのそれら一般的なセキュリティ保護された機能へのアクセスを必要とすることは明らかである。
【０４２２】
MusicStationアプリケーションがそれら制約された機能にアクセスできるようにするために、アプリケーションは「署名」される。署名及び結果として得られる署名者のＰＫＩ証明書は、アプリケーションのＪＡＤファイルに格納される。MusicStationアプリケーションが実行している場合、この署名は検査され、証明書はそれらの目的のために既にハンドセット上にある保護されたドメインルート証明書の１つに対して検査される。アプリケーションが適切に署名された場合、制約される機能は利用可能になる。
【０４２３】
一般に、電話機上に既に存在するルート証明書は、電話機の製造業者、モバイルネットワーク又はVeriSign等の認証局からのルート証明書である。
【０４２４】
６．２．４．MusicStationアプリケーション自体に属するＤＲＭ
ハッカーがＤＲＭシステムを破壊しようとする方法は多く存在する。それら方法の１つには、ＤＲＭを実現するソフトウェアコードをリバースエンジニアすることである。そのため、MusicStationハンドセットアプリケーションは、ソフトウェアを除去されることから保護するために電話機上に常駐するＤＲＭを使用して常にインストールされる。
【０４２５】
ＯＭＡ ｖ２等の高度なＤＲＭは多くのハンドセット上に存在しないが、必要とされる「フォワードロック」コンテンツ制御機構をサポートするＯＭＡ ｖ１は殆どのハンドセット上に存在する。フォワードロックはそれが提案するように動作し、この状況においてはMusicStationハンドセットアプリケーションであるコンテンツ項目の電話機からの転送又は伝送を不可能にする。MusicStationは、事前インストールされるか又はＯＴＡインストールされるかに関わらず、ＯＭＡ ｖ１フォワードロック保護ファイルとしてインストールされる。
【０４２６】
MusicStationアプリケーションのＯＴＡ配布を更にセキュリティ保護するために、ＭＮＯネットワークゲートウェイから発行することを確定されたアプリケーションダウンロードに対するＯＴＡ要求のみがサポートされる。これにより、アプリケーションコードは、一般のインターネットから発行されるのではなく、特定のＭＮＯのモバイルインターネットを介して電話機にダウンロードされることが保証される。これは、ネットワーク通信ヘッダ及びメタデータにおいて見つけられる送信元ＩＰアドレス又は宛先ＩＰアドレスが、ゲートウェイがサービスデータベースに格納したアドレスであり、またＭＮＯのアドレスであることが周知であることを確認することにより実現される。
【０４２７】
６．２．５．音楽の事前インストール
音楽コンテンツは、アプリケーションがインストールされるのと同時に電話機に事前インストールされる。このコンテンツは、宣伝のために無料であり且つＤＲＭされなくてもよいか、あるいは購入するコンテンツであり且つ音楽がMusicStationを介してダウンロードされたＯＴＡである場合に適用されるＤＲＭと同一のＤＲＭに管理される。事前インストールされたコンテンツは、MusicStationがボックス再生から得られることを可能にする。
【０４２８】
６．３．初めてMusicStationを使用する
所有者がMusicStationアプリケーションを使用する前に、アプリケーションは、適切なMusicStationサービスに登録し、ダウンロードするＤＲＭ保護音楽コンテンツにアクセスできるようにClient Certificate（及び関連するClient Private Key）を発行してもらうために、まずMusicStationサーバに接続する必要がある。Rightsオブジェクト（アクセス規則及びＤＲＭ保護コンテンツにアクセスするための鍵を含む）を発行してもらうために、MusicStationアプリケーションは権利発行器に登録する必要がある。この章において、この２ステップの登録処理について説明する。
【０４２９】
６．３．１．MusicStationサービス登録
初めてMusicStationが開始すると、MusicStationは、サービスに登録し、ＤＲＭ保護コンテンツにアクセスできるようにClient Certificate及びClient Private Keyを得るために、MusicStationサーバに接続する必要があることを認識する。登録を行なうために、サーバは装置を一意に識別できる必要がある。「２パス」MusicStationサービス登録プロトコルは、これを達成するプロトコルである。このプロトコルは、加入者及び装置のＩＤを含み、その結果、Client Certificate及び関連するClient Private KeyをMusicStationサーバ（認証局）から装置にセキュリティ上安全に転送できる。このMusicStation装置のみがClient Private Keyにアクセスできることが必須であるため、登録プロトコルはＨＴＴＰＳセキュア通信を使用する。
【０４３０】
６．３．１．１．Service Registration Request
MusicStationアプリケーションは、サーバに情報を提供して装置及びユーザを一意に識別してもよいように、ハンドセットのIMEI、Bluetooth Address、IMSI及び加入者のMSISDNにアクセスを試みる。サーバに送出される要求パラメータについては、図７２の表：Service Registration Requestのパラメータにおいて説明する。装置又はＳＩＭカードをサーバにおいて識別するために、IMEI、Bluetooth Address又はIMSIのうちの１つ†が供給される必要がある。
【０４３１】
６．３．１．２．ＭＮＯ追加メタデータ
MusicStationハンドセットアプリケーションからMusicStationサーバへの通信がＭＮＯのネットワーク化機器を介して転送されるため、以下の加入者及び潜在的にハンドセット識別子はＨＴＴＰ要求ヘッダに追加される。この情報は、それらヘッダから抽出され、追加の識別の目的でMusicStationサーバにより使用される。図７３を参照。加入者をサーバにおいて識別するために、MSISDN又はParty IDの一方†が供給される必要がある。
【０４３２】
６．３．１．３．サービス登録処理
MusicStationサーバがService Registration Requestメッセージを受信した場合、これらのステップが後続する。
【０４３３】
６．３．１．３．１．ＭＮＯホームネットワークからの登録か？
サーバが登録要求を受信した場合、サーバは、MusicStationハンドセットアプリケーションが現在使用されているモバイルデータネットワークがＭＮＯのホームネットワークであることをチェックする。これは、インターネットトラフィック転送機器及びＭＮＯのホームネットワークゲートウェイのＩＰアドレスのデータベース格納レコードの集合を使用して行なわれる。
通常の設定は、ＭＮＯのホームネットワーク又はローミング契約をしている第三者ＭＮＯのネットワーク等の他の特定のネットワークにおける装置登録のみを可能にすることである。
【０４３４】
６．３．１．３．２．顧客認証の検証
新しいMusicStationハンドセットアプリケーションをMusicStationサービスに登録するための要求を受信すると、サーバは以下のテストを実行する：
・Software Licenseが有効でアクティブなMusicStationサービスに対するものであることを確認する。
・加入者がMSISDN又はParty ID等により識別されたことを確認する。
・MSISDN又はParty IDはこのＭＮＯの顧客である（ＡＰＩがＭＮＯに存在する場合）ことを確認する。
・オプションとして、装置がIMEI又はBluetooth ID等により識別されたことを確認する。
これら認証が確認されると、サーバは以下のＰＫＩ段階に進む。
【０４３５】
６．３．１．３．３．MusicStation及び公開鍵インフラストラクチャ（ＰＫＩ）
MusicStationサービス登録が正常に完了した後、装置は、Rightsオブジェクトを要求し且つその結果ＤＲＭコンテンツにアクセスできるように権利発行器に登録する必要がある。しかし、権利発行器は、確実に識別できる装置のみを登録する。この識別は、MusicStationサーバがＰＫＩ認証局（ＣＡ）としての役割を果たし、公開鍵証明書、Client Certificateを登録済みMusicStationハンドセットアプリケーション毎に生成し、それにより各装置の信憑性及び一致を証明することにより容易になる。MusicStation権利発行器はＣＡを信頼し、MusicStationハンドセットアプリケーションにより権利発行器に提示されるClient Certificateが実際にＣＡにより発行されたことを確認できるように、MusicStationルートＣＡ証明書のコピーを有する。
【０４３６】
公開鍵インフラストラクチャ（ＰＫＩ）は使用される仕組みであり、ユーザの一致又はこの状況においてはMusicStationハンドセットアプリケーションの一致を調査し且つ保証する第三者機関を規定する。これにより、ユーザに対する公開鍵の結び付けが可能になる。一般にこれは、分散した場所にある他の連携するソフトウェア、すなわちMusicStationハンドセットアプリケーションと共に、この場合はMusicStationサーバである中央位置にあるソフトウェアにより実行される。
【０４３７】
ＰＫＩの仕組みにより、ユーザ（MusicStationアプリケーション、MusicStationサーバ、MusicStation権利発行器等）は認証され、システムにおいてユーザ間を移動するメッセージを暗号化及び復号化するためにＰＫＩ証明書の情報（すなわち、他の各公開鍵）を使用できる。一般にＰＫＩは、クライアントソフトウェア（MusicStationハンドセットアプリケーション）、認証局等のサーバソフトウェア（MusicStationサーバ）及び動作手順から成る。ユーザは自身の秘密鍵を使用してメッセージにデジタル署名してもよく、別のユーザはその署名をチェックできる（ＰＫＩ内のＣＡにより発行されるユーザの証明書に含まれる公開鍵を使用して）。これにより、２つ（又は２つ以上）の通信者は、事前に機密情報を交換する必要なく機密性、メッセージの整合性及びユーザ認証を確立できる。
【０４３８】
ＣＡの署名の信憑性及びＣＡが信頼できるかについては、証明書を検査することにより判定される。しかし、この連鎖はいずれかで終了する必要があり、いわゆる木のルートであるようなMusicStationＣＡルート証明書で終了する。ルート証明書は、黙示的に信頼され（証明書はトラストアンカーと呼ばれることもある）、ウェブブラウザ等の多くのソフトウェアアプリケーション、すなわちここではMusicStation権利発行器及びMusicStationハンドセットアプリケーションに含まれる。
【０４３９】
６．３．１．３．４．Client Certificate及びClient Private Keyの生成
新しいClient Certificateを発行する際の第１のステップは、登録しているMusicStationハンドセットアプリケーションに対する新しい公開／秘密鍵の対を生成することである。このＰＫＩの実現例は、ＲＳＡ１０２４ビット公開鍵アルゴリズムを使用する。
【０４４０】
鍵の対が生成されると、公開鍵はビルドするためにMusicStationのＣＡにより使用され、Client Certificateを発行する。Client Certificateは、Client Certificateに含まれる公開鍵が証明書に書かれたMusicStationハンドセットアプリケーションに属することをＣＡが証明することを示す。ＣＡの役割は、アプリケーションの認証を検査することであり、従って、ユーザ（MusicStationの権利発行器等の信頼する相手）はＣＡの証明書の情報を信頼できる。その概念は、ユーザがＣＡを信頼し且つＣＡの署名を検査できる場合に、特定の公開鍵がClient Certificateにおいて識別されたユーザに実際に属することを検査できることである。
【０４４１】
Client Private Keyは、MusicStationサーバに格納されない。その装置のみが開くことのできるメッセージをサーバが作成できるように、Client Public Keyのみが格納される。
【０４４２】
X.509標準は、全てのMusicStation証明書に対して使用される。X.509は、公開鍵インフラストラクチャ（ＰＫＩ）のＩＴＵ−Ｔ標準である。X.509は、特に公開鍵証明書の標準形式及び証明書パス検査アルゴリズムを指定する。
【０４４３】
６．３．１．３．５．Client GUID
Client GUIDは、新しいMusicStationハンドセットアプリケーションがサーバに登録される度に生成される一意の番号（Globally Unique ID（グローバルで一意のＩＤ））である。Client GUIDがMusicStationハンドセットアプリケーションに返されると、Client GUIDはMusicStationサーバ又はMusicStation RIに対する全ての後続する通信及び要求に格納されて返される。
【０４４４】
６．３．１．４．Service Registration Response
MusicStationのService Registration Requestメッセージに応答して、Service Registration ResponseメッセージがＣＡから装置に送出される。このメッセージは、ＨＴＴＰＳを介して保護されたClient Certificate及びClient Private Keyを搬送する。図７４：Service Registration Responseのパラメータを参照。†Status = "Success"であるかのみ必須である。
【０４４５】
６．３．１．５．サービス登録後処理
正常なサービス登録に対する結果が返された後、MusicStationハンドセットアプリケーションは以下のタスクを実行する。
【０４４６】
６．３．１．６．Client Certificateの格納
装置に対するClient Certificateは、アプリケーションのレコード管理システム（ＲＭＳ）記憶装置に格納される。Ｊ２ＭＥのＲＭＳは、アプリケーションが永続的にデータを格納し且つ後でそれを検索できる機構を提供する。レコード指向方法において、Ｊ２ＭＥのＲＭＳは複数のレコード記憶装置を含む。
【０４４７】
６．３．１．６．１．Client GUIDの格納
Client GUIDは暗号化され、スクランブルされ、アプリケーションのＲＭＳに格納される。これは、MusicStationサーバ及びMusicStation RIに対する全ての今後の要求において使用される。
【０４４８】
６．３．１．６．２．Client Private Keyの格納
MusicStationハンドセットアプリケーションは、Ｊ２ＭＥ秘密ＲＭＳ機能を使用する。これは、ＲＭＳレコード記憶装置を作成したMusicStationアプリケーションのみがその記憶装置にアクセスできることを意味する。
【０４４９】
しかし、MusicStationはClient Private Keyのセキュリティを更に保証する。起こる可能性は非常に少ないがＲＭＳが危険にさらされた場合に、MusicStationハンドセットアプリケーションのみが追加のセキュリティ手段としてClient Private Keyを暗号化した後で格納する。更にアプリケーションは、Client Private KeyをＲＭＳに格納する前及び格納している間に特定の技術を使用してClient Private Keyを更に分かりにくくする。
【０４５０】
６．３．２．権利発行器登録
装置が自身のClient Certificateを取得した直後に、装置は権利発行器（ＲＩ）への登録を試みる。装置は、登録及びＲＩからのRightsオブジェクトの取得を行なう前にMusicStationサービスに登録される必要がある。ＲＩ登録処理が正常に完了することにより、装置はドメイン鍵（ＤＫ）を取得できる。ＤＫは、装置に配布されるRightsオブジェクトの権利暗号鍵(ＲＥＫ）を保護するために使用される１２８ビットのＡＥＳ対称鍵である。
【０４５１】
ＲＩ登録プロトコルは、装置とＲＩとの間の完全なセキュリティ情報交換及びハンドシェークである。RI Registration Requetメッセージに応答して、RI Registration Responseメッセージが権利発行器から装置に送出される。このメッセージは、登録プロトコルを完了し、正常な場合は装置がそのＲＩに対してＲＩコンテキストを確立することを可能にする。ＲＩコンテキストは、２パスＲＩ登録プロトコルの間に権利発行器と交渉された情報から成る。このＲＩコンテキストは、装置がRightsオブジェクトを正常に取得するために必要である。
【０４５２】
６．３．２．１．ＤＲＭドメイン
ドメインは、権利発行器により配信される共通のドメイン鍵を所有する１つ〜複数の装置の集合である。同一ドメインの全ての装置は、同一のDomain Rightsオブジェクト（ＲＯ）及び潜在的にそれらＲＯに保護された音楽にアクセスできる。
【０４５３】
MusicStationにおいて、ＤＲＭドメインはネットワーク中心である。ＲＩは、ドメインを規定し、ドメイン鍵を管理し、ドメインに含まれる装置及びその数、並びにドメインから除外される装置及びその数を制御する。一般に各MusicStationハンドセットアプリケーションは自身のＤＫを有し、１つのMusicStation装置のみが各ドメインに存在する。
【０４５４】
６．３．２．２．RI Registration Request
RI Registration Requestメッセージは、装置から権利発行器に送出され、２パスＲＩ登録プロトコルを開始する。図７５：MusicStation RI Registration Requestのパラメータを参照。
【０４５５】
６．３．２．３．RI Registration Response
RI Registration Requestメッセージに応答して、RI Registration Responseメッセージが権利発行器から装置に送出される。登録が正常である場合、ドメイン鍵はMusicStationハンドセットアプリケーションに配布される。このＤＫは、要求においてＲＩに送出されたClient Certificate中に見つけられるClient Public Keyを使用して暗号化される。このように、装置のみが復号化する必要のあるClient Private Keyにアクセスでき且つＤＫにアクセスできるため、ＤＫはセキュリティ上安全に装置に転送される。図７６：RI Registration Responseのパラメータを参照。†Status = "Success"であるかのみ必須である。
【０４５６】
６．３．２．４．ＲＩ登録後処理
正常なRI Registration Responseが受信された後、MusicStationは返されたドメイン鍵を暗号化し且つ分かりにくくし、それをアプリケーションの専用ＲＭＳに格納する。その後ＤＫは、Rightsオブジェクト（ＲＯ）の機密部分にアクセスするために、MusicStationにより使用されてＤＫ暗号化権利暗号鍵（ＲＥＫ）にアクセスする。
【０４５７】
６．４．音楽を聴く
音楽を聴くために、MusicStation装置は、ＤＲＭコンテンツフォーマット（ＤＣＦ）にＤＲＭ保護コンテンツとして格納される音楽ファイルとＤＲＭをアンロックするためのコンテンツ暗号鍵（ＣＥＫ）を含むＲＯとを必要とする。
【０４５８】
ＤＣＦ及び対応するＲＯが同時に装置上に存在しないことが可能である。ＲＯはＤＣＦに対するＵＲＬを含み、ＤＣＦはＲＯに対するＵＲＬを含むため、一方を有する場合に他方を取得できる。双方が装置上に存在しない場合、MusicStationアプリケーションにおいて示されるトラックリストはＲＯ及びＤＣＦの双方のＵＲＬを含むため、探索において又は閲覧中にトラックの位置が特定された後、双方のファイルは同時に要求される場合が多い。
【０４５９】
６．４．１．Rightsオブジェクトの取得
２パスＲＯ取得プロトコルは、装置がRightsオブジェクトを取得する際のプロトコルである。このプロトコルは、装置及びＲＩ、整合性保護要求、並びにＲＯの配布の相互認証と、ＲＯを処理するのに必要な暗号鍵材料のセキュリティ上安全な転送とを含む。
【０４６０】
６．４．１．１．RO Acquisition Request
RO Acquisition Requestメッセージは装置からＲＩに送出され、Rightsオブジェクトを要求する。このメッセージは２パスＲＯ取得プロトコルの第１のメッセージである。図７７：MusicStation RO Acquisition Requestのパラメータを参照。
【０４６１】
６．４．１．２．RO Acquisition Response
RO Acquisition Requestメッセージに応答して、RO Acquisition ResponseメッセージがＲＩから装置に送出される。これは、当該音楽ＤＣＦに対する保護コンテンツ暗号鍵（ＣＥＫ）を含むＲＯを搬送する。図７８：MusicStation RO Acquisition Responseのパラメータを参照。†Status = "Success"であるかのみ必須である。
【０４６２】
６．４．１．３．Client Certificateの取消し
ＲＩは、装置のセッション毎に１度、装置のClient Certificateが依然として有効であるかをＣＡに確認する。ＣＡは、取り消され且つ信頼すべきでないClient Certificateのリストである証明書取消しリスト（ＣＲＬ）を維持する。証明書は、使用される時は必ずこのリストに対してチェックされ、取消し状態を確認する必要がある。ＣＡが証明書を不適切に発行した場合、秘密鍵が危険にさらされた場合、ユーザがＣＡの使用ポリシーに違反した場合、あるいはMusicStationの管理者が何かの理由によりその装置へのアクセスを拒否した場合、証明書は取り消される。
【０４６３】
６．４．２．コンテンツのダウンロード
この節において、音楽コンテンツが準備され、保護され且つMusicStationコンテンツサーバからMusicStation装置にダウンロードされる方法を説明する。
【０４６４】
６．４．２．１．コンテンツの準備
音楽コンテンツは、MusicStationコンテンツサーバ（ＣＳ）からダウンロード可能にされる前に、暗号化により無許可のアクセスから保護される。音楽ファイルを暗号化することにより、ＤＲＭコンテンツフォーマット（ＤＣＦ）として周知である新しいファイルを作成する。
【０４６５】
MusicStationにおいて、音楽コンテンツの暗号化は、１２８ビットＲＣ４対称コンテンツ暗号鍵（ＣＥＫ）を使用して実行される。全てのＤＣＦは、異なる１２８ビットＲＣ４ＣＥＫを有する。従って、１，０００，０００個のトラックが音楽ライブラリに存在し、各トラックが１０個の別個のファイル形式（種々の電話機の好み及び音楽機能／コーデックに対応するため）で入手可能である場合、物理ファイル毎に１つ存在する１０，０００，０００個の別個のＣＥＫが存在する。これは、１つのＤＣＦに対するＣＥＫが危険にさらされたとしても、その結果として他のＤＣＦが危険にさらされることはないことを意味する。
【０４６６】
６．４．２．２．Content Acquisition Request
本質的に全てのＤＣＦがセキュリティ上安全であるため、ＤＣＦはセキュリティ保護されていないトランスポートプロトコルを使用して移送される。そのため、MusicStation装置はＨＴＴＰを使用して音楽コンテンツを要求する。図７９：Content Acquisition Requestのパラメータを参照。
【０４６７】
６．４．２．３．Content Acquisition Response
一般に、MusicStationコンテンツサーバからの応答は、ＨＴＴＰを介して要求されたＤＣＦファイルのバイナリストリームである。これは、殆どの場合にファイル全体であるが、モバイルネットワーク受信可能範囲が切断されることによりファイル転送が中断される場合もある。MusicStationハンドセットアプリケーションが今回はRangeパラメータを使用して次のContent Acquisition Requestを行なうような状況においては、有していないＤＣＦの部分のみを要求する。
【０４６８】
ＤＣＦバイトストリームが装置に到着すると、MusicStationアプリケーションはファイルをハンドセットのファイルシステムに漸進的に書き込む。内部／外部（取り外し可能媒体）メモリの双方が利用される。組み合わされた内部／外部メモリのMusicStationの割り当てが一杯である場合、MusicStationは最も長期間再生されていないトラックを除去する。これは、新しく要求されたトラックに対して利用可能な空間が十分にできるまで繰り返される。
【０４６９】
全ての音楽コンテンツは、ダウンロードされた時の元のＤＣＦ保護形式で格納される。任意のＤＣＦ内の音楽にアクセスするために、ＣＥＫにアクセスしてもよいように、対応するＲＯが要求される。
【０４７０】
６．４．３．音楽コンテンツの再生
MusicStationアプリケーションを介して音楽を再生するために、音楽トラックＤＣＦ及び対応するＲＯは電話機上に存在する必要がある。まず、ＲＯが検査され、ユーザが音楽を再生する権利を有するかが確認される。権利を有する場合、ＤＣＦを復号化して音楽トラックにアクセスするために、ＣＥＫはＲＯから抽出されて使用される。その後、音楽トラックは電話機のメディアプレーヤを介して再生される。
【０４７１】
６．４．３．１．権利表現言語（ＲＥＬ）の評価
関連するＲＯ及びＤＣＦが電話機上に存在するトラックを再生するように要求が行なわれると、ＲＯに含まれる権利表現言語はMusicStationＤＲＭエージェントにより解析される。ＲＥＬは、このＲＯに関連するＤＣＦのコンテンツがユーザにより購入され且つ使用される方法を規定する。ＲＥＬにより表される権利は非常に豊富であり、以下の例を含む：
・無制限の再生に対して、コンテンツは無料である。
・コンテンツは一度再生後、購入する必要がある。
・コンテンツは１週間無料で再生可能であるが、その後購入する必要がある。
・コンテンツは１ヶ月無料で再生可能であるが、５回を超えて再生できない。
・コンテンツは、購入されると何度でも再生可能である。
・現在ユーザが有効なＡＹＣＥ加入期間内である場合、コンテンツは何度でも再生可能である。
【０４７２】
６．４．３．２．コンテンツの復号化
ユーザが音楽を再生できるとＤＲＭエージェントがＲＥＬから判定した場合、１２８ビットＡＥＳ ＲＥＫは関連するＤＣＦの暗号化ＣＥＫに対するアクセス権を得るために使用される。１２８ビットＲＣ４ＣＥＫは、ＤＣＦを復号化して元の音楽トラックにアクセスするために使用される。この復号化トラックは、特定の電話機の挙動に依存して、トラック再生期間中非永続的なハンドセットメモリに格納されるか、あるいは復号化ストリームとしてハンドセットメディアプレーヤに漸進的に配布される。復号化音楽トラックは、ハンドセットに永続的に格納されることはない。
【０４７３】
６．５．ダウンロードし放題サービス
MusicStationの高度なＤＲＭ実現例のために、タウンロードし放題（ＡＹＣＥ）等の高度なコンテンツアクセスモデルのサポートが可能である。これにより、有効な加入期間内のユーザは、任意のトラックをダウンロードし且つ各トラックを好きなだけ何度も再生するために無制限のアクセス権を有することが可能になる。
【０４７４】
６．５．１．加入期間
MusicStationは、日毎、週毎、月毎又は要求される任意の他の期間等の広範な加入期間をサポートする。MusicStationサーバがＭＮＯ課金システムと通信し、加入期間に対する適切な課金でユーザの電話請求書を正常に送ると、加入期間は開始する。
【０４７５】
MusicStationサーバは、ユーザの請求書（前払い又は後払い）に正常に課金された日付／時間及びユーザが課金された加入期間の長さを記録することにより、ユーザの加入期間の状態を維持する。この情報は、MusicStationハンドセットアプリケーション上でＤＲＭエージェントと共有されるため、装置は、ユーザが有効な加入期間にいるか否かを認識する。
【０４７６】
６．５．２．加入期間の終了
ＡＹＣＥ加入を実現する好適な方法は、継続加入方法である。このモデルにおいて、MusicStationサーバは、現在の加入期間が終了した時に新たに加入する。ユーザは加入を取り消すオプションを有し、これにより自動再加入は中断される。前回の有効な加入期間の終了後、ユーザがコンテンツ（装置上であるかないかには関係ない）にアクセスしようとする場合、ユーザは加入期間を再度開始したいかを問われる。開始したい場合、継続加入期間が再度開始する。
加入モデルが継続加入でない場合、ユーザは現在の期間が経過する度に別のＡＹＣＥ期間に加入したいかを確認する必要がある。
【０４７７】
６．５．３．親Rightsオブジェクト
Rightsオブジェクトは、別のRightsオブジェクトから許可を継承してもよい。この機構は、例えばＡＹＣＥ加入の一部として取得されるコンテンツに対する権利を指定するために使用される。許可を継承するＲＯは、子Rightsオブジェクト（Ｃ−ＲＯ）と呼ばれる。継承される許可を含むRightsオブジェクトは、親Rightsオブジェクト（Ｐ−ＲＯ）と呼ばれる。
【０４７８】
関連するコンテンツがユーザに対して利用可能にされる前に、クライアント装置は、同一の権利発行器がＣ−ＲＯ及びそれに関連するＰ−ＲＯを発行し且つそれらが双方とも同一のドメインに属することを確認する。Ｐ−ＲＯは、ＤＲＭコンテンツを直接参照しない。
【０４７９】
６．５．４．ＤＲＭ時間
電話機上のＤＲＭエージェントは、ユーザにより変更不可能な正確な日付／時間（ＤＲＭ時間）に対して永続的なアクセス権を有するのが最適である。これは移動電話には当てはまらないため、MusicStationは、システムを騙し且つ加入サービス内で違法アクセスをしようとするユーザを阻止する一方で、公正なアクセス権が電話機の日付／時間に合法的な変更を行なうユーザに与えられるように、ＤＲＭエージェントが信頼できるＤＲＭ時間を入手可能であることを保証するために種々の方法を使用する必要がある。
【０４８０】
電話機が任意の時点で日付／時間を合法的に変更してもよく（例えば、初めて設定される場合、時間帯又は夏時間を変更する）、MusicStationサーバは常に信頼できる日付／時間を保持する。従って、ネットワーク接続されている間、ＤＲＭエージェントは常に信頼できる日付／時間データにアクセスできる。
【０４８１】
MusicStationサーバの日付／時間が装置のローカル日付／時間と潜在的に異なるため、ＤＲＭエージェントは絶対日付／時間ではなくローカル日付／時間に対するタイマを使用する。しかし、ＤＲＭエージェントは、ローカル日付／時間が保持するタイマに基づくべきであることを認識する場合に対してローカル日付／時間を更に監視する。これにより、ネットワーク接続及びローカルの電話機の日付／時間の変更の識別を行なわずに加入期間は終了できる。ネットワーク接続が行なわれる度に、全てのタイマ及び実際の日付／時間の知識は再設定される。
【０４８２】
ユーザが日付／時間を過去の時間に設定することによりシステムを騙そうとすると、問題が潜在的に発生する。それら問題は、以下の論理を使用して正常に対処される：
・MusicStationハンドセットアプリケーションが開始する場合、ローカル日付／時間を前回のアプリケーション終了日付／時間と比較する。アプリケーション開始日付／時間が前回のアプリケーション終了日付／時間より前である場合、それら２つの日付／時間の差分は相対タイマから減算される。
・最終的な結果として、判定したユーザがネットワーク接続していない間にMusicStationを使用できる最長の期間は、支払いをした加入期間（例えば、１週間）の長さと等しい総合アプリケーション使用時間である。これを行なうために、MusicStatonを終了する度に時間を記録し、MusicStationを開始する度に電話機の日付／時間を開始直前の時間に再設定する必要がある。限定された報酬では、その労力をかける価値がないと考えられるのは明らかである。
・アプリケーションが開いている間にユーザが日付／時間を変更することから保護するために、アプリケーションが実行中、日付／時間は１分に１度チェックされる。現在の日付／時間が前回の日付／時間より前である場合、それら２つの日付／時間の差分は相対タイマから減算される。
【０４８３】
ユーザがローカル日付／時間を未来の日付／時間に合法的に変更し、装置がサーバに接続できる場合、有効期限時間はサーバと再同期化される。接続が利用可能でない場合：
・未来の時間が有効な加入期間内である場合、トラックは再生される。
・未来の時間がライセンス有効期限時間を超える場合、システム設定可能閾値を除いて、装置がサーバに接続するまでトラックは再生されない。クロックを進めた（MusicStationが実行していない間に）ユーザと長期間MusicStationをしていないユーザとを区別することは不可能である。ユーザを再起動し且つ加入を更新するために、データネットワークを介するサーバへの再接続が必要とされる。
【０４８４】
６．５．５．ＡＹＣＥの課金
ＡＹＣＥシステムの課金は、全てのエンドユーザによる全てのトラックの全ての再生の絶対カウントを必要とする。従って、トラック購入情報はサーバに転送される必要があり、特定のサーバの全てのMusicStation装置による全ての予備再生は集約される。それら集約された再生カウントは、音楽が課金期間に再生された各権利所有者に対する著作権使用料の支払いを判定するために使用される。３０秒等の試聴閾値期間より短い期間再生されたトラックは無料の試聴と考えられ、著作権使用料の支払いの計算には含まれない。
【０４８５】
MusicStationが不要なネットワークトラフィックの原因とならないように、再生カウントは、自然なネットワーク接続がアプリケーションにより要求されるまで装置にバッファリングされる。このバッファリングは０Ｇ（飛行及びトンネル等）にも適用され、再生カウントが拡張された期間バッファリングされ、最終的に接続された時にサーバに送出される。
【０４８６】
６．５．６．混合モデル
MusicStationは、ＡＹＣＥにいるユーザがトラックを即金で購入してもよい融合商用モデルに対応する。加入期間を更新せずに終了する場合、ユーザが購入したそれらのトラックには依然としてアクセスできる。
【０４８７】
６．６．付録Ａ：鍵の管理
ここでは、装置上のMusicStationハンドセットアプリケーションのＤＲＭエージェントのみが知る公開鍵を使用して権利発行器が装置に対してドメイン鍵（ＤＫ）を発行する暗号方法を説明する。更に、先に装置に配布されたＫＤを使用して最初に暗号化された装置に配布されるＲＥＫを使用することにより、ＲＩがＲＯのＣＥＫを保護する方法を説明する。
【０４８８】
６．６．１．装置公開鍵の下でのKDの配信
この節は、ドメイン鍵KDを装置に提供する場合に当てはまる。KDは、ドメインＤに対して発行されたKREK（「Rightsオブジェクト暗号鍵」）を保護する時に使用される対称鍵ラッピング鍵である。KDは、送信元によりランダムに生成された１２８ビットの長さのＡＥＳ鍵であり、ドメインＤ毎に一意である。KREKは、Rightsオブジェクトのコンテンツ暗号鍵KCEKに対するラッピング鍵である。非対称暗号化方式ＲＳＡは、装置のRSA Client Public Keyを使用してセキュリティ上安全にKDを受信装置に送信するために使用される。
C = RSA.ENCRYPT(ClientPubKey, KD)
Cを受信後、装置はClient Private Keyを使用してCを復号化する：
KD = RSA.DECRYPT(ClientPrivKey, C)
６．６．２．ドメイン鍵KDの下でのKREKの配信
この節は、ドメインに対するRightsオブジェクトを保護する場合に当てはまる。鍵ラッピング方式ＡＥＳ−ＷＲＡＰが使用される。ＲＩはKDを使用してKREKを暗号化する：
C = AES-WRAP(KD, KREK)
Cを受信後、装置はKDを使用してCを復号化する：
KREK = AES-UNWRAP(KD, C)
付録１：画面フロー
７．概要
この付録において、MusicStationクライアントの画面及びユーザインタフェースを説明する。これは、完全な機能リスト、並びに機能毎のユーザ体験及び適切な画面ショットの説明を含む。機能はアプリケーションの主な機能グループに分類され、一般に、これはアプリケーションのメニュー構造に従う。
【０４８９】
７．画面レイアウト及びユーザ対話
７．１．登録
図８０を参照する。MusicStationが初めて開始される場合、クライアントがサーバに登録され且つユーザが一意の識別子又はGUIDを提供される一方で、ユーザはメッセージを見る。
【０４９０】
７．２．MusicStationへの参加
図８１を参照する。ユーザが初めてMusicStationの有料機能を使用しようとすると、オプションの無料の試用期間に参加するように要求される。ユーザは確定するように要求され、ｗａｐリンクを介して条件を閲覧するオプションが与えられる。その後、加入が確定され、ユーザは、確認の上継続を選択するように要求される。正常に加入したユーザは、MusicStationのメンバとして周知である。
【０４９１】
７．３．タブ及びメニュー
図８２を参照する。ユーザインタフェースは４つのタブに分けられる。各タブは、MusicStationの特定の基本的な機能を対象としている。
【０４９２】
・Home−Chartsを含むMusicStationにおいて利用可能な全てのコンテンツ及びSearch、Options等の全ての基本的な機能へのユーザアクセスを提供する。更に、ユーザがダウンロードしたコンテンツ（すなわち、「ストア」及び「ライブラリ」の双方）を強調表示する。
・Buzz−コミュニティ機能及び音楽ニュースにアクセスできる。
・Lineup−ダウンロードして聴くトラックの現在のキューを表示する。
・Playing−現在再生中のトラックの詳細を表示する。
Homeタブ及びBuzzタブは、階層メニュー構造で構成される複数の画面から成る。
【０４９３】
７．４．メニュー及びタブナビゲーション
ユーザは、ジョイスティックを使用してアプリケーションのタブ及びメニューをナビゲートする。図８３を参照。
【０４９４】
７．５．Moreメニュー
７．５．１．機能へのアクセス
図８４を参照する。全ての画面はハンドセットの右側のソフトキー上にMoreメニューを含み、現在選択されている項目及び全体の画面の双方に関連する機能へのアクセスを可能にする。現在利用可能でないオプションは、このメニュー上で淡色表示され、選択できない。
Moreメニューは、右側のソフトキーでCancelを選択することにより再度閉じられる。
【０４９５】
７．５．２．状況依存オプション
Moreメニューにおいて利用可能なオプションは、現在強調表示されている項目に対して状況依存する。この表は、共通のMoreメニューオプション及び選択されたMoreメニューオプションが実行する動作の説明を一覧表示する。図８５及び図８６を参照。各MusicStationオプションに対して利用可能なMoreメニューオプションの詳細なリストに関しては、「付録２：状況依存メニュー」を参照。
【０４９６】
７．６．Back（戻る）
図８７を参照する。画面ナビゲーションの履歴が維持される。ユーザは、任意の所定のタブにおいて、随時、前の画面に戻るために左側のソフトキーを押下してもよい。Sony Ericssonのハンドセット等のハンドセットにおいて、ハンドセットがハードキーのBackを有する場合、それを使用して画面履歴を戻ることも可能である。
【０４９７】
７．７．音楽の再生
図８８を参照する。ユーザがPlayingタブに戻る必要なくアプリケーションの任意の画面から再生を制御できるように、種々のキーが事前定義され且つ音楽再生機能と関連付けられる。例えば、［５］キーは、ユーザがユーザインタフェース内にいる場合に音楽再生の一時停止及び再開を行なう。図８９を参照。
【０４９８】
７．８．ヘルプ
図９０及び図９１を参照する。ユーザは、［１］キーを押下することによりキーパッドのヘルプを閲覧してもよい。この画面は、MusicStationにおけるユーザの場所に関係なくハンドセット上の任意の数字キーを押下することにより実行される動作を表示する。
【０４９９】
７．９．キーパッドのロック
図９２及び図９３を参照する。キーパッドは、ユーザが［＊］キーを押下し続けることによりロックされる。キーパッドをアンロックするために、ユーザは［＊］を再び押下し続ける。音楽は、ジョイスティックがロックされている間再生し続けるが、偶発的な使用を防止するために、メニューオプション又は他の音楽再生制御キーは利用不可能となる。
【０５００】
７．１０．最小化
図９４及び図９５を参照する。アプリケーションは、［＃］キーを押下し続けることにより最小化されてもよい。音楽を停止するために、ユーザはMusicStationを再度開く必要がある。
【０５０１】
７．１１．終了
図９６を参照する。ユーザがMoreメニューからCloseを選択した時、音楽が再生中である場合、音楽を再生し続けたいかが問われる。
・Exit and keep music playing（終了し、音楽を再生し続ける）−MusicStationは最小化され、ハンドセットのバックグラウンドに移動する。ユーザは、音楽を聴きながらハンドセットの機能を使用し続けることができる。ユーザは、随時MusicStationに戻ることができる。
・Exit and stop music（終了し、音楽を停止する）−この場合、MusicStationは音楽の再生を停止し、完全に終了する。ユーザは、その後MusicStationを使用するためにはMusicStationを再開する必要がある。
【０５０２】
８．基本的な概念
８．１．Lineup
第３のタブ又はLineupは、ユーザがMusicStationを理解するのに重要な概念である。これは、ユーザが現在選択している音楽の永続的なビューを提供する。ユーザが再生する（及びデフォルトではハンドセット上に存在しない場合はダウンロードする）ために選択した任意の音楽は、Lineupに追加される。ユーザは任意のアルバム、プレイリスト、個々のトラックを選択し、それをLinupに追加できる。ダウンロードが完了していない任意のトラックは淡色表示され、ダウンロードされた割合が横に表示される。更なる情報に関しては第１２節を参照。図９７を参照。
【０５０３】
８．２．Playlists（プレイリスト）
MusicStationユーザインタフェース内にはいくつかの種類のプレイリストが存在する。
【０５０４】
【表１】
2014195274.tif 000005
【０５０５】
８．３．評価
図９８を参照する。MusicStationは、ユーザに推薦を提供することを含むコミュニティ機能を提供する。ユーザがこの処理に関わることを可能にするために、MusicStationインタフェース内の多くの種々の項目が評価される。以下の項目が評価可能である：
・トラック
・アルバム
・アーティスト
・プレイリスト
・他のメンバ
ユーザは、インタフェースにおいて項目を選択し且つMoreメニューからRateオプションを選択することにより項目を評価する。ユーザは、項目毎に選択する評価を３段階有する。
・I love it
・Neutral
・I hate it
これらの評価は、全てのユーザから収集され、それら項目に対して星評価を生成するためにMusicStationにより使用される。それら星は、インタフェースにわたり種々の場所で見られ、各項目の相対的な人気に関するビューをユーザ基盤に与える。ユーザの評価は、Top Playlistsリスト（Get New Playlists画面）等の推薦及びチャートを生成するために更に使用される。
【０５０６】
８．４．画面の更新
MusicStationは、高度なバックグラウンドダウンローダと呼ばれる構成要素を含む。この構成要素は、全ての音楽及びデータをハンドセットにダウンロードする役割を有する。これは、バックグラウンドで実行し、再生する音楽及び全ての動的メニューに対するコンテンツを配布する。これは、バックグラウンドで実行するため、ユーザがMusicStationを楽しむことを邪魔せずに、更新されたコンテンツを任意の画面に配布できる。
【０５０７】
例えば、Inboxタブ上に一覧表示されるニュースの記事は、ユーザが次にBuzzタブに切り替えた時に最新の記事がそこに用意されてユーザを待ち受けているように、ユーザが音楽を聴いている間に更新されてもよい。
【０５０８】
９．上位レベルのメニュー
ユーザインタフェースは、４つのタブに分けられる。各タブは、MusicStationの特定の基本的な機能を対象としている。
・Home−MusicStationにおいて利用可能な全てのコンテンツ及びCharts、Search等の全ての基本的な機能へのユーザアクセスを提供する。
・Buzz−コミュニティ機能及び音楽ニュースにアクセスできる。
・Lineup−聴くためのトラックキューの現在のキューを表示する。
・Playing−現在再生中のトラックの詳細を表示する。
【０５０９】
Homeタブ及びBuzzタブは、階層メニュー構造で構成される複数の画面から成る。以下の表は、Homeタブ及びBuzzタブの上位レベルのメニューのオプションのリスト及びそれらが詳細に説明される本明細書の節への相互参照を提供する。図９９及び図１００を参照。
【０５１０】
Lineupタブ及びPlayingタブはメニューを有さない。それらのタブは、現在の音楽に関連する単一の固定されたビューである。Lineupは、ユーザがダウンロード及び再生の対象として現在選択している音楽の永続的なビューを表示する。Playingタブは、現在のトラックのみを表示する。
【０５１１】
１０．Home
１０．１．Playlists
図１０１を参照する。Playlists画面は、プレイリストへのユーザアクセスを与える。ユーザは、自身の専用プレイリスト及び共有プレイリストを閲覧及び管理できる。更にユーザは、Get New Playlistsオプションを使用して、編集／コンテンツチーム又は他のユーザにより提供されたプレイリストを閲覧及びダウンロードできる。
【０５１２】
１０．１．１．My Private Playlists
専用プレイリストは、ユーザが作成し且つMusicStationコミュニティと共有されないプレイリストである。専用プレイリストは、見出しMy Private Playlistsの下に一覧表示される。ユーザは、専用プレイリストを選択し且つMoreメニューからShareオプションを選択することによりそれらのプレイリストを公開することを決定できる。
【０５１３】
１０．１．２．My Shared Playlists
図１０２を参照する。共有プレイリストは、ユーザがMusicStationコミュニティと共有しているプレイリストである。共有プレイリストは、見出しMy Shared Playlistsの下に一覧表示される。ユーザは、共有プレイリストを選択し且つMoreメニューからMake Privateオプションを選択することによりそれらプレイリストを再び個人専用にすることを決定できる。
【０５１４】
１０．１．３．Get New Playlists
図１０３を参照する。Get new playlistsオプションにより、他のユーザの編集者プレイリスト、自動生成プレイリスト及び共有プレイリストにアクセスできる。ユーザは、それらプレイリストの閲覧、再生及び評価を行なえる。図１０４を参照。
【０５１５】
それら画面上のリストは、MusicStationにより毎晩又は毎週更新される。
【０５１６】
【表２】
2014195274.tif 000006
【０５１７】
１０．１．４．Create playlist（プレイリストの作成）
図１０５を参照する。ユーザは、Create playlistオプションを使用して、専用プレイリスト又は共有プレイリストを作成できる。ユーザは、プレイリスト名を提供し、画像ライブラリからプレイリストに対する画像を選択する。作成されると、ユーザは、インタフェースを通して見つけられるAdd to Playlistオプションを使用してトラックをプレイリストに追加できる。更にユーザは、Add to Playlistを選択後に新しいプレイリストを作成できる。
【０５１８】
１０．２．プレイリストの削除
ユーザは、プレイリストを強調表示し且つMoreメニューからDeleteを選択することにより専用プレイリスト又は共有プレイリストを削除してもよい。
【０５１９】
１０．２．１．プレイリストの閲覧
図１０６を参照する。ユーザは、プレイリスト内のトラックを閲覧できる。更にユーザは、プレイリストに関連付けられた画像、プレイリストの合計再生時間及びプレイリストのトラック数を見れる。プレイリストが共有プレイリストである場合、その星評価が更に示される。各プレイリストの底部には、ユーザがプレイリストの全てのトラックをLineupに追加することを選択できるALL TRACKSオプションがある。
【０５２０】
１０．２．２．プレイリストの評価
ユーザは、共有プレイリストを評価できる。全てのユーザにより提供される評価は、Top Playlists及びYou might like...リストを生成するために総合的に使用され、それらはGet New Playlists画面においてユーザにフィードバックされる。第８．３節を参照。
【０５２１】
１０．３．Artists（アーティスト）
図１０７を参照する。Albums画面により、ユーザはMusicStationカタログにおいて入手可能な全てのアルバムにアクセスできる。ユーザは、過去にトラックをダウンロードしたアーティストを閲覧できる。ユーザは、Get new artistsオプションを使用して、このユーザにとって一般的に関心のあるアーティスト又は個人的に関心のあるアーティストを閲覧し且つ聴くことができる。
【０５２２】
１０．３．１．My Top Artists
Arthists画面のMy Top Artistsセクションにおいて、ユーザは、トラックをダウンロードしたことのあるアーティストの選択リストを閲覧できる。リストは、ユーザがトラックをダウンロードしたことのあるアーティストで構成される。これにより、ユーザはお気に入りのアーティストに容易にアクセスできる。一般にリストは、トラックをダウンロードしたことのある全てのアーティストであるが、過度に長くならないことを保証するために制限される（電話機に依存する）。
【０５２３】
１０．３．２．Get new artists
図１０８を参照する。Get new artistsオプションにより、ユーザの音楽の聴き方及びフィードバックを使用して自動的に又は編集者によって、MusicStationにより生成されたアーティストのリストにアクセスできる。これらは、２つの主なカテゴリ：Top Artists、Top Pop、Top Rock等の人気のあるアーティスト及びYou might like等の推薦アーティストに基づく。
これら画面上のリストは、MusicStationにより毎晩又は毎週更新される。
【０５２４】
【表３】
2014195274.tif 000007
【０５２５】
図１０９を参照。
【０５２６】
１０．３．３．Artist Profile−View Artist
図１１０を参照する。ユーザは、画像、アーティストのMusicStationの星評価、ダウンロードしたトラック数、ダウンロードしたトラックのリスト及びそれらのダウンロードしたトラックの合計再生時間を含むアーティストプロファイルを閲覧できる。ユーザは、このアーティストの入手可能な全てのトラック又はアルバムをこの画面から閲覧及び再生できる。
【０５２７】
１０．３．４．Artist Profile−Get new tracks
図１１１を参照する。ユーザは、選択したアーティストの全ての入手可能なトラックのリストを閲覧できる。ユーザは、この画面からトラックの再生及び評価を行なえる。
【０５２８】
１０．３．５．Artist Profile−Get new albums
図１１２を参照する。ユーザは、選択したアーティストの全ての入手可能なアルバムのリストを閲覧できる。ユーザは、この画面からアルバムのトラックを閲覧、再生及び評価できる。
【０５２９】
１０．３．６．アーティストの評価
ユーザは、MoreメニューからRateオプションを使用して任意のアーティストを評価してもよい。第８．３節を参照。
【０５３０】
１０．４．Albums
図１１３を参照する。Albums画面により、ユーザはMusicStationカタログにおいて入手可能な全てのアルバムにアクセスできる。ユーザは、過去にトラックをダウンロードしたことのあるアルバムを閲覧できる。ユーザは、Get new albumsオプションを使用して、このユーザにとって一般的に関心のあるアルバム又は個人的に関心のあるアルバムを閲覧し且つ聴くことができる。
【０５３１】
１０．４．１．My Top Albums
Albums画面のMy Top Albumsセクションにおいて、ユーザは、トラックをダウンロードしたことのあるアルバムの選択リストを閲覧できる。リストは、ユーザがダウンロードし且つ頻繁に聴いているアルバムから構成される。これにより、ユーザはダウンロードしたトラックに容易にアクセスできる。
【０５３２】
１０．４．２．Get New Albums
図１１４を参照する。Get new albumsオプションにより、ユーザの音楽の聴き方及びフィードバックを使用して自動的に又は編集者によって、MusicStationにより生成されたアルバムのリストにアクセスできる。これらは、２つの主なカテゴリ：Top Artists、Top Pop、Top Rock等の人気のあるアルバム及びYou might like等の推薦アルバムに基づく。ユーザは、任意のアルバムを容易に再生又は閲覧できる。
【０５３３】
これら画面上のリストは、MusicStationにより毎晩又は毎週更新される。
【０５３４】
【表４】
2014195274.tif 000008
【０５３５】
図１１５を参照。
【０５３６】
１０．４．３．アルバムホームページ
図１１６を参照する。ユーザは、アルバムのトラック数、アルバムの星評価及びトラックのリストを含むアルバムの詳細を閲覧できる。ユーザは、アルバムから個々のトラック又は全てのトラックを再生できる。ユーザは、アルバムホームページの底部にあるALL TRACKSオプションを使用してアルバムの全てのトラックを再生することを選択できる。
【０５３７】
１０．４．４．アルバムの評価
ユーザは、ユーザインタフェース内で任意のアルバムを評価できる。第８．３節を参照。
【０５３８】
１０．５．Tracks
図１１７を参照する。Tracks画面により、ユーザはMusicStationカタログにおいて入手可能な全てのトラックにアクセスできる。ユーザは、過去にダウンロードしたトラックの選択リストを見れる。更にユーザは、Get new tracksオプションを使用して、このユーザにとって一般的に関心のあるトラック又は個人的に関心のあるトラックを閲覧し且つ聴くことができる。
【０５３９】
１０．５．１．My Top Tracks
Albums画面のMy Top Albumsセクションにおいて、ユーザは、ダウンロードしたトラックの選択リストを閲覧できる。リストは、ユーザが頻繁に聴くトラックから構成される。このリスト中の全てのトラックは、迅速に聴くことができる。ユーザは、これらトラックのうち任意のトラックを聴くためにネットワーク受信可能範囲であることを必要としない。
【０５４０】
１０．５．２．Get New Tracks
図１１８を参照する。Get new tracksオプションにより、ユーザの音楽の聴き方及びフィードバックを使用して自動的に又は編集者によって、MusicStationにより生成されたトラックのリストにアクセスできる。これらは、２つの主なカテゴリ：Top Tracks等の人気のあるトラック及びYou might like、Just released等の推薦トラックに基づく。
【０５４１】
これら画面上のリストは、MusicStationにより毎晩又は毎週更新される。
【０５４２】
【表５】
2014195274.tif 000009
【０５４３】
１０．５．３．トラックの評価
ユーザは、任意のトラックを評価してもよい。第８．３節を参照。
【０５４４】
１０．５．４．プレイリストへのトラックの追加
ユーザは、任意のトラックをプレイリストに追加してもよい。この処理中、ユーザは、既存のプレイリストを選択してもよく又は新しいプレイリストを作成してもよい。第１０．１．４．節のCreate playlist（プレイリストの作成）を参照。
【０５４５】
１０．６．Charts
１０．６．１．チャートリスト
図１１９を参照する。Charts画面は、このサービスのユーザの音楽の聴き方及び評価の仕方から生成されるチャートのリストを提供する。チャートの選択は、毎日、毎週及び毎月を含み利用可能である。
【０５４６】
１０．６．２．チャートの詳細
図１２０を参照する。ユーザは、特定のチャートの名前、チャートの合計再生時間、チャートの全ての一連のトラック｜｜アーティストリストを含むチャートの詳細を閲覧し、そのチャートの任意のトラックを再生できる。
【０５４７】
１０．７．Search
図１２１を参照。
【０５４８】
１０．７．１．アーティスト探索
図１２２を参照する。ユーザは、Searchテキストボックスに探索用語を入力し且つSearch forメニュー上のArtistsラジオボタンを選択することによりMusicStationカタログ内の任意のアーティストを探索してもよい。その後ユーザは、探索により返された任意のアーティストプロファイルを閲覧してもよい。
【０５４９】
１０．７．２．トラック探索
図１２３を参照する。ユーザは、Searchテキストボックスに探索用語を入力し且つSearch forメニュー上のTracksラジオボタンを選択することによりMusicStationカタログ内の任意のトラックを探索してもよい。その後ユーザは、探索により返された任意のトラックを再生してもよい。
【０５５０】
１０．７．３．アルバム探索
図１２４を参照する。ユーザは、Searchテキストボックスに探索用語を入力し且つSearch forメニュー上のAlbumsラジオボタンを選択することによりMusicStationカタログ内の任意のアルバムを探索してもよい。その後ユーザは、探索により返された任意のアルバムプロファイルを閲覧又は再生してもよい。
【０５５１】
１０．８．Play Top Track
図１２５を参照する。ホームメニュー上のPlay Top Trackオプションは、ハンドセット上に既にあるトラックのリストから無作為のトラックをLineupの末尾に追加する。Lineupが空である場合、このトラックは迅速に再生を開始する。トラックは既にダウンロードされているため、このオプションはネットワーク受信可能範囲であることを必要としない。
【０５５２】
１０．９．Options
図１２６を参照する。Options画面により、ユーザはMusicStationアプリケーションを制御するために一般的な情報及びオプションにアクセスできる。
【０５５３】
１０．９．１．Membership Status
図１２７を参照する。このオプションは、ユーザの資格の状態を表示する。これは、次の更新の日付／時間、更新料及び更新頻度等の更新の詳細を示す。ユーザは、Cancel Membershipオプションを使用して資格を取り消せる。
【０５５４】
以下の表において、資格処理の種々の段階を説明する。
【０５５５】
【表６】
2014195274.tif 000010
【０５５６】
１０．９．２．About
図１２８を参照する。この画面は、MusicStationのバージョンに関する情報を表示する。これは、ユーザが現時点でハンドセットにダウンロードしてあるトラックの合計数を更に表示する。
【０５５７】
１０．９．３．Roaming Options
図１２９を参照する。ユーザは、MusicStationに対するローミング挙動を設定できる。電話機がローミング中、ユーザは、トラックをダウンロードする時又はMusicStationがメニュー項目及び画像を更新する時に追加の課金を受ける。
【０５５８】
【表７】
2014195274.tif 000011
【０５５９】
Menu & picture updatesに対するローミング挙動がAskに設定される場合、ユーザは、所定のセッションの間に、ローミング中のダウンロード、更新及び追加の課金を許可／拒否するように要求する警告メッセージを示される。図１３０を参照。
【０５６０】
ユーザがローミング中にトラックをダウンロードしようとし、トラックに対するローミング挙動がAskに設定される場合、ユーザは、ローミング中のダウンロード、更新及び追加の課金を許可／拒否するように要求する警告メッセージを示される。この許可／拒否の動作は、現在のセッションの設定を行なう。図１３１を参照。
【０５６１】
１０．９．４．言語の選択
複数の言語を規定するサービスにおいて、ユーザはMusicStationの言語を変更できる。言語を変更すると、ユーザはMusicStationを再起動するように指示される。動作を確定すると、MusicStationは終了する。図１３２を参照。
【０５６２】
１０．９．５．Terms & Conditions
この画面は、このMusicStationサービスに対する一般的なサービス別条件へのＷＡＰリンクを表示する。図１３３を参照。
【０５６３】
１０．９．６．メモリカードの最大限の使用
ユーザは、MusicStationが音楽及びデータを格納するのに使用するメモリカードの最大の割合を選択できる。ユーザは、電話機の別の使用（例えば、写真）のためにより多くの空間を残すために小さい値を設定できる。
【０５６４】
１１．Buzz
図１３４を参照する。ユーザは、Buzzプロファイルを作成することを選択してもよい。これにより、ユーザはMusicStationコミュニティ機能の全集合に参加できる。ユーザがBuzzプロファイルを有さない場合、ユーザは他のメンバと通信できない。
【０５６５】
ユーザは、Buzz画面からプロファイルを閲覧し、ニュースの記事を読み且つInboxのメッセージにアクセスできる。
【０５６６】
１１．１．Join the Buzz
図１３５を参照する。ユーザがBuzzプロファイルを必要とするコミュニティ機能を使用しようとする場合、ユーザは、Join the Buzz画面にリダイレクトされ、登録したい先のメンバ名の入力を指示される。ユーザは名前を入力し且つ画像を選択してもよく、それによりプロファイルを形成する。入力された名前は一意である必要がある。
【０５６７】
メンバ名が利用可能でない場合、別の名前が提案され、ユーザはそれを受け入れるか又は変更してもよい。ユーザは、My Profile画面からプロファイルを随時編集してもよい。オプションとして、ユーザは画像を選択し、短いキャッチフレーズを提供してもよい。それら項目は、他のユーザがそのメンバのプロファイルを閲覧する場合には必ず表示される。
【０５６８】
１１．２．Buzzメンバ
１１．２．１．My Profile
図１３６を参照する。My Profile画面により、ユーザは、自身の個人専用にされたコンテンツと共にMusicStationコミュニティの全ての面にアクセスできる。ユーザは、プロファイルを作成する前、BuzzタブのNews項目にアクセスでき且つCool Members及びBuzz playlistsを閲覧できるが、友人の追加又は推薦の送出はできない。
ユーザが登録すると、この画面は以下を示す：
・メンバ名
・画像
・星評価−他のユーザがどのように評価したかを示す
・Listens−他のユーザがこのメンバーの共有プレイリストの１つを聴いた回数
・友人の数
・キャッチフレーズ
ユーザは、My Profile画面からCool Members、Buzz Playlists及びBuzz Friendsのリストを閲覧できる。
【０５６９】
【表８】
2014195274.tif 000012
【０５７０】
１１．２．２．Edit my profile
メンバとして登録後、ユーザはMoreメニューからEdit My Profileオプションを使用してメンバプロファイルの詳細を随時変更してもよい。図１３７を参照。これにより、ユーザは、キャッチフレーズを変更でき且つ画像を変更できる。更にユーザは、プロファイルを他のユーザに対して可視にしたいか及びTop Tracksをプロファイル画面上で聴かれるようにしたいかを指定できる。
【０５７１】
１１．２．３．Cool Members
図１３８を参照する。My Profile画面上のCool Membersオプションにより、ユーザはメンバの種々のリストにアクセスできる。
【０５７２】
【表９】
2014195274.tif 000013
【０５７３】
ユーザは、これらのリストの任意のメンバをクリックし、そのメンバのプロファイルを閲覧してもよい（第１１．２．４節）。
【０５７４】
１１．２．４．Buzz Playlists
図１３９を参照する。My Profile画面上のBuzz Playlistsオプションにより、ユーザは、他のユーザの編集者プレイリスト、自動生成プレイリスト及び共有プレイリストを含む種々のプレイリストにアクセスできる。ユーザは、それらプレイリストのうち任意のプレイリストを閲覧、再生及び評価できる。図１４０を参照する。それら画面上のリストは、MusicStationにより毎晩又は毎週更新される。
【０５７５】
【表１０】
2014195274.tif 000014
【０５７６】
１１．２．５．My Friends
図１４１を参照する。My Profile画面上のMy Friendsオプションにより、ユーザは、友人として追加したユーザのリスト及び任意の保留中の友人要求にアクセスできる。Friendsに関する更なる情報は、第１１．３節を参照。
【０５７７】
１１．２．６．View another member profile（別のメンバのプロファイルの閲覧）
図１４２を参照する。この画面は、別のメンバの詳細を表示する。メンバがEdit My Profile画面上でプロファイルを可視にするオプションを有効にした場合のみ、そのメンバのプロファイルは別のユーザにより閲覧される。
Member Profile画面は、メンバの以下の情報を表示する：
・メンバ名
・画像
・星評価
・Listens（他のユーザがこのメンバの共有プレイリストの１つを聴いた回数）
・友人の数
・キャッチフレーズ
・共有プレイリストのリスト
・My Top Tracks（これはユーザの上位５つのトラック）
ユーザはこの画面から以下のことを行なってもよい：
・このメンバの共有プレイリストを閲覧する。
・このメンバの上位５つのトラックを閲覧及び再生する。（このオプションは、他のメンバがEdit my profileオプションを使用してメンバプロファイルを構成する時にオプションをShow my top tracksにした場合にのみ示される。第１１．２．２節を参照。）
・このユーザを友人として追加するように要求する。
・このメンバを評価する。
【０５７８】
１１．３．Friends
Buzzメンバは、メッセージを添付してもよい他のメンバに項目を推薦できる。しかし、友人のリストに追加したメンバに対してのみこれを行なえる。ユーザは、他のBuzzメンバに友人要求を送出することにより又は他のメンバからの要求を確認することにより友人を追加できる。友人のリストは、My Profile画面から閲覧されてもよい（第１１．３．２節を参照）。全ての推薦は、BuzzタブのInboxにおいて閲覧可能である（第１１．４節を参照）。
【０５７９】
１１．３．１．メンバを友人として追加するための要求
図１４３を参照する。メンバがユーザインタフェースにおいて一覧表示されるいずれの場所においても、ユーザはそのメンバに友人になるように要求を送出するためにMoreメニューからAdd as Friendオプションを選択してもよい。ユーザはメッセージを入力してもよく、そのメッセージは友人要求と共に送出される。メッセージを送出するために、ユーザはMoreメニューからSendオプションを選択する。友人要求は他のメンバに送出され、そのメンバは要求を受け入れるか又は拒否するオプションを有する。
【０５８０】
１１．３．２．友人のリストの閲覧
図１４４を参照する。ユーザは、My Profile画面を表示し且つMy friendsオプションを選択することにより友人のリストを随時閲覧してもよい。
【０５８１】
１１．３．３．保留中の友人要求の閲覧
図１４５を参照する。ユーザは、My Profile画面から利用可能なMy Friends画面の見出しPending friend requestsの下、送出したがまだ応答されていない友人要求のリストを閲覧してもよい（第１１．３．２節を参照）。
【０５８２】
１１．３．４．名前で友人を追加するための要求
図１４６を参照する。ユーザは、友人として追加したいメンバの名前を知っている場合、My Profile画面のMy FriendsメニューオプションからアクセスされるAdd friend by nameオプションを使用して名前を入力することにより、そのメンバに友人要求を送出してもよい（第１１．３．２節を参照）。
【０５８３】
１１．３．５．電話番号で友人を追加するための要求
図１４７を参照する。ユーザは、友人として追加したいメンバの移動電話番号を知っている場合、My Profile画面のMy FriendsメニューオプションからアクセスされるAdd friend by phone noオプションを使用して名前を入力することにより、そのメンバに友人要求を送出してもよい（第１１．３．２節を参照）。
【０５８４】
１１．３．６．友人に対するプレイリストの推薦の送出
MusicStationにおいてプレイリストが聴かれるいずれの場所においても、ユーザはMoreメニューからSend to Friendオプションを使用して１人以上の友人にメッセージを送出し、そのプレイリストを推薦してもよい。推薦メッセージは、その友人のInboxに到着する（第１１．４．３節）。
【０５８５】
１１．３．７．友人に対するアーティストの推薦の送出
アーティストがMusicStationにおいて一覧表示されるいずれの場所においても、ユーザは、MoreメニューからSend to Friendオプションを使用して１人以上の友人にメッセージを送出し、そのアーティストを推薦してもよい。推薦メッセージは、その友人のInboxに到着する（第１１．４．４節）。
【０５８６】
１１．３．８．友人に対するアルバムの推薦の送出
アルバムがMusicStationにおいて一覧表示されるいずれの場所においても、ユーザは、MoreメニューからSend to Friendオプションを使用して１人以上の友人にメッセージを送出し、そのアルバムを推薦してもよい。推薦メッセージは、その友人のInboxに到着する（第１１．４．５節）。
【０５８７】
１１．３．９．友人に対するトラックの推薦の送出
トラックがMusicStationにおいて一覧表示されるいずれの場所においても、ユーザは、MoreメニューからSend to Friendオプションを使用して１人以上の友人にメッセージを送出し、そのトラックを推薦してもよい。推薦メッセージは、その友人のInboxに到着する（第１１．４．６節）。図１４８を参照。
【０５８８】
１１．４．Inbox
Inboxは、このMusicStationサービスのユーザでもあるユーザの友人から到着したメッセージ及び推薦を表示する。MusicStationのFriends機能性に対する概要に関しては、第１１．３節を参照。メッセージは、高度なバックグラウンドダウンローダによりバックグラウンドでダウンロードされ、ユーザからの特定の対話なしでInboxに現れる。
【０５８９】
１１．４．１．友人要求メッセージの受信
図１４９を参照する。別のメンバがこのユーザを友人として追加するように要求する場合、友人要求はこのユーザのInboxに到着する。このユーザは、４つの方法のうち１つ方法でこの要求に応答できる。
【０５９０】
【表１１】
2014195274.tif 000015
【０５９１】
このユーザが応答すると、その応答は他のメンバのInboxに配布される。この応答については、第１１．４．２節において説明する。
【０５９２】
１１．４．２．友人要求からの応答
図１５０を参照する。このユーザが友人要求を別のメンバに送出した場合、そのメンバは要求を受け入れるか又は拒否するオプションを有する。応答はこのユーザに返され、Inboxに表示される。友人要求に対する３つの可能な応答を以下に一覧表示する。
【０５９３】
【表１２】
2014195274.tif 000016
【０５９４】
１１．４．３．友人からのプレイリストの推薦の受信
図１５１を参照する。友人がこのユーザにプレイリストの推薦を送出する場合（第１１．３．６節）、推薦メッセージがこのユーザのInboxに現れる。ユーザはメッセージを開き、プレイリストを閲覧するためにメッセージ中のハイパーリンクをクリックできる。
【０５９５】
１１．４．４．友人からのアーティストの推薦の受信
図１５２を参照する。友人がこのユーザにアーティストの推薦を送出する場合（第１１．３．７節）、メッセージがこのユーザのInboxに現れる。ユーザはメッセージを開き、アーティストプロファイル画面に直接移動するためにメッセージ中のハイパーリンクをクリックできる。
【０５９６】
１１．４．５．友人からのアルバムの推薦の受信
図１５３を参照する。友人がこのユーザにアルバムの推薦を送出する場合（第１１．３．８節）、メッセージがこのユーザのInboxに現れる。ユーザはメッセージを開き、アルバム画面に直接移動するためにメッセージ中のハイパーリンクをクリックできる。また、ユーザは、アーティストプロファイル画面に直接移動するためにアーティスト名をクリックしてもよい。
【０５９７】
１１．４．６．友人からのトラックの推薦の受信
図１５４を参照する。友人がこのユーザにトラックの推薦を送出する場合（第１１．３．９節）、推薦メッセージがこのユーザのInboxに現れる。ユーザはメッセージを開き、Lineupにトラックを追加するためにメッセージ中のハイパーリンクをクリックできる。
【０５９８】
１１．５．News
１１．５．１．編集者の記事のリスト
Newsセクションは、常に更新されるニュースの記事のリストを表示する。通常、国際的に広く関心のある２つの記事、現地で一般的に関心のある２つの記事、並びにこのユーザの音楽の聴き方及び評価挙動に基づく２つの記事に分類される６つの記事が表示される。この分類は、特定のサービスの要望のために構成される。
記事のリストは、MusicStationの正常な使用状態中に高度なバックグラウンドダウンローダにより更新される。記事は、バックグラウンドでこのリストに追加され、ユーザが次にBuzzタブにナビゲートした時に迅速に閲覧可能である。
【０５９９】
１１．５．２．記事の閲覧
図１５５を参照する。記事を閲覧するために、ユーザは、リストから記事を選択し且つジョイスティックボタンをクリックするか又はMoreメニューからOpenオプションを選択する。記事の本文は、見出し及び関連する画像の下に表示される。
【０６００】
１１．５．３．記事におけるハイパーリンク
図１５６を参照する。記事は、MusicStation内の他の画面へのハイパーリンクを含んでもよい。例えば、新しいアルバムの発売の発表は、関連するアーティスト及びアルバムの画面へのリンクを含むことができる。ハイパーリンクは、記事の画面において青色で表示される。ユーザは、ハイパーリンクを選択し且つジョイスティックボタンをクリックすることにより、アルバム又はアーティストに直接ナビゲートしてもよい。ユーザがジョイスティックの上／下を使用して記事を上下にスクロールすると、有効なハイパーリンクは連続するハイパーリンク間で移動する。
【０６０１】
１２．Lineup
図１５７を参照する。Lineupは、MusicStationのクライアントの中心的な概念である。これは、ユーザが聴くためにキュー登録したトラックの現在のプレイリストである。プレイリスト上の曲は順に再生される。Lineupのコンテンツは、Lineup画面で随時閲覧可能である。
現在のトラックは、現在再生中のLineup中のトラックである。現在のトラックは、左側の小さな青色のポインタで強調表示される。
図１５８を参照する。Lineupに追加されたトラックがない場合、オプションPlay top trackが表示される。このオプションは、Top trackをLineupにランダムに追加し且つ再生する。Top tracksは既にダウンロードされており、迅速に再生する。
【０６０２】
１２．１．トラックダウンロードの状態
図１５９を参照する。まだダウンロードされていないトラックは、バックグラウンドでダウンロードされる。現在ダウンロードしているか又はダウンロードされるのを待っているトラックは、単色のフォントで示される。トラックのダウンロードの進捗が、０〜１００％の割合で表示される。
【０６０３】
トラックは、Lineupから順に再生される。ダウンロードがまだ終了していないトラックに到達した場合、再生はそのトラックをスキップし、ダウンロードされている次のトラックを再生する。トラックは、ダウンロードされると再生可能になる。MusicStationは、バックグラウンドでのトラックのダウンロードを高度に管理して、ユーザ体験を最適化し、音楽再生が連続的であり且つユーザが音楽の連続した流れを聞けることを保証する。
【０６０４】
トラックがLineupに追加された方法に依存してトラックは１回に１つダウンロードされるが、ユーザがアプリケーションを終了することによりダウンロードを中断したかには関係なく、複数のトラックが部分的にダウンロードされた状態で示される。トラックがダウンロードされている間、ユーザは、既にダウンロードされた音楽を聴くことができ、MusicStationユーザインタフェースの残りの部分を自由にナビゲートできる。MusicStationが終了し、終了した場所からダウンロードを後で継続する場合、部分的にダウンロードされたトラックは保管される。
【０６０５】
１２．２．Save as playlist
図１６０を参照する。ユーザは、現在のLineupをプレイリストに対して保管できる。現在のLineupをプレイリストとして保管するために、ユーザはMoreメニューからSave as playlistを選択する。ユーザは、新しいプレイリストとして現在のLineupを保管すること又は既存のプレイリストにトラックを追加することを選択できる。この保管されたプレイリストは、ハンドセット上に中央に保管される。
【０６０６】
１２．３．Lineupからの除去
図１６１を参照する。ユーザは、Lineupからトラックを除去できる。Lineupからトラックを除去するために、ユーザは、トラックを選択し且つMoreメニューからRemoveを選択する。ユーザがCerrent Track（現在のトラック）を除去すると、現在のプレイリスト中の次に利用可能なトラックが再生される。
【０６０７】
１２．４．Lineupのクリア
図１６２を参照する。ユーザは、現在のLineupをクリアでき、Lineupから全てのトラックを除去する。Lineupをクリアするために、ユーザは、MoreメニューからClearを選択する。音楽再生は停止する。
【０６０８】
１２．５．現在のLineupのトラックへのジャンプ及び再生
ユーザは、現在のLineupから別のトラックを選択して再生できる。これを行なうために、ユーザはジョイスティックを使用してトラックにナビゲートする。ユーザは、ジョイスティックボタンを押下することにより又はMoreメニューからPlayを選択することによりトラックを開始できる。MusicStationは、選択したトラックの再生を開始する。ダウンロードされたトラックのみが再生可能である。
【０６０９】
１２．６．Lineupへの音楽の追加
ユーザは、MusicStationの音楽カタログをナビゲートし、トラック、アルバム、アーティスト又はプレイリストを選択してLineupに追加できる。ジョイスティックでトラックを選択することにより、任意のトラックがLineupに追加される。MoreメニューからAdd to Lineupを選択することにより、任意のプレイリスト、アルバム又はトラックが追加される。
【０６１０】
Lineupが空である場合、その項目の再生が開始する。Lineupが既にトラックを含む場合、追加された項目はLineupの末尾にキュー登録される。ユーザは、Lineupタブにいくことにより追加したトラックを閲覧できる。ダウンロードされていないトラックは、ダウンロードされる前にLineupに追加される。MusicStationは、バックグラウンドでの項目のダウンロードを高度に管理し、ユーザが音楽の連続した流れを楽しむことを可能にする。
【０６１１】
Lineupに項目を追加するための他のオプションがMoreメニュー上に提供される。Play next、Play ASAP又はPlay now等のそれらのオプションを以下に更に詳細に説明する。ユーザがダウンロードされる必要のあるトラックをLineupに追加し、現在Lineup中に他のトラックが存在しない場合、ユーザは迅速に再生するために上位のトラックを追加するオプションにより指示される。図１６３を参照。
【０６１２】
１２．６．１．Add to Lineup
ユーザは、MusicStationカタログを閲覧している時、MoreメニューからAdd to Lineupを選択して、トラック、プレイリスト、選択したアーティストによるトラック又はアルバムをLineupに追加できる。
【０６１３】
【表１３】
2014195274.tif 000017
【０６１４】
１２．６．２．Play Next
ユーザは、MusicStationカタログを閲覧している時、MoreメニューからPlay nextを選択して、トラック、プレイリスト、選択したアーティストによるトラック又はアルバムをLineupの現在再生しているトラックの後に挿入できる。
【０６１５】
【表１４】
2014195274.tif 000018
【０６１６】
１２．６．３．Play Now
ユーザは、MusicStationカタログを閲覧している時、MoreメニューからPlay nowを選択して、ダウンロードされたトラックをLineupに挿入できる。現在再生中のトラックは中断され、選択されたトラックは再生を開始し且つ現在のトラックを置換する。
【０６１７】
【表１５】
2014195274.tif 000019
【０６１８】
１２．６．４．Play ASAP
Play ASAPは、可能な限り迅速に再生することを意味する。ユーザは、MusicStationカタログを閲覧している時、MoreメニューからPlay ASAPを選択して、Lineupにダウンロードされていないトラック、プレイリスト、選択したアーティストによるトラック又はアルバムを選択できる。利用可能になると迅速に、トラック、プレイリスト、選択したアーティストによるトラック又はアルバムは現在再生中のトラックを置換する。
【０６１９】
トラック、プレイリスト、選択したアーティストによるトラック又はアルバムがまだダウンロードされていない場合、ユーザは、MusicStationカタログを閲覧している時、MoreメニューからPlay ASAPオプションを選択できる。
【０６２０】
【表１６】
2014195274.tif 000020
【０６２１】
１３．Playing
図１６４を参照。
【０６２２】
１３．１．１．Playing画面
Playingタブは、現在再生中のトラックの詳細を表示する。
【０６２３】
【表１７】
2014195274.tif 000021
【０６２４】
１３．１．２．Playingの動作
ユーザは、Playingタブにおいて以下の動作を実行できる。
【０６２５】
【表１８】
2014195274.tif 000022
【０６２６】
付録２：状況依存メニュー
以下の付録は、MusicStationにおいてメニュー及びオブジェクトを閲覧している時にMoreメニューにおいて利用可能なオプションを詳細に示す。
【０６２７】
【表１９】
2014195274.tif 000023
【０６２８】
【表２０】
2014195274.tif 000024
【０６２９】
【表２１】
2014195274.tif 000025
【０６３０】
【表２２】
2014195274.tif 000026
【０６３１】
【表２３】
2014195274.tif 000027
【０６３２】
【表２４】
2014195274.tif 000028
【図１】
2014195274.tif 000029
【図２】
2014195274.tif 000030
【図３】
2014195274.tif 000031
【図４】
2014195274.tif 000032
【図５】
2014195274.tif 000033
【図６】
2014195274.tif 000034
【図７】
2014195274.tif 000035
【図８】
2014195274.tif 000036
【図９】
2014195274.tif 000037
【図１０】
2014195274.tif 000038
【図１１】
2014195274.tif 000039
【図１２】
2014195274.tif 000040
【図１３】
2014195274.tif 000041
【図１４】
2014195274.tif 000042
【図１５】
2014195274.tif 000043
【図１６】
2014195274.tif 000044
【図１７】
2014195274.tif 000045
【図１８】
2014195274.tif 000046
【図１９】
2014195274.tif 000047
【図２０】
2014195274.tif 000048
【図２１】
2014195274.tif 000049
【図２２】
2014195274.tif 000050
【図２３】
2014195274.tif 000051
【図２４】
2014195274.tif 000052
【図２５】
2014195274.tif 000053
【図２６】
2014195274.tif 000054
【図２７】
2014195274.tif 000055
【図２８】
2014195274.tif 000056
【図２９】
2014195274.tif 000057
【図３０】
2014195274.tif 000058
【図３１】
2014195274.tif 000059
【図３２】
2014195274.tif 000060
【図３３】
2014195274.tif 000061
【図３４】
2014195274.tif 000062
【図３５】
2014195274.tif 000063
【図３６】
2014195274.tif 000064
【図３７】
2014195274.tif 000065
【図３８】
2014195274.tif 000066
【図３９】
2014195274.tif 000067
【図４０】
2014195274.tif 000068
【図４１】
2014195274.tif 000069
【図４２】
2014195274.tif 000070
【図４３】
2014195274.tif 000071
【図４４】
2014195274.tif 000072
【図４５】
2014195274.tif 000073
【図４６】
2014195274.tif 000074
【図４７】
2014195274.tif 000075
【図４８】
2014195274.tif 000076
【図４９】
2014195274.tif 000077
【図５０】
2014195274.tif 000078
【図５１】
2014195274.tif 000079
【図５２】
2014195274.tif 000080
【図５３】
2014195274.tif 000081
【図５４】
2014195274.tif 000082
【図５５】
2014195274.tif 000083
【図５６】
2014195274.tif 000084
【図５７】
2014195274.tif 000085
【図５８】
2014195274.tif 000086
【図５９】
2014195274.tif 000087
【図６０】
2014195274.tif 000088
【図６１】
2014195274.tif 000089
【図６２】
2014195274.tif 000090
【図６３】
2014195274.tif 000091
【図６４】
2014195274.tif 000092
【図６５】
2014195274.tif 000093
【図６６】
2014195274.tif 000094
【図６７】
2014195274.tif 000095
【図６８】
2014195274.tif 000096
【図６９】
2014195274.tif 000097
【図７０】
2014195274.tif 000098
【図７１】
2014195274.tif 000099
【図７２】
2014195274.tif 000100
【図７３】
2014195274.tif 000101
【図７４】
2014195274.tif 000102
【図７５】
2014195274.tif 000103
【図７６】
2014195274.tif 000104
【図７７】
2014195274.tif 000105
【図７８】
2014195274.tif 000106
【図７９】
2014195274.tif 000107
【図８０】
2014195274.tif 000108
【図８１】
2014195274.tif 000109
【図８２】
2014195274.tif 000110
【図８３】
2014195274.tif 000111
【図８４】
2014195274.tif 000112
【図８５】
2014195274.tif 000113
【図８６】
2014195274.tif 000114
【図８７】
2014195274.tif 000115
【図８８】
2014195274.tif 000116
【図８９】
2014195274.tif 000117
【図９０】
2014195274.tif 000118
【図９１】
2014195274.tif 000119
【図９２】
2014195274.tif 000120
【図９３】
2014195274.tif 000121
【図９４】
2014195274.tif 000122
【図９５】
2014195274.tif 000123
【図９６】
2014195274.tif 000124
【図９７】
2014195274.tif 000125
【図９８】
2014195274.tif 000126
【図９９】
2014195274.tif 000127
【図１００】
2014195274.tif 000128
【図１０１】
2014195274.tif 000129
【図１０２】
2014195274.tif 000130
【図１０３】
2014195274.tif 000131
【図１０４】
2014195274.tif 000132
【図１０５】
2014195274.tif 000133
【図１０６】
2014195274.tif 000134
【図１０７】
2014195274.tif 000135
【図１０８】
2014195274.tif 000136
【図１０９】
2014195274.tif 000137
【図１１０】
2014195274.tif 000138
【図１１１】
2014195274.tif 000139
【図１１２】
2014195274.tif 000140
【図１１３】
2014195274.tif 000141
【図１１４】
2014195274.tif 000142
【図１１５】
2014195274.tif 000143
【図１１６】
2014195274.tif 000144
【図１１７】
2014195274.tif 000145
【図１１８】
2014195274.tif 000146
【図１１９】
2014195274.tif 000147
【図１２０】
2014195274.tif 000148
【図１２１】
2014195274.tif 000149
【図１２２】
2014195274.tif 000150
【図１２３】
2014195274.tif 000151
【図１２４】
2014195274.tif 000152
【図１２５】
2014195274.tif 000153
【図１２６】
2014195274.tif 000154
【図１２７】
2014195274.tif 000155
【図１２８】
2014195274.tif 000156
【図１２９】
2014195274.tif 000157
【図１３０】
2014195274.tif 000158
【図１３１】
2014195274.tif 000159
【図１３２】
2014195274.tif 000160
【図１３３】
2014195274.tif 000161
【図１３４】
2014195274.tif 000162
【図１３５】
2014195274.tif 000163
【図１３６】
2014195274.tif 000164
【図１３７】
2014195274.tif 000165
【図１３８】
2014195274.tif 000166
【図１３９】
2014195274.tif 000167
【図１４０】
2014195274.tif 000168
【図１４１】
2014195274.tif 000169
【図１４２】
2014195274.tif 000170
【図１４３】
2014195274.tif 000171
【図１４４】
2014195274.tif 000172
【図１４５】
2014195274.tif 000173
【図１４６】
2014195274.tif 000174
【図１４７】
2014195274.tif 000175
【図１４８】
2014195274.tif 000176
【図１４９】
2014195274.tif 000177
【図１５０】
2014195274.tif 000178
【図１５１】
2014195274.tif 000179
【図１５２】
2014195274.tif 000180
【図１５３】
2014195274.tif 000181
【図１５４】
2014195274.tif 000182
【図１５５】
2014195274.tif 000183
【図１５６】
2014195274.tif 000184
【図１５７】
2014195274.tif 000185
【図１５８】
2014195274.tif 000186
【図１５９】
2014195274.tif 000187
【図１６０】
2014195274.tif 000188
【図１６１】
2014195274.tif 000189
【図１６２】
2014195274.tif 000190
【図１６３】
2014195274.tif 000191
【図１６４】
2014195274.tif 000192
【図１６５】
2014195274.tif 000193
【手続補正書】
【提出日】平成26年6月4日(2014.6.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
セルラ携帯電話端末であって、
デジタル音楽トラックを、前記セルラ携帯電話端末にダウンロードし、利用することを可能にするソフトウェアアプリケーションがプログラミングされたメモリ
を有し、
（ａ）前記ソフトウェアアプリケーションは、エンドユーザーに、セルラ無線ネットワークを用いて、リモートサーバー上の音楽トラックを直接閲覧および検索することを可能にし、かつ、前記セルラ無線ネットワークを用いて前記リモートサーバーから音楽トラックをダウンロードすることを可能にし、
（ｂ）前記ソフトウェアアプリケーションは、デジタル著作権管理プログラムを含み、もしくは、デジタル著作権管理プログラムと相互に動作し、
前記デジタル著作権管理プログラムの動作は、遠隔的に、
（ｉ）前記セルラ携帯電話端末と前記リモートサーバーとの間の加入サービスが、前記セルラ携帯電話端末、もしくは、該セルラ携帯電話端末に関連付けられたユーザーに対して有効である間、前記セルラ無線ネットワークを用いて、前記セルラ携帯電話端末へ様々な音楽トラックの無制限の合法的なダウンロードを可能にし、
（ｉｉ）前記加入サービスが終了しない間は、前記セルラ携帯電話端末に格納された各トラックを再生可能にし、
（ｃ）前記ソフトウェアアプリケーションは、マルチスレッドアーキテクチャを、ネットワークもしくは／および音楽トラックカタログへのアクセスのコンピュータ処理上の要求と、前記ソフトウェアアプリケーションのユーザインタフェース、デジタル著作権管理プログラム、およびメディア操作のうちの１または複数のコンピュータ処理上の要求とのバランスを取るために使用し、
（ｄ）前記ソフトウェアアプリケーションは、分離したメタデータの階層として形成され、トラックの属性を定義するトラックメタデータを用い、前記メタデータは、音楽トラックの外側にあり、関連する音楽トラックファイルを配信することを必要とすることなく、トラック情報の共有及び閲覧を可能とする
ことを特徴とするセルラ携帯電話端末。
【請求項２】
前記マルチスレッドアーキテクチャは、大規模オブジェクトがバックグラウンド処理として並行して前記セルラ携帯電話端末にダウンロードされることができるように、並行のダウンロードスレッドを用いることを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項３】
前記アプリケーションは、ファイルがダウンロードされた量を知的に認識することによって、携帯ネットワークにおける潜在的な固有の、および、断続的な接続を管理し、
ダウンロードされていなかったファイルの残りの一部のみを問い合わせることを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項４】
前記ソフトウェアアプリケーションは、前記ソフトウェアアプリケーションによって自動的に決定された優先度を有する、異なるオブジェクトとデータを前記リモートサーバーから要求するためのスケジューラを含むことを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項５】
インテリジェントメモリ管理は、新たにダウンロードされるトラックのための空間を設けるために、少なくとも使用したトラックを自動的に削除することを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項６】
前記デジタル著作権管理プログラムは、前記加入サービスが終了した場合でも、明示され、ダウンロードされた音楽トラックがまだ利用できるように、遠隔的に構成されることができることを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項７】
前記加入サービスのための課金インフラストラクチャは、前記セルラ無線ネットワークを制御するネットワークオペレータによって提供される前記課金インフラストラクチャの一部であることを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項８】
周期的に動作する、もしくは、一度限りの加入は、前記デジタル著作権管理プログラムの前記リモート構成を、前記セルラ無線ネットワークを制御するネットワークオペレータによって提供される前記課金インフラストラクチャにリンクすることにより、達成することを特徴する請求項１に記載のセルラ携帯電話端末。
【請求項９】
前記ソフトウェアアプリケーションは、エンドユーザーの入力なく、前記セルラ携帯電話端末に関連付けられたパラメータに自動的に適合され、
前記パラメータは、
（ａ）前記セルラ携帯電話端末の計算能力、
（ｂ）前記セルラ携帯電話端末の、音声、画像、映像、アニメーションを含む、Ｊａｖａを介して示されることができるメディアファイルおよびフォーマットの組、
（ｃ）前記セルラ携帯電話端末のメモリ制限、
（ｄ）前記セルラ携帯電話端末のオペレーティングシステムが管理できるメディアファイルとフォーマットの組、
（ｅ）前記セルラ携帯電話端末が、ネットワーク接続を制御する方法、
（ｆ）ＣＳＤ、ＧＰＲＳ、２Ｇ、２．５Ｇ、３Ｇ、ＷＡＰ、ＳＭＳ、Ｂｌｕｅｔｏｏｔｈ、赤外線、Ｗｉ−Ｆｉ、およびＷｉＭＡＸの１または複数を含む、ネットワーク能力および前記セルラ携帯電話端末の制御
の１または複数を定義することを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項１０】
前記ソフトウェアアプリケーションは、詳細なエンドユーザーのリスニングデータを記録し、リモートサーバーにフィードバックを行うことを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項１１】
前記エンドユーザーのリスニングデータは、どの程度長くトラックが聞かれたかを含むことを特徴とする請求項１０に記載のセルラ携帯電話端末。
【請求項１２】
前記エンドユーザーのリスニングデータは、何のトラックがいつ、スキップされたかを含むことを特徴とする請求項１０に記載のセルラ携帯電話端末。
【請求項１３】
前記ソフトウェアアプリケーションは、前記エンドユーザーのプレイバックの傾向に準じてフィルタされたターゲットニュースを表示することを特徴とする請求項１０に記載のセルラ携帯電話端末。
【請求項１４】
前記エンドユーザーのリスニングデータは、前記セルラ携帯電話端末上に局所的にキャッシュされ、その後、前記リモートサーバーへ、発生した通信を超えてピギーバックとして送信されることを特徴とする請求項１０に記載のセルラ携帯電話端末。
【請求項１５】
前記セルラ携帯電話端末は、ユーザーが一定期間以上接続しなかった場合には、生じると予測される前記通信を待つことなく、先制して、前記エンドユーザーのリスニングデータのトラックを送信できることを特徴とする請求項１４の記載のセルラ携帯電話端末。
【請求項１６】
前記エンドユーザーのリスニングデータは、前記セルラ携帯電話端末上の表示に音楽トラックの推奨を提供する音楽推奨エンジンを補強するために用いられることを特徴とする請求項１０に記載のセルラ携帯電話端末。
【請求項１７】
前記ソフトウェアアプリケーションは、共有プレイリストを、生成し、管理し、表示することを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項１８】
前記ソフトウェアアプリケーションは、再生の行動に基づいてユーザーによって生成されたプレイリストチャートを表示することを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項１９】
前記ソフトウェアアプリケーションは、音楽推奨システムと相互に動作することを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項２０】
複数のデバイスは、ユーザーが操作するセルラ携帯電話端末に関わりなくメタデータの同じ閲覧を提供するために、前記リモートサーバーを介した無線もしくは有線により、全て同期することができることを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項２１】
プレイリストは、前記プレイリストに前記トラックを定義しているメタデータとして前記リモートサーバーに格納され、
前記メタデータは、前記トラック自体から分けられ、前記トラック自体よりも前記セルラ無線ネットワークを超えて効果的に送信されるように構成されることを特徴とする請求項１に記載のセルラ携帯電話端末。
【請求項２２】
不揮発性記録媒体、セルラ携帯電話端末、もしくは他のハードウェアデバイスに統合され、前記セルラ携帯電話端末上でデジタル音楽トラックをダウンロードし、使用を可能とする、セルラ携帯電話端末のためのソフトウェアアプリケーションであって、
（ａ）前記ソフトウェアアプリケーションは、エンドユーザーに、セルラ無線ネットワークを用いてリモートサーバー上の音楽トラックを直接閲覧および検索可能にし、かつ、前記セルラ無線ネットワークを用いて前記リモートサーバーから音楽トラックをダウンロード可能にし、
（ｂ）前記ソフトウェアアプリケーションは、デジタル著作権管理プログラムを含み、もしくは、デジタル著作権管理プログラムと相互に連携し、
前記デジタル著作権管理プログラムの動作は、遠隔的に、
（ｉ）前記セルラ携帯電話端末と前記リモートサーバーとの間の加入サービスが、前記セルラ携帯電話端末、もしくは、該セルラ携帯電話端末に関連付けられたユーザーに対して有効である間、前記セルラ無線ネットワークを用いて、前記セルラ携帯電話端末へ様々な音楽トラックの無制限の合法的なダウンロードを可能にし、
（ｉｉ）前記加入サービスが終了しない間は、前記セルラ携帯電話端末に格納された各トラックを再生可能にし、
（ｃ）前記ソフトウェアアプリケーションは、マルチスレッドアーキテクチャを、ネットワークもしくは／および音楽トラックカタログへのアクセスのコンピュータ処理上の要求と、前記ソフトウェアアプリケーションのユーザインタフェース、デジタル著作権管理プログラム、およびメディア操作のうちの１または複数のコンピュータ処理上の要求とのバランスを取るために使用し、
（ｄ）前記ソフトウェアアプリケーションは、分離したメタデータの階層として形成され、トラックの属性を定義するトラックメタデータを用い、前記メタデータは、音楽トラックの外側にあり、関連する音楽トラックファイルを配信することを必要とすることなく、トラック情報の共有及び閲覧を可能とする
ことを特徴とするソフトウェアアプリケーション。
【請求項２３】
音楽トラック配信システムであって、
（ａ）音楽トラックを格納するためのリモートサーバーと、
（ｂ）複数のセルラ携帯電話端末であってそれぞれが、前記リモートサーバーからセルラ無線ネットワークを介してデジタル音楽トラックをダウンロード可能とし、かつ、各セルラ携帯電話端末上で再生可能とするソフトウェアアプリケーションを含み、
前記ソフトウェアアプリケーションは、自動的に、エンドユーザーの入力無しに、前記セルラ携帯電話デバイスに関連付けられたパラメータに適合され、
前記ソフトウェアアプリケーションは、エンドユーザーに、前記セルラ無線ネットワークを用いて前記リモートサーバー上の音楽トラックを閲覧および検索を可能とし、前記セルラ無線ネットワークを用いて前記リモートサーバーから音楽トラックをダウンロード可能にし、そのダウンロードされた音楽トラックをプレイバックおよび管理を可能とし、
前記ソフトウェアアプリケーションは、デジタル著作権管理システムを含み、前記デジタル著作権管理システムは、前記セルラ無線ネットワークを用いて前記セルラ携帯電話端末に様々な音楽トラックの無制限の合法的なダウンロードを可能にし、更に、加入サービスが終了していない間、前記セルラ携帯電話端末に格納された各トラックを再生可能にし、
（ｃ）前記ソフトウェアアプリケーションは、マルチスレッドアークテクチャを、ネットワークおよび／もしくは音楽トラックカタログへのアクセスのコンピュータ処理上の要求と、前記ソフトウェアアプリケーションのユーザインタフェース、前記デジタル著作権管理プログラム、およびメディア操作のうちの１または複数のコンピュータ処理上の要求とのバランスを取るために使用し、
（ｄ）前記ソフトウェアアプリケーションは、分離したメタデータの階層として形成され、トラックの属性を定義したトラックメタデータを用い、前記メタデータは、音楽トラックの外部にあり、関連する音楽トラックファイルの配信することを必要とすることなく、トラック情報を供給および閲覧を可能とする
ことを特徴とする音楽トラック配信システム。
【外国語明細書】
2014195274000001.pdf