JP3828517B2 - 電子商取引管理サーバ及び電子商取引管理方法 - Google Patents
電子商取引管理サーバ及び電子商取引管理方法 Download PDFInfo
- Publication number
- JP3828517B2 JP3828517B2 JP2003195181A JP2003195181A JP3828517B2 JP 3828517 B2 JP3828517 B2 JP 3828517B2 JP 2003195181 A JP2003195181 A JP 2003195181A JP 2003195181 A JP2003195181 A JP 2003195181A JP 3828517 B2 JP3828517 B2 JP 3828517B2
- Authority
- JP
- Japan
- Prior art keywords
- company
- ticket
- reservation
- data
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000007726 management method Methods 0.000 title description 271
- 230000005540 biological transmission Effects 0.000 claims description 34
- 238000000034 method Methods 0.000 description 73
- 238000012545 processing Methods 0.000 description 41
- 230000004044 response Effects 0.000 description 33
- 230000008569 process Effects 0.000 description 29
- 238000010586 diagram Methods 0.000 description 28
- 239000003795 chemical substances by application Substances 0.000 description 25
- 230000006870 function Effects 0.000 description 19
- 230000008859 change Effects 0.000 description 15
- 238000006243 chemical reaction Methods 0.000 description 11
- 239000008186 active pharmaceutical agent Substances 0.000 description 10
- 238000004891 communication Methods 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 238000012790 confirmation Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 6
- 238000007493 shaping process Methods 0.000 description 6
- 238000013507 mapping Methods 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 238000013500 data storage Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 238000013523 data management Methods 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000003442 weekly effect Effects 0.000 description 3
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000004308 accommodation Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 235000014510 cooky Nutrition 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 238000012946 outsourcing Methods 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、チケット供給者が、ユーザ群内のユーザにチケットを販売するための電子商取引管理サーバ及び電子商取引管理方法に関する。本明細書において「ユーザ群」には、企業、中小企業群、個人の集合等を含み、「企業」には、官公庁や各種団体、教育機関等を含むものとする。又、「部課」とは、企業を構成する部或いは部に属する課などのことで、企業が料金の精算を行う単位であるのが好ましい。
【０００２】
【従来の技術】
従来、業務出張などの旅行手配をするための旅行代理店（所謂インハウスエージェント）を企業グループ内に設け、この旅行代理店を介して、交通機関やホテル等のチケット供給者が、企業の従業員（ユーザ）にチケットを販売する方法が知られている（例えば、特許文献１）。
【０００３】
図２６に、同公報に開示されたチケットの販売方法の概要を示す。本方法では、まず、企業の従業員が、前記旅行代理店に対してチケット申込を行う。それに応じて、前記旅行代理店が、チケット供給者に対してチケット申込を行い、チケット申込が完了すると、チケットを発券し従業員に配送する。チケットの代金は、企業が前記旅行代理店に一括して精算する。前記旅行代理店は、企業から回収した代金をチケット供給者に支払い、チケットの発券手数料を得る。
【０００４】
本方法によれば、依頼人が主にグループ内企業に固定されているために出張先や手配の好みなどが偏る傾向があることを利用して、前記旅行代理店が、交通機関やホテル等のチケット供給者から、取り扱い数量をまとめることによる割引（大口割引）を引き出しやすいというメリットがある。又、従業員が所属部署と従業員ＩＤを伝えるだけで手続きができたり、チケットが従業員の部署まで届けられたりするなど、本方法は、企業内の従業員にとって非常に便利である。
【０００５】
しかし、これらの旅行代理店は、チケットの発券手数料を主な収益源としているが、チケットを発券し配布する際のコストが高く、実際にはあまり収益を上げることができていないという問題点がある。
【０００６】
又、交通機関やホテル等のチケット供給者は、ある割合の発券手数料を旅行代理店に支払う必要があり、これが収益を圧迫する原因となっている。
【０００７】
この発券手数料の割合を引き下げようにも、前記旅行代理店も、チケットを発券し配布するコストを差し引いた残りが多いわけではないので、交渉が成立しにくい。
【０００８】
このように、本方法では、発券業務に対して発生する発券手数料が、チケット供給者と前記旅行代理店の両者にとって収益を向上させるための障害となっている。
【０００９】
前述のチケットを発券し配布するコストが大きいという問題を解消するために、近年、インターネットを利用して、交通機関やホテル等のチケット供給者が、企業内の従業員等の消費者にチケットを直接販売する方法が増えつつある。
【００１０】
図２７に、上記チケットの販売方法の概要を示す。本方法では、企業内の従業員が、直接インターネットを介して、チケット供給者に対してチケット申込を行う。代金精算は、クレジットカード会社を介して行われる。そして、従業員は、交通機関やホテルの利用時に、空港やホテル等でチケットの発券を受ける。本方法は「チケットレス方式」と呼ばれる。
【００１１】
本方法では、消費者にとって、事前にチケットを買いに行く手間がかからないというメリットがあり、交通機関にとっても、チケットを発券し配送するコストを削減でき、又、申込時にクレジットカード番号を通知させることにより、確実に代金回収ができるというメリットがある。
【００１２】
ところが、本方法では、クレジットカードを用いるので、従業員が個人単位でチケット代金を支払い、後に企業が従業員に精算することになる。そのため、企業は、前述の大口割引が適用されるだけの数量のチケットを購入しているにもかかわらず、その適用を受けることができないという問題点がある。
【００１３】
上述した問題点を解消するために、チケット供給者が、チケットレス方式で、企業の従業員にチケットを直接販売する方法が知られている（例えば、特許文献２）。
【００１４】
図２８に、上記チケットの販売方法の概要を示す。本方法では、チケット供給者が、企業毎に「企業用ＩＤ」を発行し、企業の従業員は、「企業用ＩＤ」を用いて、インターネットを介して、チケット供給者に対して直接チケット申込を行う。
【００１５】
又、本方法では、チケット供給者と企業とが、同一の「企業用ＩＤ」を使用するため、以下の問題点も生じる。
【００１６】
チケット供給者が、企業毎に「企業用ＩＤ」を割り振る場合、その「企業用ＩＤ」は、この企業内の経理システムが用いる「従業員ＩＤ」や「部課コード」等とは一般に異なるものとなり、当該企業が、前記経理システムと連動してチケット代金精算することが困難となる。
【００１７】
逆に、企業が「企業用ＩＤ」を割り振る場合、チケット供給者が、企業毎の様々な様式の「企業用ＩＤ」を取り扱う必要があるので、チケット供給者の既存の予約システムで扱いにくい。又、企業毎の作法に則った経理処理を行うためには、チケット供給者に、企業の従業員や部課に関する企業内情報を提供する必要があるが、企業は、このような機密情報を提供したがらないのが普通である。更に、企業内では異動や組織変更が頻繁にあるため、チケット供給者が、これらの企業内情報の変更に追随するのは困難である。本方法は、これらの理由で実現されていないのが現状である。
【００１８】
更に、特許文献２に開示された方法では、一つの企業が複数のチケット供給者を利用する状況が想定されていないため、企業におけるユーザが、単一の「企業用ＩＤ」を用いて、複数の航空会社（チケット供給者）にまたがってチケットの検索を行ったり、航空会社とホテル（チケット供給者）等を組にして、チケットの検索及び申込を行ったりすることができない。
【００１９】
一方、従来における企業の出張管理は、コストがかかる問題点が挙げられている。
【００２０】
従来のチケットの検索及び申込におけるシステム構成図を図２９に示す。ここでは、第１の企業５ａ、第２の企業５ｂ、第３の企業５ｃ…と、チケットの供給システムである第１のホテル予約システム１１ａ、第２のホテル予約システム１１ｂ、第１の交通機関予約システム１２ａ、第２の交通機関予約システム１２ｂが存在するとする。
【００２１】
この場合、従来のチケット検索及び申込においては、例えば第１の企業５ａは、第１のホテル予約システム１１ａ、第２のホテル予約システム１１ｂ、第１の交通機関予約システム１２ａ、第２の交通機関予約システム１２ｂのそれぞれについて接続を行わなければならない。チケットの供給システムが例えばインターネットのＷｅｂにおいて公開されるような場合は、一度に複数のチケットの供給システムに接続することは容易であるが、チケットの供給システムにダイアルアップを行い接続しなければならない場合は、一度に複数のチケットの供給システムに接続することは極めて困難になる。
【００２２】
更に、例えば第２のホテル予約システム１１ｂがシステム変更になった場合は、第１の企業システム５ａもそれに伴ってシステム変更を行わなければならない。
【００２３】
このように、従来のチケット検索及び申込においては、複数のチケットの供給システムに接続し、一度の操作で複数のチケットの供給システムの役務を受けることは不可能であった。
【００２４】
上述したような、従来のチケットの検索及び申込における利用者及び旅行代理店の作業を図３０に示す。ここでは、企業の利用者が出張する場合に、旅行代理店（或いはインハウスエージェント）を介してチケットを取得する場合について説明する。
【００２５】
まず、ステップＳ９０１において、利用者の出張が決定すると、ステップＳ９０２において、経理システム或いは経理担当者に対して仮払処理を行う。更に、ステップＳ９０３において、利用者はチケットの供給システムに接続をして、交通機関やホテルを決定し、ステップＳ９０４においてその内容を旅行代理店に連絡する。
【００２６】
ステップＳ９０４の連絡を受けて、旅行代理店はステップＳ９５１において予約を受付け、ステップＳ９５２において、端末操作によってその予約内容を入力する。これにより、ステップＳ９５３において、チケットが発券される。
【００２７】
チケットが無事発券されると、ステップＳ９５４において利用者に連絡し、ステップＳ９０５において、利用者は手配が完了した連絡を受ける。
【００２８】
次に、旅行代理店は、ステップＳ９５３において発券したチケットに基づいて、ステップＳ９５５において請求書を作成し、ステップＳ９５６においてチケットを利用者に配達する。
【００２９】
次に、ステップＳ９０６において、利用者はステップＳ９５６において配達されたチケットを受け取り、支払いを行う。ステップＳ９０７において、手配されたチケットに従って出発する。出張から戻ってくると、ステップＳ９０８において、ステップＳ９０２で受けた仮払との差額の精算を行う。
【００３０】
この方法に関連して、企業における出張管理のコスト削減を図る方法が知られている（例えば、特許文献３）。
【００３１】
この出願は、業務出張に関連する一連の事務手続きを出張の起案から精算までコンピュータネットワークを利用した総合的なシステムによって支援可能とし、全てのプロセスで使用されるデータに一貫性を持たせることにより、法人等の業務組織と旅行業者等とにおける各プロセス間の情報の伝達を大幅に省力化するとともに正確性を実現し、時間短縮その他の利便性等を創出する、旅行代理店に予約申込を依頼する処理フローを電子化したシステムである。しかし、代理店の介在を前提としているため、急な出張申請や変更への対応が難しい。又、チケットを出力し、配布するため、出張管理コストの削減につながらないなどの問題があり、充分にコスト削減がなされていない。
【００３２】
一方、交通機関やホテルなどのサプライヤが企業向けに直販しているが、企業内の出張・精算システムと連動させにくく、サプライヤ毎にインタフェースが異なるため、一つの企業が直接複数のサプライヤと接続するのは、コストがかかるなどの問題点がある。
【００３３】
更に、社内業務の効率化の手法として、ＥＤＩ（Electronic Data Exchange：受発注業務に関する電子的情報交換）化されたものがある。しかし、これはあくまでも入り口だけの提供であり、出張予約の手配を行うことができる旅行代理店やサプライヤとで手配情報を交換するだけのものである。従って、企業内システムに適合したインタフェースを有さないので、ユーザが充分満足できるものではない。
【００３４】
このように、出張におけるチケットやホテルの予約に限らず、企業活動を通じて受ける様々な役務の予約及び精算は、その手続きが煩雑で、企業にとって、多大なコストを強いることになっていた。
【００３５】
【特許文献１】
特開２０００−３３１０９８号公報
【００３６】
【特許文献２】
特開平１１−３３９０７６号公報
【００３７】
【特許文献３】
特開平１１−１４３９７７号公報
【００３８】
【発明が解決しようとする課題】
しかしながら、上述したように従来方法には、チケット供給者（サプライヤ）、旅行代理店、企業、企業の従業員の全てに対して、同時にメリットをもたらすことができなかった。
【００３９】
即ち、チケット供給者と企業の双方が独自に管理するＩＤを用いて、チケット供給者が、チケットレス方式で、企業の従業員にチケットを直接販売する方法が存在しなかった。
【００４０】
又、図３０に示した例においては、出張者が費用の仮払・精算を行ったり、旅行代理店がチケットを配達しなければならないため、処理が煩雑になり、これに伴い、出張にかかるコストが大きくなっていた。
【００４１】
更に、既存のシステムと連動させ、業務効率を図ることができなかった。即ち、企業毎に社内システムに合った接続方法を提供しなければならず、そのシステムの導入には多額のコストが要求されていた。
【００４２】
更に、企業がイントラネット上で構築されたシステムで全てを処理しようとすると、イントラネットに接続できない場合に、処理を行えなくなってしまっていた。
【００４３】
又、企業内のシステムと外部システム（例えば予約システム）を接続すると、企業内の情報、例えば出張情報や従業員情報などの機密度が高い情報が外に漏れてしまう場合があり、企業内手続きのシステム化を躊躇させる要因となっていた。
【００４４】
そこで本発明は、ユーザが、役務の予約を容易に行うことのできる電子商取引管理サーバ及び電子商取引管理方法を提供することを目的とする。
【００４５】
【課題を解決するための手段】
上記課題を解決するために、本発明の第１の特徴は、企業が保有する企業予約システム及び企業経理システムと、チケット供給者が保有するチケット供給者予約システム及びチケット供給者請求システムと、に接続され、前記チケット供給者が前記企業内のユーザにチケットを販売するための電子商取引管理サーバである。本発明の第１の特徴に係る電子商取引管理サーバは、 (a) 企業を示す企業コードと、該企業内でユーザを識別するためのＩＤとを含むユーザＩＤと、 (b) 企業コードと、チケット供給者予約システムがユーザを識別するためのＩＤとを含む顧客ＩＤと、 (c) チケット供給者と、を関連付けて記憶する関連付け部と、企業予約システムから送信されるユーザＩＤ及びチケット供給者を含む第１の申込データを受信する申込データ受信部と、第１の申込データに含まれるユーザＩＤ及びチケット供給者との組み合わせに基づいて関連付け部を検索して対応する顧客ＩＤを決定し、該決定された顧客ＩＤ及びチケット供給者を含む第２の申込データを第１の申込データに基づいて作成し、チケット供給者が保有するチケット供給者予約システムに第２の申込データを送信する申込データ送信部と、チケット供給者予約システムから送信される顧客ＩＤ及びチケット供給者が含まれた申込結果データを受信し、該申込結果データに含まれる顧客ＩＤとチケット供給者との組み合わせに基づいて関連付け部を検索して対応するユーザＩＤを決定し、該決定されたユーザＩＤに含まれる企業コードで示される企業が保有する企業予約システムに、申込結果データ内の顧客ＩＤを決定されたユーザＩＤに置換した申込結果データを送信する申込結果データ提示部と、チケット供給者請求システムから送信される顧客ＩＤ及びチケット供給者を含む第１の請求データを受信する請求データ受信部と、第１の請求データに含まれる顧客ＩＤ及びチケット供給者との組み合わせに基づいて関連付け部を検索して対応するユーザＩＤを決定し、該決定されたユーザＩＤを含む第２の請求データを第１の請求データに基づいて作成し、決定されたユーザＩＤに含まれる企業コードで示される企業が保有する企業経理システムに第２の請求データを送信する請求データ送信部とを備える。
【００４９】
【発明の実施の形態】
次に、図面を参照して、本発明の第１及び第５の実施の形態を説明する。以下の図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
【００５０】
本発明の実施の形態においては、例えば、企業に所属するユーザが出張する場合に、ホテルや交通機関を予約し、その精算を行う場合について説明している。
【００５１】
（第１の実施の形態）
本発明の第１の実施の形態について、図１を参照しながら説明する。図１は、本発明の第１の実施の形態に係る電子商取引システムを示すシステム構成図である。第１の実施の形態に係る電子商取引システムは、ユーザ（従業員）の出張を管理しその出張に必要なホテルや交通機関のチケットを予約する顧客企業システム５、顧客企業システム５が予約するホテルのホテル予約システム１１、顧客企業システム５が予約する交通機関の交通機関予約システム１２、複数の顧客企業システム５から任意の複数のホテル予約システム１２、交通機関予約システム１２に接続してホテルや交通機関の予約を行わせる管理サーバ２、管理サーバ２で更新及び参照されるデータが登録されたデータベースの管理を行う共通ＤＢサーバ６、管理サーバ２の管理を行う管理端末３、４を備えている。ここで、顧客企業システム５とは、管理サーバ２が契約している企業が、管理サーバ２にアクセスするＷｅｂサーバのＣＧＩ（Common Gateway Interface：ブラウザからの要求に応じて、プログラムを起動するための仕組み）やサーブレット（モジュール化されたJava（米国 Sun Microsystems, Inc.の登録商標）プログラム）、アプリケーションサーバなどのことである。管理端末３、４は、管理サーバ２及び本発明の電子商取引システムの管理者及び運用者が利用するツールを処理する端末である。
【００５２】
図１においては、顧客企業システム５、ホテル予約システム１１及び交通機関予約システム１２は、各々一つずつしか記載していないが、複数の顧客企業システム５、ホテル予約システム１１及び交通機関予約システム１２は、複数あっても構わない。この場合、一つの顧客企業システム５から、管理サーバ２を介して、一つのホテル予約システム１１或いは交通機関予約システム１２に接続される、それぞれの接続についてセションを管理するのが好ましい。
【００５３】
本発明の電子商取引システムにおいては、各システム及びプロセスの間を接続する場合、ＡＰＩ（Application Program Interface）を介して、接続先の仕様に合わせてデータを整形する。ここで、プロセスとは、スイッチング手段２０等の各手段の構成要素の一つであるプログラムのことである。更に、接続元と接続先とでプロトコルが異なる場合に、そのプロトコルを変換することにより行われる。このＡＰＩを介して接続を行うことにより、既存のシステム及びプロセスの変更を最小限に押さえて接続することができる。即ち、本発明の電子商取引システムにおいては、大きく分けて以下の３つのＡＰＩが存在する。
【００５４】
（ａ）セション管理やログイン認証など、顧客企業・サイトから呼び出される接続管理を行う場合は、共通機能ＡＰＩである接続管理ＡＰＩが行う。図１においては、ＡＰＩ２７が接続管理ＡＰＩに相当する。
【００５５】
（ｂ）主に顧客企業システム５の利用者がホテルや交通機関を予約する場合は、予約者用ＡＰＩが行う。図１においては、ＡＰＩ１３、１４が予約者用ＡＰＩに相当する。複数の国内外の航空予約のシステム、複数の国内外のホテルの予約システムに対して、それぞれ別々に用意するのが好ましい。
【００５６】
（ｃ）管理サーバ２の管理者及び運用者が、予約状況の確認や課金情報や契約情報を見る場合は、管理者用ＡＰＩが行う。図１においては、ＡＰＩ２８が管理者用ＡＰＩ相当する。
【００５７】
これらのＡＰＩについて、どちらのシステム或いはプロセスにＡＰＩを備えるかは、システムの要件に基づいて随時判断されるのが好ましい。
【００５８】
以下、本発明に係る電子商取引システムを構成する主な要素について説明する。
【００５９】
共通ＤＢサーバ６は、管理サーバ２により更新及び参照されるデータを管理するデータベース管理手段３５０と、アカウント記憶装置３５２、契約記憶装置３５３、予約記憶装置３５４、システムアクセスアクセス数記憶装置３５５を備えている。
【００６０】
データベース管理手段３５０は、アカウント記憶装置３５０、契約記憶装置３５３、予約記憶装置３５４、システムアクセス数記憶装置３５５を管理している。即ち、データベース管理手段３５０は、管理サーバ２が管理するデータを各記憶装置に格納する。
【００６１】
アカウント記憶装置３５２には、顧客企業システム５の企業コード、アクセスＩＤ、パスワード等が記録されている。更に、企業に所属するユーザ毎にアクセスＩＤやパスワード等を設定しても良い。更に、顧客企業システム５が、ホテル予約システム１１や交通機関予約システム１２に提示する氏名やカード番号等を設定しても良い。更に、顧客企業システム５が、接続するホテル予約システム１１や交通機関予約システム１２を限定しても良い。この場合、出張先の地域によって限定をしても構わない。これにより、顧客企業システム５は、例えばある交通機関予約システム１２に対して大量の発注を行うことにより、その交通機関予約システム１２の顧客企業システム５に対する価格を下げることもできる。又、顧客企業システム５に属する出張するユーザ或いはユーザの属性に従って、提示するホテルや交通機関を決定しても良い。具体的には、企業の役員には、新幹線のグリーン車を利用を許可したり、一泊２万円以上のホテルの利用を許可することができる。
【００６２】
契約記憶装置３５３は、管理サーバ２が接続を受ける顧客企業システム５や、管理サーバ２が接続をするホテル予約システム１１や交通機関予約システム１２の、企業名、ホテル名、交通機関名、住所、電話番号、担当者名等が記録されている。
【００６３】
予約記憶装置３５４は、予約数、キャンセル数、金額などである。これにより、管理サーバ２が、顧客企業システム５に対して請求金額を提示することができる。更に、予約したホテル或いは交通機関の日付、指定便、ホテル名、人数、ランクなどを記録することにより、予約内容についても顧客企業システム５に対して請求金額を提示することができる。又、更に当該予約について、顧客企業システム５内に属する、精算を行う部課を記載していても構わない。この部課を記載することにより、顧客企業システム５内に一括で請求が来ても、記載された部課に従って請求を振り分けても良い。この請求の振り分けは、顧客企業システム５に属する経理を担当する部署が行っても良いし、インハウスエージェントが行っても良い。更に、管理サーバ２から、顧客企業システム５に属する部課に対して、直接請求を行っても構わない。
【００６４】
システムアクセス数記憶装置３５５は、顧客企業システム５が管理サーバ２に接続した回数及び時間、更にホテル予約システム１１及び交通機関予約システム１２に接続した回数及び時間、又、各接続におけるトラフィック量などが記録されている。これにより、管理サーバ２は、顧客企業システム５、ホテル予約システム１１、交通機関予約システム１２に対して、接続に対して課金を行うことができる。
【００６５】
管理サーバ２は、スイッチング手段２０、基幹管理手段２６、ログ管理手段２５０、ログデータ２５２を備えている。
【００６６】
ログデータ２５２とは、管理サーバ２における運用ログである。
【００６７】
スイッチング手段２０は、顧客企業システム５から、ＡＰＩ２７を介した接続を受付け、顧客企業システム５からの接続毎に設定されるセションを管理し、顧客企業システム５を認証し、顧客企業システム５が接続可能なホテル予約システム１１及び交通機関予約システム１２に接続し、接続された予約システムから予約可能な商品の情報を取得し、顧客企業システム５に送信する。詳述すると、顧客企業システム５からの接続を一括して受け持ち（１０１）、セション管理、認証、ホテル予約システム１１及び交通機関予約システム１２への接続、レスポンス書式のフォーマット等を行う。又、アカウント記憶装置３５２に記録されたアカウントデータを取得し、全てメモリ内に保持する。これらのデータは起動時にロードされ、基幹管理手段２６からのデータ更新通知（１０５）によって、データベース管理手段３５０から再ロードされる（１０３）。スイッチング手段２０が顧客企業システム５から受け取ったリクエストは、パース（解読）されて、予約検索リクエストであれば、所望のホテル予約システム１１及び／或いは交通機関予約システム１２に（１０２）、管理者機能へのリクエストであれば、ＡＰＩ２９を介して基幹管理手段２６へ渡される（１０６）。ホテル予約システム１１へ接続する場合はＡＰＩ１３を介して、交通機関予約システム１２へ接続する場合はＡＰＩ１４を介して、基幹管理手段２６へ接続する場合は、ＡＰＩ２９を介して或いはＡＰＩ２９を介さずに接続される。予約情報や課金単位になるトランザクション数は、データベース管理手段３５０を介して共通ＤＢサーバ６へ書き出される（１０３）。運用ログは、ログ管理手段２５０へと渡される（１０４）。
【００６８】
基幹管理手段２６は、アカウント記憶装置３５２に記録された、顧客企業システム５の認証データ、顧客企業システム５がホテル予約システム１１及び交通機関予約システム１２に接続する認証データのマッピング情報、顧客企業システム５のユーザの属性に従って決定される接続可能なホテル予約システム１１及び交通機関予約システム１２、予約記憶装置３５４に記録された商品の予約に関する情報、顧客企業システムの接続に関する情報のうち、少なくとも一つを管理する。即ち、基幹管理手段２６は、スイッチング手段２０から取得された情報と、管理端末３、４から入力された情報とに基づいて、共通ＤＢサーバ６の管理を主に行う手段である。詳述すると、アカウントデータ、予約履歴、システムアクセス数データを一括して管理し、ＡＰＩ２８を介して、管理端末３、４へ、管理機能を提供する（１０７）。共通ＤＢサーバ６に格納された上記データを、追加、変更、削除する（１０８）。スイッチング手段２０からの管理者用機能の呼び出しを受け取り、処理する。又、管理する共通ＤＢサーバ６のデータが追加、変更、削除されると、基幹管理手段２６に更新通知を送る。
【００６９】
ログ管理手段２５０は、管理サーバ２の管理者及び運用者が利用する運用ログを書き出す手段で、スイッチング手段２０からのログ書き込み要求を受けてログをログファイルに書き込む（１０４）。
【００７０】
各システム及びプロセス間のプロトコル及び文書形式は、様々な組み合わせが考えられる。
【００７１】
例えば、上記の１０１、１０２、１０６、１０７での通信の接続においては、ＯＳＩ参照モデルに対比すると、ネットワーク層及びトランスポート層の接続においてＴＣＰ／ＩＰのプロトコルが、セション層の接続においてＨＴＴＰのプロトコルが、プレゼンテーション層の接続においてＸＭＬの文書形式がそれぞれ用いられるのが好ましい。又、１０４の接続においては、トランスポート層の接続においてプロセス間通信のＵＤＰ（User Datagram Protocol）のプロトコルが用いられるのが好ましい。更に、１０５の接続においては、ネットワーク層及びトランスポート層の接続においてＴＣＰ／ＩＰのプロトコルが用いられるのが好ましい。
【００７２】
ここで、ＯＳＩ参照モデルとは、国際標準化機構（ＩＳＯ：International Organization for Standardization）により制定された、異機種間のデータ通信を実現するためのネットワーク構造の設計方針「ＯＳＩ（Open Systems Interconnection）」に基づき、コンピュータの持つべき通信機能を階層構造に分割したモデルのことである。
【００７３】
本発明の実施の形態において利用されるプロトコル及び文書形式は、この記載に拘束されるものではない。
【００７４】
図２は、図１で記載した本発明の電子商取引システムにおける各ハードウェア構成要素について、詳細に記述したシステム構成図である。
【００７５】
本発明の電子商取引システムは、サプライヤ予約システム１、管理サーバ２、顧客企業システム５を備える。ここでは、共通ＤＢサーバ６の機能を管理サーバ２が備えている場合について説明している。ここで、それぞれのシステム及びサーバは、ＬＡＮ、インターネット、回線交換による通信回線等を介して接続されている。この場合、サプライヤ予約システム１、管理サーバ２、顧客企業システム５は、モデム、ルータ、ダイアルアップルータ、プロキシサーバ、インターネット接続プロバイダのＰＰＰサーバ（ＰＰＰ（Point to Point Protocol）によって、電話回線によるダイアルアップを通じてインターネットに接続するサーバ）等を介して接続されるのが好ましい。
【００７６】
サプライヤ予約システム１は、顧客企業システム５に対してホテルや交通機関の予約を提供するシステムで、図１で示したホテル予約システム１１及び交通機関予約システム１２を備える。ホテル予約システム１１は、当該ホテルの予約に関する情報を格納した予約ＤＢ１５を、交通機関予約システム１２は、当該交通機関の予約に関する情報を格納した予約ＤＢ１６をそれぞれ備えている。ホテル予約システム１１はＡＰＩ１３を介して、交通機関予約システム１２はＡＰＩ１４を介して管理サーバ２に接続する。
【００７７】
顧客企業システム５は、ネット予約サーバ５１を備えている。ネット予約サーバ５１は、Javaライブラリ５２を介して、管理サーバ２に接続する。ネット予約サーバ５１には複数の端末が接続されており、それぞれ画面を備える。具体的には、顧客企業システム５に所属するユーザが予約を行う予約画面５３、ユーザが予約画面５３から直接に予約を行うことができない場合に、コールセンターのオペレータが予約を行うコールセンター（ＣＣ）用予約画面５４、ユーザを管理する管理者が利用する管理者画面５５等が挙げられる。又、ユーザ、コールセンターのオペレータ、管理者が処理を行える機能の権限を任意に設定することのが好ましい。
【００７８】
顧客企業システム５においては、既存のシステムである出張申請システム５９、経理システム５８、インハウスエージェントが管理しているツーリスト旅行システム５７と連携して、管理サーバ２に接続される。又、既存のシステムは、個人・部課認証データ５６を備えている。顧客企業システム５のユーザが出張を行う場合は、出張申請システム５９に対して、出張目的や、所属部課、上司の承認等が入力されるが、出張に係る予約を行う場合は、出張目的や所属部課などを提示する必要はなく、経理システム５８が出納管理を行うのに足りる情報（具体的には名前）のみ提示すれば良い。又、顧客企業システム５が提示する予約画面５３、コールセンター用予約画面５４、管理者画面５５は、出張申請システム５９が従来備えていた端末に表示すれば良い。
【００７９】
管理サーバ２は、図１で説明したように、スイッチング手段２０と、基幹管理手段２６を備えている。スイッチング手段２０は、サプライヤ予約システム１からの接続を受付ける接続モジュール２３ａ、２３ｂ、２３ｃ…を備えている。この接続モジュールは、接続制御部２１によって制御され、接続がなされると、メッセージ解析部２２において、接続により受信したメッセージの解析を行う。ここで解析されたメッセージは、ＡＰＩ２９、契約記憶装置３５３、予約記憶装置３５４を介して 基幹管理手段２６に送信される。
【００８０】
管理サーバ２が顧客企業システム５からの接続を受付けるときは、ＡＰＩ２７、接続制御部２１、メッセージ解析部２２を介して基幹管理手段２６に接続される。管理サーバ２は、ＡＰＩ２８を介して管理端末３が備える管理画面３１、管理端末４が備える管理画面４１から、管理される。
【００８１】
本発明の電子商取引システムにおいては、サプライヤ予約システム１のホテル予約システム及び交通機関予約システム１２から、実際に予約したユーザがそのホテル及び交通機関を利用したかどうかという実績に基づいて、移動実績・請求情報１７の情報を算出することができる。更に、この移動実績・請求情報１７の情報は、顧客企業システム５のツーリスト旅行システム５７に送信され、ツーリスト旅行システム５７は、個人申請システム５９や個人・部課データ５６を参照して、請求先の経理システム５８にその請求を振り分ける。これにより、顧客企業システム５は、実績データに基づいた請求を行うことができるので、キャンセルや変更に伴って請求データを変更することがなく、請求を簡略化し、かつ、確実に行うことができる。
【００８２】
勿論、管理サーバ２で予約に伴った移動実績・請求情報を管理し、顧客企業システム５に請求しても構わない。更に、顧客企業システム５の出張管理における交通機関、ホテルの予約に関する全ての情報を管理サーバ２で管理し、役務の予約のアウトソーシングの形態を取ることも可能である。
【００８３】
図３は、本発明の第１の実施の形態に係る電子商取引システムにおける出張管理のフローチャートを示した図である。
【００８４】
まず、ステップＳ１０１において、顧客企業システム５に所属するユーザの出張が決定した場合、ステップＳ１０２において、予約画面５３を介して出張申請システム５９に対して出張の申請を行う。これにより、管理サーバ２を介してホテル予約システム１１及び交通機関予約システム１２に接続し、ホテル及び交通機関の予約を行い、ステップＳ１０３において、ホテル予約システム１１及び交通機関予約システム１２に予約情報が通知される。このときに、予約に関する情報は、管理サーバ２、ホテル予約システム１１及び交通機関予約システム１２に格納されるので、その予約の確認となるチケットはユーザに配布されなくても良い。
【００８５】
ユーザは、ステップＳ１０４において、交通機関の窓口やホテルのフロントで、顧客企業システム５のユーザであることを認証することにより、その役務を受けることができる。更に、ステップＳ１０５において、ホテル予約システム１１や交通機関予約システム１２が提供した役務に基づいて、移動実績・請求情報１７を作成し、顧客企業システム５に対して、出張精算を行うことができる。
【００８６】
このように、図３で示された本発明における出張管理は、図３０に示された従来の出張管理と比べて処理が少なく、又、手作業による処理を含まないので出張のコストを削減することができる。
【００８７】
即ち、本発明における管理サーバ２（電子商取引管理サーバ）は、国内外のホテル、国内外の交通機関予約システムなど、トラベル全般の予約システムをまとめ、顧客に対しての一環したサービスを提供する。
【００８８】
具体的な管理サーバ２の機能及びそれに対する効果を以下に記載する。
【００８９】
管理サーバ２は、顧客企業システム５及びサプライヤ予約システム１に対して、検索、予約、管理機能などを提供するＡＰＩを共通の仕様で定義する。これにより、画面イメージと検索・予約処理を分割することにより、多くのサイトに予約機能を提供することができる。又、国内ホテル、海外ホテル、国内交通機関、海外交通機関の予約サービスを一貫した接続方法、プロトコル、メッセージフォーマットで提供することができる。
【００９０】
更に管理サーバ２は、顧客企業システム５の管理、契約内容を管理するデータとロジックを実装する。これにより、多くの企業に対してサービスをするにあたり、予約情報、アクセス数、統計情報を、企業毎に管理することができる。又、顧客企業システム５は、企業のシステムに限らず、複数のメンバーが集まったサイトでも構わない。
【００９１】
更に管理サーバ２は、顧客企業システム５とサプライヤ予約システム１を結ぶセションを管理する。これにより、顧客企業システム５とサプライヤ予約システム１がそれぞれ複数あった場合でも、リクエストとレスポンスはどの顧客企業システム５から来てどのサプライヤ予約システム１に返すのか、或いは、どのサプライヤ予約システム１からきてどの顧客企業システム５に返すのか、を管理することができる。
【００９２】
更に管理サーバ２は、各予約システム毎に異なるログイン方法、異なる計算方法で返ってくる料金、セション管理方法や日付等のメッセージフォーマットを、管理サーバ２が提供するＡＰＩに基づいた形式で変換する。これにより、各予約システム毎にデータの仕様が異なり、サービスの仕様が異なっても、均一なサービスを提供することができる。
【００９３】
更に管理サーバ２は、トラベルシステム全体の情報を管理するために、システム管理者、オペレータが利用するＡＰＩを定義する。これにより、予約システム利用料を企業毎に算出することができる。更に、顧客企業システム５が接続できる予約システムの契約を、その都度変更することができる。即ち、新規契約企業、サイトをシステム停止や大きな移行作業を行うことなく追加することができる。
【００９４】
又、サプライヤ予約システム１及び顧客企業システム５が提供する機能に従って、管理サーバ２が提供するＡＰＩが作成され、サプライヤ予約システム１及び顧客企業システム５は、そのＡＰＩを実装する。
【００９５】
又、管理サーバ２は、商品が予約、キャンセル、変更されるたびに、その予約情報の更新を行っている。従って、仮にサプライヤ予約システムから不正な請求がされたとしても、管理サーバ２が提示した予約情報を付き合わせて、確認の取れたものだけを支払えば良い。顧客企業システム５からサプライヤ予約システム１への接続窓口を、管理サーバ２に統合したため、管理サーバ２が管理している予約情報に基づいて請求を確認すれば足りる。これにより、従来、自社が備える出張システムと請求された金額との突き合わせに多大な時間（コスト）を要していたが、本システムによれば、容易に突き合わせができるため、コストの削減を行うことができる。
【００９６】
（第２の実施の形態）
本発明の第２の実施の形態においては、第１の実施の形態で説明した管理サーバ２について詳細に説明する。
【００９７】
図４は、本発明の第２の実施の形態に係る管理サーバ２の機能ブロック図である。管理サーバ２は、主にスイッチング手段２０、基幹管理手段２６、ログ管理手段２５０を備えており、共通ＤＢサーバ６、顧客企業システム５、サプライヤ予約システム１、管理端末３、４が接続されている。
【００９８】
スイッチング手段２０は、ＡＳＰ接続管理部２０１、ログ記録部２０２、要求解読部２０３、要求処理部２０４、ＡＣＬ（Access Control）部２０５、認証部２０６、ＩＤ変換部２０７、接続サプライヤ判断部２０８、メモリデータ管理部２０９、メモリ２１０、更新通知処理部２１１、ＤＢ接続部２１２、予約情報記録／検索部２１４、システムアクセス数記録／検索部２１５、プロトコル変換部２１６、サプライヤ接続管理部２１７、応答処理解読部２１８、応答処理部２１９、セション管理部２２０、トランザクション管理部２２１、データ変換／整形部２２２を備える。
【００９９】
ＡＳＰ接続管理部２０１は、顧客企業システム５からのリクエストを、決まったＵＲＬ（ＩＰアドレス或いはＦＱＤＮ、ポート番号、サービス名）受付け、リプライを返す。セション番号やトランザクション番号を認識したり、付与する。
【０１００】
ここで、ＦＱＤＮとは、Fully Qualified Domain Nameのことで、ＴＣＰ／ＩＰによるネットワーク上で、ドメイン名・サブドメイン名・ホスト名を省略せずに全て指定した記述形式のことである。
【０１０１】
ログ記録部２０２は、ログ管理手段２５０とコネクションを確立し、運用ログをログ管理手段２５０へ送信する。
【０１０２】
要求解読部２０３は、顧客企業システム５側からのリクエストをパースし、管理サーバ２内部で処理する情報と、サプライヤ予約システム１又は管理サーバ２側へ送る機能を分解する。
【０１０３】
要求処理部２０４は、ログイン認証や、サプライヤ予約システム１への接続時に認証したアカウントと、サプライヤ予約システム１への接続アカウントのマッピングし、接続先のサプライヤ予約システム１がその顧客企業システム５から、利用できる契約がなされているかの判断などを処理する。又、管理サーバ２やサプライヤ予約システム１の各予約システムの、どこに対してリクエストを出すのかを判断する。
【０１０４】
ＡＣＬ部２０５は、スイッチング手段２０のメモリ２１０上に保持された、顧客企業毎のアクセスコントロール情報（ＩＰアドレスやドメイン）を参照して、アクセスの許可・拒否を判断する。
【０１０５】
認証部２０６は、スイッチング手段２０のメモリ２１０上に保持された、顧客企業のアカウント情報を参照して、顧客企業からのリクエストに含まれるアカウント情報に対する認証許可・拒否を判断する。ここで、顧客企業システム５毎に認証がされても良いし、顧客企業システム５の従業員（ユーザ）毎に認証されても良い。又、更に、承認された出張に関する予約であるか、即ちその費用を顧客企業に請求して良いかどうかについて認証を行っても良い。
【０１０６】
ＩＤ変換部２０７は、スイッチング手段２０のメモリ２１０上に保持された、顧客企業のアカウント情報（企業コード）とサプライヤ予約システム１の接続アカウントのマッピング情報を参照して、サプライヤ予約システム１へ接続時に使用するアカウントを選択する。認証機構（ログイン処理）の不要なサプライヤ予約システム１に対してはこの処理は行われない。
【０１０７】
接続サプライヤ判断部２０８は、スイッチング手段２０のメモリ２１０上に保持された、顧客企業コードと利用許可サプライヤ予約システム１とのマッピング情報を参照して、接続先のサプライヤ予約システム１を使用させても良いかを判断する。ここでは、顧客企業システム５毎に判断されるが、更に、顧客企業システム５に属するユーザ毎に判断がなされても良い。
【０１０８】
更新通知処理部２１１は、基幹管理手段２６とのコネクションを確立し、基幹管理手段２６からの更新通知を受信する。
【０１０９】
ＤＢ接続部２１２は、データベース管理手段３５０とコネクションを確立し、共通ＤＢサーバ６に対するクエリ要求を受付け、クエリを行う。
【０１１０】
予約情報記録／検索部２１４は、予約成立／キャンセル時に予約情報を共通ＤＢサーバ６の予約記憶装置３５４に書き込んだり、顧客企業の管理者向けの予約内容検索リクエスト時に予約記憶装置３５４から予約情報を検索する。
【０１１１】
システムアクセス数記録／検索部２１５は、アクセス数、トランザクション数、ログイン数などを共通ＤＢサーバ６のシステムアクセス数記憶装置３５５に書き込んだり、システムアクセス数記憶装置３５５から検索したりする。
【０１１２】
プロトコル変換部２１６は、サプライヤ予約システム１の各予約システムや基幹管理手段２６などの接続先に合わせて、リクエストを作成、或いは変換する。
【０１１３】
サプライヤ接続管理部２１７は、サプライヤ予約システム１や基幹管理手段２６にリクエストを送信し、レスポンスを受信する。サプライヤ予約システム１の各予約システムや基幹管理手段２６とのセションＩＤ、トランザクションＩＤを処理する。
【０１１４】
応答処理解読部２１８は、サプライヤ予約システム１の各予約システム、基幹管理手段２６からのレスポンスをパースする。
【０１１５】
応答処理部２１９は、サプライヤ予約システム１の各予約システム、基幹管理手段２６からのレスポンスの内容に応じて、予約情報を書き出すなどの処理を制御する。
【０１１６】
セション管理部２２０は、顧客企業システム５とＡＳＰ接続管理部２０１との間のセション管理を行い、同時にサプライヤ予約システム１の各予約システムとサプライヤ接続管理部２１７との間のセション管理を行う。又、ＡＳＰ接続管理部２０１とサプライヤ接続管理部２１７とのセション情報を対にして管理する。
【０１１７】
トランザクション管理部２２１は、顧客企業システム５とＡＳＰ接続管理部２０１の間のトランザクション管理を行い、同時にサプライヤ予約システム１の各予約システムとサプライヤ接続管理部２１７との間のトランザクション管理を行う。又、ＡＳＰ接続管理部２０１とサプライヤ接続管理部２１７とのトランザクション情報を対にして管理する。
【０１１８】
データ変換／整形部２２２は、スイッチング手段２０の内部、基幹管理手段２６、或いはサプライヤ予約システム１の各予約システムからのレスポンスを、顧客企業システム５に提供しているＡＰＩの仕様に合わせてデータ変換／整形する。
【０１１９】
メモリ２１０は、アクセスコントロール情報、アカウント情報、企業コードと接続BEとのアカウントマッピング情報、接続サプライヤ予約システム１の利用許可情報の各データを共通ＤＢサーバ６から受け取って保持しておくメモリ領域である。
【０１２０】
メモリデータ管理部２０９は、スイッチング手段２０中に保持するメモリ情報をＡＣＬ部２０５、認証部２０６、ＩＤ変換部２０７、接続サプライヤ判断部２０８へ提供する。更に、共通ＤＢサーバ６の更新通知を、更新通知処理部２１１から受け取って、ＤＢ接続部２１２を通じて再度メモリ上のデータを共通ＤＢサーバ６からロード（更新）する。又、共通ＤＢサーバ６からのデータ更新時には、メモリデータの参照要求はロックする。データ更新の単位、メモリリードロックの単位は、顧客企業システム５毎や全ての項目など複数のレベルがあり得る。
【０１２１】
ログ管理手段２５０は、ログ管理部２５１及びログデータ記憶装置２５２を備えている。ログデータ記憶装置２５２は、スイッチング手段２０の処理のログデータが格納されている。ログ管理部２５１は、スイッチング手段２０のログ記録部２０２からメッセージを受信し、ログデータ記憶装置２５２にそのメッセージをログデータ記憶装置２５２に格納する。
【０１２２】
基幹管理手段２６は、ＡＰＩ接続管理部３０１、要求解読部３０２、処理部３０３、更新通知送信部３０５、企業アカウント管理部３０６、予約情報管理部３０７、システムアクセス数管理部３０９、エンジン使用料管理部３１１、契約企業情報管理部３１２、管理者アカウント管理部３１３、管理サーバ管理者セション管理部３１４、変更履歴ログ書出部３１５、ログファイル３１６を備えている。
【０１２３】
ＡＰＩ接続管理部 ３０１は、管理端末３、４からのアクセス、スイッチング手段２０のサプライヤ接続管理部２１７からのリクエストを受付け、リプライを返す。
【０１２４】
要求解読部３０２は、リクエストデータをパースする。
【０１２５】
処理部３０３は、リクエストの内容(ＡＰＩ)に応じた機能を問い合わせ、レスポンスを作成する。
【０１２６】
変更通知送信部３０５は、スイッチング手段２０とコネクションを確立し、企業アカウント管理部３０６、契約企業情報管理部３１２からの変更通知を、スイッチング手段２０に送信する。
【０１２７】
企業アカウント管理部３０６は、企業アカウントの追加／変更/削除の処理を実装する。共通ＤＢサーバ６のアカウント記憶装置３５２中のデータが変更されると、変更通知送信部３０５へ変更があった旨を知らせる。
【０１２８】
予約情報管理部３０７は、処理部３０３からの要求に応じて、共通ＤＢサーバ６の予約記憶装置３５４に格納された予約履歴を用いて、予約件数や総予約金額計算などの業務ロジックを実装する。
【０１２９】
ＤＢ接続部３０８は、データベース管理手段３５０とコネクションを確立し、共通ＤＢサーバ６に対するクエリ要求を受付け、クエリを行う。
【０１３０】
システムアクセス数管理部３０９は、処理部３０３からの要求に応じて、共通ＤＢサーバ６のシステムアクセス数記憶装置３５５に格納されているアクセス数を元に、ある期間のトランザクション数出力などの業務ロジックを実装する。
【０１３１】
エンジン使用料管理部３１０は、処理部３０３からの要求に応じて、予約情報管理部３０７からの予約数データを利用して、エンジン利用料の業務ロジックを実装し、結果を処理部３０３へと返す。
【０１３２】
契約企業情報管理部 ３１２は、契約企業の契約情報、担当者情報、業態などの契約企業情報を登録、変更、削除する処理を行う。
【０１３３】
管理者アカウント管理部 ３１３は、管理サーバ２の管理者及び運用者のアカウントの認証を行う。ここでは図示しないが、管理者及び運用者のアカウント及びパスワードを格納した記憶装置を備えるのは勿論である。
【０１３４】
ログファイル３１６は、管理サーバ２の管理者及び運用者が、契約企業情報などを変更した場合に、誰がどの操作を行ったのかを記録するログファイルである。
【０１３５】
変更履歴ログ書出部３１５は、管理サーバ２の管理者及び運用者が、内部状態を変更した場合に記録するログファイル３１６を書き出す。
【０１３６】
管理サーバ管理者セション管理部 ３１４は、変更履歴ログ書出部３１５によってログファイル（変更履歴ログ）３１６を書き出すときに、処理を実行している管理者を識別するために利用するセションを管理する。
【０１３７】
共通ＤＢサーバ６は、管理サーバ２が更新及び参照を行うデータベースの管理を行う。共通ＤＢサーバ６は、データベース管理手段３５０を備えている。
【０１３８】
データベース管理手段３５０は、ＤＢＭＳ３５１と、アカウント記憶装置３５２、契約記憶装置３５３、予約記憶装置３５４、システムアクセス数記憶装置３５５を備えている。
【０１３９】
ＤＢＭＳ（DataBase Management System）３５１は、共有データとしてのデータベースを管理し、データに対するアクセス要求に応えるソフトウェアである。
【０１４０】
ＤＢＭＳは、データの形式や利用手順を標準化し、特定のアプリケーションソフトから独立させることができる。
【０１４１】
アカウント記憶装置３５２には、顧客企業システム５の企業コード、アクセスＩＤ、パスワード等が記録されている。更に、企業に所属するユーザ毎にアクセスＩＤやパスワード等を設定しても良い。更に、顧客企業システム５が、サプライヤ予約システム１に提示する氏名やカード番号等を設定しても良い。更に、顧客企業システム５が、接続するサプライヤ予約システム１を限定しても良い。この場合、出張先の地域によって限定をしても構わない。これにより、顧客企業システム５は、例えばあるサプライヤ予約システム１に対して大量の発注を行うことにより、そのサプライヤ予約システム１の顧客企業システム５に対する価格を下げることもできる。又、顧客企業システム５に属する出張するユーザ或いはユーザの属性に従って、提示するホテルや交通機関を決定しても良い。具体的には、企業の役員には、新幹線のグリーン車を利用を許可したり、一泊２万円以上のホテルの利用を許可することができる。
【０１４２】
契約記憶装置３５３は、管理サーバ２が接続を受ける顧客企業システム５や、管理サーバ２が接続をするサプライヤ予約システム１の、企業名、ホテル名、交通機関名、住所、電話番号、担当者名等が記録されている。
【０１４３】
予約記憶装置３５４は、予約数、キャンセル数、金額などが記録されている。
【０１４４】
これにより、管理サーバ２が、顧客企業システム５に対して請求金額を提示することができる。更に、予約したホテル或いは交通機関の日付、指定便、ホテル名、人数、ランクなどを記録することにより、予約内容についても顧客企業システム５に対して請求金額を提示することができる。
【０１４５】
システムアクセス数記憶装置３５５は、顧客企業システム５が管理サーバ２に接続した回数及び時間、更にサプライヤ予約システム１に接続した回数及び時間、又、各接続におけるトラフィック量などが記録されている。これにより、管理サーバ２は、顧客企業システム５、サプライヤ予約システム１に対して、接続に対して課金を行うことができる。
【０１４６】
図５は、第２の実施の形態における管理サーバ２の処理を示すフローチャートである。ここでは、管理サーバ２が顧客企業システム５から接続を依頼され、接続先であるサプライヤ予約システム１に接続する処理について説明する。
【０１４７】
まず、ステップＳ２０１において管理サーバ２は、ＡＳＰ接続管理部２０１を介して顧客企業システム５から接続の依頼を受ける。ここで依頼された接続は、ＡＣＬ部２０５によって、接続が許可されているか否かを判断する。許可されていない場合は、処理を終了する。ステップＳ２０２において接続が許可されている場合は、更に、認証部２０５によって、認証が許可されているか否かを判断する。許可されていない場合は、処理を終了する。
【０１４８】
次に、ステップＳ２０３において認証が許可されている場合、ステップＳ２０４において、ＩＤ変換部２０７によって、接続先となるサプライヤ予約システム１に適合するＩＤに変換し、ステップＳ２０５において、接続サプライヤ判断部２０８によって、サプライヤ予約システム１に接続が許可されているか否かを判断する。許可されていない場合は、処理を終了する。
【０１４９】
ステップＳ２０５において接続できるサプライヤ予約システム１だと判断された場合は、ステップＳ２０６において、要求処理部２０４によって、顧客企業サーバ５から受信したメッセージの処理を行い、ステップＳ２０７において、メッセージの指示に従ったサプライヤ予約システム１に接続を行う。このとき、セション管理部２２０によってセションが、トランザクション管理部２２１によってトランザクションが、それぞれ管理される。
【０１５０】
次に、サプライヤ予約システム１からの応答を受けると、ステップＳ２０８において、応答処理部２１９によって、応答処理を行う。ここで得られた応答処理は、ステップＳ２０９において、データ変換／整形部２２２によって、顧客企業システム５の仕様に従って、データ変換及び整形が行われる。
【０１５１】
最後に、ステップＳ２１０において、ステップＳ２０９で作成されたデータを、ＡＳＰ接続管理部２０１によって、顧客企業システム５に送信する。
【０１５２】
次に、本発明の第２の実施の形態における管理サーバ２のセション管理部２２０によるセション管理について説明する。このセション管理は、複数の顧客企業システム５と複数のサプライヤ予約システム１を多対多で接続をすることができ、一度に、複数のセションを管理することができる。
【０１５３】
スイッチング手段２０は、セションＩＤにより、リクエストに対するレスポンスを適切な相手に返す。又、セションＩＤによって、リクエストがどの企業のどのユーザから来たものであるかを判断し、企業毎、ユーザ毎の処理を適切に行う。
【０１５４】
スイッチング手段２０でのセションＩＤの管理単位は、顧客企業システム５が管理サーバ２にログインするログインＡＰＩ呼び出し毎である。顧客企業システム５から、企業コードと、ユーザＩＤとパスワードと共にログインＡＰＩの呼び出しリクエストが送信されると、それを受けたスイッチング手段２０は、ユーザ認証の後、ユーザに特有で一意に定められたセションＩＤを返す。
【０１５５】
セションＩＤの生存期間は、指定されたタイムアウトが起きるまでか、若しくは顧客企業システム５が管理サーバ２からログアウトするログアウトＡＰＩの呼び出しまでである。
【０１５６】
顧客企業システム５へのセションＩＤの発行は、スイッチング手段２０は、顧客企業システムに対して、ログインＡＰＩのレスポンスにセションＩＤを返す。
【０１５７】
ここで、図６を参照して、本発明の第２の実施の形態における管理サーバ２のセション管理部２２０によるセション管理について説明する。
【０１５８】
基幹管理手段２６は、スイッチング手段２０側のＡＰＩ２９においては、セション管理を行わない。よって、このポートに対する全ＡＰＩは、その都度必要なパラメータを全て指定するリクエストとなる。
【０１５９】
基幹管理手段２６は、管理サーバ２の管理者側のＡＰＩ２８においては、ログインＡＰＩ呼び出しのレスポンスにセションＩＤを発行する。
【０１６０】
交通機関予約システム１２は、交通機関予約システム１２のＡＰＩ１４のうち、ログインＡＰＩの呼び出し時に、スイッチング手段２０からセション番号を受け取り、このセション番号を利用してセション管理を行う。
【０１６１】
ホテル予約システム１３は、全てのＡＰＩ１３呼び出し時に、入力パラメータとしてスイッチング手段２０のセション番号を受け取る。
【０１６２】
上記のように、これら３つのシステムでは、セション管理をしないか、又はスイッチング手段２０のセッション番号をそのまま用いるため、スイッチング手段２０では特に契約企業側セッション番号と、ホテル予約システム１３及び交通機関予約システム１４側セション番号とのマッピングテーブルを管理する必要は、必ずしもない。
【０１６３】
ここでは、実施の形態の一つとして、交通機関予約システム１２は、ログインＡＰＩの呼び出し時にセション番号を受け取り、ホテル予約システム１３は、全てのＡＰＩを呼び出しとき入力パラメータとしてセション番号を受け取ると記載したが、この実施例に限られるものではない。セション番号の受け取り方は、サプライヤ予約システム１のセション管理方法に依存する。
【０１６４】
このように、管理サーバ２は、セション管理方法が異なるシステムでも、そのシステムに応じたセション管理を行うことにより、そのシステムの差異を吸収し、接続を可能にすることができる。
【０１６５】
次に、本発明の第２の実施の形態におけるトランザクション管理について説明する。
【０１６６】
管理サーバ２で接続されるサプライヤ予約システム１は、スイッチング手段２０が予約情報を管理サーバ２に接続された共通ＤＢサーバ６の予約記憶装置３５４に格納するにあたって、予約記憶装置３５４の予約情報と、サプライヤ予約システム１の予約ＤＢ１５、１６の予約情報の一貫性を保たせる必要がある。
【０１６７】
ここでは、サプライヤ予約システム１として、ホテル予約システム１１を用いた場合について説明する。
【０１６８】
ここで、スイッチング手段２０との２フェーズコミットのシステム図を図７（ａ）に、処理フローを示すフローチャート図７（ｂ）に図示する。
【０１６９】
まず、ステップＳ３０１において、図７（ａ）の顧客企業システム５がスイッチング手段２０に対して、ホテルの予約確定のリクエストを送信すると、ステップＳ３０２において、スイッチング手段２０は、顧客企業システム２０からのリクエストをメモリ２１０内に保持しつつ、ステップＳ３０３において、このリクエストをホテル予約システム１１へ渡す。これにより、予約が確定される。
【０１７０】
次に、ホテル予約システム１１は、ステップＳ３０４において、予約ＤＢ１５に対して、データ更新処理を行い、このトランザクション処理が成功したことを確認し、その結果を確定（コミット）する。コミットをすると、ステップＳ３０５において、予約ＤＢ１５から更新結果が成功したか或いは失敗したかが返る。
【０１７１】
ホテル予約システム１１は、ステップＳ３０６において、その結果をスイッチング手段２０に返す。
【０１７２】
ステップＳ３０７において、ステップＳ３０４におけるホテル予約システム１１の予約ＤＢ１５の更新が失敗していた場合は、そのまま何もせず、顧客企業システム５へ、失敗レスポンスを返す。即ち、このトランザクションの結果は予約失敗となり、ステップＳ３１２において、スイッチング手段２０は、予約失敗したことをレスポンスとして返す。
【０１７３】
ステップＳ３０４においてホテル予約システム１１の予約ＤＢ１５の更新が成功した場合は、ステップＳ３０８において、共通ＤＢサーバ６の予約記憶装置３５４の更新を行う。ステップＳ３０８における予約記憶装置３５４の更新が成功しなかった場合は、ステップＳ３０９において、予約記憶装置３５４に対して再度の書き込みとコミットを試行する。最終的に予約記憶装置３５４の更新が成功した場合は、ステップＳ３１０において、スイッチング手段２０は、顧客企業システム５に対してホテルの予約が完了したことをレスポンスとして返す。
【０１７４】
ステップＳ３０９において、共通ＤＢサーバ６の更新が最終的に失敗した場合は、ステップＳ３１１において、異常終了となり、予約記憶装置３５４と予約ＤＢ１５との間で不整合が発生する。この場合、予約ＤＢ１５に対してロールバック（更新取消）を行い、顧客企業システム５に対しては、予約失敗したことをレスポンスとして返す。又、予約記憶装置３５４に格納すべき予約情報をエラーログに書き込み、顧客企業システム５に対しては、予約成功したことをレスポンスとして返しても良い。この場合、予約記憶装置３５４と予約ＤＢ１５は不整合のままなので、このエラーログを参照して、管理サーバ２の管理者及び運用者によって、この不整合が修正されなければならない。
【０１７５】
上述したように、第２の実施の形態においては、役務を予約する場合について説明したが、予約をキャンセルする場合にも、正当な処理がなされるのは勿論のことである。
【０１７６】
次に、図８乃至図１５を参照して、管理サーバ２或いは顧客企業システム５が、ユーザに提示している画面について説明する。ここでは、顧客企業システム５を利用しているユーザが、業務の一つである出張申請を行い、そのときに交通機関のチケットを手配する場合について説明する。
【０１７７】
図８は、顧客企業システム５が備えている、ユーザの情報を管理する画面群である。
【０１７８】
まず、図８（ａ）に示した画面は、ユーザ（従業員）の情報を得るべくログインさせるため、ユーザに従業員番号とパスワードを入力させる画面である。入力されたパスワードが顧客企業システム５内に保存されたパスワードと一致すると、図８（ｂ）に示した画面を参照する。ここで、ユーザに従業員番号とパスワードを入力させなくても、キャッシュ情報や端末固有情報等からユーザを特定しても構わない。
【０１７９】
次に、図８（ｂ）に示した画面において、ユーザが操作できる業務（出退勤管理、業務報告、出張申請、予約一覧表示等）等に対応したボタンの一覧を、表示する。ここで、「出退勤管理」ボタンがクリックされると、ユーザの過去の出退勤の結果、又、休みの予定等を入力することができる。「業務報告」ボタンがクリックされると、上司などに現在携わっている業務について報告を行うことができる。「出張申請」ボタンＢ１０１がクリックされると、上司に出張することを申請して許可をもらうことができる。「予約一覧表示」ボタンＢ１０４がクリックされると、ユーザが顧客企業システム５を介して予約した商品の一覧を表示することができる。具体的には、「出張申請」のときに予約した、交通機関及びホテルの予約内容を参照することができる。ここでは、文具などの消耗品や、本の予約を含めても良い。
【０１８０】
ここで、本発明の第２の実施の形態においては、ユーザが出張申請を行うので、「出張申請」ボタンＢ１０１をクリックすると、図８（ｃ）に示した画面である出張申請画面を表示する。
【０１８１】
図８（ｃ）の出張申請画面において、出張の期間、出張先、目的等、出張に関する情報を入力させる。更に、この出張の経費を負担する部課名を入力させても良い。更に、出張申請画面の入力時は、上司の承認が得られていないので、上司の承認が「否」にチェックされているが、出張申請が完了し、上司の承認が得られれば、上司の承認が「可」となる。これにより、出張の経費を、会社（或いは、出張の経費を負担する部課名が記されていた場合はその部課）に負担させることができる。
【０１８２】
更に、図８（ｃ）の出張申請画面において、交通機関やホテルの予約が必要な場合は、「チケット手配」ボタンＢ１０２或いは「ホテル手配」ボタンがクリックされる。この例においては、交通機関のチケットを手配するので、「チケット手配」ボタンＢ１０２がクリックされる。
【０１８３】
図９乃至図１４は、チケット手配を行う画面である。ここで表示されている時刻表、予約に関する情報、ユーザに関する情報等は、管理サーバ２からＡＰＩ２７を介して取得されたもので、その情報を元に、顧客企業システム５が画面に表示している。又、「お知らせ」や「ヘルプ」等、動的にデータが変更しないものに関しては、顧客企業システム５の内部で保存して表示するのが好ましい。
【０１８４】
又、チケット手配に関する画面遷移等は、顧客企業システム５の業務フロー、画面イメージに適合した形で作成されるのが好ましいので、顧客企業システム５の仕様に基づいて作成されるのが良い。
【０１８５】
図９に示した画面は、図８（ｃ）に示した画面において「チケット手配」ボタンＢ１０２がクリックされて、最初に表示する画面である。この画面では、図８（ｃ）に示した画面で入力された情報が、なるべく既に入力された状態で表示するのが好ましい。例えば、出張の出発日に交通機関の予約を行う場合が多いので、最初に出張の出発日を入力しておく。又、利用する航空会社をチェックボックスで選択できるようにしていても良い。更に、ここに表示する航空会社は、管理サーバの契約記憶装置３５３で契約している航空会社に限られても良い。
【０１８６】
図９に示した画面において、チケットを予約する航空機の条件を入力させて、「検索」ボタンＢ１０３をクリックさせると、図１０に示した画面において、検索条件に該当した交通機関の空席状況を一覧で表示する。図１０に示した画面において、検索条件として、搭乗日、出発地、到着地を表示する。更に、それぞれの検索結果に対応づけて、航空会社、便名、出発時刻、到着時刻、機種、空席状況、利用運賃、「予約する」ボタンＢ１０５ａ、Ｂ１０５ｂ、Ｂ１０５ｃ…を表示する。
【０１８７】
この「予約する」ボタンＢ１０５ａ、Ｂ１０５ｂ、Ｂ１０５ｃ…をユーザがクリックすると、予約処理を行い、図１１に示した画面を表示する。
【０１８８】
図１１に示した画面においては、ユーザが行った予約の確認事項を表示する。
【０１８９】
更に、予約時に座席を希望できる航空会社（この場合Ｂ社）の場合は、ここで、希望する座席を選択する。更に、交通機関を利用するユーザの、交通機関に対しての表示名（名前、固有番号等）も合わせて表示する。ここでは、企業が外に開示したくない、部署名、出張目的等の情報は一切表示しない。ここに表示された情報で正しければ、ユーザに「予約確定」ボタンＢ１０６をクリックさせる。
【０１９０】
その後、管理サーバ２は、予約情報を取得し、交通機関予約システム１２に対して、確認された交通機関の予約を行い、正常に予約完了した場合は、図１２に示す予約完了画面を表示する。更に、予約完了後に座席を指定できる航空会社（この場合Ａ社）に対して予約がなされた場合は、「事前に座席を指定する」ボタンＢ１０７をクリックさせることにより、座席を指定することができる。
【０１９１】
更に、図８（ｂ）或いは（ｃ）に示された画面において、「予約一覧表示」ボタンＢ１０４がクリックされると、図１３に示す画面を表示する。ここでは、ユーザが予約した役務を一覧表示する画面を表示する。この画面において、「予約取消」ボタンＢ１０８ａ、Ｂ１０８ｂがクリックされると、図１４に示す予約取消確認画面を表示する。ここで、「確定」ボタンＢ１０９がクリックされると、予約を取り消すため、管理サーバ２に送信され、管理サーバ２は、交通機関予約システム１２に対して予約を取り消す。
【０１９２】
このように、本発明の電子商取引システムが提供するＡＰＩによって、交通機関毎に異なるインタフェースを統合し、ユーザに一度に提示することができる。
【０１９３】
具体的には、接続先となるサプライヤ予約システム１の予約方法の違いを吸収し、同様の商品を扱い異なるサプライヤ予約システム１（所謂「同業他社」）が扱う商品を、一覧で提示し、それぞれのサプライヤ予約システム１が提供する商品を比較することができる。
【０１９４】
又、第２の実施の形態においては、ブラウザを介してシステムに接続する場合について説明したが、ブラウザでなく、一般的な画面を介してシステムに接続しても構わない。
【０１９５】
（第３の実施の形態）
本発明の第３の実施の形態について、図１５を参照しながら説明する。図１５は、本実施形態に係る電子商取引システムを示す概略構成図である。本実施形態に係る電子商取引システムは、企業の予約システム１０１０、サーバ装置（電子商取引管理サーバ）１０２０、複数のチケット供給者（航空会社）の予約システム１０３０から構成される。
【０１９６】
本実施形態では、この電子商取引システムによって、企業（ユーザ群）におけるユーザ（従業員）は、自身の従業員ＩＤを用いて、一つ又は複数のチケット供給者（航空会社）が供給するチケット検索を行う。本実施形態では、企業（ユーザ群）の従業員（ユーザ）が、複数の航空会社（チケット供給者）に対して、航空券（チケット）の予約情報を検索する場合を例として説明する。
【０１９７】
企業における従業員がチケット検索のために使用する企業の予約システム１０１０は、ユーザＩＤ及び検索条件情報を含む第１の検索要求データ１５０１を送信する検索要求データ送信手段１０１１と、検索結果情報１５０２を受信する検索結果情報受信手段１０１２とを備える。検索要求データ送信手段１０１１及び検索結果情報受信手段１０１２は、企業における汎用パソコンに搭載されたＷＷＷブラウザ等で構成される。
【０１９８】
図１６に、第１の検索要求データ１５０１の一例を示す。第１の検索要求データ１５０１は、「検索要求ＩＤ」、「ユーザＩＤ」、及び、検索条件情報としての「検索対象チケット供給者ＩＤ」と「検索対象チケット情報」等を含む。本実施形態では、「検索要求ＩＤ」には、チケット検索を行う従業員が入力する出張番号が挿入され、「ユーザＩＤ」には、該従業員の従業員ＩＤ及び該従業員が属する企業の企業コード等が挿入され、「検索対象チケット供給者」には、航空会社名が挿入される。又、「検索対象チケット情報」には、搭乗日、出発時刻、出発地、到着地等が挿入される。従業員ＩＤは、各企業が、従業員を識別するために独自に管理しているものを用いる。
【０１９９】
第１の検索要求データ１５０１は、任意の形式で良く、企業における汎用パソコンに搭載されたＷＷＷブラウザによってフォーム形式で送信されても良いし、企業の予約システム１０１０とサーバ装置１０２０との間の通信リンク上で送信されても良い。
【０２００】
図１７に、検索結果レコード１６０１及び検索結果情報１６０２の一例を示す。検索結果情報１６０２は、前記検索条件情報に合致するチケットについて複数の航空会社が生成した複数の検索結果レコード１６０１からなる。各検索結果レコード１６０１は、「検索要求ＩＤ」、「顧客ＩＤ」、「チケット供給者」、「チケット情報」等を含む。「チケット情報」としては、例えば、搭乗日、出発時刻、到着時刻、出発地、到着地、便名、機種、空席状況、料金等が含まれる。検索結果情報１６０２は、「検索要求ＩＤ」、「ユーザＩＤ」、「チケット供給者」及び「チケット情報」を含む。一つの検索情報１６０２が、複数の「チケット供給者」及び「チケット情報」を含んでも良い。
【０２０１】
企業の予約システム１０１０は、受信した検索結果情報１６０２に応じて、前記検索条件情報に合致するチケットを関連する情報と共に画面上に一覧表示する。
【０２０２】
本実施形態に係るサーバ装置１０２０は、ユーザＩＤと顧客ＩＤとを関連付ける関連付け部１０２１と、第１の検索要求データ１５０１を受信する検索要求データ受信部１０２２と、該第１の検索要求データ１５０１に応じて、第２の検索要求データ１５０２を生成し、該第２の検索要求データ１５０２の宛先のチケット供給者を選定し、該選定されたチケット供給者に該第２の検索要求データ１５０２を送信する検索要求データ送信部１０２３と、検索結果情報１６０２を前記ユーザに提示する検索結果情報提示部１０２４とを備える。検索要求データ受信部１０２２及び検索結果情報提示部１０２４は、ＷＷＷサーバ等で構成される。
【０２０３】
本実施形態において、サーバ装置１０２０が、企業グループの旅行代理店（インハウスエージェント）に設置されている場合を例として説明する。
【０２０４】
顧客ＩＤは、航空会社が、ユーザを識別するために独自に管理しているものを用いる。例えば、航空会社の利用状況に応じてサービスポイントを蓄積するための顧客毎に付与するアカウント番号を用いる。
【０２０５】
又、図１６に、第２の検索要求データ１５０２の一例を示す。第２の検索要求データ１５０２は、「検索要求ＩＤ」、「顧客ＩＤ」、及び、検索条件情報としての「検索対象チケット供給者ＩＤ」と「検索対象チケット情報」等を含む。本実施形態では、「顧客ＩＤ」には、第１の検索要求データ１５０１に含まれる「ユーザＩＤ」に関連付けられた、チケット検索を行うユーザ（従業員）を航空会社が識別するためのＩＤ及び該ユーザ（従業員）が属する企業の企業コード等が挿入され、「検索要求ＩＤ」、「検索対象チケット供給者」、「検索対象チケット情報」には、第１の検索要求データ１５０１に含まれる「検索要求ＩＤ」、「検索対象チケット供給者」、「検索対象チケット情報」が挿入される。第２の検索要求データ１５０２に含まれる「検索対象チケット供給者」及び「検索対象チケット情報」と、第１の検索要求データ１５０１に含まれる「検索対象チケット供給者」及び「検索対象チケット情報」は、異なる形式であっても良い。
【０２０６】
又、図１６に、前記関連付け部１０２１の一例を示す。関連付け部１０２１は、「ユーザＩＤ」と「検索対象チケット供給者」と「顧客ＩＤ」とを関連付けるものである。
【０２０７】
検索要求データ送信手段１０２３は、第１の検索要求データ１５０１に含まれる「ユーザＩＤ（企業コード及び従業員ＩＤ）」と「検索対象チケット供給者（航空会社名）」との組み合わせから、関連付け部１０２１を検索し、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定する。そして、この「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を含み、第１の検索要求データ１５０１に含まれる「検索対象チケット供給者（航空会社名）」及び「検索対象チケット情報（搭乗日、出発時刻、出発地、到着地等）」に応じた第２の検索要求データ１５０２を生成する。「検索対象チケット供給者」に複数の航空会社名が含まれている場合、「ユーザＩＤ（企業コード及び従業員ＩＤ）」と「検索対象チケット供給者（航空会社名）」との組み合わせ毎に「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定し、この「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」をそれぞれ含む複数の第２の検索要求データ１５０２を生成する。その後、第２の検索要求データ１５０２に含まれる「検索対象チケット供給者（航空会社名）」に基づいて、該第２の検索要求データ１５０２の宛先の航空会社を選定し、該第２の検索要求データ１５０２を、該選定された航空会社のチケット予約システム１０３０に送信する。
【０２０８】
例えば、図１６に示す例では、第１の検索要求データ１５０１において、「ユーザＩＤ＝００１」、「検索対象チケット供給者＝００１、００２」である。この場合、関連付け部２１を検索し、（ユーザＩＤ，検索対象チケット供給者）＝（００１，００１）及び（ユーザＩＤ，検索対象チケット供給者）＝（００１，００２）に対応する「顧客ＩＤ」を決定する。その結果に基づいて「顧客ＩＤ＝×××」を含む第２の検索要求データ１５０２と、「顧客ＩＤ＝○○○」を含む第２の検索要求データ１５０２とが生成される。
【０２０９】
検索結果情報提示手段１０２４は、各航空会社が生成した、複数の検索結果レコード１６０１を受信する。各検索結果レコード１６０１は、「検索要求ＩＤ」、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」、「チケット供給者（航空会社名）」、「チケット情報（搭乗日、出発時刻、到着時刻、出発地、到着地、便名、機種、空席状況、料金等）」を含む。そして、関連付け部１０２１を用いて、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」と「チケット供給者（航空会社名）」の組み合わせ毎に、対応する「ユーザＩＤ（企業コード及び従業員ＩＤ）」を決定し、各検索結果レコード１６０１の「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」をこの「ユーザＩＤ（企業コード及び従業員ＩＤ）」で置換し、新しい検索結果レコード１６０１ａを生成する。そして、同一の「検索要求ＩＤ」と「ユーザＩＤ」との組み合わせを有する検索結果レコード６０１ａを統合して、検索結果情報１６０２を生成し、該当する従業員の属する企業の予約システム１０１０に送信する。
【０２１０】
なお、第３の実施の形態管理機構により、検索結果レコード１６０１ａが、第１の検索要求データ１５０１に対応することが把握できる場合は、関連付け部１０２１を検索せずに、一時的に記憶しておいた第１の検索要求データ１５０１内の「ユーザＩＤ」で、検索結果レコード１６０１内の「顧客ＩＤ」を置換し、新しい検索結果レコード１６０１ａを生成しても良い。又、この場合、「検索要求ＩＤ」を有することなく、検索結果情報１６０２を生成することができるため、第１の検索要求データ１５０１、第２の検索要求データ１５０２、検索結果レコード１６０１、１６０１ａ及び検索結果情報１６０２に、「検索要求ＩＤ」を含まなくても良い。
【０２１１】
航空会社の予約システム１０３０は、第２の検索要求データ１５０２を受信する検索要求データ受信手段１０３１と、検索結果レコード１６０１を生成し、前記サーバ装置１０２０に送信する検索結果レコード送信手段１０３２を備える。
【０２１２】
航空会社は、第２の検索要求データ１５０２の「顧客ＩＤ」を用いて、独自の顧客ＤＢを検索し、座席の好みや、予約優先ランク、企業名などを調べた後、できるだけその条件に合った空席情報を検索したり、大口割引や年間割引などの契約があるかを調べたりした上で、空席情報及び料金等の「チケット情報」をサーバ装置１０２０に送信することもできる。
【０２１３】
旅行代理店におけるサーバ装置１０２０と企業における予約システム１０１０との通信は、専用線を用いたクローズドシステムで構成されることもあれば、インターネットを用いたオープンシステムで構成されることもある。後者の場合は、旅行代理店が仲介していることを明示するために、第２の検索要求データに１５０２に「旅行代理店ＩＤ」を付加することもできる。
【０２１４】
（第３の実施の形態に係る電子商取引システムの動作）
上記構成を有する電子商取引システムの動作は、以下の手順により実施することができる。図１８は、本実施形態に係る電子用取引システムの動作を示すタイムチャート図である。本実施形態に係る電子商取引システムによって、航空券、ホテル宿泊券、レンタカーチケット等、多岐に渡るチケット検索を行うことが可能であるが、本実施形態においては、航空券の検索の例について説明する。
【０２１５】
図１８に示すように、ステップＳ１１０１において、企業における従業員（ユーザ）が、企業の予約システム１０１０、例えば汎用パソコン上のＷＷＷブラウザを操作して、サーバ装置１０２０に接続（ログイン）する。ここでは、ＷＷＷブラウザを使用することを想定するが、本発明は、ＷＷＷブラウザを使用したものに限定されない。該サーバ装置１０２０は、企業グループの旅行代理店（インハウスエージェント）、企業内、航空会社側のいずれに設置されても良い。
【０２１６】
この際、該サーバ装置１０２０は、該従業員が、当該電子商取引システムの正規ユーザであることをパスワード等による認証手段を用いて確認することも可能である。
【０２１７】
ステップＳ１１０２において、サーバ装置１０２０は、チケットを検索するために必要なデータ項目の入力を従業員に促す「チケット検索条件入力画面」を、企業の予約システム１０１０のＷＷＷブラウザ上に提示する。「チケット検索条件入力画面」において入力するデータ項目は、旅行代理店のサーバ装置１０２０が独自に保存している情報から構成しても良いし、航空会社の予約システム１０３０に問い合わせて構成しても良い。例えば、従業員が、航空券検索を行うために、「チケット検索条件入力画面」上で入力するデータ項目としては、企業コード、従業員ＩＤ、航空会社名、出張番号、搭乗日、出発時刻、出発地、到着地等が挙げられる。
【０２１８】
ステップＳ１１０３において、従業員は、表示された「チケット検索条件入力画面」に従って、検索条件情報を指定する。
【０２１９】
ステップＳ１１０４において、企業の予約システム１０１０の検索要求データ送信手段１０１１が、入力されたデータ項目に応じて、「検索要求ＩＤ」、「ユーザＩＤ（企業コード及び従業員ＩＤ）」、「検索対象チケット供給者（航空会社名）」、「チケット情報」等を含む第１の検索要求データ１５０１をサーバ装置１０２０に送信し、サーバ装置１０２０の検索要求データ受信部１０２２が、該第１の検索要求データ１５０１を受信する。第１の検索要求データ１５０１は、任意の形式で良い。
【０２２０】
ステップＳ１１０５において、サーバ装置１０２０の検索要求データ送信部１０２３が、受信した第１の検索要求データ１５０１に含まれる「ユーザＩＤ（企業コード及び従業員ＩＤ）」と「検索対象チケット供給者（航空会社名）」との組み合わせに基づき、関連付け部１０２１を検索し、対応する「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定する。
【０２２１】
ステップＳ１１０６において、検索要求データ送信部１０２３は、「検索要求ＩＤ」、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」、「検索対象チケット供給者（航空会社名）」、「検索対象チケット情報（搭乗日、出発時刻、出発地、到着地等）」を含む第２の検索要求データ１５０２を生成し、「検索対象チケット供給者（航空会社名）」が示す航空会社の予約システム１０３０に送信し、航空会社の予約システム１０３０の検索要求データ受信手段１０３１が、該第２の検索要求データ１５０２を受信する。第２の検索要求データ１５０２に含まれる「検索対象チケット供給者」及び「検索対象チケット情報」と、第１の検索要求データ１５０１に含まれる「検索対象チケット供給者」及び「検索対象チケット情報」は、異なる形式であっても良い。
【０２２２】
第１の検索要求データ１５０１の「検索対象チケット供給者（航空会社名）」に複数の航空会社名が含まれている場合、航空会社毎に、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定し、それに応じて第２の検索要求データ１５０２を生成する。
【０２２３】
ステップＳ１１０７において、航空会社の予約システム１０３０が、それぞれ、受信した第２の検索要求データ１５０２に応じて、「検索要求ＩＤ」、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」、「チケット供給者（航空会社名）」、「チケット情報」を含む検索結果レコード１６０１を生成し、各航空会社の予約システム１０３０の検索結果レコード送信手段１０３２が、該検索結果レコード１６０１を、前記サーバ装置１０２０に送信し、前記サーバ装置１０２０の検索情報提示手段１０２４が、該検索結果レコード１６０１を受信する。
【０２２４】
ステップＳ１１０８において、検索情報提示手段１０２４は、各検索結果レコード１６０１に含まれる「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」と「チケット供給者（航空会社名）」の組み合わせから、関連付け部１０２１を検索し、対応する「ユーザＩＤ（企業コード及び従業員ＩＤ）」を決定し、該検索結果レコード１６０１の「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」をこの「ユーザＩＤ（企業コード及び従業員ＩＤ）」で置換し、新しい検索結果レコード１６０１ａを生成する。
【０２２５】
ステップＳ１１０９において、前記新しい検索結果レコード１６０１ａを、「検索要求ＩＤ」と「ユーザＩＤ」との組み合わせ毎に統合して、検索結果情報１６０２を生成し、該当する従業員の属する企業の予約システム１０１０に送信する。
【０２２６】
ステップＳ１１１０において、企業の予約システム１０の検索結果情報受信手段１０１２が、該検索結果情報１６０２を受信し、汎用パソコンの画面上に、その内容を一覧表示する。
【０２２７】
（第３の実施の形態に係る電子商取引システムによる作用及び効果）
本実施形態では、サーバ装置１０２０を設けたことにより、チケットレス方式でチケット供給者が企業の従業員にチケットを販売する電子商取引システムにおいて、企業が従業員を識別するための従業員ＩＤと、航空会社がユーザを識別するための顧客ＩＤを別々にすることができる。従って、企業が、従業員ＩＤ等の企業内情報を提供することなく、航空会社による従業員毎にカスタマイズされた検索結果を得ることができる。例えば、予め登録してある座席位置の好みをできるだけ優先して検索することができる。又、企業における従業員が、単一の従業員ＩＤを用いて、複数の航空会社にまたがってチケットの検索を行ったり、航空会社とホテル等を組にして、チケットの検索を行ったりすることができる。後者は、航空会社に空席情報を問い合わせ、ホテルに対して空き部屋情報を問い合わせ、両方が確保できる場合のみ予約したい場合などに有効である。従業員は、航空会社とホテルに登録したそれぞれの顧客ＩＤを入力する必要はなく、単一の従業員ＩＤで検索できるというメリットがある。更に、複数の航空会社と複数のホテルを同時に検索することも可能である。
【０２２８】
以上説明したように本発明の第３の実施の形態によれば、チケット供給者が、チケットレス方式で、企業のユーザにチケットを販売することができるため、旅行代理店にとって、チケットを発行し配布するコストを削減して収益を上げることができるというメリットが生じ、それによって、チケット供給者にとっても、旅行代理店に対して支払う手数料を従来より低くすることができるというメリットが生じる。
【０２２９】
つまり、本発明によれば、旅行代理店は、従来の発券手数料の代わりに、少なくとも、企業からのチケット申込をチケット供給者に紹介し、代金回収を行うことに対する販売手数料をチケット供給者から得る。この販売手数料は、本発明によって、企業がユーザを識別するためのユーザＩＤとチケット供給者がユーザを識別するための顧客ＩＤを、分離しつつ相互に関連付けられるようにすることによって、申込から精算までを自動化することができ、その結果、取次ぎ、チケット発券／配布、代金回収のコストを画期的に下げることによる付加価値への対価である。
【０２３０】
又、企業及びチケット供給者の双方が、独自に管理するＩＤを用いることができるため、企業にとっては、チケット供給者に企業機密情報を漏らすことなく、自社の経理システムと連携した自動精算処理が可能となるというメリットが生じ、チケット供給者にとっては、企業内情報の変更に追随する必要がなくなるというメリットがある。
【０２３１】
更に、企業にとっては、チケット管理システムの管理する顧客ＩＤを管理することなく、大口割引の適用を受けることができるというメリットが生じ、チケット購入者にとっては、企業単位で精算されるにもかかわらず、チケット供給者からユーザ毎に適したサービスの提供を受けることができるというメリットが生じる。
【０２３２】
（第４の実施の形態）
本発明の第４の実施の形態について図１９を参照しながら説明する。図１９は、本実施形態に係る電子商取引システムを示す概略構成図である。本実施形態に係る電子商取引システムは、企業の予約システム１０１０、サーバ装置１０２０、複数のチケット供給者（航空会社）の予約システム１０３０から構成される。
【０２３３】
本実施形態では、この電子商取引システムによって、ユーザ群（企業）におけるユーザ（従業員）が、自身の従業員ＩＤを用いて、チケット供給者が供給するチケットの申込を行う。本実施形態では、企業（ユーザ群）の従業員（ユーザ）が、航空会社（チケット供給者）に対して、航空券（チケット）の申込を行う場合を例に説明する。
【０２３４】
企業における従業員がチケット申込のために使用する企業の予約システム１０１０は、ユーザＩＤ及び申込チケット条件情報を含む第１の申込データを送信する申込データ送信手段１０１３と、申込結果データを受信する申込結果データ受信手段１０１４とを更に備える。申込データ送信手段１０１３及び申込結果データ受信手段１０１４は、企業における汎用パソコンに搭載されたＷＷＷブラウザ等で構成される。申込データ送信手段１０１３及び申込結果データ受信手段１０１４は、検索要求データ送信手段１０１１と検索結果情報受信手段１０１２と同一の汎用パソコンで構成されても良い。
【０２３５】
図２０に、第１の申込データ１９０１の一例を示す。第１の申込データ１９０１は、「申込ＩＤ」、「ユーザＩＤ」、及び、申込チケット情報として「申込対象チケット供給者ＩＤ」と「申込対象チケット情報」等を含む。本実施形態では、「申込ＩＤ」には、チケット申込を行う従業員が入力する出張番号が挿入され、「ユーザＩＤ」には、該従業員の従業員ＩＤ及び該従業員が属する企業の企業コード等が挿入され、「申込対象チケット供給者」には、航空会社名が挿入される。又、「申込対象チケット情報」には、搭乗日、便名、搭乗クラス等が挿入される。
【０２３６】
第１の申込データ１９０１は、任意の形式で良く、企業における汎用パソコンに搭載されたＷＷＷブラウザによってフォーム形式で送信されても良いし、企業の予約システム１０１０とサーバ装置１０２０との間の通信リンク上で送信されても良い。
【０２３７】
申込結果データ２００１は、「申込チケット情報」として、例えば、搭乗日、出発時刻、到着時刻、出発地、到着地、便名、機種、搭乗クラス、座席情報、料金等を含む。企業の予約システム１０は、受信した申込結果情報２００１に応じて、汎用パソコンの画面上に、その内容を表示する。
【０２３８】
本実施形態に係るサーバ装置１０２０は、第１の申込データ１９０１を受信する申込データ受信部１０２５と、該第１の申込データ１９０１に応じて、第２の申込データ１９０２を生成し、該第２の申込データ１９０１の宛先の航空会社を選定し、該選定された航空会社に該第２の申込データを送信する申込データ送信部１０２６と、申込結果データ２００１を前記ユーザに提示する申込結果データ提示部１０２７とを更に備える。申込データ受信部１０２５及び申込結果データ提示部１０２７は、ＷＷＷサーバ等で構成される。申込データ受信部１０２５及び申込結果データ提示部１０２７は、検索要求データ受信部１０２１と検索結果情報提示部１０２４と同一の汎用パソコンで構成されても良い。
【０２３９】
図２０に、第２の申込データ１９０２の一例を示す。第２の申込データ１９０２は、「申込ＩＤ」、「顧客ＩＤ」、及び、申込チケット情報としての「申込対象チケット供給者ＩＤ」と「申込対象チケット情報」等を含む。本実施形態では、「顧客ＩＤ」には、第１の申込データ１９０１に含まれる「ユーザＩＤ」に関連付けられた、チケット申込を行う従業員を航空会社が識別するＩＤ及び該従業員が属する企業の企業コード等が挿入され、「申込ＩＤ」、「申込対象チケット供給者」、「申込対象チケット情報」には、第１の申込データ１９０１に含まれる「申込ＩＤ」、「申込対象チケット供給者」、「申込対象チケット情報」が挿入される。第２の申込データ１９０２に含まれる「申込対象チケット供給者」及び「申込対象チケット情報」と、第１の申込データ１９０１に含まれる「申込対象チケット供給者」及び「申込対象チケット情報」は、異なる形式であっても良い。
【０２４０】
申込データ送信手段１０２６は、第１の申込データ１９０１に含まれる「ユーザＩＤ（企業コード及び従業員ＩＤ）」と「申込対象チケット供給者（航空会社名）」との組み合わせから、関連付け部１０２１を検索し、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定する。そして、この「顧客ＩＤ」を含み、第１の申込データ１９０１に含まれる「申込対象チケット供給者（航空会社名）」及び「申込対象チケット情報」に応じた第２の申込データ１９０２を生成する。その後、第２の申込データ１９０２に含まれる「申込対象チケット供給者（航空会社名）」に基づいて、該第２の申込データ１９０２の宛先の航空会社を選定し、該第２の申込データ１９０２を、該選定された航空会社のチケット予約システム１０３０に送信する。
【０２４１】
申込結果データ提示手段１０２７は、航空会社が生成した申込結果データ２００１を受信する。申込結果データ２００１は、「申込ＩＤ」、「顧客ＩＤ」、「チケット供給者（航空会社名）」、「申込チケット情報」を含む。そして、「顧客ＩＤ」と「チケット供給者（航空会社名）」の組み合わせによって、関連付け部１０２１を検索して、対応する「ユーザＩＤ」を決定し、申込結果データ２００１を、該「ユーザＩＤ」が示す従業員の属する企業の予約システム１０１０に送信する。送信する際に、申込結果データ２００１内の「顧客ＩＤ」を、該決定された「ユーザＩＤ」で置換する。
【０２４２】
なお、第３の実施の形態管理機構により、申込結果データ２００１が、第１の申込データ１９０１に対応することが把握できる場合は、関連付け部１０２１を検索せずに、一時的に記憶しておいた第１の申込データ１９０１内の「ユーザＩＤ」を用いても良い。又、この場合、「申込ＩＤ」を有することなく、申込結果データ２００１の送信先を決定することができるため、第１の申込データ１９０１、第２の申込データ１９０２、申込結果データ２００１に、「申込ＩＤ」を含まなくても良い。
【０２４３】
航空会社の予約システム１０３０は、第２の申込データ１９０２を受信する申込データ受信手段１０３３と、申込結果データ２００１を生成し、前記サーバ装置１０２０に送信する申込結果データ送信手段１０３４を備える。
【０２４４】
（第４の実施の形態に係る電子商取引システムの動作）
上記構成を有する電子商取引システムの動作は、以下の手順により実施することができる。図２１は、本実施形態に係る電子用取引システムの動作を示すタイムチャート図である。
【０２４５】
図２１に示すように、ステップＳ１２０１において、前記ステップＳ１１１０で表示された検索条件情報に合致するチケット（航空券）の一覧に応じて、若しくは、広告メールや出張指示メール等に含まれた検索結果情報に相当するデータ（例えばＵＲＬ）に応じて、企業における従業員が、購入したいチケット（航空券）を選択する。このとき、企業の予約システム１０１０は、「ユーザＩＤ（企業コード及び従業員ＩＤ）」を、ログイン時に従業員が入力した「ユーザＩＤ（企業コード及び従業員ＩＤ）」をクッキーなどの第３の実施の形態管理機構から取り出すか、チケット申込用の入力データ項目として明示的に従業員に再度入力を促すかして取得する。
【０２４６】
ステップＳ１２０２において、企業の予約システム１０１０の申込データ送信手段１０１３が、選択された航空券に係る情報及び入力されたデータ項目に応じて、「申込ＩＤ」、「ユーザＩＤ（企業コード及び従業員ＩＤ）」、「申込対象チケット供給者（航空会社名）」、「申込対象チケット情報」等を含む第１の申込データ１９０１をサーバ装置１０２０に送信し、サーバ装置１０２０の申込データ受信部１０２５が、該第１の申込データ１９０１を受信する。第１の申込データ１９０１は、任意の形式で良い。
【０２４７】
ステップＳ１２０３において、サーバ装置１０２０の申込データ送信部１０２６が、受信した第１の申込データ１９０１に含まれる「ユーザＩＤ（企業コード及び従業員ＩＤ）」と「申込対象チケット供給者（航空会社名）」との組み合わせに基づき、関連付け部１０２１を検索し、対応する「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定する。
【０２４８】
ステップＳ１２０４において、申込データ送信部１０２６は、「申込ＩＤ」、「顧客ＩＤ」、「申込対象チケット供給者（航空会社名）」、「申込対象チケット情報」等を含む第２の申込データ１９０２を生成し、「申込対象チケット供給者（航空会社名）」が示す航空会社の予約システム１０３０に送信し、該航空会社の予約システム１０３０の申込データ受信手段１０３３が、該第２の申込データ１９０２を受信する。第２の申込データ１９０２に含まれる「申込対象チケット供給者」及び「申込対象チケット情報」と、第１の申込データ１９０１に含まれる「申込対象チケット供給者」及び「申込対象チケット情報」は、異なる形式であっても良い。
【０２４９】
ステップＳ１２０５において、航空会社の予約システム１０３０の申込結果データ送信手段１０３４が、受信した第２の申込データ１９０２に応じて、「申込ＩＤ」、「顧客ＩＤ」、「チケット供給者（航空会社名）」、「申込チケット情報」等を含む申込結果データ２００１を生成し、該申込結果データ２００１を、前記サーバ装置１０２０に送信し、前記サーバ装置１０２０の申込結果データ提示部１０２７が、該申込結果データ２００１を受信する。
【０２５０】
ステップＳ１２０６において、申込結果データ提示部１０２７は、申込結果データ２００１に含まれる「顧客ＩＤ」と「チケット供給者（航空会社名）」の組み合わせに基づき、関連付け部１０２１を検索し、対応する「ユーザＩＤ」を決定し、該「ユーザＩＤ」が示すユーザが属する企業の予約システム１０１０に、該申込結果データ２００１を送信し、企業の予約システム１０１０の申込結果データ受信手段１０１４が、該申込結果データ２００１を受信する。
【０２５１】
ステップＳ１２０７において、企業の予約システム１０１０の申込結果データ受信手段１０１４が、受信した該申込結果データ２００１に応じて、ＷＷＷブラウザ上に、その内容を表示する。
【０２５２】
ステップＳ１２０８において、チケットの申込をした従業員は、空港、ホテル、或いはそれに代わる発券装置の設置場所等において、チケットの発券を受ける。その際に、正当な申込者であることを証明するために認証が必要である。本発明では、その具体的な方法は特に規定しない。例えば、特開平１１−３３９０７６号公報に開示されているようなＩＤカードを用いて、従業員ＩＤ及び企業コードを提示する方法、申込成立時に発行される乱数を提示する方法、申込成立時に携帯電話やＰＤＡなどの携帯型コンピュータに乱数などの認証情報を記憶させておき、発券時に、該携帯型コンピュータの画面上に表示したバーコードを読み取らせたり、接触や無線（Ｂｌｕｅｔｏｏｔｈなど）で認証データを直接転送したりする方法が考えられる。
【０２５３】
（第４の実施の形態に係る電子商取引システムによる作用及び効果）
本実施形態では、サーバ装置１０２０を設けたことにより、チケットレス方式でチケット供給者が企業の従業員にチケットを販売する電子商取引システムにおいて、企業が従業員を識別するための従業員ＩＤと、航空会社がユーザを識別するための顧客ＩＤを別々にすることができる。従って、企業が、従業員ＩＤ等の企業内情報を提供することなく、航空会社が、個人毎に適応したサービスを提供することができる。例えば、一定の利用実績があるユーザに対して座席のアップグレードを提供したりすることでユーザを惹きつけることも可能である。
【０２５４】
（第５の実施の形態）
本発明の第５の実施の形態について図２２を参照しながら説明する。図２２は、本実施形態に係る電子商取引システムを示す概略構成図である。本実施形態に係る電子商取引システムは、ユーザ群（企業）の予約システム１０１０、サーバ装置１０２０、複数のチケット供給者（航空会社）の予約システム１０３０、チケット供給者（航空会社）のチケット代金請求システム１０４０、企業の経理システム１０５０から構成される。
本実施形態では、この電子商取引システムによって、チケット供給者（航空会社）が、旅行代理店（インハウスエージェント）のサーバ装置１０２０を介して、ユーザ群（企業）に対してチケット代金の請求を行う。本実施形態では、チケット供給者（航空会社）が、月単位や週単位等の一定期間毎、或いは、チケットの販売時点毎に、旅行代理店（インハウスエージェント）にチケット代金を請求し、旅行代理店（インハウスエージェント）が、月単位や週単位等の一定期間毎、或いは、チケットの販売時点毎に、ユーザ群（企業）の経理システム１０５０と連動してチケット代金請求を行う場合を例として説明する。
航空会社が企業に対してチケット代金を請求するための航空会社のチケット代金請求システム１０４０は、企業の従業員に販売したチケットの情報を記憶するチケット販売情報記憶手段１０４１と、チケット販売情報に基づき第１の請求データを生成し送信する請求データ送信手段１０４２とを備える。チケット販売情報には、例えば、顧客ＩＤ、出張番号、出発日及び便名等を含む利用実績情報、利用料金、請求先情報等が含まれる。
第１の請求データ２１０１は、「請求データＩＤ」、「顧客ＩＤ」、「チケット供給者（航空会社名）」、「利用料金」等を含む。本実施形態において、「請求データＩＤ」には、チケット申込時に入力された出張番号が挿入される。第１の請求データ２１０１に含まれ得るデータ項目の一例を図２３に示す。
本実施形態に係るサーバ装置１０２０は、第１の請求データ２１０１を受信する請求データ受信部１０２８と、該第１の請求データ２００１に応じて、前記顧客ＩＤに関連付けられたユーザＩＤを含む第２の請求データ２１０２を生成し、前記ユーザＩＤに基づいて、該第２の請求データ２１０２の宛先の企業を選定し、該選定された企業に該第２の請求データ２１０２を送信する請求データ送信部１０２９とを更に備える。
企業の経理システム１０５０は、第２の請求データを受信する請求データ受信手段１０５１と、従業員ＩＤ毎の情報を記憶する従業員情報記憶手段１０５２とを備える。
（第５の実施の形態に係る電子商取引システムの動作）
上記構成を有する電子商取引システムの動作は、以下の手順により実施することができる。図２４は、本実施形態に係る電子用取引システムの動作を示すタイムチャート図である。
図２４に示すように、ステップＳ１３０１において、航空会社のチケット代金請求システム１０４０が、チケット販売情報記憶手段１０４１に記憶されたチケット販売情報に応じて、「顧客ＩＤ」毎に第１の請求データ２１０１を生成し、サーバ装置１０２０に送信し、サーバ装置１０２０の請求データ受信部１０２８が、該第１の請求データ２１０１を受信する。
航空会社のチケット代金請求システム１０４０は、前記第１の請求データ２１０１の生成及び送信を、月単位や週単位等の一定期間毎に、或いは、チケットの販売の時点毎に行うことができる。
ステップＳ１３０２において、第１の請求データ２１０１内の「顧客ＩＤ」と「チケット供給者（航空会社名）」の組み合わせに基づき、関連付け部１０２１を検索し、対応する「ユーザＩＤ」を決定する。
ステップＳ１３０３において、「ユーザＩＤ」をキーに、企業の経理システム１０５０の従業員情報記憶手段１０５２に記憶された「従業員情報」を獲得する。「従業員情報」には、例えば、当該従業員のチケット代金について経理処理を行う所属部課コード等が含まれる。
ステップＳ１３０４において、サーバ手段１０２０の請求データ送信部１０２９が、第 １の請求データ２１０１に応じて、「ユーザＩＤ」、「従業員情報」等を含む第２の請求データ２１０２を生成し、企業の経理システム１０５０に送信し、企業の経理システム１０５０の請求データ受信手段１０５１が、該第２の請求データ２１０２を受信する。
ステップＳ１３０５において、企業の経理システム１０５０は、受信した第２の請求データ２１０２に応じて、経理処理を行う。
（第５の実施の形態に係る電子商取引システムによる作用及び効果）
本実施形態では、サーバ装置１０２０を設けたことにより、チケットレス方式でチケット供給者が企業の従業員にチケットを販売する電子商取引システムにおいて、企業が従業員を識別するための従業員ＩＤと、航空会社がユーザを識別するための顧客ＩＤを別々にすることができる。従って、航空会社は、従業員ＩＤ等の企業内情報を意識することなく、自身の管理する顧客ＩＤを用いて、企業単位で一括してチケット代金を請求することができ、企業は、既存の経理システムを用いて経理処理を行うことができる。
（変更例１）
なお、前記サーバ装置１０２０の設置場所としては、図２５に示す３通りがある。
第１に、チケット供給者と企業の中間に位置する企業グループ内の旅行代理店（インハウスエージェント）に設置する場合がある。この構成は、本発明の基本形であり、上述したようなメリットがある。更に、企業グループ内では、比較的似た体系の従業員ＩＤが用いられることが多いので、該旅行代理店は、サーバ装置２０を構成しやすいというメリットもある。
第２に、企業に、サーバ装置１０２０を設置する場合がある。企業の外部に企業内情報が出ないので、企業グループとは関係のない旅行代理店を活用したり、チケット供給者と直接取引をしたりすることも可能である。ただし、組織別のきめ細かい精算処理は実現できない。
第３に、チケット供給者に、サーバ装置１０２０を設置する場合がある。この方法は、チケット供給者が、既存の予約システム４０では扱えないＩＤを扱えるようにすることが主目的となる。
（変更例２）
又、サーバ装置１０２０を用いることにより、従業員の選択肢を広げるだけでなく、従業員に特定のチケット供給者を利用するように強いることもできる。企業が、出張費等のコスト削減を主目的として、特定のチケット供給者と大口契約或いは年間契約を結び、それ以外の選択肢を使わなくすることにより低価格でチケットを供給してもらうという契約形態がある。このためには、従業員が、契約外のチケット供給者を指定した場合でも、まず所定のチケット供給者に対してチケット申込の可能性を問い合わせる必要がある。本発明のサーバ装置１０２０に、所定のチケット供給者が識別するための顧客ＩＤを、全従業員に対して登録しておき、チケット検索及び申込時に、その顧客ＩＤを優先して選択することで容易に実現できる。又、契約を別のチケット供給者に切り替えたい場合には、サーバ装置１０２０に新しい顧客ＩＤを登録したり、古い顧客ＩＤを抹消するなどの集中操作により、容易に切り替えることができる。
（変更例３）
更に、企業グループ内の旅行代理店（インハウスエージェント）を持たない企業に対して、同様のサービスを提供する契約法人型の旅行代理店にも、本発明を適用することができる。規模の小さい企業を多数集めて、大きな企業グループと同様のバーゲニングパワーを得てチケット供給者と割引交渉をすることが考えられる。更に、頻繁に旅行する個人を集めて、同様のサービスを提供することもできる。この場合は、個人ＩＤの漏洩防止よりも、複数のチケット供給者にまたがってチケットの検索・申込ができることが主なメリットとなる。
（その他の実施の形態）
上記のように、本発明第１乃至第５の実施の形態によって記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。
【０２５５】
本発明の実施の形態として、企業に所属するユーザが、出張における交通機関及びホテルを利用する役務を予約し、精算を行う場合について説明したが、本発明におけるユーザ及び役務はこれに限られない。例えば、ユーザは、個人でも構わないし、組合や企業に所属していても構わない。又、役務は、商品購入でも構わない。このように、あらゆる状況に対応することができる。
【０２５６】
又、本発明の実施の形態においては、ある顧客企業システム及びサプライヤ予約システムの運用をモデルとして、そのモデルに適合するように、管理サーバは機能している。しかし、管理サーバはその基本的な機能を変更することなく、顧客企業システム及びサプライヤ予約システムに対して備えられるＡＰＩを変更することにより、あらゆる顧客企業システム及びサプライヤ予約システムに対して適用が可能である。
【０２５７】
更に、本発明の実施の形態においては、全ての予約処理を、交通機関予約システムに問い合わせすることにより行ったが、要求の多い交通機関やホテルについては、管理サーバで適当な数の席数或いは部屋数を、予め保有していても構わない。その場合、ユーザからの予約の要求については、管理サーバが保有している席或いは部屋を表示しても良い。又、ホテル予約システムと交通機関予約システムは同一のシステム上に構築されていても構わない。具体的には、旅行代理店等が運営している、出張全般で必要とされる役務についての予約システムでも構わない。
【０２５８】
更に、本発明の実施の形態においては、管理サーバと共通ＤＢサーバをそれぞれ別のハードウェア構成上を持つと記載したが、同一のハードウェアに管理サーバと共通ＤＢサーバの機能を備えても良い。即ち、管理サーバに、データベース管理手段及びデータが記憶されている記憶装置を備えても良い。
【０２５９】
この様な、本発明はここでは記載していない様々な実施の形態等を含むことは勿論である。従って、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【０２６０】
【発明の効果】
本発明によれば、ユーザが、役務の予約を容易に行うことのできる電子商取引管理サーバ及び電子商取引管理方法を提供することができる。
【図面の簡単な説明】
【図１】 本発明の第１の実施の形態に係る電子商取引システムを示すシステム構成図である。
【図２】 図１で記載した本発明の第１の実施の形態に係る電子商取引システムにおける各ハードウェア構成要素について、詳細に記述したシステム構成図である。
【図３】 本発明の第１の実施の形態に係る電子商取引システムにおける出張管理のフローチャートを示した図である。
【図４】 本発明の第２の実施の形態に係る管理サーバの機能ブロック図である。
【図５】 本発明の第２の実施の形態における管理サーバの処理を示すフローチャートである。
【図６】 本発明の第２の実施の形態における管理サーバのセション管理部によるセション管理について説明する図である。
【図７】 本発明の第２の実施の形態における図７（ａ）は、スイッチング手段との２フェーズコミットのシステム図で、図７（ｂ）は処理フローを示すフローチャートである。
【図８】 本発明の第２の実施の形態における顧客企業システムが備えている、ユーザの情報を管理する画面群である。
【図９】 図８（ｃ）に示した画面において「チケット手配」ボタンＢ１０２がクリックされて、最初に表示する画面である。
【図１０】 検索条件に該当した交通機関の空席状況を一覧で表示する画面である。
【図１１】 ユーザが行った予約の確認事項を表示する画面である。
【図１２】 正常に予約完了した場合に示す、予約完了画面である。
【図１３】 ユーザが予約した役務を一覧表示する画面である。
【図１４】 ユーザが予約した役務を取り消す予約取消確認画面である。
【図１５】 本発明の第３の実施の形態に係る電子商取引システムの概略機能を示すブロック図である。
【図１６】 本発明の第３の実施の形態に係る第１の検索要求データ及び第２の検索要求データの一例を示す図である。
【図１７】 本発明の第３の実施の形態に係る検索結果レコード及び検索結果情報の一例を示す図である。
【図１８】 本発明の第３の実施の形態に係る電子商取引システムにおいて、企業におけるユーザがチケット供給者に対してチケットの検索を行う動作を示すタイムチャート図である。
【図１９】 本発明の第４の実施の形態に係る電子商取引システムの概略機能を示すブロック図である。
【図２０】 本発明の第４の実施の形態に係る第１の申込データ及び第２の申込データ示すブロック図である。
【図２１】 本発明の第４の実施の形態に係る電子商取引システムにおいて、企業におけるユーザがチケット供給者に対してチケットの申込を行う動作を示すタイムチャート図である。
【図２２】 本発明の第５の実施の形態に係る電子商取引システムの概略機能を示すブロック図である。
【図２３】 本発明の第５の実施の形態に係る第１の請求データに含まれ得るデータ項目の一例を示す図である。
【図２４】 本発明の第５の実施の形態に係る電子商取引システムにおいて、チケット供給者が、チケット代金の請求を行う動作を示すタイムチャート図である。
【図２５】 本発明の第５の実施の形態の１変更例に係る電子商取引システムの概略機能を示すブロック図である。
【図２６】 従来のチケット販売方法の概要を示すブロック図である。
【図２７】 従来のチケット販売方法の概要を示すブロック図である。
【図２８】 従来のチケット販売方法の概要を示すブロック図である。
【図２９】 従来のチケットの検索及び申込におけるシステム構成図である。
【図３０】 従来のチケットの検索及び申込における利用者及び旅行代理店の作業を示す図である。
【符号の説明】
１ サプライヤ予約システム
２ 管理サーバ
３、４ 管理端末
５ 顧客企業システム
６ 共通ＤＢサーバ
１１ ホテル予約システム
１２ 交通機関予約システム
１３、１４、２７、２８、２９ ＡＰＩ
１５、１６ 予約ＤＢ
１７ 移動実績・請求情報
２０ スイッチング手段
２１ 接続制御部
２２ メッセージ解析部
２３ａ、２３ｂ、２３ｃ 接続モジュール
２６ 基幹管理手段
３１ 管理画面
４１ 管理画面
５１ ネット予約サーバ
５２ Java（登録商標）ライブラリ
５３ 予約画面
５４ ＣＣ用予約画面
５５ 管理画面
５６ 個人・部課認証データ
５７ ツーリスト旅行システム
５８ 経理システム
５９ 出張申請システム
２０１ ＡＳＰ接続管理部
２０２ ログ記録部
２０３ 要求解読部
２０４ 要求処理部
２０５ ＡＣＬ部
２０６ 認証部
２０７ ＩＤ変換部
２０８ 接続サプライヤ判断部
２０９ メモリデータ管理部
２１０ メモリ
２１１ 更新通知処理部
２１２、３０８ ＤＢ接続部
２１４ 予約情報記録／検索部
２１５ システムアクセス数記録／検索部
２１６ プロトコル変換部
２１７ サプライヤ接続管理部
２１８ 応答処理解読部
２１９ 応答処理部
２２０ セション管理部
２２１ トランザクション管理部
２２２ データ変換／整形部
２５０ ログ管理手段
２５１ ログ管理部
２５２ ログデータ
３０１ ＡＰＩ接続管理部
３０２ 要求解読部
３０３ 処理部
３０５ 更新通知送信部
３０６ 企業アカウント管理部
３０７ 予約情報管理部
３０９ システムアクセス数管理部
３１１ エンジン使用料管理部
３１２ 契約企業情報管理部
３１３ 管理者アカウント管理部
３１４ 管理サーバ管理者セション管理部
３１５ 変更履歴ログ書出部
３１６ ログファイル
３５０ データベース管理手段
３５１ ＤＢＭＳ
３５２ アカウント記憶装置
３５３ 契約記憶装置
３５４ 予約記憶装置
３５５ システムアクセス数記憶装置
１０１０ 企業の予約システム
１０１１ 検索要求データ送信手段
１０１２ 検索結果情報受信手段
１０１３ 申込データ送信手段
１０１４ 申込結果データ受信手段
１０２０ サーバ装置
１０２１ 関連付け部
１０２２ 検索要求データ受信部
１０２３ 検索要求データ送信部
１０２４ 検索結果情報提示部
１０２５ 申込データ受信部
１０２６ 申込データ送信部
１０２７ 申込結果データ提示部
１０２８ 請求データ受信部
１０２９ 請求データ送信部
１０３０ 航空会社の予約システム
１０３１ 検索要求データ受信手段
１０３２ 検索結果レコード送信手段
１０３３ 申込データ受信手段
１０３４ 申込結果データ送信手段
１０４０ チケット供給者の請求システム
１０４１ 販売情報記憶手段
１０４２ 請求データ送信手段
１０５０ 企業の経理システム
１０５１ 請求データ受信手段
１０５２ 従業員情報記憶手段
１５０１ 第１の検索要求データ
１５０２ 第２の検索要求データ
１６０１ 検索結果レコード
１６０２ 検索結果情報
１９０１ 第１の申込データ
１９０２ 第２の申込データ
２００１ 申込結果データ
２１０１ 第１の請求データ
２１０２ 第２の請求データ
【発明の属する技術分野】
本発明は、チケット供給者が、ユーザ群内のユーザにチケットを販売するための電子商取引管理サーバ及び電子商取引管理方法に関する。本明細書において「ユーザ群」には、企業、中小企業群、個人の集合等を含み、「企業」には、官公庁や各種団体、教育機関等を含むものとする。又、「部課」とは、企業を構成する部或いは部に属する課などのことで、企業が料金の精算を行う単位であるのが好ましい。
【０００２】
【従来の技術】
従来、業務出張などの旅行手配をするための旅行代理店（所謂インハウスエージェント）を企業グループ内に設け、この旅行代理店を介して、交通機関やホテル等のチケット供給者が、企業の従業員（ユーザ）にチケットを販売する方法が知られている（例えば、特許文献１）。
【０００３】
図２６に、同公報に開示されたチケットの販売方法の概要を示す。本方法では、まず、企業の従業員が、前記旅行代理店に対してチケット申込を行う。それに応じて、前記旅行代理店が、チケット供給者に対してチケット申込を行い、チケット申込が完了すると、チケットを発券し従業員に配送する。チケットの代金は、企業が前記旅行代理店に一括して精算する。前記旅行代理店は、企業から回収した代金をチケット供給者に支払い、チケットの発券手数料を得る。
【０００４】
本方法によれば、依頼人が主にグループ内企業に固定されているために出張先や手配の好みなどが偏る傾向があることを利用して、前記旅行代理店が、交通機関やホテル等のチケット供給者から、取り扱い数量をまとめることによる割引（大口割引）を引き出しやすいというメリットがある。又、従業員が所属部署と従業員ＩＤを伝えるだけで手続きができたり、チケットが従業員の部署まで届けられたりするなど、本方法は、企業内の従業員にとって非常に便利である。
【０００５】
しかし、これらの旅行代理店は、チケットの発券手数料を主な収益源としているが、チケットを発券し配布する際のコストが高く、実際にはあまり収益を上げることができていないという問題点がある。
【０００６】
又、交通機関やホテル等のチケット供給者は、ある割合の発券手数料を旅行代理店に支払う必要があり、これが収益を圧迫する原因となっている。
【０００７】
この発券手数料の割合を引き下げようにも、前記旅行代理店も、チケットを発券し配布するコストを差し引いた残りが多いわけではないので、交渉が成立しにくい。
【０００８】
このように、本方法では、発券業務に対して発生する発券手数料が、チケット供給者と前記旅行代理店の両者にとって収益を向上させるための障害となっている。
【０００９】
前述のチケットを発券し配布するコストが大きいという問題を解消するために、近年、インターネットを利用して、交通機関やホテル等のチケット供給者が、企業内の従業員等の消費者にチケットを直接販売する方法が増えつつある。
【００１０】
図２７に、上記チケットの販売方法の概要を示す。本方法では、企業内の従業員が、直接インターネットを介して、チケット供給者に対してチケット申込を行う。代金精算は、クレジットカード会社を介して行われる。そして、従業員は、交通機関やホテルの利用時に、空港やホテル等でチケットの発券を受ける。本方法は「チケットレス方式」と呼ばれる。
【００１１】
本方法では、消費者にとって、事前にチケットを買いに行く手間がかからないというメリットがあり、交通機関にとっても、チケットを発券し配送するコストを削減でき、又、申込時にクレジットカード番号を通知させることにより、確実に代金回収ができるというメリットがある。
【００１２】
ところが、本方法では、クレジットカードを用いるので、従業員が個人単位でチケット代金を支払い、後に企業が従業員に精算することになる。そのため、企業は、前述の大口割引が適用されるだけの数量のチケットを購入しているにもかかわらず、その適用を受けることができないという問題点がある。
【００１３】
上述した問題点を解消するために、チケット供給者が、チケットレス方式で、企業の従業員にチケットを直接販売する方法が知られている（例えば、特許文献２）。
【００１４】
図２８に、上記チケットの販売方法の概要を示す。本方法では、チケット供給者が、企業毎に「企業用ＩＤ」を発行し、企業の従業員は、「企業用ＩＤ」を用いて、インターネットを介して、チケット供給者に対して直接チケット申込を行う。
【００１５】
又、本方法では、チケット供給者と企業とが、同一の「企業用ＩＤ」を使用するため、以下の問題点も生じる。
【００１６】
チケット供給者が、企業毎に「企業用ＩＤ」を割り振る場合、その「企業用ＩＤ」は、この企業内の経理システムが用いる「従業員ＩＤ」や「部課コード」等とは一般に異なるものとなり、当該企業が、前記経理システムと連動してチケット代金精算することが困難となる。
【００１７】
逆に、企業が「企業用ＩＤ」を割り振る場合、チケット供給者が、企業毎の様々な様式の「企業用ＩＤ」を取り扱う必要があるので、チケット供給者の既存の予約システムで扱いにくい。又、企業毎の作法に則った経理処理を行うためには、チケット供給者に、企業の従業員や部課に関する企業内情報を提供する必要があるが、企業は、このような機密情報を提供したがらないのが普通である。更に、企業内では異動や組織変更が頻繁にあるため、チケット供給者が、これらの企業内情報の変更に追随するのは困難である。本方法は、これらの理由で実現されていないのが現状である。
【００１８】
更に、特許文献２に開示された方法では、一つの企業が複数のチケット供給者を利用する状況が想定されていないため、企業におけるユーザが、単一の「企業用ＩＤ」を用いて、複数の航空会社（チケット供給者）にまたがってチケットの検索を行ったり、航空会社とホテル（チケット供給者）等を組にして、チケットの検索及び申込を行ったりすることができない。
【００１９】
一方、従来における企業の出張管理は、コストがかかる問題点が挙げられている。
【００２０】
従来のチケットの検索及び申込におけるシステム構成図を図２９に示す。ここでは、第１の企業５ａ、第２の企業５ｂ、第３の企業５ｃ…と、チケットの供給システムである第１のホテル予約システム１１ａ、第２のホテル予約システム１１ｂ、第１の交通機関予約システム１２ａ、第２の交通機関予約システム１２ｂが存在するとする。
【００２１】
この場合、従来のチケット検索及び申込においては、例えば第１の企業５ａは、第１のホテル予約システム１１ａ、第２のホテル予約システム１１ｂ、第１の交通機関予約システム１２ａ、第２の交通機関予約システム１２ｂのそれぞれについて接続を行わなければならない。チケットの供給システムが例えばインターネットのＷｅｂにおいて公開されるような場合は、一度に複数のチケットの供給システムに接続することは容易であるが、チケットの供給システムにダイアルアップを行い接続しなければならない場合は、一度に複数のチケットの供給システムに接続することは極めて困難になる。
【００２２】
更に、例えば第２のホテル予約システム１１ｂがシステム変更になった場合は、第１の企業システム５ａもそれに伴ってシステム変更を行わなければならない。
【００２３】
このように、従来のチケット検索及び申込においては、複数のチケットの供給システムに接続し、一度の操作で複数のチケットの供給システムの役務を受けることは不可能であった。
【００２４】
上述したような、従来のチケットの検索及び申込における利用者及び旅行代理店の作業を図３０に示す。ここでは、企業の利用者が出張する場合に、旅行代理店（或いはインハウスエージェント）を介してチケットを取得する場合について説明する。
【００２５】
まず、ステップＳ９０１において、利用者の出張が決定すると、ステップＳ９０２において、経理システム或いは経理担当者に対して仮払処理を行う。更に、ステップＳ９０３において、利用者はチケットの供給システムに接続をして、交通機関やホテルを決定し、ステップＳ９０４においてその内容を旅行代理店に連絡する。
【００２６】
ステップＳ９０４の連絡を受けて、旅行代理店はステップＳ９５１において予約を受付け、ステップＳ９５２において、端末操作によってその予約内容を入力する。これにより、ステップＳ９５３において、チケットが発券される。
【００２７】
チケットが無事発券されると、ステップＳ９５４において利用者に連絡し、ステップＳ９０５において、利用者は手配が完了した連絡を受ける。
【００２８】
次に、旅行代理店は、ステップＳ９５３において発券したチケットに基づいて、ステップＳ９５５において請求書を作成し、ステップＳ９５６においてチケットを利用者に配達する。
【００２９】
次に、ステップＳ９０６において、利用者はステップＳ９５６において配達されたチケットを受け取り、支払いを行う。ステップＳ９０７において、手配されたチケットに従って出発する。出張から戻ってくると、ステップＳ９０８において、ステップＳ９０２で受けた仮払との差額の精算を行う。
【００３０】
この方法に関連して、企業における出張管理のコスト削減を図る方法が知られている（例えば、特許文献３）。
【００３１】
この出願は、業務出張に関連する一連の事務手続きを出張の起案から精算までコンピュータネットワークを利用した総合的なシステムによって支援可能とし、全てのプロセスで使用されるデータに一貫性を持たせることにより、法人等の業務組織と旅行業者等とにおける各プロセス間の情報の伝達を大幅に省力化するとともに正確性を実現し、時間短縮その他の利便性等を創出する、旅行代理店に予約申込を依頼する処理フローを電子化したシステムである。しかし、代理店の介在を前提としているため、急な出張申請や変更への対応が難しい。又、チケットを出力し、配布するため、出張管理コストの削減につながらないなどの問題があり、充分にコスト削減がなされていない。
【００３２】
一方、交通機関やホテルなどのサプライヤが企業向けに直販しているが、企業内の出張・精算システムと連動させにくく、サプライヤ毎にインタフェースが異なるため、一つの企業が直接複数のサプライヤと接続するのは、コストがかかるなどの問題点がある。
【００３３】
更に、社内業務の効率化の手法として、ＥＤＩ（Electronic Data Exchange：受発注業務に関する電子的情報交換）化されたものがある。しかし、これはあくまでも入り口だけの提供であり、出張予約の手配を行うことができる旅行代理店やサプライヤとで手配情報を交換するだけのものである。従って、企業内システムに適合したインタフェースを有さないので、ユーザが充分満足できるものではない。
【００３４】
このように、出張におけるチケットやホテルの予約に限らず、企業活動を通じて受ける様々な役務の予約及び精算は、その手続きが煩雑で、企業にとって、多大なコストを強いることになっていた。
【００３５】
【特許文献１】
特開２０００−３３１０９８号公報
【００３６】
【特許文献２】
特開平１１−３３９０７６号公報
【００３７】
【特許文献３】
特開平１１−１４３９７７号公報
【００３８】
【発明が解決しようとする課題】
しかしながら、上述したように従来方法には、チケット供給者（サプライヤ）、旅行代理店、企業、企業の従業員の全てに対して、同時にメリットをもたらすことができなかった。
【００３９】
即ち、チケット供給者と企業の双方が独自に管理するＩＤを用いて、チケット供給者が、チケットレス方式で、企業の従業員にチケットを直接販売する方法が存在しなかった。
【００４０】
又、図３０に示した例においては、出張者が費用の仮払・精算を行ったり、旅行代理店がチケットを配達しなければならないため、処理が煩雑になり、これに伴い、出張にかかるコストが大きくなっていた。
【００４１】
更に、既存のシステムと連動させ、業務効率を図ることができなかった。即ち、企業毎に社内システムに合った接続方法を提供しなければならず、そのシステムの導入には多額のコストが要求されていた。
【００４２】
更に、企業がイントラネット上で構築されたシステムで全てを処理しようとすると、イントラネットに接続できない場合に、処理を行えなくなってしまっていた。
【００４３】
又、企業内のシステムと外部システム（例えば予約システム）を接続すると、企業内の情報、例えば出張情報や従業員情報などの機密度が高い情報が外に漏れてしまう場合があり、企業内手続きのシステム化を躊躇させる要因となっていた。
【００４４】
そこで本発明は、ユーザが、役務の予約を容易に行うことのできる電子商取引管理サーバ及び電子商取引管理方法を提供することを目的とする。
【００４５】
【課題を解決するための手段】
上記課題を解決するために、本発明の第１の特徴は、企業が保有する企業予約システム及び企業経理システムと、チケット供給者が保有するチケット供給者予約システム及びチケット供給者請求システムと、に接続され、前記チケット供給者が前記企業内のユーザにチケットを販売するための電子商取引管理サーバである。本発明の第１の特徴に係る電子商取引管理サーバは、 (a) 企業を示す企業コードと、該企業内でユーザを識別するためのＩＤとを含むユーザＩＤと、 (b) 企業コードと、チケット供給者予約システムがユーザを識別するためのＩＤとを含む顧客ＩＤと、 (c) チケット供給者と、を関連付けて記憶する関連付け部と、企業予約システムから送信されるユーザＩＤ及びチケット供給者を含む第１の申込データを受信する申込データ受信部と、第１の申込データに含まれるユーザＩＤ及びチケット供給者との組み合わせに基づいて関連付け部を検索して対応する顧客ＩＤを決定し、該決定された顧客ＩＤ及びチケット供給者を含む第２の申込データを第１の申込データに基づいて作成し、チケット供給者が保有するチケット供給者予約システムに第２の申込データを送信する申込データ送信部と、チケット供給者予約システムから送信される顧客ＩＤ及びチケット供給者が含まれた申込結果データを受信し、該申込結果データに含まれる顧客ＩＤとチケット供給者との組み合わせに基づいて関連付け部を検索して対応するユーザＩＤを決定し、該決定されたユーザＩＤに含まれる企業コードで示される企業が保有する企業予約システムに、申込結果データ内の顧客ＩＤを決定されたユーザＩＤに置換した申込結果データを送信する申込結果データ提示部と、チケット供給者請求システムから送信される顧客ＩＤ及びチケット供給者を含む第１の請求データを受信する請求データ受信部と、第１の請求データに含まれる顧客ＩＤ及びチケット供給者との組み合わせに基づいて関連付け部を検索して対応するユーザＩＤを決定し、該決定されたユーザＩＤを含む第２の請求データを第１の請求データに基づいて作成し、決定されたユーザＩＤに含まれる企業コードで示される企業が保有する企業経理システムに第２の請求データを送信する請求データ送信部とを備える。
【００４９】
【発明の実施の形態】
次に、図面を参照して、本発明の第１及び第５の実施の形態を説明する。以下の図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
【００５０】
本発明の実施の形態においては、例えば、企業に所属するユーザが出張する場合に、ホテルや交通機関を予約し、その精算を行う場合について説明している。
【００５１】
（第１の実施の形態）
本発明の第１の実施の形態について、図１を参照しながら説明する。図１は、本発明の第１の実施の形態に係る電子商取引システムを示すシステム構成図である。第１の実施の形態に係る電子商取引システムは、ユーザ（従業員）の出張を管理しその出張に必要なホテルや交通機関のチケットを予約する顧客企業システム５、顧客企業システム５が予約するホテルのホテル予約システム１１、顧客企業システム５が予約する交通機関の交通機関予約システム１２、複数の顧客企業システム５から任意の複数のホテル予約システム１２、交通機関予約システム１２に接続してホテルや交通機関の予約を行わせる管理サーバ２、管理サーバ２で更新及び参照されるデータが登録されたデータベースの管理を行う共通ＤＢサーバ６、管理サーバ２の管理を行う管理端末３、４を備えている。ここで、顧客企業システム５とは、管理サーバ２が契約している企業が、管理サーバ２にアクセスするＷｅｂサーバのＣＧＩ（Common Gateway Interface：ブラウザからの要求に応じて、プログラムを起動するための仕組み）やサーブレット（モジュール化されたJava（米国 Sun Microsystems, Inc.の登録商標）プログラム）、アプリケーションサーバなどのことである。管理端末３、４は、管理サーバ２及び本発明の電子商取引システムの管理者及び運用者が利用するツールを処理する端末である。
【００５２】
図１においては、顧客企業システム５、ホテル予約システム１１及び交通機関予約システム１２は、各々一つずつしか記載していないが、複数の顧客企業システム５、ホテル予約システム１１及び交通機関予約システム１２は、複数あっても構わない。この場合、一つの顧客企業システム５から、管理サーバ２を介して、一つのホテル予約システム１１或いは交通機関予約システム１２に接続される、それぞれの接続についてセションを管理するのが好ましい。
【００５３】
本発明の電子商取引システムにおいては、各システム及びプロセスの間を接続する場合、ＡＰＩ（Application Program Interface）を介して、接続先の仕様に合わせてデータを整形する。ここで、プロセスとは、スイッチング手段２０等の各手段の構成要素の一つであるプログラムのことである。更に、接続元と接続先とでプロトコルが異なる場合に、そのプロトコルを変換することにより行われる。このＡＰＩを介して接続を行うことにより、既存のシステム及びプロセスの変更を最小限に押さえて接続することができる。即ち、本発明の電子商取引システムにおいては、大きく分けて以下の３つのＡＰＩが存在する。
【００５４】
（ａ）セション管理やログイン認証など、顧客企業・サイトから呼び出される接続管理を行う場合は、共通機能ＡＰＩである接続管理ＡＰＩが行う。図１においては、ＡＰＩ２７が接続管理ＡＰＩに相当する。
【００５５】
（ｂ）主に顧客企業システム５の利用者がホテルや交通機関を予約する場合は、予約者用ＡＰＩが行う。図１においては、ＡＰＩ１３、１４が予約者用ＡＰＩに相当する。複数の国内外の航空予約のシステム、複数の国内外のホテルの予約システムに対して、それぞれ別々に用意するのが好ましい。
【００５６】
（ｃ）管理サーバ２の管理者及び運用者が、予約状況の確認や課金情報や契約情報を見る場合は、管理者用ＡＰＩが行う。図１においては、ＡＰＩ２８が管理者用ＡＰＩ相当する。
【００５７】
これらのＡＰＩについて、どちらのシステム或いはプロセスにＡＰＩを備えるかは、システムの要件に基づいて随時判断されるのが好ましい。
【００５８】
以下、本発明に係る電子商取引システムを構成する主な要素について説明する。
【００５９】
共通ＤＢサーバ６は、管理サーバ２により更新及び参照されるデータを管理するデータベース管理手段３５０と、アカウント記憶装置３５２、契約記憶装置３５３、予約記憶装置３５４、システムアクセスアクセス数記憶装置３５５を備えている。
【００６０】
データベース管理手段３５０は、アカウント記憶装置３５０、契約記憶装置３５３、予約記憶装置３５４、システムアクセス数記憶装置３５５を管理している。即ち、データベース管理手段３５０は、管理サーバ２が管理するデータを各記憶装置に格納する。
【００６１】
アカウント記憶装置３５２には、顧客企業システム５の企業コード、アクセスＩＤ、パスワード等が記録されている。更に、企業に所属するユーザ毎にアクセスＩＤやパスワード等を設定しても良い。更に、顧客企業システム５が、ホテル予約システム１１や交通機関予約システム１２に提示する氏名やカード番号等を設定しても良い。更に、顧客企業システム５が、接続するホテル予約システム１１や交通機関予約システム１２を限定しても良い。この場合、出張先の地域によって限定をしても構わない。これにより、顧客企業システム５は、例えばある交通機関予約システム１２に対して大量の発注を行うことにより、その交通機関予約システム１２の顧客企業システム５に対する価格を下げることもできる。又、顧客企業システム５に属する出張するユーザ或いはユーザの属性に従って、提示するホテルや交通機関を決定しても良い。具体的には、企業の役員には、新幹線のグリーン車を利用を許可したり、一泊２万円以上のホテルの利用を許可することができる。
【００６２】
契約記憶装置３５３は、管理サーバ２が接続を受ける顧客企業システム５や、管理サーバ２が接続をするホテル予約システム１１や交通機関予約システム１２の、企業名、ホテル名、交通機関名、住所、電話番号、担当者名等が記録されている。
【００６３】
予約記憶装置３５４は、予約数、キャンセル数、金額などである。これにより、管理サーバ２が、顧客企業システム５に対して請求金額を提示することができる。更に、予約したホテル或いは交通機関の日付、指定便、ホテル名、人数、ランクなどを記録することにより、予約内容についても顧客企業システム５に対して請求金額を提示することができる。又、更に当該予約について、顧客企業システム５内に属する、精算を行う部課を記載していても構わない。この部課を記載することにより、顧客企業システム５内に一括で請求が来ても、記載された部課に従って請求を振り分けても良い。この請求の振り分けは、顧客企業システム５に属する経理を担当する部署が行っても良いし、インハウスエージェントが行っても良い。更に、管理サーバ２から、顧客企業システム５に属する部課に対して、直接請求を行っても構わない。
【００６４】
システムアクセス数記憶装置３５５は、顧客企業システム５が管理サーバ２に接続した回数及び時間、更にホテル予約システム１１及び交通機関予約システム１２に接続した回数及び時間、又、各接続におけるトラフィック量などが記録されている。これにより、管理サーバ２は、顧客企業システム５、ホテル予約システム１１、交通機関予約システム１２に対して、接続に対して課金を行うことができる。
【００６５】
管理サーバ２は、スイッチング手段２０、基幹管理手段２６、ログ管理手段２５０、ログデータ２５２を備えている。
【００６６】
ログデータ２５２とは、管理サーバ２における運用ログである。
【００６７】
スイッチング手段２０は、顧客企業システム５から、ＡＰＩ２７を介した接続を受付け、顧客企業システム５からの接続毎に設定されるセションを管理し、顧客企業システム５を認証し、顧客企業システム５が接続可能なホテル予約システム１１及び交通機関予約システム１２に接続し、接続された予約システムから予約可能な商品の情報を取得し、顧客企業システム５に送信する。詳述すると、顧客企業システム５からの接続を一括して受け持ち（１０１）、セション管理、認証、ホテル予約システム１１及び交通機関予約システム１２への接続、レスポンス書式のフォーマット等を行う。又、アカウント記憶装置３５２に記録されたアカウントデータを取得し、全てメモリ内に保持する。これらのデータは起動時にロードされ、基幹管理手段２６からのデータ更新通知（１０５）によって、データベース管理手段３５０から再ロードされる（１０３）。スイッチング手段２０が顧客企業システム５から受け取ったリクエストは、パース（解読）されて、予約検索リクエストであれば、所望のホテル予約システム１１及び／或いは交通機関予約システム１２に（１０２）、管理者機能へのリクエストであれば、ＡＰＩ２９を介して基幹管理手段２６へ渡される（１０６）。ホテル予約システム１１へ接続する場合はＡＰＩ１３を介して、交通機関予約システム１２へ接続する場合はＡＰＩ１４を介して、基幹管理手段２６へ接続する場合は、ＡＰＩ２９を介して或いはＡＰＩ２９を介さずに接続される。予約情報や課金単位になるトランザクション数は、データベース管理手段３５０を介して共通ＤＢサーバ６へ書き出される（１０３）。運用ログは、ログ管理手段２５０へと渡される（１０４）。
【００６８】
基幹管理手段２６は、アカウント記憶装置３５２に記録された、顧客企業システム５の認証データ、顧客企業システム５がホテル予約システム１１及び交通機関予約システム１２に接続する認証データのマッピング情報、顧客企業システム５のユーザの属性に従って決定される接続可能なホテル予約システム１１及び交通機関予約システム１２、予約記憶装置３５４に記録された商品の予約に関する情報、顧客企業システムの接続に関する情報のうち、少なくとも一つを管理する。即ち、基幹管理手段２６は、スイッチング手段２０から取得された情報と、管理端末３、４から入力された情報とに基づいて、共通ＤＢサーバ６の管理を主に行う手段である。詳述すると、アカウントデータ、予約履歴、システムアクセス数データを一括して管理し、ＡＰＩ２８を介して、管理端末３、４へ、管理機能を提供する（１０７）。共通ＤＢサーバ６に格納された上記データを、追加、変更、削除する（１０８）。スイッチング手段２０からの管理者用機能の呼び出しを受け取り、処理する。又、管理する共通ＤＢサーバ６のデータが追加、変更、削除されると、基幹管理手段２６に更新通知を送る。
【００６９】
ログ管理手段２５０は、管理サーバ２の管理者及び運用者が利用する運用ログを書き出す手段で、スイッチング手段２０からのログ書き込み要求を受けてログをログファイルに書き込む（１０４）。
【００７０】
各システム及びプロセス間のプロトコル及び文書形式は、様々な組み合わせが考えられる。
【００７１】
例えば、上記の１０１、１０２、１０６、１０７での通信の接続においては、ＯＳＩ参照モデルに対比すると、ネットワーク層及びトランスポート層の接続においてＴＣＰ／ＩＰのプロトコルが、セション層の接続においてＨＴＴＰのプロトコルが、プレゼンテーション層の接続においてＸＭＬの文書形式がそれぞれ用いられるのが好ましい。又、１０４の接続においては、トランスポート層の接続においてプロセス間通信のＵＤＰ（User Datagram Protocol）のプロトコルが用いられるのが好ましい。更に、１０５の接続においては、ネットワーク層及びトランスポート層の接続においてＴＣＰ／ＩＰのプロトコルが用いられるのが好ましい。
【００７２】
ここで、ＯＳＩ参照モデルとは、国際標準化機構（ＩＳＯ：International Organization for Standardization）により制定された、異機種間のデータ通信を実現するためのネットワーク構造の設計方針「ＯＳＩ（Open Systems Interconnection）」に基づき、コンピュータの持つべき通信機能を階層構造に分割したモデルのことである。
【００７３】
本発明の実施の形態において利用されるプロトコル及び文書形式は、この記載に拘束されるものではない。
【００７４】
図２は、図１で記載した本発明の電子商取引システムにおける各ハードウェア構成要素について、詳細に記述したシステム構成図である。
【００７５】
本発明の電子商取引システムは、サプライヤ予約システム１、管理サーバ２、顧客企業システム５を備える。ここでは、共通ＤＢサーバ６の機能を管理サーバ２が備えている場合について説明している。ここで、それぞれのシステム及びサーバは、ＬＡＮ、インターネット、回線交換による通信回線等を介して接続されている。この場合、サプライヤ予約システム１、管理サーバ２、顧客企業システム５は、モデム、ルータ、ダイアルアップルータ、プロキシサーバ、インターネット接続プロバイダのＰＰＰサーバ（ＰＰＰ（Point to Point Protocol）によって、電話回線によるダイアルアップを通じてインターネットに接続するサーバ）等を介して接続されるのが好ましい。
【００７６】
サプライヤ予約システム１は、顧客企業システム５に対してホテルや交通機関の予約を提供するシステムで、図１で示したホテル予約システム１１及び交通機関予約システム１２を備える。ホテル予約システム１１は、当該ホテルの予約に関する情報を格納した予約ＤＢ１５を、交通機関予約システム１２は、当該交通機関の予約に関する情報を格納した予約ＤＢ１６をそれぞれ備えている。ホテル予約システム１１はＡＰＩ１３を介して、交通機関予約システム１２はＡＰＩ１４を介して管理サーバ２に接続する。
【００７７】
顧客企業システム５は、ネット予約サーバ５１を備えている。ネット予約サーバ５１は、Javaライブラリ５２を介して、管理サーバ２に接続する。ネット予約サーバ５１には複数の端末が接続されており、それぞれ画面を備える。具体的には、顧客企業システム５に所属するユーザが予約を行う予約画面５３、ユーザが予約画面５３から直接に予約を行うことができない場合に、コールセンターのオペレータが予約を行うコールセンター（ＣＣ）用予約画面５４、ユーザを管理する管理者が利用する管理者画面５５等が挙げられる。又、ユーザ、コールセンターのオペレータ、管理者が処理を行える機能の権限を任意に設定することのが好ましい。
【００７８】
顧客企業システム５においては、既存のシステムである出張申請システム５９、経理システム５８、インハウスエージェントが管理しているツーリスト旅行システム５７と連携して、管理サーバ２に接続される。又、既存のシステムは、個人・部課認証データ５６を備えている。顧客企業システム５のユーザが出張を行う場合は、出張申請システム５９に対して、出張目的や、所属部課、上司の承認等が入力されるが、出張に係る予約を行う場合は、出張目的や所属部課などを提示する必要はなく、経理システム５８が出納管理を行うのに足りる情報（具体的には名前）のみ提示すれば良い。又、顧客企業システム５が提示する予約画面５３、コールセンター用予約画面５４、管理者画面５５は、出張申請システム５９が従来備えていた端末に表示すれば良い。
【００７９】
管理サーバ２は、図１で説明したように、スイッチング手段２０と、基幹管理手段２６を備えている。スイッチング手段２０は、サプライヤ予約システム１からの接続を受付ける接続モジュール２３ａ、２３ｂ、２３ｃ…を備えている。この接続モジュールは、接続制御部２１によって制御され、接続がなされると、メッセージ解析部２２において、接続により受信したメッセージの解析を行う。ここで解析されたメッセージは、ＡＰＩ２９、契約記憶装置３５３、予約記憶装置３５４を介して 基幹管理手段２６に送信される。
【００８０】
管理サーバ２が顧客企業システム５からの接続を受付けるときは、ＡＰＩ２７、接続制御部２１、メッセージ解析部２２を介して基幹管理手段２６に接続される。管理サーバ２は、ＡＰＩ２８を介して管理端末３が備える管理画面３１、管理端末４が備える管理画面４１から、管理される。
【００８１】
本発明の電子商取引システムにおいては、サプライヤ予約システム１のホテル予約システム及び交通機関予約システム１２から、実際に予約したユーザがそのホテル及び交通機関を利用したかどうかという実績に基づいて、移動実績・請求情報１７の情報を算出することができる。更に、この移動実績・請求情報１７の情報は、顧客企業システム５のツーリスト旅行システム５７に送信され、ツーリスト旅行システム５７は、個人申請システム５９や個人・部課データ５６を参照して、請求先の経理システム５８にその請求を振り分ける。これにより、顧客企業システム５は、実績データに基づいた請求を行うことができるので、キャンセルや変更に伴って請求データを変更することがなく、請求を簡略化し、かつ、確実に行うことができる。
【００８２】
勿論、管理サーバ２で予約に伴った移動実績・請求情報を管理し、顧客企業システム５に請求しても構わない。更に、顧客企業システム５の出張管理における交通機関、ホテルの予約に関する全ての情報を管理サーバ２で管理し、役務の予約のアウトソーシングの形態を取ることも可能である。
【００８３】
図３は、本発明の第１の実施の形態に係る電子商取引システムにおける出張管理のフローチャートを示した図である。
【００８４】
まず、ステップＳ１０１において、顧客企業システム５に所属するユーザの出張が決定した場合、ステップＳ１０２において、予約画面５３を介して出張申請システム５９に対して出張の申請を行う。これにより、管理サーバ２を介してホテル予約システム１１及び交通機関予約システム１２に接続し、ホテル及び交通機関の予約を行い、ステップＳ１０３において、ホテル予約システム１１及び交通機関予約システム１２に予約情報が通知される。このときに、予約に関する情報は、管理サーバ２、ホテル予約システム１１及び交通機関予約システム１２に格納されるので、その予約の確認となるチケットはユーザに配布されなくても良い。
【００８５】
ユーザは、ステップＳ１０４において、交通機関の窓口やホテルのフロントで、顧客企業システム５のユーザであることを認証することにより、その役務を受けることができる。更に、ステップＳ１０５において、ホテル予約システム１１や交通機関予約システム１２が提供した役務に基づいて、移動実績・請求情報１７を作成し、顧客企業システム５に対して、出張精算を行うことができる。
【００８６】
このように、図３で示された本発明における出張管理は、図３０に示された従来の出張管理と比べて処理が少なく、又、手作業による処理を含まないので出張のコストを削減することができる。
【００８７】
即ち、本発明における管理サーバ２（電子商取引管理サーバ）は、国内外のホテル、国内外の交通機関予約システムなど、トラベル全般の予約システムをまとめ、顧客に対しての一環したサービスを提供する。
【００８８】
具体的な管理サーバ２の機能及びそれに対する効果を以下に記載する。
【００８９】
管理サーバ２は、顧客企業システム５及びサプライヤ予約システム１に対して、検索、予約、管理機能などを提供するＡＰＩを共通の仕様で定義する。これにより、画面イメージと検索・予約処理を分割することにより、多くのサイトに予約機能を提供することができる。又、国内ホテル、海外ホテル、国内交通機関、海外交通機関の予約サービスを一貫した接続方法、プロトコル、メッセージフォーマットで提供することができる。
【００９０】
更に管理サーバ２は、顧客企業システム５の管理、契約内容を管理するデータとロジックを実装する。これにより、多くの企業に対してサービスをするにあたり、予約情報、アクセス数、統計情報を、企業毎に管理することができる。又、顧客企業システム５は、企業のシステムに限らず、複数のメンバーが集まったサイトでも構わない。
【００９１】
更に管理サーバ２は、顧客企業システム５とサプライヤ予約システム１を結ぶセションを管理する。これにより、顧客企業システム５とサプライヤ予約システム１がそれぞれ複数あった場合でも、リクエストとレスポンスはどの顧客企業システム５から来てどのサプライヤ予約システム１に返すのか、或いは、どのサプライヤ予約システム１からきてどの顧客企業システム５に返すのか、を管理することができる。
【００９２】
更に管理サーバ２は、各予約システム毎に異なるログイン方法、異なる計算方法で返ってくる料金、セション管理方法や日付等のメッセージフォーマットを、管理サーバ２が提供するＡＰＩに基づいた形式で変換する。これにより、各予約システム毎にデータの仕様が異なり、サービスの仕様が異なっても、均一なサービスを提供することができる。
【００９３】
更に管理サーバ２は、トラベルシステム全体の情報を管理するために、システム管理者、オペレータが利用するＡＰＩを定義する。これにより、予約システム利用料を企業毎に算出することができる。更に、顧客企業システム５が接続できる予約システムの契約を、その都度変更することができる。即ち、新規契約企業、サイトをシステム停止や大きな移行作業を行うことなく追加することができる。
【００９４】
又、サプライヤ予約システム１及び顧客企業システム５が提供する機能に従って、管理サーバ２が提供するＡＰＩが作成され、サプライヤ予約システム１及び顧客企業システム５は、そのＡＰＩを実装する。
【００９５】
又、管理サーバ２は、商品が予約、キャンセル、変更されるたびに、その予約情報の更新を行っている。従って、仮にサプライヤ予約システムから不正な請求がされたとしても、管理サーバ２が提示した予約情報を付き合わせて、確認の取れたものだけを支払えば良い。顧客企業システム５からサプライヤ予約システム１への接続窓口を、管理サーバ２に統合したため、管理サーバ２が管理している予約情報に基づいて請求を確認すれば足りる。これにより、従来、自社が備える出張システムと請求された金額との突き合わせに多大な時間（コスト）を要していたが、本システムによれば、容易に突き合わせができるため、コストの削減を行うことができる。
【００９６】
（第２の実施の形態）
本発明の第２の実施の形態においては、第１の実施の形態で説明した管理サーバ２について詳細に説明する。
【００９７】
図４は、本発明の第２の実施の形態に係る管理サーバ２の機能ブロック図である。管理サーバ２は、主にスイッチング手段２０、基幹管理手段２６、ログ管理手段２５０を備えており、共通ＤＢサーバ６、顧客企業システム５、サプライヤ予約システム１、管理端末３、４が接続されている。
【００９８】
スイッチング手段２０は、ＡＳＰ接続管理部２０１、ログ記録部２０２、要求解読部２０３、要求処理部２０４、ＡＣＬ（Access Control）部２０５、認証部２０６、ＩＤ変換部２０７、接続サプライヤ判断部２０８、メモリデータ管理部２０９、メモリ２１０、更新通知処理部２１１、ＤＢ接続部２１２、予約情報記録／検索部２１４、システムアクセス数記録／検索部２１５、プロトコル変換部２１６、サプライヤ接続管理部２１７、応答処理解読部２１８、応答処理部２１９、セション管理部２２０、トランザクション管理部２２１、データ変換／整形部２２２を備える。
【００９９】
ＡＳＰ接続管理部２０１は、顧客企業システム５からのリクエストを、決まったＵＲＬ（ＩＰアドレス或いはＦＱＤＮ、ポート番号、サービス名）受付け、リプライを返す。セション番号やトランザクション番号を認識したり、付与する。
【０１００】
ここで、ＦＱＤＮとは、Fully Qualified Domain Nameのことで、ＴＣＰ／ＩＰによるネットワーク上で、ドメイン名・サブドメイン名・ホスト名を省略せずに全て指定した記述形式のことである。
【０１０１】
ログ記録部２０２は、ログ管理手段２５０とコネクションを確立し、運用ログをログ管理手段２５０へ送信する。
【０１０２】
要求解読部２０３は、顧客企業システム５側からのリクエストをパースし、管理サーバ２内部で処理する情報と、サプライヤ予約システム１又は管理サーバ２側へ送る機能を分解する。
【０１０３】
要求処理部２０４は、ログイン認証や、サプライヤ予約システム１への接続時に認証したアカウントと、サプライヤ予約システム１への接続アカウントのマッピングし、接続先のサプライヤ予約システム１がその顧客企業システム５から、利用できる契約がなされているかの判断などを処理する。又、管理サーバ２やサプライヤ予約システム１の各予約システムの、どこに対してリクエストを出すのかを判断する。
【０１０４】
ＡＣＬ部２０５は、スイッチング手段２０のメモリ２１０上に保持された、顧客企業毎のアクセスコントロール情報（ＩＰアドレスやドメイン）を参照して、アクセスの許可・拒否を判断する。
【０１０５】
認証部２０６は、スイッチング手段２０のメモリ２１０上に保持された、顧客企業のアカウント情報を参照して、顧客企業からのリクエストに含まれるアカウント情報に対する認証許可・拒否を判断する。ここで、顧客企業システム５毎に認証がされても良いし、顧客企業システム５の従業員（ユーザ）毎に認証されても良い。又、更に、承認された出張に関する予約であるか、即ちその費用を顧客企業に請求して良いかどうかについて認証を行っても良い。
【０１０６】
ＩＤ変換部２０７は、スイッチング手段２０のメモリ２１０上に保持された、顧客企業のアカウント情報（企業コード）とサプライヤ予約システム１の接続アカウントのマッピング情報を参照して、サプライヤ予約システム１へ接続時に使用するアカウントを選択する。認証機構（ログイン処理）の不要なサプライヤ予約システム１に対してはこの処理は行われない。
【０１０７】
接続サプライヤ判断部２０８は、スイッチング手段２０のメモリ２１０上に保持された、顧客企業コードと利用許可サプライヤ予約システム１とのマッピング情報を参照して、接続先のサプライヤ予約システム１を使用させても良いかを判断する。ここでは、顧客企業システム５毎に判断されるが、更に、顧客企業システム５に属するユーザ毎に判断がなされても良い。
【０１０８】
更新通知処理部２１１は、基幹管理手段２６とのコネクションを確立し、基幹管理手段２６からの更新通知を受信する。
【０１０９】
ＤＢ接続部２１２は、データベース管理手段３５０とコネクションを確立し、共通ＤＢサーバ６に対するクエリ要求を受付け、クエリを行う。
【０１１０】
予約情報記録／検索部２１４は、予約成立／キャンセル時に予約情報を共通ＤＢサーバ６の予約記憶装置３５４に書き込んだり、顧客企業の管理者向けの予約内容検索リクエスト時に予約記憶装置３５４から予約情報を検索する。
【０１１１】
システムアクセス数記録／検索部２１５は、アクセス数、トランザクション数、ログイン数などを共通ＤＢサーバ６のシステムアクセス数記憶装置３５５に書き込んだり、システムアクセス数記憶装置３５５から検索したりする。
【０１１２】
プロトコル変換部２１６は、サプライヤ予約システム１の各予約システムや基幹管理手段２６などの接続先に合わせて、リクエストを作成、或いは変換する。
【０１１３】
サプライヤ接続管理部２１７は、サプライヤ予約システム１や基幹管理手段２６にリクエストを送信し、レスポンスを受信する。サプライヤ予約システム１の各予約システムや基幹管理手段２６とのセションＩＤ、トランザクションＩＤを処理する。
【０１１４】
応答処理解読部２１８は、サプライヤ予約システム１の各予約システム、基幹管理手段２６からのレスポンスをパースする。
【０１１５】
応答処理部２１９は、サプライヤ予約システム１の各予約システム、基幹管理手段２６からのレスポンスの内容に応じて、予約情報を書き出すなどの処理を制御する。
【０１１６】
セション管理部２２０は、顧客企業システム５とＡＳＰ接続管理部２０１との間のセション管理を行い、同時にサプライヤ予約システム１の各予約システムとサプライヤ接続管理部２１７との間のセション管理を行う。又、ＡＳＰ接続管理部２０１とサプライヤ接続管理部２１７とのセション情報を対にして管理する。
【０１１７】
トランザクション管理部２２１は、顧客企業システム５とＡＳＰ接続管理部２０１の間のトランザクション管理を行い、同時にサプライヤ予約システム１の各予約システムとサプライヤ接続管理部２１７との間のトランザクション管理を行う。又、ＡＳＰ接続管理部２０１とサプライヤ接続管理部２１７とのトランザクション情報を対にして管理する。
【０１１８】
データ変換／整形部２２２は、スイッチング手段２０の内部、基幹管理手段２６、或いはサプライヤ予約システム１の各予約システムからのレスポンスを、顧客企業システム５に提供しているＡＰＩの仕様に合わせてデータ変換／整形する。
【０１１９】
メモリ２１０は、アクセスコントロール情報、アカウント情報、企業コードと接続BEとのアカウントマッピング情報、接続サプライヤ予約システム１の利用許可情報の各データを共通ＤＢサーバ６から受け取って保持しておくメモリ領域である。
【０１２０】
メモリデータ管理部２０９は、スイッチング手段２０中に保持するメモリ情報をＡＣＬ部２０５、認証部２０６、ＩＤ変換部２０７、接続サプライヤ判断部２０８へ提供する。更に、共通ＤＢサーバ６の更新通知を、更新通知処理部２１１から受け取って、ＤＢ接続部２１２を通じて再度メモリ上のデータを共通ＤＢサーバ６からロード（更新）する。又、共通ＤＢサーバ６からのデータ更新時には、メモリデータの参照要求はロックする。データ更新の単位、メモリリードロックの単位は、顧客企業システム５毎や全ての項目など複数のレベルがあり得る。
【０１２１】
ログ管理手段２５０は、ログ管理部２５１及びログデータ記憶装置２５２を備えている。ログデータ記憶装置２５２は、スイッチング手段２０の処理のログデータが格納されている。ログ管理部２５１は、スイッチング手段２０のログ記録部２０２からメッセージを受信し、ログデータ記憶装置２５２にそのメッセージをログデータ記憶装置２５２に格納する。
【０１２２】
基幹管理手段２６は、ＡＰＩ接続管理部３０１、要求解読部３０２、処理部３０３、更新通知送信部３０５、企業アカウント管理部３０６、予約情報管理部３０７、システムアクセス数管理部３０９、エンジン使用料管理部３１１、契約企業情報管理部３１２、管理者アカウント管理部３１３、管理サーバ管理者セション管理部３１４、変更履歴ログ書出部３１５、ログファイル３１６を備えている。
【０１２３】
ＡＰＩ接続管理部 ３０１は、管理端末３、４からのアクセス、スイッチング手段２０のサプライヤ接続管理部２１７からのリクエストを受付け、リプライを返す。
【０１２４】
要求解読部３０２は、リクエストデータをパースする。
【０１２５】
処理部３０３は、リクエストの内容(ＡＰＩ)に応じた機能を問い合わせ、レスポンスを作成する。
【０１２６】
変更通知送信部３０５は、スイッチング手段２０とコネクションを確立し、企業アカウント管理部３０６、契約企業情報管理部３１２からの変更通知を、スイッチング手段２０に送信する。
【０１２７】
企業アカウント管理部３０６は、企業アカウントの追加／変更/削除の処理を実装する。共通ＤＢサーバ６のアカウント記憶装置３５２中のデータが変更されると、変更通知送信部３０５へ変更があった旨を知らせる。
【０１２８】
予約情報管理部３０７は、処理部３０３からの要求に応じて、共通ＤＢサーバ６の予約記憶装置３５４に格納された予約履歴を用いて、予約件数や総予約金額計算などの業務ロジックを実装する。
【０１２９】
ＤＢ接続部３０８は、データベース管理手段３５０とコネクションを確立し、共通ＤＢサーバ６に対するクエリ要求を受付け、クエリを行う。
【０１３０】
システムアクセス数管理部３０９は、処理部３０３からの要求に応じて、共通ＤＢサーバ６のシステムアクセス数記憶装置３５５に格納されているアクセス数を元に、ある期間のトランザクション数出力などの業務ロジックを実装する。
【０１３１】
エンジン使用料管理部３１０は、処理部３０３からの要求に応じて、予約情報管理部３０７からの予約数データを利用して、エンジン利用料の業務ロジックを実装し、結果を処理部３０３へと返す。
【０１３２】
契約企業情報管理部 ３１２は、契約企業の契約情報、担当者情報、業態などの契約企業情報を登録、変更、削除する処理を行う。
【０１３３】
管理者アカウント管理部 ３１３は、管理サーバ２の管理者及び運用者のアカウントの認証を行う。ここでは図示しないが、管理者及び運用者のアカウント及びパスワードを格納した記憶装置を備えるのは勿論である。
【０１３４】
ログファイル３１６は、管理サーバ２の管理者及び運用者が、契約企業情報などを変更した場合に、誰がどの操作を行ったのかを記録するログファイルである。
【０１３５】
変更履歴ログ書出部３１５は、管理サーバ２の管理者及び運用者が、内部状態を変更した場合に記録するログファイル３１６を書き出す。
【０１３６】
管理サーバ管理者セション管理部 ３１４は、変更履歴ログ書出部３１５によってログファイル（変更履歴ログ）３１６を書き出すときに、処理を実行している管理者を識別するために利用するセションを管理する。
【０１３７】
共通ＤＢサーバ６は、管理サーバ２が更新及び参照を行うデータベースの管理を行う。共通ＤＢサーバ６は、データベース管理手段３５０を備えている。
【０１３８】
データベース管理手段３５０は、ＤＢＭＳ３５１と、アカウント記憶装置３５２、契約記憶装置３５３、予約記憶装置３５４、システムアクセス数記憶装置３５５を備えている。
【０１３９】
ＤＢＭＳ（DataBase Management System）３５１は、共有データとしてのデータベースを管理し、データに対するアクセス要求に応えるソフトウェアである。
【０１４０】
ＤＢＭＳは、データの形式や利用手順を標準化し、特定のアプリケーションソフトから独立させることができる。
【０１４１】
アカウント記憶装置３５２には、顧客企業システム５の企業コード、アクセスＩＤ、パスワード等が記録されている。更に、企業に所属するユーザ毎にアクセスＩＤやパスワード等を設定しても良い。更に、顧客企業システム５が、サプライヤ予約システム１に提示する氏名やカード番号等を設定しても良い。更に、顧客企業システム５が、接続するサプライヤ予約システム１を限定しても良い。この場合、出張先の地域によって限定をしても構わない。これにより、顧客企業システム５は、例えばあるサプライヤ予約システム１に対して大量の発注を行うことにより、そのサプライヤ予約システム１の顧客企業システム５に対する価格を下げることもできる。又、顧客企業システム５に属する出張するユーザ或いはユーザの属性に従って、提示するホテルや交通機関を決定しても良い。具体的には、企業の役員には、新幹線のグリーン車を利用を許可したり、一泊２万円以上のホテルの利用を許可することができる。
【０１４２】
契約記憶装置３５３は、管理サーバ２が接続を受ける顧客企業システム５や、管理サーバ２が接続をするサプライヤ予約システム１の、企業名、ホテル名、交通機関名、住所、電話番号、担当者名等が記録されている。
【０１４３】
予約記憶装置３５４は、予約数、キャンセル数、金額などが記録されている。
【０１４４】
これにより、管理サーバ２が、顧客企業システム５に対して請求金額を提示することができる。更に、予約したホテル或いは交通機関の日付、指定便、ホテル名、人数、ランクなどを記録することにより、予約内容についても顧客企業システム５に対して請求金額を提示することができる。
【０１４５】
システムアクセス数記憶装置３５５は、顧客企業システム５が管理サーバ２に接続した回数及び時間、更にサプライヤ予約システム１に接続した回数及び時間、又、各接続におけるトラフィック量などが記録されている。これにより、管理サーバ２は、顧客企業システム５、サプライヤ予約システム１に対して、接続に対して課金を行うことができる。
【０１４６】
図５は、第２の実施の形態における管理サーバ２の処理を示すフローチャートである。ここでは、管理サーバ２が顧客企業システム５から接続を依頼され、接続先であるサプライヤ予約システム１に接続する処理について説明する。
【０１４７】
まず、ステップＳ２０１において管理サーバ２は、ＡＳＰ接続管理部２０１を介して顧客企業システム５から接続の依頼を受ける。ここで依頼された接続は、ＡＣＬ部２０５によって、接続が許可されているか否かを判断する。許可されていない場合は、処理を終了する。ステップＳ２０２において接続が許可されている場合は、更に、認証部２０５によって、認証が許可されているか否かを判断する。許可されていない場合は、処理を終了する。
【０１４８】
次に、ステップＳ２０３において認証が許可されている場合、ステップＳ２０４において、ＩＤ変換部２０７によって、接続先となるサプライヤ予約システム１に適合するＩＤに変換し、ステップＳ２０５において、接続サプライヤ判断部２０８によって、サプライヤ予約システム１に接続が許可されているか否かを判断する。許可されていない場合は、処理を終了する。
【０１４９】
ステップＳ２０５において接続できるサプライヤ予約システム１だと判断された場合は、ステップＳ２０６において、要求処理部２０４によって、顧客企業サーバ５から受信したメッセージの処理を行い、ステップＳ２０７において、メッセージの指示に従ったサプライヤ予約システム１に接続を行う。このとき、セション管理部２２０によってセションが、トランザクション管理部２２１によってトランザクションが、それぞれ管理される。
【０１５０】
次に、サプライヤ予約システム１からの応答を受けると、ステップＳ２０８において、応答処理部２１９によって、応答処理を行う。ここで得られた応答処理は、ステップＳ２０９において、データ変換／整形部２２２によって、顧客企業システム５の仕様に従って、データ変換及び整形が行われる。
【０１５１】
最後に、ステップＳ２１０において、ステップＳ２０９で作成されたデータを、ＡＳＰ接続管理部２０１によって、顧客企業システム５に送信する。
【０１５２】
次に、本発明の第２の実施の形態における管理サーバ２のセション管理部２２０によるセション管理について説明する。このセション管理は、複数の顧客企業システム５と複数のサプライヤ予約システム１を多対多で接続をすることができ、一度に、複数のセションを管理することができる。
【０１５３】
スイッチング手段２０は、セションＩＤにより、リクエストに対するレスポンスを適切な相手に返す。又、セションＩＤによって、リクエストがどの企業のどのユーザから来たものであるかを判断し、企業毎、ユーザ毎の処理を適切に行う。
【０１５４】
スイッチング手段２０でのセションＩＤの管理単位は、顧客企業システム５が管理サーバ２にログインするログインＡＰＩ呼び出し毎である。顧客企業システム５から、企業コードと、ユーザＩＤとパスワードと共にログインＡＰＩの呼び出しリクエストが送信されると、それを受けたスイッチング手段２０は、ユーザ認証の後、ユーザに特有で一意に定められたセションＩＤを返す。
【０１５５】
セションＩＤの生存期間は、指定されたタイムアウトが起きるまでか、若しくは顧客企業システム５が管理サーバ２からログアウトするログアウトＡＰＩの呼び出しまでである。
【０１５６】
顧客企業システム５へのセションＩＤの発行は、スイッチング手段２０は、顧客企業システムに対して、ログインＡＰＩのレスポンスにセションＩＤを返す。
【０１５７】
ここで、図６を参照して、本発明の第２の実施の形態における管理サーバ２のセション管理部２２０によるセション管理について説明する。
【０１５８】
基幹管理手段２６は、スイッチング手段２０側のＡＰＩ２９においては、セション管理を行わない。よって、このポートに対する全ＡＰＩは、その都度必要なパラメータを全て指定するリクエストとなる。
【０１５９】
基幹管理手段２６は、管理サーバ２の管理者側のＡＰＩ２８においては、ログインＡＰＩ呼び出しのレスポンスにセションＩＤを発行する。
【０１６０】
交通機関予約システム１２は、交通機関予約システム１２のＡＰＩ１４のうち、ログインＡＰＩの呼び出し時に、スイッチング手段２０からセション番号を受け取り、このセション番号を利用してセション管理を行う。
【０１６１】
ホテル予約システム１３は、全てのＡＰＩ１３呼び出し時に、入力パラメータとしてスイッチング手段２０のセション番号を受け取る。
【０１６２】
上記のように、これら３つのシステムでは、セション管理をしないか、又はスイッチング手段２０のセッション番号をそのまま用いるため、スイッチング手段２０では特に契約企業側セッション番号と、ホテル予約システム１３及び交通機関予約システム１４側セション番号とのマッピングテーブルを管理する必要は、必ずしもない。
【０１６３】
ここでは、実施の形態の一つとして、交通機関予約システム１２は、ログインＡＰＩの呼び出し時にセション番号を受け取り、ホテル予約システム１３は、全てのＡＰＩを呼び出しとき入力パラメータとしてセション番号を受け取ると記載したが、この実施例に限られるものではない。セション番号の受け取り方は、サプライヤ予約システム１のセション管理方法に依存する。
【０１６４】
このように、管理サーバ２は、セション管理方法が異なるシステムでも、そのシステムに応じたセション管理を行うことにより、そのシステムの差異を吸収し、接続を可能にすることができる。
【０１６５】
次に、本発明の第２の実施の形態におけるトランザクション管理について説明する。
【０１６６】
管理サーバ２で接続されるサプライヤ予約システム１は、スイッチング手段２０が予約情報を管理サーバ２に接続された共通ＤＢサーバ６の予約記憶装置３５４に格納するにあたって、予約記憶装置３５４の予約情報と、サプライヤ予約システム１の予約ＤＢ１５、１６の予約情報の一貫性を保たせる必要がある。
【０１６７】
ここでは、サプライヤ予約システム１として、ホテル予約システム１１を用いた場合について説明する。
【０１６８】
ここで、スイッチング手段２０との２フェーズコミットのシステム図を図７（ａ）に、処理フローを示すフローチャート図７（ｂ）に図示する。
【０１６９】
まず、ステップＳ３０１において、図７（ａ）の顧客企業システム５がスイッチング手段２０に対して、ホテルの予約確定のリクエストを送信すると、ステップＳ３０２において、スイッチング手段２０は、顧客企業システム２０からのリクエストをメモリ２１０内に保持しつつ、ステップＳ３０３において、このリクエストをホテル予約システム１１へ渡す。これにより、予約が確定される。
【０１７０】
次に、ホテル予約システム１１は、ステップＳ３０４において、予約ＤＢ１５に対して、データ更新処理を行い、このトランザクション処理が成功したことを確認し、その結果を確定（コミット）する。コミットをすると、ステップＳ３０５において、予約ＤＢ１５から更新結果が成功したか或いは失敗したかが返る。
【０１７１】
ホテル予約システム１１は、ステップＳ３０６において、その結果をスイッチング手段２０に返す。
【０１７２】
ステップＳ３０７において、ステップＳ３０４におけるホテル予約システム１１の予約ＤＢ１５の更新が失敗していた場合は、そのまま何もせず、顧客企業システム５へ、失敗レスポンスを返す。即ち、このトランザクションの結果は予約失敗となり、ステップＳ３１２において、スイッチング手段２０は、予約失敗したことをレスポンスとして返す。
【０１７３】
ステップＳ３０４においてホテル予約システム１１の予約ＤＢ１５の更新が成功した場合は、ステップＳ３０８において、共通ＤＢサーバ６の予約記憶装置３５４の更新を行う。ステップＳ３０８における予約記憶装置３５４の更新が成功しなかった場合は、ステップＳ３０９において、予約記憶装置３５４に対して再度の書き込みとコミットを試行する。最終的に予約記憶装置３５４の更新が成功した場合は、ステップＳ３１０において、スイッチング手段２０は、顧客企業システム５に対してホテルの予約が完了したことをレスポンスとして返す。
【０１７４】
ステップＳ３０９において、共通ＤＢサーバ６の更新が最終的に失敗した場合は、ステップＳ３１１において、異常終了となり、予約記憶装置３５４と予約ＤＢ１５との間で不整合が発生する。この場合、予約ＤＢ１５に対してロールバック（更新取消）を行い、顧客企業システム５に対しては、予約失敗したことをレスポンスとして返す。又、予約記憶装置３５４に格納すべき予約情報をエラーログに書き込み、顧客企業システム５に対しては、予約成功したことをレスポンスとして返しても良い。この場合、予約記憶装置３５４と予約ＤＢ１５は不整合のままなので、このエラーログを参照して、管理サーバ２の管理者及び運用者によって、この不整合が修正されなければならない。
【０１７５】
上述したように、第２の実施の形態においては、役務を予約する場合について説明したが、予約をキャンセルする場合にも、正当な処理がなされるのは勿論のことである。
【０１７６】
次に、図８乃至図１５を参照して、管理サーバ２或いは顧客企業システム５が、ユーザに提示している画面について説明する。ここでは、顧客企業システム５を利用しているユーザが、業務の一つである出張申請を行い、そのときに交通機関のチケットを手配する場合について説明する。
【０１７７】
図８は、顧客企業システム５が備えている、ユーザの情報を管理する画面群である。
【０１７８】
まず、図８（ａ）に示した画面は、ユーザ（従業員）の情報を得るべくログインさせるため、ユーザに従業員番号とパスワードを入力させる画面である。入力されたパスワードが顧客企業システム５内に保存されたパスワードと一致すると、図８（ｂ）に示した画面を参照する。ここで、ユーザに従業員番号とパスワードを入力させなくても、キャッシュ情報や端末固有情報等からユーザを特定しても構わない。
【０１７９】
次に、図８（ｂ）に示した画面において、ユーザが操作できる業務（出退勤管理、業務報告、出張申請、予約一覧表示等）等に対応したボタンの一覧を、表示する。ここで、「出退勤管理」ボタンがクリックされると、ユーザの過去の出退勤の結果、又、休みの予定等を入力することができる。「業務報告」ボタンがクリックされると、上司などに現在携わっている業務について報告を行うことができる。「出張申請」ボタンＢ１０１がクリックされると、上司に出張することを申請して許可をもらうことができる。「予約一覧表示」ボタンＢ１０４がクリックされると、ユーザが顧客企業システム５を介して予約した商品の一覧を表示することができる。具体的には、「出張申請」のときに予約した、交通機関及びホテルの予約内容を参照することができる。ここでは、文具などの消耗品や、本の予約を含めても良い。
【０１８０】
ここで、本発明の第２の実施の形態においては、ユーザが出張申請を行うので、「出張申請」ボタンＢ１０１をクリックすると、図８（ｃ）に示した画面である出張申請画面を表示する。
【０１８１】
図８（ｃ）の出張申請画面において、出張の期間、出張先、目的等、出張に関する情報を入力させる。更に、この出張の経費を負担する部課名を入力させても良い。更に、出張申請画面の入力時は、上司の承認が得られていないので、上司の承認が「否」にチェックされているが、出張申請が完了し、上司の承認が得られれば、上司の承認が「可」となる。これにより、出張の経費を、会社（或いは、出張の経費を負担する部課名が記されていた場合はその部課）に負担させることができる。
【０１８２】
更に、図８（ｃ）の出張申請画面において、交通機関やホテルの予約が必要な場合は、「チケット手配」ボタンＢ１０２或いは「ホテル手配」ボタンがクリックされる。この例においては、交通機関のチケットを手配するので、「チケット手配」ボタンＢ１０２がクリックされる。
【０１８３】
図９乃至図１４は、チケット手配を行う画面である。ここで表示されている時刻表、予約に関する情報、ユーザに関する情報等は、管理サーバ２からＡＰＩ２７を介して取得されたもので、その情報を元に、顧客企業システム５が画面に表示している。又、「お知らせ」や「ヘルプ」等、動的にデータが変更しないものに関しては、顧客企業システム５の内部で保存して表示するのが好ましい。
【０１８４】
又、チケット手配に関する画面遷移等は、顧客企業システム５の業務フロー、画面イメージに適合した形で作成されるのが好ましいので、顧客企業システム５の仕様に基づいて作成されるのが良い。
【０１８５】
図９に示した画面は、図８（ｃ）に示した画面において「チケット手配」ボタンＢ１０２がクリックされて、最初に表示する画面である。この画面では、図８（ｃ）に示した画面で入力された情報が、なるべく既に入力された状態で表示するのが好ましい。例えば、出張の出発日に交通機関の予約を行う場合が多いので、最初に出張の出発日を入力しておく。又、利用する航空会社をチェックボックスで選択できるようにしていても良い。更に、ここに表示する航空会社は、管理サーバの契約記憶装置３５３で契約している航空会社に限られても良い。
【０１８６】
図９に示した画面において、チケットを予約する航空機の条件を入力させて、「検索」ボタンＢ１０３をクリックさせると、図１０に示した画面において、検索条件に該当した交通機関の空席状況を一覧で表示する。図１０に示した画面において、検索条件として、搭乗日、出発地、到着地を表示する。更に、それぞれの検索結果に対応づけて、航空会社、便名、出発時刻、到着時刻、機種、空席状況、利用運賃、「予約する」ボタンＢ１０５ａ、Ｂ１０５ｂ、Ｂ１０５ｃ…を表示する。
【０１８７】
この「予約する」ボタンＢ１０５ａ、Ｂ１０５ｂ、Ｂ１０５ｃ…をユーザがクリックすると、予約処理を行い、図１１に示した画面を表示する。
【０１８８】
図１１に示した画面においては、ユーザが行った予約の確認事項を表示する。
【０１８９】
更に、予約時に座席を希望できる航空会社（この場合Ｂ社）の場合は、ここで、希望する座席を選択する。更に、交通機関を利用するユーザの、交通機関に対しての表示名（名前、固有番号等）も合わせて表示する。ここでは、企業が外に開示したくない、部署名、出張目的等の情報は一切表示しない。ここに表示された情報で正しければ、ユーザに「予約確定」ボタンＢ１０６をクリックさせる。
【０１９０】
その後、管理サーバ２は、予約情報を取得し、交通機関予約システム１２に対して、確認された交通機関の予約を行い、正常に予約完了した場合は、図１２に示す予約完了画面を表示する。更に、予約完了後に座席を指定できる航空会社（この場合Ａ社）に対して予約がなされた場合は、「事前に座席を指定する」ボタンＢ１０７をクリックさせることにより、座席を指定することができる。
【０１９１】
更に、図８（ｂ）或いは（ｃ）に示された画面において、「予約一覧表示」ボタンＢ１０４がクリックされると、図１３に示す画面を表示する。ここでは、ユーザが予約した役務を一覧表示する画面を表示する。この画面において、「予約取消」ボタンＢ１０８ａ、Ｂ１０８ｂがクリックされると、図１４に示す予約取消確認画面を表示する。ここで、「確定」ボタンＢ１０９がクリックされると、予約を取り消すため、管理サーバ２に送信され、管理サーバ２は、交通機関予約システム１２に対して予約を取り消す。
【０１９２】
このように、本発明の電子商取引システムが提供するＡＰＩによって、交通機関毎に異なるインタフェースを統合し、ユーザに一度に提示することができる。
【０１９３】
具体的には、接続先となるサプライヤ予約システム１の予約方法の違いを吸収し、同様の商品を扱い異なるサプライヤ予約システム１（所謂「同業他社」）が扱う商品を、一覧で提示し、それぞれのサプライヤ予約システム１が提供する商品を比較することができる。
【０１９４】
又、第２の実施の形態においては、ブラウザを介してシステムに接続する場合について説明したが、ブラウザでなく、一般的な画面を介してシステムに接続しても構わない。
【０１９５】
（第３の実施の形態）
本発明の第３の実施の形態について、図１５を参照しながら説明する。図１５は、本実施形態に係る電子商取引システムを示す概略構成図である。本実施形態に係る電子商取引システムは、企業の予約システム１０１０、サーバ装置（電子商取引管理サーバ）１０２０、複数のチケット供給者（航空会社）の予約システム１０３０から構成される。
【０１９６】
本実施形態では、この電子商取引システムによって、企業（ユーザ群）におけるユーザ（従業員）は、自身の従業員ＩＤを用いて、一つ又は複数のチケット供給者（航空会社）が供給するチケット検索を行う。本実施形態では、企業（ユーザ群）の従業員（ユーザ）が、複数の航空会社（チケット供給者）に対して、航空券（チケット）の予約情報を検索する場合を例として説明する。
【０１９７】
企業における従業員がチケット検索のために使用する企業の予約システム１０１０は、ユーザＩＤ及び検索条件情報を含む第１の検索要求データ１５０１を送信する検索要求データ送信手段１０１１と、検索結果情報１５０２を受信する検索結果情報受信手段１０１２とを備える。検索要求データ送信手段１０１１及び検索結果情報受信手段１０１２は、企業における汎用パソコンに搭載されたＷＷＷブラウザ等で構成される。
【０１９８】
図１６に、第１の検索要求データ１５０１の一例を示す。第１の検索要求データ１５０１は、「検索要求ＩＤ」、「ユーザＩＤ」、及び、検索条件情報としての「検索対象チケット供給者ＩＤ」と「検索対象チケット情報」等を含む。本実施形態では、「検索要求ＩＤ」には、チケット検索を行う従業員が入力する出張番号が挿入され、「ユーザＩＤ」には、該従業員の従業員ＩＤ及び該従業員が属する企業の企業コード等が挿入され、「検索対象チケット供給者」には、航空会社名が挿入される。又、「検索対象チケット情報」には、搭乗日、出発時刻、出発地、到着地等が挿入される。従業員ＩＤは、各企業が、従業員を識別するために独自に管理しているものを用いる。
【０１９９】
第１の検索要求データ１５０１は、任意の形式で良く、企業における汎用パソコンに搭載されたＷＷＷブラウザによってフォーム形式で送信されても良いし、企業の予約システム１０１０とサーバ装置１０２０との間の通信リンク上で送信されても良い。
【０２００】
図１７に、検索結果レコード１６０１及び検索結果情報１６０２の一例を示す。検索結果情報１６０２は、前記検索条件情報に合致するチケットについて複数の航空会社が生成した複数の検索結果レコード１６０１からなる。各検索結果レコード１６０１は、「検索要求ＩＤ」、「顧客ＩＤ」、「チケット供給者」、「チケット情報」等を含む。「チケット情報」としては、例えば、搭乗日、出発時刻、到着時刻、出発地、到着地、便名、機種、空席状況、料金等が含まれる。検索結果情報１６０２は、「検索要求ＩＤ」、「ユーザＩＤ」、「チケット供給者」及び「チケット情報」を含む。一つの検索情報１６０２が、複数の「チケット供給者」及び「チケット情報」を含んでも良い。
【０２０１】
企業の予約システム１０１０は、受信した検索結果情報１６０２に応じて、前記検索条件情報に合致するチケットを関連する情報と共に画面上に一覧表示する。
【０２０２】
本実施形態に係るサーバ装置１０２０は、ユーザＩＤと顧客ＩＤとを関連付ける関連付け部１０２１と、第１の検索要求データ１５０１を受信する検索要求データ受信部１０２２と、該第１の検索要求データ１５０１に応じて、第２の検索要求データ１５０２を生成し、該第２の検索要求データ１５０２の宛先のチケット供給者を選定し、該選定されたチケット供給者に該第２の検索要求データ１５０２を送信する検索要求データ送信部１０２３と、検索結果情報１６０２を前記ユーザに提示する検索結果情報提示部１０２４とを備える。検索要求データ受信部１０２２及び検索結果情報提示部１０２４は、ＷＷＷサーバ等で構成される。
【０２０３】
本実施形態において、サーバ装置１０２０が、企業グループの旅行代理店（インハウスエージェント）に設置されている場合を例として説明する。
【０２０４】
顧客ＩＤは、航空会社が、ユーザを識別するために独自に管理しているものを用いる。例えば、航空会社の利用状況に応じてサービスポイントを蓄積するための顧客毎に付与するアカウント番号を用いる。
【０２０５】
又、図１６に、第２の検索要求データ１５０２の一例を示す。第２の検索要求データ１５０２は、「検索要求ＩＤ」、「顧客ＩＤ」、及び、検索条件情報としての「検索対象チケット供給者ＩＤ」と「検索対象チケット情報」等を含む。本実施形態では、「顧客ＩＤ」には、第１の検索要求データ１５０１に含まれる「ユーザＩＤ」に関連付けられた、チケット検索を行うユーザ（従業員）を航空会社が識別するためのＩＤ及び該ユーザ（従業員）が属する企業の企業コード等が挿入され、「検索要求ＩＤ」、「検索対象チケット供給者」、「検索対象チケット情報」には、第１の検索要求データ１５０１に含まれる「検索要求ＩＤ」、「検索対象チケット供給者」、「検索対象チケット情報」が挿入される。第２の検索要求データ１５０２に含まれる「検索対象チケット供給者」及び「検索対象チケット情報」と、第１の検索要求データ１５０１に含まれる「検索対象チケット供給者」及び「検索対象チケット情報」は、異なる形式であっても良い。
【０２０６】
又、図１６に、前記関連付け部１０２１の一例を示す。関連付け部１０２１は、「ユーザＩＤ」と「検索対象チケット供給者」と「顧客ＩＤ」とを関連付けるものである。
【０２０７】
検索要求データ送信手段１０２３は、第１の検索要求データ１５０１に含まれる「ユーザＩＤ（企業コード及び従業員ＩＤ）」と「検索対象チケット供給者（航空会社名）」との組み合わせから、関連付け部１０２１を検索し、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定する。そして、この「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を含み、第１の検索要求データ１５０１に含まれる「検索対象チケット供給者（航空会社名）」及び「検索対象チケット情報（搭乗日、出発時刻、出発地、到着地等）」に応じた第２の検索要求データ１５０２を生成する。「検索対象チケット供給者」に複数の航空会社名が含まれている場合、「ユーザＩＤ（企業コード及び従業員ＩＤ）」と「検索対象チケット供給者（航空会社名）」との組み合わせ毎に「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定し、この「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」をそれぞれ含む複数の第２の検索要求データ１５０２を生成する。その後、第２の検索要求データ１５０２に含まれる「検索対象チケット供給者（航空会社名）」に基づいて、該第２の検索要求データ１５０２の宛先の航空会社を選定し、該第２の検索要求データ１５０２を、該選定された航空会社のチケット予約システム１０３０に送信する。
【０２０８】
例えば、図１６に示す例では、第１の検索要求データ１５０１において、「ユーザＩＤ＝００１」、「検索対象チケット供給者＝００１、００２」である。この場合、関連付け部２１を検索し、（ユーザＩＤ，検索対象チケット供給者）＝（００１，００１）及び（ユーザＩＤ，検索対象チケット供給者）＝（００１，００２）に対応する「顧客ＩＤ」を決定する。その結果に基づいて「顧客ＩＤ＝×××」を含む第２の検索要求データ１５０２と、「顧客ＩＤ＝○○○」を含む第２の検索要求データ１５０２とが生成される。
【０２０９】
検索結果情報提示手段１０２４は、各航空会社が生成した、複数の検索結果レコード１６０１を受信する。各検索結果レコード１６０１は、「検索要求ＩＤ」、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」、「チケット供給者（航空会社名）」、「チケット情報（搭乗日、出発時刻、到着時刻、出発地、到着地、便名、機種、空席状況、料金等）」を含む。そして、関連付け部１０２１を用いて、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」と「チケット供給者（航空会社名）」の組み合わせ毎に、対応する「ユーザＩＤ（企業コード及び従業員ＩＤ）」を決定し、各検索結果レコード１６０１の「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」をこの「ユーザＩＤ（企業コード及び従業員ＩＤ）」で置換し、新しい検索結果レコード１６０１ａを生成する。そして、同一の「検索要求ＩＤ」と「ユーザＩＤ」との組み合わせを有する検索結果レコード６０１ａを統合して、検索結果情報１６０２を生成し、該当する従業員の属する企業の予約システム１０１０に送信する。
【０２１０】
なお、第３の実施の形態管理機構により、検索結果レコード１６０１ａが、第１の検索要求データ１５０１に対応することが把握できる場合は、関連付け部１０２１を検索せずに、一時的に記憶しておいた第１の検索要求データ１５０１内の「ユーザＩＤ」で、検索結果レコード１６０１内の「顧客ＩＤ」を置換し、新しい検索結果レコード１６０１ａを生成しても良い。又、この場合、「検索要求ＩＤ」を有することなく、検索結果情報１６０２を生成することができるため、第１の検索要求データ１５０１、第２の検索要求データ１５０２、検索結果レコード１６０１、１６０１ａ及び検索結果情報１６０２に、「検索要求ＩＤ」を含まなくても良い。
【０２１１】
航空会社の予約システム１０３０は、第２の検索要求データ１５０２を受信する検索要求データ受信手段１０３１と、検索結果レコード１６０１を生成し、前記サーバ装置１０２０に送信する検索結果レコード送信手段１０３２を備える。
【０２１２】
航空会社は、第２の検索要求データ１５０２の「顧客ＩＤ」を用いて、独自の顧客ＤＢを検索し、座席の好みや、予約優先ランク、企業名などを調べた後、できるだけその条件に合った空席情報を検索したり、大口割引や年間割引などの契約があるかを調べたりした上で、空席情報及び料金等の「チケット情報」をサーバ装置１０２０に送信することもできる。
【０２１３】
旅行代理店におけるサーバ装置１０２０と企業における予約システム１０１０との通信は、専用線を用いたクローズドシステムで構成されることもあれば、インターネットを用いたオープンシステムで構成されることもある。後者の場合は、旅行代理店が仲介していることを明示するために、第２の検索要求データに１５０２に「旅行代理店ＩＤ」を付加することもできる。
【０２１４】
（第３の実施の形態に係る電子商取引システムの動作）
上記構成を有する電子商取引システムの動作は、以下の手順により実施することができる。図１８は、本実施形態に係る電子用取引システムの動作を示すタイムチャート図である。本実施形態に係る電子商取引システムによって、航空券、ホテル宿泊券、レンタカーチケット等、多岐に渡るチケット検索を行うことが可能であるが、本実施形態においては、航空券の検索の例について説明する。
【０２１５】
図１８に示すように、ステップＳ１１０１において、企業における従業員（ユーザ）が、企業の予約システム１０１０、例えば汎用パソコン上のＷＷＷブラウザを操作して、サーバ装置１０２０に接続（ログイン）する。ここでは、ＷＷＷブラウザを使用することを想定するが、本発明は、ＷＷＷブラウザを使用したものに限定されない。該サーバ装置１０２０は、企業グループの旅行代理店（インハウスエージェント）、企業内、航空会社側のいずれに設置されても良い。
【０２１６】
この際、該サーバ装置１０２０は、該従業員が、当該電子商取引システムの正規ユーザであることをパスワード等による認証手段を用いて確認することも可能である。
【０２１７】
ステップＳ１１０２において、サーバ装置１０２０は、チケットを検索するために必要なデータ項目の入力を従業員に促す「チケット検索条件入力画面」を、企業の予約システム１０１０のＷＷＷブラウザ上に提示する。「チケット検索条件入力画面」において入力するデータ項目は、旅行代理店のサーバ装置１０２０が独自に保存している情報から構成しても良いし、航空会社の予約システム１０３０に問い合わせて構成しても良い。例えば、従業員が、航空券検索を行うために、「チケット検索条件入力画面」上で入力するデータ項目としては、企業コード、従業員ＩＤ、航空会社名、出張番号、搭乗日、出発時刻、出発地、到着地等が挙げられる。
【０２１８】
ステップＳ１１０３において、従業員は、表示された「チケット検索条件入力画面」に従って、検索条件情報を指定する。
【０２１９】
ステップＳ１１０４において、企業の予約システム１０１０の検索要求データ送信手段１０１１が、入力されたデータ項目に応じて、「検索要求ＩＤ」、「ユーザＩＤ（企業コード及び従業員ＩＤ）」、「検索対象チケット供給者（航空会社名）」、「チケット情報」等を含む第１の検索要求データ１５０１をサーバ装置１０２０に送信し、サーバ装置１０２０の検索要求データ受信部１０２２が、該第１の検索要求データ１５０１を受信する。第１の検索要求データ１５０１は、任意の形式で良い。
【０２２０】
ステップＳ１１０５において、サーバ装置１０２０の検索要求データ送信部１０２３が、受信した第１の検索要求データ１５０１に含まれる「ユーザＩＤ（企業コード及び従業員ＩＤ）」と「検索対象チケット供給者（航空会社名）」との組み合わせに基づき、関連付け部１０２１を検索し、対応する「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定する。
【０２２１】
ステップＳ１１０６において、検索要求データ送信部１０２３は、「検索要求ＩＤ」、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」、「検索対象チケット供給者（航空会社名）」、「検索対象チケット情報（搭乗日、出発時刻、出発地、到着地等）」を含む第２の検索要求データ１５０２を生成し、「検索対象チケット供給者（航空会社名）」が示す航空会社の予約システム１０３０に送信し、航空会社の予約システム１０３０の検索要求データ受信手段１０３１が、該第２の検索要求データ１５０２を受信する。第２の検索要求データ１５０２に含まれる「検索対象チケット供給者」及び「検索対象チケット情報」と、第１の検索要求データ１５０１に含まれる「検索対象チケット供給者」及び「検索対象チケット情報」は、異なる形式であっても良い。
【０２２２】
第１の検索要求データ１５０１の「検索対象チケット供給者（航空会社名）」に複数の航空会社名が含まれている場合、航空会社毎に、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定し、それに応じて第２の検索要求データ１５０２を生成する。
【０２２３】
ステップＳ１１０７において、航空会社の予約システム１０３０が、それぞれ、受信した第２の検索要求データ１５０２に応じて、「検索要求ＩＤ」、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」、「チケット供給者（航空会社名）」、「チケット情報」を含む検索結果レコード１６０１を生成し、各航空会社の予約システム１０３０の検索結果レコード送信手段１０３２が、該検索結果レコード１６０１を、前記サーバ装置１０２０に送信し、前記サーバ装置１０２０の検索情報提示手段１０２４が、該検索結果レコード１６０１を受信する。
【０２２４】
ステップＳ１１０８において、検索情報提示手段１０２４は、各検索結果レコード１６０１に含まれる「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」と「チケット供給者（航空会社名）」の組み合わせから、関連付け部１０２１を検索し、対応する「ユーザＩＤ（企業コード及び従業員ＩＤ）」を決定し、該検索結果レコード１６０１の「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」をこの「ユーザＩＤ（企業コード及び従業員ＩＤ）」で置換し、新しい検索結果レコード１６０１ａを生成する。
【０２２５】
ステップＳ１１０９において、前記新しい検索結果レコード１６０１ａを、「検索要求ＩＤ」と「ユーザＩＤ」との組み合わせ毎に統合して、検索結果情報１６０２を生成し、該当する従業員の属する企業の予約システム１０１０に送信する。
【０２２６】
ステップＳ１１１０において、企業の予約システム１０の検索結果情報受信手段１０１２が、該検索結果情報１６０２を受信し、汎用パソコンの画面上に、その内容を一覧表示する。
【０２２７】
（第３の実施の形態に係る電子商取引システムによる作用及び効果）
本実施形態では、サーバ装置１０２０を設けたことにより、チケットレス方式でチケット供給者が企業の従業員にチケットを販売する電子商取引システムにおいて、企業が従業員を識別するための従業員ＩＤと、航空会社がユーザを識別するための顧客ＩＤを別々にすることができる。従って、企業が、従業員ＩＤ等の企業内情報を提供することなく、航空会社による従業員毎にカスタマイズされた検索結果を得ることができる。例えば、予め登録してある座席位置の好みをできるだけ優先して検索することができる。又、企業における従業員が、単一の従業員ＩＤを用いて、複数の航空会社にまたがってチケットの検索を行ったり、航空会社とホテル等を組にして、チケットの検索を行ったりすることができる。後者は、航空会社に空席情報を問い合わせ、ホテルに対して空き部屋情報を問い合わせ、両方が確保できる場合のみ予約したい場合などに有効である。従業員は、航空会社とホテルに登録したそれぞれの顧客ＩＤを入力する必要はなく、単一の従業員ＩＤで検索できるというメリットがある。更に、複数の航空会社と複数のホテルを同時に検索することも可能である。
【０２２８】
以上説明したように本発明の第３の実施の形態によれば、チケット供給者が、チケットレス方式で、企業のユーザにチケットを販売することができるため、旅行代理店にとって、チケットを発行し配布するコストを削減して収益を上げることができるというメリットが生じ、それによって、チケット供給者にとっても、旅行代理店に対して支払う手数料を従来より低くすることができるというメリットが生じる。
【０２２９】
つまり、本発明によれば、旅行代理店は、従来の発券手数料の代わりに、少なくとも、企業からのチケット申込をチケット供給者に紹介し、代金回収を行うことに対する販売手数料をチケット供給者から得る。この販売手数料は、本発明によって、企業がユーザを識別するためのユーザＩＤとチケット供給者がユーザを識別するための顧客ＩＤを、分離しつつ相互に関連付けられるようにすることによって、申込から精算までを自動化することができ、その結果、取次ぎ、チケット発券／配布、代金回収のコストを画期的に下げることによる付加価値への対価である。
【０２３０】
又、企業及びチケット供給者の双方が、独自に管理するＩＤを用いることができるため、企業にとっては、チケット供給者に企業機密情報を漏らすことなく、自社の経理システムと連携した自動精算処理が可能となるというメリットが生じ、チケット供給者にとっては、企業内情報の変更に追随する必要がなくなるというメリットがある。
【０２３１】
更に、企業にとっては、チケット管理システムの管理する顧客ＩＤを管理することなく、大口割引の適用を受けることができるというメリットが生じ、チケット購入者にとっては、企業単位で精算されるにもかかわらず、チケット供給者からユーザ毎に適したサービスの提供を受けることができるというメリットが生じる。
【０２３２】
（第４の実施の形態）
本発明の第４の実施の形態について図１９を参照しながら説明する。図１９は、本実施形態に係る電子商取引システムを示す概略構成図である。本実施形態に係る電子商取引システムは、企業の予約システム１０１０、サーバ装置１０２０、複数のチケット供給者（航空会社）の予約システム１０３０から構成される。
【０２３３】
本実施形態では、この電子商取引システムによって、ユーザ群（企業）におけるユーザ（従業員）が、自身の従業員ＩＤを用いて、チケット供給者が供給するチケットの申込を行う。本実施形態では、企業（ユーザ群）の従業員（ユーザ）が、航空会社（チケット供給者）に対して、航空券（チケット）の申込を行う場合を例に説明する。
【０２３４】
企業における従業員がチケット申込のために使用する企業の予約システム１０１０は、ユーザＩＤ及び申込チケット条件情報を含む第１の申込データを送信する申込データ送信手段１０１３と、申込結果データを受信する申込結果データ受信手段１０１４とを更に備える。申込データ送信手段１０１３及び申込結果データ受信手段１０１４は、企業における汎用パソコンに搭載されたＷＷＷブラウザ等で構成される。申込データ送信手段１０１３及び申込結果データ受信手段１０１４は、検索要求データ送信手段１０１１と検索結果情報受信手段１０１２と同一の汎用パソコンで構成されても良い。
【０２３５】
図２０に、第１の申込データ１９０１の一例を示す。第１の申込データ１９０１は、「申込ＩＤ」、「ユーザＩＤ」、及び、申込チケット情報として「申込対象チケット供給者ＩＤ」と「申込対象チケット情報」等を含む。本実施形態では、「申込ＩＤ」には、チケット申込を行う従業員が入力する出張番号が挿入され、「ユーザＩＤ」には、該従業員の従業員ＩＤ及び該従業員が属する企業の企業コード等が挿入され、「申込対象チケット供給者」には、航空会社名が挿入される。又、「申込対象チケット情報」には、搭乗日、便名、搭乗クラス等が挿入される。
【０２３６】
第１の申込データ１９０１は、任意の形式で良く、企業における汎用パソコンに搭載されたＷＷＷブラウザによってフォーム形式で送信されても良いし、企業の予約システム１０１０とサーバ装置１０２０との間の通信リンク上で送信されても良い。
【０２３７】
申込結果データ２００１は、「申込チケット情報」として、例えば、搭乗日、出発時刻、到着時刻、出発地、到着地、便名、機種、搭乗クラス、座席情報、料金等を含む。企業の予約システム１０は、受信した申込結果情報２００１に応じて、汎用パソコンの画面上に、その内容を表示する。
【０２３８】
本実施形態に係るサーバ装置１０２０は、第１の申込データ１９０１を受信する申込データ受信部１０２５と、該第１の申込データ１９０１に応じて、第２の申込データ１９０２を生成し、該第２の申込データ１９０１の宛先の航空会社を選定し、該選定された航空会社に該第２の申込データを送信する申込データ送信部１０２６と、申込結果データ２００１を前記ユーザに提示する申込結果データ提示部１０２７とを更に備える。申込データ受信部１０２５及び申込結果データ提示部１０２７は、ＷＷＷサーバ等で構成される。申込データ受信部１０２５及び申込結果データ提示部１０２７は、検索要求データ受信部１０２１と検索結果情報提示部１０２４と同一の汎用パソコンで構成されても良い。
【０２３９】
図２０に、第２の申込データ１９０２の一例を示す。第２の申込データ１９０２は、「申込ＩＤ」、「顧客ＩＤ」、及び、申込チケット情報としての「申込対象チケット供給者ＩＤ」と「申込対象チケット情報」等を含む。本実施形態では、「顧客ＩＤ」には、第１の申込データ１９０１に含まれる「ユーザＩＤ」に関連付けられた、チケット申込を行う従業員を航空会社が識別するＩＤ及び該従業員が属する企業の企業コード等が挿入され、「申込ＩＤ」、「申込対象チケット供給者」、「申込対象チケット情報」には、第１の申込データ１９０１に含まれる「申込ＩＤ」、「申込対象チケット供給者」、「申込対象チケット情報」が挿入される。第２の申込データ１９０２に含まれる「申込対象チケット供給者」及び「申込対象チケット情報」と、第１の申込データ１９０１に含まれる「申込対象チケット供給者」及び「申込対象チケット情報」は、異なる形式であっても良い。
【０２４０】
申込データ送信手段１０２６は、第１の申込データ１９０１に含まれる「ユーザＩＤ（企業コード及び従業員ＩＤ）」と「申込対象チケット供給者（航空会社名）」との組み合わせから、関連付け部１０２１を検索し、「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定する。そして、この「顧客ＩＤ」を含み、第１の申込データ１９０１に含まれる「申込対象チケット供給者（航空会社名）」及び「申込対象チケット情報」に応じた第２の申込データ１９０２を生成する。その後、第２の申込データ１９０２に含まれる「申込対象チケット供給者（航空会社名）」に基づいて、該第２の申込データ１９０２の宛先の航空会社を選定し、該第２の申込データ１９０２を、該選定された航空会社のチケット予約システム１０３０に送信する。
【０２４１】
申込結果データ提示手段１０２７は、航空会社が生成した申込結果データ２００１を受信する。申込結果データ２００１は、「申込ＩＤ」、「顧客ＩＤ」、「チケット供給者（航空会社名）」、「申込チケット情報」を含む。そして、「顧客ＩＤ」と「チケット供給者（航空会社名）」の組み合わせによって、関連付け部１０２１を検索して、対応する「ユーザＩＤ」を決定し、申込結果データ２００１を、該「ユーザＩＤ」が示す従業員の属する企業の予約システム１０１０に送信する。送信する際に、申込結果データ２００１内の「顧客ＩＤ」を、該決定された「ユーザＩＤ」で置換する。
【０２４２】
なお、第３の実施の形態管理機構により、申込結果データ２００１が、第１の申込データ１９０１に対応することが把握できる場合は、関連付け部１０２１を検索せずに、一時的に記憶しておいた第１の申込データ１９０１内の「ユーザＩＤ」を用いても良い。又、この場合、「申込ＩＤ」を有することなく、申込結果データ２００１の送信先を決定することができるため、第１の申込データ１９０１、第２の申込データ１９０２、申込結果データ２００１に、「申込ＩＤ」を含まなくても良い。
【０２４３】
航空会社の予約システム１０３０は、第２の申込データ１９０２を受信する申込データ受信手段１０３３と、申込結果データ２００１を生成し、前記サーバ装置１０２０に送信する申込結果データ送信手段１０３４を備える。
【０２４４】
（第４の実施の形態に係る電子商取引システムの動作）
上記構成を有する電子商取引システムの動作は、以下の手順により実施することができる。図２１は、本実施形態に係る電子用取引システムの動作を示すタイムチャート図である。
【０２４５】
図２１に示すように、ステップＳ１２０１において、前記ステップＳ１１１０で表示された検索条件情報に合致するチケット（航空券）の一覧に応じて、若しくは、広告メールや出張指示メール等に含まれた検索結果情報に相当するデータ（例えばＵＲＬ）に応じて、企業における従業員が、購入したいチケット（航空券）を選択する。このとき、企業の予約システム１０１０は、「ユーザＩＤ（企業コード及び従業員ＩＤ）」を、ログイン時に従業員が入力した「ユーザＩＤ（企業コード及び従業員ＩＤ）」をクッキーなどの第３の実施の形態管理機構から取り出すか、チケット申込用の入力データ項目として明示的に従業員に再度入力を促すかして取得する。
【０２４６】
ステップＳ１２０２において、企業の予約システム１０１０の申込データ送信手段１０１３が、選択された航空券に係る情報及び入力されたデータ項目に応じて、「申込ＩＤ」、「ユーザＩＤ（企業コード及び従業員ＩＤ）」、「申込対象チケット供給者（航空会社名）」、「申込対象チケット情報」等を含む第１の申込データ１９０１をサーバ装置１０２０に送信し、サーバ装置１０２０の申込データ受信部１０２５が、該第１の申込データ１９０１を受信する。第１の申込データ１９０１は、任意の形式で良い。
【０２４７】
ステップＳ１２０３において、サーバ装置１０２０の申込データ送信部１０２６が、受信した第１の申込データ１９０１に含まれる「ユーザＩＤ（企業コード及び従業員ＩＤ）」と「申込対象チケット供給者（航空会社名）」との組み合わせに基づき、関連付け部１０２１を検索し、対応する「顧客ＩＤ（企業コード及び航空会社管理用ＩＤ）」を決定する。
【０２４８】
ステップＳ１２０４において、申込データ送信部１０２６は、「申込ＩＤ」、「顧客ＩＤ」、「申込対象チケット供給者（航空会社名）」、「申込対象チケット情報」等を含む第２の申込データ１９０２を生成し、「申込対象チケット供給者（航空会社名）」が示す航空会社の予約システム１０３０に送信し、該航空会社の予約システム１０３０の申込データ受信手段１０３３が、該第２の申込データ１９０２を受信する。第２の申込データ１９０２に含まれる「申込対象チケット供給者」及び「申込対象チケット情報」と、第１の申込データ１９０１に含まれる「申込対象チケット供給者」及び「申込対象チケット情報」は、異なる形式であっても良い。
【０２４９】
ステップＳ１２０５において、航空会社の予約システム１０３０の申込結果データ送信手段１０３４が、受信した第２の申込データ１９０２に応じて、「申込ＩＤ」、「顧客ＩＤ」、「チケット供給者（航空会社名）」、「申込チケット情報」等を含む申込結果データ２００１を生成し、該申込結果データ２００１を、前記サーバ装置１０２０に送信し、前記サーバ装置１０２０の申込結果データ提示部１０２７が、該申込結果データ２００１を受信する。
【０２５０】
ステップＳ１２０６において、申込結果データ提示部１０２７は、申込結果データ２００１に含まれる「顧客ＩＤ」と「チケット供給者（航空会社名）」の組み合わせに基づき、関連付け部１０２１を検索し、対応する「ユーザＩＤ」を決定し、該「ユーザＩＤ」が示すユーザが属する企業の予約システム１０１０に、該申込結果データ２００１を送信し、企業の予約システム１０１０の申込結果データ受信手段１０１４が、該申込結果データ２００１を受信する。
【０２５１】
ステップＳ１２０７において、企業の予約システム１０１０の申込結果データ受信手段１０１４が、受信した該申込結果データ２００１に応じて、ＷＷＷブラウザ上に、その内容を表示する。
【０２５２】
ステップＳ１２０８において、チケットの申込をした従業員は、空港、ホテル、或いはそれに代わる発券装置の設置場所等において、チケットの発券を受ける。その際に、正当な申込者であることを証明するために認証が必要である。本発明では、その具体的な方法は特に規定しない。例えば、特開平１１−３３９０７６号公報に開示されているようなＩＤカードを用いて、従業員ＩＤ及び企業コードを提示する方法、申込成立時に発行される乱数を提示する方法、申込成立時に携帯電話やＰＤＡなどの携帯型コンピュータに乱数などの認証情報を記憶させておき、発券時に、該携帯型コンピュータの画面上に表示したバーコードを読み取らせたり、接触や無線（Ｂｌｕｅｔｏｏｔｈなど）で認証データを直接転送したりする方法が考えられる。
【０２５３】
（第４の実施の形態に係る電子商取引システムによる作用及び効果）
本実施形態では、サーバ装置１０２０を設けたことにより、チケットレス方式でチケット供給者が企業の従業員にチケットを販売する電子商取引システムにおいて、企業が従業員を識別するための従業員ＩＤと、航空会社がユーザを識別するための顧客ＩＤを別々にすることができる。従って、企業が、従業員ＩＤ等の企業内情報を提供することなく、航空会社が、個人毎に適応したサービスを提供することができる。例えば、一定の利用実績があるユーザに対して座席のアップグレードを提供したりすることでユーザを惹きつけることも可能である。
【０２５４】
（第５の実施の形態）
本発明の第５の実施の形態について図２２を参照しながら説明する。図２２は、本実施形態に係る電子商取引システムを示す概略構成図である。本実施形態に係る電子商取引システムは、ユーザ群（企業）の予約システム１０１０、サーバ装置１０２０、複数のチケット供給者（航空会社）の予約システム１０３０、チケット供給者（航空会社）のチケット代金請求システム１０４０、企業の経理システム１０５０から構成される。
本実施形態では、この電子商取引システムによって、チケット供給者（航空会社）が、旅行代理店（インハウスエージェント）のサーバ装置１０２０を介して、ユーザ群（企業）に対してチケット代金の請求を行う。本実施形態では、チケット供給者（航空会社）が、月単位や週単位等の一定期間毎、或いは、チケットの販売時点毎に、旅行代理店（インハウスエージェント）にチケット代金を請求し、旅行代理店（インハウスエージェント）が、月単位や週単位等の一定期間毎、或いは、チケットの販売時点毎に、ユーザ群（企業）の経理システム１０５０と連動してチケット代金請求を行う場合を例として説明する。
航空会社が企業に対してチケット代金を請求するための航空会社のチケット代金請求システム１０４０は、企業の従業員に販売したチケットの情報を記憶するチケット販売情報記憶手段１０４１と、チケット販売情報に基づき第１の請求データを生成し送信する請求データ送信手段１０４２とを備える。チケット販売情報には、例えば、顧客ＩＤ、出張番号、出発日及び便名等を含む利用実績情報、利用料金、請求先情報等が含まれる。
第１の請求データ２１０１は、「請求データＩＤ」、「顧客ＩＤ」、「チケット供給者（航空会社名）」、「利用料金」等を含む。本実施形態において、「請求データＩＤ」には、チケット申込時に入力された出張番号が挿入される。第１の請求データ２１０１に含まれ得るデータ項目の一例を図２３に示す。
本実施形態に係るサーバ装置１０２０は、第１の請求データ２１０１を受信する請求データ受信部１０２８と、該第１の請求データ２００１に応じて、前記顧客ＩＤに関連付けられたユーザＩＤを含む第２の請求データ２１０２を生成し、前記ユーザＩＤに基づいて、該第２の請求データ２１０２の宛先の企業を選定し、該選定された企業に該第２の請求データ２１０２を送信する請求データ送信部１０２９とを更に備える。
企業の経理システム１０５０は、第２の請求データを受信する請求データ受信手段１０５１と、従業員ＩＤ毎の情報を記憶する従業員情報記憶手段１０５２とを備える。
（第５の実施の形態に係る電子商取引システムの動作）
上記構成を有する電子商取引システムの動作は、以下の手順により実施することができる。図２４は、本実施形態に係る電子用取引システムの動作を示すタイムチャート図である。
図２４に示すように、ステップＳ１３０１において、航空会社のチケット代金請求システム１０４０が、チケット販売情報記憶手段１０４１に記憶されたチケット販売情報に応じて、「顧客ＩＤ」毎に第１の請求データ２１０１を生成し、サーバ装置１０２０に送信し、サーバ装置１０２０の請求データ受信部１０２８が、該第１の請求データ２１０１を受信する。
航空会社のチケット代金請求システム１０４０は、前記第１の請求データ２１０１の生成及び送信を、月単位や週単位等の一定期間毎に、或いは、チケットの販売の時点毎に行うことができる。
ステップＳ１３０２において、第１の請求データ２１０１内の「顧客ＩＤ」と「チケット供給者（航空会社名）」の組み合わせに基づき、関連付け部１０２１を検索し、対応する「ユーザＩＤ」を決定する。
ステップＳ１３０３において、「ユーザＩＤ」をキーに、企業の経理システム１０５０の従業員情報記憶手段１０５２に記憶された「従業員情報」を獲得する。「従業員情報」には、例えば、当該従業員のチケット代金について経理処理を行う所属部課コード等が含まれる。
ステップＳ１３０４において、サーバ手段１０２０の請求データ送信部１０２９が、第 １の請求データ２１０１に応じて、「ユーザＩＤ」、「従業員情報」等を含む第２の請求データ２１０２を生成し、企業の経理システム１０５０に送信し、企業の経理システム１０５０の請求データ受信手段１０５１が、該第２の請求データ２１０２を受信する。
ステップＳ１３０５において、企業の経理システム１０５０は、受信した第２の請求データ２１０２に応じて、経理処理を行う。
（第５の実施の形態に係る電子商取引システムによる作用及び効果）
本実施形態では、サーバ装置１０２０を設けたことにより、チケットレス方式でチケット供給者が企業の従業員にチケットを販売する電子商取引システムにおいて、企業が従業員を識別するための従業員ＩＤと、航空会社がユーザを識別するための顧客ＩＤを別々にすることができる。従って、航空会社は、従業員ＩＤ等の企業内情報を意識することなく、自身の管理する顧客ＩＤを用いて、企業単位で一括してチケット代金を請求することができ、企業は、既存の経理システムを用いて経理処理を行うことができる。
（変更例１）
なお、前記サーバ装置１０２０の設置場所としては、図２５に示す３通りがある。
第１に、チケット供給者と企業の中間に位置する企業グループ内の旅行代理店（インハウスエージェント）に設置する場合がある。この構成は、本発明の基本形であり、上述したようなメリットがある。更に、企業グループ内では、比較的似た体系の従業員ＩＤが用いられることが多いので、該旅行代理店は、サーバ装置２０を構成しやすいというメリットもある。
第２に、企業に、サーバ装置１０２０を設置する場合がある。企業の外部に企業内情報が出ないので、企業グループとは関係のない旅行代理店を活用したり、チケット供給者と直接取引をしたりすることも可能である。ただし、組織別のきめ細かい精算処理は実現できない。
第３に、チケット供給者に、サーバ装置１０２０を設置する場合がある。この方法は、チケット供給者が、既存の予約システム４０では扱えないＩＤを扱えるようにすることが主目的となる。
（変更例２）
又、サーバ装置１０２０を用いることにより、従業員の選択肢を広げるだけでなく、従業員に特定のチケット供給者を利用するように強いることもできる。企業が、出張費等のコスト削減を主目的として、特定のチケット供給者と大口契約或いは年間契約を結び、それ以外の選択肢を使わなくすることにより低価格でチケットを供給してもらうという契約形態がある。このためには、従業員が、契約外のチケット供給者を指定した場合でも、まず所定のチケット供給者に対してチケット申込の可能性を問い合わせる必要がある。本発明のサーバ装置１０２０に、所定のチケット供給者が識別するための顧客ＩＤを、全従業員に対して登録しておき、チケット検索及び申込時に、その顧客ＩＤを優先して選択することで容易に実現できる。又、契約を別のチケット供給者に切り替えたい場合には、サーバ装置１０２０に新しい顧客ＩＤを登録したり、古い顧客ＩＤを抹消するなどの集中操作により、容易に切り替えることができる。
（変更例３）
更に、企業グループ内の旅行代理店（インハウスエージェント）を持たない企業に対して、同様のサービスを提供する契約法人型の旅行代理店にも、本発明を適用することができる。規模の小さい企業を多数集めて、大きな企業グループと同様のバーゲニングパワーを得てチケット供給者と割引交渉をすることが考えられる。更に、頻繁に旅行する個人を集めて、同様のサービスを提供することもできる。この場合は、個人ＩＤの漏洩防止よりも、複数のチケット供給者にまたがってチケットの検索・申込ができることが主なメリットとなる。
（その他の実施の形態）
上記のように、本発明第１乃至第５の実施の形態によって記載したが、この開示の一部をなす論述及び図面はこの発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかとなろう。
【０２５５】
本発明の実施の形態として、企業に所属するユーザが、出張における交通機関及びホテルを利用する役務を予約し、精算を行う場合について説明したが、本発明におけるユーザ及び役務はこれに限られない。例えば、ユーザは、個人でも構わないし、組合や企業に所属していても構わない。又、役務は、商品購入でも構わない。このように、あらゆる状況に対応することができる。
【０２５６】
又、本発明の実施の形態においては、ある顧客企業システム及びサプライヤ予約システムの運用をモデルとして、そのモデルに適合するように、管理サーバは機能している。しかし、管理サーバはその基本的な機能を変更することなく、顧客企業システム及びサプライヤ予約システムに対して備えられるＡＰＩを変更することにより、あらゆる顧客企業システム及びサプライヤ予約システムに対して適用が可能である。
【０２５７】
更に、本発明の実施の形態においては、全ての予約処理を、交通機関予約システムに問い合わせすることにより行ったが、要求の多い交通機関やホテルについては、管理サーバで適当な数の席数或いは部屋数を、予め保有していても構わない。その場合、ユーザからの予約の要求については、管理サーバが保有している席或いは部屋を表示しても良い。又、ホテル予約システムと交通機関予約システムは同一のシステム上に構築されていても構わない。具体的には、旅行代理店等が運営している、出張全般で必要とされる役務についての予約システムでも構わない。
【０２５８】
更に、本発明の実施の形態においては、管理サーバと共通ＤＢサーバをそれぞれ別のハードウェア構成上を持つと記載したが、同一のハードウェアに管理サーバと共通ＤＢサーバの機能を備えても良い。即ち、管理サーバに、データベース管理手段及びデータが記憶されている記憶装置を備えても良い。
【０２５９】
この様な、本発明はここでは記載していない様々な実施の形態等を含むことは勿論である。従って、本発明の技術的範囲は上記の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【０２６０】
【発明の効果】
本発明によれば、ユーザが、役務の予約を容易に行うことのできる電子商取引管理サーバ及び電子商取引管理方法を提供することができる。
【図面の簡単な説明】
【図１】 本発明の第１の実施の形態に係る電子商取引システムを示すシステム構成図である。
【図２】 図１で記載した本発明の第１の実施の形態に係る電子商取引システムにおける各ハードウェア構成要素について、詳細に記述したシステム構成図である。
【図３】 本発明の第１の実施の形態に係る電子商取引システムにおける出張管理のフローチャートを示した図である。
【図４】 本発明の第２の実施の形態に係る管理サーバの機能ブロック図である。
【図５】 本発明の第２の実施の形態における管理サーバの処理を示すフローチャートである。
【図６】 本発明の第２の実施の形態における管理サーバのセション管理部によるセション管理について説明する図である。
【図７】 本発明の第２の実施の形態における図７（ａ）は、スイッチング手段との２フェーズコミットのシステム図で、図７（ｂ）は処理フローを示すフローチャートである。
【図８】 本発明の第２の実施の形態における顧客企業システムが備えている、ユーザの情報を管理する画面群である。
【図９】 図８（ｃ）に示した画面において「チケット手配」ボタンＢ１０２がクリックされて、最初に表示する画面である。
【図１０】 検索条件に該当した交通機関の空席状況を一覧で表示する画面である。
【図１１】 ユーザが行った予約の確認事項を表示する画面である。
【図１２】 正常に予約完了した場合に示す、予約完了画面である。
【図１３】 ユーザが予約した役務を一覧表示する画面である。
【図１４】 ユーザが予約した役務を取り消す予約取消確認画面である。
【図１５】 本発明の第３の実施の形態に係る電子商取引システムの概略機能を示すブロック図である。
【図１６】 本発明の第３の実施の形態に係る第１の検索要求データ及び第２の検索要求データの一例を示す図である。
【図１７】 本発明の第３の実施の形態に係る検索結果レコード及び検索結果情報の一例を示す図である。
【図１８】 本発明の第３の実施の形態に係る電子商取引システムにおいて、企業におけるユーザがチケット供給者に対してチケットの検索を行う動作を示すタイムチャート図である。
【図１９】 本発明の第４の実施の形態に係る電子商取引システムの概略機能を示すブロック図である。
【図２０】 本発明の第４の実施の形態に係る第１の申込データ及び第２の申込データ示すブロック図である。
【図２１】 本発明の第４の実施の形態に係る電子商取引システムにおいて、企業におけるユーザがチケット供給者に対してチケットの申込を行う動作を示すタイムチャート図である。
【図２２】 本発明の第５の実施の形態に係る電子商取引システムの概略機能を示すブロック図である。
【図２３】 本発明の第５の実施の形態に係る第１の請求データに含まれ得るデータ項目の一例を示す図である。
【図２４】 本発明の第５の実施の形態に係る電子商取引システムにおいて、チケット供給者が、チケット代金の請求を行う動作を示すタイムチャート図である。
【図２５】 本発明の第５の実施の形態の１変更例に係る電子商取引システムの概略機能を示すブロック図である。
【図２６】 従来のチケット販売方法の概要を示すブロック図である。
【図２７】 従来のチケット販売方法の概要を示すブロック図である。
【図２８】 従来のチケット販売方法の概要を示すブロック図である。
【図２９】 従来のチケットの検索及び申込におけるシステム構成図である。
【図３０】 従来のチケットの検索及び申込における利用者及び旅行代理店の作業を示す図である。
【符号の説明】
１ サプライヤ予約システム
２ 管理サーバ
３、４ 管理端末
５ 顧客企業システム
６ 共通ＤＢサーバ
１１ ホテル予約システム
１２ 交通機関予約システム
１３、１４、２７、２８、２９ ＡＰＩ
１５、１６ 予約ＤＢ
１７ 移動実績・請求情報
２０ スイッチング手段
２１ 接続制御部
２２ メッセージ解析部
２３ａ、２３ｂ、２３ｃ 接続モジュール
２６ 基幹管理手段
３１ 管理画面
４１ 管理画面
５１ ネット予約サーバ
５２ Java（登録商標）ライブラリ
５３ 予約画面
５４ ＣＣ用予約画面
５５ 管理画面
５６ 個人・部課認証データ
５７ ツーリスト旅行システム
５８ 経理システム
５９ 出張申請システム
２０１ ＡＳＰ接続管理部
２０２ ログ記録部
２０３ 要求解読部
２０４ 要求処理部
２０５ ＡＣＬ部
２０６ 認証部
２０７ ＩＤ変換部
２０８ 接続サプライヤ判断部
２０９ メモリデータ管理部
２１０ メモリ
２１１ 更新通知処理部
２１２、３０８ ＤＢ接続部
２１４ 予約情報記録／検索部
２１５ システムアクセス数記録／検索部
２１６ プロトコル変換部
２１７ サプライヤ接続管理部
２１８ 応答処理解読部
２１９ 応答処理部
２２０ セション管理部
２２１ トランザクション管理部
２２２ データ変換／整形部
２５０ ログ管理手段
２５１ ログ管理部
２５２ ログデータ
３０１ ＡＰＩ接続管理部
３０２ 要求解読部
３０３ 処理部
３０５ 更新通知送信部
３０６ 企業アカウント管理部
３０７ 予約情報管理部
３０９ システムアクセス数管理部
３１１ エンジン使用料管理部
３１２ 契約企業情報管理部
３１３ 管理者アカウント管理部
３１４ 管理サーバ管理者セション管理部
３１５ 変更履歴ログ書出部
３１６ ログファイル
３５０ データベース管理手段
３５１ ＤＢＭＳ
３５２ アカウント記憶装置
３５３ 契約記憶装置
３５４ 予約記憶装置
３５５ システムアクセス数記憶装置
１０１０ 企業の予約システム
１０１１ 検索要求データ送信手段
１０１２ 検索結果情報受信手段
１０１３ 申込データ送信手段
１０１４ 申込結果データ受信手段
１０２０ サーバ装置
１０２１ 関連付け部
１０２２ 検索要求データ受信部
１０２３ 検索要求データ送信部
１０２４ 検索結果情報提示部
１０２５ 申込データ受信部
１０２６ 申込データ送信部
１０２７ 申込結果データ提示部
１０２８ 請求データ受信部
１０２９ 請求データ送信部
１０３０ 航空会社の予約システム
１０３１ 検索要求データ受信手段
１０３２ 検索結果レコード送信手段
１０３３ 申込データ受信手段
１０３４ 申込結果データ送信手段
１０４０ チケット供給者の請求システム
１０４１ 販売情報記憶手段
１０４２ 請求データ送信手段
１０５０ 企業の経理システム
１０５１ 請求データ受信手段
１０５２ 従業員情報記憶手段
１５０１ 第１の検索要求データ
１５０２ 第２の検索要求データ
１６０１ 検索結果レコード
１６０２ 検索結果情報
１９０１ 第１の申込データ
１９０２ 第２の申込データ
２００１ 申込結果データ
２１０１ 第１の請求データ
２１０２ 第２の請求データ
Claims (2)
- 企業が保有する企業予約システム及び企業経理システムと、チケット供給者が保有するチケット供給者予約システム及びチケット供給者請求システムと、に接続され、前記チケット供給者が前記企業内のユーザにチケットを販売するための電子商取引管理サーバであって、
(a) 前記企業を示す企業コードと、該企業内で前記ユーザを識別するためのＩＤとを含むユーザＩＤと、 (b) 前記企業コードと、前記チケット供給者予約システムが前記ユーザを識別するためのＩＤとを含む顧客ＩＤと、 (c) 前記チケット供給者と、を関連付けて記憶する関連付け部と、
前記企業予約システムから送信されるユーザＩＤ及びチケット供給者を含む第１の申込データを受信する申込データ受信部と、
前記第１の申込データに含まれる前記ユーザＩＤ及び前記チケット供給者との組み合わせに基づいて前記関連付け部を検索して対応する顧客ＩＤを決定し、該決定された顧客ＩＤ及び前記チケット供給者を含む第２の申込データを前記第１の申込データに基づいて作成し、前記チケット供給者が保有するチケット供給者予約システムに前記第２の申込データを送信する申込データ送信部と、
前記チケット供給者予約システムから送信される顧客ＩＤ及びチケット供給者が含まれた申込結果データを受信し、該申込結果データに含まれる前記顧客ＩＤと前記チケット供給者との組み合わせに基づいて前記関連付け部を検索して対応するユーザＩＤを決定し、該決定されたユーザＩＤに含まれる企業コードで示される企業が保有する企業予約システムに、前記申込結果データ内の前記顧客ＩＤを前記決定されたユーザＩＤに置換した申込結果データを送信する申込結果データ提示部と、
前記チケット供給者請求システムから送信される顧客ＩＤ及びチケット供給者を含む第１の請求データを受信する請求データ受信部と、
前記第１の請求データに含まれる前記顧客ＩＤ及び前記チケット供給者との組み合わせに基づいて前記関連付け部を検索して対応するユーザＩＤを決定し、該決定されたユーザＩＤを含む第２の請求データを前記第１の請求データに基づいて作成し、前記決定された前記ユーザＩＤに含まれる企業コードで示される企業が保有する企業経理システムに前記第２の請求データを送信する請求データ送信部と
を備えることを特徴とする電子商取引管理サーバ。 - 前記第１の申込データには、ユーザによって入力された出張番号を含む申込ＩＤが含まれ、
前記第２の申込データには、前記申込ＩＤが含まれ、
前記申込結果データには、前記申込ＩＤが含まれる
ことを特徴とする請求項１に記載の電子商取引管理サーバ。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003195181A JP3828517B2 (ja) | 2001-02-19 | 2003-07-10 | 電子商取引管理サーバ及び電子商取引管理方法 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001042280 | 2001-02-19 | ||
| JP2003195181A JP3828517B2 (ja) | 2001-02-19 | 2003-07-10 | 電子商取引管理サーバ及び電子商取引管理方法 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001398331A Division JP2002318838A (ja) | 2001-02-19 | 2001-12-27 | 電子商取引管理サーバ及び電子商取引管理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004078913A JP2004078913A (ja) | 2004-03-11 |
| JP3828517B2 true JP3828517B2 (ja) | 2006-10-04 |
Family
ID=32032102
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003195181A Expired - Lifetime JP3828517B2 (ja) | 2001-02-19 | 2003-07-10 | 電子商取引管理サーバ及び電子商取引管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3828517B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2005098736A2 (en) * | 2004-03-26 | 2005-10-20 | Convergence Ct | System and method for controlling access and use of patient medical data records |
| JP2006146439A (ja) * | 2004-11-17 | 2006-06-08 | Sumitomo Corp | 旅行予約支援システム及び旅行予約方法、並びにサーバ装置 |
| JP6381715B1 (ja) * | 2017-03-13 | 2018-08-29 | ヤフー株式会社 | 提供装置、提供方法、提供プログラム、決定装置、決定方法、及び決定プログラム |
| CN110827014A (zh) * | 2018-09-28 | 2020-02-21 | 武汉小码联城科技有限公司 | 基于企业账户的乘车支付方法、系统及一种企业端、用户终端 |
| KR102280211B1 (ko) * | 2020-04-16 | 2021-09-01 | 김기환 | 개인 예약 관리 시스템 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| NZ332228A (en) * | 1995-09-06 | 2000-01-28 | Sabre Group Inc | Computerised corporate travel management system |
| JP4086340B2 (ja) * | 1996-05-17 | 2008-05-14 | 富士通株式会社 | ネットワーク認証システム |
| JPH10177552A (ja) * | 1996-12-17 | 1998-06-30 | Fuji Xerox Co Ltd | 認証応答方法およびその方法を用いた認証応答装置 |
| JPH11143977A (ja) * | 1997-11-04 | 1999-05-28 | Japan Travel Bureau Inc | 業務出張支援システム |
| JP3493141B2 (ja) * | 1998-06-12 | 2004-02-03 | 富士通株式会社 | ゲートウェイシステムおよび記録媒体 |
| JP2002318838A (ja) * | 2001-02-19 | 2002-10-31 | Toshiba Corp | 電子商取引管理サーバ及び電子商取引管理方法 |
-
2003
- 2003-07-10 JP JP2003195181A patent/JP3828517B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004078913A (ja) | 2004-03-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7783506B2 (en) | System and method for managing reservation requests for one or more inventory items | |
| US7707075B2 (en) | System and method for managing inventory | |
| US8340989B2 (en) | Method and system for managing rental vehicle reservations with user authorization limits | |
| AU2010298137B2 (en) | Collaboration and travel ecosystem | |
| US20050033616A1 (en) | Travel management system providing customized travel plan | |
| AU2002327439A1 (en) | System and method for managing reservation requests for one or more inventory items | |
| JP5110902B2 (ja) | サービス予約システム、情報提供装置、情報提供方法及び情報提供処理プログラム | |
| JP2004110577A (ja) | 法人等の組織に対する旅費・交通費の一括請求システム | |
| JP3828517B2 (ja) | 電子商取引管理サーバ及び電子商取引管理方法 | |
| JP4097438B2 (ja) | 回送レンタカーの運用方法 | |
| JP2002318838A (ja) | 電子商取引管理サーバ及び電子商取引管理方法 | |
| JP4336116B2 (ja) | 旅費システム及び手配・精算サービス提供方法 | |
| JP3581293B2 (ja) | Ｉｃカード利用サービス提供方法、システム及びプラットフォームサーバ | |
| JP2004094944A (ja) | チケット購入システム、購入仲介システム、チケット購入画面サーバ、チケット購入管理システム、チケット購入管理方法、サプライヤ予約システム及びサプライヤ予約方法 | |
| JP2004178616A (ja) | チケット購入システム、購入仲介システム、チケット購入画面サーバ、チケット購入管理システム及びチケット購入管理方法 | |
| KR100477355B1 (ko) | 통신망을 이용한 가맹점 기반의 물건대여 방법 및 시스템 | |
| KR20030085984A (ko) | 통신망을 이용한 가맹점 기반의 물건대여 방법 및 시스템 | |
| JP2003186985A (ja) | 出張支援システム及び装置並びにプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040817 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041018 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20041029 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20041126 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050811 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060602 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060706 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3828517 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090714 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100714 Year of fee payment: 4 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313117 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100714 Year of fee payment: 4 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110714 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110714 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120714 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130714 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |