JP7272337B2 - 情報処理システム、情報処理方法及びプログラム - Google Patents

Description

本発明は、ユーザから飲食店等のサービス施設の予約を受け付け、それに通知するメッセージをサービス施設の端末へ送信可能な情報処理システム、情報処理方法及びプログラムに関する。

従来から、飲食店等のサービス施設に対する予約を当該サービス施設に代わって受け付け、管理するシステムが存在する。

例えば下記特許文献１には、ユーザ端末から管理サーバに対して予約要求が送信され、それを管理サーバで受け付けると、管理サーバが、受け付けた予約要求に基づいて、予め記憶した当該飲食店の電子メールアドレスを抽出し、電子メールで当該飲食店に予約があったことを予約者情報と共に通知することが記載されている。

特開２０１８－１９８１００号公報

しかしながら、上記特許文献１のような従来技術では、サーバ側に登録されている飲食店のメールアドレスが、例えば退職者のアドレスである場合等、現在使われなくなったアドレスである場合がある。そのような古いメールアドレスに予約の通知が送信されると、予約者の個人情報が飲食店の外部に漏洩してしまうおそれがある。

以上のような事情に鑑み、本発明の目的は、サービス施設への予約者の個人情報の漏洩を極力防止することが可能な情報処理システム、情報処理方法及びプログラムを提供することにある。

本発明の一形態に係る情報処理システムは、記憶部、通信部、制御部を有する。上記記憶部は、ユーザ端末からのサービス施設への予約要求の受付を当該サービス施設端末へ通知する予約通知メールの宛先となるメールアドレスを当該サービス施設ごとに記憶する。上記通信部は、上記ユーザ端末及び上記サービス施設端末と通信する。上記制御部は、上記サービス施設の管理者による上記メールアドレスの承認を示す承認情報を上記サービス施設端末から受信する。そして制御部は、上記ユーザ端末から上記サービス施設に対する予約要求が新たに受け付けられた場合に、上記メールアドレス宛の予約通知メールに掲載される情報の量を、当該メールアドレスに関する上記承認情報の受信からの経過時間の長さに基づいて削減して当該予約通知メールを送信する。

この構成により情報処理システムは、サービス施設の管理者に長期間承認されていないメールアドレスへの予約通知メールほど、情報量を少なくすることで、サービス施設への予約者の個人情報の漏洩を極力防止することができる。これは、予約通知メールの宛先として、サービス施設の従業員の個人メールアドレス（サービス施設以外でも使用するメールアドレス）が使用されている場合に特に有効である。またこの構成により、管理者に情報量の削減を気づかせることで、管理者にメールアドレスの早期の承認を促すこともできる。当該情報処理システムは、１または複数の情報処理装置で構成されうる。ここで「削減」とは、例えば文字の削除、記号等への変換、マスキング等、ユーザに個人情報が把握不可能な状態にするためのあらゆる処理を含む。

上記制御部は、上記予約通知メールに掲載される情報のうち、上記ユーザ端末のユーザに関する個人情報の量を、上記経過時間の長さに基づいて少なくしてもよい。

これにより情報処理システムは、予約の内容についてはサービス店舗側に把握させながらもユーザの個人情報の漏洩を防ぐことができる。

上記制御部は、上記承認情報を受信した場合に対応する上記経過時間をリセットしてもよい。

これにより情報処理システムは、承認を受けたメールアドレスに対しては個人情報を含めて正確な予約情報をサービス施設に提供することができる。

上記制御部は、上記予約要求に含まれる予約内容に応じて上記削減される情報の量を制御してもよい。

これにより情報処理システムは、予約情報の見落としがサービス施設のオペレーションや売上に与える影響が高いものほど削減量を減らす等、予約内容に応じて削減処理を柔軟に調整することができる。

上記制御部は、現在日時から上記予約要求に含まれる予約日時までの残り時間が少ないほど、上記情報の削減量を少なくしてもよい。

