JP2005173838A - チケット入手あるいは交換の支援を行うシステム及びチケット入手あるいは交換の支援を行う方法及びチケット入手あるいは交換の支援のためのコンピュータプログラム - Google Patents

Abstract

【課題】 種種の通信装置を利用してより使い易いチケット入手あるいは交換の支援を行うための支援システム、方法、それに関するプログラムを提供することである。
【解決手段】 本発明による解決手段の一つは、指定のチケットの予約ができなかったが、その指定の予約をとりたい予約希望者と、その予約希望者が必要とするチケットを保有しているが他の日へ予約を変更できる予約移譲者とのチケット転売作業を、メール通信機能等を用いて支援できるようにしたことである。さらにもう一つの解決手段の一つは、上記転売作業を行ううえで発生しうる「ダフ屋的」行為を減少させる仕組みを提供したことである。
【選択図】 図１

Description

本発明は、チケット入手あるいは交換のための、例えば携帯電話のメール機能を利用した飛行機のチケット入手あるいは交換のためのコンピュータプログラムに関する。
本発明は、前記に示したごとくチケットの入手あるいは交換を行いやすくするためのさまざまな支援に関するものである。

種種の通信装置でチケット入手あるいは交換の支援システム及びチケットの入手あるいは交換の支援方法及びチケットの入手あるいは交換の支援のためのコンピュータプログラムに関するものには、以下のような技術がある。例えば、特許文献１参照。

特許文献１には、「予め設定された条件に応じて、前記電子チケットの取引価格を自動的に計算する手段を有する、如く構成すれば、各種条件に応じて、電子チケットの取引価格が決定されるで、電子チケットの売れ残りの低減を図ることができる。」さらに「電子チケットの取引価格を設定する手段を有する、如く構成すれば、電子チケットの転売希望者の意向に添った取引価格を設定することができる。」と記載されている。

特許文献２には、「本発明の目的は、主催者の利益追求でもなく、第三者の「ダフ屋」的行為を減少させることにあるから、通常のオークションのメカニズムを利用しながら、当選確率の範囲内（幅のある範囲内の意味）で人数を絞るので、オークションの落札価格は、特定の範囲内の値段に落ち着く。」と記載されている。
特開２００３−０５０８８９号公報 （段落〔００２６〕−〔００２８〕） 特開２００３−１５０７４０号公報 （段落〔００５９〕）

本発明が解決しようとする課題は、種種の通信装置を利用してより使い易いチケット入手あるいは交換の支援を行うための支援システム、方法、それに関するプログラムを提供することである。

この課題について具体例を挙げて説明すると、ホテル、航空券、チケットなどの電子予約システムにおいて、空き予約が無い状態でも緊急予約が取れるように既存予約者と緊急予約者間でのマッチングを行うことを支援する電子予約システムあるいは電子予約方法、電子予約を行うためのコンピュータプログラムを提供することである。

さらに他の課題は、チケットの転売による「ダフ屋」的行為を減少させることにあり、チケットの購入者、チケットの移譲をする者及びチケットの販売管理元の３者全員若しくは１者以上が、目的を達成あるいは利益を得ることを支援する電子予約システムあるいは電子予約方法、電子予約を行うためのコンピュータプログラムを提供することである。

本発明による解決手段の一つは、指定のチケットの予約ができなかったが、その指定の予約をとりたい予約希望者と、その予約希望者が必要とするチケットを保有しているが他の日へ予約を変更できる予約移譲者とのチケット転売作業を、メール通信機能などを用いて支援できるようにしたことである。その手段の具体的構成の例を以下に挙げる。

予約希望者は予約期間、人数、サービスをインターネットなどの通信手段を用いて指定可能。さらに予約希望者はマッチング制限時間を指定可能。その場合、予約希望者の料金は高額となり、予約移譲者の料金は低額となる。また予約移譲の募集は既存予約者全員に電子メールなどの連絡手段を用いて実施する。そのためマッチング成立確立が高くなる。また予約移譲希望者は移譲意思、変更後予約期間、人数、サービスをインターネットなどの通信手段から指定可能である。マッチング処理サーバと一般予約処理サーバを分け、マッチング処理をマッチング処理サーバで実行することにより、高速なマッチング処理を実現することができる。マッチング処理サーバと一般予約処理サーバを分け、マッチング処理をマッチング処理サーバで実行することにより、既存の一般予約処理の処理時間に影響を与えないようにすることもできる。

さらにもう一つの解決手段の一つは、前記転売作業を行ううえで発生しうる「ダフ屋的」行為を減少させる仕組みを提供したことである。その手段の具体的構成の例を以下に挙げる。

まず予約移譲者は移譲と同時に予約変更が必須であるように制約条件を設置する。さらに予約希望者、予約移譲者ともマッチング成立後の取消、再変更はできなくする。又は取消・変更料金を課す仕組みを設ける。さらに予約移譲希望者が多人数の場合、予約移譲希望者のランダム抽出を実施する。また予約移譲希望者の２重予約などの移譲をするための個人の利益を得るために行う故意の予約操作の防止を図る。さらに移譲希望予約（抽出漏れ）の取消、変更をできなくするなどの仕組みを提供する。

指定した予約の取得を強く望む予約希望者が目的どおり予約をとることができる可能性を高くできる。さらに携帯電話のメールなどを利用した予約状況のマッチング処理により短時間で予約を成立させることができる。そのため、例えば緊急予約（緊急の業務や冠婚葬祭などのための予約）を行うことを支援することができる。また、予約を移譲した予約移譲者にはチケット料が割引になるなどの特典がある。

さらに、予約できなかった予約希望者が予約を行えるようになり、予約移譲者も予約をキャンセルするなどの行為又は「ダフ屋的」行為を行いにくい仕組みを提供するため、チケットが売れ残る、空席が多いなどの、業者側の機会損失を減らすことができる。

このように、例えば飛行機のチケットの入手などでは、チケットの予約ができなかった利用者がチケットの利用日変更が可能な予約者のチケットを入手することを支援することができる。

さらには、飛行機チケットの予約ができなかった利用者のために、移動手段や飛行ルートを検索して、目的を達する方法を提供することができる。

本発明の実施の一形態を図面に基づき詳細に説明する。
図１に、本発明が適用されるコンピューターシステムのシステム構成の一形態、図２〜図６に、本発明の一実施の形態における処理データ、図７〜図１２に、本発明の一実施の形態における処理フローを示す。以下、順に説明する。

図１に本発明が適用される一実施例のシステムの全体構成図を示す。システムは事業者マッチング処理サーバ装置１０４、事業者一般予約処理サーバ装置１０５、マッチング要求基本データベース１０１、マッチング受付基本データベース１０２、電子予約基本データベース１０３、一般予約端末装置１０６、マッチング要求端末装置１０９及び通信回線１１０から構成される。

まず、利用者が持つ携帯電話などの一般予約端末装置１０６から予約問合せを行う。その予約が通信回線１１０を通して事業者一般予約処理サーバ装置１０５で処理され、予約が成立すれば、その予約は電子予約基本データベース１０３に格納される。

予約が成立したかどうかに関する情報は事業者一般予約処理サーバ装置１０５から通信回線１１０を通して前記携帯電話などの一般予約端末装置１０６に伝えられる。予約が不成立の場合、その連絡を受けた利用者は、必要に応じ、利用者が持つ携帯電話などのマッチング要求端末装置１０９からマッチング処理を依頼する。また予約が成立した場合、予約の移譲を行っても良いと考える利用者は、その予約結果を以下に説明するマッチングの処理対象とすることができる。ここで前記携帯電話は一般予約端末装置１０６の一例であって、パーソナルコンピュータでも良いが、場所を選ばない点で携帯電話は便利である。また一般予約端末装置１０６とマッチング要求端末装置１０９は当然同じものであっても良く、利用時点でその目的から一般予約端末装置１０６となったり、マッチング要求端末装置１０９となったりする。

マッチング処理に関する情報は通信回線１１０を通して事業者マッチング処理サーバ装置１０４に送られる。送られたマッチング処理の情報はそこでマッチング要求基本データベース１０１とマッチング受付基本データベース１０２に登録される。登録されたマッチング要求基本データベース１０１は、事業者マッチング処理サーバ装置１０４でマッチング受付基本データベース１０２とマッチングが行われる。この際、マッチング受付基本データベース１０２の二重登録があるかなどの正当性のチェックなども実施される。マッチングが成立すれば、その旨が各利用者へ通信回線１１０を通して伝えられる。マッチングが成立しない場合は、それらのデータはマッチング不成立データとして引き続き保管される。またマッチング成立時にも、その成立データを保管し、予約状況分析に役立てることもできる。

図２にマッチング要求基本データベースのデータの一例を示す。マッチング要求基本データは列方向にマッチング要求番号Ａ、マッチング要求年月日Ｂ、マッチング要求時刻Ｃ、マッチング制限時間Ｄ、マッチング成立時間Ｅ、マッチング結果Ｆ、新一般予約識別番号Ｇ、マッチング先一般予約識別番号Ｈ、該当予約コードＩ、マッチングステータスＪからなり、行方向にそれぞれ複数件のデータが、マッチング要求番号Ａをキーとして保管されている。

図３にマッチング受付基本データベースのデータの一例を示す。マッチング受付基本データは列方向にマッチング受付番号Ｋ、一般予約識別番号Ｌ、マッチング受付時刻Ｍ、マッチング結果Ｎ、変更後一般予約識別番号Ｏ、移譲先一般予約識別番号Ｐ、マッチングステータスＱからなり、行方向にそれぞれ複数件のデータが、マッチング受付番号Ｋをキーとして保管されている。

