JP2023164211A - 受付システム及びプログラム - Google Patents

Abstract

【課題】受付システムを導入する訪問先企業等が来客用受付端末を設置することなく受付処理を行う。【解決手段】サーバ（２００、５００）と、アプリケーションソフトがインストールされた複数のユーザ端末（３００）とがそれぞれインターネットを介して接続され、来客携帯端末を用いた受付処理が可能な受付システム（１０）であって、サーバは、通信手段（２０１、５０１）と、来客の受付に用いられるＷｅｂ情報を記憶する記憶手段（２０３、５０３）と、処理手段（２０２、５０２）とを有し、通信手段は、来客携帯端末により所定の二次元コードが読み取られた場合、Ｗｅｂ情報を来客携帯端末へ送信し、Ｗｅｂ情報に基づいて来客携帯端末に表示されたＷｅｂページ上で来客により入力されたパスコードを受信し、処理手段は、パスコードに関連付けられた来客情報及び訪問先情報を照合し、訪問先情報に基づく第１のユーザ端末へ通知する。【選択図】図１

Description

特許法第３０条第２項適用申請有り 令和３年１０月５日に、ウェブサイト（アドレス ｈｔｔｐｓ：／／ｒａｋｕ－ｎｅｋｏ．ｊｐ／ｎｅｗｓ／２０２１／２０２１１００５／）に掲載 （刊行物等） 令和４年３月２４日に、ウェブサイト（アドレス ｈｔｔｐｓ：／／ｒａｋｕ－ｎｅｋｏ．ｊｐ／ｎｅｗｓ／２０２２／２０２２０３２４／）に掲載

本発明は、来客の訪問があったことを担当者に通知するための受付システム及びプログラムに関する。

従来、来客の訪問があったことを訪問先企業等の担当者に通知する受付システムが知られている。特許文献１には、来客用受付端末１００と、サーバ２００と、複数のユーザ端末３００ａ～３００ｘ（訪問先企業等の担当者の携帯端末等）とから構成され、互いにインターネットを介して接続された受付システムが開示されている。サーバ２００は、来客用受付端末１００からインターネットを介して取得した情報に基づいて来客情報及び訪問先情報を取得する取得手段２０２ａと、来客情報と事前に登録された音声情報とに基づいて、自動音声合成により来客の訪問を通知するための音声データを生成する生成手段２０２ｂと、ピア・ツー・ピア通信により音声データを複数のユーザ端末３００ａ～３００ｘのうち訪問先情報に基づくユーザ端末へ発信する通信手段２０１とを有する。特許文献１に開示された受付システムによれば、電話回線を利用することなく音声データを担当者の携帯端末等に着信させることができる。

特開２０２１－１６３０１５号公報

しかしながら、特許文献１に開示された受付システムでは、受付システムを導入する訪問先企業等のユーザは、来客用受付端末として、タブレット端末、タッチパネル式のディスプレイ、又はパソコン等を設置する必要がある。このため、受付システムを導入するユーザにとって、来客用受付端末の準備及び管理に手間がかかるとともに、導入コストが増加する。また、来客にとっては、受付の際に、不特定多数の他人の手で触れられた来客用受付端末を操作するのに抵抗がある可能性がある。また、同時に多数の来客があった場合には受付の行列ができる等、ユーザ及び来客の双方にとってデメリットである。

そこで本発明の目的は、受付システムを導入する訪問先企業等が来客用受付端末を設置することなく受付処理を行うことである。

本発明の受付システムは、サーバと、アプリケーションソフトがインストールされた複数のユーザ端末とがそれぞれインターネットを介して接続され、来客携帯端末を用いた受付処理が可能な受付システムであって、前記サーバは、前記インターネットを介して前記来客携帯端末および前記複数のユーザ端末との通信が可能な通信手段と、来客の受付に用いられるＷｅｂ情報を記憶する記憶手段と、処理手段とを有し、前記通信手段は、前記来客受付の際に前記来客携帯端末により所定の二次元コードが読み取られた場合、前記記憶手段に記憶されている前記Ｗｅｂ情報を前記来客携帯端末へ送信し、前記Ｗｅｂ情報に基づいて前記来客携帯端末に表示されたＷｅｂページ上で前記来客により入力されたパスコードを受信し、前記処理手段は、前記パスコードに関連付けられた来客情報及び訪問先情報を照合し、前記複数のユーザ端末のうち前記訪問先情報に基づく第１のユーザ端末へ前記来客の訪問を通知する。

本発明のプログラムは、事前に来客受付のためのパスコードを発行するステップと、来客携帯端末により所定の二次元コードが読み取られた場合、来客の受付に用いられるＷｅｂ情報を前記来客携帯端末へ送信するステップと、前記Ｗｅｂ情報に基づいて前記来客携帯端末に表示されたＷｅｂページ上で前記来客により入力された前記パスコードを受信するステップと、前記パスコードに関連付けられた来客情報及び訪問先情報を照合するステップと、アプリケーションソフトがインストールされた前記複数のユーザ端末のうち、前記訪問先情報に基づく第１のユーザ端末へ通知するステップとをコンピュータに実行させる。

本発明の他の目的や特徴は、以下の実施形態において説明される。

本発明によれば、受付システムを導入する訪問先企業等が来客用受付端末を設置することなく受付処理を行うことができる。

本実施形態に係る受付システムのブロック図である。 本実施形態に係る受付システムの処理を示すフローチャートである。 本実施形態に係る受付Ｗｅｂサーバの処理を示すフローチャートである。 本実施形態に係るサーバの処理を示すフローチャートである。 本実施形態に係る受付設定画面の一例及び位置検出処理の説明図である。 本実施形態に係るアポイントメント新規作成画面の一例である。 本実施形態に係る来客携帯端末を用いた来客受付処理の説明図である。 本実施形態に係る来客携帯端末を用いた来客受付処理の説明図である。

