特許 6964844 結婚式予約システム、及び結婚式予約管理装置

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

(12)【公報種別】特許公報(B1)

(11)【特許番号】6964844

(24)【登録日】2021年10月22日

(45)【発行日】2021年11月10日

(54)【発明の名称】結婚式予約システム、及び結婚式予約管理装置

(51)【国際特許分類】

   G06Q 10/02 20120101AFI20211028BHJP

【ＦＩ】

   G06Q10/02

【請求項の数】4

【全頁数】14

(21)【出願番号】特願2020-195014(P2020-195014)

(22)【出願日】2020年11月25日

【審査請求日】2020年11月25日

【新規性喪失の例外の表示】特許法第３０条第２項適用 令和２年１０月１５日に、ウェブサイト（ｈｔｔｐｓ：／／ｇａｍｏｓ．ｗｅｄｄｉｎｇ／ｃｏｍｐａｎｙ）にて、河部悦子が発明した結婚式予約システムについて公開した。

【早期審査対象出願】

(73)【特許権者】

【識別番号】520462528

【氏名又は名称】河部 悦子

(74)【代理人】

【識別番号】110003096

【氏名又は名称】特許業務法人第一テクニカル国際特許事務所

(72)【発明者】

【氏名】河部 悦子

【審査官】 原 忠

(56)【参考文献】

【文献】 特開２００６−２３６０２１（ＪＰ，Ａ）

【文献】 特開２００１−２５００３２（ＪＰ，Ａ）

【文献】 再公表特許第２０１５／１９８４６３（ＪＰ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

(57)【特許請求の範囲】

【請求項1】

ユーザが使用するユーザ側端末との間で情報送受可能な管理サーバを有する結婚式予約システムであって、
前記管理サーバは、
前記ユーザ側端末に対して、結婚式に適用可能な複数のサービスアイテムを表示する処理と、
ユーザから前記サービスアイテムの選択操作を受け付けている間は選択済みの前記サービスアイテムの合計費用を表示する処理と、
選択済みの前記サービスアイテムの各費用と前記合計費用を一覧表示する見積もり表示画面を表示する処理と、
前記見積もり表示画面の前記合計費用の下方のみに表示されるボタンが押下操作されたことにより、ユーザが前記合計費用を確認し納得した上で前記サービスアイテムの選択操作を終了する意志があるか否かを判定する処理と、
ユーザが前記合計費用を確認し納得した上で前記サービスアイテムの選択操作を終了する意志があるものと判定された場合に、ユーザ登録と会場見学の予約手続きを受け付ける処理と、
前記ユーザ側端末に対して、予約手続きを受け付けた前記会場見学中では問いかけることなく、会場見学後に見学した会場の選択に関する問いかけ処理と、
その問いかけに対するユーザからの決定又は解消の回答を受け付ける処理と、
を実行することを特徴とする結婚式予約システム。

【請求項2】

前記管理サーバは、
前記複数のサービスアイテムを表示する処理において、前記サービスアイテムのアイテム分類を一覧表示し、ユーザから選択されたアイテム分類に対応する全ての価格のサービスアイテムを一覧表示する
ことを特徴とする請求項１記載の結婚式予約システム。

【請求項3】

前記管理サーバは、
あらかじめ設定された所定の組合せで前記サービスアイテムが選択された場合には対応する報知情報を表示する
ことを特徴とする請求項１又は２記載の結婚式予約システム。

【請求項4】

