JP2007304637A

JP2007304637A - 公開予約処理サーバ

Info

Publication number: JP2007304637A
Application number: JP2006129156A
Authority: JP
Inventors: Kanji Kuwabara; 寛治桑原
Original assignee: TECHNO PLANNING KK
Current assignee: TECHNO PLANNING KK
Priority date: 2006-05-08
Filing date: 2006-05-08
Publication date: 2007-11-22
Anticipated expiration: 2026-05-08
Also published as: JP5049509B2

Abstract

【課題】複数の顧客端末と複数の店舗端末とネットワークで接続される公開予約処理サーバにおいて、顧客と店舗との間の予約条件に関する情報交換と、個人情報の流出の抑制を可能とすることである。
【解決手段】公開予約処理システム１０は、ネットワーク１２に複数の顧客端末２０等と、複数の店舗端末３０等と公開予約処理サーバ４０とが接続される。公開予約処理サーバ４０のＣＰＵ４２は、顧客及び店舗の個人識別情報と識別処理ネームとを関連付けて登録する登録部５２と、顧客端末２０，２１，２２からのイベント公開依頼を受け付けて公開予約処理サイトに公開する顧客依頼公開部５４と、店舗端末３０，３１，３２からのイベント公開依頼を受け付けて公開予約処理サイトに公開する店舗依頼公開部５６と、顧客側と店舗側との間の予約処理を実行する予約処理部５８を含んで構成される。
【選択図】図１

Description

本発明は公開予約処理サーバに係り、特に、複数の顧客端末及び複数の店舗端末とネットワークで接続され、顧客端末と店舗端末との間を仲介して店舗予約処理を行う公開予約処理サーバに関する。

インターネット等の発達に伴い、例えば特許文献１に示されるように、ネットワーク上でユーザが店舗に直接アクセスし、買物の注文や宿泊、切符等の予約を行うことが盛んに行われている。このように代金の決済が関係する注文や予約については、例えばキャッシュカードの番号等を入力することで個人識別と、注文や予約の意思確認が行われることが多い。

また、特許文献２に示されるように様々なイベント情報又は買物情報、旅行情報等の情報交換にもネットワークが盛んに用いられる。その１つの例はユーザが書き込み可能な掲示板形式の情報交換サイトである。この情報交換サイトにおいては、あるユーザが情報をそのサイトに公開することで、そのサイトにアクセスし、その情報を知って興味を持った他のユーザが、同じサイトに別の関連情報を公開する。このように、情報交換が複合的に行われ、多くの関連情報が短時間に交換される。例えば、特定の希少価値の商品を入手したいユーザが、その旨を情報交換サイトに公開することで、その商品の情報を知っている他のユーザから数多くの関連情報がそのサイトに寄せられる。

このように、ネットワークを介して、商品情報の交換、商品の予約、その決済等が行われていることはよく知られている。

特開２００５-３３２１３４号公報特開２００５-３４６２９９号公報

ネットワークを介する商品の予約及び決済は、いわゆる対面予約及び対面決済でない等のために、互いによく相手のことを知らない同士で商品の予約及び決済を行う危険がある。その危険を出来るだけ回避するために、売主等は、買主の個人情報の提供を要求し、買主の支払能力の担保を図ろうとする。実際に、ネットワークを介する商品の予約及び決済には、買主のクレジットカードの番号等の他に、買主の住所、電話番号、ＦＡＸ番号、電子メールアドレス、年齢、勤務先等の個人情報の開示をその都度要求されることが多いことは周知の事実である。したがって、ネットワークを介しての商品の予約及び決済は、常に個人情報の流出の危険を伴っている。

また、ネットワークを介して商品を得ようとする場合、店頭購買でなく、いわゆるカタログ購買等になることが多い。そこで、商品比較をするためにネットワークを介した商品情報の交換が用いられる。この商品情報の交換は、公開サイトによる自由な情報交換で、個人情報の開示を求められることは少ない。しかし逆にその自由性のために、予約条件の交換までに至らないことが多い。したがって、この場合でも、必要な商品情報が得られても、その商品についての予約条件をネットワーク上で詰めようとすると、やはりクレジットカード番号を含めた個人情報の開示が求められることになる。

このように、ネットワークを介しての商品の予約及び決済は便利ではあるが、個人情報の流出の危険がある。

本発明の目的は、複数の顧客端末と複数の店舗端末とネットワークで接続され、個人情報の流出の抑制を可能とする公開予約処理サーバを提供することである。本発明の他の目的は、複数の顧客端末と複数の店舗端末とネットワークで接続され、顧客と店舗との間の予約条件に関する情報交換を可能とする公開予約処理サーバを提供することである。

本発明に係る公開予約処理サーバは、複数の顧客端末及び複数の店舗端末とネットワークで接続される公開予約処理サーバであって、各顧客の顧客ＩＤに対応付けて個人情報を含まない顧客ハンドルネームと、各店舗の店舗ＩＤに対応付けて店舗名を含む店舗識別ネームとを、公開予約処理における識別処理ネームとして各顧客及び各店舗にそれぞれ割り当てて登録する登録部と、顧客端末からの企画内容公開依頼データを受信し、登録された顧客ＩＤによる依頼であるか否かを判断し、登録された顧客ＩＤによる依頼であると判断するときに、公開予約処理サイトに依頼データを顧客ハンドルネームとともに公開する顧客依頼公開部と、公開予約処理サイトにおける企画内容に応答する店舗端末からの企画対応提案公開依頼であり、その提案公開に応答して登録された顧客ＩＤによる予約があるときはその予約を承認する内容である提案公開依頼を受信し、登録された店舗ＩＤによる依頼であるか否かを判断し、登録された店舗ＩＤによる依頼であると判断するときに、公開予約処理サイトに依頼データを店舗識別ネームとともに公開する店舗依頼公開部と、公開予約処理サイトにおける提案内容に応答する顧客端末からの予約申込を受信し、登録された顧客ＩＤによる予約申込であるか否かを判断し、登録された顧客ＩＤによる予約申込であると判断するときは、予約が成立したものとして、対応する店舗端末と顧客端末に対し予約成立処理を行う予約処理部と、を備えることを特徴とする。

