図面 (/)

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

出願人 株式会社日立ソリューションズ東日本
発明者 内海由博村上仁辺見吉克佐藤博信小野さおり小林理佳大内東山本雅人川村秀憲
出願日 2003年12月9日 (15年9ヶ月経過) 出願番号 2003-411023
公開日 2005年6月30日 (14年2ヶ月経過) 公開番号 2005-173838
状態 拒絶査定
技術分野 特定用途計算機 検索装置
主要キーワード 予約端末装置 希望どおり 予約確認通知 摺り合わせ 条件マッチング マッチング要求 割増率 予約希望者
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2005年6月30日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

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

解決手段

本発明による解決手段の一つは、指定のチケットの予約ができなかったが、その指定の予約をとりたい予約希望者と、その予約希望者が必要とするチケットを保有しているが他の日へ予約を変更できる予約移譲者とのチケット転売作業を、メール通信機能等を用いて支援できるようにしたことである。さらにもう一つの解決手段の一つは、上記転売作業を行ううえで発生しうる「ダフ屋的」行為を減少させる仕組みを提供したことである。

概要

背景

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

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

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

概要

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

目的

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

効果

実績

技術文献被引用数
1件
牽制数
1件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

チケット入手あるいは交換支援を行うシステムであって、前記システムは入出力装置記憶装置を有し、前記記憶装置にはチケットの予約に関するデータと、チケットの交換に関するデータ、チケット入手あるいは交換を支援するための入力画面に関する情報が記憶され、予約を希望する入力があると、希望の予約を確保する処理を行い、予約の確保の有無を上記希望者連絡し、上記予約の確保の有無についての連絡において予約の確保無しの連絡を行った場合に対し、さらに予約確保の指示があると、予約確保者のデータベース検索し、前記予約確保に対する移譲の有無を問い合わせる送信を行い、この問い合わせの送信に関し移譲承諾回答を受信すると、予約に関する移譲可能の情報を予約希望者に送信し、予約移譲の処理を行うと共に移譲承諾者に対する新たな予約確保の処理を行うことを特徴とするチケット入手あるいは交換の支援を行うシステム。

請求項2

請求項1に記載のチケット入手あるいは交換の支援を行うシステムであって、予約を行う利用者に対するチケットの入手あるいは交換のための処理期限を入力する画面の情報を、予約を行う利用者に送信し、上記処理期限の送信に対する処理期限の回答を受信すると、上記受信した処理期限を記憶装置に保持し、前記処理期限を過ぎるとチケットの予約の移譲の処理を停止することを特徴とするチケット入手あるいは交換の支援を行うシステム。

請求項3

請求項1に記載のチケット入手あるいは交換の支援を行うシステムであって、利用者に対し予約を譲ってもよいかどうかを入力するための画像情報を送信し、上記画像情報に基づいて、利用者が予約を譲って良いことおよび譲った後の代わりの予約に対する条件を入力した情報を受信し、これを記憶し、前記移譲の処理に基づいて、記憶していた前記代わりの予約条件に従い、新たなチケットの確保のための処理を行い、新たなチケットの予約がなされると、その内容を記憶すると共に、新たなチケットが確保できたことを示す情報を利用者に送信することを特徴とするチケット入手あるいは交換の支援を行うシステム。

請求項4

請求項1に記載のチケット入手あるいは交換の支援を行うシステムであって、前記予約確保者のデータベースを検索し、予約を譲っても良い利用者の予約移譲の情報を含む予約に関する情報の一覧を検索結果として表示し、前記表示画面の表示から一つの予約を指定すると、前記指定に基づいて前記システムは譲渡可能の確認に関する情報を前記指定された人の端末へ送信し、譲渡可能の回答を受信すると、上記移譲の処理を行うことを特徴とするチケット入手あるいは交換の支援を行うシステム。

請求項5

請求項1に記載のチケット入手あるいは交換の支援を行うシステムであって、チケットの購入に関する処理において情報を他人に送信してもよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報を前記記憶装置に記憶し、指定の予約を必要とする利用者が指定の予約が取れない場合に、予約を譲っても良い利用者のチケット入手のための処理で、予約を必要とする利用者に関する情報の送信は、上記予め入力されて記憶されている上記他人に送信しても良いとの情報に基づいて行われることを特徴とするチケット入手あるいは交換の支援を行うシステム。

