JP2007025829A

JP2007025829A - 電子商取引における匿名ユーザ信頼情報の作成・表示システム及び方法

Info

Publication number: JP2007025829A
Application number: JP2005203787A
Authority: JP
Inventors: Masachika Sasaki; 将央佐々木
Original assignee: Individual
Current assignee: Individual
Priority date: 2005-07-13
Filing date: 2005-07-13
Publication date: 2007-02-01

Abstract

【課題】オークション等匿名性の高い商取引において、名前等の個人情報を公開したり、ユーザ情報登録をしたりすることなく、互いの信用度をある程度測ることが可能となるシステムを提供する。
【解決手段】ユーザ間の取引履歴に電子署名したデータ（レシート）により、ユーザは取引した事実を自ら証明できる。またレシートに取引相手の評価を追記してさらに電子署名したデータ（評価情報）を作成し公開することで、取引の当事者である自分や取引相手の評価を公表し、かつ第三者はその電子署名により、その評価情報が確かに取引の当事者によって作成されたことを確認できる。またこれから取引をする場合、取引相手の評価情報を収集することでその相手の評判を知ることができる。また収集した評価情報を用いて、ユーザ間の評価関係をグラフとして表示することで、よりユーザの信用度をわかりやすく知ることができる。
【選択図】図１３

Description

本発明は、電子商取引システム又はそれに類するシステム上において、ユーザ間で行われた取引の履歴から、ユーザの信頼情報を作成・表示するための装置および方法およびＵＩ（ユーザインターフェース）に関する。

ネットオークションなど、お互い見知らぬ関係の個人間で商取引を行う場合、これから取引をしようとする相手がどの程度信用できるか、過去に詐欺などの問題を引き起こしたことがないかを予め知ることは重要である。

従来のオークションシステムにおいては、ユーザ間で取引が行われた際に、その取引が良好なものであったか、劣悪なものであったかによって、お互いに「良い」「悪い」などの評価をつけることができるようになっているものがある。そしてこれからあるユーザと取引しようとするときには、そのユーザの過去の評価の一覧や、「良い」「悪い」の評価の合計数を見て、そのユーザが信用できるかどうかを判断できるようになっている。図２６はその例である。

前記、「良い」「悪い」といった評価を、ユーザ毎に一覧表示するユーザインターフェースは、いくつか問題がある。

例えば図２６において、あるユーザＸの信用度を知りたい場合に、そのユーザＸに、１００人のユーザ００１〜ユーザ１００が「良い」評価をつけていた場合、果たしてそのユーザ００１〜ユーザ１００自体が信頼できるのかどうか不明確である。

極端な話、ユーザＸが、自分で一時的にユーザアカウントを１００個作って、架空の取引をユーザＸのアカウントと行い、すべてに「良い」評価をつけることで、ユーザＸに１００個の「良い」評価が付いている事を偽装することができる。

それならばユーザ００１〜ユーザ１００についても、評価一覧を表示してそれぞれのユーザが信用できるかを確認すればよいが、これは手間がかかるし、ユーザ００１〜ユーザ１００についても偽装を施せばやはり確認することは困難となる。

また、この従来の方法によれば、あるユーザに関して、あるサービス内での評価はある程度知ることができるが、この評価基準について、異なるシステム間での相互運用性はなく、たとえばあるサービスで信頼を得たアカウントがあっても、他のシステム上で信用がある証明とすることはできなかった。

また、この従来の方法は、アカウントの信頼情報をすべてセンターサーバで一括管理するため、システムの管理コストがかさむ問題があった。

前記問題を解決するため、本発明では、あるユーザＸについての信用度を知るために、ユーザＸを評価したユーザの集合Ｕ１、Ｕ１に含まれるユーザを評価したユーザの集合Ｕ２、といった具合に再帰的に評価しているユーザを検索し、これをグラフとして表示する。このグラフを、以下評価グラフと呼ぶ。

また、ユーザ間が取引を行った取引履歴に対して、取引仲介サービス側で電子署名を付与して買い手・売り手に返し、買い手、売り手がこの電子署名付履歴（レシート）を管理する。

また、ユーザ間が行った取引履歴に対して、ユーザがお互いに「良い」「悪い」などの評価やコメントを付加して、取引仲介サービス側がこれに電子署名を付与して買い手・売り手に返し、買い手・売り手がこの電子署名付履歴情報（評価情報）を管理する。

これにより、ユーザＸが偽装するのに困難な数のユーザ間の信頼関係を1つの図に表示することで、ユーザＸの信用度をわかりやすく表現することができる。

また、前記電子署名付履歴情報をユーザ自身が管理するため、取引仲介サービス業者はセンターサーバで取引履歴やユーザの評価情報を管理するコストを削減することができる。

また、取引履歴やユーザの評価情報を異なる取引仲介サービス間で相互利用することも可能となる。

図１は、本発明における主要なデータ構造である。以下、順に格納される情報の意味を説明する。

売り手の識別情報１２１と買い手の識別情報１２２は、ある取引にかかわった両当事者のＩＤである。ＩＣカードに記憶することもできる。

