JP4689500B2 - 情報処理装置 - Google Patents

Description

本発明は、ネットワークを介して通信相手と音声データ、映像データなどを送受信する技術に関し、特に、データの種類が変更されることを検知して、そのデータの種類に対応した処理を行なう情報処理装置に関する。

近年、インターネットをはじめとする通信環境が広く普及し、情報処理装置に通信機能を備えるものが増加しており、このような情報処理装置がオフィス、家庭などで利用されている。また、通信環境においては、ブロードバンド化が進んでおり、それに応じて音声データ、映像データなどを送受信するマルチメディア通信機能を有する情報処理装置やアプリケーションが増加している。

また、コミュニケーション手段として用いられていた電話においても、ＶｏＩＰ（Voice over Internet Protocol）技術を用いたＩＰ化が進められており、音声に加えて映像もあわせて送受信するテレビ電話やテレビ会議などのビデオコミュニケーションも実現されてきている。

このようなコミュニケーションのＩＰ化に伴い、ＶｏＩＰをはじめとするメディアコミュニケーションを実現する技術として、インターネット標準においては、ＳＩＰ（Session Initiation Protocol）やＲＴＰ（Real-time Transport Protocol）などのプロトコルが規定されている。また、メディアデータを圧縮して送受信するために、ＭＰＥＧ（Moving Picture Experts Group）２やＭＰＥＧ４などに代表される多くのコーデックが規定されて利用されている。これらの技術を用いることによって、コミュニケーションの開始、変更、切断や、コンテンツの送受信などの基本的な機能が実現されている。

一方、このようなメディアコミュニケーションを実現した場合に、さまざまな問題点が見出させている。その１つとして、通信中に符号化方式を切替えるときに、切替えのタイミングで異音が発生したり、映像が乱れたり、途切れたりする問題が指摘されている。下記の特許文献１は、このような問題点を解決するためのものである。

特許文献１においては、通信相手との通信中に符号化方式を第１の符号化方式から第２の符号化方式に切替える場合、パケット通信装置（送信側）は、通信相手の準備が完了するまで、第１の符号化方式で符号化された音声および／または映像信号を送信する。そして、パケット通信装置（受信側）は、第２の符号化方式に対応する第２の復号化方式の復号化処理が安定した後、第２の復号化方式で復号化された音声および／または映像信号を出力する。
特開２００２−２４７１３７号公報

しかしながら、上述した特許文献１においては、通信中に符号化方式を切替えるときに、切替えのタイミングで異音が発生したり、映像が乱れたり、途切れたりすることを防止することができるが、送信するデータの種類が途中で変更される場合、その変更を受信側で検知できないため、それに対応することができない。

たとえば、通常テレビ電話では、通話者が互いにカメラで撮影した映像、マイクで集音した音声をリアルタイムで送受信するが、その最中に一方の通話者が相手に以前録画しておいた映像を見せたいと思った場合、使用するコーデックはそのままで、カメラで撮影した映像の代わりに録画映像をエンコードして相手に送信することにより、相手にその録画画像を送信することができる。これは、ＡＶ（Audio Visual）セレクタなどを用いて送信する映像ソースの入力を切替えることによって可能である。

そのとき、送信側の装置においては、ユーザがソースを指定して切替えを指示するので、それをトリガにテレビ電話の映像から録画映像に切替わったことを認識できる。しかしながら、受信側の装置においては、送信元でソースが切替えられたとしても、どのタイミングでどのようなコンテンツに切替わったかを認識することができないといった問題点があった。

また、エンコードに利用するコーデックを変更する場合、たとえばテレビ電話における通話者の画像を相手に送信する代わりに、コンテンツなどの映像を相手に送信する際、カメラでの自身の映像よりも高画質な映像を相手に見せたい場合には、高画質のコーデックに変更することを呼制御のシグナリングで再ネゴシエーションする必要があるが、それはあくまで受信側でデコードを可能にするためであり、送信されるコンテンツや映像入力デバイスが変わったという情報の通知までは行なわれない。したがって、受信側ではコーデックが変更されたので、送信コンテンツが変更されたのか、その他の要因、たとえば通信帯域状態や装置の処理能力などの条件の変化によって変更されたのかを認識することができないといった問題点があった。

本発明は、上記問題点を解決するためになされたものであり、第１の目的は、相手の情報処理装置と接続中にコミュニケーションデータを変更する場合に、どのようなタイミングで、どのようなデータに変更されるかを通知することが可能な情報処理装置を提供することである。

第２の目的は、相手の情報処理装置と接続中にコミュニケーションデータが変更される場合に、どのようなタイミングで、どのようなデータに変更されるかの通知を受信して、画面構成などを変更することが可能な情報処理装置を提供することである。

本発明のある局面に従えば、情報処理装置は、外部装置との間でデータの送受信を行なう通信手段と、ユーザからの入力ソースの切替え指示を入力するインタフェース手段と、インタフェース手段によって入力された入力ソースの切替え指示に応じて、入力ソースを切替えてデータを入力して通信手段を介して外部装置に送信し、入力データの種類または入力データの種類の組合わせを識別するための識別情報を通信手段を介して外部装置に送信する制御手段とを含む。

好ましくは、制御手段は、入力装置を選択して入力ソースを切替えてデータを入力する入力制御手段と、外部装置とのメディア通信を制御するシグナリングによって、入力データの種類または識別情報を通信手段を介して送信するシグナリング手段とを含む。

さらに好ましくは、シグナリング手段は、セッション・ディスクリプション・プロトコルによって記述された入力データの種類または識別情報を外部装置に送信する。

好ましくは、制御手段はさらに、入力制御手段によって切替えられたデータに応じてエンコーダを選択してコーデック処理を行なわせるエンコード手段を含み、シグナリング手段は、コーデック処理に関する情報を外部装置に送信する。

好ましくは、シグナリング手段は、入力制御手段によって切替えられたデータに応じて出力形態を指定する情報を外部装置に送信する。

好ましくは、制御手段は、入力装置を選択して入力ソースを切替えてデータを入力する入力制御手段と、入力制御手段によって入力されたデータおよび入力データの種類または識別情報を通信手段を介して外部装置に送信するデータ送信手段とを含む。

さらに好ましくは、データ送信手段は、リアルタイム・トランスポート・プロトコルパケットのペイロードタイプを用いて、入力データの種類または識別情報を外部装置に送信する。

本発明の別の局面に従えば、情報処理装置は、外部装置との間でデータの送受信を行なう通信手段と、通信手段を介して外部装置から受信したデータの種類または受信データの種類の組合わせを識別するための識別情報を抽出し、受信データの種類または識別情報に応じて受信データの出力を制御する制御手段とを含む。

好ましくは、制御手段は、外部装置とのメディア通信を制御するシグナリングによって、受信データの種類または識別情報を受信するシグナリング手段と、受信データの種類または識別情報に応じて受信データの出力を制御する出力制御手段とを含む。

さらに好ましくは、シグナリング手段は、セッション・ディスクリプション・プロトコルによって記述された受信データの種類または識別情報を受信する。

好ましくは、制御手段はさらに、シグナリング手段によって受信されたコーデック処理に関する情報に応じてデコーダを選択してコーデック処理を行なわせるデコード手段を含み、出力制御手段は、デコード手段によってデコードされたデータの出力を制御する。

好ましくは、出力制御手段は、シグナリング手段によって受信された出力形態を指定する情報に応じて、出力装置の出力形態を変更してデータを出力させる。

好ましくは、制御手段は、通信手段を介して受信データおよび受信データの種類または識別情報を受信するデータ受信手段と、受信データの種類または識別情報に応じて受信データの出力を制御する出力制御手段とを含む。

さらに好ましくは、データ受信手段は、ペイロードタイプを用いて受信データの種類または識別情報を指定したリアルタイム・トランスポート・ストリームパケットを受信する。

本発明のある局面によれば、制御手段が、インタフェース手段によって入力された入力ソースの切替え指示に応じて、入力ソースを切替えてデータを入力して通信手段を介して外部装置に送信し、入力データの種類または入力データの種類の組合わせを識別するための識別情報を通信手段を介して外部装置に送信するので、外部装置に対してどのようなタイミングで、どのようなデータに変更されるかを通知することが可能となる。

また、シグナリング手段が、外部装置とのメディア通信を制御するシグナリングによって、入力データの種類または識別情報を通信手段を介して送信するので、確実に外部装置にデータの変更などを通知することが可能となる。

また、シグナリング手段が、セッション・ディスクリプション・プロトコルによって記述された入力データの種類または識別情報を外部装置に送信するので、既存のプロトコルを用いて外部装置にデータの変更などを通知することが可能となる。

また、シグナリング手段が、コーデック処理に関する情報を外部装置に送信するので、外部装置はどのようなコーデック処理を用いてデータをデコードすればよいかを認識することが可能となる。

また、シグナリング手段が、入力制御手段によって切替えられたデータに応じて出力形態を指定する情報を外部装置に送信するので、それに応じて外部装置は出力形態を変更することが可能となる。

また、データ送信手段が、入力制御手段によって入力されたデータおよび入力データの種類または識別情報を通信手段を介して外部装置に送信するので、容易に外部装置にデータの変更などを通知することが可能となる。

