JP5847346B1 - サービス購入支援システム - Google Patents

Abstract

【課題】 空いた時間を使って何かをしようかなと考えている消費者に対し、新しい自分を発見できるようなユニークなサービス関連のコンテンツを提供する。【解決手段】 ユーザー端末８から送信されたユーザー特定情報及び日付時間帯場所情報に従って配信サーバー１が多数のサービスを抽出し、抽出された各サービスのコンテンツをユーザー端末８に送信して表示させる。配信サーバー１は、ユーザー特定情報に従って特定されるユーザーについて履歴情報ファイル１１を参照して履歴情報との関連性が最も低いジャンルを特定し、特定されたジャンルのサービスのコンテンツをユーザー端末８において初期表示される画面内にレイアウトする。【選択図】 図１

Description

この出願の発明は、消費者がサービスを購入する際に使用されるサービス購入支援システムに関するものである。

モノ余りと言われて久しい現代、いわゆるサービス消費の割合が増している。サービス消費とは、商品（有体物商品）の購入という消費行動ではなく、顧客が一定の時間を使い一定のサービスを受けることに対して対価を支払うという消費行動である。近年、サービス業におけるイノベーションの進展にもめざましいものがあり、有益な新しいサービスが次々に登場している。

サービスという事業形態は、事業者にとって“時間”を提供するものであり、消費者にとっても“時間”を消費するものであるため、しばしば予約という行為を必要とする。最近では、サービス消費の予約ができるインターネットサイトも多くなってきており、飲食店での席の予約、コンサートのチケットの予約、美容室の予約といった予約ができるサイトが盛んに運営され、多く利用されている。このような予約サイトは、ポータルサイトのコンテンツの一部として設けられていたり、グルメ情報を紹介サイトのように情報提供を兼ねたサイトのコンテンツとして設けられていたりする場合が多い。

特開２００２−１８９６５６号公報

一方、個人の消費行動について考えてみると、ある特定の目的をもって特定の情報を探し、商品やサービスの購入の注文をする場合もあるが、そうでない場合もある。つまり、特にあてもなくネットサーフィンをしながら、興味を覚えた商品を購入してしまうことがあり得る。
サービスという時間を要素する消費財の関連でいうと、ある空いた時間があってその時間を消費する（つぶす）ために何かしようかとネットで調べるということがあり得る。例えば急に休みが取れたが特に予定がなく何をしようかとネットで調べたり、ある日の予定である予定の時刻と別の予定の時刻とが空いてしまってその時間帯に何かしようかとネットで調べたりすることもあり得る。

このように何かしようかなと漠然と考えている消費者にとって、現状のウェブサイトはあまり使い勝手が良くないことが判る。ポータルサイトであれ情報提供サイトであれ、現状のウェブサイトは、情報（コンテンツ）の項目がすべてジャンル別に分かれていて、それをタップ（又はクリック）することでさらに詳しいジャンルが表示され、ユーザーはさらにそこから任意のものを選んで目的のコンテンツに辿り着く。この場合、特定のジャンルのサービス消費を行うことを決めているユーザーにとっては問題ないが、特に決めていないユーザーとか、何という訳ではないがいつもとは違うことをしてみたいとか、違った自分を発見してみたいとかいったユーザーには、適していない。

また一方、サービス財を提供する業者（サービス事業者）の側に立ってみると、完全予約制で固定客で常にフル稼働であるというような例外を除き、通常はある程度の顧客を見込んで人員を配置するので、顧客が来ない場合には、空き時間（売り上げのない時間）ということになる。これは、商品販売で言えば、在庫品を抱えているのと同じであり、多少ディスカウントをしても顧客に来てもらい、損失を少なくするようにしたいという要望がある。

この出願の発明は、上記のようなサービス消費を巡る課題を考慮して為されたものであり、空いた時間を使って何かをしようかなと考えている消費者に対し、新しい自分を発見できるようなユニークなサービス関連のコンテンツを提供するシステムに係るものであり、その一方で、在庫品としての空き時間をなるべく減らしたいサービス事業者にとっても有益なシステムを提案するものである。

上記課題を解決するため、この出願の請求項１記載の発明は、ユーザー端末からのアクセスをネットワークを介して受け付けるサーバーを含む一又は複数のサーバーと、
各サービス事業者によって提供される各サービスに関する情報を記憶した記憶部と
を備えており、
いずれかのサーバーには、
ユーザー端末から送信されたユーザー特定情報及び日付時間帯場所情報に従って多数のサービスを抽出し、抽出された各サービスのコンテンツを当該ユーザー端末に送信して当該ユーザー端末に表示させるコンテンツ表示プログラムと、
コンテンツ表示プログラムによりユーザー端末にコンテンツが表示された後にいずれかのサービスが当該ユーザー端末により選択された際、当該サービスの購入のための情報をユーザー端末から受信する購入用プログラムとが実装されており、
記憶部には、各サービスの情報を記録したサービス情報ファイルと、特定のサービスが特定の日時及び時間帯に提供可能である旨の空き枠の情報を記録した空き情報ファイルと、各ユーザーの過去のサービスの購入に関する履歴情報が記録された履歴情報ファイルとが記憶されており、
サービス情報ファイルに記録されたサービス情報は、各サービスを提供するサービス事業者、各サービスが提供される場所、各サービスの提供に要する時間、各サービスの対価の情報を含んでおり、
前記日付時間帯場所情報は、特定の日付の特定の時間帯の情報と特定の場所とを含む情報であり、
前記コンテンツ表示プログラムは、送信された日付時間帯場所情報に従って空き情報ファイルを検索し、前記日付時間帯場所情報に含まれる場所の情報に従って当該場所付近で提供可能であって前記日付時間帯場所情報に含まれる日付時間帯と前記空き枠の日付及び時間帯とが重なっているサービスを多数抽出し、抽出された各サービスのサービス情報をサービス情報ファイルから取得してユーザー端末に送信してコンテンツとして表示させるものであり、
前記コンテンツ表示プログラムは、各サービスのコンテンツをジャンル分けせずにランダムにユーザー端末に表示させるものであって、表示される各サービスのコンテンツは、前記購入用プログラムを起動させるためのボタンを含んでおり、
前記コンテンツ表示プログラムは、前記抽出された各サービスのコンテンツを送信する際、送信されたユーザー特定情報に従って特定されるユーザーについて前記履歴情報ファイルを参照して前記履歴情報との関連性が最も低いジャンルを特定し、特定されたジャンルのサービスを含んだ状態で前記各サービスのコンテンツをユーザー端末に送信するものであり、
前記コンテンツ表示プログラムは、前記履歴情報との関連性が最も低いとされたジャンルのサービスのコンテンツを、ユーザー端末に初期表示される画面内にレイアウトするものであるという構成を有する。
また、上記課題を解決するため、請求項２記載の発明は、前記請求項１の構成において、入札情報ファイルを記憶した記憶部を備えており、
前記コンテンツ表示プログラムは、前記多数のサービスのコンテンツが前記ユーザー端末に表示された後に特定のサービスが選択された際、当該サービスの購入についてユーザーが入札価格を入力して前記サーバーに送信するための画面をユーザー端末に表示することが可能であり、
いずれかの前記サーバーには、入札価格を含む入札情報が送信された際、当該入札情報を入札情報ファイルに記録するとともに、落札がされた際に当該落札の対象となった入札情報を送信したユーザー端末に落札の旨を返信する入札管理プログラムが実装されているという構成を有する。
また、上記課題を解決するため、請求項３記載の発明は、前記請求項１又は２の構成において、前記記憶部には、前記ユーザー端末を操作するユーザーを含むメンバーの情報を記録したユーザーグループ情報ファイルが記憶されており、ユーザーグループ情報ファイルに記録されている情報は、各メンバーが操作する端末情報を含んでおり、
前記サービスは、複数人に対して同時に提供され得るものであり、
いずれかの前記サーバーには、前記多数のサービスのコンテンツが前記コンテンツ表示プログラムにより表示された後に特定のサービスが選択された際、ユーザーグループ情報ファイルに記録された情報に従い、当該サービスの情報を当該ユーザー端末を操作するユーザー以外のメンバーの端末に送信する共有化プログラムが実装されているという構成を有する。
また、上記課題を解決するため、請求項４記載の発明は、前記請求項１乃至３いずれかの構成において、前記サービスは、複数人に対して同時に提供され得るものであり、
前記空き情報ファイルには、同時に提供可能な人数の情報である提供人数とともに前記空き枠の情報が記録されたファイルであり、
前記コンテンツ表示プログラムは、前記日付時間帯場所情報に加え、同時に提供されることを望む人数の情報である希望人数がユーザー端末から送信された際に実行されるものであって、前記日付時間帯と前記空き枠の日付及び時間帯とが重なっているとともに提供人数と希望人数とが重なっているサービスを多数抽出し、抽出した各サービスのコンテンツを前記ユーザー端末に送信するプログラムであるという構成を有する。
また、上記課題を解決するため、請求項５記載の発明は、前記請求項１乃至４いずれかの構成において、前記履歴情報は、各ユーザーのジャンル毎の購入回数に応じた数値で記録されており、
前記コンテンツ表示プログラムは、購入回数の最も少ないジャンルを前記関連性が最も低いジャンルであるとするプログラムであるという構成を有する。
また、上記課題を解決するため、請求項６記載の発明は、前記請求項５の構成において、前記履歴情報には、前記購入回数に加え、各ユーザーが購入候補とした履歴が含まれており、
前記購入用プログラムは、前記コンテンツ表示プログラムで表示された多数のサービスのコンテンツの中から選択されたサービスについて購入の決済をする決済プログラムであり、
決済プログラムは、選択されたサービスについて決済前の段階で購入の候補とするプログラムであって、購入の候補とされたサービスについて履歴情報として履歴情報ファイルに記録するプログラムであり、
前記コンテンツ表示プログラムは、前記購入回数に応じた数値に加え、購入の候補とした回数に応じた数値を加算した上で、数値が最も小さいジャンルを前記関連性が最も低いジャンルとするプログラムであるという構成を有する。
また、上記課題を解決するため、請求項７記載の発明は、前記請求項５又は６の構成において、前記コンテンツ表示プログラムは、前記ユーザー端末での選択に従い、選択されたサービスの詳細情報を当該ユーザー端末に表示させることが可能であり、
前記履歴情報には、前記購入回数に加え、前記ユーザー端末において詳細情報が表示された履歴が含まれており、
前記コンテンツ表示プログラムは、前記購入回数に応じた数値に加え、詳細情報が表示された回数に応じた数値を加算した上で、数値が最も小さいジャンルを前記関連性が最も低いジャンルとするプログラムであるという構成を有する。
また、上記課題を解決するため、請求項８記載の発明は、前記請求項１乃至７いずれかの構成において、いずれかの前記サーバーには貴重性閲覧プログラムが実装されており、
貴重性閲覧プログラムは、前記多数のサービスのコンテンツが前記コンテンツ表示プログラムにより表示された後に特定のサービスが選択された際、当該サービスの前記重なっている空き枠以外の空き枠の情報を当該ユーザー端末に送信して表示させるプログラムであるという構成を有する。
また、上記課題を解決するため、請求項９記載の発明は、前記請求項１乃至８いずれかの構成において、前記コンテンツ表示プログラムは、前記日付時間帯場所情報に含まれる場所の情報に従って当該場所付近で提供可能であって前記日付時間帯場所情報に含まれる日付時間帯と前記空き枠の日付及び時間帯とが重なっているサービスを多数抽出した際、抽出された各サービスについて、当該日付時間帯と重なってはいない他の日付時間帯の空き枠として前記空き枠情報ファイルに記録されている空き枠の数を算出し、算出された数の少ないサービスを優先表示サービスとするプログラムであって、優先表示サービスのコンテンツを他のサービスのコンテンツに比べてユーザー端末の画面内の左上に近い位置にレイアウトするプログラムであるという構成を有する。
また、上記課題を解決するため、請求項１０記載の発明は、前記請求項１乃至９いずれかの構成において、前記記憶部には、特定のユーザーに対して当該ユーザーの友人又は知人が特定のサービス又は特定のジャンルのサービスの購入を推薦する旨の情報を記録した推薦情報ファイルが記憶されており、
前記コンテンツ表示プログラムは、前記各サービスのコンテンツを前記ユーザー端末に送信する際、前記履歴情報との関連性が最も低いジャンルと特定されたジャンルのサービスについて推薦情報ファイルに記録がある場合、当該推薦の情報を含んだ状態で当該サービスのコンテンツが表示されるようにするプログラムであるという構成を有する。
また、上記課題を解決するため、請求項１１記載の発明は、前記請求項１乃至１０いずれかの構成において、前記記憶部には、各ユーザー端末を操作する各ユーザーの個人情報を記録したユーザー情報ファイルと、ユーザー空き情報ファイルとが記憶されており、
各ユーザーの個人情報には、各ユーザーの年齢及び性別が含まれており、
ユーザー空き情報ファイルは、前記ユーザー端末から送信された日付時間帯場所情報を記録したファイルであり、
いずれかの前記サーバーは、前記サービス事業者が操作する事業者端末からのネットワークを介したアクセスを受け付けることが可能であって、このサーバーには、前記サービス事業者にユーザー空き情報ファイルの内容を閲覧させるユーザー空き情報閲覧プログラムと、ユーザーに対するサービス購入のオファーを前記サービス事業者に行わせるオファープログラムが実装されており、
特定の事業者端末から前記サーバーにアクセスがあった際、ユーザー空き情報閲覧プログラムは、ユーザー空き情報ファイルに記録された日付時間帯場所情報で特定される場所が、当該事業者端末を操作するサービス事業者によるサービス提供場所付近である場合、当該日付時間帯場所情報に含まれる日付時間帯の情報を事業者端末に送信して表示させるとともに、当該日付時間帯場所情報を送信したユーザーの年齢及び性別をユーザー情報ファイルから取得して事業者端末に送信して表示させるプログラムであり、
オファープログラムは、事業者端末に表示された日付時間帯場所情報を送信したユーザーに対するサービスの提供価格を事業者端末において入力させて前記サーバーに送信させるプログラムであって、送信された提供価格を、当該日付時間帯場所情報を送信したユーザーのユーザー端末に転送するプログラムであるという構成を有する。

