JP4791213B2 - 通信装置、通信方法及びプログラム - Google Patents

Description

本発明は、通信装置及び通信方法に関し、特にコンテンツに関する情報を伝送する技術に関する。本発明はさらに前記通信方法をコンピュータに実行させるプログラムにも関する。

近年、ネットワークの発展に伴い、電話技術を基礎とする様々なタイプの通信装置が開発されてきた。特に、カメラ機能を用いて作成した写真画像をメールに添付して送信する機能や、通話時に視覚的なデータをやり取りすることにより実現されたテレビ電話機能を内蔵するものも開発されている。

一般に、通信装置を用いて通話をする場合には、通話相手に対して通話するための材料を事前に提供しておいた方が、通話が円滑に進むことが多い。例えば、特定の写真画像について話し合うという場面においては、その写真画像のデータをメール等を用いて事前に送信しておくことにより、通話の円滑化を図ることができる。

ところが、写真画像のデータをメール等で事前に送信する行為と、通話を行う行為は別個の装置によってなされていたために、通話者にとっては面倒であるという問題があった。

このような通話を円滑化するための事前の材料提供を容易にした一例としては、特許文献１の例が挙げられる。特許文献１では、発呼者が、着呼者に対して聞かせたい着信メロディを指定して発呼を行うことが出来る携帯電話システムを提案しており、着呼者は着信メロディを聞き分けることにより、発呼者の意図の一部を事前に理解し、通話を行うことが出来る。
特開２００５−１６００２３号公報

しかし、特許文献１の従来例では、事前に通知できるのは着信メロディだけであり、着信メロディより豊富な情報量を有する写真画像などのデータを通知できるわけではないので、会話を円滑に進めるための材料を提供するには不十分である。

また、この従来例では、発呼側からの情報が着呼側に伝わるだけであり、その情報に対して着呼側がどのような印象を持ったかという情報が発呼側に事前に伝えられるわけではないので、発呼者にとって会話を円滑に進める材料を得ることはできなかった。また、例えば着呼者が機械の操作に疎いユーザの場合、事前に伝えたい情報を得るための操作を円滑に出来ない可能性があった。

本発明は、上記課題に鑑みてなされたものであり、通話相手に対して会話を円滑に進めるためのお互いの材料（事前情報）を簡易に転送できる通信装置および通信方法を提供することを目的とする。本発明は、このような通信方法をコンピュータに実行させるプログラムも提供する。

上記課題を解決するために、本発明による通信装置は、通信相手の通信装置の通信履歴情報を受信するための通信履歴情報取得アドレスを、前記通信相手を識別する識別子と関連付けて登録する通信アドレス登録手段と、前記通信アドレス登録手段によって登録された前記通信履歴情報取得アドレスを用いて通信履歴情報を取得する通信履歴情報取得手段と、前記通信履歴情報取得手段によって取得された通信履歴情報を提示する通信履歴情報提示手段と、前記通信履歴情報から発呼アドレスを決定する発呼アドレス決定手段と、前記通信履歴情報提示手段による通信履歴情報の提示に対する応答を受けると、前記発呼アドレス決定手段によって決定された前記発呼アドレスに、該通信履歴情報に関連する通信履歴関連情報を付加して発呼する発呼手段とを備えることを特徴とする。

前記通信履歴情報を保持する通信履歴情報保持手段をさらに備え、前記通信履歴情報提示手段は、前記通信履歴情報保持手段に保持された通信履歴情報を提示してもよい。このようにすれば、履歴を受信した瞬間だけでなく、後でいつでも発呼できるようになる。

前記通信履歴情報取得手段は、取得済みの通信履歴情報との差分情報のみを取得してもよい。

前記通信履歴情報提示手段は、前回提示された通信履歴情報と新たに取得した通信履歴情報との差分を提示してもよい。

前記通信履歴情報提示手段は、所定の最近の期間中の通信履歴情報のみを提示してもよい。

本発明による他の通信装置は、コンテンツを保持するコンテンツ保持手段と、通信相手の通信装置にコンテンツを送信するコンテンツ送信手段と、前記コンテンツ送信手段によって送信されたコンテンツの視聴の履歴情報を前記通信相手の通信装置から取得するコンテンツ視聴履歴情報取得手段と、前記コンテンツ視聴履歴情報取得手段によって取得されたコンテンツ視聴履歴情報を、前記コンテンツ保持手段が保持するコンテンツと関連付けて提示するコンテンツ視聴履歴情報提示手段と、前記コンテンツ視聴履歴情報から発呼アドレスを決定する発呼アドレス決定手段と、前記コンテンツ視聴履歴情報提示手段による提示に対する応答を受けると、前記発呼アドレス決定手段によって決定された発呼アドレスに、該コンテンツ視聴履歴情報に関連するコンテンツ視聴履歴関連情報を付加して発呼する発呼手段とを備えることを特徴とする。

前記コンテンツ視聴履歴情報提示手段は、前記発呼アドレスを識別する発呼アドレス識別情報を、前記発呼アドレスを決定するのに用いられたコンテンツ視聴履歴情報に関連するコンテンツと関連付けて提示してもよい。このようにすれば、コンテンツごとに誰が見たかを確認できるようになる。

前記コンテンツ視聴履歴情報を保持するコンテンツ視聴履歴情報保持手段をさらに備え、前記コンテンツ視聴履歴情報提示手段は、前記コンテンツ視聴履歴情報保持手段に保持されたコンテンツ視聴履歴情報を提示してもよい。このようにすれば、履歴を受信した瞬間だけでなく、後でいつでも発呼できるようになる。

前記コンテンツと関連して提示される発呼アドレス識別情報が複数ある場合に、いずれか１つ、一部、または全部を選択する発呼アドレス選択手段をさらに備え、前記発呼手段は、前記発呼アドレス選択手段によって選択された発呼アドレスに発呼するようにしてもよい。このようにすれば、コンテンツを見た人が複数の場合、いずれかを選択するか、又は、３者間通話をすることができるようになる。

前記コンテンツ視聴履歴情報取得手段は、取得済みのコンテンツ視聴履歴情報との差分情報のみを取得してもよい。

前記履歴情報提示手段は、前回提示されたコンテンツ視聴履歴情報と新たに取得したコンテンツ視聴履歴情報との差分を提示してもよい。

前記コンテンツ視聴履歴情報提示手段は、所定の最近の期間中のコンテンツ視聴履歴情報のみを提示してもよい。

前記コンテンツは静止画コンテンツであり、前記コンテンツ視聴履歴情報は、視聴実行、ズームアップ、スライドショー開始、スライドショー一時停止及びスライドショー停止を含む、コンテンツに対する再生制御命令のうち少なくとも１つを含むようにしてもよい。

前記コンテンツは動画コンテンツであり、前記コンテンツ視聴履歴情報は、再生開始、一時停止、停止、早送り、巻き戻し及びスロー再生を含む、コンテンツに対する再生制御命令のうち少なくとも１つを含むようにしてもよい。

前記再生制御命令を含むコンテンツ視聴履歴情報は、関連するコンテンツを前記再生制御命令に関連付ける情報を含んでもよい。

本発明のさらに他の通信装置は、通信相手の通信装置からの発呼要求を着呼する着呼手段と、前記発呼要求に付加されたコンテンツ視聴履歴関連情報を提示するコンテンツ視聴履歴関連情報提示手段とを備えることを特徴とする。

前記コンテンツ視聴履歴関連情報提示手段によるコンテンツ視聴履歴関連情報の提示を、着呼処理と並列的に処理してもよい。このようにすれば、リンギングの間に履歴情報内容を提示できるようになる。

前記コンテンツ視聴履歴関連情報の提示方法を指示により切り替えるコンテンツ視聴履歴関連情報提示切替手段をさらに備えてもよい。このようにすれば、リンギングの間の内容提示で、複数の画像（例えば、アルバム）などを表示できる場合に、それを切り替えて内容を確認してからオフフックできるようになる。

前記通信相手の通信装置からコンテンツを受信するコンテンツ受信手段と、前記コンテンツ受信手段が受信したコンテンツを提示するコンテンツ提示手段と、前記コンテンツ提示手段によるコンテンツ提示のコンテンツ視聴履歴情報を作成するコンテンツ視聴履歴情報作成手段と、前記コンテンツ視聴履歴情報作成手段によって作成されたコンテンツ視聴履歴情報を前記通信相手の通信装置に送信するコンテンツ視聴履歴情報送信手段とをさらに備えてもよい。

本発明によれば、通話相手に対して会話を円滑に進めるためのお互いの材料（事前情報）を簡易に転送できる通信装置、通信方法、プログラムを提供できる。

本発明の通信装置を、図面を用いて詳細に説明する。

