JP6477208B2 - 予約処理システム、予約処理サーバー、商品取引処理プログラム - Google Patents

Description

本発明は、予約希望者からの商品購入予約に係る当該予約情報を受け付けて送信する予約者端末と、予約者端末から受信した予約情報に基づいて予約の受付処理を行う予約処理サーバーとを備えた予約処理システム、予約処理サーバー、及び商品取引処理プログラムに関する。

インターネット等の通信回線網を利用し、交通手段（航空機、列車等）のチケット、施設の使用権利、及びイベントの入場券といった商品の購入を予約する予約処理システムが普及している。

予約システムは、基本的に、購入希望者側が、希望商品に条件を付けて特定することで、商品提供側から希望商品の条件に適合する一覧を提示し、この一覧を参照して、購入希望者が選択する、といった流れとなっている。

ところで、予約処理システムでは、希望商品の条件（特に、価格）が変動する場合がある。予約時において、予約する商品の価格が、購入希望者が望む価格よりも高い場合、購入希望者は、今後に実行される可能性のあるセール期間による価格の引き下げを、こまめにチェックする必要がある。

また、予約を確定した後（商品購入後）に、同一の商品が安い価格となった場合、予約希望者は不利益をこうむることになる。

一方、商品提供側は、需要が少ないと想定し通常価格よりも安い価格とした商品の需要が多くなり、需要が多いと想定し通常価格（又は、繁盛期価格）とした商品の需要が少なくなる場合がある。

特許文献１には、複数の予約希望候補および予約決定希望時間を含む予約情報を受け付けて予約処理サーバーへ送信する予約者端末と、予約者端末から受信した予約情報に基づいて、予約希望候補の内の１つを暫定的な予約である仮予約に割り当て、予約決定希望時間に至るまでの間に受信した後着の予約情報に対して所定の条件を満たすことを条件に前記仮予約とした候補を当該後着の予約情報に対する予約商品に割り当て、前記仮予約として前記予備予約とした候補を補填する予約処理サーバーを備えた予約処理システムが記載されている。

この特許文献１によれば、予約の時期から、実際に予約が決定時期までの間に変動する条件（価格）に臨機応変に対応することができる。

ＷＯ２００５／０９８７００

しかしながら、特許文献１の含む従来の予約処理システムでは、以下の課題がある。

（課題１） 商品提供側は、予約決定希望時間が遅い場合や予約希望候補の選択肢が多い予約希望者に、インセンティブを与えるための条件（価格）を提示することになり、予約希望者は、提示された条件（価格）よりも好条件（安い価格）で予約待ちをすることができず、予約希望者にとって不利益となる場合がある。

（課題２） 商品提供側は、予約希望者に対して条件（価格）を提示し、その後条件を変動させることはない。他の予約商品が予約希望者の条件に適合し、商品提供側に有利であっても、変更することができないため、商品提供側にとって不利益となる場合がある。

本発明は上記事実を考慮し、予約希望候補として商品を予約するときの条件の幅が制限されることがなく、予約確定時期までの期間に変動する商品の条件に併せて、予約希望者側の予約条件に適合し、かつ商品提供側に有利な予約希望候補を選択することができる予約処理システム、予約処理サーバー、及び商品取引処理プログラムを得ることが目的である。

本発明は、予約希望者からの商品購入予約に係る当該予約情報を受け付けて送信する予約者端末と、予約者端末から受信した予約情報に基づいて予約の受付処理を行う予約処理サーバーとを備えた予約処理システムであって、前記予約者端末は、予約希望者が入力した予約を希望する商品を指定する複数の予約希望候補、予約希望候補毎の許容条件、および当該予約を確定する期限を指定する予約確定時期、を含む予約情報を受け付けて前記予約処理サーバーへ送信する機能を有し、前記予約処理サーバーは、予約者端末から受信した予約情報に基づいて、各予約希望候補の実条件が許容条件に適合しているか否かの判断の下、少なくとも１つの予約希望候補を保証し得た場合に、前記予約確定時期に至るまでに変動する実条件が許容条件に適合するか否かの判定結果に基づいて、保証し得る予約希望候補を更新し、前記予約確定時期に到達した時点で保証し得る予約希望候補であり、かつ商品提供側に有利な予約希望候補を選択し、予約者端末へ予約処理結果を送信する機能を有する、予約処理システムである。

本発明によれば、予約希望者は、予約者端末を用いて商品購入予約に係る予約情報を入力する。

予約情報は、予約を希望する商品を指定する複数の予約希望候補、予約希望候補毎の許容条件、および当該予約を確定する期限を指定する予約確定時期、を含む。

予約者端末では、予約情報を受け付けると、予約処理サーバーへ送信する。

予約処理サーバーでは、予約者端末から受信した予約情報に基づいて、各予約希望候補の実条件が許容条件に適合しているか否かの判断を実行する。

予約処理サーバーでは、この適合か否かの判断下、少なくとも１つの予約希望候補を保証し得る場合がある。言い換えれば、予約希望候補が保証できない場合は、予約そのものが無効となる。

前述の如く、少なくとも１つの予約希望候補を保証し得た場合には、予約確定時期に至るまでに変動する実条件が許容条件に適合するか否かの判定結果に基づいて、保証し得る予約希望候補を更新する。

なお、予約希望候補を保証し得た場合、当該保証した旨を示す情報を予約者端末へ送信し、予約希望者へ通知してもよい。通知を受けた予約希望者は、少なくとも１つの予約希望候補が確保できたことを認識することができる。

予約処理サーバーでは、予約確定時期に到達した時点で保証し得る予約希望候補であり、かつ商品提供側に有利な予約希望候補を選択し、予約者端末へ予約処理結果を送信する（予約希望者への通知）。

これにより、予約希望者及び商品提供者の双方に対して、不利益かがこうむることがない予約処理を実行することができる。

本発明において、前記予約者端末は、予約の受け付け時点において、前記予約希望候補の予約を保証し得る実条件が報知される。

予約希望者は、報知されている実許容条件を満たす許容条件を入力することで、該当する予約希望候補を保証することができる。例えば、予約希望者が、必ず予約しなければならない場合、予約の受け付け時点において、少なくとも１つの予約希望候補を確保することができる。

なお、複数の予約希望候補で、報知されている実許容条件を満たすように許容条件を入力した場合、予約確定時期に到達した時点で保証し得る予約希望候補であり、かつ商品提供側に有利な予約希望候補を選択することで、予約希望者及び商品提供側の双方に不利益をもたらすことがない。

本発明において、前記予約処理サーバーは、前記保証し得る予約希望候補が、前記予約確定時期に近づくにつれて、特定の予約希望者にとって不利となる実条件の変動が発生した場合は、前記更新を禁止して現在の予約希望候補の実条件を維持する。

特定の予約希望者が予約を実行するときの実条件の変動は、予約希望者に不利となる変動となる場合がある。しかし、特定の予約希望者にとって不利となる実条件の変動が発生した場合は、前記更新を禁止して現在の予約希望候補の実条件を維持する。これにより、特定の予約希望者が不利益をこうむることがない。

本発明において、前記予約希望候補の実条件の維持は、前記特定の予約希望者に限定して実行される。

特定の予約希望者にとって不利となる実条件の変動が発生した場合の、更新の禁止に起因する商品提供側の不利益を最小限に抑えることができる。また、システム全体の条件バランスを維持することができる。