また、本発明に係る公開予約処理サーバは、複数の顧客端末及び複数の店舗端末とネットワークで接続される公開予約処理サーバであって、各顧客の個人識別情報に対応付けて個人情報を含まない顧客ハンドルネームと、各店舗の店舗識別情報に対応付けて店舗名を含む店舗識別ネームとを、公開予約処理における識別処理ネームとして各顧客及び各店舗にそれぞれ割り当てて登録する登録部と、店舗端末からの企画提案公開依頼データを受信し、そのデータがその公開に応答して登録された顧客ＩＤによる予約があるときはその予約を承認する内容である企画提案公開依頼データであって、登録された店舗ＩＤによる依頼であると判断するときに、公開予約処理サイトに依頼データを店舗識別ネームとともに公開する店舗依頼公開部と、公開予約処理サイトにおける提案内容に応答する顧客端末からの予約申込を受信し、登録された顧客ＩＤによる予約申込であるか否かを判断し、登録された顧客ＩＤによる予約申込であると判断するときは、予約が成立したものとして、対応する店舗端末と顧客端末に対し予約成立処理を行う予約処理部と、を備えることを特徴とする。

また、予約処理部は、予約成立に対応する顧客端末及び店舗端末に対し、それぞれ予約成立内容を送信する予約成立送信手段を有することが好ましい。

また、本発明に係る公開予約処理サーバにおいて、登録部は、店舗識別情報として、予約成立内容に応じたその店舗における顧客の支払に対する割引率を含んで登録し、予約成立送信手段は、顧客端末に対し、割引率を含む予約成立内容を、顧客端末から顧客側携帯端末に転送可能で、かつ店舗端末で読み取れるデータ形式を用いて送信することが好ましい。

また、予約成立送信手段は、顧客端末に対し、割引率を含めた予約成立内容を２次元バーコードのデータ形式で送信することが好ましい。

また、本発明に係る公開予約処理サーバにおいて、店舗端末から、顧客側携帯端末より読み取ったデータを含めて送信される来店情報を受信する来店実績受信手段と、顧客端末に対し、来店情報に応じた来店確認情報を送信する来店確認送信手段と、を備えることが好ましい。

また、本発明に係る公開予約処理サーバにおいて、公開予約処理サイトにおける企画内容に応答する第２の顧客端末からの参加提案公開依頼データを受信し、登録された顧客ＩＤによる依頼であるか否かを判断し、登録された顧客ＩＤによる依頼であると判断するときに、公開予約処理サイトに、参加を希望する企画内容と関連付けて、参加提案依頼データをその顧客ハンドルネームとともに公開する参加依頼公開部を備えることが好ましい。

また、本発明に係る公開予約処理サーバにおいて、各店舗端末から送信されるイベント掲載依頼データを記憶し、各顧客端末からのアクセスを許可する店舗データベースを備えることが好ましい。

上記構成の少なくとも１つにより、各顧客の顧客ＩＤに対応付けて個人情報を含まない顧客ハンドルネームと、各店舗の店舗ＩＤに対応付けて店舗名を含む店舗識別ネームとを、公開予約処理における識別処理ネームとして登録する。そして、顧客端末からの企画内容依頼データの公開も、店舗端末からの企画対応提案依頼データも、この公開予約処理における識別処理ネームと共に公開され、顧客端末からの予約申込のときにも、顧客の個人情報等は、店舗側に開示されない。顧客側からの予約申込によって予約が成立しているかどうかは公開予約処理サーバが判断する。したがって、予約処理の際における顧客の個人情報の店舗側への流出の抑制が可能となる。また、顧客端末からの企画内容データと、店舗端末からの企画対応提案データとの双方が公開されるので、顧客と店舗との間の予約条件に関する情報交換が可能になる。

また、上記構成の少なくとも１つにより、顧客ハンドルネームと店舗識別ネームとが公開予約処理における識別処理ネームとして登録される。そして、店舗端末からの企画提案依頼データはこの識別処理ネームを用いて公開される。また、これに応答する顧客端末からの予約申込のときに、顧客端末の個人情報等は、店舗側に開示されない。顧客側からの予約申込によって予約が成立しているかどうかは公開予約処理サーバが判断する。したがって、予約処理の際における顧客の個人情報の店舗側への流出の抑制が可能となる。また、店舗端末からの企画対応提案データが公開されるので、顧客と店舗との間の予約条件に関する情報交換が可能になる。

また、予約成立に対応する顧客端末及び店舗端末に対し、それぞれ予約成立内容を送信するので、両当事者自身で予約に関してやり取りをする必要がなく、店舗側の個人情報の不必要な流出も抑制できる。

また、店舗識別情報として登録されるその店舗の割引率が、顧客端末から顧客側携帯端末に転送可能で、かつ店舗端末で読み取れるデータ形式を用いて送信されるので、顧客は、携帯端末にその割引率条件を転送して記憶させ、それを店舗に持参して割引率の提供を確実に受けることが可能となる。

また、割引率を含めた予約成立内容は２次元バーコードのデータ形式で送信されるので、十分なデータ量の予約成立条件を送信することが出来る。

また、店舗端末から来店実績を受信すると、顧客端末に対し、これを来店確認情報として送信するので、店舗端末における来店実績の正確さを顧客端末で確認され、来店実績データの信頼性を向上させることが出来る。

また、公開予約処理サイトにおける企画内容に応答する第２の顧客端末からの参加提案公開依頼データを受信してこれを公開するので、第３者からの企画参加を可能にする。

また、各店舗端末から送信されるイベント掲載依頼データに各顧客端末のアクセスが許可されるので、顧客端末から、希望のイベントを自由に検索が可能になる。

上記のように、本発明に係る公開予約処理サーバによれば、個人情報の流出を抑制して、ネットワーク上で顧客と店舗との間の予約処理を行うことが出来る。また、本発明に係る公開予約処理サーバによれば、ネットワーク上で、顧客と店舗との間の予約条件に関する情報交換が可能となる。

