JP2019067165A - 予約システム - Google Patents

Abstract

【課題】利用者の利便性の高い予約システムを提供すること。【解決手段】ソーシャルネットワークサービスを提供するためのＳＮＳサーバと、予め登録した顧客からインターネット網を介して、本人認証したことを条件に予約を受付け可能な予約サーバと、を含む予約システムであって、予約サーバは、ＳＮＳの利用者が、予約に関する所定メッセージを送信したときにＳＮＳサーバから送信されるＳＮＳ識別情報がＳＮＳ識別情報データベースに記憶されていることを条件に、顧客が本人であることの所定の認証を実行することなく予約を受付ける。【選択図】図８

Description

本発明は、予約システムに関する。

従来、ホテル等を予約する予約システムとして、インターネットに接続可能な携帯端末から予約サイトにアクセスして、予約を行うものがある（例えば、特許文献１、２参照）。

特開２００６−２６０３２６号公報 特開２０１１−１０８０２６号公報

近年、高機能な携帯端末の普及に伴い、携帯端末の所持者同士が相互にメッセージを交換可能なソーシャル・ネットワーキング・サービスの利用者が急増している。このため、これらソーシャル・ネットワーキング・サービスを利用して、携帯端末の所持者に対し、予約の対象となる予約対象施設や予約対象物の案内等を直接的かつ個別的に行うことが行われている。

しかしながら、これら予約対象施設や予約対象物の案内等を、ソーシャル・ネットワーキング・サービスを利用して行っても、携帯端末の所持者が実際に予約を行う際には、予約対象施設や予約対象物の個々の予約サイトにアクセスして予約を行う必要があり、案内された予約対象施設や予約対象物を、当該予約サイトにおいて、再度選択したり、或いは、予約を行うために、個別にログイン等の操作をしなければならず、利用者の利便性に欠けるという問題があった。

本発明は、このような問題点に着目してなされたもので、利用者の利便性の高い予約システムを提供することを目的とする。

前記課題を解決するために、本発明の請求項１に記載の予約システムは、
異なる利用者間において相互にメッセージを送受可能なソーシャルネットワークサービスに利用登録した利用者が予約を行うための予約システムであって、
前記ソーシャルネットワークサービスを提供するためのＳＮＳサーバと、
予め顧客情報を登録した顧客からインターネット網を介して、顧客が本人であることを認証したことを条件に予約を受付け可能な予約サーバと、
を含み、
前記ＳＮＳサーバと前記予約サーバとはネットワーク接続されており、
前記予約サーバは、
前記ＳＮＳサーバにおいてメッセージの送受に使用される識別情報であって、顧客情報を登録した顧客に対して前記ソーシャルネットワークサービスにおいて独自に付与されたＳＮＳ識別情報を記憶可能なＳＮＳ識別情報データベースを有し、
前記ソーシャルネットワークサービスの利用者が、予約に関する所定メッセージを送信したときに、前記ＳＮＳサーバから送信されるＳＮＳ識別情報が前記ＳＮＳ識別情報データベースに記憶されていることを条件に、顧客が本人であることの所定の認証を実行することなく、予約を受付ける
ことを特徴としている。
この特徴によれば、ソーシャルネットワークサービスを利用して予約を行う利用者は、予約の都度毎に、顧客が本人であることの所定の認証を行う必要がなく、予約における利用者の利便性を向上することができる。

本発明の請求項２の予約システムは、請求項１に記載の予約システムであって、
前記ＳＮＳサーバは、前記ＳＮＳ識別情報データベースに記憶されているＳＮＳ識別情報が付与された利用者に対しては、メッセージを表示する画面として、予約に関する異なるメニューが選択操作可能とされた特別メッセージ画面を送信する
ことを特徴としている。
この特徴によれば、メッセージが表示されるメッセージ画面において、予約に関する操作を簡便に行うことができる。

本発明の請求項３の予約システムは、請求項１または請求項２に記載の予約システムであって、
前記ＳＮＳサーバは、前記予約サーバを運営する運営者とメッセージを送受する利用者のＳＮＳ識別情報が前記ＳＮＳ識別情報データベースに記憶されているか否かを判定し、ＳＮＳ識別情報が前記ＳＮＳ識別情報データベースに記憶されているときには、予約に関するメッセージの送受を実行する一方、ＳＮＳ識別情報が前記ＳＮＳ識別情報データベースに記憶されていないときには、前記ＳＮＳ識別情報データベースにＳＮＳ識別情報を記憶することを案内するメッセージを送信する
ことを特徴としている。
この特徴によれば、ＳＮＳ識別情報のＳＮＳ識別情報データベースへの記憶を促進することができる。

本発明の請求項４の予約システムは、請求項１〜３のいずれかに記載の予約システムであって、
前記ＳＮＳサーバは、前記ＳＮＳ識別情報データベースにＳＮＳ識別情報が記憶されていることを条件に、該ＳＮＳ識別情報に付与された利用者の端末に、顧客のみに提供される特別な情報を、前記予約サーバから取得して送信する
ことを特徴としている。
この特徴によれば、ＳＮＳ識別情報のＳＮＳ識別情報データベースへの記憶を促進することができる。

本発明の請求項５の予約システムは、請求項１〜４のいずれかに記載の予約システムであって、
前記予約サーバは、予約が完了したときに当該予約について前記ＳＮＳサーバを介したメッセージの送受を伴ったＳＮＳ予約であるか否かを判定する判定手段を備え、
前記判定手段においてＳＮＳ予約でないと判定された場合には、該予約を行った顧客に対して予約完了の電子メールを送信する一方で前記ＳＮＳサーバを介した予約完了のメッセージを送信せず、
前記判定手段においてＳＮＳ予約であると判定された場合には、該予約を行った顧客に対して予約完了の電子メールを送信しない一方で前記ＳＮＳサーバを介した予約完了のメッセージを送信する
ことを特徴としている。
この特徴によれば、ＳＮＳサーバを介したメッセージの送受を伴った予約をした利用者は、予約が完了したことをメッセージにおいて確認できるようになり、予約が完了したことが利用者に認識され易くなる。

尚、本発明は、本発明の請求項に記載された発明特定事項のみを有するものであってよいし、本発明の請求項に記載された発明特定事項とともに該発明特定事項以外の構成を有するものであってもよい。

