(57)【要約】【課題】訪問理由を事前把握可能とすることで、効率的な訪問への応答を可能とする訪問者機器連携装置を提供する。【解決手段】機器接続部2は、訪問してきた呼出元の呼出元端末と無線接続する。呼出元識別部3は、前記呼出元端末より取得される呼出元識別情報に基づき、呼出元を識別する。呼出先振分部4は、呼出元より入力される情報及び／又は前記識別された呼出元に予め紐付けられた呼出先の情報に基づいて、呼出先を選択する。呼出先通知部5は、前記選択された呼出先に対して前記訪問の旨の通知を行う。【選択図】図１
2016082419.tif 000002
【特許請求の範囲】
【請求項１】
訪問してきた呼出元の呼出元端末と無線接続する機器接続部と、
前記呼出元端末より取得される呼出元識別情報に基づき、呼出元を識別する呼出元識別部と、
呼出元より入力される情報及び／又は前記識別された呼出元に予め紐付けられた呼出先の情報に基づいて、呼出先を選択する呼出先振分部と、
前記選択された呼出先に対して前記訪問の旨の通知を行う呼出先通知部と、を備える訪問者機器連携装置。
【請求項２】
前記機器接続部は、BluetoothまたはWi-Fiによる無線接続を行うことを特徴とする請求項１に記載の訪問者機器連携装置。
【請求項３】
前記呼出元識別部は、BluetoothもしくはWi-Fiのインターフェースに固有に割り振られるデバイスアドレスを利用して、または、呼出元の電話番号を利用して、呼出元を識別することを特徴とする請求項１または２に記載の訪問者機器連携装置。
【請求項４】
呼出元より画像を取得し、当該画像を認識する画像認識部をさらに備え、
前記呼出元識別部は、前記画像認識部において画像を認識した結果に基づいて、呼出元を識別することを特徴とする請求項１ないし３のいずれかに記載の訪問者機器連携装置。
【請求項５】
前記呼出元識別部は、前記呼出元を識別すると共に、当該呼出元に応じた呼出音を設定し、
前記呼出先通知部は、前記設定された呼出音を用いて前記通知することを特徴とする請求項１ないし４のいずれかに記載の訪問者機器連携装置。
【請求項６】
前記呼出先振分部は、呼出先の呼出先端末の位置情報にさらに基づいて、呼出先を選択することを特徴とする請求項１ないし５のいずれかに記載の訪問者機器連携装置。
【請求項７】
前記呼出先振分部は、呼出先の呼出先端末のうち前記訪問者機器連携装置と無線接続されている端末に対応する呼出先を、前記選択する対象とすることを特徴とする請求項１ないし６のいずれかに記載の訪問者機器連携装置。
【請求項８】
前記呼出先通知部は、呼出先の呼出先端末との間でIP通信を可能とするネットワークを確立し、当該呼出先にメッセージ通知を行うことを特徴とする請求項１ないし７のいずれかに記載の訪問者機器連携装置。
【請求項９】
前記呼出先通知部は、前記訪問者機器連携装置とは異なるネットワークに属する呼出先の呼出先端末に対して、IP通信を可能とし、当該呼出先にメッセージ通知を行うことを特徴とする請求項１ないし８のいずれかに記載の訪問者機器連携装置。
【請求項１０】
前記呼出先通知部は、前記IP通信において、呼出先へのプッシュ通知のためウェブソケットを利用することを特徴とする請求項８または９に記載の訪問者機器連携装置。
【請求項１１】
前記呼出先通知部は、呼出元の呼出元端末と呼出先の呼出先端末との間で、映像及び音声によるやりとりを可能とさせる、及び／又は、ピアツーピア通信を可能とさせることを特徴とする請求項１ないし１０のいずれかに記載の訪問者機器連携装置。
【請求項１２】
呼出元より所定の呼出先に対する訪問予定時刻を受信して当該所定の呼出先に通知する機能と、
当該通知された所定の呼出先より当該訪問の際の認証情報を受信することで、当該呼出元へと当該認証情報を通知する機能と、をさらに備えることを特徴とする訪問者機器連携装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、訪問者である呼出元を識別して適切な呼び出しを行うことのできる、ネットワークに接続された呼出先に通知を行うための訪問者機器連携装置に関する。
【背景技術】
【０００２】
家などへの訪問者が、ドアホンなどを利用して呼び出しを行う際に、在宅者は、訪問者の属性や訪問対象の在宅者などを把握したいことがある。こうした要求に関連する従来技術の例として、例えば特許文献１，２に開示のものがある。
【０００３】
特許文献1によれば、ドアホン、テレビ電話端末、携帯電話、監視カメラなどをネットワーク接続することにより、ドアホンからの呼び出しに対して、テレビ電話端末や携帯電話端末において、ドアホンカメラや監視カメラの画像を閲覧したり、最も早く応答する意図を通知した端末との間で映像及び音声のやりとりを行うとしている。また、インターネットを介して、遠隔にあるテレビ電話端末や携帯電話端末においても応答できるとしている。
【０００４】
また、特許文献2によれば、ドアホンで呼び出しを行った際に、そのイベントに応じて、テレビなどのイベント受信機器において適切な映像や音声フォーマットにおいて、出力・応答できるとしている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】再表2006/018918号公報
【特許文献２】特許5144663号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記特許文献1では、呼出元がどのような人物で、呼出先の誰に訪問したか（以下、訪問理由）を確認するためには、能動的に、ドアホンカメラの画像や映像を閲覧する、もしくはテレビ電話端末による応答を行う必要があった。
【０００７】
また、上記特許文献2では、テレビなどのドアホン専用端末でない機器においても、適した映像や音声フォーマットで出力・応答できるとしているが、こちらもテレビなどを介した映像や音声により確認する以外は、呼出先の人物が、呼出元の訪問理由を知ることはできなかった。
【０００８】
従って、上記特許文献１，２のような従来技術においては、以下のような要求に対して適切に対応することができない。
【０００９】
まず、呼出元においては、呼出先の人物に、不必要な不信感を持たれず、確実に応答してもらいたいという要求がある。一方で、呼出先においては、呼出元の訪問理由に応じて、応答すべきか否かや誰が応答するのが最も適切かを手間なく判断したいという要求がある。
【００１０】
特に、場合によっては呼出先は、特許文献１，２のような能動的な応答作業を必要とする機器を使うことが前提の環境においては、手間をかけてまで訪問理由を把握したいとは思わないこともあり、従って、応答しないということもありうる。このような場合には上記の要求はいずれも満たされない。
【００１１】
上記の要求を満たすため、呼び出しに応じて、呼出先が端末の閲覧や応答といった能動的な行為を行なわずとも、手間なく訪問理由を把握できるようにすることが望ましい。ここで、呼出元を識別し、呼出元の訪問理由に応じて、呼出音や呼出先を振り分けることも有用であると考えられる。しかしながら、従来技術においてはこうしたことは実現できない。
【００１２】
本発明は、上記従来技術の課題に鑑み、呼出先に能動的な行為を必要とせずに訪問理由を把握可能とすることで、効率的な訪問への応答を可能とする訪問者機器連携装置を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記目的を達成するため、本発明は、訪問者機器連携装置であって、訪問してきた呼出元の呼出元端末と無線接続する機器接続部と、前記呼出元端末より取得される呼出元識別情報に基づき、呼出元を識別する呼出元識別部と、呼出元より入力される情報及び／又は前記識別された呼出元に予め紐付けられた呼出先の情報に基づいて、呼出先を選択する呼出先振分部と、前記選択された呼出先に対して前記訪問の旨の通知を行う呼出先通知部と、を備えることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、呼出元端末より呼出元識別情報を取得して呼出元を識別し、適切な呼出先を自動選択して訪問の旨を通知するので、効率的な訪問への応答が可能となる。
【図面の簡単な説明】
【００１５】
【図１】一実施形態に係る訪問者連携装置の機能ブロック図である。
【図２】呼出元データベースと呼出先データベースとに登録されるそれぞれの情報を示す図である。
【図３】アプリを既に持っている場合にBluetooth（登録商標）で呼出元端末と宅内装置とが接続する場合の手順を模式的に示す図である。
【図４】アプリを既に持っている場合にWi-Fi（登録商標）アクセスポイントで呼出元端末と宅内装置とが接続する場合の手順を模式的に示す図である。
【図５】アプリがなくウェブサーバが外部にある場合に呼出元端末と宅内装置とが接続する場合の手順を模式的に示す図である。
【図６】アプリがなくウェブサーバが宅内端末に搭載されている場合に呼出元端末と宅内装置とが接続する場合の手順を模式的に示す図である。
【図７】呼出元識別部の機能を説明するための図である。
【図８】呼出先振分部の機能を説明するための図である。
【図９】呼出音を設定する所定規則の例を示す図である。
【図１０】呼出先通知部の機能を説明するための図である。
【図１１】宅内デバイスへの通知の方法の例を示す図である。
【図１２】宅外デバイスへの通知の方法の例を示す図である。
【図１３】呼出元と宅内にある呼出先との間で、映像や音声を介した応答環境を提供する方法の例を示す図である。
【図１４】呼出元と宅外にある呼出先との間で、映像や音声を介した応答環境を提供する方法の例を示す図である。
【図１５】情報登録部において、事前に、これから行われる訪問に関する情報を登録した上で、訪問を行うようにする実施形態を説明するための図である。
【発明を実施するための形態】
【００１６】
図１は、一実施形態に係る訪問者連携装置の機能ブロック図である。訪問者機器連携装置1は、機器接続部2、呼出元識別部3、呼出先振分部4、呼出先通知部5、情報登録部6、画像認識部7、呼出元データベース（以下、呼出元DB）30及び呼出先データベース（以下、呼出先DB40）を備える。
【００１７】
訪問者機器連携装置1は、一実施形態においては、呼出元が持つスマートフォンのようなデバイス（呼出元端末20）の情報や呼出元を撮影した画像に基づき、呼出元を識別し、それに応じて呼出音や呼出先を振り分ける。また、呼出元が持つ呼出先の情報に応じて、呼出先を振り分けてもよい。
【００１８】
さらに、振り分けられた呼出先の呼出先端末50には、当該呼出元の訪問理由を含む通知等が実施されることで、呼出先は安心してスムーズに呼出元へと応答することが可能となる。訪問者機器連携装置1はまた、当該応答の際の呼出先端末50と呼出元端末20とを介した呼出先と呼出元との意思疎通手段も提供することができる。
【００１９】
以下、訪問者機器連携装置1の各部の詳細を説明する。ここで、訪問者機器連携装置1が呼出先の自宅に設置されており、当該自宅への訪問者が呼出元となって利用される場合を例として説明する。このため適宜、「訪問者機器連携装置1」を別名で「宅内装置1」と略称する。
【００２０】
情報登録部6は、ユーザ入力等を受けて、呼出元識別部3及び呼出先振分部4が動作するために必要となる各種情報を、それぞれ呼出元DB30や呼出先DB40へと登録するための機能を提供する。図２は、情報登録部6により当該登録される情報の例を示す図であり、[1]に呼出元DB30に登録される情報が、[2]に呼出先DB40に登録される情報が、それぞれ示されている。呼出元DB30及び呼出先DB40は当該登録される情報を保存し、呼出元識別部3及び呼出先振分部4がそれぞれ動作する際に当該情報を提供する。
【００２１】
図２の[1]に示すように、呼出元DB30における登録情報は、呼出元基本情報と呼出元付加情報とを含んで構成される。
【００２２】
ここで、呼出元基本情報とは、呼出元を特定するための情報である。[1]に示すように、登録された呼出元を一意に判別するための呼出元IDと、呼出元IDに紐づく呼出元電話番号と、呼出元が持つデバイス（呼出元端末20）におけるBluetooth（登録商標）インターフェースの固有識別子であるBluetoothデバイスアドレス(以下、BTDアドレス)と、同デバイスにおけるWiFi（登録商標）インターフェースの固有識別子であるMacアドレスと、呼出元に紐づく画像である登録画像と、を含んで呼出元基本情報は構成される。
【００２３】
一方で、呼出元付加情報は[1]に示すように、呼出元IDに応じて設定される呼出音、呼出元IDに応じて呼出先を指定する優先呼出先を含んで構成される。
【００２４】
また、図２の[2]に示すように、呼出先DB40における登録情報は、登録された呼出先を一意に判別するための呼出先IDと、呼出先に紐づく呼出先電話番号と、呼出先の現在位置である位置情報（図中の例では緯度経度）と、を含んで構成される。
【００２５】
以上のようなDB30,40における各登録情報の作成・更新においては、種々の実施形態が可能である。例えば、情報登録部6が提供するGUI（グラフィカルユーザインターフェース）等のUIを介して、ユーザが各登録情報を直接入力してもよい。また、実施形態によっては、例えば、ネットワーク上のサーバから各登録情報を自動取得可能な場合など、情報登録部6を介した直接入力は省略してもよい。
【００２６】
また、呼出元DB30における登録情報に関しては、呼出元端末20が宅内装置1に接続してきた際の情報（接続ログの情報等）を自動取得して、情報登録部6が登録してもよい。また、各呼出先が持つデバイス（呼出先端末50の各々）に保存してある電話帳を取り込んで、電話帳にある電話番号と呼出先を紐付けて、呼出元電話番号及び優先呼出先を設定してもよい。すなわち、ある呼出先Aのデバイスに呼出元Bの電話番号が登録されていれば、呼出元BのIDに紐付けて当該呼出元Bの電話番号を登録すると共に、呼出先Aを優先呼出先として登録してよい。
【００２７】
また、呼出先DB40における登録情報に関しては、位置情報は、呼出先のデバイス（呼出先端末50）にGPSから取得した情報（緯度、経度）を、所定時間毎に一回プッシュするアプリを搭載して、情報登録部6が収集してもよい。また、屋内の測位のために、Wi-Fiの受信電波強度などを利用して、宅内の何階にいるかといった情報を各デバイスから収集してもよい。
【００２８】
機器接続部2は、呼出元が持つデバイス（呼出元端末20）と宅内装置1とを無線通信技術で接続する。この際、呼出元が呼出先の自宅へと訪問してきた際の最初の処理として、接続を確立する必要があるが、以下のようにして確立することができる。
【００２９】
まず、前提として、当該接続する一実施形態においては、自宅のドアあるいは玄関といった訪問受付場所に、NFC（近距離無線通信；Near Field Communication）タグやNFC P2P（ピアツーピア）対応端末が備え付けられているものとする。当該NFCタグ等には、呼出元端末20が宅内装置1と接続するために必要な連携情報リストの情報を格納しておく。
【００３０】
呼出元端末20は、当該NFCタグ等の読み込みをトリガーとし、宅内装置1との接続を確立する。当該接続する際に、呼出元端末20が、(1)宅内装置との連携のためのアプリを既に持っている場合と、(2)持っていない場合について、以下それぞれ説明する。
【００３１】
(1)アプリを既に持っている場合、NFCタグを読み込むと、宅内装置1との間で、BluetoothやWiFi（登録商標）アクセスポイント(AP)を介して、接続を確立する。図３及び図４に各場合の手順を模式的に示す。
【００３２】
図３に示すように、[手順1]にてNFCタグ等から連携情報リストL1を読み込んだのち、[手順2]のようにBluetoothで接続する場合には、連携情報リストL1内にある宅内装置1のBTDアドレスを指定することで、当該[手順2]における宅内装置1との接続を確立できる。
【００３３】
図４に示すように、[手順1]にてNFCタグ等から連携情報リストL2を読み込んだのち、[手順2]のようにWi-Fiを利用する場合は、[状態1]として示すように宅内装置1が既に接続済みの宅内のWi-Fiアクセスポイント（ルータ）R1に対して、呼出元端末20も接続を確立することで、間接的に宅内装置1とも接続できる。ここで一般に、Wi-FiアクセスポイントR1に加入するためには、SSID（サービスセット識別子）、パスワード、暗号化方式が必要となり、宅内装置1との通信のためには、宅内装置1のIPアドレスなどが必要となる。当該必要となる情報は図４に示すように、連携情報リストL2に記載しておけばよい。
【００３４】
(2)アプリを持っていない場合、呼出元端末20において汎用ブラウザを活用することができる。汎用ブラウザを利用すれば、その場でウェブアプリをダウンロードして実行できるため、当該実行されるウェブアプリによって上記(1)の場合と同様に宅内装置1へと接続することができる。
【００３５】
ただし当該(2)の場合、Bluetooth接続情報やWi-Fi接続情報に加えて、ウェブアプリを提供しているウェブサーバのURLを知る必要がある。このURLについても、NFCタグ等に格納しておけばよい。ウェブサーバは、外部のインターネット上にあってもよいし、宅内装置1に搭載されていてもよい。図５及び図６に各場合を模式的に示す。ウェブサーバが宅内装置1に搭載されている場合（すなわち、宅内装置1がウェブサーバの機能を担う場合）、宅内装置1とウェブサーバのURLは同じであってもよい。
【００３６】
図５に示すウェブサーバS20が外部のインターネット上にある場合は、[手順1]にてNFCタグ等から連携情報リストL3を読み込んだのち、[手順2]においてウェブサーバS20よりウェブアプリをダウンロードして実行することで、[手順3]に示すように宅内装置1との接続が可能となる。図５の例は図３の例に対応するが、連携情報リストL3には（図３の連携情報リストL1に対する）追加情報として、ウェブサーバのURLが記載されているので、[手順2]以降が可能となる。
【００３７】
図６に示すウェブサーバS1が宅内装置1に搭載されている場合は、[手順1]にてNFCタグ等から連携情報リストL4を読み込んだのち、[手順2]においてWi-FiアクセスポイントR1を介してウェブサーバS1へと接続し、[手順3]においてウェブサーバS1よりウェブアプリをダウンロードして実行することで、[手順4]に示すように宅内装置1との接続が可能となる。図６の例は図４の例に対応するが、連携情報リストL4には（図３の連携情報リストL2に対する）追加情報として、ウェブサーバのURLが記載されているので、[手順2]以降が可能となる。
【００３８】
なお、図５の例ではウェブサーバS20が外部にある際に宅内装置1とBluetoothで接続しているが、代わりに宅内装置1とWi-Fiで接続することも可能である。また、図６の例ではウェブサーバS1が宅内装置1に搭載されている際に宅内装置1とWi-Fiで接続しているが、代わりに宅内装置1とBluetoothで接続することも可能である。
【００３９】
なお、宅内装置1における機器接続部2の機能は、以上の図３〜図６等のような動作によって呼出元端末20がアプリ又はウェブアプリの機能により宅内装置1へ接続要求してきた際の応答としての接続確立の機能と、以降の処理において当該確立された接続により宅内装置1と呼出元端末20との間の種々の通信（宅内装置1を中継して呼出元端末20と呼出先端末50とが通信する場合を含む）における宅内装置1側でのインターフェース機能と、である。
【００４０】
図７は、呼出元識別部3の機能を説明するための図である。呼出元識別部3は、以上のように機器接続部2によって接続した呼出元のデバイス（呼出元端末20）から送信される呼出元識別情報に基づき、呼出元を特定する機能を持つ。呼出元識別情報は、図中にも示すように、(1)BTDアドレス、(2)MACアドレス、(3)電話番号、(4-1)画像などである。これらを呼出先DBのキーとして、呼出元IDを特定する。（なお、(4-2)については後述する。）
【００４１】
ここで(1)BTDアドレス、(2)MACアドレス、(3)電話番号を利用する際には、図７中に[参照]として示すように、呼出元DB30にある情報（図２の[1]）と一致するかを検索する。一致しなければ、未知の呼出元と判定され、事前の設定に応じて適切に処理される。これらの情報(1)〜(3)は、呼出元のデバイス（呼出元端末20）のアプリから自動で取得することができるため、呼出元が自分で入力する必要はなく、手間がかからない。なお、当該情報(1)〜(3)はいずれも呼出元端末20につき一意であるので、いずれか少なくとも1つを利用すればよい。
【００４２】
図７中に(4-1)として示すように、画像を利用する際には、呼出元端末20において例えば呼出元の顔写真を撮影し、それを宅内装置1に送って、宅内装置1の内部サーバとしての画像認識部7において、呼出元DB30に登録してある画像をリファレンスとして、画像認識を行う。認識結果として、登録画像と一致すれば、それに紐づく呼出元IDと判定する。なお、画像は、呼出元を識別できる性質のものであれば顔写真に限ることなく、任意の画像でもよい。また、呼出元個人を識別するための画像だけでなく、企業のロゴなど属性を表すものでもよい。
【００４３】
また、図７中に(4-2)として示すように、一実施形態では画像認識部7は外部サーバとして構成されていてもよい。この場合、顔写真等の画像を呼出元端末20より外部サーバとしての画像認識部7に送信し、上記(4-1)と同様に呼出元DB30をレファレンスとして認識結果を呼出元IDとして取得し、呼出元端末20に返信する。呼出元端末20では当該返信された呼出元IDを呼出元識別部3に送信すればよい。
【００４４】
呼出元識別部3では以上のような各実施形態によって呼出元を特定すると、呼出元DB30を参照することで、当該特定した呼出元IDに対応付けられた呼出音及び優先呼出先を含む呼出付加情報を読み出し、当該呼出元付加情報を呼出先振分部4へと出力する。
【００４５】
図８は、呼出先振分部4の機能を説明するための図である。呼出先振分部4は、当該呼出元が訪問してきた旨を、どの呼出先に通知すべきかを振り分ける機能を持ち、呼出設定情報を作成する。当該作成される呼出設定情報は、呼出音パタンと呼出先リストとを含む。
【００４６】
呼出先リストには、初期設定として、呼出先DB40（図２の[2]、図８にリストL30として再掲）に登録済みの全てのデバイス（呼出先端末50）を追加するとしてもよいし、以下の(条件1),(条件2)が該当する場合においては、初期設定をリセットし、特定のデバイスのみを追加してもよい。
【００４７】
(条件1) 呼出元識別部3より入力された呼出付加情報に有効な優先呼出先がある場合、当該呼出先を呼出先リストに追加する。
【００４８】
当該(条件1)が好適な具体例としては、宅内装置1の家には家族がおり、それぞれ呼出先端末50を有している際に、当該家族内の1人の友人が訪問者すなわち呼出元として呼出元端末20を持って訪問してきた場合が挙げられる。この場合、当該友人の呼出元IDに関して呼出元DB30の優先呼出先に当該家族内の1人を予め登録しておくことで、スムーズに訪問が可能となる。また、複数社員のいる会社ビルにおいて特定社員に訪問しようとするような際も同様に、スムーズな訪問が可能となる。
【００４９】
(条件2) 呼出元より呼出先の指定がある場合、当該指定された呼出先を呼出先リストに追加する。この場合、呼出元は呼出元端末20のアプリから呼出先指定情報を入力することにより、呼出先を指定することができ、指定された呼出先は呼出先リストに追加される。当該入力する呼出先指定情報には、電話番号等の、呼出先DB40に各呼出先IDと紐付けて登録されている情報を利用することができる。
【００５０】
当該(条件2)が好適な具体例は次の通りである。呼出元が宅配業者であれば、届け物の伝票に電話番号が記載されていることがあり、それを入力することで、複数人世帯や共同玄関を持つゲストハウスにおいて、本人限定受取などをスムーズに実施することができる。呼出元が友人であれば、アドレス帳から呼出先の友人の電話番号を入力することで、家族間での用件のやりとりの手間が低減できると考えられる。
【００５１】
なお、上記の(条件1)優先呼出先と(条件2)呼出先指定情報の両方が指定されている場合、いずれか片方を優先してもよいし、両方を適用してもよい。これは、事前に決めた規則に従う。
【００５２】
一方で、これら優先呼出先や呼出先指定情報によって指定された呼出先が、宅内にいるとは限らない。宅内に不在なのであれば、他の呼出先に通知を行ったほうがよい場合もある。このような観点から、一実施形態では以下のような追加処理を行うようにしてもよい。
【００５３】
すなわち、呼出先振分部4ではまず、宅内にあるデバイス（呼出先端末50）を検知して、在宅デバイスリストを作成する。在宅デバイスリストは図７にリストL40として例示されている。ここで、Bluetoothのデバイス探索により発見されたデバイスを、在宅デバイスと判断してもよいし、宅内のWi-Fiアクセスポイントに現在接続中のデバイスを、在宅デバイスと判断してもよいし、GPSなどの位置情報に基づき、在宅デバイスと判断してもよい。
【００５４】
呼出先振分部4はさらに、優先呼出先や呼出先指定情報を、当該作成した在宅デバイスリストと照合して、在宅デバイスリストに含まれる場合は、呼出先リストに追加し、含まれない場合は、追加しないようにすることができる。
【００５５】
しかしこの場合、当該照合した結果、優先呼出先や呼出先指定情報における呼出先が全て宅外におり、有効な呼出先（宅内に存在する呼出先）が存在しないこともありうる。従って、呼出先振分部4ではまた、有効な優先呼出先と呼出先指定情報が呼出先DB40上に存在しない場合の一実施形態として、次のようにしてもよい。
【００５６】
すなわち、位置情報に基づき呼出先を呼出先リストに追加するようにしてよい。上述の呼出先DB40に登録してある呼出先毎の位置情報に基づき、例えば、優先呼出先や呼出先指定情報における宅外の呼出先のうち、最も近くにいると識別された呼出先を指定する規則にしてもよい。また、同位置情報に基づき、宅内にいる複数の呼出先（優先呼出先や呼出先指定情報では指定されていない呼出先）の中で、最も近い呼出先を指定する規則にしてもよい。この際、訪問者としての呼出元の所在位置（例えば家の１回の玄関など）に最も近い呼出先を指定すればよい。
【００５７】
以上、呼出先振分部4では各実施形態によって呼出先リストを作成することができる。呼出先振分部4ではさらに当該呼出先リスト内の呼出先ごとの呼出音を設定することで、作成された呼出先リスト及び設定された呼出音として、呼出設定情報を作成する。呼出音は、呼出元IDと、呼出先IDと、当該呼出先IDの呼出先が在宅であるか否かと、に応じて所定規則で設定すればよい。
【００５８】
当該所定規則においてはさらにその他の条件を考慮してもよい。例えば、呼出先リスト内の全員が宅外に存在することや、当該自宅の全員（呼出先DB40に登録されている全呼出先）が宅外に存在すること等を、条件として考慮してもよい。
【００５９】
一般には、以上のようにして呼出設定情報を作成することができるが、実際に作成するに際しては、訪問者が訪れる際の種々の状況に応じて便利な応答が可能となるように、呼出設定情報を作成する規則を定めておけばよい。図９は、当該状況に応じた種々の規則の具体例を(1)〜(6)と場合分けして、その効果と共に示す図である。
【００６０】
(1)通常時
呼出元が初めての訪問者や未登録の訪問者の場合（例えば呼出元が全く見知らぬ人の場合等）、呼出先を最適化するための情報がないため、呼出音は通常音とし、宅内全員に通知する。通常音は未知の訪問者の可能性があるため、在宅者は、応答する必要がないといった判断ができる。
【００６１】
(2)宅配業者認識時
呼出元が既にBTDアドレスやMACアドレス、電話番号、もしくは顔画像などが登録済みの宅配業者であり、呼出先は指定されていない場合、呼出音を宅配便用の音に変更する。これにより、在宅者は、画面など見なくとも、音だけで宅配業者と判断できるため、判断の手間が軽減し、応答に向かう可能性が高くなる。呼出元の宅配業者は、在宅にも関わらず、応答がないといったことを避けられるため、再配達の手間が軽減される。
【００６２】
なお、一般には登録済の呼出元IDにそれぞれ、種別の情報を紐付けておき、種別ごとに呼出音を設定しておけばよい。上記「宅配業者」は当該種別の一例である。当該種別の情報は、呼出元DB30に登録しておけばよい。
【００６３】
(3)優先呼び出し時
呼出元が例えばある呼出先Aの友人であり、呼出先Aが自身を当該呼出元における優先呼出先に設定済みであったため、呼出先Aのみに通知が届く。呼出元自体は、登録などしていなくても、呼出先Aを直接呼び出すことが可能である。一方で、在宅者である他の呼出先候補は、用件伺いのためだけの負荷が軽減される。
【００６４】
(4)電話番号指定時
呼出元が例えば宅配業者であり、伝票に記載されている電話番号を入力することで、特定の呼出先Bを指定することができる。本人限定受取の荷物や着払いなどの対応をスムーズに行うことができる。
【００６５】
なお、当該(4)の場合、当該宅配業者としての呼出元は、(2)の場合とは異なり呼出元DB30に予め登録されているか否かによらず、上記のような指定が可能となる。
【００６６】
(5)位置情報判断時
呼出元が未知の訪問者であり、位置情報に基づき近いと判断された特定の呼出先Cに通知が届く。例えば、宅内の1階の玄関隣の部屋にいる人物が応答することが最もスムーズに応答できるため、呼出元の待ち時間を軽減する。また、呼出先C以外の他の在宅者の用件伺いのための負荷が軽減される。
【００６７】
(6)外出時
呼出元が未知の訪問者であり、宅内には全員不在の状況において、未知の訪問者に対して、優先呼出先に設定されていた特定の呼出先Dに通知が届く。これにより、外出時においても、訪問者への応答が可能となり、遠隔でも行える用件であれば、訪問者が再訪する手間が軽減される。
【００６８】
図１０は、呼出先通知部5の機能を説明するための図である。呼出先通知部5では、呼出先振分部4により設定された呼出設定情報に基づき、実際に呼出があった旨の通知を行う。通知の方法としては、宅内装置1が呼出音を鳴らし宅内全体に通知する方法と、全ての呼出先または特定の呼出先のデバイス（呼出先端末50）に対して通知を行う方法がある。いずれの方法が採用されるかは、呼出設定情報に従って決まる。
【００６９】
図１０に(1)として示すように、宅内装置1が宅内全体に通知する場合、呼出元に応じた呼出音パタンで、呼出音が鳴るため、音を聞くだけで、訪問理由がある程度推測でき、宅内にいる各呼出先は、応答すべきか否かを判断することができる。従って例えば、通常音が鳴った場合、未知の訪問者であると推測されるため、不安なので応答しないが、宅配業者用が鳴った場合、宅配業者であると推測されるため、安心して応答するといったことが可能となる。
【００７０】
一方で、図１０に(2)として示すように、各呼出先が持つデバイスに対して通知を行う場合には、宅内装置1は宅内全体に向けて呼出音を鳴らさなくてもよい。各デバイスでは、宅内装置1からの通知を常時待ち受けており、通知があったタイミングで、デバイスから音を鳴らすもしくは振動して通知を行ってもよい。この際に呼出元に関する呼出元IDや電話番号などのメタ情報や画像情報を一緒に提示してもよい。デバイスから鳴る音に関しては、アプリが、呼出音パタンで指定された音を鳴らしてもよいし、呼出元に関するメタ情報などに応じて、デバイス側のアプリで設定された呼出音を鳴らしてもよい。
【００７１】
ここで、通知の方法は、音を鳴らすことや、呼出元のメタ情報や画像情報を表示させることのような単方向的な方法のみでも構わない。また、当該単方向的な通知を行った上で、呼出元と呼出先の間での音声や映像のやりとりのような双方向的な方法でも構わない。なお、単方向とするか双方向とするかといった設定も、呼出先振分部4において呼出設定情報において所定規則で設定しておけばよい。
【００７２】
呼出先に関しては、呼出設定情報に従い、宅内にいるデバイスへ通知を行ってもよいし、宅外にいる呼出先のデバイスに対して、通知を行ってもよい。例えば、外出先において、どのような訪問者が来たのか把握できることや応答自体を行うことができれば、呼出元に再度来訪してもらう手間を軽減でき、呼出先もより早く訪問者の用件に応対することができる。
【００７３】
以下、図１１及び図１２を参照して、宅内デバイスへの通知及び宅外デバイスへの通知の具体例をそれぞれ説明する。なお、図１１及び図１２では、機能ブロックとしては呼出先通知部5ではなく呼出先振分部4を主要部として描いているが、これは、宅内デバイスへの通知及び宅外デバイスへの通知を実施する判断及び事前準備（通知のための通信確立等）を呼出先振分部4において行うためである。当該事前準備のもとで実際に通知処理を担うのが、呼出先通知部5となる。
【００７４】
図１１は、宅内にあるデバイスへの通知の方法の例を示す図である。まず、[手順1]として示すように、呼出元が来訪した際に、NFCタグなどを呼出元のデバイスで読み取り、宅内装置1へと接続を行う。（なお、当該[手順1]は機器接続部2において接続確立の際に実施済みである。）
【００７５】
この際に、例えばBluetoothを利用して、ペアリングを行うとする。ペアリング後、BluetoothのSPP(Serial Port Profile)などを使って、呼出元と宅内装置1の間でメッセージのやりとりを可能にする。Bluetoothを利用して呼出元と宅内装置1を接続することにより、呼出元が現在いる場所が、確実に家の前であることを保証できる。また、宅内装置1は、呼出元の識別のために、呼出元に入力させなくとも、呼出元のデバイスのBTDアドレスを利用することができる。Wi-Fiにおいても同様のことを実現できるが、宅内で普段利用しているWi-Fiのアクセスポイントの情報を呼出元に公開する必要があることや、同じWi-Fiアクセスポイントに接続してしまえば、宅内装置1以外に関してもアクセス可能となってしまうことも考えられ、セキュリティ上好ましくない。ただし、訪問者連携機器専用のWi-Fiアクセスポイントを用意することで回避できる。
【００７６】
ペアリング後、宅内装置1は、呼出先振分部4において、呼出元から取得された呼出元識別情報などに基づいて、呼出先振分を行う。特定の呼出先の通知でなければ、[場合1]として示すように、宅内装置1が呼出音発生器41に指示して、呼出音パタンに設定された適切な呼出音を鳴らすようにさせる。
【００７７】
一方で、[場合2]として示すように、特定の呼出先への通知であれば、呼出先との間で、ネットワークを確立する必要がある。（なお、[場合3]については図１２で説明する。）呼出先は、基本的に、宅内装置の管理者と同居していると考えられるため、IP通信が可能なWi-Fiなどで接続を行ってもよい。その場合、図示するように、宅内にWi-Fi アクセスポイント（ルータ）R1があり、[状態1],[状態2]として示すように、宅内装置1及び呼出先の呼出先端末50が当該アクセスポイントR1に接続済であることが前提となる。
【００７８】
なお、Wi-Fiではなく、Bluetoothを利用する場合においても、BluetoothのPAN（Personal Area Network）プロファイルを利用すれば、Ethernet(登録商標)をエミュレートできるため、その上でIP通信を行い、[状態1],[状態2]と同様のことが実現できる。
【００７９】
呼出先に対して、すみやかに通知を行うためには、呼出先に対してプッシュで通知を行うことができる必要がある。そのため、例えば、宅内装置は、WebSocket（ウェブソケット）サーバ42（当該サーバ42として機能する構成）を備える。呼出先のアプリは、アプリを起動したタイミングで、WebSocketサーバ42に接続を確立しておく。これにより、サーバとクライアントの双方で任意のタイミングでメッセージをやりとり可能なコネクションが確立されるため、呼出元から呼出が行われた際すぐに、[手順2]として示すように、呼出先のアプリに通知を行うことができる。
【００８０】
ここで、呼出先のアプリは、常に起動していることを前提としてもよいし、アプリが動作するプラットフォームで提供されているプッシュ通知の仕組み（例えば、Google Cloud Messaging Service, http://developer.android.com/google/gcm/index.html）を利用して、呼出が行われたタイミングで自動起動するようにしておいてもよい。
【００８１】
図１２は、宅外デバイス（宅外にある呼出先端末50）への通知の方法の例を示す図である。[手順1]として示すようなペアリングや呼出先振分については、図１１の宅内デバイスへの通知と同様の方法を利用すればよい。宅内装置1から宅外にいる呼出先デバイス50に通知を行うためには、各デバイスの間でネットワーク接続が確立されている必要がある。このため例えば、宅内には、インターネットに接続可能な宅内ルータR1があり、宅内装置1はそのルータに接続されているものとする。
【００８２】
一方で、宅外では、呼出先デバイス50についても、インターネット接続可能な宅外ルータR2に接続されている。両者がアクセス可能なインターネット上に、（外部）WebSocketサーバS2を備え、呼出先デバイスのアプリはこのWebSocketサーバS2に常時接続しておく。宅内装置1は、呼出元より呼び出しが行われた際に、[手順2]として示すように、インターネット上にあるWebSocketサーバS2のURLに対して、特定の呼出先IDを含む呼出要求を行う。要求を受け取ったWebSocketサーバS2は、[手順3]として示すように、呼出先IDに応じて、既にコネクション確立済みの呼出先のデバイスに対して、通知を行う。
【００８３】
ここで、宅内装置1は、以上の図１１，１２のような手法により、呼出元からの依頼に基づき、呼出先に対して、メタ情報や画像情報を含む単純な通知を行うだけでなく、呼出元と呼出先の間で映像や音声を介して応答できる環境を提供してもよい。以下、図１３及び図１４を参照して、呼出先がそれぞれ宅内及び宅外に存在する場合に、当該環境を提供する方法の例を説明する。
【００８４】
図１３は、呼出元と宅内にある呼出先との間で、映像や音声を介した応答環境を提供する方法の例を示す図である。[手順1],[手順2]として示すようなペアリングや呼出先振分・通知については、図１１と同様の方法を利用すればよい。呼出元と宅内にある呼出先のデバイスとを接続する方法として、同一のWi-FiアクセスポイントR1を介して接続する方法を利用する。このためまず[手順3]として示すように、Wi-FiAP情報通知部43より、呼出元に対して、[状態1]として示すように宅内装置1や呼出先デバイスが接続しているWi-FiアクセスポイントR1や呼出先に通知するためのWebSocketサーバ42への接続情報（SSID、PW、暗号化方式、WebSocketサーバのURLなど）を通知する。当該通知の際の宅内装置1から呼出元へのメッセージのやりとりは、BluetoothのSPPなどで行う。
【００８５】
呼出元は、[手順4]として示すように、受け取ったWi-Fi APの接続情報に基づき、Wi-FiアクセスポイントR1に接続する。その後、受け取ったURLに対してWebSocketで接続し、WebSocketサーバ42との間でコネクションを確立する。呼出先については、WebSocketサーバとの間でコネクションを確立済みである。この状態において、WebSocketサーバを介して、呼出元と呼出先との間で任意のメッセージを交換可能となる。
【００８６】
映像や音声をやりとりする際に、WebSocketサーバ42を介してやりとりすると、サーバに負荷がかかるため、呼出元と呼出先の間で、P2P（ピアツーピア）で接続を確立して、その上で映像や音声をやりとりする方法を利用する。この接続確立のために、[手順5]として示すように、呼出先と呼出元それぞれのIPやポート番号のネットワーク情報に加えて、サポートしている映像や音声のコーデックなどのメディア情報を含んだP2P接続情報を、WebSocketサーバ42を介してやりとりする。
【００８７】
呼出元が、WebSocketサーバ42に対して呼出元のP2P接続情報を送信すると、WebSocketサーバ42が既に接続済みの呼出先に対してP2P接続情報を中継する。例えば、それをトリガーとして、呼出先が、呼出先のP2P接続情報をWebSocketサーバ42に対して送信すると、WebSocketサーバが既に接続済みの呼出元に対してP2P接続情報を中継する。こうして[手順5]が実現され、互いにP2P接続情報が交換できたため、例えば呼出元をトリガーとして、呼出先に対してP2Pで接続し、[手順6]として示すように、メディア情報に従い、映像や音声のやりとりが可能となる。
【００８８】
なお、より詳細なP2P接続情報の内容やその交換のためのプロトコルに関しては、W3C（World Wide Consortium）が規格化を進めるWebRTC（Web Real Time Communication）の仕様に従って行ってもよい。
【００８９】
図１４は、呼出元と宅外にある呼出先との間で、映像や音声を介した応答環境を提供する方法の例を示す図である。宅内装置1は、[手順1]と示すように呼出先振分等を図１２と同様にして行った後で、[手順2]として示すように、WebSocketサーバやSTUNサーバのURL及び呼出先IDを、BluetoothのSPPなどで、呼出元に送ればよい。また、[手順3]として示すように、図１２と同様にして外部の呼出先へと通知する。
【００９０】
ここで、図１４の場合の構成が図１３の場合の構成と異なる部分は、WebSocketサーバS2がインターネット上にあることと、STUNサーバ（Simple Traversal of UDP through NATsサーバ）S3を利用するところである。WebSocketサーバS2の役割は、宅内でのP2P接続確立時と同様に、P2P接続情報を呼出元及び呼出先で交換することである。STUNサーバS3の役割は、呼出元からリクエストがあった際に、呼出元が加入しているルータのグローバルIPとポート番号を応答することである。
【００９１】
呼出元のデバイスと、宅外にいるデバイスは、通常、ルータを介して、異なるネットワークに属している。この際に、各デバイスでは、ルータ配下で利用可能なプライベートIPが割り当てられている。このプライベートIPは、ルータの管理者などが定義したルールにおいて割り当てられており、異なるルータにおいては、このプライベートIPを利用してデバイスを特定して通信を行うことはできない。一方で、世界で一意にデバイスを特定するために割り当てられたグローバルIPがある。ルータは、通常、プライベートIPとグローバルIPを変換する機能を提供しており、それ故に、インターネット接続が可能である。
【００９２】
すなわち、異なるネットワークに属する呼出元と呼出先の間で、P2Pで通信を行うためには、グローバルIPとポート番号を含むP2P接続情報を交換する必要がある。
【００９３】
このため、[手順4]として示すように、呼出元がSTUNサーバS3に対して、通過する外部ルータR3のグローバルIPとポート番号を取得した上で、[手順5]として示すように、P2P接続情報を作成し、インターネット上のWebSocketサーバS2へ送信する。WebSocketサーバS2は、呼出先に呼出元のP2P接続情報を中継する。それを受け取った呼出先も同様に、[手順6]として示すように、STUNサーバS2を介して、通過する宅外ルータR2のグローバルIPとポート番号を取得した上で、[手順7]として示すように、P2P接続情報を作成し、インターネット上のWebSocketサーバS2へ送信する。WebSocketサーバS2は、呼出元に対して、呼出先のP2P接続情報を中継することで、お互いのP2P接続情報が交換可能となる。この後は同様に、[手順8]として示すようにメディア情報に従い、映像や音声をやりとりすればよい。
【００９４】
なお、宅外端末との映像や音声のやりとりに関しても、より詳細なP2P接続情報の内容やその交換のためのプロトコルに関しては、WebRTCの仕様に従って行ってもよい。
【００９５】
図１５は、情報登録部6において、事前に、これから行われる訪問に関する情報を登録した上で、訪問を行うようにする実施形態を説明するための図である。このケースにおいては、訪問者（呼出元）及び訪問先（呼出先）が、呼出元訪問予定情報を、図１５中にリストL50として示すように、呼出元DB30に対して予め登録する。呼出元訪問予定情報は、訪問のための認証情報や訪問予定時刻などから成る。
【００９６】
訪問者においては、訪問の際に、次のようなケースが考えられる。すなわち、以上説明例として用いたような個人の家への訪問に限らず、企業への訪問のケースであり、訪問者機器連携装置1は、当該ケースにも応用可能である。企業への訪問する際には、入館にあたり、用件のある部署名や担当者の氏名や連絡先などを要求されることがある。訪問者は、担当者の氏名は覚えていても、部署名や連絡先までは覚えていないことが考えられ、調べるために手間がかかる問題がある。
【００９７】
そのため、事前に訪問先から入館にあたって、認証情報を取得できれば、入館のための手間が軽減される。認証情報は、訪問先が登録する。無作為テキストによるパスワードでもよいし、QRコード（登録商標）のような画像ベースでもよい。また、訪問者が忘れにくい訪問者自身の電話番号であってもよい。訪問の際に、その認証情報に紐づけて、上述のように、呼出音や呼出先を変更してもよいし、ドアと連携して解錠まで行ってもよい。
【００９８】
また、訪問先においては、次のようなケースが考えられる。宅配などに関しては、いつ宅配業者が訪問するかわからないため、外出して不在にすることや、訪問された際に在宅であったとしても、未知の訪問者に対して不安を抱き、応答しないという問題がある。そのため、事前に訪問予定時刻を把握できれば、不在を避けることや、不必要な不安を和らげ応答することが可能となる。
【００９９】
以上のようなケースに対応すべく、訪問予定時刻は、[手順1]として示すように、訪問者が事前に登録する。また、パスコード等の認証情報は、[手順2]として示すように、訪問先が事前に登録する。なお、訪問予定時刻の情報は、上記のように訪問先の事前把握による不安緩和の用途の他にも、実際に訪問があった時刻が予め登録されているものと大きく乖離する場合に、当該訪問者が予定外の訪問者である旨を呼出元識別部3において自動判定するためにも利用可能である。大きく乖離しているか否かは閾値判定すればよい。
【０１００】
これら訪問予定情報は、宅内及びオフィス内にいなくとも、登録できてもよい。訪問先が登録した情報は、インターネット上にあるWebサーバS20などを介して、訪問者に通知する。訪問者が登録した情報も、同様にWebサーバS20などを介して、訪問者に通知する。訪問先及び訪問者に対して、予め宅内装置とWebサーバ、訪問者が持つデバイスとWebサーバの間で既にコネクションを確立しておいて、プッシュ的に通知をしてもよいし、訪問先及び訪問者がWebサーバに能動的にアクセスして、プル的に通知してもよい。
【０１０１】
なお、情報登録部6では、訪問予定情報を、来訪後または登録後の所定の時間後、呼出元DB30より削除してもよい。
【０１０２】
以上、本発明によれば、在宅者に対しては、次のような効果を奏することができる。
【０１０３】
(1)家などへの訪問者が在宅者を呼び出しを行う際に、呼出元が持つデバイスを利用して宅内装置と無線接続を行うことで、家の前にいることを保証し、遠隔からの悪意のある呼び出しなどを防止することができる。
(2)無線接続情報などを利用して、訪問者を識別し、それに応じて呼出音を切り替えることで、宅内装置で映像の確認や応答などしなくても、訪問者の属性を手間なく把握することができる。
(3)複数の在宅者がいる際に、訪問者の用件に応じて、適切に特定の在宅者のみを呼び出すことにより、自分以外の在宅者への用件で呼び出される手間を軽減することができる。
(4)外出先でも応答ができ、いち早く訪問者の用件を把握することができる。
(5)来訪予定時刻を把握することで、不在を避けることや安心して応答できる。
【０１０４】
また、本発明によれば、訪問者に対しては、次のような効果を奏することができる。
【０１０５】
(1)在宅にも関わらず、不審者と懸念されて、居留守を使われることを抑制し、再訪問の手間を軽減することができる。
(2)用件のある在宅者本人を呼び出せるため、スムーズに用件を済ますことができる。
(3)宅内に不在の場合においても、外出時で応答してもらえることから、用件を済ませることができる場合がある。
(4)家だけでなく、企業などへの訪問時も事前情報登録により、スムーズに入館できる。
【符号の説明】
【０１０６】
1…訪問者機器連携装置、2…機器接続部、3…呼出元識別部、4…呼出先振分部、5…呼出先通知部
【図１】
2016082419.tif 000003
【図２】
2016082419.tif 000004
【図３】
2016082419.tif 000005
【図４】
2016082419.tif 000006
【図５】
2016082419.tif 000007
【図６】
2016082419.tif 000008
【図７】
2016082419.tif 000009
【図８】
2016082419.tif 000010
【図９】
2016082419.tif 000011
【図１０】
2016082419.tif 000012
【図１１】
2016082419.tif 000013
【図１２】
2016082419.tif 000014
【図１３】
2016082419.tif 000015
【図１４】
2016082419.tif 000016
【図１５】
2016082419.tif 000017