また、データ送信手段が、リアルタイム・トランスポート・プロトコルパケットのペイロードタイプを用いて、入力データの種類または識別情報を外部装置に送信するので、特別なシグナリングを用いずに外部装置にデータの変更などを通知することが可能となる。

本発明の別の局面によれば、制御手段が、通信手段を介して外部装置から受信したデータの種類または受信データの種類の組合わせを識別するための識別情報を抽出し、受信データの種類または識別情報に応じて受信データの出力を制御するので、データの変更などを容易に認識でき、それに応じた出力形態に変更することが可能となる。

また、シグナリング手段が、外部装置とのメディア通信を制御するシグナリングによって、受信データの種類または識別情報を受信するので、確実にデータの変更などの通知を受信することが可能となる。

また、シグナリング手段が、セッション・ディスクリプション・プロトコルによって記述された受信データの種類または識別情報を受信するので、既存のプロトコルを用いてデータの変更などの通知を受信することが可能となる。

また、コーデック手段が、シグナリング手段によって受信されたコーデック処理に関する情報に応じてデコーダを選択してコーデック処理を行なわせるので、デコーダの選択を容易に行なうことが可能となる。

また、出力制御手段が、シグナリング手段によって受信された出力形態を指定する情報に応じて、出力装置の出力形態を変更してデータを出力させるので、受信データに適した出力形態でデータを出力することが可能となる。

また、データ受信手段が、通信手段を介して受信データおよび受信データの種類または識別情報を受信するので、容易にデータの変更などの通知を受信することが可能となる。

また、データ受信手段が、ペイロードタイプを用いて受信データの種類または識別情報を指定したリアルタイム・トランスポート・ストリームパケットを受信するので、特別なシグナリングを用いずにデータの変更などの通知を受信することが可能となる。

（第１の実施の形態）
図１は、本発明の第１の実施の形態における情報処理装置の外観例を示す図である。この情報処理装置は、コンピュータ本体１と、ディスプレイ２と、音声などを出力するスピーカ３と、通話者の音声などを集音するマイク４と、通話者の映像などを撮影するカメラ５と、リモコン１０との間で赤外線によって通信を行なう赤外線ポート６と、外部から音声信号や映像信号が入力される外部ＡＶ入力端子７とを含む。

リモコン１０は、数字キー１０１と、発信キー１０２と、切断キー１０３と、十字キー１０４と、決定キー１０５とを含む。

図２は、本発明の第１の実施の形態における情報処理装置のハードウェア構成を示すブロック図である。この情報処理装置は、ディスプレイ２と、スピーカ３と、マイク４と、カメラ５と、赤外線ポート６と、音声外部入力端子７−１と、映像外部入力端子７−２と、音声外部出力端子８−１と、映像外部出力端子８−２と、図示しない外部スピーカを接続するための外部スピーカ端子９と、ＣＰＵ（Central Processing Unit）１１と、ＲＯＭ（Read Only Memory）１２と、ＲＡＭ（Random Access Memory）１３と、ＡＶセレクタ１４と、ネットワークデバイス１５と、ＴＶ放送波を受信するＴＶチューナ１６と、ｍｐｅｇ４デコーダ１７と、ｍｐｅｇ４エンコーダ１８と、ｍｐｅｇ２デコーダ１９と、ｍｐｅｇ２エンコーダ２０とを含む。

情報処理装置全体の制御を行なうためのプログラムはＲＯＭ１２に格納され、ＣＰＵ１１がＲＯＭ１２に格納されたプログラムをＲＡＭ１３に展開して実行する。また、ＲＡＭ１３は、音声データ、映像データなどを一時的に保持するのにも使用される。

ＡＶセレクタ１４は、ディスプレイ２、スピーカ３、マイク４、カメラ５、赤外線ポート６、音声外部入力端子７−１、映像外部入力端子７−２、音声外部出力端子８−１、映像外部出力端子８−２、外部スピーカ端子９、ＴＶチューナ１６、ｍｐｅｇ４デコーダ１７、ｍｐｅｇ４エンコーダ１８、ｍｐｅｇ２デコーダ１９、およびｍｐｅｇ２エンコーダ２０に接続され、音声や映像の入出力デバイスの切替えやミキシングを行なう。

ネットワークデバイス１５は、インターネットなどのネットワークに接続され、相手の情報処理装置との間で音声データ、映像データなどの送受信を行なう。

図３は、本発明の第１の実施の形態における情報処理装置の機能的構成を示すブロック図である。図３においては、点線で囲まれた部分がハードウェアによって構成され、実線で囲まれた部分がソフトウェアによって構成される。

入力装置２１は、図２に示すマイク４、カメラ５、赤外線ポート６、音声外部入力端子７−１、映像外部入力端子７−２、ＴＶチューナ１６などに相当する。また、出力装置２２は、図２に示すディスプレイ２、スピーカ３、音声外部出力端子８−１、映像外部出力端子８−２、外部スピーカ端子９などに相当する。

エンコーダ２４は、ｍｐｅｇ４エンコーダ１８およびｍｐｅｇ２エンコーダ２０に相当する。また、デコーダ２５は、ｍｐｅｇ４デコーダ１７およびｍｐｅｇ２デコーダ１９に相当する。また、通信装置２３は、ネットワークデバイス１５に相当する。

ソフトウェアによって実現される機能は、ＧＵＩ（Graphical User Interface）部３１と、コミュニケーション管理部３２と、入力制御部３３と、出力制御部３４と、エンコード部３５と、デコード部３６と、データ送信部３７と、シグナリング部３８と、データ受信部３９と、通信部４０とを含む。

ＧＵＩ部３１は、本実施の形態における情報処理装置のグラフィカルユーザインタフェースの機能を実現する。たとえば、ＧＵＩ部３１は、赤外線ポート６を介してリモコン１０から入力信号を受け、ディスプレイ２上の表示に応じてアプリケーションの操作などを可能にする。また、コミュニケーション管理部３２からの指示に応じて、画面構成を制御することによって、出力制御部３４が表示する映像と連携した画面表示を可能にする。

また、ＧＵＩ部３１は、ユーザからリモコン１０などによって送信するデータのソースを変更する指示があれば、それをコミュニケーション管理部３２に通知する。

コミュニケーション管理部３２は、ユーザの操作に基づくＧＵＩ部３１からの通知や、シグナリング部３８からのシグナル受信の情報を管理する。コミュニケーション管理部３２は、これらの情報に基づいて入力制御部３３を制御して、指定された入力装置２１からの音声や映像などのデータをエンコード部３５にエンコードさせ、エンコードされたデータをデータ送信部３７に送信させる。

また、コミュニケーション管理部３２は、データ受信部３９によって受信された相手の情報処理装置からのデータをデコード部３６にデコードさせる。そして、出力制御部３４を制御して、デコード後のデータを適切な出力装置２２に出力させる。

また、コミュニケーション管理部３２は、ＧＵＩ部３１から接続変更を示す通知を受けると、シグナリング部３８にＳＩＰシグナルを送信させる。コミュニケーション管理部３２は、シグナリング部３８にＳＩＰシグナルを送信させる際に、送信するコミュニケーションデータのソース情報を一緒に通知する。また、シグナリング部３８が相手の情報処理装置からコミュニケーションデータのソース情報を受信し、接続変更のネゴシエーションが完了すると、コミュニケーション管理部３２は、その接続変更に応じて入力制御部３３および出力制御部３４を制御して、入力装置２１および出力装置２２を変更したり、ＧＵＩ部３１を用いて画面構成を変更したりする。

入力制御部３３は、コミュニケーション管理部３２からの指示に応じて、指定された入力装置２１からのデータをエンコード部３５に出力する。

エンコード部３５は、コミュニケーション管理部３２からの指示に応じて、指定されたエンコーダ２４を用いてデータをエンコードし、エンコードデータをデータ送信部３７に出力する。

データ送信部３７は、エンコード部３５から受けたエンコードデータをＲＴＰパケット化し、コミュニケーション管理部３２によって指定された宛先に送信するよう通信部４０に指示する。

通信部４０は、データ送信部３７から受けたＲＴＰパケットからＩＰパケットを生成し、通信装置２３を介して送信する。また、通信部４０は、通信装置２３を介して受信したデータパケットをシグナリング部３８またはデータ受信部３９に出力する。受信したデータパケットをいずれに出力するかは、コミュニケーション管理部３２からの指示による。

データ受信部３９は、通信部４０から受けたデータパケットからデータを抽出し、デコード部３６に出力する。

デコード部３６は、コミュニケーション管理部３２によって指定されたデコーダ２５を用いてデータのデコードを行ない、デコードによって得られた信号を出力制御部３４に出力する。

出力制御部３４は、コミュニケーション管理部３２からの指示に応じて、出力装置２２を選択し、ＧＵＩ部３１と協働してデコード部３６から受けた信号を選択した出力装置２２に出力する。

シグナリング部３８は、コミュニケーション管理部３２からの指示に応じて、相手の情報処理装置に対して通信の開始、変更、終了の要求を行ない、相手の情報処理装置からの要求に対する応答を行なう。また、通信部４０によって受信されたＳＩＰシグナルのパケットデータを解釈し、その情報をコミュニケーション管理部３２に通知する。

