JP2014126958A - 座席管理システム、座席管理システムの制御方法、及びプログラム - Google Patents

Abstract

【課題】同伴者が確定していなくてもユーザが自らの席を確保するだけで、その後に同伴者が確定した場合にはユーザの席に隣接する席を同伴者の席として確保でき、その購入手続き等も容易にすることが可能な座席管理システムを提供すること。
【解決手段】関係ユーザ特定部７６は、座席が割り当てられたユーザ（割当済みユーザ）と所定の関係を有するユーザ（関係ユーザ）を特定する。制限対象選出部７８は、割当済みユーザに割り当てられた座席に隣接し、かつ、いずれのユーザにも割り当てられていない座席又は座席群を制限対象として選出する。割当制限部８０は、制限対象として選出された座席又は座席群を関係ユーザ以外のユーザに割り当てることを所定の制限期間にわたって制限する。第２割当部８２は、関係ユーザから申し込みが受け付けられた場合に、制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を当該関係ユーザに割り当てる。
【選択図】図１２

Description

本発明は座席管理システム、座席管理システムの制御方法、及びプログラムに関する。

ユーザがコンサートやスポーツの試合等に行く場合、友人等と同伴を想定している場合が多い。そして、そのユーザは同伴者の隣の席を確保することを望む。ところが、座席を予約する時点、即ちチケットを購入する時点で必ずしも同伴者の有無や同伴する友人等が確定できていない場合がある。このような場合、従来、ユーザは同伴者が確定した後に自分及び同伴者のチケットをまとめて購入していた。あるいは、ユーザは自分及び同伴者のチケットを予め購入した後に同伴者を探していた。

特開２００５−８４８６７号公報

しかしながら、同伴者が確定した後にユーザ自身及び同伴者のチケットをまとめて購入する場合には、同伴者を確定するのに時間がかかってしまうと、チケットが売り切れてしまい、チケットを購入し損ねてしまう場合があった。また、ユーザ自身及び同伴者のチケットを予め購入した後に同伴者を探す場合には、同伴者が見つからなかった場合にチケットが無駄になってしまう場合があった。また、いずれの場合もユーザ自身がチケットを購入をする必要があり、その手続きが厄介になるばかりでなく、費用負担も大きくなりがちであった。

一方、購入前に所謂仮予約の状態で座席を確保することも知られているが、これらのイベントは座席の埋まり具合によらず定められたスケジュールで開催しなければならず、イベントの開催者としては、不必要に仮予約の状態を長く保持することはできない。また、仮予約についてもユーザが行うことに変わりはなく、ユーザ自身の負担を軽減することはできない。

なお、コンサートやスポーツの試合等のみならず、飛行機や電車等の指定席についても同様な事情がある。

本発明は上記課題に鑑みてなされたものであって、その目的は、同伴者が確定していなくてもユーザが自らの席を確保するだけで、その後に同伴者が確定した場合にはユーザの席に隣接する席を同伴者の席として確保することができ、その購入等の手続きも容易にすることが可能な座席管理システム、座席管理システムの制御方法、及びプログラムを提供することにある。

上記課題を解決するために、本発明に係る座席管理システムは、会場の座席を管理する座席管理システムにおいて、座席の申し込みをユーザから受け付ける受付手段と、前記ユーザから前記申し込みが受け付けられた場合に当該ユーザに座席を割り当てる第１割当手段と、ユーザ同士の関係を示す関係データを記憶する関係データ記憶手段の記憶内容に基づいて、前記座席が割り当てられたユーザ（以下「割当済みユーザ」と記載する。）と所定の関係を有するユーザ（以下「関係ユーザ」と記載する。）を特定する関係ユーザ特定手段と、座席同士の隣接状態を示す隣接状態データと、座席がいずれかのユーザに割り当てられているか否かを示す割当状態データと、に基づいて、前記割当済みユーザに割り当てられた座席に隣接し、かつ、いずれのユーザにも割り当てられていない座席又は座席群を制限対象として選出する制限対象選出手段と、前記制限対象として選出された座席又は座席群を前記関係ユーザ以外のユーザに割り当てることを所定の制限期間にわたって制限する割当制限手段と、前記関係ユーザから前記申し込みが受け付けられた場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を当該関係ユーザに割り当てる第２割当手段と、を含むことを特徴とする。

また、本発明に係る座席管理システムの制御方法は、会場の座席を管理する座席管理システムの制御方法において、座席の申し込みをユーザから受け付ける受付ステップと、前記ユーザから前記申し込みが受け付けられた場合に当該ユーザに座席を割り当てる第１割当ステップと、ユーザ同士の関係を示す関係データを記憶する関係データ記憶手段の記憶内容に基づいて、前記座席が割り当てられたユーザ（以下「割当済みユーザ」と記載する。）と所定の関係を有するユーザ（以下「関係ユーザ」と記載する。）を特定する関係ユーザ特定ステップと、座席同士の隣接状態を示す隣接状態データと、座席がいずれかのユーザに割り当てられているか否かを示す割当状態データと、に基づいて、前記割当済みユーザに割り当てられた座席に隣接し、かつ、いずれのユーザにも割り当てられていない座席又は座席群を制限対象として選出する制限対象選出ステップと、前記制限対象として選出された座席又は座席群を前記関係ユーザ以外のユーザに割り当てることを所定の制限期間にわたって制限する割当制限ステップと、前記関係ユーザから前記申し込みが受け付けられた場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を当該関係ユーザに割り当てる第２割当ステップと、を含むことを特徴とする。

また、本発明に係るプログラムは、座席の申し込みをユーザから受け付ける受付手段、前記ユーザから前記申し込みが受け付けられた場合に当該ユーザに座席を割り当てる第１割当手段、ユーザ同士の関係を示す関係データを記憶する関係データ記憶手段の記憶内容に基づいて、前記座席が割り当てられたユーザ（以下「割当済みユーザ」と記載する。）と所定の関係を有するユーザ（以下「関係ユーザ」と記載する。）を特定する関係ユーザ特定手段と、座席同士の隣接状態を示す隣接状態データと、座席がいずれかのユーザに割り当てられているか否かを示す割当状態データと、に基づいて、前記割当済みユーザに割り当てられた座席に隣接し、かつ、いずれのユーザにも割り当てられていない座席又は座席群を制限対象として選出する制限対象選出手段、前記制限対象として選出された座席又は座席群を前記関係ユーザ以外のユーザに割り当てることを所定の制限期間にわたって制限する割当制限手段、及び、前記関係ユーザから前記申し込みが受け付けられた場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を当該関係ユーザに割り当てる第２割当手段、としてコンピュータを機能させるためのプログラムである。

また、本発明に係る情報記憶媒体は、上記プログラムを記録したコンピュータ読み取り可能な情報記憶媒体である。

また、本発明の一態様では、前記関係ユーザを勧誘対象候補として選出する勧誘対象候補選出手段と、前記勧誘対象候補として選出された前記関係ユーザを前記割当済みユーザに提示する勧誘対象候補提示手段と、前記割当済みユーザに提示された前記関係ユーザが前記割当済みユーザによって勧誘対象として指定された場合に、前記勧誘対象として指定された前記関係ユーザに前記申し込みを勧誘する勧誘手段と、を含むようにしてもよい。

また、本発明の一態様では、前記勧誘対象候補選出手段は、ユーザの申し込み履歴を示す履歴データを記憶する履歴データ記憶手段の記憶内容に基づいて、前記関係ユーザを前記勧誘対象候補として選出するようにしてもよい。

また、本発明の一態様では、前記関係ユーザを勧誘対象として選出する勧誘対象選出手段と、前記勧誘対象として選出された前記関係ユーザに前記申し込みを勧誘する勧誘手段と、を含むようにしてもよい。

また、本発明の一態様では、前記勧誘対象選出手段は、ユーザの申し込み履歴を示す履歴データを記憶する履歴データ記憶手段の記憶内容に基づいて、前記関係ユーザを前記勧誘対象として選出するようにしてもよい。

また、本発明の一態様では、前記受付手段は、所望の座席の指定を前記ユーザから受け付ける手段を含み、前記座席管理システムは、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席が、前記所望の座席として、前記関係ユーザ以外のユーザによって指定された場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席に関する前記申し込みを行うか否かを前記割当済みユーザに問い合わせる手段と、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席に関する前記申し込みを行うことを前記割当済みユーザが選択した場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を前記割当済みユーザに割り当てる手段と、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席に関する前記申し込みを行うことを前記割当済みユーザが選択しなかった場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を前記関係ユーザ以外の前記ユーザに割り当てる手段と、を含むようにしてもよい。