請求項6

請求項1に記載のチケット入手あるいは交換の支援を行うシステムであって、利用者が取得した予約を移譲する場合のチケットの再予約条件を入力する画面に関する情報を前記システムは利用者に送信し、送信された画面に関する情報に基づいて入力された条件を前記記憶装置に登録し、他の利用者から予約依頼の要求を受信すると、システムは移譲可能者の検索を行うと共に、移譲可能の確認の画像情報を送信し、上記送信に対して移譲可能との情報を受信すると、それに伴って予約を譲っても良いとした利用者の上記再予約条件を読み出し、上記読み出した条件に基づき、チケットの再予約の処理を行うことを特徴とするチケット入手あるいは交換の支援を行うシステム。

請求項7

請求項1に記載のチケット入手あるいは交換の支援を行うシステムであって、チケットの移譲に関する処理において情報を第三者に送信してよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報の送信可否の情報を受信するとこれを記憶装置に記憶し、チケットを確保した利用者がチケットの移譲を行う場合に、予約を譲っても良い利用者の情報の送信は、前記記憶された第三者への送信可否の情報に基づいて行うことを特徴とするチケット入手あるいは交換の支援を行うシステム。

請求項8

入出力装置と記憶装置とを有するシステムに使用されるチケット入手あるいは交換の支援を行う方法であって、前記記憶装置にはチケットの予約に関するデータと、チケットの交換に関するデータ、チケット入手あるいは交換を支援するための入力画面の情報が記憶され、予約の希望をシステムが受信すると、希望の予約を確保する処理を行い、予約の確保の有無を通信回線を介して上記希望者に送信し、上記送信内容が予約の確保が困難である内容の場合にこの送信に対し、予約確保の指示を受信すると、予約確保者のデータベースを検索して、検索結果として移譲可能な予約確保者を抽出し、抽出した予約確保者に対し、移譲の有無を問い合わせる情報を送信し、上記移譲の有無の問い合わせに対し、移譲承諾の回答を受信すると、予約に関する移譲可能の連絡を予約希望者に連絡し、予約移譲の処理を行うと共に移譲承諾者に対する新たな予約確保の処理を行うことを特徴とするチケット入手あるいは交換の支援を行う方法。

請求項9

請求項8に記載のチケット入手あるいは交換の支援を行う方法であって、予約を行う利用者に対するチケットの入手あるいは交換のための処理期限を入力する画面の情報を、予約を行う利用者に送信し、上記処理期限の送信に対する処理期限の回答を受信すると、上記受信した処理期限を記憶装置に保持し、前記処理期限を過ぎるとチケットの予約の移譲の処理を停止することを特徴とするチケット入手あるいは交換の支援を行う方法。

請求項10

請求項8に記載のチケット入手あるいは交換の支援を行う方法であって、利用者に対し予約を譲ってもよいかどうかを入力するための画像情報を送信し、上記画像情報に基づいて、利用者が予約を譲って良いことおよび譲った後の代わりの予約に対する条件を入力した情報を受信し、これを記憶し、前記移譲の処理に基づいて、記憶していた前記代わりの予約条件に従い、新たなチケットの確保のための処理を行い、新たなチケットの予約がなされると、その内容を記憶すると共に、新たなチケットが確保できたことを示す情報を利用者に送信することを特徴とするチケット入手あるいは交換の支援を行う方法。

請求項11

請求項8に記載のチケット入手あるいは交換の支援を行う方法であって、前記予約確保者のデータベースを検索し、予約を譲っても良い利用者の予約移譲の情報を含む予約に関する情報の一覧を検索結果として表示し、前記表示画面の表示から一つの予約を指定すると、前記指定に基づいて前記システムは譲渡可能の確認に関する情報を前記指定された人の端末へ送信し、譲渡可能の回答を受信すると、上記移譲の処理を行うことを特徴とするチケット入手あるいは交換の支援を行う方法。

請求項12