図１は、本発明の通信装置をネットワークに接続している状態を表す図である。通信装置１は、インターネットなどのネットワークに接続され、通信装置２と通信することでコミュニケーションを行うことが出来るものであり、典型的には、通信装置２に「電話」（ＳＩＰ：Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、を使うものを含む）をかける電話機である。

通信装置２は、インターネットなどのネットワークに接続され、通信装置１から「電話」がかかってきた場合に、それに応答（着呼）しコミュニケーションを行う。また、通信装置１と通信装置２の持つ「電話」機能は本質的に同じものであり、通信装置２から通信装置１に対して電話をかけることも出来る。

図２は、通信装置１の構成を示すブロック図である。通信装置１は、通信部１０１と、表示部１０２と、スピーカ１０３と、マイク１０４と、カメラ１０５と、映像音声処理部１０６と、リモコン受信部１０７と、コンテンツ入力部１０８と、ビデオ入力部１０９と、コンテンツＤＢ１１０と、電話帳ＤＢ１１１と、履歴ＤＢ１１２と、履歴取得部１１３と、公開処理部１１４と、通知送信部１１５と、呼制御部１１６と、操作処理部１１７とを備える。

通信部１０１は、ネットワークに対してデータを送信したり、受信したりすることが出来る。本質的には、ＩＰネットワークに接続できるイーサネットカードや携帯電話網に接続できるようにするための装置およびそれを制御するためのドライバソフトウェアである。

表示部１０２は、ユーザに対し様々な情報を視覚的に提供し、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ−Ｒａｙ Ｔｕｂｅ）や液晶表示装置などである。また、外部の表示装置とＶＧＡ（Ｖｉｄｅｏ Ｇｒａｐｈｉｃｓ Ａｒｒａｙ）ケーブルなどビデオ信号を伝えるケーブルなどで構成されてもよい。

スピーカ１０３は、ユーザに対し様々な情報を音声で提供し、一般に使われるスピーカー部品と本質的に同様であってもよい。

マイク１０４は、ユーザが発生した音声などを入力するもので、一般に使われるマイク部品と本質的に同様であってもよい。

カメラ１０５は、ユーザ近辺の風景を電気信号に変換し入力するもので、一般に使われるものと本質的に同様であってもよい。

映像音声処理部１０６は、表示部１０２、スピーカー１０３、マイク１０４及びカメラ１０５とのやりとりを行う電気信号と、それに対応するデジタルデータとを相互変換する。デジタルデータの形式として特に限定するわけではないが、例えば、映像としてはＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）２、ＭＰＥＧ４など、音声としては、ＭＰＥＧＡｕｄｉｏ、Ｇ７１１、Ｇ７２６などに代表されるメディアフォーマットが様々存在し、一般的にはそれらに対応するコーデックチップという形で既に市場に流通している。

リモコン受信部１０７は、リモコン１１からの操作信号を受信し、操作処理部１１７に伝達する。リモコンの方式としてはＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）や家電製品協会フォーマットの赤外線信号を使うものが多く出回っているが、その他でもＢｌｕｅｔｏｏｔｈ（登録商標）など無線電波による通信のものがある。また、通信装置１を携帯電話機のように、筐体のパネル部分に直接ボタンを設置するなど、無線通信を用いない構成にしてもよい。

コンテンツ入力部１０８は、例えば、メモリカードなどに記録されたコンテンツのデータを読み取り、コンテンツＤＢ（Ｄａｔａ Ｂａｓｅ）１１０にそのデータを書き込む。また、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）端子を備える外部記憶装置などに接続するようにしてもよい。このようなメモリカードや外部メモリなどからのデータ入力手段を備える機器はすでに市場に多く流通しており、それらと本質的に同様である。典型的には、デジタルカメラで撮影された写真画像を入力する。デジタルカメラの写真データは、フォルダ構造などが規定されており、それに従って読み込むことになる。もっとも、写真画像などは、メモリカード経由である必要はなく、例えば、携帯電話機型の通信装置１に内蔵されるカメラで撮影し、直接コンテンツＤＢ１１０に取り込むような形式でも良い。

ビデオ入力部１０９は、ホームビデオカメラで撮影されたビデオ映像（音声を含む）や、その他のビデオ信号を入力し、その内容に関するデータをコンテンツＤＢ１１０に書き込む。入力端子としては、コンポジット端子や、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌａｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）１３９４端子などが使われる。信号がアナログ信号であるときは、市場に流通しているコーデックチップを使ってデジタルデータにエンコードしながらコンテンツＤＢ１１０に書き込むことになる。もっとも、ビデオ映像は、外部の生成機器から取り込む必要はなく、例えば、携帯電話型の通信装置１に内蔵されるカメラで撮影し、直接コンテンツＤＢ１１０に取り込むような形式でも良い。

コンテンツＤＢ１１０は、写真画像や、ビデオコンテンツおよび、それらのメタ情報などを管理する。実装としては、磁気記憶装置や、光ディスク装置、半導体メモリ装置などで構成され、データベースソフトウェアやファイルシステムなどのソフトウェアで制御される。

電話帳ＤＢ１１１は、「電話」をかける相手の情報を格納する。ＳＩＰアドレスなどを含むいわゆる電話番号や、相手の名称、愛称、公開してもよいかどうかのフラグ情報、その他の情報を格納する。実装の構成としては、コンテンツＤＢ１１０と本質的に同様である。

履歴ＤＢ１１２は、履歴取得部１１３が収集してきた履歴情報を格納する。格納される情報については、以降、詳細に説明する。実装としては、コンテンツＤＢ１１０などと本質的に同様である。

履歴取得部１１３は、通信部１０１から転送された履歴情報を、履歴ＤＢ１１２に格納する。実装の構成としては、典型的には、ＣＰＵ、バス、メモリなどで構成されるハードウェアおよび、その上で実行されるソフトウェアプログラムとして構成される。

公開処理部１１４は、通信部１０１から転送されたリモートからのリクエストに対し、コンテンツＤＢ１１０で管理されるコンテンツデータをレスポンスとして提供する。典型的には、ファイル転送を行うＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）サーバーであったり、ビデオなどのストリーミングコンテンツの場合は、ＲＴＳＰ（Ｒｅａｌ−Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）サーバーであったりする。ＨＴＴＰサーバーも、ＲＴＳＰサーバーも、既存の技術であり、すでに市場で多く流通しているため、これ以上詳細の説明を行わない。また、コンテンツ伝送に用いられるものであればどのようなプロトコルを用いたものでも良い。

通知送信部１１５は、コンテンツＤＢ１１０に新規にコンテンツが追加されたり、内容が更新された場合に、それを通知情報パケットとして生成し、通信装置２などリモートのユーザに伝える処理を行う。そのための通信プロトコルとしては、ＳＩＰのＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹの仕組みをそのまま使ってもよい。但し、同様の仕組みを持つものなら、どのような通信プロトコルを使っても良い。実装の構成としては、履歴取得部１１３などと本質的に同様である。

呼制御部１１６は、操作処理部１１７から指示された発呼、通信部１０１を経由してリモートからの発呼を受信する着呼を処理し、それに対応して映像音声処理部１０６の対応する機能を起動するなどの処理を行う。操作処理部１１７とは、「呼び出し中です。。。」の表示など、主にユーザインターフェースに関わるデータ通信を行う。また、映像音声データを映像音声処理部１０６と相互に転送する処理も行う。実装としては、ＳＩＰ機能を持つライブラリなどが既に市場で流通しており、それらと本質的に同様である。

操作処理部１１７は、いわばメインルーチンにあたる部分であり、カーソル位置などの状態管理を含め様々な処理を行う。リモコン受信部１０７からのユーザ操作を処理したり、呼制御部１１６との呼制御に関する指示を処理したりする。ユーザの指示に従って発呼する処理もここで行い、状態によっては関連履歴情報を関連付ける。また、取得した履歴から、表示すべき内容を抽出する処理も行う。表示部１０２において、通信装置１におけるユーザインターフェース部品をレイアウトして表示する指示も行う。実装としては、履歴取得部１１３などと本質的に同様である。

リモコン１１は、ボタン操作情報をリモコン受信部１０７に対して送信する。実装の構成としては、赤外線を使った多くのリモコンや、携帯電話機にリモコン機能を内蔵したものが市場に流通しており、本質的にはそれらと同様である。当然、リモコン１１及びリモコン受信部１０７の代わりに、又はこれらに加えて、リモコン１１のボタンと同様のものを通信装置１の筐体に直接備えてもよい。

図３は、通信装置２の構成を示すブロック図である。通信装置２は、通信部２０１と、表示部２０２と、スピーカ２０３と、マイク２０４と、カメラ２０５と、映像音声処理部２０６、リモコン受信部２０７および電話帳ＤＢ２１１と、履歴ＤＢ２１２と、履歴送信部２１３と、通知受信部２１５と、呼制御部２１６と、操作処理部２１７とを備える。