後述するように、シグナリング部３８は、コミュニケーション管理部３２からの接続変更のＳＩＰシグナルを送信する指示を受けると、ＳＩＰシグナルのメッセージボディにａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅ行を挿入してソース情報を付加する。逆に、相手の情報処理装置からＳＩＰシグナルを受信すると、各メディアについて付記されたａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅ行の情報を抽出してコミュニケーション管理部３２に通知する。

図４は、本発明の第１の実施の形態における情報処理装置のシグナリングによる送信メディア変更を説明するためのシーケンス図である。まず、端末Ａが端末Ｂに対してＩＮＶＩＴＥリクエストを送信すると（Ｔ１）、端末ＢはＩＮＶＩＴＥのメッセージボディに含まれるメディア情報によってＴＶ電話着信であることを認識し、２００ ＯＫ応答を端末Ａに送信する（Ｔ２）。これによって、カメラ５によって撮影された映像と、マイク４によって集音された音声との送受信が開始される（通信状態１）。

次に、端末Ａが端末Ｂに対してｒｅ−ＩＮＶＩＴＥリクエストを送信すると（Ｔ３）、端末Ｂはｒｅ−ＩＮＶＩＴＥのメッセージボディに含まれるメディア情報によってコミュニケーションの変更を認識し、新しいデータに合わせて処理を切替え、２００ ＯＫ応答を端末Ａに送信する（Ｔ４）。これによって、端末Ａからは、映像外部入力端子７−２などから入力される録画映像（以下、外部入力映像と呼ぶ。）と、マイク４によって集音された音声との送信が開始される（通信状態２）。

次に、端末Ａが端末Ｂに対してｒｅ−ＩＮＶＩＴＥリクエストを送信すると（Ｔ５）、端末Ｂはｒｅ−ＩＮＶＩＴＥのメッセージボディに含まれるメディア情報によってＴＶ電話着信であることを認識し、２００ ＯＫ応答を端末Ａに送信する（Ｔ６）。これによって、ＴＶ電話としての送受信が再開される（通信状態３）。

図５は、本発明の第１の実施の形態における情報処理装置の全体的な処理手順を説明するためのフローチャートである。情報処理装置が起動されると、まず、コミュニケーション管理部３２は待ち受け状態に遷移し（Ｓ１１）、ＧＵＩ部３１に対してディスプレイ２に待ち受け画面の表示を指示する（Ｓ１２）。

次に、コミュニケーション管理部３２は、イベントを受信したか否かを判定する（Ｓ１３）。このイベントには、シグナリング部３８からのシグナル情報に関するイベントと、ＧＵＩ部３１からのユーザ操作によるイベントとがある。コミュニケーション管理部３２がイベントを受信していなければ（Ｓ１３，Ｎｏ）、イベントを受信するまで待機する。また、コミュニケーション管理部３２がイベントを受信すると（Ｓ１３，Ｙｅｓ）、そのイベントが要求受信イベントであるか否かを判定する（Ｓ１４）。

イベントが要求受信イベントであれば（Ｓ１４，Ｙｅｓ）、後述するような要求受信処理を行ない（Ｓ１５）、ステップＳ１３に戻って以降の処理を繰返す。この要求受信イベントは、シグナリング部３８がＳＩＰシグナルを受信したときに発生する。

イベントが要求受信イベントでなければ（Ｓ１４，Ｎｏ）、そのイベントが要求送信イベントであるか否かを判定する（Ｓ１６）。イベントが要求送信イベントであれば（Ｓ１６，Ｙｅｓ）、後述するような要求送信処理を行ない（Ｓ１７）、ステップＳ１３に戻って以降の処理を繰返す。この要求送信イベントは、ＧＵＩ部３１がユーザ操作を検出したときに発生する。

イベントが要求送信イベントでなければ（Ｓ１６，Ｎｏ）、そのイベントが応答受信イベントであるか否かを判定する（Ｓ１８）。イベントが応答受信イベントであれば（Ｓ１８，Ｙｅｓ）、後述するような応答受信処理を行ない（Ｓ１９）、ステップＳ１３に戻って以降の処理を繰返す。この応答受信イベントは、シグナリング部３８がＳＩＰシグナルを受信したときに発生する。

イベントが応答受信イベントでなければ（Ｓ１８，Ｎｏ）、そのイベントが応答送信イベントであるか否かを判定する（Ｓ２０）。イベントが応答送信イベントであれば（Ｓ２０，Ｙｅｓ）、後述するような応答送信処理を行ない（Ｓ２１）、ステップＳ１３に戻って以降の処理を繰返す。この応答送信イベントは、ＧＵＩ部３１がユーザ操作を検出したときに発生する。

イベントが応答送信イベントでなければ（Ｓ２０，Ｎｏ）、そのイベントが終了イベントであるか否かを判定する（Ｓ２２）。イベントが終了イベントであれば（Ｓ２２，Ｙｅｓ）、コミュニケーション管理部３２は全体の処理を終了する。この終了イベントは、たとえば、ユーザがリモコン１０の電源ボタンを長押ししたことをＧＵＩ部３１が検出したときに発生する。また、終了イベントでなければ（Ｓ２２，Ｎｏ）、ステップＳ１３に戻って以降の処理を繰返す。

図６は、本発明の第１の実施の形態における情報処理装置によって管理される状態遷移を説明するための図である。後述するように、要求受信処理には、変更受付中の状態（Ｔ１６）と、着信接続中の状態（Ｔ１３）とが含まれる。また、要求送信処理には、変更要求中の状態（Ｔ１５）と、発信接続中の状態（Ｔ１２）とが含まれる。また、応答受信処理および応答送信処理には、接続通信中の状態（Ｔ１４）が含まれる。

図６に示す状態遷移図においては、たとえば、待ち受け状態（Ｔ１１）から発信接続中状態（Ｔ１２）または着信接続中状態（Ｔ１３）に遷移することはあるが、接続通信中状態（Ｔ１４）、変更要求中状態（Ｔ１５）および変更受付中状態（Ｔ１６）に遷移することはないことを示している。

図７は、図５に示す要求受信処理（Ｓ１５）の処理手順を説明するためのフローチャートである。要求受信イベントは、ＳＩＰシグナルのうちリクエストメッセージを受信したときに発生するイベントであるので、リクエストメッセージの処理がこの要求受信処理に相当する。

まず、コミュニケーション管理部３２は、状態確認を行なう（Ｓ３１）。この状態確認とは、受け取ったイベントと現在の状態とを確認するものである。現在の状態ではシーケンス上受け取るはずがないイベントを受け取った場合（Ｓ３２，Ｎｏ）、シグナリング部３８にエラー応答を送信するよう指示する。そして、シグナリング部３８は、エラー応答を作成し、通信部４０を介して相手の情報処理装置にエラー応答を送信する（Ｓ４７）。

図８は、コミュニケーション管理部３２によって参照される状態確認表の一例を示す図である。図８に示す状態確認表においては、待ち受け状態のときに、接続要求送信、接続要求受信、接続応答送信および接続応答受信のイベントを受け取ることがあるが、その他のイベントを受け取ることがないことを示している。なお、図８に示す各イベントは、図７および図９〜１１に示すフローチャートの説明によって明らかになるであろう。

状態確認が済めば（Ｓ３２，Ｙｅｓ）、コミュニケーション管理部３２は、要求受信イベントが変更要求（変更要求受信イベント）であるか否かを判定する（Ｓ３３）。変更要求受信イベントであれば（Ｓ３３，Ｙｅｓ）、変更受付中状態に遷移し（Ｓ３４）、シグナリング部３８によって受信されたＳＩＰシグナル中のＳＤＰ（Session Description Protocol）で記述されたメッセージボディの変更情報を抽出する（Ｓ３５）。そして、コミュニケーション管理部３２は、変更受付中画面を表示するようＧＵＩ部３１に指示し（Ｓ３６）、変更が完了するまで変更要求前のコミュニケーションデータの送信を一旦停止させて（Ｓ３７）、処理を終了する。

変更要求受信イベントでなければ（Ｓ３３，Ｎｏ）、コミュニケーション管理部３２は、要求受信イベントが接続要求（接続要求受信イベント）であるか否かを判定する（Ｓ３８）。接続要求受信イベントであれば（Ｓ３８，Ｙｅｓ）、着信接続中状態に遷移し（Ｓ３９）、シグナリング部３８によって受信されたＳＩＰシグナル中のＳＤＰで記述されたメッセージボディの着信情報を抽出する（Ｓ４０）。そして、コミュニケーション管理部３２は、着信接続中画面を表示するようＧＵＩ部３１に指示し（Ｓ４１）、処理を終了する。

接続要求受信イベントでなければ（Ｓ３８，Ｎｏ）、コミュニケーション管理部３２は、要求受信イベントが切断要求（切断要求受信イベント）であるか否かを判定する（Ｓ４２）。切断要求受信イベントであれば（Ｓ４２，Ｙｅｓ）、データ送信部３７およびデータ受信部３９を制御してデータの送受信を終了し（Ｓ４４）、シグナリング部３８に切断要求に対する２００ ＯＫ応答を送信させる（Ｓ４４）。そして、コミュニケーション管理部３２は、初期画面である待ち受け画面を表示するようＧＵＩ部３１に指示し（Ｓ４５）、待ち受け状態に遷移して（Ｓ４６）、処理を終了する。