以下、本発明の実施形態に関し、図面を参照して説明する。

（受付システムの全体構成）
まず、図１を用いて、本実施形態の受付システムの概略構成について説明する。図１は、受付システム１０のブロック図である。

受付システム１０は、来客携帯端末１００、サーバ（受付システムサーバ）２００、複数のユーザ端末３００、および受付Ｗｅｂサーバ５００から構成される。なお本実施形態において、受付システム１０は、サーバ２００と受付Ｗｅｂサーバ５００の２つのサーバを有するが、これに限定されるものではなく、サーバ２００の機能と受付Ｗｅｂサーバ５００の機能の両方を備えた１つのサーバ（共通サーバ）を用いてもよい。

来客携帯端末１００は、例えば、来客自身のスマートフォンであるが、これに限定されるものではなく、来客自身で選択された通信機能を有する電子機器（訪問先企業等に設置され不特定多数により触れられる可能性がある電子機器以外のもの）であれば、来客のタブレット端末、タッチパネル式のディスプレイ、又はパソコン等であっても良い。サーバ２００は、受付システムのサービス（及び、受付システムを実現するためのプログラム）を提供する主体となる受付システムサーバであり、サービス提供者（受付システムの管理者）により所有又は管理されている。サーバ２００は、サービス提供者とは物理的に離れた場所に配置されたクラウドサーバであっても良い。この場合、サービス提供者は、インターネット（ＷＡＮのみならず、ＬＡＮ等のその他のネットワークを含むが、これに限定されるものではない）４００を介して、受付システムの管理及び運用を行うことができる。ユーザ端末３００は、例えばスマートフォン等の携帯端末であるが、これに限定されるものではなく、パソコンや、通信機能を有する他の電子機器であっても良い。

来客携帯端末１００とサーバ２００とユーザ端末３００と受付Ｗｅｂサーバ５００は、インターネット４００を介して、互いに有線または無線通信が可能である。なお本実施形態は、インターネット４００に接続されていないＬＡＮ、またはルーターを介してインターネット４００に接続されているＬＡＮを介した通信にも適用可能である。本実施形態において、来客の訪問先企業等の担当者（ユーザ）として、ユーザＡ、Ｂ、Ｃ、…Ｘが存在するものとする。このため図１には、ユーザ端末３００として、ユーザＡ、Ｂ、Ｃ、…Ｘが有するユーザ端末３００ａ、３００ｂ、３００ｃ、…３００ｘが示されている。

来客携帯端末１００は、通信手段１０１、処理手段１０２、表示手段１０３、操作手段１０４，及び、記憶手段１０５を備えている。操作手段１０４は、来客が操作するために設けられており、表示手段１０３の一部を備えて構成されたタッチパネル、ＱＲコード（登録商標）等の二次元コードの読み取り装置等を備えている。また操作手段１０４は、操作ボタン、キーボード、又はマウス等を備えていてもよい。処理手段１０２は、来客による操作手段１０４の操作に応じて、受付Ｗｅｂサーバ５００から受信した所定のＷｅｂ情報に基づいて、来客携帯端末１００の表示手段１０３にＷｅｂページを表示させるとともに、Ｗｅｂページ上で来客による操作情報を処理するために必要な各種処理を行うプロセッサ（ＣＰＵ）である。記憶手段１０５は、受付システム１０の一部を構成する来客携帯端末１００の各機能を実行するために必要なプログラムを記憶するメモリである。通信手段１０１は、インターネット４００を介して、受付Ｗｅｂサーバ５００との通信を行い、受付Ｗｅｂサーバ５００との間で必要な情報をやり取りする。表示手段１０３は、液晶パネルや有機ＥＬ等のディスプレイであり、受付Ｗｅｂサーバ５００から受信した所定のＷｅｂ情報に基づいて、Ｗｅｂページを表示する。

サーバ２００は、通信手段２０１、処理手段２０２、及び、記憶手段２０３を備えている。通信手段２０１は、インターネット４００を介して、受付Ｗｅｂサーバ５００や各ユーザ端末３００との間で通信が可能である。通信手段２０１は、例えば、来客携帯端末１００の操作に応じて受付Ｗｅｂサーバ５００から来客情報（訪問者の会社名や氏名等を示すテキスト情報）を受信するとともに、訪問先（担当者のユーザ端末３００）への通知を行う。

処理手段２０２は、受付Ｗｅｂサーバ５００から送信された来客情報等に基づいて、訪問先への通知を実行するために必要な各種処理を行うプロセッサ（ＣＰＵ）である。本実施形態において、処理手段２０２は、取得手段２０２ａを有し、来客により来客携帯端末１００を介して入力されたパスコードに関連付けられた（又は来客により直接入力された）来客情報及び訪問先情報（訪問先の会社の担当者の氏名や部署等を示すテキスト情報）を取得する。また処理手段２０２は、来客情報と予め登録された音声情報（例えば、予め記憶手段２０３に記憶された音声情報）とに基づいて音声データを生成する。また必要に応じて、処理手段２０２は、来客情報と予め登録された表示情報（記憶手段２０３に記憶された表示情報）とに基づいて表示データを生成しても良い。

記憶手段２０３は、受付システムの全体の動作を統括して各動作を管理するためのプログラム（受付システムプログラム）２０４を記憶するメモリである。プログラム２０４は、処理手段２０２等のコンピュータに受付システム１０の制御方法を実行させる。また記憶手段２０３には、来客情報や各担当者の端末情報（各ユーザ端末３００の情報）に関するデータベース２０５が記憶されている。各担当者の端末情報は、各ユーザ端末に電話番号が付与されている場合には、担当者や管理者がユーザ端末の電話番号（携帯電話番号）を逐一設定する必要がある。一方、各ユーザ端末３００にアプリをインストールしてアプリへの発信が可能である場合、アプリのログイン設定（例えば、メールアドレスとパスワード）のときに、ログイン設定を行った担当者の氏名とユーザ端末固有のＩＤ（ピアＩＤ）をサーバ２００へ送信することにより、自動的な紐づけが可能となる。