また、本発明の一態様では、前記受付手段は、所望の座席の指定を前記ユーザから受け付ける手段を含み、前記座席管理システムは、前記関係ユーザから前記申し込みが受け付けられた場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を当該関係ユーザに提示する手段と、前記関係ユーザに提示された座席が当該関係ユーザによって前記所望の座席として指定された場合に、前記所望の座席として指定された座席を当該関係ユーザに割り当てる手段と、を含むようにしてもよい。

また、本発明の一態様では、前記制限期間が経過した場合に前記割当制限手段による制限を解除する手段を含むようにしてもよい。

また、本発明の一態様では、前記制限期間が経過するまでに前記関係ユーザから前記申し込みが受け付けられなかった場合に、前記割当済みユーザへの前記座席の割り当てを、当該割当済みユーザの要求に基づいて解除する手段を含むようにしてもよい。

また、本発明の一態様では、いずれのユーザにも割り当てられていない座席の数と、イベントの開催までの残り日数又は残り時間と、の少なくとも一方に基づいて、前記制限期間の長さを変更する手段を含むようにしてもよい。

本発明によれば、同伴者が確定していなくてもユーザが自らの席を確保するだけで、その後に同伴者が確定した場合にはユーザの席に隣接する席を同伴者の席として確保でき、ユーザ自身の席として確保するのではないことから、その購入手続をシステム側で同伴者に直接依頼することもできるため、購入等の手続も容易にすることが可能となる。

本発明の実施形態に係る座席管理システムの全体構成の一例を示す図である。 座席管理サーバのハードウェア構成の一例を示す図である。 購入画面の一例を示す図である。 座席指定画面の一例を示す図である。 完了画面の一例を示す図である。 座席指定画面の他の一例を示す図である。 ソーシャルネットワーキングサービスにおけるユーザテーブルの一例を示す図である。 チケット販売サービスにおけるユーザテーブルの一例を示す図である。 イベントテーブルの一例を示す図である。 座席テーブルの一例を示す図である。 履歴テーブルの一例を示す図である。 座席管理システムの機能ブロック図である。 座席管理システムで実行される処理の一例を示す図である。 座席管理システムで実行される処理の一例を示す図である。 座席管理システムで実行される処理について説明するための図である。 座席管理システムで実行される処理について説明するための図である。 座席管理システムで実行される処理について説明するための図である。 座席管理システムで実行される処理について説明するための図である。 完了画面の他の一例を示す図である。 座席指定画面の他の一例を示す図である。

以下、本発明の実施形態の例について図面に基づき詳細に説明する。

図１は、本発明の実施形態に係る座席管理システムの全体構成の一例を示す。図１に示す座席管理システム１はコンサート又はスポーツの試合等のイベントの座席を管理するためのシステムであり、イベントのチケット販売サービスを提供する。図１に示すように、座席管理システム１は座席管理サーバ１０及びデータベース１５を含む。

座席管理サーバ１０はイベントの座席の予約を申し込んできたユーザに座席を割り当て、当該ユーザに電子チケット又は紙媒体のチケットを発行する。図２は座席管理サーバ１０のハードウェア構成の一例を示す。図２に示すように、座席管理サーバ１０は制御部１１、記憶部１２、光ディスクドライブ部１３、及び通信部１４を含む。

制御部１１は例えば１又は複数のマイクロプロセッサを含み、記憶部１２に記憶されたオペレーティングシステム又はプログラムに従って処理を実行する。記憶部１２は主記憶部及び補助記憶部を含む。例えば、主記憶部はＲＡＭであり、補助記憶部はハードディスク又はソリッドステートドライブ等である。

光ディスクドライブ部１３は、光ディスク（情報記憶媒体）に記録されたプログラムやデータを読み出す。プログラムやデータは光ディスクを介して記憶部１２に供給される。なお、光ディスク以外の情報記憶媒体を介してプログラムやデータが記憶部１２に供給されるようにしてもよい。

通信部１４は通信ネットワーク２を介してデータ通信を行うためのものである。プログラム及びデータは通信ネットワーク２を介して記憶部１２に供給されるようにしてもよい。

座席管理サーバ１０はデータベース１５にアクセスすることが可能である。データベース１５は、座席管理サーバ１０とは別のサーバコンピュータに構築されていてもよいし、座席管理サーバ１０に構築されていてもよい。チケット販売サービスを提供するために必要なデータがデータベース１５に記憶される。詳細については後述する（図８〜１１参照）。

座席管理システム１は通信ネットワーク２を介してＳＮＳ（ソーシャルネットワーキングサービス）サーバ２０と相互にデータ通信を行うことが可能である。

ＳＮＳサーバ２０はソーシャルネットワーキングサービスを提供する。ソーシャルネットワーキングサービスはユーザ同士が交流を図るためのコミュニケーションサービスであり、例えば、Ｔｗｉｔｔｅｒ（登録商標）又はＦａｃｅｂｏｏｋ（登録商標）等である。ソーシャルネットワーキングサービスは、チケット販売サービスを提供する会社とは異なる会社によって提供されてもよいし、同じ会社によって提供されてもよい。なお。ＳＮＳサーバ２０のハードウェア構成は座席管理サーバ１０と同様である。

ＳＮＳサーバ２０はデータベース２５にアクセスすることが可能である。データベース２５は、ＳＮＳサーバ２０とは別のサーバコンピュータに構築されていてもよいし、ＳＮＳサーバ２０に構築されていてもよい。ソーシャルネットワーキングサービスを提供するために必要なデータがデータベース２５に記憶される。例えば、ソーシャルネットワーキングサービスを利用するユーザに関するデータや、ソーシャルネットワーキングサービスにおいて築かれたユーザ同士の関係（友人関係等）に関するデータ等がデータベース２５に記憶される。詳細については後述する（図７参照）。

また、座席管理システム１とＳＮＳサーバ２０とは連携可能になっている。具体的には、ユーザが許可した場合に、ソーシャルネットワーキングサービスにおけるユーザデータがＳＮＳサーバ２０から座席管理システム１に提供されるようになっている。例えば、ユーザと他のユーザとの関係（例えば友人関係等）に関するデータ等がＳＮＳサーバ２０から座席管理システム１に提供されるようになっている。

座席管理システム１とＳＮＳサーバ２０との間の上記のような連携を実現するための技術としては、例えばＯＡｕｔｈ等の技術や、ソーシャルネットワーキングサービス会社が提供する独自の技術が知られている。これらの技術を利用することによって上記のような連携が実現される。

なお、ここでは、ユーザと他のユーザとの関係（例えば友人関係等）に関するデータを座席管理システム１がＳＮＳサーバ２０から取得することとして説明するが、座席管理システム１は上記のようなデータをＳＮＳサービス以外のサービスから取得するようにしてもよい。または、座席管理システム１は上記のようなデータを他のサービスから取得するのではなく、座席管理システム１において上記のようなデータを生成するようにしてもよい。例えば、座席管理システム１は友人登録をユーザから受け付けることによって、友人関係に関するデータを生成するようにしてもよい。

座席管理システム１やＳＮＳサーバ２０は通信ネットワーク２を介してユーザ端末３と相互にデータ通信を行うことが可能である。ユーザ端末３はユーザによって使用される情報処理装置である。ユーザ端末３は、例えば携帯電話、携帯情報端末、又はパーソナルコンピュータ等である。

ここで、チケット販売サービスを利用する場合にユーザが行う手順について説明する。なお、ここでは、ユーザが既にソーシャルネットワーキングサービスを利用していて、ソーシャルネットワーキングサービスにおいて他のユーザと人間関係（友人関係等）を築いているとの前提の下で、上記の手順について説明する。

まず、ユーザはユーザ登録の手続きを行う。例えば、ユーザは、座席管理サーバ１０によって提供されるユーザ登録用のウェブページにアクセスし、自らの情報を登録する。

また、ＳＮＳサーバ２０から座席管理システム１へのユーザデータの提供を許可するための手続きをユーザは行う。この手続きが完了すると、座席管理システム１は、ソーシャルネットワーキングサービスにおけるユーザデータをＳＮＳサーバ２０から取得できるようになる。例えば、座席管理システム１は、ユーザと他のユーザとの関係（例えば友人関係等）に関するデータをＳＮＳサーバ２０から取得できるようになる。

チケットを購入したいユーザは座席管理サーバ１０にユーザ端末３からアクセスし、所望のチケットを選択する。所望のチケットが選択された場合、チケットを購入するための購入画面がユーザ端末３の表示部に表示される。

図３は購入画面の一例を示す。購入画面３０には、ユーザが選択したチケットに関する情報が表示される。また、購入画面３０には枚数欄３２及び購入ボタン３４が表示される。ユーザは枚数欄３２において枚数を指定し、購入ボタン３４をクリックする。購入ボタン３４がクリックされると、座席を指定するための座席指定画面がユーザ端末３の表示部に表示される。