以下に説明する通り、この出願の請求項１記載の発明によれば、日付、時間帯及び場所の情報を送信することで購入可能な各サービスのコンテンツが配信されるので、その中から気に入ったものの詳細の情報を閲覧することができる。この際、特定のジャンルを指定したり、特定のサービスを指定したりする必要はなく、ジャンルがランダムに選択されて各コンテンツが表示される。このため、時間が空いてしまった場合にその時間を潰すためのサービス購入支援として最適なものになる。加えて、場所情報を送信させ、時間が空いてしまう場所の付近で購入可能がサービスのみが表示されるので、購入可能なサービスをユーザーが絞り込む必要がなく、この点で使い易い。コンテンツが表示される際、購入履歴との関連性が最も低いコンテンツが必ず表示されるので、新しく趣味を広げたり新しい自分を発見したりするのに役立つシステムとなっている。
また、請求項２記載の発明によれば、上記効果に加え、サービスの購入の際、サービス事業者の提示価格で購入するのではなく、オークションに参加して落札することも可能なので、より安い価格でサービス購入できる可能性がある。この点は、特定のジャンルのサービスを購入すべくコンテンツの閲覧がされるのではないという点で特に意義がある。
また、請求項３記載の発明によれば、上記効果に加え、複数人に対して同時に提供され得るサービスの購入支援システムとしてより適したものとなる。即ち、コンテンツの詳細情報が表示された際、当該情報をグループのメンバーと共有するのが容易であるので、サービスの購入についてメンバーの同意を得やすくなる。
また、請求項４記載の発明によれば、上記効果に加え、複数人に対して同時に提供され得るサービスの購入支援システムとしてより適したものとなる。即ち、希望人数が抽出の条件にされるので、複数人が特定の場所で特定の時間帯に空いてしまった場合、その空き時間を潰すためのサービス購入支援として最適なものになる。
また、請求項５記載の発明によれば、上記効果に加え、履歴情報が数値化されており、購入回数の最も少ないジャンルが関連性が最も低いジャンルとされるので、過去の履歴に関連性のないジャンルを優先して表示するという処理がよりキメ細かく行えるようになり、新しい自分を発見したり、新しい分野や趣味に興味を持つきっかけをユーザーに与えるという効果がさらに高められる。
また、請求項６記載の発明によれば、上記効果に加え、ユーザーが購入候補とした回数も加味して関連性が最も低いジャンルが決められるので、過去の履歴に関連性のないジャンルを優先して表示するという処理がよりキメ細かく行えるようになり、新しい自分を発見したり、新しい分野や趣味に興味を持つきっかけをユーザーに与えるという効果がさらに高められる。
また、請求項７記載の発明によれば、上記効果に加え、詳細表示の表示回数も加味して関連性が最も低いジャンルが決められるので、過去の履歴に関連性のないジャンルを優先して表示するという処理がよりキメ細かく行えるようになり、新しい自分を発見したり、新しい分野や趣味に興味を持つきっかけをユーザーに与えるという効果がさらに高められる。
また、請求項８記載の発明によれば、上記効果に加え、ユーザーは、自分が日付時間帯場所情報を送信したことで返信されてきた空き枠の情報がどの程度貴重なものであるか評価することができるので、サービス購入の検討がし易くなる。
また、請求項９記載の発明によれば、上記効果に加え、他の空き枠の数が少ないサービスのコンテンツが優先表示されるので、空き枠の少ない貴重なサービスの購入をユーザーがし易くなる。
また、請求項１０記載の発明によれば、上記効果に加え、友人又は知人が推薦しているサービスの空き枠であるかどうかがユーザーにおいて視認されるので、サービス購入の動機付けになり、サービス購入の促進につながる。
また、請求項１１記載の発明によれば、上記効果に加え、特定の日付の特定の時間帯に特定の場所で空いている（暇である）というユーザーの申告をサービス事業者側が閲覧でき、金額のオファーという形で能動的に対応することが可能であるので、サービス事業者側にとっては予約無しで空いている時間帯（在庫）の処分をより積極的に行うことが可能になる。ユーザーとしても、自分が空いていると申告するだけであり、オファーが届いたらその内容を吟味すれば良いので、特に予定がなく何をするという目的もない場合に利用し易いものになる。

第一の実施形態のサービス購入支援システムの概略図である。 サービス購入アプリが実行されているユーザー端末８でのサービス購入アプリの実行画面の一例を示した概略図である。 サービス購入アプリが実行されているユーザー端末８でのサービス購入アプリの実行画面の一例を示した概略図である。 サービス購入アプリが実行されているユーザー端末８でのサービス購入アプリの実行画面の一例を示した概略図である。 サービス情報ファイル１３の構造を示した概略図である。 空き情報ファイル１４の構造を示した概略図である。 空き枠登録ページの一例を示す概略図である。 コンテンツ表示プログラムの概略を示したフローチャートである。 第二の実施形態のサービス購入支援システムの概略図である。 第二の実施形態における詳細画面の一例を示した概略図である。 第三の実施形態における履歴情報ファイルの構造を示した概略図である。 第三の実施形態における履歴情報記録モジュールの概略図である。 第三の実施形態におけるコンテンツ表示プログラムの概略図を示す図である。 第四の実施形態における詳細画面の一例を示した概略図である。 第五の実施形態におけるコンテンツ初期画面の一例を示した概略図である。 第六の実施形態において、コンテンツ表示プログラムがコンテンツをユーザー端末８に表示させる際にユーザー端末８に表示される通知承認画面の一例を示した概略図である。 第六の実施形態において店舗ＩＤでログインした際に最初に表示される事業者向け初期画面の一例を示した概略図である。 店舗端末９に表示されたユーザー空き情報の一例を示す概略図である。 オファープログラムにより送信されたメール（オファーメール）の一例を示した概略図である。

次に、この出願発明を実施するための形態（以下、実施形態）について説明する。
図１は、第一の実施形態のサービス購入支援システムの概略図である。図１に示すシステムは、サービス購入支援のためのポータルサイト（以下、サービス購入ポータルサイト）を提供するものとなっている。この実施形態では、サービス購入ポータルサイトは、主としてスマートフォン向けのサイトとなっているが、この出願の発明はこれに限られるものではない。
図１に示すように、実施形態のシステムは、幾つかのサーバー１〜４と記憶部１０とによって構成されている。記憶部１０は、各サーバー１〜４が備えるハードディスクのようなストレージの場合もあるし、サーバー１〜４と別途設けられたストレージサーバーの場合もある。

サーバーとしては、コンテンツの配信を行うサーバー（以下、配信サーバー）１と、空き枠情報を管理する空き情報サーバー２と、オークションサーバー３と、管理サーバー４等が設けられている。これらのサーバー１〜４のうち、幾つか又は全部のサーバーを一つのサーバーコンピューターで構成することもあり得る。また、各サーバー１〜４に対してアクセス権を持つ管理用端末１００が設けられている。管理用端末１００は、このサイトを運営する会社（以下、サイト運営会社）の担当者が操作するものである。

配信サーバー１は、このシステムでは中核的な機能を担うものである。配信サーバー１は、Ｗｅｂサーバーであり、Ｗｅｂサーバープログラムが実装されている。特に、この実施形態ではスマホ向けのサイトを提供するものであるため、ＨＴＭＬ５のようなＷｅｂプログラミング言語及びＣＳＳ３のようなスタイルシート言語でサイトが構築されている。
実施形態において、サービス購入ポータルサイトは、一部の機能をアプリ（以下、サービス購入アプリと呼ぶ）としてユーザー端末８に予めインストールしてから利用するものとなっている。サービス購入アプリは、Google PlayやApp Storeのようなアプリダウンロードサイトにアップロードされている。アップロードの際、“サービス予約”，“空いた時間”，“新しい自分”，“今日何する”といったキーワードが登録されており、これらのキーワードで検索された際にヒットするようアップロードされている。

尚、サービス購入アプリには、初期設定プログラムが含まれて、サービス購入アプリをダウンロードすると、最初に自動実行されるようになっている。初期設定は、ユーザーＩＤ及びパスワードの登録、年齢や性別、携帯電話番号といった個人情報の登録、通知を受けるためのメールアドレスの登録、サービス購入支援サイトで使用するニックネームの登録等が含まれる。これらの登録情報は、管理サーバー４の記憶部１０に送られ、記憶部１０上のユーザー情報ファイル１２に記録される。ユーザーＩＤは、複数の端末（例えばスマホとデスクトップＰＣ）で共通したものを使用することができるようになっている。但し、ユーザー特定情報としてＵＤＩＤやＩＭＳＩのような端末識別番号、又はＭＡＣアドレスのようなＩＰアドレスを使用する場合もある。この場合には、ユーザー特定情報は端末特定情報（端末依存情報）となる。

サービス購入アプリの主な機能は、インターネット１０１を介してサービス購入ポータルサイトにアクセスさせ、日付時間帯場所情報を送信させることである。日付時間帯場所情報の送信とは、特定の日付の特定の時間帯及び特定の場所の各情報を、ユーザーが使用する端末（以下、ユーザー端末）８がシステムに送信することである。
この点について、図２〜図４を使用して説明する。図２〜図４は、サービス購入アプリが実行されているユーザー端末８でのサービス購入アプリの実行画面の一例を示した概略図である。図２（１）には、あるユーザーのユーザー端末８の画面が示されている。ユーザー端末８にダウンロードされているアプリのうち、サービス購入アプリのアイコン８１をタップすると、図２（２）に示すように、日付入力欄８２及び時間帯入力欄８３が表示される。日付入力欄８２は、いわゆるカレンダーコントロールである。時間帯入力欄８３は、テキストボックスであるが、タップすると数値キー（テンキー）が自動で表示され、ここで入力された数値がテキストボックス内に嵌め込まれるようになっている。