実施例における予約システムの構成例を示す図である。 予約システムを構成するホテル予約サーバのデータベース（ＤＢ）の構成例を説明する図である。 （ａ）は、ホテル予約サーバにおける顧客管理データベース（ＤＢ）の構成例を示す図であり、（ｂ）は、ホテル予約サーバにおけるＳＮＳ連携データベース（ＤＢ）の構成例を示す図であり、（ｃ）は、ホテル予約サーバにおけるホテル情報データベース（ＤＢ）の構成例を示す図であり、（ｄ）は、ホテル予約サーバにおける予約管理データベース（ＤＢ）の構成例を示す図である。 ホテル予約サーバに直接アクセスした際に配信されるホテル予約ページ（Ｗｅｂページ）の一例を示す図である。 ホテル予約サーバに直接アクセスした際の予約の流れを説明する説明図である。 （ａ）は、携帯端末において実行されるＳＮＳアプリの機能構成を示す図であり、（ｂ）は、携帯端末においてＳＮＳアプリが実行された際の表示例を示す図である。 ＳＮＳアプリが実行されている携帯端末において、ホテル予約の運営会社を友達として追加する際の流れと、携帯端末における表示画面例を示す図である。 連携時における、予約システムを構成する各サーバと携帯端末との情報の授受を説明する説明図である。 （ａ）は、ＳＮＳアプリが実行されている携帯端末における、連携前の表示例を示す図であり、（ｂ）は、連携後における表示例を示す図である。 シークレットプラン配信時における、予約システムを構成する各サーバと携帯端末との情報の授受を説明する説明図である。 予約完了時における、予約システムを構成する各サーバと携帯端末との情報の授受を説明する説明図である。

本発明に係る予約システムを実施するための形態を実施例に基づいて以下に説明する。

実施例に係る予約システムにつき、図１から図１１を参照して以下に説明する。

図１は、本実施例の予約システムのシステム構成を説明する図である。予約システムは、図１に示すように、予約システムの利用者が所持する携帯端末ＭＰと、携帯端末ＭＰからインターネット網を介してアクセスすることにより、ホテル予約サイトを運営する運営会社が直接運営または提携している宿泊施設であるホテルの予約を、携帯端末ＭＰを所持する利用者が行えるようにするためのホテル予約サーバＳＶ１と、携帯端末ＭＰにインストールされているＳＮＳアプリを実行することにより、携帯端末ＭＰを所持する利用者同士が、メッセージ等を交換可能なソーシャル・ネットワーキング・サービス（ＳＮＳ）を提供するためのＳＮＳサーバＳＶ２と、ソーシャル・ネットワーキング・サービス（ＳＮＳ）において、利用者の携帯端末ＭＰと運営会社との間のメッセージの授受を行うためのＳＮＳ対話用ＡＩサーバＳＶ３と、から主に構成されている。

ホテル予約サーバＳＶ１並びにＳＮＳサーバＳＶ２は、インターネット網に接続され、携帯端末ＭＰは、該インターネット網を介してホテル予約サーバＳＶ１並びにＳＮＳサーバＳＶ２にアクセスすることが可能とされている。

尚、本実施例では、セキュリティを高めるために、図１において、ホテル予約サーバＳＶ１とＳＮＳサーバＳＶ２とを直接接続する形態を例示しているが、本発明はこれに限定されるものではなく、これらホテル予約サーバＳＶ１とＳＮＳサーバＳＶ２とを、バーチャルプライベートネットワーク（ＶＰＮ）接続する等のように、インターネット網を介して接続する等、他の接続形態にて接続するようにしてもよい。

また、同様に、ＳＮＳ対話用ＡＩサーバＳＶ３についても、ＳＮＳサーバＳＶ２と直接接続する形態を例示しているが、本発明はこれに限定されるものではなく、ＶＰＮ接続等、後述するように、ＳＮＳ対話用ＡＩサーバＳＶ３を設ける場所等に応じて適宜に選択すればよい。

携帯端末ＭＰは、インターネット網の接続機能を有するとともに、ＳＮＳアプリを実行可能な処理能力に優れたものであって、利用者が携行可能なもの、例えば、携帯電話通信機能を有するスマートフォンや、携帯電話通信機能を有しないタブレット端末であればよい。但し、携帯端末ＭＰは、これらスマートフォンやタブレット端末のように、利用者が携行可能なものとすることが、予約システムの利用機会を増やすことができる観点から好ましいが、本発明はこれに限定されるものではなく、利用者が、利用可能であって、ＳＮＳ運営会社が提供するＳＮＳアプリを実行可能であり、インターネット網を介してホテル予約サーバＳＶ１やＳＮＳサーバＳＶ２にアクセス可能なデータ通信機能や表示機能を有するものであればよい。

ＳＮＳサーバＳＶ２は、ソーシャル・ネットワーキング・サービス（ＳＮＳ）を提供するＳＮＳ運営会社により管理され、当該ＳＮＳ運営会社のソーシャル・ネットワーキング・サービス（ＳＮＳ）を提供可能にインターネット網に接続された複数のサーバから構成される。具体的なソーシャル・ネットワーキング・サービス（ＳＮＳ）としては、図６（ｂ）に示すように、携帯端末ＭＰの利用者同士が、個々にメッセージや写真等を送受できるものであって、利用者数が多いもの、つまり、ＳＮＳ運営会社が提供しているＳＮＳアプリをインストールしている利用者が多いもの、例えば、ＬＩＮＥ株式会社が提供するソーシャル・ネットワーキング・サービス（ＳＮＳ）であるＬＩＮＥ（ＬＩＮＥ株式会社商標）が、本発明の予約システムの利用機会の増加を図れる観点から好適であるが、当該ＬＩＮＥ以外のソーシャル・ネットワーキング・サービス（ＳＮＳ）であってもよい。

尚、ＳＮＳサーバＳＶ２は、個人ではない企業等がソーシャル・ネットワーキング・サービス（ＳＮＳ）を利用できるようにするための個別のサーバやゲートウエイ（ハードウエア、ソフトウエアのいずれでもよい）等を備えるものであってもよい。

ＳＮＳサーバＳＶ２は、図６（ｂ）に示すように、メッセージを交換する相手となる利用者（複数可能）を選択して、メッセージを交換可能なサービスを、携帯端末ＭＰにインストールされているＳＮＳアプリが有するＳＮＳメッセージ送受機能と連動して提供する。

具体的には、メッセージを交換する相手となる利用者（複数可能）を選択すると図６（Ｂ）に示すようなメッセージ交換画面（トーク画面）が表示され、相手のメッセージと自己のメッセージとが、その送信時刻表示（タイムスタンプ）とともに表示されることで、どのようなメッセージを交換したかを、時系列に確認しながらメッセージ交換を行うことができるようになっている。尚、図６（ｂ）中の画像としては、相手側が選択した画像（写真）が表示されるようになっている。