ユーザが使用するユーザ側端末との間で情報送受可能な結婚式予約管理装置であって、
前記ユーザ側端末に対して、結婚式に適用可能な複数のサービスアイテムを表示する手段と、
ユーザから前記サービスアイテムの選択操作を受け付けている間は選択済みの前記サービスアイテムの合計費用を表示する手段と、
選択済みの前記サービスアイテムの各費用と前記合計費用を一覧表示する見積もり表示画面を表示する手段と、
前記見積もり表示画面の前記合計費用の下方のみに表示されるボタンが押下操作されたことにより、ユーザが前記合計費用を確認し納得した上で前記サービスアイテムの選択操作を終了する意志があるか否かを判定する手段と、
ユーザが前記合計費用を確認し納得した上で前記サービスアイテムの選択操作を終了する意志があるものと判定された場合に、ユーザ登録と会場見学の予約手続きを受け付ける手段と、
前記ユーザ側端末に対して、予約手続きを受け付けた前記会場見学中では問いかけることなく、会場見学後に見学した会場の選択に関する問いかけ手段と、
その問いかけに対するユーザからの決定又は解消の回答を受け付ける手段
と、
を備えていることを特徴とする結婚式予約管理装置。

【発明の詳細な説明】

【技術分野】

【0001】

開示の実施形態は、結婚式の予約を受け付ける結婚式予約システム、及び結婚式予約管理装置に関する。

【背景技術】

【0002】

例えば特許文献１には、ホームページ上のリクエストフォームにユーザが結婚式の希望条件を記入すると、対応する見積もりが電子メールにてユーザに届けられるコンピュータネットワークシステムが記載されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００２−１８９８３３号公報

【発明の概要】

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

【0004】

しかしながら上記従来技術では、リクエストフォームに何を記入できるのか、ユーザに届けられた見積もりにどのような項目や記載が行われるのかの詳細については一切開示されていない。そのため、ユーザの希望を概略的には反映するものの、結婚式の詳細な項目内容が結婚式実施業者から一方的に設定されたものであり、また見積もり価格の内訳が不明確となる可能性がある。また、結婚式という慶事イベントの特性もあり、契約後でも結婚式実施業者との詳細な打ち合わせの過程で項目内容の追加や増額が重なり、最終的に結婚式の実施に対して支払う総費用が最初の見積もり金額よりも大幅に増額してしまう場合が多くある。したがって、高額な費用を支払うユーザとしては自身による細部のこだわりを反映させた柔軟な変更もできず、契約や支払いにおいて明確に納得のいくものではなかった。

【0005】

本発明はこのような問題点に鑑みてなされたものであり、ユーザ自身が見積もり価格を確認しつつ結婚式の内容を任意に設定できる結婚式予約システム、及び結婚式予約管理装置を提供することを目的とする。

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

【0006】

上記課題を解決するため、本発明によれば、ユーザが使用するユーザ側端末との間で情報送受可能な管理サーバを有する結婚式予約システムであって、前記管理サーバは、前記ユーザ側端末に対して、結婚式に適用可能な複数のサービスアイテムを表示する処理と、ユーザから前記サービスアイテムの選択操作を受け付けている間は選択済みの前記サービスアイテムの合計費用を表示する処理と、選択済みの前記サービスアイテムの各費用と前記合計費用を一覧表示する見積もり表示画面を表示する処理と、前記見積もり表示画面の前記合計費用の下方のみに表示されるボタンが押下操作されたことにより、ユーザが前記合計費用を確認し納得した上で前記サービスアイテムの選択操作を終了する意志があるか否かを判定する処理と、ユーザが前記合計費用を確認し納得した上で前記サービスアイテムの選択操作を終了する意志があるものと判定された場合に、ユーザ登録と会場見学の予約手続きを受け付ける処理と、前記ユーザ側端末に対して、予約手続きを受け付けた前記会場見学中では問いかけることなく、会場見学後に見学した会場の選択に関する問いかけ処理と、その問いかけに対するユーザからの決定又は解消の回答を受け付ける処理と、を実行することを特徴とする。

【0007】

