JP2015075820A - 端末装置、充電支援システム、充電支援方法およびプログラム - Google Patents

Abstract

【課題】 他の端末装置から充電が受けられるよう支援する技術を提供することを目的とする
【解決手段】
本発明に係る端末装置は、他の端末装置へ電力供給を依頼するリクエストを生成する受電処理部と、他の端末装置へ電力供給を申し出るオファーを生成する給電処理部と、の少なくとも何れかと、前記リクエストまたはオファーを送信する通信部と、を備えることを特徴とする。
【選択図】 図１

Description

本発明は、充電を支援する技術に関する。

近年、通信機器やゲーム機器等の携帯型の端末装置が急激に普及している。このような携帯型端末装置の電力は、一般的には搭載された二次電池で賄われる。ところが急速な機器の発展と共に二次電池にも高容量化や小型軽量化が要求され、電池性能だけで理想的な使用時間を実現することは、非常に困難な状況となっている。また、充放電サイクルが繰り返されれば放電容量維持率が低下するため、いずれは頻繁な充電が必要となってしまう。

しかしながら、二次電池の無制限な充電が可能なのは、未だコンセント等の定点設備が存在する場所に限られている。従って外出先や移動中では、利用者は他の充電用、或いはスペアの二次電池を別途持ち歩き利用しなければならない。特許文献１には、このような技術について記載されている。

特開２０１２−１９６０７５号公報

しかしながら、電池切れ時にこのような代替の二次電池を所持していない場合、或いは代替の二次電池そのものに充電切れが発生した場合は、当然ながら端末装置を利用することはできない。さらには、端末装置が通信機器である場合に、深刻な状況となる可能性が懸念される。何故ならば、緊急時において、唯一の連絡手段が失われてしまうことがあるからである。

そこで本発明は、他の端末装置から充電が受けられるよう支援する技術を提供することを目的とする。

すなわち、本発明に係る端末装置は、他の端末装置へ電力供給を依頼するリクエストを生成する受電処理部と、他の端末装置へ電力供給を申し出るオファーを生成する給電処理部と、の少なくとも何れかと、前記リクエストまたはオファーを送信する通信部と、を備えることを特徴とする。

また、上記端末装置は、前記通信部が前記リクエストまたは前記オファーを、前記他の端末装置へ直接送信することを特徴とする。

また、上記端末装置は、前記リクエストまたは前記オファーについて前記他の端末装置との合意があった場合に、当該他の端末装置との合流をガイドする支援処理部を、さらに備えることを特徴とする。

また、本発明の他の態様に係る充電支援システムは、上記端末装置と、サーバと、を含み、前記端末装置の前記通信部は、前記リクエストおよびオファーを前記サーバへと送信し、前記サーバは、前記リクエストまたはオファーが特定の端末装置へのリクエストまたはオファーであった場合に、当該リクエストまたはオファーに関する情報を前記特定の端末装置へと送信する出力処理部を備えることを特徴とする。

また、上記充電支援システムは、前記オファーおよびリクエストが不特定多数へのオファーまたはリクエストであった場合に、当該オファーまたはリクエストを前記記憶部に登録する情報管理部と、前記端末装置から前記不特定多数へのオファーまたはリクエストの提示要求を受け付けると、前記記憶部に登録される前記オファーまたはリクエストから、給電候補または受電候補を特定する候補特定部と、を備え、前記出力処理部は、当該給電候補または受電候補の前記オファーまたはリクエストに関する情報を、前記オファーまたはリクエストの提示要求送信元の端末装置へと送信することを特徴とする。

また、本発明の他の態様に係る充電支援システムは、前記給電候補および受電候補は、前記提示要求送信元の端末装置から、所定の範囲内に存在する端末装置から選択されることを特徴とする。

また、本発明の他の態様に係る充電支援システムは、前記情報管理部は、利用者の属性に関する情報と、当該利用者が他の端末装置の利用者に希望する属性に関する情報と、を前記記憶部に予め登録し、前記給電候補および受電候補は、前記提示要求送信元の端末装置の利用者の前記希望に応じた属性の利用者の端末装置から選択されることを特徴とする。

さらに、本発明の他の態様に係る充電支援システムは、上記端末装置と、サーバと、を含み、前記端末装置の前記通信部は、救助申請である前記リクエストを前記サーバへと送信し、前記サーバは、前記リクエストを受け付けると、所定の関連装置へ救助要請を発信する出力処理部を備えることを特徴とする。

また、本発明の他の態様に係る充電支援システムは、上記端末装置と、当該端末装置に給電を行う給電装置と、を含み、前記端末装置は、前記給電装置と通信可能な状態になった場合に、前記給電装置から給電を受けることを特徴とする。

さらに、上記端末装置は、他の端末装置への給電を行う際に、給電電力の大きさに比例するシンボルを表示させることを特徴とする。

上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。

本発明によると、他の端末装置から充電が受けられるよう支援することができる。

本発明の第一の実施形態に係る充電支援システム１００の構成例を示す図である。 端末装置１の機能構成例を説明するためのブロック図である。 設定情報１２１０の一例である。 端末装置１のハードウェア構成例を示す図である。 受電処理および給電処理についてのフロー図である。 ダイレクトリクエスト表示画面の一例である。 本発明の第二の実施形態に係る充電支援システム２００の構成例を示す図である。 利用者情報３２１１の一例である。 希望情報３２１２の一例である。 （ａ）リクエスト登録情報３２２０の一例である。（ｂ）オファー登録情報３２３０の一例である。 端末装置２の機能構成例を説明するためのブロック図である。 設定情報２２１０の一例である。 探索処理の一例を示すフロー図である。 オープンオファーレポート画面の一例である。 待機処理の一例を示すフロー図である。 プライベートリクエストレポート画面の一例である。 特定処理の一例を示すフロー図である。 本発明の第三の実施形態に係る充電支援システム３００の構成例を示す図である。 履歴情報４２１０の一例である。 本発明の第四の実施形態に係る充電支援システム４００の構成例を示す図である。 リクエスト登録情報５２２０の一例である。 端末装置６の構成例を示す図である。 設定情報６２１０の一例である。 端末装置６の実行する救助申請処理の一例を示すフロー図である。 サーバ５の実行する救助要請処理の一例を示すフロー図である。 本発明の第五の実施形態に係る充電支援システム５００の構成例を示す図である。 端末装置８の機能構成例を説明するためのブロック図である。 設定情報８２１０の一例である。 給電装置９の機能構成例を説明するためのブロック図である。 給電履歴９２１０の一例である。 個人情報７２１０の一例である。 端末装置８及び給電処理９の実行する処理の一例を示すフロー図である。 ユーザーインターフェイス画面１０００の一例である。

＜＜第一の実施形態＞＞
以下に、本発明に係る第一の実施形態を適用した充電支援システム１００について、図面を参照して説明する。

図１は、本発明の第一の実施形態に係る充電支援システム１００の構成例を示す図である。本発明における充電支援システム１００には、端末間を相互に直接接続する通信ネットワークを用いることが可能な複数の端末装置１が含まれる。

端末装置１は、電力を供給する給電側の端末として、或いは、電力の供給を受ける受電側の端末として機能するものである。よって端末装置１は、電力源により動作する装置であればどのようなものであっても良い。具体的な例としては、例えば一般的なコンピュータとしての動作を行うことが可能な携帯電話機、ゲーム機、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等の移動体が挙げられる。なお、端末装置１は必ずしも移動体に限定されるものではないが、給電側、或いは受電側の何れかが移動体であることが望ましい。

本実施の形態においては、端末装置１は、電力源として二次電池を搭載した、携帯電話機であるものとする。以下、受電側としてふるまう端末を端末装置１ａ、給電側の端末としてふるまう端末装置１ｂ、その識別を要さない場合には単に端末装置１と称する。

図２は、端末装置１の機能構成例を説明するためのブロック図である。端末装置１には、制御部１１０と、記憶部１２０と、通信部１３０と、伝送部１４０と、出力部１５０と、が含まれる。

制御部１１０には、通信処理部１１１と、受電処理部１１２と、給電処理部１１３と、支援処理部１１４と、情報管理部１１５と、が含まれる。

通信処理部１１１は、所定の距離内に存在する他の端末装置と、端末間を相互に直接接続する通信ネットワークの構築処理を実行する。具体的に、本実施の形態に係る受電側の端末装置１の通信処理部１１１は、通信部１３０に、通信可能な距離内に存在する他の端末装置との間で、ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）を介さない通信ネットワークを構築させる。なお、端末装置１の構築する端末間の通信ネットワークは、必ずしも１対１の通信方式に限定されず、１対ｎ（１対多数）、および、ｎ対ｎ（多数対多数）であってもよい。

受電処理部１１２は、端末装置１が受電側の端末（１ａ）として機能するための受電処理を実行する。具体的に、本実施の形態に係る受電側の端末装置１ａの受電処理部１１２は、給電希望相手の端末装置１ｂにダイレクトリクエストを発信し、その承認の有無を取得する。

給電処理部１１３は、端末装置１が給電側の端末（１ｂ）として機能するための給電処理を実行する。具体的に、本実施の形態に係る給電側の端末装置１ｂの給電処理部１１３は、端末装置１ａからのダイレクトリクエストを受信して、当該ダイレクトリクエスト表示画面を構成し、利用者からの承認を受け付ける。

支援処理部１１４は、端末装置１ａおよび１ｂが実際の受給電を行う際に、利用者をガイドし、合流を支援する。具体的に、支援処理部１１４は、受電側の端末装置１ａと給電側の端末装置１ｂとで合意が成立した後、両端末の利用者が電力の受け渡しを実行するための連絡や移動に関する情報を提供する。

情報管理部１１５は、利用者に関する情報を受け付けて、これを登録する。具体的に、情報管理部１１５は、利用者のニックネームと、所有する端末装置に関する端末情報と、を予め受け付けて、記憶部１２０に後述する設定情報１２１０として登録する。端末情報とは例えば、端末装置のバッテリ容量や利用可能な充電規格等である。なお、本実施の形態においては、利用可能な充電規格として登録される方法による充電に必要な機材（例えば、充電ケーブルやパッド等）は、利用者がこれを保持しているものとする。

端末装置１の記憶部１２０には、設定情報記憶部１２１が含まれる。

