特開 2022-76967 予約管理サーバ及び予約管理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022076967

(43)【公開日】2022-05-20

(54)【発明の名称】予約管理サーバ及び予約管理方法

(51)【国際特許分類】

   G06Q 10/02 20120101AFI20220513BHJP

【ＦＩ】

G06Q10/02

【審査請求】有

【請求項の数】5

【出願形態】ＯＬ

(21)【出願番号】P 2020187642

(22)【出願日】2020-11-10

(11)【特許番号】

(45)【特許公報発行日】2021-08-25

(71)【出願人】

【識別番号】500165795

【氏名又は名称】ネットパイロティング株式会社

(74)【代理人】

【識別番号】100117592

【弁理士】

【氏名又は名称】土生 哲也

(72)【発明者】

【氏名】加藤 貴大

(72)【発明者】

【氏名】山田 光太郎

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049AA03

(57)【要約】

【課題】 特定の予約希望者に予約が集中することを回避するとともに、予約希望者の興味や熱意等の温度感を反映して予約を決定することが可能な予約管理サーバを提供する。
【解決手段】 ユーザには予約への入札権であるトークンを割り当てて、その残高をユーザデータベースで管理する。入札を行う際にはトークンの使用が求められ、ユーザはトークンの残高の範囲内でしか予約に入札できないので、特定のユーザによって予約可能な時間枠が占拠されることを回避し、多くのユーザからの予約を受け付けやすい構成となる。また、ユーザは残高が限られたトークンを用いて予約に入札するので、予約を希望するユーザの興味や熱意も担保しやすい。入札者の中からは、入札に用いたトークンの種別や数量によって落札者が決定されるので、トークンの種別等の設定によって、ユーザの温度感をより精度を上げて測りやすい構成とすることもできる。
【選択図】 図１

【特許請求の範囲】

【請求項1】

予約への入札権であるトークンのユーザ毎の残高に関する情報を格納するトークン残高情報格納手段と、
ユーザが操作する端末から、入札に用いられるトークンの種別又は数量が指定された所定の時間枠に予約を行うための入札要求を受信すると、少なくとも前記トークンの種別又は数量が前記トークン残高情報格納手段に格納された前記ユーザが保有するトークンの残高の範囲内にあることを条件に、前記入札要求を受け付ける入札受付手段と、
前記入札受付手段が前記時間枠に対して入札を受け付けた一又は二以上のユーザから、各々の入札に用いられたトークンの種別又は数量に基づいて、前記時間枠において予約を受け付けるユーザを決定する予約決定手段と、
を備えることを特徴とする予約管理サーバ。

【請求項2】

前記入札受付手段は、所要時間を特定可能なトークンが指定された入札要求を受信して、少なくとも前記所要時間が前記時間枠において予約可能な時間の範囲内であることを条件に、前記入札要求を受け付けること
を特徴とする請求項１記載の予約管理サーバ。

【請求項3】

予約の入札には、所要時間が異なる複数の種別のトークンを用いることが可能であり、
前記予約決定手段は、同一の時間枠に対して受け付けた入札のうち、所要時間が長いトークンを用いた入札を優先して、予約を受け付けるユーザを決定すること
を特徴とする請求項１又は２記載の予約管理サーバ。

【請求項4】

予約の入札には、重要度が異なる複数の種別のトークンを用いることが可能であり、
前記予約決定手段は、同一の時間枠に対して受け付けた入札のうち、重要度が高いトークンを用いた入札を優先して、予約を受け付けるユーザを決定すること
を特徴とする請求項１又は２記載の予約管理サーバ。

【請求項5】

予約の入札には、一の入札に対して単位時間が固定された一又は二以上のトークンを用いることが可能であり、
前記予約決定手段は、同一の時間枠に対して受け付けた入札のうち、用いられたトークンの数量が多い入札を優先して、予約を受け付けるユーザを決定すること
を特徴とする請求項１又は２記載の予約管理サーバ。

【請求項6】

前記トークン残高情報格納手段から、前記ユーザが保有するトークンの残高に関する情報を読み出して、前記端末に前記ユーザが保有するトークンの種別と数量を残高情報として表示させるために送信する残高情報提供手段を備えていて、
前記入札受付手段は、前記端末に表示された残高情報から前記ユーザが選択して決定された、入札に用いられるトークンの種別又は数量が指定された入札要求に関する情報を受信すること
を特徴とする請求項１乃至５いずれかに記載の予約管理サーバ。

【請求項7】

前記ユーザに付与されたステータスを反映して選択された、前記ユーザが入札可能な時間枠を選択して、前記端末に前記時間枠に関する情報を送信する入札可能時間枠情報送信手段を備えること
を特徴とする請求項１乃至６いずれかに記載の予約管理サーバ。

【請求項8】

予約への入札権であるトークンのユーザ毎の残高に関する情報を格納するトークン残高情報格納手段を備えた予約管理サーバが、ユーザが操作する端末から、入札に用いられるトークンの種別又は数量が指定された所定の時間枠に予約を行うための入札要求を受信すると、少なくとも前記トークンの種別又は数量が前記トークン残高情報格納手段に格納された前記ユーザが保有するトークンの残高の範囲内にあることを条件に、前記入札要求を受け付ける入札受付ステップと、
前記予約管理サーバが、前記入札受付ステップによって、前記時間枠に対して入札を受け付けた一又は二以上のユーザから、各々の入札に用いられたトークンの種別又は数量に基づいて、前記時間枠において予約を受け付けるユーザを決定する予約決定ステップと、
を有することを特徴とする予約管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、展示会における出展者ブースでの面談の予約等に用いることができる、予約管理サーバ及び予約管理方法に関するものである。

【背景技術】

【0002】

