JP2012530461A - モバイル対話システムおよびモバイル・コンテンツ配信ソリューション - Google Patents

Abstract

本発明は、無線および有線デバイス用の、オーディオおよび視覚ファイルの送信、配信、再生およびコンテンツ管理の方法、システムおよび製品、および、携帯電話等の携帯できる電子デバイスへのそのような配信のための、新しい、インターネットを用いないプロトコルに関する。

Description

関連出願
この出願は、２００２年６月６日に出願され、今は米国特許第７、５４８、８７５号であり、２００１年６月２７日に出願された米国仮出願番号６０／３０１、６８１号、２００１年７月３日に出願された米国仮出願番号第６０／３０３、１１５号、２００１年８月１４日に出願された米国仮出願番号第６０／３１２、４５０号および２００１年１０月２６日に出願された米国仮出願番号第６０／３４３、１５９号の優先権を主張する米国特許出願番号第１０／１８３、７５６号の一部継続出願である、２００９年２月４日に出願された米国特許出願番号１２／３２２、５３７号の、一部継続出願であり、これらの全ての出願はここに参照することにより援用される。

技術分野
本発明は、無線および有線デバイス用の音響および映像ファイルの送信、配信、再生およびコンテンツ管理のための方法、システムおよび製品、および、携帯電話等の携帯電子デバイスへのそのような送信のための新しい、インターネットを利用しないプロトコルに関する。

モバイル買い物検索エンジンおよび購入案内 旅行予約シナリオ モバイル株式取引シナリオ マルチモーダル対話システム基本設計概念 サーバー側の基本設計概念 顧客側コンポーネント 情報の流れ 通信の流れ 横並びの、サービス中心のシステム・コンポーネント コンテンツ管理システム コンテンツ・ディスカバリーおよび配信システム モバイル・マルチメディア・アプリケーション用デュアルプロセッサのシステム

ここで考察されているのは、同時係属中の２００９年２月４日出願の米国出願番号１２／３２２、５３７号などに開示され、ここに参照されることにより援用される、電話で起動されるプロトコルの効率を利用するモバイル通信のシステム・デザインのための様々なアプローチ、および、それらの制約に束縛されることなく、タンデムで異なる入力／出力メカニズムを作動させる利点についてである。

大規模なビジネス市場へモバイル・デバイスの利益をもたらすことに欠かせないことは、より自然な通信の方法である。本例、または「Ｍ．８００モバイル対話システム」の適用は、声、キーボードおよび、グラフィックまたはビデオさえをも介した異なる入力をユーザーへ提供する。

例えば、しばしば説明を聞いていると、顧客は上記説明をもう一度聞くことを望むかもしれない。マルチモードのインターレースは、タスクおよび目的に適した、最も便利な相互作用モードを選択できる柔軟性を提供する。

また、Ｍ．８００モバイル対話システムは、優れた末端ユーザー購買経験を提供する、強力なコンテンツ配信ソリューションであるモバイル・ダウンロード管理サーバーも含む。それは、ジャバ(Java)アプリケーション、趾骨瘤(ringbones)、ゲーム、映像およびモバイル・デバイスへのその他を含むダウンロードできるコンテンツの全てのタイプの購入、パッケージングおよび配信を管理する。

加入者は、単一ビューでコンテンツ・カタログ全体へのアクセスを有する。この単一ビューは、コンテンツのプロバイダーが、コンテンツを単一の束へ集約することを可能にする。加入者は、彼らのＷＡＰまたはウェブ・ブラウザーから見られる、直感的に理解でき、使いやすい一つのインターフェースから、いかなるタイプのコンテンツも閲覧、選択、購入およびダウンロードすることができる。

ダウンロード管理は、新たなまたは存在するコンテンツへの直接のアクセス、および、ワン・クリックでの購入および常に最新のコンテンツのサービスをユーザーへ提供する。上記コンテンツのリストは、顧客が彼らのモバイル電話上のコンテンツ・リストを開くと、自動的に送受話器へアップデートされる。

Ｍ．８００モバイル対話システムは、近年重要なものとなってきており、モバイル・ビジネスおよび末端ユーザーへ利益をもたらしている。モバイルで扱われるデバイスの受容の成長と共に、モバイル情報アクセスおよび遠隔取引は、急激に当り前なものとなってきている。

ビジネス価値
Ｍ．８００モバイル対話システムは、モバイルでの買い物、案内の購入、モバイル製品カタログ、モバイル・ディレクトリ、個人情報管理、および、統一されたメッセージングなどのほとんどのモバイル・サービスの使いやすさを向上させる。アプリケーション・サービス・プロバイダーは、モバイル対話インターフェースを用いた、広い範囲の、個別および分化した申し出を提供することができる。口座管理、証券取引口座、カストマー・サービス、および、セールス・フォース・オートメーションなどのコールセンターのアプリケーションおよび企業データサービスは、声のみのインターフェースを提供する。モバイル対話インターフェースで、多数の入力および出力デバイスを組み合わせることによって小さいデバイスを用いる際は特に、簡単にアクセスし、情報を入力することができる。