本発明において、前記予約者端末は、予約情報の受け付けの際に、前記保証し得る予約希望候補の実条件が不利益に変動しないことを示す情報、及び、前記予約の受付処理をする時期と前記予約確定時期との期間が長いほど前記予約処理結果が有利となることを示す情報、を報知する。

予約希望者に対して、保証し得る予約希望候補の実条件が不利益に変動しないことを示す情報、及び、予約の受付処理をする時期と予約確定時期との期間が長いほど予約処理結果が有利となることを示す情報、を報知することで耐戦略性を持つ予約処理システムであることをアピールすることができる。

本発明において、前記予約情報には、複数の保証し得る予約希望候補が存在する場合の選択要素の優先度に関する情報が含まれており、当該優先度に関する情報が、前記予約確定時期における予約希望候補の選択において、前記商品提供側の有利性の判断よりも優先される。

予約情報に含まれる優先度に関する情報は、予約確定時期における予約希望候補の選択において、前記商品提供側の有利性の判断よりも優先されるため、予約希望者が不利になることを抑制できる。

本発明において、前記予約処理サーバーは、前記予約希望者の各々の予約情報の履歴に基づいて、複数の保証し得る予約希望候補が存在する場合の選択要素の優先度に関する情報を策定し、当該優先度に関する情報が、前記予約確定時期における予約希望候補の選択において、前記商品提供側の有利性の判断よりも優先される。

予約処理サーバーでは、予約希望者の各々の予約情報の履歴に基づいて、複数の保証し得る予約希望候補が存在する場合の選択要素の優先度に関する情報を策定する。策定された優先度に関する情報は、予約希望者の各々の予約に関する所謂嗜好の判断材料となる。

このため、策定された優先度に関する情報は、予約確定時期における予約希望候補の選択において、前記商品提供側の有利性の判断よりも優先されるため、予約希望者が不利になることを抑制できる。

本発明において、前記保証し得る予約希望候補が更新可能な場合に、前記予約処理サーバーは、前記予約者端末に対して、前記更新可能となる毎に予約希望候補の更新をするか否かの判断を通知する。

予約処理サーバーでは、保証し得る予約希望候補が更新可能な場合、予約者端末に対して、更新可能となる毎に予約希望候補の更新をするか否かの判断を通知する。これにより、予約処理に際し、予約希望者の希望を取り入れることができる。なお、通知に対する返信がない場合は、更新するか否か、及びその決定時期を併せて通知すればよい。

本発明は、予約者端末から受け付けた、予約希望者が入力した予約を希望する商品を指定する複数の予約希望候補、予約希望候補毎の許容条件、および当該予約を確定する期限を指定する予約確定時期、を含む予約情報に基づいて、各予約希望候補の実条件が許容条件に適合しているか否かを判断する判断手段と、前記判断手段による判断の下、少なくとも１つの予約希望候補を保証し得た場合に、前記予約確定時期に至るまでに変動する実条件が許容条件に適合するか否かの判定結果に基づいて、保証し得る予約希望候補を更新する更新手段と、前記予約確定時期に到達した時点で保証し得る予約希望候補であり、かつ商品提供側に有利な予約希望候補を選択することで確定する予約希望者への予約処理結果を予約者端末へ通知する通知手段と、を有する予約処理サーバーである。

本発明は、予約者端末から受け付けた、予約希望者が入力した予約を希望する商品を指定する複数の予約希望候補、予約希望候補毎の許容条件、および当該予約を確定する期限を指定する予約確定時期、を含む予約情報に基づいて、各予約希望候補の実条件が許容条件に適合しているか否かの判断の下、少なくとも１つの予約希望候補を保証し得た場合に、前記予約確定時期に至るまでに変動する実条件が許容条件に適合するか否かの判定結果に基づいて、前記保証し得る予約希望候補を更新し、前記予約確定時期に到達した時点で保証し得る予約希望候補であり、かつ商品提供側に有利な予約希望候補を選択することで確定する予約希望者への予約処理結果を予約者端末へ通知することを、コンピュータに実行させる商品取引処理プログラムである。

以上説明した如く本発明によれば、予約希望候補として商品を予約するときの条件の幅が制限されることがなく、予約確定時期までの期間に変動する商品の条件に併せて、予約希望者側の予約条件に適合し、かつ商品提供側に有利な予約希望候補を選択することができるという優れた効果を有する。

本実施の形態に係り、通信回線網を用いた予約処理システムの構成図である。 本実施の形態に係る予約処理システムに適用される入力端末と予約処理サーバーとの制御ブロック図である。 （Ａ）は、本実施の形態に適用される入力端末の斜視図、（Ｂ）は入力端末の出力装置としてモニタ画面の画角を特定するための正面図である。 本実施の形態に係る予約処理システムに適用される入力端末と予約処理サーバーによる予約処理を実行するための処理を機能別に示した機能ブロック図である。 本実施の形態に係る入力端末における商品取引予約アプリケーションプログラムの流れを示すフローチャートである。 本実施の形態に係る予約処理サーバーにおける商品取引処理プログラムの流れを示す制御フローチャートである。 図５に示した入力端末１２の操作手順と、図６に示した予約処理サーバーの処理の流れとを１回の通信の流れとして関連付けた、入力端末１２と予約処理サーバーとの間の通信プロトコルである。 図６の変形例に係り、条件設定表の更新を組み込んだ場合の、商品取引処理実行部３２での処理の流れを示す制御フローチャートである。 本実施の形態の実施例１に係り、航空券チケット予約のための流れに沿った、入力端末の出力装置（モニタ画面）の正面図（前半）である。 本実施の形態の実施例１に係り、航空券チケット予約のための流れに沿った、入力端末の出力装置（モニタ画面）の正面図（後半）である。 本実施の形態の実施例２に係り、航空券チケット予約のための流れに沿った、入力端末の出力装置（モニタ画面）の正面図（前半）である。 本実施の形態の実施例２に係り、航空券チケット予約のための流れに沿った、入力端末の出力装置（モニタ画面）の正面図（後半）である。 本実施の形態の実施例３に係り、航空券チケット予約のための流れに沿った、入力端末の出力装置（モニタ画面）の正面図（前半）である。 本実施の形態の実施例３に係り、航空券チケット予約のための流れに沿った、入力端末の出力装置（モニタ画面）の正面図（後半）である。 本実施の形態の実施例４に係り、航空券チケット予約のための流れに沿った、入力端末の出力装置（モニタ画面）の正面図（一部）である。

（システム構成）
図１には、本実施の形態に係る、商品取引の際の予約を受け付けて、商品取引を実現するための予約処理システムの概略構成図が示されている。

予約処理システムは、インターネット等の通信回線網１０を中心としたネットワークによって構築されている。

図１に示される如く、通信回線網１０には、本実施の形態に係る入力端末として、ノートパソコン１２Ｎ、デスクトップパソコン１２Ｄ、無線通信デバイス１４を介して携帯通信端末１２Ｍがそれぞれ接続されている。なお、以下、ノートパソコン１２Ｎ、デスクトップパソコン１２Ｄ、携帯端末１２Ｍを総称する場合、「入力端末１２」等という。また、図１では、３台の入力端末１２が接続されているが、この数は限定されるものではない。

携帯通信端末１２Ｍは、無線通信デバイス１４を介して無線によって情報を送受信するようになっている。ノートパソコン１２Ｎ、デスクトップパソコン１２Ｄにおいても、無線通信デバイス１４を介在させ、無線によって情報を送受信するようにしてもよい。