飲食、医療、美容、レンタカー、設備や施設のレンタル等の様々なサービスが、サービスを提供する時間帯の予約を受け付けることによって行われているが、こうした時間帯を指定したサービスの予約には、コンピュータを利用することによって効率化が図られている。

【0003】

コンピュータを利用して時間帯を指定した予約を受け付けるシステムでは、例えば、あらかじめ指定された時間枠から希望する時間枠を選択して予約を行う方式（例えば、特許文献１段落番号００３５の「事前設定タイプ」参照。）や、予約が可能なサービス提供時間の範囲内で予約申込者が希望する時間帯を指定して予約を行う方式（例えば、特許文献１段落番号００３５の「自由受付タイプ」参照。）等が採用されている。

【0004】

また、予約申込者が時間を指定しなくても、提供を受けたいサービスの内容に応じて、サーバ側でサービスの所要時間を決定し、サービスの提供に必要な時間を確保して予約時間を決定する発明も開示されている（例えば、特許文献２及び３参照）。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０１８－２０５８１０号公報

【特許文献2】特開２０１２－２２６７０２号公報

【特許文献3】特開２０１５－１１８４８９号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

ところで、メーカーや流通業者が新製品等を紹介するために開催する展示会では、多くの来場者が会場を訪れて、各々のメーカー等が設ける出展者ブースで商品の紹介や商談が行われているが、特に面談の予約が行われることはなく、来場者が通りすがりのブースに立ち寄って会話が行われるか、予約があるとしても来場者から個別に訪問時間の連絡があり、担当者がブースに待機している程度の運用となっているのが一般的である。そのため、来場者が少ない時間帯には出展者ブースの担当者が手持ち無沙汰となってしまう一方、混雑する時間帯には十分な面談時間を確保することができずに、来場者と出展者の双方に不満の残る結果となりやすい状況が生じている。

【0007】

そこで、展示会の出展者ブースでの面談についても、先行技術に示したような予約システムを導入することが考えられるが、例えば、特定の来場者にまとめて予約の枠取りをするようなことが行われてしまうと、新製品等を多くの関係者に説明したいという出展者側の目的が達成できなくなってしまうおそれがある。

【0008】

また、出展者は、展示する新製品等に対して、より強い興味や熱意を有している来場者との面談を優先したい意向であることが通常であり、こうした来場者の温度感を反映しながら予約を決定できる仕組みが求められるところである。

【0009】

本発明は、このような課題に対応するためになされたものであり、特定の予約希望者に予約が集中することを回避するとともに、予約希望者の温度感を反映して予約を決定することが可能となる、展示会における出展者ブースでの面談の予約等に用いるのが好適な、予約管理サーバ及び予約管理方法を提供することを目的とするものである。

【課題を解決するための手段】

【0010】

このような課題を解決する本発明は、予約への入札権であるトークンのユーザ毎の残高に関する情報を格納するトークン残高情報格納手段と、ユーザが操作する端末から、入札に用いられるトークンの種別又は数量が指定された所定の時間枠に予約を行うための入札要求に関する情報を受信すると、少なくとも前記トークンの種別又は数量が前記トークン残高情報格納手段に格納された前記ユーザが保有するトークンの残高の範囲内にあることを条件に、前記入札要求を受け付ける入札受付手段と、前記入札受付手段が前記時間枠に対して入札を受け付けた一又は二以上のユーザから、各々の入札に用いられたトークンの種別又は数量に基づいて、前記時間枠において予約を受け付けるユーザを決定する予約決定手段と、を備えることを特徴とする予約管理サーバである。

【0011】

本発明では、予約を行うユーザには予約への入札権であるトークンを割り当て、トークンの残高の範囲内で予約への入札を受け付ける構成とすることによって、特定のユーザによって予約可能な時間枠が占拠されることを回避し、多くのユーザからの予約を受け付けやすくするとともに、ユーザは限られた残高の中からトークンを用いて予約の入札を行うので、予約を希望するユーザの興味や熱意も担保しやすい予約管理を実現している。各々の時間枠において予約が受け付けられるユーザは、ユーザが入札に用いたトークンの種別や数量によって決定されるので、トークンの種別等の設定によって、ユーザの興味や熱意等の温度感をより精度を上げて測りやすい構成とすることも可能である。

【0012】

また、本発明は、前記入札受付手段は、所要時間を特定可能なトークンが指定された入札要求を受信して、少なくとも前記所要時間が前記時間枠において予約可能な時間の範囲内であることを条件に、前記入札要求を受け付けることを特徴とすることもできる。

【0013】

このように構成すると、ユーザが入札に用いたトークンにより特定された所要時間が予約可能な時間を超過する場合は、入札が受け付けられなくなるので、不適正な入札をあらかじめ排除することが可能になる。

【0014】

本発明は、予約の入札には、所要時間が異なる複数の種別のトークンを用いることが可能であり、前記予約決定手段は、同一の時間枠に対して受け付けた入札のうち、所要時間が長いトークンを用いた入札を優先して、予約を受け付けるユーザを決定することを特徴としてもよい。

【0015】

本発明は、予約の入札には、重要度が異なる複数の種別のトークンを用いることが可能であり、前記予約決定手段は、同一の時間枠に対して受け付けた入札のうち、重要度が高いトークンを用いた入札を優先して、予約を受け付けるユーザを決定することを特徴としてもよい。

【0016】

本発明は、予約の入札には、一の入札に対して単位時間が固定された一又は二以上のトークンを用いることが可能であり、前記予約決定手段は、同一の時間枠に対して受け付けた入札のうち、用いられたトークンの数量が多い入札を優先して、予約を受け付けるユーザを決定することを特徴としてもよい。

【0017】

これらの３パターンの構成によると、いずれもユーザが入札に用いたトークンの種別、あるいはトークンの数量によって、ユーザの興味や熱意等の温度感をより高い精度で判別して、予約を決定することが可能になる。