通信部２０１、表示部２０２、スピーカ２０３、マイク２０４、カメラ２０５、映像音声処理部２０６、リモコン受信部２０７、電話帳ＤＢ２１１および呼制御部２１６は、各々、図２に示す通信装置１の通信部１０１、表示部１０２、スピーカ１０３、マイク１０４、カメラ１０５、映像音声処理部１０６、リモコン受信部１０７、電話帳ＤＢ１１１および呼制御部１１６と本質的に同様である。

履歴ＤＢ２１２は、主にエージェント２１４での活動や、操作処理部２１７での操作履歴情報を格納する。格納される情報は、以降、詳細に説明する。実装の構成としては、磁気記憶装置や、光ディスク装置、半導体メモリ装置などで構成され、データベースソフトウェアやファイルシステムなどのソフトウェアで制御される。

履歴送信部２１３は、履歴ＤＢ２１２に格納された履歴情報から履歴情報パケットを生成し、通信部２０１を経由して通信装置１に送信処理する。実装の構成としては、典型的には、ＣＰＵ、バス、メモリなどで構成されるハードウェアおよび、その上で実行されるソフトウェアプログラムとして構成される。

エージェント２１４は、操作処理部２１７からの指示を受け、通信装置１の公開処理部１１４に対して、コンテンツ取得アクセスを行う、ＨＴＴＰクライアントや、ＲＴＳＰクライアントなどである。エージェント２１４は、一般にキャッシュ機構を持つ場合が多く、この場合には、キャッシュ上に目的のデータがある（キャッシュヒット）場合は、通信を発生させずにデータを返せるので、操作処理部２１７からはキャッシュにヒットしたかどうかを気にせずにエージェント２１４に指示することが出来る。ＨＴＴＰクライアント及びＲＴＳＰクライアントは、キャッシュの実装を含めて既存の技術であり、すでに市場で多く流通しているため、これ以上詳細の説明を行わない。また、コンテンツ伝送に用いられるものであればどのようなプロトコルを用いたものでも良い。

通知受信部２１５は、通信装置１の通知送信部１１５で生成された通知情報パケットを、通信部２０１を経由して受け取り、それを解釈して操作処理部２１７に伝える。そのための通信プロトコルとしては、ＳＩＰのＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹの仕組みをそのまま使うことが出来る。実装の構成としては、履歴送信部２１３などと本質的に同様である。

操作処理部２１７は、リモコン受信部２０７からのユーザ操作を処理したり、呼制御部２１６との呼制御に関する指示を処理したりする。表示部２０２において、通信装置２におけるユーザインターフェース部品をレイアウトして表示する指示も行う。実装の構成としては、履歴送信部２１３などと本質的に同様である。
リモコン２１は、リモコン１１と本質的に同様である。

図４は、本発明における通信装置の一例の外観図である。通信装置１も通信装置２もほぼ似た外観でよい。

図５は、本発明におけるリモコン１１または１２の外観図であり、電源ボタンの他、メニュー操作用のボタン、テンキー（携帯電話方式などで文字入力も行える）、ビデオ操作ボタンなどを備える。一部の機能のためのボタン操作は、階層的なメニューから選択するようになっていてもよい。

次に、通信装置１、通信装置２における、コミュニケーション機能について説明する。
図６は、通信装置１において、「電話」をかける相手を登録するための処理を示すフローチャートである。

通信装置１は、すでに電源が入っており、初期化などを終え、画面表示がされ、リモコン１１で画面を操作できる状態にあるものとする。

ステップＳ１０１において、まず登録用画面を呼び出す。リモコン１１の「メニュー」ボタンを押すことで、リモコン受信部１０７がその信号を受信し、操作処理部１１７が映像音声処理部１０６を使って図７のようなメニュー画面を呼び出すことが出来る（以降、リモコン操作から、ユーザインターフェース画面表示を行う際に、リモコン受信部１０７、操作処理部１１７、映像音声処理部１０６間で制御されるという記述を省略する）。ここで、リモコン１１のカーソルボタンなどを使い、「１．アドレス登録」を選択すると、図８のようなアドレス設定のための入力フォームが表示される。

ステップＳ１０２において、データを入力する。この例では名称に「おじいちゃん」を入力し、電話番号として、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）におけるＳＩＰアドレス「sip:g-chan@domain」を入力し、通信装置１内のコンテンツを「おじいちゃん」に公開してもよいことを示すフラグをセットし、登録を実行する。ここで、ＳＩＰは、従来の電話システムをＩＰネットワーク上で実現するための現在最も有望なプロトコルであり、近年普及しつつある。本実施例では一例としてＳＩＰベースの電話システムを仮定したが、Ｓｋｙｐｅ（登録商標）（http://www.skype.com/）や、ＩＳＤＮ電話システムにおける発呼信号など、電話システムを実現するどのようなプロトコルを用いても良い。

入力されたデータは、ステップＳ１０３にて電話帳ＤＢ１１１に登録される。図９は、電話帳ＤＢ１１１に登録されたデータ例の模式図である。この例では、テーブル属性として名称、アドレス、公開フラグのみを示したが、実際には、インデックス番号や、その他の属性データが追加されていても良い。

ステップＳ１０１〜ステップＳ１０３の処理は、リモコン１１、リモコン受信部１０７、操作処理部１１７、映像音声処理部１０６、電話帳ＤＢ１１１の代わりにそれぞれ、リモコン２１、リモコン受信部２０７、操作処理部２１７、映像音声処理部２０６、電話帳ＤＢ２１１を用いれば、通信装置２においても同様に実行することが出来る。

図１０は、通信装置１において、「電話」をかける（発呼する）ための処理を示すフローチャートである。

ステップＳ２０１にて、電話帳画面を呼び出す。図７のメニューから「２．アドレスリスト」を選択し、リモコン１１の「決定」ボタンを押すと、図１１のような画面が表示される。このとき、アドレス情報は電話帳ＤＢ１１１にあるので、それを取得し、リスト表示することになる。ここでは、名称のみを表示することとした。

ステップＳ２０２にて、例えば「１．おじいちゃん」を選択し、リモコン１１の「決定」ボタンを押すと、図１２のような画面が表示される。ステップＳ２０３にて、「電話をかける」を選択して、さらに、リモコン１１の「決定」ボタンを押すことで発呼が行われる。

このあと、着呼側では、呼び出し音などと供に「○○さんから電話です」というような画面表示を行い、着呼側ユーザがそれに応じることによって呼が確立し、コミュニケーションを行うことが出来る。着呼側の処理は、従来の電話機や携帯電話機などで同様の処理がすでに確立されている。

ステップＳ２０１〜ステップＳ２０３の処理は、リモコン１１、電話帳ＤＢ１１１の代わりにそれぞれ、リモコン２１、電話帳ＤＢ２１１を用いれば、通信装置２においても同様に実行することが出来る。

次に、通信装置１においてデジタルカメラの写真画像データを公開し、通信装置２などでそれを閲覧する場合について説明する。

図１３は、メモリカードに格納された写真画像データを公開するデータとして登録する処理を示すフローチャートである。

ステップＳ３０１にて、コンテンツ入力部１０８は、メモリカードに新しい写真データが保存されていることを検出し、操作処理部１１７に伝える。この処理は、パソコンではＰｎＰ（Ｐｌｕｇ ａｎｄ Ｐｌａｙ）などとして既に実現されている機能であり、ここでも同様の処理をすればよい。

ここでメモリカードは、これに限定するものではなく、画像が保存されている記憶装置であれば何でも良い。

ステップＳ３０２にて、操作処理部１１７は、電話帳ＤＢ１１１を検索して公開対象のリモートユーザを調べた上で図１４のような画面を表示し、当該ユーザに公開するかどうかを問い合わせる。公開対象のリモートユーザを表示するのは、予期せず見られたくない相手に見せてしまうミスを防ぐためである。ＹｅｓならＳ３０３に進み、Ｎｏなら終了する。

ステップＳ３０３にて、図１５のような画面を表示し、アルバム名を入力させ、登録を実行する。

ステップＳ３０４にて、コンテンツ入力部１０８が取得した写真データを、コンテンツＤＢ１１０に登録する。コンテンツＤＢ１１０の登録内容の例を図１６に示す。図１６はコンテンツのメタ情報であり、ファイル名や更新日時、更新ＩＤなどが含まれる。ここで更新ＩＤとは、以前の状態にくらべ変化があったかどうかを簡単に判定できるために導入したものであり、コンテンツＤＢ１１０内で最大の値を持つ更新ＩＤを調べれば、以前の状態からコンテンツＤＢ１１０に対して１つでも更新があったかどうかを簡単に判定できる。また、特定のファイルに対する更新ＩＤを調べれば、その特定のファイルが以前の状態から更新があったかどうかを個別に簡単に判定できる。また、コンテンツＤＢ１１０は、新着データがあるかどうかを示すフラグ情報も持つ。