このように、携帯端末ＭＰにインストールされるＳＮＳアプリは、ＳＮＳメッセージ送受機能を有するとともに、図６（ａ）に示すように、メッセージを交換する相手を選択するＳＮＳメッセージ送受者選択機能、メッセージを交換する相手を追加するための二次元コードを読み取る二次元コード読み取り機能、Ｗｅｂページを表示するための内部ブラウザ機能等の各種の機能を有しており、これらの機能を有するＳＮＳアプリとＳＮＳサーバＳＶ２とで、ソーシャル・ネットワーキング・サービス（ＳＮＳ）が提供可能とされている。

これらＳＮＳサーバＳＶ２に接続されているＳＮＳ対話用ＡＩサーバＳＶ３は、ホテル予約サイトを運営する運営会社により管理されるサーバであって、ＳＮＳサーバＳＶ２を介して携帯端末ＭＰの利用者と運営会社との間において送受されるホテルの予約に関するメッセージ等を自動作成するためのサーバである。

よって、ＳＮＳ対話用ＡＩサーバＳＶ３には、ホテルの予約に関するメッセージの作成に必要となるデータ、具体的には、ホテル予約サーバＳＶ１に記憶されている後述するホテル情報データベース（ＤＢ）と同様データであって、予約が可能なホテル情報のデータが記憶されているとともに、人工知能（ＡＩ）プログラムも実行可能に記憶されており、これら人工知能（ＡＩ）プログラムをＳＮＳ対話用ＡＩサーバＳＶ３において実行することで、該人工知能（ＡＩ）により、利用者の携帯端末ＭＰからＳＮＳサーバＳＶ２を通じて送信されてくるメッセージに対応する応答メッセージが自動生成されるようになっている。

尚、本実施例では、ＳＮＳ対話用ＡＩサーバＳＶ３を、ホテル予約サイトを運営する運営会社が管理する形態を例示しているが、本発明はこれに限定されるものではなく、例えば、これらＳＮＳ対話用ＡＩサーバＳＶ３を、人工知能（ＡＩ）プログラムを提供する会社が管理するＡＩサーバにて構築するようにしてもよい。

また、本実施例では、ＳＮＳ対話用ＡＩサーバＳＶ３とホテル予約サーバＳＶ１とを接続していない形態を例示しているが、本発明はこれに限定されるものではなく、これらＳＮＳ対話用ＡＩサーバＳＶ３とホテル予約サーバＳＶ１とを接続し、ホテル予約サーバＳＶ１におけるホテル情報の変更、例えば、プランの変更や終了、新規プランの追加、新規ホテルの追加等を、人工知能（ＡＩ）がチェックして該人工知能（ＡＩ）が、これらの変更を、ＳＮＳ対話用ＡＩサーバＳＶ３に記憶されているデータに自動的に反映させるようにしてもよい。

ホテル予約サーバＳＶ１は、ホテル予約サイトを構成するためのサーバであり、ホテル予約サイトを運営する運営会社により管理される。これらホテル予約サーバＳＶ１は、例えば、ホテルの選択ページや、選択されたホテルの写真や案内やプラン等が表示されるトップページ等の各種Ｗｅｂページを配信するためのＷｅｂサーバ、予約完了メールやお得情報メール等の各種電子メールを送信するためのメールサーバ、予約可能なプランや日付や条件に合致する部屋の特定等、予約に関する各種処理を実行して予約を受付けるためのアプリケーション（ＡＰＰ）サーバや、図３に示すような各種のデータベース（ＤＢ）を有するデータベース（ＤＢ）サーバや、ＳＮＳサーバＳＶ２等の外部のサーバ等と連携するためのインターフェイス機能用のＡＰＩサーバ等により構成され、インターネット網に接続されている。

ホテル予約サーバＳＶ１には、上記したように、ホテル予約サイトを構成する各Ｗｅｂページや案内情報や写真やホテル予約用アプリケーション等の各種のデータに加えて、図２に示すように、既に予約を実施したことのある顧客の個人情報を管理するための顧客管理データベース（ＤＢ）、ＳＮＳとのアカウント連携を行っている顧客のＳＮＳユーザーＩＤを管理するためのＳＮＳ連携データベース（ＤＢ）、予約が可能な各ホテルに関する情報を管理するためのホテル情報データベース（ＤＢ）、受付けた予約を管理するための予約管理データベース（ＤＢ）等の複数のデータベースが記憶されている。尚、ＳＮＳユーザーＩＤは、ソーシャル・ネットワーキング・サービス（ＳＮＳ）において利用者を特定するために、利用者の各々に固有に付与されたソーシャル・ネットワーキング・サービス（ＳＮＳ）独自のＩＤであり、メッセージに付帯されて送受される。

顧客管理データベース（ＤＢ）は、図３（ａ）に示すような構成とされており、顧客登録の際に付与された顧客ＩＤに対応付けて、顧客登録時に受付けた氏名や、性別、年齢、電話番号、メールアドレス、パスワード、住所等の個人情報が登録されており、顧客ＩＤやメールアドレスや電話番号から、各顧客の個人情報を特定できるようになっている。

また、ＳＮＳ連携データベース（ＤＢ）は、図３（ｂ）に示すように、ホテル予約サイトにおいて付与される顧客ＩＤに対応付けて、当該顧客（利用者）のＳＮＳユーザーＩＤが記憶されている。

また、ホテル情報データベース（ＤＢ）は、図３（ｃ）に示すように、予約可能なホテルの各々に固有に付与れたホテルＩＤに対応付けて、当該ホテルの名称、電話番号、該当地域、所在地等の情報が記憶されており、これらホテルＩＤ等から当該ホテルに関する情報を特定できるようになっている。

また、予約管理データベース（ＤＢ）は、図３（ｄ）に示すように、完了した予約の各々を特定可能に付与された予約Ｎｏ．に対応付けて、予約されたホテルＩＤ、宿泊日、予約者の顧客ＩＤ、宿泊者の性別と人数、子供人数、プラン番号等の予約に関する情報が記憶されており、予約Ｎｏ．から予約内容を特定できるようになっている。

ここで、ホテル予約サーバＳＶ１においてホテルの予約が行われる流れについて、図４、図５を用いて簡単に説明すると、ホテル予約サーバＳＶ１にインターネット網を介して直接アクセスした場合には、例えば、図４に示すようなホテル予約ページ（Ｗｅｂページ）が配信される。尚、図４に示すページは、携帯端末用ではなくパソコン用ページの例を示すものであり、携帯端末ＭＰからアクセスした場合には、個々のアイコン表示等が小型のものとされた図示しない携帯端末用ページが配信される。