処理手段２０２は、プログラム２０４を実行し、インターネット４００を介して受付Ｗｅｂサーバ５００から送信された来客情報に基づいて、必要に応じてデータベース２０５を参照しつつ、訪問先（担当者のユーザ端末３００）を特定するとともに、担当者のユーザ端末３００への通知方法（アプリへの通知、電話番号への通知、又は、チャットツールへの通知等）を特定する。なお訪問先は、来客携帯端末１００を来客が操作して特定する場合や、サーバ２００に予め登録されている場合のいずれでも良い。担当者のユーザ端末３００への通知方法は、データベース２０５に登録されている。通信手段２０１は、処理手段２０２により特定された通知方法で、担当者のユーザ端末３００への通知を行う。なお、サーバ２００の少なくとも一部の機能をサービス提供者が所有及び管理するサーバにより実現し、サーバ２００の他の一部の機能をサービス提供者が所有及び管理するサーバとは異なるクラウドサーバにより実現するように構成してもよい。

ユーザ端末３００は、通信手段３０１、処理手段３０２、表示手段３０３、操作手段３０４、及び、記憶手段３０５を備えている。通信手段３０１は、サーバ２００からの通知を受信する。処理手段３０２は、ユーザ毎にサーバ２００により特定された通知方法に従って、サーバ２００から受信した来客情報を通知するために必要な各種処理を行う。表示手段３０３は、液晶パネルや有機ＥＬ等のディスプレイであり、サーバ２００から受信した来客情報を、前述の通知方法に従って表示する。操作手段３０４は、操作ボタン等で構成することができ、表示手段３０３の一部を備えて構成されたタッチパネル等であっても良い。 記憶手段３０５は、本実施形態の受付システム１０を実行するためのプログラムのうち、ユーザ端末３００において実行される機能を実現するためのプログラム（アプリケーションソフト、以下、「アプリ」という）を記憶するメモリである。このプログラム（アプリ）は、インターネットを介してユーザ端末３００にダウンロードして記憶手段３０５にインストールすることができる。

受付Ｗｅｂサーバ５００は、通信手段５０１、処理手段５０２、及び、記憶手段５０３を備えている。通信手段５０１は、インターネット４００を介して来客携帯端末１００およびサーバ２００との通信が可能である。なお、受付Ｗｅｂサーバ５００とサーバ２００とが共通のサーバとして用いられる場合、通信手段５０１は通信手段２０１と共通の通信手段である。処理手段５０２は、後述のように、パスコードに関連付けられた来客情報（来客の所属、氏名、訪問時間等）及び訪問先情報を照合する等、訪問先企業等の受付場所に設置された所定の二次元コードと事前に設定されたパスコードとに基づいて、受付処理を行う。記憶手段５０３は、来客の受付に用いられるＷｅｂ情報（受付処理の際に来客携帯端末１００により二次元コードが読み込まれた場合に、来客携帯端末１００に表示させるＷｅｂページに関するＨＴＭＬ等の情報）等の必要な情報を記憶しているとともに、来客携帯端末１００とのやりとりを行うために用いられるプログラム５０４を記憶している。

ＧＮＳＳ（全球測位衛星システム）６００は、ＧＰＳ（全地球測位システム）等の位置検出手段である。受付処理の際に、来客携帯端末１００の処理手段１０２は、受付Ｗｅｂサーバ５００から受信したＷｅｂ情報に格納されたプログラムに従って、ＧＮＳＳ６００を用いて取得された来客携帯端末１００の位置データと、訪問先企業等の位置として事前に設定された二次元コードの位置データとを比較する。

本実施形態の受付システム１０の全体の機能は、受付Ｗｅｂサーバ５００に格納されるプログラム（来客受付用プログラム）と、サーバ２００に格納されるプログラム（サーバ用プログラム）と、ユーザ端末３００のそれぞれにインストールされるプログラム（ユーザ端末用プログラム、すなわちユーザ端末にインストールされたアプリ）とを動作させて実現することが可能である。

（受付システム１０の全体処理）
次に、図２を用いて、受付システム１０の全体処理について説明する。図２は、受付システム１０の全体処理を示すフローチャートである。まずステップＳ１０１において、受付システム１０は、来客による来客携帯端末１００の操作に応じて、受付Ｗｅｂサーバ５００による処理を行う。本実施形態において、来客は、来客携帯端末１００を用いて受付Ｗｅｂサーバ５００から受信したＷｅｂ情報に基づくＷｅｂページ上で、事前に発行されたパスコード、又は、氏名や所属等の来客情報及び訪問先の担当者の氏名や所属等の訪問先情報を入力する。続いてステップＳ１０２において、受付システム１０は、受付Ｗｅｂサーバ５００から受信された情報に基づいて、サーバ２００による処理を行う。サーバ２００は、主に、指定された担当者のユーザ端末３００に対して、登録された通知方法に従って来客通知を行うための処理を行う（例えば、来客により入力されたパスコード等の情報に基づいて自動音声合成技術を用いて音声データを生成し、その音声データを用いて特定のユーザ端末３００へ来客通知を行う）。続いてステップＳ１０３において、受付システム１０は、サーバ２００からの指示に従って、来客の訪問先である担当者のユーザ端末３００による処理を行う。担当者は、ユーザ端末３００において来客通知を受信すると、それに応答することができる。