ステップＳ３０５にて、新着フラグをセットする。このフラグをセットすることによって、通知送信部１１５は、通知すべき新着データがあることを判定できる。

なお、携帯電話型の通信装置１の内蔵カメラで撮影した写真データの場合は、撮影した時点でコンテンツＤＢ１１０に登録されているとみなしてよく、ステップＳ３０１〜ステップＳ３０５は、この時点の一連の動作で行われると考えればよい。また、ステップＳ３０２は、メニューなどから公開するための画面をボタン操作によって呼び出してもよい。このとき、結果的に、撮影という動作が新着フラグセットにつながることになる。

図１７は、新着の写真画像データがあることを通信装置２に通知する処理を示すフローチャートである。

ステップＳ４０１にて、通知送信部１１５は、コンテンツＤＢ１１０の新着フラグを調べることで、新着データがあるかどうかを判定する。新着フラグがセットされていればステップＳ４０２に進む。もし新着フラグがセットされていなくても、前回通知した時刻から所定の期間経過していれば、同じ内容の通知を再度行うためにステップＳ４０２に進んでも良い。例えば、ＳＩＰにおけるＮＯＴＩＦＹメッセージは、１８０秒程度に一度、再送信されるように実装することが推奨されている。

ステップＳ４０２にて、新着フラグをリセットし、通知コンテンツ最大数Ｎ、カウンタｉ、一時リスト領域Ｌを初期化し、ループに入る。

ステップＳ４０３にて、コンテンツＤＢ１１０内で最も新しいものから順番に選択し、Ｌに追加する。この時、更新ＩＤの値が大きいものから見つけていくことになる。
ステップＳ４０４、Ｓ４０５にて、カウンタをインクリメントし、もし通知コンテンツ最大数Ｎを超えていなければステップＳ４０３〜ステップＳ４０５を繰り返す。もっとも、コンテンツＤＢにそれ以上のコンテンツ数がなければ繰り返さない。

ステップＳ４０５のループを抜けたら、ステップＳ４０６にて、Ｌを元に通知用のデータを生成する。例えば、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式のデータとして、図１８のようなデータにすることが出来る。ここで、report要素にupdate-id属性があるのは、この通知データを生成した時点での最新更新ＩＤが１０１３であることを示しており、従って、それ以前に通知データを送信した時点の状態から、新しい更新があったかどうかをこのデータで判定することができる。また、更新ＩＤは、update要素（ファイルまたはグループごとの更新情報概要を表す）や、action要素（個別の更新情報を表す）にも付けられており、それぞれの活動履歴が更新ＩＤを見ることによってその時間的順序、他の更新ＩＤとの関係などを簡便に判定できるようになっている。watcher要素は、対応するコンテンツを視聴したユーザを表し、この例では、#2.jpgコンテンツは、すでにおばさん（sip:oba@domain）によって視聴されたことを表す。

ステップＳ４０７にて、通知送信部１１５は、電話帳ＤＢ１１１から公開フラグがYであるアドレスを取得する。例えば、おじいちゃん（sip:g-chan@domain）を取り出す。また、Ｓ４０９のループ後、次はおばさん（sip:oba@domain）が取り出される。

ステップＳ４０８にて、取り出されたアドレスに対応してパケット化し、通信部１０１経由で送信する。例えば、図１８をＳＩＰのＮＯＴＩＦＹメッセージとしてパケット化すると、図１９のようになる。

ステップＳ４０９にて、適切なアドレスに対し全て通知されるまで繰り返す。
ここで、カメラ付き携帯電話型の通信装置１の場合には、これらの処理によって結果的に、写真を撮影した時点で、自動的にその活動履歴が通信装置２などに通知されることになる。

図２０は、通信装置２における通知メッセージの処理を示すフローチャートである。
ステップＳ５０１にて、通知受信部２１５にて、図１９で表される通知メッセージを受信し、解釈して、操作処理部２１７に伝える。

ステップＳ５０２にて、操作処理部２１７は、図２１で表されるような画面を表示し、ユーザが「はい」を選択した場合には、ステップＳ５０３にて、写真閲覧をする。例えば、ＨＴＴＰによるコンテンツ取得を行う場合には、エージェント２１４のＨＴＴＰクライアント機能を使い、通信装置１の公開処理部１にアクセスして写真コンテンツをダウンロードしてきて、操作処理部２１７は、映像音声処理部２０６に対してレイアウト表示、および、ユーザインターフェース処理をする。

図２２は、ステップＳ５０３の写真閲覧において、履歴情報生成についての処理を示すフローチャートである。

ステップＳ６０１にて、ユーザが操作し、ステップＳ６０２にて、その操作内容によって操作履歴を履歴ＤＢ２１２に格納し、ステップＳ６０３にて、履歴履歴フラグをセットする。履歴送信部２１３は履歴の送信を実行することになる。

例えば、図２３に示されるような操作では、画像データを取得したときや、スライドショーを開始したときや、特定の画像で一時停止したときなどに操作履歴データが生成され、履歴ＤＢ２１２に格納される。履歴ＤＢ２１２に格納されたデータの例を、図２４に示す。履歴データには、対象ファイルや操作の種類や、グループ名、履歴ＩＤ、送信履歴ＩＤが含まれる。操作の種類には、取得や、単純な視聴、ズームアップ、スライドショー開始、スライドショー一時停止、スライドショー停止などが含まれてもよい。履歴ＩＤは、更新ＩＤと同じ発想で導入されたものであり、履歴操作１つ１つに割り当てられ、その時間的順序などを簡単に区別することが出来る。送信履歴ＩＤは、ある履歴送信において最近の履歴ＩＤであり、その送信履歴ＩＤを持つ履歴情報パケットにより実際に送信された（リモート側に伝わっている）ことを表す。従って、まだ送信されていない履歴の場合には、その送信履歴ＩＤは設定されていないことになる。また、同じ送信履歴ＩＤを持つファイル群はある種の集合を形成するとみなせる。

ステップＳ６０４にて、終了操作をするまでステップＳ６０１〜ステップＳ６０３を繰り返す。

ここで、ステップＳ６０３とステップＳ６０４の順番により、履歴送信の特徴が変わる。すなわち、ステップＳ６０３をＳ６０４の前に実行すると、操作のつど履歴の更新が履歴送信部２１３に伝わることになり、リアルタイムで通信装置１に伝わる反面、まとまったデータがないため、ある集合を一括して扱うことが難しくなる。ステップＳ６０３をステップＳ６０４の後に実行すると、それまでの操作履歴を一括して同じグループの履歴として扱い、同じ送信履歴ＩＤとして送信するため、履歴データ受信側では、同じ送信履歴ＩＤを持つ履歴操作をグループとして扱うことが簡単になる。

図２５は、通信装置２の履歴ＤＢ２１２に格納された履歴情報を通信装置１に送信するための処理を示すフローチャートである。

ステップＳ７０１にて、履歴送信部２１３は、履歴ＤＢ２１２の履歴フラグがセットされるのを待つ。但し、通知送信処理でのＳ４０１と同様に、所定の期間後、前回と同じ履歴を送るようにしても良い。

ステップＳ７０２にて、履歴フラグをまずリセットし、履歴データの一時リスト領域Ｌを初期化する。

ステップＳ７０３にて、履歴ＤＢ２１２の中で適切な履歴を選択する。ここで適切な履歴とは次のようなものを指す：送信履歴ＩＤが設定されていないか、設定されていないものがなければ最新の送信履歴ＩＤを持つもの；リストＬには設定されていないもの；その他アプリケーションの仕様により、履歴情報として有用とされるもの。適切なものがなければ、ステップＳ７０５に進む。

ステップＳ７０４にて、選択された履歴がＬに追加され、ステップＳ７０３から繰り返す。

ステップＳ７０５にて、Ｌを元に履歴データを生成する。履歴データの例を図２６に示す。report要素にhistory-id属性が設定されており、これが送信履歴ＩＤを示す。従って、同じhistory-id属性値を持つ通知データ内の履歴情報は、ある特定のグループを形成するとみなすことが出来る。

ステップＳ７０６にて、通信部２０１を経由して履歴データを送信する。履歴データパケットの例を図２７に示す。

図２８は、通信装置１の履歴取得部１１３における履歴データ受信処理を示すフローチャートである。

ステップＳ８０１にて、履歴取得部１１３は、履歴データパケットを受信し、解釈して、ステップＳ８０２にて、履歴ＤＢ１１２に格納する。履歴ＤＢ１１２に格納されたデータの例を図２９に示す。図２４で表されたデータとほとんど同じだが、誰の操作履歴かを表す「ユーザ」という属性が追加されている。これは、コンテンツを視聴するユーザが「おじいちゃん」だけでなく、「おばさん」である場合もあり、それらを区別して扱えるようにするためである。また、送信履歴ＩＤは、受信履歴ＩＤと言い換えている。