その他の利点
モバイル対話システムに基づくモバイル買い物アプリケーションは、買い物客が、店内で購入する前に、彼らのバーコードまたは絵によってオンライン製品情報を検索および比較し、製品識別を入手し、製品情報を調査することを可能とする。モバイル購入案内および製品カタログは、図１に示されているように、より詳細なオンライン調査をするために帰宅する間に、店内で品目の予約することができる。モバイル対話システムでのモバイル・コマースは、モバイル・デバイスでの顧客の経験を向上させ、モバイル・コマースの成長および受け入れを促し得る。

シナリオ１．モバイル・スマート・ショッピング
リアルタイムの、ビデオに基づいた製品識別および個別の製品チェッカー
モバイル対話製品チェッカーは、買い物客が、店内で購入する前に、彼らのバーコード、ビデオまたは絵によってオンライン製品情報を検索および比較し、製品識別を入手し、製品情報を調査することを可能とする。モバイル買い物検索エンジンおよび購入案内は、図１に示されているように、より詳細なオンライン調査をするために帰宅する間に、店内で品目の予約することができる。

シナリオ２．旅行予約．声＋ＧＵＩ（グラフィック・ユーザー・インターフェース）
・座席選択チャートを表示（「窓側または通路側」のみではない）；
・ＰＩＮコードを入力し、話者を照合するのに、声またはキーを使う；
・通知用にオーディオまたは声を使う；
・情報は、後の使用のために保存できる。
このシナリオは図２に示されている。

示されているように、ユーザーは、特定のチャンネルの提示に縛られることはなく、流れの相互作用は、私的で最適化された経験となる。そのようなモバイル出力は、異なる様式が密接に同期されたマルチメディアの例である。

シナリオ３．モバイル株式取引
この例は、声による入力の容易さを利用し、また、同じセッションの画像表示上で詳細な情報を見ることができるため、あなたの経験がいかにより自然で、個別のものであるかを明示する。
このシナリオは、図３に示されている。

話者の照合、視覚情報の相互作用表示（例えばチャート）、オーディオ／ビデオ通知等などの追加的な特徴は、上記相互作用をより自然なものとできる。人は特定のユーザー・インターフェースに制約されることなく、多数の同期されたインターフェースの利点を有効に使うことができる。

システム基本設計概念
システムの一つの例は、サーバー顧客基本設計概念を有する。上記顧客部分は、基本的に２つの部分を含んでいてもよい：
声、テキスト、絵およびビデオ入力などのユーザー相互作用を上記サーバーへ送る入力部分、および、上記サーバーから受け取った結果を提供する出力部分。

サーバー側は、システムに重要なタスクを実行する異なるモジュールを含んでいてもよい。図４に示されているように、上記サーバーは、ユーザーから異なる入力を収集し、対話および相互作用管理（ＤＡＩＭ）へ送る入力部分を有していてもよい。上記ＤＡＩＭモジュールは、上記入力を処理し、上記ユーザーへの結果を発生させるために、アプリケーション特別モジュールと相互作用する。上記結果は、最も適した形で提供することができる上記ユーザー質問(query)の上記結果を構成する、上記出力モジュールへ送られることができる。

サーバー側
上記システムの上記サーバー側は、好ましい態様においては、図５に示されているような、ハブと呼ばれる中央促進モジュールを介して交信する、５つの主な自立したモジュール（またはサーバー）、またはその他（図示せず）を含んでいてもよい。上記異なるサーバー・モジュールは、いくつかのタスクを実行するために、互いに交信する必要がある。これらのメッセージを取り扱うために、ハブが実装される。上記ハブは、上記システムにモジュール性を都合よく提供する。

メッセージは、サービスロジックに基づいたいくつかのルールに従って、サーバー・モジュール間で分配される。

上記メッセージは通常非同期であり、このことは、上記モジュールは即座の対応を受け取ることを期待できないことを意味する。いくつかの機能性を要求するモジュールが、上記ハブへこの仕事を回すことができ、上記ハブは、上記要求を送るモジュールとなる。これは、上記ハブを構成するモジュールの上記特徴モジュール性、分配性および途切れのない統合を作り上げる。

声サーバー
上記声サーバーは、上記声様式を取り扱うモジュールである。相互作用は、両方向に取り扱われる。例えば、上記ユーザーからの会話の入力は、上記ＡＳＲ（自動会話認証）モジュールによって解釈されることができ、上記システムから上記ユーザーからへの声の出力は、合成された声を構築するために上記ＴＴＳ(テキスト対会話)モジュールを利用することができる。

上記声サーバーは、パケット交換方式および回路交換方式の両方の声送信をサッポートすることができる。上記パケットに基づくバージョンは、ＶｏＩＰソリューションである。それは、単にオーディオ入力をコピーし、標準ＰＣＭフォーマットへ変換し、ＴＣＰ／ＩＰ受け口を超えて、顧客およびサーバー間を移動させる。

ＧＵＩサーバー
上記ＧＵＩサーバーは、それぞれグラフィックおよびテキストの、上記ユーザーへの出力および上記ユーザーから受け取った入力を意味する、視覚様式を取り扱う。それは、上記顧客および上記他のサーバー・モジュール間の出入り口として働く。上記ユーザーからの入力は受け取られ、上記マルチモーダル・サーバーを介して上記対話サーバーへ送られる。ユーザー質問からのフィードバックに基づいて、上記結果を表すビデオ、グラフィックおよびテキストが、上記ＧＵＩサーバーによって取り扱われる。上記ＧＵＩサーバーは、グラフィックおよびテキストを表示するために、ウェブサーバーを使用する。

