JP2014032649A - 処理サーバおよび譲渡管理方法 - Google Patents

Abstract

【課題】入場チケットの購入者が入場チケットの譲渡を一意に管理する。
【解決手段】サーバ１０では、チケット分配部１２１が、第１の利用者の要求に基づき、認証に用いられる第１の可視情報を生成し、第２の利用者に対応付けて管理ＤＢ１１１に格納する。また、チケット分配部１２１は、第１の利用者の要求に基づき、第１の可視情報と異なる第２の可視情報を生成し、第３の利用者に対応付けて管理ＤＢ１１１に格納する。そして、例えばＱＲ返却部１２２は、管理ＤＢ１１１に格納された第１の可視情報を無効化するとともに、第２の可視情報を有効化する。さらに、ＱＲ表示部１２３は、第２の可視情報を第３の利用者のアドレス宛に送信する。
【選択図】図１

Description

本発明は、処理サーバおよび譲渡管理方法に関する。

近年、コンサートやイベント等の入場チケットとして、電子機器の表示部に表示されて認証に用いられる可視情報が利用されている。例えば、入場チケットとして、携帯端末にＱＲコード(登録商標)を表示する。

ここで、ＱＲ（Quick Response）コードは画像であるので、複製されることがある。これは、入場するための権利と、入場チケットとの関係が一対一に対応しない状況が生じる。ＱＲコードを入場チケットとして表示する場合、複製されたＱＲコードの正当性を判別することは困難であるため、例えば、入場の手続きが行われると、一旦入場の手続きが行われたＱＲコードを無効とする処理が行われている。これにより、仮にＱＲコードが複製された場合、同じ内容のＱＲコードを所有した二番目以降に入場した利用者は、複製元の正当なＱＲコードを所有している利用者であっても入場することができなくなる。特に、他人より譲渡されたＱＲコードを表示した入場チケットについては、譲渡元が先に入場すると、譲渡先の利用者は、正当なＱＲコードを所有しているが、譲渡された入場チケットを利用できなくなる。

従来技術として、オンラインチケットを譲渡する場合、譲渡元と譲渡先の双方がサーバを通じてチケットの受け渡しを行うことにより、譲渡先に新規のオンラインチケットを発行するとともに、譲渡元のオンラインチケットを無効にすることが知られている（例えば、特許文献１）。

特開２００２−２６９２７９号公報

しかしながら、電子化された入場チケットの場合、入場チケットと購入者とは関連づけられているにもかかわらず、入場チケットの購入者が入場チケットの譲渡を一意に管理することができないという問題がある。例えば、従来技術において、オンラインチケットが一旦譲渡先に譲渡されると、譲渡元は新たな譲渡先への譲渡に関与できない。すなわち、入場チケットの購入者は、譲渡した入場チケットを改めて別の第３者へ譲渡することができない。

また、一旦譲渡した後のＱＲコードが複製され、入場チケットが一意にならなくなるおそれもある。

１つの側面では、入場チケットの購入者が入場チケットの譲渡を一意に管理することを目的とする。

本願の開示する処理サーバは、第１の利用者の要求に基づき、認証に用いられる第１の可視情報を生成し、第２の利用者に対応付けて記憶部に格納する第１の生成部と、前記第１の利用者の要求に基づき、前記第１の可視情報と異なる第２の可視情報を生成し、第３の利用者に対応付けて前記記憶部に格納する第２の生成部と、前記第１の利用者の要求に基づき、前記記憶部に格納された前記第１の可視情報を無効化するとともに、前記第２の可視情報を有効化する制御部と、前記第２の可視情報を前記第３の利用者のアドレス宛に送信する送信部とを有する。

本願の開示するプログラムの１つの態様によれば、入場チケットの購入者が入場チケットの譲渡を一意に管理することができる。

図１は、実施例１に係るチケット譲渡管理システムの構成を示すブロック図である。 図２は、実施例１に係る管理ＤＢのデータ構造の一例を示す図である。 図３は、実施例１に係るチケット分配処理のフローチャートを示す図である。 図４は、実施例１に係るＱＲ返却処理のフローチャートを示す図である。 図５は、実施例１に係るＱＲ表示処理のフローチャートを示す図である。 図６は、通常譲渡する場合のチケット譲渡管理処理のシーケンスを説明する図である。 図７は、譲渡元が返却承認しない場合のチケット譲渡管理処理のシーケンスを説明する図である。 図８は、譲渡先が取得しない場合のチケット譲渡管理処理のシーケンスを説明する図である。 図９は、未取得者の権利を譲渡する場合のチケット譲渡管理処理のシーケンスを説明する図である。 図１０は、通常譲渡する場合のデータの遷移を示す図である。 図１１は、譲渡元が返却承認しない場合のデータの遷移を示す図である。 図１２は、未取得者の権利を譲渡する場合のデータの遷移を示す図である。 図１３は、実施例１に係るチケット譲渡管理の画面遷移を説明する図である。 図１４は、ＱＲ情報入力画面の一例を示す図である。 図１５は、ＱＲ送信情報入力画面の一例を示す図である。 図１６は、ＱＲ送信確認画面の一例を示す図である。 図１７は、ＱＲ送信完了画面の一例を示す図である。 図１８は、送信エラーメールの一例を示す図である。 図１９は、ＱＲ取得メールの一例を示す図である。 図２０は、ＱＲ取得画面の一例を示す図である。 図２１は、分配先を変更する場合のＱＲ送信情報入力画面の一例を示す図である。 図２２は、ＱＲ返却メールの一例を示す図である。 図２３は、ＱＲ返却承認画面の一例を示す図である。 図２４は、返却完了画面の一例を示す図である。 図２５は、ＱＲ取得ＵＲＬ無効メールの一例を示す図である。 図２６は、実施例２に係るチケット譲渡管理システムの構成を示すブロック図である。 図２７は、実施例２に係るチケットキャンセル処理のフローチャートを示す図である。 図２８Ａは、所有者がキャンセル後、新購入者に譲渡できた場合の処理のシーケンスを説明する図である。 図２８Ｂは、所有者がキャンセル後、新購入者に譲渡できた場合のキャンセル処理のシーケンスを説明する図である。 図２９Ａは、所有者がキャンセル後、キャンセルを取り下げた場合の処理のシーケンスを説明する図である。 図２９Ｂは、所有者がキャンセル後、キャンセルを取り下げた場合の処理のシーケンスを説明する図である。 図３０Ａは、所有者がキャンセル後、新購入者に譲渡できなかった場合の処理のシーケンスを説明する図である。 図３０Ｂは、所有者がキャンセル後、新購入者に譲渡できなかった場合の処理のシーケンスを説明する図である。 図３１は、所有者がキャンセル後、新購入者に譲渡できた場合のデータの遷移を示す図である。 図３２は、所有者がキャンセル後、キャンセルを取り下げた場合のデータの遷移を示す図である。 図３３は、所有者がキャンセル後、新購入者に譲渡できなかった場合のデータの遷移を示す図である。

以下に、本願の開示する処理サーバおよび譲渡管理方法の実施例を図面に基づいて詳細に説明する。なお、実施例によりこの発明が限定されるものではない。

［チケット譲渡管理システムの構成］
図１は、実施例１に係るチケット譲渡管理システムの全体を示す図である。図１に示すように、チケット譲渡管理システム９は、チケット譲渡管理サイト１と、携帯端末２と、チケット販売サイト３とを有する。チケット譲渡管理サイト１は、複数の携帯端末２やチケット販売サイト３と、例えばインターネット網を示すネットワーク４で接続されている。

チケット販売サイト３は、チケットの販売を担うサイトである。すなわち、チケット販売サイト３は、利用者の携帯端末２からのチケットの購入要求に応じてチケットを販売する。このとき、チケット販売サイト３は、入場の際認証に用いられるＱＲコードを配布したことを示すメール（「ＱＲ配布メール」という）を、チケットの購入要求をした利用者（購入者）の携帯端末２のアドレス宛へ送信する。ＱＲ配布メールには、例えば、ＱＲコードが発行されるＵＲＬ（Uniform Resource Locator）（「ＱＲ発行ＵＲＬ」という）、予約番号、パスワードＡが含まれる。また、チケット販売サイト３は、チケットの購入情報をチケット譲渡管理サイト１へ送信する。購入情報には、例えば、座席情報、購入者情報や購入者に付与したパスワード（以下、「パスワードＡ」という）が含まれる。

なお、入場の際認証に用いられるコードは、ＱＲコードに限定されず、１次元のバーコードであっても良い。また、２次元のバーコードであっても良いし、電子的に利用者の携帯端末２に表示できる可視情報であれば良い。以下では、入場の際認証に用いられるコードをＱＲコードとして説明する。

携帯端末２は、ネットワーク４への接続環境を備えた携帯電話であったり、ネットワーク４への接続を可能とするブラウザを備えたＰＤＡ（Personal Digital Assistants）端末であったりする。携帯端末２は、入場の際認証に用いられるＱＲコードが表示されるモニタを備える。

チケット譲渡管理サイト１は、チケットの譲渡を管理するサイトである。チケット譲渡管理サイト１は、サーバ１０を備える。サーバ１０は、例えばウェブサービスを実施することで、チケットの譲渡を管理する。ここでいうチケットの譲渡とは、例えば、所定イベントの入場チケットの譲渡であって座席情報の譲渡を意味する。なお、座席情報は、指定席に限定されず自由席であっても良い。

サーバ１０は、記憶部１１と制御部１２とを有する。

記憶部１１は、例えばフラッシュメモリ（Flash Memory）やＦＲＡＭ（登録商標）（Ferroelectric Random Access Memory）等の不揮発性の半導体メモリ素子等の記憶装置に対応する。そして、記憶部１１は、管理ＤＢ１１１を有する。管理ＤＢ１１１は、チケットの譲渡を管理するデータベースであり、ＱＲコード情報と座席情報と利用者情報とを対応付けて記憶する。なお、管理ＤＢ１１１のデータ構造については後述する。

制御部１２は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。そして、制御部１２は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路またはＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等の電子回路に対応する。さらに、制御部１２は、チケット分配部１２１と、ＱＲ返却部１２２と、ＱＲ表示部１２３と、ＱＲ認証部１２４とを有する。

チケット分配部１２１は、購入者によるチケットの分配要求に基づき、チケットに対応するＱＲコードを生成し、チケットが分配される利用者（購入者を含む）に対応付けて管理ＤＢ１１１に格納する。ここでは、チケット分配部１２１は、チケットが分配される利用者の利用者情報に対応付けてＱＲコードの情報と座席情報を管理ＤＢ１１１に格納する。チケットに対して初回に生成されるＱＲコードは、有効なものとなる。ここでいうＱＲコードの有効とは、ＱＲコードに対応するチケットが有効であることを示し、当該チケットを所有可能、すなわち当該ＱＲコードを取得可能となることを意味する。逆に、ＱＲコードの無効とは、ＱＲコードに対応するチケットが無効であることを示し、当該チケットを所有不可、すなわち当該ＱＲコードを取得できなくなることを意味する。そして、チケット分配部１２１は、分配した各利用者の携帯端末２のアドレス宛へＱＲコードの取得を促すメール（「ＱＲ取得メール」という）を送信する。ＱＲ取得メールには、例えば、ＱＲコードが取得されるＵＲＬ（「ＱＲ取得ＵＲＬ」という）、予約番号、生成されたＱＲコードを取得する際の認証に用いられるパスワードが含まれる。

また、チケット分配部１２１は、購入者による分配要求であって既に分配されたチケットの分配要求に基づき、既に生成されたＱＲコードと異なるＱＲコードを生成し、新たなチケットの利用者に対応付けて管理ＤＢ１１１に格納する。すなわち、購入者が一旦チケットを分配した後に、分配したチケットを別の利用者に譲渡したい場合に行われる。ここでは、チケット分配部１２１は、譲渡するチケットについて、新たな分配先の利用者情報に対応付けて新たなＱＲコードの情報と座席情報を管理ＤＢ１１１に格納する。そして、チケット分配部１２１は、新たな分配先の携帯端末２のアドレス宛へＱＲ取得メールを送信する。このとき、チケット分配部１２１は、元の分配先がＱＲコードを取得している場合、元の分配先の携帯端末２のアドレス宛へＱＲコードの返却を促すメール（「ＱＲ返却メール」という）を送信する。一方、チケット分配部１２１は、元の分配先がＱＲコードを取得していない場合、元の分配先のＱＲ取得ＵＲＬを無効にすることを示すメール（「ＵＲＬ無効メール」という）を元の分配先の携帯端末２のアドレス宛へ送信する。これは、元の分配先のＱＲコードを無効化するためである。なお、チケット分配部１２１の詳細については後述する。