【0018】

また、本発明は、前記トークン残高情報格納手段から、前記ユーザが保有するトークンの残高に関する情報を読み出して、前記端末に前記ユーザが保有するトークンの種別と数量を残高情報として表示させるために送信する残高情報提供手段を備えていて、前記入札受付手段は、前記端末に表示された残高情報から前記ユーザが選択して決定された、入札に用いられるトークンの種別又は数量が指定された入札要求に関する情報を受信することを特徴とすることもできる。

【0019】

このように構成すると、ユーザは自らが保有するトークンの残高を確認しながら、どのトークンを用いて予約に入札するかを決定することができるので、ユーザの利便性が向上するとともに、ユーザの熱意等の温度感がより正確に反映されやすい構成とすることができる。

【0020】

また、本発明は、前記ユーザに付与されたステータスを反映して選択された、前記ユーザが入札可能な時間枠を選択して、前記端末に前記時間枠に関する情報を送信する入札可能時間枠情報送信手段を備えることを特徴とすることもできる。

【0021】

このように構成すると、予約を優先的に受け付けたいユーザは先行して予約の入札を受け付けるといった運用を行いたい場合に、そうしたユーザには高いステータスを付与して、ステータスに応じて選定された入札可能な時間枠を提示することが可能になる。

【0022】

本発明は、本発明に係る予約管理サーバによって実行される、予約管理方法として特定することもできる。

【0023】

本発明に係る予約管理方法は、予約への入札権であるトークンのユーザ毎の残高に関する情報を格納するトークン残高情報格納手段を備えた予約管理サーバが、ユーザが操作する端末から、入札に用いられるトークンの種別又は数量が指定された所定の時間枠に予約を行うための入札要求に関する情報を受信すると、少なくとも前記トークンの種別又は数量が前記トークン残高情報格納手段に格納された前記ユーザが保有するトークンの残高の範囲内にあることを条件に、前記入札要求を受け付ける入札受付ステップと、前記予約管理サーバが、前記入札受付ステップによって、前記時間枠に対して入札を受け付けた一又は二以上のユーザから、各々の入札に用いられたトークンの種別又は数量に基づいて、前記時間枠において予約を受け付けるユーザを決定する予約決定ステップと、を有することを特徴とする予約管理方法である。

【0024】

また、本発明に係る予約管理方法は、先に説明した各々の構成を備える本発明に係る予約管理サーバによって実行される、予約管理方法として特定することもできる。

【発明の効果】

【0025】

本発明によると、時間枠を指定してサービスや面談の予約を受け付けるケースにおいて、特定のユーザに限定されることなく、多くのユーザからの予約を受け付けやすくなるとともに、予約を希望するユーザの興味や熱意等の温度感を反映して、予約を受け付けるユーザを決定することが可能になる。本発明は、展示会における出展者ブースでの面談の予約に特に好適であると考えられ、展示会における商談の効率化や活性化に資することが期待される。

【図面の簡単な説明】

【0026】

【図1】本発明に係る予約管理サーバの実施形態の概要を示す図である。

【図2】本発明に係る予約管理サーバの構成を示すブロック図である。

【図3】本発明に係る予約管理サーバによる予約への入札受付の処理フローを示すフローチャートである。

【図4】本発明に係る予約管理サーバのユーザ情報格納部に格納されるユーザマスタの一例を示す図である。

【図5】本発明に係る予約管理サーバのユーザ情報格納部に格納されるトークン残高の一例を示す図である。

【図6】本発明に係る予約管理サーバのイベント情報格納部に格納されるイベント情報の一例を示す図である。

【図7】本発明に係る予約管理サーバの入札情報格納部に格納される入札情報の一例を示す図である。

【図8】本発明に係る予約管理サーバの予約情報格納部に格納される予約情報の一例を示す図である。

【図9】本発明において、同一の時間枠に入札したユーザから予約を受け付けるユーザを決定する方法の一例を示す図である。

【図10】本発明において、トークンの種別又は数量を指定して予約への入札をする第１の例を示す図である。

【図11】本発明において、トークンの種別又は数量を指定して予約への入札をする第２の例を示す図である。

【図12】本発明において、トークンの種別又は数量を指定して予約への入札をする第３の例を示す図である。

【発明を実施するための形態】

【0027】

本発明を実施するための形態について、図面を用いて以下に詳細に説明する。尚、以下の説明では、本発明を、展示会における出展者ブースでの面談の予約に用いる例について説明するが、以下の説明は本発明の実施形態の一例を示したものであって、予約の対象や時間枠の区切り方、トークンの種別やユーザのステータス管理等、本発明はここに例示した実施形態に限定されるものではない。

【0028】

図１は、本発明に係る予約管理サーバの実施形態の一例について、その概要を示した図である。図１において、ユーザが操作するユーザ端末２０からインターネットを介してアクセスすることが可能な予約管理サーバ１０が、本発明に係る予約管理サーバに該当する。

【0029】

ある展示会を主催する主催者は、展示会に招待する小売業者や卸売業者の購買担当者（ユーザ端末２０を操作するユーザ）に対して、各ブースでの出展者（新製品等を出展するメーカー等）との面談予約への入札権となるトークンを所定の数量分割り当てるが、購買担当者毎（企業毎や部署毎でもよい）に保有するトークンの残高は、予約管理サーバ１０のユーザデータベースで管理される。

【0030】

購買担当者がユーザ端末２０から予約管理サーバ１０にログインすると、ユーザデータベースに記録されている自らのトークンの残高を確認できるとともに、イベントデータベースを参照して、面談予約に入札することが可能なイベント（展示会）に出展している出展者と、各々の出展者ブースでの面談予約への入札が可能な時間枠を確認することができる。いずれかの出展者との面談を予約したい場合は、イベント、出展者及び時間枠を選択して面談予約への入札を行うが、入札する購買担当者には、入札権となるトークンを用いて入札を要求することが求められる。