図４〜図６に電子予約基本データの一例を示す。電子予約基本データは列方向に一般予約識別番号Ｒ、予約コードＳ、予約期間Ｔ、予約年月日Ｕ、予約時刻Ｕ、料金Ｖ、発生マイレージＶ、住所Ｗ、氏名Ｗ、電子メールアドレスＷ、電話番号Ｗ、関連情報（予約変更不可、割引不適用など・・・）Ｗ、マッチングフラグＸ、マッチング要求番号Ｙ、マッチング受付番号Ｚからなり、行方向にそれぞれ複数件のデータが、一般予約識別番号Ｒをキーとして保管されている。

マッチング要求基本データ（図２）のマッチング要求番号Ａ「１」２０１は、電子予約基本データ（図６）のマッチング番号Ｙ「１」６０４に対応して保管される。同様に、初めに予約を希望したマッチング先一般予約識別番号Ｈ「２」２０３は、一般予約識別番号Ｒ「２」４０１に対応して保管される。マッチング後の新一般予約識別番号Ｇ「４」は、一般予約識別番号Ｒ「４」４０２に対応している。

マッチング受付基本データ（図３）のマッチング受付番号Ｋ「１」３０１は、マッチング受付番号Ｚ「１」６０５及び６０６に対応する。一般予約識別番号Ｌ「２」は一般予約識別番号Ｒ「２」に対応している。変更後一般予約識別番号Ｏ「５」３０２は一般予約識別番号Ｒ「５」６０３に対応している。移譲先一般予約識別番号Ｐ「４」３０３は一般予約識別番号Ｒ「４」６０２に対応している。

このようにマッチング要求基本データ（図２）、マッチング受付基本データ（図３）及び電子予約基本データ（図４〜図６）は、互いにマッチング要求番号（ＡとＹ）、マッチング受付番号（ＫとＺ）及び種種の一般予約識別番号（Ｒ、Ｌ、Ｏ、Ｐ、Ｇ、Ｈ）でリンクしあっている。

前記したように、マッチング要求基本データ（図２）、マッチング受付基本データ（図３）及び電子予約基本データ（図４〜図６）が互いにリンクし連動してデータを管理することで、マッチング処理が高速にかつ容易に行える環境を保持している。

図７に、図１に記載のシステムの操作及びシステムの処理のフローを示す。英数字「Ｓ」で始まる番号は前記処理フローのステップを表す。図７に従い、予約者が例えばチケットの予約を行ってから、その予約に関する処理が終了するまでのフローを説明する。まずステップＳ７０１では、予約の設定として、利用者が予約希望の登録を行う。予約の設定方法は、窓口に申し込む、携帯電話又はパソコンからの電子予約など、その形態は様々であって良い。ステップＳ７０２で、予約が取れた場合は、ステップＳ７０３へ遷移する。予約が取れなかった場合は、ステップＳ７１０へ進む。

ステップＳ７０３では、予約を移譲する意思があるかどうかを入力する。予約を移譲する意思があれば、ステップＳ７０４で、その予約移譲に関する情報の設定（入力し登録する）を行う。予約移譲に関する情報には、例えば希望する変更先の便の指定、割引率なども含まれる。設定終了後はステップＳ７０５の処理に移る。ステップＳ７０３で予約移譲の意思がないと入力した場合は、そのままステップＳ７０５の処理に移る。なお、ステップＳ７０３とステップＳ７０４は、ステップＳ７０１で、同時に行っても良いし、ステップＳ７０１の後に、続けて行っても良い。

ステップＳ７０５では、予約変更のためのマッチング処理を、事業者のサーバなどで実施する。マッチングの対象は、例えば指定の予約を必要とする予約者Ｂと、予約者Ｂが必要とする予約確保している予約者Ａとの間で行われる。マッチングが成立とは予約者Ａが確保した予約を予約者Ｂに譲り、予約者Ａが新たな予約を確保する、すなわち別の日や時間など異なる条件の予約に変更することになる。

ステップＳ７０５におけるマッチング処理の結果、ステップＳ７０６にて、マッチングが成立した予約移譲案件があれば、ステップＳ７０７の処理に移る。予約移譲案件が無ければ、ステップＳ７１３に進み、予約が決定し、その旨が利用者に伝えられ処理は終了する。

ステップＳ７０７では、予約の移譲が求められる利用者に対して、予約移譲の通知を行う。予約移譲情報の通知手段は、メール、ホームページ掲載、電話など、その手段の種別は問わない。ステップＳ７０８で、利用者は予約の移譲とそれに伴う、自分の予約の変更を行うか否かを入力する。その結果、予約の移譲と自分の予約の変更を行わないと入力した場合は、ステップＳ７１３の処理に移る。予約の移譲と自分の予約の変更を行うと入力した場合は、ステップＳ７０９の処理に移る。ステップＳ７０９では、予約を必要とする予約者への予約の移譲と自分の予約の変更に対する処理を実施する。この際、予約を移譲したものが新たな予約を確保する、すなわち自分の予約を変更する処理を行うが、これは「ダフ屋」的行為を防止する手段にすぎないため、「ダフ屋」的行為の可能性がない場合は、自分の予約の変更を行う処理を実施しなくてもかまわない。例えば、予約を移譲して、自分の予約を変更せずキャンセルした場合は、特典を受けないなどの処置を実施するなど、「ダフ屋」的行為の防止が行われれば、自分の予約の変更を実施しなくてもかまわない。前記の処理が済めば、ステップＳ７１３に進み、予約を決定する処理がなされ、その予約を利用者が確認する。

ステップＳ７０２で予約が成立しなかった場合は、ステップＳ７１０の処理に移る。ステップＳ７１０では、前記予約を取るために、利用者はマッチングの処理要求を、事業者などに対して行う。マッチングの要求は携帯電話やパソコンのメール、電話、窓口での依頼など、様々な形態で可能である。マッチングの要求をしない場合は、そのまま処理を終了する。この場合は、予約を「あきらめた」ということになる。なお、マッチングの要求をする場合は、ステップＳ７１１へ進む。

またステップＳ７０２は、場合によっては無くてもよく、図８以降に示す実施例においてはステップＳ７０２が無い場合を想定している。

マッチングの要求を受けた、事業者側などのサーバは、ステップＳ７１１で、利用者の希望する予約の獲得のために、「予約を必要な利用者に譲っても良い」という利用者の予約移譲データベースの検索処理を行う。検索処理の結果、ステップＳ７１２で検索結果について、利用者が、その内容で良いか否か判断し、良いと入力した場合はマッチングが成立したとして、ステップＳ７１３に進み予約処理は完了する。マッチングの成立とは、指定の予約を必要とする予約者が、予約移譲データの中から、良いと思うものを選択し、予約獲得のための条件に対して了承するとの入力を行い、その予約に対する予約確保の意思を入力し登録することである。またステップＳ７１２でマッチングが不成立であれば、次の案件に変更し、検索条件を変えるなどして、再度ステップＳ７１０から処理をやりなお、す。

次に図８〜図１６を用いて、本発明の実施例として、具体例を挙げて説明する。図８では、本実施例が提供するシステムを利用する一般の予約希望者の予約設定に関する処理の流れについて一部の例を示している。

なお、図８〜図１２までのフローに関する、図形の意味を凡例として８１０に示した。利用者などの操作は図形８１１で、プログラムの使用によるマシン処理は図形８１２で、同様にマシンによる判定処理は８１３で、マシンによる不正防止処理は８１４で示している。

まずステップＳ８０１で、予約希望者８０１は、パソコンのウェブ上の画面若しくは携帯電話から希望便名、会員番号又は個人情報などを入力する。予約希望者８０１は指定の予約を強く望む利用者及び予約を譲っても良い利用者など、予約を希望する利用者である。ただし図８に関しては指定の予約を強く望む利用者を予約希望者８０１としている。この時、必要に応じて予約を移譲することを希望するものは、予約のマッチング処理の制限時間を指定することができる。予約希望の入力画面の一例を図１３に示す。図1の如く事業者に接続すると、事業者からメニューが送られてくる。予約希望メニューを選択すると図１３に示す入力項目が表示され、カーソルの移動に沿って入力を行い、ＯＫボタン１３０１を押すと、予約希望の入力データが確定し、事業者マッチング処理サーバ装置８０３に、その情報が送信される。前記で述べた制限時間は、仮に今もっている予約を必要とする者に移譲する場合、予約を譲る者の中には予約の変更に伴う様々な作業が発生する者もいることに対処したものである。即ち、制限時間を設けることで、突然の予約変更を避けることができる。予約を譲る場合でも、安心して予約移譲希望を登録でき、大変便利である。また、この制限時間の設定は、通常の予約希望者で、指定の予約しか欲しくない者にとっても有効である。ぎりぎりまで予約を待つことができない場合、予約の制限時間を設定できれば、自らの予定を決めることができ、非常に都合が良い。

