JP6151041B2

JP6151041B2 - 取引システム

Info

Publication number: JP6151041B2
Application number: JP2013028983A
Authority: JP
Inventors: 川近　充; 充川近
Original assignee: SOCUEUS CO.,LTD.
Current assignee: SOCUEUS CO.,LTD.
Priority date: 2013-02-18
Filing date: 2013-02-18
Publication date: 2017-06-21
Anticipated expiration: 2033-02-18
Also published as: WO2014126126A1; JP2014157547A

Description

本発明は，物やサービス，情報などの各種商品を取引する取引システムに関する。

近年，環境に対する意識の高まりから，物を消費するのみではなく，自らが不用になった物やサービス，情報などの各種商品（以下，「商品」という）をほかの人に提供し，場合によっては他の商品と交換するサービスがインターネット上でも行われている。このようなサービスの一例を下記非特許文献１に示す。また，下記特許文献１乃至特許文献９に特許文献の一例を示す。

このような商品の取引サービスについては，ユーザの利便性のため，その多くが無料となっている。

すなわち，ユーザがこれらのサービスを利用しようと考えた場合，ユーザ登録をした上で提供されている商品の一覧の中から欲しい商品を選択すれば，商品販売サイトでなければ一般的には送料のみの負担で，商品に対する対価としては無料でその商品を入手することができる。

また商品を提供する側の場合には，提供する商品に関する情報を取引サービスのウェブサイトに登録し，ほかのユーザからのコンタクトを待つこととなる。そして，この間，ユーザに対しては利用料がかからない。

特開２００８−１７１０７１号公報特開２００８−０９７４８６号公報特開２００３−０４４７００号公報特開２００２−３１８９３６号公報特開２００２−３０４５８８号公報特開２００２−２６９３８５号公報特開２００２−２３０３３１号公報特開２００２−１５００２９号公報特開２００１−３５７２３３号公報

株式会社Studio3o2，"モノエコ"，[online]インターネット＜ＵＲＬ：http://www.monoeco.jp/＞

このように，従来の取引サービスは，一般的に無料で提供されていることが殆どである。そのため，ユーザにとっては無料で利用できるので好ましい。しかし，サービスを提供する側にとっては，サーバの運営費などの費用が発生するが，無料の場合にはこの取引サービスそのものからは，その費用をまかなうことができない。そこで，有料サービスとすることも考えられるが，お金を使わずに商品を入手したいユーザから利用料を徴収することは容易ではない。仮に，ユーザから利用料を徴収して有料サービスとして提供したとしても，利用頻度に応じて課金される従来の取引サービスでは，取引サービスの運営者にとっては良質な利用者であるヘビーユーザであるほど，利用料が高くなってしまい，結果として，その利用を妨げることとなってしまう。そのため，そのようなユーザの利用離れによって，サービスの運営が困難となってしまう。

そこでユーザから利用料を徴収する代わりに，広告枠の提供やマーケティングデータの販売によって利益を出すことで，無料サービスとして提供することが考えられる。しかし，広告を提供する場合，広告枠の提供やマーケティングデータの販売が成立するには，相当数のユーザの利用が必要であって，そこに至るまでは投資が必要となり，資本力のない企業にはそれを維持することが困難である。

すなわち，無料で行われている従来の取引サービスでは，多くのユーザがすでにいる場合はともかく，そうでない場合には，それを維持することが困難であって，結果的に，取引サービス自体が終了してしまうことも多い。

そこで本発明者は上記課題に鑑み，資本力のない企業や個人などであっても取引サービスを運営できる取引システムを発明した。

第１の発明は，商品を取引する取引システムであって，前記取引システムは，取引する商品の情報を記憶する商品情報記憶部と，ユーザが利用するユーザ端末に対して，前記商品情報記憶部に記憶した商品情報を送り表示させる商品情報提供処理部と，商品を提供したことによって得られるポイント数の合計である収入ポイントと，商品を譲り受けたことによって得られるポイント数の合計である支出ポイントとを，ユーザごとに記憶する収支情報記憶部と，前記ユーザ端末から商品の取引の申込を受け付け，その商品に対して設定されたポイント数の情報を用いて，前記収支情報記憶部における収入ポイントまたは支出ポイントを更新することで取引処理を行う取引処理部と，所定のタイミングごとに，前記収支情報記憶部に記憶する各ユーザの収入ポイントおよび支出ポイントを用いて各ユーザの利用金額を算出する課金処理部と，を有しており，前記取引処理部は，前記商品を提供したユーザの収入ポイントに，前記商品に対応付けられたポイント数を加算し，前記商品を譲り受けたユーザの支出ポイントに，前記商品に対応付けられたポイント数を加算し，前記課金処理部は，前記収支情報記憶部に記憶するユーザの収入ポイントおよび支出ポイントの合計値を，あらかじめ定められた期間単位で除算した値をすべてのユーザについて算出し，ユーザごとの前記算出した値を用いて，そのユーザの全ユーザにおける偏差値を算出することで，各ユーザのすべてのユーザにおける位置づけを判定し，前記偏差値に対応する利用料率の情報をユーザごとに特定し，ユーザごとの収入ポイントおよび支出ポイントの差分の絶対値と，特定した利用料率とを用いて，各ユーザの利用金額を算出する，取引システムである。

本発明のように構成することで，利用金額の算出にあたり，そのユーザの全ユーザに対する位置づけを特定した上で利用金額を特定することができる。そのため，従来はヘビーユーザほど利用料金が発生することが多く，利用離れを招くことがあったが，本発明ではそのようなことがなくなる。