日付及び時間帯を入力して「次へ」のボタン８４をタップすると、図２（３）に示すような場所情報の入力画面が表示される。この実施形態では、ユーザー端末８はスマホ、タブレットＰＣ等の携帯端末であることが想定されているので、場所の指定は、ユーザー端末８のＧＰＳ機能を使用できるようになっている。具体的には、図２（３）に示すように、場所指定欄には、「現在地」と表記されたボタン（以下、ＧＰＳボタン）８５があり、これがタップされると、ＧＰＳ情報を通知する旨の確認メッセージを表示した後、ユーザー端末８のＧＰＳ機能を利用してユーザー端末８の現在位置情報が送信データに格納されるようプログラミングされている。

また、場所指定欄には、「マップ使用」と表記されたボタン８６が設けられている。サービス購入アプリは、ユーザー端末８上のマップ機能をＡＰＩとして利用できるようになっており、「マップ使用」のボタン８６がタップされると、マップ機能により任意の位置を場所情報として指定できるようになっている。また、「住所入力」のボタン８７をタップすると、住所をテキスト入力する画面となり、ここで入力された情報が場所情報として保持される。

このようにして場所情報が入力され、ＧＰＳボタン８５又は送信ボタン（不図示）がタップされると、入力された日付時間帯場所情報が配信サーバー１に送信され、配信サーバー１上のコンテンツ表示プログラムに渡されるようサービス購入アプリがプログラミングされている。即ち、送信ボタンは、コンテンツ表示プログラムの起動ボタンとなっている。
尚、サービス購入アプリは、上記日付時間帯場所情報の送信の際、ユーザー特定情報も併せて配信サーバー１に送信し、コンテンツ表示プログラムに渡すようプログラミングされている。ユーザー特定情報は、この実施形態では、サービス購入アプリの初期設定で登録されるユーザーＩＤとなっている。

次に、コンテンツ表示プログラムについて説明する。まず、コンテンツ表示プログラムが参照する履歴情報ファイル及びユーザー情報ファイルについて説明する。
図１に示すように、管理サーバー４の記憶部１０には、履歴情報ファイル１１、ユーザー情報ファイル１２等が記憶されている。ユーザー情報ファイル１２は、前述したように、各ユーザーの氏名、住所、年齢、性別、職業、趣味、携帯電話番号、メールアドレス、ニックネーム等の情報が記録されたデータベースファイルである。尚、クレジットカード情報等の決済に関する情報は別のサイトで管理するので、このサイトでは登録されない。

履歴情報ファイル１１は、各ユーザーの過去のサービス購入の履歴情報等を記録したファイルである。この実施形態では、履歴情報のうちの購入履歴はこのサイト経由でのサービス購入の履歴である。履歴情報ファイル１１への記録は、後述する決済プログラムが実行されてサービス購入の決済がされた際（購入が確定した際）、決済プログラムのサブルーチンとして実行される。登録される履歴情報には、購入したサービスのジャンルが含まれる。

また、配信サーバー１の記憶部１０には、サービス情報ファイル１３が記憶されている。図５は、サービス情報ファイル１３の構造を示した概略図である。サービス情報ファイル１３は、コンテンツ表示プログラムにより表示される各サービスの情報を記録したファイルである。図５に示すように、サービス情報ファイル１３は、「サービスＩＤ」、「事業者名」、「店舗名」、「場所データ」、「サービス名」、「ジャンル」、「ジャンルＩＤ」、「所要時間」、「価格」、「アイコンパス名」等のフィールドから成るレコードを多数記録したデータベースファイルである。「アイコンパス名」のフィールドは、ユーザー端末８に当該サービスのアイコンを表示するに必要なデータやプログラムが格納された配信サーバー１上のパス名を記録したフィールドである。「場所データ」は、当該サービスが受けられる店舗の場所のデータであり、通常は緯度経度のデータである。

サービス情報ファイル１３の内容は、サイト運営会社の担当者が管理用端末１００を操作して登録する。このサイトに登録したいという申請がサービス事業者からあった場合、担当者が管理用端末１００を操作して情報を登録する。尚、店舗の場所の情報は住所である場合が多いので、住所を緯度経度の情報に適宜変換し、サービス情報ファイル１３の「場所データ」のフィールドに記録する。
また、後述するように、このサイトはサービス事業者向けのメニューも用意している。サービス事業者向けに発行されたＩＤとパスワードを入力してログインすると、サービス情報ファイル１３のうち自社のレコードの内容を修正することができるようになっている。

空き情報サーバー２の記憶部１０には、各サービス事業者における空き枠情報を記録した空き情報ファイル１４が記憶されている。空き情報ファイル１４は、空き情報サーバー２によって管理される。図６は、空き情報ファイル１４の構造を示した概略図である。
図６に示すように、空き情報ファイル１４は、「空き枠ＩＤ」、「サービスＩＤ」、「空き日付」、「空き時間帯１」、「空き時間帯２」、「空き数」、「ディスカウント価格」、「入札可否」、「入札最低価格」等のフィールドから成るレコードを多数記録したデータベースファイルである。「空き時間帯１」は空き時間帯の始まりの時刻を記録するフィールド、「空き時間帯２」は空き時間帯の終わりを記録するフィールドである。

空き情報ファイル１４は、サービス事業者によって入力された空き枠の情報が記録されるファイルである。空き情報サーバー２には、サービス事業者向けのメニューとして、空き枠の情報を登録するためのページが用意されている。図７は、このページ（以下、空き枠登録ページ）の一例を示す概略図である。
図７に示すように、空き枠登録ページでは、日付入力欄９１、時間帯入力欄９２、価格入力欄９３、入札可否入力欄９４、入札最低価格入力欄９５等が設けられている。日付入力欄９１はカレンダーコントロールが付設されており、時間帯入力欄９２はプルダウンで始まりと終わりの時刻を選択する欄である。入札最低価格入力欄９５は、入札可否入力欄９４で入札可の場合、サービス事業者が希望する最低価格を入力する欄である。これらが入力されて送信ボタン９６がクリック（又はタップ）されると、空き情報サーバー２に実装されている空き枠登録プログラムが起動し、空き情報ファイル１４に新しいレコードが追加され、入力された各情報が記録されるようプログラミングされている。

サービス事業者は、ユーザー（サービスの消費者）とは異なるＩＤでサイトにログインすることが予定されている。サービス事業者は、複数の店舗でサービスを提供することもあるので、ＩＤは店舗毎に発行される（以下、店舗ＩＤ）。サービス事業者向けのメニューには、上記空き枠の新規登録は、登録されている空き枠の閲覧や削除、空き枠の登録情報修正等が含まれる。店舗ＩＤでサイトにログインすると、初期画面（以下、事業者向け初期画面）が表示され、これらメニューのうちのいずれかを選ぶ各ボタンが表示されるようになっている。尚、管理サーバー４の記憶部１０には、図示されていないが、サービス事業者の情報を記録した事業者情報ファイルや、各サービス事業者について各店舗の情報を記録した店舗情報ファイル等が記憶されている。

次に、このような各記憶部１０上の各ファイルを参照しつつコンテンツをユーザー端末８に表示するコンテンツ表示プログラムについて説明する。図３（１）は、コンテンツ表示プログラムにより各サービスのコンテンツがユーザー端末８に表示された状態の一例を概略的に示している。図３（１）は、コンテンツ表示の初期の画面（以下、コンテンツ初期画面）を示している。
図３（１）に示すように、コンテンツ初期画面では、各サービスのコンテンツは、比較的大きなアイコン７１として表示される。アイコン７１には、サービスのジャンル、サービス事業者の名前、所要時間、費用（定価）等が表示されるようになっている。図３（１）では、４×４個の合計１６個のアイコン７１が表示されるようになっているが、下方にフリックすることでさらに別のアイコンが表示されるようになっている。

図８は、コンテンツ表示プログラムの概略を示したフローチャートである。前述したように、ユーザー端末８上で実行されているサービス購入アプリが日付時間帯場所情報及びユーザーＩＤを送信してコンテンツ表示プログラムを起動する。つまり、コンテンツ表示プログラムに対して、日付時間帯場所情報及びユーザーＩＤが引数として渡される。
コンテンツ表示プログラムは、まず、ユーザーＩＤに従って履歴情報ファイル１１を検索し、履歴情報があるかどうか判断する。履歴情報がある場合、履歴情報に含まれるジャンルを取得し、その論理否定により履歴情報にないサービスのジャンルを特定する。

履歴情報がない場合、ユーザー情報ファイル１２を検索し、ユーザー情報に従って当該ユーザーが興味がありそうなジャンルを幾つか特定し、その論理否定により興味がないと思われるジャンルを取得する。これについては、例えば、年齢、性別、職業等に従ってサービスのジャンルを幾つか対応付けするテーブル（対応表）を予め定めておき、それに従って特定したジャンルの論理否定を取得するようプログラミングされる。
このようにして論理否定により取得したジャンルのジャンルＩＤ（以下、論理否定ジャンルＩＤ）を、一時的にメモリ変数に格納する。通常、論理否定ジャンルＩＤは、複数取得される。どの程度の数の論理否定ジャンルＩＤが取得されるか不確定であるので、動的配列の配列変数を宣言して論理否定ジャンルＩＤを格納する。

次に、コンテンツ表示プログラムは、渡された日付時間帯場所情報を検索キーにして、空き情報ファイル１４を検索し、まず場所情報に従って付近の店舗で空き枠が登録されているものがあるかどうか検索する。具体的には、引数として渡された場所情報（ここでは緯度経度情報）と、空き情報ファイル１４の各レコードの「場所データ」の情報とを比較し、当該場所情報から所定の範囲内に店舗があるレコードを抽出する。即ち、引数の場所情報の緯度経度を中心として例えば半径１ｋｍ以内に「場所データ」の緯度経度があるレコードを抽出する。

次に、抽出された各レコードについて、日付時間帯場所情報に含まれる日付及び時間帯の各情報によってさらに検索して絞り込みを行う。即ち、ユーザーが空いているとした日付に空き情報ファイル１４の「空き日付」の値が一致し、空いているとした時間帯に空き情報ファイル１４の「空き時間帯」の値が重なるもの（二つの時間帯が少なくとも一部で一致するもの）を抽出する。そして、抽出したレコードの「空き枠ＩＤ」を変数に格納する。尚、日付時間帯場所情報に含まれる時間帯が「空き時間帯」の値に含まれるものを抽出しても良く、そのようにした方がユーザーが確実に提供を受けることができるので好適である。

次に、コンテンツ表示プログラムは、抽出した「空き枠ＩＤ」について、そのサービスのジャンルＩＤが論理否定ジャンルＩＤとして変数に格納されているか判断し、格納されていれば、論理否定ジャンルの空き枠である旨の配列変数に当該空き枠ＩＤを再格納する。この処理を、抽出されたすべての空き情報ファイル１４のレコードについて行う。
次に、コンテンツ表示プログラムは、論理否定ジャンルとされたグループの空き枠ＩＤについて、乱数等を使用してランダムに４個の空き枠ＩＤを選択する。そして、残りの論理否定ジャンルでなかったものも含め、残りの全てのレコードについて乱数等を使用してランダムに表示順を決定し、上位１２個の空き枠ＩＤを選択する。このようにして決定された１６個の空き枠ＩＤについて、各々サービスＩＤに従ってサービス情報ファイル１３を参照し、「アイコンパス名」のフィールドの値を取得する。そして、合計１６個のアイコン７１を、ユーザー端末８に表示させる。これで、コンテンツ表示プログラムの初期的な動作は終了である。この状態を示したのが、図３（１）である。