（受付Ｗｅｂサーバ５００の処理）
次に、受付システム１０の受付Ｗｅｂサーバ５００による処理（ステップＳ１０１）について詳述する。本実施形態の受付システム１０において、訪問先企業等のユーザは、受付システム１０の初期設定として、受付設定を行う。図５（ａ）は、本実施形態に係る受付設定画面の一例である。図５（ａ）に示される受付設定画面は、ユーザ端末３００等のユーザによる設定が可能な電子機器の表示手段に表示される。図５（ａ）に示されるように、受付設定画面において、受付システム１０の導入した企業（訪問先企業）等の名前、二次元コードを用いた受付処理を行う旨、連絡先情報や住所等を設定することができる。受付設定画面では、入力された訪問先企業の住所に基づいて、国土地理院のデータベース等を参照して、二次元コードの位置情報、すなわち訪問先企業の住所に対応する経度及び緯度が自動的に入力される。なお、緯度及び経度を手動で入力しても良い。住所、緯度、および経度などの位置情報は、データベース２０５に保存される。この初期設定は、受付システム１０の導入開始時にのみ行えば良い。

また本実施形態において、受付システム１０は、訪問先企業等の担当者の指示（アポイントメント）に従って、来客予定者のメールアドレス等の連絡先に、事前にパスコードを送付することができる。図６は、本実施形態に係るアポイントメント新規作成画面の一例である。図６に示されるアポイントメント新規作成画面は、ユーザ端末３００等のユーザによる設定が可能な電子機器の表示手段に表示される。担当者は、来客予定者がある場合、図６に示されるような画面上で、打ち合わせ日時、会議室等の場所、他の参加者、来客の会社名及び氏名、メールアドレス、受付時のウエルカムメッセージ等を入力する。この画面で登録ボタンを押すことにより、来客予定者のメールアドレスに対して、来客処理の際に用いられるパスコードを含む各情報が送信される。これらの入力処理及びパスコードの送信は、来客予定者ごとに行われる。

図３は、受付Ｗｅｂサーバ５００の処理を示すフローチャートである。図３のフローは、来客が来客携帯端末１００を用いて、訪問先企業等の受付に設置されている二次元コード５０を読み込むことで開始する。図７（ａ）は、訪問先企業等の受付に設置されている二次元コード５０の説明図である。二次元コード５０は、管理画面に表示される画像をダウンロードし、台紙のテンプレートファイルに二次元コード５０の画像を貼り付けて印刷することができる。また、二次元コード５０を印刷した用紙をアクリルスタンド等に固定して設置しても良い。

図７（ｂ）は、来客が来客携帯端末１００のカメラを用いて二次元コード５０を読み込んでいる状態を示す図である。なお本実施形態において、二次元コード５０はＱＲコード（登録商標）であるが、これに限定されるものではなく、他の二次元コードであっても良い。二次元コードは、来客携帯端末１００を受付Ｗｅｂサーバ５００に接続して来客携帯端末１００に受付画面を表示させるためのＵＲＬ情報を有する。

まず、図３のステップＳ２０１において、現在位置が訪問先企業の付近であるか否かを判断する。例えば、来客携帯端末１００を用いて二次元コード５０を読み込むと、来客携帯端末１００の処理手段１０２は、受付Ｗｅｂサーバ５００から受信したＷｅｂ情報に格納されているプログラムに従って、ＧＮＳＳ６００により検出された来客携帯端末１００の位置を示す情報と、図５（ａ）に示される受付設定画面にて事前に設定された二次元コード５０の位置（緯度及び経度）を示す情報とを比較する。そして処理手段１０２が、来客携帯端末１００の位置と二次元コード５０の位置とが所定の距離よりも離れていると判定した場合、図３のフローに従う受付処理を行うことなく、本フローを終了する。図５（ｂ）は、位置検出処理の説明図である。これらの位置が所定の距離よりも離れているか否かは、例えば、事前に設定された二次元コード５０の位置（例えば、緯度：３８．０°、経度：１４０．０°）を中心として、来客携帯端末１００の位置が半径約Ｘｍ以内であるか否かにより判断される。

一方、処理手段１０２が、来客携帯端末１００の位置と二次元コード５０の位置とが所定の距離以内であると判定した場合、ステップＳ２０２に進む。このような位置情報に基づく処理を行うことにより、受付システム１０の二次元コードを設置場所とは別の場所に持ち出された場合等に、ユーザが呼び出しを受けることを防止することができる。また、来客携帯端末１００の履歴情報から来客が誤ってユーザを呼び出すことを防止することができる。なお本実施形態において、来客携帯端末１００から受信した来客携帯端末１００の位置を示す情報に基づき、サーバ２００の処理手段２０２や、受付Ｗｅｂサーバ５００の処理手段５０２が、来客携帯端末１００の位置と二次元コード５０の位置とが所定の距離以内であるかを判定しても良い。なお本実施形態において、ステップＳ２０１は必須ではなく、訪問先企業が事前に来客携帯端末１００の現在位置が訪問先企業の付近であるか否かを判断するように設定しているか否かに応じて、ステップＳ２０１を経るか省略するかを決定しても良い。

ステップＳ２０２において、受付Ｗｅｂサーバ５００の通信手段５０１は、記憶手段５０３に記憶されているＷｅｂ情報を来客携帯端末１００に送信する。そして来客携帯端末１００は、受付Ｗｅｂサーバ５００から受信したＷｅｂ情報に基づいて受付画面（Ｗｅｂページ）を表示する。続いてステップＳ２０３において、受付Ｗｅｂサーバ５００の処理手段５０２は、来客が受付方法としてパスコード入力を選択したか否かを判断する。具体的には、まず、来客携帯端末１００は、来客がどの受付方法を選択したのかについての情報を受付Ｗｅｂサーバ５００へ送信する。次に、受付Ｗｅｂサーバ５００の処理手段５０２が来客が受付方法としてパスコード入力を選択したと判断すると、受付Ｗｅｂサーバ５００は、パスコード入力画面を表示するためのＷｅｂ情報を来客携帯端末１００へ送信する。次に、来客携帯端末１００は、受付Ｗｅｂサーバ５００から受信したＷｅｂ情報に基づき、パスコード入力画面を表示する。