また、本発明の別の観点によれば、ユーザが使用するユーザ側端末との間で情報送受可能な結婚式予約管理装置であって、前記ユーザ側端末に対して、結婚式に適用可能な複数のサービスアイテムを表示する手段と、ユーザから前記サービスアイテムの選択操作を受け付けている間は選択済みの前記サービスアイテムの合計費用を表示する手段と、選択済みの前記サービスアイテムの各費用と前記合計費用を一覧表示する見積もり表示画面を表示する手段と、前記見積もり表示画面の前記合計費用の下方のみに表示されるボタンが押下操作されたことにより、ユーザが前記合計費用を確認し納得した上で前記サービスアイテムの選択操作を終了する意志があるか否かを判定する手段と、ユーザが前記合計費用を確認し納得した上で前記サービスアイテムの選択操作を終了する意志があるものと判定された場合に、ユーザ登録と会場見学の予約手続きを受け付ける手段と、前記ユーザ側端末に対して、予約手続きを受け付けた前記会場見学中では問いかけることなく、会場見学後に見学した会場の選択に関する問いかけ手段と、その問いかけに対するユーザからの決定又は解消の回答を受け付ける手段と、を備えていることを特徴とする。

【発明の効果】

【0008】

本発明によれば、ユーザ自身が見積もり価格を確認しつつ結婚式の内容を任意に設定できる。

【図面の簡単な説明】

【0009】

【図1】実施形態に係る結婚式予約システムの概略的なシステム構成図である。

【図2】ユーザ側端末における会場選択画面の表示例を表す図である。

【図3】ユーザ側端末におけるアイテム分類選択画面の表示例を表す図である。

【図4】ユーザ側端末におけるアイテム選択画面の表示例を表す図である。

【図5】ユーザ側端末における最初の見積もり表示画面の表示例を表す図である。

【図6】ユーザ側端末における最後の見積もり表示画面の表示例を表す図である。

【図7】アイテムテーブルの記録内容を模式的に表す図である。

【図8】見積もりテーブルの記録内容を模式的に表す図である。

【図9】マナーチェックテーブルの記録内容を模式的に表す図である。

【図10】ユーザ側端末におけるマナー報知画面の表示例を表す図である。

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

【0010】

以下、一実施の形態について図面を参照しつつ説明する。

【0011】

＜概略的なシステム構成について＞
まず、図１を参照しつつ、本実施形態に係る結婚式予約システムの概略的なシステム構成について説明する。なお、図１に示す本実施形態の結婚式予約システム１の例では、ウェディング企画運営会社が運営するインターネット予約サイトへのアクセスを介して、ユーザが結婚式の予約の手続きを行う場合について説明する。

【0012】

この図１において、本実施形態の例の結婚式予約システム１は、ウェディング企画運営会社が使用する管理サーバ２を有している。管理サーバ２は、例えばインターネットなどの通信ネットワークＮＷを介して、結婚式の開催を希望している一般的なユーザが所有、使用するユーザ側端末３との間で各種の情報を送受可能となっている。上記のユーザ側端末３は、いわゆるスマートフォン、タブレット型ＰＣ、もしくはデスクトップ型またはノート型の汎用パーソナルコンピュータを利用できる。ＷＥＢアプリケーションを利用して管理サーバ２との間の情報送受を行う。なお、上記の管理サーバ２が結婚式予約管理装置に相当する。

【0013】

ここで一般的な結婚式の内容としては、参加人数分の食事や飲み物、新郎と新婦の衣装、各種演出や装飾、ギフトなどの多様な項目であらかじめ必要とされるものの設定と予約が必要となる。以上のように、結婚式の全体においてはユーザの予算や意図に応じて多様な項目内容を組み合わせて行われるものであり、本実施形態においてはそれらユーザが任意で選択し予約できる項目をサービスアイテム（適宜、アイテムと省略）と呼称する。本実施形態におけるサービスアイテムの概略的な分類の例としては、図示するように会場手配サービス、ケータリングサービス、挙式サービス、貸衣装サービス、演出サービス、装飾サービス、映像・音響サービス、フラワーサービス、ギフトサービスなどがあり、ウェディング企画運営会社は各分類のサービスでユーザが選択したサービスアイテムを一括して予約を受け付ける。

【0014】

