JP2007241769A - 決済処理システム - Google Patents

Abstract

【課題】電子装置内に複数の販売手段が存在し、これらの販売手段が自発的に決済情報を外部機器に通知できない場合であっても、外部機器が決済情報を効率的に得ることができる決済処理システムを提供すること。
【解決手段】電子装置２００は、外部機器４００と通信を行う非接触通信部２０４と、選択されたサービス類を提供するとともに、選択されたサービス類に関する決済情報を作成するＳＰアプリケーション２１２〜２１６と、決済情報を保持する決済情報保持メモリ２１０と、決済情報保持メモリ２１０が保持する決済情報を外部機器４００に送信する決済仲介部２０８と、を備える。全てのＳＰアプリケーション２１２〜２１６は、作成した決済情報を決済情報保持メモリ２１０に格納する。決済仲介部２０８は、外部機器４００から決済情報を要求された場合、決済情報保持メモリ２１０内の決済情報を外部機器４００に送信する。
【選択図】図１

Description

本発明は、決済処理システムに関し、特に、携帯型電子装置を用いた非接触通信に好適な決済処理システムならびにこれに用いる電子装置および外部機器などに関する。

近年、多くのサービスプロバイダ（以下、「ＳＰ」と略記する）が、インターネット上でサービスや物品など（以下、「サービス類」という）を提供しており、ユーザはこれらのＳＰからサービス類を購入することができる。このとき、ユーザは、何らかの方法を用いて決済を行わなければならない。例えば、特許文献１には、複数ある決済手段の中から一つの決済手段（例えば、クレジットカード会社や金融機関など）を選択し、選択された決済手段を用いてオンライン決済をすることができる決済処理システムが開示されている。特許文献１の決済処理システムの構成を示すブロック図を図１１に示す。

図１１において、決済処理システム１０は、ユーザが操作するＰＣ（Personal Computer）１２、通信網１４、サービス類を提供するＥＣ（Electronic Commerce：電子商取引）モールサーバ１６〜１８、決済処理を専門に行う決済モールシステム２０〜２２、決済システム２４、クレジットオンラインシステム２６、決済処理を行う決済業務サーバ２８〜３０から構成されている。

この決済処理システム１０における決済処理の流れは次のとおりである。

まず、ユーザは、ＰＣ１２を用いて複数あるＥＣモールサーバ１６〜１８のうち購入したいサービス類を提供しているＥＣモールサーバ１６〜１８にアクセスし、購入するサービス類を選択する。ここでは、ＥＣモールサーバ１６のサービス類が選択されたものとして以下説明する。ユーザのＰＣ１２は、購入対象のサービス類に関する購入サービス情報と、決済額やユーザが希望する決済手段、クレジットカード番号（口座番号）などを含む決済情報とを選択されたＥＣモールサーバ１６に通知する。

ＥＣモールサーバ１６は、購入サービス情報および決済情報をＥＣモールサーバ１６に接続された決済モールシステム２０に通知する。決済モールシステム２０は、決済額やクレジットカード番号（口座番号）などを、共同利用型の決済システム２４およびクレジットオンラインシステム２６を介して、ユーザが希望する決済手段の決済業務サーバ２８〜３０に通知する。ここでは、決済業務サーバ２９が選択されたものとして、以下説明する。

選択された決済業務サーバ２９は、決済処理を行い、その結果をクレジットオンラインシステム２６および決済システム２４を介して決済モールシステム２０に通知する。決済モールシステム２０は決済処理の結果などをＥＣモールサーバ１６に通知し、決済が完了する。

このように、特許文献１の発明は、各種情報をサーバに送信することから、ネットワーク通信によるオンライン処理を前提としている。したがって、ＳＰが、ネットワーク通信機能を持たない自動販売機やＡＶ機器に挿入されたＩＣカードなどによってサービス類を提供する場合、ユーザは、特許文献１の方法によって決済を行うことは不可能である。

ＳＰがネットワーク通信機能を持たない機器でサービス類を販売する場合であっても、決済を可能とする技術として、例えば、特許文献２には、携帯電話を用いて決済を行う技術が開示されている。特許文献２の情報処理システムの構成を図１２に示し、このシステムにおける決済処理の流れを説明する。

図１２（Ａ）は、ユーザが自動販売機でサービス類を購入する際に、携帯電話で決済を行う情報処理システムの構成を示す図であり、図１２（Ｂ）は、図１２（Ａ）の自動販売機の構成を示すブロック図である。

図１２（Ａ）において、情報処理システム４０は、ＳＰがサービス類を販売する自動販売機５０、無線通信可能な携帯電話６０、無線基地局６２、電話回線網６４、決済処理を行う取引銀行６６から構成される。

図１２（Ｂ）において、自動販売機５０は、無線通信によって携帯電話６０との間で各種情報を送受信する送受信回路５１と、決済情報の作成およびサービス類をユーザに提供する販売機構５２とを備える構成を採る。

この情報処理システム４０における決済処理の流れを説明する。

まず、ユーザが、自動販売機５０を操作することによって購入したいサービス類を選択する。販売機構５２は、選択されたサービス類の代金情報などを含む決済情報を作成し、送受信回路５１を介して携帯電話６０に送信する。

ユーザは、携帯電話６０の表示部に表示されたサービス類の代金を確認し、決定ボタンを押して取引の実行を承認する。これにより、携帯電話６０は、取引承認情報を作成し、無線通信によって自動販売機５０の送受信回路５１に送信する。送受信回路５１は、取引承認情報を販売機構５２に出力する。販売機構５２は、取引承認情報に基づいて選択されたサービス類の引渡し処理を行う。

一方、上記取引承認の通知とは別に、携帯電話６０は、決済情報を無線基地局６２および電話回線網６４を介して取引銀行６６に送信する。取引銀行６６は、決済情報に基づいて決済処理を行う。処理完了後、取引銀行６６は、決済完了情報を作成し、電話回線網６４および無線基地局６２を介して携帯電話６０に送信する。

このように、特許文献２記載の方法を用いることで、ＳＰがネットワーク通信機能を持たない機器によってサービス類を販売する場合であっても、ユーザは決済を行うことができる。
特開２００３−１６３６１号公報 特許第３５１６９９４号公報

しかしながら、特許文献２記載の方法にあっては、同一装置内に複数の販売機構が存在し、これらの販売機構が自発的に決済情報を携帯電話に通知できない場合、携帯電話が決済情報を効率的に得ることができないという問題がある。

すなわち、複数のＳＰが同一装置でサービス類を販売する場合、ＳＰごとに販売機構を設ける必要があるため、図１３（Ａ）に示すように、自動販売機５０内には複数の販売機構５３〜５５が存在することになる。この場合、決済情報を保持している販売機構（例えば、販売機構５５）が、保持する決済情報を携帯電話に送信すれば、携帯電話は、決済情報を保持している販売機構（販売機構５５）を特定することができる。一方、販売機構５３〜５５が決済情報を自発的に送信できない場合、携帯電話が決済情報を保持している販売機構（販売機構５５）を特定するためには、各販売機構５３〜５５が決済情報を保持しているか否かを確認するために、全ての販売機構５３〜５５にアクセスしなければならず、決済処理に時間がかかってしまう。

販売機構が自発的に決済情報を送信できない場合の例として、例えば、サービス類を提供する装置（上記の例では、自動販売機）と決済を行う外部機器（上記の例では、携帯電話）との間の無線通信方法に、非接触ＩＣカードで利用されている無線通信を適用する場合が挙げられる。具体的には、図１３（Ｂ）に示すように、送受信回路７１および複数の販売機構（ＳＰアプリケーション７２〜７４）が１枚のＩＣカード７０に格納され、このＩＣカード７０がサービス類を提供する装置に装着される形態が考えられる。この場合、販売機構はソフトウェアプログラムとして格納されるので、以下、販売機構に相当し、サービス類の販売処理を行うソフトウェアプログラムをＳＰアプリケーションと呼ぶ。