図９は、図５に示す要求送信処理（Ｓ１７）の処理手順を説明するためのフローチャートである。要求送信イベントは、ＧＵＩ部３１がユーザ操作を検出したときに発生するイベントであり、コミュニケーションを開始する場合、変更する場合、および切断する場合の処理に関連する。

まず、コミュニケーション管理部３２は、図８に示す状態確認表を参照して状態確認を行なう（Ｓ５１）。現在の状態ではシーケンス上受け取るはずがないイベントを受け取った場合（Ｓ５２，Ｎｏ）、そのまま処理を終了する。

状態確認が済めば（Ｓ５２，Ｙｅｓ）、コミュニケーション管理部３２は、要求送信イベントが変更要求（変更要求送信イベント）であるか否かを判定する（Ｓ５３）。変更要求送信イベントであれば（Ｓ５３，Ｙｅｓ）、変更要求中状態に遷移し（Ｓ５４）、ＧＵＩ部３１によって検出された変更に関する情報を抽出する（Ｓ５５）。そして、コミュニケーション管理部３２は、変更要求中画面を表示するようＧＵＩ部３１に指示し（Ｓ５６）、シグナリング部３８にＳＩＰシグナルのｒｅ−ＩＮＶＩＴＥメッセージを相手の情報処理装置に送信させ（Ｓ５７）、通信を一旦停止させて（Ｓ５８）、処理を終了する。

変更要求送信イベントでなければ（Ｓ５３，Ｎｏ）、コミュニケーション管理部３２は、要求送信イベントが接続要求（接続要求送信イベント）であるか否かを判定する（Ｓ５９）。接続要求送信イベントであれば（Ｓ５９，Ｙｅｓ）、発信接続中状態に遷移し（Ｓ６０）、ＧＵＩ部３１によって検出された発信に関する情報を抽出する（Ｓ６１）。そして、コミュニケーション管理部３２は、発信接続中画面を表示するようＧＵＩ部３１に指示し（Ｓ６２）、シグナリング部３８にＳＩＰシグナルのＩＮＶＩＴＥメッセージを相手の情報処理装置に送信させて（Ｓ６３）、処理を終了する。

接続要求送信イベントでなければ（Ｓ５９，Ｎｏ）、コミュニケーション管理部３２は、要求送信イベントが切断要求（切断要求送信イベント）であるか否かを判定する（Ｓ６４）。切断要求送信イベントであれば（Ｓ６４，Ｙｅｓ）、シグナリング部３８にＳＩＰシグナルのＢＹＥメッセージを相手の情報処理装置に送信させ（Ｓ６５）、データ送信部３７およびデータ受信部３９を制御してデータの送受信を終了する（Ｓ６６）。そして、コミュニケーション管理部３２は、初期画面である待ち受け画面を表示するようＧＵＩ部３１に指示し（Ｓ６７）、待ち受け状態に遷移して（Ｓ６８）、処理を終了する。

切断要求送信イベントでなければ（Ｓ６４，Ｎｏ）、そのまま処理を終了する。
図１０は、図５に示す応答受信処理（Ｓ１９）の処理手順を説明するためのフローチャートである。応答受信イベントは、自身が相手の情報処理装置に送信した接続要求（ＩＮＶＩＴＥメッセージ）、変更要求（ｒｅ−ＩＮＶＩＴＥメッセージ）および切断要求（ＢＹＥメッセージ）のいずれかのリクエストに対する応答を受信したときに発生するイベントであり、それに対応する処理がこの応答受信処理に相当する。

まず、コミュニケーション管理部３２は、状態確認を行なう（Ｓ７１）。現在の状態ではシーケンス上受け取るはずがないイベントを受け取った場合（Ｓ７２，Ｎｏ）、そのまま処理を終了する。

状態確認が済めば（Ｓ７２，Ｙｅｓ）、コミュニケーション管理部３２は、応答受信イベントが変更応答（変更応答受信イベント）であるか否かを判定する（Ｓ７３）。変更応答受信イベントであれば（Ｓ７３，Ｙｅｓ）、シグナリング部３８によって受信されたＳＩＰシグナルから変更応答情報を抽出する（Ｓ７４）。そして、変更応答情報によって２００ ＯＫ応答が確認されれば（Ｓ７５，Ｙｅｓ）、コミュニケーション管理部３２は、ＧＵＩ部３１、入力制御部３３および出力制御部３４を制御して、変更後の通信に合わせた画面表示を行なう（Ｓ７６）。そして、変更のネゴシエーション結果に従ったコミュニケーションデータの送受信を開始し（Ｓ７７）、接続通信中状態に遷移して（Ｓ８４）、処理を終了する。

また、変更応答情報によって２００ ＯＫ応答が確認されなければ（Ｓ７５，Ｎｏ）、変更要求がキャンセルされたとして、変更要求前の画面に戻すようＧＵＩ部３１に指示し、データ送信部３７およびデータ受信部３９に変更要求前の通信を再開させ（Ｓ７８）、接続通信中状態に遷移して（Ｓ８４）、処理を終了する。

変更応答受信イベントでなければ（Ｓ７３，Ｎｏ）、コミュニケーション管理部３２は、応答受信イベントが発信応答（発信応答受信イベント）であるか否かを判定する（Ｓ７９）。発信応答受信イベントであれば（Ｓ７９，Ｙｅｓ）、シグナリング部３８によって受信されたＳＩＰシグナルから発信応答情報を抽出する（Ｓ８０）。そして、発信応答情報によって２００ ＯＫ応答が確認されれば（Ｓ８１，Ｙｅｓ）、コミュニケーション管理部３２は、ＧＵＩ部３１、入力制御部３３および出力制御部３４を制御して、接続後の通信に合わせた画面表示を行なう（Ｓ８２）。そして、接続のネゴシエーション結果に従ったコミュニケーションデータの送受信を開始し（Ｓ８３）、接続通信中状態に遷移して（Ｓ８４）、処理を終了する。

また、発信応答情報によって２００ ＯＫ応答が確認されなければ（Ｓ８１，Ｎｏ）、接続要求が拒否されたものとして、コミュニケーション管理部３２は、初期画面である待ち受け画面を表示するようＧＵＩ部３１に指示し（Ｓ８７）、待ち受け中状態に遷移して（Ｓ８８）、処理を終了する。

発信応答受信イベントでなければ（Ｓ７９，Ｎｏ）、コミュニケーション管理部３２は、応答受信イベントが切断応答（切断応答受信イベント）であるか否かを判定する（Ｓ８５）。切断応答受信イベントであれば（Ｓ８５，Ｙｅｓ）、データ送信部３７およびデータ受信部３９を制御して通信を終了させ（Ｓ８６）、初期画面である待ち受け画面を表示するようＧＵＩ部３１に指示し（Ｓ８７）、待ち受け中状態に遷移して（Ｓ８８）、処理を終了する。

また、切断応答受信イベントでなければ（Ｓ８５，Ｎｏ）、そのまま処理を終了する。
図１１は、図５に示す応答送信処理（Ｓ２１）の処理手順を説明するためのフローチャートである。応答送信イベントは、他の情報処理装置からリクエストを受信した後、ＧＵＩ部３１がユーザ操作を検出したときに発生するイベントである。

まず、コミュニケーション管理部３２は、状態確認を行なう（Ｓ９１）。現在の状態ではシーケンス上受け取るはずがないイベントを受け取った場合（Ｓ９２，Ｎｏ）、そのまま処理を終了する。

状態確認が済めば（Ｓ９２，Ｙｅｓ）、コミュニケーション管理部３２は、シグナリング部３８にそのイベントに対応する応答を送信させる（Ｓ９３）。そして、応答送信イベントが変更応答（変更応答送信イベント）であるか否かを判定する（Ｓ９４）。変更応答送信イベントであれば（Ｓ９４，Ｙｅｓ）、２００ ＯＫ応答を送信したか否かを判定する（Ｓ９５）。

２００ ＯＫ応答を送信したのであれば（Ｓ９５，Ｙｅｓ）、コミュニケーション管理部３２は、ＧＵＩ部３１を制御して表示画面を切替えさせると共に、入力制御部３３および出力制御部３４を制御して入力装置２１および出力装置２２の設定変更を行なわせ、エンコード部３５およびデコード部３６を制御してエンコーダ２４およびデコーダ２５を切替えさせる（Ｓ９６）。そして、変更のネゴシエーション結果に従ったコミュニケーションデータの送受信を開始し（Ｓ９７）、接続通信中状態に遷移して（Ｓ１０４）、処理を終了する。

また、２００ ＯＫ応答を送信していなければ（Ｓ９５，Ｎｏ）、変更要求前の画面に戻すようＧＵＩ部３１に指示し、データ送信部３７およびデータ受信部３９に変更要求前の通信を再開させ（Ｓ９９）、接続通信中状態に遷移して（Ｓ１０４）、処理を終了する。

変更応答送信イベントでなければ（Ｓ９４，Ｎｏ）、コミュニケーション管理部３２は、応答送信イベントが接続応答（接続応答送信イベント）であるか否かを判定する（Ｓ１００）。接続応答送信イベントであれば（Ｓ１００，Ｙｅｓ）、２００ ＯＫ応答を送信したか否かを判定する（Ｓ１０１）。

