JP2020071847A - 顧客管理システム - Google Patents

Abstract

【課題】特定の対象に対して顧客が有する情熱を反映させることができる顧客管理システムを提供することを目的とする。【解決手段】メモリと、前記メモリにアクセス可能なプロセッサとを備え、前記メモリは、複数の顧客と、各々の前記顧客に付与されたポイント数であって特定の対象に対応するポイント数とを対応付けて記憶し、前記プロセッサは、前記顧客のユーザアカウントを登録し、前記特定の対象に対する活動を前記顧客がしたことを検出し、前記顧客が前記活動をしたことを検出したときに、前記顧客に対応する前記ポイント数を更新し、あらかじめ定められた規則にしたがって、前記顧客の保有する前記ポイント数に応じて、前記特定の対象に関連する特典が得られる所定の顧客を決定し出力する、顧客管理システム１が提供される。【選択図】図３

Description

本発明は、顧客管理システムに関する。

アーティスト等の特定の人物を顧客が応援する方法として、その人物のファンクラブに顧客が入会する方法がある。ファンクラブでは、顧客が一定の年会費を支払うことで、コンサートチケットやグッズの割引といった様々な特典を顧客が受けることができる。

しかしながら、アーティストに対する情熱は顧客によって様々であり、ファンクラブに入会しているだけの顧客もいれば、一年に何度もコンサートに行く顧客もいる。このように顧客ごとに情熱にばらつきがあるにも関わらず、ファンクラブが顧客に提供する特典は全ての顧客に対して同じであり、情熱を反映した特典を顧客に提供することができない。

また、従来においては、ファンクラブにおける各顧客の活動実績をファンクラブの管理者が覚えておいたり、年会費の払い込みのチェックなどによりファンクラブの会員の等級を与えたりする等、複雑な処理を行っており、顧客の管理を迅速に行うことができないという問題もある。

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

本発明は、係る問題点に鑑みて創作されたものであり、特定の対象に対して顧客が有する情熱を反映させつつ、顧客の管理を迅速に、かつより的確に行うことができる顧客管理システムを提供することを目的とする。

一側面によれば、メモリと、前記メモリにアクセス可能なプロセッサとを備え、前記メモリは、複数の顧客と、各々の前記顧客に付与されたポイント数であって特定の対象に対応するポイント数とを対応付けて記憶し、前記プロセッサは、前記顧客のユーザアカウントを登録し、前記特定の対象に対する活動を前記顧客がしたことを検出し、前記顧客が前記活動をしたことを検出したときに、前記顧客に対応する前記ポイント数を更新し、あらかじめ定められた規則にしたがって、前記顧客の保有する前記ポイント数に応じて、前記特定の対象に関連する特典が得られる所定の顧客を決定し出力する、顧客管理システムが提供される。

一側面によれば、特定の対象に対する活動を顧客がしたときに、その顧客に対応する前記ポイントをプロセッサが更新するため、顧客が特定の対象に対して有する情熱の大小をポイントに反映させることが可能となる。

また、プロセッサがポイントの更新を行うため、例えば、ファンクラブなどの組織における各顧客の活動実績をその組織の管理者が覚えておいたり、年会費の払い込みのチェックなどにより顧客の等級を与えたりする等、複雑な処理を行う場合と比較して、顧客の管理を迅速に、かつより的確に行うことができる。

本実施形態に係る顧客管理システムのシステム構成図である。 本実施形態に係る外部サーバと管理サーバの各々のハードウェア構成図である。 本実施形態に係る顧客管理システムの機能構成図である。 本実施形態に係る更新部によるポイントの更新の一例を模式的に示す図である。 図５（ａ）〜（ｃ）は、本実施形態において顧客の端末に表示されたプラン選択画面の一例を示す図である。 本実施形態に係る顧客管理方法のフローチャートである。 本実施形態におけるポイントの移転や貸借の一例を示す模式図である。 本実施形態に係る管理部の機能を説明するためのシーケンス図である。 本実施形態におけるポイントの合算の一例を示す模式図である。 本実施形態における合算部の機能を説明するためのシーケンス図である。

以下に、添付図面を参照しながら本実施形態について説明する。

なお、以下では顧客（特定のアーティストのファン）が特定の人物（アーティスト等）を応援する場合を例にして説明するが、応援の対象は人物に限定されず、複数の人物からなるグループ、スポーツチーム、会社、キャラクタ又は組織であってもよい。
＜システム構成＞
図１は、本実施形態に係る顧客管理システムのシステム構成図である。

図１に示すように、この顧客管理システム１は、管理サーバ２と、複数の外部サーバ３とを有する。これらのサーバ２、３は、インターネット等のネットワーク５により相互に接続される。