【0031】

各々の購買担当者には、種別毎にあらかじめ決められた数量のトークンが割り当てられており、トークンの残高の範囲内でしか面談予約に入札することができない。そのため、購買担当者は仮押さえ的な入札を無闇に行うことができず、面談を優先したい出展者、つまり出展している新製品等に興味や関心がある出展者のブースを優先して、入札を行うことになると考えられる。そのため、出展者であるメーカー等には、面談を予約制とすることによって機会損失や時間の無駄の削減されるともに、購買担当者の自社製品に対する興味や熱意等の温度感を測りながら、予約を受け付ける相手方を決定することが可能になる。

【0032】

購買担当者が面談予約への入札を行う際には、ユーザ端末２０から入札に用いるトークンの種別や数量を指定して、予約管理サーバ１０に入札要求を送信する。入札要求を受信した予約管理サーバ１０では、ユーザデータベースに記録されている情報から当該購買担当者が保有するトークンの残高に不足がないことを確認し、さらに、トークンから特定される面談の所要時間が面談予約の可能な時間の範囲内にあることも確認して、面談予約への入札を受け付ける。受け付けた入札に関する情報は入札データベースに格納され（入札は封印型で行われるので入札データベースの入札情報は非公開となる）、ユーザデータベースで管理されている当該購買担当者が保有するトークンの残高から、入札に用いられたトークンの数量が減じられる。

【0033】

入札を受け付けた時間枠における面談予約の落札者の決定は所定のタイミングで行われるが、落札者を決定するタイミングになると、同じ時間枠を対象に受け付けた入札の中から、所定のルールに基づいて予約を受け付ける購買担当者が決定される。予約を決定するルールは、早い者勝ちのルールとしてもよいし、出展者が個別に判断して決定することとしてもよいが、トークンに面談の所要時間を設定したり、重要度が異なる種別を設けたりする場合は、より所要時間の長いトークンを用いた入札や、より重要度の高いトークンを用いた入札を優先することによって、購買担当者の自社製品に対する興味や熱意等の温度感を反映して、面談予約を受け付ける相手方を決定することができる。

【0034】

いずれかの入札を落札者として面談予約が決定されると、予約された時間枠と落札した購買担当者、面談の所要時間等の予約に関する情報が、予約データベースに格納される。また、落札できなかった購買担当者については、入札に用いたトークンをユーザデータベースで管理されている当該購買担当者が保有するトークンの残高に戻す処理が行われる。各々の購買担当者は、ユーザ端末２０から予約データベースに格納された自らの面談予約に関する情報を確認することができる。

【0035】

図２は、本発明に係る予約管理サーバの構成の一例を、機能ブロックで示した図である。図２において、予約管理サーバ１０が本発明に係る予約管理サーバに対応する。

【0036】

予約管理サーバ１０は、インターネットに接続されたサーバコンピュータで、ＣＰＵ、メインメモリ、ＨＤＤ等の補助記憶装置が備えられている。予約管理サーバ１０では、補助記憶装置に格納されたプログラムがメインメモリに読み出され、ＣＰＵで演算処理を実行することによって所定の機能が実現される。

【0037】

予約管理サーバ１０を構成するコンピュータの物理的な構成は特に限定されるものではなく、本発明における予約の管理に関連する入札の受け付けや予約の決定等以外の機能が、同一のコンピュータに備えられるものであってもよい。また、本発明に必要な各々の機能は、物理的に一台のコンピュータによって実現されるものであってもよいし、複数のコンピュータが連携して実現されるものであってもよい。

【0038】

予約管理サーバ１０のユーザ認証部１１、入札可能枠提示部１２、入札登録部１３、予約決定部１４、予約情報閲覧部１５は、いずれも機能的に特定されるものであって、ＨＤＤ等の補助記憶装置に格納された各部の機能に対応するプログラムがメインメモリに読み出され、ＣＰＵで演算処理を実行することによって、各部に対応する機能が実現される。

【0039】

予約管理サーバ１０のユーザ情報格納部１６（ユーザマスタ１６１やトークン残高１６２が格納されている）、イベント情報格納部１７、入札情報格納部１８、予約情報格納部１９には、ＨＤＤ等の補助記憶装置の所定の記憶領域が割り当てられる。これらの記憶領域は物理的に一台のコンピュータに設けられることを必須の要件とするものではなく、データベースサーバを構成するコンピュータ等の複数のコンピュータに設けられるものであってもよい。

【0040】

ユーザ情報格納部１６に格納されるユーザ情報には、ユーザを識別するユーザＩＤと関連づけて、ユーザの認証に用いられるパスワードや、ユーザの氏名や所属等のユーザマスタ１６１が含まれている。また、ユーザが保有する、予約への入札に必要な入札権であるトークンの残高（トークン残高１６２）に関する情報も、ユーザ情報格納部１６に格納されるユーザ情報に含まれている。

【0041】

ユーザ端末２０は、インターネットに接続して予約管理サーバ１０とのデータの送受信が可能なネットワーク端末であるが、その構成は特に限定されるものではなく、ＰＣ（パーソナルコンピュータ）やタブレット型コンピュータ、スマートフォン等のネットワーク端末を用いることとすればよい。

【0042】

以上の構成を前提にして、本発明に係る予約管理サーバによって、予約への入札が受け付けられる際の処理手順を、図３のフローチャートに沿って説明する。尚、ここでも図１の説明と同様に、本発明を展示会の出展者との面談予約に適用するケースを例に説明するが、本発明の対象が展示会等での面談予約に限定されないことは、先に述べたとおりである。