取引金額１２３、取引日時１２４、取引商品１２５は取引に関連する詳細情報である。

取引ログ１２０は、少なくとも売り手の識別情報１２１と買い手の識別情報１２２を含み、取引金額１２３・取引日時１２４・取引商品１２５などの関連情報も含めることができるデータ、またはそれを識別できるハッシュやＩＤである。

取引署名１３０は、取引ログ１２０に対して所定の方法で作成された電子署名である。

レシート１６０は、取引ログ１２０および取引署名１３０からなるデータである。

コメント１４０は、ある取引に対して、そのいずれかの当事者が、取引の内容、商品、相手の対応などについて感想を文章１４１で表現したり、得点１４２で表現したり、「良い」「悪い」などの段階評価１４３をしたりする表現の総称である。

コメント付レシート１１０は、レシート１６０とコメント１４０を含むデータまたはこれを識別できるハッシュやＩＤである。

評価署名１５０は、コメント付レシート１１０に対して所定の方法で作成された電子署名である。

評価情報１００は、コメント付レシート１１０と、評価署名１５０からなるデータまたはそれを識別できるハッシュやＩＤである。

請求項５では、取引した証明となるデータを取引証明と呼ぶ。これを図１では１６０ａで示す。ただし取引証明は必ずしも取引ログ１２０を含むわけではない。

請求項５では、取引証明１６０ａとコメント１４０からなるデータを、コメント付取引証明と呼ぶ。これを図１中では１１０ａで示す。

図２は請求項３および請求項４および請求項１０に示す情報処理システムの実施例である。

この実施例によれば、まず買い手と売り手は所定の方法により電子商取引を行うことと、その支払いを電子マネーによることを同意する。

次に、買い手と売り手は、自身の持つ電子マネー２０３・２０４を使用して、取引仲介サーバ２０５経由で電子マネーの受け渡しを行う。

この時、取引仲介サーバ２０５は、買い手及び売り手の電子マネー２０３・２０４からＩＤ情報を読み取り、このＩＤ情報と取引金額、取引日付などの取引に関する情報に、取引署名サーバ２０６よって電子署名を付与し、レシート１６０を作成する。

次に取引仲介サーバ２０５は、レシート１６０を買い手クライアント２０１と売り手クライアント２０２に送信する。

これによって、買い手と売り手は、確かに互いにある日時、ある金額で電子マネーの受渡をしたことを、取引署名サーバ２０６の署名検証用の公開鍵を持っているだけで、取引仲介サーバとの通信を必要とすることなく証明することができる。

図３は、本実施例を説明したシーケンス図である。ここでは、
ステップ３０１で売り手と買い手の間で受渡処理が行われ、
ステップ３０２で売り手と買い手のＩＤが読み取られ、
ステップ３０３で取引ログ１２０が作成され、
ステップ３０４で取引署名サーバ２０６に取引ログ１２０が送信され、
ステップ３０５で取引署名１３０が作成され、
ステップ３０６で取引署名１３０が取引仲介サーバ２０５に返送され、
ステップ３０７でレシート１６０が作成され、
ステップ３０８でレシート１６０が買い手および売り手に返送される。

図４は、本実施例を説明したブロック図である。

なお、本実施例では買い手および売り手のＩＤをＩＣカードなどの情報機器内に保持しこれをユーザが持つ形態を取っているが、会員情報を管理するサーバなどに保持することもできる。

また、本実施例では取引仲介サーバ２０５と取引署名サーバ２０６を別々のサーバとしているが、単一の機器内にこれら両方の機能を持たせる構成も可能である。

図５は請求項５に示す情報処理システムの実施例である。

この実施例によれば、買い手と売り手は、既に互いに商取引を行ったことを証明するデータ（取引証明１６０ａ）を保持している。このデータとして例えば、ネットオークションの入札履歴のページのＵＲＬなどが挙げられる。

次に買い手と売り手は、この取引証明１６０ａに対して、取引がスムーズに行われたか、取引された商品は満足のいくものだったかなど、取引相手に関するコメント１４０を作成する。

次に、取引証明１６０ａとコメント１４０を、まとめて評価署名サーバ５０６に送信する。

次に評価署名サーバ５０６は、買い手または売り手の電子マネー２０３・２０４のＩＤを確認し、送信された取引証明でしめされる取引が、確かにコメントをつけた当事者によって行われたものであることを確認する。

次に評価署名サーバ５０６は、評価署名１５０を作成し、これを買い手クライアント２０１または売り手クライアント２０２に返信する。

これによって、買い手と売り手は、互いに行った商取引に関して、確かに自分があるコメントを付けたことを、評価署名サーバ５０６の署名検証用の公開鍵を持っているだけで、他のサーバとの通信を必要とすることなく証明することができる。