図４は座席指定画面の一例を示す。座席指定画面４０には、会場における座席の配列を示す座席表４２が表示される。図４に示す例では座席が複数のブロック４４Ｌ，４４Ｃ，４４Ｒに分かれている。座席表４２に付されたアルファベット文字は座席の行（横列）を示し、数字は座席の列（縦列）を示す。各座席はアルファベット文字と数字との組み合わせによって示される。以下では、例えばＡ行１列の座席のことを座席Ａ１と記載する。

黒く塗られている座席は、既にユーザに割り当てられている座席（予約済みの座席）を示す。ユーザは、いずれのユーザにも割り当てられていない座席（空席）のうちから所望の座席を指定する。図４では、黒丸印が付されている座席がユーザによって指定された座席を示している。ユーザは所望の座席を指定した後、決定ボタン４６をクリックする。

決定ボタン４６がクリックされた場合には、イベントや座席の情報を最終確認するための確認画面（図示せず）が表示された後、座席の予約申し込みが座席管理サーバ１０に通知される。この場合、例えば、決済処理、ユーザに座席を割り当てる処理や、ユーザに電子チケットを発行する処理等が実行される。それらの処理が完了すると、完了画面がユーザ端末３の表示部に表示される。

図５は完了画面５０の一例を示す。完了画面５０には、ユーザが購入したチケットに関する情報が表示される。また、完了画面５０には表示ボタン５２及び印刷ボタン５４が表示される。

表示ボタン５２がクリックされた場合、チケットの識別情報（チケットＩＤ）を示すコード画像がユーザ端末３の表示部に表示される。この場合、ユーザ端末３がチケットとして機能することになる。イベント当日に会場に入場する際にユーザはユーザ端末３の表示部に表示されたコード画像を提示する。この場合、ユーザ端末３の表示部に表示されたコード画像を読み取ることによって、ユーザがイベントのチケットを購入した者であるか否かが確認される。

印刷ボタン５４がクリックされた場合、チケットの識別情報（チケットＩＤ）を示すコード画像が、ユーザ端末３と通信可能なプリンタから印刷される。この場合、コード画像が印刷された用紙がチケットとして機能することになる。イベント当日に会場に入場する際にユーザは用紙に印刷されたコード画像を提示する。この場合、用紙に印刷されたコード画像を読み取ることによって、ユーザがイベントのチケットを購入した者であるか否かが確認される。

なお、コード画像の表示又は印刷は、ユーザが購入したチケットの履歴を示す購入履歴画面（図示せず）からも行うことが可能である。

座席管理システム１では、ユーザが予約した座席に隣接する座席がユーザの同伴者のために一時的に確保されるようになっている。このため、ユーザが予約した座席Ａ９に隣接する座席Ａ８が同伴者用座席として一時的に確保されたことを示すメッセージ５６が完了画面５０に表示されている。

ユーザの友人は、同伴者用座席として確保された座席のチケットを優先的に購入することができる。一方、ユーザの友人以外のユーザは、同伴者用座席として確保された座席のチケットの購入することができない。ただし、同伴者用座席の確保には制限期間が設けられており、同伴者用座席の確保期間が経過した時点で同伴者用座席の確保は無効になる。なお、確保期間はチケットの購入日時に基づいて設定される。例えば、チケットの購入日時から所定時間後の日時が確保期間の終了日時として設定される。

例えば、ユーザはソーシャルネットワーキングサービス又は電子メール等を介してイベントに友人を誘う。イベントに同伴することに決めた友人は座席管理サーバ１０にアクセスし、ユーザから勧められたイベントのチケットを購入する。この場合のチケットの購入も購入画面３０及び座席指定画面４０等を介して行われる。

図６は、同伴者用座席が確保されている場合の座席指定画面４０の一例を示す。この場合の座席表４２では、既にユーザに割り当てられている座席と、同伴者用座席として一時的に確保されている座席と、空席と、が区別して表示される。なお図６では、斜線が付された座席が同伴者用座席として一時的に確保されている座席を示している。図６に示す例では、座席Ａ９の同伴者用座席として座席Ａ８が確保されている。この場合、座席Ａ９を予約しているユーザの友人のみが座席Ａ８を予約することができる。

ところで、以上では、一つの座席に対して一つの同伴者用座席が確保されることとして説明したが、同伴者用座席の数は複数であってもよい。なお、同伴者用座席の数は所定の数に固定するようにしてもよいし、チケット販売会社又は興行主がイベントごとに変更するようにしてもよい。あるいは、所定の上限数以下の範囲内でユーザが同伴者用座席の数を選択できるようにしてもよい。

以上に説明した座席管理システム１によれば、同伴者が確定していなくてもユーザは自らの席を確保することができる。また、後に同伴者が確定した場合にユーザの席に隣接する席を同伴者の席として確保できる。

以上のような座席管理システム１を実現するための構成について説明する。まず、データベース２５に記憶されるデータの一例について説明する。図７はデータベース２５に記憶されるデータの一例を示す。

図７はユーザテーブルの一例を示す。ユーザテーブルは、ソーシャルネットワーキングサービスを利用するユーザの一覧を示す。例えば、ユーザテーブルは「ユーザＩＤ」、「パスワード」、「氏名」、「メールアドレス」、及び「友人」フィールドを含む。実際には、これらのフィールド以外のフィールドもユーザテーブルに含まれるが、ここでは省略している。

「ユーザＩＤ」フィールドには、ソーシャルネットワーキングサービスを利用するユーザを一意に識別するための情報（ユーザＩＤ）が登録される。「パスワード」フィールドには、ユーザによって指定されたパスワードが登録される。「氏名」及び「メールアドレス」フィールドにはユーザの氏名及びメールアドレスが登録される。

「友人」フィールドには、ユーザと友人関係を有しているユーザのユーザＩＤのリストが登録される。なお、「友人」フィールドをユーザテーブルに設けるのではなく、友人関係を有するユーザの組み合わせを示すテーブルがユーザテーブルとは別にデータベース２５に記憶されるようにしてもよい。

データベース１５に記憶されるデータの一例について説明する。図８〜図１１はデータベース１５に記憶されるデータの一例を示す。

図８はユーザテーブルの一例を示す。ユーザテーブルは、チケット販売サービスを利用するユーザの一覧を示す。例えば、ユーザテーブルは「ユーザＩＤ」、「パスワード」、「氏名」、「メールアドレス」、「クレジットカード情報」、及び「ＳＮＳユーザＩＤ」フィールドを含む。実際には、これらのフィールド以外のフィールドもユーザテーブルに含まれるが、ここでは省略している。

「ユーザＩＤ」フィールドには、チケット販売サービスを利用するユーザを一意に識別するための情報（ユーザＩＤ）が登録される。以下では、例えばユーザＩＤが「Ｕ１」であるユーザのことをユーザＵ１と記載する。

チケット販売サービスにおけるユーザＩＤは、ソーシャルネットワーキングサービスにおけるユーザＩＤと異なっていてもよいし、同じであってもよい。ここでは、チケット販売サービスにおけるユーザＩＤがソーシャルネットワーキングサービスにおけるユーザＩＤとは異なっていることとして説明する。

「パスワード」フィールドには、ユーザによって指定されたパスワードが登録される。「氏名」及び「メールアドレス」フィールドにはユーザの氏名及びメールアドレスが登録される。「クレジットカード情報」フィールドにはユーザのクレジットカードに関する情報が登録される。

「ＳＮＳユーザＩＤ」フィールドには、ソーシャルネットワーキングサービスにおけるユーザＩＤが登録される。例えば、座席管理システム１とＳＮＳサーバ２０との間の連携を通じて、ソーシャルネットワーキングサービスにおけるユーザＩＤが「ＳＮＳユーザＩＤ」フィールドに登録される。あるいは、ユーザに入力を求めることによって、ソーシャルネットワーキングサービスにおけるユーザＩＤが「ＳＮＳユーザＩＤ」フィールドに登録される。なお、チケット販売サービスとソーシャルネットワーキングサービスとで共通のユーザＩＤを用いている場合には「ＳＮＳユーザＩＤ」フィールドを省略してもよい。

図９はイベントテーブルの一例を示す。イベントテーブルは、チケット販売サービスにおいてチケットが販売されているイベントの一覧を示す。イベントテーブルは「イベントＩＤ」、「イベント名」、「カテゴリ」、「日時」、「会場」、及び「価格」フィールドを含む。

「イベントＩＤ」フィールドには、イベントを一意に識別するための情報（イベントＩＤ）が登録される。「イベント名」及び「カテゴリ」フィールドにはイベントの名称及びカテゴリが登録される。「日時」及び「会場」フィールドにはイベントの開催日時及び開催会場が登録される。「価格」フィールドにはチケットの価格に関する情報が登録される。