これにより情報処理システムは、予約日時までの残り時間が少ない場合には例外的に個人情報の削減量を減らすことで、サービス施設に、差し迫った予約に迅速に対処させることができる。

上記制御部は、上記予約要求に含まれる予約人数が多いほど、上記情報の削減量を少なくしてもよい。

これにより情報処理システムは、予約日人数が多い場合には例外的に個人情報の削減量を減らすことで、サービス施設に、席の確保等の処理を行わせ、大きな売上機会の損失を防ぐことができる。

上記制御部は、上記予約要求に含まれる予約コース種別または予約プラン種別の利用料金が高いほど、上記情報の削減量を少なくしてもよい。

これにより情報処理システムは、予約されたコース料理や施術コース、宿泊プラン等が高額な場合には例外的に個人情報の削減量を減らすことで、サービス施設に、大きな売上機会の損失を防ぐことができる。

本発明の他の形態に係る情報処理方法は、
ユーザ端末からのサービス施設への予約要求の受付を当該サービス施設端末へ通知する予約通知メールの宛先となるメールアドレスの、上記サービス施設の管理者による承認を示す承認情報を上記サービス施設端末から受信し、
上記ユーザ端末から上記サービス施設に対する予約要求が新たに受け付けられた場合に、上記メールアドレス宛の予約通知メールに掲載される情報の量を、当該メールアドレスに関する上記承認情報の受信からの経過時間の長さに基づいて削減して当該予約通知メールを送信する、ことを含む。

本発明の他の形態に係るプログラムは、情報処理装置に、
ユーザ端末からのサービス施設への予約要求の受付を当該サービス施設端末へ通知する予約通知メールの宛先となるメールアドレスの、上記サービス施設の管理者による承認を示す承認情報を上記サービス施設端末から受信するステップと、
上記ユーザ端末から上記サービス施設に対する予約要求が新たに受け付けられた場合に、上記メールアドレス宛の予約通知メールに掲載される情報の量を、当該メールアドレスに関する上記承認情報の受信からの経過時間の長さに基づいて削減して当該予約通知メールを送信するステップと、を実行させる。

以上説明したように、本発明によれば、サービス施設への予約者の個人情報の漏洩を極力防止することができる。しかし、当該効果は本発明を限定するものではない。

本発明の一実施形態に係る飲食店情報提供システムの構成を示した図である。 本発明の一実施形態に係る飲食店情報提供サーバのハードウェア構成を示した図である。 本発明の一実施形態に係る飲食店情報提供サーバが有するデータベースの構成を示した図である。 本発明の一実施形態に係る飲食店情報提供サーバによる、予約通知メール送信処理の流れを示したフローチャートである。 本発明の一実施形態において飲食店情報提供サーバによって飲食店端末に送信され表示される予約受付通知メールの例を示した図である。

以下、図面を参照しながら、本発明の実施形態を説明する。

［システムの構成］
図１は、本実施形態に係る飲食店情報提供システムの構成を示した図である。

同図に示すように、このシステムは、インターネット５０上の飲食店情報提供サーバ１００と、複数のユーザ端末２００と、複数の飲食店端末３００とを含む。

飲食店情報提供サーバ１００は、飲食店に関する情報を掲載したポータルサイトを運営するウェブサーバである。飲食店情報提供サーバ１００は、複数のユーザ端末２００及び複数の飲食店の飲食店端末３００とインターネット５０を介して接続されている。

飲食店情報提供サーバ１００は、上記ポータルサイトにおいて、ユーザ端末２００のユーザ向けに飲食店情報の検索システムを提供する。具体的には、飲食店情報提供サーバ１００は、ユーザ端末２００からの検索要求に基づいて検索条件に合致する飲食店情報を検索し、検索結果を掲載したＷｅｂページを生成してユーザ端末２００へ送信する。また飲食店情報提供サーバ１００は、当該飲食店情報を閲覧したユーザのユーザ端末２００からの、いずれかの飲食店に対する予約受付処理を代行する。