図６は本実施例を説明したシーケンス図である。ここでは、
ステップ６００で買い手と売り手は所定の方法で取引証明１６０ａを受信し、
ステップ６０１で買い手と売り手は、その取引に関するコメント１４０を作成し、
ステップ６０２で買い手と売り手は、コメント付取引証明１１０ａを作成し、
ステップ６０３で買い手と売り手は、コメント付取引証明１１０ａを、評価署名サーバ５０６に送信し、
ステップ６０４で評価署名サーバ５０６は、評価署名１５０を作成し、
ステップ６０５で評価署名サーバ５０６は、評価署名１５０を送信し、
ステップ６０６で買い手と売り手は、コメント付取引証明１０１ａと評価署名１５０から、評価情報１００を作成する。

図７は本実施例を説明したブロック図である。

また、本実施例では、取引署名サーバをネットワーク上の独立したサーバとしているが、電子署名機能を有するＩＣカードを売り手や買い手が個々に持ち、それらを用いて評価署名１５０を作成する構成も可能である。

図８は請求項１２に示す情報処理システムの構成例で、図９はそのブロック図である。

本実施例はおよそ前記２つの実施例を組み合わせたものである。

図１０と図１１は請求項１３に示す情報処理システムの実施例である。

この実施例においては、取引仲介サーバ２０５はレシート１６０を買い手と売り手に送信する代わりに、その取引を一意に識別する取引ＩＤをステップ１００８にて送信し、レシート１６０は電子マネー受渡２０５が内部に保持する。

次に売り手と買い手はコメント１４０を作成し、取引ＩＤとともに取引仲介サーバ２０５に送信する。

次に取引仲介サーバ２０５は、送信された取引ＩＤに従って、対応するレシート１６０を検索する。

次に取引仲介サーバ２０５は、評価署名サーバ２０６にコメント１４０とレシート１６０を送信して評価署名１５０を作成し、これらをあわせて評価情報１００を作成し、これを買い手または売り手に送信する。

本例では、レシート１６０を作成するサーバと、レシート１６０を利用して評価情報１００を作成するサーバがいずれも取引仲介サーバ２０５となっているが、これを別々のサーバとし、レシート１６０をそれらのサーバ間で送受信する構成も可能である。

以上に示した各々の実施例により、売り手や買い手は、評価情報１００を得ることができる。この評価情報は、取引署名サーバ２０６や評価署名サーバ５０６の公開する公開鍵によって、誰でもその正当性を確認することができる。

図１２は、この情報を使って、良い評価を得た売り手または買い手が、いかに次の取引の機会で信用を得ることができるか、またこの売り手または買い手と新たに取引を行おうとする第三者はいかにしてこの売り手または買い手の信用を確認することができるかを説明したシーケンス図である。

手順１２０１では、売り手と買い手は、互いに相手の持つ自分の評価情報１００を所定の方法により交換する。この交換には、既存のＢＢＳや電子メール、ＷＥＢページなどを利用することができる。

この評価情報交換の段階になって、相手が思いもよらぬ悪い評価を付けてきた、あるいは評価情報を出してくれないというトラブルも考えられる。この場合、被害を受けた側は改めて、請求項５に示す情報処理システムでレシート１６０に対して悪いコメント１４０を付けて相手の評価情報１００を作り直すことで、相手への評価を付け直すことが可能である。

次に、売り手や買い手は、自分に付けられた良い評価情報、あるいは相手につけた悪い評価情報を、所定の情報で公開する。図１２の例では、ステップ１２０２〜１２０３にて評価情報記憶装置に送信し、そこで評価情報を保持、公開する。評価情報記憶装置としては、ＷＥＢページやブログ、ＢＢＳなどが好適である。評価情報を専門に収集するサーバでも良い。

次に第三者は、ステップ１２０４〜１２０５にて、評価表示装置で、ネットワーク上の評価情報を検索、収集し、興味のあるユーザについての情報を表示する。

この手順により、良い評価を得た売り手および買い手は、自分で自分の良い評価をアピールでき、また自分に損害を与えた相手の悪い評価をアピールできる。また、第三者からはそれらの公開されている評価情報から、売り手又は買い手の信用度を予想することが可能となる。

図１３は、請求項１６〜請求項２６のＵＩの実施例である。

請求項１６によれば、本ＵＩは、ユーザが頂点１３０１、一回の取引が辺１３０２として表現される。

ここで用いられるユーザ情報や取引情報は、例えば既存のネットオークションなどのユーザ評価などが利用可能である。

ただし、すべてのユーザ、すべての取引を表示する必要はなく、例えば興味のあるユーザから一定距離以内で、辺も主要なものを選択して、単純化した評価グラフを表示することも可能である。

請求項１７によれば、本ＵＩは、取引を表す辺１３０２が、レシート１６０と対応する。

そして、このＵＩを持つシステムが、ネット上からレシート１６０を検索・収集し、その取引署名１３０によって正当性を確認し、評価グラフ表示を行う。

請求項１８によれば、本ＵＩは、取引を表す辺１３０２が、評価情報１００と対応する。

そして、このＵＩをもつシステムが、ネット上から、評価情報１００を検索・収集し、その評価署名１５０によって正当性を確認し、評価グラフ表示を行う。