【0043】

以下に説明するケースの前提として、メーカー等が出展する新製品等の展示会に来場する小売業者や卸売業者の購買担当者（ユーザ端末２０を操作するユーザ）に関する情報が、予約管理サーバ１０のユーザ情報格納部１６に格納されている。ユーザ情報格納部１６に格納されるユーザ情報には、各々の購買担当者（ユーザ）について、図４に例示したような、購買担当者を識別するユーザＩＤ等と関連づけて、各々の購買担当者（ユーザ）の認証に用いられるパスワードや、購買担当者の氏名や所属等のユーザマスタ１６１と、図５に例示したような、展示会の主催者が各々の購買担当者に割り当てた、各ブースでの出展者との面談予約への入札権となるトークンの残高であるトークン残高１６２が含まれている。

【0044】

尚、図５では、トークン残高１６２がユーザＩＤによって識別される購買担当者（ユーザ）毎に管理されている例を示しているが、トークンを個人単位ではなく所属する企業や部署毎に割り当てて、同じ企業や部署に所属する購買担当者が、企業や部署が保有するトークンを共用する運用としてもよい。

【0045】

また、展示会に出展するメーカー毎に、来場する購買担当者にステータスを設定して（図４の例では「ゴールド」等）、自社のブースにおける面談予約への入札が可能な期間や時間枠をステータスに応じて変える運用としてもよく、ここでは高いステータス（「ゴールド」等）が付与されている購買担当者には、先行して予約可能な期間を設ける運用の例を前提として説明する。

【0046】

展示会（この例では、２０２０年１０月２１日－２３日の間にＥ社主催で開催される展示会とする）を訪れたい購買担当者（ユーザ）は、事前に出展者との面談を予約するために、ユーザ端末２０からインターネット経由で予約管理サーバ１０に接続して、当該展示会の面談予約用のＷｅｂページにアクセスする。予約管理サーバ１０ではユーザ認証部１１が起動され、ユーザ端末２０にユーザＩＤとパスワードの入力が求められるので、購買担当者はこれらの情報を入力して、予約管理サーバ１０に送信する。

【0047】

ユーザＩＤとパスワードを受信した予約管理サーバ１０のユーザ認証部１１では、受信したパスワードを、受信したユーザＩＤに対応するユーザ情報格納部１６に格納されたユーザマスタ１６１に登録されているパスワードと照合することによって、ユーザ認証を行う（Ｓ０１）。ユーザの認証方法はパスワード認証に限定されるものではなく、生体認証等の他の認証手段を採用することとしてもよい。

【0048】

ユーザ認証が正常に終了すると、ユーザ端末２０には展示会への出展者であるメーカーのリストが表示されて、購買担当者がその中から興味のある注目メーカーを選択する操作を行うと、予約管理サーバ１０では注目メーカーの選択が受け付けられて（Ｓ０２）、入札可能枠提示部１２が起動される。

【0049】

入札可能枠提示部１２では、図６に例示した、イベント情報格納部１７に格納されたイベント情報の入札可能期間を参照して（Ｓ０３）、その時点が面談予約への入札の受け付けが可能な入札可能期間に該当するかを確認する（Ｓ０４）。

【0050】

入札可能期間は、全ての入札希望者に対して一律に設定されることとしてもよいが、出展者であるメーカーには、それぞれの取引関係等から優先的に来場を促したい小売業者等が存在することが多いので、小売業者、あるいはその購買担当者毎に、各々のメーカーが付与したステータスをユーザ情報格納部１６のユーザマスタ１６１に含めて管理し（図４の例では、ユーザＩＤ「Ａ０００１」により識別されるＡ社の購買担当者に対して、メーカーＸ社は最も優先度の高い「ゴールド」、メーカーＹ社は二番目に優先度の高い「シルバー」のステータスを付与し、メーカーＺ社はステータスを付与しない一般来場者の扱いに設定している）、イベント情報格納部１７に格納されるイベント情報にはステータス毎に異なる入札可能期間を設定しておいて、購買担当者が選択した注目メーカーが付与しているステータスに応じて、入札可能期間に該当するかを判断することとしてもよい。

【0051】

購買担当者による入札が可能な入札可能期間に該当しなければ（Ｓ０４がＮｏ）、そのまま入札受付の処理を終了するが、入札可能期間に該当すれば（Ｓ０４がＹｅｓ）、入札情報格納部１８から面談予約への入札が可能な時間枠に関する情報を取得する（Ｓ０５）。

【0052】

図７は、入札情報格納部１８に格納される入札情報の一例を示したものであるが、展示会の開催日毎に９０分単位の時間枠が区切られていて、各々の時間枠における面談の予約状況が記録されている。

【0053】

この例では、例えば、１０月２１日１０：３０－１２：００の時間枠はすでに全ての時間が面談予約で埋まっているが、１０月２１日０９：００－１０：３０の時間枠には予約が入っておらず、全ての時間を対象に面談予約への入札が可能となっている。また、１０月２１日１４：３０－１６：００の時間枠は、１５：００－１６：００の面談予約が確定しているので、１４：３０－１５：００のみを対象に面談予約への入札が可能な状態となっている。入札可能期間内に受け付けられた入札については、それぞれ該当する時間枠に入札者のユーザＩＤと、入札に用いられたトークンの種別（「Ｌ」「Ｍ」「Ｓ」のいずれか）が記録されている（入札は封印型で行われるのでこれらの情報は非公開に設定される）。

【0054】

尚、一部の時間枠については、面談予約の受け付けを所定のステータスが付与された購買担当者に制限することとしてもよく、そうしたケースではユーザ情報格納部１６のユーザマスタ１６１に含まれる出展者であるメーカーが付与したステータスを参照して、ステータスの条件を満たす時間枠のみを対象にして、入札可能な時間枠を選択することとしてもよい。