ユーザ端末２００（２００Ａ，２００Ｂ，２００Ｃ...）は、ユーザにより使用される端末であり、例えばスマートフォン、携帯電話、タブレットＰＣ（Personal Computer）、ノートブックＰＣ、デスクトップＰＣ等である。ユーザ端末２００は、飲食店情報提供サーバ１００へアクセスし、上記Ｗｅｂページを受信してブラウザ等により画面に表示する。

ユーザ端末２００は、ユーザの操作に基づいて飲食店の検索条件を決定し、当該検索条件に基づく飲食店検索要求を飲食店情報提供サーバ１００へ送信する。本実施形態では、飲食店の所在エリア（最寄駅）やジャンル、価格帯等、予め設定された検索条件をユーザ端末２００のユーザが選択することで検索要求の送信が可能である。そしてユーザ端末２００は、ユーザの操作に基づいて、上記検索結果として表示されたいずれかの飲食店に対する予約要求を飲食店情報提供サーバ１００へ送信可能である。

また一方で飲食店情報提供サーバ１００は、上記ポータルサイトに掲載される飲食店（加盟店）向けに、飲食店情報の管理画面（Ｗｅｂページ）を提供している。飲食店端末３００のユーザは、当該管理画面を介して、上記検索結果として一般ユーザに提供されるＷｅｂページ上の飲食店情報（コンテンツ）を編集・更新し、当該Ｗｅｂページを上記ポータルサイト上にアップロードすることができる。

飲食店端末３００（３００Ａ，３００Ｂ，３００Ｃ...）は、各飲食店に設置されている端末であり、タブレットＰＣ、ノートブックＰＣ、デスクトップＰＣ等である。飲食店端末３００は、管理者の操作に基づいて、上記飲食店情報の編集・更新等、自身の飲食店情報に関する処理を飲食店情報提供サーバ１００との通信により実行することが可能である。

飲食店情報提供サーバ１００は、当該予約を受け付けると、予約者情報等の予約内容を記載して予約の受付を飲食店の通知する予約通知メールを、各飲食店の管理者によって予め定められた通知用のメールアドレス宛に送信する。

本実施形態では、飲食店情報提供サーバ１００は、上記予約通知メールに掲載される情報の量を、上記メールアドレスを飲食店の管理者が最後に承認（現在使用していることの確認）したときからの経過時間の長さに応じて削減して当該予約通知メールを送信する。この予約通知メールの送信処理の詳細については後述する。

［飲食店情報提供サーバのハードウェア構成］
図２は、上記飲食店情報提供サーバ１００のハードウェア構成を示した図である。同図に示すように、飲食店情報提供サーバ１００は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、入出力インタフェース１５、及び、これらを互いに接続するバス１４を備える。

ＣＰＵ１１は、必要に応じてＲＡＭ１３等に適宜アクセスし、各種演算処理を行いながら飲食店情報提供サーバ１００の各ブロック全体を統括的に制御する。ＲＯＭ１２は、ＣＰＵ１１に実行させるＯＳ、プログラムや各種パラメータなどのファームウェアが固定的に記憶されている不揮発性のメモリである。ＲＡＭ１３は、ＣＰＵ１１の作業用領域等として用いられ、ＯＳ、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。

入出力インタフェース１５には、表示部１６、操作受付部１７、記憶部１８、通信部１９等が接続される。

表示部１６は、例えばＬＣＤ（Liquid Crystal Display）、ＯＥＬＤ（Organic ElectroLuminescence Display）、ＣＲＴ（Cathode Ray Tube）等を用いた表示デバイスである。

操作受付部１７は、例えばマウス等のポインティングデバイス、キーボード、タッチパネル、その他の入力装置である。操作受付部１７がタッチパネルである場合、そのタッチパネルは表示部１６と一体となり得る。

記憶部１８は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリ（ＳＳＤ；Solid State Drive）、その他の固体メモリ等の不揮発性メモリである。当該記憶部１８には、上記ＯＳや各種アプリケーション、各種データが記憶される。