＜管理サーバについて＞
管理サーバ２は、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＨＤＤ、フラッシュメモリなどで構成されるコンピュータであり、アイテムデータベース２１、ユーザ・見積もりデータベース２２、データ処理部２３、及びＷＥＢサーバ２４の各機能部を有している。

【0015】

アイテムデータベース２１は、サービスの分類ごとに用意された全てのサービスアイテムとそれぞれ関連する情報を記憶するデータベースである（後述の図７参照）。

【0016】

ユーザ・見積もりデータベース２２は、予約を前提として会員登録したユーザに関する情報と、当該ユーザがすでに選択しているサービスアイテム及びそれらに応じて算出された結婚式費用の見積もり価格などを記憶するデータベースである（後述の図８参照）。

【0017】

データ処理部２３は、上記のアイテムデータベース２１とユーザ・見積もりデータベース２２を参照して、各サービスアイテムごとの小計費用やそれらを合計した結婚式全体での見積もり価格などの算出処理を行う機能部である。

【0018】

ＷＥＢサーバ２４は、ユーザ側端末３との間で情報送受することにより、予約サイトにおける各種情報の表示処理やユーザ操作の受け付け処理を行う機能部である。

【0019】

＜予約サイトにおける操作表示画面の具体例について＞
次に、図２〜図６を参照して、上記管理サーバ２が管理する予約サイトにアクセスした場合のユーザ側端末３における操作表示画面の具体的な表示例について説明する。なお図示する例では、汎用パーソナルコンピュータのユーザ側端末３を利用して、ＷＥＢブラウザを介したＷＥＢアプリケーションでの処理により操作表示画面を表示した場合を示す。

【0020】

まず、特に図示しない予約サイトの所定のページで開始操作が行われることにより、最初に図２に示すような予約操作の最初の操作表示画面が表示される。この図２に示す操作表示画面では、「自分で作るウェディング」のタイトルの下に「ＳＴＥＰ１ 会場選択」、「ＳＴＥＰ２ プラン（見積もり）を作る」、「ＳＴＥＰ３ 無料見学」、「ＳＴＥＰ４ ディテクター打ち合わせと衣装合わせ」の４つのステップそれぞれの内容を表すメッセージボックスが並んで表示されている。

【0021】

ここで本実施形態の例では、当該結婚式予約システム１の予約手続きにあたって披露宴の予約が必須であり、最初にその披露宴会場の選択操作を行うステップ１に対応した当該図２の操作表示画面が会場選択画面３１として表示される（「ＳＴＥＰ１ 会場選択」のメッセージボックスのみ網掛け表示）。この会場選択画面３１では、選択候補である複数の披露宴会場のアイテムごとにそれぞれ内観写真、会場名、住所、及び費用が１つの選択操作可能なアイコンＩｃｋとしてまとめて表示されている。なお、図示する例では３つのアイコンＩｃｋが表示されているが、画面スクロールによって他の選択可能な全てのアイテムのアイコンＩｃｋが表示可能となっている。ユーザは、カーソルＣを操作して希望する披露宴会場のアイコンＩｃｋを選択操作でき、図示する例ではユーザが選択したアイコン表示部分に太線枠ＷＬが表示される。なお、アイコンＩｃｋを選択操作した際に別途の説明画面を表示し、詳細な説明とともに選択ボタンを表示して正式な選択操作を行わせてもよい（特に図示せず）。

【0022】

そして特に図示しない会場選択操作が行われることで、次に図３に示す操作表示画面が表示される。この図３は、選択した会場で提供可能なサービスアイテムを選択するステップ２に対応したアイテム分類選択画面３２であり、「ＳＴＥＰ２ プラン（見積もり）を作る」のメッセージボックスのみ網掛け表示される。この操作表示画面では、披露宴に参加する予定の人数が入力設定される設定ボックス４１が表示され、ユーザによる所定の操作により設定入力される。

【0023】