以下に図面を用いて本発明に係る実施の形態につき詳細に説明する。以下において、予約の対象は、一般ユーザである顧客側の会合や宴会等のイベント企画と、店舗側の催すクリスマスや納涼等のイベント企画のように、飲食会合イベントについて説明するが、これ以外の企画でも、顧客側と店舗側との間の予約が関連するものを対象としてもよい。例えば、商品のバザー企画や、グループ旅行企画等であってもよい。以下における公開サイトの画面は一例であり、これ以外の画面構成であってもよい。例えば、店舗情報、イベント情報等のさらなる階層的検索が可能な画面構成にしてもよい。

図１は、公開予約処理システム１０の構成を示す図である。公開予約処理システム１０は、インターネット等のネットワークに接続された複数の顧客端末２０，２１，２２と、複数の店舗端末３０，３１，３２を通して、顧客と店舗との間で公開予約処理サーバ４０の提供する公開サイト上で予約条件を含めた情報交換を行い、条件が折り合った場合には公開予約処理サーバ４０が予約処理を行うためのシステムである。このシステムにおいては、ネットワーク上の情報交換、予約処理等において、顧客側の個人情報、及び店舗側の個人的情報が相互に不必要に流出しないように、公開予約処理サーバ４０が登録管理する識別処理ネームを用いる。すなわち、顧客側は個人情報を含まない顧客ハンドルネーム、店舗側は店舗名を含むが電子メールアドレス等の情報等を含まない店舗識別ネームを、ネットワーク上における識別処理ネームとして用いる。

顧客端末２０，２１，２２は、各一般ユーザである顧客が有し、ネットワーク１２に接続される通信端末で、パーソナルコンピュータ（ＰＣ）、ＰＤＡ（ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓｉｓｔａｎｔ）や携帯電話等の移動通信端末である。店舗端末３０，３１，３２は、各店舗に備えられ、ネットワーク１２に接続される通信端末で、ＰＣ等のコンピュータ端末、及び移動通信端末等である。

公開予約処理サーバ４０は、ネットワーク１２を介して顧客端末２０，２１，２２及び店舗端末３０，３１，３２に接続されるデータ蓄積及び処理のための装置で、適当な記憶容量の記憶装置を有するコンピュータで構成される。公開予約処理サーバ４０は、ＣＰＵ４２と、顧客側イベント情報及び店舗側イベント情報等のデータを記憶する記憶装置４４と、ネットワーク１２に接続される通信制御部４６と、キーボード等の入力部４８、ディスプレイ等の出力部５０を含んで構成される。これらの要素は相互に内部バスで接続される。

ＣＰＵ４２は、顧客及び店舗の個人識別情報と識別処理ネームとを関連付けて登録する登録部５２と、顧客端末２０，２１，２２からのイベント公開依頼を受け付けて公開予約処理サイトに公開する顧客依頼公開部５４と、店舗端末３０，３１，３２からのイベント公開依頼を受け付けて公開予約処理サイトに公開する店舗依頼公開部５６と、顧客側と店舗側との間の予約処理を実行する予約処理部５８を含んで構成される。これらの機能は、ソフトウェアを実行することで実現され、具体的には、対応する公開予約処理プログラムを実行することで実現される。これらの機能の一部をハードウェアで構成することもできる。

上記構成の公開予約処理システム１０の作用を、特に公開予約処理サーバ４０の各機能を中心に、公開予約処理サーバ４０と各顧客端末２０，２１，２２と各店舗端末３０，３１，３２との相互作用に関連付けて、以下に詳細に説明する。

図２は、公開予約処理サーバ４０の登録部５２の機能を説明する図である。登録部５２は、公開予約処理システムの利用を希望する顧客及び店舗からの登録申込を、各顧客端末２０，２１，２２と各店舗端末３０，３１，３２を介して受信し、所定の処理を行って登録の可否を判断し、登録可と判断するとき、登録を行う機能を有する。また、登録部５２は、登録可と判断すると、各顧客端末２０，２１，２２にそれぞれ顧客ＩＤと顧客ハンドルネームとを、各店舗端末３０，３１，３２にそれぞれ店舗ＩＤと店舗識別ネームとを付与する機能を有する。

すなわち、図２において、各顧客端末２０，２１，２２から登録申込があると公開予約処理サーバ４０はこれを受信し（Ｓ１０）、登録可否判断に従って登録可のときは登録し、登録可となった顧客に、顧客ＩＤを付与するとともに公開予約処理における識別処理ネームとして顧客ハンドルネームを付与して各顧客端末２０，２１，２２を通して通知する（Ｓ１２）。同様に、各店舗端末３０，３１，３２から登録申込があると公開予約処理サーバ４０はこれを受信し（Ｓ１４）、登録可否判断に従って登録可のときは登録し、登録可となった店舗に、店舗ＩＤを付与するとともに公開予約処理における識別処理ネームとして店舗識別ネームを付与して各店舗端末３０，３１，３２を通して通知する（Ｓ１６）。

公開予約処理システムの利用を希望する各顧客又は各店舗が、公開予約処理サーバ４０に登録申込をするには、上記のように、顧客端末２０，２１，２２又は店舗端末３０，３１，３２を通しネットワーク１２を介して行うことができる。すなわち、公開予約処理システムを管理する公開予約処理運営会社のホームページ等にアクセスし、公開予約処理システムの利用のための登録申込フォーマットに必要事項を入力することで、登録申込を行うことができる。もちろん、顧客等が直接公開予約処理運営会社に赴き、登録申込用紙の配布を受けて、必要事項を記入し、これを提出することで勿論可能である。

顧客は、個人の資格で登録申込をすることができるが、複数人で構成するグループで登録申込をすることができる。一般的にこのようなグループは法人等の資格を有していないので、予約等の行為を行うために、グループの代表者をグループリーダと定め、グループリーダの名前で登録申込を行ことができる。店舗の場合は、通常、法人であることが多いので、その場合にはその法人店舗の資格で登録申込ができる。