次に、上記のようにして履歴ＤＢ１１２に蓄積された履歴データを確認し、それを元にコミュニケーションに活用する状況について説明する。

図３０は、蓄積された履歴情報を確認し、それと関連した写真を閲覧する処理を示すフローチャートである。

ステップＳ９０１にて、コンテンツリストを表示する。図７で表されるメニューから「３．コンテンツリスト」を選択し、リモコン１１の「決定」ボタンを押すと、図３１のような画面が表示される。

この画面例において、左側に写真画像のサムネイルが並び、だれから視聴されたかのマークが付けられている。「ｇ」はおじいちゃんから視聴されたことを示し、「ｏ」はおばさんから視聴されたことを示す。このマーク付けは一例であって、これに限定するものではない。ユーザに対応する色を予め決めておき、画像の枠の色をその色にすることによって示しても良いし、カーソルの位置によって一定時間後に一時的ウィンドウ（バルーン表示、ツールチップ）を開いて表示しても良い。後述の詳細情報にのみ表示されるようなものでも良い。その下には、カーソルで選択されている画像に対する詳細情報が表示される。ここでは、視聴履歴の詳細についてのみ表示した。

画面右側には、これらのコンテンツリスト全体と関連して行える操作メニューが並ぶ。例えば、「おじいちゃん履歴」とは、これを選択すると、図２７のような履歴情報を元に、そのとおりの視聴を再現するような再生を行う。結果的に、図２３のような画面遷移が再生される。この時、再生された部分の履歴は、今後履歴確認の画面では再生の対象から外すようにしても良い。そうすると、一度再生させて確認すると、次に別の履歴が到着するまで再生されないことになるため、常に新しい履歴を再生できることになる。

「おじいちゃん電話」とは、これらのコンテンツリストと関連して「おじいちゃん」電話をかけることができる。これらのコンテンツリストとは、例えば、それぞれのリモートユーザに対応する最新の受信履歴ＩＤで定義される履歴集合と関連するコンテンツとなる。

ここで「おじいちゃん…」「おばさん…」というボタンが表示されるのは、図９で示されるＤＢに、おじいちゃんとおばさんが登録されているからであり、その他に登録されているユーザがいれば、それも表示されることになる。対応するボタンがリモコンなどの操作によって選択されれば、図９より発呼先アドレスを決定することが出来る。

「３者電話」は、１対１の通話でなく、３人以上の間でコミュニケーションをする形態の電話をかける。この例では、「おじいちゃん」からの履歴と、「おばさん」からの履歴の２つを含むため、３者間通話を行うことで、同じ写真データを３人で共有してコミュニケーションを盛り上げることが出来る。３者間の通話自体はＴＶ会議システムなどですでに確立された技術であるため、詳細に説明しない。また、写真データなどの共有は、これまでの説明を同様に適用すればよい。特に、「３者」に限定せず、３人以上のユーザの中から２人以上のユーザを選択する一般的なユーザインターフェースを提供し、自分を合わせて３人以上で多人数電話をかけるようにしてもよい。

ステップＳ９０２にて、画面左側は、基本的に図２３で示される通信装置２におけるコンテンツ閲覧と同じように閲覧操作が行える。但し、コンテンツ自体は通信装置１のコンテンツＤＢ１１０に存在するため、通信装置２のエージェント２１４のようなものは必要なく、直接コンテンツにアクセスできる。ここで、「おじいちゃん電話」などのメニュー操作を行うことにより、表示されているコンテンツに興味があることを示した上で、リモートユーザに対して電話をかけることが出来る。ここでの「おじいちゃん電話」についても、図９のアドレステーブルにより発呼先アドレスを決定できる。

ステップＳ９０３にて、特定のコンテンツをカーソルに重ね、新たにサブメニューを表示してそこから「おじいちゃん」に電話する操作例を図３２に示す。「おじいちゃん電話」でなく、特定のコンテンツと関連付けて電話をかけると、コンテンツ内での重要度が明確になり、同じ（送信または受信）履歴ＩＤをリモートユーザと共有しても、特に、その中で話題にしたい写真画像を指定することが出来る。

発呼を実行し、呼び出し中の画面例を図３３に示す。真ん中に図３２の画面においてカーソルで選択された注目したい写真画像を表示し、両側には、それ以外の、同じ受信履歴ＩＤを持ちグループとみなされる他の画像を表示している。この画面において、カーソルなどで大きく表示する画像を切り替えることが出来ても良い。

呼び出し中の、発呼メッセージの例を図３４に示す。ここでもＳＩＰのＩＮＶＩＴＥを用いた例とした。この中で、X-History-IDとあるのが、受信（通信装置２にとっては送信）履歴ＩＤであり、話題としたいコンテンツ集合が定義される。この例では2005となる。また、subjectパラメータが指定されており、これはカーソルで指定された特に注目したい写真を特定することになる。

また、図３４の最下行に、X-SHARP-CTRLとあるのは、呼が確立した後、お互いの操作にて共有画像をお互いに切り替えることの出来るプロトコルを想定しており、そのシーケンスの概要を図３５に示す。このプロトコルで必須とされる機能は、互いの表示画像を切り替えるための「切り替えコマンド」を互いにやりとりできることであり、例えば、孫側端末で表示画像を切り替えると、それが、ネットワーク上を伝わって、おじいちゃん側端末でそのコマンドを受信して、表示画像を切り替え、逆も同じことが出来る。

図３６は、通信装置２にて着呼する場合の処理を示すフローチャートである。ステップＳ１００１にて、通信装置１からの発呼メッセージを受信する。ＳＩＰのＩＮＶＩＴＥメッセージの場合は、ＳＩＰで規定される方法により、以降、着呼処理が行われる。

ステップＳ１００２にて、X-History-IDで示される履歴IDに対応するコンテンツ集合を検索する。図２４にて表される履歴ＤＢ２１２を検索すると、対応するファイル群、および、注目しているファイルなどが特定できる。

ステップＳ１００３にて、特定されたファイル群などを元に呼び出し画面を表示、および、呼び出し音を発生する。呼び出し画面例を図３７に示す。

後は、通常の着呼処理を行えばよく、呼が確立したら、図３８のような画面が表示される。

このとき、X-History-IDで指定されたコンテンツを、通信装置１、通信装置２の両方で共有し、例えば同じ写真画像を右上に小さく表示させることが出来る。その他の写真画像はこの例では下側に並べられており、カーソルなどにより別の写真に切り替えることができる。その際は、前述の図３５で表されるようなプロトコルを用いてリモート端末の画面も切り替えることが出来る。また、写真画像は、右上に小さく表示させるのではなく、全画面であるとか、もっと大きく表示しても構わない。

ここで、受信履歴ＩＤ（＝他方端末での送信履歴ＩＤ）によって定義されるコンテンツ集合は、典型的にはそれ以前のタイミングに受け取った図２７の履歴情報などを元に検索するが、履歴情報パケットの送受信のタイミングはこれに限定するものではなく、図３４のINVITEによって発呼した後に、続けて図２７を送受信しても良い。その時は、例えば呼び出し中に図２７を受信すれば、呼び出し中画面（図３７の下側）に時間的経過とともに次々と表示するような感じになる。また、もっと遅く、呼の確立後に受信すれば、共有して静止画を見ている場合に（図３８の下側のサムネイルリスト）、次々と表示されるような感じになる。

また、ここで、共有される写真画像は、おじいちゃんの視聴履歴があるもののみを表示するとしたが、それに限らず、共有されていないものも含めて表示しても良い。このとき、例えば、視聴履歴のあるものとそうでないものを区別できるようなマーク（説明文があったり、枠の色が異なるなど）があれば、むしろ相手の見ていない写真で、かつ、お勧めのものがあれば、それを話題にしてコミュニケーションを円滑に進めることも出来る。

次に、コンテンツとして、写真画像ではなく、ビデオ映像を用いる場合について詳細に説明する。

ビデオ映像を用いる場合でも、前述の写真画像での説明のかなりの部分を共通に使うことが出来る。例えば、アドレス登録については同様の操作となる。ここではビデオ映像特有の部分の説明を行う。

まず、ビデオ映像データの登録部分が写真画像の場合とは異なる。ビデオ映像の場合は、デジタルデータとしてメモリカード上に存在していれば、写真画像の場合と同様の処理で実行できる。

しかし、外部の記憶装置に何らかの形で存在しており、それを通信装置１内部の記憶装置に、変換して転送するという特別な操作を伴うことも多い。

図３９は、外部のビデオ映像データを登録する処理を示すフローチャートである。写真画像の場合の図１３を置き換えることになる。

ステップＳ２３０１にて、ユーザはリモコン１１を操作し、ビデオコンテンツ登録のための画面を呼び出す。その画面例を図４０に示す。この過程で、電話帳ＤＢ１１１を検索し、誰に公開されるのかも表示しておくことで、予期せず見られたくない相手に見せてしまうミスを防ぐ。

