JP4131856B2 - 別個のマルチチャネルプロトコル上でのマルチモーダルセッションサポート - Google Patents

Description

優先権の主張
この特許出願は、「別個のマルチチャネルプロトコル上でのマルチモーダルセッションサポート」（“Multimodal Session Support on Distinct Multi Channel Protocol”）と題された、２００１年７月２０日に提出された米国仮特許出願第６０／３０６，７０４号の優先権を主張し、この内容の全体が、ここで引用により援用される。

発明の分野
この発明は、一般に通信システムに関し、より具体的には、異なるインタラクションチャネル間でセッションを共有するためのメカニズムに関する。

発明の背景
ワイヤレス技術の利用は逸早く、通信を可能にするための容認された人気のある方法となった。いかなる場所からも会話に携わることができる便利性のために、多くの人々がモバイルデバイスを享受している。ワイヤレスキャリアは、音声通信を提供することに加えて、さまざまなサービスを提供し始めた。これらのサービスは、多くの場合、インターネットアプリケーションの能力をワイヤレス環境へと拡張する。たとえば、多くの人々は、携帯電話を通してインターネットにアクセスして、株価を得、買物をし、または道案内を得る。

別の通信デバイスと音声情報を交換している通信デバイスは、これを音声セッション上で行なう。言い換えると、音声セッション中に行なわれるインタラクションは、可聴音を含む。対照的に、可聴音は、非音声セッション内でのインタラクションモードではない。通例、非音声セッション内のインタラクションは、ブラウザ上でのメニューの表示等の視覚的なインタラクションを含む。

たとえば、携帯電話を通してインターネット上の視覚情報にアクセスする場合、非音声セッション上で通信が行なわれる。ここで用いられるようなセッションとは、ある特定のタイプの情報交換のためにデバイスが用いられている期間を指す一般的な用語である。たとえば、携帯電話上での音声セッションの間、通信モードは、可聴音を含む。携帯電話上での非音声セッションの間、通信モードは、可聴音以外のものを含む。

あるタイプのセッションの上で通信しているとき、別のタイプのセッションに切換えて、別のモードまたはチャネル内で関連のアクティビティを続けることが望ましい場合もある。たとえば、インターネットは、いくつかのオンラインミュージックストアを含む。単一チャネルの環境では、ユーザは、単一のチャネルまたはモードから音楽をサーチし、ブラウズし、選択し、聞くことができる。たとえば、これらの動作のすべては、１−８００番号をダイヤルすることによって音声チャネル上で行なわれ得るか、または、電話ベースのブラウザを用いて非音声チャネル上で、すべてが行なわれ得る。

デバイスが両タイプのセッションをサポートする場合、ユーザが、これらのタスクのうちのいくつかをある特定のモードで行い、さらには他を別のモードで行うことができるようにすることが便利であろう。たとえば、ユーザは、ブラウジングおよび選択のためにビジュアルモードでサービスを開始し、ユーザのデバイスキーパッドを用いて適切な歌を選択し、ユーザがその歌をクリックすると、デバイスは、その歌を聞くための音声モードを
有するようにシフトし得る。

セッションタイプ間で切換わる能力が有用となり得る別の例は、電子メールアプリケーションである。ユーザは、自身の電子メールリストをブラウズできるべきであり、ある特定の電子メールをクリックしたときに、その内容を聞くことができる。なお、ここでは、電子メールの内容（データ）は、テキストであるが、ユーザが音声モードにシフトするため、インタラクションは、音声となる。

残念ながら、今日のデバイスおよびネットワークでは、デバイスが１つのモードから別のものへと（たとえば、非音声セッションから音声セッションへと）シフトするとき、トランザクションは、維持されない。言い換えると、ユーザは、コンテキストデータ、または、最近のアクティビティの状態を表わす情報をセーブできない。したがって、コンテキストデータがセッション間でセーブされ得ないため、古いセッション内で用いられた、または利用可能であった、新しいセッション内で必要とされるいずれかの情報を再入力する必要がある。たとえば、オンラインミュージックストアの例では、たとえユーザが非音声セッション内で既にその情報を入力していたとしても、音声セッション内で身分を証明し、聞きたい音楽の選択を識別する必要がある。大部分のモバイルデバイスが持つ比較的ローテクな入力メカニズムのため、データを再入力する不便さは、著しい。