図７（ｃ）は、来客携帯端末１００に表示される受付画面の一例である。受付画面において、来客がパスコード入力を選択する場合には「アポイントありの方」を選択することにより、受付方法としてパスコード入力が選択されたと判断される。パスコード入力が選択された場合、ステップＳ２０４に進む。ステップＳ２０４において、来客は、パスコードを入力する。図７（ｄ）は、パスコード入力画面の一例である。図７（ｄ）に示されるように、来客携帯端末１００上に表示された画面にて例えば４ケタのパスコード（事前に発行されたパスコード）を来客が入力することができる。

続いてステップＳ２０５において、来客携帯端末１００は、入力されたパスコードを受付Ｗｅｂサーバ５００へ送信する。そしてサーバ２００の処理手段２０２は、受付Ｗｅｂサーバ５００から送信されたパスコードを受信し、必要に応じてデータベース２０５を参照しつつ、入力されたパスコードに関連付けられた来客情報及び訪問先情報を照合する。続いてステップＳ２０６において、サーバ２００の処理手段２０２は、入力されたパスコードが本日有効なパスコードであるか否かを判断する。パスコードが本日有効か否かは、入力されたパスコードが事前に登録されたパスコードであるか否か、及び、本日が例えば図６に示される画面で事前に入力された訪問日（来訪予定日）と一致するか否かにより判断される。本日有効なパスコードでない場合、ステップＳ２０４へ戻る。一方、本日有効なパスコードである場合、ステップＳ２０９に進む。本実施形態のようにパスコードに有効期間を設けることにより、パスコードの誤用を防ぐことができる。なお本実施形態において、パスコードの照合処理及びパスコードの有効性に関する判断処理はそれぞれ、サーバ２００の処理手段２０２で実行されるが、これに限定されるものではなく、パスコードの照合処理及びパスコードの有効性に関する判断処理の全て又は一部の処理を受付Ｗｅｂサーバ５００の処理手段５０２で実行しても良い。また、パスコードが本日有効なパスコードであるか否かの判断は、本日が来訪予定日よりも前の日や来訪予定日よりも後の日も含む一定の期間に含まれるか否かにより判断しても良い。また本実施形態において、パスコードに有効期間を設けることは必須ではなく、訪問先企業がステップＳ２０６において、パスコードが事前に登録されたパスコードであるか否かのみを判断するように設定しても良い。また、サーバ２００の処理手段２０２は、パスコードが本日有効なパスワードであると判断した後に、パスコードに関連付けられた来客情報及び訪問先情報の照合を行っても良い。

ステップＳ２０３にてパスコード入力が選択されなかった場合、ステップＳ２０７において、来客は、来客携帯端末１００を用いて訪問先を選択する。例えば、来客は図７（ｃ）に示される受付画面上で「その他の受付方法」として「担当者を検索」を選択する等して、訪問先を選択することができる。続いてステップＳ２０８において、来客は、来客携帯端末１００を用いて来客情報を入力し、ステップＳ２０９に進む。なお来客情報は、来客携帯端末１００の画面に表示されるソフトウェアキーボードを用いて来客が入力することができるが、これに限定されるものではなく、例えば、来客携帯端末１００のカメラを用いて来客により提示された名刺をスキャンして、ＯＣＲ技術により来客に関する情報を取得しても良い。このとき受付Ｗｅｂサーバ５００は、入力された訪問先及び来客情報をサーバ２００へ送信し、サーバ２００は、訪問先及び来客情報に基づいてデータベース２０５を参照する。又は、受付Ｗｅｂサーバ５００がデータベース２０５を参照するように構成しても良い。

ステップＳ２０９において、来客携帯端末１００の処理手段１０２は、訪問先担当者に通話を発信する。本実施形態において、サーバ２００は、来客携帯端末１００からパスコードの受信後又は来客情報の入力後、来客携帯端末１００による特別な操作を行うことなく通話の要求を受信する（図８（ｂ）参照）。具体的には、まず、パスコードが本日有効なパスコードであった場合、受付Ｗｅｂサーバ５００は、来客携帯端末１００に対して、パスコードが本日有効であり、かつユーザ端末３００への通話発信が可能であることの通知を送信する。次に、来客携帯端末１００は、前記通知を受信した後、来客による特別な操作を経ずに、サーバ２００に対して、訪問先担当者のユーザ端末３００への通話発信を要求する。次に、サーバ２００は、訪問先担当者のユーザ端末３００へ、着信通知を送信する。

続いてステップＳ２１０において、サーバ２００は、訪問先担当者が通話に応答したか否かを判断する。訪問先担当者が通話に応答した場合、ステップＳ２１１に進み、来客と訪問先担当者が通話を行う。本実施形態では、サーバ２００が来客携帯端末１００からパスコードの受信後に通話の要求を受信した場合、第１のユーザ端末は、ピア・ツー・ピア通信等により来客携帯端末１００との双方向通話を行うことができる。来客と訪問先担当者との通話が終了した後、ステップＳ２１２に進む。一方、ステップＳ２１０にて訪問先担当者が通話に応答しない場合、ステップＳ２１１をスキップしてステップＳ２１２に進む。来客携帯端末１００のＷｅｂブラウザで使用可能な通信方式を用いることにより、従来の来客用受付端末が有する来客と担当者との音声通話機能を、来客自身のスマートフォン等の来客携帯端末１００が代替して行うことができる。また、パスコードを用いることにより、来客と担当者が相手の携帯端末の電話番号を知る必要がない。