請求項１９によれば、ある２つの頂点が、複数の辺で接続されるとき、評価グラフを単純化するため、それら複数の辺から、所定の方法により最も代表的な一辺を選択して表示する。この辺の選び方としては、例えば、金額の大きいもの、もっとも新しいもの、最もコメントの悪いもの、などの選び方が考えられる。

請求項２０によれば、２者間での売り買いの流れ（金銭の流れ）が有向辺としてあらわされる。

請求項２１によれば、取引を表す辺は、その金額が大きいほど太く、金額が少なければ細くなる。

請求項２２によれば、取引を表す辺は、そのコメントの良し悪しによって例えばその色を変える。図１３の例では、色が変わっていることを点線の辺で表現している。

また、ひとつの取引に対して、買い手と売り手の両者がコメントをつけることがある。この場合、図１４に示すように、ひとつの辺の半分を売り手１４０２のコメントに対応する色１４０４に、他方を買い手１４０１のコメントに対応する色１４０３に色分けして表示することもできる。なお図１４においては色分けを点線で示している。

請求項２３によれば、あるユーザを選択したとき、そのユーザを中心に、ある距離の範囲内で評価グラフを表示する。図１３の場合、ＵＳＥＲ１を中心に、距離２まで表示している。

請求項２４によれば、例えば頂点に対してマウスクリックしたとき、その頂点を中心とする一定半径のグラフの表示に切り替える。例えば図１３で、ＵＳＥＲ２を表す頂点１３０３をマウスクリックした場合、ユーザ２を中心とした半径２のグラフを表示する画面に遷移するようにすることができる。

請求項２５によれば、例えば頂点にマウスカーソル１３０４を近づけると、その頂点のユーザの詳細情報１３０５が表示されるようにすることができる。

請求項２６によれば、例えば辺にマウスカーソル１３０４を近づけると、その辺の取引の詳細情報１３０７が表示されるようにすることができる。

請求項２７によれば、例えばオークションサーバにおいて、ユーザの評価などから評価グラフを画像として作成し、これをクライアントに送信する。クライアント側ではウェブブラウザなどでこの画像を表示することで、クライアント側には特に何も特殊なアプリケーションを持つことなく、わかりやすいユーザ評価情報を得ることができる。図２１はその例の図である。

図１５は本発明によって作成された標準的な評価グラフである。

この例では、１５０１で示す頂点に対応するユーザを中心に、距離４までのユーザを表示している。

一般的に、ユーザ数が十分に多いコミュニティにおいて、無作為に取引を行った場合、自分が取引を行った相手、その相手が取引を行った相手・・と順に検索しても、同じユーザが２度出てくることは稀だと考えることができる。

従って、通常評価グラフは、図１５のように、ループのほとんどない木構造に近いグラフとなる。

評価対象とするユーザから、十分な距離まで評価グラフを表示して、概ね木構造となれば、そのユーザはそれだけのユーザと通常取引の関係があったと考え、ある程度信用ができるユーザであると判断することができる。

図１６は本発明によって作成された他の評価グラフである。

この例では、１６０１で示す頂点に隣接する辺だけに着目すると、一見良好な評価が１０個もあり、良心的なユーザに見える。

ところが本発明によりそのさらに周囲にまでグラフ表示を広げると、実は評価対象のユーザ１６０１と、それを評価しているユーザ群１６０２の間で、完全グラフに近い評価グラフが形成されていることがわかる。

一般的に、ユーザアカウントを保持するのは、会員料やＩＤを保持するＩＣカードの代金など、コストが必要となる。

悪意のあるユーザが、メインのアカウントに良好な評価を付けるために、複数のダミーアカウントを作ったとする。

この時、このダミーアカウントの評価も上げないと意味がないが、そのためにさらにダミーアカウントを増やしたのではコストがかさむ。

そこで、このダミーアカウント同士で評価を付け合うことが考えられる。

この手法を悪意のあるユーザが用いた場合、図１６に示す完全グラフに近い表示となり、本発明によりこれを容易に見抜くことが可能になる。

図１７において、１７０１はＵＳＥＲ１が、それまでに行ってきた取引に関して、ＵＳＥＲ２〜ＵＳＥＲ７の６人のユーザから、合計７回の取引に関して評価を受けている様子を示す既存のユーザインターフェースである。

１７０２においては、ＵＳＥＲ１は、かつてＵＳＥＲ２が出品した商品に関して落札を行い、その取引に関してＵＳＥＲ２がＵＳＥＲ１を「良い」ユーザであると評価したことを示している。

また、１７０３においては、かつてＵＳＥＲ１が出品した商品を、ＵＳＥＲ５が落札を行い、その取引に関してＵＳＥＲ５がＵＳＥＲ１を「悪い」ユーザであると評価したことを示している。

本発明においては、このようなユーザの評価の情報に対し、図１８のごとく、ユーザを頂点、取引に関する評価を辺とする有向グラフとして表示する。

すなわち、ＵＳＥＲ１に関する表示を行うのであれば、ＵＩの中心にＵＳＥＲ１の頂点１８５０を置く。