また、図１に示される如く、この通信回線網１０には、予約処理入力端末装置１６から受け付けた予約を処理する予約処理管理装置１６（以下、「予約処理サーバー１６」という場合がある。）が接続されている。

予約処理サーバー１６は、主として、通信回線網１０に接続されている入力端末１２から商品取引の予約情報を受け付け、商品の価格変動を加味した上で、顧客にインセンティブを与え、かつ、耐戦略性に則った予約処理を一括管理する役目を有している。入力端末１２及び予約処理サーバー１６を用いた予約処理システムの詳細な機能については省略する。

図２に示される如く、入力端末１２は、ＣＰＵ１２Ａ、ＲＡＭ１２Ｂ、ＲＯＭ１２Ｃ、Ｉ／Ｏ１２Ｄ及びこれらを相互に接続するデータバスやコントロールバス等のバス１２Ｅを備えたマイクロコンピュータ１８を具備する。

Ｉ／Ｏ１２Ｄには、入力装置１２Ｆ、出力装置１２Ｇ、ハードディスク（ＨＤＤ）１２Ｈ、無線（または有線）による通信Ｉ／Ｆ１２Ｉが接続されている。通信Ｉ／Ｆ１２Ｉには、前記通信回線網１０が接続されている。なお、Ｉ／Ｏ１２Ｄには、ＵＳＢに代表される外部デバイスとの接続端であるＩ／Ｆが接続される場合がある。

また、図２に示される如く、予約処理サーバー１６は、ＣＰＵ１６Ａ、ＲＡＭ１６Ｂ、ＲＯＭ１６Ｃ、Ｉ／Ｏ１６Ｄ及びこれらを相互に接続するデータバスやコントロールバス等のバス１６Ｅを備えたマイクロコンピュータ２０を具備する。

Ｉ／Ｏ１６Ｄには、ハードディスク（ＨＤＤ）１６Ｈ、無線（または有線）による通信Ｉ／Ｆ１６Ｇが接続されている。通信Ｉ／Ｆ１６Ｇには、前記通信回線網１０が接続されている。

なお、予約処理サーバー１６は、基本的には、データの送受信が行われればよく、顧客が操作する入力装置や顧客が目視確認するモニタ等の出力装置は必須ではない。例えば、メンテナンス時では、専用又は汎用のＩ／ＦにＰＣ等を接続して、入力装置や出力装置を代行するようにすればよい。

入力端末１２には、予め商品取引予約アプリケーションプログラムが予め登録されている。入力端末１２の入力装置１２Ｆの操作によって、商品取引予約アプリケーションプログラムを起動すると、出力装置１２Ｇ（ここでは、モニタ画面）に商品取引を実現するための初期画面が表示されるようになっている。図３は、入力端末１２の出力装置１２Ｇ（モニタ画面）の画像の表示形態が示されている。

例えば、図３（Ａ）に示される如く、ノートパソコン１２Ｎの出力装置１２Ｇ（モニタ画面）の画角（ｘ寸法とｙ寸法の比率）と、携帯端末１２Ｍの画面の画角（ｘ寸法とｙ寸法の比率）とは異なる場合があるが、それぞれに登録された商品取引予約アプリケーションプログラムにおいて、機器を認識することで、当該画角（ｘ寸法とｙ寸法の比率）は適宜調整される（図３（Ｂ）参照）。

すなわち、図３（Ｂ）では、出力装置１２Ｇ（モニタ画面）の画角（ｘ寸法とｙ寸法の比率）を「１：１」としているが、入力端末１２の種類により、横長に表示される場合、縦長に表示される場合を含む。例えば、以下で示す図９〜図１５に示す出力装置１２Ｇ（モニタ画面）のフォーマットは一例であり、内容以外は入力端末１２の種類によって適宜変更される。

図４（Ａ）に示される如く、商品取引予約アプリケーションプログラムは、マイクロコンピュータ１８（図２参照）の１つの機能である商品取引予約実行部２２において動作する。商品取引予約実行部２２は、入力装置１２Ｆの操作入力によって受け付けた認証情報や、商品取引に関する情報（例えば、予約情報）を解析する解析機能２４、解析機能２４で解析した商品取引に関する情報を予約処理サーバー１６へ送信する送信機能２６、予約処理サーバー１６から情報を受信する受信機能２８、受信した情報を出力装置１２Ｇ（モニタ画面）へ表示する画像処理機能３０を備える。

一方、予約処理サーバー１６は、入力端末１２（図１参照）から商品取引に関する情報を受け付けると、マイクロコンピュータ２０及びハードディスク１６Ｈ（図２参照）の１つの機能である商品取引処理実行部３２（図４（Ｂ）参照）が、商品取引処理プログラムに基づき起動して、商品取引を実行する。

図４（Ｂ）は、予約処理サーバー１６における、商品取引処理実行部３２の商品取引のための機能ブロック図である。なお、図４を示す各ブロックは、予約処理サーバーのハード構成を限定するものではない。

図４（Ｂ）に示される如く、予約処理サーバー１６のハードディスク１６Ｈには、商品取引処理実行部３２の一部を構成する機能として、顧客を管理（認証を含む）するための顧客管理データベース３４、商品の在庫を管理する商品在庫データベース３６、顧客毎の商品取引条件が設定された条件設定データベース３８が記憶されている。

通信Ｉ／Ｆ１６Ｇは、情報受付部４０に接続されており、入力端末１２（図４（Ａ）参照）からの情報（認証情報、予約プラン情報、商品プラン関連情報等）を受け付ける。

情報受付部４０は、認証実行部４２及び商品取引情報受付部４４に接続されている。

認証実行部４２は、顧客管理データベース３４に登録されている顧客情報に基づいて、受け付けた予約情報の顧客の認証を行う。

認証実行部４２は、前記商品取引情報受付部４４に接続されており、認証が適正に行われると、商品取引情報受付部４４に対して受け付けの許可信号を送出する。

この許可信号を受けて、商品取引情報受付部４４では、商品プラン関連情報を受け付け、条件設定表読出部４６に送出する。

条件設定表読出部４６は、条件設定データベース３８に接続されており商品プラン関連情報（顧客情報を含む）に基づいて、商品取引を依頼してきた顧客に対応する条件設定表を読み出し、当該条件設定表情報を、前記商品プラン関連情報と共に、商品プラン確認部４８へ送出する。

また、前記商品取引情報受付部４４では、商品プラン関連情報の１つとして受け付けた確定希望時期情報を確定希望時期管理部５０へ送出する。確定希望時期情報は、顧客が要求する商品取引を確定させる時期である。

確定希望時期管理部５０には、タイマ５２が接続されており、確定希望時期を監視する。

前記商品プラン確認部４８には、商品在庫データベース３６が接続されている。商品プラン確認部４８では、商品プラン関連情報及び条件設定表情報に基づき、顧客が要求する商品プランの有無を確認する。

商品プラン確認部４８は、商品プラン情報送出部５４及び商品プラン更新部５６に接続されている。

商品プラン情報送出部５４では、顧客が要求する商品プランの有無情報、及び商品プランが１つ以上存在する場合は当該商品プランを現在の条件で保証する旨の情報を、通信Ｉ／Ｆ１６Ｇを介して、入力端末１２へ送出（顧客へ報知）する。