ホテル予約ページ（Ｗｅｂページ）には、図４に示すように、当該ホテル予約サイトを運営するグループ名表示とともに、「北海道」、「東北」、「関東」・・・の地域毎に、各地域において予約可能なホテルの写真アイコンが選択可能に表示されている。

このように選択可能に表示されている各ホテルから、予約をしたいホテルの写真アイコンを選択すると、選択したホテルのトップページが配信される。尚、このホテルトップページには、当該ホテルの写真とともに、宿泊プラン等が選択可能に表示される。

これらホテルトップページにおいて希望の宿泊プランを選択した場合には、当該ホテルの空き室状況等が確認されて、予約可能な日付等を特定できる空き状況カレンダーを含む
日付選択ページがホテル予約用アプリケーションによって生成されて配信される。

この空き状況カレンダーにおいて、予約が可能な日付の中から宿泊を希望する日付を選択すると、宿泊人数や、宿泊者の性別、年齢等の宿泊内容の入力するための予約受付けページが配信される。そして、予約受付けページにおいて宿泊内容を入力し、料金等を確認して予約申込みのメニューを選択すると、ログインページが配信される。

ログインページには、メールアドレスとパスワード（ＰＷ）の入力部が設けられており、過去に予約を行って顧客登録をしている利用者（顧客）は、メールアドレスとパスワード（ＰＷ）を入力部に入力することで、予約が完了し、予約内容を含む予約完了メールが、該メールアドレスに対して送信される。

また、ログインページには、「新規登録」のメニューが設けられており、過去に予約を行っておらず、顧客登録をしていない利用者（顧客未登録者）は、該「新規登録」のメニューを選択することで、新規登録の受付けページが配信される。そして、該新規登録の受付けページにおいて、氏名や性別、年齢、電話番号、住所等とともに、メールアドレスとパスワード（ＰＷ）を入力して「登録」のメニューを選択すると、該利用者（顧客）に顧客ＩＤが付与されるとともに、該付与された顧客ＩＤに対応付けて、新規登録の受付けページにおいて受付けた氏名や性別、年齢、電話番号、住所、メールアドレス、パスワード（ＰＷ）等が顧客管理ＤＢに追加登録される。尚、この際、メールアドレスが正しくない可能性もあるので、入力されたメールアドレスに確認メールを送信し、該送信された確認メールによる確認ができた場合にのみ、顧客管理ＤＢへの登録を実行するようにしてもよい。

そして、当該メールアドレスに対し、予約内容を含む予約完了メールが送信される。尚、これら予約内容については、予約されたホテルに対しても送信される。

このようにして、ホテル予約サーバＳＶ１においてホテルの予約を行うことができるが、ＳＮＳを利用している利用者は、例えば、ホテル予約サーバＳＶ１に個別にアクセスして予約を行う必要があり不便であるとともに、ＳＮＳにおいて、メッセージの交換（対話）しながらホテルの予約ができれば、利用者の利便性を更に高めることができる。

このため、例えば、予約可能な各ホテルの客室等に、メッセージを交換する相手である「友達」に、ホテル予約サイトを運営する運営会社を追加するための二次元バーコードが印刷されたＰＯＰを配置しておき、ＳＮＳアプリを利用している利用者に、運営会社を「友達」と登録して、対話形式にて簡単にホテルの予約をできるようにする。

具体的には、携帯端末ＭＰの利用者は、ＳＮＳアプリの二次元コード読み取り機能を利用して、ＰＯＰに印刷されている二次元コードを読み取る。

そして、運営会社を「友達」と登録する。尚、運営会社の友達名称としては、会社名等は親しみ難い名称であるため、利用者に親しみやすい名称（図面では「Ｈ１６４」くん）を友達の名称として割り当てることがこのましい。

このように、運営会社を「友達」に追加すると、図７に示すように、挨拶メッセージが送信されるとともに、メッセージ画面として、画面の下部に「ホテル予約」、「予約確認・変更」、「お客様情報変更」、「地図」、「新着情報」、「質問」の各メニューが選択操作可能とされたメッセージ画面が、ＳＮＳサーバＳＶ２から送信されて表示される。尚、この挨拶メッセージは、ＳＮＳ対話用ＡＩサーバＳＶ３からＳＮＳサーバＳＶ２とインターネット網を経由して携帯端末ＭＰに送信される。但し、メッセージ画面については、ＳＮＳ対話用ＡＩサーバＳＶ３が送信するのではなく、ＳＮＳサーバＳＶ２がメッセージの相手側が運営会社である「Ｈ１６４」くんであることを特定（判別）して、ＳＮＳサーバＳＶ２が相手の携帯端末ＭＰに送信する。つまり、これら各メニューが選択操作可能とされた特別なメッセージ画面は、運営会社を「友達」に追加した後に、後述するように、アカウント連携により、少なくとも当該利用者のＳＮＳユーザーＩＤがＳＮＳ連携データベース（ＤＢ）に登録されている場合には、必ず携帯端末ＭＰに送信されることになる。

そして、メッセージ画面の下方に表示されたメニューのうち、例えば、図７に示すように、「質問」のメニューを選択（タップ）した場合には、自己のメッセージとして「ホテルへ質問」のメッセージが表示され、該メッセージに応答する運営会社である「Ｈ１６４」くんのメッセージとして「番号を選択して質問してね！ １、北海道 ２、東北・・・」のように、メッセージが表示される。そして、例えば、「１」をメッセージにて入力すると、「番号を選択して質問してね！ １．札幌○×ホテル ２．ホテル△△札幌・・・」のようにメッセージが表示される。これらのメッセージは、ＳＮＳ対話用ＡＩサーバＳＶ３に搭載されている人工知能（ＡＩ）プログラムにより、ＳＮＳ対話用ＡＩサーバＳＶ３に記憶されている予約可能なホテル情報に基づいて自動生成されて送信される。

つまり、携帯端末ＭＰから送信されるメッセージに含まれる番号に対応する応答メッセージが表示されることで、予約可能なホテルの情報が送信されるようになっている。但し、後述するアカウント連携を実行していない利用者の場合には、これらホテルの情報として、ホテルを選択しても、当該ホテルのシークレットプラン等の有益な情報は配信されないようになっている。

尚、メッセージ画面における「地図」のメニューを選択した場合には、指定したホテルの位置が表示された地図ページが表示される。