データ再入力の問題は、音声セッションから非音声セッションへと切換わるときにも生じる。たとえば、販売員と電話で会話しているとき、販売員のウェブサイトに切換えて、カスタマイズされた様態で販売員との会話に応じて示される製品および販売情報をすぐに見られることが望ましいであろう。残念ながら、現在は、販売員との音声による会話の後、いかなる事前の会話の恩恵も受けずに手動で対応のウェブサイトを検索する必要がある。

情報の再入力は、時間のかかる繰返しの行為であり得る。あるセッションタイプから別のものに切換えるときに情報を再入力する必要性をなくすことが望ましい。しかしながら、現在は、これを行なうための効率的なメカニズムが存在しない。

概要
先行技術の欠点を克服するために、この発明は、異なる通信モード（たとえば、音声セッションと非音声セッションとの）間でトランザクションを維持するための改善されたメカニズムを提供する。この発明の１つの局面に従うと、あるセッション内のアクティビティについての情報が、コンテキストデータとして記憶される。クライエントが、あるタイプのセッションから別のものに切換えると、そのクライエントのためのコンテキストデータが取出される。取出されたコンテキストデータが用いられて、前のセッションの状態が再生成され、したがって、以前利用可能であった情報を再入力する必要性がなくなる。

別の局面に従うと、このように記憶された情報は、同じタイプの新しいセッション内で用いるために利用できる。したがって、ユーザは、非音声セッションから音声セッションに切換えてから非音声セッションに戻り得る。後者の非音声セッションは、ユーザには見えない様態で前の非音声セッションに対してセーブされた状態データが表わす状態で、開始し得る。新しいセッション内でのアクティビティの効率および使いやすさが、大きく高められる。したがって、この発明は、先行技術と比べて大きな改善を提供する。

この発明は、同じ参照番号が同様の要素を指す添付の図において、限定としてではなく、例として示される。

実施例の詳細な説明
非音声セッションと音声セッションとの間で情報を共有するための技術が提供される。以下の説明では、説明の目的のために、多くの具体的な詳細が示されて、この発明の完全な理解が提供される。しかしながら、この発明は、これらの具体的な詳細がなくても実施され得ることは、当業者にとって明らかであろう。別の例では、この発明を不必要に曖昧にしないために、周知の構造およびデバイスは、ブロック図の形で示される。

システム概要
図１を参照して、この発明の一実施例が実現され得るシステム１００の機能ブロック図が示され、システム１００は、ＷＡＰゲートウェイ１２０、音声ノードサーバ１３０、およびウェブサーバ１５０を含む。システム１００は、通信デバイス１１０に結合される。簡潔にするために、１つの通信デバイス１１０しか示されていないが、多数の通信デバイス１１０が、ＷＡＰゲートウェイ１２０または音声ノードサーバ１３０に結合され、それらと通信し得ることが注目されるべきである。この発明の目的のために、通信デバイス１１０は、携帯電話またはパーソナルコンピュータを含むが、それらに限定されているわけではない、ＷＡＰゲートウェイ１２０および音声ノードサーバ１３０と通信できるいかなる機構でもあり得る。通信デバイス１１０は、ＷＭＬ、ＨＤＭＬ、およびＰＱＡを含むが、それらに限定されているわけではない公知のいかなるプロトコルも用いて情報を呈示し得る。通信デバイス１１０は、ＷＴＰ（「ワイヤレス転送プロトコル」）を含むが、これに限定されない公知のいかなるプロトコルも用いて、ＷＡＰゲートウェイ１２０および音声ノードサーバ１３０と通信し得る。

ＷＡＰゲートウェイ１２０は、非音声セッションにおいて通信デバイス１１０に対する非音声情報を送受信することを担う構成要素である。より具体的には、ＷＡＰゲートウェイ１２０は、１つのプロトコル内においてウェブサーバ１５０からの非音声情報を送受信し、別のプロトコル内において通信デバイス１１０からの非音声情報を送受信する。一実施例では、ＷＡＰゲートウェイ１２０は、物理的な接続上でウェブサーバ１５０と通信し、ワイヤレス接続上で通信デバイス１１０と通信する。ＷＡＰゲートウェイ１２０は、ＨＴＴＰを含むが、これに限定されない公知のいずれかのプロトコルを用いてウェブサーバ１５０と通信し得る。

