(57)【要約】【課題】  複数のサーバが特定のサーバによる一元管理の下で電子チケットなど電子データを発送するシステムにおいて、チケット発行時のトランザクションによるサーバの負荷を軽減する。  【解決手段】  電子チケットなど電子データを発行する元売りサーバ１０と、元売りサーバ１０で発行される電子チケット等の販売処理を行う代理店サーバ２０と、元売りサーバ１０および代理店サーバ２０に接続して電子チケット等を取得するクライアント端末３０とを備える。代理店サーバ２０は、クライアント端末３０からのチケットなどの電子データ発送要求に対して自身の直上に位置する代理店サーバ２０または元売りサーバ１０にアクセスするためのトークンを付加してクライアント端末３０に返送する。クライアント端末３０は、代理店サーバ２０から受信したトークンの付加された電子データ発送（チケット購入）要求を元売りサーバ１０に送信する。そして、元売りサーバ１０は、トークンの付加された電子データ発送（チケット購入）要求に応じて電子チケット等の電子データを発行する。  【選択図】  図１
2006178922.tif 000002
【特許請求の範囲】
【請求項１】
電子データを発行する元サーバと、
前記元サーバで発行される電子データの発送処理を行う代理サーバと、
前記元サーバおよび前記代理サーバに接続して電子データを取得するクライアント端末とを備え、
前記代理サーバは、前記クライアント端末からの電子データ発送要求に対して前記元サーバにアクセスするためのトークンを付加して当該クライアント端末に返送し、
前記クライアント端末は、前記代理サーバから受信したトークンの付加された電子データ発送要求を前記元サーバに送信し、
前記元サーバは、前記トークンの付加された電子データ発送要求に応じて前記電子データを発行することを特徴とする電子データ発送システム。
【請求項２】
前記元サーバと前記代理サーバは秘密鍵を共有し、
前記代理サーバは、前記秘密鍵を用いて、前記トークンの少なくとも一部を暗号化し、
前記元サーバは、前記秘密鍵を用いて、少なくとも一部が暗号化された前記トークンを復号することを特徴とする請求項１に記載の電子データ発送システム。
【請求項３】
前記代理サーバは複数存在し、前記元サーバは、代理サーバごとに固有の秘密鍵を共有することを特徴とする請求項２に記載の電子データ発送システム。
【請求項４】
前記代理サーバは、前記クライアント端末による電子データの取得に伴う決済を行うための決済機能を備えることを特徴とする請求項１に記載の電子データ発送システム。
【請求項５】
前記元サーバで発行される電子データの発送処理を行い、かつ前記クライアント端末からの電子データ発送要求に対して前記代理サーバにアクセスするためのトークンを付加して当該クライアント端末に返送する子代理サーバをさらに備え、
前記代理サーバは、前記子代理サーバによりトークンが付加された電子データ発送要求を前記クライアント端末から受信した場合に、当該トークンを自身の作成したトークンに置き換えて当該クライアント端末に返送することを特徴とする請求項１に記載の電子データ発送システム。
【請求項６】
前記代理サーバと前記子代理サーバは秘密鍵を共有し、
前記子代理サーバは、前記秘密鍵を用いて、前記トークンの少なくとも一部を暗号化し、  前記代理サーバは、前記秘密鍵を用いて、少なくとも一部が暗号化された前記トークンを復号することを特徴とする請求項５に記載の電子データ発送システム。
【請求項７】
木構造をなす複数のサーバがルートノードに対応するサーバによる一元管理の下に電子データの発送処理を行う電子データ発送システムであって、  ネットワークを介して前記木構造をなすサーバ群のサーバに接続し電子データに関するリクエストを送信するクライアント端末と、
前記クライアント端末からのリクエストに対して、前記木構造における自身の直上に位置するサーバにアクセスするためのトークンを付加して当該クライアント端末に返送する第１のサーバと、
前記木構造のルートノードに対応するサーバであってその直下の前記第１のサーバにより前記トークンが付加されたリクエストを受け付けた場合に電子データを発行する第２のサーバとを備え、
前記クライアント端末は、前記第１のサーバからトークンの付加されたリクエストが返送された場合に、当該トークンの付加されたリクエストを当該トークンにより特定される送信先である第１または第２のサーバに送信することを特徴とする電子データ発送システム。
【請求項８】
ネットワークを介してクライアント端末とアクセスするための通信部と、
前記クライアント端末からの電子データに関するリクエストに対して、当該リクエストに係る電子データの発行を管理する元サーバにアクセスするためのトークンを付加し、前記通信部を介して当該クライアント端末へ返送させる受付処理部とを備えることを特徴とするサーバ。
【請求項９】
前記元サーバと自サーバとで共有される秘密鍵を格納した秘密鍵格納部と、
前記秘密鍵格納部に格納された秘密鍵を用いて前記受付処理部が作成する前記トークンの少なくとも一部を暗号化する暗号処理部とをさらに備えることを特徴とする請求項８に記載のサーバ。
【請求項１０】
ネットワークを介してサーバにアクセスするための通信部と、
電子データを購入するための電子データ発送要求を生成し前記通信部を介して所定のサーバへ送信させるリクエスト発行部と、
前記所定のサーバから前記電子データ発送要求に他のサーバへアクセスするためのトークンが付加されたリクエストを受信した場合に、前記通信部を介して当該トークンにより特定される送信先のサーバへ当該リクエストを送信させ、前記所定のサーバまたは当該トークンにより特定される送信先のサーバから前記電子データを受信した場合に、当該電子データを記憶装置に格納する電子データ発送処理部とを備えることを特徴とする端末装置。
【請求項１１】
木構造をなす複数のサーバがルートノードに対応するサーバによる一元管理の下に電子データの発送処理を行うシステムによる電子データ発送方法であって、
前記木構造をなすサーバ群における所定のサーバが、クライアント端末からの電子データ発送要求を受け付け、当該電子データ発送要求に対して、当該木構造における自身の直上に位置するサーバにアクセスするためのトークンを付加して当該クライアント端末に返送する第１のステップと、
前記クライアント端末が、前記代理サーバから受信したトークンの付加された電子データ発送要求を当該トークンにより特定される送信先のサーバに送信する第２のステップと、
前記ルートノードに対応するサーバが、その直下のサーバにより前記トークンが付加された電子データ発送要求を前記クライアント端末から受け付けた場合に、当該電子データ発送要求に応じて前記電子データを発行する第３のステップとを含むことを特徴とする電子データ発送方法。
【請求項１２】
前記第１のステップでは、前記所定のサーバが、自サーバが自身の直上に位置するサーバと共有する秘密鍵を用いて前記トークンの少なくとも一部を暗号化し、前記電子データ発送要求に付加することを特徴とする請求項１１に記載の電子データ発送方法。
【請求項１３】
前記第１のステップは、
前記所定のサーバが、自身の直下のサーバによりトークンが付加された電子データ発送要求を受け付けた場合に、当該直下のサーバと共有する秘密鍵を用いて当該トークンを復号するステップと、
前記所定のサーバが、復号された当該トークンを、自身の直上のサーバと共有する秘密鍵を用いて暗号化するステップとを含むことを特徴とする請求項１２に記載の電子データ発送方法。
【請求項１４】
前記第３のステップでは、前記ルートノードに対応するサーバが、自身の直下のサーバによりトークンが付加された電子データ発送要求における当該トークンを、当該直下のサーバと共有する秘密鍵を用いて復号することを特徴とする請求項１１に記載の電子データ発送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、平成１６年１１月２５日付けの出願を基礎とする国内優先権主張の出願である。
本発明は、クライアントからのアクセスに応じてサーバが電子データを発送するシステムに関し、特に元売りサーバによる一元管理の下、複数の代理店サーバによって電子データが発送されるシステムおよびその発送方法に関する。以下の説明では、主に電子データを電子チケットとして、本発明の説明を行っている。従って以下の説明では、クライアントからのアクセスに応じてサーバが電子チケットを発行し販売するシステムに関し、特に元売りサーバによる一元管理の下、複数の代理店サーバによって電子チケットが販売されるシステムおよびその販売方法に関する。
先の出願の内容に対する具体的な変更点は、発明の名称及び明細書のこの０００１、０００７、００１０、００６８の段落の明細書と、特許請求の範囲と、及び要約書とである。なお、特許請求の範囲に関しては、電子チケットを電子データと変更している。本発明は、複数のサーバで階層化されたネットワーク環境において、要求クライアント端末から負荷の大きな中間サーバにされた電子データ発送要求処理を、下位のサーバに移転することを可能とする発送方法である。従って、本発明は、電子データが電子チケットかそのデジタルコンテンツ、例えば、ミュージック、映像、公的な個人住民情報等に違いにより、電子データ発送方法が異なるものではない。
【背景技術】
【０００２】
興行ビジネスにおいてチケットの販売を行う場合、代理店等を使ってチケットを委託販売することが行われる。例えば、サッカーのワールドカップでは、ＦＩＦＡ（Federation Internationale de FootballAssociation：国際サッカー連盟）が総代理店（元売り業者）を通じて各国のチケット取扱者に対してチケットの割り当てを行う。そして、チケット購入希望者は、各国のチケット取扱者からチケットを入手する。場合によっては、代理店からさらに自身の代理店を設定することによって子代理店、孫代理店というように委託の態様が数段に階層化された販売形態が取られることもある。しかし、このような販売方式では、所定の代理店でチケットが余ったり足りなくなったりした場合に柔軟に割り当てを変更することができず、販売効率が悪かった。
【０００３】
近年、コンピュータによる情報処理技術の発達に伴い、チケットの電子化（電子チケット）によってチケット販売の効率化が図られるようになっている。元売り業者・各代理店・末端販売店のそれぞれにサーバを設置し、ネットワークを通じてこれらのサーバを階層的（木構造）に接続して構成されたシステムで電子チケットを販売することにより、全てのチケットの販売状況をルートノードに当たる元売り業者で一元管理することが可能となる（例えば、特許文献１、２参照）。チケットの販売状況を一元管理することにより、特定の代理店でチケットが余ったり足りなくなったりすることを回避できる。
【０００４】
図９は、サーバを階層的に接続して構成されたシステムにおける電子チケットの販売方法を説明する図である。
図９において、チケットの購入希望者がクライアント端末９０３を操作し、チケットの購入要求（リクエスト）を発行する。すると、このリクエストがクライアント端末９０３から代理店Ｃのサーバ９０２Ｃへ送信される。代理店Ｃのサーバ９０２Ｃは、システムの階層構造において自身の上位に位置する代理店Ａのサーバ９０２Ａに、このリクエストを送信する。同様にシステムの階層構造を順次上がっていき、最後に元売り業者のサーバ９０１にリクエストが到達する。元売り業者のサーバ９０１は、このリクエストに応じてチケットを発行し、レスポンスを返す。このレスポンスは、チケット購入のリクエストが送信された経路を逆に辿ってクライアント端末９０３に到達する。そして、クライアント端９０３において決済等の手続が行われると、チケット購入希望者に対してチケットが販売されることとなる。
【０００５】
【特許文献１】特開２００２−１９７２２１号公報
【特許文献２】特開２００１−２９７２４２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上述したように、ネットワークシステムで電子チケット（以下、単にチケットと記す）の販売を管理することにより、多数の代理店や販売店を用いてチケットを販売する場合でも、全てのチケットの販売状況を元売り業者で一元管理することができる。そのため、特定の代理店でチケットが余ったり足りなくなったりすることを回避できる。しかし、チケット販売の委託契約の形態にしたがって、単純に元売り業者から末端販売店まで階層的にサーバが接続されたネットワークシステムの場合、下層に位置するサーバにかかる負荷が増大するという問題があった。
【０００７】
すなわち、かかるシステムでは、チケットの購入要求が発行されたクライアント端末から最上位のサーバに至る経路上に存在する全てのサーバは、自身が発したリクエストが最上位のサーバまで達して処理されるまでトランザクションを終了できない。例えば、図９において、代理店Ｃのサーバ９０２Ｃは、クライアント端末９０３から受け取ったリクエストが元売り業者のサーバ９０１に到達し、そのレスポンスが代理店Ｃのサーバ９０２Ｃを経てクライアント端末９０３に送信されるまでトランザクションが継続する。このため、より下層に位置するサーバほどトランザクションに要する時間が長くなり、サーバの負荷も増大することとなる。この電子チケットの発行に関する技術課題は、あらゆる電子データ（そのデジタルコンテンツ、例えば、ミュージック、映像、公的な個人住民情報等）の発送において同様に存在する。
【０００８】
下位のサーバにかかる負荷を軽減する方策として、契約上の代理店の形態（子代理店、孫代理店など）に関わらず全ての代理店のサーバを直接元売り業者のサーバへ接続することが考えられる。しかし、このようなシステムでは、全ての代理店のサーバが元売り業者のサーバに管理されるため、代理店が自身の子代理店を増減するたびに元売り業者に対してサーバ接続の了解を得なければならず、煩雑である。また、各代理店が自身の子代理店に関する情報を元売り業者や上位の代理店に提供しなければならず、代理店契約の態様によっては好ましくない場合もある。
【０００９】
そこで本発明は、複数のサーバによって構成され、かつ特定のサーバにより電子チケットの発行が一元管理されるシステムにおいて、チケット発行時のトランザクションによるサーバの負荷を軽減することを目的とする。
また本発明は、所定の代理店が自身の子代理店を増減することによるシステム構成の変更が容易な、柔軟な電子チケット販売システムを提供することを他の目的とする。
【課題を解決するための手段】
【００１０】
上記の目的を達成するため、本発明は、電子チケットを発行する元売りサーバ（元サーバ）と、この元売りサーバで発行される電子チケットの販売処理を行う代理店サーバと、元売りサーバおよび代理店サーバ（代理サーバ）に接続して電子チケットを取得するクライアント端末とを備えたチケット販売システムとして実現される。このシステムにおいて、代理店サーバは、クライアント端末からのチケット購入要求に対して元売りサーバにアクセスするためのトークンを付加してクライアント端末に返送する。クライアント端末は、代理店サーバから受信したトークンの付加されたチケット購入要求を元売りサーバに送信する。そして、元売りサーバは、トークンの付加されたチケット購入要求に応じて電子チケットを発行することを特徴とする。代理店サーバは、クライアント端末による電子チケットの取得に伴う決済を行うための決済機能を備えることができる。
【００１１】
また当然ながら、本発明は、電子チケットの発行以外に、発行された電子チケットを照会したり、キャンセルしたりするためのリクエストがクライアント端末から送信される場合にも適用することができる。この場合、電子チケットの照会やキャンセルを要求するリクエストにトークンが付加されることとなる。そして、元売りサーバは、このトークンが付加されたリクエストに基づき、電子チケットの照会やキャンセルといった管理業務のための処理を実行することとなる。
【００１２】
また、このシステムは、元売りサーバで発行される電子チケットの販売処理を行い、かつクライアント端末からのチケット購入要求に対して代理店サーバにアクセスするためのトークンを付加してクライアント端末に返送する子代理店サーバをさらに備える構成とすることができる。各子代理店サーバがさらに自身の子代理店サーバを設定することもできる。この場合、各サーバの関係は、元売りサーバをルートノードとする木構造となる。
【００１３】
このシステムにおいて、さらに好ましくは、木構造における各サーバは自身の直下のサーバと秘密鍵を共有する。そして、木構造の下位のサーバは、秘密鍵を用いて、トークンの少なくとも一部を暗号化する。一方、木構造の上位のサーバは、直下のサーバと共有する秘密鍵を用いて、少なくとも一部が暗号化されたトークンを復号する。
【００１４】
また本発明は、木構造をなす複数のサーバがルートノードに対応するサーバによる一元管理の下に電子チケットの販売処理を行うチケット販売システムとしても実現される。このシステムは、ネットワークを介して木構造をなすサーバ群のサーバに接続し電子チケットに関するリクエスト（すなわち電子チケットの購入要求、照会要求、キャンセル要求等）を送信するクライアント端末と、クライアント端末からのリクエストに対して、木構造における自身の直上に位置するサーバにアクセスするためのトークンを付加してクライアント端末に返送する第１のサーバと、木構造のルートノードに対応するサーバであってその直下の第１のサーバによりトークンが付加されたリクエストを受け付けた場合に電子チケットを発行する第２のサーバとを備える。そして、クライアント端末は、第１のサーバからトークンの付加されたリクエストが返送された場合に、トークンの付加されたリクエストをトークンにより特定される送信先である第１または第２のサーバに送信する。
【００１５】
ここで、これらのシステムにおけるサーバは、より詳細には、ネットワークを介してクライアント端末とアクセスするための通信部と、クライアント端末からの電子チケットに関するリクエストに対して、このリクエストに係る電子チケットを発行する元売りサーバにアクセスするためのトークンを付加し、通信部を介してクライアント端末へ返送させる受付処理部と、元売りサーバと自サーバとで共有される秘密鍵を格納した秘密鍵格納部と、この秘密鍵格納部に格納された秘密鍵を用いて受付処理部が作成するトークンの少なくとも一部を暗号化する暗号処理部を備える。また、クライアント端末は、ネットワークを介してサーバにアクセスするための通信部と、電子チケットを購入するためのチケット購入要求等のリクエストを生成し通信部を介して所定のサーバへ送信させるリクエスト発行部と、所定のサーバから自身の送信したリクエストに他のサーバへアクセスするためのトークンが付加されたリクエストを受信した場合に、通信部を介してトークンにより特定される送信先のサーバへトークン付きのリクエストを送信させ、所定のサーバまたはトークンにより特定される送信先のサーバから電子チケットを受信した場合に、電子チケットを記憶装置に格納するチケット購入処理部を備える。
【００１６】
さらに本発明は、木構造をなす複数のサーバがルートノードに対応するサーバによる一元管理の下に電子チケットの販売処理を行うシステムによるチケット販売方法としても実現される。この方法は、木構造をなすサーバ群における所定のサーバが、クライアント端末からのチケット購入要求を受け付け、チケット購入要求に対して、木構造における自身の直上に位置するサーバにアクセスするためのトークンを付加してクライアント端末に返送する第１のステップと、クライアント端末が、代理店サーバから受信したトークンの付加されたチケット購入要求をトークンにより特定される送信先のサーバに送信する第２のステップと、ルートノードに対応するサーバが、その直下のサーバによりトークンが付加されたチケット購入要求をクライアント端末から受け付けた場合に、チケット購入要求に応じて電子チケットを発行する第３のステップとを含むことを特徴とする。
このチケット販売方法が、電子チケットの照会やキャンセルのためのリクエストに対しても同様に適用できることは上述の通りである。
【発明の効果】
【００１７】
以上のように構成された本発明によれば、クライアント端末がトークンを用いて順次木構造の上位のサーバにアクセスしていき、最終的にルートノードに対応する元売りサーバにアクセスしてチケットを取得するため、各サーバはチケットが発行されるまでトランザクションを継続する必要がなく、負荷が軽減されるという効果がある。
また、本発明によれば、各サーバは自身の直上および直下のサーバのみを認識していれば良く、上位のサーバが自身の下位にある全てのサーバを管理する必要がないため、自身の子代理店を増減することによってシステム構成を変更することが容易な、柔軟なシステムを実現することができる。
【発明を実施するための最良の形態】
【００１８】
以下、添付図面を参照して、本発明を実施するための最良の形態（以下、実施形態）について詳細に説明する。
図１は、本実施形態によるチケット販売システムを説明する図である。
図１に示すように、本実施形態のシステムは、元売り業者のサーバである元売りサーバ１０と、代理店のサーバである代理店サーバ２０と、ネットワークを介して元売りサーバ１０および各代理店サーバ２０に接続するクライアント端末３０とを備える。元売りサーバ１０および代理店サーバ２０相互の関係は、元売り業者および代理店の間の委託契約の形態に対応する階層構造（木構造）を有する。すなわち、元売りサーバ１０をルートノードとして、その直下に元売り業者と直接委託契約を結んだ代理店の代理店サーバ２０があり、さらにその下位に代理店と委託契約を結んだ子代理店の代理店サーバ２０がある、というような木構造である。ただし、元売りサーバ１０および各代理店サーバ２０どうしは、ネットワークによって直接接続されている必要はない。以下、個々の代理店サーバ２０を区別する必要がある場合は、図１に示す代理店に対応する添え字を付して代理店サーバ２０Ａ、２０Ｂというように記述する。図１において、代理店サーバ２０Ａ、２０Ｂは共に元売りサーバ１０の直下であり、同じ階層である。また、代理店サーバ２０Ｃは代理店サーバ２０Ａの下位の階層である。
【００１９】
図１には、クライアント端末３０が代理店サーバ２０Ｃに接続された１台のみが記述されているが、実際には、クライアント端末３０は複数台存在する。また、クライアント端末３０は、必ずしも階層構造の最下層の代理店サーバ２０にのみ接続するのではなく、階層構造の中間位置に存在する代理店サーバ２０（例えば図１の代理店サーバ２０Ａ）や、元売りサーバ１０にも接続される。クライアント端末３０と代理店サーバ２０または元売りサーバ１０との間の接続は、例えば公衆回線を用いた広域なネットワークを用いることができる。
【００２０】
本実施形態において、代理店サーバ２０は、クライアント端末３０からチケットの購入要求（リクエスト）を受け付けると、自身の上位の代理店サーバ２０にアクセスするためのトークンを発行し、クライアント端末３０へ返送する。クライアント端末３０は、このトークンにより上位の代理店サーバ２０にアクセスし、チケットの購入要求を送信する。この動作を繰り返すと、最終的にクライアント端末３０は、直接元売りサーバ１０に対してチケットの購入要求を送信し、チケットを取得することとなる。
【００２１】
図１の例では、まずクライアント端末３０から代理店サーバ２０Ｃへチケットの購入要求が送信され、代理店サーバ２０Ｃからクライアント端末３０へ代理店サーバ２０Ａにアクセスするためのトークンが返送される。次に、クライアント端末３０から代理店サーバ２０Ａへ代理店サーバ２０Ｃから取得したトークンと共にチケットの購入要求が送信され、代理店サーバ２０Ａからクライアント端末３０へ元売りサーバ１０にアクセスするためのトークンが返送される。最後に、クライアント端末３０から直接元売りサーバ１０へ代理店サーバ２０Ａから取得したトークンと共にチケットの購入要求が送信される。そして、元売りサーバ１０において購入要求に係るチケットが発行され、元売りサーバ１０からクライアント端末３０へ送信される。
【００２２】
また本実施形態では、代理店サーバ２０が発行するトークンの少なくとも一部が暗号化される。元売りサーバ１０および各代理店サーバ２０は、直下の（すなわち直接の代理店関係にある）代理店サーバ２０との間で固有の秘密鍵を共有する。トークンの暗号化は、この秘密鍵を用いた秘密鍵暗号によって行われる。
【００２３】
図１の例では、元売りサーバ１０と代理店サーバ２０Ａとは、固有の秘密鍵Ａを共有する。同様に、元売りサーバ１０と代理店サーバ２０Ｂとは、固有の秘密鍵Ｂを共有する。また、代理店サーバ２０Ａと代理店サーバ２０Ｃとは、固有の秘密鍵Ｃを共有する。したがって、代理店サーバ２０Ｃで発行されたトークンは、代理店サーバ２０Ａのみが解釈でき、代理店サーバ２０Ａで発行されたトークンは、元売りサーバ１０のみが解釈できることとなる。
【００２４】
このように特定の秘密鍵を共有する２つのサーバを、本実施形態では、信頼関係を結んでいるものとみなす。これにより、元売り業者および代理店の間の委託契約の形態に基づいて定まる各サーバの階層構造において、直接の上下関係を有する２つのサーバが信頼関係を持つこととなる。逆に言えば、必ずしもネットワークで相互接続されない本実施形態の元売りサーバ１０および各代理店サーバ２０は、この信頼関係によって階層構造を維持すると言える。
【００２５】
図２は、本実施形態における元売りサーバ１０と各代理店サーバ２０との間の信頼関係を説明する図である。
本実施形態のチケット販売システムにおける階層構造は、上位に元売りサーバ１０があり、全ての代理店サーバ２０が元売りサーバ１０の直下に位置する（すなわち、元売り業者と全ての代理店とが直接の委託関係にある）ものが最も単純な形態である。この場合、図２（Ａ）に示すように、各代理店サーバ２０と元売りサーバ１０とが、各々固有の秘密鍵を共有することで信頼関係を結んでいる。
【００２６】
また、各代理店は、委託契約により自身の代理店（子代理店）を設定することができる。これにより、各代理店の代理店サーバ２０どうしも階層構造を持つこととなり、システム全体の階層が深まる。しかしながら、各代理店サーバ２０は、図２（Ｂ）に示すように、自身の直下の代理店サーバ２０との間でのみ秘密鍵を共有し信頼関係を結んでいれば良い。クライアント端末３０は、代理店サーバ２０から発行されたトークンを用いて１つ上位の代理店サーバ２０に順次アクセスすることにより、元売りサーバ１０に到達しチケットを取得することができる。すなわち、本実施形態は、元売りサーバ１０によりチケットの発行を一元管理するにも関わらず、元売りサーバ１０や上位の代理店サーバ２０が自身よりも下位にある全ての代理店サーバ２０の接続関係を知っている必要はない。したがって、各代理店は、元売り業者や上位の代理店に通知することなく任意かつ容易に自身の子代理店を増やしたり減らしたりすることができる。
【００２７】
さて、本実施形態のシステムにおいて、各代理店サーバ２０はクライアント端末３０からチケットの購入要求を受け付けるが、下位に子代理店を有する代理店の代理店サーバ２０は、子代理店の代理店サーバ２０で発行されたトークンを伴うリクエストを受け付ける合と、かかるトークンを伴わないリクエストを受け付ける場合とがある。以下の説明では、便宜的に、自身の子代理店を有する代理店を中間代理店と呼び、自身の子代理店を有さない（すなわちトークンを伴わないリクエストしか受信しない）代理店を末端代理店と呼ぶこととする。図１に示した例では、代理店Ａが中間代理店であり、代理店Ｂ、Ｃが末端代理店である。
【００２８】
また、本実施形態のシステムでは、クライアント端末３０からトークンを伴わないチケット購入要求を受け付けた代理店サーバ２０がチケットの販売業務（決済を含む）を行う。これに対し、チケットの発行やキャンセル、照会等の管理業務は、元売りサーバ１０のみによって一元管理の下で行われる。なお、元売りサーバ１０自身も、クライアント端末３０からトークンを伴わないリクエストを直接受け付けてチケットを販売することは可能である。しかし、簡単のため以下では、元売りサーバ１０は管理業務のみを行い、チケットの販売権は代理店サーバ２０のみが持つこととして説明する。
【００２９】
図３は、本実施形態のシステムにおける元売りサーバ１０および代理店サーバ２０として好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図３に示すコンピュータ装置は、演算手段であるＣＰＵ（CentralProcessing Unit：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２およびＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２およびＡＧＰ（AcceleratedGraphics Port）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Peripheral Component Interconnect）バスを介してＭ／Ｂチップセット１０２に接続された磁気ディスク装置（ＨＤＤ）１０５、ネットワークインターフェイス１０６と、さらにこのＰＣＩバスからブリッジ回路１０７およびＩＳＡ（IndustryStandard Architecture）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフレキシブルディスクドライブ１０８およびキーボード／マウス１０９とを備える。
【００３０】
なお、図３は本実施形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、外部記憶装置として、ＡＴＡ（AT Attachment）やＳＣＳＩ（Small Computer System Interface）などのインターフェイスを介してＣＤ−Ｒ（CompactDisc Recordable）やＤＶＤ−ＲＡＭ（Digital Versatile Disc Random Access Memory）のドライブを設けても良い。
【００３１】
クライアント端末３０は、チケット購入希望者が代理店サーバ２０や元売りサーバ１０にアクセスしてチケットを購入するために使用する端末装置であり、図３に示したコンピュータ装置の他、携帯電話やＰＤＡ（Personal Digital Assistant）、キオスク端末などのネットワーク機能を備えた情報処理装置で実現される。
【００３２】
図４は、元売りサーバ１０の機能構成を示す図である。
図４を参照すると、元売りサーバ１０は、クライアント端末３０とデータ通信を行うための通信部１１と、チケットの管理業務における処理を行うためのチケット発行部１２と、送受信されるデータの暗号化および復号処理を行う暗号処理部１３とを備える。また、秘密鍵を格納した秘密鍵格納部１４と、チケット管理業務の処理に用いられる商品情報データベース（ＤＢ）１５と、信頼関係にある直下の代理店の情報を格納する下位代理店データベース（ＤＢ）１６とを備える。
【００３３】
通信部１１は、例えば図３のネットワークインターフェイス１０６にて実現され、クライアント端末３０からのリクエストを受信してチケット発行部１２に渡すと共に、チケット発行部１２から受け取ったレスポンスをクライアント端末３０へ送信する。
【００３４】
チケット発行部１２は、例えば図３のプログラム制御されたＣＰＵ１０１およびメインメモリ１０３にて実現され、通信部１１から受け取ったリクエストに応じてチケットの発行やキャンセル、照会といった管理業務の処理を実行する。そして、チケット発行部１２は、発行されたチケットやキャンセル等の手続が完了したことを通知するレスポンスを通信部１１に渡してクライアント端末３０へ返送させる。
【００３５】
暗号処理部１３は、例えば図３のプログラム制御されたＣＰＵ１０１およびメインメモリ１０３にて実現され、クライアント端末３０から受信したリクエストの復号処理およびクライアント端末３０へ送信されるレスポンスの暗号化処理を行う。暗号処理部１３による復号処理および暗号化処理には、秘密鍵格納部１４に格納されている秘密鍵が用いられる。
【００３６】
秘密鍵格納部１４は、例えば図３の磁気ディスク装置１０５やメインメモリ１０３等の記憶装置にて実現され、暗号処理部１３による暗号化および復号処理に用いられる秘密鍵を保持する。秘密鍵格納部１４に保持される秘密鍵は２種類であり、１つは木構造における自身の直下の代理店サーバ２０との間で共有される秘密鍵である。これは、暗号処理部１３が直下の代理店サーバ２０で作成されたトークンを復号するために用いられる。もう１つは元売りサーバ１０が独自に持つ秘密鍵である。これは、チケット発行部１２により発行される電子チケットの少なくとも一部を暗号化するために用いられる。
【００３７】
商品情報データベース１５は、例えば図３の磁気ディスク装置１０５やメインメモリ１０３等の記憶装置にて実現され、チケットの発行に関する管理情報（どの席のチケットが既に発行されたか等）が格納される。チケット発行部１２は、クライアント端末３０からのリクエストに応じてチケットの発行やキャンセルを行うたびに、商品情報データベース１５の該当項目の情報を更新する。
【００３８】
下位代理店データベース１６は、例えば図３の磁気ディスク装置１０５やメインメモリ１０３等の記憶装置にて実現され、元売りサーバ１０の直下の代理店サーバ２０に関する情報が格納される。なお、情報が登録される代理店サーバ２０は、元売りサーバ１０の直下に位置するものであれば良く、中間代理店の代理店サーバ２０であるか末端代理店の代理店サーバ２０であるかは問わない。元売り業者が新たに所定の代理店にチケット販売の委託契約を行った場合は、その代理店の代理店サーバ２０に関する情報が追加されることとなる。反対に、既に委託契約がなされていた代理店に対して契約を解消した場合は、その代理店の代理店サーバ２０に関する情報が削除されたり、その代理店サーバ２０が無効であることを示す情報が登録されたりする。
【００３９】
図５は、代理店サーバ２０の機能構成を示す図である。
図５を参照すると、代理店サーバ２０は、クライアント端末３０とデータ通信を行うための通信部２１と、このリクエストに対してトークンを発行するリクエスト受付処理部２２と、暗号処理部２３と、チケットの販売業務を行うためのチケット販売処理部２４とを備える。また、秘密鍵を格納した秘密鍵格納部２５と、信頼関係にある直下の代理店の情報を格納する下位代理店データベース（ＤＢ）２６と、チケットを販売した顧客の情報を格納する顧客情報データベース（ＤＢ）２７とを備える。
【００４０】
通信部２１は、例えば図３のネットワークインターフェイス１０６にて実現される。そして、クライアント端末３０からのリクエストを受信してリクエスト受付処理部２２に渡すと共に、リクエスト受付処理部２２から受け取ったレスポンスをクライアント端末３０へ送信する。
【００４１】
リクエスト受付処理部２２は、例えば図３のプログラム制御されたＣＰＵ１０１およびメインメモリ１０３にて実現され、通信部２１から受け取ったリクエストを解釈して処理を行う。リクエストが自身の直下の代理店サーバ２０で発行されたトークンを含むものであった場合、リクエスト受付処理部２２は、現在のトークンを自身が発行するトークンに置き換える。一方、リクエストがトークンを含まないものであった場合、リクエスト受付処理部２２は、トークンを発行してそのリクエストに付加すると共に、トークンを付加していないリクエストをチケット販売処理部２４に渡す。これらの処理の後、リクエスト受付処理部２２は、トークンが付加された（あるいは置き換えられた）リクエストをレスポンスとして通信部２１に渡し、クライアント端末３０へ返送させる。
【００４２】
暗号処理部２３は、例えば図３のプログラム制御されたＣＰＵ１０１およびメインメモリ１０３にて実現され、クライアント端末３０から受信したリクエストの復号処理およびクライアント端末３０へ送信されるレスポンスの暗号化処理を行う。暗号処理部２３による復号処理および暗号化処理には、秘密鍵格納部２５に格納されている秘密鍵が用いられる。
【００４３】
チケット販売処理部２４は、例えば図３のプログラム制御されたＣＰＵ１０１およびメインメモリ１０３にて実現され、チケットの販売に伴う決済を実行する。チケット販売処理部２４としては、クレジットカードや電子マネー、金融機関への振り込み、その他の支払い形式による既存のオンライン決済のシステムを適用できる。
【００４４】
秘密鍵格納部２５は、例えば図３の磁気ディスク装置１０５やメインメモリ１０３等の記憶装置にて実現され、暗号処理部２３による暗号化および復号処理に用いられる秘密鍵を保持する。秘密鍵格納部２５に保持される秘密鍵は２種類であり、１つは木構造における自身の直下の代理店サーバ２０との間で共有される秘密鍵である。これは、暗号処理部２３が直下の代理店サーバ２０で作成されたトークンを復号するために用いられる。もう１つは木構造における自身の直上の代理店サーバ２０との間で共有される秘密鍵である。
これは、クライアント端末３０からのリクエストに対してトークンを付加する場合や、直下の代理店サーバ２０でリクエストに付加されたトークンをリクエスト受付処理部２２が自身のトークンに置き換える場合に、当該リクエスト受付処理部２２が作成したトークンを暗号化するために用いられる。ただし、自サーバが末端代理店の代理店サーバ２０である場合は、自サーバの下位の代理店サーバ２０は存在しないので、１つ目の直下の代理店サーバ２０との間で共有される秘密鍵は保持されない。
【００４５】
下位代理店データベース２６は、例えば図３の磁気ディスク装置１０５やメインメモリ１０３等の記憶装置にて実現され、自身の代理店サーバ２０の直下にある代理店サーバ２０に関する情報が格納される。なお、情報が登録される代理店サーバ２０は、自サーバの直下に位置するものであれば良く、中間代理店の代理店サーバ２０であるか末端代理店の代理店サーバ２０であるかは問わない。自代理店が新たに他の代理店にチケット販売の委託契約を行った場合は、当該他の代理店の代理店サーバ２０に関する情報が追加されることとなる。反対に、既に委託契約がなされていた所定の代理店に対して契約を解消した場合は、当該所定の代理店の代理店サーバ２０に関する情報が削除されたり、当該所定の代理店サーバ２０が無効であることを示す情報が登録されたりする。ただし、自サーバが末端代理店の代理店サーバ２０である場合は、自サーバの下位の代理店サーバ２０は存在しないので、下位代理店データベース２６は不要となる。
【００４６】
顧客情報データベース２７は、例えば図３の磁気ディスク装置１０５やメインメモリ１０３等の記憶装置にて実現され、チケット販売処理部２４による処理で得られる顧客（チケット購入者）の情報が格納される。
【００４７】
図６は、クライアント端末３０の機能構成を示す図である。
図６を参照すると、クライアント端末３０は、元売りサーバ１０および代理店サーバ２０とデータ通信を行うための通信部３１と、チケット購入要求を生成するリクエスト発行部３２と、チケットを購入するための各種の処理を行うチケット購入処理部３３と、ユーザに対して情報を出力しユーザによる入力操作を受け付ける入出力制御部３４と、記憶部３５とを備える。
【００４８】
通信部３１は、クライアント端末３０が図３に示したコンピュータ装置により構成される場合、ネットワークインターフェイス１０６にて実現される。この通信部３１は、チケット購入処理部３３から受け取ったリクエストを代理店サーバ２０または元売りサーバ１０に送信する。また、代理店サーバ２０または元売りサーバ１０から送信されたレスポンスを受信し、チケット購入処理部３３に渡す。
【００４９】
リクエスト発行部３２は、クライアント端末３０が図３に示したコンピュータ装置により構成される場合、プログラム制御されたＣＰＵ１０１およびメインメモリ１０３にて実現される。このリクエスト発行部３２は、入出力制御部３４により受け付けた操作にしたがって、チケットの購入要求を発行し、通信部３１に渡して代理店サーバ２０へ送信させる。
【００５０】
チケット購入処理部３３は、クライアント端末３０が図３に示したコンピュータ装置により構成される場合、プログラム制御されたＣＰＵ１０１およびメインメモリ１０３にて実現される。このチケット購入処理部３３は、代理店サーバ２０から送信されたトークン付きのリクエストを通信部３１に渡し、そのトークンによって特定される送信先である代理店サーバ２０または元売りサーバ１０（すなわち、トークンを発行した代理店サーバ２０の親に当たるサーバ）へ送信させる。さらに、チケット購入処理部３３は、元売りサーバ１０からチケットを取得した場合に、そのチケットを記憶部３５に格納する。また、チケット購入処理部３３は、チケットの購入に伴う決済をオンラインで行うために、通信部３１を介して、決済を行うためのコマンドおよび必要な情報を代理店サーバ２０に送信する。
【００５１】
入出力制御部３４は、クライアント端末３０が図３に示したコンピュータ装置により構成される場合、プログラム制御されたＣＰＵ１０１およびメインメモリ１０３にて実現される。この入出力制御部３４は、ビデオカード１０４および図示しないディスプレイ装置とで構成された表示手段を制御して、チケット購入のための一連の処理がどの段階にあるのかを表示したり、チケットの購入結果を表示したりする。また、入出力制御部３４は、キーボード／マウス１０９等の入力手段に対するユーザの入力操作を受け付けて、チケット購入処理部３３に対応する処理を実行させる。
【００５２】
記憶部３５は、クライアント端末３０が図３に示したコンピュータ装置により構成される場合、磁気ディスク装置１０５やメインメモリ１０３等の記憶装置にて実現される。この記憶部３５は、最終的に購入されたチケットの電子情報を保管する。
【００５３】
次に、以上のように構成された元売りサーバ１０、代理店サーバ２０およびクライアント端末３０からなるシステムによりチケットを販売する際の動作を説明する。
以下の説明において、システムは、図１に示すように構成されている場合を例とする。このシステムにおいて、クライアント端末３０から末端代理店である代理店Ｃの代理店サーバ２０Ｃに対して最初のチケット購入要求が送信され、中間代理店である代理店Ａの代理店サーバ２０Ａ、元売りサーバ１０と、順次アクセスがなされる。
【００５４】
図７は、チケット購入時におけるクライアント端末３０の動作を説明するフローチャートである。
図７を参照すると、まず、ユーザ（チケット購入希望者）がクライアント端末３０を操作して、代理店サーバ２０Ｃにアクセスする（ステップ７０１）。そして、ユーザが所望のチケットを選択して購入のための操作を行うと、リクエスト発行部３２が、入出力制御部３４により受け付けられた操作に基づいてチケットの購入要求を生成し、通信部３１を介して代理店サーバ２０Ｃへ送信する（ステップ７０２）。このチケット購入要求には、所望のチケットの種類に関する情報（イベントの名前や開催日時等）およびユーザに関する情報が記述される。
【００５５】
代理店サーバ２０Ｃでは、リクエスト受付処理部２２がこのチケット購入要求を受け付け、このチケット購入要求をチケット販売処理部２４に渡すと共に、このチケット購入要求に付加するトークンを作成する。このトークンには、ユーザに関する情報や後述する決済情報、トークンを付加した自サーバ（ここでは代理店サーバ２０Ｃ）を示す識別情報、次の送信先である上位のサーバ（この場合は代理店サーバ２０Ａ）を特定する情報（送信先情報）等が記述される。そして、暗号処理部２３が、秘密鍵格納部２５に格納されている代理店サーバ２０Ａとの間で共有される秘密鍵を用い、トークンのうち例えば送信先情報および自身の識別情報以外の情報を暗号化する（図８参照）。
【００５６】
一方、リクエスト受付処理部２２からチケット購入要求を受け取ったチケット販売処理部２４は、このチケット購入要求からユーザに関する情報を抽出して顧客情報データベース２７に格納する。そして、通信部２１を介して、クライアント端末３０との間で、決済に必要な情報（決済方法の指定や金額等）やコマンドのやり取りを行い、チケットの販売に伴う決済をオンラインで実行する（ステップ７０３）。なお上述したように、この決済に関する処理の実施には、既存のオンライン決済システムを用いることができる。
【００５７】
チケット販売処理部２４による決済処理が終了した後、リクエスト受付処理部２２は、作成したトークンをクライアント端末３０から受信したチケット購入要求に付加して、そのチケット購入要求を送信したクライアント端末３０へ返送する。
クライアント端末３０が代理店サーバ２０Ｃから返送されたトークン付きチケット購入要求を受信すると（ステップ７０４）、チケット購入処理部３３が、このトークンに平文で記述されている次の送信先を読み取る。そして、この送信先の記述にしたがい、このトークン付きチケット購入要求を、代理店サーバ２０Ｃの上位のサーバである代理店サーバ２０Ａへ送信する（ステップ７０５）。
【００５８】
代理店サーバ２０Ａでは、リクエスト受付処理部２２がこのトークン付きチケット購入要求を受け付けて、暗号処理部２３に渡す。暗号処理部２３は、トークンに平文で記述された識別情報および下位代理店データベース２６に格納されている直下の代理店サーバ２０の情報により、このトークンが直下のどの代理店サーバ２０によって付加されたのかを判断する。そして、トークンを付加した代理店サーバ２０と共有する秘密鍵を秘密鍵格納部２５から取り出し、この秘密鍵を用いてトークンの暗号化された部分を復号する。ここでは、トークンが代理店サーバ２０Ｃによって付加されたので、代理店サーバ２０Ｃと共有する秘密鍵Ｃ（図１参照）を用いて復号処理が行われる。
【００５９】
次に、リクエスト受付処理部２２は、暗号処理部２３により平文化されたトークンに対して、識別情報や送信先情報等の書き換えを行う。また、書き換え前のトークンの内容を要約して新たなトークンに記述する。そして、暗号処理部２３が、秘密鍵格納部２５に格納されている秘密鍵を用い、トークンのうち送信先情報以外の情報を暗号化する。今回は、代理店サーバ２０Ａの上位のサーバは元売りサーバ１０であるので、代理店サーバ２０Ａと元売りサーバ１０とで共有される秘密鍵が、暗号化に使用される。
【００６０】
以上の処理の後、リクエスト受付処理部２２は、書き換えたトークンをクライアント端末３０から受信したチケット購入要求に付加して、そのチケット購入要求を送信したクライアント端末３０へ返送する。
クライアント端末３０が代理店サーバ２０Ａから返送されたトークン付きチケット購入要求を受信すると（ステップ７０４）、チケット購入処理部３３が、このトークンに平文で記述されている次の送信先を読み取る。そして、この送信先の記述にしたがい、このトークンの付加されたチケット購入要求を、代理店サーバ２０Ａの上位のサーバである元売りサーバ１０へ送信する（ステップ７０５）。
【００６１】
元売りサーバ１０では、チケット発行部１２がこのトークン付きチケット購入要求を受け付けて、暗号処理部１３に渡す。暗号処理部１３は、トークンに平文で記述された識別情報および下位代理店データベース２６に格納されている直下の代理店サーバ２０の情報により、このトークンが直下のどの代理店サーバ２０によって付加されたのかを判断する。そして、トークンを付加した代理店サーバ２０と共有する秘密鍵を秘密鍵格納部１４から取り出し、この秘密鍵を用いてトークンの暗号化された部分を復号する。ここでは、トークンが代理店サーバ２０Ａによって付加されたので、代理店サーバ２０Ａと共有する秘密鍵Ａ（図１参照）を用いて復号処理が行われる。
【００６２】
次に、チケット発行部１２は、暗号処理部２３により平文化されたトークンおよびチケット購入要求に記述された情報に基づいて商品情報データベース１５を検索する。そして、チケット購入要求に係るチケットがあれば（既に販売されていなければ）、当該チケットを発行する。そして、暗号処理部１３が、秘密鍵格納部２５に格納されている元売りサーバ１０独自の秘密鍵を用いて、このチケットの少なくとも一部を暗号化する。チケット発行部１２は、暗号処理部１３により暗号化されたチケットを、チケット購入要求を送信したクライアント端末３０へ返送する。
【００６３】
クライアント端末３０が元売りサーバ１０から返送されたチケットを受信すると（ステップ７０６）、チケット購入処理部３３は、受信したチケットを記憶部３５に格納して処理を終了する（ステップ７０７）。
【００６４】
以上の動作例において、クライアント端末３０は、代理店サーバ２０Ｃにおいて決済処理が済んだ後にトークン付きのチケット購入要求を受信することとした。このように代金を前払いするシステムとしたのは、チケット取得までにクライアント端末３０が代理店サーバ２０Ａおよび元売りサーバ１０へ順次アクセスしていくため、最初にチケットの販売権を持つ代理店サーバ２０Ｃにアクセスした際に決済を済ませておくことが合理的と考えられるためである。しかし、システムの構成やクライアント端末３０の種類、販売されるチケットの内容等の諸事情によっては、チケット取得後に決済を行う方が好ましい場合もある。そのような場合は、クライアント端末３０が、記憶部３５に最初のアクセス先を記憶しておき、元売りサーバ１０からチケットを受信した後に、最初にアクセスした代理店サーバ２０Ｃに再度アクセスし、チケット販売処理部２４とのやり取りによって決済を行えば良い。
【００６５】
次に、販売されたチケットの使用時の動作について説明する。
クライアント端末３０が携帯電話やＰＤＡ等の携帯情報端末である場合、記憶部３５に格納された電子情報がそのままチケットとして使用される。また、クライアント端末３０がキオスク端末等の場合、記憶部３５に格納された電子情報をバーコード等に変換して印刷された紙片をチケットとして使用することができる。チケットを使用する際には、チケットが記憶された携帯情報端末からチケット検査装置に直接電子情報を転送したり、携帯情報端末の表示画面に表示されたバーコードや紙片に印刷されたバーコード等のコード情報をチケット検査装置が読み取ったりすることにより、当該チケットの有効性がチェックされる。チケット検査装置には、元売りサーバ１０においてチケットを暗号化する際に使用された元売りサーバ１０独自の秘密鍵がセットされており、この秘密鍵によってチケットの内容が解読される。
【００６６】
また、元売りサーバ１０においてチケットを発行する際、トークンに含まれるユーザに関する情報の中からユーザＩＤ等の識別情報を抽出し、この識別情報を元売りサーバ１０自身の秘密鍵により暗号化してチケットに含めることができる。このようにすれば、例えばチケットが発行された際に通信経路で当該チケットが盗まれたとしても、チケット使用時に暗号化された識別情報を復号して検証することにより、他人によって不正にチケットが使用されてしまう事態を防ぐことができる。
【００６７】
なお、上記の例では、元売りサーバ１０はチケットの発行管理のみを行い、クライアント端末３０から元売りサーバ１０に直接アクセスしてチケットを購入する場合を想定していない。しかしながら、元売りサーバ１０自身がクライアント端末３０から最初の（すなわちトークンが付加されていない）チケット購入要求を受け付けて直接チケットを販売することも可能である。この場合、図４に示した元売りサーバ１０の構成に、図５の代理店サーバ２０におけるチケット販売処理部２４および顧客情報データベース２７に相当する構成要素が追加されることとなる。
【００６８】
また、上記の例では、全ての代理店サーバ２０がクライアント端末３０からのチケット購入要求を受け付けてチケットの販売を行うことができるものとして説明した。しかしながら、中間代理店の代理店サーバ２０（例えば図１の代理店サーバ２０Ａ）がトークン付きのチケット購入要求の中継のみを行い、チケットの販売は自身の下位の代理店サーバ２０に行わせるような運用も可能である。この場合、チケットの販売を行わない中間代理店の代理店サーバ２０は、図５に示した構成のうち、チケット販売処理部２４および顧客情報データベース２７は不要となる。本発明の内容は、階層化されたサーバにおいて、中間サーバでのトランザクション処理の負荷を下位サーバに移行させる技術であることが分かる。従って、これまでチケットの販売の実施形態として説明したが、あらゆるデジタル・コンテンツ（ミュージック、映像、公的な個人情報等）を含む電子データの発送方式も本発明の内容に含まれる。
【図面の簡単な説明】
【００６９】
【図１】本実施形態によるチケット販売システムを説明する図である。
【図２】本実施形態における元売りサーバと代理店サーバとの間の信頼関係を説明する図である。
【図３】本実施形態のシステムにおける元売りサーバおよび代理店サーバとして好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
【図４】本実施形態の元売りサーバの機能構成を示す図である。
【図５】本実施形態の代理店サーバの機能構成を示す図である。
【図６】本実施形態のクライアント端末の機能構成を示す図である。
【図７】チケット購入時における本実施形態のクライアント端末の動作を説明するフローチャートである。
【図８】本実施形態においてチケット購入要求に付加されるトークンのデータ構成の例を示す図である。
【図９】サーバを階層的に接続して構成されたシステムにおける電子チケットの販売方法を説明する図である。
【符号の説明】
【００７０】
１０…元売りサーバ、１１、２１、３１…通信部、１２…チケット発行部、１３、２３…暗号処理部、１４、２５…秘密鍵格納部、１５…商品情報データベース（ＤＢ）、１６、２６…下位代理店データベース（ＤＢ）、２０…代理店サーバ、２２…リクエスト受付処理部、２４…チケット販売処理部、２７…顧客情報データベース（ＤＢ）、３０…クライアント端末、３２…リクエスト発行部、３３…チケット購入処理部、３４…入出力制御部、３５…記憶部、１０１…ＣＰＵ（Central Processing Unit：中央処理装置）、１０３…メインメモリ、１０４…ビデオカード、１０５…磁気ディスク装置（ＨＤＤ）、１０６…ネットワークインターフェイス、１０９…キーボード／マウス
【図１】
2006178922.tif 000003
【図２】
2006178922.tif 000004
【図３】
2006178922.tif 000005
【図４】
2006178922.tif 000006
【図５】
2006178922.tif 000007
【図６】
2006178922.tif 000008
【図７】
2006178922.tif 000009
【図８】
2006178922.tif 000010
【図９】
2006178922.tif 000011