上述の発明において，前記取引システムは，前記ユーザの属性情報を受け付けて登録処理を行うユーザ登録受付処理部と，前記ユーザの属性情報を記憶するユーザ情報記憶部と，を有しており，前記ユーザ登録受付処理部は，ＳＮＳサービス管理サーバから前記ユーザの属性情報を受け付ける，取引システムのように構成することができる。

ユーザの属性情報として，ユーザ端末から入力を受け付けても良いが，ＳＮＳサービスを利用している場合にはそこから取得することで，ユーザの負担を軽減することができる。

上述の発明において，前記ユーザ登録受付処理部は，前記ＳＮＳサービス管理サーバで記憶する前記ユーザの友人情報を，前記ユーザの属性情報として受け付ける，取引システムのように構成することができる。

本発明の取引システムではユーザ間で商品を取引する。そのため，全く知らないユーザ同士で取引するよりも，本発明のように，友人同士での取引の方が安心感が得られる。しかし友人情報を改めて登録するのはユーザにとって負担が重い。そこで，ＳＮＳサービスの友人情報を取得することで，取引システムにとって重要な情報である友人情報を入力するための負担を軽減することができる。

上述の発明において，前記ユーザ登録受付処理部は，前記ユーザ端末から退会要求を受け付け，前記課金処理部は，前記収支情報記憶部に記憶するユーザの収入ポイントおよび支出ポイントを用いてそのユーザの，全ユーザにおける位置づけを判定し，その判定結果を用いて退会時の利用金額を算出する，取引システムのように構成することができる。

退会する場合には本発明の処理を実行することで利用金額を算出することができる。

上述の発明において，前記ユーザ登録受付処理部は，前記ユーザ端末から退会要求を受け付け，前記課金処理部は，前記ユーザの，全ユーザにおける位置づけを，前記収支情報記憶部から，以前の課金処理で算出した位置づけの情報を抽出し，抽出した位置づけの情報を用いて退会時の利用金額を算出する，取引システムのように構成することができる。

本発明の取引システムでの利用金額の算出処理は，全ユーザに対する処理を行うことから，システムにかかる負荷が大きい。そのため，一人のユーザの退会のために，全ユーザに対する処理を行うのは好ましくない。そこで，本発明のように構成することで，その負荷を軽減することができる。

本発明の取引サービスを用いることによって，資本力のない企業や個人などであっても取引サービスを運営することができる。ユーザに対して課される費用は，ユーザの取引サービスに対する貢献によって変動しうるので，公平性を維持した課金となり，ユーザに対する不満の発生も少ない。そのため，課金制を採ったことによるユーザの利用離れが起きにくくなる。

本発明の取引システムのシステム構成の一例を模式的に示す図である。本発明の取引システムを実現するコンピュータのハードウェア構成の一例を模式的に示す図である。ユーザ登録処理の処理プロセスの一例を模式的に示すフローチャートである。商品登録処理の処理プロセスの一例を模式的に示すフローチャートである。取引処理の処理プロセスの一例を模式的に示すフローチャートである。課金処理の処理プロセスの一例を模式的に示すフローチャートである。退会処理の処理プロセスの一例を模式的に示すフローチャートである。ユーザ情報記憶部の一例を模式的に示す図である。商品情報記憶部の一例を模式的に示す図である。トップ画面の一例を模式的に示す図である。収支情報記憶部の一例を模式的に示す図である。偏差値と利用料率との対応関係の一例を模式的に示す図である。商品情報の登録を行う画面の一例を模式的に示す図である。申込画面の一例を模式的に示す図である。確認画面の一例を模式的に示す図である。メッセージの入力画面の一例を模式的に示す図である。取引成立画面の一例を模式的に示す図である。取引成立時に相手方に送られるメッセージの一例を模式的に示す図である。取引成立後のトップ画面の一例を模式的に示す図である。取引成立後に，取引の相手方のトップ画面の一例を模式的に示す図である。取引の詳細画面の一例を模式的に示す図である。収支情報のやりとりの一例を模式的に示す図である。

本発明の取引システム１のシステム構成の一例の概念図を図１に示す。本発明の取引システム１は，物やサービス，情報などの商品をウェブサイトなどを介して取引する取引サービスを実現するためのコンピュータシステムである。このウェブサイトに商品の提供者たるユーザＡが商品を登録し，それを閲覧したほかのユーザＢがその商品を欲しいことを示す申込を行うことで，ユーザＡとユーザＢとの間で商品が取引される。この取引に際しては無償であることが好ましいが，送料等の諸経費が発生することもある。

取引システム１は，本システムを管理する企業等が利用するサーバ２と，本システムのユーザが利用するユーザ端末３とを有する。

取引システム１のサーバ２，ユーザ端末３は，サーバ２やパーソナルコンピュータ，タッチパネル型表示装置を備えた可搬型通信端末などの各種のコンピュータにより実現される。図２にコンピュータのハードウェア構成の一例を示す。取引システム１におけるサーバ２，ユーザ端末３は，プログラムの演算処理を実行するＣＰＵなどの演算装置７０と，情報を記憶するＲＡＭやハードディスクなどの記憶装置７１と，ディスプレイなどの表示装置７２と，キーボードやポインティングデバイス（マウスやテンキーなど）などの入力装置７３と，演算装置７０の処理結果や記憶装置７１に記憶する情報をインターネットやＬＡＮなどのネットワークを介して送受信する通信装置７４とを有している。