音声ノードサーバ１３０は、音声セッションにおいて通信デバイス１１０に対する音声情報を送受信することを担う構成要素である。音声ノードサーバ１３０は、通信デバイス１１０からの送信を認証することを担う。音声ノードサーバ１３０は、ＨＴＴＰを含むが、これに限定されない公知のいかなるプロトコルも用いて、ウェブサーバ１５０と通信し得る。

ウェブサーバ１５０は、通信デバイス１１０からの情報に対するリクエストを処理することを担う構成要素である。この情報は、電話からの音声情報または非音声情報リクエストを含む。ウェブサーバ１５０は、静的ファイルにアクセスし、サーバによって解析されるエンティティを処理し、さらには１つ以上のアプリケーションを実行することによって、または、コンテントプロバイダにアクセスすることによって、非音声情報リクエストを処理し得る。ウェブサーバ１５０は、他のパーティとの音声コールを確立することによって、音声情報リクエストを処理し得る。

機能的概要
音声セッションまたは非音声セッションのいずれかにおいての最近のアクティビティを
詳述する状態情報が、ウェブサーバ１５０によってコンテキストデータとしてセーブされる。次に、コンテキストデータは、１つ以上の後続のセッションにとって利用可能にされる。セーブされたコンテキストデータを利用する後続のセッションは、コンテキストデータがセーブされたセッションと同じタイプであっても、または異なるタイプであってもよい。

たとえば、携帯電話のユーザが非音声セッション内でミュージックストアサイトをブラウズしていると仮定する。ユーザは、ある特定のＣＤについての情報を引出し、音声セッションベースのミュージックサービスからのＣＤのサンプルを聞くことを望み得る。音声セッションに切換わる前に、特定のＣＤを識別する非音声セッションからのコンテキストデータが、記憶される。次に、ユーザは、音声セッションに切換え、ミュージックサービスにアクセスする。ミュージックサービスは、記憶されたコンテキストデータの存在を検出し、従来の音声ベースのメカニズムを用いてＣＤを識別するか、またはコンテキストデータに記憶されたＣＤ情報を読出すかのオプションをユーザに提供し得る。ユーザがコンテキストデータの使用を特定する場合、ミュージックサービスは、コンテキストデータ内で識別されるＣＤのサンプルを再生する。

サンプルを聞き終えた後、ユーザは、オンラインストアでのＣＤのブラウジングに戻ることを望む場合もある。非音声セッションに切換えられるとき、コンテキストデータが用いられて、ユーザが音声セッションに切換えたときにユーザがいた同じポイントにおいて、新しいセッションが開始され得る。

コンテキストデータ
非音声セッションのためのコンテキストデータは、インターネット上で訪れたサイトの最近の履歴、最近の購入等を表わすデータを含み得るが、これに限定されているわけではない。同様に、音声セッションのためのコンテキストデータは、音声メニュー内で選択された最近のオプション、および別の人物との会話で扱われた最近のトピック（このような会話についての情報は、会話の参加者によって電子的に記憶され得る）等を含み得る。

いくつかの実施例では、コンテキストデータは、ある特定の通信デバイス１１０の最近のアクティビティについて記憶される。他の実施例では、コンテキストデータは、通信デバイス１１０の各ユーザの最近のアクティビティについて記憶される。

一実施例では、コンテキストデータは、固定された時間間隔でセーブされる。別の実施例では、コンテキストデータは、セッション内で新しいアクティビティができしだい、セーブされる。あるセッションのためのコンテキストデータのセーブはまた、たとえば、異なるタイプのセッションへの切換に応答して実行され得る。

コンテキストデータのセーブ
一実施例に従うと、コンテキストデータは、クッキーまたは固定の媒体にデータを記憶するための他の周知のメカニズムを用いて、ウェブサーバ１５０によってセーブされる。たとえば、インターネットｈｔｔｐ通信上では、セッションＩＤが、クッキー内でクライエントとサーバとの間で渡される。このセッションＩＤは、サーバがこの通信についてのいずれかの情報に索引をつけることを可能にする。

このマルチモーダルの世界では、多数のモードにわたって同じセッションを保つことが課題である。多数のモードは、多くの場合、多数のＩＤが存在することを仮定する。たとえば、音声モードでは、（通例、電話番号である）音声ＩＤが存在し得、ビジュアルブラウザモード（ＷＡＰブラウザ）では、これは、サブスクライバーＩＤ（「ビジュアルブラウザＩＤ」）であり得る。