図１０は座席テーブルの一例を示す。座席テーブルは各イベントの各座席の予約状況を示す。座席テーブルは「イベントＩＤ」、「座席」、「ブロック」、「状態」、「更新日時」、「予約者」、「チケットＩＤ」、及び「関連座席」フィールドを含む。

「イベントＩＤ」フィールドはイベントテーブルの「イベントＩＤ」フィールドと同様である。「座席」フィールドには、座席を一意に識別する情報（座席ＩＤ）が登録される。「ブロック」フィールドには、座席が属するブロックを一意に識別する情報（ブロックＩＤ）が登録される。「Ｌ」，「Ｃ」，「Ｒ」はそれぞれブロック４４Ｌ，４４Ｃ，４４Ｒを示す。

「状態」フィールドには、座席の予約状態を示すフラグ情報が登録される。例えば、「０」，「１」，「２」の数値が「状態」フィールドに登録される。数値「０」は、座席が空席であることを示す。すなわち、数値「０」は、座席にいずれのユーザも割り当てられていないことを示す。また、数値「１」は、座席が予約済みであることを示す。すなわち、数値「１」は、座席にユーザが割り当てられていることを示す。さらに、数値「２」は、座席が同伴者用座席として一時的に確保されていることを示す。

例えば、各座席の予約状況が図６に示す状況である場合、座席Ａ３，Ａ４，Ａ９の「状態」フィールドに「１」が登録され、座席Ａ８の「状態」フィールドに「２」が登録される。また、他の座席の「状態」フィールドに「０」が登録される。

「更新日時」フィールドには、「状態」フィールドの値が更新された日時が登録される。「予約者」フィールドには、座席に割り当てられているユーザのユーザＩＤが登録される。「チケットＩＤ」フィールドには、ユーザに発行された電子チケットを一意に識別するチケットＩＤが登録される。

「関連座席」フィールドは、ユーザに割り当てられた座席と、同伴者用座席として一時的に確保されている座席と、の関連付けを示す。例えば、ユーザに割り当てられている座席Ａ９の同伴者用座席として座席Ａ８が設定されている場合、座席Ａ８の「関連座席」フィールドに「Ａ９」が登録される。

図１１は履歴テーブルの一例を示す。履歴テーブルは、ユーザが購入したチケットの履歴を示す。例えば、履歴テーブルは「ユーザＩＤ」、「イベントＩＤ」、「座席」、「価格」、及び「購入日時」フィールドを含む。「購入日時」フィールドにはチケットの購入日時が登録される。

座席管理システム１で実現される機能ブロックについて説明する。図１２は、座席管理システム１で実現される機能ブロックについて説明するための機能ブロック図である。図１２に示すように、座席管理システム１は受付部７０（受付手段）及び座席割当処理部７２を含む。受付部７０及び座席割当処理部７２は座席管理サーバ１０の制御部１１によって実現される。

なお、図１２にはデータ記憶部６０も記載されているが、データ記憶部６０は座席管理システム１において実現されるとは限られず、座席管理システム１外のシステムにおいて実現される場合がある。例えば、データ記憶部６０はデータベース２５によって実現される。なお、データ記憶部６０はデータベース１５，２５によって実現されるようにしてもよいし、データベース１５のみによって実現されるようにしてもよい。

データ記憶部６０は、座席割当処理部７２のために必要なデータを記憶する。データ記憶部６０は関係データ記憶部６２を含む。関係データ記憶部６２はユーザ同士の関係を示す関係データを記憶する。例えば、ユーザ同士の友人関係を示すデータが関係データ記憶部６２に記憶される。例えば、図７に示したようなユーザテーブルが関係データ記憶部６２に記憶される。

受付部７０は座席の予約申し込みをユーザから受け付ける。また、受付部７０は所望の座席の指定をユーザから受け付ける。

座席割当処理部７２は、座席へのユーザの割り当てに関する処理を実行する。図１２に示すように、座席割当処理部７２は第１割当部７４（第１割当手段）、関係ユーザ特定部７６（関係ユーザ特定手段）、制限対象選出部７８（制限対象選出手段）、割当制限部８０（割当制限手段）、及び第２割当部８２（第２割当手段）を含む。

第１割当部７４は、座席の予約申し込みがユーザから受け付けられた場合に当該ユーザに座席を割り当てる。例えば、ユーザＵ１によって座席Ａ９が所望の座席として指定された場合、第１割当部７４は座席Ａ９にユーザＵ１を割り当てる。なお以下では、便宜上、座席に割り当てられたユーザのことを「割当済みユーザ」と記載する。

関係ユーザ特定部７６は、割当済みユーザと所定の関係を有するユーザを関係データ記憶部６２の記憶内容に基づいて特定する。なお以下では、便宜上、割当済みユーザと所定の関係を有するユーザのことを「関係ユーザ」と記載する。

例えば、「関係ユーザ」は、割当済みユーザと友人関係を有するユーザである。具体的には、ソーシャルネットワーキングサービスにおいて割当済みユーザと友人関係を築いているユーザである。なお、「関係ユーザ」は、割当済みユーザと友人関係以外の所定の関係を有するユーザであってもよい。

制限対象選出部７８は、座席同士の隣接状態を示す隣接状態データと、座席がいずれかのユーザに割り当てられているか否かを示す割当状態データと、に基づいて、「割当済みユーザに割り当てられた座席に隣接する座席又は座席群であって、かつ、いずれのユーザにも割り当てられていない座席又は座席群」を制限対象として選出する。なお、先に説明した例の場合、座席テーブルの「座席」及び「ブロック」フィールドによって、座席同士の隣接状態を把握できるようになっているため、座席テーブルの「座席」及び「ブロック」フィールドが「隣接状態データ」に相当している。また、座席テーブルの「状態」フィールドによって、座席がいずれかのユーザに割り当てられているか否かを把握できるようになっているため、座席テーブルの「状態」フィールドが「割当状態データ」に相当している。また、制限対象として選出される座席又は座席群は、先に説明した例における「同伴者用座席」に相当している。このため、制限対象選出部７８は同伴者用座席を選出する構成に相当している。

ここで、ユーザＵ１（割当済みユーザ）に座席Ａ９が割り当てられている場合を想定する。この場合、制限対象選出部７８は下記の条件（１）〜（４）のすべてを満足する座席を制限対象として選出する。
（１）空席である。
（２）座席Ａ９に隣接している。
（３）座席Ａ９と同じ行に存在している。
（４）座席Ａ９と同じブロックに属している。

例えば図４に示す状況の場合、座席Ａ８は上記の条件（１）〜（４）のすべてを満足しているため、制限対象選出部７８は座席Ａ８を制限対象として選出する。

なお、制限対象選出部７８は、上記の条件（１）〜（４）のすべてを満足する座席群を制限対象として選出するようにしてもよい。ここで、「座席群」とは、「同じブロックに属し、かつ、連続する複数の座席」のことを意味する。例えば図４に示す状況の場合、座席群Ａ６，Ａ７，Ａ８は上記の条件（１）〜（４）のすべてを満足している。このため、制限対象選出部７８は座席群Ａ６，Ａ７，Ａ８を制限対象として選出するようにしてもよい。

割当制限部８０は、制限対象として選出された座席又は座席群を関係ユーザ以外のユーザに割り当てることを制限する。例えば、割当制限部８０は、制限対象として選出された座席又は座席群を関係ユーザ以外のユーザに割り当てることを禁止する。先述のように、制限対象として選出される座席又は座席群は、先に説明した例における「同伴者用座席」に相当している。このため、割当制限部８０は、同伴者用座席をユーザの友人以外に割り当てることを制限する構成に相当している。

ここで、ユーザＵ１に座席Ａ９が割り当てられ、かつ、座席Ａ８が制限対象として選出されている場合を想定する。この場合、割当制限部８０は、ユーザＵ１と所定の関係（友人関係等）を有するユーザ以外のユーザに座席Ａ９を割り当てることを制限する。

割当制限部８０による制限は制限期間が経過するまでの間にわたって継続され、制限期間が経過した場合に解除される。なお、「制限期間」は、例えば受付部７０による受付又は第１割当部７４による割当が実行された日時に基づいて設定される。

例えば、上記日時から所定時間後の日時が制限期間の終了日時として設定される。例えば、上記日時が「２０１２／５／２ １９：００」であり、かつ、所定時間が「３日（すなわち７２時間）」である場合には、「２０１２／５／５ １９：００」が制限期間の終了日時として設定される。

また例えば、上記日時から所定日数が経過してなる日の２４時が制限期間の終了日時として設定されるようにしてもよい。例えば、上記日時が「２０１２／５／２ １９：００」であり、かつ、所定日数が「３日」である場合には、「２０１２／５／５ ２４：００」が制限期間の終了日時として設定されるようにしてもよい。