【0055】

面談予約への入札が可能な時間枠に関する情報はユーザ端末２０に送信され、ユーザ端末２０の画面に表示されると、購買担当者はその中から面談予約を希望する時間枠を選択して、入札要求を予約管理サーバ１０に送信する。入札が受け付けられるためには、面談予約への入札権であるトークンが必要になるが、購買担当者は自らが保有するトークンの種別（後述するように、トークンの数量を指定するパターンもある）を指定して、入札要求を送信する。

【0056】

尚、入札要求時に購買担当者が使用できるトークンの残高を確認できるようにするためには、面談予約への入札が可能な時間枠に関する情報を送信する際に、購買担当者のユーザＩＤに対応するトークン残高１６２をユーザ情報格納部１６から読み出して、あわせてユーザ端末２０に送信することとすればよい。

【0057】

図５の例では、トークンには３つの種別があって（「Ｌ」のトークンは８０分の面談、「Ｍ」のトークンは５０分の面談、「Ｓ」のトークンは２０分の面談を希望する際の入札に用いるものとする）、ユーザＩＤ「Ａ０００１」により識別されるＡ社の購買担当者は、イベントコード「Ｅ２０２００３」の展示会の面談予約への入札に用いることができるトークンの残高が、当初は５枚（以下、トークンの１単位を「枚」とする。）を割り当てられていた「Ｌ」は１枚、当初は７枚を割り当てられていた「Ｍ」は２枚、当初は１０枚を割り当てられていた「Ｓ」は４枚が残っている状態となっており、これらの残高に関する情報をユーザ端末２０に送信して画面に表示させることとすれば、購買担当者は今後どの程度の面談予約に入札する権利があるかを確認しながら、入札に用いるトークンを選択することが可能になる。

【0058】

予約管理サーバ１０において、Ｓ０５で入札が可能な時間枠に関する情報を送信してから一定時間が経過しても入札要求を受信しない場合（Ｓ０６がＮｏ）は、タイムアウトとなって入札受付の処理を終了するが、時間枠とトークンの種別が指定された入札要求を受け付けると（Ｓ０６がＹｅｓ）、入札登録部１３が起動されて、指定されたトークンから特定される面談の所要時間が指定された時間枠において確保されているか、入札情報格納部１８を参照して確認する（Ｓ０７）。

【0059】

例えば、１４：３０－１５：００の３０分のみしか空き時間がない１０月２１日１４：３０－１６：００の時間枠に対して、所要時間８０分の「Ｌ」や所要時間５０分の「Ｍ」のトークンを指定した入札要求であれば、希望する所要時間が予約可能な時間に収まらない。こうしたケースでは入札を受け付けないこととしてもよいが、ユーザ端末２０にその旨を通知して入札に用いるトークンの変更を促すこととしてもよいし、一旦入札を受け付けて、希望する時間より所要時間を短縮して面談予約を決定することとしてもよい。尚、１０月２１日１０：３０－１２：００のように全ての時間が面談予約で埋まっている時間枠が指定されている場合は、予約を受け付けないこととすればよい。

【0060】

また、入札要求に指定されたトークンが購買担当者の保有するトークンの残高の範囲内にあるか、すなわち、指定された種別のトークンの残高が存在するかを、ユーザ情報格納部１６の購買担当者のユーザＩＤに対応するトークン残高１６２を参照して確認する（Ｓ０８）。図５の例であれば、ユーザＩＤ「Ａ０００１」により識別されるＡ社の購買担当者は、イベントコード「Ｅ２０２００３」の展示会の面談予約への入札に用いることができるトークンの種別「Ｌ」「Ｍ」「Ｓ」いずれのも残高が存在しているため、「Ｌ」「Ｍ」「Ｓ」のいずれのトークンを指定した入札要求であっても、受け付けることが可能と確認できる。

【0061】

以上のように、面談の所要時間とトークン残高を確認して、入札を受け付けるために必要な要件を満たしていることが確認されると（Ｓ０９がＹｅｓ）、入札が受け付けられて、入札要求を送信した購買担当者のユーザＩＤと指定されたトークンの種別が、 入札情報格納部１８の入札した時間枠に記録されるとともに（Ｓ１０）、ユーザ情報格納部１６の購買担当者のユーザＩＤに対応するトークン残高１６２のうち、入札に用いられた種別のトークンの残高が、入札での使用を反映して更新される（Ｓ１１）。

【0062】

続いて、購買担当者が他のメーカーとの面談予約への入札を希望するかユーザ端末２０に確認されて（Ｓ１３）、希望する場合（Ｓ１３がＹｅｓ）は改めて注目メーカーの選択が促され、希望しない場合（Ｓ１３がＮｏ）は入札受付の処理を終了する。

【0063】

入札を受け付けるために必要な要件を満たしていないことが確認された場合は（Ｓ０９がＮｏ）、入札が受け付けられなかったことがユーザ端末２０に通知される（Ｓ１２）。その後は同様に、購買担当者が他のメーカーとの面談予約への入札を希望するかユーザ端末２０に確認されて（Ｓ１３）、希望する場合（Ｓ１３がＹｅｓ）は改めて注目メーカーの選択が促され、希望しない場合（Ｓ１３がＮｏ）は入札受付の処理を終了する。

【0064】

このようにして、様々な小売業者の購買担当者の入札が受け付けられた後、入札可能期間が終了すると、予約管理サーバ１０では予約決定部１４が起動されて、展示会（イベント）の時間枠毎に、入札者の中から面談予約を受け付ける購買担当者（ユーザ）が決定される。

【0065】