登録申込に必要な事項は、顧客の場合は、グループリーダについて、その氏名、住所、電話番号、ＦＡＸ番号、電子メールアドレス、クレジットカード番号等の個人情報と、グループの具体的目的等である。グループの構成人数、構成員の氏名、連絡先等も場合により必要事項とできる。

店舗の場合は、店舗名称、住所、電話番号、ＦＡＸ番号、電子メールアドレス、営業内容等の店舗に関する個人情報を含む情報と、公開予約処理システムの利用について、店舗側から顧客に提供できる割引率等の優遇条件等である。

また、公開予約処理システムにおいて処理される条件の承認も登録申込に必要な事項である。公開予約処理システムにおいて処理される条件とは、その後において公開予約処理サーバ４０が処理する手順に含まれる条件のことで、（１）顧客側又は店舗側が提案するイベントを公開予約処理システム上で公開するときは、顧客ハンドルネーム又は店舗識別ネームで行うこと、（２）予約処理は、顧客ＩＤ及び店舗ＩＤで行うこと、（３）店舗側が提案するイベントを公開するときは、その公開に応答して顧客ＩＤによる予約があるときはその予約を承認するものとみなされること、を含む。

すなわち、公開予約処理システムにおいては、（１）の条件でもって、予約処理に伴う不必要な個人情報の流出を防ぐために、公開サイトにおいては、顧客ハンドルネーム又は店舗識別ネームのみに関連付けてイベント内容が公開される。そして（２）の条件でもって、予約処理は、顧客本人と公開予約処理サーバ４０のみが把握している顧客ＩＤ、及び店舗本人と公開予約処理サーバ４０のみが把握している店舗ＩＤで実行処理が行われる。さらに、（３）の条件によって、店舗側の提案が顧客側の申込を停止条件とする申込の承諾であることとして、顧客の申込のときに原則として予約が成立することとする。

登録部５２は、予め定められている登録チェック手順に従い、登録申込に必要な事項が入力されているか、公開予約処理システムにおいて処理される条件の承認の入力がされているかをデータ上で確認し、必要な要件がすべて入力されていることが確認されると、登録可と判断する。登録可と判断されると、登録部５２は、これらの個人情報に関連付けて、顧客ＩＤと顧客ハンドルネーム、あるいは店舗ＩＤと店舗識別ネームを予め定められた手順で作成する。顧客ＩＤ及び店舗ＩＤは、これでもって公開予約処理の実行を行うＩＤであり、例えば英数字の組み合わせで作成される。顧客ハンドルネームと店舗識別ネームは、公開予約処理サイトにおいて表示される識別処理ネームであるので、いずれも個人的情報を含まない。具体的には、重複がなければ、顧客ハンドルネームについてはグループ名を、店舗識別ネームについては店舗名をそのまま用いることとして作成される。

登録部５２は、作成された顧客ＩＤと顧客ハンドルネーム、あるいは店舗ＩＤと店舗識別ネームを、それぞれの対応する個人的情報と関連付けて登録する。具体的には、これらのデータを記憶装置４４に記憶する。図３は、顧客端末に関する登録データの例で、図４は、店舗端末に関する登録データの例である。これらに示されるように、顧客については、グループリーダの氏名、住所等とクレジットカード番号等の個人情報が、顧客ＩＤ６０及び顧客ハンドルネーム６２と関連付けて登録される。図３の場合、顧客ハンドルネーム６２は、グループ名であって、グループリーダの個人情報を一切含んでいないことが示される。また、店舗については、店舗の名称、住所、電子メールアドレス等の店舗に関する個人情報が、店舗ＩＤ６４と店舗識別ネーム６６と関連付けて登録される。図４に示されるように、店舗の場合には、予約の便宜上、店舗識別ネーム６６は店舗名が使用される。これは一般に通用している店舗名は個人的情報ではなく、むしろその営業を表示するものであるからである。また、店舗の場合には、この公開予約処理システムを通した場合の料金割引条件が登録される。

このように、登録部５２の機能により、公開予約処理サーバ４０が処理する手順の承認の下で利用を希望する顧客及び店舗が、顧客ＩＤ６０と顧客ハンドルネーム６２、あるいは店舗ＩＤ６４と店舗識別ネーム６６でもって登録される。公開予約処理サーバ４０は、登録された顧客ＩＤ６０と顧客ハンドルネーム６２、あるいは店舗ＩＤ６４と店舗識別ネーム６６の識別判断に基づいて、承認された公開予約処理の手順を実行する。

公開予約処理サーバ４０によって実行される公開予約処理は、いくつかのモードを有している。１つは、顧客側からイベントを企画し、これを店舗側に公開し、店舗側がその公開された内容に応答する提案をさらに公開し、その店舗提案の中に適したものがあれば、顧客側がそれを選択して予約をするもので、いわば顧客企画型公開予約処理モードである。このモードは、あるグループが会合をしたいときに、その日時、場所、予算、料理等の希望を公開し、店舗側がその内容を見て、適合する空き室情報を提案するような場合である。他の１つは、店舗側からイベントを企画し、これを顧客側に公開し、これに参加する顧客が申込をするもので、いわば店舗企画型公開予約処理モードである。このモードは、クリスマスシーズンや納涼シーズン等に顧客側がそれに合わせたディナーパーティを企画するときに、その日時、場所、予算、料理、特別イベント等の内容を公開し、顧客側がその内容を見て、参加申込をするような場合である。以下に、モード別に、公開予約処理サーバ４０によって実行される公開予約処理の内容を説明する。