ステップＳ２３０２にて、Ｙｅｓであれば、ステップＳ２３０３に進む。
ステップＳ２３０３にて、図４１のような画面を表示し、登録するビデオの名称を入力させ、ステップＳ２３０４にて、コンテンツＤＢ１１０に登録する。コンテンツＤＢ１１０に登録されたデータの模式図は図１６のとおり。また、多くの場合は、ビデオデータ（付随する音声を含む）はアナログ信号であり、それをコーデックによってエンコードし、同じくコンテンツＤＢ１１０にコピーされる。デジタルデータの場合であっても、同じエンコードしなおして同様の処理をしても良いし、再エンコードせずにそのままコンテンツＤＢ１１０にコピーしてもよい。
ステップＳ２３０５にて、新着フラグをセットする。Ｓ３０５と同様である。

次に、新着の通知の仕組みは同様であるので、写真閲覧の代わりにビデオ閲覧に関して説明する。

図２０のステップＳ５０３にて、写真閲覧ではなく、ビデオ閲覧と読み替える。
図２２はそのままビデオ閲覧についても当てはまり、ステップＳ６０１の操作に対応する画面が異なる。

ステップＳ６０１における、ビデオ閲覧の画面例を図４２に示す。この画面例では、停止状態からまず、再生を行い、４５秒後に巻き戻しを行い、３０秒の位置に戻って一時停止を行い、その後停止した。この時の履歴ＤＢ１１２の内容例を図４３に示す。操作の種類としては、取得や、単純に再生を開始した場合の他、一時停止、停止、早送り、巻き戻しなどのデータを記録することが出来る。図２４と異なるのは、ビデオの場合は再生位置によって映像および音声が違うので、「位置」属性があることである。また対象ファイルはＨＴＴＰではなく、ストリーミング再生に適したＲＴＳＰに対するＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）となっている。

図４２で示される履歴は、結果的に図４４で示される履歴データとなり、通信装置１に送信される。「位置」属性に対応するものとしてduration要素が含まれている。

通信装置１の履歴取得部１１３が受信した結果、履歴ＤＢ１１２には、図４５で示されるようなデータが格納される。

次に履歴確認において、写真閲覧の代わりにビデオ閲覧に関して説明する。
図３０におけるステップＳ９０２にて、写真閲覧をビデオ閲覧に読み替える。

ステップＳ９０２にて、ビデオ閲覧の画面例を図４６に示す。左上に、受信履歴ＩＤに対応するビデオの画面が表示される。特に、履歴ＩＤのリストの中でも注目していそうな位置を表示する。例えば、受信履歴ＩＤと同じ履歴ＩＤ（この場合2505）を持つ履歴要素では、durationの値が”00:00:30”となっており、その位置が注目されていると考え、それに対応する最も相応しい履歴要素pauseに対応する画像を表示している。その下には、通信装置２でのビデオ操作履歴がグラフとして表示されている。

図４７は、そのグラフの詳細説明図である。横軸は経過時間であり、コンテンツが追加された時刻、または、通信装置が通知を受け取った時刻、または、その後、初めて通信装置を操作した時刻などを原点とし、右端が現在時刻となる。縦軸は再生している位置のコンテンツ内の位置割合であり、全く再生していない場合を原点とし、上端が１００％（最後を再生している状態）となる。実線で表される「おじいちゃん履歴」を例にすれば、右肩上がりの部分が再生中、右下に折れている部分が巻き戻し、水平になっている部分が一時停止中となる。そして、白抜きの矢印は、現在画面表示されている時刻位置を示している。

図４６において、「おじいちゃん履歴」を選択すると、白抜き矢印の部分から履歴を再生するようにも出来、矢印をカーソルなどで動かすことによって、おじいちゃんの履歴において、好きな部分を再現することが出来、コンテンツを視聴しているおじいちゃんの気持ちをよりよく理解することが出来る。

次に、その画面から発呼する方法は写真の場合と同様である。
呼び出し中の画面についても、ビデオ閲覧と基本的に同じであり、そのまま適用することが出来る。

図４８は、呼が確立したときの画面例である。写真の場合と同じく、右上にビデオ映像を共有した状態でコミュニケーションを実行できる。履歴閲覧時と同じように、履歴グラフを表示することも出来、履歴の再現などを出来るようにしても良い。また、この履歴グラフは履歴情報さえあればいいので、X-History-IDによって通知された通信装置２側でも同様に行うことが出来る。

以上、コンテンツの提供側から発呼を行う場合について説明したが、逆にコンテンツ閲覧側から発呼を行う場合もある。

図２３で示される写真閲覧の状態において、メニューを開いた状態の画面例を、図４９に示す。ここで「おじいちゃん」を選択すると、対応する写真履歴に関連付けて発呼することが出来る。この時点で同じく図２６で示される履歴情報は送信されているので、X-History-IDとして”2005”を指定することで写真履歴と関連付ける。（もし、ステップＳ６０３とステップＳ６０４が入れ替わっている場合は、メニューを出すときに、一度ステップＳ６０３に相当する処理を行っておく）
なお、これまでの記述において、全てのステップが必須というわけではなく、意図された目的を達成できるのであれば、不要としたり、順序を入れ替えたりする場合があってもよい。

実施例１において、通信装置１の履歴取得部が、通信装置２からの履歴通知を受信することで履歴を取得するのではなく、公開処理部へのアクセス履歴を元に取得する場合について説明する。

本実施例は、図１において、通信装置１を通信装置１ｂに置き換えて動作するものである。
図５０は、通信装置１ｂの構成を示すブロック図である。

通信装置１ｂは、通信装置１に比べ、履歴取得部１１３の代わりに履歴取得部１２３、公開処理部１１４の代わりに公開処理部１２４を備える。

履歴取得部１２３は、公開処理部１２４からの通知を受け、それを元に履歴データを生成して、履歴ＤＢ１１２に格納する。実装の構成としては、履歴取得部１１３と本質的に同様である。

公開処理部１２４は、公開処理部１１４の機能に加え、リモートからのアクセスを履歴として履歴取得部１２３に通知する機能を有する。実装としては、公開処理部１１４のログ出力機能の部分を修正し、シグナルやソケット、共有メモリなどのプロセス間通信を行って、履歴取得部１２３にその内容を通知する。実装の構成としては、公開処理部１１４と本質的に同様である。

通信装置１ｂの他の部分は、通信装置１の対応する部分と同様であり、説明を省略する。

また、処理の流れについては、履歴取得部１２３、公開処理部１２４に関わる部分のみを説明し、それ以外の部分は実施例１と同様であるので説明を省略する。

まず、実施例１と異なる処理は、公開処理部１２４におけるコンテンツ公開処理であり、ステップＳ５０３において公開処理部１１４が行っていた処理は、図５１で表されるフローチャートを適用する。

ステップＳ３１０１にて、公開処理部１２４で、公開処理部１１４と同じように処理を行う。すなわち、ＨＴＴＰサーバーであれば、ＨＴＴＰリクエストを受信して、対応するＨＴＴＰレスポンスを返す。ＲＴＳＰサーバーであれば、ＲＴＳＰリクエストを受信して、対応するＲＴＳＰレスポンスを返し、必要であれば、ストリーミングデータのトランスポート処理を行う。

ステップＳ３１０２では、履歴取得部１２３に対し、アクセスログを通知する。アクセスログの内容は、ＨＴＴＰリクエスト及びレスポンスから抽出できる内容であり、例えば、動作（ＧＥＴ／ＰＯＳＴ／ＳＥＴＵＰ／ＰＬＡＹ／ＰＡＵＳＥ／ＳＴＯＰなど）、対象ファイル（ＣＧＩなどのパラメータを含む）、アクセス日時、アクセス元のユーザ（WWW−Ａｕｔｈｅｎｔｉｃａｔｅヘッダや、ＣＧＩ引数などから取得）などとなる。

次に、実施例１と異なる処理は、履歴取得部１２３における履歴取得処理であり、図２８で表されるフローチャートの代わりに、図５２で表されるフローチャートを適用する。

ステップＳ３２０１にて、履歴取得部１２３は、公開処理部１２４からアクセスログが通知される。その内容は前述のとおりである。

ステップＳ３２０２にて、通知された履歴情報を履歴ＤＢ１１０に登録する。登録内容の例を図５３に示す。履歴情報を通信装置２から受信したわけではないので、受信履歴ＩＤなどは割り振られていないが、履歴確認の際のグルーピングにおいて、ある期間内にまとまった履歴に同じ受信履歴ＩＤを擬似的に設定することが考えられる。例えば、一定期間例えば、３０分以内に連続的にアクセスされたら同じ受信履歴ＩＤを割り振るなどとすればよい。