一実施例に従うと、「モード」−ＩＤを同じセッションにマッピングするためなどに、異なるモード間で共通のＩＤが用いられる。大部分のビジュアルブラウザ、ＷＡＰブラウザは、周知のクッキー機能をサポートし、これらは、サーバが所与のセッションについてのある情報（多数の連続的なリクエスト）を渡すことを可能にする。しかしながら、他のいくつかのモード（たとえば、音声）は、このサポートを有さない。したがって、モバイルアプリケーションサーバは、それがデバイス／モードＩＤを管理するやり方において柔軟性がなければならない。クッキーは、リクエスト上での小さな情報を記憶するための最も簡単なメカニズムになりやすいため、一実施例では、サーバは、可能な場合に、音声ＩＤ、ビジュアルブラウザＩＤ、およびセッションＩＤに対してこのメカニズムを用いる。

コンテキストデータの使用
通信デバイス１１０が新しいタイプのセッションを開始する場合、リクエストは、所望のセッションが音声セッションであるならば、音声ノードサーバ１３０によって受信され、所望のセッションが非音声セッションであるならば、ＷＡＰゲートウェイ１２０によって受信される。一実施例では、新しいセッションに対するリクエストを受信すると、ＷＡＰゲートウェイ１２０および音声ノードサーバ１３０は、リクエストが始まった特定の通信デバイス１１０を識別し、ウェブサーバ１５０と交信して、リクエストしている特定の通信デバイスのための、いずれかの記憶されたコンテキストデータが存在するかを判断する。これは、一実施例では、音声セッションを確立するために用いられる電話番号を調べ、ルックアップテーブルを用いて、リクエストしている通信デバイス１１０を決定することによって、行なわれる。別の実施例では、新しいセッションに対するリクエストを受信すると、ＷＡＰゲートウェイ１２０および音声ノードサーバ１３０は、リクエストが始まった通信デバイス１１０の特定のユーザを識別し、ウェブサーバ１５０と交信して、リクエストしている特定のユーザのためのいずれかの記憶されたコンテキストデータが存在するかを判断する。

ビジュアルから音声へのモード切換についての特定の例では、サーバは、ビジュアルＩＤを音声ＩＤにマッピングする。たとえば、ＷＡＰサーバのうちのいくつかは、クッキーをサポートせず、したがって、ビジュアルＩＤは、セッションまたは少なくともデバイスを独自に識別する何か他のものである必要がある。この特定のＷＡＰ事例では、サブスクライバーＩＤが、デバイスＩＤとして用いられ得る。

コンテキストデータが利用可能であるならば、コンテキストデータが、ウェブサーバ１５０から取出され、新しいセッション内で用いられるように利用可能にされる。言い換えると、リクエストされる新しいセッションが音声セッションである場合、コンテキストデータが、ウェブサーバ１５０から音声ノードサーバ１３０に送信され、コンテキストデータ内の情報が、新しい音声セッション内で音声ノードサーバ１３０によって用いられる。ユーザがビジュアルから音声に切換える場合には、残念ながら、ほどんどの場合、サブスクライバーＩＤは同じではない。音声の場合、デバイスＩＤは電話番号となる。したがって、システムは、それが同じセッションであることを認識できるように、サブスクライバーＩＤを電話番号と同期させる。

したがって、リクエストされる新しいセッションが非音声セッションである場合、コンテキストが、ウェブサーバ１５０からＷＡＰゲートウェイ１２０に送信され、送信されたコンテキストデータ内の情報が、新しい非音声セッション内でＷＡＰゲートウェイ１２０によって用いられる。コンテキストデータを受信するサービスは、ユーザには見えない様態で自動的にコンテキストデータを用い得るか、または、コンテキストデータを用いるか、またはある他のやり方でデータを入力するかのオプションをユーザに提供し得る。一実施例では、コンテキストデータの多数の例が存在し得、ユーザには、もしあれば、どのコ
ンテキストデータをサービスが用いるべきかを選択するオプションが提供され得る。

