(57)【要約】【課題】コンテンツの送受信に用いる従来のシステムでは、送信の際に手間がかかっており、受信にあたっては、受信者が受ける端末を自由に選べなかった。【解決手段】送信側端末に、他のユーザーに送信しようとするコンテンツを選択可能とする送信コンテンツ選択部と、送信しようとするコンテンツを選択した時の前後の入力情報を取り出す入力情報検出部と、取り出した入力情報から、他のユーザーのＩＤ等を抽出し選択可能に示す送信先選択部とを有し、受信側端末に、コンテンツの再生が可能な端末の一覧テーブルを選択可能に示す再生端末選択部と、再生端末への送信を要求する送信要求部と、送信されたコンテンツを再生するコンテンツ実行部とを有するコンテンツ送受信システムを構築する。【選択図】図１
2010237728.tif 000002
【特許請求の範囲】
【請求項１】
ユーザーが利用する端末間でコンテンツの送受信を行うシステムであって、
送信しようとする上記コンテンツを選択した時から一定時間前、一定時間後、又はその両方における入力装置からの入力情報を取り出す入力情報検出部と、
上記の取り出した入力情報から、他のユーザーのＩＤ又は他のユーザーのＩＤに関連付け可能な情報を抽出し、ユーザーが選択した上記コンテンツを送信する送信先になりうるＩＤ又はＩＤに関連付け可能な情報をリスト化して入力装置によって選択可能に示す送信先選択部と、
送信されるコンテンツの再生又は保存が可能な端末の一覧テーブルを、受信するユーザーの使用する端末に入力装置によって選択可能に示す再生端末選択部と、
再生又は保存を行う端末への上記コンテンツの実際の送信を要求する送信要求部と、
送信された上記コンテンツを受信端末において再生又は保存するコンテンツ実行部と、
を有することで、上記コンテンツの送信元ユーザーが送信先ユーザーの具体的アドレスを知らなくても送信されるユーザーに適した端末での受信を可能としたコンテンツ送受信システム。
【請求項２】
全ユーザーのＩＤを登録するユーザー登録データベースと、
上記ＩＤごとの通知を受ける端末又は宛先を登録する通知先データベースと、
上記コンテンツを受信するための端末について、上記ＩＤごとの個人用途の端末であるか共有用途の端末であるかを少なくとも分類する公共度の情報、個人用途である場合には携帯用端末であるか固定用端末であるか否かの情報、及びその端末で再生可能であるファイルの保存形式の情報、を含む端末情報を登録する受信端末登録データベースと、
コンテンツを保存するコンテンツデータベースと、
上記コンテンツデータベースに保存されたそれぞれの上記コンテンツについての、受信する端末の公共度に応じてそのコンテンツの再生を許可するか否かを分類（分岐・判断）するプライベートフラグ、そのコンテンツの保存形式と受信端末の機能との対応によりそのコンテンツが再生可能であるか否かを分類するファイルフォーマットフラグ、又はそれらの両方を含むコンテンツメタデータを保存するコンテンツメタデータデータベースと、
ユーザーが使用する端末に対して少なくとも文字情報の入力及び提示情報の選択を行いうる入力装置と、
上記コンテンツデータベースに登録された上記コンテンツの中から他のユーザーに送信しようとする上記コンテンツを入力装置によって選択可能とする送信コンテンツ選択部と、
上記入力装置により選択された送信先となるＩＤについての、上記通知先データベースに登録された通知を受ける端末又は宛先に対して、選択された上記コンテンツを受信可能か否かのリクエストを行う受信ユーザーリクエスト部と、
上記受信ユーザーリクエスト部からのリクエストを受けて、前記の通知を受ける端末又は宛先に、送信要求があった旨を送信する受信端末通知部と、
を有する請求項１に記載のコンテンツ送受信システム。
【請求項３】
各々のユーザーごとに存在する、上記コンテンツの送信先となりうる他のユーザーのＩＤを記録した送信先データベースを有し、
上記送信先選択部が、上記送信先データベースに記録された他のユーザーのＩＤについてＩＤ又は情報を抽出するものである請求項２に記載のコンテンツ送受信システム。
【請求項４】
上記送信先データベースが、送信元ユーザーが操作する端末内にあるものである請求項２に記載のコンテンツ送受信システム。
【請求項５】
上記送信先データベースが、送信元ユーザーの操作端末とネットワークを介して接続されたサーバに保存されたものである請求項３に記載のコンテンツ送受信システム。
【請求項６】
上記受信端末のそれぞれが上記コンテンツの再生又は保存が可能なオンライン状態であるか否かを検出する動作可能装置検出部と、
上記動作可能装置検出部が検出した受信端末の中に、送信先のユーザーの専用端末が含まれているか否かを判断し、含まれていれば上記コンテンツの再生又は保存が可能であると判断する受信ユーザー状況検出部と、
を有する請求項２乃至４のいずれか１項に記載のコンテンツ送受信システム。
【請求項７】
上記送信先選択部が表示する、送信先になりうるユーザーのＩＤとして、上記受信ユーザー状況検出部が、上記コンテンツの再生又は保存が可能であると判断された他のユーザーのＩＤを優先してリストアップする請求項６に記載のコンテンツ送受信システム。
【請求項８】
上記受信端末登録データベースが有するそれぞれの端末が再生可能である上記コンテンツのファイルの保存形式の情報が、再生可能な種類のファイルのファイル名に適式に付す拡張子で分類されるものであり、
上記コンテンツメタデータデータベースが有するファイルフォーマットフラグが、上記コンテンツデータベースにおいてファイルに適式に付されたファイル名の拡張子に対応するものである、請求項１乃至７のいずれか１項に記載のコンテンツ送受信システム。
【請求項９】
上記の通知を受ける端末はユーザーが携帯する端末であってその端末が存在する場所を特定可能な位置特定装置を有し、
上記再生端末選択部は、選択可能に表示させる端末の一覧テーブルの中に、上記位置特定装置で特定された端末が存在する場所の近傍に存在する共用の受信端末を含めることを特徴とする請求項１乃至８のいずれか１項に記載のコンテンツ送受信システム。
【請求項１０】
上記の通知を受ける端末は、少なくとも上記通知を受けた際にその端末が存在する場所の情報を、上記受信端末登録データベースを参照可能なサーバに送信する位置情報送信部を有し、
上記の場所の情報を受信したサーバは、上記受信端末登録データベースを参照することで、上記位置特定装置で特定された端末が存在する場所の近傍に存在する共用の受信端末をリストアップする周辺端末検索部を有し、
上記再生端末選択部は送信された共用の受信端末を含むリストを上記一覧テーブルの一部又は全部として表示する請求項９に記載のコンテンツ送受信システム。
【請求項１１】
上記再生端末選択部への通知にあたり、送信される上記コンテンツの上記ファイルフォーマットフラグから、その上記コンテンツを再生可能である端末を、上記受信端末登録データベースを参照することで抽出する対応端末抽出部を有する請求項１乃至１０のいずれか１項に記載のコンテンツ送受信システム。
【請求項１２】
上記コンテンツの送信にあたって、上記コンテンツの上記ファイルの保存形式が、送信先である上記コンテンツを再生する端末で再生できない保存形式である場合に、上記コンテンツのファイル形式をその端末で再生できる形式に変換するファイル形式変換部を有し、
上記コンテンツメタデータデータベースが、上記コンテンツの送信にあたって変換可能である変換先のファイルフォーマットの種類を示す変換ファイルフォーマットフラグを有する請求項１乃至１１のいずれか１項に記載のコンテンツ送受信システム。
【請求項１３】
上記再生端末選択部は、送信される上記コンテンツについて上記コンテンツメタデータデータベースに記録されたプライベートフラグが、個人用途に属する値である場合には、上記一覧テーブルで示す再生が可能な端末の一覧に、受信するユーザーの個人用途の端末のみを表示する請求項１乃至１２のいずれか１項に記載のコンテンツ送受信システム。
【請求項１４】
上記送信先データベースに他のユーザーを登録するにあたり、上記ユーザー登録データベースに登録されているＩＤを有するユーザーであるか否かを確認するユーザー確認部を有する請求項１乃至１２のいずれか１項に記載のコンテンツ送受信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ユーザー間でコンテンツの送受信を行うシステムに関する。
【背景技術】
【０００２】
現在、インターネットを通じて写真や動画などのコンテンツのファイルを送受信することが一般的に行われている。これは、ユーザー同士の端末間における送受信であったり、サーバに対して端末がリクエストすることによる送受信であったりする。
【０００３】
ユーザー間においてコンテンツを送受信する方法として例えば、インスタントメッセンジャーソフトを介して、ＩＰアドレスなどにより送信元が受信相手の端末を直接指定してファイルを送る方法がある。また、電子メールの添付ファイルを利用する方法は、サーバを介するものの、実質的にはユーザー同士の端末間での送受信を実現するものである。さらに、送信者が端末からＦＴＰサーバなどに一旦ファイルをアップロードしておき、その旨とアドレスやＩＤ等を受信者に通知して、受信者がダウンロードすることで送受信を実現する方法もある。
【０００４】
一方、サーバ側から多数のユーザーに対して送信する場合としては、ＨＴＴＰサーバによるＨＴＭＬファイルやＸＭＬファイルによるページの送信が一般的である。また、ライセンス管理された動画ファイルについて、受信者の端末がライセンス管理上受信可能なものであるか否かをサーバが判断した上で、送信者の端末からのリクエストに応えて動画ファイルを送信するといったことも行われている。
【０００５】
具体的なシステムとしては、例えば特許文献１及び２に記載のシステムが挙げられる。
特許文献１には、顧客情報データベースから連絡先情報を読み取った上で、ファックス又は電子メールの配信を行う情報配信支援システムが提示されている。この技術は、顧客の環境に応じて最適な受信環境を予め登録しておき、その情報を抽出して送信することで、顧客が望む方法で受信できるものである。
特許文献２には、電子ライセンスを受けたクライアントシステムからのリクエストに対して、サーバが確認の上で電子コンテンツをクライアントシステムによって取り出し可能とするシステムが記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−１６５７４８号公報
【特許文献２】特開２００８−１８１５１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、メッセンジャーを用いた場合は、その時点でオンラインになっている話し相手にしか送信することができず、送信相手が限定されてしまうという問題点がある。
【０００８】
また、電子メールの添付ファイルとして送信する場合にも多くの問題点がある。
まず、送信先アドレスの直接入力や、アドレス帳から選択するといったことが行われている。しかし、アドレスの直接入力を正確に行うことは熟練者でも手間であり、実際にはアドレス帳への登録が前提となるが、アドレス帳に記載のデータが多くなるほど選択に苦労することとなる。
また、電子メールでの送信は受信できる端末が限定される場合がある。携帯電話の電子メールアドレスである場合には、添付ファイルで送られても再生できない場合もある。一方で、携帯電話以外の電子メールアドレスに送られると、確認に時間を要し、その場では再生できずに、緊急性を要する場合には対応できないといったことが起こる。さらに、容量制限があり、場合によってはアカウントのスペースを過度に圧迫して機能不全を起こすこともある。
【０００９】
ＦＴＰサーバなどを用いたやりとりは、受信者の端末がダウンロードに対応していないことが多い。特に携帯端末の場合は、ほとんどの場合、受信することは不可能である。さらに、別途通知手段を設ける必要があり、そのために電子メールやメッセンジャーなどでの連絡を行うこととなり、結果として二度手間になることもある。
【００１０】
特許文献１のシステムでは、登録された情報の更新こそ可能であるものの、基本的にその配信先である顧客ごとの配信先は固定されており、受信者の時々刻々変化する状況にまで対応できるものではなかった。
【００１１】
特許文献２のシステムは、あくまでもユーザーのライセンスを確認された上でユーザーが自分のクライアントシステムにダウンロード可能とするものであり、ライセンスを受けるクライアントシステムが固定されてしまい、任意のクライアントシステムで見ることができないという問題があった。
【００１２】
すなわち、従来のシステムでは、送信にあたっては受信者がオンラインであるか否かに拘束されることが多く、また、受信者を指定する際にも間違えやすく、混乱を生じやすい状態にある。一方、受信にあたっては、受信者が受信する端末を選択することができず、更に受信端末がオンラインで無ければ受信できないなど、送信者が決定した送信方法に拘束される形で受信しなければならなかった。この発明は、これらの問題点を解決することを目的とする。
【課題を解決するための手段】
【００１３】
この発明は、
ユーザーが利用する端末間でコンテンツの送受信を行うシステムであって、
送信側端末に、
他のユーザーに送信しようとする上記コンテンツを入力装置によって選択可能とする送信コンテンツ選択部と、
送信しようとする上記コンテンツを選択した時から一定時間前、一定時間後、又はその両方における入力装置からの入力情報を取り出す入力情報検出部と、
上記の取り出した入力情報から、他のユーザーのＩＤ又は他のユーザーのＩＤに関連付け可能な情報を抽出し、ユーザーが選択した上記コンテンツを送信する送信先になりうるＩＤ又はＩＤに関連付け可能な情報をリスト化して入力装置によって選択可能に示す送信先選択部とを有し、
受信側端末に、
送信されるコンテンツの再生又は保存が可能な端末の一覧テーブルを、受信するユーザーの使用する端末に入力装置によって選択可能に示す再生端末選択部と、
再生又は保存を行う端末への上記コンテンツの実際の送信を要求する送信要求部と、
送信された上記コンテンツを受信端末において再生又は保存するコンテンツ実行部と、
を有するコンテンツ送受信システムにより、上記の課題を解決したものである。
【００１４】
そのシステムの細部、及び上記の部を実行するためのサーバは、具体的には以下のような構成が考えられる。前提として、送信側端末と受信側端末とは、下記の部を実行するために、少なくとも文字情報の入力及び提示情報の選択を行いうる入力装置を有する。
【００１５】
まず、送信側端末及び受信側端末と通信可能なサーバに、
全ユーザーのＩＤを登録するユーザー登録データベースと、
上記ＩＤごとの通知を受ける端末の宛先を登録する通知先データベースと、
上記コンテンツを受信するための端末について、上記ＩＤごとの個人用途の端末であるか共有用途の端末であるかを少なくとも分類する公共度の情報、個人用途である場合には携帯用端末であるか固定用端末であるか否かの情報、その端末で再生可能であるファイルの保存形式の情報、及びその端末の宛先の情報を含む端末情報を登録する受信端末登録データベースとを有する。
【００１６】
また、送信側端末と上記サーバとのいずれか、又は両方に、
コンテンツを保存するコンテンツデータベースと、
上記コンテンツデータベースに保存されたそれぞれの上記コンテンツについての、受信する端末の公共度に応じてそのコンテンツの再生を許可するか否かを分類（分岐・判断）するプライベートフラグ、そのコンテンツの保存形式と受信端末の機能との対応によりそのコンテンツが再生可能であるか否かを分類するファイルフォーマットフラグ、又はそれらの両方を含むコンテンツメタデータを保存するコンテンツメタデータデータベースとを有する。
【００１７】
さらに、送信側端末とサーバとのいずれかに、
上記入力装置により選択された送信先となるＩＤについての、上記通知先データベースに登録された通知を受ける端末が、選択された上記コンテンツを受信可能か否かのリクエストを行う受信ユーザーリクエスト部を有する。
【００１８】
さらにまた、上記サーバには、
上記受信ユーザーリクエスト部からのリクエストを受けて、前記の通知を受ける端末に、送信要求があった旨を表示する受信端末通知部を有する。
【００１９】
このような構成からなるシステムの具体的実行の際の内容は以下の通りである。
送信にあたっては、入力装置からの入力情報をキーロガーソフトなどである上記入力情報検出部で記録しておく。脈絡無くコンテンツを送信することは少ないため、送信するコンテンツを選択する前後の入力情報の中に、そのコンテンツを送信したい相手のＩＤやそのＩＤに関連する情報が含まれていることが多い。上記送信先選択部は、その入力情報から送信先のユーザーのＩＤ，又はＩＤに関連付け可能な情報を抽出し、入力装置から選択可能にすることで、従来行われていたメールアドレスの全入力や、膨大な件数になることもあるアドレス帳から宛先を捜索するといった作業を省略し、限られた件数のリストから選択するだけで送信準備が整うようにすることができる。
また、上記受信ユーザーリクエスト部及び受信端末通知部により受信者の登録された通知先端末に通知した上で送信が始まるため、メッセンジャーを用いた場合と異なり、受信者が所謂オンライン状態でなくても、送信作業を行うことができる。
【００２０】
一方、受信者は、予め通知先データベースに登録しておいた、自分が通知を受けるのに適した携帯電話などの通知を受ける端末又は宛先に、送信される旨の連絡が入りそれを確認するので、一方的な受信ではなく、そこから上記再生端末選択部で受信する端末を選ぶことができる。
また、上記再生端末選択部は、送信される上記コンテンツメタデータデータベースに記録された、上記のプライベートフラグ、ファイルフォーマットフラグで、受信可能として提示する端末の中から、適したものを選択して表示することができる。例えば、ホームビデオなどの仮定的なコンテンツについては、公共性がなく、個人的な端末でしか見ることは無いため、上記プライベートフラグは、個人用途に属する値となり、会議室などに設けられた共有の端末は受信する端末の一覧テーブルに挙げられない。また、送信されるコンテンツのファイル形式が、一部の携帯電話では再生できないような形式であったり、逆に特別の端末でなければ見られない形式であったりすることがある。上記コンテンツメタデータデータベースに記録されたファイルフォーマットフラグに対応した再生環境を有さないことが上記受信端末登録データベースに登録されている場合には、その端末を再生端末選択部が一覧テーブルから除外して表示する。これにより、受信できない端末を選んでしまうことがない。このように最適化された一覧テーブルから、送信者が自分の状況に合わせた端末を選択し、上記送信要求部がコンテンツデータベースに対して送信要求をすることで、受信者は送信されたデータを自分が希望する端末のコンテンツ実行部で再生、又は保存することができる。
【００２１】
上記の宛先とは、上記の通知を受ける端末が携帯端末である場合にはメールアドレスや、発話による音声案内、その他端末ごとにメッセージを受け取り可能な宛先を指定できる。一方、上記コンテンツの実際の送信にあたっては、受信する端末のＩＰアドレス等のネットワークアドレスを直接に宛先として利用することができる。
【００２２】
なお、コンテンツデータベース及びコンテンツメタデータデータベースは、送信するユーザーの端末内にある場合も、端末とネットワークを介して繋がった別の電子計算機上にある場合もある。また、上記の通知を発する上記受信ユーザーリクエスト部は、送信者の使用する端末にあってもよいし、サーバ側で処理してしまうものでもよい。
【００２３】
またこのシステムが、各々のユーザーごとに存在する、上記コンテンツの送信先となりうる他のユーザーのＩＤを記録した送信先データベースを有し、上記送信先選択部が、上記送信先データベースに記録された他のユーザーのＩＤについてＩＤ又は情報を抽出するものであると、送信の度に、システムの全ユーザーを記録している上記ユーザー登録データベースに照会することなく、送信される可能性が現実的なユーザーのみからなるリストを利用することが出来る。この送信先データベースは、送信元ユーザーが操作する端末内に保存する場合と、送信元ユーザーの操作端末とネットワークを介して接続されたサーバに保存する場合とがある。端末内に保存する場合には照会が容易である。一方、サーバ上に存在する場合は、送信元となる端末が固定されず、上記サーバに接続される環境であれば汎用的に用いることができるという利点がある。
【００２４】
またこのシステムが、上記受信端末のそれぞれが上記コンテンツの再生又は保存が可能なオンライン状態であるか否かを検出する動作可能装置検出部と、上記動作可能装置検出部が検出した受信端末の中に、送信先のユーザーの専用端末が含まれているか否かを判断し、含まれていれば上記コンテンツの再生又は保存が可能であると判断する受信ユーザー状況検出部とを有すると、送信先であるユーザーが速やかにその専用端末で受信することができることがわかる。これにより、送信者は、インスタントメッセンジャーなどでオンラインであることを確認するまでもなく、速やかに送信可能であると判断することができる。
【００２５】
上記のオンライン状態であることを検出することで、上記送信先選択部が表示する送信先になりうるユーザーのＩＤを優先してリストアップすることにより、送信先である可能性がより高いユーザーを適切に絞り込むことができる。ユーザーがオンライン状態であると、チャットやメッセンジャーソフトなど、他の手段によって、現時点で受信者となりうる可能性が高くなるためである。
【００２６】
上記受信端末登録データベースが有するそれぞれの端末が再生可能である上記コンテンツのファイルの保存形式の情報が、再生可能な種類のファイルのファイル名に適式に付す拡張子で分類されるものであり、上記コンテンツメタデータデータベースが有するファイルフォーマットフラグが、上記コンテンツデータベースにおいてファイルに適式に付されたファイル名の拡張子によると、ファイルヘッダ等を参照することなく、そのコンテンツを再生可能な端末であるか否かを速やかに判別することができる。ただしこの場合、拡張子は適式に付されている必要があり、その適式な拡張子が付されたファイルについて、その受信する端末は全て再生又は保存可能である必要がある。
【００２７】
またこのシステムが、上記の通知を受ける端末は携帯電話のようにユーザーが携帯する端末であって、その端末が存在する場所を特定可能なＧＰＳなどの位置特定装置を有し、上記再生端末選択部は、選択可能に表示させる端末の一覧テーブルの中に、上記位置特定装置で特定された端末が存在する場所の近傍に存在する共用の受信端末を含めるようにするものであると、受信者が携帯電話しか持っておらず、携帯電話では受信できないコンテンツを送信する旨の通知が来たときに、周辺にある共有の受信端末を用いて受信することができる。これは例えば、社内の至る処に共有端末が設置されているような場合や、社会インフラとして利用可能な程度にまで町中に一般利用可能な端末が設置されているような場合に、それらを利用して受信することが考えられる。
ただし、これらの共用の受信端末では、上記プライベートフラグが個人用途を示す値である上記コンテンツの再生はできない。このようにして送信する上記コンテンツとしては、余人に聞かれても問題の無い連絡事項の伝達、社内にある端末を会議などに利用するに当たり共有する資料、公共の場にある端末に表示する個人向けにカスタマイズした広告などが挙げられる。
【００２８】
上記のような、位置特定装置を有する場合、上記の通知を受ける端末は、少なくとも上記通知を受けた際にその端末が存在する場所の情報を、上記受信端末登録データベースを参照可能なサーバに送信する位置情報送信部を有し、
上記の場所の情報を受信したサーバは、上記受信端末登録データベースを参照することで、上記位置特定装置で特定された端末が存在する場所の近傍に存在する共用の受信端末をリストアップして、上記の通知を受ける端末へ送信する周辺端末検索部を有し、
上記再生端末選択部は送信された共用の受信端末のリストを上記一覧テーブルの一部又は全部として表示するようにすることが好ましい。
受信する端末の位置情報が必要になるのは、通知を受けた際に限られるためである。また、上記受信端末登録データベースを参照できるサーバにその位置情報を送信することで、サーバが位置を一元管理でき、速やかに、その位置情報の周囲にある共用の受信端末のリストアップが可能となる。受信端末が単独で管理するには、共用の受信端末の情報が膨大である場合があり、サーバで周辺端末を検索する方が低負荷だからである。
【００２９】
またこのシステムは、上記再生端末選択部が、送信される上記コンテンツの上記ファイルフォーマットフラグから、その上記コンテンツを再生可能である端末を、上記受信端末登録データベースを参照することで抽出して表示するようにすることで、実際には再生できない端末がリストに挙がることを防ぎ、受信者の利便性を向上させることができる。
【００３０】
またこのシステムは、上記コンテンツの送信にあたって、上記コンテンツの上記ファイルの保存形式が、送信先である上記コンテンツを再生する端末で再生できない保存形式である場合に、上記コンテンツのファイル形式をその端末で再生できる形式に変換するファイル形式変換部を有し、上記コンテンツメタデータデータベースが、上記コンテンツの送信にあたって変換可能である変換先のファイルフォーマットの種類を示す変換ファイルフォーマットフラグを有するものであると、そのままのファイル形式ではその受信する端末では再生できない場合でも、変換することで再生可能になり、利便性が大きく向上する。
例えば、動画ファイルでは圧縮コーデックを変換したり、縦横サイズを縮小したりすることで、制限のある端末でも再生可能になる場合がある。文書ファイルでは、ＰＤＦ形式などの汎用閲覧ソフトで閲覧可能な形式に変換することで再生可能となる場合がある。このファイル形式変換部は、コンテンツデータベース及びコンテンツメタデータデータベースが送信する端末にある場合には、送信する端末にあるとよく、これらデータベースがサーバにある場合には、サーバにあるとよい。送信の際に既に受信側が再生可能な形式で送ることができ、利用しやすくなるためである。ただし、上記コンテンツデータベース等が送信する端末にある場合でも、上記ファイル形式変換部をサーバに置いておくと、送信する端末の処理負荷を軽減することができる。送信する端末の演算能力が貧弱な場合には、ファイル形式の変換が困難である場合もあるからである。
【００３１】
またこのシステムの上記再生端末選択部は、送信される上記コンテンツについて上記コンテンツメタデータデータベースに記録されたプライベートフラグが、個人用途に属する値である場合には、上記一覧テーブルで示す再生が可能な端末の一覧に、受信するユーザーの個人用との端末のみを表示するものであると、共用端末では利用する可能性が無いのに、余分な端末が選択肢に現れることを防ぐことができ、受信者の手間を省くことができる。
【００３２】
またこのシステムは、上記送信先データベースに他のユーザーを登録するにあたり、上記ユーザー登録データベースに登録されているＩＤを有するユーザーであるか否かを確認するユーザー確認部を有するものであると、送信先としてシステムに登録されていないユーザーが提示されることがなく、送信元の端末に保存されている場合でも、エラーを生じることがない。
【発明の効果】
【００３３】
この発明により、上記コンテンツの送信元ユーザーが送信先ユーザーの具体的アドレスをはっきりと知らないような状況での、曖昧な宛先入力や、意図的でない宛先入力でも送信先ユーザーを決定し、又は容易に選択できるようにする。また、送信先ユーザーの現在いる場所やコンテンツの再生環境、保持する端末などを気にすることなく送信できる。さらに、送信先を直接入力するといった手間を省き、コンテンツの送信による情報の共有をスムーズに行うことができる。
【００３４】
一方、送信先ユーザーはコンテンツを再生する端末を自ら選ぶことができ、送信元ユーザーによる指定に縛られることなく私的公的の別や、再生環境の有無、端末の種別など、最適な環境でコンテンツを受け取ることができる。これにより、従来は送信先メールアドレスや指定されたソフトウェア等によって制限されていた再生環境の選択権を送信先ユーザーが得ることができる。
【００３５】
総合的には、送信元ユーザーも送信先ユーザーも、互いの操作、環境、個人情報が隠蔽され、細かい環境や手順を意識することなく、コンテンツの共有が図られる。
【図面の簡単な説明】
【００３６】
【図１】この発明にかかるシステム全体の概念図
【図２】送信端末側の実施形態の例を示すフロー図
【図３】サーバにおける通知段階の実施形態の例を示すフロー図
【図４】通知後の受信側端末の実施形態の例を示すフロー図
【発明を実施するための形態】
【００３７】
以下、この発明にかかるコンテンツ送受信システムについて具体的実施形態を示して詳細に説明する。図１にこの発明にかかるコンテンツ送受信システムの概要を示す。
このコンテンツ送信システムの基本的な構成は、コンテンツの送信元であるユーザーが操作する送信端末１と、送信先のユーザーがコンテンツを送信される旨の通知を受ける通知先端末３と、送信先のユーザーが実際にコンテンツを受け取る受信端末４と、これらの端末との間でネットワークを介して通信可能であり、後述する種々のデータベース機能と実行手段を有するサーバ２とからなり、それぞれが後述する機能のそれぞれを有する。ただし、この発明の実施にあたり、送信するコンテンツについて保存するデータベースなどは送信端末１とサーバ２とのどちらに存在してもよい。これらを、送信端末１とサーバ２との間のどちらに属しても良いコンテンツ収容部６としてまとめて記載する。なお、この他にも、送信端末１とサーバ２とのどちらに属していてもよい機能が存在し、これについては別途記載する。
【００３８】
この発明においてコンテンツとは、音楽ファイルや動画ファイル、文書ファイルなど、ネットワークを介してやりとりが可能なファイルであればその内容を問うものではない。その中でも特に、受信者への、訴求力や即時性が高く、一方で、再生する際にファイルの設定と端末の能力による縛りが強い動画ファイルの送受信について好適に使用することができる。
【００３９】
まず、送信端末１について説明する。この送信端末１とは、ネットワーク機能を有する情報端末であり、具体的には、パソコン、携帯電話、ワークステーションの他、上記コンテンツの把握と選択表示が可能な表示装置と、選択肢の選択や文字の入力ができる入力装置１１を有する装置であればよい。例えば、ネットワーク機能を有するゲーム機などでもよい。
【００４０】
この送信端末１におけるフローを図２に示す。まず、送信元ユーザーが送信端末１の使用を開始する（１０１）。文字入力や、テキストを含むハイパーテキストのリンクをクリックして閲覧するなどの入力を入力装置１１により行う（１０２）。この際に、入力情報検出部１３が、入力、選択された文字列を一時的に記憶する。この入力情報検出部１３とは、具体的には、キーロガーのような入力した文字を記録するソフトウェアや、ハイパーテキスト上のアクセス解析、ネットワーク上のパケットキャプチャなどのソフトウェアである。これにより、直接的又は間接的に入力された入力情報を記録する。これを、コンテンツが選択される（１０３）まで続ける。ただし、そこまでの全情報を記録しておくことは記憶容量と処理速度の点から現実的ではなく、コンテンツ選択までの直近の時間を１分〜５分程度定めて、それよりも時間が経過した情報は破棄する。
【００４１】
送信元ユーザーが、送信コンテンツ選択部１５により、コンテンツ収容部６にあるコンテンツＤＢ２５に記録されたコンテンツを選択する（１０３）。この送信コンテンツ選択部１５とは、コンテンツデータベース２５（以下、「データベース」を「ＤＢ」と略記する。）に保存されているコンテンツを、コンテンツメタデータＤＢ２６に記録されている、それぞれのコンテンツのメタデータに対応して、判別可能な状態で選択できるように提示するものである。具体的には、オフライン又はオンライン上におけるファイラーのようなソフトが挙げられる。
【００４２】
ここで、コンテンツＤＢ２５とコンテンツメタデータＤＢ２６について説明する。物理的には、送信端末１の中に含まれる場合と、ネットワークを介したサーバ２上に含まれる場合がある。その物は、磁気ディスクや不揮発性メモリなどの電子データとして情報を記録しておくことのできる媒体に記録した情報をデータベースとして参照可能としたものである。コンテンツＤＢ２５は、上記のコンテンツのデータそのものを記録するものである。そしてコンテンツメタデータＤＢ２６は、コンテンツＤＢ２５に保存されたそれぞれの上記コンテンツについての、受信端末４の公共度に応じてそのコンテンツの再生を許可するか否かを分類するプライベートフラグ、そのコンテンツの保存形式と受信端末の機能との対応によりそのコンテンツが再生可能であるか否かを分類するファイルフォーマットフラグ、又はそれらの両方を含むコンテンツメタデータを保存するものである。また、コンテンツメタデータとしてはこの他に、ユーザーごとに選択可能であるか否かの読み取りフラグ、送信可能かどうかの送信可能フラグなどを有していてもよい。コンテンツメタデータＤＢ２６に登録されるテーブルの例を表１に示す。また、上記表１中、上記の公共度を示す値として、プライベートフラグの例を示す。ここでは、１であれば私的なものを、０であれば公的なものを示す。また、タグとは検索の際に用いる識別符であり、ユーザーが登録の際に自由に付することができるものである。ファイルフォーマットフラグは、表１中に具体的に示す拡張子や、動画のエンコードフォーマットだけではなく、それぞれの端末で利用可能かどうかの可否を、別途定めた規格に基づいて０であれば利用不可、１であれば利用可といった具合に数値化したものである。例えば、提供元である特定のキャリア、特定のメーカの携帯電話、端末の利用契約形態、ペアレンタルコントロールのような設定形式、必要なソフトのインストールの有無などに対応したフラグを立てることが挙げられる。
【００４３】
【表１】
2010237728.tif 000003
【００４４】
上記の選択とは、コンテンツを送信先に送信する明確な意図をもった選択だけでなく、送信元ユーザー自身がそのコンテンツを閲覧、再生するために選択した場合も含む（１０４）。前者である場合は、入力情報検出部１３が、そこまでに蓄積した上記入力情報を取り出す（１０６）。後者である場合には、選択後も一定時間に亘って入力を受け付け（１０５）、その後に入力情報検出部１３が文字情報を取り出す。コンテンツを閲覧した後に、他人に対してそのコンテンツを共有しようとの発意が送信元ユーザーに生じることでこのような事態が起こりうる。
【００４５】
なお、送信のための意図的な選択である場合にも、選択後一定時間に亘って上記入力情報を記録して取り出してもよい。用途によってはコンテンツの選択前に前触れとなる入力をすることなく選択を行い、選択後に送信先をはっきりと入力する場合もあるからである。
【００４６】
この取り出された上記入力情報から、送信先選択部１４により、送信先の選択を行う（１１１〜）。この送信先選択部１４は、上記入力情報から送信先となりうる他のユーザーのＩＤ又は他のユーザーのＩＤに関連づけ可能な情報を抽出し、送信元ユーザーが送信しようとする送信先の一覧として、そのＩＤ、ＩＤに関連づけ可能な情報又はその両方（以下、まとめて「ＩＤ等」という。）を選択可能に示すものである（１１１）。ＩＤとは、この発明にかかるシステムを利用するにあたって割り振られる固有の文字列であり、ＩＤに関連づけ可能な情報とはユーザーが互いに判別しやすいように付けたニックネーム、又は、個人の名前又は組織の名称が挙げられる。上記コンテンツの選択の前後に入力されたこれらの文字列は、送信元ユーザーが意図して送信しようとする相手である蓋然性が高いためである。
【００４７】
上記送信先選択部１４は、上記文字情報を形態素解析し、含まれるＩＤ等と思われる文字列を全て抽出するものでもこの発明は成立する。ただし、それでは存在しないＩＤや意図しない選択先が抽出される可能性が高いため、確実にシステム利用者を示すＩＤ等であることを確認することが好ましい。
【００４８】
そのように確実性を期する手段としては、この発明にかかるシステム全体のユーザーを管理するサーバ２内のユーザー登録ＤＢ３１に直接リクエストして確認する手段が挙げられる。またその他に、送信元ユーザーと直接の関係があり、送信先ユーザーの候補となりうるユーザーのＩＤ等を記録した送信先ＤＢ２１を予め作成しておくという手段が挙げられる。この場合、上記の送信先選択部１４は、この送信先ＤＢ２１に記録されたＩＤ等のみを最初にリストアップする。これは電子メールソフトにおけるアドレス帳に相当する。
【００４９】
この送信先ＤＢ２１は、送信端末１にあってもよいし、サーバ２内にあってもよい。送信端末１内にある場合は、個人管理のアドレス帳としても利用可能であり、コンテンツ送信時にはそこを参照して速やかに送信先を決定できる。サーバ２内にある場合には、送信元ユーザーは送信にあたって利用する端末を制限されることなく送信先ＤＢ２１を利用できるという利点がある。使用時にはネットワークを通じてサーバ２から送信先ＤＢ２１の内容を読み込み、上記文字情報との対比から抽出を行う。
【００５０】
なお、上記の送信先ＤＢ２１に登録するにあたっては、サーバ２内のユーザー確認部３２が、上記のユーザー登録ＤＢ３１にアクセスして、そのＩＤ等が実際にシステムの利用者のＩＤとして実在しているか否かを確認する。また、送信先ＤＢ２１がサーバ２上にある場合には、システム利用者の変更に伴い、設定変更又はシステムからの削除があった利用者について、個々のユーザーの送信先ＤＢ２１を書き換える。
【００５１】
一方、送信先ＤＢ２１が個々のユーザーの送信端末１にある場合には、送信先選択部１４の実行時にも、現時点でそのユーザーが元の情報のままでシステムのユーザー登録ＤＢ３１に登録されているかを確認し、必要であれば変更を行うようにする。もし、変更ではなく、該当するユーザーが存在しない場合には、ユーザーが存在しない旨の返答を送信端末１へ返す。この場合、送信作業はここで終了する。
【００５２】
また、選択にあたって、送信先ＤＢ２１に未登録のユーザーに対して送信する場合も考えられる。このため、送信先選択部１４は、送信先ＤＢ２１内に送信元ユーザーが送信しようとする相手が存在しない場合には、上記のサーバ２内に登録された、このシステムの利用者を総合的に管理するユーザー登録ＤＢ３１に対して、公開してもよい設定となっているユーザーのＩＤ等をリクエストするものでもよい。同様のことは、送信先ＤＢ２１がシステムに存在しない場合でも可能である。この場合は、送信先選択部１４はユーザー登録ＤＢ３１に対して直接、該当するＩＤ等をクエリとして公開設定になっているユーザーの登録情報を検索する。登録されている情報の中に該当するものがあればそれをランキング付けして送信端末１に表示する。該当する者がなければ、ユーザーが存在しない旨の返答を送信端末１へ返す。この場合、送信作業はここで終了する。
【００５３】
上記送信先選択部１４の作用について続ける。
上記送信先ＤＢ２１を参照して抽出した確実性の高いＩＤ等について、上記文字情報内における出現回数を踏まえ、送信しようとするコンテンツに関連するランキングを生成する（１１２）。例えば、出現回数が多いＩＤ等は高いランキングとなり、コンテンツの選択を行った時点に近いタイミングで入力されたＩＤ等は高いランキングとなる。このようにして生成されたランキングの中から、上位の数件を送信端末１の表示装置（図示せず）に提示して選択可能とする（１１３）。なお、抽出されたＩＤ等が１件である場合も、その送信先であるか否かを確実にユーザーが判別できるようにする。送信元ユーザーは、入力装置１１から、送信先であるユーザーのＩＤ等を選択する（１１４）。また、該当するＩＤ等が１件も存在しない場合や、件数が少ない場合は、送信元ユーザーがＩＤ等を簡略化して入力した場合や、誤入力した場合も想定されるため、上記文字情報から抽出したＩＤ等と類似するＩＤ等についてもランキングに載せる。
【００５４】
上記のＩＤ等が選択されると、受信ユーザーリクエスト部２２が、サーバ２へ選択したＩＤ等を含むリクエストを送る。この段階ではコンテンツ自体は送信されず、あくまで送信前の通知の予備段階である。また、送信しようとするコンテンツがサーバ２上にある場合には、そのコンテンツを判別する情報も共に送信する。ここまでが送信のためのリクエストの処理である（１１６）。
【００５５】
次に、ＩＤ等のリクエストを受けたサーバ２における処理を説明するが、まず、その前提として、ユーザーの設定情報のシステムへの登録手順について説明する。
【００５６】
ユーザーは登録時に、システムがユーザーを識別するＩＤとともにユーザー登録ＤＢ３１に登録される。また、このときユーザー自身のニックネーム、名前、名称などをＩＤに関連づけてユーザー間で識別しやすくするための情報として登録する。また、システムを利用するにあたって認証を行うためのパスワードも登録する。これらの登録はユーザー登録ＤＢ３１に対して行う。また、サービスを利用するにあたってのサービスのグレードや契約形態なども登録しうる情報である。さらに、通知先端末３についての識別符号も入力する。その他、ユーザーの所属先、役職、住所、電話番号、生年月日、ユーザーの利用サービスから抽出されるキーワード、ユーザーが設定するタグなどを入力することで、ユーザー情報全体を管理するものでもよい。このＤＢのテーブルの例を表２に示す。なお、このテーブルのようにユーザーごとに複数の通知先ＩＤや送受信端末ＩＤを登録し得るような形式以外に、ユーザーＩＤと通知先ＩＤや送受信端末ＩＤとを一対一対応させる形式も挙げられる。
【００５７】
【表２】
2010237728.tif 000004
【００５８】
この発明にかかるシステムでは、送信先ユーザーは送信されるコンテンツを受動的に受けるのではなく、一旦コンテンツが送信される旨の通知を受け、その通知に対してサーバ２に応答し、適切な受信端末４での受信を行うものである。このため少なくとも、通知を受ける端末である通知先端末３へ具体的な通知を行うために必要な情報をサーバ２に登録しておく必要がある。この必要な情報とは、例えば、携帯電話ＩＤ、携帯電話番号、メールアドレス、連絡手段となりうる他のサービスにおけるＩＤ、その他のテキスト送信サービスにおいて有効なアドレスなどが挙げられる。すなわち、これらは端末固定でなくてもよく、ネットワーク環境があればいつでも見ることが出来る共有サービスのＩＤでも構わない。これらの情報をまとめて１つの通知先ＩＤに関連づけたテーブルにまとめ、通知先ＤＢ３３に登録する。この通知先ＤＢ３３のテーブルの例を表３に示す。なお、表中ＳＮＳとはソーシャルネットワークサービスをいい、「映像配信ＩＤ」とは、本システムそのもの以外の映像配信可能なサービスのＩＤをいう。この中でも特に、常時携帯している可能性が極めて高く、通知に好適である携帯電話のアドレスが含まれると好ましい。なお、一つのＩＤにつき、上記通知先ＩＤは複数登録するものでもよい。
【００５９】
【表３】
2010237728.tif 000005
【００６０】
さらに必要に応じて、ユーザー個人が所有する端末であって、この発明にかかるシステムで送信端末１、受信端末４として利用する可能性のある端末のアドレス等を登録する。まず、送信端末１として利用する可能性のある端末のアドレス等を登録しておくことで、サーバ２は送信要求に対してその要求が正規のユーザーが手にする端末であるか否かの判別が可能となり、第三者のなりすましを抑制することができる。
【００６１】
次に、受信端末４として利用する可能性のある端末については、実際にコンテンツを受け取ることができる機能を有することが必要である。ただし、想定される全てのコンテンツの受信、再生ができるものである必要はなく、限られた形式のコンテンツのみ受信、再生できるものであってもよい。受信端末４の情報を受信端末登録ＤＢ３４に登録するにあたっては、再生可能であるコンテンツの種別、画面の大きさ、画面解像度、通信速度、装置の演算能力、対応するコンテンツの種類等を記載する。その上で、その受信端末４が実際にコンテンツであるファイルを受け取ることができるアドレスを登録すると、携帯電話の場合に特に好ましい。一方で、パソコンなどのアクセス自由度の高い端末を用いる場合には、通知先ＤＢ３３のＩＤのみでその端末を利用可能であるため、必ずしも具体的なアドレスは必要ではない。このような受信端末登録ＤＢ３４のテーブルの例を表４に示す。ここで対応形式とは、再生できる動画コンテンツのファイルフォーマットに付される拡張子である。ただし、厳密には「＊．ａｖｉ」や「＊．ｍｐ４」、「＊．ｗｍｖ」などの場合には、対応するコーデックの種類やバージョンまで記録しておくと好ましい。同一拡張子であっても形式が異なるファイルが存在するからである。具体的には、それぞれの拡張子について何ビットかのフラグを設定しておき、各ビットがそれぞれコーデックに対応するようにする方法や具体的なバージョン番号を併せて記録するといった方法が挙げられる。なお、上記に挙げたようなそれぞれのファイル形式への対応は、コーデックや再生ソフトのインストールによって拡張することができる。
【００６２】
【表４】
2010237728.tif 000006
【００６３】
また、これらの受信端末４は、ＣＰＵを有する処理装置を有する装置と、画面表示装置とが一体であるものと、それぞれ分離したものとの両方が挙げられる。一体であるものとしては、携帯電話やノートパソコン、携帯用ゲーム機が挙げられる。分離したものとしては、デスクトップパソコンや、据え置き型ゲーム機などが挙げられ、一つのディスプレイを共用する場合がある。また、一つのデスクトップパソコンに、複数のディスプレイが接続され、受信した端末から、どのディスプレイで表示するか選択可能な場合も挙げられる。その利用方法としては、例えば、共用の処理装置を有する端末が複数のディスプレイに接続されており、送信先ユーザーが共用の処理装置を操作して、どのディスプレイに表示するかを指定して表示を開始させた後は、処理装置はバックグラウンドで表示を続けるとともに、他の送信先ユーザーによる処理を受け付け可能とするようなケースが挙げられる。これらの連携を行う際には、受信端末登録ＤＢ３４には、それぞれの端末が接続している端末ＩＤを記録しておくとよい。
【００６４】
このように、同一拡張子であっても形式が異なるファイルが存在すると、送信したものの再生できないということが起こりうる。このため、システム全体としては、まず、ファイルの拡張子は適式に付してある必要がある。その上で、一の拡張子への対応を表４に登録する場合には、その端末はその拡張子のファイルのあらゆるフォーマットに対応したものであることを条件として課すと、問題は起こりにくくなる。ただし、ファイルフォーマットは次々と新しいものが出現するため、全ての形式に対応するようにするのは現実的ではない。実際にはシステムが送信可能とするコンテンツの種類を、汎用の装置で再生可能なものに絞り込む方が現実的である。
【００６５】
また、受信端末４についてはユーザーが所有する個人用の物の他に、このシステムの利用者が共通して利用可能な共有端末についても上記の情報を登録しておく。これにより、送信先ユーザー（受信ユーザー）がその時点で手にしている端末が当該コンテンツの再生を行う機能を有さないものであっても、手近にある共有端末を受信端末４として利用することでコンテンツの受信が可能となる。
【００６６】
なお、これを実現するために、受信端末登録ＤＢ３４には、その端末が公共用であるか個人用であるかの種別を記録し、個人用である場合には固定用か携帯用かの種別も記録する。もちろん、これよりもさらに細かい情報を付加して分類してもよい。
【００６７】
上記のような情報が登録されたユーザー登録ＤＢ３１、通知先ＤＢ３３、受信端末登録ＤＢ３４を有するサーバ２が、上記受信ユーザーリクエスト部２２からの送信通知を受けてから実行される手順について図３を用いて説明する（１５１，１５２）。
【００６８】
まず、通知先が存在するか否かを確認するため、サーバ２は動作可能装置検出部４１を実行する。その内容は、受信ユーザーリクエスト部２２から通知されたユーザーについて、通知先ＤＢ３３より通知先のアドレス等を取得する（１５３）。その上で、その通知先が現在アクティブであるか否かを検出する（１５４）。アクティブであるとは、すなわち、通知を速やかに受け取れる状態であるか否かであり、携帯電話であれば、電源が入っているか、又は電波が届く範囲にいるか否かである。ＳＮＳやその他のサービスのＩＤであればオンライン状態であるか否かなどを判断する。一つも存在しない場合は通知が出来ないので、送信端末１に通知不可の旨の返答をして（１６１）、送信作業は終了する（１６２）。
【００６９】
さらに、動作可能装置検出部４１は、通知を行う宛先を、個人携帯端末、個人固定端末又はそれから利用していると思われているアクティブなサービスアドレスなどのうち、少なくとも一つから選び、通知の準備をする。
【００７０】
あわせて、サーバ２は、動作可能装置検出部４１を、送信先ユーザーの、受信端末登録ＤＢ３４に登録されている受信端末４についても実行し（１５５）、上記と同様にアクティブか否かを検出する（１５６）。通知先端末３と受信端末４が兼用になっている場合には、先の通知先取得の結果を一部流用する。これにより、個人用端末についてリストアップし、一覧テーブルの作成が可能である。
【００７１】
また、個人用端末についてのリストアップとともに、公共端末のリストアップを行う場合について補足する。送信先ユーザーがＧＰＳのように端末の存在する位置を特定できる位置特定装置５２を有する端末を所持しており、なおかつユーザー登録ＤＢにそのＧＰＳを参照するための情報を登録してある場合には、サーバ２は周辺端末検索部４４を実行して、送信先ユーザーが所持しているＧＰＳ端末の位置情報送信部５１を起動させて、位置特定装置５２により緯度経度情報としての位置情報を送信させる。次に、システムの受信端末登録ＤＢ３４に公共固定端末として登録された受信端末４のうち、取得した位置情報の近くにあるものをリストアップして一覧テーブルを作成する（１５７）。また、周辺端末検索部４４はそれとともに、それぞれの公共固定端末である受信端末４が起動しているか否かを判断して、起動していないもの、使用不可であるものを上記一覧テーブルから除外する（１５８）。
【００７２】
また、サーバ２は、上記一覧テーブルに対して、送信されるコンテンツのファイルフォーマットフラグから、その上記コンテンツが再生可能である受信端末４を、上記受信端末登録ＤＢ３４を参照して抽出する対応端末抽出部４６を実行する（１５９）。コンテンツを再生できない端末を一覧テーブルに載せて送信しても、ユーザーにとっては邪魔になるだけでなく、エラーの元となるからである。なお、再生が出来なくても、保存可能である端末については、一覧テーブルから除外するのではなく、保存のみ可能である旨の情報を付記してもよい。
【００７３】
また、上記の対応端末抽出部４６の実行にあたっては、上記コンテンツがコンテンツ収容部６に保存されている現実のファイルフォーマットだけでなく、コンテンツ収容部６が有するファイル形式変換部２７の実行により変換可能なフォーマットについても含めて良い。すなわち、そのままでは再生できなくても、受信端末４が再生可能な形式に、送信側で変換してしまえば、再生可能である端末の種別は広がり、このシステムの利用範囲を広げることができる。また、コンテンツメタデータＤＢ２６は、メタデータの一つとして、可能である変換先の形式について記録した変換ファイルフォーマットフラグを記録可能であるとよい。このようなファイル形式変換部２７とは、具体的には、エンコーダソフトウェアなどである。
【００７４】
個人用端末と公共固定端末のいずれでも、利用可能かつファイル再生可能な端末が無かったら（１６０）、同様に送信端末１に送信不可の返答をして（１６１）、終了する（１６２）。
【００７５】
いずれか一つでも利用可能な端末があったら（１６０）、リストアップを行う。このとき、送信しようとするコンテンツのメタデータのうち、プライベートフラグ（図中「ＰＶｆｌａｇ」と略記する。）が１であるか否かによってリストアップの順序を変更する（１７１）。プライベートフラグが０である場合、すなわち、公共性の高いコンテンツである場合には、公共固定端末を第一候補として受信端末４の上記一覧テーブルのソートを行う（１７２）。
【００７６】
一方、プライベートフラグが１のとき、すなわち私的なコンテンツである場合には、サーバ２は受信ユーザー状況検出部４５により、送信先ユーザーが個人用の固定端末として登録した受信端末４の近くにいるか否かを検出する（１７２）。ほとんどのコンテンツを見る場合には、携帯端末用の小さな画面で見るよりは、固定端末用の大きな画面で見ることが好ましく、また、操作の自由度も高いため、個人用の固定端末が使える状態であれば、固定端末を優先することが好ましいからである。
【００７７】
この受信ユーザー状況検出部４５の具体的な構成としては、例えば、上記の登録してある通知先端末がＧＰＳなどの位置特定装置５２を有する携帯電話である場合に、その存在位置を確認するために位置情報送信部５１に位置情報を送信させ、その位置が送信先ユーザーの個人用の固定端末である受信端末４の存在箇所の半径１０メートル程度以内であるか否か判断するといったことが挙げられる。また別の構成としては、企業内において、個々人の座席にカメラまたはセンサーを取り付けて、そこに対象者がいるかどうかを把握できるシステムを設けておく構成が挙げられる。これらのような在席情報を確認するシステムの情報は、ユーザー登録ＤＢ３１に記録しておいてもよいし、別途設けたシステム内のＤＢから取得してもよい。
【００７８】
上記受信ユーザー状況検出部４５により、在席していると判断された場合には（１７３）、その在席箇所に備え付けられた個人用の固定端末を第一候補として受信端末４の上記一覧テーブルのソートを行う（１７４）。逆に在席していないと判断された場合には、個人用の携帯端末を第一候補とし、周辺端末検索部４４にて求められた周辺の公共用固定端末を第二候補として受信端末４の上記一覧テーブルのソートを行う（１７５）。
【００７９】
ただし、コンテンツのプライベートフラグが個人用である場合には、公共用の受信端末を一覧テーブルから除外するという設定にしておいてもよい。オープンな場所で見ても差し支えがないコンテンツと、完全に秘密が要求されるコンテンツとがあるためである。この場合、プライベートフラグは単純に０か１かではなく、個人用でもオープン可のものとオープン不可のものを分けるといった、より細かいフラグが設定されていてもよい。なお、このような設定は、ユーザーがユーザー登録ＤＢ３１に対して自ら設定できるようにしておくと好ましい。
【００８０】
なお、コンテンツが特定の端末専用である場合には、上記一覧テーブルに挙げる端末は、その対応する端末のみとすることが好ましい。例えば、特定のキャリアの携帯電話専用の着信音対応メロディフォーマットなどである場合である。この形式のファイルはパソコンで再生環境を有するものはほとんどなく、パソコンに送ってもほとんど意味が無いためである。また、携帯電話の外部イルミネーションの発光パターン設定ファイルは特定の端末専用となる。さらに、コンテンツがゲームのデータである場合には、受信端末４はそのゲームを実行できる特定のゲーム機に限られることとなる。
【００８１】
上記の受信端末通知部４２は、上記のいずれかの方法でソートされた上記一覧テーブルとともに、コンテンツの送信要求があった旨を通知先端末３に通知する（１７６）。このとき、コンテンツメタデータも共に送信すると、送信先ユーザーが判断しやすく好ましい。
【００８２】
なお、動作可能装置検出部４１の実行無しに直接に受信端末通知部４２を実行することも可能ではあるが、想定されうるエラーのほとんどを予期できなくなるので、動作可能装置検出部４１を実行する方が好ましい。
【００８３】
送信先ユーザーが通知を受けた後の動作について、図４を用いて説明する（２０１）。サーバ２の受信端末通知部４２からソートされた上記一覧テーブルとともに、コンテンツの送信通知が通知先端末３に送られる。通知先端末３では、この上記一覧テーブルを選択可能に表示する再生端末選択部５３を実行する（２０２）。これにより、送信先ユーザー、すなわち受信ユーザーは、提示されたどの受信端末４で受信するかを決定する。このとき、上記のソートの際に、受信に適した端末を優先して表示されるようになっており、また、再生が不可能である端末は除外されているため、ユーザーは効率的に選択することができる。
【００８４】
なお、通知だけ受けて受信しないこともできる。本人にとって不要な場合もあるからである。これにより、容量が大きいコンテンツの余分な送信を防ぐことができ、通信費用の節約、ネットワーク資源の節約ができる。
【００８５】
通知先端末３の入力装置（図示せず。）により、コンテンツの受信を行う受信端末４を選択することで（２０３）、受信端末４の送信要求部６１は、コンテンツ収容部６（すなわち、送信端末１とサーバ２とのうち、コンテンツが実際に保存されている方）に対して、送信通知のあった当該コンテンツの送信を要求する（２０４）。もちろん、通知先端末３と受信端末４が同一の端末である場合には、選択してすぐにその端末にコンテンツを送信することが可能である。
【００８６】
ここで、送信元のコンテンツＤＢ２５に保存されているコンテンツのファイルフォーマットが、受信する受信端末４で直接に再生できるものであれば（２０５）、そのまま受信端末４へ送信させる（２０７）。一方、そのままでは再生出来ないフォーマットである場合には、コンテンツ収容部６が有するファイル形式変換部２７にて、その受信端末４が再生できるフォーマットに変換して送信する（２０６，２０７）。
【００８７】
受信端末４のコンテンツ実行部６２は、送信されたコンテンツを再生する（２０７）。ただし、受信端末４が個人用である場合には、コンテンツ実行部６２は再生ではなく保存ができるようにしてもよい。送信を拒絶するわけではないが、その時点では再生している余裕がない場合や、後でじっくりとコンテンツを鑑賞したい場合に有効である。また、コンテンツがサーバ２にある場合には、送信待機の状態で停止しておくことができるようにする。ただし、コンテンツが送信端末１に保存されている場合は、待機状態にしておくことは現実的ではない。
【００８８】
上記の公共用の端末としては、完全に公のスペースに設置された端末だけでなく、企業内の会議室などに置かれた端末も含まれる。これらの設置箇所の違いによってさらに細かく配信先を分けるようにしてもよい。この場合は、コンテンツメタデータＤＢ２６や受信端末登録ＤＢ３４に登録する公共度のフラグやプライベートフラグをより細分化した値として設定する。
【００８９】
上記のサーバ２に含まれる機能及びデータベースは、単一の装置であるサーバに含まれるものでもよいし、互いに接続された複数のサーバからなるものでもよい。
【００９０】
この他、他の想定される機能について説明する。
上記の送信先選択部１４は受信ユーザー状況検出部４５と連動していてもよい。すなわち、送信先として、その時点で受信端末４を直接操作してコンテンツの再生又は保存ができる状態にあるユーザーを優先して選択可能とするものである。これは、チャットの最中にコンテンツを送信しようとする場合に有効である。会話中の相手は必ずオンラインであるからである。
【００９１】
また、上記の実施形態はコンテンツ選択後にユーザーを選択しているが、別の実施形態として、予め送信先ＤＢ２１で送信先ユーザーをバッファしておき、コンテンツ選択とともにリスト表示することもありうる。特に、一旦コンテンツを送信した後、引き続いて次のコンテンツを送信しようとする際に有効である。
【符号の説明】
【００９２】
１  送信端末
２  サーバ
３  通知先端末
４  受信端末
６  コンテンツ収容部
１１  入力装置
１３  入力情報検出部
１４  送信先選択部
１５  送信コンテンツ選択部
２１  送信先ＤＢ
２２  受信ユーザーリクエスト部
２５  コンテンツＤＢ
２６  コンテンツメタデータＤＢ
２７  ファイル形式変換部
３１  ユーザー登録ＤＢ
３２  ユーザー確認部
３３  通知先ＤＢ
３４  受信端末登録ＤＢ
４１  動作可能装置検出部
４２  受信端末通知部
４４  周辺端末検索部
４５  受信ユーザー状況検出部
４６  対応端末抽出部
５１  位置情報送信部
５２  位置特定装置
５３  再生端末選択部
６１  送信要求部
６２  コンテンツ実行部
【図１】
2010237728.tif 000007
【図２】
2010237728.tif 000008
【図３】
2010237728.tif 000009
【図４】
2010237728.tif 000010