知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-07-01
(45)【発行日】2024-07-09
(54)【発明の名称】情報処理システム、情報処理方法及びプログラム
(51)【国際特許分類】
G06Q 50/10 20120101AFI20240702BHJP
G07C 9/20 20200101ALI20240702BHJP
G07C 9/27 20200101ALI20240702BHJP
【ＦＩ】
G06Q50/10
G07C9/20
G07C9/27
【請求項の数】
9
(21)【出願番号】P 2020012834
(22)【出願日】2020-01-29
(65)【公開番号】P2021117919
(43)【公開日】2021-08-10
【審査請求日】2022-11-29
(73)【特許権者】
【識別番号】506026449
【氏名又は名称】株式会社シャノン
(74)【代理人】
【識別番号】100126000
【弁理士】
【氏名又は名称】岩池 満
(74)【代理人】
【識別番号】100154748
【弁理士】
【氏名又は名称】菅沼 和弘
(74)【代理人】
【識別番号】100114557
【弁理士】
【氏名又は名称】河野 英仁
(74)【代理人】
【識別番号】100078868
【弁理士】
【氏名又は名称】河野 登夫
(72)【発明者】
【氏名】中村 健一郎
(72)【発明者】
【氏名】堀 譲治
【審査官】毛利 太郎
(56)【参考文献】
【文献】特開２０１２－０７３８９０（ＪＰ，Ａ）
【文献】国際公開第２０１８／１６３８２２（ＷＯ，Ａ１）
【文献】特開２０１０－１５２５９３（ＪＰ，Ａ）
【文献】特開２００１－２７３３２４（ＪＰ，Ａ）
【文献】特開２００６－０９９７８６（ＪＰ，Ａ）
【文献】特開２０１２－０５４７２８（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００ － ９９／００
Ｇ０７Ｃ ９／００ － ９／３８
(57)【特許請求の範囲】
【請求項1】
携帯端末と、イベントに来場する来場者に関する来場者情報を管理する管理装置とを有する情報処理システムであって、前記携帯端末は、
前記来場者の識別子である来場者ＩＤを、該来場者ＩＤを記述したコードから読み取る読取部と、
前記管理装置と通信可能か否かを判定する判定部と、
通信可能であると判定した場合、読み取った前記来場者ＩＤを前記管理装置に送信する送信部と、
通信不可能であると判定した場合、読み取った前記来場者ＩＤを記憶する記憶部とを備え、
前記判定部は、所定の時間間隔ごとに前記管理装置と通信可能か否かを再判定し、
通信可能であると判定した場合、前記送信部は、前記記憶部に記憶した未同期の前記来場者ＩＤを前記管理装置に送信し、
前記管理装置は、
前記来場者が前記イベントに来場する前に予め、前記来場者ＩＤと対応付けて前記来場者情報を記憶する第２記憶部と、
前記来場者ＩＤを前記携帯端末から受信した場合、受信した前記来場者ＩＤに基づいて来場を許可するか否かを判定する第２判定部と、
来場を許可すると判定した場合に前記来場者情報を前記携帯端末に送信する第２送信部とを備え、
前記携帯端末は、
前記管理装置から前記来場者情報を取得する取得部と、
前記取得部が取得した前記来場者情報を表示する表示部と
を備える情報処理システム。
【請求項2】
前記記憶部は、前記来場者ＩＤを読み取った読取時刻と対応付けて、読み取った前記来場者ＩＤ、及び前記管理装置との間の前記来場者ＩＤの同期状態を記憶し、前記表示部は、同期済みの前記来場者ＩＤと、前記未同期の前記来場者ＩＤとを識別可能に示す読取履歴画面を表示する
ことを特徴とする請求項１に記載の情報処理システム。
【請求項3】
前記携帯端末は、前記記憶部を参照して、前記未同期の前記来場者ＩＤの件数を集計する集計部を備え、前記表示部は、前記集計部が集計した前記未同期の前記来場者ＩＤの件数を表示する
ことを特徴とする請求項１又は２に記載の情報処理システム。
【請求項4】
前記携帯端末は、前記イベントが終了したか否かを判定する第３判定部と、
前記イベントが終了したと判定した場合、前記未同期の前記来場者ＩＤが前記記憶部に記憶されているか否かを判定する第４判定部とを備え、
前記送信部は、前記未同期の前記来場者ＩＤが記憶されていると判定した場合、前記未同期の前記来場者ＩＤを前記管理装置に送信する
ことを特徴とする請求項１から３までのいずれか一つに記載の情報処理システム。
【請求項5】
前記読取部はさらに、前記来場者に応じた要望を表す要望コードを読み取り、前記表示部は、前記要望コードを表示する
ことを特徴とする請求項１から４までのいずれか一つに記載の情報処理システム。
【請求項6】
前記管理装置は、複数の前記携帯端末夫々との間の通信状態を監視する監視部と、
前記携帯端末夫々との通信状態の一覧を出力する出力部と
を備える請求項１から５までのいずれかひとつに記載の情報処理システム。
【請求項7】
前記第２判定部は、前記携帯端末から新たに受信した前記来場者ＩＤが、既に来場を許可した受信済みの前記来場者の前記来場者ＩＤと重複するか否かを判定することを特徴とする請求項１から６のいずれか１項に記載の情報処理システム。
【請求項8】
携帯端末と、イベントに来場する来場者に関する来場者情報を管理する管理装置とが処理を実行する情報処理方法であって、前記携帯端末が、
前記来場者の識別子である来場者ＩＤを、該来場者ＩＤを記述したコードから読み取り、
前記管理装置と通信可能か否かを判定し、
通信可能であると判定した場合、読み取った前記来場者ＩＤを前記管理装置に送信し、
通信不可能であると判定した場合、読み取った前記来場者ＩＤを記憶部に記憶し、
所定の時間間隔ごとに前記管理装置と通信可能か否かを再判定し、
通信可能であると判定した場合、前記記憶部に記憶した前記来場者ＩＤを前記管理装置に送信し、
前記管理装置が、
前記来場者が前記イベントに来場する前に予め、前記来場者ＩＤと対応付けて前記来場者に関する来場者情報を記憶している場合において、
前記来場者ＩＤを前記携帯端末から受信した場合、受信した前記来場者ＩＤに基づいて来場を許可するか否かを判定し、
来場を許可すると判定した場合に、前記来場者ＩＤと対応付けて前記来場者情報を前記携帯端末に送信し、
前記携帯端末は、
前記管理装置から前記来場者情報を取得し、
取得した前記来場者情報を表示部に表示する
処理を実行させる情報処理方法。
【請求項9】
イベントに来場する来場者の識別子である来場者ＩＤを、該来場者ＩＤを記述した来場者用のコードから読み取り、前記来場者が前記イベントに来場する前に予め、前記来場者ＩＤと対応付けて前記来場者に関する来場者情報を記憶している管理装置と、ネットワークを経由して通信可能か否かを判定し、
通信可能であると判定した場合、読み取った前記来場者ＩＤを前記管理装置に送信して前記来場者情報を取得し、
通信不可能であると判定した場合、読み取った前記来場者ＩＤを記憶部に記憶し、
所定の時間間隔ごとに前記管理装置と通信可能か否かを再判定し、
通信可能であると判定した場合、前記記憶部に記憶した未同期の前記来場者ＩＤを前記管理装置に送信して前記来場者情報を取得する
処理をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理システム、情報処理方法及びプログラムに関する。
【背景技術】
【0002】
施設やイベント会場に来場者が来場する際に、来場者識別用のコードを用いて受付を行う技術がある。例えば特許文献１には、来場者が持参した書状に印刷された来場者識別コードを読み込み、読込んだ来場者識別コードを来場者データベースに登録する来場管理システムが開示されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２００６－９９７８６号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、特許文献１に係る発明は、ネットワークの接続トラブルまたは不安定な通信状態が発生した場合などに、受付を行うことができない恐れがある。
【0005】
一つの側面では、来場者の受付を好適に行うことが可能な情報処理システム等を提供することにある。
【課題を解決するための手段】
【0006】
一つの側面に係る情報処理システムは、携帯端末と、イベントに来場する来場者に関する来場者情報を管理する管理装置とを有する情報処理システムであって、前記携帯端末は、前記来場者の識別子である来場者ＩＤを、該来場者ＩＤを記述したコードから読み取る読取部と、前記管理装置と通信可能か否かを判定する判定部と、通信可能であると判定した場合、読み取った前記来場者ＩＤを前記管理装置に送信する送信部と、通信不可能であると判定した場合、読み取った前記来場者ＩＤを記憶する記憶部とを備え、前記判定部は、所定の時間間隔ごとに前記管理装置と通信可能か否かを再判定し、通信可能であると判定した場合、前記送信部は、前記記憶部に記憶した未同期の前記来場者ＩＤを前記管理装置に送信し、前記管理装置は、前記来場者ＩＤと対応付けて前記来場者情報を記憶する第２記憶部と、前記来場者ＩＤを前記携帯端末から受信した場合、受信した前記来場者ＩＤに基づいて来場を許可するか否かを判定する第２判定部と、来場を許可すると判定した場合に前記来場者情報を前記携帯端末に送信する第２送信部とを備え、前記携帯端末は、前記管理装置から前記来場者情報を取得する取得部と、前記取得部が取得した来場者情報を表示する表示部とを備える。
【発明の効果】
【0007】
一つの側面では、来場者の受付を好適に行うことができる。
【図面の簡単な説明】
【0008】
【図1】来場者受付システムの概要を示す説明図である。
【図2】サーバの構成例を示すブロック図である。
【図3】イベントＤＢのレコードレイアウトの一例を示す説明図である。
【図4】来場者管理ＤＢのレコードレイアウトの一例を示す説明図である。
【図5】来場者ＤＢのレコードレイアウトの一例を示す説明図である。
【図6】端末の構成例を示すブロック図である。
【図7】読取履歴ＤＢのレコードレイアウトの一例を示す説明図である。
【図8】来場者情報表示用ＤＢのレコードレイアウトの一例を示す説明図である。
【図9】来場者受付システムの処理動作を示す機能ブロック図である。
【図10】イベントに来場する来場者を登録する際の処理手順を示すフローチャートである。
【図11】イベントに来場した来場者を受け付ける際の処理手順を示すフローチャートである。
【図12】イベントに来場した来場者を受け付ける際の処理手順を示すフローチャートである。
【図13】サーバと通信可能か否かを判定するサブルーチンの処理手順を示すフローチャートである。
【図14】来場者の受付画面の一例を示す説明図である。
【図15】読取履歴画面の一例を示す説明図である。
【図16】未同期の来場者ＩＤのアラート表示に関する説明図である。
【図17】イベントが終了した場合に未同期の来場者ＩＤを一括送信する際の処理手順を示すフローチャートである。
【図18】実施形態３の来場者ＤＢのレコードレイアウトの一例を示す説明図である。
【図19】要望コード及び来場者情報を表示する際の処理手順を示すフローチャートである。
【図20】実施形態４のサーバの構成例を示すブロック図である。
【図21】端末監視ＤＢのレコードレイアウトの一例を示す説明図である。
【図22】通信状態の一覧画面の一例を示す説明図である。
【図23】端末との通信状態の一覧を出力する際の処理手順を示すフローチャートである。
【図24】未同期の来場者ＩＤを最終確認するアラート表示に関する説明図である。
【図25】未同期の来場者ＩＤを最終確認する際の処理手順を示すフローチャートである。
【発明を実施するための形態】
【0009】
以下、本発明をその実施形態を示す図面に基づいて詳述する。
【0010】
（実施形態１）
実施形態１は、来場者に事前に配布した識別用のコードを用いて、イベントに来場する来場者の受付を行う形態に関する。図１は、来場者受付システムの概要を示す説明図である。本実施形態のシステムは、管理装置１及び携帯端末２を含み、各装置はインターネット等のネットワークＮを介して情報の送受信を行う。
実施形態１は、来場者に事前に配布した識別用のコードを用いて、イベントに来場する来場者の受付を行う形態に関する。図１は、来場者受付システムの概要を示す説明図である。本実施形態のシステムは、管理装置１及び携帯端末２を含み、各装置はインターネット等のネットワークＮを介して情報の送受信を行う。
【0011】
管理装置１は、種々の情報に対する処理、記憶及び送受信を行う情報処理装置である。管理装置１は、例えばサーバ装置、パーソナルコンピュータ等である。本実施形態において、管理装置１はサーバ装置であるものとし、以下では簡潔のためサーバ１と読み替える。
【0012】
携帯端末２は、イベントに来場する来場者の識別子である来場者ＩＤを記述した来場者用のコードの読取、及び当該コードから読み取った来場者ＩＤのサーバ１への送信を行う端末装置である。携帯端末２は、例えばスマートフォン、タブレット等の情報処理機器である。または、携帯端末２は、コードを読み取り可能な専用の読取モジュールが設けされた端末装置であっても良い。以下では簡潔のため、携帯端末２を端末２と読み替える。
【0013】
例えば端末２は、複数の出展者がブースを出展する展示イベントのように、複数のサブイベント（ブース）が行われるイベントにおいて、来場者の来場をチェックすべく、コードの読取を行う。なお、イベントは展示イベントに限定されず、例えば講演会や音楽ライブなど、その他のイベントであってもよい。端末２は、例えばイベントの主催者、あるいはイベント会場内の個々のブースに出展する出展者が操作し、イベント会場に設置されている所定の受付窓口や、個々のブースにおいてコードの読取を行う。例えば端末２は、イベント開催時にイベント主催者の担当者や個々のサブイベントの開催者（出展者）に貸し出され、イベント終了後に返却される。
【0014】
サーバ１は、イベントに来場する来場者（申込者）に関する情報を来場者ＩＤと対応付けて予め登録（記憶）してあり、来場者ＩＤを記述した来場者用のコードを来場者に事前に発行する。端末２は、サーバ１が来場者に発行した来場者用のコードから来場者ＩＤを読み取り、ネットワークＮを経由してサーバ１に送信する。
【0015】
本実施の形態で端末２は、来場者ＩＤを読み取った際に、例えばイベント会場内のアクセスポイントに不具合が生じている場合など、サーバ１に来場者ＩＤを送信できない場合、来場者ＩＤを一時的に記憶する。そして端末２は、通信が復旧し次第、来場者ＩＤを送信してサーバ１と同期し、当該来場者ＩＤに対応する来場者情報を取得する。
【0016】
なお、本実施形態で「同期」とは、端末２からサーバ１に来場者ＩＤを送信するだけでなく、後述のように、当該来場者ＩＤの送信に対してサーバ１から返信される筈のデータ（後述の判定結果及び来場者情報）を未取得の状態も含み得る。この点について、詳細は後述する。
【0017】
図２は、サーバ１の構成例を示すブロック図である。サーバ１は、制御部１１、記憶部１２、通信部１３、入力部１４、表示部１５、読取部１６及び大容量記憶部１７を含む。各構成はバスＢで接続されている。
【0018】
制御部１１はＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を含み、記憶部１２に記憶された制御プログラム１Ｐを読み出して実行することにより、サーバ１に係る種々の情報処理、制御処理等を行う。なお、図２では制御部１１を単一のプロセッサであるものとして説明するが、マルチプロセッサであっても良い。
【0019】
記憶部１２はＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等のメモリ素子を含み、制御部１１が処理を実行するために必要な制御プログラム１Ｐ又はデータ等を記憶している。また、記憶部１２は、制御部１１が演算処理を実行するために必要なデータ等を一時的に記憶する。通信部１３は通信に関する処理を行うための通信モジュールであり、ネットワークＮを介して、端末２等との間で情報の送受信を行う。
【0020】
入力部１４は、マウス、キーボード、タッチパネル、ボタン等の入力デバイスであり、受け付けた操作情報を制御部１１へ出力する。表示部１５は、液晶ディスプレイ又は有機ＥＬ（electroluminescence）ディスプレイ等であり、制御部１１の指示に従い各種情報を表示する。
【0021】
読取部１６は、ＣＤ（Compact Disc）－ＲＯＭ又はＤＶＤ（Digital Versatile Disc）－ＲＯＭを含む可搬型記憶媒体１ａを読み取る。制御部１１が読取部１６を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、大容量記憶部１７に記憶しても良い。また、ネットワークＮ等を介して他のコンピュータから制御部１１が制御プログラム１Ｐをダウンロードし、大容量記憶部１７に記憶しても良い。さらにまた、半導体メモリ１ｂから、制御部１１が制御プログラム１Ｐを読み込んでも良い。
【0022】
大容量記憶部１７は、例えばＨＤＤ（Hard disk drive:ハードディスク）、ＳＳＤ(Solid State Drive:ソリッドステートドライブ)等の記録媒体を備える。大容量記憶部１７は、イベントＤＢ（データベース：database）１７１、来場者管理ＤＢ１７２及び来場者ＤＢ１７３を含む。イベントＤＢ１７１は、イベントに関する情報を記憶している。来場者管理ＤＢ１７２は、イベントに来場する来場者を管理する管理情報を記憶している。来場者ＤＢ１７３は、来場者に関する情報を記憶している。
【0023】
なお、本実施形態において記憶部１２及び大容量記憶部１７は一体の記憶装置として構成されていても良い。また、大容量記憶部１７は複数の記憶装置により構成されていても良い。更にまた、大容量記憶部１７はサーバ１に接続された外部記憶装置であっても良い。
【0024】
なお、本実施形態では、サーバ１は一台の情報処理装置であるものとして説明するが、複数台により分散して処理させても良く、または仮想マシンにより構成されていても良い。
【0025】
図３は、イベントＤＢ１７１のレコードレイアウトの一例を示す説明図である。イベントＤＢ１７１は、イベントＩＤ列、イベント名列、プログラム列、開催場所列、開催日列、開催開始時間列、開催終了時間列、申込開始日時列、申込終了日時列、受付開始時間列、受付終了時間列、サブイベントＩＤ列、サブイベント名称列を含む。
【0026】
イベントＩＤ列は、各イベントを識別するために、一意に特定されるイベントのＩＤを記憶している。イベント名列は、イベントの名称を記憶している。プログラム列は、イベントのプログラム（内容）を記憶している。開催場所列は、イベントを開催する場所を記憶している。開催日列は、イベントを開催する日を記憶している。
【0027】
開催開始時間列は、イベントの開催の開始時間を記憶している。開催終了時間列は、イベントの開催の終了時間を記憶している。申込開始日時列は、イベントを申し込む開始日時を記憶している。申込終了日時列は、イベントを申し込む終了日時を記憶している。受付開始時間列は、イベントを受け付ける開始時間を記憶している。受付終了時間列は、イベントを受け付ける終了時間を記憶している。
【0028】
サブイベントＩＤ列は、イベント内のサブイベント（例えば出展ブース）を一意に特定するサブイベントＩＤを記憶している。サブイベント名称列は、サブイベントの名称を記憶している。
【0029】
図４は、来場者管理ＤＢ１７２のレコードレイアウトの一例を示す説明図である。来場者管理ＤＢ１７２は、イベントＩＤ列、来場者ＩＤ列、申込状態列、受付状態列、サブイベントＩＤ列を含む。イベントＩＤ列は、イベントを特定するイベントＩＤを記憶している。来場者ＩＤ列は、来場者を特定する来場者ＩＤを記憶している。申込状態列は、イベント来場の申し込み状態を記憶している。申込状態列には、例えば「申込済み」、「キャンセル」等が記憶される。受付状態列は、来場者の受付状態を記憶している。受付状態列には、例えば「来場済み」、「未受付」等が記憶される。サブイベントＩＤ列は、来場者が来場済みのサブイベントを特定するサブイベントＩＤを記憶している。
【0030】
図５は、来場者ＤＢ１７３のレコードレイアウトの一例を示す説明図である。来場者ＤＢ１７３は、来場者ＩＤ列、イベントＩＤ列、サブイベントＩＤ列、来場者名列、来場者人数列、会社列、属性列及びメールアドレス列を含む。来場者ＩＤ列は、各来場者を識別するために、一意に特定される来場者のＩＤを記憶している。イベントＩＤ列は、イベントを特定するイベントＩＤを記憶している。サブイベントＩＤ列は、来場者が来場するサブイベントを特定するサブイベントＩＤを記憶している。来場者名列は、来場者の名前を記憶している。また、一つの来場者ＩＤを複数の来場者（複数人）が同時に利用することができる。
【0031】
来場者人数列は、一つの来場者ＩＤに応じて、イベントに来場した人数を記憶している。会社列は、来場者が勤務している会社の名称を記憶している。属性列は、来場者の属性に応じた属性情報を記憶している。属性情報は、例えばイベントが製品の展示会である場合、「ＶＩＰ（Very Important Person）会員」、「製品Ａ購入顧客」等で表現され得る。メールアドレス列は、来場者と連絡用のメールアドレスを記憶している。
【0032】
なお、上述した各ＤＢの記憶形態は一例であり、データ間の関係が維持されていれば、他の記憶形態であっても良い。
【0033】
図６は、端末２の構成例を示すブロック図である。端末２は、制御部２１、記憶部２２、通信部２３、入力部２４、表示部２５、時計部２６、補助記憶部２７、撮影部２８及びコード読取部２９を含む。各構成はバスＢで接続されている。
【0034】
制御部２１はＣＰＵ、ＭＰＵ等の演算処理装置を含み、記憶部２２に記憶された制御プログラム２Ｐを読み出して実行することにより、端末２に係る種々の情報処理、制御処理等を行う。なお、図６では制御部２１を単一のプロセッサであるものとして説明するが、マルチプロセッサであっても良い。記憶部２２はＲＡＭ、ＲＯＭ等のメモリ素子を含み、制御部２１が処理を実行するために必要な制御プログラム２Ｐ又はデータ等を記憶している。また、記憶部２２は、制御部２１が演算処理を実行するために必要なデータ等を一時的に記憶する。
【0035】
通信部２３はワイヤレス無線ＷＡＮ（Wide Area Network）を利用して通信に関する処理を行うための通信モジュールであり、ネットワークＮを介して、サーバ１等と情報の送受信を行う。無線ＷＡＮは、通信規格４Ｇ(Generation)若しくは５ＧであるＬＴＥ(Long Term Evolution)等の携帯電話回線を通じて事業者の通信網に接続するためのネットワークであり、契約者に提供される。入力部２４は、キーボード、マウスまたは表示部２５と一体化したタッチパネルでも良い。表示部２５は、液晶ディスプレイ又は有機ＥＬディスプレイ等であり、制御部２１の指示に従い各種情報を表示する。
【0036】
時計部２６は、時刻又は経過時間等を計時しており、制御部２１からの求めに応じて、計時結果を制御部２１に与える回路である。また、時計部２６はタイマ機能を提供する。タイマ機能は開始を指示されてから、予め設定した時間が経過した場合、その旨を制御部２１に通知する機能である。又は、タイマ機能は開始を指示されてから、予め設定した時間が経過したか否かを、制御部２１からの問い合わせに対して回答する機能である。
【0037】
補助記憶部２７は、例えばＨＤＤ、ＳＳＤ等の記録媒体を備える。補助記憶部２７は、読取履歴ＤＢ２７１及び来場者情報表示用ＤＢ２７２を含む。読取履歴ＤＢ２７１は、来場者ＩＤを記述したコードから読み取った履歴情報を記憶している。来場者情報表示用ＤＢ２７２は、イベントに来場する来場者に関する来場者情報を記憶している。なお、本実施形態において記憶部２２及び補助記憶部２７は一体の記憶装置として構成されていても良い。また、補助記憶部２７は複数の記憶装置により構成されていても良い。更にまた、補助記憶部２７は端末２に接続された外部記憶装置であっても良い。
【0038】
撮影部２８は、例えばＣＣＤ(Charge Coupled Device)カメラ、ＣＭＯＳ（Complementary Metal Oxide Semiconductor）カメラ等の撮影装置である。なお、撮影部２８は、複数の撮影装置により構成されても良い。なお、撮影部２８は端末２に内蔵せず、外部で直接に端末２と接続し、撮影可能な構成としても良い。コード読取部２９は、２次元コード、１次元コード等を読み取るための読取専用モジュールである。なお、コードの読取については後述する。
【0039】
図７は、読取履歴ＤＢ２７１のレコードレイアウトの一例を示す説明図である。読取履歴ＤＢ２７１は、イベントＩＤ列、来場者ＩＤ列、来場日時列及び状態列を含む。イベントＩＤ列は、イベントを特定するイベントＩＤを記憶している。来場者ＩＤ列は、来場者を特定する来場者ＩＤを記憶している。来場日時列は、来場者がイベントに来場した日時情報を記憶している。
【0040】
状態列は、コードから読み取った来場者ＩＤの同期状態を記憶している。同期状態は、例えば「送信済み」、「未送信」、「送信エラー」及び「読取エラー」状態で表される。「送信済み」状態は、来場者ＩＤをサーバ１に送信して来場者情報を取得した同期済みの状態である。「未送信」状態は、通信不可能と判定したことにより来場者ＩＤを未送信の状態である。「送信エラー」状態は、送信時に回線不調等が発生し、送信に失敗した状態である。「読取エラー」状態は、不正な来場者コードであることを表す。
【0041】
図８は、来場者情報表示用ＤＢ２７２のレコードレイアウトの一例を示す説明図である。来場者情報表示用ＤＢ２７２は、来場者ＩＤ列、会社名称列、来場者名列、来場者人数列及び属性列を含む。来場者ＩＤ列は、来場者を特定する来場者ＩＤを記憶している。会社名称列は、来場者が勤務している会社の名称を記憶している。来場者名列は、来場者の名前を記憶している。来場者人数列は、一つの来場者ＩＤに応じて、イベントに来場した人数を記憶している。属性列は、来場者の属性に応じた属性情報を記憶している。
【0042】
なお、上述した各ＤＢの記憶形態は一例であり、データ間の関係が維持されていれば、他の記憶形態であっても良い。
【0043】
図９は、来場者受付システムの処理動作を示す機能ブロック図である。先に、サーバ１が行う来場者（申込者）の登録及び来場者用のコードの発行処理を説明する。サーバ１は、イベントに来場する来場者に関する情報を来場者ＩＤと対応付けて予め来場者ＤＢ１７３に登録してある。具体的には、サーバ１は、来場者ＩＤを割り振って、イベントＩＤ、来場者の名前、来場者人数、会社、属性情報（例えば、ＶＩＰ等）及びメールアドレスを一つのレコードとして来場者ＤＢ１７３に記憶している。
【0044】
サーバ１は、来場者ＩＤを記述した来場者用のコードを来場者に発行する。コードは、例えば、２次元コード、１次元コード等である。２次元コードは、横方向にしか情報を持たない１次元コードに対し、水平方向と垂直方向に情報を持つ表示方式のコードである。代表的な２次元コードは、例えばＱＲコード（登録商標）、ＤａｔａＭａｔｒｉｘ（登録商標）又はＶｅｒｉＣｏｄｅ（登録商標）である。１次元コードは、例えばバーコードである。本実施の形態では一例として、２次元コードを読み取るものとして説明する。
【0045】
具体的には、サーバ１は、イベントＩＤに基づき、二次元コードを発行する対象となる来場者の来場者ＩＤを来場者ＤＢ１７３から取得する。サーバ１は、二次元コードの生成ライブラリを利用し、来場者ＩＤを含む来場者用の二次元コードを生成する。なお、二次元コードの中に埋め込まれる項目は、上述した来場者ＩＤに限らず、実際のニーズに応じて任意の項目が設定されても良い。
【0046】
サーバ１は、イベントＩＤに対応付けて、来場者ＩＤ、申込状態及び受付状態を一つのレコードとして来場者管理ＤＢ１７２に記憶する。なお、来場者の初期登録の場合、受付状態列に「未受付」が記憶される。
【0047】
サーバ１は、生成した来場者用の二次元コードを該当する来場者に送信する。なお、来場者用の二次元コードをメール、ＳＮＳ（Social Networking Service）またはＳＭＳ（Short Message Service）等を利用して来場者に送信しても良い。または、来場者用の二次元コードを印刷して郵送等により来場者に送付しても良い。
【0048】
続いて、端末２においてイベントに来場した来場者を受け付ける処理を説明する。まず、端末２は、来場者用の二次元コードを読み取る。端末２は、二次元コードの解析ライブラリを利用し、読み取った二次元コードから来場者ＩＤを取得する。
【0049】
次に、端末２は、サーバ１と通信可能か否かを判定する。具体的には、端末２は、端末２の中の制御プログラム２Ｐの一つの機能である接続回線取得ＡＰＩ（Application Programming Interface）を利用して、ネットワークＮの通信状態に関する情報を取得する。接続回線は、通信規格４Ｇ若しくは５ＧであるＬＴＥ通信回線、または、Ｗｉ－Ｆｉ（登録商標）等の無線通信回線を含む。端末２は、ネットワークＮの通信状態に応じて、サーバ１と通信可能であるか否かを判定する。
【0050】
例えば端末２は、通信状態に関する情報として、接続回線の種類、該接続回線の電波の受信レベルなどのデータを取得する。電波の受信レベルは、スマートフォン、携帯電話またはデータ通信端末等をネットワークＮに接続し、端末の置かれた位置の電波の受信状態を確認するための情報である。電波の受信レベルは、例えば圏外、レベル０、レベル１、レベル２及びレベル３を含み、順次に電波の強度が強くなる。
【0051】
例えば、端末２は、取得した電波の受信レベルが圏外である場合、通信不可能であると判定する。端末２は、取得した電波の受信レベルがレベル０である場合、通信が不安定になっている可能性が高いため、通信不可能であると判定しても良い。端末２は、取得した電波の受信レベルがレベル１～３である場合、ネットワークＮに通信可能であると判定する。
【0052】
端末２は、通信可能であると判定した場合、二次元コードから読み取った来場者ＩＤをサーバ１に送信する。サーバ１は、端末２から送信された来場者ＩＤを受信する。サーバ１は、受信した来場者ＩＤに基づき、来場を許可するか否かを判定する。
【0053】
先ず、サーバ１は、来場者がイベントへの参加を申し込んだか否かを判定する。具体的には、サーバ１は、来場者ＩＤ及びイベントＩＤに基づき、来場者管理ＤＢ１７２から該来場者の申込状態を取得する。サーバ１は、取得した申込状態が「申込済み」であると判定した場合、来場者がイベントの参加に申し込んだと判定する。サーバ１は、取得した申込状態が「申込済み」以外であると判定した場合、来場者をイベントの参加に申し込んでいないと判定する。
【0054】
次に、サーバ１は、重複来場であるか否かを判定する。具体的には、来場者ＩＤ及びイベントＩＤに基づき、来場者管理ＤＢ１７２から該来場者の受付状態を取得する。サーバ１は、取得した受付状態が「来場済み」であると判定した場合、重複来場であると判定する。サーバ１は、取得した受付状態が「未申込」であると判定した場合、重複来場でないと判定する。
【0055】
サーバ１は、来場者がイベントへの参加を申込済みであり、かつ、重複来場でないと判定した場合、来場を許可すると判定する。この場合、サーバ１は、来場者ＩＤに基づき、来場者ＤＢ１７３から来場者情報を取得する。来場者情報は、来場者が属する会社名称、来場者の名前、来場者人数及び来場者の属性（例えば、ＶＩＰ会員、製品Ａ購入顧客等）を含む。サーバ１は、イベントＩＤ及び来場者ＩＤに基づき、来場者管理ＤＢ１７２の受付状態列を「来場済み」に更新する。サーバ１は、取得した来場者情報を端末２に送信する。
【0056】
なお、本実施の形態では来場者が事前に申込を行っているか否かをチェックするものとするが、一連の判定処理において、申込の有無は判定せずともよい。この場合、例えばサーバ１は、重複来場であるか否かのみを判定し、申込の有無については判定処理をスキップする。このように、申込の有無を判定する構成は必須ではない。
【0057】
端末２は、サーバ１から送信された来場者情報を受信して表示する。端末２は、二次元コードの読取履歴を読取履歴ＤＢ２７１に記憶する。具体的には、端末２は、来場日時（来場者ＩＤを読み取った読取時刻）に対応付けて、イベントＩＤ、来場者ＩＤ及び「送信済み」状態を一つのレコードとして読取履歴ＤＢ２７１に記憶する。端末２は、来場者情報を来場者情報表示用ＤＢ２７２に記憶する。具体的には、端末２は、来場者ＩＤ、会社名称、来場者名、来場者人数及び属性を一つのレコードとして来場者情報表示用ＤＢ２７２に記憶する。
【0058】
サーバ１は、来場者がイベントへの参加を申込済みでない、または重複来場であると判定した場合、来場を許可しないと判定する。この場合、サーバ１は来場者情報を端末２に送信せず、来場を許可しない旨の読取エラーメッセージを端末２に送信する。端末２は、サーバ１から送信された読取エラーメッセージに応じて、来場者ＩＤの送信状態を「読取エラー」として二次元コードの読取履歴を読取履歴ＤＢ２７１に記憶する。具体的には、端末２は、来場日時に対応付けて、イベントＩＤ、来場者ＩＤ及び「読取エラー」状態を一つのレコードとして読取履歴ＤＢ２７１に記憶する。上記の処理によって、サーバ１及び端末２は来場者ＩＤに基づく同期を行い、来場を許可するか否かの判定結果と、来場を許可された来場者の来場者情報とを共有する。
【0059】
一方で、ネットワークＮの通信状態に応じてサーバ１と通信不可能であると判定した場合、端末２は、二次元コードから読み取った来場者ＩＤ（未同期の来場者ＩＤ）を読取履歴ＤＢ２７１に記憶する。具体的には、端末２は、来場日時に対応付けて、イベントＩＤ、来場者ＩＤ及び「未送信」状態を一つのレコードとして読取履歴ＤＢ２７１に記憶する。
【0060】
未送信の来場者ＩＤをサーバ１に再送信するため、端末２はタイマを起動して経過時間を計算する。端末２は、所定の時間間隔（例えば、１０秒）を経過したと判断した場合、サーバ１と通信可能か否かを再判定する。端末２は、サーバ１と通信可能であると判定した場合、来場者ＩＤをサーバ１に再送信する。なお、通信の再判定処理及び来場者ＩＤの再送信処理に関しては、上述した処理と同様であるため、説明を省略する。
【0061】
このように、端末２は、通信状態の悪化などの理由でサーバ１に来場者ＩＤを送信できない場合に、「未送信」として来場者ＩＤを一時的に記憶し、通信が復旧し次第、送信を再開する。これにより、例えばイベント会場によっては通信状態が悪い場合などであっても、来場者の受付を滞りなく行うことができる。
【0062】
なお、上記ではネットワークＮの通信状態に応じてサーバ１に来場者ＩＤが送信できない場合を説明したが、例えばサーバ１自体がダウンするなど、通信状態以外の原因でサーバ１との通信を行うことができない場合もあり得る。そこで端末２は、上記の通信状態の判定以外に、サーバ１からの返信の有無（判定結果の受信の有無）に応じて来場者ＩＤを一時記憶し、サーバ１に再送信する処理も並行して行う。
【0063】
例えば端末２はタイマを起動して、来場者ＩＤを送信してから所定の時間間隔（例えば、５秒）が経過したか否かを判定する。端末２は、所定の時間間隔が経過し、かつ、サーバ１に送信した来場者ＩＤに対応する判定結果及び来場者情報をサーバ１から受信していないと判定した場合、来場者ＩＤの送信状態を「送信エラー」として二次元コードの読取履歴を読取履歴ＤＢ２７１に記憶する。具体的には、端末２は、来場日時に対応付けて、イベントＩＤ、来場者ＩＤ及び「送信エラー」状態を一つのレコードとして読取履歴ＤＢ２７１に記憶する。
【0064】
その後、端末２は、上記の送信間隔よりも長い所定の時間間隔（例えば１時間）が経過した場合、「エラー」とした来場者ＩＤをサーバ１に再送信する。そして端末２は判定結果及び来場者情報をサーバ１から受信したか否かを再判定し、「エラー」の状態が継続する限り来場者ＩＤを再送信する。このように、端末２は、ネットワークＮの通信状態が原因で未同期となっている来場者ＩＤだけでなく、サーバ１側の原因で未同期となっている来場者ＩＤを特定し、当該来場者ＩＤを送信して同期を行う。来場者ＩＤの同期に成功した場合、端末２は、イベントＩＤ及び来場者ＩＤに基づき、読取履歴ＤＢ２７１の状態列を「送信済み」に更新する。サーバ１は、イベントＩＤ及び来場者ＩＤに基づき、来場者管理ＤＢ１７２の受付状態列を「来場済み」に更新する。これにより、通信状態以外の原因で未同期となっている来場者ＩＤも好適に処理することができる。
【0065】
イベントに来場した来場者は、イベント会場に設置されている所定の受付窓口にて上記の二次元コードの読取を行い、来場の認証を受けてイベント会場に入場する。その後、来場者は個々のサブイベント（例えば出展ブース）に参加する。ここで、各サブイベントの開催者（出展者）もイベント主催者から端末２の貸し出しを受け、二次元コードの読取を行う。なお、各サブイベントにおいても来場者の認証を行っても良いが、上述の如く受付窓口において来場者の認証が完了しているため、各サブイベントでは来場者ＩＤに基づく認証は行わない。二次元コードの読取を行った場合、来場者ＩＤ及びサブイベントＩＤと紐付けてサブイベントへの来場履歴が来場者管理ＤＢ１７２にレコードされる（図４参照）。
【0066】
本実施の形態においてサーバ１は、来場者管理ＤＢ１７２で管理する各来場者の来場状況を所定のファイルにまとめて出力する機能を有する。具体的には、サーバ１は、各サブイベントの開催者（出展者）からの要求を受けて、サブイベントへの各来場者の来場の有無等を、ＣＳＶ（comma-separated values）、Ｅｘｃｅｌ（登録商標）等の形式で一覧化したファイルを生成し、出力する。
【0067】
例えばサーバ１は、サブイベントの開催者に貸し出した端末２、あるいは他の端末装置からサブイベントＩＤを指定したファイルの出力要求を受け付ける。出力要求を受け付けた場合、サーバ１は、サブイベントＩＤに対応する来場者の来場履歴を来場者管理ＤＢ１７２から参照して、サブイベントへの来場者の来場の有無、及び当該来場者に関する来場者情報を一覧化したファイルを生成し、要求元の端末装置に出力する。サブイベントの開催者は、当該ファイルをダウンロードすることで、サブイベントに来場した来場者に関するデータ納品を受けることができる。特に本実施の形態では、端末２をサブイベントの開催者に貸し出し、イベントの受付窓口での読取と並行してサブイベントでの読取も同時に記録しているため、サブイベントの開催者はイベント開催中に、リアルタイムで来場予定の来場者の状況を確認することができる。
【0068】
図１０は、イベントに来場する来場者を登録する際の処理手順を示すフローチャートである。サーバ１の制御部１１は、イベントに来場する来場者（申込者）に関する情報を取得する（ステップＳ１０１）。例えば、制御部１１は、申込者による申込フォーム若しくはメール経由での申込を通信部１３により受け付けても良く、または郵送での申込書に基づいて申込者の情報の入力を入力部１４により受け付けても良い。来場者に関する情報は、イベントＩＤ、来場者の名前、来場者人数、会社、属性情報及びメールアドレスを含む。
【0069】
制御部１１は、来場者に関する情報を来場者ＩＤと対応付けて予め大容量記憶部１７の来場者ＤＢ１７３に登録する（ステップＳ１０２）。制御部１１は、イベントＩＤに基づき、二次元コードを発行する対象となる来場者の来場者ＩＤを大容量記憶部１７の来場者ＤＢ１７３から取得する（ステップＳ１０３）。制御部１１は、二次元コードの生成ライブラリを利用し、来場者ＩＤを記述した来場者用の二次元コードを生成する（ステップＳ１０４）。
【0070】
制御部１１は、イベントＩＤに対応付けて、来場者ＩＤ、申込状態及び受付状態を一つのレコードとして来場者管理ＤＢ１７２に記憶する（ステップＳ１０５）。制御部１１は、生成した来場者用の二次元コードを来場者に発行する（ステップＳ１０６）。例えば、制御部１１は来場者ＩＤに基づき、来場者ＤＢ１７３から来場者のメールアドレスを取得する。制御部１１は、生成した来場者用の二次元コードを通信部１３によりメールアドレス宛に送信する。または、例えば制御部１１は、ＰＤＦ（Portable Document Format）生成ライブラリを利用し、生成した来場者用の二次元コードをＰＤＦに出力しても良い。
【0071】
図１１及び図１２は、イベントに来場した来場者を受け付ける際の処理手順を示すフローチャートである。端末２の制御部２１は、撮影部２８またはコード読取部２９を介して、来場者用の二次元コードを読み取る（ステップＳ２１１）。制御部２１は、二次元コードの解析ライブラリを利用し、読み取った二次元コードから来場者ＩＤを取得する（ステップＳ２１２）。
【0072】
制御部２１は、ネットワークＮ経由でサーバ１と通信可能か否かの通信判定処理を行う（ステップＳ２１３）。なお、通信判定のサブルーチンについては後述する。制御部２１は、通信判定処理の判定結果に基づき、サーバ１と通信可能か否かを判定する（ステップＳ２１４）。制御部２１は、サーバ１と通信可能であると判定した場合（ステップＳ２１４でＹＥＳ）、二次元コードから読み取った来場者ＩＤを通信部２３によりサーバ１に送信する（ステップＳ２１５）。
【0073】
サーバ１の制御部１１は、通信部１３を介して、端末２から送信された来場者ＩＤを受信する（ステップＳ１１１）。制御部１１は、来場者ＩＤ及びイベントＩＤに基づき、来場者管理ＤＢ１７２から該来場者の申込状態を取得し、取得した申込状態に基づいて来場者がイベントの参加に申し込んだか否かを判定する（ステップＳ１１２）。なお、ステップＳ１１２の判定処理ステップはスキップしてもよい。
【0074】
制御部１１は、来場者がイベントの参加に申し込んでいないと判定した場合（ステップＳ１１２でＮＯ）、制御部１１は処理をステップＳ１１１に戻す。制御部１１は、来場者がイベントの参加に申し込んだと判定した場合（ステップＳ１１２でＹＥＳ）、来場者ＩＤ及びイベントＩＤに基づき、来場者管理ＤＢ１７２から該来場者の受付状態を取得し、取得した受付状態に基づいて来場者が重複来場であるか否かを判定する（ステップＳ１１３）。制御部１１は、来場者が重複来場であると判定した場合（ステップＳ１１３でＹＥＳ）、制御部１１は処理をステップＳ１１１に戻す。
【0075】
なお、例えば来場を許可しない場合（ステップＳ１１２でＮＯ、またはステップＳ１１３でＹＥＳ）、制御部１１は、読取エラーを通信部１３により端末２に送信する。端末２は、サーバ１から送信された読取エラーに応じて、来場日時に対応付けて、イベントＩＤ、来場者ＩＤ及び「読取エラー」状態を一つのレコードとして読取履歴ＤＢ２７１に記憶する。
【0076】
制御部１１は、来場者が重複来場でないと判定した場合（ステップＳ１１３でＮＯ）、来場者ＩＤに基づき、来場者ＤＢ１７３から来場者情報を取得する（ステップＳ１１４）。来場者情報は、来場者が属する会社名称、来場者の名前、来場者人数及び来場者の属性を含む。制御部１１は、イベントＩＤ及び来場者ＩＤに基づき、来場者管理ＤＢ１７２の受付状態列を「来場済み」に更新する（ステップＳ１１５）。制御部１１は、通信部１３を介して、取得した来場者情報を端末２に送信する（ステップＳ１１６）。
【0077】
制御部２１は、時計部２６によりタイマを起動して所定の時間間隔（例えば、５秒）を経過したか否かを判定する（ステップＳ２１６）。制御部２１は、所定の時間間隔を経過していないと判定した場合（ステップＳ２１６でＮＯ）、制御部２１は処理を待機する。制御部２１は、所定の時間間隔を経過したと判定した場合（ステップＳ２１６でＹＥＳ）、通信部２３を介して、サーバ１から送信された来場者情報を受信したか否かを判定する（ステップＳ２１７）。
【0078】
制御部２１は、来場者情報を受信したと判定した場合（ステップＳ２１７でＹＥＳ）、制御部２１は、読取履歴及び来場者情報を補助記憶部２７に記憶する（ステップＳ２１８）。具体的には、制御部２１は、来場日時に対応付けて、イベントＩＤ、来場者ＩＤ及び「送信済み」状態を一つのレコードとして読取履歴ＤＢ２７１に記憶する。制御部２１は、来場者ＩＤ、会社名称、来場者名、来場者人数及び属性を一つのレコードとして来場者情報表示用ＤＢ２７２に記憶する。
【0079】
制御部２１は、来場者情報を表示部２５により表示する（ステップＳ２１９）。制御部２１は、来場者情報を受信していないと判定した場合（ステップＳ２１７でＮＯ）、来場日時に対応付けて、イベントＩＤ、来場者ＩＤ及び「送信エラー」状態を一つのレコードとして読取履歴ＤＢ２７１に記憶する（ステップＳ２２２）。なお、この場合、制御部２１は該来場者の受付に失敗した旨を含むメッセージを表示部２５により表示しても良い。その後、制御部１１は所定の時間間隔（例えば１時間）が経過したか否かを判定する（ステップＳ２２３）。所定の時間間隔が経過していないと判定した場合（ステップＳ２２３でＮＯ）、制御部２１は処理を待機する。所定の時間間隔が経過したと判定した場合（ステップＳ２２３でＹＥＳ）、制御部２１は処理をステップＳ２１３に戻す。
【0080】
制御部２１は、サーバ１と通信不可能であると判定した場合（ステップＳ２１４でＮＯ）、来場日時に対応付けて、イベントＩＤ、来場者ＩＤ及び「未送信」状態を一つのレコードとして読取履歴ＤＢ２７１に記憶する（ステップＳ２２０）。制御部２１は、時計部２６により所定の時間間隔（例えば、５秒）を経過したか否かを判定する（ステップＳ２２１）。制御部２１は、所定の時間間隔を経過したと判断した場合（ステップＳ２２１でＹＥＳ）、ステップＳ２１３に戻り、サーバ１と通信可能か否かを再判定する。制御部２１は、所定の時間間隔を経過していないと判断した場合（ステップＳ２２１でＮＯ）、制御部２１は処理を待機する。
【0081】
図１３は、サーバ１と通信可能か否かを判定するサブルーチンの処理手順を示すフローチャートである。端末２の制御部２１は、接続回線取得ＡＰＩを利用して、通信状態に関する情報を取得する（ステップＳ２３１）。制御部２１は、取得した通信状態に関する情報に基づき、ネットワークＮに通信可能な回線があるか否かを判定する（ステップＳ２３２）。制御部２１は、通信可能な回線がないと判定した場合（ステップＳ２３２でＮＯ）、ネットワークＮに通信不可能である判定結果をもどす（ステップＳ２３３）。
【0082】
制御部２１は、通信可能な回線があると判定した場合（ステップＳ２３２でＹＥＳ）、制御部２１は、該当する通信回線の電波の受信レベルが閾値より大きいか否かを判定する（ステップＳ２３４）。通信可能な回線は、例えばＬＴＥ通信回線、または無線通信回線等である。電波の受信レベルは、例えば圏外、レベル０、レベル１、レベル２及びレベル３を含み、順次に電波の強度が強くなる。
【0083】
制御部２１は、通信回線の電波の受信レベルが閾値（例えば、レベル０）より大きいと判定した場合（ステップＳ２３４でＹＥＳ）、ネットワークＮに通信可能である判定結果をもどす（ステップＳ２３５）。制御部２１は、通信回線の電波の受信レベルが閾値以下であると判定した場合（ステップＳ２３４でＮＯ）、制御部２１は処理をステップＳ２３３に遷移する。
【0084】
なお、上述した処理は、通信判定処理の一例であり、実際の接続回線タイプまたは機種情報等に応じて、任意の通信判定用のアルゴリズムを採用しても良い。例えば端末２は、通信回線の電波の受信レベルを判定せず、通信可能な回線があるか否かのみを判定しても良い。または、端末２は、来場者受付アプリケーションとは別な並列処理（オペレーティングシステム内のスレッド）で常にネットワークが復帰したか否かを監視しておき、ネットワークが復帰した場合、来場者受付アプリケーションにネットワークが復帰した旨を通知して未同期の来場者ＩＤをサーバ１に再送してもよい。
【0085】
図１４は、来場者の受付画面の一例を示す説明図である。受付画面は、イベント名２０ａ、件数表示欄２０ｂ、来場者表示欄２０ｃ、ボタン２０ｄ、オブジェクト２０ｅを含む。イベント名２０ａは、イベントの名称を表示する表示欄である。件数表示欄２０ｂは、来場者用の二次元コードの読取総件数（「総読取」）、来場した人数（「来場」）及び未同期の来場者ＩＤの件数（「未同期」）を表示する表示欄である。来場者表示欄２０ｃは、来場者情報を表示する表示欄である。
【0086】
ボタン２０ｄは、読取モードを切り替えるためのボタンである。読取モードは、来場者用の二次元コードを読み取るコード読取モード、及び来場者ＩＤ（受講票ＩＤ）を直接入力する直接入力モードを含む。オブジェクト２０ｅは、来場者ＩＤを受け付けるためのボタンまたはテキストフィールドである。直接入力モードの場合、オブジェクト２０ｅは来場者ＩＤを入力するためのテキストフィールドである。コード読取モードの場合、オブジェクト２０ｅは二次元コードを読み取るためのボタンに変わる。
【0087】
端末２は、イベントＩＤに基づき、読取履歴ＤＢ２７１から読取総件数（同期済みの件数、及び未同期の件数）を集計する。端末２は、来場者情報表示用ＤＢ２７２から来場者人数を集計する。端末２は、イベントＩＤに基づき、「未送信」又は「エラー」状態である未同期の件数を読取履歴ＤＢ２７１から集計する。端末２は、集計した読取総件数、来場者人数及び未同期の件数を件数表示欄２０ｂに表示する。なお、本実施形態では、「未送信」状態の件数と「エラー」状態の件数との集計件数を未同期の件数として表示する例を説明したが、これに限るものではない。例えば、「未送信」状態の件数及び「エラー」状態の件数それぞれを表示しても良い。
【0088】
端末２は、２０ｄボタンのタッチ操作を受け付けた場合、来場者用の二次元コードを読み取る。端末２は、読み取った二次元コードから来場者ＩＤを取得する。また、端末２は、入力された来場者ＩＤを２０ｅテキストフィールドから直接に受け付けても良い。
【0089】
端末２は、サーバ１との通信判定処理を行う。端末２は、サーバ１と通信可能であると判定した場合、受け付けた来場者ＩＤをサーバ１に送信する。サーバ１は、端末２から送信された来場者ＩＤを受信し、受信した来場者ＩＤに基づいて来場を許可するか否かを判定する。サーバ１は、来場を許可したと判定した場合、来場者ＩＤに基づき、来場者名、来場者人数、会社及び属性等を含む来場者情報を来場者ＤＢ１７３から取得する。
【0090】
サーバ１は、取得した来場者情報を端末２に送信する。端末２は、サーバ１から送信された来場者情報を受信する。端末２は、イベントＩＤ及び来場者ＩＤに基づき、来場者日時及び「送信済み」状態を一つのレコードとして読取履歴ＤＢ２７１に記憶する。端末２は、受信した来場者情報を２０ｃに表示する。
【0091】
図１５は、読取履歴画面の一例を示す説明図である。件数表示欄２０ｂは、図１４での件数表示欄２０ｂと同様であるため、説明を省略する。読取履歴画面は、読取履歴表示欄２１ａ、送信アイコン２１ｂ、未送信アイコン２１ｃ、送信エラーアイコン２１ｄ、読取エラーアイコン２１ｅ、キャンセルアイコン２１ｆ、送信抽出ボタン２１ｇ、未送信抽出ボタン２１ｈ、送信エラー抽出ボタン２１ｉ及び読取エラー抽出ボタン２１ｊを含む。
【0092】
読取履歴表示欄２１ａは、二次元コードの読取履歴を表示する表示欄である。読取履歴表示欄２１ａに表示される読取履歴は、来場者ＩＤ及び二次元コードの読取時刻を含む。送信アイコン２１ｂは、「送信」状態を示すアイコンである。「送信」は、来場者ＩＤの送信に成功した読取履歴である。未送信アイコン２１ｃは、「未送信」状態を示すアイコンである。「未送信」は、回線不調時に来場者ＩＤが読み取られたが、サーバ１に送信されていない状態を表す。
【0093】
送信エラーアイコン２１ｄは、「送信エラー」状態を示すアイコンである。「送信エラー」は、送信時に回線不調等が発生し、送信に失敗した状態を表す。読取エラーアイコン２１ｅは、「読取エラー」状態を示すアイコンである。「読取エラー」は、不正な来場者コードであることを表す。キャンセルアイコン２１ｆは、「キャンセル」状態を示すアイコンである。「キャンセル」は、読み取った来場者ＩＤがキャンセルされたことを表す。なお、上述した各種のアイコンに限らず、実際のニーズに応じて任意のアイコンを設けても良い。
【0094】
送信抽出ボタン２１ｇは、「送信」状態の読取履歴のみを表示するためのボタンである。未送信抽出ボタン２１ｈは、「未送信」状態の読取履歴のみを表示するためのボタンである。送信エラー抽出ボタン２１ｉは、「送信エラー」状態の読取履歴のみを表示するためのボタンである。読取エラー抽出ボタン２１ｊは、「読取エラー」状態の読取履歴のみを表示するためのボタンである。端末２は、イベントＩＤに基づき、来場者ＩＤ、来場日時情報及び同期状態を読取履歴ＤＢ２７１から取得する。端末２は、取得した来場者ＩＤ及び来場日時情報を、読取履歴表示欄２１ａに表示する。端末２は、取得した来場者ＩＤに対応する同期状態に基づき、該当するアイコンを表示する。
【0095】
端末２は、送信抽出ボタン２１ｇのタッチ操作を受け付けた場合、読取履歴ＤＢ２７１から取得した読取履歴から「送信」状態に対応する読取履歴を抽出する。端末２は、未送信抽出ボタン２１ｈのタッチ操作を受け付けた場合、読取履歴ＤＢ２７１から取得した読取履歴から「未送信」状態に対応する読取履歴を抽出する。端末２は、送信エラー抽出ボタン２１ｉのタッチ操作を受け付けた場合、読取履歴ＤＢ２７１から取得した読取履歴から「送信エラー」状態に対応する読取履歴を抽出する。端末２は、読取エラー抽出ボタン２１ｊのタッチ操作を受け付けた場合、読取履歴ＤＢ２７１から取得した読取履歴から「読取エラー」状態に対応する読取履歴を抽出する。端末２は、抽出した読取履歴を読取履歴表示欄２１ａに表示する。
【0096】
本実施形態によると、来場者ＩＤを記述したコードを読み取ることにより、イベントに来場する来場者を受け付けることが可能となる。
【0097】
本実施形態によると、来場者を受け付ける端末２はサーバ１と接続できない場合、来場者ＩＤを記憶し、通信状況を回復する後に再送信することが可能となる。
【0098】
本実施形態によると、ネットワークＮの通信状態不調時、またはサーバ１上のシステムダウン時に来場者の受付を継続させることが可能となる。
【0099】
本実施形態によると、現地の環境に依存せず、端末２上で来場者の受付を行うことが可能となる。
【0100】
本実施形態によると、来場者ＩＤを送信済みの状態、来場者ＩＤを未送信の状態、または来場者情報を未取得の状態を識別可能に読取履歴画面に表示することにより、来場者の受付状況を分かり易く把握することが可能となる。
【0101】
（実施形態２）
実施形態２は、イベントが終了した場合、未同期の来場者ＩＤをサーバ１に一括送信する形態に関する。なお、実施形態１と重複する内容については説明を省略する。
実施形態２は、イベントが終了した場合、未同期の来場者ＩＤをサーバ１に一括送信する形態に関する。なお、実施形態１と重複する内容については説明を省略する。
【0102】
実施形態１では、「未送信」又は「エラー」の状態になっている来場者ＩＤをサーバ１に随時送信する旨を説明した。一方で、ネットワークＮの通信やサーバ１が復旧せずに、来場者ＩＤが未同期となったままとなる場合があり得る。そこで本実施形態では、イベント終了時に未同期の来場者ＩＤの一括送信を行う。
【0103】
例えば端末２は、現在時刻とイベントの終了時刻とを比較して、イベントが終了したか否かを判定する。端末２は、イベントが終了したと判定した場合、未同期の来場者ＩＤが読取履歴ＤＢ２７１に記憶されているか否かを判定する。端末２は、未同期の来場者ＩＤが記憶されていると判定した場合、未同期の来場者ＩＤが存在する旨のアラートを表示する。
【0104】
なお、本実施の形態ではイベントの終了時刻を保持し、現在時刻に応じてイベントが終了したか否かを判定するものとするが、本実施の形態はこれに限定されるものではない。例えばイベントが終了した際に読み取るイベント終了処理用コードを予め用意しておき、端末２が当該コードを読み取った場合に、イベントが終了したものと判定してもよい。イベント終了処理用コードは、例えばイベント主催者の担当者や各サブイベントの開催者（ブース出展者）が端末２を返却する返却窓口に用意され、当該窓口においてイベント終了処理用コードを読み取ることで、イベントが終了したと判定する。このように、端末２はイベントが終了したか否かを判定可能であればよく、時刻に基づく判定は必須ではない。
【0105】
図１６は、未同期の来場者ＩＤのアラート表示に関する説明図である。例えば端末２は、イベントが終了し、かつ、未同期の来場者ＩＤが記憶されている場合、図１６に示すポップアップ画面を表示し、未同期の来場者ＩＤが存在する旨をアラートする。ポップアップ画面は、未同期の来場者ＩＤが存在する旨のメッセージのほか、送信ボタン２２ａを含む。送信ボタン２２ａは、未同期の来場者ＩＤ（受講票ＩＤ）を一括送信するためのボタンである。端末２は、送信ボタン２２ａへのタッチ操作を受け付けた場合、端末２はすべての未同期の来場者ＩＤを読取履歴ＤＢ２７１から取得する。端末２は、取得したすべての未同期の来場者ＩＤをサーバ１に送信する。
【0106】
図１７は、イベントが終了した場合に未同期の来場者ＩＤを一括送信する際の処理手順を示すフローチャートである。端末２の制御部２１は、イベントの開始を入力部２４により受け付ける（ステップＳ２５１）。制御部２１は、該イベントのイベントＩＤを通信部２３によりサーバ１に送信する（ステップＳ２５２）。サーバ１の制御部１１は、端末２から送信されたイベントＩＤを通信部１３により受信する（ステップＳ１５１）。
【0107】
制御部１１は、受信したイベントＩＤに基づき、大容量記憶部１７のイベントＤＢ１７１から該イベントの終了時間を取得する（ステップＳ１５２）。制御部１１は、取得したイベントの終了時間を通信部１３により端末２に送信する（ステップＳ１５３）。端末２の制御部２１は、サーバ１から送信されたイベントの終了時間を通信部２３により受信する（ステップＳ２５３）。
【0108】
制御部２１は、現時点がイベントの終了時間であるか否かを時計部２６により判定する（ステップＳ２５４）。制御部２１は、現時点がイベントの終了時間でないと判定した場合（ステップＳ２５４でＮＯ）、制御部２１は処理をステップＳ２５４に戻す。制御部２１は、現時点がイベントの終了時間であると判定した場合（ステップＳ２５４でＹＥＳ）、未同期の来場者ＩＤが補助記憶部２７の読取履歴ＤＢ２７１に記憶されているか否かを判定する（ステップＳ２５５）。
【0109】
制御部２１は、未同期の来場者ＩＤが記憶されていないと判定した場合（ステップＳ２５５でＮＯ）、処理を終了する。制御部２１は、未同期の来場者ＩＤが記憶されていると判定した場合（ステップＳ２５５でＹＥＳ）、すべての未同期の来場者ＩＤを読取履歴ＤＢ２７１から取得する（ステップＳ２５６）。制御部２１は、取得したすべての未同期の来場者ＩＤを通信部２３によりサーバ１に送信する（ステップＳ２５７）。
【0110】
サーバ１の制御部１１は、通信部１３を介して、端末２から送信されたすべての未同期の来場者ＩＤを受信する（ステップＳ１５４）。制御部１１は、受信したそれぞれの未同期の来場者ＩＤに基づき、例えば該当する大容量記憶部１７の来場者管理ＤＢ１７２の受付状態列を「イベント終了後の同期済み」に更新する（ステップＳ１５５）。
【0111】
本実施形態によると、イベントが終了した場合、未同期の来場者ＩＤをサーバ１に送信することにより、未同期の来場者ＩＤを一括同期することが可能となる。
【0112】
（実施形態３）
実施形態３は、サブイベント（出展ブース）において二次元コードを読み取った場合に、来場者に応じた要望を表す要望コードを表示する形態に関する。なお、実施形態１～２と重複する内容については説明を省略する。要望コードは、イベントに来場する来場者の要望（例えば、当日の説明担当者、興味度合い、配布のカタログ等）を特定するための識別子であり、サブイベントの開催者（出展者）が任意に定義する。サブイベントの開催者は要望コードを確認することで、来場者の要望を迅速に把握することができる。
実施形態３は、サブイベント（出展ブース）において二次元コードを読み取った場合に、来場者に応じた要望を表す要望コードを表示する形態に関する。なお、実施形態１～２と重複する内容については説明を省略する。要望コードは、イベントに来場する来場者の要望（例えば、当日の説明担当者、興味度合い、配布のカタログ等）を特定するための識別子であり、サブイベントの開催者（出展者）が任意に定義する。サブイベントの開催者は要望コードを確認することで、来場者の要望を迅速に把握することができる。
【0113】
図１８は、実施形態３の来場者ＤＢ１７３のレコードレイアウトの一例を示す説明図である。なお、図５と重複する内容については同一の符号を付して説明を省略する。来場者ＤＢ１７３は、要望コード列を含む。要望コード列は、要望を特定する要望コードを記憶している。
【0114】
上記の様に、サーバ１は、イベントに来場する来場者（申込者）に関する情報として、来場者の要望を来場者ＩＤと対応付けて予め来場者ＤＢ１７３に登録してある。具体的には、サーバ１は、サブイベントの開催者から事前に要望コードの通知を受け、来場者ＤＢ１７３に記憶してある。サーバ１は、来場者ＩＤを割り振って、イベントＩＤ、サブイベントＩＤ、来場者の名前、会社、属性情報（例えば、ＶＩＰ等）、メールアドレスと共に、要望コードを一つのレコードとして来場者ＤＢ１７３に記憶する。
【0115】
サーバ１は、来場者用の二次元コードを発行する場合に、来場者ＩＤに加えて、要望コードを記述した来場者用の二次元コードを来場者に発行する。具体的には、サーバ１は、イベントＩＤに基づき、二次元コードを発行する対象となる来場者の来場者ＩＤ及び該来場者ＩＤに対応する要望コードを来場者ＤＢ１７３から取得する。サーバ１は、二次元コードの生成ライブラリを利用し、来場者ＩＤ及び要望コードを含む来場者用の二次元コードを生成する。
【0116】
サーバ１は、イベントＩＤ及びサブイベントＩＤに対応付けて、来場者ＩＤ、申込状態及び受付状態を一つのレコードとして来場者管理ＤＢ１７２に記憶する。サーバ１は、生成した来場者用の二次元コードを、メールまたはＳＮＳ等を利用して該当する来場者に送信する。
【0117】
端末２は、来場者用の二次元コードを読み取る。この場合に端末２は、来場者ＩＤ以外に、要望コードを二次元コードから取得する。なお、要望コードを上述した来場者用の二次元コードと別の二次元コードから取得しても良い。端末２は、二次元コードから読み取った来場者ＩＤをサーバ１に送信する。サーバ１は、端末２から送信された来場者ＩＤを受信し、来場者情報を返信する。
【0118】
端末２は、サーバ１から送信された来場者情報を受信して表示すると共に、二次元コードから読み取った要望コードを併せて表示する。サブイベントの開催者は、自らが管理する要望コード及び要望内容のテーブル（対応表）を確認して、来場者の要望内容を把握する。
【0119】
なお、要望コードに対応する要望内容をサーバ１または端末２が保持しておき、端末２が要望内容を表示可能としても良い。
【0120】
図１９は、要望コード及び来場者情報を表示する際の処理手順を示すフローチャートである。なお、端末２がサーバ１と通信可能か否かを判定する処理を省略し、サーバ１と通信可能である前提条件として説明する。
【0121】
端末２の制御部２１は、撮影部２８またはコード読取部２９を介して、来場者用の二次元コードを読み取る（ステップＳ２７１）。制御部２１は、二次元コードの解析ライブラリを利用し、読み取った二次元コードから来場者ＩＤ及び要望コードを取得する（ステップＳ２７２）。制御部２１は、二次元コードから読み取った来場者ＩＤを通信部２３によりサーバ１に送信する（ステップＳ２７３）。
【0122】
サーバ１の制御部１１は、通信部１３を介して、端末２から送信された来場者ＩＤを受信する（ステップＳ１７１）。制御部１１は、来場者ＩＤに基づいて来場者ＤＢ１７３から来場者情報を取得する（ステップＳ１７２）。制御部１１は、通信部１３を介して、取得した来場者情報を端末２に送信する（ステップＳ１７３）。
【0123】
端末２の制御部２１は、サーバ１から送信された来場者情報を通信部２３により受信し（ステップＳ２７４）、要望コードと受信した来場者情報とを表示部２５により表示する（ステップＳ２７５）。制御部２１は、二次元コードの読取履歴を読取履歴ＤＢ２７１に記憶し、来場者情報を来場者情報表示用ＤＢ２７２に記憶する（ステップＳ２７６）。
【0124】
本実施形態によると、イベントに来場する来場者の要望コードを表示することにより、来場者の要望を迅速に把握することが可能となる。
【0125】
（実施形態４）
実施形態４は、サーバ１は、複数の端末２それぞれとの間の通信状態を監視し、端末２それぞれとの通信状態の一覧を出力する形態に関する。なお、実施形態１～３と重複する内容については説明を省略する。
実施形態４は、サーバ１は、複数の端末２それぞれとの間の通信状態を監視し、端末２それぞれとの通信状態の一覧を出力する形態に関する。なお、実施形態１～３と重複する内容については説明を省略する。
【0126】
図２０は、実施形態４のサーバ１の構成例を示すブロック図である。なお、図２と重複する内容については同一の符号を付して説明を省略する。サーバ１は、時計部１８を含む。時計部１８は、時刻又は経過時間等を計時しており、制御部１１からの求めに応じて、計時結果を制御部１１に与える回路である。また、時計部１８はタイマ機能を提供する。タイマ機能は開始を指示されてから、予め設定した時間が経過した場合、その旨を制御部１１に通知する機能である。又は、タイマ機能は開始を指示されてから、予め設定した時間が経過したか否かを、制御部１１からの問い合わせに対して回答する機能である。大容量記憶部１７には、端末監視ＤＢ１７４が記憶されている。端末監視ＤＢ１７４は、監視対象となる複数の端末に関する情報を記憶している。
【0127】
図２１は、端末監視ＤＢ１７４のレコードレイアウトの一例を示す説明図である。端末監視ＤＢ１７４は、端末ＩＤ列、端末名列、最終アプリログイン日時列、最終読取日時列及び状態列を含む。端末ＩＤ列は、各監視対象となる端末を識別するために、一意に特定される端末のＩＤを記憶している。端末名列は、監視対象となる端末の名称を記憶している。最終アプリログイン日時列は、監視対象となる端末が最後にサーバにログイン（接続）した日時情報を記憶している。最終読取日時列は、最後に端末の通信状態を読み取った日時情報を記憶している。状態列は、監視対象となる端末との通信状態を記憶している。本実施の形態では、通信状態として「online」、「offline」又は「停止」のステータスが格納される。「online」は、サーバ１が端末２と通信可能状態である。「offline」は、サーバ１が端末２と通信不可能状態である。「停止」は、端末２の通信機能がサーバ１から停止されている状態である。
【0128】
図２２は、通信状態の一覧画面の一例を示す説明図である。一覧画面は、端末ＩＤ表示欄１０ａ、端末名表示欄１０ｂ、最終アプリログイン日時表示欄１０ｃ、最終読取日時表示欄１０ｄ、通信状態欄１０ｅ、停止ボタン１０ｆを含む。端末ＩＤ表示欄１０ａは、端末ＩＤを表示する領域である。端末名表示欄１０ｂは、端末名を表示する領域である。最終アプリログイン日時表示欄１０ｃは、最終アプリログインの日時情報を表示する領域である。最終読取日時表示欄１０ｄは、最終読取の日時情報を表示する領域である。通信状態欄１０ｅは、端末との通信状態を表示する領域である。停止ボタン１０ｆは、端末２の動作をサーバ１側から停止するための操作ボタンである。停止ボタン１０ｆによる端末２の停止機能は、端末２の紛失時などに利用される。
【0129】
端末２は、サーバ１にログインのリクエストを送信する。リクエストは、ログインＩＤ、パスワード、端末ＩＤ及び端末名等を含む。サーバ１は、端末２から送信されたリクエストを受信する。サーバ１は、受信したログインＩＤ及びパスワードに基づき、ログインの認証処理を行う。サーバ１は、ログインに成功したと判定した場合、端末ＩＤ、端末名、ログイン日時、読取日時及び通信状態を一つのレコードとして端末監視ＤＢ１７４に記憶する。サーバ１は、端末ＩＤ、端末名、ログイン日時、読取日時及び通信状態それぞれを１０ａ、１０ｂ、１０ｃ、１０ｄ及び１０ｅに表示する。
【0130】
サーバ１は、所定間隔でそれぞれの監視対象となる端末との通信状態を読み取り、読み取った日時情報及び通信状態を端末監視ＤＢ１７４に更新する。具体的には、サーバ１は、読み取った日時情報及び通信状態を端末監視ＤＢ１７４の最終読取日時列及び状態列に更新する。サーバ１は、読み取った日時情報を１０ｄに再表示し、通信状態を１０ｅに再表示する。
【0131】
図２３は、端末２との通信状態の一覧を出力する際の処理手順を示すフローチャートである。端末２の制御部２１は、通信部２３を介して、ログインＩＤ、パスワード、端末ＩＤ及び端末名等を含むログインのリクエストを送信する（ステップＳ２８１）。サーバ１の制御部１１は、通信部１３を介して、端末２から送信されたリクエストを受信する（ステップＳ１８１）。制御部１１は、受信したログインＩＤ及びパスワードに基づき、ログインに成功するか否かを判定する（ステップＳ１８２）。制御部１１は、ログインに成功したと判定した場合（ステップＳ１８２でＹＥＳ）、端末ＩＤ、端末名、ログイン日時、読取日時及び通信状態を含む端末に関する情報を大容量記憶部１７の端末監視ＤＢ１７４に記憶する（ステップＳ１８３）。
【0132】
制御部１１は、表示部１５を介して、端末ＩＤ、端末名、ログイン日時、読取日時及び通信状態を含む通信状態一覧を表示（出力）する（ステップＳ１８４）。制御部１１は、時計部１８により所定の時間間隔（例えば、５秒）を経過したか否かを判定する（ステップＳ１８５）。制御部１１は、所定の時間間隔を経過していないと判定した場合（ステップＳ１８５でＮＯ）、制御部１１は処理を待機する。制御部１１は、所定の時間間隔を経過したと判定した場合（ステップＳ１８５でＹＥＳ）、端末２と通信可能か否かを判定する（ステップＳ１８６）。なお、通信判定処理に関しては、実施形態１での通信判定処理と同様であるため、説明を省略する。
【0133】
制御部１１は、端末２と通信可能と判定した場合（ステップＳ１８６でＹＥＳ）、読み取った日時情報及び「online」通信状態を端末監視ＤＢ１７４の最終読取日時列及び状態列に更新する（ステップＳ１８７）。制御部１１は、表示部１５を介して、読み取った日時情報及び「online」通信状態を再表示する（ステップＳ１８８）。
【0134】
制御部１１は、端末２と通信不可能と判定した場合（ステップＳ１８６でＮＯ）、読み取った日時情報及び「offline」通信状態を端末監視ＤＢ１７４の最終読取日時列及び状態列に更新する（ステップＳ１８９）。制御部１１は、表示部１５を介して、読み取った日時情報及び「offline」通信状態を再表示する（ステップＳ１９０）。
【0135】
制御部１１は、ログインに失敗したと判定した場合（ステップＳ１８２でＮＯ）、ログインに失敗した旨を含むメッセージを通信部１３により端末２に送信する（ステップＳ１９１）。端末２の制御部２１は、サーバ１から送信されたメッセージを通信部２３により受信し（ステップＳ２８２）、受信したメッセージを表示部２５により表示する（ステップＳ２８３）。
【0136】
本実施形態によると、複数の端末２それぞれとの間の通信状態を監視することにより、各端末２の通信状況を把握することが可能となる。
【0137】
（実施形態５）
実施形態５は、イベントの終了時間経過または端末２の電源ＯＦＦ操作により未同期の来場者ＩＤを最終確認する形態に関する。なお、実施形態１～４と重複する内容については説明を省略する。実施の形態１で説明したように、本システムではイベント主催者の担当者やサブイベントの開催者（出展者）に専用の端末２を貸し出し、各端末２において二次元コードの読取を行う。本実施形態では、各端末２での読取状況について、未同期の来場者ＩＤに対して同期漏れ等のミスを生じないように最終確認を行う。
実施形態５は、イベントの終了時間経過または端末２の電源ＯＦＦ操作により未同期の来場者ＩＤを最終確認する形態に関する。なお、実施形態１～４と重複する内容については説明を省略する。実施の形態１で説明したように、本システムではイベント主催者の担当者やサブイベントの開催者（出展者）に専用の端末２を貸し出し、各端末２において二次元コードの読取を行う。本実施形態では、各端末２での読取状況について、未同期の来場者ＩＤに対して同期漏れ等のミスを生じないように最終確認を行う。
【0138】
具体的には、端末２は、イベントの終了時間を経過し、イベントの終了時間から所定の時間間隔（例えば、３０分）を経過し、または電源ＯＦＦ操作を検出した場合、端末２は未同期の来場者ＩＤが読取履歴ＤＢ２７１に記憶されているか否かを判定する。端末２は、未同期の来場者ＩＤが記憶されていると判定した場合、未同期の来場者ＩＤが存在する旨のアラートを表示する。
【0139】
図２４は、未同期の来場者ＩＤを最終確認するアラート表示に関する説明図である。例えば端末２は、イベントの終了時間から所定の時間間隔を経過し、かつ、未同期の来場者ＩＤが記憶されている場合、図２４に示すポップアップ画面を表示し、未同期の来場者ＩＤが存在する旨をアラートする。ポップアップ画面は、未同期の来場者ＩＤが存在する旨のメッセージのほか、送信ボタン２２ａ及び保存ボタン２３ａを含む。
【0140】
送信ボタン２２ａは、図１６での送信ボタン２２ａと同様であるため、説明を省略する。保存ボタン２３ａは、未同期の来場者ＩＤ（受講票ＩＤ）をメモリーカードに一括保存するためのボタンである。端末２は、保存ボタン２３ａのタッチ操作を受け付けた場合、端末２に取り付けられたメモリーカードを認識する。端末２は、認識したメモリーカードに未同期の来場者ＩＤを一括記憶する。なお、本実施形態では、来場者ＩＤをメモリーカードに保存した例を説明したが、これに限るものではない。例えば、端末２が外部のＰＣ（personal computer）に接続し、接続した該外部のＰＣに来場者ＩＤを転送しても良い。
【0141】
図２５は、未同期の来場者ＩＤを最終確認する際の処理手順を示すフローチャートである。端末２の制御部２１は、電源ＯＦＦ操作を受け付けたか否かを判定する（ステップＳ２９１）。制御部２１は、電源ＯＦＦ操作を受け付けたと判定した場合（ステップＳ２９１でＹＥＳ）、制御部２１は後述する処理をステップＳ２９３に遷移する。制御部２１は、電源ＯＦＦ操作を受け付けていないと判定した場合（ステップＳ２９１でＮＯ）、制御部２１は、イベントの終了時間から所定の時間間隔（例えば、３０分）を経過したか否かを判定する（ステップＳ２９２）。
【0142】
制御部２１は、イベントの終了時間から所定の時間間隔を経過していないと判定した場合（ステップＳ２９２でＮＯ）、制御部２１は処理をステップＳ２９１に戻す。制御部２１は、イベントの終了時間から所定の時間間隔を経過したと判定した場合（ステップＳ２９１でＹＥＳ）、制御部２１は、「未送信」状態及び「エラー」状態に対応する未同期の来場者ＩＤが補助記憶部２７の読取履歴ＤＢ２７１に記憶されているか否かを判定する（ステップＳ２９３）。
【0143】
制御部２１は、未同期の来場者ＩＤが記憶されていないと判定した場合（ステップＳ２９３でＮＯ）、制御部２１は処理を終了する。制御部２１は、未同期の来場者ＩＤが記憶されていると判定した場合（ステップＳ２９３でＹＥＳ）、すべての未同期の来場者ＩＤを読取履歴ＤＢ２７１から取得する（ステップＳ２９４）。
【0144】
制御部２１は、受け付けたタッチ操作が送信ボタンのタッチ操作であるか否かを判定する（ステップＳ２９５）。制御部２１は、受け付けたタッチ操作が送信ボタンのタッチ操作であると判定した場合（ステップＳ２９５でＹＥＳ）、制御部２１は、取得したすべての未同期の来場者ＩＤを通信部２３によりサーバ１に送信する（ステップＳ２９６）。なお、制御部２１は、通信不可能であると判定した場合、図２４の送信ボタン２２ａを表示しなくても良く、または送信ボタン２２ａを操作できないよう半透明の状態で表示しても良い。
【0145】
制御部２１は、受け付けたタッチ操作が送信ボタンのタッチ操作でないと判定した場合（ステップＳ２９５でＮＯ）、制御部２１は、受け付けたタッチ操作が保存ボタンのタッチ操作であるか否かを判定する（ステップＳ２９７）。制御部２１は、受け付けたタッチ操作が保存ボタンのタッチ操作でないと判定した場合（ステップＳ２９７でＮＯ）、制御部２１は処理を終了する。制御部２１は、受け付けたタッチ操作が保存ボタンのタッチ操作であると判定した場合（ステップＳ２９７でＹＥＳ）、制御部２１は、未同期の来場者ＩＤをメモリーカードに記憶し（ステップＳ２９８）、処理を終了する。
【0146】
なお、図２５では、電源ＯＦＦ操作の例を説明したが、これに限るものではない。例えば、制御部２１は、メモリデータの初期化または消去操作を受け付けた場合、上述した未同期の来場者ＩＤの最終確認処理を実行しても良い。または、イベント終了処理用コードを端末返却窓口で読み取ることにより、上述した未同期の来場者ＩＤの最終確認処理を実行しても良い。
【0147】
本実施形態によると、未同期の来場者ＩＤを最終確認することにより、来場者ＩＤの同期ミスを防止することが可能となる。
【0148】
今回開示された実施形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【0149】
１ 管理装置（サーバ）
１１ 制御部
１２ 記憶部
１３ 通信部
１４ 入力部
１５ 表示部
１６ 読取部
１７ 大容量記憶部
１７１ イベントＤＢ
１７２ 来場者管理ＤＢ
１７３ 来場者ＤＢ
１７４ 端末監視ＤＢ
１８ 時計部
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
１Ｐ 制御プログラム
２ 携帯端末（端末）
２１ 制御部
２２ 記憶部
２３ 通信部
２４ 入力部
２５ 表示部
２６ 時計部
２７ 補助記憶部
２７１ 読取履歴ＤＢ
２７２ 来場者情報表示用ＤＢ
２８ 撮影部
２９ コード読取部
２Ｐ 制御プログラム
１１ 制御部
１２ 記憶部
１３ 通信部
１４ 入力部
１５ 表示部
１６ 読取部
１７ 大容量記憶部
１７１ イベントＤＢ
１７２ 来場者管理ＤＢ
１７３ 来場者ＤＢ
１７４ 端末監視ＤＢ
１８ 時計部
１ａ 可搬型記憶媒体
１ｂ 半導体メモリ
１Ｐ 制御プログラム
２ 携帯端末（端末）
２１ 制御部
２２ 記憶部
２３ 通信部
２４ 入力部
２５ 表示部
２６ 時計部
２７ 補助記憶部
２７１ 読取履歴ＤＢ
２７２ 来場者情報表示用ＤＢ
２８ 撮影部
２９ コード読取部
２Ｐ 制御プログラム
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】