(57)【要約】【課題】知人が着席する周囲の席に、ユーザが着座することを支援することを課題とする。【解決手段】ユーザ間の知人関係を記憶した知人関係情報テーブルと、複数の座席の配置を記憶した座席位置テーブルと、前記座席位置テーブルに記憶されている各座席にどのユーザが着席しているかを記憶する座席テーブルと、前記ユーザを特定するユーザＩＤをリーダ装置から取得する取得部と、前記取得したユーザＩＤに基づき、前記知人関係情報テーブルを参照して、前記ユーザの知人である他のユーザＩＤを抽出すると共に、前記座席位置テーブルおよび前記座席テーブルを参照し、前記抽出された他のユーザが着席している座席の周囲の空席情報を出力する処理部とを有する。【選択図】図１
2013030049.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ間の知人関係を記憶した知人関係情報テーブルと、
複数の座席の配置を記憶した座席位置テーブルと、
前記座席位置テーブルに記憶されている各座席にどのユーザが着席しているかを記憶する座席テーブルと、
前記ユーザを特定するユーザＩＤをリーダ装置から取得する取得部と、
前記取得したユーザＩＤに基づき、前記知人関係情報テーブルを参照して、前記ユーザの知人である他のユーザＩＤを抽出すると共に、前記座席位置テーブルおよび前記座席テーブルを参照し、前記抽出された他のユーザが着席している座席の周囲の空席情報を出力する処理部と、
を有することを特徴とする情報処理装置。
【請求項２】
前記処理部は、
抽出された前記ユーザの知人である他のユーザのうち、所定時間以上、継続して着席していない他のユーザが着席している座席の周囲の空席情報を出力する
請求項１に記載の情報処理装置。
【請求項３】
前記各座席には、ユーザＩＤ識別子を送信する送信機からのユーザＩＤを読み取る読み取り部が設けられており、
前記処理部は、前記読取り部のいずれかがが前記ユーザＩＤを読み取ると、前記読み取ったユーザＩＤと読取った前記読取り部に対応する座席とを関連付けて前記座席テーブルに記憶させ、前記ユーザＩＤを読取れない読取り部に対応する座席を空席として前記座席テーブルに記憶させる
請求項１または２記載の情報処理装置。
【請求項４】
前記各座席には、ユーザＩＤを送信する送信機からのユーザＩＤを読み取る読取り部が設けられており、
前記処理部は、前記各読取り部からの読み取り結果を蓄積するとともに、前記着席した読み取り結果に基づき、隣接して着席するユーザ同士が知人関係にあるとして前記知人関係情報テーブルに記憶する
請求項１から３のいずれかに記載の情報処理装置。
【請求項５】
前記座席テーブルは、前記他のユーザがグループで食事中か否かを記憶し、
前記処理部は、前記グループを構成する全ユーザと前記ユーザとが知人関係である場合のみ、前記他のユーザが着席している座席の周囲の空席情報を出力する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項６】
コンピュータに座席検索処理を実行させる情報処理プログラムであって、
前記コンピュータは、
ユーザ間の知人関係を記憶した知人関係情報テーブルと、
複数の座席の配置を記憶した座席位置テーブルと、
前記座席位置テーブルに記憶されている各座席にどのユーザが着席しているかを記憶する座席テーブルと、
を有し、
前記コンピュータに、
前記ユーザを特定するユーザＩＤをリーダ装置から取得し、
ユーザの要求に応じ、前記知人関係情報テーブルを参照して、前記ユーザの知人である他のユーザＩＤを抽出すると共に、前記座席位置テーブルおよび前記座席テーブルを参照し、前記抽出された他のユーザが着席している座席の周囲の空席情報を出力させる
処理を実行させることを特徴とする情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
開示のシステムは、座席情報を出力する情報処理装置および情報処理プログラムに関する。
【背景技術】
【０００２】
精算システムは、種々の状況で適用される。例えば、社員食堂や学生食堂などでは、食堂が広く且つ知人が多い場合がある。従来の技術として、事前に登録された知人関係情報によって、知人の現在位置を特性する技術はある。
【０００３】
しかし、食堂などの場合、従来の技術をそのまま適用することができない、または、そのまま適用したとしても知人を探すのは困難な場合がある。
【０００４】
例えば、規則として食堂内で携帯端末の使用を禁止する場合がある。また、携帯端末を使用することができる場合でも、食堂内ではトレーを持つ場合が多く、携帯端末を手に持つことができない場合がある。また手にもてたとしても操作することができない。また、知人の位置が分かったとしても、隣席があいているとは限らない。また、各自の食事時間が異なるため、知人の着席時刻から時間が経過している場合は隣席に座っても迷惑になる場合がある。当前記知人は、すでに他の知り合いと食べている場合がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−９３６１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
開示の情報処理装置は、知人が着席する周囲の席に、ユーザが着座することを支援することを課題とする。
【課題を解決するための手段】
【０００７】
開示の情報処理装置は、ユーザ間の知人関係を記憶した知人関係情報テーブルと、複数の座席の配置を記憶した座席位置テーブルと、前記座席位置テーブルに記憶されている各座席にどのユーザが着席しているかを記憶する座席テーブルと、前記ユーザを特定するユーザＩＤをリーダ装置から取得する取得部と、前記取得したユーザＩＤに基づき、前記知人関係情報テーブルを参照して、前記ユーザの知人である他のユーザＩＤを抽出すると共に、前記座席位置テーブルおよび前記座席テーブルを参照し、前記抽出された他のユーザが着席している座席の周囲の空席情報を出力する処理部とを有する。
【発明の効果】
【０００８】
開示の情報処理装置は、知人が着席する周囲の席に、ユーザが着座することを支援することが可能になる。
【図面の簡単な説明】
【０００９】
【図１】本実施例の食堂システムの構成例である。
【図２】精算処理のフローチャートである。
【図３】精算時に精算機が表示する画面例である。
【図４】一時記憶テーブルの構成例である。
【図５】ユーザテーブルの構成例である。
【図６】精算時に精算機が表示する知合い検索処理結果の画面例である。
【図７】着席状況管理処理のフローチャートである。
【図８】食堂内のユーザが食事をする際に着席するテーブルの構成例である。
【図９】着席履歴テーブルの構成例である。
【図１０】座席テーブルの構成例である。
【図１１】知合い推定処理のフローチャートである。
【図１２】座席位置テーブルの構成例である。
【図１３】知人関係情報テーブルの構成例である。
【図１４】食事相手検索処理のフローチャートである。
【図１５】座席の状態を示す例である。
【図１６】本実施例のハードウェア構成の一例である。
【発明を実施するための形態】
【００１０】
本実施例では、情報処理装置及び情報処理プログラムを、食堂システムを例に説明する。本食堂システムでは、携帯端末に組み込まれたＩＣチップを使用する例を説明する。
【００１１】
［機能説明］
図１は、本実施例の食堂システムの構成例である。精算システム１は、複数の精算機２、サーバ３、複数の携帯ホルダ５を含む。各精算機２は、それぞれ、ユーザ購入する料理を精算する際に使用する装置である。
【００１２】
精算機２は、精算リーダライタ部２１、精算送受信部２２、および精算表示部２３を含む。精算機２は、各種の情報を読み取るための読み取り部と処理結果を表示する画面を有する。精算機２の精算リーダライタ部２１は、精算しようとするユーザの携帯端末６の情報の読み出し、あるいは携帯端末６への情報の書き込みを行う。精算機２の精算送受信部２２は、サーバ３に対してデータを送受信するインターフェースである。精算機２の精算表示部２３は、精算時の金額情報、あるいは食事相手候補情報を表示する。
【００１３】
サーバ３は、精算処理、座席管理処理、食事相手検索処理を実行する。サーバ３は、精算機−サーバ送受信部３１、携帯ホルダ−サーバ送受信部３２、精算処理部３３、座席管理部３４、着席履歴管理部３５、知合い推定処理部３６、および食事相手検索処理部３７を含む。
【００１４】
精算機−サーバ送受信部３１は精算機２とデータの送受信をする。携帯ホルダ−サーバ送受信部３２は携帯ホルダ５とデータの送受信をする。精算処理部３３は精算処理を実行する。座席管理部３４は座席管理処理を実行する。着席履歴管理部３５は着席履歴を管理する。知合い推定処理部３６はユーザ間の知合い関係を推定する。食事相手検索処理部３７は食事相手の検索処理を実行する。着席履歴テーブル３８は、ユーザの過去の着席の履歴情報を格納しており、知合い推定処理で使用される。
【００１５】
座席位置テーブル３９は、食堂内の座席の位置が記憶されている。食事相手検索処理時に使用される。なお、本実施例では、一つの座席に一つの携帯ホルダ５が設置されているものとする。座席位置テーブル３９は、予め設定されて記憶されているものとする。
【００１６】
知人関係情報テーブル４０は、知合い推定処理結果から特定された情報を記憶するテーブルである。知人関係情報テーブル４０は、食事相手検索処理時に使用される。
【００１７】
一時記憶テーブル４１は精算時に登録される。一時記憶テーブル４１は知合い推定処理、食事相手検索処理で使用される。一時記憶テーブル４１は知合い推定処理時では当日の全データが使用される。一時記憶テーブル４１は食事相手候補特定処理では登録されたデータが使用される
座席テーブル４２は現在の着席状況を記憶している。座席テーブル４２は食事相手検索処理で使用される。座席テーブル４２には、携帯ホルダ５がユーザの携帯端末を検出すると着席と記憶され、ユーザの携帯端末を検出しなくなると離席とされる。
【００１８】
ユーザテーブル４３はユーザの情報を記憶する。ユーザテーブル４３は知合い推定処理、食事相手検索処理で使用される。ユーザテーブル４３は予め記憶されているものとする。
【００１９】
携帯ホルダ５は、食堂内の各座席に設置されている。携帯ホルダ５は、座席リーダライタ部５１と座席送受信部５２とを含む。携帯ホルダ５の、座席リーダライタ部５１は、着席しているユーザを識別するユーザ識別情報を取得する。携帯ホルダ５は、例えば、座席リーダライタ部５１が携帯端末からユーザ識別情報を検出してから不検出となるまで所定のタイミング毎に、サーバ３に、ユーザ識別情報を送信する。
【００２０】
携帯端末６は、ユーザＩＤを格納しているものとする。携帯端末６は、精算機２あるいは携帯ホルダ５からユーザＩＤの送信要求を受信すると、精算機２あるいは携帯ホルダ５に対してユーザＩＤを送信する。この処理により、精算機２あるいは携帯ホルダ５は、携帯端末６のユーザＩＤを特定する。
【００２１】
以下、精算システム１の各処理を、フローチャートを用いて説明する。
【００２２】
［精算処理］
図２は精算処理のフローチャートである。本実施例では、社員食堂等では、ユーザがセルフサービスで料理を取ってトレーに乗せ、自動精算機に向かい、食器に付けたRFIDタグを自動精算機で読み取り、ＩＣカード等により精算する方法をベースに説明する。
【００２３】
精算機２は例えば、食器（料理の皿など）に埋め込まれた識別情報（料理情報）を読み込むことにより、ユーザが購入した料理を検出する（Ｓ１１）。ここで、本実施例の精算機２は、料理情報と価格情報とは予め関連付けられた料理価格テーブルを記憶しているものとする。
【００２４】
精算機２は、Ｓ１１で検出した料理の合計金額を算出する（Ｓ１２）。精算機は、料理価格テーブルを参照して、ユーザが購入した料理のそれぞれの価格を読み出し、読み出した価格の合計を算出する。
【００２５】
精算機２は、ユーザが購入した料理、当前記料理のそれぞれの金額、Ｓ１２で算出した合計金額、知り合い検索ボタンを画面に表示する（Ｓ１３）。
【００２６】
図３はＳ１３の時点で精算機２が表示する画面例である。画面には、料理の購入者が購入した料理名、当前記料理の価格、購入した料理の合計金額が表示される。また、画面には「知り合い検索」ボタンが表示される。
【００２７】
ユーザは画面に金額が表示されると、精算を行う。本実施例では、ＩＣカードや、携帯端末に設置されたＩＣチップなどを用いて精算するものとする。なお、本実施例のＩＣカードやＩＣチップには機体を識別可能な機体番号が格納されているものとする。
【００２８】
以下、ＩＣチップを例に説明する。精算機２は、携帯端末６のＩＣチップに格納された機体番号情報をリーダライタ部により取得する（Ｓ１４）。
【００２９】
精算機２は精算機２を識別する精算機ＩＤ情報およびＳ１４で取得した機体番号情報をサーバ３に送信する（Ｓ１５）。
【００３０】
サーバ３は、精算機２から送信された機体番号情報を受信すると（Ｓ２１）、ユーザテーブル４３から機体番号に対応するユーザＩＤ、精算機ＩＤ、精算時刻を読み出し、読み出したユーザＩＤ、精算機ＩＤ、精算時刻を一時記憶テーブル４１に格納する（Ｓ２２）。
【００３１】
図４は一時記憶テーブル４１の構成例である。一時記憶テーブル４１は、ユーザＩＤ、精算機ＩＤ、精算時刻を含む。ユーザＩＤはユーザを識別するための識別情報であり、ユーザごとに割り振られている。精算機ＩＤは精算機を識別するための識別情報であり、精算機ごとに割り振られている。精算時刻は、ユーザが料理を精算したときの時刻である。
【００３２】
図５は、ユーザテーブル４３の構成例である。ユーザテーブル４３は、携帯端末６の固有の番号である機体番号、ユーザを識別するユーザＩＤ、ユーザの氏名、ユーザのメールアドレス、など、ユーザを特定するための情報を含む。携帯端末６は、精算機２あるいは携帯ホルダ５に対して、機体番号を送信することにより、精算機２あるいは携帯ホルダ５に携帯端末を特定させる。また、顔画像などの情報をあわせて記憶させることもできる。ユーザテーブル４３のユーザ情報は予め記憶されているものとする。
【００３３】
次に、精算機２は、ＩＣチップから得られた機体番号情報に基づき精算処理を実行する（Ｓ１６）。
【００３４】
なお、本実施例の精算処理については、既存の処理手法に沿って行う。まず、精算機２は機体番号を受信する。次に精算機２は精算時刻、精算金額を特定し、受信した機体番号に関連付けてサーバ３に送信する。なお、本実施例の精算時刻は、精算機２で精算処理のための読み取りが実行された時刻であるものとする。なお、本実施例の精算金額は、精算機２で算出された合計金額であるものとする。サーバ３は、精算機２から受信した機体番号、精算時刻、精算金額と、精算システム１を特定するための精算システムＩＤを合わせて、図示しない決済システムに送信する。決済システムは、決済処理を実行すると実行結果をサーバ３に送信する。以上によって、精算処理が実行される。
【００３５】
精算機２は、画面に表示された知合い検索ボタンの押下があったか否かを判別する（Ｓ１７）。なお、本実施例では、精算機２はユーザから知合い検索処理の依頼を受信したときに知合い検索処理を実行しているが、ユーザＩＤを取得すると、知合い検索を実行するようことをも可能である。精算機２は、例えば、ユーザによるマウスカーソルでクリックやタッチパッドセンサーによるタッチ検出などにより知合い検索ボタンが押されたことを検出する。知合い検索ボタンの押下を検出した場合（Ｓ１７：Ｙｅｓ）と、精算機の精算送受信部２２は、サーバ３にユーザＩＤおよび知合い検索処理依頼を送信する（Ｓ１８）。
【００３６】
サーバ３は知合い検索処理依頼を精算機２から受信すると（Ｓ２３）、知合い検索処理を実行する（Ｓ２４）。知合い検索処理については、後述する。サーバ３は知合い検索処理結果を精算機２に送信する（Ｓ２５）。なお、サーバ３は、知合い検索処理結果として前記当候補がいない場合は「前記当候補なし」を出力し、前記当候補がいる場合は、知合い候補のユーザＩＤおよび当前記ユーザの座席ＩＤを出力する。なお、サーバ３は、知合い候補のユーザがグループである場合、グループに含まれる全ユーザＩＤおよび当前記全ユーザの座席ＩＤを出力する。
【００３７】
精算送受信部２２はサーバ３から現在のユーザの食事相手の候補の座席情報を受信する（Ｓ１９）と、精算機２は、知合検索処理結果を画面に表示する（Ｓ２０）。具体的には、精算機２は、受信した知合い検索処理結果が「前記当候補なし」である場合、前記当候補がいない旨を表示する。また、精算機２は、受信した知合い検索処理結果が「知合い候補のユーザＩＤ」である場合、ユーザテーブル４３からユーザＩＤに対応する情報を読み出す。精算機２は読み出したユーザＩＤに対応する情報を座席ＩＤで特定される座席位置に対応するように表示する。なお、精算機２は、サーバ３から精算中のユーザが着席すべき座席の座席ＩＤを受信し、当前記座席ＩＤの座席位置を画面に表示してもよい。
【００３８】
図６は、Ｓ２０で精算表示部２３が表示する知合い検索処理結果の画面例である。画面には、料理の購入者が購入した料理名、当前記料理の価格、購入した料理の合計金額が表示される。また、画面には「知り合い検索」ボタンが表示される。知合検索処理結果の画面は、知合いの情報と、当前記知合いの座席情報を含む。知合いの情報は、例えば、名前、顔画像など、ユーザが知合いを特定できる情報であればよい。また、食堂内の座席を表示し、食堂内のどの座席に知合いがいるのかを表示する。また、当前記知合いが、一人でいるのか、複数でいるのかについても表示する。なお、知合い検索ボタンが押されたことを検出しない（Ｓ１７：Ｎｏ）と、精算機２は、処理を終了する。例えば、所定時間の経過後に画面表示を消すとしてもよいし、次の精算処理の開始を検出したときに画面の表示を消巣処理にしてもよい。
【００３９】
［着席状況管理処理］
図７は着席状況管理処理のフローチャートである。着席状況は、サーバ３と携帯ホルダ５とにより管理される。本実施例のユーザは、所望の座席に着席したとき、座席に設置された携帯ホルダ５に自分の携帯端末をセットするものとする。図７の処理は、サーバ３と食堂内の全ての携帯ホルダ５との間で行われる。以降、一つの携帯ホルダ５とサーバ３との間の処理を説明するが、他の携帯ホルダ５についても同様の処理を行うものとする。
【００４０】
図８は、食堂内のユーザが食事をする際に着席するテーブルの構成例である。テーブル７には席毎に携帯ホルダ５が設置されている。ユーザは携帯ホルダに自身の携帯端末６をセットすることにより、当前記座席に当前記ユーザが着席していることを携帯ホルダ５に検出させる。携帯ホルダ５は携帯端末６の機体番号を読み出すことにより、ユーザの着席を検出する。
【００４１】
なお、本実施例の携帯ホルダは、各座席に予め設置されている。したがって、携帯ホルダが特定される場合、当前記携帯ホルダに対応する座席が特定される。各携帯ホルダは各座席に予め対応付けられているため、各携帯ホルダはそれぞれに対応する座席ＩＤを記憶しているものとする。
【００４２】
携帯ホルダ５は、ユーザの携帯端末６が置かれたか否かを判別する（Ｓ３１）。携帯ホルダ５の座席リーダライタ部５１は定期的に情報取得のための無線電波を出力する。ユーザによって携帯端末６が携帯ホルダ５に置かれた場合、携帯端末６は、座席リーダライタ部５１から送信された情報取得のための無線電波に対する応答する無線電波を送信する。座席リーダライタ部５１は携帯端末から応答の無線電波を受信した場合に、ユーザの携帯端末６がおかれたと判別する。なお、定期的に行う検出の「定期的」とは、例えば、一秒に一回程度でよい。携帯端末６が置かれていないと判別した場合（Ｓ３１：Ｎｏ）、携帯端末６が置かれたか否かを判別する処理を継続する。
【００４３】
携帯端末６が置かれたと判別した場合（Ｓ３１：Ｙｅｓ）、携帯ホルダ５は、携帯端末６に格納された機体番号を取得し、携帯端末６が置かれた時刻を取得する（Ｓ３２）。Ｓ３２で携帯ホルダが取得した時刻は着席時刻である。携帯ホルダ５は、携帯ホルダ５の座席ＩＤ、Ｓ３２で取得した機体番号および着席時刻をサーバ３に送信する（Ｓ３３）。
【００４４】
サーバ３は座席ＩＤ、機体番号および着席時刻を受信する（Ｓ３７）と、機体番号に対応するユーザＩＤをユーザテーブル４３に基づき特定し、着席履歴テーブル３８に座席ＩＤ、ユーザＩＤおよび着席時刻を記憶する（Ｓ３８）。
【００４５】
図９は、着席履歴テーブル３８の構成例である。着席履歴テーブル３８は、ユーザＩＤ、座席ＩＤ、エリア、着席時刻、離席時刻の情報を含む。ユーザＩＤは、ユーザを識別する情報である。座席ＩＤは、食堂内の座席を識別する情報である。エリアは、食堂内の場所を複数に分割した場所を識別する情報である。着席時刻は、ユーザが携帯端末６を携帯ホルダ５に置いた時刻であり、本実施例ではユーザが着席した時刻である。なお、着席時刻は食事の開始時刻でもある。離席時刻は、ユーザが携帯端末６を携帯ホルダ５に取り上げた時刻であり、本実施例ではユーザが離席した時刻である。なお、着席時刻は食事の終了時刻でもある。
【００４６】
また、サーバ３は座席ＩＤ、ユーザＩＤおよび着席時刻を受信する（Ｓ３７）と、座席テーブル４２の座席ＩＤが対応するレコードに、ユーザＩＤおよび着席時刻を記憶する（Ｓ３９）。また、サーバ３はグループ情報を座席テーブル４２に登録する（Ｓ４３）。グループ情報は、隣席に着席しているユーザ同士が知合いの場合に当前記ユーザ同士はグループであるとして、グループ情報を付加する。このグループ情報は、食事相手検索処理時に使用される。
【００４７】
サーバ３は、座席テーブル４２の隣席の関係にある座席レコードを読み出し、読み出した座席レコードのユーザが互いに知合いか否かを知人関係情報テーブル４０のレコードに基づき判別する。また、サーバ３は、着席時刻が所定の時間内の場合のみ、読み出した座席レコードのユーザがグループであると決定してもよい。
【００４８】
図１０は、座席テーブル４２の構成例である。座席テーブル４２は、座席ＩＤ、エリア、ユーザＩＤ、着席時刻の情報を含む。座席ＩＤは、食堂内の座席を識別する情報である。エリアは、食堂内の場所を複数に分割した場所を識別する情報である。ユーザＩＤは、ユーザを識別する情報である。着席時刻は、ユーザが携帯端末６を携帯ホルダ５に置いた時刻であり、本実施例ではユーザが着席した時刻である。なお、着席時刻は食事の開始時刻でもある。座席テーブル４２は、座席ＩＤの種類の数のレコードを有する。座席ＩＤ，エリアについては固定された情報である。グループ情報は、知合い同士が近隣の座席に着席していることを示す情報である。本実施例ではグループ毎に異なる番号を付加する。座席テーブル４２のユーザＩＤ、着席時刻およびグループ情報は、携帯ホルダがユーザの携帯端末を検出したときに登録され、携帯ホルダがユーザの携帯端末を検出できなくなったときに消去される。
【００４９】
携帯ホルダ５は、携帯端末６の検出ができるか否かを判定する（Ｓ３４）。携帯端末６の検出ができる状態は、例えば、ユーザが食事を継続しており、携帯端末６が携帯ホルダに置かれている状態である。携帯端末６の検出ができなくなった状態は、例えば、ユーザが食事を終了し、携帯端末６を携帯ホルダ５から取り上げた状態である。携帯ホルダ５は、携帯端末６の検出ができる場合（Ｓ３４：Ｙｅｓ）、Ｓ３１で検出した携帯端末６の検出を継続する。携帯ホルダ５は、携帯端末６の検出ができない場合（Ｓ３４：Ｎｏ）、離席時刻を取得する（Ｓ３５）。なお、携帯ホルダ５は、ユーザが携帯ホルダ５から一時的に携帯端末を取り上げた場合に離席であると誤って検出しないように、不検出の時間が所定時間以上連続した場合に離席したと判定してもよい。携帯ホルダ５は、座席ＩＤおよびＳ３５で取得した離席時刻をサーバ３に送信する（Ｓ３６）。
【００５０】
サーバ３は座席ＩＤおよび離席時刻を受信すると（Ｓ４０）、座席テーブル４２の座席ＩＤが合致するレコードのユーザＩＤおよび着席時刻を削除する（Ｓ４１）。また、サーバ３は座席ＩＤおよび離席時刻を受信すると（Ｓ４０）、着席履歴テーブル３８の座席ＩＤが合致するレコードに離席時刻を格納する（Ｓ４２）。
以上の処理によって、精算システム１は着席履歴情報を取得する。
【００５１】
［知合い推定処理］
図１１は、知合い推定処理のフローチャートである。
【００５２】
サーバ３は、着席履歴テーブル３８、ユーザテーブル４３、座席位置テーブル３９に格納された情報に基づき知合い関係を推定し、推定した知合い関係を知人関係情報テーブル４０に格納する。サーバ３は、知合い推定処理を定期的に実行することにより、知合い情報を蓄積する。サーバ３は、同時間帯に同じテーブルで食事をとった複数のユーザの携帯電話識別情報を取得し、取得した複数ユーザは互いに知合いであると推定して知人関係情報テーブル４０に格納する。
【００５３】
サーバ３は例えば一日の着席状況を着席履歴テーブル３８に格納し、当前記着席の履歴に基づき、ユーザ同士が知合いか否かを推定する。
【００５４】
なお、本実施例では、過去の着席の状態から知合い関係を推定する処理を行っているが、ユーザによって予め登録することも可能であるし、サーバ３は、ユーザテーブル４３の情報から部署などの共通点を検索して知合いを推定することも可能である。
【００５５】
本実施例では、サーバ３は、複数の条件を満たした場合に、知合いであると判定する。複数の条件は、（１）知合いの候補のユーザが近隣の座席に着席したこと、（２）着席時刻の差が所定の時間差よりも短いこと、（３）離席時刻の差が所定の時間差よりも短いことである。なお、所定の時間は適宜設定可能であるが、例えば数分以内とすればよい。
【００５６】
サーバ３は、着席履歴テーブル３８の全てのレコードに対して以下の処理を行う。
【００５７】
サーバ３は、着席履歴テーブル３８の一つのレコードを読み出す（Ｓ５１）。サーバ３は、読み出したレコードの座席ＩＤ、着席時刻、離席時刻を特定する。ここで特定した座席ＩＤ、着席時刻、離席時刻は、座席ＩＤ（Ａ）、着席時刻（Ａ）、離席時刻（Ａ）とする（Ｓ５２）。サーバ３は、特定した座席ＩＤ（Ａ）の近隣座席ＩＤを座席テーブル３９から特定する（Ｓ５３）。
【００５８】
図１２は、座席位置テーブル３９の構成例である。座席位置テーブル３９は、座席ＩＤ，近隣座席ＩＤ、エリアを含む。座席ＩＤは、食堂内の座席を識別する情報である。近隣座席ＩＤは、座席ＩＤで特定される座席の近隣に位置する座席を識別する情報である。同一レコードでの座席ＩＤと近隣座席ＩＤとの関係は、ユーザが相席の関係を満たす位置関係である。したがって、近隣座席ＩＤは座席ＩＤの座席の位置によって、数が変わり得る。例えばテーブルの隅の座席の場合、近隣の座席は、向かい側の席と左隣あるいは右隣の席となる。他の場合、近隣の座席は、向かい側の席と左隣および右隣の席となる。また、柱があるなどして、その他の事情により隣の席がない場合などがある。これらの情報を加味して、設定者は予め近隣座席ＩＤを座席ＩＤに関連付けておく。エリアは、食堂内の場所を複数に分割した場所を識別する情報である。
【００５９】
サーバ３は、特定した近隣座席ＩＤにより着席履歴テーブル３８を検索し、近隣座席ＩＤを含むレコードを抽出する（Ｓ５４）。サーバ３は、抽出したレコード群の中から一つの近隣座席ＩＤを含むレコード群を特定する（Ｓ５５）。サーバ３は、特定した一つの近隣座席ＩＤを含むレコード群の内、着席時刻（Ａ）、離席時刻（Ａ）に最も近い着席時刻（Ｂ）、離席時刻（Ｂ）を含むレコードを特定する（Ｓ５６）。
【００６０】
サーバ３は、特定した着席時刻（Ｂ）と着席時刻（Ａ）とは所定時間以内か否かを判別する（Ｓ５７）。所定時間よりも離れている場合（Ｓ５７：Ｎｏ）、処理対象のユーザは近隣座席のユーザと知合いではないと推定する。所定時間以内の場合（Ｓ５７：Ｙｅｓ）、サーバ３は、特定した離席時刻（Ｂ）と離席時刻（Ａ）とは所定時間以内か否かを判別する（Ｓ５８）。所定時間よりも離れている場合（Ｓ５８：Ｎｏ）、処理対象のユーザは近隣座席のユーザと知合いではないと推定する。所定時間以内の場合（Ｓ５８：Ｙｅｓ）、サーバ３は、Ｓ５１で読み出した着席履歴テーブル３８の一つのレコードに記憶されたユーザＩＤとＳ５６で特定した着席履歴テーブル３８のレコードに記憶されたユーザＩＤとの組み合わせが知人関係情報テーブル４０に格納されているか判別する（Ｓ５９）。
【００６１】
図１３は知人関係情報テーブル４０の構成例である。知人関係情報テーブル４０は、ユーザＩＤ１、ユーザＩＤ２、および登録日を含む。ユーザＩＤ１およびユーザＩＤ２は、ユーザを識別するユーザＩＤである。登録日は知人関係情報テーブル４０に登録された日付である。知人関係情報テーブル４０に格納されていない場合（Ｓ５９：Ｎｏ）、サーバ３は、Ｓ５１で処理対象となったユーザＩＤとＳ５６で処理対象となったユーザＩＤの組み合わせを登録する（Ｓ６０）。
【００６２】
サーバ３は、他の近隣座席ＩＤがあるか否かを判別する（Ｓ６１）。他の近隣座席ＩＤがある場合（Ｓ６１：Ｙｅｓ）、サーバ３は次の近隣座席ＩＤについて知り合いか否かを推定するＳ５５以降の処理を実行する。
【００６３】
他の近隣座席ＩＤがない場合（Ｓ６１：Ｎｏ）、サーバ３は着席履歴テーブル３８の全てのユーザについて処理を終了したか否かを判定する（Ｓ６２）。全てのユーザについて処理を終了していない場合（Ｓ６２：Ｎｏ）、着席履歴テーブル３８の次のレコードに対してＳ５１以降の知合いの推定処理を実行する。全てのユーザについて処理を終了した場合（Ｓ６２：Ｙｅｓ）、サーバ３は知合い推定処理を終了する。
【００６４】
以上の処理によって、着席履歴テーブル３８から知合いを推定することができる。なお、本実施例では、一日の履歴で知合いの推定を行ったが、単一の日付だけでなく、複数の日付を加味して知合いの推定を行うことも可能である。例えばサーバ３は、知合いであると推定した複数のユーザの組み合わせの情報を日ごとに格納しておき、複数の日で共通の組み合わせを検出した場合に知合いであると推定するようにしてもよい。
【００６５】
［食事相手検索処理］
図１４は、図２の精算処理において、サーバ３がＳ２４で実行する食事相手検索処理のフローチャートである。サーバ３は、ユーザの要求に応じ、知人関係情報テーブル４０を参照して、ユーザの知人である他のユーザを抽出すると共に、座席位置テーブル３９および座席テーブル４２を参照し、抽出された他のユーザが着席している座席の周囲の空席情報を出力する。本実施例では、精算機２が料理を購入したユーザにより食事相手の知合い検索依頼を入力された場合に、サーバ３が精算機２から知合い検索依頼を受信して検索処理を実行するものとする。サーバ３は、食事相手を検索する際に、単に知合いを表示するのではなく、所定の条件を満たす知合いのみを表示することとする。なお、この時に表示される知合いは、知人関係情報テーブル４０に知合いとして登録されているユーザであり、過去に一緒に食事をしたユーザである。本実施例の所定の条件は、（１）当前記知り合いが着席してから一定時間以内（たとえば３分以内）であること、（２）当前記知り合いが１人あるいは知り合いのみのグループで食事をしていることである。なお、以降の説明において、料理を購入し、一緒に食事をする相手を検索依頼するユーザをユーザＡとする。
【００６６】
サーバ３は、精算機２から受信し一時記憶テーブル４１に格納されたユーザＡのユーザＩＤを元に知合いを検索する。まず、サーバ３は、一時記憶テーブル４１からユーザＡのユーザＩＤを読みだす（Ｓ７１）。次に、サーバ３は、知人関係情報テーブル４０からユーザＡの知合いであるユーザを抽出する（Ｓ７２）。具体的には、サーバ３は、知人関係情報テーブル４０からユーザＡのユーザＩＤを含むレコードを検索する。サーバ３は、検索結果のレコードに含まれるユーザＩＤを抽出する。サーバ３は、抽出したユーザＩＤをユーザＡの知合いのユーザのユーザＩＤとする。なお、Ｓ７２で抽出されたユーザＡの知合いのユーザをユーザＢとする。
【００６７】
次に、サーバ３はＳ７２でユーザＢを抽出できたか否かを判別する（Ｓ７３）。サーバ３は、ユーザＢを抽出できなかった場合（Ｓ７３：Ｎｏ）、ユーザＡの知合いが知人関係情報テーブル４０に登録されていないことにより知合いを検索できなかったため、検索結果として「前記当候補なし」を精算機２に出力する（Ｓ８０）。
【００６８】
サーバ３は、一人以上のユーザＢを抽出できた場合（Ｓ７３：Ｙｅｓ）、抽出できたユーザＢに対してそれぞれＳ７４以降の処理を行う。サーバ３は、座席テーブル４２の各座席レコードのユーザＩＤを読み出し、読み出したユーザＩＤと処理対象のユーザＢのユーザＩＤとが合致するか否か判別し、合致する座席レコードが存在するか否かにより、ユーザＢが着席状態か否かを判別する（Ｓ７４）。
【００６９】
サーバ３は、座席テーブル４２に存在しない場合（Ｓ７４：Ｎｏ）、次の処理対象のユーザＢについてＳ７４以降の処理を実行する。サーバ３は、座席テーブル４２に存在する場合（Ｓ７４：Ｙｅｓ）、座席テーブル４２のグループ情報を参照することにより、ユーザＢは一人か否かを判別する（Ｓ７５）。
【００７０】
ユーザＢが複数の場合（Ｓ７５：Ｎｏ）、サーバ３は、ユーザＢのグループを構成する全ユーザとユーザＡとが知り合いか否かを判別する（Ｓ７９）。ユーザＢが候補として検索された場合であっても、ユーザＢがユーザＡの知らない人と一緒である場合、ユーザＡが邪魔になることがある。よって、本実施例では、サーバ３は、ユーザＢのグループを構成する全ユーザとユーザＡとが知り合いでない場合（Ｓ７９：Ｎｏ）、食事相手の候補としない。
【００７１】
図１５は座席の状態を示す例である。図１５は、食堂内のＡ１エリアを示す。Ａ１エリアは一つのテーブルがあり、当前記テーブルは６席（Ｔ００１，Ｔ００２，Ｔ００３，Ｔ００４，Ｔ００５，Ｔ００６）有する。例えば、Ｔ００１に着席中のユーザ「Ｕ００５」とＴ００２に着席中のユーザ「Ｕ０２１」とは知合いである。ユーザ「Ｕ００５」はユーザ「Ｕ０２１」と食事中である。同様に、Ｔ００５に着席中のユーザ「Ｕ００６」とＴ００６に着席中のユーザ「Ｕ０２５」とは知合いである。ユーザ「Ｕ００６」はユーザ「Ｕ０２５」と食事中である。Ｔ００３およびＴ００４は空席である。ユーザＡ（例えばユーザ「Ｕ００１」）が精算したとする。ユーザ「Ｕ００１」はユーザ「Ｕ００５」およびユーザ「Ｕ０２１」と知合いであるとする。ユーザ「Ｕ００１」はユーザ「Ｕ００５」およびユーザ「Ｕ０２１」と知合いである場合、Ｔ００３およびＴ００４が空席であるため、食事相手の候補として表示される場合がある。ユーザＡがユーザ「Ｕ００５」あるいはユーザ「Ｕ０２１」のどちらか一方のみと知合いである場合、本実施例では食事相手の候補として表示されない。
【００７２】
サーバ３は、ユーザＢが一人の場合（Ｓ７５：Ｙｅｓ）、あるいは、ユーザＢのグループを構成する全ユーザとユーザＡとが知り合いの場合（Ｓ７９：Ｙｅｓ）、ユーザＢの隣席が空いているか否かを判別する（Ｓ７６）。ユーザＢの隣席が空いていない場合（Ｓ７６：Ｎｏ）、ユーザＡがユーザＢと一緒に食事ができる座席がないため、次の処理対象のユーザＢについてＳ７４以降の処理を実行する。ユーザＢの隣席が空いている場合（Ｓ７６：Ｙｅｓ）、サーバ３は、ユーザＢが食事を開始した時刻から現在の時刻までの時間は、所定の時間内か否かを判別する（Ｓ７７）。なお、グループを構成する全ユーザがユーザＡと知合いである場合、サーバ３は、当前記グループを構成する全ユーザについて、Ｓ７４乃至Ｓ７９の処理を実行することになる。
【００７３】
サーバ３は、抽出されたユーザＢのうち、所定時間以上、継続して着席していない他のユーザを食事相手の候補として抽出する。所定の時間よりも長い時間が経過している場合（Ｓ７７：Ｎｏ）、ユーザＢとユーザＡの食事時間のずれが大きくなるため、次の処理対象のユーザＢについてＳ７４以降の処理を実行する。所定の時間内である場合（Ｓ７７：Ｙｅｓ）、サーバ３は、処理対象のユーザＢを知り合いの候補として記憶する（Ｓ７８）。サーバ３は、Ｓ７３で抽出した全ユーザＢについてＳ７４乃至Ｓ７９の処理を実行した後、知合い検索処理結果として、ユーザＡに知合いの候補が居ない場合には「前記当候補なし」を出力し、ユーザＡに知合いの候補が居る場合には、知合い候補のユーザＩＤおよび知合い候補の着席する座席ＩＤを出力する（Ｓ８０）。なお、サーバ３は、知合い候補のユーザがグループである場合、グループに含まれる全ユーザＩＤおよび当前記全ユーザの座席ＩＤを出力する。  なお、サーバ３は、ユーザＡが着席すべき座席の座席ＩＤを精算機２に送信してもよい。
【００７４】
サーバ３は、Ｓ２５において、Ｓ８０の知合い検索処理結果（「前記当候補なし」あるいは知合い候補のユーザＩＤ）を精算機２に出力する。
【００７５】
なお、サーバ３は、知合いの候補が多い場合、所定の数に絞込みを行って表示をすることも可能である。例えば、食事の開始時刻が最近のユーザから順番に所定の上位の人数だけ表示することも可能である。また、サーバ３は、着席から離席までの時間を記憶することで、各ユーザの食事の平均時間を算出して記憶しておき、知合い検索のときにおいては、食事の終了予定時刻が一致するようなユーザを特定するようにしても良い。例えば、サーバ３は、ユーザＡの食事終了予想時刻を、現在の時刻（精算の時点）にユーザＡの平均食事時間を加えた時間から算出する。また、サーバ３は食事相手の候補の食事終了予想時刻を、着席時刻にユーザＢの平均食事時間を加えた時間から算出する。サーバ３は、ユーザＡの食事終了予想時刻とユーザＢの食事終了予想時刻とが所定の時間差よりも小さい場合に食事相手の候補として出力することも可能である。
【００７６】
なお、サーバ３は、Ｓ８０において知合い候補のユーザＩＤだけでなくユーザＡが座るべき座席ＩＤをあわせて出力することも可能である。この構成とした場合、精算機２にさらに座席予約ボタンを表示する機能を設け、ユーザＡにより座席予約をボタンが押されたことを検出すると、座席の予約をすることも可能である。例えば、精算機２は座席予約依頼を送信し、サーバ３は当前記予約を受信すると、座席テーブル４２の対応する座席ＩＤのレコードにユーザＩＤおよび着席時刻を仮登録する。なお、食堂内の各携帯ホルダ５は予め表示機能を設けられており、ユーザＡに仮登録された携帯ホルダ５は、ユーザＡの着席を示す情報を表示することも可能である。サーバ３は所定時間以内にユーザＡの着席を検出できなかった場合、あるいはユーザＡが他の座席に着席したことを検出した場合に、当前記仮登録したレコードを削除する。サーバ３は、仮登録の機能により、例えば、精算機２で知り合いではない複数のユーザが短期間に共通のユーザを食事相手として表示されることを防止することができる。このような構成にすることにより、より正確に食事相手を検索することが可能になる。
【００７７】
［ハードウェア構成］
図１６は、本実施例のハードウェア構成の一例である。精算システム１は、少なくとも一台の精算機２、サーバ３、および複数の携帯ホルダ５を有する。
【００７８】
精算機２は、ＣＰＵ（中央処理装置）２０１、ＲＡＭ（Ｒａｍｄｏｍ  Ａｃｃｓｅｓｓ  Ｍｅｍｏｒｙ）２０２、ＲＯＭ(Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ)２０３、Ｉ／Ｆ（インターフェース）２０４、ディスプレイ２０５、リーダライタ２０６を有し、それぞれバスを介してデータ通信を行う。ＲＯＭ２０３には、ＣＰＵ２０１が実行するプログラムが記憶されている。ＣＰＵ２０１は、ＲＯＭ２０３に記憶されたプログラムを読み込みながら処理を行うことで、精算機２としての各種処理を行う。ＲＡＭ２０２は、ＣＰＵ２０１のプログラム実行の際の一時データを格納する。また、このＲＡＭ２０２は、後述するリーダライタ２０６で取得したユーザＩＤ、サーバ３から受信したユーザＩＤ，座席ＩＤなどが格納される。また、各テーブルの情報を記憶することも可能である。ＣＰＵ２０１が、データを取得・記憶する記載がある場合、実際には、ＲＡＭ２０２に一時的に前記データを記憶させているものとする。Ｉ／Ｆ(インターフェース)２０４は、サーバ３との通信を行うものである。ディスプレイ２０５は、精算画面、知合い相手検索処理結果を表示する。リーダライタ２０６は、携帯端末６との通信を行うものである。本実施例の携帯端末６には非接触ＩＣチップが搭載されており、無線により通信を行う。
【００７９】
サーバ３は、ＣＰＵ（中央処理装置）３０１、ＲＡＭ（Ｒａｍｄｏｍ  Ａｃｃｓｅｓｓ  Ｍｅｍｏｒｙ）３０２、ＲＯＭ(Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ)３０３、Ｉ／Ｆ（インターフェース）３０４を有する。ＲＯＭ３０３には、ＣＰＵ３０１が実行するプログラムが記憶されている。ＣＰＵ３０１は、ＲＯＭ３０３に記憶されたプログラムを読み込みながら処理を行うことで、サーバ３としての各種処理を行う。ＲＡＭ３０２は、ＣＰＵ３０１のプログラム実行の際の一時データを格納する。また、このＲＡＭ３０２は、各テーブルの情報を記憶する。ＣＰＵ３０１が、データを取得・記憶する記載がある場合、実際には、ＲＡＭ３０２に一時的に前記データを記憶させているものとする。Ｉ／Ｆ(インターフェース)３０４は、精算機２および携帯ホルダ５との通信を行うものである。
【００８０】
携帯ホルダ５は、ＣＰＵ（中央処理装置）５０１、ＲＡＭ（Ｒａｍｄｏｍ  Ａｃｃｓｅｓｓ  Ｍｅｍｏｒｙ）５０２、ＲＯＭ(Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ)５０３、Ｉ／Ｆ（インターフェース）５０４、リーダライタ５０５を有する。ＲＯＭ５０３には、ＣＰＵ５０１が実行するプログラムが記憶されている。ＣＰＵ５０１は、ＲＯＭ５０３に記憶されたプログラムを読み込みながら処理を行うことで、携帯ホルダ５としての各種処理を行う。ＲＡＭ５０２は、ＣＰＵ５０１のプログラム実行の際の一時データを格納する。また、このＲＡＭ５０２は、後述するリーダライタ５０５で取得したユーザＩＤなどが格納される。また、各テーブルの情報を記憶することも可能である。ＣＰＵ５０１が、データを取得・記憶する記載がある場合、実際には、ＲＡＭ５０２に一時的に前記データを記憶させているものとする。Ｉ／Ｆ(インターフェース)５０４は、サーバ３との通信を行うものである。リーダライタ５０５は、携帯端末６との通信を行うものである。本実施例の携帯端末６には非接触ＩＣチップが搭載されており、無線により通信を行う。
【００８１】
［その他］
以上に説明した精算システム１は、社員食堂や学生食堂等の特有の場所および状況下での問題を解決できる。一般のレストラン等と異なり、社員食堂や学生食堂で食事をする場合、知り合いと会う可能性が高い。このため、一緒に食事をする相手を探したい場合がある。
【００８２】
事前に携帯電話を用いて、特定の知り合いと待ち合わせをすることもできるが、相手が社員食堂等に行くかどうか、相手が社員食堂等に行く時刻が合うかとか等が不明である。また、食堂でメニューを選んでいる時などに、携帯電話等を利用して食事相手を探すことも想定できるが、食べ物を載せたトレーを持っているため両手が使えず、携帯電話の操作が困難な場合もある。また、メニューを選ぶのに時間がかかったり、精算機が混雑して待たされたりする場合があるので、本人も、相手も、食べ始めのタイミングを確定できないので、所定の時刻に待ち合わせするのが困難な事情がある。
【００８３】
さらに、精算後に社員食堂内にいる食事相手を目視で探すこともできるが、相手が見つかっても、相手が食べ終わりの場合だと、途中で相席すると、自分が食べ終わるまで相手を待たせることになってしまう問題が懸念される。その他、相手が見つかっても、知らない人が一緒だったり、席が空いてなかったりする問題が懸念される。
【００８４】
以上に説明した精算システム１は、社員食堂や学生食堂等で起こり得る上記の問題を解決できるため、ユーザは効率的に食事の相手を探すことができる。
【００８５】
また、以上に説明した精算システムは、社員食堂や学生食堂等の特有の場所および状況下において、食事相手の隣席等が空いている、食事相手が知らない人と食事中ではない、食事相手が食べ始めたばかりである、といった条件を満たす場合にのみ、食事相手の隣席を表示する。このため、本精算システムは、すでに食事中の知人にとっても、精算中の本人にとっても、効率的に食事相手を探せる有利な効果がある。
【００８６】
以上の本実施例では、携帯端末に組み込まれたＩＣチップを使用する例を説明したが、これに限らず、ＩＣカード、バーコードなど、ユーザを識別可能な技術を使用することも可能である。また、携帯端末のネットワーク通信機能を使用して実施することも可能である。
【符号の説明】
【００８７】
１  精算システム
２  精算機
３  サーバ
５  携帯ホルダ
２１  精算リーダライタ部
２２  精算送受信部
２３  精算表示部
３１  精算機−サーバ送受信部
３２  携帯ホルダ−サーバ送受信部
３３  精算処理部
３４  座席管理部
３５  着席履歴管理部
３６  知合い推定処理部
３７  食事相手検索処理部
３８  着席履歴テーブル
３９  座席位置テーブル
４０  知人関係情報テーブル
４１  一時記憶テーブル
４２  座席テーブル
４３  ユーザテーブル
【図１】
2013030049.tif 000003
【図２】
2013030049.tif 000004
【図３】
2013030049.tif 000005
【図４】
2013030049.tif 000006
【図５】
2013030049.tif 000007
【図６】
2013030049.tif 000008
【図７】
2013030049.tif 000009
【図８】
2013030049.tif 000010
【図９】
2013030049.tif 000011
【図１０】
2013030049.tif 000012
【図１１】
2013030049.tif 000013
【図１２】
2013030049.tif 000014
【図１３】
2013030049.tif 000015
【図１４】
2013030049.tif 000016
【図１５】
2013030049.tif 000017
【図１６】
2013030049.tif 000018