第1の通信可能範囲を有する第1通信部と、第2の通信可能範囲を有する第2通信部と、ユーザへ報知を行う報知部と、前記第1通信部から、前記第2通信部を介した通信の開始を要求する要求信号を他の通信装置へ送信し、前記第1通信部が前記要求信号に対する応答信号を受信した後、当該応答信号に基づいて前記他の通信装置との間の前記第2通信部を介した通信が可能であると判断した場合に、前記第2通信部から認証要求を前記他の通信装置へ送信する制御部と、を備え、前記要求信号は、ユーザによるハンドオーバ開始操作に応じて送信され、前記報知部は、前記第1通信部により前記要求信号に対する前記応答信号が受信された後、前記第2通信部により認証応答が受信される前に、ユーザへ報知を行う、通信装置。前記報知部は、音声出力装置を介してユーザへ報知を行う、請求項1に記載の通信装置。前記ハンドオーバ開始操作に応じて第1の画面を表示し、前記第1通信部により前記要求信号に対する前記応答信号が受信された後に第2の画面を表示する表示部、をさらに備える、請求項1又は請求項2に記載の通信装置。前記第1通信部は、近接通信方式に従って通信する、請求項1~3のいずれか1項に記載の通信装置。第1の通信可能範囲を有する第1通信部と、第2の通信可能範囲を有する第2通信部と、ユーザへ報知を行う報知部と、他の通信装置から受信される認証要求に基づいて前記他の通信装置との間の前記第2通信部を介した通信を認証し認証応答を出力する認証部と、前記第1通信部が前記第2通信部を介した通信の開始を要求する要求信号を前記他の通信装置から受信した後、前記第1通信部から前記他の通信装置へ前記要求信号に対する応答信号を送信し、前記第2通信部が前記他の通信装置から前記認証要求を受信した後、前記第2通信部から前記他の通信装置へ前記認証応答を送信する制御部と、を備え、前記要求信号は、ユーザによるハンドオーバ開始操作に応じて送信され、前記報知部は、前記第1通信部により前記要求信号が受信された後、前記認証部により出力された前記認証応答が前記第2通信部から送信される前に、ユーザへ報知を行う、通信装置。前記報知部は、音声出力装置を介してユーザへ報知を行う、請求項5に記載の通信装置。前記第1通信部から前記応答信号が送信された後に第1の画面を表示し、ハンドオーバ許可操作に応じて第2の画面を表示する表示部、をさらに備える、請求項5又は請求項6に記載の通信装置。前記第1通信部は、近接通信方式に従って通信する、請求項5~7のいずれか1項に記載の通信装置。しかしながら、これまでに提案されてきたハンドオーバの仕様では、第1の通信手段から第2の通信手段への切替えの状況をユーザに報知する手段が規定されていなかった。例えば、ハンドオーバを行う機器が、表示画面を備えた端末装置などであれば、表示画面にハンドオーバの状況を表示させることが考えられる。しかし、機器によっては表示画面を持たない場合もある。また、将来的にハンドオーバの処理が複雑になり、又は高度なセキュリティを実現したい場合などハンドオーバに掛かる処理時間が長くなったときに、ユーザが画面を注視し続けなければならないとすると、利便性が損なわれる。そこで、ユーザに画面を注視させることなくハンドオーバの進行状況を報知することのできる通信装置が提供されることが望ましい。本開示によれば、第1の通信可能範囲を有する第1通信部と、第2の通信可能範囲を有する第2通信部と、ユーザへ報知を行う報知部と、前記第1通信部から、前記第2通信部を介した通信の開始を要求する要求信号を他の通信装置へ送信し、前記第1通信部が前記要求信号に対する応答信号を受信した後、当該応答信号に基づいて前記他の通信装置との間の前記第2通信部を介した通信が可能であると判断した場合に、前記第2通信部から認証要求を前記他の通信装置へ送信する制御部と、を備え、前記要求信号は、ユーザによるハンドオーバ開始操作に応じて送信され、前記報知部は、前記第1通信部により前記要求信号に対する前記応答信号が受信された後、前記第2通信部により認証応答が受信される前に、ユーザへ報知を行う、通信装置が提供される。また、本開示によれば、第1の通信可能範囲を有する第1通信部と、第2の通信可能範囲を有する第2通信部と、ユーザへ報知を行う報知部と、他の通信装置から受信される認証要求に基づいて前記他の通信装置との間の前記第2通信部を介した通信を認証し認証応答を出力する認証部と、前記第1通信部が前記第2通信部を介した通信の開始を要求する要求信号を前記他の通信装置から受信した後、前記第1通信部から前記他の通信装置へ前記要求信号に対する応答信号を送信し、前記第2通信部が前記他の通信装置から前記認証要求を受信した後、前記第2通信部から前記他の通信装置へ前記認証応答を送信する制御部と、を備え、前記要求信号は、ユーザによるハンドオーバ開始操作に応じて送信され、前記報知部は、前記第1通信部により前記要求信号が受信された後、前記認証部により出力された前記認証応答が前記第2通信部から送信される前に、ユーザへ報知を行う、通信装置が提供される。本開示に係る技術によれば、ユーザに画面を注視させることなくハンドオーバの進行状況を報知することができる。以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。また、以下の1~3の各節に分けて当該発明を実施するための最良の形態を説明する。1通信システムの概要2通信装置の基本的な構成例3ハンドオーバ処理の流れと報知処理の例1通信システムの概要まず、図1を参照しながら、本発明の一実施形態に係る通信システム1の概要について説明する。図1は、本発明の一実施形態に係る通信システム1について概略的に示した模式図である。図1を参照すると、通信システム1は、第1の通信装置100と第2の通信装置200とを含む。図1では、第1の通信装置100として携帯電話端末、第2の通信装置200として映像表示装置を示しているが、第1の通信装置100及び第2の通信装置200はかかる例に限定されない。例えば、第1の通信装置100又は第2の通信装置200は、PCやPDA、音声再生用機器、若しくはデジタルカメラなどの情報処理装置、又はこれら装置に接続される無線通信モジュールなどであってもよい。図1に示したように、これら第1の通信装置100及び第2の通信装置200は、第1通信方式及び第2通信方式の2種類の通信方式により相互に通信することができる。第1通信方式は、典型的には、例えば10cm程度の非常に短い距離間で通信するための近接通信方式として実現される。第1通信方式として、例えば、NFCNearFieldCommunication標準規格に従った非接触通信方式を用いることができる。一方、第2通信方式は、第1通信方式よりも広い範囲で通信可能な通信方式である。第2通信方式は、典型的には、第1通信方式に比べて帯域幅が広く、比較的高速な通信方式として実現される。第2通信方式として、例えば、無線LANやBTなどの通信方式を用いることができる。図1に示した通信システム1においてハンドオーバが行われる場合、第1の通信装置100及び第2の通信装置200の間で、まず第1通信方式により、第2通信方式を介した通信のための設定情報が交換される。設定情報の交換は、例えば、ハンドオーバの開始を要求する要求信号の送信と、当該要求信号に対する応答信号の受信により行われる。その後、設定情報の交換が終了すると、第1の通信装置100及び第2の通信装置200の間で、第2通信方式を用いて認証が行われる。そして、第2通信方式を用いた認証が成功すると、ハンドオーバが最終的に完了し、第1の通信装置100及び第2の通信装置200の間のアプリケーションサービスの提供が開始される。このとき、例えば高度なセキュリティを実現するために処理コストの大きい認証処理を伴う場合や通信環境の状況などに応じて、ハンドオーバの要求から完了までの間に一定の時間を要する場合がある。また、ハンドオーバが失敗し得る要因として、通信エラーやユーザによる接続拒否などが考えられる。そこで、本実施形態に係る第1の通信装置100及び第2の通信装置200は、以下に詳細に述べるように、ハンドオーバの成功や失敗、あるいは試行中などといった様々な進行状況をユーザに報知する仕組みを提供する。2通信装置の基本的な構成例次に、図2~図4を用いて、第1の通信装置100及び第2の通信装置200の基本的な構成の一例を説明する。図2は、本発明の一実施形態に係る第1の通信装置100のハードウェア構成の一例を示す説明図である。図2を参照すると、第1の通信装置100は、第1通信回路50、第2通信回路56、MPUMicroProcessingUnit60、RAMRandomAccessMemory62、ROMReadOnlyMemory64、記録媒体66、入出力インタフェース70、入力装置72、及び報知装置76を備える。また、これら構成要素間は、データの伝送路としてのバス68により相互に接続される。第1通信回路50は、第1の通信装置100が第1通信方式による通信を行うために設けられる装置である。第1通信方式として、例えばNFC方式を用いる場合には、第1通信回路50は、所定のインダクタンス及びキャパシタンスを有する共振回路、共振回路により受信された信号を復調する復調回路、及び搬送波を増幅して共振回路から送信させる送信回路を含む。その代わりに、第1通信回路50は、例えば、IrDAInfraredDataAssociation標準規格に従った赤外線ポートなどであってもよい。第2通信回路56は、第1の通信装置100が第2通信方式による通信を行うために設けられる装置である。第2通信回路56は、例えば、IEEE802.15.1による標準仕様に従ったBTポート、又はIEEE802.11a、b、g、n等による標準仕様に従った無線LANポートなどであってもよい。また、第1の通信装置100に異なる種類の通信方式に従った複数の第2通信回路56を設けてもよい。MPU60は、第1の通信装置100全体を制御する制御部として機能する。RAM62は、例えば、MPU60により実行されるプログラムやデータなどを一次的に記憶する。また、ROM64は、例えば、MPU60が使用するプログラムや演算パラメータなどの制御用データを記憶する。記録媒体66は、例えば、ハードディスクなどの磁気記録媒体や、フラッシュメモリなどの不揮発性メモリなどにより構成され、第1の通信装置100の設定情報や認証情報、アプリケーション情報などのデータ、及び各種プログラム等を記憶する。入出力インタフェース70は、例えば、バス68と入力装置72、表示装置74、及び報知装置76とを接続する。入出力インタフェース70としては、例えば、USBUniversalSerialBus端子や、DVIDigitalVisualInterface端子などを用いることができる。入力装置72は、例えば、ボタン、方向キー、ジョイスティック、キーボード、マウスなどにより構成され、ユーザからの操作を受け付ける。表示装置74は、例えば、CRTCathodeRayTubeや液晶ディスプレイ、有機ELElectro-Luminescenceディスプレイなどにより構成され、ユーザへ向けて情報を表示する。報知装置76は、ユーザの感覚器官に信号を送る任意の装置であってよい。例えば、LEDLightEmittingDiodeを用いれば、点滅パターンや表示色などによりユーザの視覚に対して報知することができる。また、例えば、スピーカやベルなどを用いれば、鳴音パターンや音階、リズムなどによりユーザの聴覚に対して報知することができる。また、偏心モータなどによるバイブレータを用いれば、振動パターンや振動の強さなどによりユーザの触覚に対して報知することができる。ここまで、図2を用いて、一実施形態に係る第1の通信装置100のハードウェア構成について説明した。なお、本実施形態において、第2の通信装置200のハードウェアもまた図2に示したように構成される。次に、図3は、本実施形態における第1の通信装置100の論理的な構成を示すブロック図である。図3を参照すると、第1の通信装置100は、第1通信部110、第2通信部120、表示部130、操作部140、制御部150、記憶部160、アプリケーション部170、及び報知部180を備える。第1通信部110は、図2を用いて説明した第1通信回路50を用いて、第2の通信装置200との間の第1通信方式による通信を仲介する。本実施形態において、第1の通信装置100の第1通信部110は、制御部150からの指示に応じて、後述する第2通信部を介した通信の開始を要求する要求信号リクエストメッセージを第2の通信装置200へ送信する。即ち、本実施形態では、第1の通信装置100がハンドオーバを要求する側の端末となる。その後、要求信号に応じて第2の通信装置200から返送される応答信号セレクトメッセージを受信した後、第2通信部120を介した通信が開始される。第2通信部120は、図2を用いて説明した第2通信回路56を用いて、第2の通信装置200との間の第2通信方式による通信を仲介する。第2通信方式としては、前述したように、例えばBT方式又は無線LAN方式などが用いられる。第2通信部120により第2通信方式を用いた通信が開始される際には、通信相手との間で所定の認証が行われる。表示部130は、図2を用いて説明した表示装置74を用いて、例えば制御部150から出力されるテキスト情報や画像情報をユーザに表示する。操作部140は、図2を用いて説明した入力装置72に対しユーザが例えばハンドオーバの開始や接続承認などの操作を行った際に、各操作に応じた入力信号を生成して制御部150へ出力する。制御部150は、第1通信部110、第2通信部120、表示部130、操作部140、記憶部160、アプリケーション部170、及び報知部180と接続され、各構成要素の機能を制御する。制御部150は、主に図2を用いて説明したMPU60、RAM62、及びROM64により構成される。例えば、制御部150は、操作部140からハンドオーバの開始が指示されたことを示す入力信号を受け取ると、第1通信部110からハンドオーバを要求する要求信号を送信する。そして、制御部150は、送信した要求信号に対する応答信号を例えば第2の通信装置200から受信すると、受信した応答信号に含まれる設定情報等に基づいて、第2の通信装置200との間の第2通信部120を介した通信が可能であるかを判断する。ここで、応答信号に含まれる設定情報としては、例えば、第2通信方式のためのアドレス情報やサポートされる認証方式に関する情報、又は各装置の有するアプリケーションに関する情報などが挙げられる。そこで、制御部150は、設定情報を用いて、例えば第2の通信装置200がサポートする認証方式を自装置が使用できるか、又は例えば第2の通信装置200が自装置と共通するアプリケーションを有しているかなどを確認することができる。また、応答信号に接続可否情報が含まれる場合には、制御部150は、接続が許可されたか否かを当該接続可否情報を用いて判断することができる。そして、制御部150は、第2の通信装置200との間の第2通信部120を介した通信が可能であると判断した場合には、さらに第2通信部120から第2の通信装置200へ認証情報を送信する。ここで、第2通信部120から送信される認証情報には、例えばBTや無線LANの標準規格において採用された公開鍵暗号方式における公開鍵や証明書などが含まれる。それにより、第2の通信装置200は、第1の通信装置100との間の通信の認証を経て、セキュリティの担保された通信を開始することができる。記憶部160は、図2を用いて説明した記録媒体66を用いて、例えば制御部150やアプリケーション部170により実行されるプログラム、又は第1通信部110若しくは第2通信部120を介した通信に必要とされる設定情報などのデータを記憶する。アプリケーション部170は、制御部150と同様、主に図2を用いて説明したMPU60、RAM62、及びROM64により構成される。アプリケーション部170は、第1の通信装置100と第2の通信装置200との間の通信機能を活用した任意のアプリケーションサービスをユーザに提供する。このうち、例えば画像データや音楽データなどのデータ共有サービスやデータのバックアップサービスなど、一定容量を超えるデータ交換を必要とするサービスは、後述するハンドオーバ処理を経て、第2通信部120を介する第2通信方式を用いて行われる。報知部180は、図2を用いて説明した報知装置76により構成される。報知部180は、例えば、制御部150からの指示に基づき、第2の通信装置200との間のハンドオーバの成功や失敗、あるいは試行中などといった進行状況をユーザに報知する。ここで、報知部180は、ハンドオーバ処理の進行状況に応じて、異なる複数の報知パターンを使い分けてもよい。報知パターンとは、例えば、報知装置76がLED等の発光装置の場合には点灯色や光量、点滅の間隔など、スピーカ等の音声出力装置の場合には音階や音量、リズムなど、バイブレータ等の振動装置の場合にはバイブレーションの強さや間隔などにより識別される。なお、制御部150による制御を受けて行われる一連のハンドオーバ処理及び報知処理の流れについては、次節においてさらに詳しく説明する。次に、図4は、本実施形態における第2の通信装置200の論理的な構成を示すブロック図である。図4を参照すると、第2の通信装置200は、第1通信部210、第2通信部220、表示部230、操作部240、制御部250、記憶部260、アプリケーション部270、報知部280、及び認証部290を備える。なお、ここでは、図3を用いて説明した第1の通信装置100に係る第1通信部110、第2通信部120、表示部130、操作部140、記憶部160、アプリケーション部170、及び報知部180と同様の機能の説明は省略する。第2の通信装置200の第1通信部210は、第1の通信装置100との間の前述した第1通信方式による通信を仲介する。本実施形態において、第2の通信装置200の第1通信部210は、第1の通信装置100から送信される、第2通信部を介した通信の開始を要求する要求信号を受信する。そして、第1通信部210は、制御部250からの指示に応じて、第1の通信装置100へ応答信号を送信する。即ち、本実施形態では、第2の通信装置200がハンドオーバの要求に対して応答する側の端末となる。一方、第2の通信装置200の第2通信部220は、第2通信回路50を用いて、第1の通信装置100との間の前述した第2通信方式による通信を仲介する。制御部250は、第1の通信装置100から送信された前述の要求信号が第1通信部210により受信されると、例えば前述した第2通信方式のためのアドレス情報などの設定情報等を記憶部260から取得する。そして、制御部250は、取得した設定情報を含む応答信号を、第1通信部210から第1の通信装置100へ送信させる。その後、制御部250は、第1の通信装置100から送信された第2通信方式による通信の認証のための認証情報が第2通信部220により受信されると、認証部290に当該認証情報を受け渡して認証を要求する。そして、認証部290による認証の結果に応じて、制御部250は、認証結果を第2通信部220から第1の通信装置100へ送信させる。ここで、本実施形態において、認証部290による認証は、例えばEAP-TLSEAP-TransportLayerSecurityやPEAPProtectedEAPなどの標準仕様の他、任意の認証方式に従って行うことができる。なお、本実施形態では、ハンドオーバに際して第1の通信装置100から第2の通信装置200へ認証を要求する例を説明している。しかしながら、その代わりに、第2の通信装置200から第1の通信装置100へ認証を要求してもよい。その場合には、図3に示した第1の通信装置100の論理的な構成に、認証部290と同等の機能が追加的に設けられる。ここまで、図2~図4を用いて、第1の通信装置100及び第2の通信装置200のハードウェア構成及び論理的な構成の一例について説明した。次に、かかる構成により、第1の通信装置100と第2の通信装置200との間で行われるハンドオーバ処理の流れと報知処理の例について説明する。3ハンドオーバ処理の流れと報知処理の例3-1典型的な流れ図5は、第1の通信装置100と第2の通信装置200との間で行われるハンドオーバ処理の流れの一例を示すシーケンス図である。図5の例において、ハンドオーバ処理は、まず第1の通信装置100に対しユーザが所定の操作をすることにより開始されるS302。例えば、第1の通信装置100は、操作部140の所定のボタンが押下されたことにより、ハンドオーバ処理を開始してもよい。次に、第1の通信装置100の制御部150は、第2通信方式による通信の開始、即ちハンドオーバを要求する要求信号を、第1通信部110から第2の通信装置200へ送信させるS304。ここで、第1通信部110による通信可能範囲第1の通信可能範囲は、例えばNFC方式の場合には、10cm程度の近接的な距離の範囲内となる。そこで、例えば第1の通信装置100の表示部130に、第1の通信装置100を第2の通信装置200に近づけるタッチすることをユーザに促す画面を表示させる。それにより、ユーザは第1の通信装置100を第2の通信装置200にタッチさせ、第1通信部110から送信されたハンドオーバの要求信号が第2の通信装置200に到達する。第2の通信装置200に到達したハンドオーバの要求信号は、第2の通信装置200の第1通信部210により受信される。そして、第2の通信装置200の制御部250は、受信した要求信号への応答として、第2通信方式による通信の認証のための設定情報等を含む応答信号を、第1通信部210から第1の通信装置100へ送信させるS306。第1の通信装置100において、第2の通信装置200から送信された応答信号が受信されると、第1の通信装置100の制御部150は、タッチが成功したことを報知部180からユーザへ報知させるH1。それにより、ユーザは、第1の通信装置100を第2の通信装置200から離してもよいことを認識する。かかる報知は、図5に示したような音による報知に限られない。例えば、LEDの点滅やバイブレータの振動などにより報知が行われてもよい。また、接続するアプリケーションの種類などに応じて報知パターンを変更してもよい。なお、S304及びS306のハンドオーバの要求及び応答のシーケンスは、図5に示したように1往復で終了する場合に限定されない。S304及びS306が複数回繰り返される場合には、例えば、最終的に第1通信方式における通信完了コマンドが送受信された時点をタッチが成功した時点と判断することができる。その後、第2の通信装置200では、例えば、ユーザによりハンドオーバを許可する操作が行われるS308。例えば、第2の通信装置200の表示部230にハンドオーバの可否を確認する画面を表示させ、操作部240を介してユーザによる許可又は拒否の操作を受け付けてもよい。なお、ハンドオーバを自動的に認める設定が事前になされている場合には、S308を省略し、ユーザにハンドオーバの可否を確認することなく自動的に後続の処理を進めてもよい。一方、S306の後、第1の通信装置100の制御部150は、第2通信方式による通信の認証のための認証情報を、第2通信部120から送信させる。典型的には、認証情報は、S306の後、第2の通信装置200から認証結果が返信されるか一定の時間が経過してタイムアウトするまで、反復的に第2通信部120から送信されるS310。その間、例えば第1の通信装置100の表示部130には、現在第2通信方式での認証を試行していることを示す接続中の画面が表示される。その後、ユーザによりハンドオーバが許可された第2の通信装置200において、第2通信部220が認証情報を受信すると、制御部250は、受信した認証情報を用いて認証部290に認証を求めるS312。そして、制御部250は、認証部290による認証結果を、第2通信部220から第1の通信装置100へ送信するS314。第1の通信装置100において、第2の通信装置200から認証要求に対する応答としての認証結果が受信されると、第1の通信装置100の制御部150は、認証が行われたことを報知部180からユーザへ報知させるH2。それにより、ユーザは、ハンドオーバが成功し、又は失敗したことを認識することができる。その後、第1の通信装置100と第2の通信装置200の間では、例えば、アプリケーションに特化しない基本情報が第2通信方式を用いて交換されるS316。ここで、基本情報には、例えば各装置を使用するユーザのプロフィール情報などが含まれる。また、基本情報の交換の後、さらにアプリケーションに特化した詳細情報が第2通信部120及び220の間で交換されるS318。ここで、交換されたアプリケーションの詳細情報に基づいて、第1通信装置100の制御部150又は第2通信装置200の制御部250は、アプリケーションを開始することが可能か否かをさらに判断してもよい。そして、アプリケーションの詳細情報の交換の後、セキュリティの担保された通信環境の下、第2通信方式を用いたアプリケーションサービスの提供が開始されるS320。3-2変形例図5では、ハンドオーバ処理の流れと典型的な報知処理について説明した。しかしながら、本実施形態において、図5とは異なる内容又は異なるタイミングによる様々な報知処理を実現することができる。以下、図6~図15を用いて、報知処理の変形例について説明する。図6では、第1の通信装置100の第1通信部110からのハンドオーバの要求信号の送信が開始されS304、第2の通信装置200から応答信号が返信されるS306までの間、継続的に報知が行われているH3。このような一定の期間継続する報知は、例えば、鳴音の繰返しやLEDの点灯又は点滅の繰返しなどにより行うことができる。それにより、ユーザは、報知がされている間タッチを継続させる必要があることを認識する。図7では、第2の通信装置200から応答信号が返信された際、応答信号に基づいて第2の通信装置200との間の通信を開始できないと制御部150が判断した場合にS307、ハンドオーバの失敗を表す報知が行われているH4。例えば、第1の通信装置100と第2の通信装置200の機能が適合しない場合や、応答信号にハンドオーバの拒否を示す接続可否情報が含まれていた場合に、ハンドオーバは失敗したと判断され得る。機能が適合しない例としては、対応するアプリケーションが無いこと、バージョンの齟齬、必要となるデバイスや制御プロファイルの欠落などが挙げられる。こうしたハンドオーバの失敗の原因を、報知パターンを分けてユーザに知らせてもよい。それにより、ユーザは、例えば表示部130を注視し続けることなく、ハンドオーバの成功又は失敗、及び失敗の場合にはその原因などを認識することができる。図8では、第1通信部110からのハンドオーバの要求信号の送信が開始された後S304、所定の期間が経過しても第2の通信装置200から応答が無かった場合に、要求がタイムアウトにより失敗したことを表す報知が行われているH5。かかる場合には、図7におけるハンドオーバの失敗を表す報知H4とは異なる報知パターンにより、ハンドオーバの失敗の種類を識別できる形で報知してもよい。また、上で述べたように、S304とS306が複数回繰り返される場合において、例えば所定の期間が経過しても通信完了コマンドが確認されない際に、H5と同様のタイムアウトを示す報知を行ってもよい。図9では、ハンドオーバの要求S304及び応答S306の後、第2の通信装置200において、ユーザによりハンドオーバを許可又は拒否する操作が行われた際にS308、ハンドオーバが許可又は拒否されたことを表す報知が行われているH6。かかる報知は、例えば、第2通信装置200の制御部250から報知部280に指示を与えることにより行われる。また、ハンドオーバの許可の場合と拒否の場合とで、報知パターンを変えて報知を行ってもよい。図10では、第2の通信装置200から第2通信方式による通信の認証結果が返信された際、認証が失敗したことを制御部150が判断した場合にS315、認証の失敗を表す報知が行われているH7。図11では、第2通信部120からの認証要求が送信された後S310、所定の期間が経過しても第2の通信装置200から認証結果が返信されなかった場合に、認証がタイムアウトにより失敗したことを表す報知が行われているH8。かかる場合には、図10における認証の失敗を表す報知H7とは異なる報知パターンにより、認証の失敗の種類を識別できる形で報知してもよい。それにより、ユーザは認証の成功又は失敗だけではなく、認証の失敗の原因を認識することができる。また、S310ではなく、図5に示したS314、S316、S318などの各ステップの実行後に所定の期間通信相手からの応答が無い場合に、同様のタイムアウトに関する報知をしてもよい。図12では、第1の通信装置100と第2の通信装置200の間で、基本情報が交換されS316、さらにアプリケーションの詳細情報が交換された際、アプリケーションの機能不適合が判明した場合にS319、報知が行われているH9。図13は、図5に示したハンドオーバ処理の進行状況を、状況が変化する都度報知する例を示している。図13の例では、ハンドオーバ開始操作時S302、H11、ハンドオーバ要求時S304、H12、ハンドオーバ応答時S306、H13、認証要求時S310、H14、認証応答時S314、H15、基本情報交換時S316、H16、アプリケーション詳細情報交換時S318、H17、アプリケーション開始時S320、H18にそれぞれ報知している。また、図2に示した第2通信回路56の説明に関連して述べたように、第1の通信装置100と第2の通信装置200との間で複数の種類の第2通信方式を用い得る場合もある。そうした場合に、図14に示したように、第1の通信装置100からのハンドオーバの要求信号を受信した第2の通信装置200において、ハンドオーバさせる第2通信方式を複数の候補からユーザに選択させることが考えられる。図14では、一例として通信方式A及び通信方式Bの2つの選択肢が画面上に示されている。例えば、図14において、通信方式AはBT方式、通信方式BはWi-Fi方式などであってよい。図14の例において、第2の通信装置200から返信される応答信号には、ユーザにより選択された通信方式を指定する情報が含まれるS306。このような応答信号を受信した第1の通信装置100は、例えば、BT方式が指定された場合にはH21、Wi-Fi方式が指定された場合にはH22といったように、指定された通信方式に応じて異なる報知をしてもよい。なお、図14ではユーザに第2通信方式を選択させる例を示したが、その代わりに、事前に設定された優先度などに応じて、第1の通信装置100又は第2の通信装置200により第2通信方式を自動的に選択してもよい。また、第1通信方式として用いられるNFCなどの近接通信においては、リーダ/ライタの役割を果たす装置が搬送波を出力して、通信相手を捕捉する。本実施形態では、第2の通信装置200がリーダ/ライタの役割を果たす。そして、搬送波の出力は、ユーザからの操作をきっかけとして開始される場合と、常時出力している場合がある。そこで、第2の通信装置200において搬送波が出力されているか否かを報知部280により報知させてもよい。図15では、ユーザにより搬送波の出力開始操作が行われたことをきっかけとして、第2の通信装置200の第1通信部210から搬送波の出力が開始されS303、搬送波が出力されている間報知が行われているH31。それにより、ユーザは、第1の通信装置100をいつ第2の通信装置200にタッチさせればよいかを認識することができる。ここまで、図5~図15を用いて、本発明の一実施形態に係るハンドオーバ処理の流れと報知処理の例について説明した。なお、図9及び図15を除く各図では、第1の通信装置100の報知部180を用いて報知する例を示した。しかしながら、各図に示した報知のタイミングで、第2の通信装置200の報知部280を用いて報知を行ってもよい。また、第1の通信装置100と第2の通信装置200の両方を用いて報知することも可能である。但し、ユーザの混乱を避けるためには、例えばハンドオーバを要求する側の一方の装置のみで報知を行うなど、ハンドオーバ処理に関連する報知を統一感を保ちながら行うのが好適である。本実施形態によれば、ユーザに画面を注視させることなく、ハンドオーバの進行状況を適宜ユーザに認識させることができる。また、表示画面を持たない通信装置においても、ハンドオーバの進行状況を表現することができる。それにより、ハンドオーバを活用したセキュアでシームレスな通信の利便性が向上し、より多様な場面での近接通信や近距離通信の利用が期待される。以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。