各外部サーバ３は、アーティスト等の特定の人物に関連した各種のコンテンツを提供するwebサーバである。一例として、各外部サーバ３は、ファンクラブ、商品販売、及びオフィシャルサイトを提供する。また、当該人物に関連するインターネットコンテンツを提供するwebサーバも外部サーバ３の一例である。更に、本実施形態では、フェイスブックやツイッター（登録商標）等のSNSを提供するwebサーバも外部サーバ３の一例となる。また、クレジットカードを管理するカード会社のサーバも外部サーバ３の一例である。
なお、複数の外部サーバ３の各々は物理マシンである必要はなく、一つ又は複数の物理マシンの上で実行される仮想マシンでもよい。
一方、管理サーバ２は、後述のように顧客に対してポイントを付与する情報処理装置である。

このような顧客管理システム１においては、例えば、スマートフォン等の端末４を顧客が操作することにより、各外部サーバ３から端末４にコンテンツが提供される。
＜ハードウェア構成＞
図２は、各サーバ２、３のハードウェア構成図である。

図２に示すように、各サーバ２、３は、プロセッサ１０、メモリ１１、記憶部１２、及びNIC(Network Interface Controller)１３を備える。これらの各部は、バス１４により相互にアクセス可能である。

このうち、プロセッサ１０は、例えばCPU(Central Processing Unit)であり、メモリ１
１と協働してオペレーティングシステムや各種のアプリケーションプログラムを実行する。

メモリ１１は、例えばDRAM(Dynamic Random Access Memory)等の不揮発性メモリであり、その上に前述のオペレーティングシステムや各種のアプリケーションプログラムが展開される。
NIC１３は、各サーバ２、３をネットワーク５に接続するデバイスである。
＜機能構成＞
次に、本実施形態に係る顧客管理システム１の機能構成について説明する。
図３は、本実施形態に係る顧客管理システム１の機能構成図である。

図３に示すように、顧客管理システム１は、決済部２１、発行部２２、登録部２４、検出部２５、更新部２６、通知部２７、管理部２８、合算部２９、及び決定部３０を備える。

これらの各部は、管理サーバ２のプロセッサ１０とメモリ１１とが協働することにより実現される。また、各外部サーバ３のプロセッサ１０とメモリ１１とが協働することにより送信部２３が実現される。

このうち、決済部２１は、クレジットカードを管理するカード会社の外部サーバ３と連携して、店舗で顧客が商品を購入した時に電子決済をする。例えば、決済部２１は、顧客を識別するためのQR(Quick Response)コードなどのシンボルコードを端末に送信する。そして、店側のPOS端末等でそのQRコード（登録商標）を読み込むことで、クレジットカードで決済をすることができる。
また、このように電子決済をしたときは、決済部２１は、電子決済をしたことを知らせるイベント情報を検出部２５に通知する。

発行部２２は、特定の人物が出演するコンサート等に入場するための電子チケットを発行する。その顧客がその電子チケットを購入すると、顧客の端末に電子チケットを識別するためのQRコードが表示される。そして、コンサート会場の入り口で主催者がリーダでQRコードを読み取ることで、顧客がそのコンサートに入場することができる。
なお、このように電子チケットを発行したときは、発行部２２は、電子チケットを発行したことを知らせるイベント情報を検出部２５に通知する。
送信部２３は、管理サーバ２の検出部２５にイベント情報を送信する。

イベント情報の内容は複数の外部サーバ３ごとに異なる。例えば、ファンクラブ用の外部サーバ３においては、ファンクラブへの顧客の入会、顧客によるファンクラブの更新、及びファンクラブからの顧客の退会のいずれかのイベントが発生したことがイベント情報であってもよい。

また、グッズ販売用の外部サーバ３においては、顧客による商品の購入、又は顧客による商品の購入のキャンセルの各イベントが発生したことがイベント情報となる。

オフィシャルサイト用の外部サーバ３においては、顧客がオフィシャルサイトに訪問したことがイベント情報となる。一例として、顧客がそのオフィシャルサイトにログインしたときにイベント情報が送信される。

また、特定の人物に関連するインターネットコンテンツを提供するための外部サーバ３においては、顧客がそのコンテンツを閲覧したことがイベント情報となる。例えば、顧客がそのコンテンツにログインしたときにイベント情報が送信される。
そして、SNS用の外部サーバ３においては、顧客が特定の人物に関する情報をSNSで発信したことがイベント情報となる。

また、登録部２４は、管理サーバ２に顧客のユーザアカウントを登録する。ユーザアカウントは、顧客が管理サーバ２からサービスを受けることができる権限である。この例では、登録部２４は、顧客を識別するユーザ名とパスワードとの組み合わせによりユーザアカウントを登録する。