また、ＵＳＥＲ２がＵＳＥＲ１に関する評価１７０２を行っていれば、１８５０に隣接する頂点としてＵＳＥＲ２（１８５１）を置き、１８５０との間を有向辺１８０２で接続する。この時、矢印の向きは取引の向き（代金の流れ）を表す。

図１７の１７０４、１７０５によれば、ＵＳＥＲ３は、ＵＳＥＲ１と出品者・落札札者両方の立場で１回ずつ取引を行っている。この場合、図１８の１８５２で示すようにＵＳＥＲ１に隣接するＵＳＥＲ３の頂点を設け、２回の取引それぞれについて辺１８０４、１８０５で接続する。

図１７の１７０３によれば、ＵＳＥＲ５はＵＳＥＲ１に「悪い」評価を付けている。これは図１８の１８０３の如く、有向辺を別の色で（ここでは点線で示す）表現する。

この手順を、ＵＳＥＲ１を評価しているユーザすべて（１８５１〜１８５６）に関して行う。

さらに、ＵＳＥＲ１に隣接するすべてのユーザ（１８５１〜１８５６）に関して、上記手順を再帰的に適用する。

例えば図１９において、１９０１はＵＳＥＲ２が、それまでに行ってきた取引に関して、ＵＳＥＲ８〜ＵＳＥＲ１０の３人のユーザから、合計３回の取引に関して評価を受けている様子を示す既存のユーザインターフェースである。

これに上記手順を適用すると、図１８において、ＵＳＥＲ２を表す頂点１８５１に、ＵＳＥＲ８〜ＵＳＥＲ１０を表す頂点１８５７〜１８５９が隣接し、その間を有向辺で接続される。ＵＳＥＲ３（１８５２）〜ＵＳＥＲ７（１８５６）に関しても同様である。

上記手順において、同一のユーザが２度以上検索されることがある。例えば図１８において、頂点１８６０で示されるユーザは、一度ＵＳＥＲ４（１８５３）を評価しているユーザとして検索されたが、その後、ＵＳＥＲ６（１８５５）をも評価しているユーザとして再度検索された。この場合、同一ユーザに対して頂点を２個以上作ることはせず、一つの頂点から、評価関係のあるユーザの頂点全てに辺を接続する（１８２０、１８２１）。

図２０の実施例では、取引を仲介する取引仲介サーバと、その仲介サーバを経由してユーザ間が取引を行った場合に、ユーザ間の取引履歴とユーザ間相互の評価を取引仲介サーバが蓄積し、それを公開する。そしてあるユーザが別のあるユーザの評価を知りたい場合に、ユーザのクライアント上のアプリケーションで知りたいユーザの評価を収集し、あるいはこれをローカルシステム上に蓄積し、収集したデータから評価グラフを表示するようになっている。

図２１は、図２０とほぼ同様の構成で、評価グラフＵＩ生成装置が取引仲介サーバ内に構築される例である。
この場合、評価グラフＵＩ生成装置により生成されたＵＩは、ＨＴＭＬやクリッカブルマップなどの技術によってクライアント機器に送信される。

図２２は、図２１とほぼ同様の構成で、評価情報の記憶装置と、評価グラフＵＩ生成装置を、それぞれ別のサーバ設置した場合の構成例である。この例によると、ユーザ間の取引処理は取引仲介サーバにより行われ、それぞれの取引に関してユーザは評価を行い、その結果が評価記憶サーバに記憶される。そして、評価グラフＵＩ生成サーバは評価記憶サーバから評価情報を読み出し評価グラフＵＩを生成してクライアント機器に送信する。また、この構成において、取引仲介サーバ、評価記憶サーバ、評価グラフＵＩ生成サーバは単一である必要はなく、それぞれ複数個のサーバで構成されていてもよいし、うち２つ以上の機能を併せ持つサーバがあってもよい。

図２３は、評価記憶サーバをユーザが個々に持ちこれを公開する場合の構成例である。この構成例によれば、評価情報を記憶・公開する評価記憶サーバは、ユーザが個々に保持、管理し、各自自分に都合の良い評価（自分に対する「良い」評価情報や、自分に損害を与えたユーザに対する「悪い」評価情報など）を配信する。ユーザは各自の利益のために評価記憶サーバの管理コストを支払うので、システム全体に評価情報を一括管理するセンターサーバが不要となり、管理者側のコストメリットがある。

図２４の実施例は、図６に示すシーケンスにおいて、評価署名サーバを用いる代わりに、各ユーザが持つ電子署名機能付ＩＣカードを使用するようになっている。

このＩＣカードは、容易には解析不可能な耐タンパ性能を備え、外部からは読み取りできない記憶領域に電子署名を行うための秘密鍵が書き込まれている。

この実施例によれば、評価署名をユーザが自力で作成できるため、評価署名を作成するためのセンターサーバが不要となり、管理コストへのメリットがある。