１．顧客企画型公開予約処理モード
図５は、顧客が顧客端末２０を用いて、イベントの企画内容を公開予約処理サイトに公開することを依頼したいときに、公開予約処理サーバ４０が実行する処理内容を説明する図である。この処理は、公開予約処理サーバ４０の顧客依頼公開部５４の機能によって実行される。顧客端末２０がネットワーク１２を介して企画内容の公開依頼を顧客ＩＤとともに送信すると、公開予約処理サーバ４０はこれを受信する（Ｓ１８）。そして、登録された顧客ＩＤからの依頼であるかどうかを記憶装置４４に記憶される登録内容と比較する。登録された顧客ＩＤからの依頼であると判断するとこれを公開可として認証する（Ｓ２０）。認証がすむと、依頼データの内容を点検し、顧客ハンドルネームを識別処理ネームとして、その内容を公開予約処理サイトに掲示して公開する（Ｓ２２）。各顧客、各店舗は、ネットワーク１２に接続される各顧客端末２０，２１，２２及び各店舗端末３０，３１，３２を通して公開予約処理サイトにアクセスしてその内容を知ることができる（Ｓ２４，Ｓ２６）。

図６は、公開予約処理サイトにおけるサイト画面７０の一例を示す図である。サイト画面７０は、左上に顧客ＩＤ又は店舗ＩＤを入力するＩＤウインド７２が設けられる。顧客あるいは店舗が、登録された顧客ＩＤ又は店舗ＩＤをここに入力することで、サイト画面７０の表示内容が拡張される。すなわち、サイト画面７０の左側に利用可能なメニューが表示され、適当なメニューを選択してクリックすることで、さまざまなメニューがサイト画面の右側に表示される。

サイト画面７０の「ユーザイベント公開依頼」７４のメニューをクリックすると、企画内容依頼画面が表示される。ここではその画面が図示されていないが、例えば、あるグループが会合をしたいときには、その日時、場所、予算、料理等の希望を画面上で入力できる。企画内容依頼画面への必要な事項の入力が完了すると、そのデータは、公開予約処理サーバ４０の顧客依頼公開部５４に送信される。この手順は、図５におけるＳ１８に対応する。なお、サイト画面７０の「店舗イベント公開依頼」７６のメニューは、店舗企画型公開予約処理モードのときにおける店舗側企画提案の公開依頼画面を表示するときに用いられる。サイト画面７０の右側には、公開予約処理におけるいくつかのモードの画面が表示される。いくつかのモードの中におけるモード選択は、タブの選択によって行うことができる。ここでは、ユーザイベント公開依頼が登録認証されたときの「公開ユーザイベント」モードが選択されたときの画面が示されている。「公開ユーザイベント」モードとは、顧客企画型公開予約処理モードのことである。すなわち、このモードを選択したときのサイト画面７０の右側には、地域選択ウインド８６があり、選択された地域についての顧客から公開依頼された企画内容が掲示公開される。

図６の例では、２種類の顧客からの企画内容が公開されている。各企画内容は、企画内容欄８８に詳細が公開される。ここでは、ハンドルネームに対応付けて、その企画の日時、場所、予算、料理等の希望が公開されている。各企画内容欄８８には、「提案／参加」ボタン９０と、「詳細状況」ボタン９２が設けられる。

このように、サイト画面７０において、顧客から公開依頼された企画内容が公開され、登録された顧客ＩＤ又は店舗ＩＤを有する顧客、店舗は、それぞれの顧客端末２０，２１，２２又は店舗端末３０，３１，３２において、ＩＤウインド７２に登録された顧客ＩＤ又は店舗ＩＤを入力し、モード選択タブを「公開ユーザイベント」に選択することで、顧客の企画内容にアクセスすることができる。この手順は、図５におけるＳ２４，Ｓ２６に対応する。

次に、このサイト画面７０にアクセスした店舗側からの提案公開について説明する。図７は、店舗側が店舗端末３０を用いて、顧客の企画内容に応答した企画対応提案を公開予約処理サイトに公開することを依頼したいときに、公開予約処理サーバ４０が実行する処理内容を説明する図である。この処理は、公開予約処理サーバ４０の店舗依頼公開部５６の機能によって実行される。店舗端末３０がネットワーク１２を介して企画対応提案内容の公開依頼を店舗ＩＤとともに送信すると、公開予約処理サーバ４０はこれを受信する（Ｓ２８）。そして、登録された店舗ＩＤからの依頼であるかどうかを記憶装置４４に記憶される登録内容と比較する。登録された店舗ＩＤからの依頼であると判断するとこれを公開可として認証する（Ｓ３０）。認証がすむと、依頼データの内容を点検し、店舗名を識別処理ネームとして、その内容を公開予約処理サイトに掲示して公開する（Ｓ３２）。各顧客、各店舗は、ネットワーク１２に接続される各顧客端末２０，２１，２２及び各店舗端末３０，３１，３２を通して公開予約処理サイトにアクセスしてその内容を知ることができる（Ｓ３４，Ｓ３６）。

なお、店舗側は、日時が経過することで、企画対応提案、例えば空室状況が変化するので、適宜、内容を更新してその公開を依頼できる。具体的には、店舗端末３０がネットワーク１２を介して企画対応提案内容の更新公開依頼を店舗ＩＤとともに送信すると、公開予約処理サーバ４０はこれを受信する（Ｓ３８）。登録認証を経て、サイト画面を更新する（Ｓ４０）。したがって、各顧客、各店舗は、公開予約処理サイトにアクセスしてその更新内容を知ることができる（Ｓ４２，Ｓ４４）。

再び図６に戻ると、「公開ユーザイベント」モードを選択して、顧客の企画内容を知り、その企画内容に対応した提案をしたいと考える店舗は、「提案／参加」ボタン９０をクリックする。サイト画面７０の下欄９４の説明に明示されているように、「提案／参加」ボタン９０をクリックすることで、店舗側から対応対案をする画面を出すことができる。ここではその画面が図示されていないが、例えば、ある店舗が、ハンドルネーム「福井チヌ釣り親睦会」の企画内容に対応する提案をしたいと考えるときは、その企画内容に適合する日時、場所、予算、料理等の提案を画面上で入力できる。企画対応提案公開依頼画面への必要な事項の入力が完了すると、そのデータは、公開予約処理サーバ４０の店舗依頼公開部５６に送信される。この手順は、図７におけるＳ２８に対応する。

このようにして、顧客の企画内容が公開されると、これに対応する店舗側の企画対応提案が公開される。その内容は、サイト画面７０において表示させることができる。図６の場合は、「公開ユーザイベント」モードのサイト画面７０における企画内容欄８８の「詳細状況」ボタン９２をクリックすることで、その詳細がサイト画面７０に表示される。