なお本実施形態において、ステップＳ２０９は必須ではなく、訪問先企業が事前に来客と訪問先担当者との双方向通話を行うように設定されているか否かに応じて、ステップＳ２０９を経るか省略するかを決定しても良い。図８（ａ）は、ステップＳ２０９の通話処理を省略した場合の来客携帯端末１００に表示される画面の一例である。図８（ｂ）は、ステップＳ２０９の通話処理を経る場合の来客携帯端末１００に表示される画面の一例である。通話処理を省略する場合、図８（ａ）に示されるように、パスコードの入力後、来客通知が送信され、受付完了画面が表示される。一方、通話処理を経る場合、図８（ｂ）に示されるように、パスコードの入力後、訪問先担当者に通話の要求が送信される。そして、担当者の呼び出し画面の表示後、通話中の画面が表示され、受付完了画面が表示される。

ステップＳ２１２において、受付Ｗｅｂサーバ５００は、サーバ２００へ来客通知の実行要求を送信する。そしてステップＳ２１３において、受付Ｗｅｂサーバ５００は、来客携帯端末１００に受付完了画面を表示し、本フローを終了する。

なお本実施形態において、受付Ｗｅｂサーバ５００が来客携帯端末１００からパスコードを受信した場合、又は、双方向通話が終了した場合、後述のように、サーバ２００は、第１のユーザ端末へ来客の訪問を通知するとともに、複数のユーザ端末３００のうち第１のユーザ端末以外の第２のユーザ端末へ来客の訪問を通知することもできる。例えば、訪問先担当者が通話に対応して、通話が終了した場合には、来客による特別な操作を経ずに、訪問先担当者や訪問先担当者以外の者が閲覧できるチャットツールに、担当者が通話の着信に応答した旨の来客通知を行うこともできる。一方、訪問先担当者が通話に対応しなかった場合には、来客による特別な操作を経ずに、訪問先担当者や訪問先担当者以外の者が閲覧できるチャットツールに、担当者が通話の着信に応答しなかった旨を表示するとともに、図４に示したサーバ２００による来客通知を行うことができる。なお、ステップＳ２０９を省略した場合には、図４に示したサーバ２００による来客通知が行われる。このとき、好ましくは、受付Ｗｅｂサーバ５００は、双方向通話が終了した直後、又は、第１のユーザ端末及び第２のユーザ端末への来客の訪問を通知した直後に、来客携帯端末１００に受付完了画面を表示させる。

（サーバ２００の処理）
次に、図４を用いて、受付システム１０のサーバ２００の処理（ステップＳ１０２）について詳述する。図４は、サーバ２００の処理を示すフローチャートである。図４のフローは、図３のステップＳ２１３にて来客携帯端末１００に受付完了画面が表示された後に実行される。なお、図３のステップＳ２１２にて受付Ｗｅｂサーバ５００からサーバ２００へ来客通知の実行要求を送信した後に、図４のフローが実行され、図４のステップＳ３１４にて担当者のユーザ端末３００へ通知が行われた後に、図３のステップＳ２１３にて来客携帯端末１００に受付完了画面を表示してもよい。また、本実施形態において、図３のステップＳ２０９にて訪問先担当者が通話に対応して、通話が終了した場合には、ステップＳ１０２を省略することができる。

まずステップＳ３０１において、サーバ２００は、通信手段２０１を介して、受付Ｗｅｂサーバ５００から来客通知の実行要求を受信する。続いてステップＳ３０２において、処理手段２０２は、例えば記憶手段２０３に格納されたデータベース２０５を参照して、訪問先企業等の担当者（担当者のユーザ端末３００）への通知手段（通知方法）を特定する。

続いてステップＳ３０３において、処理手段２０２は、ステップＳ３０２にて特定された通知方法がユーザ端末３００にインストールされたアプリへの通知であるか否かを判断する。ユーザ端末３００への通知方法がアプリへの通知である場合、ステップＳ３０４へ進む。ステップＳ３０４において、処理手段２０２は、ステップＳ３０１にて受信した来客情報を音声ファイル（音声データ）へ変換する。音声ファイルは、事前に登録された音声情報（固定の音声内容）としての音声ファイル（例えば、「××会社の＊＊様がお見えになりました」等）と、来客情報に応じて異なる音声ファイル（「××会社の＊＊様」のうち「××」及び「＊＊」）とを結合して生成される。これらの音声ファイルは、記憶手段２０３に記憶して予め登録しておくことができる。またこのとき、処理手段２０２は、来客情報と予め登録された表示情報（固定の表示内容）とに基づいて表示データを生成してもよい。ここで生成された音声データ及び表示データは、記憶手段２０３に記憶される。

このとき取得手段２０２ａは、来客携帯端末１００からの受信信号に基づいて、パスコードを入力する等により来客がアポイント有りであると判断される場合、処理手段２０２は、更に、アポイント有りの来客であることを通知するための音声データ又は表示データを生成しても良い。一方、パスコードの入力以外の方法で来客情報及び訪問先情報が取得された場合、処理手段２０２は、更に、アポイント無しの来客であることを通知するための音声データ又は表示データを生成しても良い。

続いてステップＳ３０５において、処理手段２０２は、ＷｅｂＲＴＣ（Ｗｅｂ Ｒｅａｌ－Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）によりユーザ端末３００にインストールされたアプリへ発信する。ここで、ＷｅｂＲＴＣは、ＷｅｂブラウザやモバイルアプリケーションにＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）経由でリアルタイム通信を提供するプロジェクトである。Ｗｅｂページ内で直接のピア・ツー・ピア（Ｐ２Ｐ）通信によって、プラグインのインストールやネイティブアプリのダウンロードを必要とせずに、Ｗｅｂブラウザ間の電話やチャット等が可能になる。なお本実施形態において、ＷｅｂＲＴＣは一例に過ぎず、ピア・ツー・ピア（Ｐ２Ｐ）通信を行う他の規格を用いても良い。