次にステップＳ８０２では、事業者マッチング処理サーバ装置８０３において以下の処理を実施する。まず、予約希望者などから入力されたマッチング要求基本データをデータベースなどに作成する。マッチング要求基本データは、マッチング要求番号Ａ、マッチング要求年月日Ｂ、マッチング要求時刻Ｃ、マッチング制限時間Ｄ及び該当予約コードＩからなり、マッチングステータスＪは１のマッチング先連絡待ちに設定する。なお、Ｉの該当予約コードとは、予約する者が、取得を強く望む飛行機の便の名称などである。次にステップＳ８０４で、予約希望者の個人情報と該当予約コードＩを事業者一般予約処理サーバ装置８０４へ送信し、ステップＳ８０３で処理する。ついで事業者一般予約処理サーバ装置８０４でマッチング（検索）の処理が行われ、抽出された住所・氏名・電子メールアドレス・電話番号・関連情報Ｗ及び一般予約識別番号Ｒに関する、予約希望者に関する情報をステップＳ８０５で送信する。送信情報は事業者マッチング処理サーバ装置８０３へ送られ、ステップＳ８０２の「抽出情報Ｗ、Ｒ、予約希望者Ｒを受信」のステップで受信される。なお、一般予約識別番号Ｒとは、指定の予約を行いたいと強く願う予約者の識別番号である。次にステップＳ８０２の「Ｗ全てにメール配信」のステップでは、抽出された一般予約識別番号に該当するメールアドレスなどＷにメールなどを配信する。ステップＳ８０２はマッチングチング制限時間Ｄ内で、その処理を継続し続ける。

ステップＳ８０３は、事業者一般予約処理サーバ装置８０４が、ステップＳ８０４で通知された予約希望者の個人情報と該当予約コードＩから予約希望者と予約移譲希望者などの予約関連情報のマッチング（検索）の処理を行い、その結果を事業者マッチング処理サーバ装置８０３に送信するステップである。以下、その処理内容を述べる。

ステップＳ８０３では、まずステップＳ８０４で入手した、予約希望者の個人情報と該当予約コードＩを受信する。次にマッチング要求基本データの該当予約コードＩと電子予約基本データの予約コードＳとのマッチング（検索）の処理を行う。次にマッチングした該当者のメールアドレスＷを抽出。予約希望者の電子予約基本データ（一般予約識別番号Ｒ、予約コードＳ、予約期間Ｔ、住所・氏名・電子メールアドレス・電話番号・関連情報Ｗ）を完成させる。次にマッチング（検索）の処理で抽出した電子メールアドレスなどＷ・一般予約識別番号Ｒ及び予約希望者の一般予約識別番号Ｒを事業者マッチング処理サーバ装置８０３に送付し、ステップＳ８０２の受信の処理で受信する（ステップＳ８０５）。このステップＳ８０２〜ステップＳ８０５の処理はステップＳ８０１で設けた制限時間内で継続して実行される。

図９で予約移譲通知に関する処理の流れの一例を説明する。まずステップＳ９０１では、予約を譲っても良いとする利用者である予約移譲対象者・予約移譲希望者８０２に対して、「予約移譲の意思があるか、どうか」に関する確認結果を入力する。入力データから予約移譲の意思があると判断されればステップＳ９０２の処理に移る。予約移譲の意思が無いと判断されれば、本処理は終了する（図示せず）。この際、予約移譲の意思と同時に、予約を移譲した後の、予約移譲者の変更後の予約情報も設定するようにもできる。

なお、前記記述で、予約移譲対象者あるいは予約移譲希望者と分けた。予約の移譲は決まったが自分の予約変更をする必要がある利用者などは、この利用者を予約移譲対象者と呼ぶ。まだ予約の移譲が決まっていない利用者を予約移譲希望者と呼ぶ。

この通知画面の一例を図１４（Ａ）に示す。通知内容に対して、予約の移譲条件を設定する場合にはＵＲＬ１４０３にアクセスする操作を行う。アクセスすると、図１４（Ｂ）で示す画面が表示される。その画面で必要に応じて、予約の変更可能日の設定入力などをシステムに対して行う。予約の移譲希望登録と変更後予約の設定を行う場合は、ＯＫボタン１４０４を押す。すると以下で説明する予約の移譲に関する処理が図１４（Ａ）で表示されている案件について実施例で説明したシステムで開始される。キャンセルボタン１４０５を押すと、図１４（Ａ）で表示されている案件についての予約の移譲に関する処理は行われない。

図１４（Ｂ）の画面における予約の変更に関する設定で、予約を移譲した利用者は、変更可能日時などの条件設定入力などの操作をシステムに対して行う。予約の変更に関する結果をシステムから図１６に示す予約確認通知で受ける。予約の変更処理は、本実施例が提供するシステムで自動的に行う。その際、移動手段やルートをシステムが検索し、変更条件に沿う予約又はその一覧をシステムで抽出し、予約変更希望者にその予約又は一覧を利用者に通知する。

予約確認通知は、候補が複数存在する場合には、図１５（Ａ）に示すように、予定変更希望一覧をシステムにより携帯電話やパソコンなどの画面に表示してもよい。すなわち譲った予約の代わりとなる予約で、なおかつ譲った者が指定した条件に合致する予約の一覧がシステムにより、情報公開される。その場合、利用者は図１５（Ａ）の中から変更後の希望予約を選択する。希望予約の選択は複数でもかまわない。選択する際は１５０１に示すようなＵＲＬ経由で設定しても良いが、予約登録先のレコードにＵＲＬの欄を表示せず、チェックボックスなどを設けて、チェックを入れるようにしても良い。予約を複数選択した場合は、前記システムで予め設定した優先順位（図示せず）に応じて確実に変更後の予約をシステムが獲得してくれる。

次にステップＳ９０２で、事業者マッチング処理サーバ装置８０３はステップＳ８０１で設定入力された制限時間内であれば、ステップＳ９０３の処理を実施し、制限時間若しくは制限時間外であれば、ステップＳ９０４の処理を実施する。まずステップＳ９０３の処理では、マッチング受付基本データ（マッチング受付番号Ｋ、一般予約識別番号Ｌ、マッチング受付時刻Ｍ、マッチングステータスＱ＝ランダム抽出待ち６）をシステムが作成する。また一般予約識別番号Ｌとマッチング先一般予約識別番号Ｈで合致するマッチング要求基本データのマッチングステータスＪをランダム抽出待ち５に設定する。

ステップＳ９０４では、マッチング受付基本データ（マッチング受付番号Ｋ、一般予約識別番号Ｌ、マッチング受付時刻Ｍ、マッチング結果Ｎ＝マッチング不成立２、マッチングステータスＱ＝不成立５）をシステムが作成する。また一般予約識別番号Ｌとマッチング先一般予約識別番号Ｈで合致するマッチング要求基本データのマッチング結果Ｆを不成立２に設定、マッチングステータスＪを時間切れ４にシステムが設定する。本処理完了後に予約希望者（予約を譲ってもらってでも予約したい利用者）や予約移譲希望者（予約を譲っても良い利用者）に時間切れの情報をメールで利用者にシステムが通知する。

図１０で予約変更のためのマッチング処理について、その処理の流れの一例を説明する。まず事業者マッチング処理サーバ装置８０３で以下の処理を行う。はじめにステップＳ１００１でマッチング処理継続に関する制限時間の監視をシステムが行う。次にステップＳ１００２で制限時間のチェックをシステムが行う。制限時間に達していなければ、ステップＳ１００１に戻る。制限時間に達した場合は、ステップＳ１００３の処理に移る。ステップＳ１００３では予約移譲を行った予約移譲者の変更後予約と既存予約のチェックをシステムが行う。変更後予約は予約を譲った利用者が、譲った予約の変わりに自分の予約を変更するというものである。また既存予約とは、予約を譲った利用者が、譲っても大丈夫なように前もって別の予約を行う行為のことである。これは「ダフ屋」的行為の防止のために実施する。もし、このような心配が無ければ省略することも可能である。

次にステップＳ１００４で前記した、変更後予約があり、かつ同一既存予約が無ければステップＳ１００５の処理に移る。もしそうでなければステップＳ１００６の処理に移る。ステップＳ１００６では、マッチング受付基本データ（マッチング受付番号Ｋ、一般予約識別番号Ｌ、マッチング受付時刻Ｍ、マッチング結果Ｎ＝マッチング不成立２、マッチングステータスＱ＝不成立４）をシステムが作成する。前記のデータに基づき、予約移譲希望者へ抽選漏れの通知をシステムが利用者に対して行う。

前記の処理は、例えば図２のマッチング要求番号Ａが２のレコードと、図３のマッチング受付番号Ｋが２のレコードが、この処理の一例に該当する。

ステップＳ１００５では、システムがランダムに抽出処理を行う。もちろん抽出の際に、予約を入れた時間の早い者や予約移譲に対するサービスの設定内容によって優先順位を設けてもかまわない。ランダムに抽出処理終了後はステップＳ１００７の処理に移る。ステップＳ１００７では抽出該当者以外のものに対しては前記したステップＳ１００６の処理を行う。抽出該当者に対しては、ステップＳ１００８の処理を行う。

ステップＳ１００８では、以下の処理をシステムが行う。まずマッチング受付基本データ（マッチング受付番号Ｋ、一般予約識別番号Ｌ、マッチング受付時刻Ｍ、マッチングステータスＱ＝受付完了１）を作成する。次に一般予約識別番号Ｌとマッチング先一般予約識別番号Ｈで合致するマッチング要求基本データのマッチングステータスＪをマッチング先連絡待ち１に設定する。次に予約移譲者向けに、予約意思を指定するＧＵＩを構築する。もちろん既に用意した画面を表示しても良い。次にマッチングステータスＪに予約指定待ち２を、マッチングステータスＱに予約指定待ち２を設定する。前記の予約移譲希望者（予約を譲っても良い利用者）の予約移譲関連情報を事業者一般予約処理サーバ装置８０４に送付する。次に事業者マッチング処理サーバ装置８０３では、変更後予約Ｒを受信する。ステップＳ１００８は処理待ちループであるステップＳ１００１とステップＳ１００２で制限時間を監視した後に実行される。