ＱＲ返却部１２２は、元の分配先の携帯端末２からＱＲコードの返却承認を受信した場合に、当該ＱＲコードを無効化するとともに、分配先のＱＲコードを有効化する。なお、ＱＲ返却部１２２の詳細については後述する。

ＱＲ表示部１２３は、分配先の携帯端末２からＱＲコードの取得要求を受信した場合に、元の分配先のＱＲコードが無効化されていれば、分配先のＱＲコードの取得回数を１加算して得られた値を管理ＤＢ１１１に格納する。そして、ＱＲ表示部１２３は、取得されたＱＲコードを分配先の携帯端末２のモニタに表示する。すなわち、ＱＲ表示部１２３は、元の分配先のＱＲコードが返却されていれば、分配先のＱＲコードを分配先の携帯端末２のモニタに表示できる。分配先の携帯端末２に表示されたＱＲコードが、分配先の利用者が入場する際に認証に用いられるＱＲコードとなる。ここで、分配先の利用者は、表示されたＱＲコードを誤って削除することもある。このため、分配先の利用者は、規定回数まで同じＱＲコードを再取得できるようにしても良い。なお、ＱＲ表示部１２３の詳細については後述する。

ＱＲ認証部１２４は、利用者が入場する際、携帯端末２に表示されたＱＲコードを用いて認証を行う。例えば、ＱＲ認証部１２４は、利用者の携帯端末２に表示されたＱＲコードを読み取る図示しない読み取り装置からＱＲコードを受信する。そして、ＱＲ認証部１２４は、受信したＱＲコードを後述する管理ＤＢ１１１内に紐付かれたＱＲ画像と照合し、利用者のＱＲコードを認証する。そして、ＱＲ認証部１２４は、受信したＱＲコードがＱＲ画像と合致すれば、入場を許可する旨の通知を、読み取り装置に送信する。これにより、利用者は、入場できることとなる。一方、ＱＲ認証部１２４は、受信したＱＲコードがＱＲ画像と合致しなければ、入場を許可しない旨の通知を読み取り装置に送信する。これにより、利用者は、入場できないことになる。

［管理ＤＢのデータ構造］
次に、管理ＤＢ１１１のデータ構造について、図２を参照して説明する。図２は、実施例１に係る管理ＤＢのデータ構造の一例を示す図である。図２に示すように、管理ＤＢ１１１は、現ＱＲコード１１１ａと、旧ＱＲコード１１１ｂと、席種類１１１ｃと、席種類名１１１ｄと、階数１１１ｅと、列数１１１ｆと、席番号１１１ｇと、ブロック番号１１１ｈと、ゲート１１１ｉとを有する。さらに、管理ＤＢ１１１は、予約番号１１１ｊと、ＱＲ画像ファイル名１１１ｋと、ＱＲ取得回数１１１ｌと、パスワードＢ１１１ｍと、メールアドレス１１１ｎと、電話番号１１１ｏと、所有者フラグ１１１ｐとを有する。

現ＱＲコード１１１ａは、現在のＱＲコードの内容を示す。旧ＱＲコード１１１ｂは、初回に生成されたＱＲコードの内容を示す。席種類１１１ｃは、座席の種類を表すコードを示す。席種類名１１１ｄは、座席の種類の名称を示す。階数１１１ｅは、座席のある階数を示す。列数１１１ｆは、座席のある列数を示す。席番号１１１ｇは、座席の番号を示す。かかる階数１１１ｅ、列数１１１ｆおよび席番号１１１ｇが、一意の座席情報となる。すなわち、購入者がこの座席情報のチケットを譲渡する場合、譲渡先の現ＱＲコード１１１ａには、譲渡元と異なるＱＲコードが設定される。

ブロック番号１１１ｈは、座席をブロックでグループ化した場合の座席の存在するブロックの番号を示す。ゲート１１１ｉは、入場ゲートを示す。予約番号１１１ｊは、チケットを購入したときの予約番号を示す。ＱＲ画像ファイル名１１１ｋは、ＱＲ画像を記憶したファイルの名称を示す。ＱＲ取得回数１１１ｌは、同一のＱＲコードを取得した回数を示す。パスワードＢ１１１ｍは、ＱＲコードを取得する際認証に用いられるパスワードを示す。メールアドレス１１１ｎは、利用者のメールアドレスを示す。電話番号１１１ｏは、利用者の電話番号を示し、ＱＲコードを取得する際パスワードＢ１１１ｍとともに認証に用いられる。所有者フラグ１１１ｐは、チケットの所有者に関するフラグを示す。所有者フラグ１１１ｐには、例えば、チケットを所有していないことを表す「０」、チケットを所有可能であることを表す「１」、チケットの所有を解放したことを表す「９」がある。

一例として、購入者が購入したチケットを分配する前の管理ＤＢ１１１内の内容を示す。予約番号１１１ｊが「Ｙ５０００１８３」、階数１１１ｅが「１階」、列数１１１ｆが「Ｉ列」、席番号１１１ｇが「１８３番」である場合、現ＱＲコード１１１ａとして「Ｆ１５３００」、旧ＱＲコード１１１ｂとして「Ｆ１５３００」と記憶している。また、席種類１１１ｃとして「１００」、席種類名１１１ｄとして「アリーナ席」、ブロック番号１１１ｈとして「Ｇブロック」、ゲート１１１ｉとして「Ａゲート」と記憶している。また、ＱＲ画像ファイル名１１１ｋとして「Ｆ１５３００．ｊｐｅｇ」、ＱＲ取得回数１１１ｌとして「０」、所有者フラグ１１１ｐとして「１」と記憶している。分配先の利用者情報であるパスワードＢ１１１ｎ、メールアドレス１１１ｎ、電話番号１１１ｏには、まだデータが記憶されていない。

次に、図３〜図５を参照して、実施例１に係るチケット譲渡管理における処理のフローチャートを説明する。図３では、チケット分配処理のフローチャートについて説明する。図４では、ＱＲ返却処理のフローチャートについて説明する。図５では、ＱＲ表示処理のフローチャートについて説明する。なお、チケットの購入者の携帯端末２には、チケット販売サイト３から送信されたＱＲ配布メールが保持されている。かかるメールには、ＱＲ発行ＵＲＬ、チケットを購入した際の予約番号およびパスワードＡが含まれている。また、管理ＤＢ１１１には、チケットの購入情報として座席情報と予約番号が記憶され、さらに座席情報毎に初回に生成されたＱＲコード、所有者フラグ「１」（所有可能）、ＱＲ取得回数「０」が記憶されている。

［チケット分配処理のフローチャート］
図３に示すように、チケット分配部１２１が、予約番号に対してチケットの分配要求があったか否かを判定する（ステップＳ１１）。すなわち、チケット分配部１２１は、ＱＲ発行ＵＲＬよりアクセスがされたか否かを判定する。予約番号に対してチケットの分配要求がなかったと判定した場合（ステップＳ１１；Ｎｏ）、チケット分配部１２１は、当該分配要求があるまで判定処理を繰り返す。

一方、予約番号に対してチケットの分配要求があったと判定した場合（ステップＳ１１；Ｙｅｓ）、チケット分配部１２１は、ＱＲ情報入力画面を表示する（ステップＳ１２）。なお、ＱＲ情報入力画面は、購入者を認証する画面であり、認証に必要な情報例えば予約番号やパスワードＡを、購入者の携帯端末２から入力させる。ここで、チケット分配部１２１は、予約番号に対してチケットの分配要求があっても、分配要求があった所定の時点を越えると分配できないようにすることが望ましい。例えば、チケット分配部１２１は、チケットを用いて入場する日の０：００を超えると分配できないようにすべく、エラーを表示する。

そして、チケット分配部１２１は、入力された予約番号およびパスワードＡが管理ＤＢ１１１内の情報と一致しているか否かを判定する（ステップＳ１３）。管理ＤＢ１１１内の情報と一致していないと判定した場合（ステップＳ１３；Ｎｏ）、チケット分配部１２１は、一致するまで判定処理を繰り返す。

一方、管理ＤＢ１１１内の情報と一致していると判定した場合（ステップＳ１３；Ｙｅｓ）、チケット分配部１２１は、購入者が正当であると判断し、ＱＲ送信情報入力画面を表示する（ステップＳ１４）。なお、ＱＲ送信情報入力画面は、購入したチケットを分配先に分配する画面である。ＱＲ送信情報入力画面は、購入者の携帯端末２から、チケットに対応する座席情報毎に分配先の利用者情報を入力させる。ＱＲ送信情報入力画面は、初めて分配先を入力させる場合および分配先を譲渡するために分配先を変更させる場合に用いられる。座席情報とは、例えば、階数、列数および席番号で表される座席に関わる情報である。利用者情報とは、例えば、利用者の電話番号および利用者のメールアドレスである。利用者の電話番号は、利用者のハンドル名であっても良いし、合言葉であっても良いし、利用者と購入者との間で識別できる利用者の識別情報であれば良い。

そして、チケット分配部１２１は、座席情報に対応する分配先の利用者情報が入力されたか否かを判定する（ステップＳ１５）。座席情報に対応する利用者情報が入力されていないと判定した場合（ステップＳ１５；Ｎｏ）、チケット分配部１２１は、当該情報が入力されるまで、判定処理を繰り返す。

一方、座席情報に対応する利用者情報が入力されていると判定した場合（ステップＳ１５；Ｙｅｓ）、チケット分配部１２１は、管理ＤＢ１１１に同一の座席情報が格納されているか否かを判定する（ステップＳ１６）。管理ＤＢ１１１に同一の座席情報が格納されていないと判定した場合（ステップＳ１６；Ｎｏ）、チケット分配部１２１は、分配先の利用者情報を座席情報に対応付けて格納する（ステップＳ１７）。これにより、チケット分配部１２１は、この座席情報に対して初回に生成されたＱＲコードを有効化することになる。なお、管理ＤＢ１１１内の利用者情報は、例えば、電話番号１１１ｏとメールアドレス１１１ｎに対応する。管理ＤＢ１１１内の座席情報は、例えば、階数１１１ｅ、列数１１１ｆ、席番号１１１ｇに対応する。

そして、チケット分配部１２１は、分配先のメールアドレスへＱＲ取得メールを送信する（ステップＳ１８）。そして、チケット分配部１２１は、チケット分配処理を終了する。

一方、管理ＤＢ１１１に同一の座席情報が格納されていると判定した場合（ステップＳ１６；Ｙｅｓ）、チケット分配部１２１は、同一の座席情報に対応するＱＲコードが取得されているか否かを判定する（ステップＳ１９）。なお、ＱＲコードが取得されているか否かは、管理ＤＢ１１１内の、同一の座席情報に対応する所有者フラグ１１１ｐおよびＱＲ取得回数１１１ｌのそれぞれの値によって判別される。所有者フラグ１１１ｐが「１」（所有可能）であり、且つＱＲ取得回数１１１ｌが「０」より大きい場合に、ＱＲコードが取得されていると判別される。所有者フラグ１１１ｐが「１」（所有可能）であり、且つＱＲ取得回数１１１ｌが「０」である場合に、ＱＲコードが取得されていないと判別される。

ここで、ＱＲコードが取得されていると判定した場合（ステップＳ１９；Ｙｅｓ）、チケット分配部１２１は、同一の座席情報に対応するＱＲコードと異なるＱＲコードを生成する。そして、チケット分配部１２１は、生成したＱＲコードと座席情報に分配先情報を対応付けて格納する（ステップＳ２０）。このとき、チケット分配部１２１は、所有者フラグに「０」（未所有）、ＱＲ取得回数に「０」を設定する。