第２割当部８２は、関係ユーザから座席の申し込みが受け付けられた場合に、制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を当該関係ユーザに割り当てる。

ここで、ユーザＵ１に座席Ａ９に割り当てられており、かつ、座席Ａ８が制限対象として選出されている場合を想定する。この状況で、ユーザＵ１と所定の関係（友人関係等）を有しているユーザが座席Ａ８を所望の座席として指定した場合、第２割当部８２は当該ユーザに座席Ａ８を割り当てる。

以上に説明した機能ブロックを実現するために座席管理システム１で実行される処理について説明する。図１３，１４は、座席の予約申し込みを受け付けた場合に座席管理サーバ１０が実行する処理の一例を示す。座席管理サーバ１０の制御部１１がプログラムに従って図１３，１４に示す処理を実行することによって、制御部１１は受付部７０及び座席割当処理部７２として機能するようになる。

図１５Ａ〜１５Ｄは図１３，１４に示す処理について説明するための図であり、座席テーブルの変化の一例を示す。以下、図１５Ａ〜図１５Ｄを参照しながら、図１３，１４に示す処理について説明する。

座席指定画面４０の決定ボタン４６がクリックされた場合、イベント及び座席の情報をユーザが最終確認するための確認画面が表示された後、座席の予約申し込みが座席管理サーバ１０に通知される。この場合、ユーザのユーザＩＤ、ユーザが選択したイベントのイベントＩＤ、ユーザが所望した座席の座席ＩＤ等が座席管理サーバ１０に通知される。

座席の予約申し込みが座席管理サーバ１０によって受け付けられた場合、図１３に示すように、座席管理サーバ１０の制御部１１は、ユーザが所望した座席がいずれかのユーザの同伴者用座席として確保されている座席であるか否かを判定する（Ｓ１０１）。すなわち、制御部１１は座席テーブルを参照し、ユーザが所望した座席の「状態」フィールドの値が「２」であるか否かを判定する。

ユーザが所望した座席がいずれかのユーザの同伴者用座席として確保されている座席でないと判定された場合、制御部１１は、ユーザが所望した座席が空席であるか否かを判定する（Ｓ１０２）。すなわち、制御部１１は座席テーブルを参照し、ユーザが所望した座席の「状態」フィールドの値が「０」であるか否かを判定する。

ユーザが所望した座席が空席であると判定された場合、制御部１１は決済処理を実行する（Ｓ１０３）。また、制御部１１（第１割当部７４）はユーザが所望した座席にユーザを割り当て（Ｓ１０４）、電子チケットをユーザに発行する（Ｓ１０５）。

ここで、図１５Ａに示す状況においてユーザＵ１が座席Ａ９を所望の座席として指定した場合を想定する。この場合、図１５Ｂに示すように、制御部１１は座席Ａ９の「状態」フィールドの値を「１」に更新し、「更新日時」フィールドに現在日時を登録する。また制御部１１は座席Ａ９の「予約者」フィールドに「Ｕ１」を登録する。さらに制御部１１は、既存のチケットＩＤと重複しないようにして、新たなチケットＩＤを生成し、座席Ａ９の「チケットＩＤ」フィールドに登録する。

ステップＳ１０３〜Ｓ１０５が実行された後、制御部１１（制限対象選出部７８）は同伴者用座席として確保することが可能な座席が存在しているか否かを判定する（Ｓ１０６）。すなわち、制御部１１は座席テーブルを参照し、先述の条件（１）〜（４）のすべてを満足する座席を存在しているか否かを判定する。

同伴者用座席として確保することが可能な座席が存在していると判定された場合、制御部１１（割当制限部８０）はその座席を同伴者用座席として一時的に確保する（Ｓ１０７）。なお、同伴者用座席として確保することが可能な座席が複数存在している場合には、それら複数の座席のうちのいずれか一つが同伴者用座席として確保される。

ここで、図１５Ｂに示す状況において座席Ａ９の同伴者用座席として座席Ａ８が確保される場合を想定する。この場合、図１５（Ｃ）に示すように、制御部１１は座席Ａ８の「状態」フィールドの値を「２」に更新し、「更新日時」フィールドに現在日時を登録する。また、制御部１１は座席Ａ８の「関連座席」フィールドに「Ａ９」を登録する。

ステップＳ１０７が実行された後、制御部１１は完了画面５０のデータをユーザ端末３に送信する（Ｓ１０８）。この場合、例えば図５に示すような完了画面５０がユーザ端末３の表示部に表示される。

なお、ステップＳ１０６において、同伴者用座席として確保することが可能な座席が存在しないと判定された場合、制御部１１は完了画面５０のデータをユーザ端末３に送信する（Ｓ１０９）。ただし、この場合、同伴者用座席が確保されないため、完了画面５０にはメッセージ５６が表示されない。

また、ステップＳ１０２において、ユーザが所望した座席が空席でないと判定された場合、制御部１１はエラー画面のデータをユーザ端末３に送信する（Ｓ１１０）。このエラー画面には、ユーザが所望した座席が他のユーザによって予約済みであることを示すメッセージが表示される。

また、ステップＳ１０１において、ユーザが所望した座席がいずれかのユーザの同伴者用座席として確保されている座席であると判定された場合、図１４に示すように、制御部１１（関係ユーザ特定部７６）はユーザが同伴者になり得るか否かを判定する（Ｓ２０１）。

例えば、ステップＳ２０１では下記に説明するような処理が実行される。なお、ここでは、図１５Ｃに示す状況において、同伴者用座席として確保されている座席Ａ８をユーザＵ２が所望の座席として指定した場合を想定する。

まず、座席管理サーバ１０の制御部１１は座席テーブルを参照し、座席Ａ８が座席Ａ９の同伴者用座席として設定されていることを把握する。さらに、制御部１１は座席Ａ９にユーザＵ１が割り当てられていることを把握する。

この場合、制御部１１はユーザＵ２がユーザＵ１と友人関係を有しているか否かを判定する。まず、制御部１１はユーザＵ２の友人リストをＳＮＳサーバ２０から取得する。例えば、制御部１１はユーザＵ２のＳＮＳユーザＩＤ「ＳＵ２」をユーザテーブル（図８）から取得する。そして、制御部１１はＳＮＳユーザＩＤ「ＳＵ２」をＳＮＳサーバ２０に送信する。

ＳＮＳサーバ２０の制御部はユーザテーブル（図７）を参照し、ＳＮＳユーザＩＤ「ＳＵ２」に関連付けられた友人リスト「ＳＵ１，ＳＵ５」を取得する。そして、制御部は友人リスト「ＳＵ１，ＳＵ５」を座席管理サーバ１０に返信する。

この場合、座席管理サーバ１０の制御部１１はユーザＵ１のＳＮＳユーザＩＤ「ＳＵ１」をユーザテーブル（図８）から取得する。そして、制御部１１は、ＳＮＳサーバ２０から取得した友人リスト「ＳＵ１，ＳＵ５」に「ＳＵ１」が含まれているか否かを判定する。友人リスト「ＳＵ１，ＳＵ５」に「ＳＵ１」が含まれている場合、制御部１１はユーザＵ２がユーザＵ１の友人であると判断する。この場合、制御部１１はユーザＵ２がユーザＵ１の同伴者になり得ると判定する。

なお、以上では、ユーザＵ２の友人リストをＳＮＳサーバ２０から取得し、ユーザＵ１がユーザＵ２の友人リストに含まれている否かを判定するようにしたが、ユーザＵ１の友人リストをＳＮＳサーバ２０から取得し、ユーザＵ２がユーザＵ１の友人リストに含まれている否かを判定するようにしてもよい。

また、ステップＳ２０１で実行される処理は以上に説明した処理に限られない。ステップＳ２０１では下記に説明するような処理を実行するようにしてもよい。なお、ここでも、図１５Ｃに示す状況において、同伴者用座席として確保されている座席Ａ８をユーザＵ２が所望の座席として指定した場合を想定する。

まず、座席管理サーバ１０の制御部１１はユーザＵ２のＳＮＳユーザＩＤ「ＳＵ２」をユーザテーブル（図８）から取得する。また、制御部１１は座席テーブルを参照し、座席Ａ８が座席Ａ９の同伴者用座席として設定されていることを把握する。さらに、制御部１１は座席Ａ９にユーザＵ１が割り当てられていることを把握する。そして、制御部１１はユーザＵ１のＳＮＳユーザＩＤ「ＳＵ１」をユーザテーブル（図８）から取得する。