ダウンロード管理サーバー
上記ダウンロード管理サーバーは、上記顧客のコンテンツ・リストを更新し管理するため、および、顧客の送受話器における新たなサービスや情報を無線で更新するために割り当てられてもよい。上記サーバー側のアプリケーションは、顧客の携帯電話へダウンロードおよび貯蔵するため、および、貯蔵およびいかなるデータの束をも費用効率が高いひとつのパッケージにおいて速く効率的に届ける目的で、ウェブサイトと携帯電話との間の直接のやり取りをサポートするためのコンテンツ・リストを作りだす。

ダウンロード管理は、ワン・クリック購入での、新しいまたは存在するコンテンツおよびサービスへの直接のアクセスおよび常に最新のコンテンツをユーザーへ提供する。上記コンテンツ・リストは、顧客が顧客の携帯電話上で上記コンテンツ・リストを開くと、自動的に送受話器へ更新される。

対話サーバー
対話管理とも呼ばれる上記対話サーバー・モジュールは、上記システムの他の重要で、好ましい部分である。上記対話サーバーは、上記マルチモーダル・サーバーからの上記ユーザー質問を受け取る、これらの入力に基づいて、上記対話サーバーは、上記ユーザー相互作用の意味を抽出する。さらに、対話管理は、上記ユーザー質問への答えを生み出すために、上記データベース・サーバーと相互作用する。最終工程は、会話、グラフィックおよびビデオを含む上記質問への応答を上記ユーザーへ提供し、上記情報を移動させることである。

データベース・サーバーおよびデータベース
上記データベースは、全ての種類のアプリケーションをサポートするために、具体的であり、可能な限り一般的であるべきであるアプリケーションである。上記データベース・サーバーは、上記対話サーバーと上記データベースとの間の接続リンクとして働く。

顧客側
基本的に、マルチモーダル顧客は、声顧客およびＧＵＩ顧客を含み、両方とも独立したソフトウェア製品に包含される。例えば、このソフトウェアは、マイクロソフト・ウィンドウズ・モバイル５．０以上などのウィンドウズ・モバイル・プラットフォームのために開発されてもよい。

図６は、顧客がつまり、上記接続管理、ＧＵＩ顧客および声顧客からなる、異なるコンポーネントの理論上の概観を示す。

上記接続管理は、上記声顧客とＧＵＩ顧客と、上記ネットワークを介して結果的に上記マルチモーダル・サーバーとの間のインターフェースを提供する。上記顧客は、Ｐ２Ｐを使用する上記サーバーで交信する。

上記声顧客は、声様式を取り扱う、すなわち、それは上記ユーザーから声コマンドを受け取り、送り、上記マルチモーダル・サーバーから合成された声を出力する。

上記ＧＵＩ顧客は、幾分より複雑である。それは、グラフィック・ユーザー・インターフェースを含むウェブページを読み出すウェブ・ブラウザーからなり、結果としてアプリケーションは提供される。また、それは、他の利用できる上記ユーザーからの入力も取り扱う、すなわち、ユーザーがウェブページ上でアイコンを指すと、上記指されたアイコンの座標(coordinates)が収集され、その後ユーザーが入力し、取り扱うと、上記マルチモーダル・サーバーへ移動される。

情報および通信の流れ
図７は、ユーザー、顧客およびサーバー間の相互作用のパターン、および、上記システムのモジュール間の情報の流れを示す。

上記情報の流れは、ユーザー質問に基づく。これらの入力は、それらの各サーバー・モジュールへ移動される。上記ＧＵＩサーバーは、ユーザーが指した場所を記録し、上記声サーバーがＤＴＭＦまたは声認証を実行し、それの意味の要点を抽出する。次に、これらの入力は、特定の時間ウィンドウ内での入力信号を収集するためにタイマー・メカニズムを採用する、マルチモーダル・サーバーへ引き渡される。

さらに、マルチモーダル・サーバーが受け取った最大の同時入力を、上記時間ウィンドウが失効(expires)すると、それは、これらの入力を上記対話サーバーへ引き渡す。上記対話サーバーは上記マルチモーダル統合と競争し、この処理に基づいて、それは上記質問への応答を生み出そうと試みる。応答について詳しく述べるため、上記対話サーバーは上記データベース・サーバーへ質問することができる。上記データベース・サーバーは、データベース内の検索を実行し、上記対話モジュールへ上記結果を送り返す。

上記結果はその後、上記ユーザーは提供可能な応答を生み出すために、上記対話管理によって処理される。上記応答は、上記マルチモーダル・サーバーへ引き渡され、上記情報は異なる様式、すなわちグラフィックおよび会話へ分けられ、それぞれ上記ＧＵＩおよび声サーバーを介して送り出される。

図７は、上記顧客が、顧客およびサーバー間の２つのロジカルチャンネルを設立する必要があることを示している。１つのチャンネルは、声様式を送信するためであり、もう１つのチャンネルはデータ用である。