また処理システムの状況に応じて、ステップＳ１００３からステップＳ１００８までを処理のループの対象となるようにしてもかまわない。すなわちステップＳ１００２をステップＳ１００８とステップＳ１００９の間に処理されるようにする。さらに、ステップＳ１００１の直後に時間間隔をチェックするステップを設置する。この時間間隔をチェックするステップでは、例えば前回のステップＳ１００３からステップＳ１００８の処理から１時間経過していない場合で、なおかつ制限時間以内はステップＳ１００１に戻るようにする。一方、１時間経過経過している若しくは、制限時間に達した場合はステップＳ１００３からステップＳ１００８の処理が行われるようにしても良い。

次に事業者一般予約処理サーバ装置８０４はステップＳ１００９の処理を行う。ステップＳ１００９では、ステップＳ１００８で作成した予約移譲希望者に関する情報をシステム間で受信する。変更後の予約に関する情報を電子予約基本データベースに登録する。変更後の予約に関する情報には、一般予約識別番号Ｒ、予約コードＳ、予約期間Ｔ、住所・氏名・電子メールアドレス・電話番号・関連情報Ｗがある。変更後の予約に関する情報として、一般予約識別番号Ｒを事業者マッチング処理サーバ装置８０３に送信し、予約変更のためのマッチング処理（検索の処理）は終了する。

図１１で予約決定・確認の処理について、その処理の流れの一例を説明する。図１１においては指定の予約を強く望む利用者を予約希望者８０１としている。まず予約希望者８０１が、ステップＳ１１０１で、Ｗｅｂ画面や携帯電話などから予約の意思があることを示す操作を行う。その指示を受けたシステムは、そのデータを事業者マッチング処理サーバ装置８０３に送信する。予約希望者８０１が予約の意思を伝える画面の一例を図１６に示す。図１６に示すように、予約者は自分の氏名と予約便などの確認をし、その内容で良ければＯＫボタン１６０１を押す操作を行う。予約確認の内容には図１６に示した内容以外に割増率などの情報も加えて確認画面に表示されることもある。複数の移譲された予約案件がある場合は、システムが一定の基準で予約案件を抽出しても良いが、予約案件の一覧を予約希望者８０１に開示し、そこから選ばせるようにしても良い。

予約案件の一覧の例を図１５（Ｂ）に示す。すなわち指定の予約を強く望む利用者が必要とする予約に関して、予約を譲っても良いと申し出た予約の一覧がシステムにより携帯電話やパソコンなどの画面上に情報公開されている。希望する予約には、譲り受けたいと願う予約を移譲されることを希望する利用者のサービス提供条件など（割増率）と、譲っても良いとする予約移譲者の希望など（移譲者の特典）の様々な条件がついている。例えば譲り受けたいと願う予約移譲希望者のサービス提供条件など（割増率）は譲っても良いとする予約移譲者の希望など（移譲者の特典）の値からシステムによって算出された値である。従って譲り受けたいと願う予約移譲希望者が、譲る代わりに提供するサービス提供条件をマッチング処理の申し込み時に設定する操作を行っている場合は、自分の提供条件を満たしているものだけ画面に表示させるようにシステムに対して設定することもできる。また自分の提供した条件を外れているものを選んだ場合に警告を発するように設定することもできる。指定の予約を強く必要とする予約の希望者は、これらの予約一覧画面から希望するものを選択することもできる。選択の際は、ＵＲＬ１５０２などにアクセスし、その詳細などを確認して予約を確定するための操作を行う。その指示を受けてシステムが予約を確定する。あるいはＵＲＬの欄を表示せずに予約登録先のレコードに予約確定ボタンなどを並べて、即座に予約をできるようにしても良い。

このように予約の移譲情報一覧を携帯電話やパソコンの画面に情報公開することで、予約を譲り受けたい利用者は、より割増率などが低い予約を指定でき、予約を譲ってもらえる可能性が増す。さらに予約を譲り受けたい利用者のサービス条件を外れている移譲情報しかない場合にも、その情報を知ることで、場合によっては指定したサービス条件を外れてでも予約を行うことができるケースも発生する。また予約の移譲が滞っている場合は、予約を譲っても良いとする利用者が自ら移譲者の特典の条件を下げるなどの操作をし、移譲しやすくするなどの操作も可能にすることができる。さらにこの割増率や移譲者の特典の値を、予約を譲って欲しい利用者と予約を譲っても良い利用者の間で、上げ下げすることでチケットのオークション的な取引をシステムで実施できるようにしても良い。このように前記した様な機能を加えることで、予約獲得のチャンスをさらに増やすことができる。

また図１６の予約確認操作において、予約の内容が自分の希望に合わないなどの理由で予約しない場合はキャンセルボタン１６０２を押す。キャンセルボタン１６０２を押すと、利用者は制限時間まで予約の確認のメールがシステムから送信されてくるのを待つことになる。予約の内容が自分の希望どおりなどの理由で、予約すると決めたなら、ＯＫボタン１６０１を押す。ＯＫボタン１６０１を押すことで予約の意思を示しステップＳ１１０２の処理に移ることになる。

ステップＳ１１０２では、事業者マッチング処理サーバ装置８０３が以下の処理を行う。まずシステムが予約意思の確認を受けて、マッチング要求基本データにマッチング成立時間Ｅ、マッチング結果Ｆ＝成立１、新一般予約識別番号Ｇ、マッチング先一般予約識別番号Ｈを設定する。次にこの成立情報をステップＳ１１０３で、事業者一般予約処理サーバ装置８０４への通知処理を実施する。次に、事業者一般予約処理サーバ装置８０４における予約移譲者関係のデータに関する変更処理の終了通知をステップＳ１１０５で事業者一般予約処理サーバ装置８０４が送信し、ステップＳ１１０２で事業者マッチング処理サーバ装置８０３が受信する。その終了通知を受けて、事業者マッチング処理サーバ装置８０３のステップＳ１１０２の処理では、予約移譲の成立に関する情報を予約移譲希望者、予約移譲者、あるいは予約希望者へ通知する処理を実施する。なお、予約移譲希望者あるいは予約移譲者と分けた。予約の移譲が決まっていない利用者を予約移譲希望者と呼ぶ。予約の移譲は決まったが、予約を移譲した代わりに自分の予約の変更をする必要がある利用者などは、この利用者を予約移譲者と呼ぶ。

事業者マッチング処理サーバ装置８０３では、次にシステムが、マッチング要求基本データのマッチングステータスＪを成立（メール発信済み）３にセットする。ついで、マッチング受付基本データのマッチング結果Ｎに成立１を、変更後一般予約識別番号Ｏと移譲先一般予約識別番号Ｐをセットし、マッチングステータスＱに成立（メール発信済み）３をセットする。以上で予約決定と確認に関する処理は終了する。これは、例えば図２の例ではマッチング要求番号Ａが１のレコードが、図３の例ではマッチング受付番号Ｋが１のレコードが、この処理の一例に該当する。

ステップＳ１１０４は、事業者一般予約処理サーバ装置８０４が予約移譲者関係のデータに関する変更処理を行い、事業者マッチング処理サーバ装置８０３にステップＳ１１０５で、その終了結果を通知するステップである。以下その処理を説明する。まず、ステップＳ１１０３で事業者マッチング処理サーバ装置８０３によって送信された成立通知を事業者一般予約処理サーバ装置８０４が受信する。次にシステムで、予約移譲希望者に関するデータである以下のデータを電子予約基本データにセットする。まず予約年月日Ｕ・予約時刻Ｕ、料金Ｖ・発生マイレージＶをセットする。マッチングフラグＸには「あり（要求側）」２をセット、マッチング要求番号Ｙにはマッチング要求番号Ａ、マッチング受付番号Ｚにはマッチング要求番号Ａをセットする。

予約移譲者の移譲前の予約レコードには、マッチングフラグＸに「あり（受付・変更前）」１をセット、マッチング受付番号Ｚにマッチング受付番号Ｋをセットする。例えば図６の例では一般予約識別番号Ｒが２のレコードが、この処理の一例に該当する。

予約移譲者の変更後予約に関するレコードに関しては、予約年月日Ｕ・予約時刻Ｕ、料金Ｖ・発生マイレージＶをセットする。またマッチングフラグＸには「あり（受付・変更後）」３をセット、マッチング受付番号Ｚにはマッチング要求番号Ａをセットする。例えば図６の例では一般予約識別番号Ｒが５のレコードが、この処理の一例に該当する。

以上で予約移譲者関係のデータに関する変更処理を終了し、本処理の終了通知を、ステップＳ１１０５で事業者マッチング処理サーバ装置８０３に行い、ステップＳ１１０４の処理を終了する。

図１２で予約の取消・変更の処理について、その処理の流れの一例を説明する。まずステップＳ１２０１で、予約希望者８０１は、予約の取消又は変更の操作を行う。このステップで、処理の対象となる利用者は、主に予約移譲対象者８０２などであるが、予約を譲り受ける利用者もチェックの対象になることもある。予約希望者８０１は指定の予約を強く望む利用者及び予約を譲っても良い利用者など、予約を希望する利用者である。

予約の取消・変更の処理について、事業者マッチング処理サーバ装置８０３では、システムで以下の処理を行う。まずステップＳ１２０２で、予約成立者の不正をチェックし、不正予約の防止を図る。不正者には、例えば予約移譲者であれば、「ダフ屋」的行為によって不当に利益を得る者がいる。また指定の予約を希望する者の中には、一人で複数の予約を行い、その予約確率を上げようとする者もいる。本発明が提供する方法に基づく実施例ではこれらの不正を以下の方法によって防止できる。