なお，図１ではサーバ２が一台のコンピュータで実現される場合を示したが，複数台のコンピュータにその機能が分散配置され，実現されても良い。

本発明における各手段は，その機能が論理的に区別されているのみであって，物理上あるいは事実上は同一の領域を為していても良い。

サーバ２は，ユーザ登録受付処理部２０とユーザ情報記憶部２１と認証処理部２２と商品情報登録受付処理部２３と商品情報記憶部２４と商品情報提供処理部２５と取引処理部２６と収支情報記憶部２７と課金処理部２８とを有する。

ユーザ登録受付処理部２０は，取引システム１で提供する取引サービスの利用を希望するユーザがユーザ登録をするため，ユーザの属性情報とユーザ登録の要求をユーザ端末３から受け付ける。受け付けたユーザの属性情報は，後述するユーザ情報記憶部２１に記憶させる。ユーザの属性情報としては，たとえば氏名，年齢，性別，住所，電子メールアドレス，電話番号，当該ユーザの友人情報（友人の氏名，識別情報など）などさまざまな情報を用いることができる。また本取引システム１以外のコンピュータシステム，たとえばＳＮＳサービスのコンピュータシステムからその情報を取得しても良い。

ユーザ情報記憶部２１は，ユーザの属性情報を記憶する。またユーザの属性情報に対応づけて，当該ユーザを取引システム１で識別するユーザ識別情報に対応づけられても良い。ユーザ識別情報は，ユーザ情報の登録時に，ユーザ登録受付処理部２０が任意に発行してもよいし，ユーザ端末３から入力を受け付けても良い。図８にユーザ属性情報の一例を模式的に示す。なお，図８における口座情報とは，後述する収支情報記憶部２７における当該ユーザの収支情報を識別する情報である。収支情報は，ユーザ登録の際に収支情報記憶部２７において生成される，当該ユーザのポイントの収入および支出を示す情報である。

認証処理部２２は，取引システム１への認証処理をユーザ情報記憶部２１に記憶する認証情報，たとえばユーザＩＤ，パスワードなどに基づいて行う処理です。

商品情報登録受付処理部２３は，ユーザ端末３から，取引システム１へ商品を提供することを示す商品情報の登録の受付処理を行う。また，ユーザ端末３から，取引システム１を介して，ほかのユーザから希望の商品の提供を受けたいことを示す商品情報の登録の受付処理を行う。受け付けた商品情報は，当該商品を識別可能な商品識別情報に対応づけて，後述する商品情報記憶部２４に記憶する。

受け付ける商品情報としては，提供する商品に関する情報（商品名，商品に関する詳細な情報，商品の画像情報，商品の個数など），その商品の提供に必要なポイント数，希望する商品に関する情報（商品名，商品に関する詳細な情報，商品の個数など），その商品の提供を受けた場合に提供したユーザに対して付与するポイント数などがある。また，商品を提供するとは，当該商品を登録したユーザからほかのユーザに対して，当該商品を譲る，販売する，などである。商品を希望するとは，当該商品を登録したユーザが，ほかのユーザに対して，当該商品を譲ってもらえるまたは販売してもらうように依頼するなどである。

商品情報記憶部２４は，商品情報登録受付処理部２３で受け付けた商品情報を記憶する。図９に商品情報記憶部２４の一例を模式的に示す。

商品情報提供処理部２５は，商品情報記憶部２４に記憶する提供商品情報，希望商品情報をそれぞれウェブサイトで表示し，ほかのユーザのユーザ端末３に表示させる。図１０に商品情報記憶部２４の一例を模式的に示す。

取引処理部２６は，商品情報ウェブサイトを閲覧したユーザが，そこに表示されている商品を欲しいまたは譲りたいという場合に，たとえば「申込」のボタンを押下することによって，取引を行う画面を表示し，取引を行う。また取引処理部２６は，取引の成立後，提供商品の取引の場合には，収支情報記憶部２７において，商品を提供したユーザの収支情報のうち収益について，当該成立した商品に対応づけられたポイント数を加算し，商品を譲り受けたユーザの収支情報のうち支出について，当該成立した商品に対応づけられたポイント数を加算する。また，希望商品の取引の成立の場合には，商品を希望したユーザの収支情報のうち支出について，当該成立した商品に対応づけられたポイント数を加算し，商品を提供したユーザの収支情報のうち収入について，当該成立した商品に対応づけられたポイント数を加算する。

収支情報記憶部２７は，各ユーザの収入および支出のポイントの情報を記憶する。図１１に収支情報記憶部２７の概念図の一例を模式的に示す。図１１では示していないが，後述する課金処理で用いる偏差値，利用料金などを記憶していても良い。収入ポイントとは商品を提供したことによって得られたポイント数の合計であり，支出ポイントとは商品をもらったことによって得られたポイント数の合計である。

なお，本発明においては退会したユーザがいた場合であっても，ユーザ情報記憶部２１に記憶するユーザ情報は消去したとしても，収支情報についてはその記録を残しておき，消去しない。なぜならば，本発明では，取引によって収入と支出について相対するポイントが発生し，全ユーザの収入ポイントの合計と，支出ポイントの合計とは一致しているためである。その結果，退会したユーザの収支情報を消去してしまうとそのバランスが不一致となってしまうからである。なお，退会後に収支情報を消去しない結果，当該ユーザが再入会した場合，その収支情報を再度，利用することが可能となる。