商品プラン更新部５６は、商品在庫データベース３６に接続されている。商品プラン更新部５６では、時々刻々と変化する商品在庫に基づいて、商品プランの更新を実行する。商品プランの更新とは、顧客が要求する商品プランとして新たに追加し得る商品プランがあるか否かを判断する。また、新たに追加し得る商品プランがあった場合は、既存の商品プランとの優劣を判断する。なお、顧客に対して既に報知した商品プランが顧客にとって劣化する変更はしないことが好ましい。

商品プラン更新部５６では、この結果、顧客が要求する複数の商品プランが存在する場合に、商品提供側に最も有利な商品プランが常に最優先として更新され、更新プラン一時格納部５８へ一時的に格納される。

更新プラン一時格納部５８には、前記確定希望時期監視部５０が接続されている。更新プラン一時格納部５８では、確定希望時期監視部５０から、確定希望時期に到達したことを示す信号が入力されると、現在一時的に記憶している商品プランを、確定した商品プランとして、確定商品プラン送出部６０へ送出する。

確定商品プラン送出部６０では、確定した商品プランに関する情報を、通信Ｉ／Ｆ１６Ｇを介して、入力端末１２へ送出（顧客へ報知）する。

以下に本実施の形態の作用を説明する。

（入力端末１２側の操作手順）
図５は、入力端末１２における商品取引予約アプリケーションプログラムの流れ、すなわち、商品取引の予約を実行する入力端末処理ルーチンを示すフローチャートである。

入力端末１２において、商品取引予約アプリケーションプログラムを起動させると、まず、ステップ１００では、出力装置１２Ｇに初期画面が表示される。初期画面は、例えば、図９（Ａ）に示される如く、航空券購入ガイド画面であり、次のステップ１０２において、入力装置１２Ｆを用いて認証情報を入力する。認証情報は、例えば、顧客を識別するための識別符号である。

次のステップ１０４では、入力した認証情報を予約処理サーバー１６へ送信する。次のステップ１０６では、認証が完了したか否かが判断され、このステップ１０６で否定判定されると、ステップ１０８へ移行して認証エラーを受信したか否かが判断される。ステップ１０８で否定判定された場合は、ステップ１０６へ戻り、何れかで肯定判定されるまで、ステップ１０６及びステップ１０８を繰り返す。

ステップ１０８で肯定判定されると、認証ができなかったと判断され、ステップ１１０へ移行して認証エラー処理が実行され、ステップ１３６へ移行して、通信完了処理が実行されて、このルーチンは終了する。なお、認証エラー処理には、再認証が含まれ、再認証によって認証が完了した場合は、ステップ１０６で肯定判定されたとものとしてもよい。

ステップ１０６で肯定判定されると（又は、再認証で認証が完了すると）、ステップ１１２へ移行し、出力装置１２Ｇに、予約プラン入力画面が表示される。予約プランは、例えば航空券チケット購入であれば、図９（Ｂ）に示される如く、出発日、出発地、目的地である。

次のステップ１１４では、予約プランの入力が終了したか否かが判断され、このステップ１１４で肯定判定されると、ステップ１１６へ移行して、予約プランに関する情報を予約処理サーバー１６へ送信し、ステップ１１８へ移行する。

ステップ１１８では、前記予約プランに関する情報の応答として、予約処理サーバー１６から希望の商品プランの条件一覧を受信したか否かが判断される。このステップ１１８で肯定判定されると、ステップ１２０へ移行して、出力装置１２Ｇには、希望の商品プランの条件一覧画面が表示される。

希望の商品プランの条件一覧画面は、例えば、図９（Ｃ）に示される如く、予約プランに基づいて予約処理サーバー１６に適合した商品プランの一覧が表示される画面である。

顧客は、この希望の商品プランの条件一覧画面に基づいて、商品プランの関連情報として、希望商品プランの選択（予約希望候補）、希望価格（許容条件）、スケジュール確定希望日時（予約確定時期）を入力する（ステップ１２２）。

商品プランの関連情報は、例えば、図９（Ｄ）に示される如く、航空券チケット購入であれば、希望商品プランの選択（予約希望候補）が便であり、希望価格（許容条件）が各便の購入希望価格であり、スケジュール確定希望日時（予約確定時期）がチケットの確定時期である。

すなわち、希望商品プランの選択は、一覧画面に列挙されている出発便の中で希望する便名を選択する。

希望価格は、選択した出発便の航空券を購入するときの希望価格を入力する。なお、希望価格の入力が便の選択と認識するようにしてもよい。言い換えれば、希望価格の入力がない便は非選択便として判断される。

なお、この希望価格の入力は、所謂入札であり、常識を逸脱した価格（例えば、１０円等）を入力することも可能である。商品提供側からすれば、常識を逸脱した価格でも、顧客を呼び込むサービスとして採用される場合がある。

スケジュール確定希望日時は、購入する航空券の便名の確定を顧客が待つことができる最終日時である。すなわち、予約時からスケジュール確定希望日時までの期間は、航空券キャンセルや価格変動を加味することができる猶予期間ということができる。

次のステップ１２４では、ステップ１２２で入力した商品プランの関連情報を予約処理サーバー１６へ送信し、ステップ１２６へ移行する。

ステップ１２６では、顧客の希望に沿う（適合する）商品プランが存在し、当該適合商品プランを保証する旨の情報を受信したか否かが判断され、肯定判定されると、ステップ１２８へ移行する。

なお、ステップ１２６で否定判定され場合は。ステップ１３０へ移行して取引不成立の通知を受信したか否かが判断され、否定判定されると、ステップ１２６へ戻る。ここで、スケジュール確定希望日時までの、ステップ１２６及びステップ１３０の繰り返し中に、
キャンセル又は価格変動があって、適合する商品プランが出れば、ステップ１２６で肯定判定されてステップ１２８へ移行する。また、スケジュール確定希望時期までの、ステップ１２６及びステップ１３０の繰り返し中に、適合する商品プランが出なければ、ステップ１３０で肯定判定されて、ステップ１３６へ移行し、通信完了処理が実行されて、このルーチンは終了する。従って、顧客は、少なくとも１つが保証し得るように商品プランの関連情報を入力することが好ましい。

ステップ１２８では、出力装置１２Ｇに保証商品を案内する画面が表示され、ステップ１３２へ移行する。

ステップ１３２では、確定商品プランを受信したか否かが判断される。すなわち、スケジュール確定希望時期になると、予約処理サーバー１６から確定商品プランが送信されてくる予定であるため、このステップ１３２は、当該スケジュール確定希望日時までの待機ステップとなる。

スケジュール確定希望時期、すなわち、ステップ１３２で肯定判定されると、ステップ１３４へ移行して確定商品を案内する画面が表示され、次いで、ステップ１３６へ移行して通信完了処理が実行されて、このルーチンは終了する。

（予約処理サーバーでの処理手順）
図６は、予約処理サーバー１６における商品取引処理プログラムの流れ、すなわち、商品取引処理実行部３２での処理の流れを示す制御フローチャートである。

ステップ１５０では、顧客（例えば、顧客Ａ）の識別符号の受け付けに基づく認証処理が実行され、認証完了後、ステップ１５２へ移行して、入力端末１２から顧客Ａの予約プランを受付けたか否かが判断される。

ステップ１５２で肯定判定されると、ステップ１５４へ移行して、予約プランに基づく希望商品プランの一覧を入力端末１２へ送信する。

次のステップ１５６では、入力端末１２から商品プランの関連情報を受付けたか否かが判断され、肯定判定されると、ステップ１５８へ移行して、顧客Ａに適用される、条件設定表を条件設定表データベース３８から読み出し、ステップ１６０へ移行する。