まずステップＳ１２０３で、電子予約基本データの一般予約識別番号Ｒがマッチング要求基本データの新一般予約識別番号Ｇと同一である場合、これは予約を譲っても良いとしている予約移譲者が前もって、同じ予約を複数行っている場合であると判断される。この場合は、予約移譲者は予約を譲ることによって、当初の予約を失うことがない。そのため、サービスだけを受けて、自分の予定には何ら影響がないことになる。このような、利用者に対しては、ステップＳ１２０４でシステムにより自動的にサービスを停止するなどの処置を行っても良い。また、変更後の予約をキャンセルする際にキャンセル料を請求する、あるいは変更後の予約の取消をさせない、さらなる変更をさせないといった処置をシステムで自動的に実施することも可能である。このような措置により、利用者の不正を防止し、安心してシステムを運用できる。

また一般予約識別番号Ｒが０である場合は、予約の成立を破棄している利用者であり、他の利用者に迷惑がかかる。このような場合にもステップＳ１２０４で、システムがチェックを行い。キャンセル料などを請求するようにして、前記のような行為を防止することができる。またステップＳ１２０４では、このような利用者の住所・氏名・電子メールアドレスなどの情報Ｗを自動的に記憶し、度重なる不正行為者にはシステムの使用を許可させないようにシステムで制御することもできる。

また、ステップＳ１２０６では抽選漏れした利用者に対して、不正防止のためのチェックをシステムが行う。ステップＳ１２０７で電子予約基本データの一般予約識別番号Ｒがマッチング受付基本データの一般予約識別番号と合致し、かつマッチングステータスが不成立（ランダム抽出漏れ）４で、なおかつ一定期間内に同一サービスに対する予約がある場合、同一予約獲得のための複数回予約行為とシステムで判断されステップＳ１２０８で不正対応策をシステムで行う。ステップＳ１２０８では、このような利用者に対して自動的に予約のキャンセル料を請求する。あるいは前記したケースにおけるような不正目的の予約の取消や変更をできなくするなどの処置をシステムの処理に設定することができる。またステップＳ１２０８でも、このような利用者の住所・氏名・電子メールアドレスなどの情報Ｗをシステムが自動的に記憶し、度重なる不正行為者にはシステムの使用を自動的に許可させないようにシステムの処理を変更することもできる。こうすることで、一部の利用者がシステムを独占することなく、利用者が平等な条件でシステムを利用できるようになる。

なお、ステップＳ１２０３及びステップ１２０７でチェックにかからなかった場合は、ステップＳ１２０５で通常どおり取消処理ができる。

図２０から図３３に示す画面イメージを用いて、本発明の方法に基づくシステムの具体的な、利用例を説明する。まず図２０に、マッチング（検索）の処理による転売操作無しの通常の予約で、指定した予約が取れないが、その予約を強く必要とする利用者がマッチング（検索）の処理による転売操作有りの予約を行う場合に操作するシステムの予約画面の例を示す。画面の２００２には、利用者の予約希望内容が入っている。予約希望者はエリア２００３で示した「ご提供いただけるサービス」の中から、チケットを譲り受ける際に提供するサービスの種類と内容を指定する。例えばチケットを譲り受ける代わりに運賃を５０００円提供しても良い場合は、エリア２００３の運賃欄をチェックし、横の金額記入欄に５０００と入力する。ついで、エリア２００４に必要事項を記入し、ＮＥＸＴボタン２００５を押す。本画面の処理を破棄したい場合はＣＡＮＣＥＬボタン２００６を押す。ＮＥＸＴボタン２００５を押すことで、図２１に示す画面が表示される。

図２１の画面は、指定の予約を強く必要とする予約者のチケットの予約内容と移譲を受ける際の条件（提供するサービスなど）などの確認画面である。エリア２１０２で示した内容でＯＫである場合は、ＲＥＳＥＲＶＥボタン２１０３を押す。ＣＡＮＣＥＬボタン２１０４を押せば、図２０で設定した内容の予約は破棄され予約登録は行われない。ＲＥＳＥＲＶＥボタン２１０３を押すと図２０で設定した内容の予約登録がシステムによって行われ、予約確認画面（図２２）が表示される。チケットの予約成立はエリア２２０２に示しているように、予約成立後にシステムからメールで連絡される。あるいは指定のＵＲＬから利用者がシステムに確認することもできる。

図２３は、本実施例の予約システムへ顧客情報を登録する場合に用いる手続画面の一例である。２３０２には利用客の個人情報などが携帯電話やパソコンなどの画面に表示されている。これらの情報は、予め事前の処理（図示せず）で、入力されている。チケット予約時に、「予約の移譲が可能な予約の移譲処理」を望む場合は、移譲メール希望２３０３で「希望する」をチェック、希望しない場合は「希望しない」をチェックする。「希望する」をチェックした場合、チケットの移譲希望者がいる場合などに、チケット予約時に移譲メール希望の有無の伺いをシステムから通知され、その結果を指定することになる。さらに「予約の移譲に対するサービス」に対する条件などがある場合は、これを指定しても良い。この場合、利用者自身の予約に関する情報は公開されるが、利用者自身のメールアドレスなどの個人情報は一切公開されず、予約移譲などに関する処理はすべてシステムが代行してくれる。従って個人情報が外部に漏れる心配は一切ない。ただし、進んでシステムに情報を公開したい場合は、公開したい情報を個別に選択して、その情報のみを情報公開できるようにしても良い。また「希望しない」をチェックした場合は、チケットを譲っても良いとする予約移譲者としてチケット移譲のためのマッチング（検索）の処理の対象とはならず、移譲伺いのメールが事業者側のサーバなどから送信されることはない。さらに自分の予約に関する情報は一切、他の利用者には公開されない。図２３の画面の内容でＯＫであれば、ＲＥＧＩＳＴＥＲ２３０４を押し、この内容をシステムに登録する。ＮＧであればＣＡＮＣＥＬ２３０５を押して、登録しない。

図２４は、航空券の予約手続画面の一例である。チケット予約時にエリア２４０３で「希望する」を選択すると、移譲の（チケット譲る）際、譲った代わりに取る自分の予約の条件を指定することになる。「希望しない」を選択すれば、移譲しても良い予約としては処理されず、移譲に関するメール（「チケットを譲ってください」といった内容のメール）もシステムから送られてこない。

図２５はチケットを譲る際、その代わりとなる自分の予約（変更後予約）に対する条件を指定する画面の一例である。利用者はエリア２５０２に予約（変更後予約）の変更希望内容を入力する。チケットを譲ることが決まった際は、この画面で設定した条件に沿う内容のチケットがシステムによって自動的に予約される。図２５で示す変更先の予約がシステムによって確約された場合に、システムは自動的にチケットを譲る手続にはいる。仮に、チケットの移譲が成立したにもかかわらず予約を譲った利用者の予約変更が失敗する事態が生じた場合は、システムで先の予約移譲処理を取消して、予約を移譲する直前の状態に自動的に復帰することもできる。図２５の内容でＯＫであれば、利用者はＮＥＸＴ２５０３ボタンを押して、予約の登録を完了させる。予約の完了画面に関する図と操作説明は省略する。ＣＡＮＣＥＬ２５０４ボタンを押せば、図２５の内容は破棄され図２４の画面に戻る。

図２６は、システムからの移譲伺い確認メールの画面の一例である。メールはシステムの事業者あるいは航空会社２６０４などから、予約移譲を希望した（予約を譲っても良いと設定していた）利用者２６０３宛にシステムから送付されてくる。メールにはエリア２６０５に示すように「チケットを譲ってください」という内容が書かれている。チケットを譲ることが可能であれば、画面に書かれたＵＲＬを選択して変更操作画面（図示せず）を表示し、そこから変更可能な便を探して、予約の変更のための操作を行う。その操作に従って予約の変更がシステムで実行される。

図２７は予約チケットを譲ることを決めた利用者が、本実施例のシステムで自分の予約を移譲することに対する、システムからの予約移譲上の注意事項の通知とそれに対する同意確認の画面の一例である。システムにおける予約移譲者（予約を譲る利用者）は自分以外にも複数存在することがあり、自分以外の利用者が予約の移譲を成立させてしまい、自分は前の予約に戻されることがある。エリア２７０２には、その内容が書かれており、その内容に同意する場合は「同意する」ボタン２７０３を押す。「同意する」ボタン２７０３を押すと、予約移譲に関する処理がシステムにより続行される。「同意しない」ボタン２７０４を押せば、図２６で受けたメールに対する予約の移譲に関する処理は行われない。その場合は、システムから別の移譲伺いのメールを再び待つことになる。制限時間までに「同意する」ボタン２７０３を押さなければ、予約の移譲の不成立が確定する。

図２８は、予約移譲と予約変更が実施可能となった時にシステムから通知される携帯電話などの画面の一例である。「指定の予約の取得を強く望む利用者」に譲った、前の予約内容がエリア２８０２に、譲った予約の代わりに予約した新しい予約の内容がエリア２８０３に、自分の氏名・連絡先がエリア２８０４に表示されている。予約を譲る代わりに、変更後の便の運賃が５０００円割引になっている。内容を確認したらＮＥＸＴボタン２７０５を押す。参照を中止するのであればＣＡＮＣＥＬボタン２７０６を押し、この画面を閉じる。ＮＥＸＴボタン２７０５を押すと、予約移譲手続完了待ちの確認画面（図２９）が表示される。図２９のエリア２９０２に示すようにチケットの移譲成立とそれに伴う予約の変更完了は、後でシステムからメールで通知される。またＵＲＬから、その結果を参照することもできる。