そして、チケット分配部１２１は、分配先のメールアドレスへＱＲ取得メールを送信すると同時に、取得されているＱＲコードの所有者にＱＲ返却メールを送信する（ステップＳ２１）。すなわち、チケット分配部１２１は、一旦分配されたチケットの譲渡先にＱＲコードの取得を促すメールを送信すると同時に、分配元（譲渡元）にＱＲコードの返却を促すメールを送信する。そして、チケット分配部１２１は、チケット分配処理を終了する。

一方、ＱＲコードが取得されていないと判定した場合（ステップＳ１９；Ｎｏ）、チケット分配部１２１は、分配先のメールアドレスへＱＲ取得メールを送信する。同時に、チケット分配部１２１は、取得されていないＱＲコードの権利者のメールアドレスへＵＲＬ無効メールを送信する（ステップＳ２２）。これにより、チケット分配部１２１は、この座席情報に対して取得されていないＱＲコードを無効化する。

そして、チケット分配部１２１は、取得されていないＱＲコードの権利者のレコードについて、当該権利者に代えて新たな分配先の利用者情報を上書きする（ステップＳ２３）。これにより、チケット分配部１２１は、この座席情報に対して新たな分配先のＱＲコードを有効化する。そして、チケット分配部１２１は、チケット分配処理を終了する。

［ＱＲ返却処理のフローチャート］
図４に示すように、ＱＲ返却部１２２は、ＱＲコードの返却指示（返却承認）があったか否かを判定する（ステップＳ３１）。ＱＲコードの返却指示がなかったと判定した場合（ステップＳ３１；Ｎｏ）、ＱＲ返却部１２２は、ＱＲコードの返却指示があるまで、判定処理を繰り返す。

一方、ＱＲコードの返却指示があったと判定した場合（ステップＳ３１；Ｙｅｓ）、ＱＲ返却部１２２は、返却指示があった所有者のレコードに対して、所有者フラグ１１１ｐを「９」（解放）に設定する（ステップＳ３２）。これにより、ＱＲ返却部１２２は、この所有者に対するＱＲコードを無効化する。

そして、ＱＲ返却部１２２は、分配先のレコードに対して、所有者フラグ１１１ｐを「１」（所有可能）に設定する（ステップＳ３３）。これにより、ＱＲ返却部１２２は、分配先に対するＱＲコードを有効化する。そして、ＱＲ返却部１２２は、ＱＲ返却処理を終了する。

［ＱＲ表示処理のフローチャート］
図５に示すように、ＱＲ表示部１２３は、分配先からＱＲ取得要求があったか否かを判定する（ステップＳ４１）。すなわち、ＱＲ表示部１２３は、ＱＲ取得ＵＲＬよりアクセスがされたか否かを判定する。ＱＲ取得要求がなかったと判定した場合（ステップＳ４１；Ｎｏ）、ＱＲ表示部１２３は、ＱＲ取得要求があるまで、判定処理を繰り返す。

一方、ＱＲ取得要求があったと判定した場合（ステップＳ４１；Ｙｅｓ）、ＱＲ表示部１２３は、ＱＲ取得画面を表示する（ステップＳ４２）。なお、ＱＲ取得画面は、分配先を認証する画面であり、分配先の携帯端末２から分配先の認証に必要な情報、例えばパスワードＢや分配先の電話番号を入力させる。

そして、ＱＲ表示部１２３は、入力されたパスワードＢおよび分配先の電話番号が管理ＤＢ１１１内の分配先情報と一致しているか否かを判定する（ステップＳ４３）。管理ＤＢ１１１内の分配先情報と一致していないと判定した場合（ステップＳ４３；Ｎｏ）、ＱＲ表示部１２３は、一致するまで判定処理を繰り返す。

一方、管理ＤＢ１１１内の分配先情報と一致していると判定した場合（ステップＳ４３；Ｙｅｓ）、ＱＲ表示部１２３は、分配先が正当であると判断する。そして、ＱＲ表示部１２３は、ＱＲ取得回数１１１ｌが規定回数内であるか否かを判定する（ステップＳ４４）。ＱＲ取得回数１１１ｌが規定回数内であると判定した場合（ステップＳ４４；Ｙｅｓ）、ＱＲ表示部１２３は、同一の座席情報に対応する所有者フラグ１１１ｐが「１」（所有可能）であるか否かを判定する（ステップＳ４５）。

同一の座席情報に対応する所有者フラグ１１１ｐが「１」（所有可能）であると判定した場合（ステップＳ４５；Ｙｅｓ）、ＱＲ表示部１２３は、分配先に対応するＱＲコードをページに表示する。そして、ＱＲ表示部１２３は、分配先のレコードに対して、ＱＲ取得回数１１１ｌを１加算して得られた値を設定する（ステップＳ４６）。これにより、この座席情報の所有者が、ＱＲ取得要求があった分配先となる。そして、ＱＲ表示部１２３は、ＱＲ表示処理を終了する。

ＱＲ取得回数１１１ｌが規定回数外であると判定した場合（ステップＳ４４；Ｎｏ）、または同一の座席情報に対応する所有者フラグ１１１ｐが「１」（所有可能）でないと判定した場合（ステップＳ４５；Ｎｏ）、ＱＲ表示部１２３は、取得エラーを表示する（ステップＳ４７）。例えば、ＱＲ表示部１２３は、ＱＲ取得回数１１１ｌが規定回数外である場合、ＱＲ取得回数１１１ｌが規定回数を超えていることを表示する。ＱＲ表示部１２３は、同一の座席情報に対応する所有者フラグ１１１ｐが「１」（所有可能）でない場合、同一の座席情報のチケットがまだ返却されていないことを表示する。そして、ＱＲ表示部１２３は、ＱＲ表示処理を終了する。

［通常譲渡する場合のチケット譲渡管理処理のシーケンス］
次に、通常譲渡する場合のチケット譲渡管理処理のシーケンスを、適宜管理ＤＢ１１１内のデータの内容を用いながら説明する。図６は、通常譲渡する場合のチケット譲渡管理処理のシーケンスを説明する図である。図６では、購入者Ａがチケットを２席購入し、購入者Ａは席ａの所有者になり、分配先Ｂは席ｂの所有者になったとする。以下では、購入者Ａが分配先Ｂによって所有されている席ｂを分配先Ｃに譲渡する場合について説明する。なお、以下では、図１０に示される管理ＤＢ１１１内の席ｂのレコードを適宜用いながら説明する。

購入者Ａの認証が成功した後、チケット分配部１２１は、ＱＲ送信情報入力画面を表示する（ステップＳ５１）。

この時点では、管理ＤＢ１１１内の席ｂのレコードには、メールアドレス１１１ｎとして「Ｂのアドレス」、電話番号１１１ｏとして「ＢのＴＥＬ」が設定されている。所有者フラグ１１１ｐとして「１」（所有可能）、ＱＲ取得回数１１１ｌとして「１」が設定されている（図１０、Ｎｏ２参照）。

そして、購入者ＡがＱＲ送信情報入力画面を用いて、席ｂに対して譲渡先の電話番号および譲渡先のメールアドレスを入力する。すると、チケット分配部１２１は、席ｂに対応する所有者フラグ１１１ｐが「１」であり、且つＱＲ取得回数１１１ｌが「１」であるので、ＱＲコードが取得されていると判別する。そこで、チケット分配部１２１は、管理ＤＢ１１１内に、席ｂに対応する分配先Ｃのレコードを追加する。

ここでは、管理ＤＢ１１１内の追加されたレコードには、新規に生成される現ＱＲコード１１１ａとして「Ｆ１５３４３」、メールアドレス１１１ｎとして「Ｃのアドレス」、電話番号１１１ｏとして「ＣのＴＥＬ」が設定されている。所有者フラグ１１１ｐとして「０」（未所有）、ＱＲ取得回数１１１ｌとして「０」が設定されている（図１０、Ｎｏ４参照）。

そして、チケット分配部１２１は、譲渡先（分配先Ｃ）のメールアドレスへＱＲ取得メールを送信する（ステップＳ５２）。また、チケット分配部１２１は、ＱＲ取得メールと同時にＱＲ返却メールを席ｂの現在の所有者である分配先Ｂに対して送信する（ステップＳ５３）。

その後、分配先ＢによりＱＲ返却ＵＲＬにアクセスがされると、ＱＲ返却部１２２は、ＱＲ返却承認画面を表示する（ステップＳ５４）。そして、分配先Ｂが返却承認画面を用いて席ｂに対応するＱＲの返却承認をすると、ＱＲ返却部１２２は、分配先Ｂのレコードに対して、所有者フラグ１１１ｐを「９」（解放）に設定する。これと同時に、分配先Ｃのレコードに対して、所有者フラグ１１１ｐを「１」（所有可能）に設定する（図１０、Ｎｏ５参照）。これにより、ＱＲ返却部１２２は、分配先Ｂに対するＱＲコードを無効化するとともに、分配先Ｃに対するＱＲコードを有効化する。この結果、分配先Ｂは、所有者でなくなる。

そして、分配先ＣによりＱＲ取得ＵＲＬにアクセスがされると、ＱＲ表示部１２３は、ＱＲ取得画面を表示する（ステップＳ５５）。そして、分配先ＣがＱＲ取得画面を用いて、自己の電話番号およびパスワードを入力する。すると、ＱＲ表示部１２３は、入力した電話番号およびパスワードが管理ＤＢ１１１内の分配先Ｃに対応する電話番号１１１ｏおよびパスワードＢ１１１ｍと一致すれば、分配先Ｃが正当であると判断する。さらに、ＱＲ表示部１２３は、分配先Ｃに対応する所有者フラグ１１１ｐが「１」（所有可能）であれば、分配先ＣのレコードのＱＲ取得回数１１１ｌに「１」を設定する（図１０、Ｎｏ６参照）。そして、ＱＲ表示部１２３は、分配先Ｃに対してＱＲを表示する。

この結果、席ｂの所有者が分配先Ｂから分配先Ｃに変更される。

［譲渡元が返却承認しない場合のチケット譲渡管理処理のシーケンス］
次に、譲渡元の分配先ＢがＱＲ返却メールを受け取った後に、返却承認をしない場合のチケット譲渡管理処理のシーケンスを、図７を参照して説明する。図７は、譲渡元が返却承認しない場合のチケット譲渡管理処理のシーケンスを説明する図である。なお、図６に示す通常譲渡する場合のシーケンスと同一のシーケンスについては同一符号を示すことで、その重複する動作の説明については省略する。また、以下では、図１１に示される管理ＤＢ１１１内の席ｂのレコードを適宜用いながら説明する。

ステップＳ５２では、チケット分配部１２１が、譲渡先（分配先Ｃ）のメールアドレスへＱＲ取得メールを送信する。また、ステップＳ５３では、チケット分配部１２１が、譲渡先である分配先ＣへのＱＲ取得メールと同時にＱＲ返却メールを席ｂの現在の所有者である分配先Ｂに対して送信する。ここで、分配先ＢがＱＲ返却ＵＲＬにアクセスしないで、ＱＲの返却承認をしないとする。

その後、分配先ＣによりＱＲ取得ＵＲＬにアクセスがされると、ＱＲ表示部１２３は、ＱＲ取得画面を表示する（ステップＳ５５）。そして、分配先ＣがＱＲ取得画面を用いて、自己の電話番号およびパスワードを入力する。すると、ＱＲ表示部１２３は、入力した電話番号およびパスワードが管理ＤＢ１１１内の分配先Ｃに対応する電話番号１１１ｏおよびパスワードＢ１１１ｍと一致すれば、分配先Ｃが正当であると判断する。

ところが、ＱＲ表示部１２３は、分配先Ｂに対応する所有者フラグ１１１ｐが「１」（所有可能）であり「９」（解放）でないので（図１１、Ｎｏ４参照）、取得エラーを表示する。すなわち、現在の所有者である分配先Ｂが返却承認しないので、譲渡先である分配先ＣはＱＲを取得できない。

この結果、席ｂの所有者は、分配先Ｂのままとなり、分配先Ｃに変更されない。