図３（１）において、最上部の四つの横に並んだアイコン７１は、論理否定ジャンルの空き枠ＩＤのアイコン７１である。従って、ユーザーにとっては、過去にサービス購入したことのないジャンルであるか、又は登録したユーザー情報との相関性がないとされたジャンルのサービスのアイコン７１である。下側の１２個のアイコン７１は、論理否定グループと非論理否定グループとが混在した状態でランダムに抽出されているので、過去にサービス購入したジャンルであったり、ユーザー情報との相関性が高いものであったり場合もあるが、そうでない場合もある。いずれにしても、コンテンツ表示プログラムが実行された最初の画面では、最上部の四つのアイコン７１は、ユーザーが過去にサービス購入したことのないジャンルであるか、又は登録したユーザー情報との相関性がないとされたジャンルのサービスのアイコン７１である。

その後、ユーザー端末８上で下方にスワイプされると、コンテンツ表示プログラムは、次の表示順のアイコン７１を表示する。即ち、論理否定グループの上位４個を除く論理否定グループと非論理否定グループからなるグループのうち、１３番目以降の表示順の空き枠ＩＤについて同様に「アイコンパス名」のフィールドの値を取得し、ユーザー端末８に各々アイコン７１を表示する。

このようにしてユーザー端末８に表示されるアイコン７１には、表示しているサービスや空き枠の詳細情報を表示するモジュール（以下、詳細表示モジュール）の起動コマンドが埋め込まれている。詳細表示モジュールは、コンテンツ表示プログラムのサブルーチンとしてプログラミングされている。空き枠の詳細画面の一例が、図３（２）に示されている。
図３（２）に示すように、詳細画面では、店舗名やサービス内容を表示した箇所に加え、日付、時間帯、価格、入札可否等が表示されるよう詳細表示モジュールがプログラミングされている。このうち、日付はユーザーが指定した日付、時間帯は、サービス事業者側で設定した時間帯であってユーザーが指定した時間帯の範囲に入る時間帯である。

また、価格のうち、「即決価格」は、その価格であれば入札無しに予約ができる価格である。これは、定価の場合もあるが、サービス事業者が最初からディスカウントして設定した価格の場合もある。サービス事業者側で入札可の設定をしている場合、図３（２）に示すように、「最低入札価格」の金額が表示され、併せて「入札」と表示されたボタン（以下、入札ボタン）７２が表示されるようになっている。

コンテンツ表示プログラムにより表示された各アイコン７１には、空き枠ＩＤを含む起動コマンドが埋め込まれており、詳細表示モジュールは、選択された空き枠ＩＤに従って空き情報ファイル１４を検索し、各情報を取得して詳細画面に組み込むようプログラミングされている。

また、図１に示すように、オークションサーバー３の記憶部１０には、入札情報ファイル１５が設けられている。入札情報ファイル１５は、一つの空き情報ファイル１４について少なくとも一つの入札があった際に空き枠ＩＤを使用したファイル名で自動作成されるデータベースファイルである。図示は省略するが、入札情報ファイル１５は、「ユーザーＩＤ」、「入札金額」等のフィールドから成るデータベースファイルとなっている。
図３（２）に示すように、入札可の場合、詳細画面には入札ボタン７２が表示されるようになっている。入札ボタン７２がタップされると、コンテンツ表示プログラムは、図３（３）に示すような入札金額を入力する画面を表示するようプログラミングされている。ここで、金額が入力され、送信ボタン７３がタップされると、コンテンツ表示プログラムは、図４（１）に示す入札確認画面を表示するようプログラミングされている。

入札確認画面に設けられた入札確認ボタン７４には、オークションサーバー３に実装された入札情報記録プログラムの起動コマンドが埋め込まれている。ここで入札確認ボタン７４がタップされると、入札情報がオークションサーバー３に送信され、入札情報記録プログラムにより入札情報ファイル１５に記録されるようになっている。入札情報記録プログラムは、当該空き枠ＩＤの入札情報ファイル１５が無い場合には新しくファイルを作成して入札情報を記録し、ある場合にはそのファイルを開いて入札情報を記録する。
尚、図示は省略するが、入札確認ボタン７４がタップされると、より詳細な個人情報を入力させる画面がユーザー端末８に表示されるようになっている。例えば、氏名、住所、メールアドレス等の個人情報である。ここで入力された個人情報は、ユーザー情報ファイル１２に追加して記録されるようプログラムが配信サーバー１に実装されている。

また、図３（２）に示すように、詳細画面には、「即決」と表示されたボタン（以下、即決ボタン）７５が設けられている。即決ボタン７５には、配信サーバー１上に実装された予約プログラムの起動コマンドが埋め込まれている。図１に示すように、管理サーバー４の記憶部１０には予約情報ファイル１６が記憶されている。予約情報ファイル１６は、「ユーザーＩＤ」、「空き枠ＩＤ」、「予約ＩＤ」等のフィールドから成るレコードを記録したデータベースファイルである。即決ボタン７５には、当該空き枠の空き枠ＩＤが埋め込まれており、予約プログラムは、空き情報ファイル１４に新しくレコードを追加し、ユーザーＩＤ及び空き枠ＩＤ等を記録する。
このように、コンテンツ表示プログラムによりサービス情報のコンテンツがユーザー端末８上に表示されると、ユーザーは、興味を持ったサービスのアイコン７１をタップして詳細表示し、入札金額を入力して送信したり、予約の送信を行ったりすることができるようになっている。

また、オークションサーバー３には、各入札情報ファイル１５を管理する入札管理プログラムが実装されており、ある期限が到達すると、入札管理プログラムにより落札プログラムが自動実行される。例えば、ある入札情報ファイル１５において対象となっている空き枠の日付の一週間前に落札プログラムが自動実行されるよう入札管理プログラムが実装されている。入札管理プログラムは、入札情報ファイル１５の中からその時点で最も高い入札額となっているレコードについてユーザーＩＤを取得し、そのユーザーに対し、自動送信メール（落札通知メール）で連絡をする。落札通知メールの一例が、図４（２）に示されている。図４（２）に示すように、落札通知メールには、落札者が予約を完了するためのプログラムのＵＲＬ（ハイパーリンク）７６が記載されている。ユーザーは、落札通知メールを受信した際、ＵＲＬ７６をタップして予約を完了する。この際、入札管理プログラムは、その空き枠について落札をしたユーザーが予約をしたとして扱い、予約情報ファイル１６に予約の旨の記録を追加する。

一方、サービス事業者向けのメニューとして、予約確認、落札確認等のメニューが用意されている。空き情報サーバー２には、サービス事業者に対して予約情報ファイル１６を閲覧させる予約状況閲覧プログラムや入札情報ファイル１５を閲覧させる入札情報閲覧プログラムが実装されている。

また、管理サーバー４には、決済プログラムが実装されている。決済プログラムについては、前述したように、空き情報閲覧画面で即決ボタン７５に実行コマンドが組み込まれている他、落札したことをユーザーに伝える自動送信メールに実行用ＵＲＬ（ハイパーリンク）７６が組み込まれる。従って、即決ボタン７５をタップするか、落札したことのメールを受信したユーザーが実行用ＵＲＬ７６をタップすることで実行される。
この実施形態では、ユーザーに対してはクレジットカードにより行うようになっている。決済プログラムは、セキュリティの高い別のクレジットカード決済用配信サーバー（不図示）に遷移するプログラムであり、そこで決済が行われる。
尚、この実施形態では、クレジットカード会社からの入金（各サービスの購入代金）はサイト運営会社に対して行われる。サイト運営会社は、各購入代金から一定のマージンを差し引いて各サービス事業者に支払う。

決済プログラムは、サブルーチンとして、決済報告モジュール、履歴情報記モジュール、空き情報更新モジュール等を有している。決済報告モジュールは、サービス事業者に購入がされた旨を伝えるモジュールであり、予め登録されているサービス事業者のメールアドレスに予約及び決済が完了した旨のメールを自動送信するモジュールである。履歴情報記録モジュールは、決済がされた空き枠について、履歴情報ファイル１１の新しいレコードを追加して記録するモジュールである。空き情報更新モジュールは、決済により正式に予約がされたことになるので、空き情報ファイル１４の当該空き枠のレコードを削除するモジュールである。尚、落札プログラム又は予約プログラムが実行された時点（未決済の状態）で、空き枠は仮予約の状態になるので、その旨の値が空き情報ファイル１４に記録され、コンテンツ表示プログラムが空き枠として抽出しないようにされる。

このような実施形態のサービス購入支援システムの全体の動作について、概略的に説明する。
ユーザーは、予めサービス購入アプリをユーザー端末８にダウンロードしておく。この際、年齢、性別、趣味といったユーザー情報が配信サーバー１に送信され、ユーザー情報ファイル１２に記録される。各サービス事業者は、サイト運営会社との間で契約を結び、マージンの額等を取り決めておく。
サービス事業者は、自社の店舗での空き状況を見ながら、店舗端末９を操作して空き枠の情報を空き情報サーバー２に送信する。空き情報サーバー２上の空き枠登録プログラムは、送信された空き枠の情報を空き情報ファイル１４に記録する。

ユーザーは、例えばある日のある時間帯に空き時間が出来てしまうことに気づき、サービス購入アプリを使用して何かしてみようと思い立ち、ユーザー端末（スマホ）８のサービス購入アプリのアイコン８１をタップする。そして、日付時間帯場所情報を入力してユーザー端末８から配信サーバー１に送信する。これにより、配信サーバー１上のコンテンツ表示プログラムが起動し、各サービスのアイコン７１がユーザー端末８上に表示される。この際、コンテンツ表示プログラムは、履歴情報ファイル１１又はユーザー情報ファイル１２を参照し、論理否定ジャンルの情報を取得し、論理否定ジャンルの４個のサービスのアイコン７１を初期の画面内に必ず表示する。

ユーザーは、興味を持ったものがあった場合、そのアイコン７１をタップし、詳細を表示する。そして、即決価格（定価又はディスカウント価格）で購入してみようと思った場合、即決ボタン７５をタップし、クレジットカードでの決済を行う。また、入札に参加しようと思った場合、入札ボタン７２をタップし、任意の金額を入力、送信する。後日、落札した旨の連絡がメールであった場合、決済プログラムのＵＲＬ７６をタップし、決済を行う。決済プログラムは、決済用の配信サーバー１に遷移するが、この際、履歴情報ファイル１１に新しいレコードを追加し、そのジャンルの購入履歴を記録する。
一方、サービス事業者は、サービスの予約又は落札がされて決済が完了すると、メールで連絡がされるので、正式に予約がされたことを知る。そして、予約の日時が到来したら、ユーザーに対してサービスを提供する。

このような構成及び動作に係る実施形態のサービス購入支援システムによれば、日付時間帯場所情報を送信することで購入可能な各サービスのコンテンツが配信されるので、その中から気に入ったものの詳細の情報を閲覧して予約することができる。この際、特定のジャンルを指定したり、特定のサービスを指定したりする必要はなく、ジャンルがランダムに選択されて各コンテンツが表示される。このため、時間が空いてしまった場合にその時間を潰すためのサービス購入支援として最適なものになる。できてしまった空き時間を潰す場合、特にこれといった当てがないのが通常なので、ジャンルを選択していかないと詳細な情報が得られない現状のポータルサイトは使いにくいし、ユーザーの利用が促進できない。この実施形態では、ジャンルを選択したり特定のサービスを選択したりすることなく各コンテンツが表示されるので、上記のような問題はない。