図３は、設定情報記憶部１２１に記憶される設定情報１２１０の一例である。設定情報１２１０には、利用者のニックネームに関する情報が格納されるニックネーム格納領域１２１ａと、端末装置１のバッテリ容量や、利用可能な充電規格等の、端末に関する情報が格納される端末情報格納領域１２１ｂと、が含まれる。

通信部１３０は、通信処理部１１１からの信号に基づき、通信可能な距離内に存在する他の端末装置との間で、ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）を介さない通信ネットワークを構築するとともに、ネットワークを介した情報の送受信を行う。

伝送部１４０は、他の装置の内部電源との間で、電力の受給電を行うものである。なお、電力伝送には、あらゆる方法を利用することができる。例えば、一般的な電力線の他、電磁誘導、振動、光、音、熱等が挙げられる。

出力部１５０は、ディスプレイやプリンタ等の画像出力装置に対する出力依頼を受け付けると、出力を依頼された画像を後述の表示装置９６に表示させる。

以上が、端末装置１の構成である。特に図示しないが、端末装置１は、一般的なコンピュータとしての動作を行うことが可能である。すなわち、端末装置１は、利用者によるキーボードあるいはマウス、タッチパネル、タッチペン等による入力を受け付け、記憶部１２０に格納された情報を参照して、ディスプレイ等に所定のレイアウトで表示させることができる。

図４は、端末装置１のハードウェア構成例を示す図である。端末装置１は、演算装置９１と、主記憶装置９２と、記憶装置９３と、伝送装置９４と、入力装置９５と、表示装置９６と、ＧＰＳ受信装置９７と、通信装置９８と、各装置をつなぐバス９９と、を少なくとも備える。

演算装置９１は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの演算装置である。

主記憶装置９２は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などのメモリ装置である。

記憶装置９３は、デジタル情報を記憶可能な、いわゆるハードディスク（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）あるいはフラッシュメモリなどの不揮発性記憶装置である。

伝送装置９４は、内部電源、例えば二次電池と外部デバイスとの間での受給電を可能にする任意のインターフェースである。電力伝送用のインターフェースとしては例えば、電磁誘導による無接点受給電を可能とするコイルや、レーザー光による無接点充電を可能とするレーザー送光および受光ユニット等が挙げられる。この他にも、電力線や、振動、光、音等のあらゆる電力伝送方法に適したインターフェースが利用できる。もちろん、端末装置１が必ずしもこのようなエネルギー変換能を有する必要はない。よって、端末装置１は、充電ケーブルや充電パッド等の外部モジュールと接続することで受給電可能な端子を有する構成であれば足りる。

入力装置９５は、タッチパネル、キーボード、マウス、タッチペンその他のハードスイッチ等である。

表示装置９６は、液晶ディスプレイや有機ＥＬ等の画像表示装置である。

ＧＰＳ受信装置９７は、ＧＰＳ衛星の信号を受信して衛星位置を求め、これに基づいて自機の位置を算出する装置である。

通信装置９８は、ネットワークを介して情報の送受信を行う装置である。ネットワークとしては例えば、インターネット、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＰＡＮ（Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ピアツーピア型通信路、携帯電話網、無線通信路等を含むあらゆる通信網である。

なお、本実施の形態に係る端末装置１の通信装置９８は、端末間を相互に直接接続する通信方式を採ることが可能である。このような通信方式としては例えば、ＩＥＥＥ８０２．１１ｎに準拠する無線ＬＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＲＦＩＤタグ、ＩｅＤＡに準拠する赤外線通信等のインターフェースを利用することが挙げられる。

演算装置９１と、主記憶装置９２と、記憶装置９３と、伝送装置９４と、入力装置９５と、表示装置９６と、ＧＰＳ受信装置９７と、通信装置９８とは、バス９９等の接続導線により互いに接続される。なお、入力装置９５および表示装置９６は、端末装置１の外部に独立して存在する場合には、バス９９に直接接続されるものではなく、所定の信号線（ＵＳＢケーブル等各種ケーブル、あるいはＢｌｕｅｔｏｏｔｈ（登録商標）等の無線を含む）を介して接続されるものであることは言うまでもない。

上記した端末装置１の通信処理部１１１と、受電処理部１１２と、給電処理部１１３と、支援処理部１１４と、情報管理部１１５とは、演算装置９１に処理を行わせるプログラムによって実現される。このプログラムは、主記憶装置９２または図示しないＲＯＭ装置内に記憶され、実行にあたって主記憶装置９２上にロードされ、演算装置９１により実行される。

また、端末装置１の記憶部１２０は、主記憶装置９２および記憶装置９３により実現される。また、通信部１３０は、通信装置９８により実現される。伝送部１４０は、伝送装置９４により実現される。出力部１５０は、表示装置９６によって実現される。以上が、端末装置１のハードウェア構成例である。

[動作の説明]
次に、本実施形態における端末装置１ａおよび１ｂの動作を説明する。

最初に、端末装置１の通信処理部１１１の実行する一般的な端末機器間における通信ネットワークの構築処理（Ａｃｔｉｖｅ ｓｃａｎ）の一例について簡単に説明する。なお、本例では通信ネットワークとして無線ＬＡＮを利用する例を挙げるが、これに限定されず、所定の距離内において端末装置間での情報の送受信が可能であればどのような通信手段を利用してもよい。

通信処理部１１１はまず、ある周波数チャネルにおいて通信相手を発見するためのプローブ要求を同報送信する。送信後、所定の時間内に要求に対し他の端末装置１からプローブ応答があれば、応答元を通信相手として認証要求を送信する。そして、認証要求に対する認証応答を受けた後に、接続を開始する。なお、時間内にプローブ応答が無ければ、通信処理部１１１は他の周波数チャネルに切り換えて処理を繰り返す。

通信処理部１１１は、当然プローブ要求の受信側にもなり得る。即ち通信処理部１１１は、他の端末装置１からプローブ要求を受信すると、これに対しプローブ応答を返す。また、認証要求を受けるとこれに認識応答を返し、接続を開始する。

このように端末装置１は、常に通信相手を走査して、自律的に端末間における通信ネットワークの構築処理を行っているものとする。また本実施の形態においては一例として、構築される端末間通信ネットワークは、１対１の通信方式であるものとする。

次に、受電側としてふるまう端末装置１ａが実行する受電処理、および給電側としてふるまう端末装置１ｂが実行する給電処理について説明する。図５は、端末装置１ａの実行する受電処理、および端末装置１ｂの実行する給電処理のフロー図である。

受電処理は、端末装置１ａが稼働を開始すると、或いは受電処理の開始の指示を受け付けると、また或いはバッテリ残量が所定の値以下に達する等の所定の条件を満足すると開始される。あるいは、端末装置１ａの稼働中に定期的に受電処理が実行されてもよい。

まず、端末装置１ａの受電処理部１１２は、端末間通信ネットワークが構築されているか否かを判断する（ステップＳ１１）。具体的には、受電処理部１１２は、通信部１３０によって、他の端末装置との間に端末間通信ネットワークが成立しているか否かを判断する。端末間通信ネットワークが成立している場合には、ステップＳ１２へと進む。また、端末間通信ネットワークが成立していない場合には、成立するまでステップＳ１１を繰り返す。

次に、端末装置１ａの受電処理部１１２は、端末間通信ネットワークが成立している端末装置１ｂに対して、ダイレクトリクエストを送信する（ステップＳ１２）。本実施形態におけるダイレクトリクエストとは、特定の給電を希望する相手に直接、給電の依頼を行うものである。具体的に、受電処理部１１２は、設定情報記憶部１２１に記憶されている設定情報１２１０から、利用者のニックネームと、端末情報と、を読み出して、これらの情報を含むダイレクトリクエストを生成し、端末装置１ｂに送信する。なお、ダイレクトリクエストに付随される情報はこれに限定されず、第二の実施形態において説明するようなリクエストメッセージや、個人情報等、他のどのような情報を追加してもよい。端末装置１ａはそのまま所定の時間待機し、端末装置１ｂからの応答を待つ。

ここで、端末装置１ｂの給電処理の説明に移る。端末装置１ｂの給電処理部１１３は、端末装置１ａからのダイレクトリクエストを受信すると、ダイレクトリクエスト表示画面を生成する（ステップＳ２１）。具体的に、給電処理部１１３は、端末装置１ａから受信したダイレクトリクエストに含まれる情報、ここでは端末装置１ａの利用者のニックネームと、端末装置１ａの端末情報と、を読み出して、これらを配置したダイレクトリクエスト表示画面を生成し、出力部１５０を介して表示装置９６に表示させる。

図６に、ダイレクトリクエスト表示画面の一例を示す。ダイレクトリクエスト表示画面９００には、利用者のニックネーム、端末装置１ａの端末情報、給電に合意するか否かを入力するための選択を受け付ける選択領域等が表示される。これにより端末装置１ｂの利用者は、相手先のバッテリの容量や、利用可能な充電規格等を確認することができる。例えば、相手の端末のバッテリ容量が自端末よりも遙かに大きい場合、給電の効果は殆ど無いと考えられる。逆に、相手の端末のバッテリ容量が自端末よりも遙かに小さい場合、大きな給電効果が期待できる。また、充電規格から、充電に要する時間をある程度推測することもできる。

次に給電処理部１１３は、利用者が給電に合意するか否かを判断する（ステップＳ２２）。具体的に給電処理部１１３は、利用者から給電に合意する選択（例として、図中の「はい」ボタン）、或いは、合意しない選択（例として、図中の「いいえ」ボタン）を受け付ける。

利用者が給電に合意しなかった場合（ステップＳ２２のＮＯ）、給電処理部１１３は、端末装置１ａに非合意応答を送信し（ステップＳ２３）、給電処理を終了する。

なお給電処理部１１３は、ダイレクトリクエストを受け付けた段階で、端末情報から自端末の充電規格が相手端末と合致しているか否かを判断して、合致しない場合には自動的に非合意応答を送信し、給電処理を終了してもよい。

利用者が給電に合意した場合（ステップＳ２２のＹＥＳ）、給電処理部１１３は、端末装置１ａに合意応答を送信し（ステップＳ２４）、認証応答を待つ。認証応答があれば、支援処理部１１４に支援処理の開始を要求し（ステップＳ２５）、給電処理を終了する。