なお、履歴情報が共有されているわけではないので、図３４のようにX-History-IDなどで指定出来ないため、ＩＤを指定する代わりに履歴情報そのものを添付して発呼することになる。例えば、ＭＩＭＥ（Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎ）のｍｕｌｔｉｐａｒｔ方式を使ったものを図５４に示す。各呼制御部では、ＩＤから履歴情報を検索する代わりに、添付されている履歴情報を直接使うことになる。

本実施例では、主に写真画像を使った例としたが、ビデオ映像に関してもそのまま適用可能である。

なお、これまでの記述において、全てのステップが必須というわけではなく、意図された目的を達成できるのであれば、不要としたり、順序を入れ替えたりする場合があってもよい。

実施例１、実施例２は、通信装置内部に持つコンテンツに関しての興味に依存しているが、それに限定するわけではなく、第３の端末上のデータに依存しても良い。

図５５は、その１実施例を示す概要図である。
通信装置１ｃは通信装置２とコミュニケーション処理を行うが、同時にＲＳＳサーバーとのやり取りも行う。

ＲＳＳサーバーは、ＨＴＴＰサーバーの一種であるが、非常に簡単に日記などのコンテンツ（ブログと呼ばれる）を登録することが出来る。また、同時に、それらの新着情報をＲＳＳ（ＲＤＦ（Ｒｅｓｏｕｒｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ） Ｓｉｔｅ Ｓｕｍｍａｒｙ）というフォーマット済みテキストで配信することでプログラムが自動的に新着内容を検出することが出来るようになっているため、ＲＳＳリーダーというプログラムを利用することによりほぼリアルタイムに更新情報を検出することが出来る。ＲＳＳサーバー、ＲＳＳリーダーの例としては、「ｇｏｏブログ」「ｇｏｏＲＳＳリーダー」（http://blog.goo.ne.jp/index.php）などがあり、既に多数流通している。

図５６は、通信装置１ｃの構成を示すブロック図である。
通信装置１ｃは、通信装置１に比べ、電話帳ＤＢ１１１の代わりに電話帳ＤＢ１５１、履歴取得部１１３の代わりに履歴取得部１５３、操作処理部１１７の代わりに操作処理部１５７を備える。

電話帳ＤＢ１５１は、電話帳ＤＢ１１１と比べ、ＲＳＳサイトのアドレスをも記録する。履歴を取得する手段１５３は、ＲＳＳリーダーの機能を含み、ＲＳＳサイトの新着情報を検出して履歴ＤＢ１１２に履歴を格納する。操作処理部１５７は、操作処理部１１７と比べ、ＲＳＳサイトの入力機能を持ち、また、ＲＳＳ新着情報を画面表示する機能を持つ。その他は、基本的に通信装置１の対応する部分と本質的に同様である。

また、処理の流れについては、電話帳ＤＢ１５１、履歴取得部１５３、操作処理部１５７に関わる部分のみを説明し、それ以外の部分は実施例１と同様であるので説明を省略する。

まず、実施例１と異なる処理は、アドレス登録であり、図６のステップＳ１０１〜Ｓ１０３における画面構成、およびデータ項目が異なる。

ステップＳ１０１にて、表示される画面は、図５７のようになる。図８に比べ、ＲＳＳサイトのアドレスを入力する部分がある。ここに例えば、「http://…/taro.rdf」のように入力する。すると、電話帳ＤＢ１５１の内容の例は、図５８のようになる。

次に履歴取得部１５３の動作について説明する。履歴取得部１５３が、履歴情報を取得する処理を示すフローチャートを図５９に示す。

ステップＳ４２０１にて、履歴取得部１５３は登録されたＲＤＦファイルを取得する。この処理は一般のＲＳＳリーダープログラムと同じであり、詳細の説明を省略する。ここで取得されたＲＳＳファイルの例を図６０に示す。ＲＳＳファイルには、タイトルや、記事のＵＲＬ、更新時刻などが記録されており、ステップＳ４２０２にて、ＲＳＳファイルの内容と、すでに履歴ＤＢ１１２に記録されている情報とを比べ、違いがあれば、ステップＳ４２０３にて、履歴情報を履歴ＤＢ１１２に登録する。履歴ＤＢ１１２の登録内容の例を、図６１に示す。ここで、対象ファイルは日記テキストのＷＥＢサイトＵＲＬとなり、内容は「written」（書き込まれた）となっている。

次に、この履歴をどのように画面で確認するのかについて説明する。図３０のステップＳ９０１において、コンテンツリストから、ブログリスト（図７から、たどれるものとする）を表示すると、図６２のような画面が表示される。この例では「太郎：日記１３２」などがリスト表示される。あとは、「太郎：日記１３２」を選択した上で、電話をかけたり、内容を確認したりできるのは、実施例１などと同様である。

次に、日記コンテンツをもとに、電話をかける場合について説明する。基本的には、図３０のとおりであるが、ステップＳ９０３において、その時点で履歴情報を共有できていないので、実施例２と同様に、発呼メッセージに履歴情報自体をＭＩＭＥなどの方法で添付することになる。

図６３に、「太郎：日記１３２」を関連付けて電話をかける際の、発呼メッセージの例を示す。実施例２と同様に、通信装置２側でも履歴情報を共有して利用できるようになる。

なお、上記でＲＳＳを基にしたコンテンツのやりとりについて説明したが、それに限定するわけではなく、更新履歴を検出できるように履歴取得部を適切に実装できるならば、コンテンツは日記データ以外のどうようなデータでもよい。例えば、通常のＷＥＢページでもよく、その場合は、ＬＡＳＴ−Ｍｏｄｉｆｉｅｄレスポンスヘッダや、ＨＴＭＬテキストそのものを判断材料とすればよい。

本発明は、通信装置、通信方法及びプログラムに利用可能である。

本発明の通信装置をネットワークに接続している状態を表す図である。 通信装置１の構成を示すブロック図である。 通信装置２の構成を示すブロック図である。 本発明における通信装置の一例の外観図である。 リモコンの外観図である。 「電話」をかける相手を登録するための処理を示すフローチャートである。 メニュー画面を示す図である。 アドレス設定のための入力フォームを示す図である。 電話帳ＤＢ１１１に登録されたデータ例の模式図である。 「電話」をかける（発呼する）ための処理を示すフローチャートである。 電話帳画面を示す図である。 電話帳画面を示す図である。 写真画像データを公開するデータとして登録する処理を示すフローチャートである。 画像を公開するかどうかを問い合わせる画面を示す図である。 アルバム名を入力させ、登録を実行する画面を示す図である。 コンテンツＤＢ１１０の登録内容の例を示す表である。 新着の写真画像データがあることを通知する処理を示すフローチャートである。 通知データの例を示す図である。 通知パケットの例を示す図である。 通知メッセージの処理を示すフローチャートである。 写真閲覧を問い合わせる画面を示す図である。 履歴情報生成についての処理を示すフローチャートである。 写真閲覧の操作の一例を示す図である。 履歴ＤＢ２１２に格納されたデータの例を示す表である。 通信装置２の履歴ＤＢ２１２に格納された履歴情報を通信装置１に送信するための処理を示すフローチャートである。 履歴データの例を示す図である。 履歴パケットの例を示す図である。 履歴データ受信処理を示すフローチャートである。 履歴ＤＢ１１２に格納されたデータの例を示す表である。 蓄積された履歴情報を確認し、それと関連した写真を閲覧する処理を示すフローチャートである。 コンテンツリスト画面を示す図である。 コンテンツリスト画面で電話をかける様子を示す図である。 呼び出し中画面を示す図である。 発呼メッセージの例を示す図である。 共有画像をお互いに切り替えるシーケンスの概要を示す図である。 通信装置２にて着呼する場合の処理を示すフローチャートである。 呼び出し画面を示す図である。 呼が確立したときに表示される画面を示す図である。 ビデオ映像データを登録する処理を示すフローチャートである。 ビデオコンテンツ登録のための画面を示す図である。 登録するビデオの名称を入力する画面を示す図である。 ビデオ閲覧の画面を示す図である。 履歴ＤＢ１１２の内容の例を示す表である。 履歴データを示す図である。 履歴ＤＢ１１２に格納されるデータを示す表である。 ビデオ閲覧の画面を示す図である。 ビデオ操作履歴のグラフである。 呼が確立したときの画面を示す図である。 メニューを開いた状態の画面を示す図である。 通信装置１ｂの構成を示すブロック図である。 公開処理部１２４におけるコンテンツ公開処理を示すフローチャートである。 履歴取得部１２３における履歴取得処理を示すフローチャートである。 履歴ＤＢ１１０に登録される履歴情報の例を示す表である。 履歴情報を示す図である。 本発明の通信装置をネットワークに接続している状態を表す図である。 通信装置１ｃの構成を示すブロック図である。 アドレス登録画面を示す図である。 電話帳ＤＢ１５１の内容の例を示す表である。 履歴取得部１５３における履歴取得処理を示すフローチャートである。 ＲＳＳファイルの例を示す図である。 履歴ＤＢ１１２の登録内容の例を示す図である。 ブログリスト表示画面を示す図である。 発呼メッセージの例を示す図である。