顧客およびサーバー間の上記通信は、図８に詳しく説明されている。手順１から６は、上述されている。手順７において、上記マルチモーダル・サーバーは、ウェブ／ワプ(wap)サーバーへアップロードされる、ウェブ／ワプページを生み出す。同時に、上記顧客のソフトウェアへメッセージが送られ、与えられたＵＲＬにおいて上記ウェブページをダウンロードするように伝える。埋め込まれたウェブ・ブラウザーを有する上記顧客は、生み出された上記ウェブページを読み出すために、標準ＨＴＴＰリクエストを送る。手順１０において、上記マルチモーダル・サーバーは、上記ユーザー質問の上記結果から緻密に作りこまれた上記声応答を移動させる。好ましくは同時に、上記結果の声様式を提供するウェブページが上記顧客へ表示される。これらの２つの出力の同期は、上記ユーザー入力の同期と同じぐらい上記ユーザー経験のためには重要である。

好ましいシステム要件
モバイル・マルチモーダル顧客サーバー・システムのための好ましい要件を提示する。上で提示された例は、異なる状況および人々が有するであろう異なるニーズを提供し、マルチモーダル・システムはサービスを提供することができる。これらのシナリオに基づいて、要件は、機能および実行要件の両要件に重点的に取り組まれる。
・上記マルチモーダル・プラットフォームは、好ましくは、それに加えてたくさんのサービスを実行する可能性がある、包括的なプラットフォームである。
・上記マルチモーダル・プラットフォームは、好ましくは、第三者のサービス・プロバイダが彼らのサービスを上記モバイルオペレータのマルチモーダル・プラットフォーム上で提供することを可能とする。
・上記マルチモーダル・システムの顧客側は、有利に単純であり、末端において上記ユーザーの最小限の設定(installation)を要求する。

マルチモーダル性の組み合わせ
本発明の文脈におけるマルチモーダル性は、１つより多くのモーダル性のユーザーを意味する。これは、サービスへ入力する際に、ユーザーは好ましくは１つより多くのモードを使うことができることを意味する。同様に、上記システムは、１つより多くのモーダル性使うユーザーへ出力できることが好ましい。マルチモーダル性の定義は、モーダル性が同時に適応されるか、順次適応されるかについては制限するものではない。

ワールドワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）は、マルチモーダル入力および出の組み合わせの３つの異なる方法を定義した；順次的、非協調同時および協調同時マルチモーダル入力／出力。それらの実行の複雑さは極めて異なるため、これらの３つのシナリオを区別することに利点がある。

順次的マルチモーダル入力／出力
これはマルチモーダル相互作用の最も単純な形式であり、異なるモーダル性の入力および出力が別々に解釈されるが、いかなる瞬間においてもただ一つの、指定された入力モードが動作している。

非協調同時マルチモーダル入力／出力
この状況においては、複数の平行した入力モードが同時に動作している。これは、上記ユーザーが、各対話ステージにおいて彼らが好む入力モードを選択することができることを意味するが、順番に、処理のために一つのみが選択される。各順番においてどのモードが使われるかは、第一のモードで開始、または一つのモードが他のモードよりも優先であるなど、異なる尺度に応じて判断されることができる。

協調同時マルチモーダル入力／出力
これは、相互作用の最も発展した形式である。ここでも、１つより多くの入力モードを同時に利用することができるが、上記非協調同時モードに比べ、ここでは異なるモーダル性からの全ての入力が時間ウィンドウ内で収集され、解釈される。協調同時モードにおいては、イベントは組み合わされ、マルチモーダル・システムへの質問を生み出す。

同時回路切換えおよびパケット切換え接続
近年、ＧＳＭネットワーク用の同時回路およびパケット切換え接続を可能にする、新しい見込みのある方法が見出された。

この技術はデュアル・トランスファー・モード（ＤＴＭ）と呼ばれ、上記テーマについて多くの研究がされている。上記方法は、２つのラジオレシーバを必要としないため、より合理的かつ費用対効果が高い。ＵＭＴＳにおいては、使用されるラジオインターフェースのため、多数の、平行したベアラーをエア・インターフェース上でサポートすることが極めて容易である。これは、同時回路およびパケット切換え接続を可能にする。ＵＭＴＳ装置は、動作の異なるモードにおいて働くことが可能である。表３参照。

モバイル作動システム
今日の市場においては、異なる作動システムおよび接続選択肢を有する数々のモバイル端末がある。新しいスマートフォンおよびＰＤＡと携帯電話との間の集中(convergence)は、複雑なタスクをすることができる、高度に進歩した端末をもたらす。

モバイル端末に主要であると思われる、主に２つのＯＳがある。ノキア、ソニーエリクソン、パナソニック、シーメンスＡＧに所有されるシンビアン、および、マイクロソフトによって提供されるウィンドウズモバイルである。

つい最近まで、シンビアンＯＳが、高度なモバイル端末用の主要な作動システムであった。これは、ノキアやエリクソンなどのいくつかの世界最大級の携帯電話会社が上記ＯＳを彼らのスマートフォンで使用しているからである。にもかかわらず、上記同じプラットフォームのユーザーは、各会社が彼らの私有のグラフィック・ユーザー・インターフェースを使用している。マイクロソフトがモバイル端末市場に参入しようと決断した時、彼らが強力な競争相手となることは明らかであった。ほとんどのＰＣユーザーは、ウィンドウズＯＳを知っている。多くのユーザーが、彼らのモバイル端末においても同じサービスおよびアプリケーションへの同じインターフェースおよびアクセスを望むのは自然なことである。