この場合、一般的なＩＣカード内のアプリケーションは、リーダ／ライタからの要求を受けてから動作するよう規格で定められているため、ＩＣカード７０内のＳＰアプリケーション７２〜７４は、自発的に決済情報を外部機器に通知することができない。したがって、リーダ／ライタである外部機器が、ＳＰアプリケーション７２〜７４に決済情報の通知を要求することになるが、外部機器は、決済情報を保持するＳＰアプリケーション（例えば、ＳＰアプリケーション７４）を特定することができないため、ＩＣカード７０内の全てのＳＰアプリケーション７２〜７４に対し、決済情報を保持しているか否かを確認するためにアクセスしなければならず、決済処理に時間がかかってしまう。また、この場合、外部機器が、ＩＣカード７０内の全てのＳＰアプリケーション７２〜７４についての情報を把握しなければならないという問題もある

上記問題点を解決する方法として、決済情報を保持するＳＰアプリケーション（ＳＰアプリケーション７４）を特定できる情報を外部機器に入力することで、外部機器が決済情報を保持しているＳＰアプリケーション（ＳＰアプリケーション７４）を特定できるようにする方法が考えられる。しかし、この方法では、ユーザが手入力をすることから、決済処理に時間がかかってしまうことは解決できない。

また、上記ＩＣカードの例では、ユーザが複数のＳＰアプリケーション（例えば、ＳＰアプリケーション７２およびＳＰアプリケーション７４）からサービス類を同時に購入しようとする場合、外部機器は、ＳＰアプリケーション（ＳＰアプリケーション７２およびＳＰアプリケーション７４）ごとに個別に決済処理を行わなければならず、決済処理に時間がかかってしまうという問題もある。

このように、特許文献２記載の方法にあっては、同一装置内に複数の販売機構が存在し、これらの販売機構が自発的に決済情報を携帯電話などの外部機器に通知できない場合、外部機器が決済情報を効率的に得ることができず、決済処理に時間がかかるという問題があった。

本発明は、かかる点に鑑みてなされたものであり、同一装置内に複数の販売機構が存在し、これらの販売機構が自発的に決済情報を外部機器に通知できない場合であっても、外部機器が決済情報を効率的に得ることができる、決済処理システムならびにこれに用いる電子装置および外部機器、ならびに決済情報管理方法および決済処理方法を提供することを目的とする。

本発明の決済処理システムは、物品またはサービスを販売する電子装置と、前記物品またはサービスの販売に伴う決済処理を行う外部機器と、を有し、前記電子装置は、外部機器と通信を行う通信手段と、選択された物品またはサービスを提供するための処理を行い、前記選択された物品またはサービスの提供に関する決済情報を作成する販売手段と、前記販売手段によって作成された決済情報を保持する決済情報保持手段と、前記決済情報保持手段に保持された決済情報を、前記通信手段を介して前記外部機器に送信する決済仲介手段と、を備え、前記外部機器は、前記電子装置と通信を行う通信手段と、前期決済仲介手段から前記外部機器の通信手段を介して前記決済情報を受信し、前記決済情報に基づいて決済処理を行う決済処理手段と、を備える。

本発明の電子装置は、外部機器と通信を行う通信手段と、選択された物品またはサービスを提供するための処理を行い、前記選択された物品またはサービスの提供に関する決済情報を作成する販売手段と、前記販売手段によって作成された決済情報を保持する決済情報保持手段と、前記決済情報保持手段に保持された決済情報を、前記通信手段を介して前記外部機器に送信する決済仲介手段と、を備える構成を採る。

本発明の外部機器は、本発明の電子装置から決済情報を受信し、決済処理を行う外部機器であって、前記電子装置と通信を行う通信手段と、前記通信手段を介して前記決済情報を受信し、前記決済情報に基づいて決済処理を行う決済処理手段と、を備える。

本発明の決済情報管理方法は、選択された物品またはサービスの提供に関する決済情報を作成するステップと、前記決済情報を決済情報保持手段で保持するステップと、前記決済情報保持手段に保持された決済情報を、外部機器に送信するステップと、を有する。

本発明の決済処理方法は、本発明の電子装置から複数の決済情報を受信し、決済処理を行う外部機器の決済処理方法であって、前記複数の決済情報を受信するステップと、前記決済情報それぞれに対応する対価情報を作成するステップと、全ての前記対価情報を含む合算対価情報を作成するステップと、前記対価情報および乱数からハッシュ関数を用いて得られる、前記対価情報それぞれに対応する対価情報ブロックデータを作成するステップと、前記合算対価情報および全ての対価情報ブロックデータを前記電子装置に送信するステップと、前記決済情報に基づいて決済処理を行うステップと、を有する。

本発明によれば、同一装置内に複数の販売機構が存在し、これらの販売機構が自発的に決済情報を外部機器に通知できない場合であっても、外部機器は決済仲介手段にアクセスするだけで電子装置内の全ての販売機構の決済情報を得ることができるため、外部機器が決済情報を効率的に得ることができ、決済処理にかかる時間を削減することができる。

以下、本発明の実施の形態について、図面を参照して説明する。

（実施の形態１）
図１は、本発明の実施の形態１に係る決済システムの構成を示すブロック図である。本実施の形態は、本発明に係る電子装置を非接触ＩＣカードの機能を備えたメモリカード（以下、「ＩＣカード」という）に適用した例である。

図１において、ＩＣカード決済システム１００は、ＩＣカード２００、ＡＶ機器３００、外部機器４００を備えて構成される。

ＩＣカード２００は、ＡＶ機器３００に装着可能な非接触ＩＣカードの機能を備えたメモリカードであり、ＡＶ機器３００および外部機器４００との間で各種情報を送受信することができる。また、ＳＰが提供する動画や音楽などのコンテンツをＡＶ機器３００が利用不可能な状態で格納しており、外部機器４００から決済処理を完了したことを通知されると、ＡＶ機器３００がコンテンツを利用（再生）できるようにする。

ＡＶ機器３００は、ＩＣカード２００を装着できるように構成されている。また、ＡＶ機器３００は、ＩＣカード２００との間でコンテンツの選択および再生に関する情報を送受信することができ、ＩＣカード２００内のコンテンツの選択および再生を行う。

外部機器４００は、ＩＣカード２００との間で決済に関する情報を送受信することができ、ＩＣカード２００内のコンテンツを購入する際に決済処理を行う。

ＩＣカード２００は、接触通信部２０２、非接触通信部２０４、カードマネージャ２０６、決済仲介部２０８、ＳＰアプリケーション２１２〜２１６、を備えて構成される。

接触通信部２０２は、ＩＣカード２００内のアプリケーションや機能部とＡＶ機器３００との間の通信を行う。

非接触通信部２０４は、ＩＣカード２００内のアプリケーションや機能部と外部機器４００との間の通信を行う。

カードマネージャ２０６は、ＩＣカード２００内のアプリケーションを統括する。具体的には、例えば、ＩＣカード２００内のＳＰアプリケーション２１２〜２１６のリスト（以下、「ＳＰアプリケーション一覧」という）を作成し、外部（例えば、ＡＶ機器３００）からの要求に応じてＳＰアプリケーション一覧を送信する。