端末装置１ａの受電処理に戻って、受電処理部１１２は、ダイレクトリクエストを送信後（ステップＳ１２）、所定の時間内に給電を希望する端末装置１ｂから合意応答があったか否かを判断する（ステップＳ１３）。合意がなかった（応答が無い、或いは非認証応答があった）場合には（ステップＳ１３のＮＯ）、受電処理部１１２は、通信処理部１１１に他の装置との新たな通信ネットワークを構築するよう要求して（ステップＳ１４）、受電処理を終了する。なおその際には、合意が無かった旨のメッセージ（「応答がありませんでした」「同意が得られませんでした」等）を通知する通知画面を構成して、出力部１５０を介して表示装置９６に表示させてもよい。

一方、合意があった（合意応答があった）場合には（ステップＳ１３のＹＥＳ）、受電処理部１１２は、端末装置１ｂを給電相手として特定し、認証応答を返す（ステップＳ１５）。そして、支援処理部１１４に支援処理の開始を要求して（ステップＳ１６）、受電処理を終了する。

次に、支援処理部１１４の動作について説明する。端末装置１ａの支援処理部１１４および端末装置１ｂの支援処理部１１４は、支援処理の開始要求を受け付けると、任意の誘導方法で端末装置１ａの利用者と、端末装置１ｂの利用者とが出会って受給電を行えるよう支援する。誘導方法の例としては、次のようなものが挙げられる。

＜特徴支援＞
支援処理部１１４は、支援処理の開始要求を受け付けると、例えば、給電相手の特定に要する特徴を設定させる特徴情報設定画面を出力させ、給電側の利用者からの設定を受け付ける。このような特徴の例としては、利用者によるもの（例えば、身振りや、服装等）、または、端末装置によるもの（所定の色や点滅パターンの光、音等）が挙げられる。支援処理部１１４は、当該特徴が設定されると、設定された特徴に関する情報を、受電側の利用者の端末装置１に送信する。当該情報を受信した受電側の利用者の支援処理部１１４は、給電側の特長に関する情報を表示装置９６に表示させる。受電側の利用者は、当該特徴を頼りに給電側の利用者に合流する。このような方法は例えば、数メートル内の通信ネットワークを利用している際に、特に有効である。
なお、支援処理部１１４による特徴支援は上述のものに限らない。利用者の特長情報は設定支援処理の開始要求の度に入力せず、予め設定された特徴情報を用いてもよい。また、特徴情報の送信についても、給電側から受電側に限らず、受電側から給電側に送信するよう、あるいは、受電側と給電側とが互いに送信しあうように構成してもよい。

＜通信支援＞
支援処理部１１４は、支援処理の開始要求を受け付けると、受電／給電相手の端末装置１に対し所定の連絡手段の開始を要求すると共に、自端末においても連絡手段を開始する。連絡手段としては例えば、文字や音声によるリアルタイムな交信が可能なＵＩの提供（チャット、ボイスチャット等の起動）等が挙げられる。両端末装置の利用者は、このようなインターフェースを介して相互に連絡を取り合い合流する。

＜位置支援＞
支援処理部１１４は、支援処理の開始要求を受け付けると、受電／給電相手の端末装置１に対して、自端末の位置に関する情報を含む位置通知を、所定のタイミングごとに送信する。これに対し相手端末の支援処理部１１４も、自端末の位置に関する情報を含む位置通知の送信を開始する。そして、端末装置１ａおよび１ｂの支援処理部１１４は、地図上に互いの位置情報を標記した地図画面を生成して、出力部１５０を介して表示装置９６に表示させる。両端末装置の利用者は、相手の位置情報を頼りに合流する。このような支援方法は例えば、数十メートル以上に亘るような通信ネットワークを利用している際に、特に有効である。

＜誘導支援＞
なお、合流地点を設定して、当該地点への誘導を行ってもよい。その場合、端末装置１ａおよび１ｂの支援処理部１１４は、互いの位置から合流地点を特定する。合流地点の特定は例えば、互いの中間地点、周辺に存在するランドマーク、店、建物、駅等、待ち合わせに適した地点が選択される。合流地点が特定されると、両端末装置の支援処理部１１４は、合流地点へ利用者を誘導する誘導処理を開始する。誘導処理には、一般的なナビゲーション機能を利用することができる。なお、合流地点は、互いの利用者に選択させてもよい。その場合、端末装置１ａは、選択画面を生成して、出力部１５０を介して表示装置９６に表示させる。このような支援方法は例えば、数十メートル以上に亘るような通信ネットワークを利用している際に、特に有効である。

以上、支援処理部１１４の支援処理について説明したが、必ずしも上記に限定されず、既知のあらゆる方法を用いて支援を行うことが可能である。利用者に支援方法を選択させてもよく、複数の方法を組み合わせてもよい。さらに、条件によって最適な支援方法が設定されてもよい。

例えば、相手の端末装置との距離が所定の値よりも大きい場合は位置支援や誘導支援が、所定の値よりも小さい場合は特徴支援や通信支援が選択されてもよく、また途中で支援方法を切り換えてもよい。さらに例えば、バッテリ残量が少ない場合には、より電力消費の少ない支援が設定されてもよい。

以上、第一の実施形態に係る充電支援システム１００について説明した。このような充電支援システム１００によれば、受電側の端末装置は速やかに給電を希望する端末装置を検索して、給電相手を発見し、電力の受給電を行うことが可能である。また、範囲の限定された端末間通信ネットワークを利用することで、比較的近い距離の端末装置を検出することができ、タイムラグが小さいため短時間で給電相手と合流することができる。

＜＜第二の実施形態＞＞
以下に、本発明に係る第二の実施形態を適用した充電支援システム２００について、図面を参照して説明する。なお、上述の実施形態と略同様の構成を有するものには同様の符号を付し、詳細な説明は省略する。

本実施の形態に係る充電支援システム２００では、受電側の端末装置がリクエストにより給電側の端末装置を募るのに対し、給電側の端末装置についてもオファーにより受電側の端末装置を募ることが可能な構成である。

図７は、本発明の第二の実施形態に係る充電支援システム２００の構成例を示す図である。本発明における充電支援システム２００には、複数の端末装置２（図中では、端末装置２ａ、２ｂとして示す）と、電力の受電／給電を行う端末候補を特定するサーバ３と、が含まれる。

サーバ３には、制御部３１０と、記憶部３２０と、通信部３３０と、が含まれる。

制御部３１０には、情報管理部３１１と、候補特定部３１２と、出力処理部３１３と、支援処理部３１４と、が含まれる。

情報管理部３１１は、端末装置２の利用者に関する情報を管理する。具体的に、情報管理部３１１は、端末装置２から送信される個人情報を受け付けて、当該個人情報を記憶部３２０の個人情報記憶部３２１へと格納する（図８および図９参照）。

また、情報管理部３１１は、受電の不特定多数への依頼（オープンリクエスト）、給電の不特定多数への申出（オープンオファー）の登録を行う登録処理を実行する。具体的に、情報管理部３１１は、受信側の端末装置２ａから送信されるオープンリクエスト登録要求を受け付けて、当該リクエストをリクエスト記憶部３２２にリクエスト登録情報３２２０（図１０（ａ）参照）として格納する。さらに、情報管理部３１１は、給信側の端末装置２ｂから送信されるオープンオファー登録要求を受け付けて、当該オファーをオファー記憶部３２３にオファー登録情報３２３０（図１０（ｂ）参照）として格納する。

なお、情報管理部３１１は、端末装置２からオープンリクエストまたはオープンオファーの取消要求を受け付けた場合には、リクエスト登録情報３２２０またはオファー登録情報３２３０から、該当するリクエストまたはオファーを削除する。

候補特定部３１２は、端末装置２の受電／給電相手候補となる端末を探索して特定する特定処理を実行する。具体的に、候補特定部３１２は、受電側の端末装置２ａからオープンオファー提示要求を受け付けると、オファー登録情報３２３０に登録される端末の中から、条件に合致する給電候補端末を探索して特定する。また、候補特定部３１２は、給電側の端末装置２ｂからのオープンリクエスト提示要求を受け付けると、リクエスト登録情報３２２０に登録されている端末の中から、条件に合致する受電候補端末を特定する。

これらの特定処理は即ち、オープンオファー／リクエストを出力した端末装置２の利用者が設定した条件に見合う候補端末を特定するものである。マッチング方法にはどのような方法を用いても構わない。具体的な処理の例は、以下の動作の説明において後述する。

出力処理部３１３は、候補特定部３１２が特定した受電候補端末、或いは給電候補端末に関するオープンリクエスト情報／オープンオファー情報を、提示要求の送信元である端末装置２へと送信する。

また、出力処理部３１３は、受電側の端末装置２ａからのプライベートリクエスト送信要求を受け付けると、当該リクエストに関するプライベートリクエスト情報を対象である給電側の端末装置２ｂへと送信する。さらに、出力処理部３１３は、給電側の端末装置２ｂからのプライベートオファー送信要求を受け付けると、当該オファーに関するプライベートオファー情報を対象である受電側の端末装置２ａへと送信する。

支援処理部３１４は、端末装置２ａおよび２ｂが実際の受電／給電を行う際、利用者をガイドし、合流を支援する。具体的に、支援処理部３１４は、端末装置２からのプライベートリクエストまたはプライベートオファーへの合意応答を受け付けると、受電側および給電側の両端末が電力の受け渡しを実行するための連絡や移動に要する情報を提供する。例えば、両端末にチャットやボイスチャット等のインターフェースの立ち上げを要求し、両者間を接続するネットワークを提供する。また、地図等のインターフェースの立ち上げを要求して、両者のＧＰＳ情報を出力する。詳細な支援内容については支援処理部１１４と同様であるため、説明は省略する。

ここで、各リクエストとオファーについて説明する。本実施の形態においては、受電側の端末装置２ａは、オープンリクエスト／プライベートリクエストによって、給電側の端末装置２ｂを募ることができる。逆に、給電側の端末装置２ｂは、オープンオファー／プライベートオファーによって、受電側の端末装置２ａを募ることができる。

オープンリクエストとは、受電側の端末装置２ａによる、給電の不特定多数への公開依頼である。オープンリクエストは、サーバ３の情報管理部３１１によりリクエスト記憶部３２２にプールされ、候補特定部３１２が特定した端末装置２ｂに公開される。

オープンオファーとは、給電側の端末装置２ｂによる、受電の不特定多数への公開申出である。オープンオファーは、サーバ３の情報管理部３１１によりオファー記憶部３２３にプールされ、候補特定部３１２が特定した端末装置２ａに公開される。