課金処理部２８は，所定のタイミングにおいて，収支情報記憶部２７に記憶する各ユーザのポイントの収入および支出の情報に基づき，当該ユーザに対して課金する利用金額を算出する。所定のタイミングとしては，取引が行われる都度，請求のタイミング（たとえば毎月所定日など），退会処理のタイミングなど，任意に設定が可能である。

課金処理としては，以下のように行う。まず課金処理部２８は，課金処理の対象となったユーザの収入および支出のポイントの情報を収支情報記憶部２７から抽出し，収入ポイントＰｉと支出ポイントＰｏの合計値Ｐａを算出する。そしてこの合計値Ｐａに対して，あらかじめ定められた期間（たとえば１週間，１ヶ月，６ヶ月など）の単位（時間，日数，週数，月数，年数など）で除算した値Ｐｂを，すべてのユーザについて算出する。そしてユーザごとの値Ｐｂを用いて，処理対象となったユーザに関する偏差値ＶＬを算出する。そして，課金処理部２８であらかじめ設定されている偏差値ＶＬと利用料率との対応関係のテーブル（図１２）に基づき，当該ユーザの利用料率を特定する。なお，偏差値ＶＬを算出するタイミングは課金処理時のほか，あらかじめ定められたタイミングであれば良く，たとえば毎日，毎週所定曜日など，定められる。

たとえば図１２の場合，算出した偏差値ＶＬが４８であれば利用料率は０．１０％と特定し，偏差値ＶＬが６７であれば利用料率は０．０４％と特定する。

そして課金処理部２８は，当該ユーザの収入ポイントＰｉから支出ポイントＰｏの差分の絶対値Ｐｃに，上記で特定した利用料率を乗算することで，利用金額を算出する。

課金処理部２８でこのような処理を行うことで，取引システム１全体における当該ユーザの貢献度合い（位置づけ，偏差値）を特定し，それに基づいて利用料率が変動しうる。そして貢献度が高いユーザほど利用料率が低くなるので，従来のようにヘビーユーザほど高額な利用料金になることが回避できる。なお，利用金額の算出にあたっては，ユーザの収入ポイントと支出ポイントとを用いて，当該ユーザの全ユーザにおける位置づけを判定し，その判定結果を利用して利用金額を算出するのであれば，上記方法に限定されず，ほかの方法であっても良い。

課金処理部２８は，以上のようにして算出した利用料金を，ユーザ情報記憶部２１に記憶する電子メールアドレスの情報に基づいて，通知を行う。なお，当該ユーザ自身のページ（マイページ）が生成される場合には，そこで表示を行っても良い。また，ユーザに，現在の貢献度合いを示すため，そのウェブサイト上で偏差値ＶＬを表示しておくと良い。

つぎに本発明の取引システム１の処理プロセスの一例を図３乃至図７のフローチャートを用いて模式的に示す。

まず取引システム１を利用する場合には，そのユーザ登録をする必要がある。この処理プロセスを図３のフローチャートを用いて説明する。

まず取引システム１にユーザ登録をしたい場合，ユーザは所定の方法でユーザ端末３からサーバ２にアクセスし，ユーザ登録の処理要求を行う。そしてユーザ登録の画面をユーザ端末３で表示させ，当該ユーザの属性情報の入力をユーザ登録受付処理部２０で受け付ける（Ｓ１００）。ユーザ登録受付処理部２０は，受け付けたユーザの属性情報を，発行したユーザ識別情報に対応づけてユーザ情報記憶部２１に記憶させる（Ｓ１１０）。また，ユーザ登録受付処理部２０は，あらたに登録を受け付けたユーザの収支情報として，収支情報記憶部２７に，収入ポイント，支出ポイントの初期値を設定する（Ｓ１２０）。通常は収入ポイント，支出ポイントの初期値はいずれも０であるが，それ以外に設定されていても良い。

以上のような処理を実行することで，ユーザ登録の処理を行うことができる。

また，ユーザの属性情報などは，ユーザ端末３から入力を受け付けるのではなく，取引システム１とは別のＳＮＳサービスから情報を取得しても良い。すなわち，ユーザはユーザ端末３で所定の操作を行うことで，本取引システム１のサーバ２にアクセスし，ユーザ登録の処理要求を行うと，ＳＮＳサービスを提供するＳＮＳサービス管理サーバ（図示せず）へのログイン画面を表示させる。そしてＳＮＳサービスに対してログインをする。これによって，取引システム１がＳＮＳ管理サーバで記憶している当該ユーザの属性情報を抽出し，取引システム１のサーバ２のユーザ登録受付処理部２０で取得する。そして取得したユーザの属性情報をユーザ登録受付処理部２０が，ユーザ情報記憶部２１に記憶させる。

このような方法によってユーザの属性情報の登録を行うことで，ユーザは属性情報の入力を行う必要性がなくなる。またＳＮＳサービスのＳＮＳサービス管理サーバから取得することで，通常，ＳＮＳサービスでは，当該ユーザの友人の情報が記憶されていることから，それを取得することもできる。すなわち，取引システム１においては，ユーザ間での商品の取引（譲る／あげる）が行われることから，全く知らないユーザ間でそれが行われるよりも，知っているユーザ間で行われるほうが安心感がある。そのため，ユーザの友人情報を取得し，そのユーザの商品情報を商品情報提供処理部２５が優先的に表示すると安心感が得られる。しかし，全く最初の状態から友人の情報を登録するのには，負担が発生する。そこで，ＳＮＳサービスのＳＮＳサービス管理サーバから取得することで，その負担を減らすことができ，取引サービスならではのメリットを享受することができる。