また、検出部２５は、特定の人物に関する活動を顧客がしたことを検出する。そのような活動は、特定の人物に対するポジティブな活動やネガティブな活動等、あらゆる活動を含む。例えば、検出部２５は、複数の外部サーバ３のそれぞれの送信部２３から前述のイベント情報を受信したときに、顧客が活動をしたことを検出する。なお、特定の人物に対するポジティブな活動やネガティブな活動の例は後述する。
そして、管理サーバ２のメモリ１１は、顧客データベース３５を記憶する。

顧客データベース３５は、複数の顧客３５ａと、各々の顧客３５ａに付与されたポイント数３５ｂとを対応付けたデータベースである。ポイント数３５ｂは、特定の人物に対するファン活動を顧客が積極的に行ったことを示す整数値又は実数値であって、その値が大きいほど顧客３５ａがその人物に対して熱い情熱を有することになる。なお、この例では、顧客を識別するために、顧客のメールアドレスや氏名を使用する。

また、ポイント数３５ｂは、顧客が関心を有する対象ごとに与えられる。なお、本明細書では、顧客の関心の対象をアーティストなどの「人物」であるとして説明する。種々の実施形態における顧客の関心の対象は、人物に限定されるものではなく、アニメやゲームなどのキャラクタ等であってもよい。
例えば、氏名「AAA」の顧客が、アーティストX、Y、Zの三人に関心があるとする。その場合には、氏名「AAA」の顧客は、三人のアーティストX、Y、Zのそれぞれについてポイント数３５ｂを有することになる。
更新部２６は、顧客が特定の人物に対するファン活動をしたことを検出部２５が検出したときに、その顧客に対応するポイント数３５ｂを更新する。

決定部３０は、顧客の保有するポイント数３５ｂに応じて、特定の人物に関連する特典を決定する。特定の人物がアーティストの場合には、そのような特典としては、そのアーティストとの握手会への無料招待や、そのアーティストのライブへの無料招待等がある。

なお、決定部３０は、顧客が得られる特典を、他の顧客が保有するポイント数３５ｂに依存して決定してもよい。例えば、当該顧客が他の顧客よりも多くのポイント数３５ｂを保有している場合には、決定部３０は、他の顧客よりも魅力的な特典を当該顧客に対して付与するように決定してもよい。

また、決定部３０は、顧客が保有するポイント数３５ｂの金銭的価値に依存して、当該顧客に与える特典を決定してもよい。ポイント数３５ｂの金銭的価値の算出方法は特に限定されない。例えば、ある複数の顧客の間でポイント数３５ｂが売買されたときに、その売買における取引価格を基準に用いて、ポイント数３５ｂの金銭的価値を算出してもよい。例えば、顧客の保有するポイント数の金銭的価値が高い順に所定の数の顧客を決定する規則は、あらかじめ定められた規則の一例である。顧客が保有するポイント数３５ｂの金銭的価値は、その顧客が人物（アーティスト）を魅力的に感じている尺度となる。そのため、人物（アーティスト）に対して顧客が感じている魅力の度合いを考慮に入れて、顧客に特典を与えることが可能となる。

なお、このようにポイント数３５ｂの売買を許す場合には、売買価格を意図的につり上げるような不正な売買の芝居を防止する方策を定めておくのが好ましい。例えば、特定の顧客の間で、通常の額よりも高額で、ポイントの売買を繰り返すような行為は、不正な売買の一例である。そのような不正な売買を未然に防止する方策としては、例えば、一定の信用力のある顧客のみに対して売買を許す方策がある。また、不正をした顧客に対して、売買の禁止や、ポイントの利用の停止等の制裁を加えてもよい。
また、通知部２７は、決定部３０が決定した特典が得られる旨の通知を顧客に行う。通知の手段としては、例えば電子メールの送付がある。
ポイントの売買は、Ａ顧客からＣ顧客への一対一の取引、Ａ顧客とＢ顧客とからＣ顧客への多対一の取引であってもよい。この場合には、ポイントの売買に関与する管理サイトは、顧客対顧客（個人対個人）のポイントの売買の仲介又は貸借を仲介する機能を有する。
また、所定の取引所が、各々の人物に関連するポイントの相場を管理し、取引所を経由して、顧客間でポイントの売買が行えるようにしてもよい。この場合のポイントの売買は、通貨の授受によって行われてもよい。或いは、ポイントの売買は、通貨と同様に所定の物又サービスと交換できる特定のポイントの授受によって行われてもよい。