また図示する例では、この予定人数の設定ボックス４１の下に、アイテム分類ごとに対応した分類アイコンＩｃｂが並んで表示されている。図示する例では、「フード」、「ドリンク」、「新婦衣装」、「新郎衣装」、「挙式」、「装花」、「写真映像」、「演出」、「装飾アイテム」、「ギフト」、及び「その他」の１１個の分類アイコンＩｃｂが一覧表示されており、それぞれの分類アイコンＩｃｂ内にはその時点で既に選択されているアイテムの数、もしくはデフォルトのモデルプランとして選択されているアイテムの数も併せて表示されている。

【0024】

また図示する例では、操作表示画面の最も下方の位置に合計表示枠４２が表示されている。当該図３のアイテム分類選択画面３２が表示されている時点では、少なくとも上記図２の会場選択画面３１で選ばれた会場で提供可能なサービスアイテムの幾つかがデフォルトで選択済みの状態となっており、すなわち予め会場側が推奨するモデルプランの合計費用を算出できる。そしてこのステップ２以降に対応して表示されるいずれの操作表示画面においても、常にユーザーはサービスアイテムの選び変えや削除・追加を行いその時点で選択済みにしたサービスアイテムの合計費用が自動的に算出され、リアルタイムに合計表示枠４２に表示される。また図示する例では、合計表示枠４２において自作プランの一時保存ボタン４３と見積もり表示ボタン４４も表示されている。

【0025】

このアイテム分類選択画面３２で、ユーザがカーソルＣを操作して希望するアイテム分類のアイコンＩｃｂを選択操作した場合には、その後に図４に示すようなアイテム選択画面３３が表示される。図４に示すアイテム選択画面３３は、新婦衣装のアイテム分類アイコンＩｃｂが選択操作された場合に対応して表示されるアイテム選択画面３３の一例である。このアイテム選択画面３３では、選択されたアイテム分類に対応して選択候補となる複数のサービスアイテム（この例の新婦衣装）ごとに、それぞれ外観写真、アイテム名称、特徴、及び費用が１つの選択操作可能なアイコンＩｃｓとしてまとめて表示されている。そして上述した会場選択画面３１と同様に、画面スクロールによって選択可能な全てのアイテムのアイコンＩｃｓが一覧表示可能となっており、費用が最も低いアイテムから最も高いアイテムまでの全ての価格のサービスアイテムのアイコンＩｃｓが選択可能となっている。

【0026】

ユーザは、それぞれのサービスアイテムのアイコンＩｃｓに対して選択操作する度に個別に選択状態と非選択状態を切り換えることができ、選択状態のアイコンＩｃｓにおいてはその表示部に太線枠ＷＬが表示される。そして、例えば図示する例の新婦衣装のようなアイテム分類の場合には、複数のアイテムのアイコンＩｃｓを選択できるようになっている。ただし、アイテム分類によっては選択できるアイテムを１つのみに制限してもよい。

【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】

１ 結婚式予約システム
２ 管理サーバ（結婚式予約管理装置に相当）
３ ユーザ側端末
２１ アイテムデータベース
２２ ユーザ・見積もりデータベース
２３ データ処理部
２４ ＷＥＢサーバ
３１ 会場選択画面
３２ アイテム分類選択画面
３３ アイテム選択画面
３４ 見積もり表示画面
３５ マナー報知画面

【要約】

【課題】ユーザ自身が見積もり価格を確認しつつ自分の結婚式の内容（プラン）を任意に設定可能にする。
【解決手段】ユーザが使用するユーザ側端末３との間で情報送受可能な管理サーバ２を有する結婚式予約システム１であって、管理サーバ２は、ユーザ側端末３に対して、結婚式に適用可能な複数のサービスアイテムを表示し、ユーザからサービスアイテムの選択操作を受け付けている間は選択済みのサービスアイテムの合計費用を表示し、複数のサービスアイテムの表示において、サービスアイテムのアイテム分類を一覧表示し、ユーザから選択されたアイテム分類に対応する全ての価格のサービスアイテムを一覧表示する。
【選択図】図４

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】