［譲渡先が取得しない場合のチケット譲渡管理処理のシーケンス］
次に、譲渡元の分配先ＢがＱＲの返却承認をしても、譲渡先の分配先ＣがＱＲを取得しない場合のチケット譲渡管理処理のシーケンスを、図８を参照して説明する。図８は、譲渡先が取得しない場合のチケット譲渡管理処理のシーケンスを説明する図である。なお、図６に示す通常譲渡する場合のシーケンスと同一のシーケンスについては同一符号を示すことで、その重複する動作の説明については省略する。また、以下では、図１０に示される管理ＤＢ１１１内の席ｂのレコードを適宜用いながら説明する。

ステップＳ５２では、チケット分配部１２１が、譲渡先（分配先Ｃ）のメールアドレスへＱＲ取得メールを送信する。また、ステップＳ５３では、チケット分配部１２１が、譲渡先である分配先ＣへのＱＲ取得メールと同時にＱＲ返却メールを席ｂの現在の所有者である分配先Ｂに対して送信する。

その後、分配先ＢによりＱＲ返却ＵＲＬにアクセスがされると、ＱＲ返却部１２２は、ＱＲ返却承認画面を表示する（ステップＳ５４）。そして、分配先Ｂが返却承認画面を用いて席ｂに対応するＱＲの返却承認をすると、ＱＲ返却部１２２は、分配先Ｂのレコードに対して、所有者フラグ１１１ｐを「９」（解放）に設定する。これと同時に、分配先Ｃのレコードに対して、所有者フラグ１１１ｐを「１」（所有可能）に設定する（図１０、Ｎｏ５参照）。これにより、ＱＲ返却部１２２は、分配先Ｂに対するＱＲコードを無効化するとともに、分配先Ｃに対するＱＲコードを有効化する。この結果、分配先Ｂは、所有者でなくなる。

その後、譲渡先の分配先ＣがＱＲ取得ＵＲＬにアクセスしないで、ＱＲを取得しないとする。すると、席ｂの所有者は、いない状態となる。そこで、席ｂに対する権利をＱＲの未取得者である分配先Ｃから別の利用者に譲渡する場合を、以下に示す。

［未取得者の権利を譲渡する場合のチケット譲渡管理処理のシーケンス］
図９は、未取得者の権利を譲渡する場合のチケット譲渡管理処理のシーケンスを説明する図である。なお、以下では、図１２に示される管理ＤＢ１１１内の席ｂのレコードを適宜用いながら説明する。

購入者Ａの認証が成功した後、チケット分配部１２１は、ＱＲ送信情報入力画面を表示する（ステップＳ６１）。

この時点では、管理ＤＢ１１１内の席ｂの分配先Ｂに対応するレコードには、メールアドレス１１１ｎとして「Ｂのアドレス」、電話番号１１１ｏとして「ＢのＴＥＬ」が設定されている。所有者フラグ１１１ｐとして「９」（解放）が設定されている。また、管理ＤＢ１１１内の席ｂの分配先Ｃに対応するレコードには、メールアドレス１１１ｎとして「Ｃのアドレス」、電話番号１１１ｏとして「ＣのＴＥＬ」が設定されている。所有者フラグ１１１ｐとして「１」（所有可能）、ＱＲ取得回数１１１ｌとして「１」が設定されている（図１２、Ｎｏ５参照）。

そして、購入者ＡがＱＲ送信情報入力画面を用いて、席ｂに対して譲渡先（分配先Ｄ）の電話番号およびメールアドレスを入力する。すると、チケット分配部１２１は、席ｂの譲渡元（分配先Ｃ）に対応する所有者フラグ１１１ｐが「１」であり、且つＱＲ取得回数１１１ｌが「０」であるので、ＱＲコードが取得されていないと判別する。そこで、チケット分配部１２１は、取得されていないＱＲコードの権利者（分配先Ｃ）に対してＵＲＬ無効メールを送信する（ステップＳ６２）。これにより、チケット分配部１２１は、席ｂに対して取得されていない権利者（分配先Ｃ）のＱＲコードを無効化する。

そして、チケット分配部１２１は、譲渡先（分配先Ｄ）のメールアドレスへＱＲ取得メールを送信する（ステップＳ６３）。そして、チケット分配部１２１は、取得されていないＱＲコードの権利者（分配先Ｃ）のレコードに新たな分配先Ｄの利用者情報を上書きする。

ここでは、管理ＤＢ１１１内に、席ｂに対して、メールアドレス１１１ｎとして「Ｄのアドレス」、電話番号１１１ｏとして「ＤのＴＥＬ」が設定されている（図１２、Ｎｏ９参照）。

そして、分配先ＤによりＱＲ取得ＵＲＬにアクセスがされると、ＱＲ表示部１２３は、ＱＲ取得画面を表示する（ステップＳ６４）。そして、分配先ＤがＱＲ取得画面を用いて、自己の電話番号およびパスワードを入力する。すると、ＱＲ表示部１２３は、入力した電話番号およびパスワードが管理ＤＢ１１１内の分配先Ｄに対応する電話番号１１１ｏおよびパスワードＢ１１１ｍと一致すれば、分配先Ｄが正当であると判断する。さらに、ＱＲ表示部１２３は、分配先Ｄの所有者フラグ１１１ｐが「１」（所有可能）であるので、分配先ＤのレコードのＱＲ取得回数１１１ｌに「１」を設定する（図１２、Ｎｏ１０参照）。そして、ＱＲ表示部１２３は、分配先Ｄに対してＱＲを表示する。

この結果、席ｂの所有者が分配先Ｂから分配先Ｄに変更される。

［チケット譲渡管理の画面遷移］
次に、実施例１に係るチケット譲渡管理の画面遷移を、図１３を参照して説明する。図１３は、実施例１に係るチケット譲渡管理の画面遷移を説明する図である。

図１３に示すように、購入者がチケットを購入した際、チケット販売サイト３からＱＲ配布メールが購入者の携帯端末２に送信される。ＱＲ配布メールのＱＲ発行ＵＲＬがアクセスされると、ＱＲ情報入力画面がチケット分配部１２１によって表示される（ステップＳ７１）。

次に、ＱＲ情報入力画面で予約番号、パスワードＡおよび名前（カタカナ）が入力されると、認証がＯＫである場合、ＱＲ送信情報入力画面がチケット分配部１２１によって表示される（ステップＳ７２）。そして、ＱＲ送信情報入力画面でチケット（座席情報）毎に分配先の電話番号およびメールアドレスが入力されると、入力された分配先の内容の確認を促すＱＲ送信確認画面がチケット分配部１２１によって表示される（ステップＳ７３）。

そして、ＱＲ送信確認画面でメール送信ボタンが押下されると、分配先に関わる送信内容に間違いがなければ、ＱＲ送信完了画面がチケット分配部１２１によって表示される（ステップＳ７４）。一方、分配先に関わる送信内容に間違いがあれば、送信エラーメールがチケット分配部１２１によって購入者の携帯端末２に送信される（ステップＳ７５）。

また、ＱＲ送信確認画面でメール送信ボタンが押下されると、分配先に関わる送信内容に間違いがなければ、ＱＲ取得メールがチケット分配部１２１によって分配先の携帯端末２に送信される（ステップＳ７６）。そして、ＱＲ取得メールのＱＲ取得ＵＲＬがアクセスされると、ＱＲ取得画面がＱＲ表示部１２３によって表示される（ステップＳ７７）。

そして、ＱＲ取得画面でパスワードＢおよび電話番号が入力されると、認証がＯＫである場合、ＱＲがＱＲ表示部１２３によって表示される（ステップＳ７８）。一方、認証がＮＧである場合または取得条件を満たさない場合、ＱＲの取得エラーがＱＲ表示部１２３によって表示される（ステップＳ７９）。取得条件を満たさない場合とは、例えばＱＲ取得を規定回数以上行った場合や現在の所有者がＱＲの返却承認を行っていない場合である。

ＱＲ送信確認画面でチケット（座席情報）を新たな分配先に譲渡する場合、座席情報の分配元がＱＲコードを取得している場合、ＱＲ返却メールがチケット分配部１２１によって分配元の携帯端末２に送信される（ステップＳ８０）。そして、ＱＲ返却メールのＱＲ返却承認ＵＲＬがアクセスされると、ＱＲ返却承認画面がＱＲ返却部１２３によって表示される（ステップＳ８１）。

そして、ＱＲ返却承認画面で承認ボタンが押下されると、返却完了画面がＱＲ返却部１２３によって表示される（ステップＳ８２）。これにより、返却されたＱＲコードは、無効になる。

ＱＲ送信確認画面でチケット（座席情報）を新たな分配先に譲渡する場合、座席情報の分配元がＱＲコードを取得していない場合、ＵＲＬ無効メールがチケット分配部１２１によって分配元の携帯端末２に送信される（ステップＳ８３）。これにより、分配元のＱＲ取得ＵＲＬは無効になる。

［チケット譲渡管理処理で用いられる画面およびメールの一例］
図１４は、ＱＲ情報入力画面の一例を示す図である。図１４に示すように、チケットの購入者の携帯端末２からＱＲ発行ＵＲＬがアクセスされると、チケット分配部１２１は、予約番号、パスワードおよび名前（カタカナ）を入力できるテキストボックスを表示するとともに、ＱＲ送信情報入力画面に遷移するために、送信ボタンを表示する。図１４では、チケット分配部１２１は、購入者を認証し、認証に成功したらＱＲ送信情報入力画面に遷移することができる。

図１５は、ＱＲ送信情報入力画面の一例を示す図である。図１５に示すように、チケット分配部１２１は、座席情報毎にチケットの分配先の電話番号およびメールアドレスを入力できるテキストボックスを表示する。また、チケット分配部１２１は、分配先にＱＲ送信確認画面を介してＱＲ取得メールを送信するために、座席情報毎にメール送信ボタンを表示する。さらに、チケット分配部１２１は、入力された座席情報毎の分配先に一括してＱＲ取得メールを送信するために、メール一括送信ボタンを表示する。図１５では、チケット分配部１２１は、購入者に、座席情報毎にチケットの分配先を入力させることができる。なお、ＱＲ送信情報入力画面は、分配先を変更する場合にも用いられる。かかる場合の画面の一例は、後述する。

図１６は、ＱＲ送信確認画面の一例を示す図である。図１６に示すように、チケット分配部１２１は、ＱＲ送信情報入力画面で入力された座席情報毎の分配先情報を表示する。また、チケット分配部１２１は、分配先にＱＲ取得メールを送信するために、メール送信ボタンを表示する。図１６では、チケット分配部１２１は、購入者に座席情報毎の分配先を確認させることができる。

図１７は、ＱＲ送信完了画面の一例を示す図である。図１７に示すように、チケット分配部１２１は、分配先にＱＲ取得メールを送信したことを示すメッセージを表示する。図１７では、チケット分配部１２１は、購入者に分配先にＱＲ取得メールを送信したことを確認させることができる。

図１８は、送信エラーメールの一例を示す図である。図１８に示すように、チケット分配部１２１は、分配先へのＱＲ取得メールの送信が失敗したことを示すメッセージを表示する。図１８では、チケット分配部１２１は、購入者に分配先へのＱＲ取得メールの送信が失敗したことを知らせることができる。

図１９は、ＱＲ取得メールの一例を示す図である。図１９に示すように、ＱＲ取得メールには、分配されたチケットの座席情報、予約番号やＱＲコードを取得するために必要なパスワードおよびＱＲ取得ＵＲＬが記述されている。図１９では、ＱＲ取得メールは、分配先にＱＲ取得を促すことができる。なお、ＱＲ取得メールは、チケット分配部１２１から分配先の携帯端末２に送信される。

図２０は、ＱＲ取得画面の一例を示す図である。図２０に示すように、ＱＲ表示部１２３は、分配された座席情報とともに、電話番号およびパスワードを入力できるテキストボックスを表示する。また、ＱＲ表示部１２３は、分配先を認証後にＱＲを表示するために、送信ボタンを表示する。図２０では、ＱＲ表示部１２３は、認証に成功し、且つ取得条件を満たせばＱＲを表示することができる。