また、メッセージ画面における「新着情報」のメニューを選択した場合には、新規プランや新たなキャンペーン等の情報が送信されて表示される。

また、ホテル予約のメニューを選択した場合には、既に、アカウント連携を実行している利用者の場合には、質問と同様に、地域、ホテル、プランの選択メッセージが順次表示されて、予約可能なホテルが案内される。

また、予約確認・変更のメニューを選択した場合には、アカウント連携を実行している利用者の場合であれば、ホテル予約サーバＳＶ１から送信される予約確認・変更のＷｅｂページが内部ブラウザにより表示され、該予約確認・変更のＷｅｂページにおいて、改めてログインをしなくても、予約の確認、変更を行うことができる。つまり、予約確認・変更のメニューが選択された場合には、後述するように、アカウント連携を実行している利用者であるか否かを、メッセージに付帯しているＳＮＳユーザーＩＤがＳＮＳ連携データベース（ＤＢ）に登録されているか否かをよって判定し、アカウント連携を実行している利用者であることを条件に、予約確認・変更のＷｅｂページを送信するようになっている。尚、この際、アカウント連携を実行している利用者であると判定したときに、予約確認・変更のＷｅｂページのＵＲＬを含む移行確認メッセージを送信してメッセージ画面に表示させ、該移行確認メッセージにおけるＵＲＬを選択させることで送信されるリクエストに応じて予約確認・変更のＷｅｂページを配信することで、誤配信を防止できるようにしてもよい。但し、予約確認・変更のＷｅｂページのＵＲＬは、メッセージ表示されるので、ワンタイムＵＲＬであることが好ましい。

また、お客様情報変更のメニューを選択した場合には、アカウント連携を実行している利用者の場合であれば、ホテル予約サーバＳＶ１から送信されるお客様情報変更のＷｅｂページが内部ブラウザにより表示され、該お客様情報変更のＷｅｂページにおいて、改めてログインをしなくても、登録情報の変更を行うことができる。つまり、お客様情報変更のメニューが選択された場合には、後述するように、アカウント連携を実行している利用者であるか否かを、メッセージに付帯しているＳＮＳユーザーＩＤがＳＮＳ連携データベース（ＤＢ）に登録されているか否かをよって判定し、アカウント連携を実行している利用者であることを条件に、お客様情報変更のＷｅｂページを送信するようになっている。尚、この際、アカウント連携を実行している利用者であると判定したときに、お客様情報変更のＷｅｂページのＵＲＬを含む移行確認メッセージを送信してメッセージ画面に表示させ、該移行確認メッセージにおけるＵＲＬを選択させることで送信されるリクエストに応じて予約確認・変更のＷｅｂページを配信することで、誤配信を防止できるようにしてもよい。但し、予約確認・変更のＷｅｂページのＵＲＬは、メッセージ表示されるので、ワンタイムＵＲＬであることが好ましい。

上記のように運営会社を「友達」に追加することによって携帯端末ＭＰの表示画面に表示されるメッセージ画面の下方に表示される各メニューのうち、「ホテル予約」、「予約確認・変更」、「お客様情報変更」のメニュー（予約関連操作メニュー）が選択された場合は、図８に示すように、ＳＮＳを利用して予約を行う利用者の利便性を向上させるためのアカウント連携が実行される。

ここで、図８を用いて、アカウント連携の流れについて説明すると、携帯端末ＭＰにおいて予約関連操作メニューのいずれかが操作されると、ＳＮＳサーバＳＶ２は、該操作が予約関連操作であるか否かを判定する。尚、これらの判定としては、本実施例では、「ホテル予約」、「予約確認・変更」、「お客様情報変更」のメニューが操作された場合には、携帯端末ＭＰからのメッセージとして、操作（タップ）されたメニューと同一のメッセージ、例えば、「ホテル予約」のメニューが操作（タップ）された場合には、「ホテル予約」のメッセージが送信されるので、携帯端末ＭＰから送信されるメッセージが、「ホテル予約」、「予約確認・変更」、「お客様情報変更」のいずれかに完全に一致するか否かにより判定すればよい。尚、携帯端末ＭＰから送信される利用者が作成したメッセージにも、「ホテル予約」、「予約確認・変更」、「お客様情報変更」の文言が含まれる場合もあるので、このような場合に誤って予約関連操作であると判定しないように、完全一致を判定することがこのましい。

また、「ホテル予約」、「予約確認・変更」、「お客様情報変更」のメニューが操作された場合には、通常、メッセージにおいては使用しない文字例等の特別なタグが付与されたメッセージを送信するようにして、予約関連操作であることの判別を的確かつ容易に行えるようにしてもよい。尚、この場合、特別なタグのみを送信するようにしても良いが、特別なタグのみを送信すると、メッセージ画面において、どのような操作を実施したかを利用者が確認できなくなってしまうので、特別なタグを用いる場合には、特別なタグを、操作（タップ）されたメニューに対応するメッセージに付加することで、メッセージ画面において、利用者が、どのような操作を実施したかを確認できるようにすることがこのましい。

また、本実施例では、これら予約関連操作である否かの判定を、ＳＮＳサーバＳＶ２が実行する形態を例示しているが、本発明はこれに限定されるものではなく、これらの判定を携帯端末ＭＰにおいてＳＮＳアプリが実行するようにしてもよいし、ＳＮＳ対話用ＡＩサーバＳＶ３がホテル予約サーバＳＶ１に接続されている場合には、該ＳＮＳ対話用ＡＩサーバＳＶ３において判定するようにしてもよい。

これら予約関連操作であるか否かの判定において、予約関連操作ではないと判定された場合、つまり、「地図」、「新着情報」、「質問」のメニューの操作（タップ）である場合には、ＳＮＳ対話用ＡＩサーバＳＶ３に対して、ＳＮＳユーザーＩＤが付帯されたメッセージを送信することで、該メッセージに対応する応答メッセージがＳＮＳ対話用ＡＩサーバＳＶ３において生成される。

一方、予約関連操作であると判定された場合には、当該メッセージに付帯されているＳＮＳユーザーＩＤを含む判定要求を、ホテル予約サーバＳＶ１（具体的には、ＳＮＳ専用の外部ＡＰＩ）に送信する。

このようにしてＳＮＳサーバＳＶ２から判定要求を受信した場合にホテル予約サーバＳＶ１（外部ＡＰＩ）は、受信した判定要求に含まれるＳＮＳユーザーＩＤが、図３（ｂ）に示すＳＮＳ連携データベース（ＤＢ）に記憶されているか否かを判定し、判定結果を返信する。