２００ ＯＫ応答を送信したのであれば（Ｓ１０１，Ｙｅｓ）、コミュニケーション管理部３２は、ＧＵＩ部３１を制御してコミュニケーションデータの情報に従った表示画面に切替えさせると共に、入力制御部３３および出力制御部３４を制御して入力装置２１および出力装置２２の設定変更を行なわせ、エンコード部３５およびデコード部３６を制御してエンコーダ２４およびデコーダ２５を切替えさせる（Ｓ１０２）。そして、接続のネゴシエーション結果に従ったコミュニケーションデータの送受信を開始し（Ｓ１０３）、接続通信中状態に遷移して（Ｓ１０４）、処理を終了する。

また、２００ ＯＫ応答を送信していなければ（Ｓ１０１，Ｎｏ）、コミュニケーション管理部３２は、初期画面である待ち受け画面を表示するようＧＵＩ部３１に指示し（Ｓ１０５）、待ち受け中状態に遷移して（Ｓ１０６）、処理を終了する。

図１２は、コミュニケーション開始の一例を説明するための図である。図１２（ａ）は、ユーザがリモコン１０の＃キーを押下することにより、電話帳の表示画面に切替えたところを示している。リモコン１０の十字キーの上下を押下することによって、発信先を選択し、決定キー１０５を押下することによって発信を開始する。

図１２（ｂ）は、ユーザが発信キーを押下することにより電話番号入力にし、数字キー１０１で接続先のＴＶ電話番号を入力するところを示している。ユーザが再度発信キーを押下することによって発信を開始する。

図１３は、ＳＩＰシグナルのＩＮＶＩＴＥリクエスト（ＴＶ電話モード）の一例を示す図である。このＩＮＶＩＴＥリクエストは、ヘッダフィールド（１）と、メッセージボディ（２）とを含む。

ヘッダフィールド（１）において、最初のヘッダフィールドにはリクエストの種類であるＩＮＶＩＴＥと、ＳＩＰ ＵＲＩ（Uniform Resource Identifier）とが記述される。Ｖｉａヘッダフィールドは、トランザクションのために使用されるトランスポートを示し、トランザクションを識別するｂｒａｎｃｈパラメータを含む。

Ｆｒｏｍヘッダフィールドは、リクエストを開始した者の論理的なアイデンティティを示し、乱数文字列を含んだｔａｇパラメータを含む。Ｔｏヘッダフィールドは、希望するリクエストの論理的な受信者などを示す。Ｃａｌｌ−ＩＤヘッダフィールドは、連続するメッセージをグループ化するための一意の識別子を示す。

ＣＳｅｑヘッダフィールドは、トランザクションを識別し順番付けするためのシーケンス番号とメソッドとを示す。Ｃｏｎｔａｃｔヘッダフィールドは、これに続くリクエストでそのＵＡ（User Agent）の特定のインスタンスにコンタクトするために使用できるＳＩＰ ＵＲＩなどを示す。Ａｌｌｏｗヘッダフィールドは、そのメッセージを生成するＵＡがサポートするメソッドの組のリストを示しており、ＩＮＶＩＴＥ、ＡＣＫ、ＣＡＮＣＥＬ、ＢＹＥ、ＯＰＴＩＯＮＳ、ＭＥＳＳＡＧＥ、ＳＵＢＳＣＲＩＢＥおよびＮＯＴＩＦＹがサポートされている。

Ｓｕｐｐｏｒｔｅｄヘッダフィールドは、サーバが応答に適用できるＳＩＰの拡張のサポートを示す。Ｓｅｓｓｉｏｎ−Ｅｘｐｉｒｅｓヘッダフィールドは、メッセージがそれ以降期限切れになる相対時間を示す。

Ｍａｘ−Ｆｏｒｗａｒｄｓヘッダフィールドは、リクエストがディスティネーションに向かう過程で通過することができるホップの数の制限を示す。Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダフィールドは、受信者に送られたメッセージボディのメディアタイプを示す。Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダフィールドは、受信者に送られたメッセージボディのサイズを示す。

メッセージボディ（２）において、（３）は音声のメディア記述を示しており、音声のＲＴＰポート番号が４０５０、音声の圧縮方式がＧ．７１１のＰＣＭＵ（Pulse Codec Modulation μ-Law）であることを示している。また、ａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅ行によって音声がマイク音声であることを示している。

メッセージボディ（２）において、（４）は映像のメディア記述を示しており、発信側の装置が映像データを受信することを希望する映像の圧縮方式がＭＰ４Ｖ−ＥＳ、ＲＴＰポート番号が４０６０であることを示している。また、ａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅ行によってこのメディアはカメラの映像とするようリクエストしている。

メッセージボディの情報によって、アプリケーションとしてテレビ電話モードであると解釈することができ、相手の情報処理装置は、テレビ電話としての映像の表示、マイク音声の出力を行なうことができる。

図１４は、ＳＩＰシグナルの２００ ＯＫ応答（ＴＶ電話モード）の一例を示す図である。この２００ ＯＫ応答は、ＩＮＶＩＴＥリクエストに対して接続を了承するレスポンスとしてコミュニケーションデータの通信に関する情報をＳＤＰ記述しており、ヘッダフィールド（１）と、メッセージボディ（２）とを含む。

ヘッダフィールド（１）において、図１３と異なるのはＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドが追加されている点である。このＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダフィールドは、ダイアログ中のそれ以降のリクエストをプロキシを通してルートさせることを示している。

メッセージボディ（２）において、（３）は音声のメディア記述を示しており、音声のＲＴＰポート番号が１６３５０であることを示している。それ以外の記述については、ＩＮＶＩＴＥリクエストの記述と同様である。

メッセージボディ（２）において、（４）は映像のメディア記述を示しており、映像のＲＴＰポート番号が１６３６０であることを示している。それ以外の記述については、ＩＮＶＩＴＥリクエストの記述と同様である。

この２００ ＯＫ応答がリクエストを発信した情報処理装置に送信されることによって、ＴＶ電話による通話が開始される。

図１５は、ＴＶ電話モードで通話中の状態を示す図である。それぞれの情報処理装置の表示画面には、相手の顔が大きく表示され、自身の顔が小さく表示されており、相手の音声が情報処理装置のスピーカから出力されているところを示している。この状態で、左側のユーザが、たとえばリモコン１０の＊ボタンを押下することにより、送信ソースの切替えが開始される。

図１６は、送信ソースの切替え画面を示す図である。左側のユーザがリモコン１０の＊ボタンを押下することにより、表示画面に送信ソースの一覧が表示される。たとえば、外部入力が選択された状態で、リモコン１０の決定キー１０５が押下されると、カメラ映像から外部入力映像に切替えられる。

図１７は、ＳＩＰシグナルのｒｅ−ＩＮＶＩＴＥリクエスト（外部入力映像切替え）の一例を示す図である。このｒｅ−ＩＮＶＩＴＥリクエストは、カメラ映像から外部入力映像に切替えることを要求するものであり、ヘッダフィールド（１）と、メッセージボディ（２）とを含む。

ヘッダフィールド（１）は、図１３のＩＮＶＩＴＥメッセージと同じで、ＣＳｅｑが１から２に１つ数が増えている。

メッセージボディ（２）において、（３）は音声のメディア記述を示しており、音声のＲＴＰポート番号が４０５０、音声の圧縮方式がＧ．７１１のＰＣＭＵであることを示している。また、ａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅ行によって音声がマイク音声であることを示している。

メッセージボディ（２）において、（４）は映像のメディア記述を示しており、映像のＲＴＰポート番号が４０６０、映像の圧縮方式がＭＰ４Ｖ−ＥＳであることを示している。また、ａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅ行によって映像がカメラ映像であることを示している。さらに、この映像ストリームはリクエスト側において受信のみ（ｒｅｃｅｉｖｅｏｎｌｙ）であることが記述されている。

メッセージボディ（２）において、（５）は映像のメディア記述を示しており、映像のＲＴＰポート番号が４０８０、映像の圧縮方式がＭＰ４Ｖ−ＥＳであることを示している。また、ａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅ行によって映像が外部入力映像であることを示している。さらに、この映像ストリームは応答した側から見て送信のみ（ｓｅｎｄｏｎｌｙ）であることが記述されている。

メッセージボディの情報によって、カメラ映像から外部入力映像に切替わると解釈することができ、相手の情報処理装置は、外部入力映像の表示、マイク音声の出力を行なうことができる。

図１８は、ＳＩＰシグナルの２００ ＯＫ応答（外部入力映像切替え）の一例を示す図である。この２００ ＯＫ応答は、ｒｅ−ＩＮＶＩＴＥリクエストに対して変更を了承するレスポンスとしてコミュニケーションデータの通信に関する情報をＳＤＰ記述しており、ヘッダフィールド（１）と、メッセージボディ（２）とを含む。

ヘッダフィールド（１）は、図１４に示すヘッダフィールド（１）と同様である。メッセージボディ（２）において、（３）は音声のメディア記述を示しており、図１４の（３）の記述と同様である。

メッセージボディ（２）において、（４）は映像のメディア記述を示しており、映像のＲＴＰポート番号が１６３６０であり、この映像が送信のみ（ｓｅｎｄｏｎｌｙ）であることを示している。それ以外の記述については、図１７に示すｒｅ−ＩＮＶＩＴＥリクエストの（４）の記述と同様である。