コンテキストデータがサービスに対する入力として用いられる場合、ユーザは、手作業でデータを入力しなければならないという問題を回避する。モバイルデバイスへのデータ入力は、多くの場合、厄介で退屈であるため、データを再入力する必要性を避けるための、ここで説明される技術は、モバイルデバイスのユーザに大きな利益を提供する。

ハードウェア概要
図２は、この発明の実施例が実現され得るコンピュータシステム２００を例示するブロック図である。コンピュータシステム２００は、バス２０２または情報を通信するための他の通信機構と、バス２０２に結合され情報を処理するためのプロセッサ２０４とを含む。コンピュータシステム２００は、バス２０２に結合されプロセッサ２０４によって実行されるべき命令および情報を記憶するための、ランダムアクセスメモリ（ＲＡＭ）または他の動的記憶装置等のメインメモリ２０６も含む。メインメモリ２０６は、プロセッサ２０４によって実行されるべき命令の実行中に一時変数または他の中間情報を記憶するためにも用いられ得る。コンピュータシステム２００は、バス２０２に結合されプロセッサ２０４のための命令および静的情報を記憶するためのリードオンリメモリ（ＲＯＭ）２０８または他の静的記憶装置をさらに含む。磁気ディスクまたは光ディスク等の記憶装置２１０が、提供され、バス２０２に結合されて情報および命令を記憶する。

コンピュータシステム２００は、情報をコンピュータユーザに対して表示するための陰極線管（ＣＲＴ）等のディスプレイ２１２にバス２０２を介して結合され得る。英数字キーおよび他のキーを含む入力デバイス２１４が、バス２０２に結合され、情報およびコマンド選択をプロセッサ２０４に伝達する。別の種類のユーザ入力デバイスは、方向情報およびコマンド選択をプロセッサ２０４に伝達し、さらにはディスプレイ２１２上でのカーソルの動きを制御するための、マウス、トラックボール、またはカーソル方向キー等のカーソル制御部２１６である。この入力デバイスは、通例、第１の軸（たとえば、ｘ）および第２の軸（たとえば、ｙ）の２つの軸において２自由度を有し、これは、デバイスが平面における位置を特定することを可能にする。

この発明は、デジタルビデオコンテントを生成するためにコンピュータシステム２００を用いることに関する。この発明の一実施例によると、デジタルビデオコンテントは、プロセッサ２０４が、メインメモリ２０６内に含まれる１つ以上の命令の１つ以上のシーケンスを実行したことに応答して、コンピュータシステム２００によって提供される。このような命令は、記憶装置２１０等の別のコンピュータ読出可能な媒体からメインメモリ２０６上に読出され得る。メインメモリ２０６内に含まれる命令シーケンスの実行によって、プロセッサ２０４がここで説明されるプロセスステップを実行することになる。代替的な実施例では、ソフトウェア命令の代わりに、またはそれと組合わせてハードワイヤード回路を用いて、この発明を実現してもよい。したがって、この発明の実施例は、ハードウェア回路およびソフトウェアのいずれかの特定の組合せに限定されるわけではない。

この発明を実施するために必要とされる命令シーケンスの実行は、単一のコンピュータシステム２００によって行なわれる必要はない。この発明を実施するために必要とされる命令シーケンスは、ローカルネットワーク２２２に接続されるか、インターネット２２８に接続されるか、または他の様態で互いにデータ通信状態にある複数のコンピュータシステム２００によって実行され得る。

ここで用いられる用語「コンピュータ読出可能な媒体」は、実行のために命令をプロセッサ２０４に提供することに関与するいずれかの媒体を指す。このような媒体は、不揮発性媒体、揮発性媒体、および伝送媒体を含むが、これらに限定されているわけではない多
くの形をとり得る。不揮発性媒体は、たとえば、記憶装置２１０等の光ディスクまたは磁気ディスクを含む。揮発性媒体は、メインメモリ２０６等のダイナミックメモリを含む。伝送媒体は、バス２０２を含む配線を含んだ、同軸ケーブル、銅線、および光ファイバを含む。伝送媒体は、電波および赤外線データ通信中に生成されるもののような、音波または光波の形もとることができる。

一般的な形のコンピュータ読出可能な媒体は、たとえば、フロッピー（Ｒ）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、または他のいずれかの磁気媒体、ＣＤ−ＲＯＭ、他のいずれかの光学媒体、せん孔カード、紙テープ、孔のパターンを備えた他のいずれかの物理的な媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、他のいずれかのメモリチップまたはカートリッジ、以下で説明されるような搬送波、またはコンピュータが読出すことのできる他のいずれかの媒体を含む。