つぎに，ユーザが商品登録を行う場合の処理を図４のフローチャートを用いて説明する。商品登録を行う場合，まずユーザは所定の方法でログインを行う。すなわち，ユーザ端末３からユーザ識別情報とパスワードの入力を行うことで，それをサーバ２の認証処理部２２で受け付け，ユーザ情報記憶部２１を参照することで認証処理を行う。認証処理が正常に行われれば，以降の処理を実行する。なお，認証処理は，ＳＮＳサービスにおける認証処理を実行しても良い。この場合，認証処理部２２でユーザ識別情報とパスワードの入力を受け付けると，それをＳＮＳサービス管理サーバに渡し，認証結果を認証処理部２２で受け取る。正常に認証が行われた情報を受け取れば以降の処理を実行し，そうでない場合には再度の認証処理を実行させる。

正常に認証処理が実行された後，商品情報提供処理部２５がユーザ情報記憶部２１および商品情報記憶部２４に記憶する情報に基づいて，図１０に示すように，当該ユーザの友人が登録している商品情報を抽出してトップ画面に表示をする。なお，友人が商品情報を登録していない場合には，ランダムに商品情報を抽出し，表示しても良いし，表示をしなくても良い。

そして，提供する／または希望する商品情報の登録をユーザ端末３から受け付ける（Ｓ２００）。すなわち，図１０のトップ画面から，ユーザが商品を提供したい（譲りたい）場合には，投稿のプルダウンメニューから「ゆずる」を選択し，希望の商品が欲しい（もらいたい）場合には，投稿のプルダウンメニューから「もらう」を選択する。また，その商品のカテゴリの選択を受け付ける。「物品」は書籍，電化製品，ＣＤなどの物であり，「場所」はユーザが利用していない土地や部屋，店舗などであり，「時間」は家庭教師，家事代行などの時間によるサービスであり，「運送」は自動車の乗り合い，荷物の運搬など移動・輸送に関する者であり，「芸術」は絵画や写真，彫刻などの芸術作品などであり，「割引」は割引券などのクーポンを指す。

そして「ゆずる」か「もらう」かの選択と商品のカテゴリの選択を受け付けると，商品情報登録受付処理部２３は，ユーザ端末３に，図１３に示す画面を表示させ，詳細な商品情報の選択を受け付ける。ここで商品名，商品がどのカテゴリに属するかの選択，譲るのか貸すのかパターンの選択，在庫数，引渡方法の選択，商品に関する説明，商品などに関する情報のリンク，商品の画像ファイルの選択，だれに対して公開するのか（全員か，友人のみか，自分のみか）などの商品情報の入力をユーザがユーザ端末３で行い，それをユーザ端末３から商品情報登録受付処理部２３が受け付ける。そして，商品情報登録受付処理部２３は，受け付けた商品情報を商品情報記憶部２４に記憶させ，商品情報を登録する（Ｓ２１０）。

このようにして商品情報が商品情報記憶部２４に記憶されることで，取引システム１において，当該ユーザが提供する商品，希望する商品が登録される（Ｓ２２０）。

つぎに，本取引システム１を用いて，商品の取引を行う場合を図５のフローチャートを用いて説明する。

まず商品の取引を希望するユーザは，所定の方法でユーザ端末３からサーバ２にアクセスすることで，公開されている商品情報の閲覧要求がユーザ端末３からサーバ２に送られ，サーバ２の商品情報提供処理部２５でそれを受け付ける。商品情報提供処理部２５は，受け付けた閲覧要求における当該ユーザのユーザ識別情報に基づいてユーザ情報記憶部２１を参照することで，当該ユーザの友人の情報を抽出する。そして抽出した友人が商品情報を登録しているかを商品情報記憶部２４から検索し，図１０に示すトップ画面にその商品情報を表示させる（Ｓ３００）。

また友人が商品情報を登録していない場合には，ランダムあるいは登録日時の遅い商品情報（直近に登録された商品情報）など，所定の基準に基づいて，順に，商品情報記憶部２４から抽出し，表示させる。なお，ユーザが任意のキーワードを図１０のトップ画面の入力欄に入力し検索することで，そのキーワードを含む商品情報があるかを商品情報記憶部２４から検索し，該当する商品情報を図１０のトップ画面に表示させても良い。

まずユーザＡが商品を提供したいときの取引（申込者（ユーザＢ）にとっては，ほかのユーザＡが譲るとしている商品に対して，その商品を譲り受ける取引）を説明する。この場合，ユーザＢは，このトップ画面から取引したい商品情報を選択し，それをサーバ２の取引処理部２６は受け付ける（Ｓ３１０）。すなわち，トップ画面に表示された商品情報をユーザ端末３で閲覧したユーザＢは，取引をしたい商品（譲り受けたい商品）があった場合には，トップ画面の商品情報のうち「申込」のボタンを押下する。これによって，申込が押されたことの情報がユーザ端末３からサーバ２に送られ，サーバ２の取引処理部２６は，対応する商品情報を商品情報記憶部２４から抽出し，その情報を含む，図１４に示す申込画面を取引処理部２６がユーザ端末３に表示させる。

この申込画面を閲覧したユーザＢは，譲り受けたい商品の個数の情報と，引渡方法の選択を行い，「次へ進む」を選択する。個数と引渡の情報がユーザ端末３からサーバ２に送られ，サーバ２の取引処理部２６は，図１５に示す確認画面をユーザ端末３に表示させる。