図８は、詳細状況画面１００の一例を示す図である。ここでは、ハンドルネーム「福井チヌ釣り親睦会」の企画内容欄８８の「詳細状況」ボタン９２をクリックした場合が示されている。詳細状況画面１００は、大別して３つに分かれ、上段は顧客の企画内容表示欄１０２である。中段の内容は後述するとして、下段に、店舗提案一覧表示欄１０６が設けられる。ここではハンドルネーム「福井チヌ釣り親睦会」の企画内容に対し、３つの店舗からの対応提案があることが示される。各対応提案は、店舗識別ネームによって表示される。各対応提案の「詳細」ボタンをクリックすると、その対応提案の詳細画面を表示することができる。

図９は、店舗側の対応提案の詳細画面１１０についての一例を示す図である。ここでは図８において、店舗識別ネーム「ＡＢＣ亭」の「詳細」ボタンをクリックした場合が示される。詳細画面１１０は、予約画面を兼ねており、大別して、顧客ハンドルネーム及び店舗識別ネームによる特定欄１１２と、予約可能な提案内容、すなわち空室情報がいくつか示される。図９の例では、店舗識別ネーム「ＡＢＣ亭」から２つの提案が示されている。

このようにして、企画内容を公開した顧客は、それに対応した店舗側の提案をサイト画面７０上で知ることができる。図８、図９から理解できるように、１つの顧客の企画内容に対し、複数の店舗から、また、１つの店舗について複数の提案があることが公開され、顧客は、これらをサイト画面７０上で比較し、予約するかどうか検討することができる。図９の詳細画面１１０の下欄に明示されるように、各提案の１つを選択し、それに対応する「予約」ボタン１１６をクリックすると、顧客側の予約申込となり、顧客側と店舗側との間で予約が成立する。

すなわち、サイト画面７０の使用は、顧客ＩＤ及び店舗ＩＤに基づいて行われており、店舗側からの提案公開依頼は「その提案公開に応答して登録された顧客ＩＤによる予約があるときはその予約を承認する」ことがあらかじめ確認されているので、顧客の「予約」ボタンのクリックのみで、その顧客ＩＤの顧客と、その店舗ＩＤの店舗との間の予約が成立する。この判断は、上記のように、顧客ＩＤ及び店舗ＩＤに基づいて、店舗側からの提案公開依頼がなされ、顧客側から予約申込がなされたことを公開予約処理サーバ４０が各工程で確認することで行われている。

図１０は、顧客端末２０を通しての顧客からの予約申込以後における公開予約処理サーバ４０の処理の内容等を説明する図である。この処理は、公開予約処理サーバ４０の予約処理部５８の機能により実行される。公開予約処理サイトに顧客が顧客端末２０を通してアクセスし予約申込をすると、公開予約処理サーバ４０はこれを受信する（Ｓ４６）。この工程は、図９で説明した「予約」ボタン１１６のクリックに相当する。受信した公開予約処理サーバ４０は、この予約申込が、登録された顧客ＩＤに基づくものか、記憶装置４４の登録内容と比較して判断し、登録された顧客ＩＤに基づくものであると判断するときは、対応する顧客側と店舗側との間で予約成立したとして、割引率を含む予約成立内容を顧客端末２０に送信する（Ｓ４８）。顧客端末２０のアドレスは、図３で説明したように、記憶装置４４の登録内容に含まれているので、それを読み出して送信が行われる。

割引率は図４で説明したように、記憶装置４４の登録内容に含まれているので、予約成立内容に応じた割引率を算出してこれを送信内容に含める。例えば、図９の例で、「ＡＢＣ亭」において、人数２０名、予算４０００から６０００円で予約成立したとすると、図４の登録内容から、割引率は１０％が適用される。

割引率を含む予約成立内容は、顧客がそのまま店舗に行くときに提示できるように、顧客端末２０から顧客側携帯端末、例えば携帯電話に転送可能で、かつ店舗端末で読み取れるデータ形式を用いて送信される。具体的には、２次元バーコードを用いて送信されることが望ましい。２次元バーコードとしては、例えばＱＲコード（デンソーウェーブ社の商品名、ＱｕｉｃｋＲｅｓｐｏｎｓｅコード）を用いることができる。ＱＲコードのデータ量は、数字データに換算して７，０８９ビットであるので、関連付け識別情報を表現するのに十分な容量を有する。

また、公開予約処理サーバ４０は、同じ予約成立内容を対応する店舗端末３０に送信する（Ｓ５０）。店舗端末３０のアドレスは、図４で説明したように、記憶装置４４の登録内容に含まれているので、それを読み出して送信が行われる。

このようにして、顧客端末２０、店舗端末３０に対し、それぞれ予約成立内容が送信されると、次に顧客が予約成立内容データを記憶した顧客側携帯端末を持参して店舗に来店する（Ｓ５２）。店舗では、顧客側予約成立内容を適当な端末で読み取り（Ｓ５４）、その内容に基づき、実際の来店人数、価格、実施割引率等を加味して来店実績を作成し、これを公開予約処理サーバ４０に送信する。公開予約処理サーバ４０はこれを受信し（Ｓ５６）、その来店情報を確認のために、顧客端末２０に転送する（Ｓ５８）。その際に適当なサイト利用の御礼文言を加えてもよい。この来店情報の転送により、仮に、顧客側の認識と店舗側の送信内容が食い違うときには、その訂正が容易となり、実績把握の精度が向上する。その結果は、利用履歴として、対応する顧客および店舗の登録内容に記憶される（Ｓ６０）。