さまざまな形のコンピュータ読出可能な媒体は、実行のために１つ以上の命令の１つ以上のシーケンスをプロセッサ２０４に提供することに関与し得る。たとえば、命令は、最初、リモートコンピュータの磁気ディスク上で担持され得る。リモートコンピュータは、そのダイナミックメモリに命令をロードし、命令をモデムを用いて電話回線を介して送信し得る。コンピュータシステム２００にとってローカルであるモデムは、電話回線上のデータを受信し、赤外線送信機を用いてデータを赤外線信号に変換し得る。赤外線検出器が、赤外線信号内で運ばれるデータを受信し、適切な回路がデータをバス２０２上に置き得る。バス２０２は、データをメインメモリ２０６へと運び、ここから、プロセッサ２０４が命令を取出し実行する。メインメモリ２０６が受けとる命令は、プロセッサ２０４による実行の前またはその後のいずれかにおいて記憶装置２１０上に任意で記憶され得る。

コンピュータシステム２００は、バス２０２に結合される通信インターフェイス２１８も含む。通信インターフェイス２１８は、ローカルネットワーク２２２に接続されるネットワークリンク２２０に結合される双方向データ通信を提供する。たとえば、通信インターフェイス２１８は、統合サービスデジタル網（ＩＳＤＮ）カードまたはモデムであって、対応の種類の電話回線に対するデータ通信接続を提供し得る。別の例として、通信インターフェイス２１８は、ローカルエリアネットワーク（ＬＡＮ）カードであって、互換性のあるＬＡＮに対するデータ通信接続を提供し得る。ワイヤレスリンクも実現され得る。このようないずれの実現例でも、通信インターフェイス２１８は、さまざまな種類の情報を表わすデジタルデータストリームを運ぶ電気信号、電磁信号、または光信号を送受信する。

ネットワークリンク２２０は、通例、１つ以上のネットワークを通して他のデータデバイスへとデータ通信を提供する。たとえば、ネットワークリンク２２０は、ローカルネットワーク２２２を通して、ホストコンピュータ２２４に、またはインターネットサービスプロバイダ（ＩＳＰ）２２６によって操作されるデータ装置に接続を提供し得る。ＩＳＰ２２６は、現在「インターネット」１１２８と一般に称されるワールドワイドパケットデータ通信ネットワークを通してデータ通信サービスを提供する。ローカルネットワーク２２２およびインターネット２２８は、両方とも、デジタルデータストリームを運ぶ電気信号、電磁信号、または光信号を用いる。さまざまなネットワークを通る信号と、コンピュータシステム２００にデジタルデータを運び、さらにはコンピュータシステム２００からデジタルデータを運ぶ、ネットワークリンク２２０上の、かつ通信インターフェイス２１８を通る信号とは、情報を運ぶ搬送波の例示的な形である。

コンピュータシステム２００は、ネットワーク、ネットワークリンク２２０、および通信インターフェイス２１８を通して、プログラムコードを含むメッセージを送信し、データを受信し得る。インターネットの例では、サーバ２３０は、インターネット２２８、Ｉ
ＳＰ２２６、ローカルネットワーク２２２、および通信インターフェイス２１８を通して、アプリケーションプログラムに対するリクエストされたプログラムコードを送信し得る。

プロセッサ２０４は、受信されたコードをそれが受信されたときに実行してもよく、および／または、後の実行のために記憶装置２１０または他の不揮発性記憶装置に記憶してもよい。この様態で、コンピュータシステム２００は、搬送波の形でアプリケーションコードを得てもよい。

上述の明細書では、この発明は、その具体的な実施例を参照しながら説明されてきた。しかしながら、この発明のより広い思想および範囲から逸脱することなく、それに対してさまざまな変形および変更が作成され得ることは明らかであろう。したがって、明細書および図面は、限定的な意味ではなく、例示的な意味でみなされるべきである。

この発明の一実施例が実現され得るシステム１００の機能ブロック図である。 この発明の実施例が実現され得るコンピュータシステム２００を例示するブロック図である。

Claims (31)