ユーザＢがユーザ端末３で「確定する」を選択すると，その情報がユーザ端末３からサーバ２に送られ，サーバ２の取引処理部２６は，図１６に示すメッセージの入力画面をユーザ端末３に表示させる。当該ユーザＢが商品情報の登録をしたユーザＡとコミュニケーションを取りたい場合にはその入力を受け付け，「次へ進む」を選択する。この選択をユーザ端末３から受け付けたサーバ２の取引処理は，そのメッセージを受け付け，サーバ２の取引処理部２６は，図１７に示す取引成立画面をユーザ端末３に表示させる。さらにサーバ２の取引処理部２６は，当該取引の当事者間におけるポイントの処理を行う（Ｓ３２０）。

すなわち，成立した取引が，提供した商品に対する申込である場合（商品をあげる場合（申込者にとっては商品を譲り受ける場合）），たとえばユーザＡが提供した商品「メモ帳」をユーザＢが欲しいと思って申込をした場合，収支情報記憶部２７におけるユーザＡの収入のポイント数に，当該商品情報に対応づけられたポイント数を加算する。加算前のポイント数が０であり，「メモ帳」に対応づけられたポイント数が２００である場合，取引処理部２６は，ユーザＡの収入のポイント数を２００に更新する。また，収支情報記憶部２７におけるユーザＢの支出のポイント数に，当該商品情報に対応づけられたポイント数を加算する。加算前のポイント数が０であり，「メモ帳」に対応づけられたポイント数が２００である場合，取引処理部２６はユーザＢの支出のポイント数を２００に更新する。

つぎに，ユーザＡが商品を譲り受けたいときの取引（申込者（ユーザＢ）にとっては，ほかのユーザＡが欲しいと要望している商品に対して，その商品を提供する取引）を説明する。この場合，ユーザＢは，このトップ画面から取引したい商品情報を選択し，それをサーバ２の取引処理部２６は受け付ける（Ｓ３１０）。すなわち，トップ画面に表示された商品情報をユーザ端末３で閲覧したユーザＢは，取引をしたい商品（提供したい商品）があった場合には，トップ画面の商品情報のうち「リクエストに応える」のボタンを押下する。これによって，当該ボタンが押されたことの情報がユーザ端末３からサーバ２に送られ，サーバ２の取引処理部２６は，対応する商品情報を商品情報記憶部２４から抽出し，その情報を含む，図１３に示す商品情報の登録画面をユーザ端末３で表示させ，詳細な商品情報の選択を受け付ける。

ここで商品名，商品がどのカテゴリに属するかの選択，譲るのか貸すのかパターンの選択，在庫数，引渡方法の選択，商品に関する説明，商品などに関する情報のリンク，商品の画像ファイルの選択，だれに対して公開するのか（全員か，友人のみか，自分のみか）などの商品情報の入力をユーザＢがユーザ端末３で行い，それをユーザ端末３から商品情報登録受付処理部２３が受け付ける。そして，商品情報登録受付処理部２３は，受け付けた商品情報を商品情報記憶部２４に記憶させ，商品情報を登録する。

このようにして商品情報が商品情報記憶部２４に記憶されることで，取引システム１において，当該ユーザが提供する商品，希望する商品が登録される。

そして商品情報が商品情報記憶部２４に登録されると，当該ユーザＡのみに対して，その商品に対する提供があったことの表示が，たとえば図１０と同様に行われる。そしてトップ画面から，提供があった商品が当該ユーザＡの要望に適い，取引をしたい場合には，上述のＳ３１０と同様に，ユーザＡが取引したい商品情報を選択し，それをサーバ２の取引処理部２６は受け付ける。すなわち，トップ画面に表示された商品情報をユーザ端末３で閲覧したユーザＡは，提供したいと登録があった商品について取引をしたい場合には，トップ画面の商品情報のうち「申込」のボタンを押下する。これによって，申込が押されたことの情報がユーザ端末３からサーバ２に送られ，サーバ２の取引処理部２６は，対応する商品情報を商品情報記憶部２４から抽出し，その情報を含む，図１４に示す申込画面を取引処理部２６がユーザ端末３に表示させる。

この申込画面を閲覧したユーザＡは，譲り受けたい商品の個数の情報と，引渡方法の選択を行い，「次へ進む」を選択する。個数と引渡の情報がユーザ端末３からサーバ２に送られ，サーバ２の取引処理部２６は，図１５に示す確認画面をユーザ端末３に表示させる。

ユーザＡがユーザ端末３で「確定する」を選択すると，その情報がユーザ端末３からサーバ２に送られ，サーバ２の取引処理部２６は，図１６に示すメッセージの入力画面をユーザ端末３に表示させる。当該ユーザＡが商品情報の登録をしたユーザＢとコミュニケーションを取りたい場合にはその入力を受け付け，「次へ進む」を選択する。この選択をユーザ端末３から受け付けたサーバ２の取引処理は，そのメッセージを受け付け，サーバ２の取引処理部２６は，図１７に示す取引成立画面をユーザ端末３に表示させる。さらにサーバ２の取引処理部２６は，当該取引の当事者間におけるポイントの処理を行う（Ｓ３２０）。