この返信を受けてＳＮＳサーバＳＶ２は、判定結果が登録有りの判定結果であるか否かを判定する。そして、登録有りの判定結果の場合、つまり、当該利用者が、既にアカウント連携を実行済の利用者である場合には、当該メッセージをＳＮＳ対話用ＡＩサーバＳＶ３に対して送信する。これにより、送信された該メッセージ、例えば、「ホテル予約」のメッセージであれば、該「ホテル予約」に対応した応答メッセージである、予約を行うための地域をどこにするかを問うメッセージが生成される。

一方、登録無しの判定結果の場合、つまり、当該利用者が、未だアカウント連携を実行してしないか、或いは、顧客登録も実行していない利用者である場合には、顧客登録、アカウント連携の選択ページのＵＲＬを含む登録要求メッセージを携帯端末ＭＰに対して送信する。これにより、携帯端末ＭＰには、選択ページのＵＲＬを含む登録要求メッセージが表示される（図９（ａ−２）参照）。

尚、本実施例では、登録無しの判定結果によって、選択ページのＵＲＬを含む登録要求メッセージを送信するようにしているが、本発明はこれに限定されるものではなく、例えば、顧客登録やアカウント連携についての利用者の意思を確認するための確認メッセージを送信して、意思確認が得られたことを条件に選択ページのＵＲＬを含む登録要求メッセージを送信するようにしてもよい。

また、本実施例では、選択ページのＵＲＬを固定としているために、予め選択ページのＵＲＬを含む登録要求メッセージをＳＮＳサーバＳＶ２に記憶しておき、該ＳＮＳサーバＳＶ２が送信できるようにしているが、本発明はこれに限定されるものではなく、選択ページのＵＲＬが流用されてしまうと、メールアドレスの盗用により同一人によるなりすまし連携が可能となってしまうので、これら選択ページをホテル予約サーバＳＶ１において、その都度生成する等により、これらＵＲＬをワンタイムＵＲＬとするようにしてもよい。

このようにして表示された選択ページのＵＲＬを、利用者がタップすると、当該ＵＲＬを含むリクエストがホテル予約サーバＳＶ１に送信され、これに対応して、ホテル予約サーバＳＶ１から選択ページが配信される。

この選択ページには、「新規顧客登録」の選択メニューと、「連携」の選択メニューとが設けられているとともに、「連携」のメニューに対応するように、顧客登録したメールアドレスの入力部とが設けられている。

未だ顧客登録していない利用者である場合には、該利用者が「新規顧客登録」の選択メニューを選択することで、新規登録ページのリクエストがホテル予約サーバＳＶ１に送信されて新規登録ページが配信され、該新規登録ページにおいて、氏名、性別、年齢、電話番号、メールアドレス、パスワード、住所等の個人情報を入力することで、顧客登録が可能となる。尚、顧客登録される際には、新たに付与された顧客ＩＤに対応付けて当該利用者のＳＮＳユーザーＩＤがＳＮＳ連携データベース（ＤＢ）に登録されることにより、アカウント連携も同時に実行され、再度、アカウント連携を行う必要はない。

一方、既に顧客登録しているがアカウント連携を実行してしない利用者である場合には、該利用者が、メールアドレスの入力部に、顧客登録において登録したメールアドレスを入力したのち、「連携」の選択メニューを選択することで、該入力されたメールアドレスがホテル予約サーバＳＶ１に通知される。

ホテル予約サーバＳＶ１は、該通知を受けて、通知されたメールアドレスが、顧客管理データベース（ＤＢ）に登録されているか否かを判定する。登録されていない場合には、入力間違いや自分が利用している異なるメールアドレスを入力した場合が考えられるので、所定回数に亘って、選択ページが繰り返し配信される。尚、図８においては、紙面の都合上、繰り返し配信の部分は省略している。

これら登録されていない場合が所定回数繰り返された場合にホテル予約サーバＳＶ１は、新規顧客登録の案内ページを配信することで、改めて、顧客登録の実行を促す。

一方、通知されたメールアドレスが、顧客管理データベース（ＤＢ）に登録されている場合、つまり、利用者が、過去にホテル予約をサイトにおいて実行したことのある顧客である場合には、ＳＮＳからのホテル予約において、予約の都度、氏名等の入力等が要求されて不便となってしまうことのないように、顧客管理データベース（ＤＢ）において通知されたメールアドレスに対応付けて記憶されている顧客ＩＤを特定し、該顧客ＩＤとＳＮＳユーザーＩＤとを対応付けてＳＮＳ連携データベース（ＤＢ）に追加登録する。

尚、この登録に際して、メールアドレスを入力した携帯端末ＭＰが、ＳＮＳメッセージを送受している利用者の携帯端末ＭＰと同一であるか、つまり、メールアドレスの入力がなりすましの端末ではないことを確認するために、一旦、「連携が可能で、よろしいですか？ １．はい ２．いいえ」のメッセージを送信し、「１」のメッセージを受信したときに、該メッセージに付帯しているＳＮＳユーザーＩＤが、最初に登録の有無を判定したＳＮＳユーザーＩＤと同一であるか否かを確認し、該確認が得られた場合にのみ、顧客ＩＤとＳＮＳユーザーＩＤとを対応付けてＳＮＳ連携データベース（ＤＢ）に追加登録するようにしてもよい。

そして、ＳＮＳ連携データベース（ＤＢ）に追加登録が完了したときに、アカウント連携が完了した旨の連携完了ページを配信する。尚、この連携完了ページには、処理を継続するために、再度「ホテル予約」、「予約確認・変更」、「お客様情報変更」のメニューをタップすることを促すメッセージが含まれており、該メッセージに従って利用者が、例えば「ホテル予約」を選択することで、既に、ＳＮＳ連携データベース（ＤＢ）にＳＮＳユーザーＩＤが登録されていると判定されることで、メッセージがＳＮＳ対話用ＡＩサーバＳＶ３に送信されて、送信された該メッセージ、例えば、「ホテル予約」のメッセージであれば、該「ホテル予約」に対応した応答メッセージである、予約を行うための地域をどこにするかを問うメッセージが生成される。

上記したように図８に示す処理が予約システムにおいて実行されることにより、アカウント連携前である場合に「ホテル予約」のメニューを、図９（ａ−１）に示すようにタップした場合には、図９（ａ−２）に示すように、顧客登録、アカウント連携の選択ページのＵＲＬを含む登録要求メッセージが表示され、該表示されたＵＲＬをタップすることで、顧客登録時のメールアドレスを入力する選択ページが配信されて、アカウント連携を実行できるようになる。