プライベートリクエストとは、受電側の端末装置２ａが、給電端末候補の中から選択された特定の端末装置２ｂに対して給電の依頼を行うものである。プライベートリクエストは、サーバ３の出力処理部３１３を介して、受電側の端末装置２ａから相手先の端末装置２ｂへと送られる。

プライベートオファーとは、給電側の端末装置２ｂが、受電端末候補の中から選択された特定の端末装置２ａに対して、受電の申出を行うものである。プライベートオファーは、サーバ３の出力処理部３１３を介して、給電側の端末装置２ｂから相手先の端末装置２ａへと送られる。

記憶部３２０には、個人情報記憶部３２１と、リクエスト記憶部３２２と、オファー記憶部３２３と、が含まれる。

個人情報記憶部３２１には、利用者情報３２１１と、希望情報３２１２と、が記憶されている。これらの個人情報は、サーバ３が候補端末を探索して特定する特定処理を実行する際に、主に利用される。

図８は、利用者情報３２１１の一例である。利用者情報３２１１には、利用者を識別するために割り当てられた利用者ＩＤが格納される利用者ＩＤ格納領域３２１ａと、当該利用者ＩＤ毎に、利用者のニックネームに関する情報が格納されるニックネーム格納領域３２１ｂと、利用者の属性に関する情報が格納される属性格納領域３２１ｃと、が含まれる。

利用者の属性とは、利用者に関する情報を任意の属性で区分したものである。例えば、氏名、生年月日、年齢、性別、職業、所属先、趣味、ホームページのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）等である。図示しないが、その他にも、住所、出身地、家族構成、身長、体重、年収、電話番号、顔写真やアバター等の画像、特定の利用者ＩＤ（友人登録を行った利用者の利用者ＩＤ等）、メールアドレス等が含まれていてもよい。なお、ここでは各属性について、利用者が選択した公開または非公開を識別するための情報も同時に格納されているものとする。ここで公開が選択された属性は、各リクエストやオファーで他の利用者に対し公開される。

図９は、希望情報３２１２の一例である。希望情報３２１２には、利用者ＩＤ格納領域３２１ａ毎に、受電／給電の候補となる端末の利用者に対する各属性の希望に関する情報が格納される希望属性格納領域３２１ｄが含まれる。なお、希望属性は必ずしも全ての属性に対して設定されるものではなく、事前に利用者が登録した希望の属性に対してのみ設定がなされる。例えば、図９における利用者ＩＤ０００００１の利用者は、年齢が２０〜４０歳で、趣味が読書の相手を、受電／給電候補として希望している。利用者ＩＤ０００００２の利用者は、年齢が１８〜２２歳の学生で、ホームページアドレスを公開している相手を、受電／給電候補として希望している。

リクエスト記憶部３２２には、オープンリクエスト登録要求のあった端末装置２ａのリクエスト登録情報３２２０が登録される。図１０（ａ）は、リクエスト登録情報３２２０の一例である。リクエスト登録情報３２２０には例えば、受電側の端末装置２ａの利用者ＩＤと、端末情報、リクエストメッセージ等が格納されている。

オファー記憶部３２３には、オープンオファー登録要求のあった端末装置２ｂのオファー登録情報３２３０が登録される。図１０（ｂ）は、オファー登録情報３２３０の一例である。オファー登録情報３２３０には例えば、給電側の端末装置２ｂの利用者ＩＤと、端末情報、オファーメッセージ等が格納されている。

次に、端末装置２について説明する。図１１は、端末装置２の機能構成例を説明するためのブロック図である。端末装置２には、制御部２１０と、記憶部２２０と、通信部１３０と、伝送部１４０と、出力部１５０と、が含まれる。

制御部２１０には、情報管理部２１１と、受電処理部２１２と、給電処理部２１３と、が含まれる。

情報管理部２１１は、予め利用者から個人情報を受け付けて、これをサーバ３に送信する処理を実行する。具体的に、情報管理部２１１は、予め利用者に対し図示しない入力画面を構築して、出力部１５０を介して表示装置９６に表示させる。なお、入力画面はＷｅｂページ等であってもよい。そして、当該入力画面を介して利用者から個人情報（図８および図９参照）の入力を受け付け、これをサーバ３へと送信する。個人情報は例えば、利用者情報３２１１に登録されるニックネームや、属性情報とその表示・非表示、および、希望情報３２１２に登録される受電／給電候補となる利用者への希望属性とその内容である。

また、情報管理部２１１は、予め利用者からリクエストやオファーに関する設定情報を受け付ける設定処理を実行する。設定内容は、設定情報記憶部２２１に設定情報２２１０として記憶される（図１２参照）。

受電処理部２１２は、端末装置２が受電側の端末（２ａ）として機能するための受電処理を実行する。受電処理は、利用者が給電相手を積極的に探す探索処理と、給電相手からの申出を待つ待機処理と、オープンリクエストの状況を監視する監視処理に分けられる。

＜探索処理＞
受電処理部２１２は、オープンオファーをサーバ３から取得し、各オファーの表示画面を構成して、出力部１５０を介して表示装置９６に表示させる。そして、利用者からのオープンオファーの選択を受け付けて、該当オファーに対するプライベートリクエストを、サーバ３へと送信する。

＜待機処理＞
受電処理部２１２は、自端末へのプライベートオファーをサーバ３から取得し、各オファーの表示画面を構成して、出力部１５０を介して表示装置９６に表示させる。そして、利用者からプライベートオファーに合意するか否かの選択を受け付けて、該当オファーに対する認証応答をサーバ３へと送信する。

＜監視処理＞
受電処理部２１２は、設定情報２２１０を監視し、オープンリクエストの登録要求および削除要求の出力を行う。具体的に受電処理部２１２は、利用者が設定したオープンリクエスト条件（バッテリ残量等）に応じて、設定情報２２１０のオープンリクエスト状況格納領域２２１ｃに格納されるステータスのＯＮ／ＯＦＦを切り換えると共に、サーバ３にオープンリクエストの登録要求、および削除要求を送信する。

給電処理部２１３は、端末装置２が給電側の端末（２ｂ）として機能するための給電処理を実行する。給電処理は、利用者が受電相手を積極的に探す検索処理と、受電相手からの依頼を待つ待機処理と、オープンオファーの状況を監視する監視処理に分けられる。

＜探索処理＞
給電処理部２１３は、オープンリクエストをサーバ３から取得し、各リクエストの表示画面を構成して、出力部１５０を介して表示装置９６に表示させる。そして、利用者からのオープンリクエストの選択を受け付けて、該当リクエストに対するプライベートオファーを、サーバ３へと送信する。

＜待機処理＞
給電処理部２１３は、自端末へのプライベートリクエストをサーバ３から取得し、各リクエストの表示画面を構成して、出力部１５０を介して表示装置９６に表示させる。そして、利用者からプライベートリクエストに合意するか否かの選択を受け付けて、該当リクエストに対する認証応答をサーバ３へと送信する。

＜監視処理＞
給電処理部２１３は、設定情報２２１０を監視し、オープンオファーの登録要求および削除要求の出力を行う。具体的に給電処理部２１３は、利用者が設定したオープンオファー条件（バッテリ残量等）に応じて、設定情報２２１０のオープンオファー状況格納領域２２１ｆに格納されるステータスのＯＮ／ＯＦＦを切り換えると共に、サーバ３にオープンオファーの登録要求、および削除要求を送信する。

記憶部２２０には、設定情報記憶部２２１が含まれる。設定情報記憶部２２１には、設定情報２２１０が記憶されている。

図１２は、設定情報２２１０の一例である。設定情報２２１０には、予め取得された利用者ＩＤが格納される利用者ＩＤ格納領域２２１ａと、端末情報が格納される端末情報格納領域２２１ｂと、オープンリクエストを登録しているか否かの状況が格納されるオープンリクエスト状況格納領域２２１ｃと、オープンリクエスト登録要求および削除要求を出力する条件が格納されるオープンリクエスト条件格納領域２２１ｄと、オープンリクエストに登録されるメッセージが格納されるリクエストメッセージ格納領域２２１ｅと、オープンオファーを登録しているか否かの状況が格納されるオープンオファー状況格納領域２２１ｆと、オープンオファー登録要求および削除要求を出力する条件が格納されるオープンオファー条件格納領域２２１ｇと、オープンオファーに登録されるメッセージが格納されるオファーメッセージ格納領域２２１ｈと、が含まれている。

オープンリクエスト条件は、条件に達した場合に自動でオープンリクエストの登録と削除が行われるものである。これには例えばバッテリ残量で登録と削除を行うような条件を設定することができる。即ち、バッテリ残量が１０％未満となった場合にオープンリクエストを登録し、１０％以上となった場合はオープンリクエストを削除する要求を送信するような設定である。オープンオファー条件についても同様に、バッテリ残量が８０％以上となった場合にオープンオファーを登録し、８０％未満となった場合はオープンオファーを削除する要求を送信するように設定できる。これにより、受電側／給電側として適格でないオープンリクエストやオープンオファーを排除できる。なお、これに限定されず、自宅からの距離や、使用時間等を条件として設定してもよい。

また、オープンリクエストとオープンオファーの登録要求および削除要求は、利用者の操作によってのみ送信される設定を選択可能としてもよい（手動設定）。本実施の形態においては、プライベートリクエストやプライベートオファーは、オープンリクエストやオープンオファーでの公開情報に基づいて送信されるため、利用者はオープンリクエストおよびオープンオファーの登録をしないことで、他者から受電の依頼や給電の申出を受けずにすむ。逆に、被災地等で電力に不安がある場合や、ボランティア活動等を行う場合には、常にオープンリクエストおよびオープンオファーの登録を行うことで、需要者と供給者が出会い易くなる。また、オープンオファーは必ずしも必要ではなく、常に全利用者を給電候補として（即ち、常時オープンオファー状況がＯＮの状態）、参加させてもよい。

[動作の説明]
次に、本実施形態における端末装置２の動作を説明する。

まず、最初に受電処理部２１２および給電処理部２１３が実行する探索処理について説明する。図１３は、各部の探索処理の一例を示すフロー図である。各部の探索処理は、「オファー」と「リクエスト」を読み替える点のみで異なっているため、ここでは受電処理部２１２が実行する探索処理について説明し、給電処理部２１３の実行する探索処理についてはその詳細な説明を省略する。