請求項8に記載のチケット入手あるいは交換の支援を行う方法であって、チケットの購入に関する処理において情報を他人に送信してもよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報を前記記憶装置に記憶し、指定の予約を必要とする利用者が指定の予約が取れない場合に、予約を譲っても良い利用者のチケット入手のための処理で、予約を必要とする利用者に関する情報の送信は、上記予め入力されて記憶されている上記他人に送信しても良いとの情報に基づいて行われることを特徴とするチケット入手あるいは交換の支援を行う方法。

請求項13

請求項8に記載のチケット入手あるいは交換の支援を行う方法であって、利用者が取得した予約を移譲する場合のチケットの再予約条件を入力する画面に関する情報を前記システムは利用者に送信し、送信された画面に関する情報に基づいて入力された条件を前記記憶装置に登録し、他の利用者から予約依頼の要求を受信すると、システムは移譲可能者の検索を行うと共に、移譲可能の確認の画像情報を送信し、上記送信に対して移譲可能との情報を受信すると、それに伴って予約を譲っても良いとした利用者の上記再予約条件を読み出し、上記読み出した条件に基づき、チケットの再予約の処理を行うことを特徴とするチケット入手あるいは交換の支援を行う方法。

請求項14

請求項8に記載のチケット入手あるいは交換の支援を行う方法であって、チケットの移譲に関する処理において情報を第三者に送信してよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報の送信可否の情報を受信するとこれを記憶装置に記憶し、チケットを確保した利用者がチケットの移譲を行う場合に、予約を譲っても良い利用者の情報の送信は、前記記憶された第三者への送信可否の情報に基づいて行うことを特徴とするチケット入手あるいは交換の支援を行う方法。

請求項15

入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とするコンピュータプログラム、予約を希望する入力があると、希望の予約を確保する処理を行い、予約の確保の有無を上記希望者に連絡し、上記予約の確保の有無についての連絡において予約の確保無しの連絡を行った場合に対し、さらに予約確保の指示があると、予約確保者のデータベースを検索し、前記予約確保に対する移譲の有無を問い合わせる送信を行い、この問い合わせの送信に関し移譲承諾の回答を受信すると、予約に関する移譲可能の情報を予約希望者に送信し、予約移譲の処理を行うと共に移譲承諾者に対する新たな予約確保の処理を行う。

請求項16

入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項15に記載のコンピュータプログラム、予約を行う利用者に対するチケットの入手あるいは交換のための処理期限を入力する画面の情報を、予約を行う利用者に送信し、上記処理期限の送信に対する処理期限の回答を受信すると、上記受信した処理期限を記憶装置に保持し、前記処理期限を過ぎるとチケットの予約の移譲の処理を停止する。

請求項17

入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項15に記載のコンピュータプログラム、利用者に対し予約を譲ってもよいかどうかを入力するための画像情報を送信し、上記画像情報に基づいて、利用者が予約を譲って良いことおよび譲った後の代わりの予約に対する条件を入力した情報を受信し、これを記憶し、前記移譲の処理に基づいて、記憶していた前記代わりの予約条件に従い、新たなチケットの確保のための処理を行い、新たなチケットの予約がなされると、その内容を記憶すると共に、新たなチケットが確保できたことを示す情報を利用者に送信する。

請求項18

入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項15に記載のコンピュータプログラム、前記記憶装置は予約確保者のデータベースを有しており、予約確保者のデータベースを検索し、予約を譲っても良い利用者の予約移譲の情報を含む予約に関する情報の一覧を検索結果として表示し、前記表示画面の表示から一つの予約を指定すると、前記指定に基づいて前記システムは譲渡可能の確認に関する情報を前記指定された人の端末へ送信し、譲渡可能の回答を受信すると、上記移譲の処理を行う。

請求項19

入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項15に記載のコンピュータプログラム、チケットの購入に関する処理において情報を他人に送信してもよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報を前記記憶装置に記憶し、指定の予約を必要とする利用者が指定の予約が取れない場合に、予約を譲っても良い利用者のチケット入手のための処理で、予約を必要とする利用者に関する情報の送信は、上記予め入力されて記憶されている上記他人に送信しても良いとの情報に基づいて行われる。

請求項20