具体的には、予約決定部１４は入札情報格納部１８から、時間枠毎に入札者（該当する時間枠にユーザＩＤが記録されている購買担当者）に関する情報を読み出し、所定のルールに基づき落札者を決定して（固定されたルールにより落札者を決定するのではなく、出展者が個別に判断して決定することとしてもよい）、落札した購買担当者に関する情報を、該当する時間枠の面談予約者として予約情報格納部１９に記録する。図８は、予約情報格納部１９に格納された予約情報の例であるが、各々の時間枠には面談予約の時間が割り当てられた購買担当者のユーザＩＤが、面談時間とともに記録されている。時間枠内における具体的な面談時間の指定方法は、特に限定されるものではない。

【0066】

落札できなかった入札者については、他の時間枠に改めて入札を行えるように、面談予約の入札に用いたトークンによって減じられたユーザ情報格納部１６のトークン残高１６２を、入札前の数量に戻す（１枚増やす）処理が行われる。

【0067】

時間枠毎の落札者、すなわち面談予約を受け付ける購買担当者（ユーザ）を決定するルールは、前述のとおり特に限定されるものではないが、図９はその一例を示したものである。このケースでは、入札に用いられたトークンの種別から、希望する面談予約の所要時間が長いものを第一に優先し、トークンの種別が同じである場合は、入札要求のタイミングが早かったものを優先するというルールで、面談予約を受け付ける購買担当者を決定することとしている。

【0068】

図９の例では、時系列で並べると、ユーザＩＤ「Ａ０００１」により識別されるＡ社の購買担当者、ユーザＩＤ「Ｂ０００２」により識別されるＢ社の購買担当者、ユーザＩＤ「Ｃ０００３」により識別されるＣ社の購買担当者の順に入札を受け付けており、ユーザＩＤ「Ａ０００１」は「Ｓ（２０分）」のトークン、ユーザＩＤ「Ｂ０００２」は「Ｍ（５０分）」のトークン、ユーザＩＤ「Ｃ０００３」は「Ｍ（５０分）」のトークンをそれぞれ用いて、入札を行ったものとする。

【0069】

このケースに前述のルールを適用すると、所要時間が長い「Ｍ（５０分）」のトークンを用いて入札したユーザＩＤ「Ｂ０００２」とユーザＩＤ「Ｃ０００３」の入札が、「Ｓ（２０分）」のトークンを用いて入札したユーザＩＤ「Ａ０００１」より優先され、さらにユーザＩＤ「Ｃ０００３」より早く入札したユーザＩＤ「Ｂ０００２」の入札が、ユーザＩＤ「Ｃ０００３」より優先されることになる。

【0070】

時間枠は１０：３０－１２：００の９０分間で、延長の可能性を考慮して面談予約の後には１０分のバッファを入れることにすると（こうしたバッファを考慮して、ここに示した例ではトークンの種別を「Ｌ」は８０分、「Ｍ」は５０分、「Ｓ」は２０分としている）、まずは「Ｍ（５０分）」のトークンで入札したユーザＩＤ「Ｂ０００２」の面談予約が決定され、バッファの１０分を考慮すると残り時間は３０分に限られるため、「Ｍ（５０分）」のトークンで入札したユーザＩＤ「Ｃ０００３」は除外され、「Ｓ（２０分）」のトークンで入札したユーザＩＤ「Ａ０００１」に残りの時間が割り当てられる。

【0071】

但し、上記のような決定方法に限定されるものではなく、本来は入札の優先度がユーザＩＤ「Ａ０００１」より高いユーザＩＤ「Ｃ０００３」の入札を優先し、面談予約の時間を希望する５０分から２０分に短縮して、残り時間は３０分にはユーザＩＤ「Ｃ０００３」の面談予約を入れることとしてもよい（この場合、ユーザＩＤ「Ｃ０００３」のトークン残高１６２には、「Ｍ（５０分）」のトークンを１枚戻して増加させ、「Ｓ（２０分）」のトークンの残高を１枚減じることが必要になる）。

【0072】

尚、図９では、時間枠の全てが面談予約で埋まるケースを説明し、この場合は入札情報格納部１８の当該時間枠には「予約終了」と記録されて、入札可能枠から除外されることになるが、面談予約の決定後も時間枠に余りが発生した場合は、時間枠のうち予約可能な時間帯が入札情報格納部１８の当該時間枠に記録され、入札の所要時間は制限されるものの、次の入札可能期間にも入札可能枠の対象に含まれることになる。

【0073】

図４－９を用いて説明した例では、入札に用いるトークンに面談の所要時間が異なる複数の種別を用意することによって、入札する購買担当者の出展する製品等に対する興味や熱意等の温度感を把握することを可能にしているが、他にもトークンの種別や入札時に用いるトークンの数量から、購買担当者の興味や熱意等の温度感を把握する方法がいくつか想定される。

【0074】

図１０は、図４－９を用いて説明したトークンの種別の例を整理したものであるが、面談の所要時間が異なる複数の種別を用いると、所要時間の長いトークンで入札した購買担当者ほど熱意があって商談が成約しやすいことが推認されるので、この例では優先順位を「Ｌ」「Ｍ」「Ｓ」として落札者を決定すればよいことになる。

【0075】

図１１は、面談の所要時間はいずれも３０分で差がなく、購買担当者にとっての面談の重要度が異なる複数の種別のトークンを用いる例であり、「金」「銀」「銅」の順に重要度が高いこととしているが、重要度の高いトークンで入札した購買担当者ほど熱意があって商談が成約しやすいことが推認されるので、この例では優先順位を「金」「銀」「銅」として落札者を決定すればよいことになる。

【0076】