ステップ１６０では、読み出した条件設定表に基づき、取引可能な商品プランがあるか否かが判断される。

このステップ１６０で否定判定されると、ステップ１６２へ移行して、顧客Ａが指定したスケジュール確定希望時期に到達したか否かが判断される。このステップ１６２で否定判定されると、ステップ１６４へ移行して、顧客Ａに適用される条件設定表に変更があったか否かが判断される。

ステップ１６４において、肯定判定された場合は、顧客Ａに対して取引可能な商品プランが存在する可能性があるため、ステップ１５８へ移行する。また、ステップ１６４で否定判定された場合は、現時点では、顧客Ａに対して取引可能な商品プランが存在する可能性がないため、ステップ１６２へ移行する。

一方、ステップ１６２で肯定判定された場合は、スケジュール確定希望時期までに、顧客Ａに対して取引可能な商品プランが出てこなかったと判断し、ステップ１６５で顧客Ａに取引不成立を通知し、このルーチンは終了する。

一方、ステップ１６０において、肯定判定、すなわち、顧客Ａから受付けた希望商品プランの中に取引可能な商品プランが存在していた場合は、ステップ１６０からステップ１６６へ移行する。

ステップ１６６では、入力端末１２（顧客Ａ）に何れかの商品プランを保証する旨を通知し、ステップ１６８へ移行する。この保証する商品プランは、確定希望時期までの仮の商品プランであり、顧客Ａの他の希望商品プランに変更される場合がある。

なお、顧客Ａが仮設定の商品プランで確定を希望し、その旨の通知を受けた場合は、スケジュール確定希望時期を待たずに、仮設定した商品プランを確定させてもよい。

ステップ１６８では、スケジュール確定希望時期に到達したか否かが判断され、肯定判定されると、ステップ１７０へ移行して、顧客Ａの条件を満たし、かつ、到達時点で商品提供側に最も都合の良い（例えば、最も利益率の高い）商品プランを選択し、次いで、ステップ１７２へ移行して、選択した商品プランを入力端末１２（顧客Ａ）に通知して、このルーチンは終了する。

例えば、顧客Ａの希望に適合した商品プランが複数存在する場合、顧客Ａからすれば、自身の希望に適合した商品プランであれば、何れの商品プランであっても問題はない。一方、商品提供側からすれば、複数の商品プランの内、例えば、利益率の高い商品プランを提供しても、顧客Ａの希望から逸脱することはなく、所謂「win-win」の関係とすることができ、双方に都合の良い結果を得ることができる。

（入力端末と予約処理サーバーとの通信プロトコル）
図７は、図５に示した入力端末１２の操作手順と、図６に示した予約処理サーバーの処理の流れとを１回の通信の流れとして関連付けた、入力端末１２と予約処理サーバーとの間の通信プロトコルである。以下の通信プロトコルの説明において、括弧内の数字は、図５又は図６に付与したステップ番号である。

入力端末１２の商品取引予約アプリケーションが起動し、初期画面が表示（１００）され、入力された、認証のための識別符号を予約処理サーバー１６へ送信すると、予約処理サーバー１６では認証処理が実行される（１５０）。

入力端末１２では、認証確認送信を受けると、予約プラン入力画面が表示され（１１２）、予約プランを入力し、予約処理サーバー１６へ送信する（１１６）。

予約処理サーバー１６側で希望商品プランを検索し、入力端末１２へ希望商品プランの一覧を送信する（１５４）。

この結果、入力端末１２には、商品プラン関連情報入力画面が表示され（１２０）、この商品プラン関連情報入力画面に基づいて、商品プラン関連情報を入力し、送信する（１２２，１２４）。

予約処理サーバー１６では、顧客毎の条件設定表を読み出し（１５８）、適合する商品プランを選別し、取引可能な商品プランがあったときは、入力端末１２へ当該商品プランを保証する旨を通知する（１６６）。この通知を受けた入力端末１２では、保証商品プランが案内された画面が表示される（１２８）。

この保証商品プランを案内してから、スケジュール確定希望時期までは、顧客毎の条件設定表の変動に基づき適合商品プランの更新が実行される。

スケジュール確定希望時期になると、予約処理サーバー１６は、確定希望時期到達時の適合商品プランから１つを選択し（１７０）、入力端末１２へ通知する（１７２）。

入力端末１２では、通知を受けた確定商品プランを案内する画面が表示される。

（変形例）
なお、本実施の形態では、特定の顧客に対する商品取引に特化して説明したが、例えば、特定の顧客に対する商品取引により、他の顧客に影響を及ぼす場合がある。

そこで、特定の顧客に対する商品取引に基づく状況の変化をその都度更新し、各顧客毎に設定している条件設定表を更新するようにしてもよい。

図８は、図６において、条件設定表の更新を組み込んだ場合の、商品取引処理実行部３２での処理の流れを示す制御フローチャートである。なお、図６と同一の処理を示すステップは、同一のステップ番号の末尾に符号「Ａ」を付す。

ステップ１５０Ａでは、顧客（例えば、顧客Ａ）の識別符号の受け付けに基づく認証処理が実行され、認証完了後、ステップ１５２Ａへ移行して、入力端末１２から顧客Ａの予約プランを受付けたか否かが判断される。

ステップ１５２Ａで肯定判定されると、ステップ１５４Ａへ移行して、予約プランに基づく希望商品プランの一覧を入力端末１２へ送信する。

次のステップ１５６Ａでは、入力端末１２から商品プランの関連情報を受付けたか否かが判断され、肯定判定されると、ステップ１５８Ａへ移行して、顧客Ａに適用される、条件設定表を条件設定表データベース３８から読み出し、ステップ１６０Ａへ移行する。

ステップ１６０Ａでは、読み出した条件設定表に基づき、取引可能な商品プランがあるか否かが判断される。

このステップ１６０Ａで否定判定されると、ステップ１６２Ａへ移行して、顧客Ａが指定したスケジュール確定希望時期に到達したか否かが判断される。このステップ１６２Ａで否定判定されると、ステップ１６４Ａへ移行して、顧客Ａに適用される条件設定表に変更があったか否かが判断される。

ステップ１６４Ａにおいて、肯定判定された場合は、顧客Ａに対して取引可能な商品プランが存在する可能性があるため、ステップ１５８Ａへ移行する。また、ステップ１６４Ａで否定判定された場合は、現時点では、顧客Ａに対して取引可能な商品プランが存在する可能性がないため、ステップ１６２Ａへ移行する。

一方、ステップ１６２Ａで肯定判定された場合は、スケジュール確定希望時期までに、顧客Ａに対して取引可能な商品プランが出てこなかったと判断し、ステップ１６５Ａで顧客Ａに取引不成立を通知し、このルーチンは終了する。

一方、ステップ１６０Ａにおいて、肯定判定、すなわち、顧客Ａから受付けた希望商品プランの中に取引可能な商品プランが存在していた場合は、ステップ１６０Ａからステップ１６６Ａへ移行する。

ステップ１６６Ａでは、入力端末１２（顧客Ａ）に何れかの商品プランを保証する旨を通知し、ステップ１８０へ移行する。この保証する商品プランは、確定希望時期までの仮の商品プランであり、顧客Ａの他の希望商品プランに変更される場合がある。