なお、このように顧客が特典を得た場合であっても、更新部２６は、当該顧客のポイント数３５ｂを減じないのが好ましい。これにより、特典を得るのを顧客が躊躇するのを防止できると共に、ポイントが減ることによる喪失感を顧客に感じさせないで済む。
＜ポイントの性質＞
ポイントは、消費できるポイントでもよいし、株式のように、一定の期間、ポイントを保有していると、一定期間保有したポイントの数に比例した配当がつくポイントでもよい。

消費できるポイントの場合には、特典との引き換えにポイント数３５ｂが減る。但し、上記のように、ポイントに基づいて特典を得ても、顧客の喪失感をなくすためにポイントを減じないようにしてもよい。

また、配当がつくポイントの場合には、例えば一年に一回の頻度で顧客に配当に相当する新たなポイントを付与する。また、ポイントを長期にわたって保有している顧客ほど、配当時に与える新たなポイント数３５ｂを多くしてもよい。
或いは、顧客Ａが保有するポイント（及び／又は使用したポイント数）に応じて、顧客Ａが特典を得たときに、顧客Ａにポイントを付与してもよい。付与されたポイントは、顧客Ａ本人が使用できるようにしてもよいし、顧客Ａから顧客Ｂに転送（例えばプレゼント）できるようにしてもよい。このようにすることによって、ポイントを保有すること、あるいはポイントを使用することへのインセンティブを顧客Ａに与えることができる。顧客Ａから顧客Ｂへ転送できるこのようなポイントには、ポイントに転送元が分かるフラグを付すなどして、顧客Ａ又は顧客Ｂが認識できるようにしてもよい。また、ポイントが顧客Ａから顧客Ｂの端末に転送されたことが容易にわかるように、顧客Bの端末などに顧客Aから転送されたポイント数などを表示するようにしてもよい。

上記のいずれのタイプのポイントであっても、管理サーバ２のプロセッサ１０が、複数の顧客ごとにポイント数３５ｂを計算し、それを基にして顧客を順位付けしてもよい。そして、順位が上の顧客に対して、下位の顧客よりも魅力的な特典を付与することにより、顧客がポイントを貯めるインセンティブを与えてもよい。
＜ポイント更新の例＞
図４は、更新部２６によるポイント数３５ｂの更新の一例を模式的に示す図である。

この例では、特定の人物を応援する活動を顧客がした場合に、更新部２６がポイント数
３５ｂを増やす。そのような活動としては、例えば、ユーザアカウントへの新規登録、ユーザアカウントへのログイン、当該人物のファンクラブへの入会、ファンクラブの更新、当該人物のオフィシャルサイトへの訪問、当該人物に関連する商品の購入、当該人物に関連するインターネットコンテンツの閲覧、及び当該人物に関する情報のSNSでの発信等がある。
また、決済部２１が電子決済をした場合や、発行部２２が電子チケットを発行した場合も、更新部２６がポイント数３５ｂを増やしてもよい。

特に、発行部２２が、一人の顧客に対して複数の電子チケットを一括で発行した場合には、一枚の電子チケットのみを発行する場合よりも多くのポイント数３５ｂを当該顧客に付与してもよい。

また、電子チケットの発行については、管理サーバ２による発行だけでなく、チケット販売会社が管理する外部サーバから電子チケットが発行された場合でも、更新部２６がポイント数３５ｂを増やしてもよい。
一方、特定の人物に対する興味が減退したことに起因した活動を顧客が行った場合には、更新部２６はポイント数３５ｂを減じてもよい。

そのような活動としては、例えば、ファンクラブからの退会や、特定の人物に関連する商品の購入のキャンセル等がある。また、ユーザアカウントにアクセスしない時間が所定の期間を超えた場合にも更新部２６はポイント数３５ｂを減じてもよい。更に、決済部２１による決済をキャンセルしたり、発行部２２による電子チケットの発行をキャンセルしたりした場合にも、更新部２６はポイント数３５ｂを減じてもよい。

このように、本実施形態では、顧客の活動に応じてポイント数３５ｂを増減するため、顧客が特定の人物に対して有する情熱の大小をポイント数３５ｂに反映させることが可能となる。

しかも、このようにプロセッサ１０が自動的にポイント数３５ｂを更新するため、例えば、ファンクラブなどの組織における各顧客の活動実績をその組織の管理者が覚えておいたり、年会費の払い込みのチェックなどにより顧客の等級を与えたりする等、複雑な処理を行ってポイント数３５ｂを更新する場合と比較して、顧客の管理を迅速・的確に行うことができる。

更に、本実施形態では、決済部２１、発行部２２、検出部２５、及び更新部２６の各機能を同一の管理サーバ２内のプロセッサ１０が実行する。そのため、これらの各部を別々の物理マシンに分散させる場合と比較して、各部同士の通信に要する速度を速めることができ、迅速にポイント数３５ｂを更新することができる。なお、一部の機能を他のプロセッサに実行させてもよいことは言うまでもない。
加えて、ポイントをより的確に管理することで、ポイントに応じた特典を適切に提供することが可能となる。