入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項15に記載のコンピュータプログラム、利用者が取得した予約を移譲する場合のチケットの再予約条件を入力する画面に関する情報を前記システムは利用者に送信し、送信された画面に関する情報に基づいて入力された条件を前記記憶装置に登録し、他の利用者から予約依頼の要求を受信すると、システムは移譲可能者の検索を行うと共に、移譲可能の確認の画像情報を送信し、上記送信に対して移譲可能との情報を受信すると、それに伴って予約を譲っても良いとした利用者の上記再予約条件を読み出し、上記読み出した条件に基づき、チケットの再予約の処理を行う。

請求項21

入出力装置と記憶装置とを有するシステムにチケット入手あるいは交換の支援を行う次に示す機能を持たせることを特徴とする請求項15に記載のコンピュータプログラム、チケットの移譲に関する処理において情報を第三者に送信してよいかを指定する入力画面の情報を利用者に送信し、その画面に基づいて入力された情報の送信可否の情報を受信するとこれを記憶装置に記憶し、チケットを確保した利用者がチケットの移譲を行う場合に、予約を譲っても良い利用者の情報の送信は、前記記憶された第三者への送信可否の情報に基づいて行う。

技術分野

0001

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

背景技術

0002

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

0003

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

0004

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

発明が解決しようとする課題

0005

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

0006

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

0007

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

課題を解決するための手段

0008

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

0009

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

0010

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

0011

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

発明の効果

0012

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

0013

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

0014

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

0015

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

発明を実施するための最良の形態

0016

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

0017

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

0018

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

0019

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

0020

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

0021

図2にマッチング要求基本データベースのデータの一例を示す。マッチング要求基本データは列方向にマッチング要求番号A、マッチング要求年月日B、マッチング要求時刻C、マッチング制限時間D、マッチング成立時間E、マッチング結果F、新一般予約識別番号G、マッチング先一般予約識別番号H、該当予約コードI、マッチングステータスJからなり、行方向にそれぞれ複数件のデータが、マッチング要求番号Aをキーとして保管されている。

0022

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

0023

図4図6に電子予約基本データの一例を示す。電子予約基本データは列方向に一般予約識別番号R、予約コードS、予約期間T、予約年月日U、予約時刻U、料金V、発生マイレージV、住所W、氏名W、電子メールアドレスW、電話番号W、関連情報(予約変更不可、割引不適用など・・・)W、マッチングフラグX、マッチング要求番号Y、マッチング受付番号Zからなり、行方向にそれぞれ複数件のデータが、一般予約識別番号Rをキーとして保管されている。

0024

マッチング要求基本データ(図2)のマッチング要求番号A「1」201は、電子予約基本データ(図6)のマッチング番号Y「1」604に対応して保管される。同様に、初めに予約を希望したマッチング先一般予約識別番号H「2」203は、一般予約識別番号R「2」401に対応して保管される。マッチング後の新一般予約識別番号G「4」は、一般予約識別番号R「4」402に対応している。

0025

マッチング受付基本データ(図3)のマッチング受付番号K「1」301は、マッチング受付番号Z「1」605及び606に対応する。一般予約識別番号L「2」は一般予約識別番号R「2」に対応している。変更後一般予約識別番号O「5」302は一般予約識別番号R「5」603に対応している。移譲先一般予約識別番号P「4」303は一般予約識別番号R「4」602に対応している。

0026

このようにマッチング要求基本データ(図2)、マッチング受付基本データ(図3)及び電子予約基本データ(図4図6)は、互いにマッチング要求番号(AとY)、マッチング受付番号(KとZ)及び種種の一般予約識別番号(R、L、O、P、G、H)でリンクしあっている。

0027

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

0028

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

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

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

0037

なお、図8図12までのフローに関する、図形の意味を凡例として810に示した。利用者などの操作は図形811で、プログラムの使用によるマシン処理は図形812で、同様にマシンによる判定処理は813で、マシンによる不正防止処理は814で示している。

0038

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

0039

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

0040

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

0041

