(57)【要約】【課題】任意のタイミングのデータ共有要求に対して、データ共有可能かを自動的に判断し、適切なデータ共有を行う携帯情報端末を提供する。【解決手段】サーバ機能部１０６ａ、クライアント機能部１０６ｆ、応答ポリシー管理部１０６ｂ、リダイレクト情報管理部１０６ｃ、キャッシュ情報管理部１０６ｄ、電話帳管理部１０６ｅ、を備えて構成され、サーバ機能部１０６ａは、他の携帯電話端末又は通信端末からのデータ転送のリクエストに対し、リクエスト内容を処理し、応答を返す。一方、クライアント機能部１０６ｆは、サーバ機能部１０６ａと連携し、後述するリダイレクト情報やキャッシュ情報を利用し、リダイレクト受信を可能にする。【選択図】図１
2010183236.tif 000002
【特許請求の範囲】
【請求項１】
バッテリーを内蔵する携帯情報端末であって、
通信端末又は他の携帯情報端末からのデータ取得要求に対し、データ取得可否の応答を返信するサーバ機能部と、
前記データ取得要求に対して、どのように取得要求に応じるかを記述した応答ポリシー管理部と、
を備え、
前記サーバ機能部は、前記他の通信端末からのデータ取得要求があった場合に、前記応答ポリシー管理部にデータ送信のための応答条件を入力し、記述された応答ポリシーに基づいて、データ送信の可否を決定することを特徴とする携帯情報端末。
【請求項２】
電波強度を測定し、測定した該電波強度を前記サーバ機能部に通知する電波強度測定部を備え、
前記応答条件が、前記電波強度測定部により測定した電波強度のレベルであることを特徴とする請求項１に記載の携帯情報端末。
【請求項３】
前記バッテリーを含む電源電圧を測定し、測定した該電源電圧を前記サーバ機能部に通知する電源管理部を備え、
前記応答条件が、前記電源管理部により測定した電源電圧のレベルであることを特徴とする請求項１又は請求項２に記載の携帯情報端末。
【請求項４】
端末装置を識別するための固有データを記録した電話帳を管理する電話帳管理部を備え、
前記サーバ機能部は、前記他の携帯情報端末からのデータ取得要求時に送信される前記固有データと同一の固有データが前記電話帳に記録されている否かを判断し、記録されていると判断した場合に、データ取得要求した前記他の携帯情報端末を識別すると同時に、データ取得要求に対する応答を行うことを特徴とする請求項１から請求項３のいずれか１項に記載の携帯情報端末。
【請求項５】
前記サーバ機能部は、前記他の携帯情報端末からのデータ取得要求に対する応答においてデータ送信の応答不可と判断した場合に、該他の携帯情報端末に対して、前記データ取得要求を別の他の携帯情報端末に転送するための情報を送信することを特徴とする請求項１から請求項４のいずれか１項に記載の携帯情報端末。
【請求項６】
さらに、前記サーバ機能部との通信によってリダイレクト情報を生成するクライアント機能部と、該リダイレクト情報を管理するリダイレクト情報管理部と、を備え、
前記サーバ機能部により、前記他の携帯情報端末からのデータ取得要求に対してデータ送信を実行した後、該他の携帯情報端末からキャッシュ情報生成通知を受信した場合に、前記クライアント機能部は、該リダイレクト情報を生成することを特徴とする請求項１から請求項５のいずれか１項に記載の携帯情報端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介し、マルチメディアデータの送受信及びデータ共有を行う携帯情報端末に関する。
【背景技術】
【０００２】
一般に、携帯電話等の携帯情報端末の高性能化、携帯電話ネットワーク等の高速化が進んでいる近年、携帯情報端末（以下、代表的な携帯電話端末を例に説明する。）は、インターネットから様々なマルチメディアコンテンツをダウンロードしたり、搭載されているカメラを活用して写真や映像などのコンテンツを作成したりするなどして、マルチメディアコンテンツのストレージデバイスとしても機能するようになってきている。
【０００３】
このように携帯電話端末上でマルチメディアコンテンツを扱うようになるにつれて、携帯電話端末に搭載されているメモリ内に格納されているデータを、親しい友人に対してメールや赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの通信手段を用いて転送したり、インターネット上のサーバにアップロードしたりするなどして、データを共有するといった使われ方がなされるようになっている。上記のような通信手段を用いた場合、アップロードできるデータに種々の制限があったり、通信する端末同士が物理的に近距離にいなければならなかったりと、様々な制約が多く、効率的なデータの転送を行うことが困難であるという問題点があった。また、従来のサーバ・クライアント型のシステムにおけるデータ共有にあっては、サーバ内に膨大なデータを格納する必要があり、サーバの構築等が大規模となるなどの問題点があった。
【０００４】
そこで、上記問題を解決すべく、インターネットなどの公衆ネットワークを介して、携帯電話端末内のデータを効率的に共有する中継サーバを備えたデータ共有システムが提案されている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１２００６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記のようなデータ共有システムであっても、携帯電話端末間において、ネットワークを介してデータの共有を行う場合、任意のタイミングでのデータ共有を可能にするためには、電波強度やバッテリー残量に応じた対応が必要となる。例えば、２台の携帯電話端末間でデータを共有する場合に、一方の携帯電話端末が他方の携帯電話端末が保持するデータをダウンロードしようとした際に、いずれか一方の携帯電話端末が電波強度の弱い場所に位置していたとすると、ダウンロードに要する時間が大きくなるほか、パケットロスの発生によるパケットの再送回数が増加して、通信に使われる電力の消費も大きくなる。
【０００７】
また、バッテリー残量が少ない場合に、別の携帯電話端末からデータのダウンロード要求を受けた場合に、データの転送を実行したことによって、バッテリーが「空」になるといった事態も起こりうる。
【０００８】
また、別の問題もある。例えば、特許文献１に開示されている技術では、インターネット上に中継サーバを設置し、共有データはその中継サーバを介して行われるが、インターネットなどの公衆ネットワーク上に共有データを置く場合、サーバのセキュリティホールや不正アクセスといったリスクが存在する。不特定多数に公開してよいデータであれば、それでも構わないであろうが、データによっては、特に親しい仲間内だけでデータを共有したいような場合もある。そのような場合には、中継サーバを利用しないシステムが要求される。
【０００９】
そこで、本発明は、斯かる実情に鑑みてなされたものであって、任意のタイミングのデータ共有要求に対して、データ共有可能かを自動的に判断し、適切なデータ共有を行う携帯情報端末を提供するものである。
【課題を解決するための手段】
【００１０】
上記のような問題点を解決するために、本発明に係る携帯情報端末は、以下のような構成とし、特徴を有する。
【００１１】
本発明に係る携帯情報端末は、バッテリーを内蔵する携帯情報端末であって、通信端末又は他の携帯情報端末からのデータ取得要求に対し、データ取得可否の応答を返信するサーバ機能部と、前記データ取得要求に対して、どのように取得要求に応じるかを記述した応答ポリシー管理部と、を備え、前記サーバ機能部は、前記他の通信端末からのデータ取得要求があった場合に、前記応答ポリシー管理部にデータ送信のための応答条件を入力し、記述された応答ポリシーに基づいて、データ送信の可否を決定することを特徴とする。
【００１２】
また、本発明に係る携帯情報端末は、電波強度を測定し、測定した該電波強度を前記サーバ機能部に通知する電波強度測定部を備え、前記応答条件が、前記電波強度測定部により測定した電波強度のレベルであることを特徴とする。
【００１３】
また、本発明に係る携帯情報端末は、前記バッテリーを含む電源電圧を測定し、測定した該電源電圧を前記サーバ機能部に通知する電源管理部を備え、前記応答条件が、前記電源管理部により測定した電源電圧のレベルであることを特徴とする。
【００１４】
また、本発明に係る携帯情報端末は、端末装置を識別するための固有データを記録した電話帳を管理する電話帳管理部を備え、前記サーバ機能部は、前記他の携帯情報端末からのデータ取得要求時に送信される前記固有データと同一の固有データが前記電話帳に記録されている否かを判断し、記録されていると判断した場合に、データ取得要求した前記他の携帯情報端末を識別すると同時に、データ取得要求に対する応答を行うことを特徴とする。
【００１５】
また、本発明に係る携帯情報端末は、前記サーバ機能部は、前記他の携帯情報端末からのデータ取得要求に対する応答においてデータ送信の応答不可と判断した場合に、該他の携帯情報端末に対して、前記データ取得要求を別の他の携帯情報端末に転送するための情報を送信することを特徴とする。
【００１６】
また、本発明に係る携帯情報端末は、前記サーバ機能部との通信によってリダイレクト情報を生成するクライアント機能部と、該リダイレクト情報を管理するリダイレクト情報管理部と、を備え、前記サーバ機能部により、前記他の携帯情報端末からのデータ取得要求に対してデータ送信を実行した後、該他の携帯情報端末からキャッシュ情報生成通知を受信した場合に、前記クライアント機能部は、該リダイレクト情報を生成することを特徴とする。
【発明の効果】
【００１７】
本発明の携帯情報端末によれば、以下に示す優れた効果を奏し得る。
【００１８】
上記のように構成された本発明の携帯情報端末によれば、電波強度、及びバッテリー残量の変化に応じた動作をポリシーとして選択できるようにすることで、任意のタイミングにおけるデータ共有の要求に対して、データ共有可能かを自動的に判断し、適切なデータ共有を行うことができる。
【００１９】
また、本発明の携帯情報端末によれば、電話帳による要求を送信してきた他の端末との相互の電話帳による登録識別、又は相互認証を行うようにすることで、中継サーバを介する必要がないため、データ共有の安全性、利便性を向上することができる。
【００２０】
また、本発明の携帯情報端末によれば、キャッシュ情報を利用したデータ共有を行うことにより、他の親しい仲間内が所有している携帯情報端末から同じデータを取得することができるため、データ共有の迅速性、安全性を高めることができるという効果もある。
【図面の簡単な説明】
【００２１】
【図１】本実施形態に係る携帯電話端末を用いた通信システムの構成を示す概略図である。
【図２】本実施形態に係る携帯電話端末の主要部を示す機能ブロック図である。
【図３】電話帳管理部が管理する電話帳データのデータ構造を示す図である。
【図４】電波強度及びバッテリー残量に応じて処理を選択する応答ポリシーを説明する図である。
【図５】キャッシュデータを生成したことを通知するために生成されるキャッシュ情報のデータ構造を示す図である。
【図６】キャッシュ情報を受信した場合に作成されるリダイレクト情報のデータ構造を示す図である。
【図７】本実施形態に係る携帯電話端末において、他の携帯電話端末又は通信端末からデータ要求を受信した場合の動作を示すフロー図（１／２）である。
【図８】本実施形態に係る携帯電話端末において、他の携帯電話端末又は通信端末からデータ要求を受信した場合の動作を示すフロー図（２／２）である。
【図９】本実施形態に係る携帯電話端末間で、データ要求を送信した場合の動作を示すフロー図（１／２）である。
【図１０】本実施形態に係る携帯電話端末間で、データ要求を送信した場合の動作を示すフロー図（２／２）である。
【図１１】本実施形態に係る携帯電話端末間で、データリクエスト動作を実行した場合の動作シーケンスを表す図である。
【図１２】本実施形態に係る携帯電話端末間で、データリクエスト動作を実行した場合で、リダイレクトが発生した場合の動作シーケンスを表す図である。
【図１３】本発明の機能を有しない通信端末が、本発明の携帯電話端末に対し、データリクエスト動作を実行した場合の動作シーケンスを表す図である。
【発明を実施するための形態】
【００２２】
以下、本発明に係る携帯情報端末の一実施形態について図面を参照して説明する。なお、本実施形態では、携帯情報端末の代表的な端末である携帯電話端末を用いて以下に説明する。また、図１〜図１３は、本発明に係る携帯電話端末の一実施形態を示す図であって、図中、同一の符号を付した部分は同一物を表わすものである。
【００２３】
図１は、本実施形態に係る携帯電話端末を用いた通信システムの構成を示す概略図である。
【００２４】
図１に示す通信システムでは、本発明に係る携帯電話端末である３つの携帯電話端末Ａ、携帯電話端末Ｂ、携帯電話端末Ｃと、１つの通信端末Ｄを備えて構成され、各端末は、それぞれのアクセスネットワークＡ、Ｂ、Ｃを介してインターネットに接続され、相互間の情報伝達を行うよう構成されている例を示している。
【００２５】
以下、本実施形態では、アクセスネットワークＡ・Ｂは移動体通信網（携帯電話回線網）であり、アクセスネットワークＣが固定電話回線網（ブロードバンド）である場合を例に説明するが、この構成に限るものではない。移動体通信網および固定電話回線網は、インターネットを介して接続されており、それぞれの端末は、相互に通信することが可能である。
【００２６】
なお、図１に示す携帯電話端末Ａ、携帯電話端末Ｂ、および、携帯電話端末Ｃは、それぞれ、主要部分が同一の構成を有するカメラ付き携帯電話端末とする。
【００２７】
続いて、本実施形態に係る携帯電話端末１０（例えば、携帯電話端末１０を図１に示す携帯端末Ａとする。）の具体的な構成について、図２を参照して説明する。
【００２８】
図２は、本実施形態に係る携帯電話端末の主要部を示す機能ブロック図である。
【００２９】
携帯電話端末Ａは、図２に示すように、カメラ１００、マイク１０１、表示装置１０２、スピーカ１０３、キー入力装置１０４、外部記憶装置１０５、赤外線通信インタフェイス１０９、Ｂｌｕｅｔｏｏｔｈインタフェイス１０９等を含む各種装置と、データの送受信するための送受信処理部１０７ａおよび、電波強度を測定するための電波強度測定部１０７ｂと、を備えた無線通信部１０７と、電圧測定部１０８ａを備えた電源管理部１０８と、これらの各装置を統括的に制御するための統括制御部１０６と、を備えて構成されている。
【００３０】
また、統括制御部１０６は、各装置を統括的に制御する以外に、サーバ機能部１０６ａ、クライアント機能部１０６ｆ、応答ポリシー管理部１０６ｂ、リダイレクト情報管理部１０６ｃ、キャッシュ情報管理部１０６ｄ、および、電話帳管理部１０６ｅを備えている。
【００３１】
ここで、図２に示す本発明に係る携帯電話端末１０の構成要素の内、統括制御部１０６に含まれるサーバ機能部１０６ａ、クライアント機能部１０６ｆ、応答ポリシー管理部１０６ｂ、リダイレクト情報管理部１０６ｃ、キャッシュ情報管理部１０６ｄ、電話帳管理部１０６ｅ、ならびに、無線通信部１０７に含まれる電波強度測定部１０７ｂ、電源管理部１０８に含まれる電圧測定部１０８ａが、本発明に係る携帯電話端末１０の特徴部分の構成要素である。
【００３２】
また、サーバ機能部１０６ａ、クライアント機能部１０６ｆ、応答ポリシー管理部１０６ｂ、リダイレクト情報管理部１０６ｃ、キャッシュ情報管理部１０６ｄ、電話帳管理部１０６ｅは、統括制御部１０６の構成に含めずに、他の機能ブロックに含めてもよいし、個々の機能ブロックとして構成してもよい。
【００３３】
なお、サーバ機能部１０６ａは、他の携帯電話端末又は通信端末からのデータ転送のリクエストに対し、リクエスト内容を処理し（データの送信等）、他の携帯電話端末又は通信端末に応答を返す機能を有する。一方、クライアント機能部１０６ｆは、上記サーバ機能部１０６ａと連携して、後述するリダイレクト情報やキャッシュ情報を利用し、リダイレクト受信を可能にする機能を有する。また、これらサーバ機能部１０６ａ及びクライアント機能部１０６ｆの間の通信によって生成されるリダイレクト情報、キャッシュ情報は、それぞれ、リダイレクト情報管理部１０６ｃ、キャッシュ情報管理部１０６ｄによって管理される。
【００３４】
続いて、上記のように構成された携帯電話端末Ａ、Ｂ、Ｃの概略動作及び携帯電話端末間の連携動作について説明する。
【００３５】
携帯電話端末Ａは、他の携帯電話端末（例えば、他の携帯電話端末を以下、図１に示す携帯電話端末Ｂとする）からデータのリクエストを受信すると、まず、携帯電話端末Ａのサーバ機能部１０６ａは、電話帳管理部１０６ｅが管理する電話帳データ（下記の図３参照）に、携帯電話端末Ｂの情報が含まれているかどうかを確認する。
【００３６】
図３は、電話帳管理部によって管理される電話帳データのデータ構造を示す図である。
【００３７】
図３に示す電話帳管理部１０６ｅによって管理される電話帳データには、電話番号、氏名、メールアドレスといった一般的な情報に加え、携帯電話端末Ｂ、または通信端末Ｄから、携帯電話端末１０にアクセスするのに必要なＵＲＬ、電話帳による相手認証を行う際に用いる共有キー（固有ＩＤ）等のデータが含まれている。
【００３８】
サーバ機能部１０６ａは、上記共有キーが電話帳に登録されているかどうかを確認することで、リクエストを送信した携帯電話端末Ｂが電話帳データに含まれているか否かを判断することができる。
【００３９】
次に、サーバ機能部１０６ａは、携帯電話端末Ｂの共有キーが、電話帳データに含まれていることを確認すると、電波強度測定部１０７ｂおよび、電圧測定部１０８ａにより、電波強度のレベルとバッテリー電圧のレベルを測定し、その測定結果に基づいて、携帯電話端末Ｂからのデータリクエストに対して、どのように応答するかを決定する。どのように応答するかは、応答ポリシーという形で応答ポリシー管理部１０６ｂによって設定される。
【００４０】
図４は、携帯電話端末Ｂ又は通信端末Ｄから、携帯電話端末Ａにアクセス要求があった場合に、要求受信時の電波強度、および、電源状況によって、どのように要求に応じるかを記述した応答ポリシーの記述例を示す図である。
【００４１】
この例では、電圧測定部１０８ａによって得られるバッテリー電圧のレベル（図中表記、ＰＯＷＥＲ＿ＬＥＶＥＬ）を０から３の４段階、電波強度測定部１０７ｂによって得られる電波強度のレベル（図中表記、ＲＡＤＩＯ＿ＬＥＶＥＬ）を０から３の４段階で表現した場合において、バッテリー電圧のレベルが３以上の場合、および、バッテリー電圧のレベルが２で、かつ、電波強度のレベルが３以上の場合に要求内容に応じたレスポンス（図中表記、ＨＴＴＰ＿ＯＫ）を返し、バッテリー電圧のレベルが２で、かつ、電波強度のレベルが３未満の場合には、携帯端末Ｂに要求を転送させるリダイレクト応答（図中表記、ＨＴＴＰ＿ＲＥＤＩＲＥＣＴ）を返し、バッテリー電圧のレベルが２未満の場合は、その要求に応じることができないことを表すレスポンス（図中表記、ＨＴＴＰ＿ＳＥＲＶＥＲ＿ＥＲＲＯＲ）を返す、という内容を示している。
【００４２】
なお、図４では、プログラムコードのような書式を用いているが、この書式に限られることはなく、表組みを用いた記述や、パターンの列挙による記述であってもよい。
【００４３】
図４に記述したように、携帯電話端末Ａのサーバ機能を有するサーバ機能部１０６ａは、応答ポリシーの確認によってデータの応答が認められた場合にのみ、携帯電話端末Ｂがリクエストしたデータを返信し、それ以外の場合では、携帯電話端末Ａ及び携帯電話端末Ｂの双方の電話帳に登録されており、かつ、携帯電話端末Ｂがリクエストしたデータのキャッシュデータを持っている新たな第３の携帯電話端末（例えば、第３の携帯電話端末を以下、図１に示す携帯電話端末Ｃとする。）に対してリクエストをリダイレクトするか、応答不可能を表すメッセージを返信する。携帯電話端末Ｂが、携帯電話端末Ａに対し、携帯電話端末Ｃへのリダイレクトを指示した場合、携帯電話端末Ａは、携帯電話端末Ｃに対して、携帯電話端末Ｂに送信したリクエストと同様のリクエストを送信する。そして、携帯電話端末Ａからリクエストを受信した携帯電話端末Ｃは、携帯電話端末Ａからリクエストを受信した場合の携帯電話端末Ｂと同様の処理を行う。
【００４４】
ここで、携帯電話端末Ａにおいて、携帯電話端末Ｂへのリクエスト、あるいは、リダイレクト先である携帯電話端末Ｃへのリクエストが成功すると、リクエストしたデータのキャッシュデータを生成することが選択でき、キャッシュ情報を生成しておくことで、携帯電話端末Ｂ，Ｃとは異なる第４の携帯電話端末（図１には図示していない）が同じデータをリクエストした際に、携帯電話端末Ｂ，Ｃの電波状況あるいはバッテリー状況が芳しくない場合においても、データの取得を可能にすることができる。
【００４５】
図５は、キャッシュ情報のデータ構造の一例を示す図である。
【００４６】
キャッシュ情報は、ダウンロードしたデータをキャッシュデータとして保存した場合に生成され、携帯電話端末Ｂに送信され、携帯電話端末Ｂのキャッシュ情報管理部１０６ｄに格納される。
図５に示すように、キャッシュ情報には、キャッシュデータの本来の格納場所（図中表記、Ｓｏｕｒｃｅ  ＵＲＬ）、キャッシュデータを生成した場所（図中表記、Ｃａｃｈｅ  ＵＲＬ）、キャッシュデータの生成日時、生成したキャッシュデータを保持する期限を示すキャッシュデータの有効期限、キャッシュデータを生成した携帯電話端末の電話帳に含まれる共有キーを示す署名が含まれる。
【００４７】
図６は、キャッシュ情報を受信した場合に作成されるリダイレクト情報のデータ構造を示す図である。
【００４８】
携帯電話端末Ｂは、図５に示したキャッシュ情報生成通知を受信すると、当該携帯電話端末のリダイレクト情報管理部１０６ｃは、キャッシュ情報のＳｏｕｒｃｅ  ＵＲＬとＣａｃｈｅ  ＵＲＬから、生成されたキャッシュデータの元データについて、そのデータに対する要求のリダイレクト先を、Ｄｅｓｔ  ＵＲＬに登録し、同時に、有効期限と電話帳による認証に必要となるキーを併せて登録して、リダイレクト情報を生成する。
【００４９】
そして、携帯電話端末Ｂのサーバ機能部１０６ａは、携帯電話端末Ａからデータ取得のリクエストがあり、要求受信時の電波強度状況等の条件が満足せず、リダイレクト応答を返す必要がある場合に、上記リダイレクト情報の取得要求のあったデータのＵＲＬ（Ｓｏｕｒｃｅ  ＵＲＬ）からキャッシュデータが格納されているＵＲＬ（Ｃａｃｈｅ  ＵＲＬ）を見つけ出し、そのキャッシュデータの有効期限を確認し、キャッシュデータの有効期限内であれば、キャッシュデータが格納されているＵＲＬと共有キーをリダイレクト応答として、携帯電話端末に返信することで、リクエスト送信を実行する。
【００５０】
次に、図７及び図８のフロー図を参照して、携帯電話端末Ａ又は通信端末Ｄからデータの要求を受信した際の携帯電話端末Ｂの処理について説明する。
【００５１】
なお、これら一連の処理のフローは、図２で示したサーバ機能を有するサーバ機能部１０６ａを中心に実現されるものである。
【００５２】
携帯電話端末Ｂは、例えば、携帯電話端末ＡからのＨＴＴＰリクエストを受信すると、そのリクエストに含まれる送信者情報の確認を行う（ステップＳ１０１）。送信者情報は、図３で示した電話帳データに含まれる共有キーを利用する。この共有キーが含まれるか否かによって、電話帳による送信者チェックを行うか否かを判断する（ステップＳ１０２）。電話帳による送信者チェックを行うと判断した場合（ステップＳ１０２；ＹＥＳ）、リクエストに含まれていた共有キーと同じ共有キーを持つ電話帳データを探し出す（ステップＳ１０３）。リクエストに含まれていた共有キーと同じ共有キーを持つデータが存在すれば（ステップＳ１０４；ＹＥＳ）、次に、図４で示した応答ポリシーのチェックに移る（ステップＳ１０５、Ｓ１０６）。ここで、リクエストに含まれていた共有キーと同じ共有キーを持つ電話帳データが存在しない場合には（ステップＳ１０４；ＮＯ）、そのリクエストを無視し、応答は返さないで本処理を終了する。
【００５３】
応答ポリシーのチェックでは、電圧測定部１０８ａから得られたバッテリー残量のレベルのチェックと（ステップＳ１０５）、電波強度測定部１０７ｂから得られた電波強度のレベルのチェックを行い（ステップＳ１０６）、得られたそれぞれの値が応答ポリシーを満たすかどうかを判断する（ステップＳ１０７；図８の記号Ａに続く）。
【００５４】
バッテリーレベル、および、電波強度レベルチェックの結果、応答ポリシーによってデータの応答が可能な状態にあると判断した場合には（ステップＳ１０７；ＹＥＳ）、携帯電話端末Ｂ内の記憶装置からリクエストを受けたデータをロードし（ステップＳ１０８）、ロードしたデータを無線通信部１０７からアンテナ１１１を介してリクエスト送信した携帯電話端末Ａに対して返信する（ステップＳ１０９）。応答後は、リクエスト受信時に電話帳による送信者チェックを行っているため、リクエスト送信した携帯電話端末Ａからのキャッシュ情報生成通知待ち状態に移行し、キャッシュ情報生成通知待ちの処理を行う（ステップＳ１１１）。リクエスト送信した携帯電話端末からのキャッシュ情報生成通知の受信判断を行い（ステップＳ１１２）、キャッシュ生成通知を受信した場合（ステップＳ１１２；ＹＥＳ）、この情報を元に図６に示したリダイレクト情報を生成し（ステップＳ１１３）、一連の本処理を終了する。
【００５５】
一方、キャッシュ情報生成通知を受信しない場合に（ステップＳ１１２；ＮＯ）、一定時間経過した場合には（ステップＳ１１４；ＹＥＳ）、リダイレクト情報の生成を行わず一連の本処理を終了する。
【００５６】
ステップＳ１０７の応答ポリシーのチェックにおいて、電波強度、バッテリー残量がリクエストデータの返信条件を満たさない場合（ステップＳ１０７；ＮＯ）、その電波強度、バッテリー残量において、リダイレクト条件を満たすかどうか判定する（ステップＳ１３０）。リダイレクト条件を満たす場合（ステップＳ１３０；ＹＥＳ）、リクエストがあったデータに対する、図６で示したリダイレクト情報をロードし（ステップＳ１３１）、リダイレクト情報が存在するかどうかを確認する（ステップＳ１３２）。リダイレクト情報が存在する場合（ステップＳ１３２；ＹＥＳ）、リダイレクト応答を送信する（ステップＳ１３３）。なお、このリダイレクト応答には、リダイレクト時のキャッシュ登録を有効にするかどうかを含めることができ、含めた場合にキャッシュ登録が有効かの判定を行い（ステップＳ１３４）、リダイレクト時のキャッシュ登録を有効にした場合には（ステップＳ１３４；ＹＥＳ）には、ステップＳ１１１に移行する。他方、リダイレクト時のキャッシュ登録を有効にしない場合は（ステップＳ１３４；ＮＯ）は、一連の本処理を終了する。
【００５７】
ここで、電波強度、および、バッテリー残量が、リダイレクト条件も満たさない場合（ステップＳ１３０；ＮＯ）、または、リダイレクト条件を満たしているが（ステップＳ１３０；ＹＥＳ）、該当するリダイレクト情報が存在しない場合には（ステップＳ１３２；ＮＯ）、その時点ではデータの応答ができないことになり、サービス提供不可応答を送信し（ステップＳ１３５）、一連の本処理を終了する。
【００５８】
また、リクエスト送信の携帯電話端末が、本発明による機能を持たない場合には、電話帳による送信チェックは行えないため、他の認証手段を利用することになる。ステップＳ１０２の処理において、電話帳に関連する共有キー情報が含まれないため、電話帳による送信者チェックは行わず（ステップＳ１０２；ＮＯ）、リクエスト送信の携帯電話端末に対して認証データを要求する（ステップＳ１５０）。リクエスト送信の携帯電話端末に対し認証データを送信した後は、認証データ受信待ち状態処理に移行する（ステップＳ１５１）。認証データ受信待ち状態において、認証データを受信したか否かを判定し（ステップＳ１５２）、認証データを受信すると（ステップＳ１５２；ＹＥＳ）、認証データのチェックを行う（ステップＳ１５３）。認証データのチェックを行った結果、認証データが正当であることを確認し（ステップＳ１５４）、正当であると確認した場合には（ステップＳ１５４；ＹＥＳ）、ステップＳ１０５の処理に移行する。一方、認証データ受信待ちで、認証データを受信せず（ステップＳ１５２；ＮＯ）、一定時間経過した場合（ステップＳ１５５；ＹＥＳ）、および、認証データチェックし、認証データが正当なものではなかった場合（ステップＳ１５４；ＮＯ）には、リクエスト拒絶応答を返し（ステップＳ１５６）、一連の本処理を終了する。また、一定時間経過していない場合（ステップＳ１５５；ＮＯ）、ステップＳ１５１の処理に戻る。
【００５９】
次に、図９，１０のフロー図を参照して、携帯電話端末Ａが、携帯電話端末Ｂに対し、データの要求を送信する際の携帯電話端末Ａの動作処理について説明する。
【００６０】
これら一連の処理のフローは、図２で示したクライアント機能を有するクライアント機能部１０６ｆによって実現されるものである。
【００６１】
携帯電話端末Ａ上で、ユーザのアクセスしたい携帯電話端末ＢのＵＲＬが入力されると、ＵＲＬで指定された相手携帯電話端末Ｂに対し、ＨＴＴＰリクエストを送信する（ステップＳ２０１）。このＨＴＴＰリクエストには、図７，８で示したサーバ動作において、電話帳チェックを実行する（図７：ステップＳ１０２）ためのパラメータを含む。リクエスト送信後は、送信先である相手携帯電話端末Ｂからの応答の待機処理を行い（ステップＳ２０２）、応答受信があったか否かを判断し（ステップＳ２０３）、応答を受信すると（ステップＳ２０３；ＹＥＳ）、受信した応答データチェック処理を行う（ステップＳ２０４）。受信データをチェックした結果、それが前記リクエストで要求したデータであるか否かを判断し（ステップＳ２０５）、リクエストで要求したデータであると判断した場合には（ステップＳ２０５；ＹＥＳ）、受信したデータを携帯電話端末内の記憶装置に格納するなど、受信データの処理を行う（ステップＳ２０６）。その後、自端末のポリシーとして、キャッシュ情報生成を行うか否かを判断し（ステップＳ２０７）、生成を行うと判断した場合には（ステップＳ２０７；ＹＥＳ）、キャッシュＵＲＬとデータの格納先とのリンクを作成し、要求の送信相手に対してキャッシュ情報を生成したことを通知するために、図５で示したキャッシュ生成情報を生成する（ステップＳ２０８）。ここで生成されたキャッシュ情報を、要求の送信相手Ｂに対して送信し（ステップＳ２０９）、一連の本処理を終了する。
【００６２】
なお、自身のポリシーとして、キャッシュ情報の生成を行わないのであれば（ステップＳ２０７；ＮＯ）、その時点で一連の本処理を終了する。
【００６３】
一方、受信したデータが前記リクエストで要求したデータではない場合（ステップＳ２０５；ＮＯ）、リダイレクト要求を受信したとして受信データのチェックを行う（ステップＳ２２０）。受信データがリダイレクト要求であるか否かを判断する（ステップＳ２２０；図１０の記号Ｂに続く）。受信データがリダイレクト要求であると判断した場合には（ステップＳ２２０；ＹＥＳ）、リダイレクト要求に含まれるパラメータから、リダイレクト先の共有キー情報を取得し、それが電話帳に登録されているかどうかを確認する（ステップＳ２２１）。自端末が保持する電話帳の中に、リダイレクト要求に含まれる共有キーと同じキーを持つ電話帳データが存在すれば、リダイレクト先は電話帳に登録されていると判断し（ステップＳ２２１；ＹＥＳ）、リダイレクト先（ここでは、携帯電話端末Ｃとする）に前記リクエストで要求したデータと同じデータを要求するために、ＨＴＴＰリクエストを送信する（ステップＳ２２２）。もし、ここでリダイレクト先が電話帳に登録されていなければ（ステップＳ２２１；ＮＯ）、これ以上、リクエストを送信することは不可能となるため、ユーザに、送信に失敗したというメッセージを出力するなどして、リクエスト処理失敗処理を行い（ステップＳ２４１）、本処理を終了する。
【００６４】
ステップＳ２２２の処理においてリダイレクト先にリクエストを送信した後は、リダイレクト先からの応答を待つ（ステップＳ２２３）。リダイレクト先からの応答受信を受けたか否かを判断し（ステップＳ２２４）、リダイレクト先からの応答を受信すれば（ステップＳ２２４；ＹＥＳ）、受信データが要求データであるかどうかをチェックする（ステップＳ２２５）。受信データが要求データであるか否かを判断し（ステップＳ２２６）、要求データである判断した場合には（ステップＳ２２６；ＹＥＳ）、受信データを携帯電話端末内の記憶装置に格納するなど受信データの処理（ステップＳ２２７）を行う。
【００６５】
ここで、受信データにキャッシュ登録を有効にするためのパラメータが含まれているか否かを判断し（ステップＳ２２８）、含まれていると判断した場合には（ステップＳ２２８；ＹＥＳ）、ステップＳ２０７（図９の記号Ｃに続く）の処理に移行する。一方、キャッシュ登録を有効にするためのパラメータが含まれていない場合には（ステップＳ２２８；ＮＯ）、ここで一連の本処理を終了する。
【００６６】
ステップＳ２２６において、受信データが要求データであるかどうかを確認した際、要求データでなかった場合には（ステップＳ２２６；ＮＯ）、サービス提供不可応答かどうかを判断する（ステップＳ２４４）。リダイレクト先が返した応答が、サービス提供不可応答である場合には（ステップＳ２４４；ＹＥＳ）、サーバーエラーがあったことをユーザに通知するメッセージを出力するなどしてリクエスト処理の失敗処理を行い（ステップＳ２４５）、一連の本処理を終了する。また、サービス提供可応答である場合には（ステップＳ２４４；ＮＯ）、何らかのエラーが発生したものとして、エラー処理を行い（ステップＳ２４６）、本処理を終了する。
【００６７】
ところで、リダイレクト先からの応答待ちの状態で、リダイレクト先からの応答を受信せず（ステップＳ２２４；ＮＯ）、リダイレクト先にリクエストを送信してから一定時間が経過した場合には（ステップＳ２４２；ＹＥＳ）、リクエストの送信に失敗した、または、タイムアウトが発生したことをユーザに通知するメッセージを出力するなどして、リクエスト送信失敗処理を行い（ステップＳ２４３）、本処理を終了する。また、ステップＳ２４２の処理において、一定時間が経過していない場合（ステップＳ２４２；ＮＯ）には、ステップＳ２２３に処理を戻す。さらに、ステップＳ２２０の処理において、受信データがリダイレクト要求ではないと判断した場合には（ステップＳ２２０；ＮＯ）、サービス提供可応答を受信したか否かを判断し（ステップＳ２４０）、受信した場合には（ステップＳ２４０；ＹＥＳ）、ステップＳ２４１、受信しない場合には（ステップＳ２４０；ＮＯ）、ステップＳ２４６の処理に移行する。
【００６８】
なお、受信データチェックにおいて、受信データの種類を分別するのには、例えば、ＨＴＴＰのリクエストコードを用いることができる。要求データの応答であれば２００ＯＫ、リダイレクト要求であれば３０２（Ｍｏｖｅｄ  Ｔｅｍｐｏｒａｒｉｌｙ）、サービス提供不可応答であれば、５０３（Ｓｅｒｖｉｃｅ  Ｕｎａｖａｉｌａｂｌｅ）などのコードを利用することができる。
【００６９】
次に、図１１および図１２を参照して、本実施形態に係る携帯電話端末間で、データリクエスト動作を実行する場合の動作シーケンスについて図７，８及び図９，１０と対応させて説明する。
【００７０】
図１１は、携帯電話端末Ａが、携帯電話端末Ｂに対し、データリクエストを送信し、携帯電話端末Ｂがリダイレクト情報を生成するまでのシーケンスを示している。携帯電話端末Ａは、携帯電話端末ＢのＵＲＬを指定して、データ取得要求のリクエストを送信する。リクエストを受信した携帯電話端末Ｂでは図７を用いて説明したとおり、送信者チェックを行い、さらに、携帯電話端末Ａが電話帳に登録されているかどうかをチェックする。携帯電話端末Ａが電話帳に登録されている場合には、次に、バッテリー残量のチェックと電波強度のチェックを行い、携帯電話端末Ｂで設定されている応答ポリシーの条件に適合するかどうかを確認する。応答ポリシーに適合すれば、携帯電話端末Ａが要求したデータをロードし、そのデータを返信することになる。なお、この返信までの間、携帯電話端末Ａは、携帯電話端末Ｂからのリクエストデータ返信の応答を待っている。
【００７１】
携帯電話端末Ｂは、携帯電話端末Ａに対し、リクエストデータの返信を行うと、携帯電話端末Ａは、図９を用いて説明したとおり、データ受信処理を行い、受信データの確認がとれた後、キャッシュ情報の生成を行う。ここで生成されたキャッシュ情報は、キャッシュ情報生成通知として、携帯電話端末Ｂに送信される。なお、このキャッシュ情報生成通知の送信までは、携帯電話端末Ｂは携帯電話端末Ａからの通知を受け取るか、または、一定時間経過するまでは、携帯電話端末Ａからのデータ受信を待ち受ける。
【００７２】
一定時間経過するまでに、携帯電話端末Ａからキャッシュ情報生成通知を受信すれば、携帯電話端末Ｂはリダイレクト情報を生成して一連の処理を完了する。
【００７３】
一方、図１２は、携帯電話端末Ａが、図１１と同様、携帯電話端末Ｂに対してリクエストを送信するが、携帯電話端末Ｂが携帯電話端末Ｃにリダイレクトする場合のシーケンスを示している。
【００７４】
携帯電話端末Ａは、携帯電話端末ＢのＵＲＬを指定して、データ取得要求のリクエストを送信する。リクエストを受信した携帯電話端末Ｂは、図７を用いて説明したとおり、送信者のチェックと電話帳のチェックを行い、続いてバッテリー残量のチェックを行う。ここで、バッテリー残量が携帯電話端末Ｂの応答ポリシーに適合しなかったとして、携帯電話端末Ｂは携帯電話端末Ａにリダイレクトを実行させるために、リダイレクト情報をロードし、リダイレクト応答を携帯電話端末Ａに返す。なお、携帯電話端末Ｂがリダイレクト応答を返すまでの間、携帯電話端末Ａは応答待ち状態となっている。ここで、リダイレクト応答には、リダイレクトが成功した場合にもキャッシュ情報を生成してもよいかどうかを示すパラメータが含まれている。携帯電話端末Ｂは携帯電話端末Ａにリダイレクト応答を返すと、リダイレクト応答を受信した携帯電話端末Ａは、携帯電話端末Ａが保持している電話帳に、リダイレクト先として指定された携帯電話端末Ｃが含まれているかどうかをチェックする。携帯電話端末Ａの電話帳に、携帯電話端末Ｃが登録されていることを確認できれば、携帯電話端末Ａは携帯電話端末Ｃに対し、携帯電話端末Ｂに要求したデータと同じデータを要求するためのリクエストを送信する。リクエストを受信した携帯電話端末Ｃは、図７に示した動作フローの通り、リクエストの送信者を確認し、携帯電話端末Ｃの電話帳に携帯電話端末Ａが登録されているかどうかを確認する。そして、バッテリー残量のチェックと電波強度のチェックを行い、携帯電話端末Ｃの応答ポリシーに適合することを確認した後、データをロードし、携帯電話端末Ａに対し、携帯電話端末Ａからリクエストのあったデータを送信する。なお、携帯電話端末Ａは、携帯電話リクエストを送信してから携帯電話端末Ｃからの応答を受信するまでは、応答待ちとなっている。携帯電話端末Ｃからリクエストデータを受信した携帯電話端末Ａは、データの受信処理を行う。ここで、携帯電話端末Ｂからリダイレクト応答を受信した際に、リダイレクト成功時にキャッシュ情報を生成してもよいというパラメータを含んでいた場合には、携帯電話端末Ａは、データの受信処理に続いて、キャッシュ情報を生成し、携帯電話端末Ｂに対し、キャッシュ情報生成通知を行う。なお、携帯電話端末Ｂは、携帯電話端末Ａに対し、リダイレクト応答を行った後、リダイレクト時にもキャッシュ情報生成を有効としていたのであれば、携帯電話端末Ａからのキャッシュ生成通知の受信待ちを行っている。携帯電話端末Ｂは、携帯電話端末Ａからのキャッシュ生成通知を受信するとリダイレクト情報を生成して、一連の処理を完了する。
【００７５】
なお、本発明の機能を全て利用するためには、図８で示したクライアント機能が必須であるが、電話帳チェックやキャッシュ情報生成機能を利用しない場合には、例えば、既に広く普及しているＷｅｂブラウザを利用して本発明の機能を有する携帯電話端末にアクセスすることもできる。
【００７６】
次に、図１３を参照して、本発明の機能を有しない通信端末（ここでは、通信端末Ｄとする）から、本発明の携帯電話端末（ここでは、携帯電話端末Ａとする）に対し、データリクエスト動作を実行する場合の動作シーケンスについて説明する。
【００７７】
通信端末Ｄにおいて、携帯電話端末Ａが持つデータを取得するには、携帯電話端末ＡのＵＲＬを指定して、携帯電話端末Ａにデータ取得のリクエストを送信する。リクエストを受信した携帯電話端末Ａは、送信者チェックにおいて、電話帳に含まれる共有キーデータが存在しないため、リクエストを送信してきた通信端末に対して、認証情報を要求する応答を返す。ここで、リクエストを送信した通信端末Ｄの認証情報は、通信端末Ｄのユーザがあらかじめ作成するなどして、既に登録されているものとする。認証情報を要求する応答を受信した通信端末Ｄは、携帯電話端末Ａに登録されている、認証に必要な情報を入力し、携帯電話端末Ａに認証情報を送信する。通信端末Ｄから送信された認証情報を受信した携帯電話端末Ａは、認証情報が正当であるかをチェックし、認証情報が正当であることを確認できれば、バッテリー残量のチェック、電波強度チェックを行って応答ポリシーに適合するかを確認し、適合が確認できれば通信端末Ｄが要求したデータをロードし、通信端末Ｄにリクエストデータを返信する。リクエストデータを受信した通信端末Ｄは、利用しているＷｅｂブラウザの仕様に従って、データの受信処理を行う。なお、本発明の機能を有しないＷｅｂブラウザにおいては、キャッシュ情報生成の通知が行えないため、一連の処理はここで完了する。携帯端末Ａにおいては、送信者チェックの段階で、リクエストを送信してきた通信端末Ｄは、電話帳データにもとづくリダイレクトが行えないということを認識しているので、リクエストデータの応答後、一連の処理を完了させる。
【００７８】
以上説明したように、本発明の携帯電話端末によれば、携帯電話端末のバッテリー残量や、電波強度に従って、データの応答可否を決めつつ、応答不可能な場合には他の携帯電話端末にリダイレクトすることで、データ共有システムに利用することができる。さらに、携帯電話端末の電話帳に基づいたアクセス制御を実施することで、利用者の利便性を向上しつつ、携帯電話端末の利用者の仲間内に限定したデータ共有を可能とするデータ共有システムに利用することができる。
【００７９】
尚、本発明の携帯情報端末は、上述の図示例にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【符号の説明】
【００８０】
１０  携帯電話端末
１０６  統括制御部
１０６ａ  サーバ機能部
１０６ｂ  応答ポリシー管理部
１０６ｃ  リダイレクト情報管理部
１０６ｄ  キャッシュ情報管理部
１０６ｅ  電話帳管理部
１０６ｆ  クライアント機能部
１０７  無線通信部
１０７ａ  送受信処理部
１０７ｂ  電波強度測定部
１０８  電源管理部
１０８ａ  電圧測定部
【図１】
2010183236.tif 000003
【図２】
2010183236.tif 000004
【図３】
2010183236.tif 000005
【図４】
2010183236.tif 000006
【図５】
2010183236.tif 000007
【図６】
2010183236.tif 000008
【図７】
2010183236.tif 000009
【図８】
2010183236.tif 000010
【図９】
2010183236.tif 000011
【図１０】
2010183236.tif 000012
【図１１】
2010183236.tif 000013
【図１２】
2010183236.tif 000014
【図１３】
2010183236.tif 000015