公開されたウィンドウズモバイル６は、異なるバージョンになっており、ひとつのバージョンはスマートフォンと呼ばれ、他はポケットＰＣと呼ばれる。これらのバージョンにおける主な違いは、それらが２つの異なるタイプの進歩したモバイル端末に適合していることである。上記スマートフォン版は、キーパッドおよびスクリーンを有する通常の携帯電話により近い。上記ポケットＰＣ版は、タッチセンサー式スクリーンを有するＰＤＡのために開発された。

モバイルコンテンツ配信ソリューション
現代のモバイルコンテンツ配信ソリューションは、ホリゾンタル・サービス・オリエンテド・アーキテクチャー・アプローチを利用する図９が、典型的なシステム・コンポーネントを説明する。

好ましいシステム・コンポーネント
・モバイル相互作用サービス（ＭＩＳ）：デバイス認証に最適なデバイスを提供し、ディスカバリー・ポートレットを提供し、デバイスおよび彼らがサポートするデジタル・メディア・フォーマットのプロファイルを維持する。
・達成管理：コンテンツの種類および対象デバイスに基づいて最適なダウンロードメカニズムを決定することにより、幅広いアクセスチャンネルのダウンロード可能なコンテンツの配信を提供し、その後、ダウンロード自体の完了を確保する。
・ユーザー・ポータル：オペレータの既存の請求およびメッセージング・プラットフォームとの素早い統合を可能とする、利用可能なコンテンツおよびファシリティーのディスカバリーのための骨格。
・コンテンツ管理システム：提出および取得から、目録および照合まで、発行およびデジタル・メディアの最終的な退役までの、完全なコンテンツ・ライフサイクル管理を提供する。
本発明のシステムによって提供される機能は、図１０に説明されている。

コンテンツ・ディスカバリーおよび配信は、末端ユーザーがアクセスし、オペレータによって提供されるサービスおよびコンテンツを利用する、上記ユーザー・ポータル環境の背景においてなされる。

コンテンツ管理は、上記ユーザー・ポータル環境へのコンテンツの提出、承認および発行を管理するために、コンテンツ・プロバイダがオペレータと作業をする、オペレータの管理上の環境においてなされる。

典型的なオペレータの環境における他のコンポーネントとの統合および相互作用と共に、上記個々のコンポーネントによって提供される機能は、以下の記載および図１１に詳細に記載されている。

上記ユーザー・ポータル環境におけるコンテンツ・ディスカバリーおよび配信
上記ユーザー・ポータルは、彼らのサービス加入、設定された好み、および上記ユーザー・ポータルへアクセスするために彼らが使用している上記デバイスの性能に基づいて、末端ユーザーに一連の利用可能なサービスへのアクセスを提供する。上記ユーザー・ポータルは、上記ユーザーのデバイスを認識し、上記ユーザーのサービス加入プロファイルへアクセスし、上記デバイスの性能に基づいて適切に申し込まれたサービスを提供することにより、上記末端ユーザーの利用可能なサービスの適合した表示を動的に生み出す。上記ユーザー・ポータルは、末端ユーザーがＰＣブラウザ、ＰＤＡブラウザ、ＷＡＰおよび携帯電話ブラウザ等を含む幅広いデバイスからサービスへアクセスすることを可能とする。

上記ユーザー・ポータルにおいて提供されるサービスに、着信音ダウンロード、壁紙ダウンロード、ジャバゲームダウンロード、音楽およびビデオ・ダウンロード等などのコンテンツ・ダウンロード・サービスがある。これらのダウンロード・サービスは、ユーザー・ポータルにおける「ポートレット」として実行され、末端ユーザーが彼らのデバイスへダウンロード可能なコンテンツを「発見」し、その後購入（適切であれば）を開始し、彼らのデバイスへのコンテンツの「配信」（ダウンロード）を可能にする。

コンテンツ・ディスカバリー
個々のコンテンツディスカバリーポートレットは、ダウンロード可能のものとして末端ユーザーのデバイスに適切なコンテンツのみが提供されることを確実にするために、上記ユーザー・ポータルによって提供された、上記デバイスが承知した骨格を活用する。例えば、多声の着信音は、末端ユーザーのデバイスがそれらをサポートする場合にのみ、上記ディスカバリー・ポートレットへ示される。上記ディスカバリー・ポートレットは、上記マルチチャンネルデバイスをも活用し、最適な提示および上記ポートレット自体とのユーザー相互作用を確保するために、上記ユーザー・ポータルの機能を提供する。

上記ユーザー・ポータルと統合された上記コンテンツ・ディスカバリー骨格は、以下を含む上記コンテンツ・ディスカバリー処理を可能とする、追加の、一般的な性能をディスカバリー・ポートレットへ提供する。
・デバイス特性、特定のコンテンツ骨格、キーワード、サービス・アソシエーション等に基づいて、利用可能な発行されたコンテンツを質問し、確認するためのインターフェース。
・末端ユーザーへ提供するための、価格情報の検索を可能にするインターフェース。
・ディスカバリーが完了したら、上記コンテンツ自体の配信を開始する機能。