決済仲介部２０８は、ユーザがＳＰアプリケーション２１２〜２１６内のコンテンツを購入し、外部機器４００を用いて決済するときに、ＳＰアプリケーション２１２〜２１６と外部機器４００の決済処理部４０６〜４１０との間の決済に関する情報のやりとりを仲介する。また、必要に応じて、内部に備える決済情報保持メモリ２１０に決済処理に関する情報を格納する。例えば、ＳＰアプリケーション２１２〜２１６が、決済処理部４０６〜４１０に決済情報（後述）を通知するときに、決済仲介部２０８は、決済情報を保持するＳＰアプリケーション（例えば、ＳＰアプリケーション２１６）から決済情報を一旦入力し、決済情報保持メモリ２１０に格納する。その後、決済処理部（例えば、決済処理部４０６）が、各ＳＰアプリケーション２１２〜２１６の決済情報を要求してきた際に、格納した決済情報を決済処理部（決済処理部４０６）に送信する。

ＳＰアプリケーション２１２〜２１６は、ＳＰが動画や音楽などのコンテンツを提供する販売手段であり、ＩＣカードが有するメモリ部（図示しない）にソフトウェアプログラムとして格納されている。ＳＰアプリケーション２１２〜２１６は、コンテンツを提供するＳＰごとに設けられ、また、各ＳＰアプリケーション２１２〜２１６には、それぞれ一つ以上のコンテンツが格納されている。各ＳＰアプリケーション２１２〜２１６は、ＡＶ機器３００が利用不可能な状態でコンテンツを格納するが、外部機器４００から決済処理を完了したことを通知されると、ＡＶ機器３００がコンテンツを利用できるようにする。

ＡＶ機器３００は、ＧＵＩ部３０２およびコンテンツ再生部３０４を備えて構成される。

ＧＵＩ部３０２は、ユーザがＩＣカード２００内に格納されたＳＰアプリケーション２１２〜２１６および各ＳＰアプリケーション２１２〜２１６が販売するコンテンツを選択するための入力部である。また、ＧＵＩ部３０２は、選択されたＳＰアプリケーション（例えば、ＳＰアプリケーション２１２）を起動し、選択されたコンテンツを起動したＳＰアプリケーション（ＳＰアプリケーション２１２）に通知する。

コンテンツ再生部３０４は、ＩＣカード２００内の利用可能なコンテンツを再生する。

外部機器４００は、通信部４０２、ＧＵＩ部４０４、決済処理部４０６〜４１０を備えて構成される。

通信部４０２は、ＩＣカード２００の非接触通信部２０４と無線通信を行い、決済に関する情報を送受信する。

ＧＵＩ部４０４は、決済処理を行う決済手段をユーザが選択するための入力部である。決済手段としては、例えば、各種電子マネーによる決済や各種クレジットカード会社による決済、各種金融機関による決済などが挙げられる。

決済処理部４０６〜４１０は、外部機器４００が対応する決済手段の数だけ設けられており、決済処理部４０６〜４１０は、それぞれ所定の決済手段による決済処理を実行する。

以下、上述のように構成された決済システム１００の動作について説明する。

まず、決済システム１００における、コンテンツ選択からコンテンツ再生までの全体の流れについて説明する。決済に関する情報のやりとりについては、図３に示すシーケンス図を用いて後述する。

まず、ＩＣカード２００がＡＶ機器３００に装着され、ＡＶ機器３００の電源が入れられると、ＡＶ機器３００のＧＵＩ部３０２に、ＩＣカード２００内に格納されたコンテンツ（およびそのコンテンツを販売するＳＰアプリケーション）の一覧が表示される。

次に、ユーザは、ＧＵＩ部３０２を操作し、コンテンツ（およびそのコンテンツを販売するＳＰアプリケーション）を選択する。図２（Ａ）は、ＧＵＩ部３０２のＳＰ（アプリケーション）一覧の表示例であり、サービスプロバイダＡ（のＳＰアプリケーション）が選択された場合を示す図である。また、図２（Ｂ）は、ＧＵＩ部３０２のコンテンツ一覧の表示例であり、映画Ｂが選択された場合を示す図である。以下、ユーザがＳＰアプリケーション２１４を選択したものとして説明する。なお、この時点では、選択されたＳＰアプリケーション２１４は、選択されたコンテンツを利用不可能な状態にしているので、ＡＶ機器３００のコンテンツ再生部３０４は、選択されたコンテンツを再生することはできない。

次に、ユーザは、外部機器４００のＧＵＩ部４０４を操作し、決済手段を選択する。図２（Ｃ）は、ＧＵＩ部４０４の決済手段選択画面の表示例であり、決済手段として電子マネーＡが選択された場合を示す図である。以下、ユーザが決済処理部４１０に対応する決済手段を選択したものとして説明する。

次に、外部機器４００は、コンテンツが選択されたＩＣカード２００と通信を開始する。通信開始後、決済に関する情報が、ユーザに選択された決済処理部４１０とＳＰアプリケーション２１４との間でやりとりされる。このとき、決済仲介部２０８が決済に関する情報を仲介するので、決済処理部４１０は、ＳＰアプリケーション２１４とではなく、決済仲介部２０８との間で決済に関する情報の送受信を行う。外部機器４００は、決済に関する情報を送受信した後、選択されたコンテンツ購入に伴う決済処理を決済処理部４１０で行う。決済に関する情報のやりとりについては、図３に示すシーケンス図を用いて後述する。

決済処理が完了すると、ＳＰアプリケーション２１４は、選択されたコンテンツを利用可能な状態にする。

以後、ＡＶ機器３００は、ユーザの希望に応じて、選択されたコンテンツをコンテンツ再生部３０４で再生する。

次に、図１に示す決済システム１００における決済に関する情報のやりとりについて、図３に示すシーケンス図を用いて説明する。

図３は、図１の決済システム１００において、ユーザが、ＩＣカード２００内のコンテンツを購入するときに、外部機器４００を用いて決済を行う手順を示すシーケンス図である。

まず、ＡＶ機器３００の電源が入れられると、ＧＵＩ部３０２は、ＳＰアプリケーション一覧要求を作成し、接触通信部２０２を介してカードマネージャ２０６に送信する（Ｓ１００）。

カードマネージャ２０６は、ＳＰアプリケーション一覧要求を解釈し、保有するＳＰアプリケーション一覧を接触通信部２０２を介してＧＵＩ部３０２に送信する（Ｓ１０１）。

情報を受け取ったＧＵＩ部３０２は、ＳＰアプリケーション一覧を表示する（Ｓ１０２）。ユーザは、ＧＵＩ部３０２を操作し、ＳＰアプリケーション２１２〜２１６および購入コンテンツを選択する。以下、図３に示す例では、ユーザが、ＳＰアプリケーション２１２が提供するコンテンツを選択したものとして説明する。

ＧＵＩ部３０２は、選択されたＳＰアプリケーション２１２を接触通信部２０２を介して起動し、選択されたコンテンツを通知する（Ｓ１０３）。

ＳＰアプリケーション２１２は、決済情報を作成し、決済仲介部２０８に出力する（Ｓ１０４）。決済情報とは、選択されたコンテンツを提供するＳＰアプリケーションを特定する識別子（以下、「ＳＰＩＤ」と略記する）、選択されたコンテンツを特定する識別子（以下、「コンテンツＩＤ」と略記する）および選択されたコンテンツの金額情報を含む情報である。図４（Ａ）は、決済情報の一例を示す図である。なお、決済情報には、ポイント情報やクーポン情報などの金額以外の情報を含めても良い。

決済仲介部２０８は、決済情報を決済情報保持メモリ２１０に格納する（Ｓ１０５）。

次に、ユーザは、外部機器４００のＧＵＩ部４０４を操作し、決済手段を選択する。以下、図３に示す例では、ユーザが、決済処理部４０６に対応する決済手段を選択したものとして説明する。ＧＵＩ部４０４は、選択された決済手段に対応する決済処理部４０６を起動する（Ｓ１０６）。

決済処理部４０６は、決済情報取得要求を作成し、通信部４０２および非接触通信部２０４を介して決済仲介部２０８に送信する（Ｓ１０７）。