その後、制御部１１は、ユーザＵ１，Ｕ２のＳＮＳユーザＩＤの組み合わせ「ＳＵ１，ＳＵ２」をＳＮＳサーバ２０に送信することによって、ユーザＵ１，Ｕ２の間に友人関係が存在しているか否かをＳＮＳサーバ２０に問い合わせる。

ＳＮＳサーバ２０の制御部はユーザテーブル（図７）を参照し、ユーザＳＵ１とユーザＳＵ２との間に友人関係が存在しているか否かを判定する。そして、制御部はその判定結果を座席管理サーバ１０に返信する。

ユーザＵ１，Ｕ２の間に友人関係が存在するとの判定結果がＳＮＳサーバ２０から返信された場合、座席管理サーバ１０の制御部１１はユーザＵ２がユーザＵ１の同伴者になり得ると判定する。一方、ユーザＵ１，Ｕ２の間に友人関係が存在しないとの判定結果がＳＮＳサーバ２０から返信された場合、制御部１１はユーザＵ２がユーザＵ１の同伴者になり得ないと判定する。

ステップＳ２０１においてユーザが同伴者になり得ると判定された場合、制御部１１は決済処理を実行する（Ｓ２０２）。また、制御部１１（第２割当部８２）はユーザが所望した座席にユーザを割り当て（Ｓ２０３）、電子チケットをユーザに発行する（Ｓ２０４）。

ここで、例えば図１５Ｃに示す状況において、座席Ａ８を所望の座席として指定したユーザＵ２が同伴者となり得るとステップＳ２０１において判定された場合を想定する。この場合、図１５Ｄに示すように、制御部１１は座席Ａ８の「状態」フィールドの値を「１」に更新し、「更新日時」フィールドに現在日時を登録する。また、制御部１１は座席Ａ８の「予約者」フィールドに「Ｕ２」を登録する。さらに制御部１１は、既存のチケットＩＤと重複しないようにして、新たなチケットＩＤを生成し、座席Ａ８の「チケットＩＤ」フィールドに登録する。

ステップＳ２０２〜Ｓ２０４が実行された後、制御部１１は完了画面５０のデータをユーザ端末３に送信する（Ｓ２０５）。ただし、この場合、新たな同伴者用座席は確保されないため、完了画面５０にはメッセージ５６が表示されない。

また、ステップＳ２０１においてユーザが同伴者になり得ないと判定された場合、制御部１１はエラー画面のデータをユーザ端末３に送信する（Ｓ２０６）。このエラー画面には、ユーザが所望した座席がユーザと友人関係にない他のユーザの同行者用座席として確保されているため、予約することができないことを示すメッセージが表示される。

なお、図１３，１４では省略されているが、制御部１１は、同伴者用座席として確保されている各座席に関し、確保期間が経過したか否かを監視する。確保期間が経過している否かの判定は各座席の「更新日時」フィールドに登録されている更新日時に基づいて行われる。例えば、更新日時の所定時間後の日時が確保期間の終了時点として設定される場合であれば、制御部１１は更新日時から所定時間が経過したか否かを判定することによって、確保期間が経過したか否かを判定する。

同伴者用座席の確保期間が経過した場合、制御部１１は同伴者用座席として確保されていた座席を空席の状態に戻す。例えば、制御部１１はその座席の「状態」フィールドの値を「０」に更新し、「更新日時」フィールドに現在日時を登録する。また、制御部１１はその座席の「関連座席」フィールドをクリアする。

以上に説明した座席管理システム１によれば、同伴者が確定していなくてもユーザは自らの席を確保することができ、かつ、後に同伴者が確定した場合にはユーザの席に隣接する席を同伴者の席として確保できるようになる。

なお、座席管理システム１では、ユーザ同士の関係（友人関係等）に関するデータを既存のソーシャルネットワーキングサービスから取得するようになっている。このため、座席管理システム１では、ユーザ同士の関係（友人関係等）に関するデータを新たに登録する手間が生じないようになっている。

また、座席管理システム１では、ユーザ（同伴者を誘う側のユーザ）は任意の座席を選択できるようになっており、ユーザの座席選択の自由度が担保されている。

なお、本発明は以上に説明した実施形態に限定されるものではない。

［変形例１］例えば、座席指定画面４０では、ユーザの同伴者用座席として確保されている座席を、当該ユーザの友人以外のユーザが指定できないようにしてもよい。例えば図１０に示す状況ではユーザＵ１の同伴者用座席として座席Ａ８が確保されている。このような場合、座席指定画面４０では、ユーザＵ１の友人以外のユーザが座席Ａ８を指定できないようにしてもよい。

［変形例２］例えば、図５に示す完了画面５０の代わりに、図１６に示すような完了画面５０Ａを表示するようにしてもよい。図１６に示す完了画面５０Ａは勧誘対象候補リスト９０及び勧誘ボタン９２を含む点で図５に示す完了画面５０と相違している。

勧誘対象候補リスト９０にはユーザの友人が勧誘対象候補として表示される。ユーザは勧誘対象候補リスト９０に表示される友人のうちから勧誘対象を指定し、勧誘ボタン９２をクリックする。勧誘ボタン９２がクリックされると、勧誘対象として指定された友人宛に勧誘メッセージがソーシャルネットワーキングサービス又は電子メール等を介して送信される。

以上のような完了画面５０Ａを表示するための処理について説明する。この変形例２では、図１３のステップＳ１０８において下記に説明するような処理が実行される。

まず、座席管理サーバ１０の制御部１１（勧誘対象候補選出手段）は、勧誘対象候補のリストとして、ユーザの友人リストをＳＮＳサーバ２０から取得する。この処理に関しては図１４のステップＳ２０１における処理と同様である。

その後、制御部１１はユーザテーブル（図８）を参照し、友人リストに含まれるユーザの氏名を取得する。このようにして取得された氏名に基づいて、制御部１１（勧誘対象候補提示手段）は、勧誘対象候補リスト９０を含む完了画面５０Ａのデータを生成し、ユーザ端末３に送信する。その結果、図１６に示すような完了画面５０Ａがユーザ端末３の表示部に表示され、勧誘対象候補リスト９０がユーザに提示される。

なお、完了画面５０Ａの勧誘ボタン９２がクリックされた場合には、例えば、ユーザのユーザＩＤ、イベントのイベントＩＤ、及び勧誘対象として指定された友人のユーザＩＤが座席管理サーバ１０に送信される。

この場合、座席管理サーバ１０の制御部１１はユーザテーブル（図８）を参照し、勧誘対象として指定された友人のメールアドレスを取得する。また、制御部１１（勧誘手段）は、取得されたメールアドレスに基づいて、勧誘メッセージを示す電子メールを勧誘対象の友人に送信する。

あるいは、制御部１１はユーザテーブル（図８）を参照し、勧誘対象として指定された友人のＳＮＳユーザＩＤを取得する。また、制御部１１（勧誘手段）は、取得されたＳＮＳユーザＩＤやメッセージ内容をＳＮＳサーバ２０に送信することによって、勧誘メッセージを勧誘対象の友人に通知するようにＳＮＳサーバ２０に要求する。この場合、ＳＮＳサーバ２０では、座席管理サーバ１０からの要求に従って、勧誘メッセージが勧誘対象の友人に通知される。

以上に説明した変形例２によれば、所望の友人を同伴者として誘い易くなるようにユーザを補助することが可能になる。

なお、変形例２では、勧誘対象候補の選出を、データベース１５（履歴データ記憶手段）に記憶された履歴テーブル（履歴データ）に基づいて実行するようにしてもよい。

例えば、ユーザの友人のうちの、今回のイベントと同一又は類似のカテゴリのイベントのチケットを過去に購入したことがある友人を勧誘対象候補として選出するようにしてもよい。なお、この場合、同一又は類似するカテゴリの組み合わせを定義したデータに基づいて、イベントのカテゴリが同一又は類似するか否かを判定するようにすればよい。

このようにすれば、イベントに同伴してくれる可能性の高い友人を誘い易くなるようにユーザを補助することが可能になる。

また、変形例２では、勧誘対象として指定された友人のみを同伴者用座席に割り当てるようにしてもよい。すなわち、ユーザの友人であっても、勧誘対象として指定されていない場合には、同伴者用座席に割り当てることを制限するようにしてもよい。このようにすれば、ユーザが勧誘対象として指定した友人のみが同伴者用座席に割り当てられるようになる。

［変形例３］変形例２では、ユーザによって勧誘対象として指定された友人に勧誘メッセージを送信するようになっていたが、ユーザに指定を求めることなく、ユーザの友人を勧誘対象として選出し、勧誘対象の友人宛に勧誘メッセージを通知するようにしてもよい。

この変形例３では、例えば図１３のステップＳ１０８の前又は後において、下記に説明するような処理が実行される。