加えて、場所情報を送信させ、時間が空いてしまう場所の付近で購入可能がサービスのみが表示されるので、購入可能なサービスをユーザーが絞り込む必要がなく、この点で使い易い。この際、場所情報の送信はユーザー端末８のＧＰＳ機能を使用して行うことができるので、何らかの原因で時間が空いてしまったその場で（リアルタイムで）サービス購入をする場合に好都合である。また、場所情報は、地図情報サーバー（不図示）から取得して送信することができるので、将来のスケジュールにおいて時間が空いてしまうと予想される場合、特に便利なものとなる。
また、実施形態のシステムでは、コンテンツが表示される際、購入履歴にないジャンルのサービス又はユーザー情報との相関性がないジャンルのコンテンツが必ず表示されるので、新しく趣味を広げたり新しい自分を発見したりするのに役立つシステムとなっている。
実施形態において、各ジャンルの区別はある程度細かくする方が好ましい。大まかなジャンル分けであると、全てのジャンルについて購入履歴があるという状態になり易いからである。尚、この実施形態では、購入履歴のないジャンルがない場合、特に論理否定ジャンルの設定はせずに各コンテンツの表示がされる。

さらに、サービスの予約の際、サービス事業者の提示価格（定価又はディスカウント価格）で購入するのではなく、オークションに参加して落札することも可能なので、より安い価格でサービス購入できる可能性がある。この点は、特定のジャンルのサービスを購入すべくコンテンツの閲覧がされるのではないという点で特に意義がある。特定のサービスの購入（例えば美容室でのヘアカット）を目的としてネット検索をする場合、ユーザー自身が価格面である程度情報を持っており、表示される情報を参照しながら高い安いを判断できる場合が多い。一方、この実施形態のように特に当てもなく何となくやってみようかなと思った程度のサービスだと、価格の相場的なものがわかならい場合が多く、これぐらいの価格だったらやっても良いかな、という程度の場合が多い。したがって、とりあえずオークションに入札し、自分の希望価格を提示するというアプローチの方がトライし易い場合が多い。実施形態のシステムは、この点を考慮し、サービスという商取引の目的物に対してオークションという形を取り入れている。

尚、オークションを経てサービス購入をさせることは、実施形態のシステムにおいて必須の要件ではない。オークションの機能のないサイトであっても良い。また、サービスの提供開始時刻（空き時間帯の始まりの時刻）が近づいてきた場合、オークションを継続することは適切ではないので、例えば１日前とか数時間前とかの時間を区切ってそれ以降はオークションできない構成とされることもあり得る。この場合は、図３（２）に示す入札ボタン７２がグレーアウトされてタップできない状態とされる。

一方、サービス事業者においても、ある程度の顧客を見込んで人員を配置しなければならず、予約が入っていない空き時間帯は、不良在庫になってしまう可能性がある。それよりは、定価より安い価格でも顧客が来た方が良い。そして、実施形態のシステムでは、そのサービスを受けるのが初めてであるという顧客の可能性が高いので、その後、固定客になってリピートとしてもらえるがあり得る。即ち、実施形態のシステムにより顧客層を広げることで売り上げ拡大につながる可能性がある。

このように、実施形態のサービス購入支援システムによれば、空き時間ができてしまった際に特に当てもなく時間を潰したい場合に好適に利用でき、新しく趣味を広げたり新しい自分を発見したりする効果も期待できる。実施形態のシステムのより具体的な利用例を示すと、例えば、ある用事で自宅から離れた場所に出かける予定があり、ちょうどその日の別の時間帯にその場所の近くで別の用事があるとする。一度自宅に帰ってもう一度出かけても良いが、時間的に間に合わなかったり、面倒であったりする場合がある。この場合、その用事の場所の付近で暇つぶしをしたくなるが、ちょうどのその時間帯をつぶせるサービスがその場所付近であるかどうか探すのは、結構面倒である。実施形態のシステムによれば、その日時と場所の情報をするだけで購入可能なサービス（暇つぶしのアイテム）のコンテンツが多数表示されるので、非常に便利である。

この他、例えば急に休みができてしまったりとか、外出先で急に予定が変更になって時間が空いてしまったりするのは結構あることである。このような場合、何をしようかと特に意図しなくても、実施形態のシステムで提供されるコンテンツを閲覧することで、空いた時間を有意義に使える場合もあり得る。
尚、図２（２）に示すように、サービス購入アプリを起動すると、「マイページ」と表記されたボタン（マイページボタン）８８が表示されるようになっている。配信サーバー１には、マイページプログラムが実装されている。マイページプログラムは、ログインしたユーザーの過去の閲覧履歴や購入履歴、入札履歴等をリストにして表示するプログラムである。

次に、第二の実施形態のサービス購入支援システムについて説明する。図９は、第二の実施形態のサービス購入支援システムの概略図、図１０は、第二の実施形態における詳細画面の一例を示した概略図である。
第一の実施形態では、サービスは基本的に一人のユーザーのみが提供を受けるものとして説明したが、第二の実施形態は、複数人が提供を受けるサービスをも対象とするものとなっており、それを前提として最適化された構成を有している。
第一の実施形態のシステムでも、複数人に対して提供されるサービスの購入に利用することは可能である。複数人でサービスの提供を受ける場合、それら複数人がサービス提供場所にいなければいけないから、そこに来ることの同意を各人から取ったり、スケジュールの調整をしたりといったことが出てくる。

第二の実施形態のシステムは、これらの点を考慮して最適化した構成を有している。具体的に説明すると、まず、第二の実施形態では、複数人に対して同時に提供されるサービスも対象にできるようになっており、サービス情報ファイル１３には「対象人数」のフィールドが含まれている。そして、図１０に示すように、第二の実施形態では、サービス情報ファイル１３に記録されている「対象人数」が表示されるようになっている。

図９に示すように、第二の実施形態では、追加のサーバーとして共有化サーバー５が設けられている。また、第二の実施形態では、共有化サーバー５の記憶部１０には、ユーザーグループ情報ファイル１７が記憶されている。図示は省略するが、ユーザーグループ情報ファイル１７は、グループを構成するメンバーのニックネーム、電話番号、メールアドレス等の情報をデータベース化して記録したファイルである。各グループにはグループＩＤが付与されており、ユーザー情報ファイル１２には、グループＩＤのフィールドが設けられている。グループに属しているユーザーのレコードには、グループＩＤが記録されている。

共有化サーバー５には、空き枠の情報を共有化するためのメール（以下、共有化メール）の送信プログラムが実装されている。図１０に示すように、詳細画面には、「友達に知らせる」と表記されたボタン７７が設けられている。ボタン７７は、共有化メールの送信プログラムの起動コマンドが埋め込まれている。送信プログラム（以下、共有化メール送信プログラム）は、当該ユーザーが属するグループの各メンバーに対して共有化メールを送信するようプログラミングされている。共有化サーバーは、各種ＳＮＳやショートメールサービス等と同様の構成であり、グループのメンバー全員に対してメールでのやりとりを可能にするものである。
図示は省略するが、共有化サーバーから送られる共有化メールには、予約のためのＵＲＬや入札のためのＵＲＬが記載されている。メールを受信したいずれかのメンバーがＵＲＬをタップすると、予約や入札が行えるようになっている。この際、予約や入札は、そのタップを行ったメンバーの名前（ユーザー特定情報）でされるようになっている。

第二の実施形態では、コンテンツ配信される空き枠の情報をグループで共有することができるので、仲が良い友達同士でグループを作り、みんなでサービスの提供を受けることができる。例えば、ある日付のある時刻に集まろうという約束をメンバーがしたが、特に何かすることを決めている訳ではないとき、実施形態のシステムは好適に利用される。あるメンバーがアプリを使用してコンテンツを閲覧し、このサービスを利用しようかと聞く。メンバーは、このシステムのチャット機能（共有化メール送信プログラム）を利用し、意見を交換し、賛同が得られたら、メンバーの誰かが予約ないし入札をする。このような使い方が可能である。

尚、第一の実施形態の場合も含め、同時に提供を受けることを希望する人数（希望人数）をユーザー端末８から配信サーバー１に送信できるようにし、希望人数で空き情報の絞り込みが行われるようにすると、より好適である。具体的には、空き情報ファイルには、各空き枠について同時に提供可能な人数の情報（提供人数）が記録されている。サービス購入アプリは、日付時間帯場所情報に加え、希望人数を送信する画面を含む。ここで人数が入力されて送信されると、コンテンツ配信プログラムは、該当する空き枠の情報を抽出した後、希望人数と提供人数が重なる空き枠のみを絞り込むようプログラミングされる。「重なる」とは、希望人数が例えば５人の場合、提供人数が５人以下であるとか、提供人数が３人〜６人であるといった場合である。コンテンツ配信プログラムは、このように人数で絞り込みを行った後、前述したのと同様に論理否定ジャンルのサービスの優先表示を行いながら、ユーザー端末に各サービスのコンテンツを表示する。
このようにすると、複数人に対して同時に提供され得るサービスの購入支援システムとしてより適したものとなる。即ち、複数人が特定の場所で特定の時間帯に空いてしまった場合、その空き時間を潰すためのサービス購入支援として最適なものになる。

次に、第三の実施形態のサービス購入支援システムについて説明する。第三の実施形態は、履歴情報ファイル１１の構造、及び履歴情報ファイル１１の内容を参照してコンテンツを表示するコンテンツ表示プログラムが上記各実施形態と異なっている。
まず、第三の実施形態における履歴情報ファイルについて説明する。図１１は、第三の実施形態における履歴情報ファイル１１の構造を示した概略図である。

前述したように、履歴情報ファイル１１は、ユーザー毎に作成され、このサービス購入ポータルサイト経由でのサービス購入履歴が記録されたファイルである。図１１に示すように、履歴情報ファイル１１は、「購入日時」、「提供日時」、「ジャンル１」、「ジャンル２」等のフィールドから成るレコードを記録したデータベースファイルである。
「購入日時」のフィールドは、決済がされた日が記録されるフィールドである。「提供日時」のフィールドは、サービス提供の開始日時が記録されるフィールドである。

「ジャンル１」、「ジャンル２」、・・・は、各ジャンル毎の履歴情報を数値化して記録したフィールドである。これらフィールドは、ジャンルＩＤがフィールド名になっていたり、ジャンルの名称がフィールド名になっていたりする場合もある。この実施形態の特徴点は、各ジャンルの履歴情報が数値化されて記録される点である。そして、この実施形態では、数値化は、購入されたサービスのジャンルについてポイントを付与するのではなく、購入されなかったジャンルについてポイントを付与するものとなっている。以下、履歴情報ファイル１１における「ジャンル１」、「ジャンル２」・・・の各フィールドをジャンルポイントフィールドと呼ぶ。

第三の実施形態のシステムにおいて、管理サーバー４には、履歴情報記録モジュールが実装されている。図１２は、第三の実施形態における履歴情報記録モジュールの概略図である。履歴情報記録モジュールは、決済プログラムのサブルーチンとして実行されるモジュールであり、決済プログラムにより決済がされた際、決済プログラムにより呼び出されて実行されるサブプログラムである。

図１２に示すように、履歴情報記録モジュールは、ログインの際に保持されたユーザーＩＤに従って当該ユーザーの履歴情報ファイル１１を開き、決済プログラムにおいて取得された購入日時や提供日時の情報を、「購入日時」、「提供日時」のフィールドにそれぞれ記録する。そして、決済プログラムにおいて取得されたジャンルＩＤに従って、該当するジャンルのジャンルポイントフィールド以外の全てのジャンルポイントフィールドの値を記録する。例えば、購入されたサービスのジャンルが「ジャンル２」であった場合、履歴情報記録モジュールは、「ジャンル１」、「ジャンル３」・・・「ジャンルｎ」について１を記録し、「ジャンル２」については０を記録する。これで、履歴情報記録モジュールは終了である。