またシステム運営上の環境に応じて、システムが予約移譲と予約変更を完了させた時点で、図２８に記載した内容の通知がシステムから行なわれるようにしても良い。また図２８、図２９の通知後に予約移譲と予約変更が実施されないことがないように予約システムを制御しても良いし、その間の緊急事態や不測の事態を考慮して、あえて予約移譲と予約変更のキャンセル処理ができるようにしても良い。

図３０（Ａ）は、チケットの予約が成立した場合にシステムから送られてくるメールの一例である。チケットの予約成立のパターンは、予約移譲無しで成立する場合、予約移譲を受けて成立する場合、予約移譲を行って変更予約が成立する場合の３とおりがある。この３とおりのパターンはそれぞれ事前に利用者が、予約移譲無しで予約、予約移譲を受けてでも予約、予約を移譲しても良いと指定して予約することによって発生しうるものである。図３０（Ｂ）はチケットを譲って、自分の予約も変更された場合にシステムから通知されるメールの一例である。図３０（Ｃ）はチケットを譲る希望をしていたが、そのチケットを譲ることができなかった場合にシステムから通知されるメールの一例である。

以上図２０から図３０では、チケットを譲る場合の例について具体的なシステムのイメージを用いて説明した。

「指定のチケットを譲り受けたい利用者」の具体的なシステムの操作画面は省略するが、予約移譲者が提示した条件をもとに、その予約を獲得する処理になる。予約獲得の優先順は、早い者順、もしくは予約を譲る者へのサービス額が高額であるものなどとなる。

この実施例の方法に基づくシステムを使用すると、チケットを譲ったものは、サービスを受けることができ、強くチケットを必要とする利用者もチケットが得る機会が増えるため、利用者にとっては大変便利である。また、予約を譲る際に、予約移譲者に対する予約変更の措置を設けるなどして、「ダフ屋」的行為への対策も行っている。従って、安心してシステムを利用できる。またチケットを移譲したものが新たな予約を入れることが原則であるためチケットの販売量も向上する。このように、本実施例の方法は、この実施例の方法を適用したシステムを搭載した航空会社などにも多大なるメリットをもたらすことができる。

図３１には、本実施例の方法によるシステムを実施した際のデータを元に予約移譲の統計を調べる場合の条件指定画面である。条件にはエリア３１０２で示したように、便名や出発地と到着地、期間などがある。システムによる分析結果の一例を図３２（Ａ）、図３２（Ｂ）、図３２（Ｃ）、図３３に示す。図で示すように、予約の移譲に関する様々な分析ができるため、機会損失のリスク分析、顧客層の分析、利用目的の分析に活用することができる。また図３３に示すように予約率・搭乗率・移譲成立率をシステムで各データベースのデータから分析することで、本実施例の方法によるシステム活用による搭乗率への影響なども確認できる。このような分析結果を得ることで、より利用者の側にたった運行予定やチケットの販売計画の策定に関する支援が行えるようになり、非常に有益である。また機会損失に関するリスクなどの分析の支援もできるため、実施例に示すシステムを搭載した航空会社などに多大なるメリットをもたらすことができる。

図１７から図１９までは、本発明の実施例に基づく適用例の一部を掲載した。図１７から図１９までの示した処理は、前記した実施例のシステムの機能により処理が実施される。図１７は、予約販売事業者を例にとった、販売プロセスの一例である。以下、そのプロセスを説明する。購入者Ａ１７０２が予約販売事業者１７０１に対して予約１７１１するための処理を行うための予約指示操作を行う。また購入者Ｂ１７０３が予約販売事業者１７０１に対して予約１７１２を行うための予約指示操作を行う。仮に購入者Ｂ１７０３が依頼した予約がシステムの処理によって成立しなかった場合、予約販売事業者１７０１の保持するサーバなどは購入者Ｂ１７０３に対して予約不成立に関する通知１７１３の処理を行う。それに対して購入者Ｂ１７０３は予約販売事業者１７０１に対して、割増予約依頼１７１４などのための依頼指示操作をシステムに対して行う。割増予約依頼１７１４とは、既に予約を獲得している利用者、例えば購入者Ａ１７０２が予約を確保していたとして、その予約を、割増料金を払うことによって獲得しようとする行為である。利用者の指示どおりシステムが割増予約１７１４を予約販売事業者１７０１のサーバなどに対して行った結果、システムの予約処理で予約が成立したと判断されると、予約販売事業者１７０１のサーバなどは購入者Ｂ１７０３に対して予約成立に関する通知処理１７１５を行う。その処理の後に、予約を譲った購入者Ａ１７０２は、購入者Ｂ１７０３に譲った予約に替わる予約の変更依頼１７１６の通知を、予約販売事業者１７０１のサーバなどから受ける。その通知を受けて、購入者Ａ１７０２は予約販売事業者１７０１のサーバなどに対して、予約変更に関する承諾と予約変更手続き１７１７の操作を行う。以上、述べたプロセスで指定の予約を必要とする購入者Ｂ１７０３は割増料金で必要な予約を、購入者Ａ１７０２より譲り受けることができる。

図１８には、図１７において説明した購入者Ａ１７０２と購入者Ｂ１７０３の入手チケットの具体的変更内容を示した。購入者Ａ１７０２は予約１８０１を確保していたが、購入者Ｂ１７０３に、前記実施例に示すシステムの機能により、そのチケットを譲り、割安で別の便のチケット１８０２を入手した。一方、指定の予約を必要とした購入者Ｂ１７０３は予約希望１８０３のチケットを入手できず、前記実施例に示すシステムの機能により、購入者Ａ１７０２から割増料金でチケット１８０４を入手した。従ってチケット１８０１とチケット１８０４の予約内容は同一であるが、指定の予約を購入者Ｂ１７０３が購入者Ａ１７０２から譲り受けたため、譲り受けたチケット１８０４は当初のチケット１８０１の料金より高くなっている。また本実施例のシステムでは購入者Ａ１７０２が手に入れた割引チケットを利用して「ダフ屋」的行為を軽減するために、同一利用者などによる同一内容のチケットの複数枚予約に対する防止策や利益を目的とした不当な理由でのキャンセルに対するキャンセル料金の高額設定などによる防止策などを行っている。

また、指定の予約が欲しいとして予約を行った予約希望者の予約キャンセルに関しても、必要以上の不当な予約依頼、例えば利用者一人が同一年月日の同一便に対して複数の予約を依頼するなどの行為、ができないようにそのキャンセル料の設定を調整するなどの操作も可能である。

図１９は航空券の予約を例にとった、予約券販売のプロセスの一例である。予約の変更が可能である予約移譲希望者である予約購入者Ａ１７０２は、初めにステップＳ１９０１で、転売管理システム１９００に対して航空券予約の操作を行う。予約の際、ステップＳ１９３１で予約購入者Ａ１７０２は、予約に加え、予約変更可否と必要に応じて予約変更条件などの申請を行う。予約変更を可にすると条件マッチング（検索）の処理ステップＳ１９０４で譲る側の予約情報として、その対象となる。さらに、予約変更条件には、待機期限・サービス内容の希望などがあるが、予約変更条件は無くてもかまわない。予約変更条件が無ければ、デフォルトで用意した予約変更条件の値がシステムにより設定される。予約変更可否の設定もデフォルト値が設定されているので、必要に応じて利用者が任意の設定指示をシステムに対して操作画面から行う。予約変更を不可にすると条件マッチング（検索）の処理ステップＳ１９０４で譲る側の予約情報として、その対象とはならない。なお、前記の申請内容は予約Ｍ１９２１に電子データとして保管される。

一方、指定の予約の取得を強く望む予約購入者Ｂ１７０３は、ステップＳ１９０２でシステムが提供する画面で予約状況紹介の操作を行ったが、システム処理のステップＳ１９３２により満席であり予約ができないという通知を転売管理システム１９００のサーバなどからメールなどで受け取る。予約購入者Ｂ１７０３は、指定の予約の取得を強く望んでいる。そのため、予約購入者Ｂ１７０３は、ステップＳ１９０３の操作によりシステムの画面で転売希望通知の操作を行い、転売希望の通知を転売管理システム１９００に対して行う。その希望内容は、システムにより、ステップＳ１９３３の登録処理で、電子データとして転売Ｍ１９２２に保管される。

こうして用意された予約Ｍ１９２１と転売Ｍ１９２２の情報から、転売管理システム１９００はステップＳ１９０４で条件マッチング（検索）の処理を行う。条件マッチング（検索）処理は、予約購入者Ａ１７０２と予約購入者Ｂ１７０３の予約券取得に関する取引条件の摺り合わせを行い、両者の取引を成立させ、両者の希望どおりの予約を行うために行う。システムによる予約条件のマッチング（検索）の処理の結果、マッチングが成立した場合はステップＳ１９３４で、転売管理システム１９００から予約購入者Ａ１７０２に転売依頼通知がメールなどで通知される。通知を受けた予約購入者Ａ１７０２は、ステップＳ１９０６で転売ができるか否かを判断し、その判断結果をシステムが提供する操作画面に入力設定し、ステップＳ１９３５で転売管理システム１９００に通知するための操作を行う。その操作指示による通知を受けて転売管理システム１９００はステップＳ１９０５の処理を開始する。ステップＳ１９０５では、予約購入者Ａ１７０２がシステムの操作画面で設定した内容に基づき、転売管理システム１９００で、予約購入者Ａ１７０２が前記処理で獲得していた予約券の転売が可能か否かを判断する。その結果、転売が可能であるとシステムで判断されると、転売管理システム１９００はステップＳ１９０８で、予約購入者Ｂ１７０３に対して、予約券の購入可能通知をメールなどで行う。転売が不可能であれば転売管理システム１９００はステップＳ１９１２で、予約購入者Ｂ１７０３に対して、予約券の購入不可能通知をメールなどで行う。