後述するが、特に本実施形態において、記憶部１８は、後述する予約通知メール送信処理に必要なアプリケーション等のプログラムの他、飲食店情報データベース、ユーザ情報データベース、及び予約情報データベースを有している。

通信部１９は、例えばEthernet用のＮＩＣ（Network Interface Card）や無線ＬＡＮ等の無線通信用の各種モジュールであり、上記ユーザ端末２００との間の通信処理を担う。

なお、図示しないが、ユーザ端末２００及び飲食店端末３００の基本的なハードウェア構成も上記飲食店情報提供サーバ１００のハードウェア構成と略同様である。

［飲食店情報提供サーバのデータベース構成］
図３は、上記飲食店情報提供サーバ１００が有するデータベースの構成を示した図である。

同図に示すように、飲食店情報提供サーバ１００は、記憶部１８に、飲食店情報データベース３１、ユーザ情報データベース３２、予約情報データベース３３を有している。

飲食店情報データベース３１は、飲食店毎に、その飲食店の店名、所在位置（住所または緯度経度）情報、エリア情報、アクセス情報（最寄り駅情報、最寄り駅からの徒歩距離情報）電話番号、その飲食店を識別するＩＤ（店舗ＩＤ）、その飲食店の業態・サービスのカテゴリ情報、その飲食店を紹介する情報（店舗のＰＲ文等の店舗の特徴を示す情報、飲食店が行うイベント情報等）、飲食店に関する（飲食店を紹介する）画像データ、飲食店が提供するメニューに関するメニュー情報、平均予算情報、営業時間、ウェブサイトＵＲＬ等の情報等を記憶している。これらの情報は、各飲食店の飲食店端末３００から、飲食店情報提供サーバ１００が提供する管理画面を介して入力されたものである。

上記メニュー情報は、上記ポータルサイト上の各飲食店のサイトに掲載されるメニューに対応する情報であり、各飲食店が提供可能な複数のメニューのメニュー名を、飲食店毎に記憶している。当該メニュー情報は、例えば前菜／メイン、ランチ／ディナー／コース等のメニューカテゴリ毎に記憶されてもよい。またメニュー情報としては、メニュー名や値段、説明等を示す文字情報の他、当該メニューを撮影した写真等の画像情報も対応付けて記憶される。

上記エリア情報としては、広さ単位の異なる複数のエリアに関する情報が含まれる。広いエリアとしては例えば都道府県や市区町村、狭いエリアとしては例えば駅から数百ｍ以内（例えば、「銀座エリア」）、それらの間の広さのエリアとして、例えば駅から１ｋｍ以内のエリアや、複数の駅周辺エリアがまとまったエリア（例えば、「銀座・新橋・有楽町エリア」）等が挙げられるが、これらに限られない。これにより、同じ飲食店でも、その広さによって複数のエリアに紐付けられていることになる。

上記カテゴリ情報は、例えば和食、中華、イタリアン、フレンチ、焼肉等のメインカテゴリの他、和食における焼き鳥・天ぷら等、イタリアンにおけるパスタ・ピザ等のより詳細なサブカテゴリを含んでいてもよい。

また飲食店情報データベース３１には、ユーザ端末２００からの飲食店の予約要求の受付を飲食店へ通知する予約通知メールの宛先情報として、一または複数のメールアドレスも、飲食店ごとに記憶されている。当該メールアドレスは、上記飲食店端末３００にインストールされたメールソフトで用いられるメールアドレスであってもよいし、飲食店の従業員が飲食店端末３００とは別に保有するスマートフォンにインストールされたメールソフトで用いられるメールアドレスであってもよいし、その他飲食店端末３００や従業員の端末から受信可能なウェブメールのメールアドレスであってもよい。