一方、第三の実施形態では、コンテンツ表示プログラムは、このような履歴情報ファイル１１内のジャンルポイントフィールドの値を参照しながらコンテンツを表示するようプログラミングされている。図１３は、第三の実施形態におけるコンテンツ表示プログラムの概略図を示す図である。
前述した各実施形態と同様に、ユーザー端末８上で実行されているサービス購入アプリが日付時間帯場所情報及びユーザーＩＤを送信してコンテンツ表示プログラムを起動する。コンテンツ送信プログラムは、日付時間帯場所情報を検索キーにして、日付時間場所情報を検索キーにして空き情報ファイル１４を検索し、該当レコードを抽出する。

次に、コンテンツ表示プログラムは、ユーザーＩＤに従って履歴情報ファイル１１を検索し、履歴情報があるかどうか判断する。履歴情報がある場合即ち履歴情報ファイル１１に少なくとも一つのレコードがある場合、各ジャンルポイントフィールドの値を順次読み込み、各ジャンルポイントフィールド毎に集計して合計のポイントを算出する。そして、最もポイントが高いジャンルポイントフィールドのジャンルＩＤを取得する。この際、最も値が高いジャンルポイントフィールドが複数あれば、乱数等を適宜使用してランダムに順位を決定する。以下、この最もポイントが高いジャンルポイントフィールドのジャンルを、最高ポイントジャンルと呼ぶ。履歴情報記録モジュールは、このサイトでのサービス購入の確定のたびに実行され、その際に購入されたサービスのジャンル以外のジャンルについて１ポイントを記録するので、最高ポイントジャンルというのは、最も購入回数の少ないジャンル（購入無しも含む）ということになる。

コンテンツ表示プログラムは、空き情報ファイル１４から抽出した各レコードについて、ジャンルが最高ポイントジャンルであるかどうか判断し、そうであれば、表示する空き枠であるとして空き枠ＩＤをメモリ変数に格納する。この処理を、抽出されたすべてのレコードについて行う。そして、最高ポイントジャンルのレコードが五つ以上あれば、乱数等を使用してランダムに四つを選択し、それらの空き枠ＩＤを優先表示コンテンツとしてメモリ変数に格納する。ちょうど四つであれば、同様にそれらをメモリ変数に格納する。四つ未満であれば、次にポイントが高かったジャンルポイントフィールドを特定し、それを最高ポイントジャンルであるとして同様に抽出レコードの絞り込みをし、優先表示コンテンツとする空き枠ＩＤを不足数の分だけ特定する。

その後は、上記各実施形態と同様の処理となっており、抽出されたレコードのうち優先表示コンテンツとされなかった残りの全てのレコードについてランダムに表示順を決定し、優先表示コンテンツのアイコンを最初の画面内の所定位置に組み込みつつ、残りのレコードについて決定された表示順にしたがって各アイコンを組み込み、ユーザー端末８に送信して表示させる。

この第三の実施形態によれば、各ジャンルについてユーザーの過去の購入頻度が数値化され、購入回数がより少ないジャンルが優先表示コンテンツとなって表示されるので、ユーザーがサービス購入により新しい自分を発見したり、新しい分野や趣味に興味を持つきっかけをユーザーに与えるといった効果がより期待できる。

第三の実施形態において、サービス購入に達しないまでの途中の段階について履歴情報としてポイントを加算しても良い。例えば、多くのネットショッピングサイトでは、最終的な決済（購入）の前に「カートに入れる」というステップがあり、購入候補のアイテムとして情報を登録するステップがある。前述した各実施形態でも、説明は省略したが、決済プログラムは、そのように購入候補登録のステップを有している。この際、決済プログラムは、購入候補として登録された段階で履歴情報記録モジュールを起動するようプログラミングされる。そして、当該ユーザーの履歴情報ファイル１１において、購入候補とされた空き枠のサービスのジャンルについてのジャンルポイントフィールドに１を記録する。

また、ユーザーがコンテンツの詳細情報を見たことを捉えてジャンルポイントフィールドに１を記録してもよい。具体的には、特定のアイコンがタップされてコンテンツ表示プログラムが当該空き枠の詳細情報をユーザー端末８に送信した際、コンテンツ表示プログラムが履歴情報記録モジュールを呼び出して実行するようプログラミングされる。履歴情報記録モジュールは、当該ユーザーの履歴情報ファイル１１を開き、詳細情報を送信した空き枠のジャンルに相当するジャンルポイントフィールドに１を記録する。
尚、実際に購入したのと、購入候補に入れるとか詳細閲覧をしたとかいうのでは、履歴情報としての重みが違うので、その点を考慮してポイントを加算するとより好適である。例えば、詳細情報を見ただけでは１ポイント加算のみ、詳細情報を見て購入候補に入れた場合、さらに１ポイント加算（合計２ポイント）、購入確定させた場合にはさらに１ポイント加算（合計３ポイント）というようにする。このようにすると、過去の履歴に関連性のないジャンルを優先して表示するという処理がよりキメ細かく行えるようになり、新しい自分を発見したり、新しい分野や趣味に興味を持つきっかけをユーザーに与えるという効果がさらに高められる。

次に、第四の実施形態のサービス購入支援システムについて説明する。第四の実施形態の大きな特徴点は、日付時間帯場所情報を入力して空き枠を検索してコンテンツが表示された際、ヒットした空き枠の貴重性をユーザーが評価できるようにしている点である。

具体的に説明すると、図１４は、第四の実施形態における詳細画面の一例を示した概略図である。コンテンツ初期画面においてアイコン７１がタップされると、コンテンツ表示プログラムは、図１４（１）に示す詳細画面をユーザー端末８に表示させる。この際、コンテンツ表示プログラムは、「このお店の他の空き枠を見る」と表記されたボタン（以下、貴重性閲覧ボタン）７８を組み込んだ状態で詳細情報をユーザー端末８に表示させるようプログラミングされている。

配信サーバー１には貴重性閲覧モジュールが実装されており、貴重性閲覧ボタン７８には、貴重性閲覧モジュールの起動コマンドが埋め込まれている。図１４（２）には、貴重性閲覧モジュールの実行結果が示されている。起動コマンドは、詳細表示されている空き枠の空き枠ＩＤを引数にして貴重性閲覧モジュールを実行するものであり、貴重性閲覧ボタン７８は、空き枠ＩＤによって空き情報ファイル１４を検索して当該空き枠の店舗ＩＤを取得し、当該店舗ＩＤで空き情報ファイル１４を再検索する。この際、日付時間帯場所情報で特定される日付の例えば前後二週間（一週間前から一週間後）までの条件で検索し、この検索結果を、ユーザー端末８にリスト表示するようプログラミングされている。

図１４（２）に示すように、貴重性閲覧プログラムは、他の空き枠の日時、空き枠件数、貴重性ランクなどをユーザー端末８に表示するようプログラミングされている。貴重性ランクは、空き枠件数に従って予め定められた基準で決定される。例えば他の空き枠の件数が１件以下であればＡランク、２件〜４件であればＢランク、５件以上であればＣランクとされる。

この第四の実施形態によれば、ユーザーは、自分が入力した日付時間帯場所情報でヒットした空き枠が、偶然にヒットしたのか、それとも登録されている空き枠の件数が多くてヒットしたのかを評価（貴重性の評価）をすることができる。空き枠の件数が少なければ、ユーザーはこのお店が人気店であると考え、それならばこの空き枠のサービスを購入してみようかと思うことも考えられ、サービス購入の検討がし易くなる。尚、他の空き枠のリストの各行に、その日付時間帯で購入（予約）をしたりオークション参加をしたりするためのボタンを設けても良い。

また、上述した貴重性の概念は、コンテンツの表示順に利用しても良い。具体的には、貴重性の高いサービス（他の空き枠の数が少ないサービス）ほど優先表示されるようコンテンツ表示プログラムがプログラミングされる。優先表示とは、上述した論理否定ジャンルのものとして表示されるコンテンツの中での優先表示と、論理否定ジャンルとは無関係にランダムに表示順が決められる際の優先表示とがある。前者の場合、論理否定ジャンルとして抽出された空き枠について、上記のように他の空き枠の数が参照される。そして、ユーザー端末８の画面の一番上において、他の空き枠の数が少ない順に左からアイコンが並べられる。論理否定ジャンルとは無関係に表示順が決定される残りの領域については、他の空き枠の数の少ない順に表示する。他の空き枠の数が同じである空き枠については、ランダムに順番を決定する。尚、表示順は、他の空き枠の数が少ない空き枠ほど、画面の原点位置（左上の端の位置）に近い位置となる順である。

このようにすると、他の空き枠が少ないサービスのコンテンツほどユーザーが視認し易くなる。このため、そのサービスのアイコンがタップされて詳細表示され、そのサービスが購入される可能性が高まる。ユーザーにとっては、たまたまその空き時間に空き枠があった幸運なサービスについてより購入の可能性が高まるので、その点で便利である。優先表示がされない場合、ユーザーは自分で画面をスクロールしながら貴重性の高いサービス（他の空き枠の少ないサービス）を探さなければならないが、上記の構成ではそのような不便はない。
尚、貴重性についての表示は、図１４に示す例以外にも各種のものがある。例えば、図３（１）に示すコンテンツ初期画面において貴重性が高いものと低いものとで表示の色を変え、高いものについて赤色のような目につき易い色で表示する例が挙げられる。

次に、第五の実施形態について説明する。図１５は、第五の実施形態におけるコンテンツ初期画面の一例を示した概略図である。第五の実施形態の大きな特徴点は、図１５に示すように、日付時間帯場所情報を配信サーバー１に送信することでコンテンツがユーザー端末８２に表示された際、当該ユーザーの友人又は知人の推薦情報が併せて表示されるようになっている点である。尚、「知人」は広い意味であり、親兄弟のような親類や教師等を含む。

具体的に説明すると、図１５に示すように、あるコンテンツのアイコン７１は、「推薦者あり（２）」というように推薦している友人又は知人の人数を表人する部分７１１が組み込まれて表示されるようになっている。これを実現するため、管理サーバー４の記憶部１０には、各ユーザーの推薦人の情報を記録した推薦人情報ファイル（不図示）が記憶されている。推薦人情報ファイルは、ユーザー毎に作成されており、図示は省略するが、「推薦人ＩＤ」、「推薦人ニックネーム」、「登録日時」、「承認フラグ」等のフィールドから成るデータベースファイルである。

管理サーバー４には、推薦人登録プログラムが実装されている。また、サービス購入アプリには、設定メニューとして推薦人情報送信プログラムが含まれている。サービス購入アプリの設定メニューには推薦人登録ボタンが含まれており、推薦人登録ボタンがタップされると、推薦人登録をする友人又は知人の携帯電話番号又はメールアドレスを入力する画面が表示される。ここで携帯電話番号又はメールアドレスが入力されると、推薦人情報送信プログラムが起動し、入力された情報を管理サーバー４に送信し、推薦人登録プログラムが実行されるようになっている。

この実施形態では、推薦人は、ユーザーと同様にサービス購入アプリをユーザー端末８上にダウンロードしていることが前提になっている。推薦人登録プログラムは、送信された携帯電話番号又はメールアドレスを検索キーにして管理サーバー４上のユーザー情報ファイル１２を検索し、該当レコードがなければ、「入力された方は本アプリをダウンロードしていません。本アプリをダウンロードしてもらうようお願い下さい。」というようなエラーメッセージを表示して終了する。該当レコードがあれば、当該レコードから「ユーザーＩＤ」及び「ニックネーム」の各フィールドの値を取得する。そして、推薦人情報を送信してきたユーザー端末８のユーザーについて作成されている推薦人情報ファイル（無ければ新たに作成する）にレコードを追加し、新たに推薦人ＩＤを生成して記録するとともに、取得されたユーザーＩＤとニックネームを「推薦人ＩＤ」及び「推薦人ニックネーム」の各フィールドに記録する。また、記録した時点の日時を「登録日時」のフィールドに記録する。