予約券の購入可能通知を受けた予約購入者Ｂ１７０３は、ステップＳ１９０９で購入手続操作を行う。購入手続に関するデータはステップＳ１９０９の購入手続操作の内容に基づいて、転売管理システム１９００により、ステップＳ１９３６で電子データとして送信されステップＳ１９１０で処理される。また予約購入者Ａ１７０２は、ステップＳ１９０７で、予約購入者Ｂ１７０３に譲った予約の代わりに別の予約を取る操作を実施する。その予約操作において、予約購入者Ａ１７０２は、その予約関連の情報入力などの操作を行う。この操作に対するデータは転売管理システム１９００によってステップＳ１９３７で、電子データとして送信され、ステップＳ１９１０で処理される。

ステップＳ１９１０では、前記の操作や処理で送られたデータに基づき、転売管理システム１９００は予約購入者Ａ１７０２の変更便に関する手続と予約購入者Ｂ１７０３の予約に関する購入手続の確定処理を行う。またこの際、転売管理システム１９００は予約購入者Ａ１７０２に対しては予約を移譲したことに対してサービス料金などの設定（ステップＳ１９１１での減算）処理を行う。また、予約購入者Ｂ１７０３に対しては指定の予約を譲り受けたことに対する割増料金の設定（ステップＳ１９１１での加算）処理を行う。これらの予約券の購入に関するデータは電子データとしてシステムにより自動的に購入Ｍ１９２３に保管される。

前記したように、本実施例の方法によれば、指定の予約の取得を強く望む利用者は割増料金の設定により、予約を譲っても良いという利用者から予約を譲り受けることが可能となり、予約を確実に取得する可能性が高まる。また予約を譲った利用者は割引サービスを受けることができる。この際、前記実施例の方法によれば、「ダフ」屋的行為の防止策を行い、適切な転売行為を成立させることができる。例えば予約を譲った者は別の予約を行うように管理するなどの処置を行う。従って予約券の販売率が、前記の転売操作により高まる。また、これらの転売データの分析により予約券の販売計画などの策定を支援することもできるため予約券を販売する側にとっても大変都合が良い。

このように本実施例の方法によれば、指定の予約を必要とする利用者、予約を譲った利用者、予約券を販売する業者など、それぞれの、希望をかなえることができる。

本発明が適用されるコンピューターシステムの一実施例の全体構成図である。 本発明の一実施例におけるマッチング要求基本データの一例を示す図である。 本発明の一実施例におけるマッチング受付基本データの一例を示す図である。 本発明の一実施例におけるマッチング電子予約基本データの一例を示す図である。 本発明の一実施例におけるマッチング電子予約基本データの一例を示す図である。 本発明の一実施例におけるマッチング電子予約基本データの一例を示す図である。 本発明の一実施例における操作及び処理のフロー図である。 本発明の一実施例における予約設定に関する操作及び処理のフロー図である。 本発明の一実施例における予約移譲通知に関する操作及び処理のフロー図である。 本発明の一実施例における予約変更のためのマッチング処理に関する処理のフロー図である。 本発明の一実施例における予約決定・確認に関する操作及び処理のフロー図である。 本発明の一実施例における予約取消・変更に関する操作及び処理のフロー図である。 本発明の一実施例における予約希望に関する操作画面の一例を示す図である。 本発明の一実施例における予約変更伺に関する操作画面の一例を示す図である。 本発明の一実施例における予約変更設定に関する操作画面の一例を示す図である。 本発明の一実施例における予約変更希望に関する操作画面の一例を示す図である。 本発明の一実施例における移譲予約選択に関する操作画面の一例を示す図である。 本発明の一実施例における予約確認に関する操作画面の一例を示す図である。 本発明の一実施例における予約移譲に関するビジネスモデルの一例を示す図である。 本発明の一実施例における予約移譲に関するビジネスモデルの一例を示す図である。 本発明の一実施例における予約移譲に関するビジネスモデルの一例を示すフロー図である。 本発明の方法を利用したシステム実例の、指定希望の予約に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約確認に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約承認に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、顧客情報の登録手続に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、航空券の予約手続に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、チケット移譲時の予約変更条件を指定する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、移譲伺いメールの確認に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約変更手続に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約移譲完了通知に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約移譲完了通知に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約の成立通知に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約移譲の成立通知に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約移譲の不成立通知に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約移譲の統計を調べる場合の条件指定に関する操作画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約移譲に関する年齢分析情報の結果表示画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約移譲に関する利用目的分析情報の結果表示画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約移譲に関する移譲マイル分析情報の結果表示画面の一例を示す図である。 本発明の方法を利用したシステム実例の、予約に関する統計情報の結果表示画面の一例を示す図である。

符号の説明

１０１ 実施例におけるマッチング要求基本データを保持するデータベース
１０２ 実施例におけるマッチング受付基本データを保持するデータベース
１０３ 実施例における電子予約基本データを保持するデータベース
１０４ 実施例における事業者マッチング処理サーバ装置
１０５ 実施例における事業者一般予約処理サーバ装置
１０６ 実施例における一般予約端末装置
１０９ 実施例におけるマッチング要求端末装置
２００ 実施例におけるマッチング要求基本データ
３００ 実施例におけるマッチング受付基本データ
４００ 実施例における電子予約基本データ
５００ 実施例における電子予約基本データ
６００ 実施例における電子予約基本データ
１３００ 実施例におけるシステムの予約希望画面
１４０１ 実施例におけるシステムの予約変更伺の画面
１４０２ 実施例におけるシステムの予約変更設定画面
１６００ 実施例におけるシステムの予約確認画面
２００１ 本発明の方法を利用したシステム実例の指定希望の予約に関する操作画面
２１０１ 実施例におけるシステムの予約確認に関する操作画面
２２０１ 実施例におけるシステムの予約承認に関する操作画面
２３０１ 実施例におけるシステムの顧客情報の登録手続に関する操作画面
２４０１ 実施例におけるシステムの航空券の予約手続に関する操作画面
２５０１ 実施例におけるシステムのチケット移譲時の予約変更条件を指定する操作画面
２６０１ 実施例におけるシステムの移譲伺いメールの確認に関する操作画面
２７０１ 実施例におけるシステムの予約変更手続に関する操作画面
２８０１ 実施例におけるシステムの予約移譲完了通知に関する操作画面
２９０１ 実施例におけるシステムの予約移譲完了通知に関する操作画面
３００１ 実施例におけるシステムの予約の成立通知に関する操作画面
３００２ 実施例におけるシステムの予約移譲の成立通知に関する操作画面
３００３ 実施例におけるシステムの予約移譲の不成立通知に関する操作画面
３１０１ 実施例におけるシステムの予約移譲の統計を調べる場合の条件指定に関する操作画面
３２０１ 実施例におけるシステムの予約移譲に関する統計情報の結果表示画面
３２０２ 実施例におけるシステムの予約移譲に関する統計情報の結果表示画面
３２０３ 実施例におけるシステムの予約移譲に関する統計情報の結果表示画面
３３０１ 実施例におけるシステムの予約に関する統計情報の結果表示画面

Claims (21)

1. チケット入手あるいは交換の支援を行うシステムであって、
   前記システムは入出力装置と記憶装置を有し、前記記憶装置にはチケットの予約に関するデータと、チケットの交換に関するデータ、チケット入手あるいは交換を支援するための入力画面に関する情報が記憶され、予約を希望する入力があると、希望の予約を確保する処理を行い、予約の確保の有無を上記希望者に連絡し、
   上記予約の確保の有無についての連絡において予約の確保無しの連絡を行った場合に対し、さらに予約確保の指示があると、予約確保者のデータベースを検索し、前記予約確保に対する移譲の有無を問い合わせる送信を行い、この問い合わせの送信に関し移譲承諾の回答を受信すると、予約に関する移譲可能の情報を予約希望者に送信し、予約移譲の処理を行うと共に移譲承諾者に対する新たな予約確保の処理を行うことを特徴とするチケット入手あるいは交換の支援を行うシステム。
2. 請求項１に記載のチケット入手あるいは交換の支援を行うシステムであって、予約を行う利用者に対するチケットの入手あるいは交換のための処理期限を入力する画面の情報を、予約を行う利用者に送信し、上記処理期限の送信に対する処理期限の回答を受信すると、上記受信した処理期限を記憶装置に保持し、前記処理期限を過ぎるとチケットの予約の移譲の処理を停止することを特徴とするチケット入手あるいは交換の支援を行うシステム。
3. 請求項１に記載のチケット入手あるいは交換の支援を行うシステムであって、
   利用者に対し予約を譲ってもよいかどうかを入力するための画像情報を送信し、上記画像情報に基づいて、利用者が予約を譲って良いことおよび譲った後の代わりの予約に対する条件を入力した情報を受信し、これを記憶し、前記移譲の処理に基づいて、記憶していた前記代わりの予約条件に従い、新たなチケットの確保のための処理を行い、新たなチケットの予約がなされると、その内容を記憶すると共に、新たなチケットが確保できたことを示す情報を利用者に送信することを特徴とするチケット入手あるいは交換の支援を行うシステム。
4. 請求項１に記載のチケット入手あるいは交換の支援を行うシステムであって、
   前記予約確保者のデータベースを検索し、予約を譲っても良い利用者の予約移譲の情報を含む予約に関する情報の一覧を検索結果として表示し、前記表示画面の表示から一つの予約を指定すると、前記指定に基づいて前記システムは譲渡可能の確認に関する情報を前記指定された人の端末へ送信し、譲渡可能の回答を受信すると、上記移譲の処理を行うことを特徴とするチケット入手あるいは交換の支援を行うシステム。