決済仲介部２０８は、決済情報取得要求を解釈し、保持している決済情報（この場合、ＳＰアプリケーション２１２の決済情報）を非接触通信部２０４および通信部４０２を介して決済処理部４０６に送信する（Ｓ１０８）。

決済処理部４０６は、受信した決済情報内のコンテンツの金額に等しい額の電子マネーを含む対価情報を作成し、通信部４０２および非接触通信部２０４を介して決済仲介部２０８に送信する（Ｓ１０９）。図４（Ｂ）に対価情報の一例を示す。

決済仲介部２０８は、保持する決済情報を参照して、受信した対価情報を対応するＳＰアプリケーション２１２に出力する（Ｓ１１０）。なお、対価情報を受信したことは、決済仲介部２０８が決済情報を受信したことを意味するので、決済情報保持メモリ２１０は、メモリ容量が足りなくなることがないように、保持している決済情報を削除するのが好ましい。

ＳＰアプリケーション２１２は、入力した対価情報を確認して問題がなければ、対価情報に自身のＳＰＩＤおよび提供するコンテンツのコンテンツＩＤを加えた決済証書情報を作成し、決済仲介部２０８に出力する（Ｓ１１１）。図４（Ｃ）に決済証書情報の一例を示す。

決済仲介部２０８は、入力した決済証書情報を決済情報保持メモリ２１０に格納すると共に、非接触通信部２０４および通信部４０２を介して決済処理部４０６に送信する（Ｓ１１２）。

決済処理部４０６は、受信した決済証書情報に基づいて決済処理を行う。決済処理が完了した後、決済が完了したことを伝える決済完了情報を作成し、通信部４０２および非接触通信部２０４を介して決済仲介部２０８に送信する（Ｓ１１３）。

決済仲介部２０８は、決済完了情報をＳＰアプリケーション２１２に出力する（Ｓ１１４）。なお、決済完了情報を受信したことは、決済処理部４０６が決済証書情報を受信したことを意味するので、決済情報保持メモリ２１０は、メモリ容量が足りなくなることがないように、保持している決済証書情報を削除するのが好ましい。

ＳＰアプリケーション２１２は、決済完了情報を入力した後、ユーザが選択したコンテンツを利用可能にする（Ｓ１１５）。以後、ユーザは、ＡＶ機器のコンテンツ再生部３０４を用いて、好きなときにコンテンツを再生することができる。

ＳＰアプリケーション２１２は、決済完了情報に対する返答（ＡＣＫ）を決済仲介部２０８に出力する（Ｓ１１６）。

決済仲介部２０８は、ＡＣＫを非接触通信部２０４および通信部４０２を介して決済処理部４０６に送信し、通信を終了する（Ｓ１１７）。

以上のように、本実施の形態によれば、電子装置上の複数のＳＰアプリケーション（販売手段）は決済情報を決済仲介部に通知し、決済仲介部は各ＳＰアプリケーションの決済情報を決済情報保持メモリに保持することで、外部機器の決済処理部は、全てのＳＰアプリケーションにアクセスする必要なく、決済仲介部にアクセスするだけで決済情報を取得することができる。したがって、従来の技術と比較して、外部機器との間の決済処理を短時間に完了することができる。

（実施の形態２）
実施の形態１では、外部機器がＳＰアプリケーションごとに決済処理を行う例を示した。実施の形態２は、外部機器が複数のＳＰアプリケーションの決済処理をまとめて行う例を示す。

図５は、本発明の実施の形態２に係る決済システムの構成を示すブロック図である。実施の形態１に係る決済システムと同じ構成要素については同一の符号を付し、重複箇所の説明を省略する。

図５において、決済システム５００は、ＩＣカード６００、ＡＶ機器３００、外部機器７００を備えて構成される。

ＩＣカード６００は、接触通信部２０２、非接触通信部２０４、カードマネージャ２０６、決済仲介部６０２、ＳＰアプリケーション６０６〜６１０を備えて構成される。決済仲介部６０２およびＳＰアプリケーション６０６〜６１０以外のものは、実施の形態１と同様のものなのでここでは説明しない。

決済仲介部６０２は、決済情報保持メモリ２１０および対価情報置換部６０４を備えて構成される。決済情報保持メモリ２１０は、実施の形態１と同様のものなのでここでは説明しない。

対価情報置換部６０４は、個別対価情報を作成する。個別対価情報については図９を参照しながら後述する。

ＳＰアプリケーション６０６〜６１０は、それぞれ、外部機器７００の決済処理部７０２〜７０６の数とそれぞれ同数（例えば、図５に示す構成の場合は３つ）のハッシュ関数７０８〜７１２および検証用公開鍵６１２〜６１６を有する。なお、ハッシュ関数７０８〜７１２および検証用公開鍵６１２〜６１６は、ＩＣカード６００内の耐タンパなメモリ領域（図示しない）に格納されることが好ましい。

ハッシュ関数７０８〜７１２は、個別対価情報を検証する際に用いられる関数である。各ＳＰアプリケーション６０６〜６１０は、決済処理部７０２〜７０６が有するハッシュ関数と同じ関数を全て有する。

検証用公開鍵６１２〜６１６は、各決済処理部７０２〜７０６が作成した署名付き合算対価情報ブロックデータ（後述）を検証する際に用いられる鍵である。各ＳＰアプリケーション６０６〜６１０は、決済処理部７０２〜７０６が有する署名用秘密鍵（後述）に対応する検証用公開鍵を全て有する。

外部機器７００は、通信部４０２、ＧＵＩ部４０４、決済処理部７０２〜７０６を備えて構成される。通信部４０２およびＧＵＩ部４０４は、実施の形態１と同様のものなのでここでは説明しない。

決済処理部７０２〜７０６は、それぞれハッシュ関数７０８〜７１２および署名用秘密鍵７１４〜７１８を一つずつ有する。

ハッシュ関数７０８〜７１２は、ＳＰアプリケーションの対価情報を対価情報ブロックデータ（後述）に変換する際に用いられる関数である。決済処理部７０２〜７０６は、それぞれ異なるハッシュ関数を有する。

署名用秘密鍵７１４〜７１８は、合算対価情報ブロックデータ（後述）を署名付き合算対価情報ブロックデータ（後述）に変換する際に用いられる鍵である。決済処理部７０２〜７０６は、それぞれ異なる署名用秘密鍵を有する。

以下、上述のように構成された決済システムの動作について説明する。コンテンツ選択からコンテンツ再生までの全体の流れについては、実施の形態１とほぼ同じなので説明しない。ここでは、図５に示す決済システム５００における決済に関する情報のやりとりについて、図６に示すシーケンス図を用いて詳細に説明する。

図６は、図５の決済システム５００において、ユーザが、ＩＣカード６００内のコンテンツを購入するときに、外部機器７００を用いて決済を行う手順を示すシーケンス図である。

まず、ＡＶ機器３００の電源が入れられると、ＧＵＩ部３０２は、ＳＰアプリケーション一覧要求を作成し、接触通信部２０２を介してカードマネージャ２０６に送信する（Ｓ２００）。

カードマネージャ２０６は、ＳＰアプリケーション一覧要求を解釈し、カードマネージャ２０６に登録されているＳＰアプリケーション一覧を接触通信部２０２を介してＧＵＩ部３０２に送信する（Ｓ２０１）。

情報を受け取ったＧＵＩ部３０２は、ＳＰアプリケーション一覧を表示する（Ｓ２０２）。ユーザは、ＧＵＩ部３０２を操作し、ＳＰアプリケーション６０６〜６１０および購入コンテンツを選択する。以下、図６に示すシーケンス図では、ユーザが、ＳＰアプリケーション６０６およびＳＰアプリケーション６０８が提供するコンテンツをそれぞれ一つずつ選択したものとして説明する。