そして、送信部２３の機能を外部サーバ３に持たせることにより、管理サーバ２内で送信部２３を実現する場合と比較して、的確にポイントを管理しつつ、管理サーバ２のハードウェアリソースを削減することもできる。

また、図４の例では、活動ごとにポイント数３５ｂの増分値を変えている。顧客が行う活動は、その顧客が特定の人物に対して有する興味の大きさによって変わるため、このように活動ごとにポイント数３５ｂの増分値を変えることで、顧客の興味の大きさをポイント数３５ｂに反映させることができる。
更に、以下のようにポイント数３５ｂの与え方が異なる複数のプランを顧客に提示し、これらのプランのうちの一つを顧客に選択させてもよい。
図５（ａ）〜（ｃ）は、管理サーバ２が顧客４の端末に表示させたプラン選択画面の一例を示す図である。

このうち、図５（ａ）は、顧客が消費した金銭が多いほどポイント数３５ｂが多くなるプランの一例を示す図である。この例では、特定の人物に対して顧客が有する情熱の大きさを「熱量」と称している。

このプランでは、ファンクラブへの入会や商品（グッズ）の購入等のように金銭の消費を伴う活動に対して大きなポイント数３５ｂを与える。一方、ユーザアカウントへのログイン（チェックイン）や、SNSによる情報発信（SNS連携）等のように、金銭の消費を伴わない活動に対してはポイント数３５ｂを付与しないか、ポイント数３５ｂの付与の率を小さくしてもよい。
図５（ｂ）は、金銭の消費を伴わない活動ほどポイント数３５ｂの増分を大きくするプランの一例である。

このプランでは、ファンクラブの更新やユーザアカウントへのログイン（チェックイン）等のように、金銭の消費を伴わないものの、特定の人物に対する興味に起因して行われた活動に対してポイント数３５ｂの増分値を大きくする。
図５（ｃ）は、特定の人物に関する情報を他人に拡散する活動に対してポイント数３５ｂの増分を大きくするプランの一例である。

このプランでは、例えばSNSによる情報発信（SNS連携）等のように、特定の人物に関する情報を他人に拡散する活動をした場合にポイント数３５ｂの増分値を大きくする。

図５（ａ）〜（ｃ）のように、活動ごとにポイント数３５ｂの増分値が異なる複数のプランを顧客に提示して、顧客が複数のプランのうち、所望のプランを選択することができるようにしてもよい。このようにすることで、自分の行動に合ったプランを顧客が選択でき、顧客の満足度を高めることができる。

また、管理サーバ２のプロセッサ１０が、複数の特定の人物ごとに、その人物に対応したポイント数３５ｂの時価総額を計算してもよい。時価総額としては、例えば、顧客が有するその人物に関連する複数のポイント数３５ｂの金銭的価値の合計値を採用し得る。そして、その時価総額を基にして、管理サーバが、複数の顧客の各々に適したプランを決めてもよい。例えば、時価総額が小さい人物（アーティスト）については、まずファンクラブに入会するファンの数が増えることを優先させるように、例えば、図５（ａ）のプランを顧客に適用させるようにしてもよい。
或いは、管理サーバ２の管理者により、特定のアーティストに対して、特定のプランが定められてもよい。例えば、年齢層の高いファインが多い場合には、グッズ購入などに多くのポイントが付与され、利用頻度が少ないと予想されるＳＮＳなどに関する活動を重視しない図５（ｂ）のプランをデフォルトのプランとすることにしてもよい。

更に、管理サーバ２のプロセッサ１０が、時価総額が多い順に複数の特定の人物の順位付けを行ってもよい。この場合、人物に関連するポイントの時価総額が大きい上位のランキングの人物を端末４に表示することにより、人気のある人物を顧客が把握できるようにするのが好ましい。このように、人物に関連するポイントの時価総額は、その人物の人気度を示す指標として利用することができる。
＜顧客管理方法＞
次に、本実施形態に係る顧客管理方法について説明する。
図６は、本実施形態に係る顧客管理方法のフローチャートである。
まず、検出部２５が、送信部２３から送信されたイベント情報に基づいて、ファン活動等の行為を顧客がしたことを検出する（ステップＳ１）。