探索処理は、端末装置２が稼働を開始すると、或いは探索処理の開始の指示を受け付けると、また或いは所定の条件を満足すると、また或いは、稼働中に定期的に開始される。

＜探索処理＞
受電処理部２１２は、まず、利用者からオープンオファーを見るか否かの選択を受け付ける（ステップＳ３１）。具体的には、受電処理部２１２は、利用者にオープンオファーを見るか否かの選択を受け付ける選択画面を構成して出力部１５０を介して表示装置９６に表示させ、当該画面を介して利用者から選択を受け付ける。オープンオファーを見ない選択を受け付けた場合（ＮＯ）、受電処理部２１２は処理を終了する。オープンオファーを見る選択を受け付けた場合（ＹＥＳ）、受電処理部２１２は、ステップＳ３２へと処理を進める。

オープンオファーを見る選択を受け付けた場合（ステップＳ３１でＹＥＳ）、受電処理部２１２は、サーバ３からオープンオファーを取得し、オープンオファーレポート画面を構成して、出力部１５０を介して表示装置９６に表示させる（ステップＳ３２）。具体的に、受電処理部２１２は、設定情報２２１０に格納される利用者ＩＤを読み出して、当該ＩＤを含むオープンオファーの提示要求を、サーバ３へ送信する。そして、サーバ３からの応答によりオープンオファー情報を取得すると、図１４に記載するような、各オファーのオープンオファーレポート画面９０１を構成する。なお、オープンオファー情報には例えば、各オファー元の利用者ＩＤ、ニックネーム、端末情報、属性情報（公開設定のもの）、オファーメッセージに関する情報が含まれているものとする。

オープンオファーレポート画面９０１は例えば、オープンオファー情報に含まれる各オファー元の利用者のニックネーム、端末情報、オファーメッセージ、属性情報、そしてプライベートリクエストを送信するか否かを選択するための選択領域等から構成される。

次に、受電処理部２１２は、利用者からいずれかのオープンオファーにプライベートリクエストを送信する選択があったか否かを判断する（ステップＳ３３）。プライベートリクエストを送信する選択があった場合には（ＹＥＳ）、ステップＳ３４へと処理を進める。

プライベートリクエストを送信する選択があった場合（ステップＳ３３でＹＥＳ）、受電処理部２１２は、サーバ３にプライベートリクエスト送信を要求する（ステップＳ３４）。具体的に、受電処理部２１２は、リクエスト先の利用者ＩＤと、設定情報２２１０に格納される自端末の利用者ＩＤと端末情報、そしてリクエストメッセージを読み出して、プライベートリクエスト送信要求としてサーバ３へと送信し、処理を終了する。なお、リクエストメッセージは予め格納していたものを用いずに、その都度入力を受け付けてもよい。

ここで、サーバ３の出力処理部３１３が、プライベートリクエスト送信要求を受け付けた際に実行する処理について説明する。サーバ３はプライベートリクエスト送信要求を受け付けると、リクエスト元の利用者ＩＤを読み出して、利用者情報３２１１の当該利用者ＩＤのレコードに格納されるニックネームと、公開設定の属性情報を読み出す。そして、要求元から送信された利用者ＩＤと端末情報、そしてリクエストメッセージに、ニックネームと公開設定の属性情報を追加して、リクエスト先となる端末装置へプライベートリクエスト情報として送信する。

＜待機処理＞
次に、受電処理部２１２および給電処理部２１３が実行する待機処理について説明する。図１５は、各部の待機処理の一例を示すフロー図である。各部の待機処理は、「オファー」と「リクエスト」を読み替える点のみで異なっているため、ここでは給電処理部２１３が実行する待機処理について説明し、受電処理部２１２の実行する待機処理についてはその詳細な説明を省略する。

待機処理は、端末装置２が稼働を開始すると、或いは待機処理の開始の指示を受け付けると、また或いは所定の条件を満足すると、また或いは、稼働中に定期的に開始される。

給電処理部２１３は、サーバ３からプライベートリクエストを受信したか否かを監視する（ステップＳ４１）。プライベートリクエスト情報を受信した場合には、ステップＳ４２へと処理を進める。

プライベートリクエスト情報を受信すると（ステップＳ４２でＹＥＳ）、給電処理部２１３は、プライベートリクエストレポート画面を構成して、出力部１５０を介して表示装置９６に表示させる（ステップＳ４２）。具体的に、給電処理部２１３は、プライベートリクエスト情報から必要な情報を読み出し、図１６に記載するような、各リクエストのプライベートリクエストレポート画面９０２を構成する。なお、プライベートリクエスト情報には例えば、各リクエスト元の利用者ＩＤ、ニックネーム、端末情報、属性情報（公開設定のもの）、リクエストメッセージに関する情報が含まれているものとする。

プライベートリクエストレポート画面９０２は例えば、プライベートリクエスト情報に含まれる各リクエスト元の利用者のニックネーム、端末情報、オファーメッセージ、属性情報、そしてプライベートリクエストに合意するか否かを選択するための選択領域等から構成される。

次に、給電処理部２１３は、利用者からいずれかのプライベートリクエストに合意する選択があったか否かを判断する（ステップＳ４３）。プライベートリクエストに合意する選択があった場合には（ＹＥＳ）、ステップＳ４４へと処理を進める。

プライベートリクエストに合意する選択があった場合（ステップＳ４３でＹＥＳ）、給電処理部２１３は、サーバ３にプライベートリクエストの合意応答を送信する（ステップＳ４４）。具体的に、給電処理部２１３は、リクエスト元の利用者ＩＤと、設定情報２２１０に格納される自端末の利用者ＩＤと、を含む合意応答をサーバ３へと送信する。合意応答を受けたサーバ３は、支援処理を開始する。

次に、給電処理部２１３は、設定情報２２１０のオープンオファー状況格納領域２２１ｆに格納されるステータスをＯＦＦに切り換え、サーバ３にオープンオファーの削除要求を送信して（ステップＳ４５）、処理を終了する。

ここでさらに、サーバ３の候補特定部３１２が実行する特定処理について説明する。図１７は、特定処理の一例を示すフロー図である。

候補特定部３１２は、受電処理部２１２からオープンオファー提示要求を受けた場合にはオファー登録情報３２３０から、給電処理部２１３からオープンリクエスト提示要求を受けた場合にはリクエスト登録情報３２２０から、候補端末を特定する処理を開始する。

まず、候補特定部３１２は、位置から候補端末を絞り込む（ステップＳ５１）。具体的に、当該処理は、所定の範囲内に存在する端末装置２の利用者同士でなければ、合流が困難であることを理由に行われるものである。位置からの絞り込みにはどのような方法を用いても構わないが、例えば、提示要求元の端末装置と、同じ基地局に接続している端末装置２の利用者ＩＤを抽出する方法を用いることができる。また、両端末からＧＰＳ情報を取得して、提示要求元の端末装置２から、所定の距離内にある端末装置２の利用者ＩＤを絞り込むことも可能である。

次に候補特定部３１２は、希望属性でさらに候補端末を絞り込む（ステップＳ５２）。具体的に、候補特定部３１２は、オープンオファー提示要求またはオープンリクエスト提示要求に含まれる利用者ＩＤを抽出して、希望情報３２１２から当該利用者の希望属性を読み出す。そして、当該希望属性と利用者情報３２１１の属性格納領域３２１ｃに格納されている属性を照合し、合致するレコードの利用者ＩＤを読み出す。

なお、希望属性との照合はどのような方法で行ってもよい。例えば、各項目の重み付け対応表を予め保持しておき、点数の高いものから所定の数を抽出してもよい。さらに、属性格納領域３２１ｃで「公開」に設定されている属性に対してのみ照合を行ってもよく、希望属性が設定されている属性が「非公開」であるレコードは、候補端末から排除してもよい。非公開の内容が、検索によって他者に特定される虞があるからである。また、必ずしも全ての属性項目が一致する必要もない。その場合には、一致する項目が多い順から並べてもよい。

また、希望属性に特定の利用者ＩＤを登録しておくことで（友人登録）、当該利用者ＩＤを有する利用者の端末装置以外を、受電／給電の候補端末から排除することもできる。これは、例えば学校内等の、メンバーの入れ替わりが少なく、人が密集する場所において、特に有効である。

なお、必ずしも希望属性で候補端末を絞り込む必要はなく、位置から絞り込まれた利用者ＩＤを、全て候補端末としてもよい。また例えば、位置から絞り込まれた利用者ＩＤが所定の数以上の場合にのみ、希望属性から候補端末を絞り込んでも良い。また、給電候補端末は例えば、バッテリ残量の多い端末装置から優先的に選択されるような構成としてもよい。

候補特定部３１２は、こうして絞り込んだ利用者ＩＤの送信要求を出力処理部３１３へと出力し、処理を終了する（ステップＳ５３）。出力処理部３１３は、利用者情報３２１１から、候補特定部３１２が特定した利用者ＩＤのレコードに格納される、利用者のニックネームや属性等の情報を抽出し、これらをオープンオファー情報、或いは、オープンリクエスト情報として、端末装置２へと送信する。

以上、第二の実施形態に係る充電支援システム２００について説明した。このような充電支援システム２００によれば、近距離の端末装置２と直接に通信を行わなくとも、候補端末を見つけることが可能である。また、受電依頼や給電申出を公開しておくことで、気軽に候補端末を探すことができる。さらには、サーバ３によりある程度絞り込まれた候補端末からさらに端末を選択可能であるため、より希望に近い相手と授受を行うことができる。

＜＜第三の実施形態＞＞
次に、本発明に係る第三の実施形態を適用した充電支援システム３００について、図１８を参照して説明する。図１８は、本発明の第三の実施形態に係る充電支援システム３００の構成例を示す図である。なお、上述の実施形態と略同様の構成を有するものには同様の符号を付し、詳細な説明は省略する。

本実施の形態に係る充電支援システム３００は、記憶部４２０の個人情報記憶部４２１が、履歴情報４２１０をさらに記憶している点で、第二の実施形態とは異なる。

図１９に、履歴情報４２１０の一例を示す。履歴情報４２１０は、利用者ＩＤが格納される利用者ＩＤ格納領域４２１ａと、利用者のこれまでの受電／給電に関する履歴が格納される履歴格納領域４２１ｂと、信用度が格納される信用度格納領域４２１ｃと、が含まれている。