まず、座席管理サーバ１０の制御部１１（勧誘対象選出手段）は、勧誘対象のリストとして、ユーザの友人リストをＳＮＳサーバ２０から取得する。この処理に関しては図１４のステップＳ２０１における処理と同様である。

その後、制御部１１（勧誘手段）はユーザテーブル（図８）を参照し、友人リストに含まれるユーザの氏名及びメールアドレスを取得し、勧誘メッセージを示す電子メールを勧誘対象のユーザに送信する。

あるいは、制御部１１はユーザテーブル（図８）を参照し、ユーザのＳＮＳユーザＩＤを取得する。また、制御部１１（勧誘手段）は、取得されたＳＮＳユーザＩＤやメッセージ内容をＳＮＳサーバ２０に送信することによって、ユーザの友人に勧誘メッセージを通知するようにＳＮＳサーバ２０に要求する。この場合、ＳＮＳサーバ２０では、座席管理サーバ１０からの要求に従って、勧誘メッセージがユーザの友人（勧誘対象のユーザ）に通知される。

以上に説明した変形例３によれば、友人を同伴者として誘い易くなるようにユーザを補助することが可能になる。

なお、変形例３では、勧誘対象の選出を、データベース１５（履歴データ記憶手段）に記憶された履歴テーブル（履歴データ）に基づいて実行するようにしてもよい。

例えば、ユーザの友人のうちの、今回のイベントと同一又は類似のカテゴリのイベントのチケットを過去に購入したことがある友人を勧誘対象として選出するようにしてもよい。なお、この場合、同一又は類似するカテゴリの組み合わせを定義したデータに基づいて、イベントのカテゴリが同一又は類似するか否かを判定するようにすればよい。

このようにすれば、イベントに同伴してくれる可能性の高い友人を同伴者として誘い易くなるようにユーザを補助することが可能になる。

［変形例４］例えば、図６に示す座席指定画面４０の代わりに、図１７に示すような座席指定画面４０Ａを表示するようにしてもよい。なお、図１７は、ユーザＵ１の同伴者用座席として座席Ａ８が確保されている場合（図１０参照）において、ユーザＵ１の友人であるユーザＵ２のユーザ端末３の表示部に表示される座席指定画面４０の一例を示す。

図１７に示す座席指定画面４０Ａはメッセージ９４を含む点で図６に示す座席指定画面４０とは異なっている。メッセージ９４は、ユーザＵ１の同伴者用座席として座席Ａ８が確保されていることを示している。ユーザＵ１の友人であるユーザＵ２はこのメッセージ９４を見ることによって、ユーザＵ１の同伴者用座席として座席Ａ８が確保されていることを一見して把握することができる。

なお、メッセージ９４を表示する代わりに、座席Ａ８を区別表示又は強調表示するようにしてもよい。あるいは、座席Ａ８に所定の画像を関連付けて表示するようにしてもよい。このようにすることによって、ユーザＵ１の友人であるユーザＵ２がユーザＵ１の同伴者用座席として座席Ａ８が確保されていることを一見して把握できるようにしてもよい。

変形例４によれば、友人の同伴者用座席として確保されている座席を把握し易くなるようにユーザを補助することが可能になる。

［変形例５］例えば図１０に示す状況ではユーザＵ１の同伴者用座席として座席Ａ８が確保されている。このような状況において、ユーザＵ１の友人でないユーザＵ３が座席Ａ８を所望の座席として指定した場合には、下記に説明するような処理を実行するようにしてもよい。

例えば、座席管理サーバ１０の制御部１１は、同伴者用座席として確保されている座席Ａ８に対する予約申し込みを行うか否かをユーザＵ１に問い合わせる。この問い合わせはソーシャルネットワーキングサービス又は電子メール等を介して行われる。また、問い合わせに対する返答は、座席管理サーバ１０によって提供される所定のウェブページにおいて受け付けられる。

座席Ａ８に対する予約申し込みを行うことをユーザＵ１が選択した場合、制御部１１は座席Ａ８をユーザＵ１に割り当てる。この場合、図１４のステップＳ２０２〜Ｓ２０５と同様の処理が実行される。

一方、座席Ａ８に対する予約申し込みを行うことをユーザＵ１が選択しなかった場合、制御部１１は座席Ａ８をユーザＵ３に割り当てる。この場合にも、図１４のステップＳ２０２〜Ｓ２０５と同様の処理が実行される。

このようにすることによって、ユーザの同伴者用座席として確保されている座席を予約する余地を、当該ユーザの友人でないユーザにも与えることができるようになる。

［変形例６］例えば図１０に示す状況ではユーザＵ１の同伴者用座席として座席Ａ８が確保されている。このような状況において、座席Ａ８がユーザＵ１の友人によって指定されることなく（すなわち、ユーザＵ１の同伴者が決定されることなく）、同伴者用座席の確保期間が経過した場合、先述のように座席Ａ８は解放され、空席の状態に戻る。

このような場合、ユーザＵ１の要求（意思表示）に応じて、ユーザＵ１への座席Ａ９の割り当てを解除するようにしてもよい。すなわち、ユーザＵ１に割り当てられている座席Ａ９を解放するようにしてもよい。

なお、ユーザＵ１の上記要求（意思表示）は同伴者用座席の確保期間が経過した後に受け付けるようにしてもよいし、同伴者用座席の確保期間が経過する前に予め受け付けておくようにしてもよい。例えば、同伴者が決定されなかった場合には座席Ａ９をキャンセルする旨の要求（意思表示）を、座席の予約（チケットの購入）を行う際にユーザＵ１から予め受け付けておくようにしてもよい。

［変形例７］例えば図１０に示す状況ではユーザＵ１の同伴者用座席として座席Ａ８が確保されている。この同伴者用座席の確保期間が経過した後に、同伴者用座席として確保されていた座席Ａ８に対する予約申込みを他のユーザが行った場合には、元々のユーザであるユーザＵ１に対して、複数の隣接する空席のいずれかに座席に変更することを提案する構成としてもよい。例えば、図１０に示す状況の場合であれば、隣接する座席Ａ１，Ａ２が空席になっているため、座席Ａ１，Ａ２のいずれかに座席を変更することをユーザＵ１に提案するようにしてもよい。例えば、ユーザＵ１が座席を座席Ａ２に変更した場合、座席Ａ２に隣接する座席Ａ１が同伴者用座席として確保されるわけではないが、ユーザＵ１の座席に隣接する座席をユーザＵ１の同伴者が予約する余地は残されることになる。

以上のようにすれば、座席の絶対的な位置に拘らないユーザにとっては、残り日数が少なくなっても同伴者用座席を確保するのと同様な効果が得られるため、一層利便性が高くなる。また、イベントの開催者にとっても、イベントの開催が迫った時期に他のユーザが予約できない状況を発生させることなく、即ち他のユーザに不利益なく、より空席を減らす可能性を高くなるという利点がある。

［変形例８］例えば、いずれのユーザにも割り当てられていない座席の数に基づいて、同伴者用座席の確保期間（制限期間）の長さを変更するようにしてもよい。

例えば、いずれのユーザにも割り当てられていない座席の数が少ないほど、同伴者用座席の確保期間の長さを短くするようにしてもよい。言い換えれば、いずれのユーザにも割り当てられていない座席の数が多いほど、同伴者用座席の確保期間の長さを長くするようにしてもよい。

「いずれのユーザにも割り当てられていない座席の数」としては、「状態」フィールドの値が「０」である座席の数を用いるようにしてもよいし、「状態」フィールドの値が「１」でない座席の数を用いるようにしてもよい。

なお、いずれのユーザにも割り当てられていない座席の数に基づいて、同伴者用座席の確保期間の長さを変更する場合には、座席の数と確保期間の長さとの対応関係を示す対応関係情報が必要となり、この情報と、いずれのユーザにも割り当てられていない座席の数と、に基づいて、同伴者用座席の確保期間の長さを設定することになる。

［変形例９］例えば、イベントの開催までの残り日数又は残り時間に基づいて、同伴者用座席の確保期間（制限期間）の長さを変更するようにしてもよい。

例えば、残り日数又は残り時間が少ない場合には、同伴者用座席の確保期間の長さを短くするようにしてもよい。言い換えれば、残り日数又は残り時間が多い場合には、同伴者用座席の確保期間の長さを長くするようにしてもよい。

例えば、通常は確保期間を３日に設定し、イベントの開催までの残り日数が７日以内になったら、確保期間を１日に設定するようにしてもよい。

なお、イベントの開催までの残り日数又は残り時間に基づいて、同伴者用座席の確保期間の長さを変更する場合には、残り日数又は残り時間と確保期間の長さとの対応関係を示す対応関係情報が必要となり、この情報と、イベントの開催までの残り日数又は残り時間と、に基づいて、同伴者用座席の確保期間の長さを設定することになる。