すなわち，成立した取引が，提供した商品に対する申込である場合（商品をあげる場合（申込者にとっては商品を譲り受ける場合））と同様に，たとえばユーザＡが欲しいと思って登録した商品「メモ帳」をユーザＢが提供したいと思ってその商品を登録し，それを閲覧したユーザＡが欲しいと思って申込をした場合，収支情報記憶部２７におけるユーザＢの収入のポイント数に，当該商品情報に対応づけられたポイント数を加算する。加算前のポイント数が０であり，「メモ帳」に対応づけられたポイント数が２００である場合，取引処理部２６は，ユーザＢの収入のポイント数を２００に更新する。また，収支情報記憶部２７におけるユーザＡの支出のポイント数に，当該商品情報に対応づけられたポイント数を加算する。加算前のポイント数が０であり，「メモ帳」に対応づけられたポイント数が２００である場合，取引処理部２６はユーザＡの支出のポイント数を２００に更新する。

取引処理部２６は，その取引の相手方の電子メールアドレスをユーザ情報記憶部２１から抽出し，図１８に示すようなメッセージを，たとえば電子メールで送る。

取引成立画面を閲覧したユーザは，「トップへ」を選択すると，その情報がユーザ端末３からサーバ２に送られ，サーバ２の商品情報提供処理部２５は図１９に示すようなトップ画面を表示させる。図１９のトップ画面では，取引が成立したことと，その取引に対して評価を促すことのメッセージが表示される。

一方，取引の他方当事者であるユーザがトップ画面を表示する場合，図２０に示すように，取引が成立したことのメッセージが表示される。そして当該ユーザが図２０のトップ画面におけるメッセージを選択すると，図２１に示すように取引の詳細画面が表示される。

以上のようにして両当事者間での商品の取引が行われる。商品の引渡などは，両当事者間で直接，電子メールやメッセージ，チャットなど，任意の方法で連絡を取り合うことで行える。

つぎに，課金処理を行う場合を図６のフローチャートを用いて説明する。たとえば毎月一回，所定のタイミングで課金処理部２８は，課金処理を行う。

図２２に，ユーザとしてＡ乃至Ｄがいた場合であって，取引が行われた場合の収支情報記憶部２７の一例を模式的に示す。なお，図２２においてユーザＡの括弧で表示しているポイント数は，退会後のポイント数である。退会後には変動はないものの，収支情報は消去しないため，それをわかりやすく表示するため括弧書きで表示している。

まず課金処理部２８は，収支情報記憶部２７に記憶する各ユーザの収支情報を抽出し，それぞれの収支情報における収入ポイントＰｉと支出ポイントＰｏの合計値Ｐａを算出する。そして合計値Ｐａに対して，あらかじめ定められた期間単位（時間，日数，週数，月数，年数など）で除算することで値Ｐｂを，すべてのユーザについて算出する。そしてユーザごとの値Ｐｂを用いて，処理対象となったユーザに関する偏差値ＶＬを算出する（Ｓ４００）。偏差値ＶＬを算出することによって，取引システム１において，全ユーザにおけるそのユーザの位置づけを特定することができる。そして，課金処理部２８は，算出した偏差値ＶＬに基づいて，図１２に示す偏差値と利用料率との対応関係を示す情報から，ユーザごとの利用料率を特定する（Ｓ４１０）。抽出した収入ポイントＰｉ，支出ポイントＰｏ，特定した偏差値ＶＬは，ユーザの便宜に供するため，商品情報提供処理部２５でトップ画面などを表示する際に，あわせて表示することが好ましい。

以上のようにして特定した利用料率に基づいて，課金処理部２８は，ユーザごとに収支情報記憶部２７に記憶する収支情報における収入ポイントＰｉと支出ポイントＰｏの差分の絶対値Ｐｃに，Ｓ４１０で特定した利用料率を乗算して利用料金を算出する（Ｓ４２０）。

以上のようにして算出した利用料金を，ユーザ情報記憶部２１に記憶する電子メールアドレスなどに基づいて，電子メールで通知し，請求を行う（Ｓ４３０）。あるいは，ユーザのトップ画面に利用料金を表示させても良いし，所定の住所に請求書として送付しても良い。

つぎにユーザが退会する場合の処理プロセスの一例を図７のフローチャートを用いて説明する。

まずユーザが希望する場合，図１０に示すようなトップ画面から所定の操作を行うことで，退会要求をユーザ端末３からサーバ２に送る。サーバ２のユーザ登録受付処理部２０では，退会要求を受け付けると（Ｓ５００），課金処理部２８における退会時における課金処理を開始させる。すなわち，Ｓ４００と同様に，その時点における収支情報記憶部２７に記憶する各ユーザの収支情報を抽出し，それぞれの収支情報における収入ポイントＰｉと支出ポイントＰｏの合計値Ｐａを算出する。そして合計値Ｐａに対して，あらかじめ定められた期間単位で除算することで値Ｐｂを，すべてのユーザについて算出する。そしてユーザごとの値Ｐｂを用いて，処理対象となったユーザに関する偏差値ＶＬを算出する（Ｓ５１０）。偏差値ＶＬを算出することによって，取引システム１において，全ユーザにおけるそのユーザの位置づけを特定することができる。そして，課金処理部２８は，算出した偏差値ＶＬに基づいて，図１２に示す偏差値と利用料率との対応関係を示す情報から，退会を希望するユーザの利用料率を特定する（Ｓ５２０）。

以上のようにして特定した利用料率に基づいて，課金処理部２８は，退会を希望するユーザの収支情報記憶部２７に記憶する収支情報における収入ポイントＰｉと支出ポイントＰｏの差分の絶対値Ｐｃに，Ｓ５２０で特定した利用料率を乗算して利用料金を算出する（Ｓ５３０）。

以上のようにして算出した退会時の利用料金を，ユーザ情報記憶部２１に記憶する電子メールアドレスなどに基づいて，電子メールで通知し，請求を行う（Ｓ５４０）。あるいは，ユーザのトップ画面に利用料金を表示させても良いし，所定の住所に請求書として送付しても良い。