なお、顧客Ａが仮設定の商品プランで確定を希望し、その旨の通知を受けた場合は、スケジュール確定希望時期を待たずに、仮設定した商品プランを確定させてもよい。

ステップ１８０では、現時点での顧客Ａの効用が最大の商品プランと効用度合いを保存し、ステップ１６８Ａへ移行する。

ステップ１６８Ａでは、スケジュール確定希望時期に到達したか否かが判断され、肯定判定されると、ステップ１７０Ａへ移行して、顧客Ａの条件を満たし、かつ、到達時点で商品提供側に最も都合の良い（例えば、最も利益率の高い）商品プランを選択し、次いで、ステップ１７２Ａへ移行して、選択した商品プランを入力端末１２（顧客Ａ）に通知して、このルーチンは終了する。

また、ステップ１６８Ａで否定判定された場合は、ステップ１８２へ移行して、状況の変化に応じて、顧客Ａに適用される条件設定表を更新し、ステップ１６８Ａへ移行する。

例えば、顧客Ａの希望に適合した商品プランが複数存在する場合、顧客Ａからすれば、自身の希望に適合した商品プランであれば、何れの商品プランであっても問題はない。一方、商品提供側からすれば、複数の商品プランの内、例えば、利益率の高い商品プランを提供しても、顧客Ａの希望から逸脱することはなく、所謂「win-win」の関係とすることができ、双方に都合の良い結果を得ることができる。

また、この変形例では、顧客Ａの条件設定表は、顧客Ａ以外の顧客によって変動する場合があるため、状況の変化に応じて、顧客Ａの条件設定表を更新することで、顧客Ａ及び商品提供側の双方にとって、より適正な商品プランの選択が可能となる。

以下に、本実施の形態で説明した予約処理システムが適用可能な、航空券購入のためのチケット予約処理システムの実施例を列挙する。なお、本発明は、当該列挙する実施例の事例に限定されるものではなく、列車、船舶、バス等の公共交通機関のチケット予約（片道、往復を含む）、コンサートや映画等、同一内容で複数回行われる講演、ホテル（連泊数、客室種等）、テーマパークのファーストパス、及び、高速道路通行券といった、様々な予約に適用可能である。また、単一の日時に限らず、複数の日時で選択肢を提示してもよい。

（実施例１）
図９及び図１０は、実施例１に係り、航空券予約処理の流れを、入力端末１２の出力装置１２Ｇ（モニタ画面）に従い説明したものである。なお、日付、便名等が架空の数値であり、当該数値に限定されるものではない。

１月１０日、東京在住の顧客Ａは、２月１日に大阪へ遊びに行くことを思いつき、入力端末１２を使って、商品取引予約アプリケーションプログラムを起動した。
（１） まず、図９（Ａ）の画面で認証処理を実行する。
（２） 次に、図９（Ｂ）の予約プラン入力画面で、２月１日の羽田−伊丹便を指定する。
（３） その後、予約処理サーバー１６からの応答で、図９（Ｃ）の商品プラン一覧が表示される。
（４） 顧客Ａは、「００２便なら１００００円払う。８０００円なら００１便でもよい。００３便は間に合わない。出発の前日の寝るまでにスケジュールを確定してほしい」という要望の下、商品プランの関連情報として、希望商品の選択、希望価格、スケジュール確定希望日時を入力し（図９（Ｄ）参照）、予約処理サーバー１６へ送信する。
（５） １月１５日の時点で、予約処理サーバー１６から連絡があり（図１０（Ａ）参照）、入力端末１２の出力装置１２Ｇに、「○○様のご予約の２／１（土）、００１便又は００２便の何れかの席の保証が確定しました。便の確定は、スケジュール確定希望日時（１／３１（金）、２２：００）までお待ちください」と表示される。
（６） 前記（５）の表示後、スケジュール確定希望日時（（１／３１（金）、２２：００））に、予約処理サーバー１６から連絡があり（図１０（Ｂ）参照）、入力端末１２の出力装置１２Ｇに、「○○様のご予約のフライトは、東京羽田→大阪伊丹、２／１（土）、００２便、８：００→９：００に確定しました。価格は１０，０００円です。よいご旅行を」と表示される。

これにより、顧客Ａは、所望の便を所望の価格で確保することができる。
（７） なお、前記（５）において、保証できる便がない場合は、予約処理サーバー１６から以下の連絡があり（図１０（Ｃ）参照）、「○○様のご予約の２／１（土）の便は、現在、保証できるものがありません。スケジュール確定希望日時（１／３１（金）、２２：００）までお待ちください」と表示される。
（８） （７）の表示後、スケジュール確定希望日時までに便を確保できなかった場合は、予約処理サーバー１６から以下の連絡があり（図１０（Ｄ）参照）、「○○様のご予約のフライトは、残念ながらご希望に添える便がありませんでした。」と表示される。

（実施例２）
図１１及び図１２は、実施例２に係り、航空券予約処理の流れを、入力端末１２の出力装置１２Ｇ（モニタ画面）に従い説明したものである。

実施例１では、各便の価格が表示されないため、顧客Ａが全ての便で販売価格未満の価格を入力した場合、全ての便が保証されない場合がある。

そこで、実施例２では、各便の現在の価格を表示するようにした。

実施例２の購入概略は以下のとおりである（図１１（Ａ）〜（Ｄ）、図１２（Ａ）、（Ｂ）参照）。

「１２月１０日の時点で、２月８日に大阪の結婚式に呼ばれた顧客Ａ。外せない用事なので、今すぐ大阪行きの便を確保したい。００２便がちょうど良いが、とても安いなら早起きして００１便で行っても良い。朝のタクシーの予約があるので、３日前までにどちらかの便か決めてほしい。」
（１） 予約した直後に、商品提供側から連絡。

「○○様のご予約の２／８（土）、００１便もしくは００２便の何れかの席の保証が確定しました。便の確定は２／５（水）、１７：３０までお待ちください。」と表示される。
（２） ２月５日（水）、１７：３０に商品提供側から連絡。

「○○様のご予約のフライトは、２／８（土）００１便に確定しました。価格は３，０００円です。よいご旅行を」と表示される。

実施例２では、００２便に対して現在価格と同一の価格を入力しているため、００２便に関しては必ず保証がなされることになる。

一方、００１便に関しては、１つの便（００２便）が確保されたため、仮に、極めて低価格の提示をすることが可能である。仮に、この００１便が確保されれば、早起きを強いられるが、低価格での購入が可能となる。

（実施例３）
図１３及び図１４は、実施例３に係り、航空券予約処理の流れを、入力端末１２の出力装置１２Ｇ（モニタ画面）に従い説明したものである。

実施例３は、インセティブの支払いを行う実施例である。

実施例３の購入概略は以下のとおりである（図１３（Ａ）〜（Ｄ）、図１４（Ａ）、（Ｂ）参照）。

２月６日の時点で、２月１０日に大阪に出張が決まった顧客Ａ。交通費実費支給のＡは上限２０，０００円までならいくらでも良いと思っているが、毎回高い交通費を申請するのは気が引ける。
（１） 顧客Ａは、００１便に２０，０００円、００２便に２０，０００円、確定希望日時２／７（金）、２４：００と入力。
（２） 予約した直後に、商品提供側から連絡。

「○○様のご予約の２／１０（月）、００１便もしくは００２便の何れかの席の保証が確定しました。便の確定は２／７（金）、２４：００までお待ちください。」と表示される。
（２） ２月７日（金）、２４：００に商品提供側から連絡。