図２１は、分配先を変更する場合のＱＲ送信情報入力画面の一例を示す図である。図２１に示すように、チケット分配部１２１は、座席情報毎に新たな分配先の電話番号およびメールアドレスを入力するテキストボックスを表示する。電話番号およびメールアドレスのそれぞれのテキストボックスには、既に分配された分配先の電話番号およびメールアドレスが表示される。また、チケット分配部１２１は、既に分配された分配先毎に、ＱＲコードの取得状況を表すステータスを表示する。ステータスには、例えば、ＱＲコードの取得待ちであることを示す「ＱＲ取得待ち」、ＱＲコードの取得済みであることを示す「ＱＲ取得済み」が表示される。なお、チケット分配部１２１は、管理ＤＢ１１１における、分配先に対応する所有者フラグ１１１ｐ、ＱＲ取得回数１１１ｌがそれぞれ「１」（所有可能）、「０」である場合に、ステータスに「ＱＲ取得待ち」を表示すれば良い。また、チケット分配部１２１は、管理ＤＢ１１１における、分配先に対応する所有者フラグ１１１ｐ、ＱＲ取得回数１１１ｌがそれぞれ「１」（所有可能）、「１以上」である場合に、ステータスに「ＱＲ取得済み」を表示すれば良い。図２１では、チケット分配部１２１は、購入者に、分配先を変更させることができるとともに、分配先のＱＲコードの取得状況を確認させることができる。

図２２は、ＱＲ返却メールの一例を示す図である。図２２に示すように、ＱＲ返却メールには、分配されたチケットの座席情報とともに、ＱＲコードの返却作業を行う旨のメッセージおよびＱＲ返却承認ＵＲＬが記述されている。図２２では、ＱＲ返却メールは、分配先にＱＲの返却承認を促すことができる。なお、ＱＲ返却メールは、ＱＲ返却部１２２から分配先の携帯端末２に送信される。

図２３は、ＱＲ返却承認画面の一例を示す図である。図２３に示すように、ＱＲ返却部１２２は、ＱＲコードを返却承認する場合にチェックできるチェックボックスを表示する。また、ＱＲ返却部１２２は、ＱＲコードを返却させるために、チケット（ＱＲコード）返却ボタンを表示する。図２３では、ＱＲ返却部１２２は、チケットの所有者にチケットに対応するＱＲコードの返却を承認させたうえで当該ＱＲコードを返却させることができる。

図２４は、返却完了画面の一例を示す図である。図２４に示すように、ＱＲ返却部１２２は、ＱＲコードの返却がされた旨のメッセージを表示する。図２４では、ＱＲ返却部１２２は、ＱＲコードの返却がされたことを、ＱＲコードを返却した所有者に確認させることができる。

図２５は、ＱＲ取得ＵＲＬ無効メールの一例を示す図である。図２５に示すように、ＱＲ取得ＵＲＬ無効メール（ＵＲＬ無効メール）には、分配されていたチケットが無効となった旨のメッセージが記述されている。図２５では、ＱＲ取得ＵＲＬ無効メールは、分配先であった利用者に分配されていたチケットが無効となったことを確認させることができる。なお、ＱＲ取得ＵＲＬ無効メールは、チケット分配部１２１から分配先であった利用者の携帯端末２に送信される。

なお、ＱＲ認証部１２４は、入場の際読み取り装置によって読み取られたＱＲコードを受信し、受信したＱＲコードを管理ＤＢ１１１内の紐付かれたＱＲ画像と照合し、照合の結果、合致すれば、入場を許可する旨の通知を読み取り装置に送信するようにした。一方、ＱＲ認証部１２４は、照合の結果、合致しなければ、入場を許可しない旨の通知を読み取り装置に送信するようにした。しかしながら、ＱＲ認証部１２４は、これに限定されず、照合の結果、合致すれば、受信したＱＲコードが有効化されているか否かを判定し、判定結果を読み取り装置に送信するようにしても良い。例えば、ＱＲ認証部１２４は、管理ＤＢ１１１に記憶されている、ＱＲコードに対応する所有者フラグ１１１ｐを参照して当該ＱＲコードの有効化されているか否かを判定する。すなわち、ＱＲ認証部１２４は、所有者フラグ１１１ｐが「１」（所有可能）である場合、ＱＲコードが有効であると判定する。一方、ＱＲ認証部１２４は、所有者フラグ１１１ｐが「９」（解放）である場合、ＱＲコードが無効であると判定する。そして、ＱＲ認証部１２４は、受信されたＱＲコードの有効または無効を判定結果として読み取り装置に送信する。これにより、ＱＲ認証部１２４は、読み取り装置に対して、照合に合致しなかったＱＲコードのみならず、無効化されているＱＲコードを識別させることができる。つまり、読み取り装置では、照合に合致しなかったＱＲコードの利用者のみならず、無効化されているＱＲコードの利用者の入場を不許可にできる。

また、ＱＲ認証部１２４は、照合の結果、合致すれば、受信したＱＲコードが有効化されているか否かを判定し、ＱＲコードが有効化されていれば、さらに、管理ＤＢ１１１に記憶されている利用者の携帯端末２に入場を許可された旨のメールを送信しても良い。これにより、ＱＲ認証部１２４は、利用者が入場の際、有効なＱＲコードの真の利用者にのみメールを送信することとなるので、入場後に発生するおそれのある入場者の正当性チェックを円滑に行わせることができる。

また、ＱＲ認証部１２４は、同じＱＲコードを複数回受信した場合、複数回アクセスがあったことを読み取り装置に送信するようにしても良い。この場合、ＱＲ認証部１２４は、ＱＲコード毎にアクセスがあった回数を記憶部１１に保持するようにし、アクセスがあったときに、アクセスがあったＱＲコードに対応する回数を参照するようすれば良い。これにより、ＱＲ認証部１２４は、読み取り装置に対して、複数回入場のあった利用者に対応するＱＲコードを識別させることができる。つまり、読み取り装置では、複製されたＱＲコードを識別することが可能となる。なお、ＱＲ認証部１２４は、複数回アクセスがあったことを読み取り装置に送信する際、管理ＤＢ１１１に記憶された利用者の電話番号を共に送信しても良い。これにより、読み取り装置では、ＱＲコードの利用者の電話番号を認識することができ、入場の際入場した利用者に対して電話番号の確認をすることができる。

［チケット譲渡管理処理の変形例］
上記実施例１では、サーバ１０は、一旦分配先に分配されたチケットが譲渡される場合、分配先のＱＲコードが返却されてから、譲渡先のＱＲコードを譲渡先に取得させるようにした。すなわち、サーバ１０は、分配先のＱＲコードが無効化され、譲渡先のＱＲコードが有効化されてから、譲渡先のＱＲコードを譲渡先の携帯端末２に表示する。しかしながら、サーバ１０は、これに限定されず、一旦分配先に分配されたチケットが譲渡される場合、分配先のＱＲコードが返却されてなくても、譲渡先のＱＲコードを譲渡先に取得させても良い。例えば、ＱＲ表示部１２３は、分配先のＱＲコードが無効化され、譲渡先のＱＲコードが有効化されているかを判定することなく、譲渡先のＱＲコードを譲渡先の携帯端末２に表示する。これにより、ＱＲコードの無効化や有効化とは無関係に、譲渡先は、自己のＱＲコードを表示することができる。但し、譲渡先のＱＲコードが有効となってから譲渡先の入場を可能とすることは上記実施例１の場合と同様である。つまり、サーバ１０は、元の分配先のＱＲコードを返却により無効とし、譲渡先のＱＲコードを有効とした後、譲渡先の入場を可能とする。

［実施例１の効果］
上記実施例１によれば、サーバ１０は、購入者（第１の利用者）の要求に基づき、認証に用いられる第１の可視情報を生成し、チケットの分配先（第２の利用者）に対応付けて管理ＤＢ１１１に格納する。そして、サーバ１０は、購入者（第１の利用者）の要求に基づき、分配先のチケットを譲渡する際、第１の可視情報と異なる第２の可視情報を生成し、新たな分配先（第３の利用者）に対応付けて管理ＤＢ１１１に格納する。そして、サーバ１０は、管理ＤＢ１１１に格納された第１の可視情報を無効化するとともに、第２の可視情報を有効化する。そして、サーバ１０は、第２の可視情報を第３の利用者のアドレス宛に送信する。これにより、サーバ１０は、元の分配先に対する可視情報を無効化するとともに、新たな分配先に対する可視情報を有効化するので、チケットの購入者が可視情報に対応するチケットの譲渡を一意に管理できる。

また、上記実施例１によれば、サーバ１０は、第１の可視情報が無効化され、且つ、第２の可視情報が有効化されている場合に、第２の可視情報を第３の利用者のアドレス宛に送信する。これにより、第１の可視情報が無効化され、第２の可視情報が有効化されない限り、第３の利用者は第２の可視情報を所有できないようにでき、可視情報に対応するチケットの譲渡を厳しく管理できる。

また、上記実施例１によれば、サーバ１０は、第１の可視情報が無効化され、且つ、第２の可視情報が有効化されているかを判定することなく、当該第２の可視情報を第３の利用者のアドレス宛に送信する。これにより、第１の可視情報の無効化や第２の可視情報の有効化とは独立して、第３の利用者は第２の可視情報を所有することができる。

また、上記実施例１によれば、サーバ１０は、第２の利用者の携帯端末２から第１の可視情報の返却承認を受信した場合に、第１の可視情報を無効化するとともに、第２の可視情報を有効化する。これにより、サーバ１０は、第２の利用者の返却承認を契機に、第１の可視情報を無効化するとともに、第２の可視情報を有効化するので、第１の可視情報および第２の可視情報に対応するチケットの譲渡を確実に一意に管理できる。

また、上記実施例１によれば、サーバ１０は、第２の可視情報が有効化されているが、第２の可視情報が未だ第３の利用者の携帯端末２に送信されていない場合には、第３の利用者からの返却承認なしに第２の可視情報を無効化する。これにより、サーバ１０は、第２の可視情報に対応するチケットを新たな利用者に安全に譲渡することができる。

また、上記実施例１によれば、サーバ１０は、読み取り装置から受信した第２の可視情報が有効な場合、管理ＤＢ１１１に記憶されている第２の可視情報に対応付けられた利用者の携帯端末２に、新たな可視情報を出力する。これにより、サーバ１０は、有効な可視情報に対応する利用者に新たな可視情報を出力するので、入場の際に正当な入場者を判別することができる。言い替えれば、サーバ１０は、例えば複製された可視情報を持つ入場者を判別することが可能となる。

また、上記実施例１では、チケット譲渡管理システム９は、チケット譲渡管理サイト１とチケット販売サイト３とを分ける構成とした。しかしながら、チケット譲渡管理システム９は、これに限定されず、チケット譲渡管理サイト１とチケット販売サイト３とを統合する構成としても良い。

また、上記実施例１では、ＱＲ認証部１２４は、サーバ１０内に有するものとした。しかしながら、ＱＲ認証部１２４は、これに限定されず、サーバ１０と異なる新たな情報処理装置内に有するものとしても良い。この場合、新たな情報処理装置では、サーバ１０の管理ＤＢ１１１内のデータを適宜コピーするようにすれば良い。

ところで、実施例１では、サーバ１０は、チケットの購入者による購入したチケットの分配要求に基づき、チケットを利用者に譲渡する。そして、サーバ１０は、既に譲渡されたチケットについて、チケットの購入者による分配要求に基づき、当該チケットを別の利用者に再譲渡する場合を説明した。しかしながら、サーバ１０は、さらに、チケットを既に譲渡された利用者からチケットの購入者へのチケットのキャンセル依頼に基づき、チケットの供給者（チケット販売サイト３）を介して当該チケットを別の利用者に再譲渡（再販売）する場合であっても良い。これにより、チケットの供給者が仲介することで、当初のチケットの購入者と新規購入者とが直接やり取りせずにチケットを売買できる。

そこで、実施例２では、サーバは、さらに、チケットを既に譲渡された利用者からチケットの当初の購入者へのチケットのキャンセル依頼に基づき、チケットの供給者を介して当該チケットを別の利用者に再譲渡（再販売）する場合について説明する。なお、実施例２では、チケットの供給者とは、チケット販売サイトのことを意味するものとする。