なお，上述では，退会要求を受け付けた場合に，その時点における偏差値ＶＬを算出し，利用料率を特定する処理を実行したが，前回の課金処理の際に特定した利用料率を収支情報記憶部２７に基づいて特定し，それを用いても良い。この場合，収支情報記憶部２７から，退会を希望するユーザの，前回の課金処理で用いた利用料率を抽出し，退会時における収支情報記憶部２７に記憶する収支情報における収入ポイントＰｉと支出ポイントＰｏの差の絶対値Ｐａに，抽出した利用料率を乗算すればよい。

偏差値ＶＬの算出にあたっては，全ユーザに対する処理が必要となるため，このように処理することで，処理を簡略化でき，システム上の負荷を軽減することができる。

１：取引システム
２：サーバ
３：ユーザ端末
２０：ユーザ登録受付処理部
２１：ユーザ情報記憶部
２２：認証処理部
２３：商品情報登録受付処理部
２４：商品情報記憶部
２５：商品情報提供処理部
２６：取引処理部
２７：収支情報記憶部
２８：課金処理部
７０：演算装置
７１：記憶装置
７２：表示装置
７３：入力装置
７４：通信装置

Claims

商品を取引する取引システムであって，
前記取引システムは，
取引する商品の情報を記憶する商品情報記憶部と，
ユーザが利用するユーザ端末に対して，前記商品情報記憶部に記憶した商品情報を送り表示させる商品情報提供処理部と，
商品を提供したことによって得られるポイント数の合計である収入ポイントと，商品を譲り受けたことによって得られるポイント数の合計である支出ポイントとを，ユーザごとに記憶する収支情報記憶部と，
前記ユーザ端末から商品の取引の申込を受け付け，その商品に対して設定されたポイント数の情報を用いて，前記収支情報記憶部における収入ポイントまたは支出ポイントを更新することで取引処理を行う取引処理部と，
所定のタイミングごとに，前記収支情報記憶部に記憶する各ユーザの収入ポイントおよび支出ポイントを用いて各ユーザの利用金額を算出する課金処理部と，
を有しており，
前記取引処理部は，
前記商品を提供したユーザの収入ポイントに，前記商品に対応付けられたポイント数を加算し，前記商品を譲り受けたユーザの支出ポイントに，前記商品に対応付けられたポイント数を加算し，
前記課金処理部は，
前記収支情報記憶部に記憶するユーザの収入ポイントおよび支出ポイントの合計値を，あらかじめ定められた期間単位で除算した値をすべてのユーザについて算出し，
ユーザごとの前記算出した値を用いて，そのユーザの全ユーザにおける偏差値を算出することで，各ユーザのすべてのユーザにおける位置づけを判定し，
前記偏差値に対応する利用料率の情報をユーザごとに特定し，
ユーザごとの収入ポイントおよび支出ポイントの差分の絶対値と，特定した利用料率とを用いて，各ユーザの利用金額を算出する，
ことを特徴とする取引システム。
前記取引システムは，
前記ユーザの属性情報を受け付けて登録処理を行うユーザ登録受付処理部と，
前記ユーザの属性情報を記憶するユーザ情報記憶部と，を有しており，
前記ユーザ登録受付処理部は，
ＳＮＳサービス管理サーバから前記ユーザの属性情報を受け付ける，
ことを特徴とする請求項１に記載の取引システム。
前記ユーザ登録受付処理部は，
前記ＳＮＳサービス管理サーバで記憶する前記ユーザの友人情報を，前記ユーザの属性情報として受け付ける，
ことを特徴とする請求項２に記載の取引システム。
前記ユーザ登録受付処理部は，
前記ユーザ端末から退会要求を受け付け，
前記課金処理部は，
前記収支情報記憶部に記憶するユーザの収入ポイントおよび支出ポイントを用いてそのユーザの，全ユーザにおける位置づけを判定し，その判定結果を用いて退会時の利用金額を算出する，
ことを特徴とする請求項２に記載の取引システム。
前記ユーザ登録受付処理部は，
前記ユーザ端末から退会要求を受け付け，
前記課金処理部は，
前記ユーザの，全ユーザにおける位置づけを，前記収支情報記憶部から，以前の課金処理で算出した位置づけの情報を抽出し，抽出した位置づけの情報を用いて退会時の利用金額を算出する，
ことを特徴とする請求項２に記載の取引システム。
商品を提供したことによって得られるポイント数の合計である収入ポイントと，商品を譲り受けたことによって得られるポイント数の合計である支出ポイントとを，ユーザごとに記憶する収支情報記憶部と，
所定のタイミングごとに，前記収支情報記憶部に記憶する各ユーザの収入ポイントおよび支出ポイントを用いて各ユーザの利用金額を算出する課金処理部と，
を有しており，
前記課金処理部は，
前記収支情報記憶部に記憶するユーザの収入ポイントおよび支出ポイントの合計値を，あらかじめ定められた期間単位で除算した値をすべてのユーザについて算出し，
ユーザごとの前記算出した値を用いて，そのユーザの全ユーザにおける偏差値を算出することで，各ユーザのすべてのユーザにおける位置づけを判定し，
前記偏差値に対応する利用料率の情報をユーザごとに特定し，
ユーザごとの収入ポイントおよび支出ポイントの差分の絶対値と，特定した利用料率とを用いて，各ユーザの利用金額を算出する，
ことを特徴とするコンピュータシステム。