図１２は、面談の所要時間の単位時間が固定され、面談の重要度にも差がない、一種類のトークンのみが用いられるが、トークン１枚あたりの所要時間が比較的短く設定されており（この例では１０分）、購買担当者は希望する面談の所要時間に応じたトークンの数量を指定して入札を行うこととする例である。指定した数量が多いほど希望する面談の所要時間が長く、購買担当者に熱意があって商談が成約しやすいことが推認されるので、この例では優先順位を「５枚」「４枚」「３枚」として落札者を決定すればよいことになる。

【0077】

面談予約を完了した購買担当者は、予約情報格納部１９に格納された確定した面談予約に関する情報を閲覧することも可能である。その際には、ユーザ端末２０から予約管理サーバ１０に予約情報の閲覧要求を送信すると、予約管理サーバ１０では予約情報閲覧部１５が起動され、ユーザ情報格納部１６のユーザマスタ１６１を参照して購買担当者のユーザ認証を行った上で、予約情報格納部１９に格納された購買担当者の確定した面談予約を閲覧することが可能となっている。

【符号の説明】

【0078】

１０ 予約管理サーバ
１１ ユーザ認証部
１２ 入札可能枠提示部
１３ 入札登録部
１４ 予約決定部
１５ 予約情報閲覧部
１６ ユーザ情報格納部
１６１ ユーザマスタ
１６２ トークン残高
１７ イベント情報格納部
１８ 入札情報格納部
１９ 予約情報格納部
２０ ユーザ端末

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【手続補正書】

【提出日】2021-06-25

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

予約への入札権であるトークンのユーザ毎の残高に関する情報を格納するトークン残高情報格納手段と、
ユーザが操作する端末から、入札に用いられるトークンの種別又は数量が指定された所定の時間枠に予約を行うための入札要求を受信すると、少なくとも前記トークンの種別又は数量が前記トークン残高情報格納手段に格納された前記ユーザが保有するトークンの残高の範囲内にあることを条件に、前記入札要求を受け付ける入札受付手段と、
前記入札受付手段が、同一の時間枠に対して二以上のユーザからの入札を受け付けた場合は、各々のユーザの入札に用いられたトークンの種別又は数量に基づいて、前記時間枠において予約を受け付けるユーザを決定する予約決定手段と、を備えていて、
予約の入札には、所要時間が異なる複数の種別のトークン、重要度が異なる複数の種別のトークン、又は一の入札に対して単位時間が固定された一若しくは二以上のトークンの少なくともいずれかを用いることが可能であり、
前記予約決定手段は、予約の入札に所要時間が異なる複数の種別のトークンが用いられる場合は、同一の時間枠に対して受け付けた入札のうち所要時間が長いトークンを用いた入札を優先して、予約の入札に重要度が異なる複数の種別のトークンが用いられる場合は、同一の時間枠に対して受け付けた入札のうち重要度が高いトークンを用いた入札を優先して、予約の入札に一の入札に対して単位時間が固定された一又は二以上のトークンが用いられる場合は、同一の時間枠に対して受け付けた入札のうち用いられたトークンの数量が多い入札を優先して、予約を受け付けるユーザを決定すること
を特徴とする予約管理サーバ。

【請求項2】

前記入札受付手段は、所要時間を特定可能なトークンが指定された入札要求を受信して、少なくとも前記所要時間が前記時間枠において予約可能な時間の範囲内であることを条件に、前記入札要求を受け付けること
を特徴とする請求項１記載の予約管理サーバ。

【請求項3】

前記トークン残高情報格納手段から、前記ユーザが保有するトークンの残高に関する情報を読み出して、前記端末に前記ユーザが保有するトークンの種別と数量を残高情報として表示させるために送信する残高情報提供手段を備えていて、
前記入札受付手段は、前記端末に表示された残高情報から前記ユーザが選択して決定された、入札に用いられるトークンの種別又は数量が指定された入札要求に関する情報を受信すること
を特徴とする請求項１又は２記載の予約管理サーバ。

【請求項4】

前記ユーザに付与されたステータスを反映して選択された、前記ユーザが入札可能な時間枠に関する情報を、前記端末に送信する入札可能時間枠情報送信手段を備えること
を特徴とする請求項１乃至３いずれかに記載の予約管理サーバ。

【請求項5】

予約への入札権であるトークンのユーザ毎の残高に関する情報を格納するトークン残高情報格納手段を備えた予約管理サーバが、ユーザが操作する端末から、入札に用いられるトークンの種別又は数量が指定された所定の時間枠に予約を行うための入札要求を受信すると、少なくとも前記トークンの種別又は数量が前記トークン残高情報格納手段に格納された前記ユーザが保有するトークンの残高の範囲内にあることを条件に、前記入札要求を受け付ける入札受付ステップと、
前記予約管理サーバが、前記入札受付ステップにおいて、同一の時間枠に対して二以上のユーザからの入札を受け付けた場合は、各々のユーザの入札に用いられたトークンの種別又は数量に基づいて、前記時間枠において予約を受け付けるユーザを決定する予約決定ステップと、を有していて、
予約の入札には、所要時間が異なる複数の種別のトークン、重要度が異なる複数の種別のトークン、又は一の入札に対して単位時間が固定された一若しくは二以上のトークンの少なくともいずれかを用いることが可能であり、
前記予約決定ステップにおいて、前記予約管理サーバは、予約の入札に所要時間が異なる複数の種別のトークンが用いられる場合は、同一の時間枠に対して受け付けた入札のうち所要時間が長いトークンを用いた入札を優先して、予約の入札に重要度が異なる複数の種別のトークンが用いられる場合は、同一の時間枠に対して受け付けた入札のうち重要度が高いトークンを用いた入札を優先して、予約の入札に一の入札に対して単位時間が固定された一又は二以上のトークンが用いられる場合は、同一の時間枠に対して受け付けた入札のうち用いられたトークンの数量が多い入札を優先して、予約を受け付けるユーザを決定すること
を特徴とする予約管理方法。