［実施例２に係るチケット譲渡管理システムの構成］
図２６は、実施例２に係るチケット譲渡管理システムの構成を示すブロック図である。なお、図１に示すチケット譲渡管理システム９と同一の構成については同一符号を示すことで、その重複する構成および動作の説明については省略する。実施例１と実施例２とが異なるところは、チケット譲渡管理サイト１に代えてチケット販売サイト３Ａがチケットの譲渡管理を行うサーバ３０を有するようにした点にある。また、実施例１と実施例２とが異なるところは、制御部１２にチケットキャンセル部２０１とチケット再販部２０２とを追加した点にある。

チケットキャンセル部２０１は、チケットの所有者の携帯端末２から当該チケットのキャンセル（取消）依頼を受信した場合に、当該チケットに対応するＱＲコードの対応付けを、キャンセル依頼を行ったチケットの所有者からチケットの供給者であるチケット販売サイト３Ａに変更する。つまり、チケットの所有者からチケットのキャンセル依頼があった場合には、キャンセル依頼があったチケットを一時的にチケット販売サイト３Ａが預かるようにする。そして、チケットキャンセル部２０１は、後述するチケット再販部２０２に対して、キャンセル依頼のあったチケットについて再販売の募集をさせる。

また、チケットキャンセル部２０１は、キャンセル依頼がされたチケットの購入を希望する旨の要求を、新たな購入者の携帯端末２から受信した場合に、当該チケットに対応する新たなＱＲコードを生成し、新たな購入者に対応付けて管理ＤＢ１１１に格納する。ここでは、チケットキャンセル部２０１は、新たな購入者の利用者情報に対応付けて新たなＱＲコードの情報とキャンセル依頼を受けたチケットの座席情報を管理ＤＢ１１１に格納する。そして、チケットキャンセル部２０１は、供給者であるチケット販売サイト３Ａに対応するＱＲコードを無効化するとともに、新たなＱＲコードを有効化する。つまり、チケット販売サイト３Ａが、再販売の募集の結果、新たな購入者が現れれば、チケット販売サイト３ＡのＱＲコードは無効となり、新たな購入者に新たなＱＲコードが付与される。

また、チケットキャンセル部２０１は、キャンセル依頼がされたチケットの購入を希望する旨の要求を受信しなかった場合に、当該チケットに対応するＱＲコードの対応付けを、チケット販売サイト３Ａから当初のチケットの購入者に変更する。つまり、チケット販売サイト３Ａによる再販売の募集の結果、新たな購入者が現れなければ、チケットの所有者は、当初のチケットの購入者となる。

また、チケットキャンセル部２０１は、チケットのキャンセル依頼の取り下げを受信した場合に、当該チケットに対応するＱＲコードの対応付けを、チケット販売サイト３Ａから当初のチケットの購入者に変更する。つまり、チケットのキャンセル依頼の取り下げがあった場合も、新たな購入者が現れなかった場合と同様に、チケットの所有者は、当初のチケットの購入者となる。なお、チケットキャンセル部２０１の詳細については後述する。

チケット再販部２０２は、キャンセル依頼のあったチケットの再販売の募集を行う。例えば、チケット再販部２０２は、チケット販売サイト３Ａ専用のチケット情報サイトまたは汎用化されたチケット情報サイトに、キャンセル依頼のあったチケットについて再販売の募集がある旨を書き込む。

このようにして、チケットキャンセル部２０１は、キャンセル依頼がされたチケットの売買に、供給者（チケット販売サイト３０）を仲介させることで、新たな購入者と当初の購入者との間で、直接やり取りせずチケットを売買させることができる。すなわち、新たな購入者と当初の購入者は、相互に、それぞれの個人情報をやり取りしないので、安全にチケットを売買できる。

また、チケットキャンセル部２０１は、キャンセル依頼がされたチケットの売買に、供給者を仲介させることで、新たな購入者と当初の購入者との間で、直接金銭のやり取りをせずチケットを売買させることができる。つまり、チケット再販部２０２が、供給者として、キャンセル依頼がされたチケットの再販売の募集を行い、新たな購入者が現れると、チケットの代金は、新たな購入者から供給者を経由して当初の購入者に支払われる。したがって、当初の購入者は、確実に、新たな購入者からチケットの代金を受け取ることができる。

また、チケットキャンセル部２０１は、キャンセル依頼がされたチケットの売買に、供給者（チケット販売サイト３Ａ）を仲介させることで、供給者に対して柔軟にチケットを販売させることができる。例えば、供給者は、当初の購入者に対して、早期にキャンセル情報を提供させるようにしておけば、提供されたキャンセル席と未だ販売できていない席で、連席販売することが可能となる。特に、供給者が、チケットの興行開催日の間近まで、座席情報を確定しない（購入者への座席情報の案内を遅らせる）場合には、効率的に連席販売することができる。

［チケットキャンセル処理のフローチャート］
次に、図２７を参照して、チケットキャンセル処理のフローチャートを説明する。図２７は、実施例２に係るチケットキャンセル処理のフローチャートを示す図である。なお、管理ＤＢ１１１には、当初のチケットの購入者からチケットが分配された分配先毎に、チケットの購入情報として、ＱＲコード情報、座席情報および利用者情報が記憶され、さらに、所有者フラグ「１」（所有可能）、ＱＲ取得回数「１」が記憶されている。

図２７に示すように、チケットキャンセル部２０１は、分配先から当初のチケットの購入者に対して、チケットのキャンセル依頼があったか否かを判定する（ステップＳ１０１）。チケットのキャンセル依頼がなかったと判定した場合（ステップＳ１０１；Ｎｏ）、チケットキャンセル部２０１は、チケットのキャンセル依頼があるまで、判定処理を繰り返す。

一方、チケットのキャンセル依頼があったと判定した場合（ステップＳ１０１；Ｙｅｓ）、チケットキャンセル部２０１は、当初のチケットの購入者の携帯端末２にＱＲ送信情報入力画面を表示する（ステップＳ１０２）。なお、ＱＲ送信情報入力画面は、購入したチケットを分配先に分配する画面であるが、ここでは、一旦分配した分配先を変更する場合に用いられる。

そして、チケットキャンセル部２０１は、キャンセル依頼があったチケットの座席情報に対応する分配先が供給者に変更されたか否かを判定する（ステップＳ１０３）。例えば、チケットキャンセル部２０１は、ＱＲ送信情報入力画面の変更された分配先が供給者の電話番号およびメールアドレスであるか否かを判定する。そして、供給者に変更されなかったと判定した場合（ステップＳ１０３；Ｎｏ）、チケットキャンセル部２０１は、供給者に変更されるまで、判定処理を繰り返す。

一方、供給者に変更されたと判定した場合（ステップＳ１０３；Ｙｅｓ）、チケットキャンセル部２０１は、キャンセル依頼があったチケットの座席情報に対応するＱＲコードと異なるＱＲコードを生成する。そして、チケットキャンセル部２０１は、生成したＱＲコードと座席情報に分配先情報を対応付けて格納する（ステップＳ１０４）。このとき、チケットキャンセル部２０１は、所有者フラグ「０」（未所有）、ＱＲ取得回数に「０」を設定する。

そして、チケットキャンセル部２０１は、分配先（チケット販売サイト３Ａ）のメールアドレスへＱＲ取得メールを送信する（ステップＳ１０５）。これと同時に、チケットキャンセル部２０１は、取得されているＱＲコードの所有者にＱＲコードの返却メールを送信する（ステップＳ１０６）。すなわち、チケットキャンセル部２０１は、キャンセル依頼のあったチケットの所有者にＱＲコードの返却を促すメールを送信する。

続いて、チケットキャンセル部２０１は、チケット再販部２０２に対して、キャンセル依頼のあったチケットについて、再販売の募集をさせる（ステップＳ１０７）。

その後、チケットキャンセル部２０１は、当初のチケットの購入者からチケットのキャンセル依頼の取り下げ要求があったか否かを判定する（ステップＳ１０８）。チケットのキャンセル依頼の取り下げ要求がなかったと判定した場合（ステップＳ１０８；Ｎｏ）、チケットキャンセル部２０１は、チケットの購入を希望する旨の要求があったか否かを判定する（ステップＳ１０９）。

チケットの購入を希望する旨の要求があったと判定した場合（ステップＳ１０９；Ｙｅｓ）、チケットキャンセル部２０１は、供給者の端末にＱＲ送信情報入力画面を表示する（ステップＳ１１０）。そして、チケットキャンセル部２０１は、座席情報に対応する分配先（新購入者）の利用者情報が入力されたか否かを判定する（ステップＳ１１１）。分配先（新購入者）の利用者情報が入力されなかったと判定した場合（ステップＳ１１１；Ｎｏ）、チケットキャンセル部２０１は、分配先（新購入者）の利用者情報が入力されるまで、判定処理を繰り返す。

一方、分配先（新購入者）の利用者情報が入力されたと判定した場合（ステップＳ１１１；Ｙｅｓ）、チケットキャンセル部２０１は、分配先（新購入者）の利用者情報を座席情報に対応付けて格納する（ステップＳ１１２）。このとき、チケットキャンセル部２０１は、所有者フラグに「１」（所有可能）、ＱＲ取得回数に「０」を設定する。これにより、チケットキャンセル部２０１は、この座席情報に対してＱＲコードを有効化することになる。そして、チケットキャンセル部２０１は、供給者のレコードに対して、所有者フラグ１１１ｐを「９」（解放）を設定する（ステップＳ１１３）。これにより、チケットキャンセル部２０１は、供給者に対するＱＲコードを無効化する。

そして、チケットキャンセル部２０１は、分配先（新購入者）のメールアドレスへＱＲ取得メールを送信する（ステップＳ１１４）。そして、チケットキャンセル部２０１は、チケットキャンセル処理を終了する。

一方、チケットのキャンセル依頼の取り下げ要求があったと判定した場合（ステップＳ１０８；Ｙｅｓ）またはチケットの購入を希望する旨の要求がなかったと判定した場合（ステップＳ１０９；Ｎｏ）、チケットキャンセル部２０１は、以下の処理を行う。すなわち、チケットキャンセル部２０１は、供給者の端末にＱＲ送信情報入力画面を表示する（ステップＳ１１５）。

そして、チケットキャンセル部２０１は、座席情報に対応する分配先（当初購入者）の利用者情報が入力されたか否かを判定する（ステップＳ１１６）。分配先（当初購入者）の利用者情報が入力されなかったと判定した場合（ステップＳ１１６；Ｎｏ）、チケットキャンセル部２０１は、分配先（当初購入者）の利用者情報が入力されるまで、判定処理を繰り返す。

一方、分配先（当初購入者）の利用者情報が入力されたと判定した場合（ステップＳ１１６；Ｙｅｓ）、チケットキャンセル部２０１は、分配先（当初購入者）のレコードに対して、所有者フラグ１１１ｐを「１」（所有可能）に設定する（ステップＳ１１７）。これにより、チケットキャンセル部２０１は、分配先（当初購入者）に対するＱＲコードを有効化する。そして、チケットキャンセル部２０１は、供給者のレコードに対して、所有者フラグ１１１ｐを「９」（解放）を設定する（ステップＳ１１８）。これにより、チケットキャンセル部２０１は、供給者に対するＱＲコードを無効化する。

そして、チケットキャンセル部２０１は、分配先（当初購入者）のメールアドレスへＱＲ取得メールを送信する（ステップＳ１１９）。そして、チケットキャンセル部２０１は、チケットキャンセル処理を終了する。

［所有者がキャンセル後、新購入者に譲渡できた場合の処理のシーケンス］
次に、所有者がチケットをキャンセル後、新購入者に譲渡できた場合のキャンセル処理のシーケンスを、適宜管理ＤＢ１１１内のデータの内容を用いながら説明する。図２８Ａ、図２８Ｂは、所有者がキャンセル後、新購入者に譲渡できた場合の処理のシーケンスを説明する図である。図２８Ａ、図２８Ｂでは、購入者Ａがチケットを４席購入し、購入者Ａは席ａの所有者、分配先Ｂ，Ｃ，Ｄはそれぞれ席ｂ，ｃ，ｄの所有者であったとする。以下では、分配先Ｄが所有している席ｄのキャンセル依頼をした後、供給者が再募集した結果、新購入者Ｅに譲渡する場合について説明する。なお、以下では、図３１に示される管理ＤＢ１１１内の席ｄ（１階、Ｉ列、１８３番）のレコードを適宜用いながら説明する。