符号の説明

１、２ 通信装置
１１ リモコン
１０１ 通信部
１０２ 表示部
１０３ スピーカ
１０４ マイク
１０５ カメラ
１０６ 映像音声処理部
１０７ リモコン受信部
１０８ コンテンツ入力部
１０９ ビデオ入力部
１１０ コンテンツＤＢ
１１１ 電話帳ＤＢ
１１２ 履歴ＤＢ
１１３ 履歴取得部
１１４ 公開処理部
１１５ 通知送信部
１１６ 呼制御部
１１７ 操作処理部

Claims (20)

1. 通信相手のコンテンツ視聴履歴情報を取得するコンテンツ視聴履歴情報取得手段と、
   前記コンテンツ視聴履歴情報取得手段によって取得されたコンテンツ視聴履歴情報を提示するコンテンツ視聴履歴情報提示手段と、
   前記コンテンツ視聴履歴情報から前記通信相手の発呼アドレスを決定する発呼アドレス決定手段と、
   前記コンテンツ視聴履歴情報提示手段によるコンテンツ視聴履歴情報の提示に対する応答を受けると、前記発呼アドレス決定手段によって決定された前記発呼アドレスに、該コンテンツ視聴履歴情報に関連する履歴関連情報を付加して発呼する発呼手段とを備えることを特徴とする通信装置。
2. コンテンツを保持するコンテンツ保持手段と、
   通信相手の通信装置にコンテンツを送信するコンテンツ送信手段と、をさらに備え、
   前記コンテンツ視聴履歴情報取得手段は、前記コンテンツ送信手段によって送信されたコンテンツのコンテンツ視聴履歴情報を取得することを特徴とする請求項１に記載の通信装置。
3. 前記コンテンツ視聴履歴情報を保持するコンテンツ視聴履歴情報保持手段をさらに備え、
   前記コンテンツ視聴履歴情報提示手段は、前記コンテンツ視聴履歴情報保持手段に保持されたコンテンツ視聴履歴情報を提示することを特徴とする請求項１または２記載の通信装置。
4. 前記コンテンツ視聴履歴情報取得手段は、取得済みのコンテンツ視聴履歴情報との差分情報のみを取得することを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
5. 前記コンテンツ視聴履歴情報提示手段は、前回提示されたコンテンツ視聴履歴情報と新たに取得したコンテンツ視聴履歴情報との差分を提示することを特徴とする請求項１乃至４のいずれか１項に記載の通信装置。
6. 前記コンテンツ視聴履歴情報提示手段は、所定の最近の期間中のコンテンツ視聴履歴情報のみを提示することを特徴とする請求項１乃至４のいずれか１項に記載の通信装置。
7. 前記コンテンツ視聴履歴情報提示手段は、前記発呼アドレスを識別する発呼アドレス識別情報を、前記発呼アドレスを決定するのに用いられたコンテンツ視聴履歴情報に関連するコンテンツと関連付けて提示することを特徴とする請求項１乃至６のいずれか１項に記載の通信装置。
8. 前記コンテンツと関連して提示される発呼アドレス識別情報が複数ある場合に、いずれか１つ、一部、または全部を選択する発呼アドレス選択手段をさらに備え、
   前記発呼手段は、前記発呼アドレス選択手段によって選択された発呼アドレスに発呼することを特徴とする請求項７記載の通信装置。
9. 前記コンテンツは静止画コンテンツであり、
   前記コンテンツ視聴履歴情報は、視聴実行、ズームアップ、スライドショー開始、スライドショー一時停止及びスライドショー停止を含む、コンテンツに対する再生制御命令のうち少なくとも１つを含むことを特徴とする請求項１乃至８のいずれか１項に記載の通信装置。
10. 前記コンテンツは動画コンテンツであり、
    前記コンテンツ視聴履歴情報は、再生開始、一時停止、停止、早送り、巻き戻し及びスロー再生を含む、コンテンツに対する再生制御命令のうち少なくとも１つを含むことを特徴とする請求項１乃至８のいずれか１項に記載の通信装置。
11. 前記再生制御命令を含むコンテンツ視聴履歴情報は、関連するコンテンツを前記再生制御命令に関連付ける情報を含むことを特徴とする請求項９または１０に記載の通信装置。
12. 通信相手の請求項１乃至１１のいずれか１項に記載の通信装置からの発呼要求を着呼する着呼手段と、
    前記発呼要求に付加されたコンテンツ視聴履歴関連情報を提示するコンテンツ視聴履歴関連情報提示手段とを備えることを特徴とする通信装置。
13. 前記コンテンツ視聴履歴関連情報提示手段によるコンテンツ視聴履歴関連情報の提示を、着呼処理と並列的に処理することを特徴とする請求項１２記載の通信装置。
14. 前記コンテンツ視聴履歴関連情報の提示方法を指示により切り替えるコンテンツ視聴履歴関連情報提示切替手段をさらに備えることを特徴とする請求項１２または１３に記載の通信装置。
15. 前記通信相手の通信装置からコンテンツを受信するコンテンツ受信手段と、
    前記コンテンツ受信手段が受信したコンテンツを提示するコンテンツ提示手段と、
    前記コンテンツ提示手段によるコンテンツ提示のコンテンツ視聴履歴情報を作成するコンテンツ視聴履歴情報作成手段と、
    前記コンテンツ視聴履歴情報作成手段によって作成されたコンテンツ視聴履歴情報を前記通信相手の通信装置に送信するコンテンツ視聴履歴情報送信手段とをさらに備えることを特徴とする請求項１２乃至１４のいずれか１項に記載の通信装置。
16. 前記コンテンツ受信手段によって受信したコンテンツをキャッシュするコンテンツキャッシュ手段をさらに備え、
    前記コンテンツ視聴履歴関連情報提示手段は、前記コンテンツ視聴履歴関連情報に関連するコンテンツが前記コンテンツキャッシュ手段にキャッシュされている場合、前記コンテンツキャッシュ手段にキャッシュされているコンテンツを提示することを特徴とする請求項１５に記載の通信装置。
17. 通信相手の通信装置のコンテンツ視聴履歴情報を取得するためのコンテンツ視聴履歴情報取得アドレスを、前記通信相手を識別する識別子と関連付けて登録するコンテンツ視聴履歴情報取得アドレス登録ステップと、
    前記コンテンツ視聴履歴情報取得アドレス登録ステップにおいて登録された前記コンテンツ視聴履歴情報取得アドレスを用いてコンテンツ視聴履歴情報を取得するコンテンツ視聴履歴情報取得ステップと、
    前記コンテンツ視聴履歴情報取得ステップにおいて取得されたコンテンツ視聴履歴情報を提示するコンテンツ視聴履歴情報提示ステップと、
    前記コンテンツ視聴履歴情報から発呼アドレスを決定する発呼アドレス決定ステップと、
    前記コンテンツ視聴履歴情報提示ステップにおけるコンテンツ視聴履歴情報の提示に対する応答を受けると、前記発呼アドレス決定ステップにおいて決定された前記発呼アドレスに、該コンテンツ視聴履歴情報に関連するコンテンツ視聴履歴関連情報を付加して発呼する発呼ステップとを備えることを特徴とする通信方法。
18. コンテンツを保持するコンテンツ保持ステップと、
    通信相手の通信装置にコンテンツを送信するコンテンツ送信ステップと、
    前記コンテンツ送信ステップにおいて送信されたコンテンツの視聴の履歴情報を前記通信相手の通信装置から取得するコンテンツ視聴履歴情報取得ステップと、
    前記コンテンツ視聴履歴情報取得ステップにおいて取得されたコンテンツ視聴履歴情報を、前記コンテンツ保持ステップにおいて保持されたコンテンツと関連付けて提示するコンテンツ視聴履歴情報提示ステップと、
    前記コンテンツ視聴履歴情報から発呼アドレスを決定する発呼アドレス決定ステップと、
    前記コンテンツ視聴履歴情報提示ステップにおける提示に対する応答を受けると、前記発呼アドレス決定ステップにおいて決定された発呼アドレスに、該コンテンツ視聴履歴情報に関連するコンテンツ視聴履歴関連情報を付加して発呼する発呼ステップとを備えることを特徴とする通信方法。
19. 通信相手の請求項１乃至１１のいずれか１項に記載の通信装置からの発呼要求を着呼する着呼ステップと、
    前記発呼要求に付加されたコンテンツ視聴履歴関連情報を提示するコンテンツ視聴履歴関連情報提示ステップとを備えることを特徴とする通信方法。
20. コンピュータに請求項１７、１８又は１９記載の通信方法を実行させるためのプログラム。

Images