図２５は、図６の実施例に加えて、評価署名サーバは評価署名を作成する際、ステップ２５０１にて買い手または売り手にＩＤを読みに行き、確かに取引証明の当事者からの評価署名作成依頼であることを確認するようになっている。

これにより、取引の当事者以外が無闇に評価情報を作成することを防止できる。

買い手や売り手のＩＤの記憶方法として、耐タンパ性に優れたＩＣカードや、センターサーバで一括管理されるユーザ情報など、エンドユーザが容易に偽装できない記憶方法が好適である。

評価情報を構成するデータ構造を示す図である。レシートを作成するシステム構成図である。レシートを作成するシーケンス図である。レシートを作成するブロック図である。評価情報を作成するシステム構成図である。評価情報を作成するシーケンス図である。評価情報を作成するブロック図である。レシートを取引証明とする場合の評価情報を作成するシステム構成図である。レシートを取引証明とする場合の評価情報を作成するブロック図である。評価情報を作成する他のシーケンス図である。評価情報を作成する他のシーケンス図である。評価情報の流通についてのシーケンス図である。評価グラフの例を示す図である。評価グラフの書き方の例を示す図である。代表的な評価グラフの例を示す図である。代表的な他の評価グラフの例を示す図である。単一ユーザの評価をリスト表示するＵＩの例の図である。評価グラフの例を示す図である。単一ユーザの評価をリスト表示する他のＵＩの例の図である。本発明によるシステム構成図の例である。本発明による他のシステム構成図の例である。本発明による他のシステム構成図の例である。本発明による他のシステム構成図の例である。評価情報を作成する他のシーケンス図である。評価情報を作成する他のシーケンス図である。既存の評価表示ＵＩの例を示す図である。

符号の説明

１００評価情報
１１０コメント付レシート
１１０ａコメント付取引証明
１２０取引ログ
１２１売り手の識別情報
１２２買い手の識別情報
１２３取引金額
１２４取引日時
１２５取引商品
１３０取引署名
１４０コメント
１４１取引の感想
１４２得点
１４３「良い」「悪い」等
１５０評価署名
１６０レシート
１６０ａ取引証明
２０１買い手クライアント
２０２売り手クライアント
２０３買い手ＩＤ付電子マネー
２０４売り手ＩＤ付電子マネー
２０５取引仲介サーバ
２０６取引署名サーバ
３０１支払処理・受取処理ステップ
３０２ＩＤ読取ステップ
３０３取引ログ作成ステップ
３０４取引ログ送信ステップ
３０５取引署名作成ステップ
３０６取引署名送信ステップ
３０７レシート作成ステップ
３０８レシート送信ステップ
４１１取引仲介装置
４１２識別情報読取装置
４１３取引ログ送信装置
４１４取引署名受信装置
４１５レシート作成装置
４１６レシート送信装置
４２１取引ログ受信装置
４２２取引電子署名装置
４２３取引署名送信装置
４３１取引証明受信装置・レシート受信装置
４３２コメント入力装置
４３３コメント付取引証明送信装置・コメント付レシート送信装置
４３４評価署名受信装置
４３５評価情報作成装置
４４１コメント付取引証明受信装置・コメント付レシート受信装置
４４２評価電子署名装置
４４３評価署名送信装置
５０６評価署名サーバ
６００取引証明受信ステップ
６０１コメント作成ステップ
６０２コメント付取引証明作成ステップ
６０３コメント付取引証明送信ステップ
６０４評価署名作成ステップ
６０５評価署名送信ステップ
６０６評価情報作成ステップ
１００８取引ＩＤ読取ステップ
１１０１コメント作成ステップ
１１０３コメントと取引ＩＤを送信するステップ
１１０５評価署名送信ステップ
１１０６評価情報作成ステップ
１２０１評価情報交換ステップ
１２０２評価情報掲載ステップ
１２０３評価情報保持ステップ
１２０４評価情報収集ステップ
１２０５評価情報表示ステップ
１３０１評価グラフにおける頂点
１３０２評価グラフにおける辺
１３０３評価グラフにおける頂点
１３０４マウスカーソル
１３０５頂点に関連するユーザの詳細情報
１３０７辺に関連する取引の詳細情報
１４０１買い手を示す頂点
１４０２買い手の提示した評価の色
１４０３売り手を示す頂点
１４０４売り手の提示した評価の色
１５０１評価グラフにおける頂点
１６０１評価グラフにおける頂点
１６０２評価グラフにおける頂点
１７０１評価をリスト表示するＵＩ
１７０２ＵＳＥＲ１への評価
１７０３ＵＳＥＲ１への評価
１７０４ＵＳＥＲ１への評価
１７０５ＵＳＥＲ１への評価
１８０２評価グラフにおける辺
１８０３評価グラフにおける辺
１８０４評価グラフにおける辺
１８０５評価グラフにおける辺
１８２０評価グラフにおける辺
１８２１評価グラフにおける辺
１８５１ＵＳＥＲ１を評価したユーザ・およびそれを示す頂点
１８５２ＵＳＥＲ１を評価したユーザ・およびそれを示す頂点
１８５３ＵＳＥＲ１を評価したユーザ・およびそれを示す頂点
１８５４ＵＳＥＲ１を評価したユーザ・およびそれを示す頂点
１８５５ＵＳＥＲ１を評価したユーザ・およびそれを示す頂点
１８５６ＵＳＥＲ１を評価したユーザ・およびそれを示す頂点
１８５７ＵＳＥＲ２を評価したユーザ・およびそれを示す頂点
１８５８ＵＳＥＲ２を評価したユーザ・およびそれを示す頂点
１８５９ＵＳＥＲ２を評価したユーザ・およびそれを示す頂点
１８６０評価グラフにおける頂点
１９０１評価をリスト表示するＵＩ
２５０１ＩＤ読取ステップ