［変形例１０］以上に説明した実施形態ではユーザが所望の座席を指定できるようになっていたが、ユーザが所望の座席を指定できるようにすることは必須でない。ユーザが所望の座席を指定できないようにしてもよい。すなわち、ユーザに割り当てる座席が座席管理サーバ１０によって選択されるようにしてもよい。

なお、変形例１〜１０のうちの複数を組み合わせるようにしてもよい。

１ 座席管理システム、２ 通信ネットワーク、３ ユーザ端末、１０ 座席管理サーバ、１１ 制御部、１２ 記憶部、１３ 光ディスクドライブ部、１４ 通信部、１５，２５ データベース、２０ ＳＮＳサーバ、３０ 購入画面、３２ 枚数欄、３４ 購入ボタン、４０，４０Ａ 座席指定画面、４２ 座席表、４４Ｌ，４４Ｃ，４４Ｒ ブロック、４６ 決定ボタン、５０，５０Ａ 完了画面、５２ 表示ボタン、５４ 印刷ボタン、５６，９４ メッセージ、 ６０ データ記憶部、６２ 関係データ記憶部、７０ 受付部、７２ 座席割当処理部、７４ 第１割当部、７６ 関係ユーザ特定部、７８ 制限対象選出部、８０ 割当制限部、８２ 第２割当部、９０ 勧誘対象候補リスト、９２ 勧誘ボタン。

Claims (12)

1. 会場の座席を管理する座席管理システムにおいて、
   座席の申し込みをユーザから受け付ける受付手段と、
   前記ユーザから前記申し込みが受け付けられた場合に当該ユーザに座席を割り当てる第１割当手段と、
   ユーザ同士の関係を示す関係データを記憶する関係データ記憶手段の記憶内容に基づいて、前記座席が割り当てられたユーザ（以下「割当済みユーザ」と記載する。）と所定の関係を有するユーザ（以下「関係ユーザ」と記載する。）を特定する関係ユーザ特定手段と、
   座席同士の隣接状態を示す隣接状態データと、座席がいずれかのユーザに割り当てられているか否かを示す割当状態データと、に基づいて、前記割当済みユーザに割り当てられた座席に隣接し、かつ、いずれのユーザにも割り当てられていない座席又は座席群を制限対象として選出する制限対象選出手段と、
   前記制限対象として選出された座席又は座席群を前記関係ユーザ以外のユーザに割り当てることを所定の制限期間にわたって制限する割当制限手段と、
   前記関係ユーザから前記申し込みが受け付けられた場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を当該関係ユーザに割り当てる第２割当手段と、
   を含むことを特徴とする座席管理システム。
2. 請求項１に記載の座席管理システムにおいて、
   前記関係ユーザを勧誘対象候補として選出する勧誘対象候補選出手段と、
   前記勧誘対象候補として選出された前記関係ユーザを前記割当済みユーザに提示する勧誘対象候補提示手段と、
   前記割当済みユーザに提示された前記関係ユーザが前記割当済みユーザによって勧誘対象として指定された場合に、前記勧誘対象として指定された前記関係ユーザに前記申し込みを勧誘する勧誘手段と、
   を含むことを特徴とする座席管理システム。
3. 請求項２に記載の座席管理システムにおいて、
   前記勧誘対象候補選出手段は、ユーザの申し込み履歴を示す履歴データを記憶する履歴データ記憶手段の記憶内容に基づいて、前記関係ユーザを前記勧誘対象候補として選出することを特徴とする座席管理システム。
4. 請求項１に記載の座席管理システムにおいて、
   前記関係ユーザを勧誘対象として選出する勧誘対象選出手段と、
   前記勧誘対象として選出された前記関係ユーザに前記申し込みを勧誘する勧誘手段と、
   を含むことを特徴とする座席管理システム。
5. 請求項４に記載の座席管理システムにおいて、
   前記勧誘対象選出手段は、ユーザの申し込み履歴を示す履歴データを記憶する履歴データ記憶手段の記憶内容に基づいて、前記関係ユーザを前記勧誘対象として選出することを特徴とする座席管理システム。
6. 請求項１乃至５のいずれかに記載の座席管理システムにおいて、
   前記受付手段は、所望の座席の指定を前記ユーザから受け付ける手段を含み、
   前記座席管理システムは、
   前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席が、前記所望の座席として、前記関係ユーザ以外のユーザによって指定された場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席に関する前記申し込みを行うか否かを前記割当済みユーザに問い合わせる手段と、
   前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席に関する前記申し込みを行うことを前記割当済みユーザが選択した場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を前記割当済みユーザに割り当てる手段と、
   前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席に関する前記申し込みを行うことを前記割当済みユーザが選択しなかった場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を前記関係ユーザ以外の前記ユーザに割り当てる手段と、を含む、
   ことを特徴とする座席管理システム。
7. 請求項１乃至６のいずれかに記載の座席管理システムにおいて、
   前記受付手段は、所望の座席の指定を前記ユーザから受け付ける手段を含み、
   前記座席管理システムは、
   前記関係ユーザから前記申し込みが受け付けられた場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を当該関係ユーザに提示する手段と、
   前記関係ユーザに提示された座席が当該関係ユーザによって前記所望の座席として指定された場合に、前記所望の座席として指定された座席を当該関係ユーザに割り当てる手段と、を含む、
   ことを特徴とする座席管理システム。
8. 請求項１乃至７のいずれかに記載の座席管理システムにおいて、
   前記制限期間が経過した場合に前記割当制限手段による制限を解除する手段を含むことを特徴とする座席管理システム。
9. 請求項１乃至８のいずれかに記載の座席管理システムにおいて、
   前記制限期間が経過するまでに前記関係ユーザから前記申し込みが受け付けられなかった場合に、前記割当済みユーザへの前記座席の割り当てを、当該割当済みユーザの要求に基づいて解除する手段を含むことを特徴とする座席管理システム。
10. 請求項１乃至９のいずれかに記載の座席管理システムにおいて、
    いずれのユーザにも割り当てられていない座席の数と、イベントの開催までの残り日数又は残り時間と、の少なくとも一方に基づいて、前記制限期間の長さを変更する手段を含むことを特徴とする座席管理システム。
11. 会場の座席を管理する座席管理システムの制御方法において、
    座席の申し込みをユーザから受け付ける受付ステップと、
    前記ユーザから前記申し込みが受け付けられた場合に当該ユーザに座席を割り当てる第１割当ステップと、
    ユーザ同士の関係を示す関係データを記憶する関係データ記憶手段の記憶内容に基づいて、前記座席が割り当てられたユーザ（以下「割当済みユーザ」と記載する。）と所定の関係を有するユーザ（以下「関係ユーザ」と記載する。）を特定する関係ユーザ特定ステップと、
    座席同士の隣接状態を示す隣接状態データと、座席がいずれかのユーザに割り当てられているか否かを示す割当状態データと、に基づいて、前記割当済みユーザに割り当てられた座席に隣接し、かつ、いずれのユーザにも割り当てられていない座席又は座席群を制限対象として選出する制限対象選出ステップと、
    前記制限対象として選出された座席又は座席群を前記関係ユーザ以外のユーザに割り当てることを所定の制限期間にわたって制限する割当制限ステップと、
    前記関係ユーザから前記申し込みが受け付けられた場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を当該関係ユーザに割り当てる第２割当ステップと、
    を含むことを特徴とする座席管理システムの制御方法。
12. 座席の申し込みをユーザから受け付ける受付手段、
    前記ユーザから前記申し込みが受け付けられた場合に当該ユーザに座席を割り当てる第１割当手段、
    ユーザ同士の関係を示す関係データを記憶する関係データ記憶手段の記憶内容に基づいて、前記座席が割り当てられたユーザ（以下「割当済みユーザ」と記載する。）と所定の関係を有するユーザ（以下「関係ユーザ」と記載する。）を特定する関係ユーザ特定手段と、
    座席同士の隣接状態を示す隣接状態データと、座席がいずれかのユーザに割り当てられているか否かを示す割当状態データと、に基づいて、前記割当済みユーザに割り当てられた座席に隣接し、かつ、いずれのユーザにも割り当てられていない座席又は座席群を制限対象として選出する制限対象選出手段、
    前記制限対象として選出された座席又は座席群を前記関係ユーザ以外のユーザに割り当てることを所定の制限期間にわたって制限する割当制限手段、及び、
    前記関係ユーザから前記申し込みが受け付けられた場合に、前記制限対象として選出された座席又は座席群のうちの少なくとも一つの座席を当該関係ユーザに割り当てる第２割当手段、
    としてコンピュータを機能させるためのプログラム。

Images