受電／給電に関する履歴は、例えば、どの利用者から受電を受けたか、およびどの利用者に対して給電を行ったかを蓄積するものである。このような履歴は、合意があった相手との受電／給電完了後に評価報告画面を提示するなどして、利用者からの報告を蓄積することで実現可能である。なお、端末装置２が自動的に受電／給電相手を認識して、その情報をサーバ４に送信する構成としてもよい。

信用度とは、受電／給電相手として、その利用者がどの程度信用のおける人物かを表す値である。例えば、受電／給電完了後の利用者からの評価報告により、低い評価であれば所定の値だけ下降させ、逆に良い評価であれば所定の値だけ上昇させる。

このような信用度は、次のように利用される。例えば、候補特定部３１２が特定処理を行う際に、信用度の低い利用者の利用者ＩＤについては、候補から排除することができる。また、各オファーやリクエストの表示画面に信用度を表示することで、利用者は、候補者が信用できる人物か否かを知ることができる。なお、信用度の順（お勧めの順）にオファーやリクエストを表示してもよい。

またさらに、会員制のＳＮＳページ等のソーシャルネットワーク型のサービスと連携し、各会員のページに、履歴や信用度を表示してもよい。なお、これらの統計を取ってランキング等で表示することもできる。例えば、信用度のランキングや、自分の電力授受の履歴等を、簡便に知ることができる。また、各オファーやリクエストの表示画面に各利用者のＳＮＳページへのリンクを設けることで、候補者のより詳細な情報を知ることも可能である。

また、受電／給電の履歴にポイントを対応させてサーバ上でポイントを管理し、電力の授受があった場合に、受電側から給電側にポイントが支払われるような構成としてもよい。このようなポイントは予め利用者に購入させてもよく、携帯電話キャリアやプロバイダ等が通信料金に加算、或いは減算して請求してもよい。

以上、第三の実施形態に係る充電支援システム３００について説明した。このような充電支援システム３００によれば、利用者はより安全に、受電／給電を行うことができる。

＜＜第四の実施形態＞＞
以下に、本発明に係る第四の実施形態を適用した充電支援システム４００について、図面を参照して説明する。なお、上述の実施形態と略同様の構成を有するものには同様の符号を付し、詳細な説明は省略する。

本実施の形態に係る充電支援システム４００では、例えば災害等の緊急時に動けず救助を求めることができない場合、連絡を取ったりする際に電力量が不足している場合に、端末装置６によるリクエストが救助申請を兼ねる構成となっている。

図２０は、本発明の第四の実施形態に係る充電支援システム４００の構成例を示す図である。本発明における充電支援システム４００には、端末装置６と、緊急時に情報を受け付けるサーバ５と、が含まれる。

サーバ５には、制御部５１０と、記憶部５２０と、通信部５３０と、が含まれる。

制御部５１０には、情報管理部５１１と、要請生成部５１２と、出力処理部５１３と、が含まれる。

情報管理部５１１は、端末装置６から送信される緊急リクエスト登録要求を受け付けて、当該緊急リクエストをリクエスト記憶部５２１にリクエスト登録情報５２１０（図２１参照）として格納する。なお、情報管理部５１１は、図示しない入力部や、端末装置６等から緊急リクエストの取消要求を受け付けた場合には、リクエスト登録情報５２１０から、該当するリクエストを削除する。

要請生成部５１２は、緊急リクエストから救助要請を生成する。救助要請は、音声、画像等どのような形態の情報でもよく、例えば音声による無線通信が挙げられる。また、要請生成部５１２は、緊急リクエストの一覧表画面を生成して、図示しない表示装置に表示させてもよい。なお、一覧表画面には、後述の緊急リクエストに含まれる位置情報や救難者の情報、関連施設に関する情報についても表示されてもよい。

出力処理部５１３は、要請生成部５１２が作成した救助要請を、所定の装置へと発信する。所定の装置とは例えば、救命センターや消防署、病院、緊急車両の関連施設、または、関連施設の職員等の関係者の有する有線或いは無線で情報を出入力可能な装置（以下、関連装置とも称する）である。

記憶部５２０には、関連情報記憶部５２１と、リクエスト記憶部５２２と、が含まれる。

関連情報記憶部５２１には、ＧＰＳによる位置情報と関連付けられた地図情報と、関連装置に関する情報と、が含まれる。関連装置に関する情報とは、例えば、各関連施設や関係者の連絡先、管轄区域、出動状況や空き状況等の状況に関する情報等が挙げられる。

リクエスト記憶部５２２には、端末装置６からの緊急リクエストに基づくリクエスト登録情報５２２０が記憶されている。図２１は、リクエスト登録情報５２２０の一例である。リクエスト登録情報５２２０には例えば、緊急リクエストを識別するための識別子が格納されるＩＤ格納領域５２２ａ、端末装置６に予め登録される個人情報が格納される個人情報格納領域５２２ｂ、端末装置６の位置情報が格納される位置情報格納領域５２２ｃ、緊急リクエストのステータスが格納されるステータス格納領域５２２ｄ、が含まれる。

通信部５３０は、有線、或いは無線で情報の送受信を可能とする。

次に、端末装置６について説明する。図２２は、本発明の第四の実施形態に係る端末装置６の構成例を示す図である。端末装置６には、制御部６１０と、記憶部６２０と、通信部６３０と、伝送部１４０と、出力部１５０と、が含まれる。

制御部６１０は、情報管理部６１１と、申請処理部６１２と、が含まれる。

情報管理部６１１は、利用者に関する情報を受け付けて、これを登録する。具体的に情報管理部６１１は、例えば、氏名や住所、性別、年齢、連絡先等、緊急時に要する個人情報を予め受け付けて、記憶部６２０に後述する設定情報６２１０として登録する。

申請処理部６１２は、後述のリクエスト条件を満たした場合に、緊急リクエストを発信する。緊急リクエストには、例えば、上述の個人情報と、通信部６３０を介して受信したＧＰＳ信号から得られた位置情報と、が含まれる。

記憶部６２０には、設定情報記憶部６２１が含まれる。

設定情報記憶部６２１には、設定情報６２１０が記憶される。図２３に、設定情報６２１０の一例を示す。設定情報６２１０は、個人情報格納領域６２１ａと、リクエスト条件格納領域６２１ｂと、位置情報６２１ｃと、を含んでいる。リクエスト条件とは、緊急リクエストを発信するタイミングを設定するものである。これにはどのようなタイミングを設定してもよいが、例えば、他のアプリケーション等により何らかの災害情報を受け取った場合や、バッテリ残量が所定の値未満となった場合、所定の時間以上連続して充電が無かった場合等が挙げられる。

通信部６３０は、有線、或いは無線で情報の送受信を可能とする。また、ＧＰＳ信号を受信して、位置情報を得る。

次に、端末装置６が実行する救助申請処理、について説明する。図２４は、端末装置６の実行する救助申請処理のフロー図である。

救助申請処理は、端末装置６が稼働を開始すると、或いは救助申請処理の開始の指示を受け付けると、また或いは所定の条件を満足すると、また或いは稼働中に定期的に開始される。

まず、端末装置６の申請処理部６１２は、現在の状態がリクエスト条件を満たしているか否かを判断する（ステップＳ６１）。具体的に、申請処理部６１２は、設定情報６２１０のリクエスト条件格納領域６２１ｂを読み出し、現在の状態がリクエスト条件を満たしているか否かを判断する。リクエスト条件を満たしていると判断した場合には（ＹＥＳ）、ステップ６２へと進み、満たしていないと判断した場合には（ＮＯ）、本処理を繰り返す。

現在の状態がリクエスト条件を満たしていると判断した場合（ステップＳ６１でＹＥＳ）、位置情報を取得する。具体的に、申請処理部６１２は、通信部６３０を介してＧＰＳ信号を受信し、位置情報を取得し、設定情報６２１０の位置情報格納領域６２１ｃに格納する。

ここで、ＧＰＳ信号が受信できない等により位置情報が取得できない場合には、それまでに得た最新の位置情報を位置情報格納領域６２１ｃに格納しておいてもよい。このような位置情報は、特定のアプリケーションを利用等により得ることができる。また、申請処理部６１２が定期的に受信するような構成としてもよい。

次に、申請処理部６１２は、救助申請を生成する（ステップＳ６３）。具体的に、申請処理部６１２は、設定情報６２１０の個人情報格納領域６２１ａから個人情報を、位置情報格納領域６２１ｃから位置情報を読み出し、これらを含む情報である救助申請を生成する。

そして、申請処理部６１２は、生成した救助申請を発信する（ステップＳ６４）。具体的に、申請処理部６１２は、サーバ５へと救助申請を送信する。なお、救助申請の発信は必ずしもこの限りではなく、例えばネットワークに接続できない場合、第三者の端末装置へ直接救助申請を送信してもよい。第三者の端末装置の申請処理部６１２は、救助申請を受信すると、サーバ５へと救助申請を代理して送信する。なお、他の端末装置でもネットワークに接続できない場合には、さらに他の端末装置へ救助申請を送信することもできる。またさらに、微弱無線局として微弱電波を発生することにより、救助申請を発信してもよい。

最後に申請処理部６１２は、省エネモードに切り替えを行い（ステップＳ６５）、処理を終了する。なお、省エネモードとは、所定の機能を制限することで消費電力を節減する一般的な機能であり、公知のどのような技術を用いてもよい。

次に、サーバ５が実行する救助要請処理について説明する。図２５は、サーバ５の実行する救助要請処理のフロー図である。

まず、サーバ５の情報管理部５１１は、救助申請を受信したか否かを判断する（ステップＳ７１）。救助申請を受信したと判断した場合には（ＹＥＳ）、情報管理部５１１はリクエスト登録情報５２２０に新たなレコードを作成し、重複しないユニークなＩＤをＩＤ格納領域５２２ａに、救助申請に含まれる個人情報と位置情報を個人情報格納領域５２２ｂと位置情報格納領域５２２ｃに、「未処理」のステータスをステータス格納領域５２２ｄに格納し、ステップＳ７２へと進む。救助申請を受信したと判断しなかった場合には（ＮＯ）、本処理を繰り返す。