続いてステップＳ３１４において、通信手段２０１は、担当者のユーザ端末３００へ、アプリへの発信により来客の通知を行う。このように通信手段２０１は、ＷｅｂＲＴＣ等のピア・ツー・ピア通信により、記憶手段２０３に記憶された音声データをユーザ端末３００へ送信することにより、ユーザ端末３００への来客通知を行う。本実施形態において、通信手段２０１は、ステップＳ３０４にて生成された音声データを、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）により、音声を符号化および圧縮しパケットに変換したものをＩＰネットワークを介してリアルタイムで伝送する。また、ステップＳ３０４にて音声データに加えて表示データが生成されている場合、通信手段２０１は、音声データに加えて、記憶手段２０３に記憶された表示データをユーザ端末へ送信することにより、ユーザ端末３００への来客通知を行う。なお、表示データは、ピア・ツー・ピア通信に限定されるものではなく、ＨＴＴＰ通信などの他の通信方法により送信しても良い。

一方、ステップＳ３０３にてユーザ端末３００への通知方法がアプリへの通知ではない場合、ステップＳ３０６へ進む。ステップＳ３０６において、処理手段２０２は、ステップＳ３０２にて特定された通知方法が電話番号への通知であるか否かを判断する。通知方法が電話番号への通知である場合、ステップＳ３０７へ進む。ステップＳ３０７において、処理手段２０２は、ステップＳ３０１にて受信した来客情報を音声ファイルへ変換する。続いてステップＳ３０８において、通信手段２０１は、担当者のユーザ端末３００の電話番号へ発信する。これによりステップＳ３１４において、通信手段２０１は、担当者のユーザ端末３００へ、電話番号への通知により来客の通知を行う。

一方、ステップＳ３０６にてユーザ端末３００への通知方法が電話番号への通知ではない場合、ステップＳ３０９へ進む。ステップＳ３０９において、処理手段２０２は、ステップＳ３０２にて特定された通知方法がチャットツールへの通知であるか否かを判断する。通知方法がチャットツールへの通知である場合、ステップＳ３１０へ進む。ステップＳ３１０において、処理手段２０２は、ステップＳ３０１にて受信した来客情報をチャット形式へ変換する。続いてステップＳ３１１において、通信手段２０１は、担当者のユーザ端末３００へ、担当者が利用しているチャットツールへの通知を行う。これによりステップＳ３１４において、通信手段２０１は、担当者のユーザ端末３００へ、チャットツールへの通知により来客の通知を行う。

一方、ステップＳ３０９にてユーザ端末３００への通知方法がチャットツールへの通知ではない場合、ステップＳ３１２へ進む。ステップＳ３１２において、処理手段２０２は、ステップＳ３０１にて受信した来客情報をメール形式へ変換する。続いてステップＳ３１３において、通信手段２０１は、担当者のユーザ端末３００へ、担当者のメールアドレスへ来客通知を送信する。これによりステップＳ３１４において、通信手段２０１は、担当者のユーザ端末３００へ、メールへの通知により来客の通知を行う。

（複数のユーザ端末３００の処理）
次に、受付システム１０のユーザ端末３００の処理（ステップＳ１０３）について詳述する。図４のステップＳ３１４にて、サーバ２００から選択された通知方法で通知を受けた場合、ユーザ端末３００はその通知方法に応じた対応が可能となる。

また本実施形態において、複数のユーザ（複数のユーザ端末３００ａ～３００ｘ）が特定のルーム（グループ）に登録されている場合、このグループに登録されたユーザ同士で、ユーザ端末を用いてチャット（チャットルーム上）でのやり取り（通信）が可能である。ここでは、担当者のユーザ端末３００ａを第１のユーザ端末、グループに登録されている他のユーザ端末（グループに登録されている他の一つ又は全てのユーザ端末）３００ｂ～３００ｘを第２のユーザ端末という。

第１のユーザ端末は、サーバ２００から来客通知を受信してもユーザが応答しない場合、表示手段３０３に所定の表示データを履歴として表示する。ここで履歴表示のための表示データは、サーバ２００の処理手段２０２により、来客情報と記憶手段２０３に記憶された表示情報とに基づいて生成され、通信手段２０１を介してＨＴＴＰ通信により第１のユーザ端末へ送信される。また表示手段３０３は、第１のユーザ端末から第２のユーザ端末への対応要請情報が送信されても第２のユーザ端末の応答がない場合、第２のユーザ端末が応答しなかったことを示す情報を表示する。

なお本実施形態の受付システム１０において、来客が訪問先情報として一人の担当者を入力した場合や、ある担当者から発行されたパスコードを入力した場合において、その来客に対応する関係者が複数存在する場合や、担当者がまだ決まっていない場合も考えられる。このような場合、予め、来客に対する複数の関係者をグループ化して事前にデータベース２０５に登録しておくことにより、グループ化された複数の関係者の全員のユーザ端末３００に対して、来客の訪問を同時に通知することができる。すなわち、サーバ２００の判断手段（処理手段２０２の一部の機能）は、来客情報、及び一人の関係者に対応する訪問先情報に基づいて、データベース２０５を参照し、来客の訪問に対応すべき複数の関係者を含むグループに関する情報が存在するか否かを判断する。判断手段がグループが存在しないと判断した場合、通信手段２０１は、ピア・ツー・ピア通信により音声データを訪問先情報に基づく一人の関係者のユーザ端末３００へのみ発信することにより、一人の関係者のユーザ端末への来客通知を行う。一方、判断手段がグループが存在すると判断した場合、通信手段２０１は、ピア・ツー・ピア通信により音声データを訪問先情報に基づくグループに含まれる複数の関係者のユーザ端末へ発信することにより、複数の関係者のユーザ端末への来客通知を同時に行う。