コンテンツ・ディスカバリー・ポートレットは、次の２つのいずれかの方法においてコンテンツのディスカバリーを可能にするために、上記発行されたコンテンツを質問する機能を一般的に活用する：１）末端ユーザーには、一連のメニューが提供され、興味がある特定のピースのコンテンツを彼らが見つけるまで、選択されたカテゴリーのコンテンツの中をナビゲートされる。これらのメニューは、上記ディスカバリー・ポートレットによって動的に生み出され、上記末端ユーザーのデバイスの機能に基づいてフィルタリングされたコンテンツの選択肢のみが上記末端ユーザーへ提供されることを確保する。コンテンツのメニューは、カテゴリー、フォーマット、人気度等によって編成され、提供されてもよい；２）末端ユーザーに、上記検索基準にマッチする、利用可能なコンテンツのリストが提供される。この場合も、上記末端ユーザーのデバイスの機能に基づいて、コンテンツはフィルタリングされる。

実際は、コンテンツ・ディスカバリー中の上記ユーザー経験は、個々のディスカバリー・ポートレットの実行、オペレータによって採用される所望のビジネスモデル、ネットワーク自体に潜在する、オペレータによって提供される性能によって大きく異なる。さらに、末端ユーザーは、コンテンツの完全版の配信を開始する前にコンテンツの試写または見本をとる能力を提供されてもよい。また、末端ユーザーは、コンテンツの種類や、例えば、一定月額で無制限の着信音ダウンロードが無料、１０個の壁紙が５ドル、各ジャバゲームが２ドル、ゲームの追加レベルが各２．５ドルなどの、オペレータが選んだビジネスモデルに応じて、選択する価格オプションを提供されてもよい。

ネットワーク性能制限は、前払いのダウンロードの提供、ＷＡＰプッシュを用いるコンテンツの配信の供給、または、他の末端ユーザーのためにコンテンツを発見する能力の提供することを不可能にするかもしれない。

上記ディスカバリー・ポートレット自体は、単純で、人を引き付けるユーザー経験を確保するように設計されていることが好ましい。

コンテンツ配信
末端ユーザーが上記コンテンツ・ディスカバリー処理を終了し、上記コンテンツの配信を進めることを承認すると、上記配信処理が始まる。上記選択されたコンテンツの配信は、上記末端ユーザーが要求したコンテンツの種類；上記末端ユーザーのデバイスの性能；および上記コンテンツが発見された方法に大きく依存する。

例えば、ディスカバリーが上記コンテンツが配信されるべきデバイスと同じデバイスを用いて終了された場合、上記コンテンツは、上記コンテンツを引き入れるように上記末端ユーザーのブラウザまたはアプリケーション管理をリダイレクトすることにより、同じセッション内において直接配信されることができる。また、ＷＡＰプッシュなどのメカニズムを使って、上記コンテンツは別々に上記末端ユーザーのデバイスへ送られることができる。

コンテンツ・ダウンロード・サービスを含む上記ユーザー・ポータルは、議論されていない。上記モバイル相互作用サーバーは、デバイス認証および上記ユーザー・ポータルや関連した幅広いデバイスに亘るサービスの最適な提出を提供するために、上記ユーザー・ポータル骨格内に配備される。

上記ユーザー・ポータル骨格は、それらがコンテンツのディスカバリーおよび配信中に利用されることができるように、オペレータの配備環境における様々な要素と統合されている。典型的には、上記ユーザー・ポータルは、上記オペレータのショート・メッセージ・サービス・センター（ＳＭＳＣ）およびＷＡＰプッシュ・プロキシ―・ゲートウェイ（ＰＰＧ）、前払いおよび後払いの請求プラットフォーム、および、上記オペレータの供給および顧客ケア・プラットフォームと統合されている。上記ユーザー・ポータルは、また、統合されたコンテンツ管理システムである。

達成管理
上記モバイルコンテンツ配信骨格内において、上記達成管理は上記コンテンツ配信処理を促進する。それは、上記ダウンロードを要求する上記末端ユーザーが、コンテンツのダウンロードを許可されることを確保し、上記コンテンツおよび対象デバイスに基づいて使われるべき適切なダウンロードメカニズムを決定し、上記ダウンロード自体の完了を確保する。

それは、請求の承認を可能とし、ダウンロードの追跡を確保するために、請求および統計発生コンポーネントとインターフェースし、また、必要に応じて、Ｊ２ＭＥデバイスからのインストール報告も取り扱う。

上記達成管理内におけるビジネス論理は、オペレータのビジネスモデルと合わせるようにカスタマイズすることができる。例えば、請求承認は、上記コンテンツの配信の前に生じてもよいし、上記ダウンロードの完了に追ってのみ生じてもよい。上記ビジネス論理は、前払いの加入者および後払いの加入者間でも異なる。

上記達成管理は、通常は上記Ｊ２ＥＥ顧客供給標準に基づく。それは、コンテンツの種類の数の供給のための概念的なアダプター・モデルを提供し、数々の供給モデルをサポートする。上記達成管理は、上記ディスカバリー・デバイスへの直接の配信を促進し、上記オペレータのネットワークから入手可能なＷＡＰプッシュファシリティーを用いてデバイスへの配信を可能とすることにより、ＰＣに基づくディスカバリーもサポートする。