次に、更新部２６が、前述の図４の表に従って、顧客のポイント数３５ｂを更新する（ステップＳ２）。このとき、前述のように特定の人物を応援する活動を顧客がした場合には更新部２６がポイント数３５ｂを増やす。これとは逆に、特定の人物に対する興味が減退したことに起因した活動を顧客が行った場合には、更新部２６がポイント数３５ｂを減じる。
次いで、通知部２７が、顧客が有するポイント数３５ｂが、顧客に特典を与える基準となる所定値を超えているかを判断する（ステップＳ３）。ポイント数が所定値を超えていることは、所定の規則の一例である。このステップＳ３において、所定の規則に従って、得点を与え得る所定の顧客を出力するようにしてもよい。

ここで、「所定値を超えている」（ＹＥＳ）と判断された場合には、ステップＳ４に移ることとしてもよい。そのステップＳ４では、通知部２７が、特典が得られる旨の電子メールを顧客に送信する。通知の手法は、電子メールに限定されるものではない。
一方、ステップＳ３において「所定値を超えていない（ＮＯ）」と判断された場合には処理を終了する。
＜ポイント数３５ｂの移転又は貸借＞

本実施形態では、管理サーバ２を介して複数の顧客同士がポイント数３５ｂの移転や貸借を行うことができる。管理部２８は、そのようなポイント数３５ｂの移転や貸借を管理する。
図７は、ポイント数３５ｂの移転や貸借の一例を示す模式図である。

図７の例では、顧客Aが、自身が有するポイント数３５ｂのうちの１０ポイントを顧客Bに移転する場合を想定している。この場合の処理の流れを、図８を参照しながら説明する。
なお、ポイント数３５ｂの移転は無償で行われてもよいし、顧客Bから顧客Aへの金銭の支払いを前提として行われてもよい。
図８は、管理部２８の機能を説明するためのシーケンス図である。
まず、顧客Aが、自身の端末４を操作することにより、ポイントの移転を要求する移転要求を管理部２８に通知する（ステップＳ１０）。

その移転要求には、移転元の顧客Aを識別する移転元識別子、移転先の顧客Bを識別する移転先識別子、及び移転したいポイント数３５ｂが含まれる。移転元識別子と移転先識別子は特に限定されない。移転元識別子としては、例えば顧客Aの氏名やメールアドレスがある。また、移転先識別子としては、例えば顧客Bの氏名やメールアドレスがある。

なお、一定の信用力のある顧客同士の間の移転のみを管理部２８が受け付けてもよい。例えば、前述の移転元識別子と移転先識別子から両顧客の各々が有しているポイントの総数を管理部２８が求め、両顧客のポイント数３５ｂの各々が一定数以上の場合のみ、管理部２８が移転要求を受け付けてもよい。また、ポイント数３５ｂに代えて、特典を所定の回数だけ得ているかどうかを信用力の目安として採用してもよい。
移転要求を受けた管理部２８は、顧客Bの端末４に対して、顧客Bにポイントの移転を許可するように要求する許可要求を通知する（ステップＳ１１）。
なお、その許可要求には、顧客Aを識別するための前述の移転元識別子も含まれる。

ここで、顧客Bがポイントの移転を承認する場合には、顧客Bが端末４を操作することに
より、端末４が管理部２８に許可通知を返す（ステップＳ１２）。なお、顧客Bがポイントの移転を承認しない場合には、顧客Bが端末４を操作することにより、端末４が管理部２８に拒否通知を返し（ステップＳ１３）、処理を終える。
例えば、金銭の支払いを前提にして移転が行われる場合であって、顧客Bが金銭の額について不満があるときに、拒否通知を返すことが想定される。
上記の許可通知を受けた管理部２８は、更新部２６に対し、顧客データベース３５を更新するように要求する更新要求を通知する（ステップＳ１４）。

これを受けた更新部２６は、データベース３５を更新することにより、顧客Aのポイント数３５ｂを１０ポイントだけ減らすと共に、顧客Bのポイント数３５ｂを１０ポイントだけ増やす（ステップＳ１５）。
そして、更新部２６が、データベース３５の更新が完了したことを知らせる更新完了報告を管理部２８に通知する（ステップＳ１６）。

その後に、管理部２８が、顧客Aの端末４に対し、ポイントの移転が完了したことを知らせる移転完了報告を通知する（ステップＳ１７）。同様に、顧客Bの端末４に対しても、管理部２８が移転完了報告を通知する（ステップＳ１８）。

このように、顧客Aから顧客Bにポイントの移転が行えるようにすることで、増えたポイントによって顧客Bが特典を受けられるようになると共に、顧客Aが有するポイントを有効活用することができる。