分配先Ｄから購入者Ａにチケットのキャンセル依頼がされた後、チケットキャンセル部２０１は、ＱＲ送信情報入力画面を表示する（ステップＳ１２１）。

この時点では、管理ＤＢ１１１内の席ｄのレコードには、メールアドレス１１１ｎとして「Ｄのアドレス」、電話番号１１１ｏとして「ＤのＴＥＬ」が設定されている。所有者フラグ１１１ｐとして「１」（所有可能）、ＱＲ取得回数１１１ｌとして「１」が設定されている（図３１、Ｎｏ２参照）。

そして、購入者ＡがＱＲ送信情報入力画面を用いて、席ｄに対して譲渡先として供給者の電話番号および譲渡先のメールアドレスを入力する。すると、チケットキャンセル部２０１は、管理ＤＢ１１１内に、席ｄに対応する譲渡先として供給者のレコードを追加する。すなわち、チケットキャンセル部２０１は、供給者をチケットの一時的な預かり先とする。

ここでは、管理ＤＢ１１１内の追加されたレコードには、新規に生成される現ＱＲコード１１１ａとして「Ｆ１５３４３」、メールアドレス１１１ｎとして「供給者のアドレス」、電話番号１１１ｏとして「供給者のＴＥＬ」が設定されている。所有者フラグ１１１ｐとして「０」（未所有）、ＱＲ取得回数１１１ｌとして「０」が設定されている（図３１、Ｎｏ４参照）。

そして、チケットキャンセル部２０１は、譲渡先（提供者）のメールアドレスへＱＲ取得メールを送信する（ステップＳ１２２）。また、チケットキャンセル部２０１は、ＱＲ取得メールと同時にＱＲ返却メールを席ｄの現在の所有者である分配先Ｄに対して送信する（ステップＳ１２３）。

その後、分配先ＤによりＱＲ返却ＵＲＬにアクセスがされると、ＱＲ返却部１２２は、ＱＲ返却承認画面を表示する（ステップＳ１２４）。そして、分配先Ｄが返却承認画面を用いて席ｄに対応するＱＲの返却承認をすると、ＱＲ返却部１２２は、分配先Ｄのレコードに対して、所有者フラグ１１１ｐを「９」（解放）に設定する（図３１、Ｎｏ５参照）。これと同時に、分配先（供給者）のレコードに対して、所有者フラグ１１１ｐを「１」（所有可能）に設定する（図３１図示せず）。これにより、ＱＲ返却部１２２は、分配先Ｄに対するＱＲコードを無効化するとともに、分配先（供給者）に対するＱＲコードを有効化する。この結果、分配先Ｄは、所有者でなくなり、供給者が、一旦所有者となる。

その後、供給者であるチケット販売サイト３Ａが、キャンセル依頼がされた席（ｄ）のチケットを再募集する。そして、チケットキャンセル部２０１は、新たな購入者Ｅの携帯端末２から、キャンセル依頼がされたチケットの購入を希望する旨の要求を受信したとする。

すると、チケットキャンセル部２０１は、供給者の端末に、ＱＲ送信情報入力画面を表示する（ステップＳ１２５）。そして、供給者がＱＲ送信情報入力画面を用いて、席ｄに対して譲渡先として購入者Ｅの電話番号および譲渡先のメールアドレスを入力する。すると、チケットキャンセル部２０１は、管理ＤＢ１１１内に、席ｄに対応する譲渡先として購入者Ｅのレコードを追加する。

ここでは、管理ＤＢ１１１内の追加されたレコードには、新規に生成される現ＱＲコード１１１ａとして「Ｆ１５６８６」、メールアドレス１１１ｎとして「Ｅのアドレス」、電話番号１１１ｏとして「ＥのＴＥＬ」が設定されている。所有者フラグ１１１ｐとして「１」（所有可能）、ＱＲ取得回数１１１ｌとして「０」が設定されている（図３１、Ｎｏ５参照）。加えて、チケットキャンセル部２０１は、供給者のレコードに対して、所有者フラグ１１１ｐを「９」（解放）に設定する（図３１、Ｎｏ５参照）。

そして、チケットキャンセル部２０１は、購入者ＥのメールアドレスへＱＲ取得メールを送信する（ステップＳ１２６）。

そして、購入者ＥによりＱＲ取得ＵＲＬにアクセスがされると、ＱＲ表示部１２３は、ＱＲ取得画面を表示する（ステップＳ１２７）。そして、購入者ＥがＱＲ取得画面を用いて、自己の電話番号およびパスワードを入力する。すると、ＱＲ表示部１２３は、入力した電話番号およびパスワードが管理ＤＢ１１１内の購入者Ｅに対応する電話番号１１１ｏおよびパスワードＢ１１１ｍと一致すれば、購入者Ｅが正当であると判断する。さらに、ＱＲ表示部１２３は、購入者Ｅに対応する所有者フラグ１１１ｐが「１」（所有可能）であれば、購入者ＥのレコードのＱＲ取得回数１１１ｌに「１」を設定する（図３１、Ｎｏ６参照）。そして、ＱＲ表示部１２３は、購入者Ｅに対してＱＲを表示する。

この結果、席ｄの所有者が分配先Ｄから購入者Ｅに変更される。

［所有者がキャンセル後、キャンセルを取り下げた場合の処理のシーケンス］
次に、所有者がチケットをキャンセル後、キャンセルを取り下げた場合のキャンセル処理のシーケンスを、適宜管理ＤＢ１１１内のデータの内容を用いながら説明する。図２９Ａ、図２９Ｂは、所有者がキャンセル後、キャンセルを取り下げた場合の処理のシーケンスを説明する図である。なお、図２８Ａ、図２８Ｂに示すシーケンスと同一のシーケンスについては同一符号を示すことで、その重複する動作の説明については省略する。以下では、図３２に示される管理ＤＢ１１１内の席ｄ（１階、Ｉ列、１８３番）のレコードを適宜用いながら説明する。

分配先Ｄから購入者Ａにチケットのキャンセル依頼がされた後、チケットキャンセル部２０１は、提供者のメールアドレスへＱＲ取得メールを送信し、ＱＲ返却メールを席ｄの現在の所有者である分配先Ｄに対して送信する（ステップＳ１２１〜Ｓ１２３）。その後、分配先ＤによりＱＲ返却ＵＲＬにアクセスがされると、ＱＲ返却部１２２は、ＱＲ返却承認画面を表示し、ＱＲの返却承認をする（ステップＳ１２４）。すなわち、分配先Ｄのレコードに対して、所有者フラグ１１１ｐに「９」（解放）が設定され、供給者のレコードに対して、所有者フラグ１１１ｐに「１」（所有可能）が設定されている（図３２、Ｎｏ７参照）。この結果、分配先Ｄは、所有者でなくなり、供給者が、一旦所有者となる。

その後、供給者であるチケット販売サイト３Ａが、キャンセル依頼がされた席（ｄ）のチケットを再募集する。ところが、チケットキャンセル部２０１は、購入者Ａから供給者に対して、チケットのキャンセル依頼の取り下げ要求を受信したとする。

すると、チケットキャンセル部２０１は、管理ＤＢ１１１内に、席ｄに対応する譲渡先として当初の購入者Ａのレコードを追加する。

ここでは、管理ＤＢ１１１内の追加されたレコードには、新規に生成される現ＱＲコード１１１ａとして「Ｆ１５６８６」、メールアドレス１１１ｎとして「Ａのアドレス」、電話番号１１１ｏとして「ＡのＴＥＬ」が設定されている。所有者フラグ１１１ｐとして「０」（未所有）、ＱＲ取得回数１１１ｌとして「０」が設定されている（図３２、Ｎｏ７参照）。

そして、チケットキャンセル部２０１は、供給者の端末に、ＱＲ送信情報入力画面を表示する（ステップＳ１３１）。そして、供給者がＱＲ送信情報入力画面を用いて、席ｄに対して譲渡先として当初の購入者Ａの電話番号および譲渡先のメールアドレスを入力する。すると、チケットキャンセル部２０１は、当初の購入者Ａのレコードに対して、所有者フラグ１１１ｐを「１」（所有可能）に設定する（図３２、Ｎｏ７参照）。加えて、チケットキャンセル部２０１は、供給者のレコードに対して、所有者フラグ１１１ｐを「９」（解放）に設定する（図３２、Ｎｏ８参照）。

そして、チケットキャンセル部２０１は、当初の購入者ＡのメールアドレスへＱＲ取得メールを送信する（ステップＳ１３２）。

そして、当初の購入者ＡによりＱＲ取得ＵＲＬにアクセスがされると、ＱＲ表示部１２３は、ＱＲ取得画面を表示する（ステップＳ１３２）。そして、当初の購入者ＡがＱＲ取得画面を用いて、自己の電話番号およびパスワードを入力する。すると、ＱＲ表示部１２３は、入力した電話番号およびパスワードが管理ＤＢ１１１内の当初の購入者Ａに対応する電話番号１１１ｏおよびパスワードＢ１１１ｍと一致すれば、当初の購入者Ａが正当であると判断する。さらに、ＱＲ表示部１２３は、当初の購入者Ａに対応する所有者フラグ１１１ｐが「１」（所有可能）であれば、当初の購入者ＡのレコードのＱＲ取得回数１１１ｌに「１」を設定する（図３２、Ｎｏ９参照）。そして、ＱＲ表示部１２３は、当初の購入者Ａに対してＱＲを表示する。

この結果、席ｄの所有者が供給者からチケットの当初の購入者Ａに戻る。

［所有者がキャンセル後、新購入者に譲渡できなかった場合の処理のシーケンス］
次に、所有者がチケットをキャンセル後、新購入者に譲渡できなかった場合のキャンセル処理のシーケンスを、適宜管理ＤＢ１１１内のデータの内容を用いながら説明する。図３０Ａ、図３０Ｂは、所有者がキャンセル後、新購入者に譲渡できなかった場合の処理のシーケンスを説明する図である。なお、図２８Ａ、図２８Ｂに示すシーケンスと同一のシーケンスについては同一符号を示すことで、その重複する動作の説明については省略する。以下では、図３３に示される管理ＤＢ１１１内の席ｄ（１階、Ｉ列、１８３番）のレコードを適宜用いながら説明する。

分配先Ｄから購入者Ａにチケットのキャンセル依頼がされた後、チケットキャンセル部２０１は、提供者のメールアドレスへＱＲ取得メールを送信し、ＱＲ返却メールを席ｄの現在の所有者である分配先Ｄに対して送信する（ステップＳ１２１〜Ｓ１２３）。その後、分配先ＤによりＱＲ返却ＵＲＬにアクセスがされると、ＱＲ返却部１２２は、ＱＲ返却承認画面を表示し、ＱＲの返却承認をする（ステップＳ１２４）。すなわち、分配先Ｄのレコードに対して、所有者フラグ１１１ｐに「９」（解放）が設定され、供給者のレコードに対して、所有者フラグ１１１ｐに「１」（所有可能）が設定されている（図３３、Ｎｏ８参照）。この結果、分配先Ｄは、所有者でなくなり、供給者が、一旦所有者となる。

その後、供給者であるチケット販売サイト３Ａが、キャンセル依頼がされた席（ｄ）のチケットを再募集する。ところが、チケットキャンセル部２０１は、購入者から供給者に対して、チケットのキャンセル依頼の取り下げ要求を受信しなかったとする。

すると、チケットキャンセル部２０１は、管理ＤＢ１１１内に、席ｄに対応する譲渡先として当初の購入者Ａのレコードを追加する。

ここでは、管理ＤＢ１１１内の追加されたレコードには、新規に生成される現ＱＲコード１１１ａとして「Ｆ１５６８６」、メールアドレス１１１ｎとして「Ａのアドレス」、電話番号１１１ｏとして「ＡのＴＥＬ」が設定されている。所有者フラグ１１１ｐとして「０」（未所有）、ＱＲ取得回数１１１ｌとして「０」が設定されている（図３３、Ｎｏ７参照）。