一方、アカウント連携後である場合に「ホテル予約」のメニューを、図９（ｂ−１）に示すようにタップした場合には、登録要求メッセージが表示されることなく、図９（ｂ−２）に示すように、予約を行うためのメッセージとして、地域を選択するためのメッセージが表示され、例えば、「２」をメッセージ入力することで、東北にある予約可能な各ホテルを選択するためのメッセージが表示される。

そして、該メッセージにおいて予約を希望する１のホテルの番号をメッセージ入力した場合には、該メッセージ入力したホテル、つまり、選択したホテルのプランのうち、顧客登録した顧客のみが予約可能なシークレットプラン（顧客専用プラン）が、メッセージ画面に表示される（図９（ｂ−１）参照）。

これらシークレットプランが携帯端末ＭＰに表示される流れについて、図１０を用いて説明すると、ＳＮＳサーバＳＶ２は、ＳＮＳ対話用ＡＩサーバＳＶ３から携帯端末ＭＰに送信されるメッセージ中に、ホテル名が含まれているか否かを監視、判定している。

そして、ホテル名が含まれていると判定した場合には、該メッセージの送信先（相手側）のＳＮＳユーザーＩＤをホテル予約サーバＳＶ１に送信する。

ホテル予約サーバＳＶ１は、送信されたＳＮＳユーザーＩＤがＳＮＳ連携データベース（ＤＢ）に登録されているか否かを判定し、判定結果を返信する。

この返信を受けてＳＮＳサーバＳＶ２は、判定結果が登録有りの判定結果であるか否かを判定する。そして、登録有りの判定結果の場合、つまり、当該利用者が、既にアカウント連携を実行済の利用者である場合には、当該ホテルのシークレットプランの送信を要求する。

該要求の受信に応じてホテル予約サーバＳＶ１は、選択されたホテルのシークレットプランを特定し、該シークレットプランの画像をＳＮＳサーバＳＶ２に返信する。ＳＮＳサーバＳＶ２は、返信されたシークレットプラン（画像）を携帯端末ＭＰに送信して表示させる。尚、この場合、シークレットプラン（画像）が複数であってもよく、複数の場合には、図９（ｂ−１）に示すように、横方向に並んだ状態で表示され、各シークレットプラン（画像）を横方向にスクロールして確認することができる。

これらシークレットプラン等の各プランを選択した場合には、予約可能な日付等を特定できる空き状況カレンダーを含む日付選択ページが、ホテル予約サイトと同様に配信され、該日付選択ページが、ＳＮＳアプリの内部ブラウザ機能により携帯端末ＭＰに表示される。

そして、これら日付選択ページにて日付を選択した後、宿泊人数や、宿泊者の性別、年齢等の宿泊内容の入力するための予約受付けページが配信され、該予約受付けページにおいて宿泊内容を入力し、料金等を確認することで、ログインページ等が配信されることなく予約申込みが完了する。

つまり、利用者がＳＮＳのメッセージを通じて予約を行う場合においてホテル予約サーバＳＶ１は、ＳＮＳのメッセージに付帯されているＳＮＳユーザーＩＤがＳＮＳ連携データベース（ＤＢ）に登録されているか否かを判定して、当該利用者がアカウント連携済の利用者（顧客）であるか否かを判定し、アカウント連携済の利用者（顧客）である場合には、ログインページ等を配信して利用者（顧客）が本人であることの所定の認証を実行することなく、予約を受付ける。尚、予約の受付けに先立って、当該利用者（顧客）がアカウント連携済の利用者（顧客）であるかの判定を実行済である場合には、判定済であることを示すデータをセッション情報等に予め記憶しておき、予約の受付時に該情報の有無を判定するようにしてもよい。

このようにして予約の受付けが完了すると、ホテル予約サーバＳＶ１は、当該予約についてのセッション情報をチェックする。尚、セッションの情報には、セッションにおいてＷｅｂページが配信された場合には、Ｗｅｂページの送信先のクッキーデータ等が格納され、セッションにおいてＳＮＳメッセージが送信された場合には、メッセージの送信先のＳＮＳユーザーＩＤが格納されており、当該予約が、ＳＮＳが利用された予約であるか否かを、ＳＮＳユーザーＩＤが格納されているか否かにより判定できるようになっている。

セッション情報にＳＮＳユーザーＩＤが格納されている場合、つまり、ＳＮＳメッセージが送信された予約である場合には、予約したホテルの名称や電話番号、予約の日付、予約番号等を含む予約完了メッセージのみを作成して送信し、予約完了の電子メールを送信しないようにすることで、該予約完了メッセージが携帯端末ＭＰにおいて、内部ブザウザが終了してメッセージ画面に戻り、該メッセージ画面に予約完了メッセージが表示されるので、画面やアプリを切り替えて電子メールを表示して予約の内容を確認する面倒がないとともに、ＳＮＳによって予約が完了したという完了感を利用者に与えることができる。また、予約完了の電子メールを送信しないので、これらメッセージ画面にて予約を確認中に、着信した電子メールによって、メッセージの確認が阻害されてしまうこともない。

一方、セッション情報にＳＮＳユーザーＩＤが格納されていない場合、つまり、ホテル予約サイトからのログインによる予約である場合には、予約したホテルの名称や電話番号、予約の日付、予約番号等を含む予約完了電子メールを作成して送信する。

尚、本実施例では、セッション情報にＳＮＳユーザーＩＤが格納されている場合には、予約完了メッセージのみを送信するようにしているが、本発明はこれに限定されるものではなく、これら予約完了メッセージに加えて、予約完了の電子メールも送信するようにしてもよい。但し、この場合にあっては、予約完了メッセージの送信を先とし、所定期間（例えば、３０秒や１分）が経過してから予約完了の電子メールを送信するようにすることがこのましい。

以上に示した本実施例によれば、ＳＮＳを利用して予約を行う利用者は、予約の都度毎に、予約サイトへのアクセス操作をしたり、パスワードの入力等を行う必要がなく、シームレスに予約を行うことができるので、予約における利用者の利便性を向上することができる。

以上、本発明の実施例を図面により説明してきたが、具体的な構成はこれら実施例に限られるものではなく、本発明の要旨を逸脱しない範囲における変更や追加があっても本発明に含まれる。