更に、本実施形態では、更新部２６と管理部２８の各機能を同一の管理サーバ２内のプロセッサ１０が実行するため、これらの各部を別々の物理マシンに分散させる場合と比較して、各部同士の通信に要する速度を速めることができ、迅速・的確にポイント数３５ｂの移転を行うことができる。
なお、この例ではポイント数３５ｂの移転について説明したが、ポイント数３５ｂの貸借についても同様の流れで処理をすることができる。貸借の場合には、例えば所定の顧客間（当事者間）で合意された期間又は予め設定されている期間が経過すると、貸借の対象となっているポイントは、元の所有者に戻す処理が行われる。また、金銭の授受が完了すると、ポイントの貸借が成立するようにしてもよい。

また、顧客A、Bを秘匿にしながら、移転要求や許可要求の通知を行ってもよい。その場合には、移転要求や許可要求に含まれる移転元識別子や移転先識別子として、顧客Aや顧客Bのハンドルネームを使用すればよい。これにより、顧客A、Bのプライバシを保護しながら、ポイント数３５ｂの移転や貸借をすることができる。

更に、金銭等の対価の授受を前提にしてポイント数３５ｂの移転や貸借をする場合には、顧客Aから対価の支払いがあったことを管理部２８が確認し、その後にポイント数３５ｂを顧客Bに移転する等、対価の授受の管理を管理部２８が行ってもよい。
なお、対価は、金銭又は金銭と同様に物又はサービス等と交換できるような金銭的な価値を持つポイント又は仮想通貨などであってもよい。
＜ポイント数３５ｂの合算＞

本実施形態では、管理サーバ２を介して複数の顧客の間でポイント数３５ｂを合算し、これらの顧客のうちの一人に合算後のポイントを付与することができる。合算部２９は、そのようなポイント数３５ｂの合算を行う。
図９は、ポイント数３５ｂの合算の一例を示す模式図である。

図９の例では、顧客Aが有するポイント数３５ｂのうちの５ポイントと、顧客Bが有する
ポイント数３５ｂのうちの１０ポイントとを合算し、１５ポイントを顧客Cに付与する場合を想定している。この場合の処理の流れを、図１０を参照しながら説明する。
なお、ポイント数３５ｂの合算は無償で行われてもよいし、顧客A、Bから顧客Cへの金銭の支払いを前提として行われてもよい。
図１０は、合算部２９の機能を説明するためのシーケンス図である。

まず、顧客Aが自身の端末４を操作することにより、顧客Aから顧客Cへのポイント数３５ｂの付与を依頼する付与要求を合算部２９に通知する（ステップＳ２０）。

同様に、顧客Bが自身の端末４を操作することにより、顧客Bから顧客Cへのポイント数３５ｂの付与を依頼する付与要求を合算部２９に通知する（ステップＳ２１）。

なお、ポイント数３５ｂの移転や貸借の場合と同様に、一定の信用力のある顧客同士の間でのポイント数３５ｂの付与を合算部２９が受け付けてもよい。例えば、顧客A、B、Cの各々が有しているポイント数３５ｂを合算部２９が求め、これらの顧客の各々のポイント数３５ｂが一定数以上の場合のみ、合算部２９が付与要求を受け付けてもよい。また、ポイント数３５ｂに代えて、特典を所定の回数だけ得ているかどうかを信用力の目安として採用してもよい。
これらの付与要求を受けた合算部２９は、顧客Cに対して、ポイント数３５ｂの付与に同意するように要求する同意要求を通知する（ステップＳ２２）。

ここで、顧客Cがポイント数３５ｂの付与に同意する場合には、顧客Cが端末４を操作することにより、端末４が合算部２９に許可通知を返す（ステップＳ２３）。なお、顧客Cがポイント数３５ｂの付与を承認しない場合には、顧客Cが端末４を操作することにより、端末４が管理部２８に拒否通知を返し（ステップＳ２４）、処理を終える。
例えば、金銭の支払いを前提にして移転が行われる場合であって、顧客Cが金銭の額について不満があるときに、拒否通知を返すことが想定される。
上記の許可通知を受けた管理部２８は、更新部２６に対し、顧客データベース３５の更新を要求する更新要求を通知する（ステップＳ２５）。

これを受けた更新部２６は、顧客データベース３５を更新する。この例では、更新部２６は、顧客Aのポイント数３５ｂを５ポイントだけ減らすと共に、顧客Bのポイント数３５ｂを１０ポイントだけ減らす。また、更新部２６は、これらのポイント数３５ｂを合算した１５ポイントを顧客Cに付与する。
そして、更新部２６が、データベース３５の更新が完了したことを知らせる更新完了報告を合算部２９に通知する（ステップＳ２７）。

その後に、管理部２８が、顧客A、B、Cのそれぞれの端末４に対し、ポイント数３５ｂの合算が終了したことを知らせる終了報告を通知する（ステップＳ２８〜Ｓ３０）。