上記達成管理は、ＭＩＤＰ ＯＴＡおよびＯＭＡ、ＯＴＡのための特定のアダプターを提供し、例えばイメージ、オーディオ、ファイル等
の直接のダウンロードなどの、その他全てのダウンロードを取り扱うための包括的なダウンロードアダプターを提供し、必要に応じて、追加的なアダプターをサポートするために容易に広げることができる。

コンテンツ管理
上記モバイルコンテンツ配信システムは、上記コンテンツ管理スイートの上記コアコンポーネントを活用する：
コンテンツ・サーバー：コンテンツ・プロバイダによって提示され、その後上記サイト・キャッシング・サービスへ発行された上記コンテンツを貯蔵する。
キャッシング・サービス：上記ユーザー・ポータルにおいてディスカバリー・ポートレットからダウンロードできる、発行されたコンテンツを貯蔵する。関連するデータベースが上記サイト・キャッシング・サービスに貯蔵されたコンテンツと同様に、外部のコンテンツ・プロバイダによって物理的に主催されたコンテンツを説明するメタ−データを貯蔵する。
コンテンツサービス：可能性のあるダウンロードのために上記末端ユーザーへ提示するのに適した特定のコンテンツのための、入手可能な発行されたコンテンツを検索するために、ディスカバリー・ポートレットがコンテンツ接続を使うことを許容する、メタ−データベースへのインターフェース。
ウェブ制作者：コンテンツのライフサイクルを管理するために、コンテンツ管理者によって使われるツール。処理は、コンテンツが提示され、分類され、承認され、発行され、必要に応じて退却されることを可能とする、カスタマイズされた作業の流れとして具現化される。メタ−データ・オブジェクト・モデルは、上記コンテンツを完全に説明し、発行物のディスカバリーおよびダウンロードを可能とするために使われる。上記メタ−データは、コンテンツの種類、形式およびサイズなどの上記コンテンツ自体について、また、アーティスト、タイトル、およびカテゴリーなどの記述的な情報についての基本的な詳細を説明し、末端ユーザーへの提示のためにコンテンツをフィルターにかけるために、個々のディスカバリー・ポートレットが効果的に上記コンテンツ・サービス・インターフェースを効果的に使うことを可能とする。
メディア・サービス：自動複製および別の形式およびサイズへの提示されたコンテンツの変換を提供し、自動メタ−データ抽出を実行し、ＤＲＭツールキット、グラフィック・サービス等の統合を可能とする拡張可能なプラグ−イン骨格を提供する。

コンテンツ・プロバイダ
外部のコンテンツ・プロバイダによるコンテンツの提示を促進するために、上記オペレータの管理環境にコンテンツ・プロバイダ・ポータルが配備されてもよい。上記コンテンツ・プロバイダ・ポータルは、上記コンテンツ・サーバーへコンテンツを提示および更新するためにコンテンツ・プロバイダによって使用されることができる、コンテンツ管理ウェブアプリおよび／またはＦＴＰサーバーなどのインターフェースを提供する。ウェブ・アプリケーションを用いて、コンテンツ・プロバイダは、基本的に上記メタ−データスケマである上記コンテンツを説明するウェブに基づくフォームを記入し、その後、上記コンテンツ・サーバーへ上記コンテンツを更新する。ＦＴＰサーバーを用いて、コンテンツ・プロバイダは、上記コンテンツおよび上記コンテンツ用のメタ−データを説明するＸＭＬファイルを更新する。

好ましい無線デバイス要件。デュアル−プロセッサ基本設計概念
米国特許第７，５４８，８７５号には、マルチメディアＤＳＰサブシステムを有する無線通信デバイスが記載されている。このデュアル−プロセッサ基本設計概念は、リアルタイムのビデオ処理を含む、最も要求が多いマルチメディア・アプリケーションの処理にとてもよく適合している。上記基本設計概念は著しく向上され、低電力な、プログラミングできるＤＳＰおよび強力なＲＩＳＣ（縮小命令セット・コンピュータ）多目的プロセッサを利用することによって最適化された。

アプリケーションの要求のため、上記２つのプロセッサ間での上記アプリケーション・タスクの分割は重要である。それらを最も適して取り扱えるように上記プロセッサへタスクを割り当てる際には、上記システムの速度および処理能力が最適化されるべきである。上記適したプロセッサへの最適なタスクの割り当ては、各タスクのために要求されるプロセッサ・サイクルの数を低減し、同様に、上記バッテリーから流れ出る電力を低減し、上記モバイル・デバイスの使用可能時間を延ばす。

図１２は、要求が多い無線マルチメディア・アプリケーションのために必要とされる処理能力の提供を最適化し、同時に、より少ない電力を消費することによってモバイル・デバイスのバッテリー寿命を延ばす、モバイル・ビデオ・アプリケーションを上記デュアル−プロセッサ基本設計概念上へ位置するための効率的な方法を示す。

モバイル・ビデオ・アプリケーションに関与する上記タスクは、制御、輸送、およびメディア・デコードに分割できる。制御および輸送タスクは、リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）およびリアルタイム・プロトコル（ＲＴＰ）の処理を含み、それはメディア輸送メカニズムである。これらのタスクはコンピュータ的に集中していないため、多目的ＲＩＳＣプロセッサがこれらの実行に適している。