メッセージボディ（２）において、（５）は映像のメディア記述を示しており、映像のＲＴＰポート番号が１６３７０であり、この映像が受信のみ（ｒｅｃｅｉｖｅｏｎｌｙ）であることを示している。それ以外の記述については、図１７に示すｒｅ−ＩＮＶＩＴＥリクエストの（５）の記述と同様である。ここで、今までカメラ映像を受信していたポート“１６３６０”と異なるポート“１６３７０”に変更してレスポンスしている。そのため、切替えのタイミングでカメラの映像データが外部入力映像として処理されることを防止している。

この２００ ＯＫ応答がｒｅ−ＩＮＶＩＴＥリクエストを発信した情報処理装置に送信されることによって、発信元の情報処理装置は外部入力映像の送信を開始する。また、音声はそれまでのとおりであるので、会話を続けることができる。

図１９は、端末Ａが切替え（変更）要求を送信したときの画面表示を示す図である。左側のユーザが切替え要求を送信すると、その情報処理装置の画面には「切替え要求送信」が表示される。また、切替え要求を受信した右側の情報処理装置の画面には、「切替え要求受信」が表示される。右側のユーザは、リモコン１０を操作することによって、切替え要求を受けるか否かを選択する。右側のユーザが切替えを選択した場合、２００ ＯＫ応答が左側の情報処理装置に送信される。

図２０は、映像が外部入力映像に切替えられた場合の画面表示を示す図である。図２０に示すように、今までのＴＶ電話の画面構成ではなく、外部入力映像を共有するような画面構成に変更される。音声はそれまでのとおりであるので、会話を続けることができる。

以上の説明においては、ＳＩＰシグナルを利用してコミュニケーションデータを変更するものであったが、ＳＩＰプロトコルに依存するものではなく、他の呼制御プロトコルまたはその拡張やオリジナルの通知プロトコルによって実現することも可能である。

また、本実施の形態においては、ａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅとした拡張ヘッダを定義し、ソースデバイスの情報を相手に通知するようにしたが、ソースデバイス以外の情報を通知することも可能である。具体的には、ソースコンテンツファイルの種類の情報、たとえば、“２００５年誕生日パーティの写真”のようなコンテンツを指定するものであったり、“デジタルビデオ撮影映像”や“スポーツ映像”、“音楽映像”などのようにカテゴリを示すものであってもよい。

このようにすることによって、たとえば「運動会」というタイトルであれば、映像受信に合わせて「運動会」にマッチする画像を背景に表示させたり、「運動会」をイメージさせる音楽をＢＧＭに流したりするようなアプリケーションを作成することも可能である。

また、「音楽」に相当するタイトルならば、音声外部出力端子８−１に接続されたステレオスピーカに音声出力を切替えるような設定も可能であるし、外部入力からの音楽は外付けスピーカに出力させ、マイク音声は内蔵スピーカに出力させるなど、ミキシングしないで出力デバイスを選択することも可能である。

また、ＳＩＰシグナルにソースデバイスの情報を直接記述する以外に、コミュニケーションモードを記述することによってソースデバイスの組合わせを選択するようにしてもよい。たとえば、カメラとマイクとであればテレビ電話モードであると定義し、マイクと外部入力映像とであれば映像共有音声コミュニケーションモードであると定義して、そのモードを記述して相手に通知する。ＳＩＰであれば、セッション情報を記述するｉヘッダフィールドで情報を通知することも可能である。

また、セッションの状態に名前を付けて記述するようにしてもよい。たとえば、カメラを用いたテレビ電話モードであれば“ＴＶＰｈｏｎｅ”、外部入力映像を送信して共有しながら会話するモードであれば“ＥｘＶｉｄｅｏ”というように記述する。この場合にも、通常のテレビ電話とビデオ共有モードとで背景や画面構成などを切替えるようにすることも可能である。

以上説明したように、本実施の形態における情報処理装置においては、情報処理装置が相手の情報処理装置と接続中に、送信データの種類を示す情報を含んだｒｅ−ＩＮＶＩＴＥリクエストを送信するようにしたので、相手の情報処理装置は受信データが切替えられることを認識することができ、それに応じた画面構成の変更、出力装置の選択などを行なうことが可能となった。

（第２の実施の形態）
本発明の第２の実施の形態における情報処理装置の外観、ハードウェア構成および機能的構成は、図１〜３に示す第１の実施の形態における外観、ハードウェア構成および機能的構成と同様である。また、本発明の第２の実施の形態における情報処理装置の処理手順は、図５、図７および図９〜１１に示す第１の実施の形態における処理手順と同様である。したがって、詳細な説明は繰返さない。

第１の実施の形態においては、送信中の映像を他の映像に置換えるものであった。本実施の形態における情報処理装置は、既に使用中のコミュニケーションデータの通信に加えて、新たなコミュニケーションデータの通信を追加するものである。

図２１は、使用中のメディアに新たなメディアを追加する場合のＳＩＰシグナルのｒｅ−ＩＮＶＩＴＥリクエストの一例を示す図である。このｒｅ−ＩＮＶＩＴＥリクエストは、マイク音声とカメラ映像とに加えて、さらに音声外部入力端子７−１などから入力される音声（以下、外部入力音声と呼ぶ。）と外部入力映像とを追加するものであり、ヘッダフィールド（１）と、メッセージボディ（２）とを含む。

ヘッダフィールド（１）は、図１７に示すヘッダフィールド（１）と同様である。メッセージボディ（２）において、図１３と異なるのは、（４）の外部入力音声の記述と、（６）の外部入力映像の記述が追加されている点である。

メッセージボディ（２）において、（４）は音声のメディア記述を示しており、音声のＲＴＰポート番号が４０７０、音声の圧縮方式がＧ．７１１のＰＣＭＵであることを示している。また、ａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅ行によって音声が外部入力音声であることを示している。また、この音声は送信のみ（ｓｅｎｄｏｎｌｙ）であることが記述されている。

メッセージボディ（２）において、（６）は映像のメディア記述を示しており、映像のＲＴＰポート番号が４０８０、映像の圧縮方式がＭＰ４Ｖ−ＥＳであることを示している。また、ａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅ行によって映像が外部入力映像であることを示している。また、この映像は送信のみ（ｓｅｎｄｏｎｌｙ）であることが記述されている。

図２２は、使用中のメディアに新たなメディアを追加する場合のＳＩＰシグナルの２００ ＯＫ応答の一例を示す図である。この２００ ＯＫ応答は、ｒｅ−ＩＮＶＩＴＥリクエストに対してメディアの追加を了承するレスポンスとしてコミュニケーションデータの通信に関する情報をＳＤＰ記述しており、ヘッダフィールド（１）と、メッセージボディ（２）とを含む。

ヘッダフィールド（１）は、図１８に示すヘッダフィールド（１）と同様である。メッセージボディ（２）において、図１４と異なるのは、（４）の外部入力音声の記述と、（６）の外部入力映像の記述が追加されている点である。

メッセージボディ（２）において、（４）は音声のメディア記述を示しており、音声のＲＴＰポート番号が１６３７０、音声の圧縮方式がＧ．７１１のＰＣＭＵであることを示している。また、ａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅ行によって音声が外部入力音声であることを示している。また、この音声は受信のみ（ｒｅｃｅｉｖｅｏｎｌｙ）であることが記述されている。

メッセージボディ（２）において、（６）は映像のメディア記述を示しており、映像のＲＴＰポート番号が１６３８０、映像の圧縮方式がＭＰ４Ｖ−ＥＳであることを示している。また、ａ＝Ｘ−ｍｅｄｉａ−ｓｏｕｒｃｅ行によって映像が外部入力映像であることを示している。また、この映像は受信のみ（ｒｅｃｅｉｖｅｏｎｌｙ）であることが記述されている。

図２３は、メディアとして外部入力音声および外部入力映像が追加された場合の情報処理装置を示す図である。それぞれの情報処理装置の表示画面には、共有映像として外部入力映像が親画面として大きく表示され、相手の顔がピクチャ・イン・ピクチャで子画面として小さく表示されている。また、それぞれの情報処理装置の内蔵スピーカ３から外部入力音声が出力され、音声外部出力端子８−１に接続された外付けのスピーカから相手の音声が出力されているところを示している。

このように、ビデオコンテンツを同時に視聴しながら、相手の表情を見たり会話したりすることも可能なセッションに変更することができる。通信される音声や映像のコミュニケーションデータの出力方法は、アプリケーションによって自由に制御することが可能である。

以上説明したように、本実施の形態における情報処理装置によれば、ｒｅ−ＩＮＶＩＴＥリクエストによって使用中のメディアに新たなメディアを追加するようにしたので、情報処理装置の操作性をさらに向上させることが可能となった。

（第３の実施の形態）
第１および第２の実施の形態においては、コミュニケーションデータとは別のシグナリングで情報を通知するものであった。本実施の形態における情報処理装置においては、特別なシグナリングを用いずに、コミュニケーションデータの通信内においてこのような情報を通知するものである。

本発明の第３の実施の形態における情報処理装置の外観、ハードウェア構成および機能的構成は、図１〜３に示す第１の実施の形態における外観、ハードウェア構成および機能的構成と同様である。したがって、詳細な説明は繰返さない。

図２４は、ＲＴＰパケットで送信されるペイロードタイプの値を利用してコミュニケーションデータを変更する方法を示す図である。予め決めておいたペイロードタイプのパケットを本データの前に挿入して送信することで、テレビ電話モードの開始、切替えや、変更後のコミュニケーションモード、ソースの種類などを通知することができる。