1. 単一の通信デバイス内で音声セッションと非音声セッションとの間で情報を共有するための方法であって、
   第１のタイプのセッションである第１のセッション内で通信するユーザのためのコンテキストデータを記憶するステップを含み、前記第１のタイプのセッションは、音声セッションおよび非音声セッションのうちの一方であり、前記方法はさらに、
   前記ユーザからリクエストを受信して第２のタイプのセッション上での通信を開始するステップを含み、前記第２のタイプのセッションは、前記第１のタイプのセッションとは異なる、音声セッションおよび非音声セッションのうちの他方であり、前記方法はさらに、
   前記コンテキストデータを取出すステップと、
   前記コンテキストデータからの情報を前記第２のタイプのセッション内で課された(assessed)サービスに提供するステップとを含み、
   前記コンテキストデータは、前記第１のセッションのコンテキストを反映する、方法。
2. 前記第２のタイプのセッションに対するリクエストを受信すると、前記リクエストを行った特定の通信デバイスを識別し、前記ユーザに関連する識別子に関連づけてその情報を記憶するステップと、
   前記特定の通信デバイスについての何らかの記憶されたコンテキストデータが存在するかを判断するステップとをさらに含む、請求項１に記載の方法。
3. 前記特定の通信デバイスを識別するステップは、ＷＡＰゲートウェイまたは音声ノードサーバによって実行される、請求項２に記載の方法。
4. 前記コンテキストデータは、ウェブサーバ上に記憶される、請求項２または３に記載の方法。
5. 前記何らかの記憶されたコンテキストデータが存在するかを判断するステップは、前記
   ウェブサーバと交信するステップを含む、請求項４に記載の方法。
6. 前記コンテキストデータを前記ウェブサーバから前記ＷＡＰゲートウェイへ送信するステップをさらに含む、請求項４または５に記載の方法。
7. コンテキストデータを記憶する前記ステップは、前記第１のタイプのセッションから前記第２のタイプのセッションへの切換に応答して実行される、請求項１〜６のいずれか１項に記載の方法。
8. 前記第１のタイプのセッションは、音声セッションであり、前記第２のタイプのセッションは、非音声セッションである、請求項１〜７のいずれか１項に記載の方法。
9. 前記第１のタイプのセッションは、非音声セッションであり、前記第２のタイプのセッションは、音声セッションである、請求項１〜７のいずれか１項に記載の方法。
10. コンテキストデータを記憶する前記ステップは、前記ユーザに関連する識別子に関連づけてコンテキストデータを記憶するステップを含み、
    前記コンテキストデータを取出す前記ステップは、前記ユーザに関連する前記識別子に基づいて前記コンテキストデータを取出すステップを含む、請求項１〜９のいずれか１項に記載の方法。
11. 前記識別子は、前記第２のタイプのセッションをリクエストするために前記ユーザによって用いられるデバイスの電話番号に関連する、請求項２または１０に記載の方法。
12. ユーザのためのコンテキストデータを記憶する前記ステップは、クッキーを用いることによって実行される、請求項１〜１１のいずれか１項に記載の方法。
13. 前記ユーザからリクエストを受信して前記第２のタイプのセッションから前記第１のタイプのセッションに切換え直すステップと、
    前記第１のタイプのセッションに切換え直した後、以下のステップを実行するステップとをさらに含み、前記以下のステップは、
    前記コンテキストデータを取出すステップと、
    前記コンテキストデータからの情報を前記第１のタイプのセッション内で課されたサービスに提供するステップとを含む、請求項１〜１２のいずれか１項に記載の方法。
