(57)【要約】【課題】低コストで、信用度が高い上、支払者などの操作負担も低い、効率的な決済サービスを提供する。【解決手段】コンピュータネットワークと、支払者が携帯する携帯通信装置を利用して決済を行う決済システムにおいて、請求書関連メッセージ送信装置と、共用決済処理装置とを備え、携帯通信装置は、請求書関連メッセージを受信するメッセージ受信部と、共用決済処理装置と通信するための決済処理用通信部と、受信した請求書関連メッセージに対応する支払者の操作に応じて、請求書または請求書識別情報を、決済処理用通信部を介して共用決済処理装置に送信させる決済対応部とを備え、決済処理の実行に先立ち、共用決済処理装置の決済用ユーザインタフェース部に、請求書の内容を表示させ、支払者の確認を得た上で決済処理を実行させる。【選択図】  図１
2004164007.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータネットワークと、支払者が携帯する携帯通信装置を利用して決済を行う決済システムにおいて、
金銭の支払いを請求する請求書、または当該請求書に関連づけられた請求書識別情報を含む請求書関連メッセージを送信する請求書関連メッセージ送信装置と、
支払者に決済のための情報を伝える決済用ユーザインタフェース部を有し、複数の支払者によって共用され、前記携帯通信装置から受信する請求書または請求書識別情報に応じて決済処理を実行させる共用決済処理装置とを備え、
前記携帯通信装置は、
前記請求書関連メッセージを受信するメッセージ受信部と、
前記共用決済処理装置と通信するための決済処理用通信部と、
受信した前記請求書関連メッセージに対応する支払者の操作に応じて、前記請求書または請求書識別情報を、前記決済処理用通信部を介して前記共用決済処理装置に送信させる決済対応部とを備え、
前記決済処理の実行に先立ち、前記共用決済処理装置の決済用ユーザインタフェース部に、前記請求書の内容を表示させ、前記支払者の確認を得た上で決済処理を実行させることを特徴とする決済システム。
【請求項２】
請求項１の決済システムにおいて、
前記請求書にかかる商品が、所定の機能許可コードを入力することによって当該商品の持つ機能を発揮させる機能許可制御部を有するものである場合、
当該機能許可コードを、前記携帯通信装置または予め支払者によって登録された支払者側通信装置に送信する機能許可コード送信装置を設け、
前記決済処理が完了したとき当該機能許可コード送信装置が機能許可コードの送信を行うことを特徴とする決済システム。
【請求項３】
請求項１の決済システムにおいて、
前記請求書関連メッセージはハイパーリンクの埋め込まれた電子メールであり、
前記支払者が当該ハイパーリンクを操作することにより、前記決済対応部が自動的に機能することを特徴とする決済システム。
【請求項４】
請求項１の決済システムにおいて、
前記共用決済処理装置は、
前記請求書識別情報と請求書とを対応付けて格納した請求書格納装置に接続されており、
前記請求書関連メッセージが請求書識別情報を含むものである場合には、前記決済処理用通信部から受信した請求書識別情報をもとに当該請求書格納装置を検索して、該当する請求書を取得することを特徴とする決済システム。
【請求項５】
請求項１の決済システムにおいて、
前記請求書関連メッセージに含まれる請求書には、前記支払者を識別する支払者識別情報のほかに少なくとも、商品名、商品の金額、または、支払われた金銭の最終的な供給先を識別する供給先識別情報のいずれかが含まれていることを特徴とする決済システム。
【請求項６】
コンピュータネットワークと、支払者が携帯する携帯通信装置を利用して決済を行う決済方法において、
請求書関連メッセージ送信装置が、金銭の支払いを請求する請求書、または当該請求書に関連づけられた請求書識別情報を含む請求書関連メッセージを送信し、
支払者に決済のための情報を伝える決済用ユーザインタフェース部を有し、複数の支払者によって共用される共用決済処理装置が、前記携帯通信装置から受信する請求書または請求書識別情報に応じて決済処理を実行させる際、
前記請求書関連メッセージ送信装置と共用決済処理装置のあいだに介在する携帯通信装置では、
メッセージ受信部が前記請求書関連メッセージを受信し、
受信した当該請求書関連メッセージに対応する支払者の操作に応じて、決済対応部が、前記請求書または請求書識別情報を、前記共有決済処理装置と通信するための決済処理用通信部を介して前記共用決済処理装置に送信させ、
前記決済処理の実行に先立ち、前記共用決済処理装置の決済用ユーザインタフェース部に、前記請求書の内容を表示させて前記支払者の確認を得た上で決済処理を実行させることを特徴とする決済方法。
【請求項７】
請求項６の決済方法において、
前記請求書にかかる商品が、所定の機能許可コードを入力することによって当該商品の持つ機能を発揮させる機能許可制御部を有するものである場合、
当該機能許可コードを、前記携帯通信装置または予め支払者によって登録された支払者側通信装置に送信する機能許可コード送信装置を設け、
前記決済処理が完了したとき当該機能許可コード送信装置が機能許可コードの送信を行うことを特徴とする決済方法。
【請求項８】
請求項６の決済方法において、
前記請求書関連メッセージはハイパーリンクの埋め込まれた電子メールであり、
前記支払者が当該ハイパーリンクを操作することにより、前記決済対応部が自動的に機能することを特徴とする決済方法。
【請求項９】
複数の支払者によって共用され、支払者が携帯する携帯通信装置と通信することにより決済処理を実行させる共用決済処理装置において、
支払者に決済のための情報を伝える決済用ユーザインタフェース部と、
金銭の支払いを請求する請求書、または当該請求書に関連づけられた請求書識別情報を含む請求書関連メッセージを、前記携帯通信装置から受信する請求書関連メッセージ受信部とを備え、
前記決済処理の実行に先立ち、前記決済用ユーザインタフェース部に、前記請求書の内容を表示させ、前記支払者の確認を得た上で決済処理を実行させることを特徴とする共用決済処理装置。
【請求項１０】
請求項９の共用決済処理装置において、
前記請求書にかかる商品が、所定の機能許可コードを入力することによって当該商品の持つ機能を発揮させる機能許可制御部を有するものである場合、
当該共用決済処理装置は、
所定の機能許可コード送信装置に対して、決済処理の完了を通知する決済処理完了通知部を備え、
決済処理の完了を通知することで、前記機能許可コード送信装置に前記機能許可コードを、前記携帯通信装置または予め支払者によって登録された支払者側通信装置へ送信させることを特徴とする共有決済処理装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は決済システムおよび方法に関し、例えば、携帯電話機や現金自動預け払い機（ＡＴＭ端末）などを利用して決済を行う場合に適用して好適なものである。
【０００２】
また、本発明は、かかる決済システムの構成要素としての共有決済処理装置に関するものである。共有決済処理装置の例としては、当該ＡＴＭ端末があげられる。
【０００３】
【従来の技術】
一般に、従来の請求書による請求及び決済処理は紙をベースに行われている。公共料金や通信販売代金決済等ではコンビニエンスストアでの窓口支払いができるようにコンビニエンスストア決済提供会社と契約を結び、専用支払用紙と現金をコンビニエンスストアの窓口に提出することにより決済を行ういわゆるコンビニ決済の仕組みが普及しつつあるが、個人・中小事業者が請求書による支払決済を行う場合にはこの方法は用いられず、主として請求書に振込先を指示しておき銀行振込により決済が行われる。
【０００４】
支払手段として銀行に設置されているＡＴＭ端末や、コンビニエンスストアに設置されているＭＭＫ（マルチ・メディア・キオスク）端末などを用いて現金振込を利用する場合について、典型的な請求から収納までのプロセスは次の（１）〜（４）の順番で進む。
【０００５】
（１）請求者は請求書を印刷し封筒にいれて支払者に郵送する。
【０００６】
（２）この郵便を受け取った支払者は、銀行などへ出向き、前記ＡＴＭ端末などのタッチパネルを操作して請求書に書かれた請求情報（請求者の銀行名・支店名・受取人名義・口座種別・口座番号等及び請求金額等）を手入力し、現金を投入する。
【０００７】
（３）金融機関は、支払者に取引明細書を発行する。
【０００８】
（４）請求者は、振込内容を確認し、請求データを消しこむ。
【０００９】
一方、近年では、次の特許文献１〜３に開示されるように、紙をなるだけ使わずに電子的な手段で請求・収納処理を行う電子請求書決済システムが存在する。
【００１０】
【特許文献１】特開２００２−７９４５号公報
【００１１】
【特許文献２】特開２００１−２５００６９号公報
【００１２】
【特許文献３】特開２００１−３１９１６７号公報
【００１３】
【発明が解決しようとする課題】
ところが、上述した紙をベースとする決済システムでは、次のような問題があった。
【００１４】
まず請求者にとっては、請求書の発行・郵送等に時間的及び金銭的コストがかかる上に収納状況の管理が難しく効率的でなかった。支払者にとっては、前記ＡＴＭ端末などで前記請求情報をいちいち手入力することは操作負担が大きく、効率的ではなかった。タッチパネルを操作して請求情報を入力するのは、ＡＴＭ端末などにおいて最も難しく時間のかかる操作であり、特に高齢者や障害者にとっては利用の障壁ともなっていた。また、ＡＴＭ端末を設置する銀行などにとっては、支払者が請求情報を手入力するのに時間がかかることが多いため、単位時間あたりに到着する支払者の多い期間（例えば、平日の昼休みや、支払期日の集中する月末や連休前後など）にはＡＴＭ端末の前に長蛇の列ができ、混雑の度合いが高くなってしまう。
【００１５】
上述したコンビニ決済では、前記請求情報などが記載された所定の用紙をコンビニエンスストアの店員に渡して料金を支払うだけで決済を行うことができるため、支払者の操作負担の軽減にも有効であるし、決済サービスを提供する窓口の数を増加することにもなるため、ＡＴＭ端末の前の待ち行列を短縮することにも大きな効果がある。
【００１６】
しかしながらコンビニ決済では、支払者と請求者のあいだに決済代行業者が介在するため、請求者などが当該決済代行業者との間であらかじめその旨の契約を締結し、相当の利用料を支払う必要がある。そのため、請求者が、個人・中小事業者のように月当たりの請求書発行数が比較的少ないものである場合には、請求書１通あたりのコストが過大となり、事実上、コンビニ決済を利用することは不可能であった。また、コンビニ決済では、途中に人手による集計作業などが行われるため、請求者が請求書を発行してから実際に代金が回収できるまでに１〜２ヶ月のタイムラグが発生することがあり、資金繰りの点からも個人・中小事業者には利用が難しかった。
【００１７】
一方、電子請求書をベースとした前記特許文献１〜３の電子請求書決済システムでは、次のような問題点があった。
【００１８】
前記特許文献１〜３でセンタ、決済サービスセンタ、共同センタなどと呼ばれているセンタ機能は、現実の実装では、サーバ、データベース、ネットワーク機器など、多数のコンピュータの集合体として構築されるものであるため、その構築、運用、管理には多大なコストを要し、当該センタ機能を運営する事業者との契約では、このようなセンタ機能を利用した決済処理を望む請求者側は、一般的に、高額な契約料・利用料を支払う必要があるものと考えられ、結局、コンビニ決済の場合と同様に、月当たりの請求書発行数が比較的少ない個人・中小事業者などは、請求書１通あたりのコストが過大となるため、事実上利用は不可能であると考えられる。
【００１９】
また、近年ではインターネットバンキングの普及により、Ｗｅｂ上での決済も利用されるようになってきているが、これは必ずしも万人向けのものではない。現時点でのわが国の状況を見ると、パソコンを持っていない人や、Ｗｅｂ上で電子的にお金をやり取りすることに強い抵抗感を示す人も未だに多く、実際には、前記ＡＴＭ端末などを用いて行う在来型の決済（現金振込）が多用されているからである。
【００２０】
このような現象の背景には、Ｗｅｂページの改ざんや、個人情報の流出などの報道が行われることの少なくないインターネットは信用度が低く、多くの人が根強い不信感を持っていることがあるものと考えられる。
【００２１】
【課題を解決するための手段】
かかる課題を解決するために、第１の発明では、コンピュータネットワークと、支払者が携帯する携帯通信装置を利用して決済を行う決済システムにおいて、（１）金銭の支払いを請求する請求書、または当該請求書に関連づけられた請求書識別情報を含む請求書関連メッセージを送信する請求書関連メッセージ送信装置と、（２）支払者に決済のための情報を伝える決済用ユーザインタフェース部を有し、複数の支払者によって共用され、前記携帯通信装置から受信する請求書または請求書識別情報に応じて決済処理を実行させる共用決済処理装置とを備え、前記携帯通信装置は、（３）前記請求書関連メッセージを受信するメッセージ受信部と、（４）前記共用決済処理装置と通信するための決済処理用通信部と、（５）受信した前記請求書関連メッセージに対応する支払者の操作に応じて、前記請求書または請求書識別情報を、前記決済処理用通信部を介して前記共用決済処理装置に送信させる決済対応部とを備え、（６）前記決済処理の実行に先立ち、前記共用決済処理装置の決済用ユーザインタフェース部に、前記請求書の内容を表示させ、前記支払者の確認を得た上で決済処理を実行させることを特徴とする。
【００２２】
また、第２の発明では、コンピュータネットワークと、支払者が携帯する携帯通信装置を利用して決済を行う決済方法において、（１）請求書関連メッセージ送信装置が、金銭の支払いを請求する請求書、または当該請求書に関連づけられた請求書識別情報を含む請求書関連メッセージを送信し、（２）支払者に決済のための情報を伝える決済用ユーザインタフェース部を有し、複数の支払者によって共用される共用決済処理装置が、前記携帯通信装置から受信する請求書または請求書識別情報に応じて決済処理を実行させる際、前記請求書関連メッセージ送信装置と共用決済処理装置のあいだに介在する携帯通信装置では、（３）メッセージ受信部が前記請求書関連メッセージを受信し、（４）受信した当該請求書関連メッセージに対応する支払者の操作に応じて、決済対応部が、前記請求書または請求書識別情報を、前記共有決済処理装置と通信するための決済処理用通信部を介して前記共用決済処理装置に送信させ、（５）前記決済処理の実行に先立ち、前記共用決済処理装置の決済用ユーザインタフェース部に、前記請求書の内容を表示させて前記支払者の確認を得た上で決済処理を実行させることを特徴とする。
【００２３】
さらに、第３の発明では、複数の支払者によって共用され、支払者が携帯する携帯通信装置と通信することにより決済処理を実行させる共用決済処理装置において、（１）支払者に決済のための情報を伝える決済用ユーザインタフェース部と、（２）金銭の支払いを請求する請求書、または当該請求書に関連づけられた請求書識別情報を含む請求書関連メッセージを、前記携帯通信装置から受信する請求書関連メッセージ受信部とを備え、（３）前記決済処理の実行に先立ち、前記決済用ユーザインタフェース部に、前記請求書の内容を表示させ、前記支払者の確認を得た上で決済処理を実行させることを特徴とする。
【００２４】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかる決済システムおよび方法、並びに、共用決済処理装置に関する実施形態について説明する。
【００２５】
第１および第２の本実施形態に共通する特徴は、携帯電話機を用いたネットワーク経由の通信の利便性と、長年にわたる在来型の決済サービスで大きな信用が蓄積された共用端末（ＡＴＭ端末など）の持つ高い信頼性を巧みに組み合わせることにより、効率的で、なおかつ安心して利用することのできる決済サービスを提供することにある。
【００２６】
この決済サービスは、今までコンビニ決済や電子請求書決済の活用が難しかった個人・中小事業者にも、容易に利用することが可能である。
【００２７】
（Ａ−１）第１の実施形態の構成
本実施形態にかかる通信システム１０の全体構成例を図１に示す。
【００２８】
図１において、当該通信システム１０は、インターネット１１と、携帯電話ネットワーク１２と、専用線（専用線伝送網）１３と、請求書発行端末１４と、携帯電話機１５と、共用端末１６と、ホスト１７とを備えている。
【００２９】
このうちインターネット１１は、必要に応じて、ＬＡＮ（ローカルエリアネットワーク）などにも置換可能であるが、本実施形態ではインターネットを想定する。
【００３０】
当該インターネット１１には図示しないイントラネットや、ＩＳＰ網などを介して請求書発行端末１４が接続され、携帯電話ネットワーク１２を介して携帯電話機１５が接続されている。
【００３１】
当該請求書発行端末１４は、商品を購入したユーザＵ２に対し、当該商品の代金などを請求するための請求書（電子請求書）を発行する機能を持つ端末で、例えば、ネットワーク機能を備えたパーソナルコンピュータなどによって構成される。必ずしも代金を請求する請求者と、当該請求書発行端末１４を操作して電子請求書を発行するユーザＵ１が同一である必要はないが、ここでは同一であるものとする。
【００３２】
したがって、ユーザ（請求者）Ｕ１は、ユーザ（支払者）Ｕ２が前記商品を購入した小売店などの請求書発行業務担当者であってよい。
【００３３】
電子請求書をインターネット１１経由でユーザＵ２まで届けるには様々な方法が使用可能であるが、ここでは電子メールを利用するものとする。したがって、請求書発行端末１４はメーラ（ＭＬ１とする）を搭載している必要がある。
【００３４】
このメーラＭＬ１から送信された電子メールＭＥ１は図示しないメールサーバによって中継され、インターネット１１と携帯電話ネットワーク１２を介し、最終的には、携帯電話ネットワーク１２内の無線基地局（図示せず）を経て、ユーザＵ２が携帯する携帯電話機１５に届けられる。
【００３５】
携帯電話機１５にもメーラ（ＭＬ２とする）が搭載されているため、電子メールＭＥ１を受信すると、その本文メッセージの内容（すなわち、電子請求書）は、当該メーラＭＬ２の機能により携帯電話機１５の表示画面上に表示される。
【００３６】
詳細については後述するが、このあと、携帯電話機１５の持つ機能により、共用端末１６とローカル通信を行うことで、共用端末１６の表示画面上に電子請求書の内容が表示されるから、ユーザＵ２は信用度の高い共用端末１６で電子請求書の内容を再確認した上で、安心して、決済処理の進行を指示することができる。
【００３７】
共用端末１６とは、一般的なユーザ（Ｕ２もその一人）からみて信用の置ける環境に設置され、多数のユーザによって共用され決済処理の実行を指示できる機能を持つ通信端末のことである。したがって、共用端末１６にはコンビニエンスストアに設置されているＭＭＫ端末など様々な通信端末が該当し得るが、ここでは主として、銀行に設置されているＡＴＭ端末を想定する。
【００３８】
ＡＴＭ端末としての当該共用端末１６は、専用線１３を介してホスト１７に接続されており、ユーザＵ２からの指示にしたがい、当該ホスト１７と通信することによって決済処理を実行する。
【００３９】
なお、銀行などは、高い信用度を確保するためにＡＴＭ端末とホスト１７の接続には専用線を利用するのが普通であるが、ＭＭＫ端末の場合など、ホスト１７（あるいは、ホスト１７に相当する機能を持つサーバなど）と通信するために、必ずしも専用線を用いなくてもかまわない。ただしその場合でも、この通信でやり取りされるのは金銭の授受などに関係する個人情報であるから、暗号化技術などを活用して秘匿性や信頼性を確保する必要がある。
【００４０】
前記請求書発行端末１４の内部構成例は図２に示す通りである。
【００４１】
（Ａ−１−１）請求書発行端末の内部構成例
図２において、当該請求書発行端末１４は、リモート通信部２０と、制御部２１と、操作部２２と、表示部２３と、記憶部２４とを備えている。
【００４２】
このうちリモート通信部２０はインターネット１１などを経由したリモート通信のために機能する部分で、電子メールＭＥ１の送信に際して前記メールサーバとのあいだでＴＣＰコネクションの設定などを行い、電子メールＭＥ１を送信する。
【００４３】
操作部２２は、ユーザＵ１が操作して請求書発行端末１４に指示を伝える部分で、例えば、マウスなどのポインティングデバイスやキーボードなどを有する。
【００４４】
表示部２３は、前記メーラＭＬ１などの機能に応じて画面表示を行うディスプレイ装置に対応する部分で、ユーザＵ１に電子請求書の内容などを閲覧させる。ユーザＵ１はこの画面表示を目視しながら前記操作部２２を操作することにより、電子請求書の編集や、編集結果としての電子請求書を収容した電子メールＭＥ１の送信などを行うことができる。
【００４５】
制御部２１は、ハードウエア的には当該請求書発行端末１４のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）や前記メーラＭＬ１、請求書作成ツールＡＰ１、ＤＢＭＳなどの各種プログラムに相当する部分である。
【００４６】
請求書作成ツールＡＰ１は、前記電子請求書を本文メッセージとして含む電子メールを効率的に作成するための編集用ソフトウエアで、作成した電子請求書を電子メールに収容するため、前記メーラＭＬ１と連携する機能を有する。この請求書作成ツールＡＰ１が表示部２３に表示する画面は、例えば、図８に示すものであってよい。
【００４７】
図８に示すように、この画面には、前記商品に関する注文内容を入力するための部品（テキストボックス、押しボタンなど）を備えた画面要素ＰＴ１と、顧客名（例えば、ユーザＵ２の氏名）などを入力するための部品を備えた画面要素ＰＴ２と、振り込み先の口座を入力するための部品（画面要素ＰＴ３には、前記テキストボックスのほか、プルダウンリストも含まれている）を備えた画面要素ＰＴ３と、電子請求書のテンプレートに相当する画面要素ＰＴ４とを備えている。この画面要素ＰＴ４上の部品としては、テキストボックス、押しボタン、テキストエリアが含まれている。
【００４８】
図８の例では、画面要素ＰＴ１には、各注文を識別するための注文番号、各商品を識別するための商品番号、商品の名称である商品名、商品の単価である単価、商品の注文数量である数量、注文された商品の合計金額である合計を記述するための各部品が用意されている。
【００４９】
同様に、画面要素ＰＴ２には、顧客を識別するための顧客番号（会員番号）、顧客の氏名である名前、顧客の電子メールアドレスであるメールアドレスを記述するための各部品が用意されており、画面要素ＰＴ３には、請求者の口座を開設してある銀行および支店の名称である銀行名と支店名、口座の種別を示す預金種類、口座を識別するための口座番号、その口座内に振り込まれた金銭を受け取る受取人の名前である受取人を記述するための各部品が用意されている。
【００５０】
このうちユーザＵ１が顧客の相違に応じて変更する必要があるのは、基本的に、画面要素ＰＴ１とＰＴ２の各部品の記述内容だけでよい。
【００５１】
なお、必要に応じて、これらの部品の一部を省略したり、他の情報を記述するための部品と置換することが可能である。
【００５２】
ここでは、請求書作成ツールＡＰ１はメーラＭＬ１と別個のプログラムであるものとするが、必要ならば、メーラＭＬ１の機能を拡張することによって当該請求書作成ツールＡＰ１の機能を実現することもでき、その場合には、請求書作成ツールの機能をメーラＭＬ１の一部として位置づけることができる。
【００５３】
また、このような電子請求書のフォーマットは、ＸＭＬのような一定のルールに従ったテキストベースのものとなっているので、図８に示すような画面を表示する機能を備えた専用のツールでなくても、一般的なテキストエディタやワープロ、業務用ソフトウェアや表計算ソフトからの電子請求書フォーマットでのデータ書き出しによって作成・編集してもよい。特に請求書発行機能を持つ業務用ソフトウェアに電子請求書発行用のコマンドを設け、電子請求書作成・送信を簡便にできるようにするようにすれば従来の請求書処理を容易に電子化できることとなり好適である。
【００５４】
記憶部２４はハードウエア的には、ＲＡＭ（ランダムアクセスメモリ）や、ハードディスクなどによって構成される記憶資源であり、ソフトウエア的には、データベースＤＢ１や各種のファイルがこの部分に含まれ得る。前記メーラＭＬ１や、請求書作成ツールＡＰ１などのプログラムファイルもこのようなファイルの一つであるから、メーラＭＬ１や請求書作成ツールＡＰ１も、その物理的な実体は、この記憶部２４に位置する。
【００５５】
なお、データベースＤＢ１は顧客管理用のデータベースで、顧客の氏名、電子メールアドレス、購入して未決済の商品の商品名、価格、数量などの個人情報を、各顧客ごとに整理して格納してある。当該データベースＤＢ１は、直接的には前記ＤＢＭＳによって管理され検索されるが、ＤＢＭＳは、前記請求書作成ツールＡＰ１を介したユーザＵ１からの指示に応じて、当該検索などを実行するものであってよい。
【００５６】
もちろん、必要ならば、データベースＤＢ１は、請求書発行端末１４の外部に配置してもかまわないし、データベースＤＢ１を省略して、紙などに記録された情報に基づいて、ユーザＵ１が前記各部品に必要事項を１つずつ手作業で記述するようにしてもよい。
【００５７】
次に、当該請求書発行端末１４が送信した電子メールＭＥ１を受信する携帯電話機１５の内部構成例について、図９を用いて説明する。
【００５８】
（Ａ−１−２）携帯電話機の内部構成例
図９において、当該携帯電話機１５は、リモート通信部３０と、制御部３１と、操作部３２と、表示部３３と、記憶部３４と、ローカル通信部３５とを備えている。
【００５９】
これらの構成要素３０〜３４は基本的に前記請求書発行端末１４の各構成要素２０〜２４と同じものである。すなわち、リモート通信部３０は前記２０と対応し、制御部３１は前記２１と対応し、操作部３２は前記２２と対応し、表示部３３は前記２３と対応し、記憶部３４は前記２４と対応するので、その詳しい説明は省略する。
【００６０】
ただし、機能上その必要がないため、携帯電話機１５は、前記請求書作成ツールＡＰ１やデータベースＤＢ１を搭載しない。
【００６１】
また、携帯電話機は一般にそのボディの寸法もパーソナルコンピュータなどと比べると、はるかに小さいため、携帯電話機１５の表示部３３が備える表示画面も小さなものとなるが、一例として、図８に示すような記述内容に対応する電子メールＭＥ１を受信した場合、表示部３３には図４に示すような表示画面が表示され、ユーザＵ２によって閲覧される。さらに、ボディ寸法が小さいために、携帯電話機１５は操作部３２の寸法も小さく、個々の操作ボタン等も小さいから、操作性は、通常のパーソナルコンピュータなどに比べてはるかに劣るのが普通である。
【００６２】
この点に配慮し、本実施形態では、携帯電話機１５の操作部２２に対する操作をほとんど行うことなく、決済処理を実行できるようにしている。
【００６３】
パーソナルコンピュータなどである前記請求書発行端末１４の場合には、前記リモート通信部２０の機能のうち、ＯＳＩ参照モデルの物理層に該当する部分は有線通信（もちろん、必要ならば無線通信としてもかまわない）に対応するものであることが多いが、携帯電話機１５のリモート通信部２０の場合には、すべて無線通信である。
【００６４】
また、当該携帯電話機１５は前記請求書発行端末１４が持たなかったローカル通信部３５を備えている。
【００６５】
当該ローカル通信部３５は、インターネット１１などのネットワークを経由することなく、直接、通信端末と通信するために使用する部分で、前記請求書発行端末１４が備える必要のなかった機能である。携帯電話機１５がローカル通信部３５を用いて通信する通信端末は、前記共通端末１６である。
【００６６】
ローカル通信は有線方式と無線方式に分けることができる。有線方式では、例えば、ケーブルなどの有線伝送媒体を着脱自在なコネクタで接続し、有線によるローカル通信を行うものである。無線方式は、多くの場合、高々、１０数メートル程度の近距離で行う近距離無線通信を実行するものであるが、伝送媒体の相違により、電波を用いるものと赤外線を用いるものに細分できる。
【００６７】
通信の秘匿性を確保する観点では有線方式を用いるほうが望ましいが、使い勝手などの観点ではコネクタの装着などが不要な無線方式のほうが優れている。無線方式のなかでは、透過や回折などにより、どこまで届いているかが不明確な電波を用いるものよりも、見通しが得られる範囲でしか通信できない赤外線を用いるもののほうが傍受される危険性が少なく秘匿性に優れているといえる。
【００６８】
本実施形態で携帯電話機１５と共用端末１６のあいだのローカル通信によって伝送されるのは、電子請求書などの個人情報であり、秘匿性を確保する必要性は高いから、本実施形態のローカル通信では、赤外線を用いるものとする。赤外線を用いる場合、前記ローカル通信部３５は赤外線の送受を行うための赤外線ポートを装備することになる。
【００６９】
赤外線の出力などにも依存するが、携帯電話機の場合、赤外線通信が可能な最大距離は高々、数十センチメートル程度であることが多い。このため、ローカル通信を行うときには、ユーザＵ２は、共用端末１６の近傍まで移動し、共有端末１６側の赤外線ポートに、当該ローカル通信部３５の赤外線ポートを対向させる必要がある。
【００７０】
携帯電話機１５が搭載しているメーラＭＬ２の機能は、基本的に前記メーラＭＬ１と同じであってよいが、前記請求書作成ツールＡＰ１などと連携する機能は必要はない。
【００７１】
また、当該メーラＭＬ２は、ハイパーリンクに対応し、ユーザＵ２が前記操作部３２を用いてハイパーリンクを操作したときには自動的にＷｅｂブラウザなどを起動できるものとする。ただし本実施形態でメーラＭＬ２が起動するのはＷｅｂブラウザではなく、請求情報送信用プログラムＡＰ２である。請求情報送信用プログラムＡＰ２は、前記ハイパーリンクに埋め込まれた請求情報ＣＬ１を受け取ると、自動的に当該請求情報ＣＬ１を、前記ローカル通信部３５を用いて共有端末１６に送信させる機能を持ったアプリケーションである。この請求情報送信用プログラムＡＰ２は、製品としての携帯電話機１５の製造工程において当該携帯電話機１５に組み込むようにしてもよいが、本実施形態では、ネットワーク経由で搬送されてきて、当該携帯電話機１５にインストールされるものとする。携帯電話機１５は、当該請求情報送信プログラムＡＰ２を実行するための実行環境を有する。
【００７２】
なお、請求情報ＣＬ１とは、図８の画面において、画面要素ＰＴ１、ＰＴ２，ＰＴ３の各部品に記述した情報の集合体である。ただし、画面要素ＰＴ１、ＰＴ２，ＰＴ３の各部品に記述した情報のすべてを用いず、一部だけを請求情報ＣＬ１として用いることもできる。例えば、画面要素ＰＴ１に関しては、注文番号、商品番号、単価、数量などは省略して、合計だけを請求情報ＣＬ１の一部とすることができる。
【００７３】
電子メールの読み書きや送信を行うためのＭＵＡであるメーラにとって、ハイパーリンクへの対応は決して本来の機能ではないが、ハイパーリンクに対応する機能を持つメーラが現在、広く普及している。ただし当該メーラＭＬ２をハイパーリンクに対応したものとするのは、ユーザＵ２の操作負担を軽減するためであるから、操作負担を軽減する必要性が低い場合などには、ハイパーリンクに対応する機能を持たないメーラを利用することも可能である。
【００７４】
次に、当該携帯電話機１５とローカル通信を行う前記共有端末１６の内部構成例について、図１０を用いて説明する。
【００７５】
（Ａ−１−３）共有端末の内部構成例
図１０において、当該共有端末１６は、リモート通信部４０と、制御部４１と、操作部４２と、表示部４３と、記憶部４４と、ローカル通信部４５と、印刷部４６とを備えている。
【００７６】
これらの構成要素４０〜４５は基本的に前記携帯電話機１５の各構成要素３０〜３５と同じものである。すなわち、リモート通信部４０は前記３０と対応し、制御部４１は前記３１と対応し、操作部４２は前記３２と対応し、表示部４３は前記３３と対応し、記憶部４４は前記３４と対応するので、その詳しい説明は省略する。
【００７７】
ただし、ＡＴＭ端末である当該共有端末１６のリモート通信部４０は、通常、無線通信を行うことはなく、インターネット１１経由の通信や、携帯電話ネットワーク１２経由の通信を行うこともない。すなわち、当該リモート通信部４０は、前記専用線１３経由でホスト１７と通信する部分である。
【００７８】
また、ＡＴＭ端末のユーザインタフェースは通常、タッチパネルを採用しているから、操作部４２と表示部４３は、当該共有端末１６を操作するユーザ（例えば、Ｕ２）からみると、少なくとも物理的には一体である。さらに表示部４３および操作部４２の寸法は、通常のパーソナルコンピュータより、やや小さいが、携帯電話機１５の表示部３３や操作部３２に比べるとはるかに大きく、使いやすい。
【００７９】
図６（Ａ）、（Ｂ）、および図７が、当該表示部４３に表示される画面の例である。
【００８０】
なお、印刷部４６は取引明細書などを印刷出力（発行）する部分である。
【００８１】
また、制御部４１には、ある口座に対し（または、口座間で）金銭の出し入れを行うための機能、金銭の出し入れの結果を示す取引明細書の内容を決定する機能、このような出し入れが完了したあと取引明細書を印刷するために印刷部４６を制御する機能に加え、このような出し入れを行っている途中でトランザクションに障害が発生しても矛盾を生じないような仕組みが用意されている。例えば、ユーザＵ２の口座ＡＣ２から３５０００円を出しユーザＵ１の口座ＡＣ１へ入れる途中で障害が発生すると、口座ＡＣ２の残高は３５０００円減少しているのに、口座ＡＣ１の残高に変化はない状態で障害から復帰し、そのままの状態がその後も維持されることになるため、所定の仕組みを用意して、このような矛盾の発生を防止する必要がある。
【００８２】
ＡＴＭ端末としての共用端末１６に搭載されるこのような機能や仕組みは、すでに膨大な数のＡＴＭ端末に実装され、信頼性も確保されて確立されたものであるから、これを変更するとなると、膨大なコストや時間がかかる。したがって、本実施形態で必要な新たな機能の追加にあたっても、これら既存の機能や仕組みを変更する必要が生じないような方法を用いることが、実現性の観点で重要である。
【００８３】
現在のところ、ローカル通信部４５に相当する機能を備えたＡＴＭ端末は存在しないため、ローカル通信部４５を用いて前記請求情報ＣＬ１を共有端末（ＡＴＭ端末）１６に送信する部分に関して、新たな機能の追加が必要になる。ローカル通信部４５は、前記携帯電話機１５のローカル通信部３５に対向する部分であるから、前記ローカル通信部３５が赤外線通信を行う場合には、当該ローカル通信部４５も赤外線通信を行うことになり、当然、前記赤外線ポートを装備する。
【００８４】
また、図６（Ａ）の画面で携帯電話を選択するときに操作するボタンＢＴ１や、当該ボタンＢＴ１を操作したあとに表示される図６（Ｂ）の画面なども、新たに追加される機能に対応する部分である。
【００８５】
なお、前記ホスト１７は、ＡＴＭ端末などとの通信に応じて、各口座（例えば、ＡＣ１）などの金銭の出し入れを実行し、管理する機能を持つ情報処理装置であるが、本実施形態に特有なものではなく、既存のホストを機能変更せずにそのまま利用する。
【００８６】
以下、上記のような構成を有する本実施形態の動作について、図３の動作シーケンスを参照しながら説明する。
【００８７】
図３の動作シーケンスは、Ｓ１１〜Ｓ１５の各ステップを備えている。
【００８８】
（Ａ−２）第１の実施形態の動作
前記ユーザＵ１が請求書発行端末１４を操作し、前記請求書作成ツールＡＰ１が提供する図８の画面などを活用して電子請求書を作成したあと、当該電子請求書（請求情報ＣＬ１）を収容した電子メールＭＥ１を送信すると、当該電子メールＭＥ１はインターネット１１と携帯電話ネットワーク１２を経由して携帯電話機１５に受信される（Ｓ１１）。
【００８９】
一般に、携帯電話機の電子メールシステムの内容は携帯電話ネットワークごと（携帯電話事業者ごと）に相違し、携帯電話ネットワーク１２主導で電子メールＭＥ１を宛先の携帯電話機１５に送りつけるタイプの電子メールシステムや、メールサーバに設けられたユーザＵ２のメールボックスに電子メールＭＥ１が着信したことだけを携帯電話機１５に伝え、携帯電話機１５が電子メールＭＥ１を受信するには、メールボックスから当該電子メールＭＥ１を取り出すための操作を携帯電話機１５側から行うことを要するタイプの電子メールシステムがある。いずれの場合でも、少なくとも電子メールＭＥ１が着信したことは着信音やバイブレーションによって、直ちに、ユーザＵ２に伝えられるから、ほとんどの場合、携帯電話機１５を携帯したユーザＵ２がどこにいても、即座に、電子メールＭＥ１の着信を知ることができる。
【００９０】
また、前記請求情報ＣＬ１は、秘匿すべき個人情報の一種であるとも考えられるため、当該請求情報ＣＬ１を含む電子メールＭＥ１はインターネット１１上を平文のまま伝送せず、暗号化を施すようにすることも望ましい。さらに、請求情報ＣＬ１は、金銭の授受に直結する情報であるから、その内容が改ざんされていないことの確認や、送信元（ここでは、Ｕ１）が正当であることの確認を、ユーザＵ２側で行うことができることが望ましい。そのためには、一例として、Ｓ／ＭＩＭＥを利用してもよい。
【００９１】
携帯電話機１５で電子メールＭＥ１を受信し、例えば、図４に示す画面を閲覧したユーザＵ２は、振り込みの必要性を認識し、前記共有端末１６が設置されている銀行などへ出向くことになる。
【００９２】
ユーザＵ２が共有端末１６の近傍に移動し、共有端末１６に画面表示されている図６（Ａ）の画面上でボタンＢＴ１を選択すると、共有端末１６が表示する画面は、図６（Ｂ）の画面に変わる。このあとは、図６（Ｂ）のメッセージにしたがって、共有端末１６側の赤外線ポートに携帯電話機１５の赤外線ポートを対向させた上で、携帯電話機１５の図８に示す画面上でハイパーリンク（「ＡＴＭ振込み」の部分）を操作して、請求情報送信用プログラムＡＰ２に上述した請求情報ＣＬ１を送信させる（Ｓ１２）。
【００９３】
この際、請求情報送信用プログラムＡＰ２が携帯電話機１５の表示部３３に表示させる画面は、図５（Ａ）、（Ｂ）、（Ｃ）の順番で遷移する。すなわち、図５（Ａ）の画面でユーザＵ２が新規振込先入力を選択すると、画面は図５（Ｂ）に遷移するが、図５（Ｂ）に表示されている銀行名「あいうえ銀行」、支店名「大阪支店」、金額（合計）「３５０００円」などの情報は、前記ハイパーリンクに埋め込まれた請求情報ＣＬ１の内容に対応し、ユーザＵ２が逐一、入力する必要のないものである。図５（Ｂ）の画面上でユーザＵ２が「送信」を選択すると、携帯電話機１５から共通端末１６に対し、前記赤外線による請求情報ＣＬ１のローカル通信（送信）が開始されて画面は図５（Ｃ）に示すものに遷移する。
【００９４】
このため、請求情報ＣＬ１は、ユーザＵ２が請求情報ＣＬ１中の各情報を入力するための操作を実行しなくても、自動的に、共用端末１６に入力されることになる。
【００９５】
この請求情報ＣＬ１を受けて、共有端末１６には図７に示す画面が表示される。
【００９６】
なお、ここでは、ユーザＵ２が共有端末１６に現金を投入することによって決済を行う場合を例に取っているが、必要ならば、ユーザＵ２の口座（例えば、前記ＡＣ２）の残高の一部を用いて決済を行うようにしてもよいことは当然である。
【００９７】
この場合、口座ＡＣ２の口座番号などを図８の画面要素ＰＴ２で入力させ、ローカル通信によって送信される請求情報ＣＬ１にも当該口座番号を含めるようにしておけば、ユーザＵ２が共用端末１６を操作して口座番号などを入力する操作を省略することができる。
【００９８】
本実施形態の処理の流れからすると、ユーザＵ２は、請求情報ＣＬ１中で請求された金額（図示の例では、３５０００円）をそのまま支払うことになるため、図７に示すボタンＢＴ１１のように、金額を変更するための機能は不要であると考えられるが、共有端末１６がすでに備えている上述した既存の機能や仕組みに応じた処理により、図７の画面上では、ボタンＢＴ１１などが表示されている。これは共有端末１６を用いる既存の決済方法、すなわち、携帯電話機１５などを用いずに、支払者が前記請求情報ＣＬ１に相当する情報を逐一、手作業で共用端末１６に入力して決済を行うケースに対応する仕様である。
【００９９】
したがって、もし必要ならば、携帯電話機１５を用いた決済の場合には、図７の画面上でボタンＢＴ１１などを表示させないようにしてもよい。ただしその場合には上述した実現性が犠牲になる。
【０１００】
Ｗｅｂサイトなどを用いて取り引きのすべてをインターネット１１や携帯電話ネットワーク１２経由で実行する純然たる電子商取引（ＥＣ）に比べると、共用端末１６を操作して図７のような画面を確認すること等は、ユーザＵ２にとって手数が増大する点で不利であるが、長年にわたる在来型の決済サービスで大きな信用が蓄積された共用端末１６の持つ高い信頼性を活用することができるため、インターネット１１に不信感を持つ多数のユーザにも安心して受け入れてもらえる可能性が高い。
【０１０１】
必要な代金（ここでは、３５０００円）を投入し、ユーザＵ２が後続の必要な操作（ここでは、ボタンＢＴ１２の操作）を実行すると、共用端末１６とホスト１７のあいだの通信により、当該代金を前記ユーザＵ１の口座ＡＣ１へ振り込むための振込トランザクションが実行され（Ｓ１３）、ホスト１７は、口座番号や受取人のチェックをした上でその実行結果（振込受付が完了した旨の通知）を共用端末１６へ返送する（Ｓ１４）。
【０１０２】
これにより、共用端末１６が取引明細書の発行やお釣りの発行など、既存の機能による処理を実行する（Ｓ１５）。当該取引明細書を受け取ることによっても、ユーザＵ２の安心感は増大する。
【０１０３】
以上の本実施形態では、従来のコンビニ決済のように決済代行業者が介在することもなく、電子請求書システムのようにセンタ機能が介在することもないため、決済代行業者に支払う利用料や、センタ機能の運営を行う事業者に支払う契約料や利用料も不要となり、個人や、中小事業者にも利用しやすい低コストの決済サービスを提供することができる。
【０１０４】
また、請求者（Ｕ１）にとっても、支払者（Ｕ２）にとっても、操作負担が少なく、効率的である。
【０１０５】
さらに、信用度の高い共用端末１６を利用することで、通信システム１０全体としても、決済に関する信用度が高まり、インターネット１１に対する不信感のある人にも広く受け入れてもらえる可能性が高い。
【０１０６】
また、決済は、従来の共用端末やホスト１７の機能をベースとしているので、低コストかつ容易に実現できる上に、請求者にとっては代金回収サイクルが早いことも大きなメリットである。
【０１０７】
（Ａ−３）第１の実施形態の効果
本実施形態によれば、低コストで、信用度が高い上、ユーザ（Ｕ１およびＵ２）の操作負担も低い、効率的な決済サービスを提供することができる。
【０１０８】
（Ｂ）第２の実施形態
以下では、本実施形態が第１の実施形態と相違する点についてのみ説明する。
【０１０９】
本実施形態は、振込受付が完了したときに、他システムと連携して、さらに新たな処理を実行する点が第１の実施形態と相違する。
ここでは他システムの例として、ソフトウェア開発会社が自社ソフトウェアのアクチベーションコード発行に利用するコード発行サーバ１８（図１２参照）を想定する。
【０１１０】
アクチベーションコードはソフトウェアを起動させるために必要な一種のパスワードである。ソフトウエアをネットワーク経由でダウンロードさせて販売するダウンロード販売で、ダウンロード後に決済を行う場合、当該アクチベーションコード（例えば、１０個程度の数字あるいは文字のユニークな系列）の利用が有効である。
【０１１１】
ソフトウエア本体をダウンロードしても、正しいアクチベーションコードを入力しなければソフトウエアを利用することができないため、決済後に、当該ソフトウエアの購入者（前記Ｕ２に対応）にアクチベーションコードを伝え、ソフトウエアを利用可能とするものである。
【０１１２】
（Ｂ−１）第２の実施形態の構成および動作
本実施形態にかかる通信システム９の全体構成例を図１２に示す。
【０１１３】
図１２において、当該通信システム９は、インターネット１１と、携帯電話ネットワーク１２と、専用線（専用線伝送網）１３と、請求書発行端末１４と、携帯電話機１５と、共用端末１６と、ホスト１７と、前記コード発行サーバ１８と、ゲートウエイ１９とを備えている。
【０１１４】
このうち図１と同じ符号１１〜１７を付与した構成要素の機能は、基本的に第１の実施形態と同じなので、その詳しい説明は省略する。
【０１１５】
ただし本実施形態の共通端末１６は、振込完了後に振込完了通知をコード発行サーバ１８へ送信する必要があるため、図１３に示すように、振込完了通知部４７を備えている。
【０１１６】
振込完了通知をコード発行サーバ１８に送信するための通信手段としては様々なものが考えられ、その選択は、コード発行サーバ１８をどこに配置するか、通信システム９の全体構成をどのようにするか等の条件にも依存するが、本実施形態では、図１２に示したように、コード発行サーバ１８をインターネット１１上に配置し、共通端末１６とコード発行サーバ１８は、専用線伝送網１３内に設置されたゲートウエイ１９を介して、インターネット１１経由で通信するものとしたため、一例として、電子メールの利用が可能である。
【０１１７】
電子メールを用いる場合、前記振込通知部４７は、自動的に電子メールＭＥ２を作成し、前記コード発行サーバ１８に宛てて送信する機能を備えることとなる。このとき、当該振込通知部４７は、当該電子メールＭＥ２のメールヘッダのＴｏフィールドに記述するため、コード発行サーバ１８の電子メールアドレスを取得する必要があるが、例えば、受取人の口座番号と電子メールアドレスの対応関係を格納したデータベースをゲートウエイ１９より専用線１３側に設けておけばセキュリティ性を保ちながら、口座番号を検索キーとして当該データベースを検索することにより、前記コード発行サーバ１８の電子メールアドレスを取得することができる。
【０１１８】
コード発行サーバ１８は、前記ソフトウェア開発会社のサーバであるから、銀行側のネットワークである専用線１９内に配置することは、銀行側のセキュリティ確保の観点などからも困難であると考えられるため、図示のようにインターネット１１上に配置するものとした。
【０１１９】
また、ゲートウエイ１９は、専用線１３内部とインターネット１１とを物理的に遮断し、インターネット１１上のパーソナルコンピュータなどから専用線１９の内部にアクセスすることを禁止する。通過を許すのは、専用線１３に接続された共有端末（例えば、１６）を送信元とする電子メール（例えば、ＭＥ２）だけでよい。メールを送信するということはエラーメールが戻ってくる可能性があることを意味するが、エラーメールの受信のためには、インターネット１１上に専用のメールサーバ等を用意することで、専用線１３側のセキュリティを確保できる。
【０１２０】
なお、共通端末１６から直接、インターネット１１やコード発行サーバ１８に通信することも考えられるが、図１２には１つしか図示していないものの専用線１３に接続される共通端末１６の数は膨大なので、外部（ここでは、コード発行サーバ１８やインターネット１１）とのアクセスポイントの数を集約したほうが、専用線１９内部のセキュリティを確保しやすいと考えて、ゲートウエイ１９を配置した。
【０１２１】
前記コード発行サーバ１８は、コード（すなわち、上述したアクチベーションコード）を発行する機能を持つサーバであるが、その主要部の構成例は、図１４に示す通りである。
【０１２２】
（Ｂ−１−１）コード発行サーバの内部構成例
図１４において、当該コード発行サーバ１８は、リモート通信部５０と、制御部５１と、メール処理部５２と、記憶部５３とを備えている。
【０１２３】
このうち構成要素５０，５１，５３は、基本的に、第１の実施形態の請求書発行端末１４の前記構成要素２０，２１，２４と同じであるので、その詳しい説明は省略する。
【０１２４】
すなわち、リモート通信部５０は前記２０に対応し、制御部５１は前記２１に対応し、記憶部５３は前記２４に対応する。
【０１２５】
ただしリモート通信部５０は、電子メール（ＭＥ３）を送信するだけでなく、前記共有端末１６から振込完了通知として送信される電子メールＭＥ２を前記専用線１３，ゲートウエイ１９およびインターネット１１を経由して受信する必要がある。
【０１２６】
また、記憶部５３に格納されているデータベースＤＢ２は、ダウンロード販売したソフトウエアの購入者（Ｕ２）の識別子（購入者識別子）と、販売したソフトウエアのアクチベーションコードの対応関係などを格納したデータベースである。
【０１２７】
購入者識別子としては、当該ユーザＵ２の電子メールアドレス、電話番号、住所と氏名など、様々な情報を利用することが考えられるが、前記請求情報ＣＬ１に、ユーザＵ２の口座ＡＣ２を示す口座番号を含めるようにしておけば、共用端末１６が自動的に当該口座番号を含む電子メールＭＥ２を送信するように構成することができ、購入者識別子をユーザＵ２が共用端末１６を操作して入力する必要がなく、効率的である。
【０１２８】
本実施形態の動作をまとめた動作シーケンスは図１１の通りである。図１１の動作シーケンスは、Ｓ１１〜Ｓ１７の各ステップから構成されている。
【０１２９】
このうち図３と同じ符号Ｓ１１〜Ｓ１５を付与した各ステップの処理は、第１の実施形態と同じであるから、その詳しい説明は省略する。
【０１３０】
ステップＳ１５のあと（必要に応じて、ステップＳ１５とＳ１４のあいだでも可）、共用端末１６が前記電子メールＭＥ２による振込完了通知を行うと、この通知を受けたコード発行サーバ１８は、前記データベースＤＢ２を検索して、該当するアクチベーションコードを特定し、当該アクチベーションコードを収容した電子メールＭＥ３を自動的に作成して、携帯電話機１５へ送信する（Ｓ１７）。
【０１３１】
これにより、ユーザＵ２は正しいアクチベーションコードを知ることができるから、予めダウンロードしてあるソフトウエアを利用することができるようになる。
【０１３２】
当該ソフトウエアをダウンロードする通信端末は、携帯電話機１５であってもよく、携帯電話機１５以外のユーザＵ２のパーソナルコンピュータなどであってもよい。当該ソフトウエアは、アクチベーションコードを入力するためのウインドウなどのユーザインタフェースを有するため、ユーザＵ２はキーボードなどを操作することによって、アクチベーションコードを入力可能である。
【０１３３】
なお、電子メールＭＥ２，ＭＥ３の送信でも、必要に応じて、前記Ｓ／ＭＩＭＥなどを利用するとよい。
【０１３４】
（Ｂ−２）第２の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることができる。
【０１３５】
加えて、本実施形態では、代金の支払から商品（ソフトウエア）の利用開始までの時間を最短にすることが可能である。
【０１３６】
また、請求者（Ｕ１）にとっては、振込がされることが確認されてから実質的な商品提供を行うことに等しいため、代金回収リスクが低減される。
【０１３７】
（Ｃ）他の実施形態
上記第１および第２の実施形態では、ＡＴＭ端末としての共用端末における振込操作を例に取ったが、本発明はＡＴＭ端末に限って適用されるものでないことはすでに述べた通りである。前記請求情報ＣＬ１に相当する情報の事前入力情報とその情報に基づく自動処理を行うものならば他機器へも応用可能である。例えば、発券端末へ応用して、航空券や列車指定券の予約を予め携帯電話機で行っておき、その予約情報を電子請求書として受け取り、街角の発券端末で支払を行うと紙のチケットが発行されるようにしてもよい。
【０１３８】
また、上記第１および第２の実施形態における携帯電話機は、その他の携帯通信装置に置換可能である。例えば、メール端末、ＰＨＳ端末、ＰＤＡ端末、タブレットＰＣなどに置換することが可能である。
【０１３９】
さらに、第１および第２の実施形態において、請求情報ＣＬ１は電子メールの中に直接的に埋め込まれているものとしたが、例えば、電子メールＭＥ１には、請求情報ＣＬ１を識別するためのＩＤ番号を埋め込んでおき、そのＩＤ番号に対応する請求情報は当該ＩＤ番号と対応付けた形式で、どこかの場所に蓄積する構成とし、実際の振込作業のときには電子メールＭＥ１から取り出したそのＩＤ番号を検索キーとして対応する請求情報を取り出すようにしてもよい。
【０１４０】
なお、セキュリティあるいは使いやすさの観点から、請求情報のうちの一部あるいは全てを支払者から不可視にしたり編集不可能にしたりしてもよい。
【０１４１】
また、上記第１および第２の実施形態において、請求書発行端末１４は必ずしも請求者Ｕ１が所有したり操作したりする必要はない。例えば物品販売サイトなどにおいて、ユーザＵ２の発注内容に応じてサーバーサイドプログラムで請求金額を自動計算し、その結果を電子請求書として自動的に送信するようにしてもよい。
【０１４２】
さらに、第１および第２の実施形態において、電子請求書はインターネット１１や携帯電話ネットワーク１２を経由するリモート通信によって送信したが、ローカル通信によって送信することも可能である。例えば、ＭＭＫ端末で物品の注文を行い、そのＭＭＫ端末の赤外線ポートから直接、電子請求書を受け取ることも考えられる。
【０１４３】
なお、第１および第２の実施形態において、電子請求書は請求者から送信される電子メールから取得するるものとしたが、支払者が自ら作成してもよいことは当然である。
【０１４４】
また、第２の実施形態では、ソフトウェアのアクチベーションコードを発行するコード発行サーバとの連携について説明したが、本発明は、これに限定するものではなく、開錠番号の入力によって開錠するロッカーシステムや自動化された物品発送システムとの連携にも応用できる。
【０１４５】
さらに、第２の実施形態では、アクチベーションコード発行装置に直接、振込受付通知が届き、自動的に処理されてアクチベーションコードが発行される例について述べたが、振込受付通知を請求者のところに届けるようにしておき、その後の作業は人手によって行うようにしてもよい。
【０１４６】
なお、第２の実施形態において、振込完了通知は振込受付がなされた時点で行うようになっているが、実際に請求者側の口座に振込が完了した時点などの別のトリガによって通知を行うようにしてもよい。
【０１４７】
また、第２の実施形態において、通知は電子メールで行うとしているが、その他の電子的なメッセージ・ＦＡＸ・電話等値の通信手段によって行うこととしてもよい。
【０１４８】
さらに、図１２に示した第２の実施形態のネットワーク構成は、必要に応じて変更することも可能である。
【０１４９】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０１５０】
【発明の効果】
以上に説明したように、本発明によれば、低コストで、信用度が高い上、支払者などの操作負担も低い、効率的な決済サービスを提供することが可能である。
【図面の簡単な説明】
【図１】第１の実施形態に係る通信システムの全体構成例を示す概略図である。
【図２】第１および第２の実施形態で使用する請求書発行端末の主要部の構成例を示す概略図である。
【図３】第１の実施形態の動作を示すフローチャートである。
【図４】第１および第２の実施形態の動作を示す表示画面例である。
【図５】第１および第２の実施形態の動作を示す表示画面例である。
【図６】第１および第２の実施形態の動作を示す表示画面例である。
【図７】第１および第２の実施形態の動作を示す表示画面例である。
【図８】第１および第２の実施形態の動作を示す表示画面例である。
【図９】第１および第２の実施形態で使用する携帯電話機の主要部の構成例を示す概略図である。
【図１０】第１の実施形態で使用する共用端末の主要部の構成例を示す概略図である。
【図１１】第２の実施形態の動作を示すフローチャートである。
【図１２】第２の実施形態に係る通信システムの全体構成例を示す概略図である。
【図１３】第２の実施形態で使用する共用端末の主要部の構成例を示す概略図である。
【図１４】第２の実施形態で使用するコード発行サーバの主要部の構成例を示す概略図である。
【符号の説明】
９，１０…通信システム、１１…インターネット，１２…携帯電話ネットワーク、１３…専用線、１４…請求書発行端末、１５…携帯電話機、１６…共用端末、１７…ホスト、１９…ゲートウエイ、２０，３０，４０…リモート通信部、２１，３１，４１…制御部、２４，３４，４４…記憶部、３５，４５…ローカル通信部、４６…印刷部、ＭＥ１〜ＭＥ３…電子メール、ＡＰ１…請求書作成ツール、ＡＰ２…請求情報送信用プログラム。
【図１】
2004164007.tif 000003
【図２】
2004164007.tif 000004
【図３】
2004164007.tif 000005
【図４】
2004164007.tif 000006
【図５】
2004164007.tif 000007
【図６】
2004164007.tif 000008
【図７】
2004164007.tif 000009
【図８】
2004164007.tif 000010
【図９】
2004164007.tif 000011
【図１０】
2004164007.tif 000012
【図１１】
2004164007.tif 000013
【図１２】
2004164007.tif 000014
【図１３】
2004164007.tif 000015
【図１４】
2004164007.tif 000016