顧客が企画内容の公開依頼をし、これがサイト画面７０に公開されると、他の顧客もその企画内容を知り、その企画に参加したいと考えることがある。このような場合も、ネットワーク１２を介し、サイト画面７０上で参加を成立させることができる。図１１は、参加依頼があるときの公開予約処理サーバ４０等についての処理内容を説明する図である。図１１において、Ｓ１８，Ｓ２０，Ｓ２２は、図５で説明した内容と同じで、ここで、顧客Ａからの企画内容がサイト画面７０に公開される。第２の顧客Ｂがこれに参加を希望するときは、参加内容公開依頼を公開予約処理サーバ４０に送信し、公開予約処理サーバ４０はこれを受信する（Ｓ６２）。そして、登録された顧客ＩＤからの依頼であるかどうかを記憶装置４４に記憶される登録内容と比較する。登録された顧客ＩＤからの依頼であると判断するとこれを公開可として認証する（Ｓ６４）。認証がすむと、参加依頼データの内容を点検し、顧客ハンドルネームを識別処理ネームとして、その内容を公開予約処理サイトに元々の企画内容に併合して公開する（Ｓ６６）。各顧客、各店舗は、ネットワーク１２に接続される各顧客端末２０，２１，２２及び各店舗端末３０，３１，３２を通して公開予約処理サイトにアクセスしてその内容を知ることができる（Ｓ６８，Ｓ７０，Ｓ７２）。

具体的に参加内容公開依頼をサイト画面上で行うには、図６のサイト画面７０の右下欄９４に明示されているように、「提案／参加」ボタン９０をクリックすることで、第２の顧客側から合同参加申込をする画面を出すことができる。ここではここではその画面が図示されていないが、例えば、顧客Ｂが、ハンドルネーム「福井チヌ釣り親睦会」の企画内容に参加したいと考えるときは、その企画内容に適合する参加人員等の提案を画面上で入力できる。参加内容公開依頼画面への必要な事項の入力が完了すると、そのデータは、公開予約処理サーバ４０に送信される。この手順は、図１１におけるＳ６２に対応する。

その内容は、図６における「詳細状況」をクリックすることでサイト画面７０上に現わすことができる。図８の詳細状況画面１００の中段には、そのユーザ参加詳細欄１０４が設けられ、そこに参加希望の内容が公開される。ここでは、ハンドルネーム「丸岡チヌの会」が、３名で参加したいことが公開されている。この内容を加味して、店舗側は、対応提案をすることができる。

２．店舗企画型公開予約処理モード
図１２は、店舗が店舗端末３０を用いて、イベントの企画提案を公開予約処理サイトに公開することを依頼したいときに、公開予約処理サーバ４０が実行する処理内容を説明する図である。店舗端末３０がネットワーク１２を介して企画提案の公開依頼を店舗ＩＤとともに送信すると、公開予約処理サーバ４０はこれを受信する（Ｓ７４）。そして、登録された店舗ＩＤからの依頼であるかどうかを記憶装置４４に記憶される登録内容と比較する。登録された店舗ＩＤからの依頼であると判断するとこれを公開可として認証する（Ｓ７６）。認証がすむと、依頼データの内容を点検し、店舗識別ネームを識別処理ネームとして、その内容を公開予約処理サイトに掲示して公開する（Ｓ７８）。各顧客、各店舗は、ネットワーク１２に接続される各顧客端末２０，２１，２２及び各店舗端末３０，３１，３２を通して公開予約処理サイトにアクセスしてその内容を知ることができる（Ｓ８０，Ｓ８２）。

図１３は、サイト画面７０において、「公開店舗イベント」８２のタブを選択し、店舗側の企画提案の公開内容を現わす様子を示す図である。「公開店舗イベント」モードは、店舗企画型公開予約処理モードに対応する。「公開店舗イベント」８２のサイト画面では、イベントの種類を選択できるイベントウインド１２２が設けられ、顧客側が、興味のあるイベントの種類を選択できる。イベントの種類を選択後、「検索開始」ボタン１２４をクリックすると、その種類の店舗提案イベントの内容が表示される。詳しくは、提案内容欄１２６に、店舗識別ネームを用いた企画提案内容が表示される。各提案内容欄１２６には「参加」ボタン１２８が設けられ、サイト画面７０の下欄１３０の説明に明示されるように、この「参加」ボタン１２８をクリックすることで、サイト画面７０に予約画面が現れる。予約画面の内容は、図９で説明したものと同様で、「予約」ボタンをクリックすることで、予約が成立する。予約成立後の処理は、図１０で説明したものと同様である。

このように、店舗企画型公開予約処理モードは、店舗側からの企画提案に興味ある顧客が個人、またはグループで参加するものである。

また、図６、図１３におけるサイト画面７０におけるもう１つのタブ「店舗検索予約」は、店舗企画型ほどの強いイベント参加提案ではないが、店舗側からのイベントの内容を記憶装置４４の店舗データベースから顧客側が任意に検索できるモードである。ここでは、顧客側は企画内容を有していても公開せず、単に店舗データベースを検索するもので、予約も、直接顧客が店舗にアクセスして行う。

本発明に係る実施の形態における公開予約処理システムの構成を示す図である。本発明に係る実施の形態において、公開予約処理サーバの登録部の機能を説明する図である。本発明に係る実施の形態において、顧客端末に関する登録データの例を示す図である。本発明に係る実施の形態において、店舗端末に関する登録データの例を示す図である。本発明に係る実施の形態において、顧客が顧客端末を用いて、イベントの企画内容を公開予約処理サイトに公開することを依頼したいときに、公開予約処理サーバが実行する処理内容を説明する図である。本発明に係る実施の形態において、公開予約処理サイトにおけるサイト画面の一例を示す図である。本発明に係る実施の形態において、店舗側が店舗端末を用いて、顧客の企画内容に応答した企画対応提案を公開予約処理サイトに公開することを依頼したいときに、公開予約処理サーバが実行する処理内容を説明する図である。本発明に係る実施の形態において、詳細状況画面の一例を示す図である。本発明に係る実施の形態において、店舗側の対応提案の詳細画面についての一例を示す図である。本発明に係る実施の形態において、顧客端末を通しての顧客からの予約申込以後における公開予約処理サーバの処理の内容等を説明する図である。本発明に係る実施の形態において、参加依頼があるときの公開予約処理サーバ等についての処理内容を説明する図である。本発明に係る実施の形態において、店舗が店舗端末を用いて、イベントの企画提案を公開予約処理サイトに公開することを依頼したいときに、公開予約処理サーバが実行する処理内容を説明する図である。本発明に係る実施の形態において、サイト画面上で「公開店舗イベント」のタブを選択し、店舗側の企画提案の公開内容を現わす様子を示す図である。

符号の説明

１０公開予約処理システム、１２ネットワーク、２０，２１，２２顧客端末、３０，３１，３２店舗端末、４０公開予約処理サーバ、４２ＣＰＵ、４４記憶装置、４６通信制御部、４８入力部、５０出力部、５２登録部、５４顧客依頼公開部、５６店舗依頼公開部、５８予約処理部、６０顧客ＩＤ、６２顧客ハンドルネーム、６４店舗ＩＤ、６６店舗識別ネーム、７０サイト画面、７２ＩＤウインド、７４ユーザイベント公開依頼メニュー、７６店舗イベント公開依頼メニュー、８６地域選択ウインド、８８企画内容欄、９０提案／参加ボタン、９２詳細状況ボタン、９４，１３０下欄、１００詳細状況画面、１０２企画内容表示欄、１０４ユーザ参加詳細欄、１０６店舗提案一覧表示欄、１１０詳細画面、１１２特定欄、１２２イベントウインド、１２４検索開始ボタン、１２６提案内容欄、１２８参加ボタン。

Claims

複数の顧客端末及び複数の店舗端末とネットワークで接続される公開予約処理サーバであって、
各顧客の顧客ＩＤに対応付けて個人情報を含まない顧客ハンドルネームと、各店舗の店舗ＩＤに対応付けて店舗名を含む店舗識別ネームとを、公開予約処理における識別処理ネームとして各顧客及び各店舗にそれぞれ割り当てて登録する登録部と、
顧客端末からの企画内容公開依頼データを受信し、登録された顧客ＩＤによる依頼であるか否かを判断し、登録された顧客ＩＤによる依頼であると判断するときに、公開予約処理サイトに依頼データを顧客ハンドルネームとともに公開する顧客依頼公開部と、
公開予約処理サイトにおける企画内容に応答する店舗端末からの企画対応提案公開依頼であり、その提案公開に応答して登録された顧客ＩＤによる予約があるときはその予約を承認する内容である提案公開依頼を受信し、登録された店舗ＩＤによる依頼であるか否かを判断し、登録された店舗ＩＤによる依頼であると判断するときに、公開予約処理サイトに依頼データを店舗識別ネームとともに公開する店舗依頼公開部と、
公開予約処理サイトにおける提案内容に応答する顧客端末からの予約申込を受信し、登録された顧客ＩＤによる予約申込であるか否かを判断し、登録された顧客ＩＤによる予約申込であると判断するときは、予約が成立したものとして、対応する店舗端末と顧客端末に対し予約成立処理を行う予約処理部と、
を備えることを特徴とする公開予約処理サーバ。
複数の顧客端末及び複数の店舗端末とネットワークで接続される公開予約処理サーバであって、
各顧客の個人識別情報に対応付けて個人情報を含まない顧客ハンドルネームと、各店舗の店舗識別情報に対応付けて店舗名を含む店舗識別ネームとを、公開予約処理における識別処理ネームとして各顧客及び各店舗にそれぞれ割り当てて登録する登録部と、
店舗端末からの企画提案公開依頼データを受信し、そのデータがその公開に応答して登録された顧客ＩＤによる予約があるときはその予約を承認する内容である企画提案公開依頼データであって、登録された店舗ＩＤによる依頼であると判断するときに、公開予約処理サイトに依頼データを店舗識別ネームとともに公開する店舗依頼公開部と、
公開予約処理サイトにおける提案内容に応答する顧客端末からの予約申込を受信し、登録された顧客ＩＤによる予約申込であるか否かを判断し、登録された顧客ＩＤによる予約申込であると判断するときは、予約が成立したものとして、対応する店舗端末と顧客端末に対し予約成立処理を行う予約処理部と、
を備えることを特徴とする公開予約処理サーバ。
請求項１又は請求項２に記載の公開予約処理サーバにおいて、
予約処理部は、
予約成立に対応する顧客端末及び店舗端末に対し、それぞれ予約成立内容を送信する予約成立送信手段を有することを特徴とする公開予約処理サーバ。
請求項３に記載の公開予約処理サーバにおいて、
登録部は、
店舗識別情報として、予約成立内容に応じたその店舗における顧客の支払に対する割引率を含んで登録し、
予約成立送信手段は、
顧客端末に対し、割引率を含む予約成立内容を、顧客端末から顧客側携帯端末に転送可能で、かつ店舗端末で読み取れるデータ形式を用いて送信することを特徴とする公開予約処理サーバ。
請求項４に記載の公開予約処理サーバにおいて、
予約成立送信手段は、
顧客端末に対し、割引率を含めた予約成立内容を２次元バーコードのデータ形式で送信することを特徴とする公開予約処理サーバ。
請求項４に記載の公開予約処理サーバにおいて、
店舗端末から、顧客側携帯端末より読み取ったデータを含めて送信される来店情報を受信する来店実績受信手段と、
顧客端末に対し、来店情報に応じた来店確認情報を送信する来店確認送信手段と、
を備えることを特徴とする公開予約処理サーバ。
請求項１に記載の公開予約処理サーバにおいて、
公開予約処理サイトにおける企画内容に応答する第２の顧客端末からの参加提案公開依頼データを受信し、登録された顧客ＩＤによる依頼であるか否かを判断し、登録された顧客ＩＤによる依頼であると判断するときに、公開予約処理サイトに、参加を希望する企画内容と関連付けて、参加提案依頼データをその顧客ハンドルネームとともに公開する参加依頼公開部を備えることを特徴とする公開予約処理サーバ。
請求項１に記載の公開予約処理サーバにおいて、
各店舗端末から送信されるイベント掲載依頼データを記憶し、各顧客端末からのアクセスを許可する店舗データベースを備えることを特徴とする公開予約処理サーバ。