メディア・デコード・タスクは、上記ビデオ・ビット・ストリームのデコード、高品質オーディオ・デコードおよび他の信号処理タスクに関与する。これらの処理は、コンピュータ的に集中している。その結果、高性能な、低電力ＤＳＰがメディア・デコード・タスクにぴったり合う。

ビデオ・アプリケーションの処理中、モデムを通して上記システムへラジオ信号が入る。上記多目的ＲＩＳＣプロセッサは、ＲＴＰ／ＲＴＳＰプロトコル処理を取り扱い、上記オーディオおよびビデオ・データを分離する。上記ラジオ信号はその後、基本的なビット・ストリームへ変換され、ＤＳＰの内部のランダム・アクセス・メモリ（ＲＡＭ）へ送られる。

上記システム上での処理要求を最小にするために、ビデオ・アプリケーションは、現在(current)のフレームまたはイメージを次のフレームの推測に利用する。フレームは、一度に１つのマクロ−ブロックが、上記フレーム・バッファーから、他の情報と組み合わされ、上記現在のフレームとして上記ディスプレイへ送られるＤＳＰの内部ＲＡＭへ移動される。

上記２つのプロセッサの処理能力は、データがタイミング良く上記システム内を移動できないと、無駄になる。ダイレクト・メモリ・アクセス（ＤＭＡ）接続は、Ｉ／Ｏボトルネックを防止するために用いられ、ビデオ・アプリケーションを無効にすることができる。すべてのＤＭＡチャンネルは、すべての共有されているメモリへのアクセスを有し、効率的な内部データの流れを確保する。上記ＤＭＡ能力は、大きなグラフィック・イメージは、素早くおよび絶え間なく外部メモリから内部メモリへ移動されなければならないため、データ構造の移動を加速するために必要とされる。

デュアル−プロセッサ基本設計概念は、両方のプロセッサが同じメモリ・ロケーションを争う場合に生じ得る、プロセッサ間の対立の問題を提起する。加えて、２つのいずれかのプロセッサによって開始された、特定の位置のメモリへのメモリ・アクセス要求は、一度に一つしか処理できない。基本設計概念の内在する部分である上記トラフィック制御のため、上記システムは上記プロセッサ間の争いを打開することができる。

上記トラフィック管理は、上記ＤＳＰ、多目的ＲＩＳＣプロセッサおよび外部のインターフェース間に位置する、プログラミング可能な調停メカニズムである。上記トラフィック制御内へプログラムされたアルゴリズムに応じて、それは、メモリ・アクセスの優先順位を決め、起こり得る対立を解決する。

エラー修正。現代の圧縮標準に組み込まれたＭＰＥＧ−４などの、通常のエラー回復ツールの他に、上記システムには上記後処理技術が従事する。この技術は、上記ビデオ・デコード処理を追跡し、破損したマクロブロックを、前のフレームからの破損していないマクロブロックと交換し、上述したエラー回復ツールを介して回復されたデータを使用する。

現在のフレームをより正確に推定するために、上記プロセッサが過去のフレームを再分析することが、これらのツールおよび技術には度々必要であるため、エラー修正処理は、デバイスのＩ／Ｏチャンネルへ負担をかける。データの大きなブロックが、ＤＳＰプロセッサの外部メモリとそのオン−チップＲＡＭ間を行ったり来たり流れる。Ｉ／Ｏがボトルネックとなる可能性を減少させる、数々のＤＭＡチャンネルのため、上記システムはそれを乗り越えられる。

用語集
ＣＭＳ ＡＰＩ：コンテンツ管理システム・アプリケーション・プログラミング・インターフェース
ＤＢ：データベース
ＤＣ：ディバリー・コンテクスト
ＤＲＭ：デジタル・著作権管理
ＦＴＰ：ファイル転送プロトコル
Ｊ２ＭＥ：ジャバ２プラットフォーム、マイクロ・エディション
ＪＳＰ：ジャバ・サーバー・ページ
ＯＭＡ：オープン・モバイル・アライアンス
ＭＭＳ−Ｃ：マルチメディア・メッセージ・サービス・センター
ＰＯＲＴＬＥＴＳ：ウェブポータルにおいて管理および表示されるユーザー・インターフェース・コンポーネント
ＰＤＡ：個人用デジタル補助装置
ＳＣＰサービス管理ポイント
ＳＤＰ：サービス配信プラットフォーム
ＳＭＰＰ：ショート・メッセージ・ピアツーピア・プロトコル
ＳＭＳ−Ｃ：ショートメッセージ・サービス・センター
ＷＡＰ：ワイヤレス・アプリケーション・プロトコル
ＷＡＰ−ＧＷ：ワイヤレス・アプリケーション・プロトコル・ゲートウェイ
ＷＰＰＧ：ＷＡＰプッシュ・プロキシ・ゲートウェイ
ＸＭＬ：拡張マークアップ言語

本発明を利用するための好ましい方法およびシステムは、２００２年６月２６日に出願され、「メディア配信プラットフォーム」と題され、同時係属の米国特許出願番号１０／１５３、７５６号、新しい米国特許第７，５４８，８７５号に開示されたものであり、ここに参照することにより、その全体が援用される。

Claims (2)

1. レシーバーへ、デジタル的に圧縮されたデータコンテンツを介して品目および購入情報を送信する、バーコード・リーダー。
2. 携帯電話である、バーコード・リーダー。

Images