Claims

ある電子商取引に対して、
「ある二者が取引したことを証明する情報」（以下取引証明と呼ぶ）１６０ａと、
「取引相手を評価する情報」（以下コメントと呼ぶ）１４０と、
「取引証明１６０ａとコメント１４０またはそれらを識別できるハッシュやＩＤなど」（以下コメント付取引証明と呼ぶ）１１０ａと、
「コメント付取引証明１１０ａに対して所定の方法で作成された電子署名」（以下評価署名と呼ぶ）１５０と、
「コメント付取引証明１１０ａと評価署名１５０、またはそれらを識別できるハッシュやＩＤなど」（以下評価情報と呼ぶ）１００と
が定義されたとき、評価情報１００を記憶する媒体。
ある電子商取引に対して、
「売り手の識別情報１２１と買い手の識別情報１２２とを含む情報、またはそれらを識別できるハッシュやＩＤなど」（以下取引ログと呼ぶ）１２０と、
「取引ログに対して所定の方法で作成された電子署名」（以下取引署名と呼ぶ）１３０と、
「取引ログ１２０と取引署名１３０、またはそれらを識別できるハッシュやＩＤなど」（以下レシートと呼ぶ）１６０と
が定義されたとき、前記取引証明がレシートであることを特徴とする請求項１の媒体。
買い手から売り手への金銭またはそれに相当するデータの受け渡しを仲介する取引仲介装置４１１と、
売り手および買い手を識別するための識別情報１２１、１２２を読み取る識別情報読取装置４１２と、
取引ログ１２０を送信する取引ログ送信装置４１３と、
取引ログ１２０を受信する取引ログ受信装置４２１と、
取引署名１３０を作成する取引電子署名装置４２２と、
取引署名１３０を送信する取引署名送信装置４２３と、
取引署名１３０を受信する取引署名受信装置４１４と、
レシート１６０を作成するレシート作成装置４１５と
を備えることを特徴とする情報処理システム。
請求項３の情報処理システムであって、レシート１６０を買い手及び売り手に送信するレシート送信装置４１６を備えることを特徴とする情報処理システム。
取引証明１６０ａを受信する取引証明受信装置４３１と、
コメント１４０を入力するコメント入力装置４３２と、
コメント付取引証明１１０ａを送信するコメント付取引証明送信装置４３３と、
コメント付取引証明１１０ａを受信するコメント付取引証明受信装置４４１と、
評価署名１５０を作成する評価電子署名装置４４２と、
評価署名１５０を送信する評価署名送信装置４４３と、
評価署名１５０を受信する評価署名受信装置４３４と、
評価情報１００を作成する評価情報作成装置４３５と
を備えることを特徴とする情報処理システム。
取引仲介装置４１１が、買い手から売り手への金銭またはそれに相当するデータの受け渡しを仲介するステップ３０１と、
識別情報読取装置４１２が、売り手および買い手を識別するための識別情報１２１、１２２を読み取るステップ３０２と、
取引仲介サーバ２０５が、取引ログ１２０を作成するステップ３０３と、
取引ログ送信装置４１３が、取引ログ受信装置４２１に、取引ログ１２０を送信するステップ３０４と、
取引電子署名装置４２２が、取引ログ１２０から、取引署名１３０を作成するステップ３０５と、
取引署名送信装置４２３が、取引署名受信装置４１４に、取引署名１３０を送信するステップ３０６と、
レシート作成装置４１５が、取引ログ１２０と取引署名１３０から、レシート１６０を作成するステップ３０７と
を有することを特徴とする情報処理方法。
請求項６の情報処理方法であって、取引仲介サーバ２０５が、レシート１６０を買い手及び売り手に送信するステップ３０８を有することを特徴とする情報処理方法。
売り手と買い手が、取引証明受信装置４３１で、取引証明１６０ａを受信するステップ６００と、
売り手と買い手が、コメント入力装置４３２で、コメント１４０を入力するステップ６０１と、
売り手と買い手が、コメント付取引証明１１０ａを作成するステップ６０２と、
売り手と買い手が、コメント付取引証明送信装置４３３で、コメント付取引証明受信装置４４１に、コメント付取引証明１１０ａを送信するステップ６０３と、
評価電子署名装置４４２が、コメント付取引証明１１０ａから、評価署名１５０を作成するステップ６０４と、
評価署名送信装置４４３が、売り手と買い手の評価署名受信装置４３４に、評価署名１５０を送信するステップ６０５と、
売り手と買い手が、評価情報作成装置４３５で、コメント付取引証明１１０ａと評価署名１５０から、評価情報１００を作成するステップ６０６と
を有することを特徴とする情報処理方法。
請求項３又は請求項４の情報処理システムにおいて、取引ログ１２０に、取引で受け渡された金額、取引の発生した日時、取引された商品に関する情報のうち少なくとも１つ以上の情報も含まれることを特徴とする情報処理システム。
請求項３又は請求項４の情報処理システムにおいて、買い手および売り手の識別情報を、ＩＣカードまたはそれに類する携帯可能で耐タンパ性に優れた情報処理装置（以下単にＩＣカードと呼ぶ）に保持することを特徴とする情報処理システム。
請求項５の情報処理システムにおいて、評価電子署名装置が、ＩＣカードであることを特徴とする情報処理システム。
請求項４および請求項５の両方を備える情報処理システムであって、
請求項５の取引証明１６０ａが、請求項４のレシート１６０であることを特徴とする情報処理システム。
請求項３および請求項５の両方を備える情報処理システムであって、
請求項５の情報処理システムは、
買い手または売り手から指定された取引に関連するレシート１６０を検索する検索装置を備え、
取引証明１６０ａとしてレシート１６０を使用し、
取引証明受信装置４３１は、レシート１６０を受信する代わりに、請求項３の情報処理システムが保持するレシート１６０を参照する
ことを特徴とする情報処理システム。
請求項７および請求項８の両方の特徴を備える情報処理方法であって、
請求項８の取引証明１６０ａが、請求項７のレシート１６０であることを特徴とする情報処理方法。
請求項６および請求項８の両方の特徴を備える情報処理方法であって、
請求項８の情報処理方法は、
買い手または売り手から指定された取引に関連するレシート１６０を検索するステップを有し、
取引証明１６０ａとしてレシート１６０を使用し、
取引証明受信装置４３１で、レシート１６０を受信するステップの代わりに、請求項６の情報処理方法で作成されたレシート１６０を参照する
ことを特徴とする情報処理方法。
１つ以上の取引ログ１２０を表示するユーザインターフェース（以下単にＵＩと呼ぶ）であって、買い手または売り手の識別情報を頂点、取引ログ１件を辺とするグラフまたはその部分グラフとして表示をすることを特徴とするＵＩ。
請求項３又は請求項４の情報処理システムによって作成されるレシート１６０を表示するＵＩで、買い手または売り手の識別情報を頂点、レシート１件を辺とするグラフまたはその部分グラフとして表示をすることを特徴とするＵＩ。
請求項５又は請求項１２の情報処理システムによって作成される評価情報１００を表示するＵＩで、買い手または売り手の識別情報を頂点、評価情報１件を辺とするグラフまたはその部分グラフとして表示をすることを特徴とするＵＩ。
請求項１６〜請求項１８のいずれかのＵＩであって、同一の売り手・買い手の組の取引ログ（又はレシート又は評価情報）が複数あるとき、その中から所定の方法で代表的な取引ログ（又はレシート又は評価情報）を選択することにより、グラフを単純グラフとして表示することを特徴とするＵＩ。
請求項１６〜請求項１８のいずれかのＵＩであって、取引の方向（売り・買い）によって、対応する取引ログ（又はレシート又は評価情報）の辺が有向辺となり、全体としてグラフが有向グラフとなることを特徴とするＵＩ。
請求項１６〜請求項１８のいずれかのＵＩであって、取引の金額に応じて辺の表示（例えば辺の太さ）が変化することを特徴とするＵＩ。
請求項１６〜請求項１８のいずれかのＵＩであって、取引のコメントに応じて辺の表示（例えば辺の色）が変化することを特徴とするＵＩ。
請求項１６〜請求項２２のいずれかのＵＩであって、特定のユーザの識別情報を入力することで、そのユーザの頂点を中心に、所定の距離までのグラフを表示することを特徴とするＵＩ。
請求項１６〜請求項２２のいずれかのＵＩであって、頂点に対してある操作（例えばマウスクリック）をすることで、その頂点に関連するユーザの識別情報を入力した場合の請求項２３によるグラフが表示されることを特徴とするＵＩ。
請求項１６〜請求項２４のいずれかのＵＩであって、頂点に対してある操作（例えばマウスカーソルを重ねる）をすることで、その頂点に関連するユーザの詳細情報が表示されることを特徴とするＵＩ。
請求項１６〜請求項２４のいずれかのＵＩであって、辺に対してある操作（例えばマウスカーソルを重ねる）をすることで、その辺に関連する取引ログ（又はレシート又は評価情報）の詳細情報が表示されることを特徴とするＵＩ。
請求項１６〜請求項２６のいずれかのＵＩについて、このＵＩを所定の方法（画像やクリッカブルマップなど）として生成し送信することを特徴とするサーバ装置。