このように、複数の顧客が有するポイント数３５ｂを合算して一人の顧客に付与することで、１対１で行われるポイント数３５ｂの移転や貸借と比較して、一人の顧客に付与されるポイント数３５ｂを大きくすることができる。

しかも、本実施形態では、更新部２６と合算部２９の各機能を同一の管理サーバ２内のプロセッサ１０が実行するため、これらの各部を別々の物理マシンに分散させる場合と比較して、各部同士の通信に要する速度を速めることができ、迅速・的確にポイント数３５ｂの合算を行うことができる。

１…顧客管理システム、２…管理サーバ、３…外部サーバ、４…端末、５…ネットワーク、１０…プロセッサ、１１…メモリ、１２…記憶部、１３…NIC、１４…バス、２１…決済部、２２…発行部、２３…送信部、２４…登録部、２５…検出部、２６…更新部、２７…通知部、２８…管理部、２９…合算部、３５…顧客データベース。

Claims (12)

1. メモリと、前記メモリにアクセス可能なプロセッサとを備え、
   前記メモリは、
   複数の顧客と、各々の前記顧客に付与されたポイント数であって特定の対象に対応するポイント数とを対応付けて記憶し、
   前記プロセッサは、
   前記顧客のユーザアカウントを登録し、
   前記特定の対象に対する活動を前記顧客がしたことを検出し、
   前記顧客が前記活動をしたことを検出したときに、前記顧客に対応する前記ポイント数を更新し、
   あらかじめ定められた規則にしたがって、前記顧客の保有する前記ポイント数に応じて、前記特定の対象に関連する特典が得られる所定の顧客を決定し出力する、
   顧客管理システム。
2. 前記所定の顧客が得られる特典は、他の顧客の保有するポイント数に依存して決定される請求項１に記載の顧客管理システム。
3. 前記所定の顧客が得られる特典は、前記顧客の保有するポイント数の金銭的価値に依存して決定される請求項１または２に記載の顧客管理システム。
4. 前記金銭的価値は、前記複数の顧客の間で行われる前記ポイント数の売買における取引価格に基づいて決定される請求項３に記載の顧客管理システム。
5. 前記活動が前記対象を応援する活動である場合には、前記プロセッサは、前記ポイント数を増やし、
   前記活動は、前記ユーザアカウントへの新規登録、前記ユーザアカウントへのログイン、前記対象のファンクラブへの入会、前記ファンクラブの更新、前記対象のオフィシャルサイトへの訪問、前記対象に関連する商品の購入、前記対象に関連するインターネットコンテンツの閲覧、及び前記対象に関する情報の発信のいずれかを含む請求項１乃至請求項４のいずれかに記載の顧客管理システム。
6. 前記プロセッサは、前記活動ごとに前記ポイント数の増分値を変える請求項５に記載の顧客管理システム。
7. 前記活動が、前記対象に対する興味が減退したことにより行われた活動である場合には、前記プロセッサは、前記ポイント数を減じ、
   前記活動は、前記対象のファンクラブからの退会、前記対象に関連する商品の購入のキャンセル、及び前記ユーザアカウントにアクセスしない時間が所定の期間を超えた状況の放置のいずれかを含む請求項１乃至請求項６のいずれかに記載の顧客管理システム。
8. 前記プロセッサは、複数の前記顧客の間での前記ポイント数の移転又は貸借を管理する請求項１乃至請求項７のいずれかに記載の顧客管理システム。
9. 前記プロセッサは、前記ポイント数の移転又は貸借のときに、前記顧客同士を秘匿にしながら、前記顧客同士を連絡可能にする請求項８に記載の顧客管理システム。
10. 前記プロセッサは、複数の前記顧客の間で前記ポイント数を合算し、前記複数の顧客のうちの一人に合算後の前記ポイント数を付与する請求項１乃至請求項９のいずれかに記載の顧客管理システム。
11. 前記プロセッサは、前記顧客が前記特典を得た場合でも、前記ポイント数を減じない請求項１乃至請求項１０のいずれかに記載の顧客管理システム。
12. 顧客のユーザアカウントを登録する登録部と、
    特定の対象に対する活動を前記顧客がしたことを検出する検出部と、
    複数の前記顧客と、各々の前記顧客に付与されたポイント数であって特定の対象に対応するポイント数とを対応付けて記憶する記憶部と、
    前記顧客が前記活動をしたことを前記検出部が検出したときに、前記顧客に対応する前記ポイント数を更新する更新部と、
    あらかじめ定められた規則にしたがって、前記顧客の保有する前記ポイント数に応じて、前記特定の対象に関連する特典が得られる所定の顧客を決定し出力する決定部と、
    を有する顧客管理システム。
    
    
    

Images