通常、ＳＩＰなどでネゴシエーションされた本データ以外のペイロードタイプの情報は廃棄されるが、予め決められたペイロードタイプの値を知る情報処理装置であれば、区切りのパケットとそのペイロードタイプの値とで何に切替わるかを認識することができる。

図２４においては、テレビ電話モードの開始前にペーロードタイプ（ＰＴ）＝１００のパケットが送信され、ビデオ共有モード開始時にはＰＴ＝１０１のパケットが送信されており、それぞれの本データはＰＴ＝９８のパケットとして送信される。このように、テレビ電話モードからビデオ共有モードに変更するだけであれば、シグナリングによる再ネゴシエーションは不要であり、ペーロードタイプや受信ポートなどの通信も全く変わらないが、受信側で送信されたデータが別のソースに切替わったことを認識することができる。

図２５は、本発明の第３の実施の形態における情報処理装置の処理手順を説明するためのフローチャートである。まず、コミュニケーション管理部３２は、ＳＩＰシグナルによってネゴシエーションされた結果に基づいて、入力装置２１、出力装置２２などの選択や、パラメータ設定、画面構成などの切替えを行なう（Ｓ１１１）。

次に、コミュニケーション管理部３２は、ユーザ操作やシグナリングによってコミュニケーションの終了イベントが発生したか否かを判定する（Ｓ１１２）。終了イベントが発生すれば（Ｓ１１２，Ｙｅｓ）、通信を終了する。また、終了イベントが発生していなければ（Ｓ１１２，Ｎｏ）、コミュニケーション管理部３２は、データ受信部３９によって受信されたＲＴＰパケットを図示しない受信バッファから読出し（Ｓ１１３）、そのペイロードタイプを抽出する（Ｓ１１４）。

ＳＩＰシグナルによってネゴシエーションされたペイロードタイプと一致する場合には（Ｓ１１５，Ｙｅｓ）、そのデータをデコーダ２５の図示しない入力バッファに書込み（Ｓ１２０）、ステップＳ１１２に戻って以降の処理を繰返す。

ネゴシエーションされたペイロードタイプと一致しない場合には（Ｓ１１５，Ｎｏ）、そのパケットの送信元がどこであるかを確認し（Ｓ１１６）、通信相手と一致しているか否かを判定する（Ｓ１１７）。

通信相手と一致していなければ（Ｓ１１７，Ｎｏ）、そのパケットは無視して、ステップＳ１１２に戻って以降の処理を繰返す。また、通信相手と一致していれば（Ｓ１１７，Ｙｅｓ）、ペイロードタイプにアサインした出力設定を読出し（Ｓ１１８）、ペイロードタイプに該当するモードがなければ（Ｓ１１９，Ｎｏ）、そのデータをデコーダ２５の入力バッファに書込み（Ｓ１２０）、ステップＳ１１２に戻って以降の処理を繰返す。

ペイロードタイプに該当するモードがあれば（Ｓ１１９，Ｙｅｓ）、デコーダの入力バッファに残っているデータをクリアし（Ｓ１２１）、画面構成、出力設定などをペイロードに該当するモードに対応するよう変更し（Ｓ１２２）、ステップＳ１１２に戻って以降の処理を繰返す。

図２６は、ペイロードタイプにアサインした出力設定（モード）の一例を示す図である。ＰＴ＝１００の場合には、カメラ映像が送信され、テレビ電話構成（モード）であることを示す。ＰＴ＝１０１の場合には、外部入力映像（動画）が送信され、ビデオ共有構成（モード）であることを示す。ＰＴ＝１０２の場合には、外部入力映像（静止画）が送信され、静止画共有構成（モード）であることを示す。ＰＴ＝１０３の場合には、ファイル映像が送信され、ファイル共有構成（モード）であることを示す。

図２７は、図２６に示すアサインされた構成に対応する画面構成を示す図である。図２７（ａ）は、テレビ電話構成に対応する画面構成を示しており、通信相手からのカメラ映像を大きく表示し、自身のカメラ映像を小さく表示する。

図２７（ｂ）は、ビデオ共有構成に対応する画面構成を示しており、ビデオの上にピクチャ・イン・ピクチャで相手のカメラ映像を表示し、ビデオ視聴中の相手の表示を見れるようにしている。

図２７（ｃ）は、静止画共有構成に対応する画面構成を示しており、静止画のみが表示されている。

以上説明したように、本実施の形態における情報処理装置によれば、予め決めておいたペイロードタイプのパケットを本データの前に挿入して送信するようにしたので、特別なシグナリングを用いずに、コミュニケーションデータの通信内においてモードを変更することが可能となった。

（第４の実施の形態）
第３の実施の形態においては、情報処理装置が予め決めておいたペイロードタイプのパケットを本データの前に挿入して送信するものであった。本実施の形態における情報処理装置においては、コミュニケーションデータのパケットにペイロードタイプの値を埋め込んで送信することにより情報を通知するものである。

本発明の第４の実施の形態における情報処理装置の外観、ハードウェア構成および機能的構成は、図１〜３に示す第１の実施の形態における外観、ハードウェア構成および機能的構成と同様である。したがって、詳細な説明は繰返さない。

図２８は、ＲＴＰパケットで送信されるコミュニケーションデータにペイロードタイプの値を埋め込んで、コミュニケーションデータを変更する方法を示す図である。予め決めておいたペイロードタイプをコミュニケーションデータに埋め込んで送信することで、テレビ電話モードの開始、切替えや、変更後のコミュニケーションモード、ソースの種類などを通知することができる。埋め込まれたＰＴ＝９８の場合には、テレビ電話モードであることを示す。また、ＰＴ＝９９の場合には、ビデオ共有モードであることを示す。

図２９は、本発明の第４の実施の形態における情報処理装置の処理手順を説明するためのフローチャートである。まず、コミュニケーション管理部３２は、ＳＩＰシグナルによってネゴシエーションされた結果に基づいて、入力装置２１、出力装置２２などの選択や、パラメータ設定、画面構成などの切替えを行なう（Ｓ１３１）。

次に、コミュニケーション管理部３２は、ユーザ操作やシグナリングによってコミュニケーションの終了イベントが発生したか否かを判定する（Ｓ１３２）。終了イベントが発生すれば（Ｓ１３２，Ｙｅｓ）、通信を終了する。また、終了イベントが発生していなければ（Ｓ１３２，Ｎｏ）、コミュニケーション管理部３２は、データ受信部３９によって受信されたＲＴＰパケットを図示しない受信バッファから読出し（Ｓ１３３）、そのパケットの送信元がどこであるかを確認し（Ｓ１３４）、通信相手と一致しているか否かを判定する（Ｓ１３５）。

通信相手と一致していなければ（Ｓ１３５，Ｎｏ）、そのパケットは無視して、ステップＳ１３２に戻って以降の処理を繰返す。また、通信相手と一致していれば（Ｓ１３５，Ｙｅｓ）、そのペイロードタイプを抽出する（Ｓ１３６）。そして、ペイロードタイプにアサインした出力設定を読出し（Ｓ１３７）、ペイロードタイプに該当するモードがなければ（Ｓ１３８，Ｎｏ）、通信を終了する。

ペイロードタイプに該当するモードがあれば（Ｓ１３８，Ｙｅｓ）、画面構成、出力設定などをペイロードに該当するモードに対応するよう変更し（Ｓ１３９）、デコーダの入力バッファに残っているデータをクリアし（Ｓ１４０）、デコーダの入力バッファにコミュニケーションデータを書込んで（Ｓ１４１）、ステップＳ１３２に戻って以降の処理を繰返す。

図３０は、コミュニケーションのモードが切替わるときの表示画面の一例を示す図である。図３０に示すように、コミュニケーションのモードが変わることを画面上のメッセージでユーザに知らせる。

また、画像の表示サイズや位置を変更したり、背景画像や映像表示枠のデザインなどの表示の装飾を変更することも可能である。このような情報が予め情報処理装置に設定値として保持されたり、通知されることによって実現可能である。

図３１は、ＳＤＰ記述でａｔｔｒｉｂｕｔｅを拡張して、メディア表示に関する情報を送信する場合のＳＩＰシグナルの一例を示す図である。この記述においては、ビデオを左上位置を原点とする（ｘ，ｙ）座標でＡ×Ｂのサイズで表示し、表示枠は「レイアウト１」という名称で定義されたデザインのレイアウトが使用されることが示されている。この例において、「レイアウト１」は画面全体の領域で背景イメージを指定でき、下部にメッセージ表示エリアを有するものであり、その上に自由なビデオ表示を重ねて表示することが可能なものである。背景イメージには「背景１」という名称のイメージが表示され、メッセージ表示エリアには「２００５／５／８のコンサートビデオ」を表示することが指定されている。

図３２は、レイアウト１の定義データの一例を示す図である。この定義データにおいては、画面サイズが左上座標（０，０）を原点として６４０×４８０であり、背景がデフォルト設定されておらず（ｎｕｌｌ）、メッセージエリアが座標（０，５００）から（５００，８０）のサイズであることが示されている。

図３３は、図３１に示すＳＤＰ記述および図３２に示すレイアウト１の定義データに基づいて表示された画面の一例を示す図である。