ＧＵＩ部３０２は、選択された第一のＳＰアプリケーション６０６を接触通信部２０２を介して起動し、選択されたコンテンツを通知する（Ｓ２０３）。

ＳＰアプリケーション６０６は、決済情報（ＳＰＩＤ、コンテンツＩＤ、コンテンツの金額）を作成し、決済仲介部６０２に出力する（Ｓ２０４）。

決済仲介部６０２は、ＳＰアプリケーション６０６の決済情報を決済情報保持メモリ２１０に格納する（Ｓ２０５）。

ＧＵＩ部３０２は、選択された第二のＳＰアプリケーション６０８を接触通信部２０２を介して起動し、選択されたコンテンツを通知する（Ｓ２０６）。

ＳＰアプリケーション６０８は、決済情報を作成し、決済仲介部６０２に出力する（Ｓ２０７）。

決済仲介部６０２は、入力したＳＰアプリケーション６０８の決済情報を決済情報保持メモリ２１０に格納する（Ｓ２０８）。

次に、ユーザは、外部機器７００のＧＵＩ部４０４を操作し、決済手段を選択する。以下、図６に示すシーケンス図では、ユーザが決済処理部７０２に対応する決済手段を選択したものとして説明する。ＧＵＩ部４０４は、選択された決済手段に対応する決済処理部７０２を起動する（Ｓ２０９）。

決済処理部７０２は、決済情報取得要求を作成し、通信部４０２および非接触通信部２０４を介して決済仲介部６０２に送信する（Ｓ２１０）。

決済仲介部６０２は、決済情報取得要求を解釈し、決済情報保持メモリ２１０が保持している複数の決済情報（この場合、ＳＰアプリケーション６０６およびＳＰアプリケーション６０８の決済情報）を非接触通信部２０４および通信部４０２を介して決済処理部７０２に送信する（Ｓ２１１）。

決済処理部７０２は、合算電子マネー、合算対価情報、受信した決済情報と同数（図６に示す例では、二つ）の対価情報ブロックデータ、受信した決済情報と同数（図６に示す例では、二つ）の乱数、合算対価情報ブロックデータおよび署名付き合算対価情報ブロックデータを作成し、通信部４０２および非接触通信部２０４を介して、決済仲介部６０２に送信する（Ｓ２１２）。

ここで、合算電子マネー、合算対価情報、対価情報ブロックデータ、乱数、合算対価情報ブロックデータおよび署名付き合算対価情報ブロックデータの作成手順について図７および図８を用いて説明する。

合算電子マネーは、受信した複数の決済情報に含まれる決済金額の合計額と同額の電子マネーである。図６に示す例では、合算電子マネーの金額はＳＰアプリケーション６０６の決済金額とＳＰアプリケーション６０８の決済金額の合計額である。図７（Ａ）に合算電子マネーの一例を示す。

合算対価情報は、各ＳＰアプリケーションについての対価情報が記載された情報である。図６に示す例では、合算対価情報はＳＰアプリケーション６０６についての対価情報およびＳＰアプリケーション６０８についての対価情報が記載された情報であり、図８（Ａ）に示すようになる。

対価情報ブロックデータは、合算対価情報に含まれる各ＳＰアプリケーションの対価情報に、それぞれ異なる乱数を加え、ハッシュ関数（図６に示す例では、決済処理部７０２が有するハッシュ関数７０８）を施したデータである。このようにすることで、ＳＰアプリケーションは、対価情報ブロックデータの内容を把握することができなくなる。対価情報ブロックデータは、合算対価情報に含まれる全ての対価情報について作成されるので、合算対価情報に含まれる対価情報の数だけ作成されることになる。図６に示す例では、ＳＰアプリケーション６０６およびＳＰアプリケーション６０８の対価情報が合算対価情報に含まれるので、ＳＰアプリケーション６０６の対価情報を変換して得られるデータ（以下、「対価情報ブロックデータ１」という）およびＳＰアプリケーション６０８の対価情報を変換して得られるデータ（以下、「対価情報ブロックデータ２」という）の、二つの対価情報ブロックデータが、図８（Ｂ）および（Ｃ）に示す手順で作成される。

乱数は、対価情報にハッシュ関数を施して対価情報ブロックデータを作成する際に利用するデータである。このとき、異なる対価情報には異なる乱数を加えるので、乱数は合算対価情報に含まれる対価情報の数だけ作成される。図６に示す例では、対価情報ブロックデータ１を作成する際に用いられる乱数（以下、「乱数１」という）および対価情報ブロックデータ２を作成する際に用いられる乱数（以下、「乱数２」という）の、二つの乱数が作成される。

合算対価情報ブロックデータは、各ＳＰアプリケーションについての対価情報ブロックデータを統合したデータである。図６に示す例では、対価情報ブロックデータ１および対価情報ブロックデータ２が図８（Ｄ）に示すように統合され、合算対価情報ブロックデータが作成される。

署名付き合算対価情報ブロックデータは、合算対価情報ブロックデータに署名用秘密鍵を用いて作成した署名を付けたデータである。図６に示す例では、署名付き合算対価情報ブロックデータは、合算対価情報ブロックデータおよび署名用秘密鍵７１４を用いて図８（Ｅ）に示す手順で作成される。

図６に示すシーケンス図の説明に戻る。決済仲介部６０２は、個別対価情報１を対価情報置換部６０４によって作成し、合算電子マネー、個別対価情報１、合算対価情報ブロックデータ、署名付き合算対価情報ブロックデータおよび乱数１をＳＰアプリケーション６０６に出力する（Ｓ２１３）。

ここで、個別対価情報とは、合算対価情報に含まれる全ての対価情報のうち、送信先となるＳＰアプリケーション以外のＳＰアプリケーションの対価情報を、対応する対価情報ブロックデータに置換したものである。図６に示す例では、決済仲介部６０２が、個別対価情報をＳＰアプリケーション６０６に送信する場合、対価情報置換部６０４は、図９に示すように、合算対価情報中の二つの対価情報のうち、ＳＰアプリケーション６０８の対価情報を対価情報ブロックデータ２（ＳＰアプリケーション６０８の対価情報に乱数２を加え、ハッシュ関数を施したデータ）に置換し、個別対価情報１を作成する。決済仲介部６０２は、合算対価情報ではなく、個別対価情報１をＳＰアプリケーション６０６に送信することで、ＳＰアプリケーション６０６にＳＰアプリケーション６０８の対価情報を知られることを防ぐことができる。

図６に示すシーケンス図の説明に戻る。ＳＰアプリケーション６０６は、入力した個別対価情報１が正当なものであるか否かを確認するために、入力した情報（合算電子マネー、個別対価情報１、合算対価情報ブロックデータ、署名付き合算対価情報ブロックデータおよび乱数１）、対価情報の作成元である決済処理部７０２が有するものと同じハッシュ関数７０８、および決済処理部７０２が有する署名用秘密鍵７１４に対応する検証用公開鍵６１２を用いて、個別対価情報１の検証を行う（Ｓ２１４）。

ここで、ＳＰアプリケーション６０６が、個別対価情報１の検証を行う手順を、図１０を参照しながら説明する。

まず、個別対価情報１内のＳＰアプリケーション６０６の対価情報に乱数１を加えたものにハッシュ関数７０８を施し、ハッシュデータを求める（図１０（Ａ）参照）。

次に、求めたハッシュデータおよび対価情報ブロックデータ２を統合したデータと合算対価情報ブロックデータとを比較し、同一であることを確認する（図１０（Ｂ）参照）。

次に、署名付き合算対価情報ブロックデータを検証用公開鍵６１２で検証し、署名検証用データを作成する（図１０（Ｃ）参照）。