そして、チケットキャンセル部２０１は、供給者の端末に、ＱＲ送信情報入力画面を表示する（ステップＳ１３１）。そして、供給者がＱＲ送信情報入力画面を用いて、席ｄに対して譲渡先として当初の購入者Ａの電話番号および譲渡先のメールアドレスを入力する。すると、チケットキャンセル部２０１は、当初の購入者Ａのレコードに対して、所有者フラグ１１１ｐを「１」（所有可能）に設定する（図３３、Ｎｏ７参照）。加えて、チケットキャンセル部２０１は、供給者のレコードに対して、所有者フラグ１１１ｐを「９」（解放）に設定する（図３３、Ｎｏ８参照）。

そして、チケットキャンセル部２０１は、当初の購入者ＡのメールアドレスへＱＲ取得メールを送信する（ステップＳ１３２）。

そして、当初の購入者ＡによりＱＲ取得ＵＲＬにアクセスがされると、ＱＲ表示部１２３は、ＱＲ取得画面を表示する（ステップＳ１３３）。そして、当初の購入者ＡがＱＲ取得画面を用いて、自己の電話番号およびパスワードを入力する。すると、ＱＲ表示部１２３は、入力した電話番号およびパスワードが管理ＤＢ１１１内の当初の購入者Ａに対応する電話番号１１１ｏおよびパスワードＢ１１１ｍと一致すれば、当初の購入者Ａが正当であると判断する。さらに、ＱＲ表示部１２３は、当初の購入者Ａに対応する所有者フラグ１１１ｐが「１」（所有可能）であれば、当初の購入者ＡのレコードのＱＲ取得回数１１１ｌに「１」を設定する（図３３、Ｎｏ９参照）。そして、ＱＲ表示部１２３は、当初の購入者Ａに対してＱＲを表示する。

この結果、席ｄの所有者が供給者からチケットの当初の購入者Ａに戻る。

［実施例２の効果］
上記実施例２によれば、サーバ３０は、有効化された可視情報に対応付けられたチケットの分配先の携帯端末２から当該チケットのキャンセル依頼を受信する。このとき、サーバ３０は、当該可視情報の対応付けを、キャンセル依頼を行った分配先から供給者（チケット販売サイト３Ａ）に変更する。そして、サーバ３０は、購入を希望する新たな購入者の携帯端末２から購入を希望する旨の要求を受信した場合に、新たな可視情報を生成し、キャンセル依頼の可視情報を無効化するとともに、新たな可視情報を有効化する。これにより、サーバ３０は、供給者が仲介することで、チケットを分配した当初のチケットの購入者と新たな購入者とが直接やり取りせずに、キャンセル依頼のあったチケットを売買できる。

また、上記実施例２によれば、サーバ３０は、購入を希望する旨の要求を受信しなかった場合に、キャンセル依頼のチケットに対応付けられた可視情報の対応付けを、供給者からチケットを分配した当初の購入者に変更する。これにより、サーバ１０は、購入を希望する者が現れなかった場合でも、チケットに対応付けられた可視情報の所有者を当初の購入者とすることで、供給者に不利益を生じさせない。

また、上記実施例２によれば、サーバ３０は、チケットのキャンセル依頼の取り下げを受信した場合に、キャンセル依頼のチケットに対応付けられた可視情報の対応付けを、供給者からチケットを分配した当初の購入者に変更する。これにより、サーバ１０は、チケットのキャンセル依頼の取り下げがあった場合でも、チケットに対応付けられた可視情報の所有者を当初の購入者とすることで、供給者のみならず当初の購入者にも不利益を生じさせない。

なお、サーバ１０、３０は、既知のパーソナルコンピュータ、ワークステーション等の情報処理装置に、上記した制御部１２と、記憶部１１等の各機能を搭載することによって実現することができる。

また、上記実施例２では、チケット譲渡管理システム９Ａは、チケット販売サイト３Ａにチケットの譲渡管理を行うサーバ３０を有する構成とした。しかしながら、チケット譲渡管理システム９Ａは、これに限定されず、チケットの譲渡管理を行うサーバ３０を有するチケット譲渡管理サイトと、チケット再販部２０２を有するチケット販売サイト３Ａとを分ける構成としても良い。かかる構成にしても、サーバ３０は、チケット販売サイト３Ａである供給者が仲介することで、チケットを分配した当初のチケットの購入者と新たな購入者とが直接やり取りせずに、キャンセル依頼のあったチケットを売買することが可能となる。

また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、チケット分配部１２１とＱＲ返却部１２２とＱＲ表示部１２３とを１個の部として統合しても良い。一方、チケット分配部１２１を、チケットの初回の分配処理を行う第１の分配部とチケットの２回目以降の分配処理を行う第２の分配部とに分散しても良い。また、管理ＤＢ１１１等の記憶部１１をサーバ１０、３０の外部装置としてネットワーク経由で接続するようにしても良い。

以上説明した実施形態及びその変形例に関し、更に以下の付記を開示する。

（付記１）第１の利用者の要求に基づき、認証に用いられる第１の可視情報を生成し、第２の利用者に対応付けて記憶部に格納する第１の生成部と、
前記第１の利用者の要求に基づき、前記第１の可視情報と異なる第２の可視情報を生成し、第３の利用者に対応付けて前記記憶部に格納する第２の生成部と、
前記第１の利用者の要求に基づき、前記記憶部に格納された前記第１の可視情報を無効化するとともに、前記第２の可視情報を有効化する制御部と、
前記第２の可視情報を前記第３の利用者のアドレス宛に送信する送信部とを有する
ことを特徴とする処理サーバ。

（付記２）前記送信部は、前記第１の可視情報が無効化され、かつ、前記第２の可視情報が有効化されている場合に、当該前記第２の可視情報を前記第３の利用者のアドレス宛に送信することを特徴とする付記１に記載の処理サーバ。

（付記３）前記送信部は、前記第１の可視情報が無効化され、かつ、前記第２の可視情報が有効化されているかを判定することなく、当該前記第２の可視情報を前記第３の利用者のアドレス宛に送信する
ことを特徴とする付記１に記載の処理サーバ。

（付記４）前記制御部は、前記第２の利用者の端末から前記第１の可視情報の返却承認を受信した場合に、前記第１の可視情報を無効化するとともに、前記第２の可視情報を有効化する
ことを特徴とする付記１〜３のいずれか１つに記載の処理サーバ。

（付記５）前記制御部は、前記第２の可視情報が有効化されているが、前記第２の可視情報が未だ前記第３の利用者のアドレス宛に送信されていない場合には、前記第３の利用者からの返却承認なしに前記第２の可視情報を無効化する
ことを特徴とする付記４に記載の処理サーバ。

（付記６）読み取り装置から受信した前記第２の可視情報が有効な場合、前記記憶部に記憶されている前記第２の可視情報に対応付けられた利用者の電子機器に、新たな可視情報を出力する認証部をさらに有する
ことを特徴とする付記１から付記５のいずれか１つに記載の処理サーバ。

（付記７）前記制御部は、有効化された可視情報に対応付けられた利用者の端末から当該可視情報の取消依頼を受信した場合に、当該可視情報の対応付けを、前記取消依頼を行った利用者から供給者に変更し、利用を希望する新たな利用者の端末から利用を希望する旨の要求を受信した場合に、新たな可視情報を生成し、前記取消依頼の可視情報を無効化するとともに、前記新たな可視情報を有効化する
ことを特徴とする付記１に記載の処理サーバ。

（付記８）前記制御部は、利用を希望する旨の要求を受信しなかった場合に、前記取消依頼の可視情報の対応付けを前記供給者から前記第１の利用者に変更する
ことを特徴とする付記７に記載の処理サーバ。

（付記９）前記制御部は、前記取消依頼の取り下げを受信した場合に、前記取消依頼の可視情報の対応付けを前記供給者から前記第１の利用者に変更する
ことを特徴とする付記７または付記８に記載の処理サーバ。

（付記１０）コンピュータが、
第１の利用者の要求に基づき、認証に用いられる第１の可視情報を生成し、第２の利用者に対応付けて記憶部に格納し、
前記第１の利用者の要求に基づき、前記第１の可視情報と異なる第２の可視情報を生成し、第３の利用者に対応付けて前記記憶部に格納し、
前記第１の利用者の要求に基づき、前記記憶部に格納された前記第１の可視情報を無効化するとともに、前記第２の可視情報を有効化し、
前記第２の可視情報を前記第３の利用者のアドレス宛に送信する
各処理を実行することを特徴とする譲渡管理方法。

１ チケット譲渡管理サイト
２ 携帯端末
３、３Ａ チケット販売サイト
４ ネットワーク
９、９Ａ チケット譲渡管理システム
１０、３０ サーバ
１１ 記憶部
１１１ 管理ＤＢ
１２ 制御部
１２１ チケット分配部
１２２ ＱＲ返却部
１２３ ＱＲ表示部
１２４ ＱＲ認証部
２０１ チケットキャンセル部
２０２ チケット再販部

Claims (9)

1. 第１の利用者の要求に基づき、認証に用いられる第１の可視情報を生成し、第２の利用者に対応付けて記憶部に格納する第１の生成部と、
   前記第１の利用者の要求に基づき、前記第１の可視情報と異なる第２の可視情報を生成し、第３の利用者に対応付けて前記記憶部に格納する第２の生成部と、
   前記第１の利用者の要求に基づき、前記記憶部に格納された前記第１の可視情報を無効化するとともに、前記第２の可視情報を有効化する制御部と、
   前記第２の可視情報を前記第３の利用者のアドレス宛に送信する送信部とを有する
   ことを特徴とする処理サーバ。
2. 前記送信部は、前記第１の可視情報が無効化され、かつ、前記第２の可視情報が有効化されている場合に、当該前記第２の可視情報を前記第３の利用者のアドレス宛に送信することを特徴とする請求項１に記載の処理サーバ。
3. 前記送信部は、前記第１の可視情報が無効化され、かつ、前記第２の可視情報が有効化されているかを判定することなく、当該前記第２の可視情報を前記第３の利用者のアドレス宛に送信する
   ことを特徴とする請求項１に記載の処理サーバ。
4. 前記制御部は、前記第２の利用者の端末から前記第１の可視情報の返却承認を受信した場合に、前記第１の可視情報を無効化するとともに、前記第２の可視情報を有効化する
   ことを特徴とする請求項１〜３のいずれか１つに記載の処理サーバ。
5. 前記制御部は、前記第２の可視情報が有効化されているが、前記第２の可視情報が未だ前記第３の利用者のアドレス宛に送信されていない場合には、前記第３の利用者からの返却承認なしに前記第２の可視情報を無効化する
   ことを特徴とする請求項４に記載の処理サーバ。
6. 前記制御部は、有効化された可視情報に対応付けられた利用者の端末から当該可視情報の取消依頼を受信した場合に、当該可視情報の対応付けを、前記取消依頼を行った利用者から供給者に変更し、利用を希望する新たな利用者の端末から利用を希望する旨の要求を受信した場合に、新たな可視情報を生成し、前記取消依頼の可視情報を無効化するとともに、前記新たな可視情報を有効化する
   ことを特徴とする請求項１に記載の処理サーバ。
7. 前記制御部は、利用を希望する旨の要求を受信しなかった場合に、前記取消依頼の可視情報の対応付けを前記供給者から前記第１の利用者に変更する
   ことを特徴とする請求項６に記載の処理サーバ。
8. 前記制御部は、前記取消依頼の取り下げを受信した場合に、前記取消依頼の可視情報の対応付けを前記供給者から前記第１の利用者に変更する
   ことを特徴とする請求項６または請求項７に記載の処理サーバ。
9. コンピュータが、
   第１の利用者の要求に基づき、認証に用いられる第１の可視情報を生成し、第２の利用者に対応付けて記憶部に格納し、
   前記第１の利用者の要求に基づき、前記第１の可視情報と異なる第２の可視情報を生成し、第３の利用者に対応付けて前記記憶部に格納し、
   前記第１の利用者の要求に基づき、前記記憶部に格納された前記第１の可視情報を無効化するとともに、前記第２の可視情報を有効化し、
   前記第２の可視情報を前記第３の利用者のアドレス宛に送信する
   各処理を実行することを特徴とする譲渡管理方法。

Images