ステップS803では、まずステップS804で入手した、予約希望者の個人情報と該当予約コードIを受信する。次にマッチング要求基本データの該当予約コードIと電子予約基本データの予約コードSとのマッチング(検索)の処理を行う。次にマッチングした該当者のメールアドレスWを抽出。予約希望者の電子予約基本データ(一般予約識別番号R、予約コードS、予約期間T、住所・氏名・電子メールアドレス・電話番号・関連情報W)を完成させる。次にマッチング(検索)の処理で抽出した電子メールアドレスなどW・一般予約識別番号R及び予約希望者の一般予約識別番号Rを事業者マッチング処理サーバ装置803に送付し、ステップS802の受信の処理で受信する(ステップS805)。このステップS802〜ステップS805の処理はステップS801で設けた制限時間内で継続して実行される。

0042

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

0043

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

0044

この通知画面の一例を図14(A)に示す。通知内容に対して、予約の移譲条件を設定する場合にはURL1403にアクセスする操作を行う。アクセスすると、図14(B)で示す画面が表示される。その画面で必要に応じて、予約の変更可能日の設定入力などをシステムに対して行う。予約の移譲希望登録と変更後予約の設定を行う場合は、OKボタン1404を押す。すると以下で説明する予約の移譲に関する処理が図14(A)で表示されている案件について実施例で説明したシステムで開始される。キャンセルボタン1405を押すと、図14(A)で表示されている案件についての予約の移譲に関する処理は行われない。

0045

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

0046

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

0047

次にステップS902で、事業者マッチング処理サーバ装置803はステップS801で設定入力された制限時間内であれば、ステップS903の処理を実施し、制限時間若しくは制限時間外であれば、ステップS904の処理を実施する。まずステップS903の処理では、マッチング受付基本データ(マッチング受付番号K、一般予約識別番号L、マッチング受付時刻M、マッチングステータスQ=ランダム抽出待ち6)をシステムが作成する。また一般予約識別番号Lとマッチング先一般予約識別番号Hで合致するマッチング要求基本データのマッチングステータスJをランダム抽出待ち5に設定する。

0048

ステップS904では、マッチング受付基本データ(マッチング受付番号K、一般予約識別番号L、マッチング受付時刻M、マッチング結果N=マッチング不成立2、マッチングステータスQ=不成立5)をシステムが作成する。また一般予約識別番号Lとマッチング先一般予約識別番号Hで合致するマッチング要求基本データのマッチング結果Fを不成立2に設定、マッチングステータスJを時間切れ4にシステムが設定する。本処理完了後に予約希望者(予約を譲ってもらってでも予約したい利用者)や予約移譲希望者(予約を譲っても良い利用者)に時間切れの情報をメールで利用者にシステムが通知する。

0049

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

0050

次にステップS1004で前記した、変更後予約があり、かつ同一既存予約が無ければステップS1005の処理に移る。もしそうでなければステップS1006の処理に移る。ステップS1006では、マッチング受付基本データ(マッチング受付番号K、一般予約識別番号L、マッチング受付時刻M、マッチング結果N=マッチング不成立2、マッチングステータスQ=不成立4)をシステムが作成する。前記のデータに基づき、予約移譲希望者へ抽選漏れの通知をシステムが利用者に対して行う。

0051

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

0052

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

0053

ステップS1008では、以下の処理をシステムが行う。まずマッチング受付基本データ(マッチング受付番号K、一般予約識別番号L、マッチング受付時刻M、マッチングステータスQ=受付完了1)を作成する。次に一般予約識別番号Lとマッチング先一般予約識別番号Hで合致するマッチング要求基本データのマッチングステータスJをマッチング先連絡待ち1に設定する。次に予約移譲者向けに、予約意思を指定するGUI構築する。もちろん既に用意した画面を表示しても良い。次にマッチングステータスJに予約指定待ち2を、マッチングステータスQに予約指定待ち2を設定する。前記の予約移譲希望者(予約を譲っても良い利用者)の予約移譲関連情報を事業者一般予約処理サーバ装置804に送付する。次に事業者マッチング処理サーバ装置803では、変更後予約Rを受信する。ステップS1008は処理待ちループであるステップS1001とステップS1002で制限時間を監視した後に実行される。

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