また、送信するビデオの種類によって、画質などの優先度が変わる。たとえば、ビデオを共有する場合には高画質な映像が要求されるが、テレビ電話でのカメラ映像は相手の表情を見る程度の画質でもよく、むしろ遅延を少なくするために画質を下げる方がよいと考えられる。映像において、その品質はジッタと呼ばれる遅延時間の揺らぎによって影響されるが、そのためのバッファサイズを変動させることによって、画質の高低や、遅延の大小を制御することができる。

また、切替えタイミングにおいて、上述したようにバッファをクリアすることができるので、切替え後の映像の開始の遅延を少なくすることもできる。

以上説明したように、本実施の形態における情報処理装置によれば、予め決めておいたペイロードタイプをコミュニケーションデータのパケットに挿入して送信するようにしたので、特別なシグナリングを用いずに、コミュニケーションデータの通信内においてモードを変更することが可能となった。

今回開示された実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

本発明の第１の実施の形態における情報処理装置の外観例を示す図である。 本発明の第１の実施の形態における情報処理装置のハードウェア構成を示すブロック図である。 本発明の第１の実施の形態における情報処理装置の機能的構成を示すブロック図である。 本発明の第１の実施の形態における情報処理装置のシグナリングによる送信メディア変更を説明するためのシーケンス図である。 本発明の第１の実施の形態における情報処理装置の全体的な処理手順を説明するためのフローチャートである。 本発明の第１の実施の形態における情報処理装置によって管理される状態遷移を説明するための図である。 図５に示す要求受信処理（Ｓ１５）の処理手順を説明するためのフローチャートである。 コミュニケーション管理部３２によって参照される状態確認表の一例を示す図である。 図５に示す要求送信処理（Ｓ１７）の処理手順を説明するためのフローチャートである。 図５に示す応答受信処理（Ｓ１９）の処理手順を説明するためのフローチャートである。 図５に示す応答送信処理（Ｓ２１）の処理手順を説明するためのフローチャートである。 コミュニケーション開始の一例を説明するための図である。 ＳＩＰシグナルのＩＮＶＩＴＥリクエスト（ＴＶ電話モード）の一例を示す図である。 ＳＩＰシグナルの２００ ＯＫ応答（ＴＶ電話モード）の一例を示す図である。 ＴＶ電話モードで通話中の状態を示す図である。 送信ソースの切替え画面を示す図である。 ＳＩＰシグナルのｒｅ−ＩＮＶＩＴＥリクエスト（外部入力映像切替え）の一例を示す図である。 ＳＩＰシグナルの２００ ＯＫ応答（外部入力映像切替え）の一例を示す図である。 端末Ａが切替え（変更）要求を送信したときの画面表示を示す図である。 映像が外部入力映像に切替えられた場合の画面表示を示す図である。 使用中のメディアに新たなメディアを追加する場合のＳＩＰシグナルのｒｅ−ＩＮＶＩＴＥリクエストの一例を示す図である。 使用中のメディアに新たなメディアを追加する場合のＳＩＰシグナルの２００ ＯＫ応答の一例を示す図である。 メディアとして外部入力音声および外部入力映像が追加された場合の情報処理装置を示す図である。 ＲＴＰパケットで送信されるペイロードタイプの値を利用してコミュニケーションデータを変更する方法を示す図である。 本発明の第３の実施の形態における情報処理装置の処理手順を説明するためのフローチャートである。 ペイロードタイプにアサインした出力設定（モード）の一例を示す図である。 図２６に示すアサインされた構成に対応する画面構成を示す図である。 ＲＴＰパケットで送信されるコミュニケーションデータにペイロードタイプの値を埋め込んで、コミュニケーションデータを変更する方法を示す図である。 本発明の第４の実施の形態における情報処理装置の処理手順を説明するためのフローチャートである。 コミュニケーションのモードが切替わるときの表示画面の一例を示す図である。 ＳＤＰ記述でａｔｔｒｉｂｕｔｅを拡張して、メディア表示に関する情報を送信する場合のＳＩＰシグナルの一例を示す図である。 レイアウト１の定義データの一例を示す図である。 図３１に示すＳＤＰ記述および図３２に示すレイアウト１の定義データに基づいて表示された画面の一例を示す図である。

符号の説明

１ コンピュータ本体、２ ディスプレイ、３ スピーカ、４ マイク、５ カメラ、６ 赤外線ポート、７ 外部ＡＶ入力端子、７−１ 音声外部入力端子、７−２ 映像外部入力端子、８−１ 音声外部出力端子、８−２ 映像外部出力端子、９ 外部スピーカ端子、１０ リモコン、１１ ＣＰＵ、１２ ＲＯＭ、１３ ＲＡＭ、１４ ＡＶセレクタ、１５ ネットワークデバイス、１６ ＴＶチューナ、１７ ｍｐｅｇ４デコーダ、１８ ｍｐｅｇ４エンコーダ、１９ ｍｐｅｇ２デコーダ、２０ ｍｐｅｇ２エンコーダ、２１ 入力装置、２２ 出力装置、２３ 通信装置、２４ エンコーダ、２５ デコーダ、３１ ＧＵＩ部、３２ コミュニケーション管理部、３３ 入力制御部、３４ 出力制御部、３５ エンコード部、３６ デコード部、３７ データ送信部、３８ シグナリング部、３９ データ受信部、４０ 通信部、１０１ 数字キー、１０２ 発信キー、１０３ 切断キー、１０４ 十字キー、１０５ 決定キー。

Claims (14)

1. 外部装置との間でデータの送受信を行なう通信手段と、
   ユーザからの入力ソースの切替え指示を入力するインタフェース手段と、
   前記インタフェース手段によって入力された入力ソースの切替え指示に応じて、入力ソースを切替えてデータを入力して前記通信手段を介して前記外部装置に送信し、前記入力データの種類または前記入力データの種類の組合わせを識別するための識別情報を前記通信手段を介して前記外部装置に送信する制御手段とを含む情報処理装置。
2. 前記制御手段は、入力装置を選択して前記入力ソースを切替えてデータを入力する入力制御手段と、
   前記外部装置とのメディア通信を制御するシグナリングによって、前記入力データの種類または前記識別情報を前記通信手段を介して送信するシグナリング手段とを含む、請求項１記載の情報処理装置。
3. 前記シグナリング手段は、セッション・ディスクリプション・プロトコルによって記述された前記入力データの種類または前記識別情報を前記外部装置に送信する、請求項２記載の情報処理装置。
4. 前記制御手段はさらに、前記入力制御手段によって切替えられたデータに応じてエンコーダを選択してコーデック処理を行なわせるエンコード手段を含み、
   前記シグナリング手段は、コーデック処理に関する情報を前記外部装置に送信する、請求項２または３記載の情報処理装置。
5. 前記シグナリング手段は、前記入力制御手段によって切替えられたデータに応じて出力形態を指定する情報を前記外部装置に送信する、請求項２〜４のいずれかに記載の情報処理装置。
6. 前記制御手段は、入力装置を選択して前記入力ソースを切替えてデータを入力する入力制御手段と、
   前記入力制御手段によって入力されたデータおよび前記入力データの種類または前記識別情報を前記通信手段を介して前記外部装置に送信するデータ送信手段とを含む、請求項１記載の情報処理装置。
7. 前記データ送信手段は、リアルタイム・トランスポート・プロトコルパケットのペイロードタイプを用いて、前記入力データの種類または前記識別情報を前記外部装置に送信する、請求項６記載の情報処理装置。
8. 外部装置との間でデータの送受信を行なう通信手段と、
   前記通信手段を介して前記外部装置から受信したデータの種類または受信データの種類の組合わせを識別するための識別情報を抽出し、前記受信データの種類または前記識別情報に応じて前記受信データの出力を制御する制御手段とを含む情報処理装置。
9. 前記制御手段は、前記外部装置とのメディア通信を制御するシグナリングによって、前記受信データの種類または前記識別情報を受信するシグナリング手段と、
   前記受信データの種類または前記識別情報に応じて前記受信データの出力を制御する出力制御手段とを含む、請求項８記載の情報処理装置。
10. 前記シグナリング手段は、セッション・ディスクリプション・プロトコルによって記述された前記受信データの種類または前記識別情報を受信する、請求項９記載の情報処理装置。
11. 前記制御手段はさらに、前記シグナリング手段によって受信されたコーデック処理に関する情報に応じてデコーダを選択してコーデック処理を行なわせるデコード手段を含み、
    前記出力制御手段は、前記デコード手段によってデコードされたデータの出力を制御する、請求項９または１０記載の情報処理装置。
12. 前記出力制御手段は、前記シグナリング手段によって受信された出力形態を指定する情報に応じて、出力装置の出力形態を変更してデータを出力させる、請求項９〜１１のいずれかに記載の情報処理装置。
13. 前記制御手段は、前記通信手段を介して前記受信データおよび前記受信データの種類または前記識別情報を受信するデータ受信手段と、
    前記受信データの種類または前記識別情報に応じて前記受信データの出力を制御する出力制御手段とを含む、請求項８記載の情報処理装置。
14. 前記データ受信手段は、ペイロードタイプを用いて前記受信データの種類または前記識別情報を指定したリアルタイム・トランスポート・ストリームパケットを受信する、請求項１３記載の情報処理装置。

Images