救助申請を受信したと判断した場合には（ステップＳ７１でＹＥＳ）、要請生成部５１２は、救助要請の発信先を決定する（ステップＳ７２）。具体的に、要請生成部５１２は、リクエスト登録情報５２２０のステータスが「未処理」であるレコードを抽出し、救助要請先を決定する。救助要請先の決定は、例えば、関連情報記憶部５２１に記憶される、位置情報と関連装置の管轄区域を関連付けた情報から決定することができる。なお、これに限らず、救助申請の一覧表画面を作成し、利用者に処理を行う救助申請と、その救助要請の発信先を選択させてもよい。

次に、出力処理部５１３は、救助要請を発信する（ステップＳ７３）。具体的に、出力処理部５１３は、ステップＳ７２で決定された発信先に救助要請を発信する。なお、救助要請には、リクエスト登録情報５２２０に格納される、救助要請を識別するためのＩＤと、個人情報と、位置情報と、が含まれる。また、発信先の関連装置の受信状態に合わせて、どのような発信方法を用いてもよい。

そして、出力処理部５１２は、ステータスを更新する（ステップＳ７４）。具体的に、出力処理部５１３は、ステップＳ７３で発信された救助要請に関するリクエスト登録情報５２２０のレコードのステータスを「要請済」に変更し、処理を終了する。

なお、出力処理部５１２は、リクエストが終了（充電、救助の終了や、間違いの発覚等）した旨の情報を随時受け付けると、ステータスを「終了」に変更する。

以上、第四の実施形態に係る充電支援システム４００について説明した。このような充電支援システム４００によれば、利用者は緊急時に自動的に救助を求めることが可能となる。

＜＜第五の実施形態＞＞
以下に、本発明に係る第五の実施形態を適用した充電支援システム５００について、図面を参照して説明する。なお、上述の実施形態と略同様の構成を有するものには同様の符号を付し、詳細な説明は省略する。

本実施の形態に係る充電支援システム５００では、日常的に利用する装置が給電機能を有する給電装置として動作し、受電側の端末装置８へ頻繁に、短時間の給電が自動的に行われるものである。

図２６は、本発明の第五の実施形態に係る充電支援システム５００の構成例を示す図である。本発明における充電支援システム５００には、受電側の端末装置８と、受給電に関する情報を管理するサーバ７と、給電装置９と、が含まれる。

図２７に、端末装置８の機能構成例を説明するためのブロック図を示す。端末装置８には、制御部８１０と、記憶部８２０と、通信部１３０と、伝送部１４０と、出力部１５０と、が含まれる。

制御部８２０には、情報管理部８１１と、受電処理部８１２と、が含まれる。

情報管理部８１１は、利用者からの設定を受け付けて、これを登録する。具体的に、情報管理部８１１は、例えば給電装置９による自動的な給電機能のＯＮ／ＯＦＦや、給電条件等の設定を予め受け付けて、記憶部８２０に後述する設定情報８２１０（図２８参照）として登録する。そして、情報管理部８１１は、端末装置８の状態を適宜監視し、給電条件に基づいて給電機能のＯＮ／ＯＦＦを切り替える。

受電処理部８１２は、給電機能がＯＮの際に給電装置９と通信可能な状態となると、給電装置９へ利用者ＩＤを含む給電リクエストを出力し、給電装置９から伝送部１４０を介した給電を受ける。なお、通信可能な状態とは、ここでは例えば、給電装置９から所定の距離内に端末装置８が存在する場合である。

記憶部８２０には、設定情報記憶部８２１が含まれる。

設定情報記憶部８２１には、設定情報８２１０が記憶される。図２８に、設定情報８２１０の一例を示す。設定情報８２１０は、給電機能のＯＮ／ＯＦＦが格納される給電機能格納領域８２１ａと、給電機能がＯＮとなる条件が格納される給電条件格納領域８２１ｂと、を含んでいる。給電機能がＯＮとなる条件とは、例えば、端末装置８の電力残量等が所定の値以下になった場合等が挙げられる。

次に、給電装置９について説明する。図２９は、給電装置９の機能構成例を説明するためのブロック図である。給電装置９は受電側の端末装置８に給電を行える装置であればどのようなものでもよいが、利用者が端末装置８を利用して、情報の送受信を行う装置であることが望ましい。具体的には例えば、料金の支払い時等に利用される、駅やバス等に備えられる改札機、自動販売機や、店舗のレジスター等である。なお、情報の送受信の手段はどのようなものであってもよいが、例えば端末装置８側が予めリーダライタ機能を有するＩＣチップ等を含み、アプリケーションによってこれらの動作を統括する等、公知の技術を用いることが可能である。このような構成の場合、端末装置８の備えるＩＣは、給電装置９の発する電磁波を受けることで自らアクティブとなり、情報を発信することが可能となる。

給電装置９には、制御部９１０と、記憶部９２０と、通信部１３０と、伝送部１４０と、が含まれる。

制御部９１０には、給電処理部９１１と、履歴管理部９１２と、が含まれる。

給電処理部９１１は、端末装置８への給電処理を行う。具体的に、給電処理部９１１は、端末装置８からの給電リクエストを受け付けると、伝送部１４０を介して端末装置８への給電を実行する。なお、伝送部１４０の用いる給電の手法としては上記に挙げたどのようなものであってもよいが、ここではその性質上、非接触、かつ、端末装置８の利用者が待ち時間を生じないような短時間で充電可能な方法が望ましい。例えば、電磁誘導、振動、光、音、熱等の媒体を介し、非接触で送電可能な方法である。なお、給電量については特に制限されるものではなく、端末装置８に短時間な充電が可能であれば足りる。

履歴管理部９１２は、端末装置８への給電履歴を登録する。具体的に、履歴管理部９１２は、給電処理部９１１が端末装置８への給電を実行すると、当該給電の履歴を給電履歴９２１０（図３０参照）として登録する。給電履歴には、例えば、端末装置８の給電リクエストに含まれる利用者ＩＤや、給電の時刻、給電に使用した電力量、自装置を識別するための装置ＩＤが含まれる。また、履歴管理部９１２は、登録された給電履歴をサーバ７へと随時送信する。

記憶部９２０には、給電履歴記憶部９２１が含まれる。

給電履歴記憶部９２１には、給電履歴９２１０が記憶される。図３０に、給電履歴９２１０の一例を示す。給電履歴９２１０は、給電対象の端末装置８の利用者を識別するための利用者ＩＤ格納領域９２１ａと、給電を行った時刻が格納される給電時刻格納領域９２１ｂと、給電に使用した電力量が格納される使用電力量格納領域９２１ｃと、給電を行った給電装置９を識別するための装置ＩＤ格納領域９２１ｄと、を含んでいる。

次に、サーバ７について説明する。図２６に戻って、サーバ７には、制御部７１０と、記憶部７２０と、通信部３３０と、が含まれる。

制御部７１０には、情報管理部７１１と、請求処理部７１２とが含まれる。

情報管理部７１１は、予め登録された端末装置８の利用者の個人情報（図３１参照）を管理する。個人情報とは、例えば、端末装置８の利用者ＩＤと、当該端末装置８が給電装置９から給電を受けた際に発生する料金の請求先と、を関連付けた情報である。また、情報管理部７１１は、給電装置９から給電履歴９２１０の送信を随時受け付けて、給電履歴記憶部７２２へと格納する。

請求処理部７１２は、給電履歴記憶部７２２に格納される給電履歴９２１０の各レコードについて、利用者ＩＤを参照し、個人情報７２１０から当該利用者ＩＤの請求先を読み出す。そして、給電履歴９２１０の各レコードを、読み出した該当請求先へとそれぞれ送信する。なお、請求先とは、例えばクレジットカード会社、携帯電話キャリア、電子マネーの管理会社等、給電に伴う電力やサービス等の料金支払先である。

記憶部７２０には、個人情報記憶部７２１と、給電履歴記憶部７２２と、が含まれる。

個人情報記憶部７２１には、個人情報７２１０が記憶される。図３１に、個人情報７２１０の一例を示す。個人情報７２１０には、端末装置８の利用者ＩＤ格納領域７２１ａと、当該ＩＤで識別される端末装置８における、給電時の請求先のアドレスが格納される請求先格納領域７２１ｂと、が含まれる。

給電履歴記憶部７２２には、給電装置９から送信された給電履歴９２１０が記憶される。

次に、端末装置８が実行する受電処理、及び給電装置９が実行する給電処理について説明する。図３２は、端末装置８及び給電処理９の実行する処理のフロー図である。

受電処理は、給電装置９との通信が可能になった場合に開始される。

まず、端末装置８の受電処理部８１２は、給電機能がＯＮであるか否かを判断する（ステップＳ８１）。具体的に、受電処理部８１２は、設定情報８２１０から、給電機能格納領域８２１ａに格納されているステータスを読み出す。給電機能がＯＮであれば（ＹＥＳ）、ステップＳ８２へと進み、給電機能がＯＦＦであれば（ＮＯ）、処理を終了する。

給電機能がＯＮであった場合（ステップＳ８１でＹＥＳ）、受電処理部８１２は、給電リクエストを送信する（ステップＳ８２）。具体的に、受電処理部８１２は、給電装置９へ利用者ＩＤを含む給電リクエストを送信する。

そして、受電処理部８１２は、伝送部１４０を介して給電装置９から給電される電力を受電し（ステップＳ８３）、処理を終了する。

次に、給電装置９の実行する給電処理の説明に移る。給電装置９は、給電リクエストを受信すると、当該処理を開始する。なお、給電装置９は、同時に料金支払等の他の処理についても、同時に実行していてもよい。

まず、給電装置９の給電処理部９１１は、端末装置８から給電リクエストを受信する（ステップＳ９１）。

次に、給電処理部９１１は、伝送部１４０を介して給電を開始する（ステップＳ９２）。

そして、給電処理部９１１は、端末装置８が離れたか否かを判断する（ステップＳ９３）。具体的に、給電処理部９１１は例えば、端末装置８に応答要求を定期的に送信し、応答がなければ端末装置８が離脱したと判断する。端末装置８が離れたと判断した場合には（ＹＥＳ）、ステップＳ９４へと進み、端末装置が離れたと判断しなかった場合には（ＮＯ）、本処理を繰り返す。

端末装置８が離れたと判断した場合には（ステップＳ９３でＹＥＳ）、給電処理部９１１は、給電を終了する（ステップＳ９４）。

次に、履歴管理部９１２は、給電履歴を生成する（ステップＳ９５）。具体的に、履歴管理部９１２は、ステップ９１で受信した給電リクエストに含まれていた利用者ＩＤを、利用者ＩＤ、給電時刻、給電に使用した電力量、自装置ＩＤを、給電履歴９２１０にそれぞれ格納して、処理を終了する。