事業者マッチング処理サーバ装置803では、次にシステムが、マッチング要求基本データのマッチングステータスJを成立(メール発信済み)3にセットする。ついで、マッチング受付基本データのマッチング結果Nに成立1を、変更後一般予約識別番号Oと移譲先一般予約識別番号Pをセットし、マッチングステータスQに成立(メール発信済み)3をセットする。以上で予約決定と確認に関する処理は終了する。これは、例えば図2の例ではマッチング要求番号Aが1のレコードが、図3の例ではマッチング受付番号Kが1のレコードが、この処理の一例に該当する。

0062

ステップS1104は、事業者一般予約処理サーバ装置804が予約移譲者関係のデータに関する変更処理を行い、事業者マッチング処理サーバ装置803にステップS1105で、その終了結果を通知するステップである。以下その処理を説明する。まず、ステップS1103で事業者マッチング処理サーバ装置803によって送信された成立通知を事業者一般予約処理サーバ装置804が受信する。次にシステムで、予約移譲希望者に関するデータである以下のデータを電子予約基本データにセットする。まず予約年月日U・予約時刻U、料金V・発生マイレージVをセットする。マッチングフラグXには「あり(要求側)」2をセット、マッチング要求番号Yにはマッチング要求番号A、マッチング受付番号Zにはマッチング要求番号Aをセットする。

0063

予約移譲者の移譲前の予約レコードには、マッチングフラグXに「あり(受付・変更前)」1をセット、マッチング受付番号Zにマッチング受付番号Kをセットする。例えば図6の例では一般予約識別番号Rが2のレコードが、この処理の一例に該当する。

0064

予約移譲者の変更後予約に関するレコードに関しては、予約年月日U・予約時刻U、料金V・発生マイレージVをセットする。またマッチングフラグXには「あり(受付・変更後)」3をセット、マッチング受付番号Zにはマッチング要求番号Aをセットする。例えば図6の例では一般予約識別番号Rが5のレコードが、この処理の一例に該当する。

0065

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

0066

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

0067

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

0068

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

0069

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

0070

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

0071

なお、ステップS1203及びステップ1207でチェックにかからなかった場合は、ステップS1205で通常どおり取消処理ができる。

0072

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

0073

図21の画面は、指定の予約を強く必要とする予約者のチケットの予約内容と移譲を受ける際の条件(提供するサービスなど)などの確認画面である。エリア2102で示した内容でOKである場合は、RESERVEボタン2103を押す。CANCELボタン2104を押せば、図20で設定した内容の予約は破棄され予約登録は行われない。RESERVEボタン2103を押すと図20で設定した内容の予約登録がシステムによって行われ、予約確認画面(図22)が表示される。チケットの予約成立はエリア2202に示しているように、予約成立後にシステムからメールで連絡される。あるいは指定のURLから利用者がシステムに確認することもできる。

0074

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

0075

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

0076

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

0077

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

0078

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

0079

図28は、予約移譲と予約変更が実施可能となった時にシステムから通知される携帯電話などの画面の一例である。「指定の予約の取得を強く望む利用者」に譲った、前の予約内容がエリア2802に、譲った予約の代わりに予約した新しい予約の内容がエリア2803に、自分の氏名・連絡先がエリア2804に表示されている。予約を譲る代わりに、変更後の便の運賃が5000円割引になっている。内容を確認したらNEXTボタン2705を押す。参照を中止するのであればCANCELボタン2706を押し、この画面を閉じる。NEXTボタン2705を押すと、予約移譲手続完了待ちの確認画面(図29)が表示される。図29のエリア2902に示すようにチケットの移譲成立とそれに伴う予約の変更完了は、後でシステムからメールで通知される。またURLから、その結果を参照することもできる。

0080

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

0081

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

0082

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

0083

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

0084

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

0085

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

0086

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

0087

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

0088

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

0089

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

0090

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

0091