最後に、署名検証用データと合算対価情報ブロックデータとを比較し同一であることを確認する（図１０（Ｄ）参照）。

以上の検証処理において、ハッシュデータおよび対価情報ブロックデータ２を統合したデータと合算対価情報ブロックデータとが同一でない場合、または、署名検証用データと合算対価情報ブロックデータとが同一でない場合、ＳＰアプリケーション６０６は、個別対価情報１が不正なものであると判断し、以後の決済の手続を進めずにエラーを決済仲介部６０２に返す。一方、ハッシュデータおよび対価情報ブロックデータ２を統合したデータと合算対価情報ブロックデータとが同一、かつ、署名検証用データと合算対価情報ブロックデータとが同一の場合、ＳＰアプリケーション６０６は、個別対価情報１が正当なものであると判断し、決済の決済を続行する。以下、個別対価情報１が正当なものであると判断したものとして説明を続ける。

図６に示すシーケンス図の説明に戻る。ＳＰアプリケーション６０６は、個別対価情報１を確認して問題がなければ、入力した合算電子マネーに自身のＳＰＩＤおよび提供するコンテンツのコンテンツＩＤを加えた決済証書情報を作成し、決済仲介部６０２に出力する（Ｓ２１５）。

決済仲介部６０２は、合算対価情報に含まれる対価情報のうち、ＳＰアプリケーション６０６の対価情報を対価情報ブロックデータ１に置換した個別対価情報２を対価情報置換部６０４に作成させた後、合算電子マネー、個別対価情報２、合算対価情報ブロックデータ、署名付き合算対価情報ブロックデータおよび乱数２をＳＰアプリケーション６０８に出力する（Ｓ２１６）。決済仲介部６０２は、合算対価情報ではなく、個別対価情報２をＳＰアプリケーション６０８に送信することで、ＳＰアプリケーション６０８にＳＰアプリケーション６０６の対価情報を知られることを防ぐことができる。なお、合算電子マネーなどの情報を受信したということは、決済処理部７０２が決済情報を受信したということを意味するので、決済情報保持メモリ２１０は、メモリ容量が足りなくなることがないように、保持している決済情報を削除するのが好ましい。

ＳＰアプリケーション６０８は、入力した個別対価情報２が正当なものであるか否かを確認するために、入力した情報（合算電子マネー、個別対価情報２、合算対価情報ブロックデータ、署名付き合算対価情報ブロックデータおよび乱数２）、対価情報の作成元である決済処理部７０２が有するものと同じハッシュ関数７０８、および決済処理部７０２が有する署名用秘密鍵７１４に対応する検証用公開鍵６１２を用いて、Ｓ２１４の手順と同様に、個別対価情報２の検証を行う（Ｓ２１７）。検証の結果、ＳＰアプリケーション６０８が、個別対価情報２が不正なものであると判断した場合、ＳＰアプリケーション６０８は、以後の決済処理を進めずにエラーを決済仲介部６０２に返す。一方、ＳＰアプリケーション６０８が、個別対価情報２が正当なものであると判断した場合、ＳＰアプリケーション６０８は決済処理を続行する。以下、個別対価情報２が正当なものであると判断したものとして説明を続ける。

ＳＰアプリケーション６０８は、個別対価情報２を確認して問題がなければ、受信した合算電子マネーに自身のＳＰＩＤおよび提供するコンテンツのコンテンツＩＤを加えた決済証書情報を作成し、決済仲介部６０２に出力する（Ｓ２１８）。

決済仲介部６０２は、ＳＰアプリケーション６０６およびＳＰアプリケーション６０８から受信した決済証書情報を基に合算決済証書情報を作成し、決済情報保持メモリ２１０に格納するとともに、非接触通信部２０４および通信部４０２を介して決済処理部７０２に送信する（Ｓ２１９）。図７（Ｂ）に合算決済証書情報の一例を示す。

決済処理部７０２は、受信した合算決済証書情報に基づいて決済処理を行う。決済処理が完了した後、決済が完了したことを伝える決済完了情報を作成し、通信部４０２および非接触通信部２０４を介して決済仲介部６０２に送信する（Ｓ２２０）。

決済仲介部６０２は、受信した決済完了情報をＳＰアプリケーション６０６に出力する（Ｓ２２１）。なお、決済完了情報を受信したことは、決済処理部７０２が合算決済証書情報を受信したことを意味するので、決済情報保持メモリ２１０は、メモリ容量が足りなくなることがないように、保持しているＳＰアプリケーション６０６の決済証書情報を削除するのが好ましい。

決済完了情報を入力したＳＰアプリケーション６０６は、ユーザが選択したコンテンツを利用可能にする（Ｓ２２２）。以後、ユーザは、ＡＶ機器のコンテンツ再生部３０４を用いて、好きなときに購入したＳＰアプリケーション６０６のコンテンツを再生することができる。

ＳＰアプリケーション６０６は、決済完了情報に対する返答（ＡＣＫ）を、決済仲介部６０２に出力する（Ｓ２２３）。

決済仲介部６０２は、受信した決済完了情報をＳＰアプリケーション６０８に出力する（Ｓ２２４）。なお、決済完了情報を受信したということは、決済処理部７０２が合算決済証書情報を受信したということを意味するので、決済情報保持メモリ２１０は、メモリ容量が足りなくなることがないように、保持しているＳＰアプリケーション６０８の決済証書情報および合算決済証書情報を削除するのが好ましい。

決済完了情報を入力したＳＰアプリケーション６０８は、ユーザが選択したコンテンツを利用可能にする（Ｓ２２５）。以後、ユーザは、ＡＶ機器のコンテンツ再生部３０４を用いて、好きなときに購入したＳＰアプリケーション６０８のコンテンツを再生することができる。

ＳＰアプリケーション６０８は、決済完了情報に対する返答（ＡＣＫ）を決済仲介部６０２に出力する（Ｓ２２６）。

決済仲介部６０２は、ＳＰアプリケーション６０６およびＳＰアプリケーション６０８からの入力したＡＣＫを非接触通信部２０４および通信部４０２を介して決済処理部７０２に送信する（Ｓ２２７）。

このように本実施の形態によれば、実施の形態１の効果に加えて、ユーザが複数のＳＰアプリケーションで同時にコンテンツを購入する場合であっても、決済仲介部は複数のＳＰアプリケーションの決済情報を決済処理部に同時に送信し、決済処理部は合計額に値する合算電子マネーと個々のＳＰアプリケーションに支払う額が記載された合算対価情報とを同時に決済仲介部に送信することで、決済処理部と決済仲介部との間の通信を一度行うだけで決済処理を完了することができる。したがって、各ＳＰアプリケーションと個別に通信を行う従来技術に比べて、決済処理を高速化することができる。

また、本実施の形態によれば、実施の形態１の効果に加えて、複数のＳＰアプリケーションで同時にコンテンツを購入する場合であっても、決済仲介部は、各ＳＰアプリケーションについての対価情報をそのまま含む合算対価情報ではなく、出力先のＳＰアプリケーション以外のＳＰアプリケーションについての対価情報を対応するブロックデータに置換した個別対価情報を各ＳＰアプリケーションに送信することで、各ＳＰアプリケーションに他のＳＰアプリケーションについての対価情報を知られることを防ぐことができる。

また、本実施の形態によれば、実施の形態１の効果に加えて、各ＳＰアプリケーションは、合算電子マネー、個別対価情報、合算対価情報ブロックデータ、署名付き合算対価情報ブロックデータ、乱数、ハッシュ関数および検証用公開鍵を用いて個別対価情報の正当性を検証することで、不正な個別対価情報に基づく決済を防ぐことができる。

なお、上記各実施の形態では、本発明の電子装置として非接触ＩＣカードの機能を備えたメモリカードを用いた例について説明したが、本発明はこれに限定されず、その要旨を逸脱しない範囲において様々な態様で実施し得る。