以上、端末装置８及び給電装置９の実行する処理について説明した。給電装置９は、適宜給電履歴９２１０をサーバ７へと送信し、サーバ７は、給電履歴９２１０の各レコードを、予め登録された請求先へと送信する。

なお、料金は必ずしも金銭（電子マネー含む）で支払われる必要はない。例えば、サーバ７や請求先が広告を端末装置８へと送信し、利用者にこれを視聴させることで支払に変えてもよい。

また、利用者は、設定情報８２１０に、予めどの給電装置９で給電を行うかについて設定可能な構成としてもよい。例えば、所定の駅の改札や、所定の場所の自動販売機等、詳細な設定を行うことで、希望する場所のみでの給電を行うことが可能である。

さらに、本実施の形態では給電に関する料金は、携帯電話のキャリア等から後ほど請求される形式となっているが、必ずしもこの限りではなく、端末装置８で管理される電子マネーにより、その場で支払が行われる構成としてもよい。その場合、端末装置８に予めチャージされる電子マネーの残高から給電に関する料金が差し引かれ、その場で清算される。

以上、第五の実施形態に係る充電支援システム５００について説明した。このような充電支援システム５００によれば、利用者は、特に意図することなく、日常的に頻繁な充電を行うことができる。またその料金は自動的に清算されるため、煩雑な支払の手間を生じることがない。

なお、上記の実施形態は、本発明の要旨を例示することを意図し、本発明を限定するものではない。本発明の技術的思想の範囲内で様々な変形が可能である。

例えば、各実施形態の構成は、他の実施形態に適用することができる。具体的に、第二の実施形態においても、第一の実施形態と同様に、受電依頼や給電申出の公開を行わず、サーバ３が自動的に選択した端末装置２に対して、リクエストを送信する構成としてもよい。

また、上記実施の形態においては、プライベートリクエストやプライベートオファーはオープンリクエストやオープンオファーでの公開情報に基づいて送信されるものであるが、これに限らず、利用者がリクエスト／オファーを望む相手を利用者ＩＤやニックネーム等で指定して、送信するような構成としてもよい。

さらに、第一の実施形態において、給電側の端末装置のみがダイレクトオファーを出力するような構成としてもよい。これは即ち、図５のフロー図のリクエストをオファーと読み替えるような処理を実行することで実現可能である。

なお、端末装置は必ずしも受電側、および給電側の両方として機能する必要はない。例えば、受電側としてのみ機能する場合、二次電池を備えている必要はなく、また、外部電源に接続されて動作する装置であってもよい。

逆に、給電側のみとして機能する場合としては、例えば、店頭等で顧客に給電サービスを提供するような給電用の装置が挙げられる。このような給電用の装置は、オープンリクエスト状況が常時ＯＦＦ、オープンオファー状況が常時ＯＮとすることで実現可能である。なお、このような装置では、利用者は、例えば上述のポイントを使用することにより受電が可能となるような構成としてもよい。また、利用する際に、端末装置側に広告等のデータ等を受け取らせる構成としてもよい。

なお、上記したように、伝送部１４０は電力の伝送に、あらゆる方法を利用することができる。その際、給電側の端末の支援処理部１１４及び３１４は、図３３に示すようなユーザーインターフェイス画面１０００を表示装置９６に表示させてもよい。ユーザーインターフェイス画面１０００には、矢印１００２と、矢印１００２の移動経路を示すレール１００１と、が表示されている。伝送部１４０は、表示装置９６を介して、利用者１００３が矢印１００２に触れたままレール１００１上を矢示方向に動かす（フリック）する動きを感知すると、電力の伝送を開始する。

その際、支援処理部１１４及び３１４は、利用者に給電電力量を予め設定させて矢印１００２の大きさを当該電力量に比例させてもよい。さらに、利用者のフリック動作の速さを認識し、その速さに比例して、電力量を決定してもよい。なお、このような電力量を表すシンボルは矢印形状に限らず、どのような形状のものであってもよい。また、電力の伝送開始のきっかけもこのような手法に限定されず、例えば、端末同士をぶつけて、その衝撃で受給電が開始されるような構成としてもよい。

また、給電側の端末の支援処理部１１４及び３１４は、利用者に給電可能な伝送量を通知してもよい。給電可能な伝送量は、充電までにかかる時間と、予めモニタされた普段の消費電力量とから算出することが可能である。例えば、支援処理部１１４及び３１４は、利用者に充電までにかかる時間（例えば、帰宅するまでにかかる時間）を入力させ、これに時間当たりの通常の消費電力量をかける。これにより、充電までに必要な電力量を予測して、表示装置９６に表示させることが可能である。なお、ＧＰＳによる位置情報を利用し、自宅までの移動時間を自動的に算出しても良い。また、普段の消費電力量を時間帯ごとにモニタリングしておき、その時間帯ごとの消費電力量を用いて計算してもよい。

１・１ａ・１ｂ・２・２ａ・２ｂ・６・８：端末装置、３・４・５・７：サーバ、９：給電装置、１００・２００・３００・４００・５００：充電支援システム、９００：ダイレクトリクエスト表示画面、９０１：オープンオファーレポート画面、９０２：プライベートリクエストレポート画面、１０００：ユーザーインターフェイス画面。

Claims (15)

1. 他の端末装置へ電力供給を依頼するリクエストを生成する受電処理部と、
   他の端末装置へ電力供給を申し出るオファーを生成する給電処理部と、
   の少なくとも何れかと、
   前記リクエストまたはオファーを送信する通信部と、を備える
   ことを特徴とする端末装置。
2. 請求項１に記載の端末装置であって、
   前記通信部は、前記リクエストまたは前記オファーを、前記他の端末装置へ直接送信する
   ことを特徴とする端末装置。
3. 請求項１または２に記載の端末装置であって、
   前記リクエストまたは前記オファーについて、前記他の端末装置との合意があった場合に、当該他の端末装置との合流をガイドする支援処理部を、さらに備える
   ことを特徴とする端末装置。
4. 請求項１に記載の端末装置と、サーバと、を含み、
   前記端末装置の前記通信部は、前記リクエストを前記サーバへと送信し、
   前記サーバは、
   前記リクエストが特定の端末装置へのリクエストであった場合に、当該リクエストに関する情報を前記特定の端末装置へと送信する出力処理部を備える
   ことを特徴とする充電支援システム。
5. 請求項４に記載の充電支援システムであって、
   前記端末装置の前記通信部は、前記オファーを前記サーバへと送信し、
   前記出力処理部は、
   前記オファーが特定の端末装置へのオファーであった場合に、当該オファーに関する情報を前記特定の端末装置へと送信する
   ことを特徴とする充電支援システム。
6. 請求項５に記載の充電支援システムであって、
   前記サーバは、
   記憶部と、
   前記オファーが不特定多数へのオファーであった場合に、当該オファーを前記記憶部に登録する情報管理部と、
   前記端末装置から前記不特定多数へのオファーの提示要求を受け付けると、前記記憶部に登録される前記オファーから、給電候補を特定する候補特定部と、を備え、
   前記出力処理部は、当該給電候補の前記オファーに関する情報を、前記オファーの提示要求送信元の端末装置へと送信する
   ことを特徴とする充電支援システム。
7. 請求項４から６の何れか一項に記載の充電支援システムであって、
   前記情報管理部は、
   前記リクエストが不特定多数へのリクエストであった場合に、当該リクエストを前記記憶部に登録し、
   前記候補特定部は、
   前記端末装置から前記不特定多数へのリクエストの提示要求を受け付けると、前記記憶部に登録される前記リクエストから、受電候補を特定し、
   前記出力処理部は、当該受電候補の前記リクエストに関する情報を、前記提示要求送信元の端末装置へと送信する
   ことを特徴とする充電支援システム。
8. 請求項６または７に記載の充電支援システムであって、
   前記給電候補および受電候補は、前記提示要求送信元の端末装置から、所定の範囲内に存在する端末装置から選択される
   ことを特徴とする充電支援システム。
9. 請求項６から８の何れか一項に記載の充電支援システムであって、
   前記情報管理部は、利用者の属性に関する情報と、当該利用者が他の端末装置の利用者に希望する属性に関する情報と、を前記記憶部に予め登録し、
   前記給電候補および受電候補は、前記提示要求送信元の端末装置の利用者の前記希望に応じた属性の利用者の端末装置から選択される
   ことを特徴とする充電支援システム。
10. 請求項６から９の何れか一項に記載の充電支援システムであって、
    前記受電処理部は、前記特定の端末装置の選択を、前記給電候補から受け付け、
    前記給電処理部は、前記特定の端末装置の選択を、前記受電候補から受け付ける
    ことを特徴とする充電支援システム。
11. 請求項１に記載の端末装置と、サーバと、を含み、
    前記端末装置の前記通信部は、救助申請である前記リクエストを前記サーバへと送信し、
    前記サーバは、
    前記リクエストを受け付けると、所定の関連装置へ救助要請を発信する出力処理部を備える
    ことを特徴とする充電支援システム。
12. 請求項１に記載の端末装置と、当該端末装置に給電を行う給電装置と、を含み、
    前記端末装置は、前記給電装置と通信可能な状態になった場合に、前記給電装置から給電を受ける
    ことを特徴とする充電支援システム。
13. 請求項１から３の何れか一項に記載の端末装置であって、
    他の端末装置への給電を行う際に、給電電力の大きさに比例するシンボルを表示させる
    ことを特徴とする端末装置。
14. 他の端末装置へ電力供給を依頼するリクエストを生成するステップと、
    他の端末装置へ電力供給を申し出るオファーを生成するステップと、
    の少なくとも何れかと、
    前記リクエストまたはオファーを前記他の端末装置へ送信するステップと、を実行する
    ことを特徴とする充電支援方法。
15. コンピュータに、充電を支援させるプログラムであって、
    前記コンピュータを、制御手段として機能させ、
    前記制御手段に、
    他の端末装置へ電力供給を依頼するリクエストを生成するステップと、
    他の端末装置へ電力供給を申し出るオファーを生成するステップと、
    の少なくとも何れかと、
    前記リクエストまたはオファーを前記他の端末装置へ送信するステップと、を実行させる
    ことを特徴とするプログラム。

Images