14. コンテキストデータを記憶する前記ステップは、定期的な間隔で実行される、請求項１〜１３のいずれか１項に記載の方法。
15. コンテキストデータを記憶する前記ステップは、前記第１のタイプのセッション内の新しいアクティビティに応答して実行される、請求項１〜１４のいずれか１項に記載の方法。
16. コンテキストデータを記憶する前記ステップは、前記音声セッション内の参加者が前記音声セッションに関連するデータを入力したことに応答して実行される、請求項１〜１４のいずれか１項に記載の方法。
17. 単一の通信デバイス内で音声セッションと非音声セッションとの間で情報を共有するための命令を担持するコンピュータ読出可能な媒体であって、前記命令は、以下のステップを実行するための命令を含み、前記以下のステップは、
    第１のタイプのセッションである第１のセッション内で通信しているユーザのためのコ
    ンテキストデータを記憶するステップを含み、前記第１のタイプのセッションは、音声セッションおよび非音声セッションのうちの一方であり、前記以下のステップはさらに、
    前記ユーザからリクエストを受信して第２のタイプのセッション上での通信を開始するステップを含み、前記第２のタイプのセッションは、前記第１のタイプのセッションとは異なる、音声セッションおよび非音声セッションのうちの他方であり、前記以下のステップはさらに、
    前記コンテキストデータを取出すステップと、
    前記コンテキストデータからの情報を前記第２のタイプのセッション内で課されたサービスに提供するステップとを含み、
    前記コンテキストデータは、前記第１のセッションのコンテキストを反映する、コンピュータ読出可能な媒体。
18. 前記命令は、
    前記第２のタイプのセッションに対するリクエストを受信すると、前記リクエストを行った特定の通信デバイスを識別し、前記ユーザに関連する識別子に関連づけてその情報を記憶するステップと、
    前記特定の通信デバイスについての何らかの記憶されたコンテキストデータが存在するかを判断するステップとを実行するための命令をさらに含む、請求項１７に記載のコンピュータ読出可能な媒体。
19. 前記コンテキストデータは、ウェブサーバ上に記憶される、請求項１７または１８に記載のコンピュータ読出可能な媒体。
20. 前記何らかの記憶されたコンテキストデータが存在するかを判断するステップは、前記ウェブサーバと交信するステップを含む、請求項１９に記載の方法。
21. 前記コンテキストデータを前記ウェブサーバからＷＡＰゲートウェイへ送信するステップをさらに含む、請求項１９または２０に記載の方法。
22. コンテキストデータを記憶する前記ステップは、前記第１のタイプのセッションから前記第２のタイプのセッションへの切換に応答して実行される、請求項１７〜２１のいずれか１項に記載のコンピュータ読出可能な媒体。
23. 前記第１のタイプのセッションは、音声セッションであり、前記第２のタイプのセッションは、非音声セッションである、請求項１７〜２２のいずれか１項に記載のコンピュータ読出可能な媒体。
24. 前記第１のタイプのセッションは、非音声セッションであり、前記第２のタイプのセッションは、音声セッションである、請求項１７〜２２のいずれか１項に記載のコンピュータ読出可能な媒体。
25. コンテキストデータを記憶する前記ステップは、前記ユーザに関連する識別子に関連づけてコンテキストデータを記憶するステップを含み、
    前記コンテキストデータを取出す前記ステップは、前記ユーザに関連する前記識別子に基づいて前記コンテキストデータを取出すステップを含む、請求項１７〜２４のいずれか１項に記載のコンピュータ読出可能な媒体。
26. 前記識別子は、前記第２のタイプのセッションをリクエストするために前記ユーザによって用いられるデバイスの電話番号に関連する、請求項１７〜２５のいずれか１項に記載のコンピュータ読出可能な媒体。
27. ユーザのためのコンテキストデータを記憶する前記ステップは、クッキーを用いることによって実行される、請求項１７〜２６のいずれか１項に記載のコンピュータ読出可能な媒体。
28. 前記ユーザからリクエストを受信して前記第２のタイプのセッションから前記第１のタイプのセッションに切換え直すステップと、
    前記第１のタイプのセッションに切換え直した後、
    前記コンテキストデータを取出すステップと、
    前記コンテキストデータからの情報を前記第１のタイプのセッション内で課されたサービスに提供するステップとを実行するステップとを行うための命令をさらに含む、請求項１７〜２７のいずれか１項に記載のコンピュータ読出可能な媒体。
29. コンテキストデータを記憶する前記ステップは、定期的な間隔で実行される、請求項１７〜２８のいずれか１項に記載のコンピュータ読出可能な媒体。
30. コンテキストデータを記憶する前記ステップは、前記第１のタイプのセッション内の新しいアクティビティに応答して実行される、請求項１７〜２９のいずれか１項に記載のコンピュータ読出可能な媒体。
31. コンテキストデータを記憶する前記ステップは、前記音声セッション内の参加者が前記音声セッションに関連するデータを入力したことに応答して実行される、請求項１７〜３０のいずれか１項に記載のコンピュータ読出可能な媒体。

Images