また、上記各実施の形態では、本発明の電子装置に備えられる販売手段として、ソフトウェアプログラムであるＳＰアプリケーションを用いた例について説明したが、本発明の電子装置に備えられる販売手段は、ソフトウェアプログラムに限定されない。

また、上記各実施の形態では、ＳＰアプリケーションから決済仲介手段への決済情報の送信時に署名検証を行わなかったが、署名検証を行うようにしても良い。例えば、各ＳＰアプリケーションは、それぞれが保有する署名用秘密鍵によって決済情報に署名を付けた後、決済情報を決済仲介部に送信するようにし、決済仲介部は、保有する各ＳＰアプリケーションの検証用公開鍵によって決済情報の署名を検証するようにしても良い。これにより、決済仲介部は、不正なＳＰアプリケーションからの決済情報を把握でき、不正な決済処理を防げることができる。

なお、上記実施の形態１では、決済処理部からＳＰアプリケーションへの対価情報の送信時に署名検証を行わなかったが、署名検証を行うようにしても良い。例えば、各決済処理部は、それぞれが保有する署名用秘密鍵によって対価情報に署名を付けた後、対価情報をＳＰアプリケーションに送信するようにし、ＳＰアプリケーションは、保有する各決済処理部の検証用公開鍵によって対価情報の署名を検証するようにしても良い。これにより、ＳＰアプリケーションは、不正な決済処理部からの対価情報を把握でき、不正な決済処理を防げることができる。

また、上記各実施の形態では、決済仲介部が決済証書情報（合算決済証書情報を含む）を決済処理部へ一度だけ送信する場合について説明したが、決済仲介部は決済証書情報を必要に応じて再送信するようにしても良い。例えば、決済仲介部は、決済処理部へ決済証書情報を送信した後、予め設定された時間内に決済処理部から決済完了情報を受信しない場合、次の決済処理時に保持している決済証書情報を再送信するようにしても良い。これにより、何らかの障害によって決済証書情報が決済仲介部から決済処理部に通知されない時でも、障害が回復した後に決済処理を完了することができる。

また、上記各実施の形態では、外部機器は、外部機器内で決済処理を実行したが、外部機器は、通信手段を介して図示しない外部の決済サーバへ決済処理を依頼するようにしてもよい。例えば、外部機器として携帯電話を用いて、携帯電話の無線通信機能を利用してクレジットカード会社や金融機関などの決済サーバへ決済処理を依頼するようにしても良い。これにより、決済手段の幅をより広げることができる。

本発明に係る電子装置および決済処理方法は、ＩＣカードなどのセキュアデバイスを装着でき、コンテンツの再生など様々なアプリケーション実行を行う、ネットワーク通信機能を持たないＡＶ機器や携帯情報端末（ＰＤＡ）などの情報処理装置におけるコンテンツ購入などにおいて有用である。

本発明の実施の形態１に係る決済システムの構成を示すブロック図 （Ａ）ＡＶ機器のＧＵＩ部におけるサービスプロバイダ一覧の表示例を示す図、（Ｂ）ＡＶ機器のＧＵＩ部におけるコンテンツ一覧の表示例を示す図、（Ｃ）外部機器のＧＵＩ部における決済手段選択画面の一例を示す図 上記実施の形態１に係る決済システムにおいて決済を行う手順を示すシーケンス図 （Ａ）決済情報の一例を示す図、（Ｂ）対価情報の一例を示す図、（Ｃ）決済証書情報の一例を示す図 本発明の実施の形態２に係る決済システムの構成を示すブロック図 上記実施の形態２に係る決済システムにおいて決済を行う手順を示すシーケンス図 （Ａ）合算電子マネーの一例を示す図、（Ｂ）合算決済証書情報の一例を示す図 （Ａ）合算対価情報の一例を示す図、（Ｂ）合算対価情報からＳＰアプリケーションの対価情報を作成する手順を示す図、（Ｃ）ＳＰアプリケーションの対価情報から対価情報ブロックデータを作成する手順を示す図、（Ｄ）対価情報ブロックデータから合算対価情報ブロックデータを作成する手順を示す図、（Ｅ）合算対価情報ブロックデータから署名付き合算対価情報ブロックデータを作成する手順を示す図 ＳＰアプリケーションの対価情報を二つ含む合算対価情報から個別対価情報を作成する手順を示す図 個別対価情報の署名検証を行う手順を示す図であって、（Ａ）は個別対価情報からハッシュデータを作成する手順を示す図、（Ｂ）はハッシュデータと合算対価情報ブロックデータとを比較することを示す図、（Ｃ）は署名付き合算対価情報ブロックデータから署名検証用データを作成する手順を示す図、（Ｄ）は署名検証用データと合算対価情報ブロックデータとを比較することを示す図 従来の決済処理システムの構成を示すブロック図 （Ａ）従来の情報処理システムの構成を示す図、（Ｂ）（Ａ）の自動販売機の構成を示すブロック図 本発明の課題を説明するための図

符号の説明

１０ 決済処理システム
１２ ＰＣ
１４ 通信網
１６〜１８ ＥＣモールサーバ
２０〜２２ 決済モールシステム
２４ 決済システム
２６ クレジットオンラインシステム
２８〜３０ 決済業務サーバ
４０ 情報処理システム
５０ 自動販売機
５１ 送受信回路
５２〜５５ 販売機構
６０ 携帯電話
６２ 無線基地局
６４ 電話回線網
６６ 取引銀行
７０ ＩＣカード
７１ 送受信回路
７２〜７４ ＳＰアプリケーション
１００，５００ 決済システム
２００，６００ ＩＣカード
２０２ 接触通信部
２０４ 非接触通信部
２０６ カードマネージャ
２０８，６０２ 決済仲介部
２１０ 決済情報保持メモリ
２１２〜２１６，６０６〜６１０ ＳＰアプリケーション
３００ ＡＶ機器
３０２ ＧＵＩ部
３０４ コンテンツ再生部
４００，７００ 外部機器
４０２ 通信部
４０４ ＧＵＩ部
４０６〜４１０，７０２〜７０６ 決済処理部
６０４ 対価情報置換部
６１２〜６１４ 検証用公開鍵
７０８〜７１２ ハッシュ関数
７１４〜７１８ 署名用公開鍵

Claims (24)

1. 外部機器と通信を行う通信手段と、
   選択された物品またはサービスを提供するための処理を行い、前記選択された物品またはサービスの提供に関する決済情報を作成する販売手段と、
   前記販売手段によって作成された決済情報を保持する決済情報保持手段と、
   前記決済情報保持手段に保持された決済情報を、前記通信手段を介して前記外部機器に送信する決済仲介手段と、
   を備える電子装置。
2. 前記決済仲介手段は、
   前記外部機器からの要求に応じて、前記決済情報の送信を行う、
   請求項１記載の電子装置。
3. 前記決済仲介手段は、さらに、
   前記外部機器から前記通信手段を介して前記決済情報に対応する対価情報を受信し、受信した対価情報を前記販売手段に送信する、
   請求項１記載の電子装置。
4. 前記販売手段は、さらに、
   前記対価情報に対応する決済証書情報を作成し、
   前記決済情報保持手段は、さらに、
   前記販売手段によって作成された決済証書情報を保持し、
   前記決済仲介手段は、さらに、
   前記決済情報保持手段に保持された決済証書情報を、前記通信手段を介して前記外部機器に送信する、
   請求項３記載の電子装置。
5. 前記販売手段は、さらに、
   秘密鍵を用いて前記決済情報に署名を付与し、
   前記決済仲介手段は、さらに、
   前記秘密鍵に対応する公開鍵を用いて、前記販売手段によって付与された署名を検証する、
   請求項１記載の電子装置。