各飲食店の管理者は、例えば飲食店情報提供サーバ１００からの承認要求に応じて、または自発的に、上記予約通知メールの宛先として設定されているメールアドレスが現在も実際に使用されていることを承認する承認情報を飲食店情報提供サーバ１００へ、例えば上記管理画面や電子メール等を通じて送信する。飲食店情報データベース３１には、当該受信した承認情報の履歴（受信日時、承認対象のメールアドレス）も飲食店ごとに記憶されている。

上記メールアドレスが使われなくなった場合や、メールアドレスが変更された場合、また新たなメールアドレスを追加する場合には、管理者は上記管理画面や電子メール等を介して、その旨の情報を送信し、飲食店情報提供サーバ１００は、その情報に応じて飲食店情報データベース３１内の予約通知メールの宛先情報を更新する。

ユーザ情報データベース３２は、ユーザ端末２００を所有する、上記飲食店情報提供サーバ１００が提供する上記ポータルサイトを介した飲食店情報サービスの利用者（会員）であるユーザに関する情報を記憶する。具体的には、ユーザ情報データベース３２は、ユーザＩＤ、パスワード、氏名、メールアドレス（その他、メッセージの宛先となる情報）、電話番号、住所、年齢（層）、性別、誕生日等の情報をユーザ毎に記憶している。

予約情報データベース３３は、ユーザ端末２００から受信した、各飲食店の予約要求に含まれる予約情報（例えば、飲食店名、予約者名、予約時刻、利用人数、利用コース等；予約台帳情報ともいう）を飲食店ごとに記憶する。当該予約情報データベース３３に記憶された情報を基に、上記予約通知メールが飲食店ごとに設定された上記メールアドレスへ送信される。

これら各データベースは、後述する飲食店情報提供サーバ１００による予約通知メール送信処理において、必要に応じて相互に参照されて用いられる。

［飲食店情報提供サーバの動作］
次に、以上のように構成された飲食店情報提供サーバ１００の動作について説明する。当該動作は、飲食店情報提供サーバ１００のＣＰＵ１１及び通信部１９等のハードウェアと、記憶部１８に記憶されたソフトウェアとの協働により実行される。以下の説明では、便宜上、ＣＰＵ１１を動作主体とする。

図４は、飲食店情報提供サーバ１００による、予約通知メール送信処理の流れを示したフローチャートである。

当該処理の前提として、飲食店情報提供サーバ１００の飲食店情報データベース３１は、上述したように、予約通知メールの宛先として設定されたメールアドレスについて、各飲食店の管理者から受信した承認情報の受信履歴を記憶し、最後に承認情報を受信してからの経過時間を管理している。したがって飲食店情報提供サーバ１００は、あるメールアドレスについて承認情報を受信した場合、それまで管理していた対応する経過時間をリセットし、新たに経過時間のカウントを開始する。なお、経過時間が常にカウントされている必要は無く、予約通知メールを作成する時点で対応するメールアドレスに関する承認情報の最終受信日時から現在までの経過時間が算出されてもよい。

同図に示すように、飲食店情報提供サーバ１００のＣＰＵ１１は、まず、ユーザ端末２００から、上記ポータルサイト上の飲食店情報に含まれる飲食店の予約要求を受信したか否かを判断する（ステップ４１）。

当該予約要求は、上記ユーザ端末２００のユーザを識別する情報（ユーザＩＤ、メールアドレス等）の他、少なくとも予約日時及び予約人数に関する情報を含み、また予約コース等の情報が含まれてもよい。

当該予約要求は、上記ポータルサイト上で例えばエリア、日時、人数、ジャンル、予算等の条件で検索された結果の検索結果（飲食店）一覧ページを介して送信されたものであってもよいし、飲食店情報の検索を経ずに（例えば該当飲食店のページに直接アクセスすることで）送信されたものであっても構わない。

上記予約要求を受信したと判断した場合（Ｙｅｓ）、ＣＰＵ１１は、上記飲食店情報データベース３１を参照して、予約対象の飲食店への通知用のメールアドレスを特定する（ステップ４２）。

続いてＣＰＵ１１は、上記飲食店情報データベース３１を参照して、上記特定したメールアドレスに関する最後の承認情報の受信からの経過時間を特定する（ステップ４３）。