上記推薦人情報ファイルへの記録は仮登録であり、推薦人登録プログラムは、当該推薦人のユーザーのメールアドレスをユーザー情報ファイル１２から取得し、推薦人登録を承認するかどうかのメールを送る。メールには、承認する際にはタップして欲しい旨を表記したＵＲＬが記載されており、当該ＵＲＬは、管理サーバー４に実装されている登録承認プログラムの起動コマンドとなっている。登録承認プログラムは、当該ユーザーが推薦人となっている推薦人情報ファイルの「承認フラグ」のフィールドに承認ありの旨の入力をする。管理サーバー４には、「登録日時」の値から一定期間後の時点で「承認フラグ」の値をチェックし、承認有りになっていなければ当該レコードを削除する。

また、管理サーバー４の記憶部１０には、各ユーザーについて当該ユーザーに対する推薦情報を記録した推薦情報ファイル（不図示）が記憶されており、管理サーバー４には推薦情報登録プログラムが実装されている。推薦情報ファイルは、「推薦人ＩＤ」、「推薦対象サービスＩＤ」、「コメント」等のフィールドから成るデータベースファイルである。「コメント」はテキストデータのフィールドである。そして、図示は省略するが、ユーザー端末８に表示される詳細画面には、「特定の友人又は知人にこのサービスを推薦する」と表記されたコマンドボタン（以下、推薦送信ボタン）が設けられている。推薦送信ボタンがタップされると、そのユーザーを推薦人として登録している他のユーザーのニックネームのリストが表示されるようになっており、そこから一人を選んで送信ボタンをタップすると、推薦情報登録プログラムが実行される。

推薦情報登録プログラムは、詳細画面に表示されている空き枠の空き枠ＩＤ、ユーザーＩＤ（推薦をする人のユーザーＩＤ）、推薦対象のユーザーＩＤを送信させ、推薦対象のユーザーＩＤについて作成されている（無ければ新たに作成する）推薦情報ファイルに新しくレコードを追加して各情報を記録するようプログラミングされている。この際、コメント入力欄がユーザー端末８に表示され、そこで入力されたコメントが推薦情報ファイルの「コメント」のフィールドに記録されるようになっている。

一方、コンテンツ表示プログラムは、ユーザー端末８からユーザーＩＤ及び日付時間帯場所情報が送信されて日付時間帯場所情報で空き情報ファイル１４を検索して空き枠の抽出を行った際、当該ユーザーについて推薦情報ファイルが作成されていれば、ファイルを開く。そして、抽出された各空き枠のレコードからサービスＩＤを取得し、サービスＩＤで推薦情報ファイルを検索し、ヒットした件数を取得する。そして、コンテンツ表示プログラムは、ジャンルが論理否定ジャンルとなっている空き枠（第一の実施形態の場合）又は優先表示コンテンツとされた空き枠（第四の実施形態の場合）について、ヒットした件数の情報を、図１５に示すように、当該空き枠のサービスを表示するアイコンに組み込み、ユーザー端末８に送信して他のアイコンと同様に表示させる。

また、推薦人の情報が組み込まれているアイコンがタップされた場合に表示される詳細画面には、「推薦の詳細情報を見る」と表記されたボタン（推薦詳細閲覧ボタン）が設けられている。推薦詳細閲覧ボタンには、管理サーバー４上の推薦詳細情報表示プログラムの起動コマンドが埋め込まれている。推薦詳細情報表示プログラムがタップされると、推薦している人のニックネームやコメントがユーザー端末８に表示されるよう推薦詳細情報表示プログラムがプログラミングされている。

この第五の実施形態によれば、日付時間帯場所情報を送信してマッチする各空き枠のコンテンツが表示された際、友人又は知人が推薦しているサービスの空き枠であるかどうかがユーザーにおいて視認されるので、サービス購入の動機付けになり、従ってサービス購入の促進につながる。特に、論理否定ジャンルの空き枠や優先表示コンテンツの空き枠は、過去に購入履歴が無いか購入履歴がより少ないジャンルであるため、ユーザーにとってはなじみが無い（又は全く無い）場合が多い。従って、友人や知人の推薦は非常に貴重であり、「○○君が推薦しているなら」と、全く経験したことのないサービスの提供を受けてみようという気になる可能性が高い。このため、店舗側にとっては、このサイト経由でのサービスの売り上げ促進につながる。

上記の例では、推薦は特定のサービス（特定のサービス事業者によって提供される特定のサービス）であったが、ジャンルを推薦するようにしても良い。具体的には、上記のようにある者が推薦送信ボタンをタップして推薦を行った場合、当該サービスＩＤのサービスのみならず、同じジャンルに属する他のサービスについても推薦有りとする。
尚、推薦人による推薦がより多くされるようにするため、推薦をした者に対し何らかの特典が付与されると好適である。例えば、推薦送信ボタンをタップして推薦情報を送信して推薦情報ファイルに登録した場合、そのユーザーに対してこのサイト経由での次回のサービス購入の際に料金を割り引くポイントを付与するようにすることが考えられる。ポイントは、ユーザー情報ファイル１２に記録され、決済プログラムによって参照されて利用される。
また、上記の例では、論理否定ジャンルの空き枠や優先表示コンテンツの空き枠についてのみ推薦情報が表示されたが、それ以外の空き枠についても同様に表示するようにしても良い。

次に、第六の実施形態について説明する。第六の実施形態では、店舗側が利用できるメニューとして有益なメニューが追加されている。即ち、第六の実施形態では、あるユーザーが日付時間帯場所情報をサーバーに送信した記録を店舗側が閲覧できるようになっており、それに対応してサービス提供のオファーをサーバーに対して送信できるようになっている。

より具体的に説明すると、図１６は、第六の実施形態において、コンテンツ表示プログラムがコンテンツをユーザー端末８に表示させる際にユーザー端末８に表示される通知承認画面の一例を示した概略図である。通知承認画面は、あるユーザー端末８から日付時間帯場所情報が入力されてコンテンツサーバーに送信された際、その情報を店舗側に通知することの承認を求める画面である。図１６に示すように、通知承認画面は、当該ユーザーが当該日時（日付時間帯情報で特定される日付と時間帯）に当該場所（場所情報で特定される場所）で時間が空いている（暇である）ことを店舗側に通知することの承認を求めるものであり、承認する場合にタップされる承認ボタン７９が設けられている。店舗側に通知されるのは、ユーザー情報ファイル１２に記録されている情報のうち、年齢と性別のみである。

管理サーバー４には、ユーザー空き枠登録プログラムが実装されており、承認ボタン７９には、ユーザー空き枠登録プログラムの起動コマンドが埋め込まれている。管理サーバー４の記憶部１０には、すべてのユーザーの空き情報を記録したユーザー空き情報ファイル（不図示）が記憶されている。ユーザー空き情報ファイルは、「ユーザーＩＤ」、「場所情報」、「日付情報」、「時間帯情報１」、「時間帯情報２」等のフィールドから成るデータベースファイルである。「時間帯情報１」には空き時間の始まり、「時間帯情報２」には空き時間の終わりのフィールドである。ユーザー空き枠登録プログラムは、ユーザー空き情報ファイルにおいて新しくレコードを追加し、ログインの際に保持したユーザーＩＤと、コンテンツサーバーに対して送信した場所情報と日付時間帯情報とを対応するフィールドに記録するようプログラミングされている。

一方、図１７は、第六の実施形態において店舗ＩＤでログインした際に最初に表示される事業者向け初期画面の一例を示した概略図である。図１７に示すように、事業者向け初期画面には、「ユーザー空き情報を見る」と表記されたコマンドボタン（以下、ユーザー空き情報閲覧ボタン）９７が設けられている。配信サーバー１には、ユーザー空き情報ファイルの内容を店舗側に閲覧させるユーザー空き情報閲覧プログラムが実装されており、ユーザー空き情報閲覧ボタン９７にはその起動コマンドが埋め込まれている。

ユーザー空き情報閲覧プログラムは、まず、ユーザー空き情報ファイルを検索する条件として、日付と時間の情報を入力させる画面を店舗端末９に表示させる。通常、カレンダーコントロールで日付を指定させ、時間帯をプルダウン等により指定させる。日付は、一週間単位のように複数の日数にまたがって指定させる場合もある。

ユーザー空き情報閲覧プログラムは、指定させた日付と時間帯の各情報を検索キーにしてユーザー空き情報ファイルを検索する。この際、ログインの際に保持した店舗ＩＤにより店舗情報ファイルを検索し、当該店舗の場所情報を取得する。そして、ユーザー空き情報ファイルに登録されている場所情報と当該店舗の場所情報とを比較して二つの場所の距離が一定範囲内であり、日付と時間帯の各情報が、ユーザー空き情報ファイルに登録されている情報と重なるレコードを全て抽出する。そして、抽出した各レコードについて、ユーザーＩＤにより「年齢」及び「性別」の各情報をユーザー情報ファイル１２から取得し、店舗端末９に返信して表示させる。

図１８は、店舗端末９に表示されたユーザー空き情報の一例を示す概略図である。図１８に示すように、店舗端末９では、当該店舗の周辺の場所で特定の日時の特定の時間帯に空いている（即ち、暇である）と申告してきたユーザーの年齢と性別がリスト表示されるようになっている。そして、リストの各行には、「オファーする」と表記されたボタン（オファーボタン）９８が設けられている。管理サーバー４には、オファープログラムが実装されており、オファーボタン９８によって起動するようになっている。

管理サーバー４の記憶部１０には、オファー情報ファイル（不図示）が記憶されている。オファー情報ファイルは、「オファーＩＤ」、「店舗ＩＤ」、「ユーザー空き枠ＩＤ」、「オファー金額」等のフィールドから成るデータベースファイルである。図示は省略するが、オファープログラムは、オファー金額を入力する欄を店舗端末９に表示し、金額が入力されて送信ボタンがタップされると、オファーＩＤを生成するとともにオファー情報ファイルにレコードを追加するようプログラミングされている。そして、オファープログラムは、オファーＩＤ，店舗ＩＤ，オファー金額を各フィールドに記録してファイルを更新する。

その後、オファープログラムは、ユーザー空き枠ＩＤに従ってユーザー空き情報ファイルを検索してユーザーＩＤを取得し、ユーザーＩＤに従ってユーザー情報ファイル１２を検索して当該ユーザーのメールアドレスを取得する。そして、ある店舗からオファーが届いている旨のメールを生成して自動的に送信する。図１９は、オファープログラムにより送信されたメール（オファーメール）の一例を示した概略図である。

図１９に示すように、オファーメールには、オファーの内容とともに、「店舗、サービスの詳細を見る」と表記されたボタン（以下、詳細ボタン）７０１が設けられている。詳細ボタン７０１は、図３（２）に示す詳細画面と同様の画面を表示するプログラムの起動コマンドが埋め込まれている。詳細画面には、購入手続きに進むためのボタンも含まれており、このボタンをタップすることで購入できるようになっている。

この実施形態によれば、特定の日付の特定の時間帯に特定の場所で空いている（暇である）というユーザーの申告を店舗側が閲覧でき、金額のオファーという形で能動的に対応することが可能であるので、店舗側にとっては予約無しで空いている時間帯（在庫）の処分をより積極的に行うことが可能になる。ユーザーとしても、自分が空いていると申告するだけであり、オファーが届いたらその内容を吟味すれば良いので、特に予定がなく何をするという目的もない場合に利用し易いものになる。