6. 前記販売手段は、さらに、
   前記外部機器が秘密鍵を用いて前記対価情報に付与した署名を、前記秘密鍵に対応する公開鍵を用いて検証する、
   請求項３記載の電子装置。
7. 前記販売手段は、さらに、
   秘密鍵を用いて前記決済証書情報に署名を付与し、
   前記決済仲介手段は、さらに、
   前記秘密鍵に対応する公開鍵を用いて、前記販売手段によって付与された署名を検証する、
   請求項４記載の電子装置。
8. 前記決済仲介手段は、さらに、
   前記外部機器から対価情報を受信した場合、前記決済情報保持手段に保持された決済情報を削除する、
   請求項３記載の電子装置。
9. 前記決済仲介手段は、さらに、
   前記外部機器から決済完了情報を受信した場合、前記決済情報保持手段に保持された決済証書情報を削除する、
   請求項４記載の電子装置。
10. 前記決済仲介手段は、さらに、
    前記決済証書情報を送信した後、所定の時間内に前記外部機器から決済完了情報を受信しない場合、次回前記外部機器と通信する時に、前記決済情報を前記外部機器に再度送信する、
    請求項４記載の電子装置。
11. 前記決済仲介手段は、
    前記決済情報保持手段に複数の決済情報が保持されている場合、前記複数の決済情報を一度に送信する、
    請求項１記載の電子装置。
12. 前記決済仲介手段は、
    前記決済情報保持手段に複数の決済情報が保持されている場合、前記外部機器から前記通信手段を介して前記複数の決済情報のそれぞれに対応する対価情報を含む合算対価情報を受信する、
    請求項１１記載の電子装置。
13. 前記販売手段は、複数存在し、
    前記決済仲介手段は、
    前記合算対価情報に含まれる複数の対価情報のうち、前記複数の販売手段の一に対応する対価情報を除く他のすべての対価情報を、前記複数の販売手段がおのおの認識できないデータにそれぞれ置換する手段を含み、
    前記合算対価情報に含まれる複数の対価情報のうち、前記複数の販売手段の一に対応する対価情報を除く他のすべての対価情報を前記データにそれぞれ置換して得られた個別対価情報を、前記一の販売手段に送信する、
    請求項１２記載の電子装置。
14. 前記決済仲介手段は、さらに、
    前記複数の対価情報のそれぞれに対応する対価情報ブロックデータを前記外部機器から前記通信手段を介して受信し、
    受信した対価情報ブロックデータを前記データとして用いて、前記複数の販売手段の一に対応する対価情報を除く他のすべての対価情報に対応する対価情報ブロックデータと、前記一の販売手段に対応する対価情報とを含む個別対価情報を作成し、
    作成した個別対価情報を、前記一の販売手段に送信する、
    請求項１３記載の電子装置。
15. 前記対価情報ブロックデータは、対価情報および乱数からハッシュ関数を用いて作成されたデータである、請求項１４記載の電子装置。
16. 前記決済仲介手段は、さらに
    すべての対価情報ブロックデータを含む合算対価情報ブロックデータを前記外部機器から受信し、
    受信した合算対価情報ブロックデータを前記一の販売手段に送信し、
    前記一の販売手段は、
    前記決済仲介手段から個別対価情報を受信し、
    受信した個別対価情報に含まれる自己宛の対価情報および前記乱数から前記ハッシュ関数を用いて検証用データを作成し、
    作成した検証用データを合算対価情報ブロックデータと比較して、受信した個別対価情報を検証する、
    請求項１５記載の電子装置。
17. 前記一の販売手段は、さらに、
    前記外部機器が秘密鍵を用いて前記合算対価情報ブロックデータに付与した署名を、前記秘密鍵に対応する公開鍵を用いて検証する、
    請求項１６記載の電子装置。
18. 請求項１記載の電子装置から決済情報を受信し、決済処理を行う外部機器であって、
    前記電子装置と通信を行う通信手段と、
    前記通信手段を介して前記決済情報を受信し、前記決済情報に基づいて決済処理を行う決済処理手段と、
    を備える電子装置。
19. 請求項１記載の電子装置から決済情報を受信し、決済処理を行う外部機器であって、
    前記電子装置と通信を行う通信手段と、
    前記通信手段を介して前記決済情報を受信し、前記決済情報に基づいて決済処理を前記通信手段を介して外部に依頼する決済処理手段と、
    を備える電子装置。
20. 請求項１４記載の電子装置から複数の決済情報を受信し、決済処理を行う外部機器であって、
    前記電子装置と通信を行う通信手段と、
    前記通信手段を介して前記複数の決済情報を受信し、前記決済情報それぞれに対応する対価情報と、すべての前記対価情報を含む合算対価情報と、前記対価情報および乱数からハッシュ関数を用いて得られる、前記対価情報それぞれに対応する対価情報ブロックデータと、を作成し、前記合算対価情報およびすべての対価情報ブロックデータを前記通信手段を介して前記電子装置に送信し、前記決済情報に基づいて決済処理を行う決済処理手段と、
    を備える電子装置。
21. 物品またはサービスを販売する電子装置と、前記物品またはサービスの販売に伴う決済処理を行う外部機器と、を有する決済処理システムであって、
    前記電子装置は、
    外部機器と通信を行う第一通信手段と、
    選択された物品またはサービスを提供するための処理を行い、前記選択された物品またはサービスの提供に関する決済情報を作成する販売手段と、
    前記販売手段によって作成された決済情報を保持する決済情報保持手段と、
    前記決済情報保持手段に保持された決済情報を、前記第一通信手段を介して前記外部機器に送信する決済仲介手段と、を備え、
    前記外部機器は、
    前記電子装置と通信を行う第二通信手段と、
    前記決済仲介手段から前記第一通信手段および第二通信手段を介して前記決済情報を受信し、前記決済情報に基づいて決済処理を行う決済処理手段と、を備える、
    決済処理システム。
22. 物品またはサービスを販売する電子装置と、前記物品またはサービスの販売に伴う決済処理を外部の決済サーバに依頼する外部機器と、を有する決済処理システムであって、
    前記電子装置は、
    外部機器と通信を行う第一通信手段と、
    選択された物品またはサービスを提供するための処理を行い、前記選択された物品またはサービスの提供に関する決済情報を作成する販売手段と、
    前記販売手段によって作成された決済情報を保持する決済情報保持手段と、
    前記決済情報保持手段に保持された決済情報を、前記第一通信手段を介して前記外部機器に送信する決済仲介手段と、を備え、
    前記外部機器は、
    前記電子装置および外部と通信を行う第二通信手段と、
    前記決済仲介手段から前記第一通信手段および第二通信手段を介して前記決済情報を受信し、前記決済情報に基づいて決済処理を前記第二通信手段を介して外部の決済サーバに依頼する決済処理手段と、を備える、
    決済処理システム。
23. 選択された物品またはサービスの提供に関する決済情報を作成するステップと、
    前記決済情報を決済情報保持手段で保持するステップと、
    前記決済情報保持手段に保持された決済情報を、外部機器に送信するステップと、
    を有する決済情報管理方法。
24. 請求項１５記載の電子装置から複数の決済情報を受信し、決済処理を行う外部機器の決済処理方法であって、
    前記複数の決済情報を受信するステップと、
    前記決済情報それぞれに対応する対価情報を作成するステップと、
    すべての前記対価情報を含む合算対価情報を作成するステップと、
    前記対価情報および乱数からハッシュ関数を用いて得られる、前記対価情報それぞれに対応する対価情報ブロックデータを作成するステップと、
    前記合算対価情報およびすべての対価情報ブロックデータを前記電子装置に送信するステップと、
    前記決済情報に基づいて決済処理を行うステップと、
    を有する決済処理方法。

Images