続いてＣＰＵ１１は、上記予約要求に含まれる情報を基に、上記メールアドレス宛の予約通知メールを生成する（ステップ４４）。

続いてＣＰＵ１１は、上記予約通知メール中の、個人情報に該当する項目の記載量を、上記特定された経過時間の長さに基づいて削減する（ステップ４５）。

ここで「削減」とは、例えば文字の削除、記号や数字（例えば＊、●等）への変換、マスキング（塗りつぶし）等、ユーザに個人情報を把握不可能な状態にするためのあらゆる処理を含む。

また、経過時間の長さに基づいた削減としては、例えば、個人情報に該当する全項目（例えば予約者名、電話番号、メールアドレス等）の数に対する削減する（非表示にする）項目の数（または割合）が、経過時間（の範囲）と対応付けて記憶され、経過時間に応じた数の項目が非表示とされてもよい。例えば、個人情報の項目数が３つである場合、経過時間１カ月以上３カ月未満であれば１項目削減、３カ月以上６カ月未満であれば２項目削減、６カ月以上であれば３項目（全項目）削減、というように削減量が設定されてもよい。飲食店情報提供サーバ１００は、このような経過期間と削減する個人情報の項目の数または種別とを対応付けたテーブルを予め記憶しておき、当該テーブルに基づいて予約通知メール上の情報削減処理をしてもよい。

また、経過時間が所定の閾値（例えば６カ月）を超えた場合に一律に所定数（所定割合）の項目を削減する方法や、さらに当該閾値を超えた場合に経過時間に応じて削減項目数（割合）を増やしていく方法等、様々な手法が実行されうる。

そしてＣＰＵ１１は、上記情報削減後の予約通知メールを上記メールアドレスに対して送信する（ステップ４６）。

図５は、飲食店情報提供サーバ１００が生成し予め設定されたメールアドレス宛に送信される予約通知メールの例を示した図である。

同図に示すように、予約通知メールは、飲食店情報提供サーバ１００が受け付けた飲食店に対する予約内容を示す、例えば予約日時、予約人数、予約者名、予約者の電話番号、予約者のメールアドレス、予約コース等の情報項目を含む。

ただし、これらの項目のうち、個人情報に該当する予約者名及び電話番号は、記号「＊」５１に置換され非表示とされている。一方で、予約者のメールアドレスは個人情報に該当するがそのまま表示されている。これは、例えば、個人情報に該当する全項目数＝３に対して、経過時間が３カ月以上６カ月未満であったことから、それに応じた項目数＝２が削減された例を示している。

また、当該予約通知メールにおいて、メールアドレスの未承認期間に基づいて個人情報が削減されている場合には、同図に示すように、その旨を示す情報及び早期の承認処理を促す情報を含む管理者への注意書き情報５２も掲載されてもよい。またこの注意書き情報５２に、上記管理画面等、承認情報の送信のためのページへのハイパーリングが設定されていてもよい。

このような予約通知メールの送信後、飲食店情報提供サーバ１００は、管理者から上記管理画面等を介してその宛先のメールアドレスに関する承認情報を受信した場合には、当該メールアドレス対応する経過時間をリセットし、その後の予約通知メールについては当該リセット後の経過時間に基づいて個人情報の削減量を決定する。

また飲食店情報提供サーバ１００は、上記個人情報が削減された予約通知メールを送信した後、所定時間内（例えば２４時間以内）にその宛先のメールアドレスに関する承認情報を受信した場合、同一の予約内容について、上記個人情報を全て開示した予約通知メールを再送してもよい。

［まとめ］
以上説明したように、本実施形態によれば、飲食店情報提供サーバ１００は、サービス施設の管理者に長期間承認されていないメールアドレスへの予約通知メールほど、個人情報量を少なくすることで、サービス施設への予約者の個人情報の漏洩を極力防止することができる。これは、予約通知メールの宛先として、サービス施設の従業員の個人メールアドレス（サービス施設以外でも使用するメールアドレス）が使用されている場合に特に有効である。またこの構成により、管理者に情報量の削減を気づかせることで、管理者にメールアドレスの早期の承認を促すこともできる。

［変形例］
本発明は上述の実施形態にのみ限定されるものではなく、本開示の要旨を逸脱しない範囲内において種々変更され得る。

上述の実施形態において、飲食店情報提供サーバ１００は、上記承認情報の最後の受信からの経過時間に加えて、上記予約要求に含まれる予約内容に応じて上記削減される情報の量を制御してもよい。これにより飲食店情報提供サーバ１００は、予約情報の見落としがサービス施設のオペレーションや売上に与える影響が高いものほど削減量を減らす等、予約内容に応じて削減処理を柔軟に調整することができる。

具体的には、例えば飲食店情報提供サーバ１００は、現在日時から上記予約要求に含まれる予約日時までの残り時間が少ないほど、上記情報の削減量を少なくしてもよい。例えば飲食店情報提供サーバ１００は、上述の実施形態に従って、経過時間に応じて削減する項目数を特定した後、当該特定した項目数から、予約日時までの残り時間（または残り時間範囲）に応じて予め設定された項目数を引いた数を最終的な削減項目数として決定してもよい。

これにより飲食店情報提供サーバ１００は、予約日時までの残り時間が少ない場合には例外的に個人情報の削減量を減らすことで、飲食店に、差し迫った予約に迅速に対処させることができる。

また飲食店情報提供サーバ１００は、上記予約要求に含まれる予約人数が多いほど、上記情報の削減量を少なくしてもよい。例えば飲食店情報提供サーバ１００は、上述の実施形態に従って、経過時間に応じて削減する項目数を特定した後、当該特定した項目数から、予約人数（または人数範囲）に応じて予め設定された項目数を引いた数を最終的な削減項目数として決定してもよい。

これにより情報処理システムは、予約日人数が多い場合には例外的に個人情報の削減量を減らすことで、飲食店に、席の確保等の処理を行わせ、大きな売上機会の損失を防ぐことができる。

また、飲食店情報提供サーバ１００は、上記予約要求に含まれる予約コース種別または予約プラン種別の利用料金が高いほど、上記個人情報の削減量を少なくしてもよい。例えば飲食店情報提供サーバ１００は、上述の実施形態に従って、経過時間に応じて削減する項目数を特定した後、当該特定した項目数から、予約コースまたは予約プランの料金（または料金範囲）に応じて予め設定された項目数を引いた数を最終的な削減項目数として決定してもよい。

これにより飲食店情報提供サーバ１００は、予約されたコース料理が高額な場合には例外的に個人情報の削減量を減らすことで、飲食店に、大きな売上機会の損失を防ぐことができる。

また、飲食店情報提供サーバ１００は、上記予約日時までの残り時間、予約人数、予約コース種別のうち少なくとも２つに応じて個人情報の削減量を少なくしてもよい。

上述の実施形態及び変形例では、個人情報のみが削減対象とされたが、他の情報（予約日時や予約コース等）を含めて削減対象とされてもよい。

上述の実施形態において、飲食店情報提供サーバ１００は、単一のサーバではなく複数のコンピュータによって構成され、その機能がそれらコンピュータによって分散して実行されてもよい。

上述の実施形態では、サービス施設として飲食店が例に挙げられたが、サービス施設は飲食店に限られず、例えば、ホテル・旅館等の宿泊施設、テニス、バスケットボール、ゴルフ等の各種スポーツ施設、カラオケ・ボーリング等の娯楽施設、マッサージ・エステ等の施術施設等の様々なサービス施設についても、本発明は同様に適用可能である。この場合、上述の実施形態における予約コースに代えて予約プランが予約情報に含まれてもよく、宿泊施設やスポーツ施設の場合、予約部屋数や予約コート／組数等が予約情報に含まれてもよい。

本願の特許請求の範囲に記載された発明のうち、「情報処理方法」と記載された発明は、その各ステップを、ソフトウェアによる情報処理によりコンピュータ等の少なくとも１つの装置が自動的に行うものであり、人間がコンピュータ等の装置を用いて行うものではない。すなわち、当該「情報処理方法」は、コンピュータ・ソフトウェアによる情報処理方法であって、コンピュータという計算道具を人間が操作する方法ではない。

１１…ＣＰＵ
１８…記憶部
１９…通信部
３１…飲食店情報データベース
３２…ユーザ情報データベース
３３…予約情報データベース
１００…飲食店情報提供サーバ
２００…ユーザ端末
３００…飲食店端末

Claims (9)

1. ユーザ端末からのサービス施設への予約要求の受付を当該サービス施設のサービス施設端末へ通知する予約通知メールの宛先となるメールアドレスを当該サービス施設ごとに記憶する記憶部と、
   前記ユーザ端末及び前記サービス施設端末と通信可能な通信部と、
   前記サービス施設の管理者による上記メールアドレスの承認を示す承認情報を前記サービス施設端末から受信し、
   前記ユーザ端末から前記サービス施設に対する予約要求が新たに受け付けられた場合に、上記メールアドレス宛の予約通知メールに掲載される情報の量を、当該メールアドレスに関する前記承認情報の受信からの経過時間の長さに基づいて削減して当該予約通知メールを送信する
   制御部と
   を具備する情報処理システム。
2. 請求項１に記載の情報処理システムであって、
   前記制御部は、前記予約通知メールに掲載される情報のうち、前記ユーザ端末のユーザに関する個人情報の量を、前記経過時間の長さに基づいて少なくする
   情報処理システム。
3. 請求項１または２に記載の情報処理システムであって、
   前記制御部は、前記承認情報を受信した場合に対応する前記経過時間をリセットする
   情報処理システム。
4. 請求項１乃至３のいずれかに記載の情報処理システムであって、
   前記制御部は、前記予約要求に含まれる予約内容に応じて前記削減される情報の量を制御する
   情報処理システム。
5. 請求項４に記載の情報処理システムであって、
   前記制御部は、現在日時から前記予約要求に含まれる予約日時までの残り時間が少ないほど、前記情報の削減量を少なくする
   情報処理システム。
6. 請求項４または５に記載の情報処理システムであって、
   前記制御部は、前記予約要求に含まれる予約人数が多いほど、前記情報の削減量を少なくする
   情報処理システム。
7. 請求項４乃至６のいずれか記載の情報処理システムであって、
   前記制御部は、前記予約要求に含まれる予約コース種別または予約プラン種別の利用料金が高いほど、前記情報の削減量を少なくする
   情報処理システム。
8. ユーザ端末からのサービス施設への予約要求の受付を当該サービス施設のサービス施設端末へ通知する予約通知メールの宛先となるメールアドレスの、前記サービス施設の管理者による承認を示す承認情報を前記サービス施設端末から受信し、
   前記ユーザ端末から前記サービス施設に対する予約要求が新たに受け付けられた場合に、上記メールアドレス宛の予約通知メールに掲載される情報の量を、当該メールアドレスに関する前記承認情報の受信からの経過時間の長さに基づいて削減して当該予約通知メールを送信する、
   コンピュータが実行する情報処理方法。
9. 情報処理装置に、
   ユーザ端末からのサービス施設への予約要求の受付を当該サービス施設のサービス施設端末へ通知する予約通知メールの宛先となるメールアドレスの、前記サービス施設の管理者による承認を示す承認情報を前記サービス施設端末から受信するステップと、
   前記ユーザ端末から前記サービス施設に対する予約要求が新たに受け付けられた場合に、上記メールアドレス宛の予約通知メールに掲載される情報の量を、当該メールアドレスに関する前記承認情報の受信からの経過時間の長さに基づいて削減して当該予約通知メールを送信するステップと
   を実行させるプログラム。

Images