「○○様のご予約のフライトは、２／１０（月）００１便に確定しました。価格は１０，０００円です。よいご旅行を」と表示される。

（実施例４）
図１５は、実施例３に係り、実施例１、実施例２、及び実施例３において、航空券予約処理が顧客にインセンティブを与えていることをアピールする画面を追加した場合を、入力端末１２の出力装置１２Ｇ（モニタ画面）に従い説明したものである。

実施例４は、耐戦略性を保証した実施例である。

図１５（Ａ）は、前述した実施例２の図１１（Ｂ）と同一であり、図１５（Ｃ）は前述した実施例２の図１１（Ｃ）と同一である。

この実施例４の特徴は、図１５（Ａ）と（Ｃ）との間に、図１５（Ｂ）示される如く、顧客に対して耐戦略性を保証することをアピールしたメッセージを提供することにある。

すなわち、図１５（Ｂ）には、以下のメッセージが表示される。

「希望価格の入力後にスケジュール確定希望日時までに航空券の価格が下がった場合、新しい価格を適用しますが、価格が上がった場合は新しい価格を適用しません。ご旅行の予定が確定された場合、早めにお申し込みください。」と表示される。

これにより、顧客は、時間が経過しても損をしないことを認識するため、早めに予約をし、かつ、期間をあけて価格変動等の動向をみることに躊躇がなくなり、商品提供側にとっても、顧客の正確な需要を収集することができる。

なお、上記実施例１〜実施例４において、入力する場合、例えば、プルダウンメニューを表示して、当該プルダウンメニューに表示されたリストから選択するようにしてもよい。

また、単一価格と、その価格で許容できる選択肢のみを入力させるようにしてもよい。さらに、第１希望価格とそれに対する相対領域を入力させるようにしてもよい。

（サービスの付加例）
なお、本実施の形態（実施例を含む）において、以下のサービスを付加してもよい。なお、サービスを付加する商品として、実施例１〜実施例４の航空券チケットを例にとり説明する。

（付加サービス１） 仮決定便を顧客に提示してもよい。

例えば、顧客に対して、「現在の仮決定は００１便です、スケジュール希望確定日時までに、００２便に変更される可能性があります。」といったメッセージを通知する。

（付加サービス２） 顧客本人に対する料金テーブルを常に表示し、顧客はスケジュール確定希望日時までの間に申し込みの変更及びキャンセルを自由に実施できるようにしてもよい。

予約申込を行ったが、なかなか、何れかを保証する通知が来ない顧客が、予約申込の価格を上げることや、予定より早く到着する必要ができた顧客が、遅い時間の便をキャンセルし、早い時間の便のみを残すことが想定される。そこで、予約申込後の変更及びキャンセルを自由に実施可能とすれば、顧客の有用性が高くなる。この場合、スケジュール希望日時を変更してもよい。

（付加サービス３） 仮決定便が満席に近づいた場合にのみ、キャンセル料を発生させてもよい。

例えば、顧客に対して、「現在あなた様のスケジュールで仮決定となっている００１便は、満席が予測されています。明日２／１１（火）、００：００以降に当該便に関する申込みをキャンセルされた場合には、キャンセル料が発生します。但し、当社都合であなた様が申し込み中の他の便に変更した場合は、キャンセル料は発生しません。」といったメッセージを通知する。

（付加サービス４） 仮決定便が満席に近づいた場合、顧客に、キャンセル規定の受け入れ、又は当該便の予約からの削除を選択させるようにしてもよい。

例えば、顧客に対して、「現在あなた様のスケジュールで仮決定となっている００１便は、満席が予測されています。明日２／１１（火）、００：００以降に当該便に関する申込みをキャンセルされた場合には、キャンセル料が発生します。キャンセル規定に同意できない場合は、２／１１（火）、００：００までに当該便の予約を取り消してください。００１便の予約を取り消されても、あなたの予約している何れかの便でのご旅行は保証されていますのでご安心ください。但し、当社都合であなた様が申し込み中の他の便に変更した場合は、キャンセル料は発生しません。」といったメッセージを通知する。

（耐戦略性について）
以上説明した如く、本実施の形態（実施例を含む）では、「早い予約（申告）」、「高い金額での予約」、「遅いスケジュール確定希望日時」を実行することが顧客を有利とすることができる。

例えば、実施例１〜実施例４（特に実施例４を含む実施例３参照）の場合、以下の手順が耐戦略性の実現となる。

（手順１） 商品（航空券チケット）提供側は、予約の開始の時点で、全顧客に対して各顧客専用の料金テーブル（条件設定表）を決定する。当然、異なる顧客に同じ料金テーブルを設定してもよいし、会員種別や誕生日特別セール等で区別してもよい。

（手順２） 商品提供側は、顧客が予約の申し込みを実施する以前は、従来と同様に、空席数に連動する形態で、各顧客の領域を自由に変動させる。

（手順３） 特定の顧客Ａが、予約申し込みを実施した場合、顧客Ａの予約申し込みの内、何れか１つでも商品提供側が決定した料金以下の商品（航空券チケット）があれば、そのうち１つを仮決定商品として扱い（顧客Ａが当該商品を購入すると仮定し）、他の顧客の条件設定表（料金テーブル）に反映させる。一方、予約申し込みをした顧客Ａ自身の料金テーブル（条件設定表）には反映させない。

（手順４） 商品提供側は、仮決定商品が決まった顧客Ａに、「何れかの選択肢を保証する」連絡を実施する。

（手順５） 商品提供側は、顧客Ａ以外の顧客の予約申し込み状況により、顧客Ａの条件設定表（料金テーブル）を更新する。但し、顧客Ａについて仮決定している商品（航空券チケット）については、料金の引き下げは実施しても構わないが、料金の引き上げは実施しない。すなわち、顧客Ａの効用がこれ以上下がらないことを保証する。

（手順６） 顧客Ａの条件設定表（料金テーブル）における価格引き下げにより、商品（航空券チケットの便）を変更した方が顧客Ａの効用が上昇する場合、仮決定している商品を変更する。

いままでの仮決定商品は、この時点で仮決定商品ではなくなり、料金の引き上げが可能になる一方で、新たな仮決定商品の料金の引き上げはしない。

（手順７） 上記（手順６）を、顧客Ａの申告したスケジュール確定希望日時まで継続する。

なお、顧客Ａの条件設定表（料金テーブル）の決定時に、顧客Ａ自身の情報を利用しなければ、耐戦略性が厳密に満たされることになる。

（効用最適化について）
また、本実施の形態（実施例を含む）において、顧客に対する効用（例えば、前記「耐政略性について」の項目、手順５及び手順６参照）を最適化について、実施例１〜実施例４の商品（航空券チケット）の購入を例とり列挙する。

（効用最適化１）線形効用の仮定
ある顧客Ａの入力が、００１便→１０，０００円、００２便→１５，０００円であったとする。更新により、仮決定の００１便が９，０００円になり、００２便が１２，０００円になったとすると、００１便は１，０００円の得、００２便は３，０００円の得となり（この場合、１，０００円＜３，０００円）、顧客Ａは００２便を好むと判断し、仮決定便を００２便に変更（更新）する。

（効用最適化２）料金変動の都度、顧客に確認
顧客に対して、「あなたの現在の仮決定便は００１便で料金は９，０００円ですが、００２便の料金が１２，０００円に引き下げられました。仮決定便を変更しますか？」というメッセージを通知する。顧客Ａが変更を承認すると、仮決定便は００２便となる。