従来の電話回線を利用した受付システムでは、電話帳に登録していない来客の訪問を受けた場合、その来客の氏名や会社名を通知することや表示することはできない。一方、本実施形態の受付システム１０は、ＷｅｂＲＴＣによりアプリへ音声データを発信することに加えて、ＨＴＴＰ通信により来客者のテキスト情報（表示データ）を発信することにより、電話帳に未登録の来客に関する表示データを、着信データ又は着信履歴としてユーザ端末の表示手段に表示することができる。

また、本実施形態の受付システム１０において、来客携帯端末１００において来客により入力された来客情報又はパスコードは、受付Ｗｅｂサーバ５００を介してサーバ２００に送信される。サーバ２００の処理手段２０２は、来客情報をデータベース２０５に登録する。すなわち来客情報（又はパスコードに関連付けられた来客情報）は、記憶手段２０３に蓄積して記憶され、通信手段２０１は、ユーザ端末３００からの要求に従って、記憶手段２０３から読み出された来客情報（必要な来客情報）をユーザ端末３００へ送信する。このように本実施形態の受付システム１０は、来客情報を自動的に収集して管理することができるため、従来のように来客名簿等を作成して管理する必要はない。また、来客の名刺を受領して記帳する工数もかからない。

また、来客が定期的に訪問するような場合、訪問の都度、担当者が出迎えにいく必要がない状況も考えられる。このような場合、本実施形態の受付システム１０は、来客が来客携帯端末１００において来客情報及び訪問先情報を入力した際に、サーバ２００は、受付Ｗｅｂサーバ５００を介して、担当者により予め登録されたウエルカムメッセージ等のメッセージ情報を来客携帯端末１００へ送信して表示させることができる。このメッセージ情報として、例えば、打ち合わせ場所を来客携帯端末１００に表示させた場合、来客は、担当者が出迎えることなく、打ち合わせ場所を知ることができる。すなわちサーバ２００の通信手段２０１は、来客情報及び訪問先情報に基づいて、記憶手段２０３に予め記憶されたメッセージ情報を来客携帯端末１００へ送信する。メッセージ情報は、来客携帯端末１００の画面（表示手段）に表示される情報であって、来客を打ち合わせ場所へ直接誘導するための情報を含む。このため本実施形態の受付システム１０によれば、担当者が来客を出迎えることなく、来客を打ち合わせ場所へ直接誘導することが可能である。

本実施形態によれば、受付システムを導入する訪問先企業等が来客用受付端末を設置することなく受付処理を行うことができる。また、電話回線を利用せずに音声データを担当者の携帯端末等に着信させることができる。

以上、本発明の好ましい実施形態について説明したが、本発明はこれに限定されるものではなく、その要旨の範囲内において種々の変形や変更が可能である。

例えば、本実施形態において、サーバ２００と受付Ｗｅｂサーバ５００の機能の少なくとも一部を互いに入れ替えてもよい。すなわち、受付Ｗｅｂサーバ５００による処理をサーバ２００で処理することや、逆に、サーバ２００による処理を受付Ｗｅｂサーバ５００で処理することも可能である。

また、本実施形態の受付システムは、サーバ２００と受付Ｗｅｂサーバ５００の２つのサーバを用いているが、これに限定されるものではなく、２つのサーバの機能の全て又は一部を１つの共通のサーバで実現するように構成しても良い。この場合、来客携帯端末１００は１つの共通のサーバと通信可能であり、２つのサーバ間の通信を行う必要はない。また、２つのサーバの機能を３つ以上のサーバを用いて実現するように構成しても良い。

また、本実施形態の受付システムは、来客自身の来客端末携帯を用いて二次元コードを読み取る方式（第１方式）のみを実行するが、第１方式と、特許文献１に開示されているような訪問先企業に設置された来客用受付端末を用いた方式（第２方式）とを併用する受付システムであっても良い。この場合、訪問先企業は、受付システムを設置する際に、第１方式又は第２方式のいずれの受付処理を採用するかを選択することができ、受付システムは、その選択に応じた制御を行うことが可能である。

１０ 受付システム
５０ 二次元コード
１００ 来客携帯端末
２００ サーバ（受付システムサーバ）
２０１ 通信手段
２０２ 処理手段
２０２ａ 取得手段
２０３ 記憶手段
２０４ プログラム
２０５ データベース
３００ ユーザ端末
５００ 受付Ｗｅｂサーバ（サーバ）
５０１ 通信手段
５０２ 処理手段
５０３ 記憶手段
５０４ プログラム
６００ ＧＮＳＳ

Claims (1)

1. サーバと、アプリケーションソフトがインストールされた複数のユーザ端末とがそれぞれインターネットを介して接続され、来客携帯端末を用いた受付処理が可能な受付システムであって、
   前記サーバは、
   前記インターネットを介して前記来客携帯端末および前記複数のユーザ端末との通信が可能な通信手段と、
   来客の受付に用いられるＷｅｂ情報を記憶する記憶手段と、
   処理手段と、を有し、
   前記通信手段は、
   前記来客の受付の際に前記来客携帯端末により所定の二次元コードが読み取られた場合、前記記憶手段に記憶されている前記Ｗｅｂ情報を前記来客携帯端末へ送信し、
   前記Ｗｅｂ情報に基づいて前記来客携帯端末に表示されたＷｅｂページ上で前記来客により入力されたパスコードを受信し、
   前記処理手段は、
   前記パスコードに関連付けられた来客情報及び訪問先情報を照合し、
   前記複数のユーザ端末のうち前記訪問先情報に基づく第１のユーザ端末へ前記来客の訪問を通知することを特徴とする受付システム。

Images