上記第六の実施形態において、ユーザー空き枠の登録は、コンテンツ表示プログラムによるコンテンツの表示（各空き枠のアイコンの表示）に際して行われたが、コンテンツの表示とは無関係に行っても良い。即ち、サービス購入アプリのメニューとして、ユーザー空き枠登録というメニューを設け、ここでは、日付時間帯場所情報を単に送信するだけであり、送信が行われると、ユーザー空き情報ファイルに記録されるだけで特にコンテンツは表示されないようにしても良い。

上記各実施形態において、日付時間帯場所情報のうちの場所情報については、予め登録されている情報をそのまま使用する構成もあり得る。例えば、サービス購入アプリの初期登録の際、最寄り駅とか自宅住所のうちの丁目情報（番地を省いた何丁目までの住所情報）とかを登録してもらう。そして、図２（３）に示す場所入力画面においてＧＰＳボタンを設け、それがタップされた場合には登録されている最寄り駅とか丁目情報とかを場所情報として配信サーバー１に送信するようにしても良い。尚、丁目情報ではなくて住所そのものを場所情報として使用する場合もある。

また、以上の各実施形態において、空き情報サーバー２については、このシステムとは別のシステムのサーバーを兼用することがあり得る。即ち、予約を専ら行うサイトが別にあり、そこで空き枠の情報や予約情報が一元的に管理されている場合、空き枠の登録や予約情報の記録はそのサイトで行われている場合がある。サービス事業者がこのサイトを利用している場合、各実施形態のシステムは、このサイトのサーバーに遷移して空き枠の情報を取得したり、予約情報の記録を行ったりするよう構成され得る。

１ 配信サーバー
１０ 記憶部
１１ 履歴情報ファイル
１２ ユーザー情報ファイル
２ 空き情報サーバー
３ オークションサーバー
４ 管理サーバー
５ 共有化サーバー
８ ユーザー端末
９ 店舗端末

Claims (11)

1. ユーザー端末からのアクセスをネットワークを介して受け付けるサーバーを含む一又は複数のサーバーと、
   各サービス事業者によって提供される各サービスに関する情報を記憶した記憶部と
   を備えており、
   いずれかのサーバーには、
   ユーザー端末から送信されたユーザー特定情報及び日付時間帯場所情報に従って多数のサービスを抽出し、抽出された各サービスのコンテンツを当該ユーザー端末に送信して当該ユーザー端末に表示させるコンテンツ表示プログラムと、
   コンテンツ表示プログラムによりユーザー端末にコンテンツが表示された後にいずれかのサービスが当該ユーザー端末により選択された際、当該サービスの購入のための情報をユーザー端末から受信する購入用プログラムとが実装されており、
   記憶部には、各サービスの情報を記録したサービス情報ファイルと、特定のサービスが特定の日時及び時間帯に提供可能である旨の空き枠の情報を記録した空き情報ファイルと、各ユーザーの過去のサービスの購入に関する履歴情報が記録された履歴情報ファイルとが記憶されており、
   サービス情報ファイルに記録されたサービス情報は、各サービスを提供するサービス事業者、各サービスが提供される場所、各サービスの提供に要する時間、各サービスの対価の情報を含んでおり、
   前記日付時間帯場所情報は、特定の日付の特定の時間帯の情報と特定の場所とを含む情報であり、
   前記コンテンツ表示プログラムは、送信された日付時間帯場所情報に従って空き情報ファイルを検索し、前記日付時間帯場所情報に含まれる場所の情報に従って当該場所付近で提供可能であって前記日付時間帯場所情報に含まれる日付時間帯と前記空き枠の日付及び時間帯とが重なっているサービスを多数抽出し、抽出された各サービスのサービス情報をサービス情報ファイルから取得してユーザー端末に送信してコンテンツとして表示させるものであり、
   前記コンテンツ表示プログラムは、各サービスのコンテンツをジャンル分けせずにランダムにユーザー端末に表示させるものであって、表示される各サービスのコンテンツは、前記購入用プログラムを起動させるためのボタンを含んでおり、
   前記コンテンツ表示プログラムは、前記抽出された各サービスのコンテンツを送信する際、送信されたユーザー特定情報に従って特定されるユーザーについて前記履歴情報ファイルを参照して前記履歴情報との関連性が最も低いジャンルを特定し、特定されたジャンルのサービスを含んだ状態で前記各サービスのコンテンツをユーザー端末に送信するものであり、
   前記コンテンツ表示プログラムは、前記履歴情報との関連性が最も低いとされたジャンルのサービスのコンテンツを、ユーザー端末に初期表示される画面内にレイアウトするものであることを特徴とするサービス購入支援システム。
2. 入札情報ファイルを記憶した記憶部を備えており、
   前記コンテンツ表示プログラムは、前記多数のサービスのコンテンツが前記ユーザー端末に表示された後に特定のサービスが選択された際、当該サービスの購入についてユーザーが入札価格を入力して前記サーバーに送信するための画面をユーザー端末に表示することが可能であり、
   いずれかの前記サーバーには、入札価格を含む入札情報が送信された際、当該入札情報を入札情報ファイルに記録するとともに、落札がされた際に当該落札の対象となった入札情報を送信したユーザー端末に落札の旨を返信する入札管理プログラムが実装されていることを特徴とする請求項１記載のサービス購入支援システム。
3. 前記記憶部には、前記ユーザー端末を操作するユーザーを含むメンバーの情報を記録したユーザーグループ情報ファイルが記憶されており、ユーザーグループ情報ファイルに記録されている情報は、各メンバーが操作する端末情報を含んでおり、
   前記サービスは、複数人に対して同時に提供され得るものであり、
   いずれかの前記サーバーには、前記多数のサービスのコンテンツが前記コンテンツ表示プログラムにより表示された後に特定のサービスが選択された際、ユーザーグループ情報ファイルに記録された情報に従い、当該サービスの情報を当該ユーザー端末を操作するユーザー以外のメンバーの端末に送信する共有化プログラムが実装されていることを特徴とする請求項１又は２記載のサービス購入支援システム。
4. 前記サービスは、複数人に対して同時に提供され得るものであり、
   前記空き情報ファイルには、同時に提供可能な人数の情報である提供人数とともに前記空き枠の情報が記録されたファイルであり、
   前記コンテンツ表示プログラムは、前記日付時間帯場所情報に加え、同時に提供されることを望む人数の情報である希望人数がユーザー端末から送信された際に実行されるものであって、前記日付時間帯と前記空き枠の日付及び時間帯とが重なっているとともに提供人数と希望人数とが重なっているサービスを多数抽出し、抽出した各サービスのコンテンツを前記ユーザー端末に送信するプログラムであることを特徴とする請求項１乃至３いずれかに記載のサービス購入支援システム。
5. 前記履歴情報は、各ユーザーのジャンル毎の購入回数に応じた数値で記録されており、
   前記コンテンツ表示プログラムは、購入回数の最も少ないジャンルを前記関連性が最も低いジャンルであるとするプログラムであることを特徴とする請求項１乃至４いずれかに記載のサービス購入支援システム。
6. 前記履歴情報には、前記購入回数に加え、各ユーザーが購入候補とした履歴が含まれており、
   前記購入用プログラムは、前記コンテンツ表示プログラムで表示された多数サービスのコンテンツの中から選択されたサービスについて購入の決済をする決済プログラムであり、
   決済プログラムは、選択されたサービスについて決済前の段階で購入の候補とするプログラムであって、購入の候補とされたサービスについて履歴情報として履歴情報ファイルに記録するプログラムであり、
   前記コンテンツ表示プログラムは、前記購入回数に応じた数値に加え、購入の候補とした回数に応じた数値を加算した上で、数値が最も小さいジャンルを前記関連性が最も低いジャンルとするプログラムであることを特徴とする請求項５記載のサービス購入支援システム。
7. 前記コンテンツ表示プログラムは、前記ユーザー端末での選択に従い、選択されたサービスの詳細情報を当該ユーザー端末に表示させることが可能であり、
   前記履歴情報には、前記購入回数に加え、前記ユーザー端末において詳細情報が表示された履歴が含まれており、
   前記コンテンツ表示プログラムは、前記購入回数に応じた数値に加え、詳細情報が表示された回数に応じた数値を加算した上で、数値が最も小さいジャンルを前記関連性が最も低いジャンルとするプログラムであることを特徴とする請求項５又は６記載のサービス購入支援システム。
8. いずれかの前記サーバーには貴重性閲覧プログラムが実装されており、
   貴重性閲覧プログラムは、前記多数のサービスのコンテンツが前記コンテンツ表示プログラムにより表示された後に特定のサービスが選択された際、当該サービスの前記重なっている空き枠以外の空き枠の情報を当該ユーザー端末に送信して表示させるプログラムであることを特徴とする請求項１乃至７いずれかに記載のサービス購入支援システム。
9. 前記コンテンツ表示プログラムは、前記日付時間帯場所情報に含まれる場所の情報に従って当該場所付近で提供可能であって前記日付時間帯場所情報に含まれる日付時間帯と前記空き枠の日付及び時間帯とが重なっているサービスを多数抽出した際、抽出された各サービスについて、当該日付時間帯と重なってはいない他の日付時間帯の空き枠として前記空き枠情報ファイルに記録されている空き枠の数を算出し、算出された数の少ないサービスを優先表示サービスとするプログラムであって、優先表示サービスのコンテンツを他のサービスのコンテンツに比べてユーザー端末の画面内の左上に近い位置にレイアウトするプログラムであることを特徴とする請求項１乃至８いずれかに記載のサービス購入支援システム。
10. 前記記憶部には、特定のユーザーに対して当該ユーザーの友人又は知人が特定のサービス又は特定のジャンルのサービスの購入を推薦する旨の情報を記録した推薦情報ファイルが記憶されており、
    前記コンテンツ表示プログラムは、前記各サービスのコンテンツを前記ユーザー端末に送信する際、前記履歴情報との関連性が最も低いジャンルと特定されたジャンルのサービスについて推薦情報ファイルに記録がある場合、当該推薦の情報を含んだ状態で当該サービスのコンテンツが表示されるようにするプログラムであることを特徴とする請求項１乃至９いずれかに記載のサービス購入支援システム。
11. 前記記憶部には、各ユーザー端末を操作する各ユーザーの個人情報を記録したユーザー情報ファイルと、ユーザー空き情報ファイルとが記憶されており、
    各ユーザーの個人情報には、各ユーザーの年齢及び性別が含まれており、
    ユーザー空き情報ファイルは、前記ユーザー端末から送信された日付時間帯場所情報を記録したファイルであり、
    いずれかの前記サーバーは、前記サービス事業者が操作する事業者端末からのネットワークを介したアクセスを受け付けることが可能であって、このサーバーには、前記サービス事業者にユーザー空き情報ファイルの内容を閲覧させるユーザー空き情報閲覧プログラムと、ユーザーに対するサービス購入のオファーを前記サービス事業者に行わせるオファープログラムが実装されており、
    特定の事業者端末から前記サーバーにアクセスがあった際、ユーザー空き情報閲覧プログラムは、ユーザー空き情報ファイルに記録された日付時間帯場所情報で特定される場所が、当該事業者端末を操作するサービス事業者によるサービス提供場所付近である場合、当該日付時間帯場所情報に含まれる日付時間帯の情報を事業者端末に送信して表示させるとともに、当該日付時間帯場所情報を送信したユーザーの年齢及び性別をユーザー情報ファイルから取得して事業者端末に送信して表示させるプログラムであり、
    オファープログラムは、事業者端末に表示された日付時間帯場所情報を送信したユーザーに対するサービスの提供価格を事業者端末において入力させて前記サーバーに送信させるプログラムであって、送信された提供価格を、当該日付時間帯場所情報を送信したユーザーのユーザー端末に転送するプログラムであることを特徴とする請求項１乃至１０いずれかに記載のサービス購入支援システム。

Images