5. 請求項１に記載のチケット入手あるいは交換の支援を行うシステムであって、
   チケットの購入に関する処理において情報を他人に送信してもよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報を前記記憶装置に記憶し、
   指定の予約を必要とする利用者が指定の予約が取れない場合に、予約を譲っても良い利用者のチケット入手のための処理で、予約を必要とする利用者に関する情報の送信は、上記予め入力されて記憶されている上記他人に送信しても良いとの情報に基づいて行われることを特徴とするチケット入手あるいは交換の支援を行うシステム。
   
6. 請求項１に記載のチケット入手あるいは交換の支援を行うシステムであって、
   利用者が取得した予約を移譲する場合のチケットの再予約条件を入力する画面に関する情報を前記システムは利用者に送信し、送信された画面に関する情報に基づいて入力された条件を前記記憶装置に登録し、
   他の利用者から予約依頼の要求を受信すると、システムは移譲可能者の検索を行うと共に、移譲可能の確認の画像情報を送信し、上記送信に対して移譲可能との情報を受信すると、それに伴って予約を譲っても良いとした利用者の上記再予約条件を読み出し、上記読み出した条件に基づき、チケットの再予約の処理を行うことを特徴とするチケット入手あるいは交換の支援を行うシステム。
7. 請求項１に記載のチケット入手あるいは交換の支援を行うシステムであって、
   チケットの移譲に関する処理において情報を第三者に送信してよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報の送信可否の情報を受信するとこれを記憶装置に記憶し、
   チケットを確保した利用者がチケットの移譲を行う場合に、予約を譲っても良い利用者の情報の送信は、前記記憶された第三者への送信可否の情報に基づいて行うことを特徴とするチケット入手あるいは交換の支援を行うシステム。
8. 入出力装置と記憶装置とを有するシステムに使用されるチケット入手あるいは交換の支援を行う方法であって、前記記憶装置にはチケットの予約に関するデータと、チケットの交換に関するデータ、チケット入手あるいは交換を支援するための入力画面の情報が記憶され、予約の希望をシステムが受信すると、希望の予約を確保する処理を行い、予約の確保の有無を通信回線を介して上記希望者に送信し、
   上記送信内容が予約の確保が困難である内容の場合にこの送信に対し、予約確保の指示を受信すると、予約確保者のデータベースを検索して、検索結果として移譲可能な予約確保者を抽出し、抽出した予約確保者に対し、移譲の有無を問い合わせる情報を送信し、上記移譲の有無の問い合わせに対し、移譲承諾の回答を受信すると、予約に関する移譲可能の連絡を予約希望者に連絡し、予約移譲の処理を行うと共に移譲承諾者に対する新たな予約確保の処理を行うことを特徴とするチケット入手あるいは交換の支援を行う方法。
9. 請求項８に記載のチケット入手あるいは交換の支援を行う方法であって、予約を行う利用者に対するチケットの入手あるいは交換のための処理期限を入力する画面の情報を、予約を行う利用者に送信し、上記処理期限の送信に対する処理期限の回答を受信すると、上記受信した処理期限を記憶装置に保持し、前記処理期限を過ぎるとチケットの予約の移譲の処理を停止することを特徴とするチケット入手あるいは交換の支援を行う方法。
10. 請求項８に記載のチケット入手あるいは交換の支援を行う方法であって、利用者に対し予約を譲ってもよいかどうかを入力するための画像情報を送信し、上記画像情報に基づいて、利用者が予約を譲って良いことおよび譲った後の代わりの予約に対する条件を入力した情報を受信し、これを記憶し、前記移譲の処理に基づいて、記憶していた前記代わりの予約条件に従い、新たなチケットの確保のための処理を行い、新たなチケットの予約がなされると、その内容を記憶すると共に、新たなチケットが確保できたことを示す情報を利用者に送信することを特徴とするチケット入手あるいは交換の支援を行う方法。
11. 請求項８に記載のチケット入手あるいは交換の支援を行う方法であって、
    前記予約確保者のデータベースを検索し、予約を譲っても良い利用者の予約移譲の情報を含む予約に関する情報の一覧を検索結果として表示し、前記表示画面の表示から一つの予約を指定すると、前記指定に基づいて前記システムは譲渡可能の確認に関する情報を前記指定された人の端末へ送信し、譲渡可能の回答を受信すると、上記移譲の処理を行うことを特徴とするチケット入手あるいは交換の支援を行う方法。
12. 請求項８に記載のチケット入手あるいは交換の支援を行う方法であって、
    チケットの購入に関する処理において情報を他人に送信してもよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報を前記記憶装置に記憶し、
    指定の予約を必要とする利用者が指定の予約が取れない場合に、予約を譲っても良い利用者のチケット入手のための処理で、予約を必要とする利用者に関する情報の送信は、上記予め入力されて記憶されている上記他人に送信しても良いとの情報に基づいて行われることを特徴とするチケット入手あるいは交換の支援を行う方法。
13. 請求項８に記載のチケット入手あるいは交換の支援を行う方法であって、
    利用者が取得した予約を移譲する場合のチケットの再予約条件を入力する画面に関する情報を前記システムは利用者に送信し、送信された画面に関する情報に基づいて入力された条件を前記記憶装置に登録し、
    他の利用者から予約依頼の要求を受信すると、システムは移譲可能者の検索を行うと共に、移譲可能の確認の画像情報を送信し、上記送信に対して移譲可能との情報を受信すると、それに伴って予約を譲っても良いとした利用者の上記再予約条件を読み出し、上記読み出した条件に基づき、チケットの再予約の処理を行うことを特徴とするチケット入手あるいは交換の支援を行う方法。
14. 請求項８に記載のチケット入手あるいは交換の支援を行う方法であって、
    チケットの移譲に関する処理において情報を第三者に送信してよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報の送信可否の情報を受信するとこれを記憶装置に記憶し、
    チケットを確保した利用者がチケットの移譲を行う場合に、予約を譲っても良い利用者の情報の送信は、前記記憶された第三者への送信可否の情報に基づいて行うことを特徴とするチケット入手あるいは交換の支援を行う方法。
15. 入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とするコンピュータプログラム、
    予約を希望する入力があると、希望の予約を確保する処理を行い、予約の確保の有無を上記希望者に連絡し、
    上記予約の確保の有無についての連絡において予約の確保無しの連絡を行った場合に対し、さらに予約確保の指示があると、予約確保者のデータベースを検索し、前記予約確保に対する移譲の有無を問い合わせる送信を行い、この問い合わせの送信に関し移譲承諾の回答を受信すると、予約に関する移譲可能の情報を予約希望者に送信し、予約移譲の処理を行うと共に移譲承諾者に対する新たな予約確保の処理を行う。
16. 入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項１５に記載のコンピュータプログラム、
    予約を行う利用者に対するチケットの入手あるいは交換のための処理期限を入力する画面の情報を、予約を行う利用者に送信し、上記処理期限の送信に対する処理期限の回答を受信すると、上記受信した処理期限を記憶装置に保持し、前記処理期限を過ぎるとチケットの予約の移譲の処理を停止する。
17. 入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項１５に記載のコンピュータプログラム、
    利用者に対し予約を譲ってもよいかどうかを入力するための画像情報を送信し、上記画像情報に基づいて、利用者が予約を譲って良いことおよび譲った後の代わりの予約に対する条件を入力した情報を受信し、これを記憶し、前記移譲の処理に基づいて、記憶していた前記代わりの予約条件に従い、新たなチケットの確保のための処理を行い、新たなチケットの予約がなされると、その内容を記憶すると共に、新たなチケットが確保できたことを示す情報を利用者に送信する。
18. 入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項１５に記載のコンピュータプログラム、
    前記記憶装置は予約確保者のデータベースを有しており、予約確保者のデータベースを検索し、予約を譲っても良い利用者の予約移譲の情報を含む予約に関する情報の一覧を検索結果として表示し、前記表示画面の表示から一つの予約を指定すると、前記指定に基づいて前記システムは譲渡可能の確認に関する情報を前記指定された人の端末へ送信し、譲渡可能の回答を受信すると、上記移譲の処理を行う。
19. 入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項１５に記載のコンピュータプログラム、
    チケットの購入に関する処理において情報を他人に送信してもよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報を前記記憶装置に記憶し、
    指定の予約を必要とする利用者が指定の予約が取れない場合に、予約を譲っても良い利用者のチケット入手のための処理で、予約を必要とする利用者に関する情報の送信は、上記予め入力されて記憶されている上記他人に送信しても良いとの情報に基づいて行われる。
20. 入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項１５に記載のコンピュータプログラム、
    利用者が取得した予約を移譲する場合のチケットの再予約条件を入力する画面に関する情報を前記システムは利用者に送信し、送信された画面に関する情報に基づいて入力された条件を前記記憶装置に登録し、
    他の利用者から予約依頼の要求を受信すると、システムは移譲可能者の検索を行うと共に、移譲可能の確認の画像情報を送信し、上記送信に対して移譲可能との情報を受信すると、それに伴って予約を譲っても良いとした利用者の上記再予約条件を読み出し、上記読み出した条件に基づき、チケットの再予約の処理を行う。
21. 入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項１５に記載のコンピュータプログラム、
    チケットの移譲に関する処理において情報を第三者に送信してよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報の送信可否の情報を受信するとこれを記憶装置に記憶し、
    チケットを確保した利用者がチケットの移譲を行う場合に、予約を譲っても良い利用者の情報の送信は、前記記憶された第三者への送信可否の情報に基づいて行う。

Images