例えば、前記実施例では、予約の対象を宿泊施設であるホテルとした形態を例示しているが、本発明はこれに限定されるものではなく、これら宿泊施設をホテル以外の旅館等としてもよいし、更には、宿泊施設以外の施設、例えば、飲食店や病院等の施設の予約、交通機関の座席やチケットの予約、レンタカーの予約、コンサートの予約等、どのような予約であってもよい。

また、前記実施例では、予約の対象をホテルの１種類とした形態を例示しているが、本発明はこれに限定されるものではなく、例えば、ホテルと飲食店のように、複数の異なる種類の予約が可能なシステムであってもよく、このような場合には、ホテルの予約サーバと飲食店の予約サーバと連携したポータルサーバを設けて、ポータルサーバとＳＮＳサーバ２とを接続するようにしてもよい。つまり、多数の異なる予約が可能な総合予約サイトを運営して、該総合予約サイトとＳＮＳサーバ２とを接続することで、異なる種類の予約を、ＳＮＳを通じて容易に実行できるようにしてもよく、このようにすることで、ＳＮＳの利用者の利便性を更に向上することができる。

また、前記実施例では、予約のみを行う形態を例示しているが、本発明はこれに限定されるものではなく、例えば、予約に伴って必要となる商品やサービスを購入可能なサイトのサーバも予約サーバに接続しておき、予約の完了メッセージにおいてこれらの商品を紹介し、該商品やサービスをＳＮＳからシームレスに購入できるようにしてもよい。

また、前記実施例では、特別なメッセージ画面において、選択（タップ）可能なメニューとして「ホテル予約」、「予約確認・変更」、「お客様情報変更」、「地図」、「新着情報」、「質問」の６つのメニューをした形態を例示しているが、本発明はこれに限定されるものではなく、これらのメニューの数や内容、配置等は適宜に決定すれば良い。但し、これらメニューが配置される位置としては、交換されるメッセージの表示に邪魔とならず、かつ、携帯端末を把持する利用者が、把持したままでの操作が可能な位置である画面下部の位置であることが好ましい。

また、前記実施例では、シークレットプラン（画像）を、ＳＮＳサーバＳＶ２がホテル予約サーバＳＶ１から取得して単に配信しているが、これら配信されたシークレットプラン（画像）が、顧客ではない他の利用者に容易に転送されてしまうことがないように、シークレットプラン（画像）を他のＳＮＳ利用者等に送信する場合に、ＳＮＳサーバＳＶ２が該送信を制限するための特別な情報（データ）を付与して送信したり、或いは、他のＳＮＳ利用者等に送信した場合には、画像が見えなくなるような特殊なデータとすることで、これら他のＳＮＳ利用者等への転送によって、シークレットプラン（画像）の価値が低下してしまうことを防止できるようにしてもよい。

また、前記実施例では、メッセージを送受する利用者が１人の場合を例示したが、たとえば、ＳＮＳが、複数の利用者（メンバー）が同時にメッセージを交換可能な機能を有する場合に、これら複数の利用者（メンバー）とのメッセージ交換による予約を可能としてしまうと、対象者が不定となってしまうことから、これら複数の利用者（メンバー）がメッセージの交換対象となっているか否かを判定して、複数の利用者（メンバー）がメッセージの交換対象である場合には予約を不能または制限するようにしてもよい。

ＳＶ１ ホテル予約サーバ
ＳＶ２ ＳＮＳサーバ
ＳＶ３ ＳＮＳ対話用ＡＩサーバ
ＭＰ 携帯端末

Claims (5)

1. 異なる利用者の端末間において相互にメッセージを送受可能なソーシャルネットワークサービスに利用登録した利用者が予約を行うための予約システムであって、
   前記ソーシャルネットワークサービスを提供するためのＳＮＳサーバと、
   予め顧客情報を登録した顧客の端末からインターネット網を介して、顧客が本人であることを認証したことを条件に予約を受付け可能な予約サーバと、
   を含み、
   前記ＳＮＳサーバと前記予約サーバとはネットワーク接続されており、
   前記予約サーバは、
   前記ＳＮＳサーバにおいてメッセージの送受に使用される識別情報であって、顧客情報を登録した顧客に対して前記ソーシャルネットワークサービスにおいて独自に付与されたＳＮＳ識別情報を記憶可能なＳＮＳ識別情報データベースを有し、
   前記ソーシャルネットワークサービスの利用者が、予約に関する所定メッセージを送信したときに、前記ＳＮＳサーバから送信されるＳＮＳ識別情報が前記ＳＮＳ識別情報データベースに記憶されていることを条件に、顧客が本人であることの所定の認証を実行することなく、予約を受付ける
   ことを特徴とする予約システム。
2. 前記ＳＮＳサーバは、前記ＳＮＳ識別情報データベースに記憶されているＳＮＳ識別情報が付与された利用者に対しては、メッセージを表示する画面として、予約に関する異なるメニューが選択操作可能とされた特別メッセージ画面を送信する
   ことを特徴とする請求項１に記載の予約システム。
3. 前記ＳＮＳサーバは、前記予約サーバを運営する運営者とメッセージを送受する利用者のＳＮＳ識別情報が前記ＳＮＳ識別情報データベースに記憶されているか否かを判定し、ＳＮＳ識別情報が前記ＳＮＳ識別情報データベースに記憶されているときには、予約に関するメッセージの送受を実行する一方、ＳＮＳ識別情報が前記ＳＮＳ識別情報データベースに記憶されていないときには、前記ＳＮＳ識別情報データベースにＳＮＳ識別情報を記憶することを案内するメッセージを送信する
   ことを特徴とする請求項１または２に記載の予約システム。
4. 前記ＳＮＳサーバは、前記ＳＮＳ識別情報データベースにＳＮＳ識別情報が記憶されていることを条件に、該ＳＮＳ識別情報に付与された利用者の端末に、顧客のみに提供される特別な情報を、前記予約サーバから取得して送信する
   ことを特徴とする請求項１〜３のいずれかに記載の予約システム。
5. 前記予約サーバは、予約が完了したときに当該予約について前記ＳＮＳサーバを介したメッセージの送受を伴ったＳＮＳ予約であるか否かを判定する判定手段を備え、
   前記判定手段においてＳＮＳ予約でないと判定された場合には、該予約を行った顧客に対して予約完了の電子メールを送信する一方で前記ＳＮＳサーバを介した予約完了のメッセージを送信せず、
   前記判定手段においてＳＮＳ予約であると判定された場合には、該予約を行った顧客に対して予約完了の電子メールを送信しない一方で前記ＳＮＳサーバを介した予約完了のメッセージを送信する
   ことを特徴とする請求項１〜４のいずれかに記載の予約システム。

Images