その後、また、００１便の料金が安くなった場合、顧客に対して、「あなたの現在の仮決定便は００２便で料金は１２，０００円ですが、００１便の料金が６，０００円に引き下げられました。仮決定便を変更しますか？」というメッセージを通知する。これを、顧客Ａの申告したスケジュール確定希望日時まで継続する。

（効用最適化３）
顧客による嗜好の入力から決定する、もしくは、普段の顧客の行動から自動推定する。

顧客による嗜好の入力とは、価格優先にするかスケジュール優先にするか、大型機優先か小型機優先から事前に選択してもらう、といった顧客の嗜好に関する項目を事前に選択してもらうことを言い、当該選択情報を仮決定商品の更新の是非に反映させる。

また、普段の顧客の行動から自動推定するとは、いつの行動履歴から、特定の便を気に入っている、といった主としてリピータの顧客の利用形態をデータベース化し、商品提供側で判断することを言う。

また、上記効用最適化２と効用最適化３を組み合わせてもよい。

１０ 通信回線網
１２Ｎ（１２） ノートパソコン（予約者端末）
１２Ｄ（１２） デスクトップパソコン（予約者端末）
１４ 無線通信デバイス１４
１２Ｍ（１２） 携帯通信端末（予約者端末）
１６ 予約処理入力端末装置（予約処理サーバー）
１２Ａ ＣＰＵ
１２Ｂ ＲＡＭ
１２Ｃ ＲＯＭ
１２Ｄ Ｉ／Ｏ
１２Ｅ バス
１８ マイクロコンピュータ
１２Ｆ 入力装置
１２Ｇ 出力装置
１２Ｈ ハードディスク（ＨＤＤ）
１２Ｉ 通信Ｉ／Ｆ
１６Ａ ＣＰＵ
１６Ｂ ＲＡＭ
１６Ｃ ＲＯＭ
１６Ｄ Ｉ／Ｏ
１６Ｅ バス
２０ マイクロコンピュータ
１６Ｈ ハードディスク（ＨＤＤ）
１６Ｇ 通信Ｉ／Ｆ
２２ 商品取引予約実行部
２４ 解析機能
２６ 送信機能
２８ 受信機能
３０ 画像処理機能
３２ 商品取引処理実行部
３４ 顧客管理データベース
３６ 商品在庫データベース
３８ 条件設定データベース
４０ 情報受付部
４２ 認証実行部
４４ 商品取引情報受付部
４６ 条件設定表読出部
４８ 商品プラン確認部
５０ 確定希望時期管理部
５２ タイマ
５４ 商品プラン情報送出部
５６ 商品プラン更新部
５８ 更新プラン一時格納部
６０ 確定商品プラン送出部

Claims (10)

1. 予約希望者からの商品購入予約に係る当該予約情報を受け付けて送信する予約者端末と、予約者端末から受信した予約情報に基づいて予約の受付処理を行う予約処理サーバーとを備えた予約処理システムであって、
   前記予約者端末は、
   予約希望者が入力した予約を希望する商品を指定する複数の予約希望候補、予約希望候補毎の許容条件、および当該予約を確定する期限を指定する予約確定時期、を含む予約情報を受け付けて前記予約処理サーバーへ送信する機能を有し、
   前記予約処理サーバーは、
   予約者端末から受信した予約情報に基づいて、各予約希望候補の実条件が許容条件に適合しているか否かの判断の下、少なくとも１つの予約希望候補を保証し得た場合に、
   前記予約確定時期に至るまでに変動する実条件が許容条件に適合するか否かの判定結果に基づいて、保証し得る予約希望候補を更新し、
   前記予約確定時期に到達した時点で保証し得る予約希望候補であり、かつ商品提供側に有利な予約希望候補を選択し、
   予約者端末へ予約処理結果を送信する機能を有する、
   予約処理システム。
2. 前記予約者端末は、
   予約の受け付け時点において、前記予約希望候補の予約を保証し得る実条件が報知される請求項１記載の予約処理システム。
3. 前記予約処理サーバーは、
   前記保証し得る予約希望候補が、前記予約確定時期に近づくにつれて、特定の予約希望者にとって不利となる実条件の変動が発生した場合は、前記更新を禁止して現在の予約希望候補の実条件を維持する請求項１又は請求項２記載の予約処理システム。
4. 前記予約希望候補の実条件の維持は、前記特定の予約希望者に限定して実行される請求項３記載の予約処理システム。
5. 前記予約者端末は、予約情報の受け付けの際に、
   前記保証し得る予約希望候補の実条件が不利益に変動しないことを示す情報、及び、前記予約の受付処理をする時期と前記予約確定時期との期間が長いほど前記予約処理結果が有利となることを示す情報、を報知する請求項１〜請求項４の何れか１項記載の予約処理システム。
6. 前記予約情報には、複数の保証し得る予約希望候補が存在する場合の選択要素の優先度に関する情報が含まれており、
   当該優先度に関する情報が、前記予約確定時期における予約希望候補の選択において、前記商品提供側の有利性の判断よりも優先される請求項１〜請求項５の何れか１項記載の予約処理システム。
7. 前記予約処理サーバーは、
   前記予約希望者の各々の予約情報の履歴に基づいて、複数の保証し得る予約希望候補が存在する場合の選択要素の優先度に関する情報を策定し、
   当該優先度に関する情報が、前記予約確定時期における予約希望候補の選択において、前記商品提供側の有利性の判断よりも優先される請求項１〜請求項５の何れか１項記載の予約処理システム。
8. 前記保証し得る予約希望候補が更新可能な場合に、前記予約処理サーバーは、前記予約者端末に対して、前記更新可能となる毎に予約希望候補の更新をするか否かの判断を通知する請求項１〜〜請求項７の何れか１項記載の予約処理システム。
9. 予約者端末から受け付けた、予約希望者が入力した予約を希望する商品を指定する複数の予約希望候補、予約希望候補毎の許容条件、および当該予約を確定する期限を指定する予約確定時期、を含む予約情報に基づいて、各予約希望候補の実条件が許容条件に適合しているか否かを判断する判断手段と、
   前記判断手段による判断の下、少なくとも１つの予約希望候補を保証し得た場合に、前記予約確定時期に至るまでに変動する実条件が許容条件に適合するか否かの判定結果に基づいて、保証し得る予約希望候補を更新する更新手段と、
   前記予約確定時期に到達した時点で保証し得る予約希望候補であり、かつ商品提供側に有利な予約希望候補を選択することで確定する予約希望者への予約処理結果を予約者端末へ通知する通知手段と、
   を有する予約処理サーバー。
10. 予約者端末から受け付けた、予約希望者が入力した予約を希望する商品を指定する複数の予約希望候補、予約希望候補毎の許容条件、および当該予約を確定する期限を指定する予約確定時期、を含む予約情報に基づいて、各予約希望候補の実条件が許容条件に適合しているか否かの判断の下、少なくとも１つの予約希望候補を保証し得た場合に、
    前記予約確定時期に至るまでに変動する実条件が許容条件に適合するか否かの判定結果に基づいて、保証し得る予約希望候補を更新し、
    前記予約確定時期に到達した時点で保証し得る予約希望候補であり、かつ商品提供側に有利な予約希望候補を選択することで確定する予約希望者への予約処理結果を予約者端末へ通知することを、
    コンピュータに実行させる商品取引処理プログラム。

Images