こうして用意された予約M1921と転売M1922の情報から、転売管理システム1900はステップS1904で条件マッチング(検索)の処理を行う。条件マッチング(検索)処理は、予約購入者A1702と予約購入者B1703の予約券取得に関する取引条件摺り合わせを行い、両者の取引を成立させ、両者の希望どおりの予約を行うために行う。システムによる予約条件のマッチング(検索)の処理の結果、マッチングが成立した場合はステップS1934で、転売管理システム1900から予約購入者A1702に転売依頼通知がメールなどで通知される。通知を受けた予約購入者A1702は、ステップS1906で転売ができるか否かを判断し、その判断結果をシステムが提供する操作画面に入力設定し、ステップS1935で転売管理システム1900に通知するための操作を行う。その操作指示による通知を受けて転売管理システム1900はステップS1905の処理を開始する。ステップS1905では、予約購入者A1702がシステムの操作画面で設定した内容に基づき、転売管理システム1900で、予約購入者A1702が前記処理で獲得していた予約券の転売が可能か否かを判断する。その結果、転売が可能であるとシステムで判断されると、転売管理システム1900はステップS1908で、予約購入者B1703に対して、予約券の購入可能通知をメールなどで行う。転売が不可能であれば転売管理システム1900はステップS1912で、予約購入者B1703に対して、予約券の購入不可能通知をメールなどで行う。

0092

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

0093

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

0094

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

0095

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

図面の簡単な説明

0096

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

符号の説明

0097

101 実施例におけるマッチング要求基本データを保持するデータベース
102 実施例におけるマッチング受付基本データを保持するデータベース
103 実施例における電子予約基本データを保持するデータベース
104 実施例における事業者マッチング処理サーバ装置
105 実施例における事業者一般予約処理サーバ装置
106 実施例における一般予約端末装置
109 実施例におけるマッチング要求端末装置
200 実施例におけるマッチング要求基本データ
300 実施例におけるマッチング受付基本データ
400 実施例における電子予約基本データ
500 実施例における電子予約基本データ
600 実施例における電子予約基本データ
1300 実施例におけるシステムの予約希望画面
1401 実施例におけるシステムの予約変更伺の画面
1402 実施例におけるシステムの予約変更設定画面
1600 実施例におけるシステムの予約確認画面
2001 本発明の方法を利用したシステム実例の指定希望の予約に関する操作画面
2101 実施例におけるシステムの予約確認に関する操作画面
2201 実施例におけるシステムの予約承認に関する操作画面
2301 実施例におけるシステムの顧客情報の登録手続に関する操作画面
2401 実施例におけるシステムの航空券の予約手続に関する操作画面
2501 実施例におけるシステムのチケット移譲時の予約変更条件を指定する操作画面
2601 実施例におけるシステムの移譲伺いメールの確認に関する操作画面
2701 実施例におけるシステムの予約変更手続に関する操作画面
2801 実施例におけるシステムの予約移譲完了通知に関する操作画面
2901 実施例におけるシステムの予約移譲完了通知に関する操作画面
3001 実施例におけるシステムの予約の成立通知に関する操作画面
3002 実施例におけるシステムの予約移譲の成立通知に関する操作画面
3003 実施例におけるシステムの予約移譲の不成立通知に関する操作画面
3101 実施例におけるシステムの予約移譲の統計を調べる場合の条件指定に関する操作画面
3201 実施例におけるシステムの予約移譲に関する統計情報の結果表示画面
3202 実施例におけるシステムの予約移譲に関する統計情報の結果表示画面
3203 実施例におけるシステムの予約移譲に関する統計情報の結果表示画面
3301 実施例におけるシステムの予約に関する統計情報の結果表示画面

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • オムロン株式会社の「 マッチング処理装置」が 公開されました。( 2019/08/08)

    【課題・解決手段】利活用対象のセンシングデータによる容易なセンサマッチングを行うマッチング処理部50が提供される。マッチング処理部50は、提供側端末11により入力された提供側センシングデータを取得する... 詳細

  • オムロン株式会社の「 検索用データ生成装置」が 公開されました。( 2019/08/08)

    【課題・解決手段】センサの検索精度を向上させることができる検索用データ生成装置が提供される。検索用データ生成装置50は、入力された、センシングデバイス20に関連する検索条件301から検索用データを取得... 詳細

  • 三菱電機株式会社の「 情報処理装置および情報処理方法」が 公開されました。( 2019/08/08)

    【課題・解決手段】情報処理装置(10)は、時系列データである入力データを取得するデータ取得部(101)と、時系列データである学習データから抽出した部分列である複数の学習部分列の中で類似する学習部分列を... 詳細

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