(57)【要約】【課題】インターオペラビリティと効率性を高める。【解決手段】統括ポイント処理サーバと、当該統括ポイント処理サーバの配下に位置する少なくとも１つの個別ポイント処理サーバとを備えたポイント処理システムにおいて、個別ポイント処理サーバは、個別ユーザ管理手段と、ポイント処理手段とを備え、統括ポイント処理サーバは、ポイント管理手段と、統括ユーザ管理手段とを備え、配下のいずれかの個別ポイント処理サーバに対し、ユーザが、個別ポイント処理サーバで決められたデータ項目からなる属性情報を供給して会員登録を行うときには、副次的に、統括ポイント処理サーバに対する会員登録も行わせる。【選択図】　図１
2004062494.tif 000002
【特許請求の範囲】
【請求項１】
統括ポイント処理サーバと、当該統括ポイント処理サーバの配下に位置する少なくとも１つの個別ポイント処理サーバとを備えたポイント処理システムにおいて、
前記個別ポイント処理サーバは、
各ユーザに関し、前記ユーザ識別情報を含む所定の属性情報を管理する個別ユーザ管理手段と、
自身の管理範囲の内外で通用する共通ポイント、または自身の管理範囲の内部でのみ通用する個別ポイントに関する処理を各ユーザからの要求に応じて処理するポイント処理手段とを備え、
前記統括ポイント処理サーバは、
前記ポイント処理手段からの通信により、前記共通ポイントまたは個別ポイントの発行および／または消費を、前記ユーザ識別情報を用いて各ユーザごとに管理するポイント管理手段と、
各ユーザに関し、前記ユーザ識別情報を含む所定の属性情報を管理する統括ユーザ管理手段とを備え、
配下のいずれかの個別ポイント処理サーバに対し、前記ユーザが、当該個別ポイント処理サーバで決められたデータ項目からなる前記属性情報を供給して会員登録を行うときには、副次的に、前記統括ポイント処理サーバに対する会員登録も行わせることを特徴とするポイント処理システム。
【請求項２】
請求項１のポイント処理システムにおいて、
前記統括ポイント処理サーバは、
前記統括ポイント処理サーバに対する副次的な会員登録では、前記属性情報のデータ項目を規制せず、配下の個別ポイント処理サーバが設定しているデータ項目をそのまま透過的に受け入れる透過登録手段を備えたことを特徴とするポイント処理システム。
【請求項３】
請求項１のポイント処理システムにおいて、
予め、配下の全個別ポイント処理サーバが前記属性情報に設定しているデータ項目の集合を認識しておき、前記統括ポイント処理サーバに対する副次的な会員登録では、前記属性情報のデータ項目として、当該集合中のすべてのデータ項目の充足を要求する非透過登録手段を備えたことを特徴とするポイント処理システム。
【請求項４】
請求項２または３のいずれかのポイント処理システムにおいて、
前記データ項目の名称を、配下の全個別ポイント処理サーバのあいだで共通化しておくことを特徴とするポイント処理システム。
【請求項５】
統括ポイント処理サーバと、当該統括ポイント処理サーバの配下に位置する少なくとも１つの個別ポイント処理サーバとを備えたポイント処理システムの構成要素としての個別ポイント処理サーバにおいて、
各ユーザに関し、前記ユーザ識別情報を含む所定の属性情報を管理する個別ユーザ管理手段と、
自身の管理範囲の内外で通用する共通ポイント、または自身の管理範囲の内部でのみ通用する個別ポイントに関する処理を各ユーザからの要求に応じて処理するポイント処理手段とを備え、
配下のいずれかの個別ポイント処理サーバに対し、前記ユーザが、当該個別ポイント処理サーバで決められたデータ項目からなる前記属性情報を供給して会員登録を行うときには、副次的に、前記統括ポイント処理サーバに対する会員登録も行わせることを特徴とする個別ポイント処理サーバ。
【請求項６】
統括ポイント処理サーバと、当該統括ポイント処理サーバの配下に位置する少なくとも１つの個別ポイント処理サーバとを備えたポイント処理システムの構成要素としての統括ポイント処理サーバにおいて、
前記個別ポイント処理サーバが、自身の管理範囲の内外で通用する共通ポイント、または自身の管理範囲の内部でのみ通用する個別ポイントに関する処理を各ユーザからの要求に応じて処理するために備えるポイント処理手段からの通信により、前記共通ポイントまたは個別ポイントの発行および／または消費を、前記ユーザ識別情報を用いて各ユーザごとに管理するポイント管理手段と、
各ユーザに関し、前記ユーザ識別情報を含む所定の属性情報を管理する統括ユーザ管理手段とを備え、
配下のいずれかの個別ポイント処理サーバに対し、前記ユーザが、前記個別ポイント処理サーバで決められたデータ項目からなる前記属性情報を供給して会員登録を行うときには、副次的に、前記統括ポイント処理サーバに対する会員登録も行わせることを特徴とする統括ポイント処理サーバ。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はポイント処理システムに関し、例えば、各企業が販売促進などのために発行するポイントを共通化してポイントの利用を促進する場合などに適用して好適なものである。
【０００２】
また、本発明は、かかるポイント処理システムの構成要素としての個別ポイント処理サーバに関するものである。
【０００３】
さらに、本発明は、かかるポイント処理システムの構成要素としての統括ポイント処理サーバに関するものである。
【０００４】
【従来の技術】
近年、ポイント処理システムとして、カード事業者がクレジットカードの利用金額に応じて発行するものや、旅客航空事業者が利用マイルに応じてポイントを発行するものや、家電販売事業者が各店舗での購入金額に応じてポイントを発行するものなど、様々な形態のシステムがある。
【０００５】
従来のこのようなポイント処理システムの多くは、ポイントを発行した事業者がポイントに応じた利益をカードまたはシール等の形態で発行し、その利益を消費させて、顧客にポイントに応じた利益を還元するのが一般的である。
【０００６】
しかしながら、企業毎又はポイント専門の事業者単位でポイントシステムの管理運営を行っているため、各事業者のポイントのあいだでは単位ポイント（例えば、１ポイント）の金銭的な価値が相違するなど、そのままでは事業者間でポイント値を交換することができない。
【０００７】
このような不都合を解決するため、ポイントを、共通ポイントや他のシステムのポイントに交換することも既に提案されている（例えば、特開２００１−２５０１７０、特開２００２−２４７２４）。
【０００８】
【発明が解決しようとする課題】
ところが、前記共通ポイントなどを利用して異なる事業者のあいだでポイント値の交換を行う場合、交換のために通信料金が発生したりシステムの処理能力を消費したりするから、その交換を効率的に行うことが重要になる。
【０００９】
また、各事業者は、各ユーザのポイント値を管理するため、会員登録の際などに、そのユーザを識別するための情報（ユーザ識別子）や、顧客管理上、価値の高いそのユーザに関する個人情報を収集するのが普通である。ユーザ識別子や個人情報として具体的にどのような情報を収集するかは、事業者ごとに相違することが多いため、このような情報の取り扱いで矛盾が生じないようにインターオペラビリティ（相互運用性）が高め、なおかつ、効率的に行う必要がある。
【００１０】
【課題を解決するための手段】
かかる課題を解決するために、第１の発明では、　統括ポイント処理サーバと、当該統括ポイント処理サーバの配下に位置する少なくとも１つの個別ポイント処理サーバとを備えたポイント処理システムにおいて、前記個別ポイント処理サーバは、（１）各ユーザに関し、前記ユーザ識別情報を含む所定の属性情報を管理する個別ユーザ管理手段と、（２）自身の管理範囲の内外で通用する共通ポイント、または自身の管理範囲の内部でのみ通用する個別ポイントに関する処理を各ユーザからの要求に応じて処理するポイント処理手段とを備え、前記統括ポイント処理サーバは、（３）前記ポイント処理手段からの通信により、前記共通ポイントまたは個別ポイントの発行および／または消費を、前記ユーザ識別情報を用いて各ユーザごとに管理するポイント管理手段と、（４）各ユーザに関し、前記ユーザ識別情報を含む所定の属性情報を管理する統括ユーザ管理手段とを備え、（５）配下のいずれかの個別ポイント処理サーバに対し、前記ユーザが、当該個別ポイント処理サーバで決められたデータ項目からなる前記属性情報を供給して会員登録を行うときには、副次的に、前記統括ポイント処理サーバに対する会員登録も行わせることを特徴とする。
【００１１】
また、第２の発明では、統括ポイント処理サーバと、当該統括ポイント処理サーバの配下に位置する少なくとも１つの個別ポイント処理サーバとを備えたポイント処理システムの構成要素としての個別ポイント処理サーバにおいて、（１）各ユーザに関し、前記ユーザ識別情報を含む所定の属性情報を管理する個別ユーザ管理手段と、（２）自身の管理範囲の内外で通用する共通ポイント、または自身の管理範囲の内部でのみ通用する個別ポイントに関する処理を各ユーザからの要求に応じて処理するポイント処理手段とを備え、（３）配下のいずれかの個別ポイント処理サーバに対し、前記ユーザが、当該個別ポイント処理サーバで決められたデータ項目からなる前記属性情報を供給して会員登録を行うときには、副次的に、前記統括ポイント処理サーバに対する会員登録も行わせることを特徴とする。
【００１２】
さらに、第３の発明では、統括ポイント処理サーバと、当該統括ポイント処理サーバの配下に位置する少なくとも１つの個別ポイント処理サーバとを備えたポイント処理システムの構成要素としての統括ポイント処理サーバにおいて、（１）前記個別ポイント処理サーバが、自身の管理範囲の内外で通用する共通ポイント、または自身の管理範囲の内部でのみ通用する個別ポイントに関する処理を各ユーザからの要求に応じて処理するために備えるポイント処理手段からの通信により、前記共通ポイントまたは個別ポイントの発行および／または消費を、前記ユーザ識別情報を用いて各ユーザごとに管理するポイント管理手段と、（２）各ユーザに関し、前記ユーザ識別情報を含む所定の属性情報を管理する統括ユーザ管理手段とを備え、（３）配下のいずれかの個別ポイント処理サーバに対し、前記ユーザが、前記個別ポイント処理サーバで決められたデータ項目からなる前記属性情報を供給して会員登録を行うときには、副次的に、前記統括ポイント処理サーバに対する会員登録も行わせることを特徴とする。
【００１３】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかるポイント処理システム、個別ポイント処理サーバおよび統括ポイント処理サーバの実施形態について説明する。
【００１４】
ポイントは、その値が大きいほどユーザにとって有益となる指標で、例えば、パチンコ遊技場（遊技場の事業者）などにおいては、遊技者（ユーザ）が遊技で獲得した賞球などをポイントに交換（事業者の側からみればポイントの発行）すれば、蓄積しているその遊技者のポイントの値は増大し、蓄積しているポイント値の一部を、遊技を行うために球などに交換すれば蓄積しているポイント値は減少する（ポイントの消費）。遊技に負けて球を失うことがつづけばポイント値は減少する一方であるが、遊技に勝って多くの球を獲得すればその球をポイントに交換することによって大きなポイント値の蓄積が可能となる。ポイント値は、その一部または全部をその値に応じた価格の景品と交換して消費することができる。
【００１５】
ここでは、あるパチンコ遊技場の内部におけるポイントに関する処理（発行、消費）を示したが、上述した共通ポイントを利用すれば、あるパチンコ遊技場で発行を受けたポイントを、異なるパチンコ遊技場や、前記カード事業者、旅客航空事業者、家電販売事業者など多種多様な事業を行う事業者の店舗で消費することが可能になる。
【００１６】
（Ａ−１）実施形態の構成
本実施形態の通信システム１０の全体構成例を図１に示す。
【００１７】
図１において、当該通信システム１０は、ネットワーク１１と、統括ポイントサーバ１２と、３つの個別ポイントサーバ１３〜１５と、３つの企業側ネットワーク１６〜１８と、店舗端末１９〜２１とを備えている。
【００１８】
このうちネットワーク１１は専用線やＬＡＮ（ローカルエリアネットワーク）などであってもかまわないが、ここでは、インターネットであるものとする。
【００１９】
各個別ポイントサーバ１３〜１５は、異なる事業者（企業）の企業側ネットワーク１６〜１８と通信システム１０とのインタフェースとなる機器である。したがって個別ポイントサーバ１３は企業ＥＰ１が運用し、個別ポイントサーバ１４は企業ＥＰ２が運用し、個別ポイントサーバ１５は企業ＥＰ３が運用している。
【００２０】
この企業ＥＰ１〜ＥＰ３のそれぞれに、例えば、前記旅客航空事業者、家電販売事業者、遊技場事業者などが該当する。
【００２１】
図示の状態では、通信システム１０内に３つの個別ポイントサーバ１３〜１５が存在するが、個別ポイントサーバの数は、３つより少なくてもよく、多くてもかまわないことは当然である。
【００２２】
各個別ポイントサーバ１３〜１５はインタフェースにすぎないから、インタフェースの内側、すなわち、各企業の内部においてどのような企業側ネットワーク１６〜１８を構築するかは各企業の自由である。ただ１つの店舗（拠点）だけしか持たず企業側ネットワークがその店舗内だけで完結している企業があってもよいし、全国に多数の店舗（拠点）を持ち、各拠点を企業側ネットワークで接続する企業があってもよい。ただし各企業側ネットワーク１６〜１８には少なくとも１つ以上の拠点が含まれ、各拠点には少なくとも１つ以上の店舗端末１９〜２１が含まれている。インタフェースである個別ポイントサーバも、各企業側ネットワークの構成要素とみることができる。
【００２３】
店舗端末１９〜２１は各企業側ネットワーク１６〜１８の構成要素となる通信端末で、例えば、パーソナルコンピュータなどのようにネットワーク機能、ディスプレイ装置、入出力装置などを備えた情報処理装置である。当該店舗端末１９〜２１は、各ユーザによって、各ユーザが各企業ＥＰ１〜ＥＰ３に会員登録したり、個人情報（例えば、ポイント値など）に変更が生じた場合などに操作される（必要に応じて、店員（図示せず）などに操作させてもよい）。
【００２４】
もちろん、店舗端末１９は企業ＥＰ１のための企業側ネットワーク１６に設けられているから、企業ＥＰ１にユーザが会員登録するときや、企業ＥＰ１における顧客管理システム上、ユーザの個人情報（ポイント値も含む）に変更が生じたとき等に使用される。同様に、店舗端末２０は、企業ＥＰ２にユーザが会員登録するときや、企業ＥＰ２における顧客管理システム上、ユーザの個人情報に変更が生じたとき等に使用され、店舗端末２１は、企業ＥＰ３にユーザが会員登録するときや、企業ＥＰ３における顧客管理システム上、ユーザの個人情報に変更が生じたとき等に使用される。
【００２５】
ただし各企業ＥＰ１〜ＥＰ３は、通信システム１０に参加しているから、自身に会員登録していないユーザによって、ポイント（共通ポイント）を消費されることがあり、そのようなユーザも、各店舗端末（例えば、１９）を利用する。このユーザは、通信システム１０内の企業ＥＰ１〜ＥＰ３のうち少なくとも１つの企業に会員登録し、統括ポイントサーバ１２に会員登録したユーザである。
【００２６】
企業側ネットワーク１６〜１８は基本的にその企業の内部だけで使用されるネットワークであるが、必ずしも、物理的に小さいネットワークであることを意味しない。全国各地に分散した拠点を接続したり、世界各国に分散した拠点を接続する企業側ネットワークもあり得る。
【００２７】
したがって個別ポイントサーバ１３〜１５は、各企業側ネットワーク１６〜１８の構成に応じて、企業側ネットワーク内の各拠点（各拠点に配置される店舗端末を含む）と通信し得るが、企業側ネットワーク１６〜１８の外部では、統括ポイントサーバ１２だけと通信する。すなわち、個別ポイントサーバ相互間（例えば、個別ポイントサーバ１３と１４のあいだ等）で通信を行うことはない。本実施形態はこれによって効率の向上をはかるものである。
【００２８】
なお、各企業ＥＰ１〜ＥＰ３間に取引きがある場合などには、ＢｔｏＢのＥＣサイトの運用など各企業側ネットワーク１６〜１８を利用して各企業が通信（例えば、ＥＰ１とＥＰ２が通信）することはあってよいが、その通信は通信システム１０とは無関係な任意の２企業間の問題である。
【００２９】
個別ポイントサーバ１３〜１５が統括ポイントサーバ１２だけと通信することから、通信システム１０の論理構造は、統括ポイントサーバ１２を唯一の親（根）とし、３つの個別ポイントサーバ１３〜１５を子（節あるいは葉）とする階層構造（木構造）とみることができる。
【００３０】
個別ポイントサーバ１３〜１５の内部構成例を図３に示す。個別ポイントサーバ１３〜１５の内部構成はすべて同じであってよいが、以下では、図３には主として個別ポイントサーバ１３を示したものとして説明を進める。
【００３１】
（Ａ−１−１）個別ポイントサーバの内部構成例
図３において、当該個別ポイントサーバ１３は、通信部３０と、制御部３１と、透過登録要求部３２と、ユーザ管理データベース３３とを備えている。
【００３２】
このうち通信部３０は、企業ＥＰ１の企業側ネットワークに属する各拠点と通信するほか、前記統括ポイントサーバ１２と通信する部分である。統括ポイントサーバ１２との通信のセキュリティ性を高めるためには、当該通信部３０にＶＰＮ機能を搭載して統括ポイントサーバ１２とのあいだでインターネットＶＰＮによる通信を行うようにしてもよい。
【００３３】
ネットワーク１１としてインターネットを利用すると、セキュリティ性が低い点や、通信品質の保証がない等の不利があるが、専用線などを用いる場合に比べて通信費用が格段に安いことや、全国各地、あるいは世界各国にアクセスポイントを得ることが容易である等の利点がある。
【００３４】
前記制御部３１はハードウエア的には当該個別ポイントサーバ１３のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）やＤＢＭＳ（データベース管理システム）等に相当する部分である。
【００３５】
ユーザ管理データベース３３は、当該個別ポイントサーバ１３に対応する企業ＥＰ１が、自身の顧客であるユーザを管理するデータベースで、例えば、図５に示すユーザ管理用のテーブルＴＥ１を含んでいる。当該ユーザ管理テーブルＴＥ１は、企業ＥＰ１の顧客管理システムの中核をなす構成要素である。
【００３６】
システム構築の順番が、通信システム１０のほうが企業ＥＰ１の企業側ネットワークよりも早い場合には、その企業側ネットワークで使用する顧客管理システム（ユーザ管理データベース３３の構成（テーブルＴＥ１のスキーマ）も含む）を通信システム１０に合わせて構築することも可能であるが、一般的にはそうではなく、通信システム１０が実際に構築されたときには、すでに企業ＥＰ１などの各企業が各自の企業側ネットワークを構築、運用し、顧客管理システムもすでに構築され稼働していることが多い。
【００３７】
したがって、本実施形態でも、通信システム１０のほうが企業ＥＰ１などの企業側ネットワークよりも後から構築された場合を想定する。この場合、通信システム１０は、企業側ネットワークごとに異なる顧客管理システムを統合する必要が生じる。
【００３８】
反対に、このような統合を行うことによってはじめて、各企業はそれまで使用してきた顧客管理システムの変更や再構築をほとんど行うことなく（共通ポイントへの対応がほとんど唯一の変更点となる）、通信システム１０に接続することが可能になる。
【００３９】
したがって例えば、図５に示すユーザ管理テーブルＴＥ１としては、個別ポイントサーバ１３を設けて通信システム１０に接続する以前から、企業ＥＰ１の企業側ネットワーク内において顧客管理のために利用されてきたテーブルをそのまま用いることができる。
【００４０】
一般的にポイントの管理を行う各企業は、企業側ネットワークの内部において、各ユーザのポイント値を管理するため、会員登録の際などに、前記ユーザ識別子や、顧客管理上、価値の高い各ユーザに関する個人情報などのデータ項目に関する情報を収集するのが普通である。収集された個人情報は、前記ポイント値などとともに、顧客管理情報として利用される。
【００４１】
企業ＥＰ１の場合、図５に示すように、ユーザ管理テーブルＴＥ１のデータ項目として、「ユーザＩＤ」、「パスワード」、「電子メール」、「氏名」、「来店回数」、「ポイント値」を設けている。
【００４２】
このうち「ユーザＩＤ」は、企業ＥＰ１が自身の企業側ネットワーク１６の内部において各ユーザを識別するために付与する識別情報で、「パスワード」はユーザ認証を行う際にユーザに入力させる情報である。企業ＥＰ１の場合、何らかのユーザ認証を実施しているために当該「パスワード」が必要になっているが、ユーザ認証を行わない企業（例えば、ＥＰ２，ＥＰ３）の場合には「パスワード」に相当するデータ項目を設ける必要はない。
【００４３】
また、前記「電子メール」はユーザの電子メールアドレスを示す情報で、企業ＥＰ１から各ユーザに通知や広告の配信を行う場合などに利用できる。当該「電子メール」はまた、ＩＭＡＰ４などの共有メールボックスを指定する電子メールアドレスなどを除き、原則として、企業側ネットワーク１６の外部でも通用し完全な識別性（一意性）を有するユーザ識別子として活用することができる。
【００４４】
「氏名」は各ユーザの氏名を示す情報である。一意性が保証されておらず識別性が必ずしも十分ではないため単独ではユーザ識別子として用いることは困難な場合も多いが、人間にとって可読で分かりやすい情報であるから、この「氏名」は、企業側ネットワーク１６の外部でも通用する簡便なユーザ識別子として利用可能である。
【００４５】
「来店回数」はユーザが企業ＥＰ１の企業側ネットワーク１６内のいずれかの店舗に訪れた回数の累計値を示す情報であり、「ポイント値」は、各ユーザの現時点における上述したポイントの値を示す情報である。
【００４６】
ユーザ識別子や個人情報として具体的にどのような情報（データ項目）を収集するかは、企業ごとに、実質的に同じ部分と実質的に異なる部分がある。
【００４７】
例えば、前記「氏名」などのデータ項目は、ユーザ識別子として使用するか否かにかかわらず、いずれの企業でも収集している可能性が高いが、パチンコ機などを用いた過去の遊技でユーザが出した大当たりの累計回数を示す「大当たり回数」などのデータ項目は、遊技場を運営する企業などに特有なデータ項目であり、カード事業者や、旅客航空事業者などがデータ項目として「大当たり回数」を管理している可能性は低い。
【００４８】
一例として、図７に示すユーザ管理テーブルＴＥ３には、データ項目として当該「大当たり回数」が設けられている。これは、前記個別ポイントサーバ１５を運営する企業ＥＰ３が遊技場事業者であるためである。
【００４９】
また、ユーザの「氏名」に関するデータ項目を各企業ＥＰ１〜ＥＰ３が管理しているとしても、各企業のユーザ管理データベース（ユーザ管理テーブル）ＴＥ１〜ＴＥ３のなかで、当該「氏名」に相当するデータ項目にどのような名称を付与しているかは企業ごとに相違することも多い。例えば、企業ＥＰ２に対応する図６のユーザ管理テーブルＴＥ２ではデータ項目「なまえ」が、この「氏名」に相当し、企業ＥＰ３に対応する図７のユーザ管理テーブルＴＥ３ではデータ項目「姓名」がこの「氏名」に相当する。
【００５０】
同様のデータ項目名称の相違が、テーブルＴＥ１、ＴＥ２の「ユーザＩＤ」と、テーブルＴＥ３の「ＩＤ」のあいだにも存在し、テーブルＴＥ１の「電子メール」とテーブルＴＥ２の「メール」とテーブルＴＥ３の「ｅメールアドレス」のあいだにも存在し、テーブルＴＥ１の「ポイント値」とテーブルＴＥ２の「ポイント数」とテーブルＴＥ３の「ポイント」のあいだにも存在する。
【００５１】
このように、データ項目の意味する実質的な内容は同じであってもデータ項目名称の表記が相違する場合、そのまま放置すると、上述した統合を正常に行うことができず矛盾が生じる。この矛盾は、後述するように統括ポイントサーバ１２が項目名対応テーブルＴＢ１（図８参照）を用いて解消する。
【００５２】
図３に示す透過登録要求部３２は、ユーザ（ここでは、Ｕ１とする）がいずれかの拠点から個別ポイントサーバ１３に対応する顧客管理システムに会員登録するとき、そのユーザＵ１に関する個人情報をユーザ管理データベース３３内のユーザ管理テーブルＴＥ１に登録（格納）するとともに、統括ポイントサーバ１２内のユーザ管理データベース４５にも登録する部分である。
【００５３】
このとき本実施形態では、前記店舗端末１９を操作するユーザＵ１に対し、企業ＥＰ１が図５に示すユーザ管理テーブルＴＥ１にすでに設けている以外のデータ項目の入力（あるいは提供）を要求しないものとする。
【００５４】
本実施形態では、この企業ＥＰ１に対する会員登録に際してユーザＵ１が入力（あるいは提供）するデータ項目の数は、一般的に、通信システム１０内の他の企業ＥＰ２またはＥＰ３にユーザＵ１がすでに会員登録している場合には少なく、いずれの企業にも会員登録していない場合には多くなる。通信システム１０内の他の企業ＥＰ２またはＥＰ３にユーザＵ１がすでに会員登録している場合にユーザＵ１自身が入力するデータ項目の数を少なくできるのは、すでに統括ポイントサーバ１２に蓄積されているユーザＵ１の個人情報を、企業ＥＰ１への会員登録にも、自動的に再利用するからである。
【００５５】
一方、前記統括ポイントサーバ１２の内部構成例は、図２に示す通りである。
【００５６】
（Ａ−１−２）統括ポイントサーバの内部構成例
図２において、当該統括ポイントサーバ１２は、通信部４０と、制御部４１と、透過登録対応部４２と、項目名管理部４３と、企業管理データベース４４と、ユーザ管理データベース４５とを備えている。
【００５７】
このうち通信部４０は、インターネット１１を介して前記個別ポイントサーバ１６の通信部３０と対向する部分で、必要に応じて、前記ＶＰＮ機能を有する。
【００５８】
制御部４１はハードウエア的には当該統括ポイントサーバ１２のＣＰＵに相当し、ソフトウエア的にはＯＳやＤＢＭＳ等に相当する部分である。
【００５９】
透過登録対応部４２は、前記個別ポイントサーバ１３内の透過登録要求部３２からの要求に対応して、透過登録を行う部分である。
【００６０】
透過登録とは、通信システム１０内の他の企業（例えば、ＥＰ２，ＥＰ３）の顧客管理システムがどのようなデータ項目を備えているかに依存せず、ユーザがいま会員登録を行おうとしている企業（ここでは、ＥＰ１）の顧客管理システムのデータ項目だけをユーザＵ１に入力させ、そのデータ項目によって企業ＥＰ１だけでなく、統括ポイントサーバ１２に対する会員登録をも行うことを指す。
【００６１】
この透過登録により、上述した企業ＥＰ１の顧客管理システムに対する会員登録に際してユーザＵ１が入力（あるいは提供）する必要のある情報は、多い場合でも、図５に示す、ユーザＩＤと、パスワードと、電子メールアドレスと、氏名と、来店回数と、ポイント値に関する情報だけとなる。このうちユーザＩＤ、パスワード、来店回数、ポイント値は、システム側が自動的に入力（生成）するようにしてもよい（特に、ポイント値などは通常、ユーザに入力させることはできない）から、ユーザＵ１の入力が必須となるのは、電子メールアドレスと氏名だけである。もちろんシステム側が自動的に生成した場合、ユーザＩＤやパスワードなどは、その内容を、ユーザＵ１に通知しておく必要がある。
【００６２】
当該透過登録によれば、ユーザＵ１は、例えば、図６の自宅電話番号や、図７の電話番号などの個人情報の入力を省略することができる。
【００６３】
また、上述した再利用により、すでに統括ポイントサーバ１２にユーザＵ１の個人情報が蓄積されている場合には、企業ＥＰ１への会員登録では、ユーザＵ１は氏名の入力も省略することが可能である。
【００６４】
ユーザＵ１が自身の電子メールアドレスを店舗端末１９に入力すれば、当該電子メールアドレスをもとに個別ポイントサーバ１３が統括ポイントサーバ１２へ、当該ユーザＵ１の個人情報が後述するユーザ管理テーブルＴＢ３にすでに蓄積されているか否かの問い合わせを行い、蓄積されている旨の問い合わせ結果がその氏名の値などとともに返ってきた場合には、その氏名の値を再利用して、前記ユーザ管理テーブルＴＥ１に対するユーザＵ１の登録を行うことができるからである。
【００６５】
この再利用に際しては、例えば、店舗端末１９のディスプレイ装置に「あなたは山田太郎　様ですね」などと画面表示して、ユーザＵ１に氏名の値の正確さを確認してもらうようにしてもよい。
【００６６】
図５〜図７の例では、再利用できるのは氏名の値だけであるが、各ユーザ管理テーブルＴＥ１〜ＴＥ３の備えるデータ項目によっては、複数のデータ項目の値を再利用できる可能性も高い。
【００６７】
また、企業ＥＰ１に会員登録する際、統括ポイントサーバ１２に対する会員登録まで行うか否かの意思確認を店舗端末１９を用いてユーザＵ１に行い、ユーザＵ１の意思によっては統括ポイントサーバ１２に対する会員登録は行わず、企業ＥＰ１に対する会員登録だけを行うことができるようにしてもよいが、ここでは、説明の簡単のために、ユーザＵ１が企業ＥＰ１に会員登録する際には、強制的に統括ポイントサーバ１２に対する会員登録も行い、当該ユーザＵ１の個人情報は統括ポイントサーバ１２のユーザ管理データベース４５にも格納されるものとする。
【００６８】
企業ＥＰ２，ＥＰ３に対する会員登録でもこれと同様であるから、通信システム１０内のいずれかの企業（例えば、ＥＰ１）の会員であるということは直ちに、統括ポイントサーバ１２の会員であることを意味し、そのユーザ（ここでは、Ｕ１）の個人情報は統括ポイントサーバ１２にも蓄積されている。
【００６９】
これにより上述したように、すでに統括ポイントサーバ１２に蓄積されているユーザＵ１の個人情報を、企業ＥＰ１への会員登録にも自動的に再利用することが可能となる。
【００７０】
なお、ポイントに関しては、各企業側ネットワーク（例えば、１６）の内部でのみ有効な個別ポイントと、通信システム１０に参加している全企業ＥＰ１〜ＥＰ３の企業側ネットワーク１６〜１８で有効な共通ポイントがあり得、通信システム１２内に個別ポイントと共通ポイントを併存させることも可能であるが、本実施形態では、説明の簡単のためにすべてのポイントは共通ポイントとして管理するものとする。
【００７１】
各個別ポイントは通常、単位ポイント（例えば、１ポイント）の金銭的な価値が、共通ポイントと異なるため、ある企業が通信システム１０に参加したときには、それまで個別ポイントとして蓄積されている各ユーザの全ポイント値を、所定の演算式に応じて共通ポイントに変換する必要がある。
【００７２】
例えば、企業側ネットワーク１６内では１ポイントが１００円の価値を持つ個別ポイントが用いられており、共通ポイントでは１ポイントが１０円の価値である場合には、参加の時点で、あるユーザの当該個別ポイントが１５０ポイントであるものとすると、当該１５０ポイントは、共通ポイントの１５００ポイントに変換される。
【００７３】
項目名管理部４３は、各企業ＥＰ１〜ＥＰ３の顧客管理システム間における上述したデータ項目名称の相違を吸収するための部分である。当該項目名管理部４３の機能によって、例えば、上述したテーブルＴＥ１の「電子メール」とテーブルＴＥ２の「メール」とテーブルＴＥ３の「ｅメールアドレス」のあいだの相違が吸収され、すべて同じ「電子メールアドレス」として取り扱われる。
【００７４】
このような機能を提供するため、当該項目名管理部４３は、図８に示す項目名対応テーブルＴＢ１を利用する。この項目名対応テーブルＴＢ１は、統括ポイントサーバ１２内のユーザ管理データベース４５に格納されている。
【００７５】
図８において、当該項目名対応テーブルＴＢ１のデータ項目である「ユーザＩＤ」、「パスワード」、「電子メールアドレス」、「氏名」、「自宅電話番号」、「勤務先電話番号」、「来店回数」、「購入金額総計」、「大当たり回数」、「ポイント値」のそれぞれが、通信システム１０内における標準的なデータ項目名称である。
【００７６】
例えば、電子メールアドレスに関しては、企業ＥＰ１では「電子メール」と表記し、企業ＥＰ２では「メール」と表記し、企業ＥＰ３では「ｅメールアドレス」と表記しているが、項目名対応テーブルＴＢ１は、その標準的な表記が「電子メールアドレス」であることを示している。
【００７７】
データ項目の名称だけからでは、その意味が必ずしも明確でない場合もあるため、この項目名対応テーブルＴＢ１に各値を登録する際には、データ項目の意味を特定するために十分な情報を各企業ＥＰ１〜ＥＰ３側から得ておく必要がある。
【００７８】
例えば、図７の「電話番号」は、その名称だけでは、自宅の電話番号なのか、勤務先の電話番号なのか、携帯電話機の電話番号なのか等が不明である。いずれの電話番号でもかまわない場合にもその旨の情報を得ておく必要がある。図８の例では、この「電話番号」を勤務先の電話番号として登録している。
【００７９】
このような標準的なデータ項目名称の表記は、統括ポイントサーバ１２内でのみ使用され、統括ポイントサーバ１２からいずれかの個別ポイントサーバに送信するときには、送信先の個別ポイントサーバ側の表記にもどして送信する。このような送信は、統括ポイントサーバ１２が、個別ポイントサーバ１３〜１５からの問い合わせに応える際に発生する。
【００８０】
通信システム１０を長期間、運用していると、新たな企業が通信システム１０に参加したり、これまで参加していた企業が離脱したり、これまで参加していた企業が、その企業内部の都合により、顧客管理システムを変更したりすることが起こり得るが、これらのケースでは、項目名対応テーブルＴＢ１を変更する必要が生じる。
【００８１】
例えば、新たな企業が通信システム１０に参加してインターネット１１経由で統括ポイントサーバ１２に接続するようになった場合には、その企業の顧客管理システムに応じたタプル（行）が、図８に示す項目名対応テーブルＴＢ１に追加される。また、その企業の顧客管理システムが、これまで登録していた企業ＥＰ１〜ＥＰ３のいずれの顧客管理システムのデータ項目とも実質的に相違するデータ項目を有する場合などには、そのデータ項目に合わせたデータ項目（列名）を、当該項目名対応テーブルＴＢ１に追加することが望ましい。
【００８２】
同様に、これまで参加していた企業（例えば、ＥＰ２）が離脱した場合には、項目名対応テーブルＴＢ１から当該企業ＥＰ２の行を削除し、これまで参加していた企業（例えば、ＥＰ３）が、その企業内部の都合により、顧客管理システムを変更した場合には、その変更の内容に合わせて項目名対応テーブルＴＢ１上の当該企業ＥＰ３の行の該当するデータ項目の値を変更すること等が必要になる。
【００８３】
各企業は、自身の顧客管理システム中のデータ項目のうち必ずしもすべてのデータ項目を統括ポイントサーバ１２に開示する必要はないが、ユーザ識別子として利用可能なデータ項目は開示することが望ましい。予めどのようなデータ項目を開示する必要があるかは、通信システム１０に各企業が参加する際の契約によって定めておくようにしてもよい。
【００８４】
例えば、前記「来店回数」、「購入金額総計」、「大当たり回数」などのデータ項目は伝える必要性が低いが、前記「ユーザＩＤ」に相当するデータ項目、「電子メールアドレス」に相当するデータ項目、「氏名」に相当するデータ項目などは伝える必要性が高い。
【００８５】
なお、前記「電子メールアドレス」に相当するデータ項目は、図８中のその他の識別子（例えば、ユーザＩＤや、氏名など）と異なり、企業側ネットワーク１６の外部でも通用し完全な識別性を有するユーザ識別子で、本実施形態においても特別な意味を持つから、もしも各企業の顧客管理システムがユーザの電子メールアドレスをデータベースのデータ項目として管理していない場合には、通信システム１０に参加するにあたって、データ項目として当該電子メールアドレス（データ項目名称の表記は各企業の自由）を追加する必要がある。
【００８６】
もっとも、電子メールの普及率の高さ等を反映し、多くの企業の顧客管理システムでは、すでに電子メールアドレスをデータ項目として備えているものと考えられる。
【００８７】
また、電子メールアドレスとともに、または電子メールアドレスに置き換えて、ユーザが携帯する携帯通信端末（例えば、携帯電話機など）の識別子である端末ＩＤを利用することもできる。
【００８８】
携帯通信端末が近距離無線通信機能（赤外線通信や電波などを利用する通信機能）や着脱可能なコネクタを持つケーブルを利用する有線通信機能により、当該端末ＩＤを送信する機能を装備している場合には、前記店舗端末（例えば、１９）にも対応する近距離無線通信機能やコネクタ等を搭載することで、自動的に、端末ＩＤを伝えることも可能となり、ユーザの操作負担を軽減できる。
【００８９】
ただし端末ＩＤを利用する場合、ユーザが携帯通信端末を携帯しており、なおかつ当該携帯通信端末が近距離無線通信機能や有線通信機能などにより端末ＩＤを送信する機能を搭載していることが条件となるから、この条件を満たさないユーザはこの方法を利用できず、カバーできるユーザの範囲は、電子メールアドレスのほうが広い。
【００９０】
もちろん、電子メールアドレスとともに端末ＩＤにも対応し、ユーザの都合に応じて、いずれを選択することも可能とすれば、カバーできるユーザの範囲をいっそう拡大することができる。
【００９１】
なお、携帯電話機などの場合、近距離無線通信機能や有線通信機能などにより端末ＩＤを送信する機能は、アプレットを利用して、製造後に追加することも可能である。
【００９２】
図２に示す企業管理データベース４４は、統括ポイントサーバ１２が、通信システム１０に参加している各企業ＥＰ１〜ＥＰ３を管理するための企業管理テーブルＴＢ２を備えたデータベースである。
【００９３】
企業管理テーブルＴＢ２では、例えば、図９に示すように、通信システム１０内において統括ポイントサーバ１２が各企業ＥＰ１〜ＥＰ３を一義的に識別するために割り当てた企業ＩＤであるＩＥＰ１〜ＩＥＰ３に対応づけて、各企業ＥＰ１〜ＥＰ３を管理する。ここで、ＩＥＰ１は、企業ＥＰ１の企業ＩＤであり、ＩＥＰ２は、企業ＥＰ２の企業ＩＤであり、ＩＥＰ３は、企業ＥＰ３の企業ＩＤである。
【００９４】
図９の例では、当該「企業ＩＤ」のほかのデータ項目として、「料金精算状況」が設けられている。
【００９５】
「料金精算状況」には、共通ポイントの消費に関連する各企業ＥＰ１〜ＥＰ３のあいだの料金の精算状況を示す情報が記述される。
【００９６】
各ポイント（共通ポイント）は発行元の各企業がユーザに対して金銭や商品などを提供する義務のある債務のようなものであるから、発行元の企業（例えば、ＥＰ１）とは異なる企業（例えば、ＥＰ３）でユーザがその共通ポイントを商品などと交換して消費すると、本来の債務者とは異なる者がその債務を弁済をしたことに等しいから、当該商品の分に相当する金銭を、発行元の企業ＥＰ１が消費先の企業ＥＰ３に対して支払って、精算する必要が生じる。料金の精算状況とは、このような精算に関する状況である。
【００９７】
料金の精算は、一定の周期（例えば、１週間ごとに）で定期的に行うものであってよい。
【００９８】
統括ポイントサーバ１２が備えたユーザ管理データベース４５は、前記項目名対応テーブルＴＢ１と、図１０に示すユーザ管理テーブルＴＢ３を格納しているデータベースである。
【００９９】
当該ユーザ管理テーブルＴＢ３は、統括ポイントサーバ１２に対する会員登録を行ったユーザに関する個人情報を管理するためのテーブルである。当該ユーザ管理テーブルＴＢ３は、各個別ポイントサーバ１３〜１５が備えるユーザ管理テーブル（例えば、ＴＥ１）に対応するテーブルである。
【０１００】
本実施形態では、ユーザ（例えば、Ｕ１）が通信システム１０に参加しているいずれかの企業（例えば、ＥＰ１）に会員登録する際には、強制的に統括ポイントサーバ１２に対する会員登録も行うものとしたため、企業ＥＰ１〜ＥＰ３のいずれかに会員登録し対応する個別ポイントサーバ（例えば、１３）内のユーザ管理テーブル（例えば、ＴＥ１）に個人情報を格納されたユーザＵ１は、その会員登録とほぼ同時に、統括ポイントサーバ１２のユーザ管理テーブルＴＢ３にも個人情報を格納されることになる。
【０１０１】
図１０に示すように、ユーザ管理テーブルＴＢ３は、表記が相違するだけのデータ項目は１つに集約しているものの、図５〜図７の各ユーザ管理テーブルＴＥ１〜ＴＥ３が持つすべてのデータ項目を備えており、その上で、ユーザ管理テーブルＴＥ１〜ＴＥ３が持たないデータ項目「共通ユーザＩＤ」と「登録企業」も備えている。
【０１０２】
なお、図１０中の「ユーザＩＤ」とは、統括ポイントサーバ１２の内部で各ユーザを一義的に識別するための識別子である。したがって、統括ポイントサーバ１２の外部（例えば、個別ポイントサーバ１３）では同じ値のユーザＩＤが他のユーザに割り当てられている可能性もある。
【０１０３】
これに対し、「共通ユーザＩＤ」とは、統括ポイントサーバ１２の外部でも通用するユーザ識別子である。共通ユーザＩＤの生成法には様々な方法が考えられるが、もっとも単純なものは、企業ＥＰ１〜ＥＰ３のうち、あるユーザが最初に会員登録を行った企業の個別ポイントサーバ内で各ユーザに割り当てられているユーザＩＤとその企業の企業ＩＤとを合成して共通ＩＤを得る方法である（例えば、共通ユーザＩＤ＝企業ＩＤ＋ユーザＩＤ）。
【０１０４】
当該ユーザが会員登録を行う２番目以降の企業では、この共通ユーザＩＤをそのまま、自身のユーザＩＤとして利用するようにするとよい。
【０１０５】
これによって、通信システム１０全体で、一意なユーザＩＤを設定でき、統括ポイントサーバ１２と、個別ポイントサーバ１３〜１５のあいだの処理が簡単になる。
【０１０６】
以下、上記のような構成を有する本実施形態の動作について説明する。
【０１０７】
本実施形態の動作は、図４の動作シーケンスに示す。
【０１０８】
当該動作シーケンスは、Ｓ１０〜Ｓ１５の各ステップから構成されている。
【０１０９】
（Ａ−２）実施形態の動作
例えば、図１に示すように、企業ＥＰ１〜ＥＰ３がすでに通信システム１０に参加している状態において、あるユーザＵ１が企業ＥＰ１の企業側ネットワーク１６に設けられた店舗端末１９を用いて会員登録を行うものとすると、当該店舗端末１６は最初に電子メールアドレス（図５の「電子メール」に対応）の入力を促す。
【０１１０】
これを受けて、ユーザＵ１が自身の電子メールアドレスを入力する。当該電子メールアドレスとしては、ユーザＵ１がすでに企業ＥＰ２またはＥＰ３に会員登録している場合には、そのとき使用した電子メールアドレスを用いる。一人のユーザが、携帯電話機の電子メールアドレスやパーソナルコンピュータの電子メールアドレスなど、複数の電子メールアドレスを持つことも少なくないから、この電子メールアドレスはすでに会員登録で登録した電子メールアドレスに限定する必要がある。
【０１１１】
ここでは、当該ユーザＵ１がすでに企業ＥＰ２に会員登録しているものとし、そのとき使用した電子メールアドレスが「ＡＡ＠ＢＢＢ」であるものとすると、企業ＥＰ２の個別ポイントサーバ１４内のユーザ管理テーブルＴＥ２の多数の行のなかには、一例として、図６に示すＬ１のような行が存在する。
【０１１２】
この行Ｌ１は、当該ユーザＵ１に対応する行であり、ユーザＩＤが０００１１１で、電子メールアドレスがＡＡ＠ＢＢＢで、自宅電話番号０１２３４５６で、氏名が山田太郎で、購入金額総計が９９９９円で、ポイント値が１５００ポイント（共通ポイント）であることを示している。
【０１１３】
また、個別ポイントサーバ１４のユーザ管理テーブルＴＥ２にこのような行Ｌ１が存在するということは、図１０に示す統括ポイントサーバ１２のユーザ管理テーブルＴＢ３にも、必ずこのユーザＵ１に対応する例えばＬ２のような行が存在する。これは、いずれかの企業ＥＰ１〜ＥＰ３に会員登録する際には、強制的に統括ポイントサーバ１２に対する会員登録も行うものとしているからである。
【０１１４】
このような前提のもと、ユーザＵ１が前記店舗端末１６に電子メールアドレスが「ＡＡ＠ＢＢＢ」を入力すると、当該店舗端末１６は当該電子メールアドレスを個別ポイントサーバ１３に供給し、個別ポイントサーバ１３は図４のステップＳ１０に示すように、当該電子メールアドレスをもとに、ユーザＵ１がすでに会員登録されているか否かの問い合わせを統括ポイントサーバ１２に対して行う。
【０１１５】
この問い合わせに応じて、統括ポイントサーバ１２内の制御部４１がユーザ管理データベース４５内のユーザ管理テーブルＴＢ３を検索すると、前記行Ｌ２のなかに当該電子メールアドレスＡＡ＠ＢＢＢの存在を認めることができるから、ステップＳ１１に示すように、ユーザＵ１がすでに統括ポイントサーバ１２内に登録されている旨の返答とともに、当該行Ｌ２から得られるユーザＵ１の登録された氏名の値である「山田太郎」と共通ユーザＩＤの値である「００１０−０００１１１」（ＩＥＰ２＝００１０の場合）とポイント値である「１５００」を、個別ポイントサーバ１３に返す。
【０１１６】
個別ポイントサーバ１３では例えば当該「山田太郎」をユーザＵ１が操作している店舗端末１９に返してそのディスプレイ装置上に「あなたは山田太郎　様ですね」などと画面表示し、ユーザＵ１に氏名の値の正確さを確認してもらい、ユーザＵ１による肯定的な意思表示がボタン操作などによって示されれば、前記共通ユーザＩＤ「００１０−０００１１１」を、企業側ネットワーク１６におけるユーザＵ１のユーザＩＤとし、前記「山田太郎」をユーザＵ１の氏名として登録する。
【０１１７】
もちろん当該「山田太郎」をユーザＵ１に目視させず、店員などが目視した上で、ユーザに自身の氏名を名乗らせることで、簡易なユーザ認証に利用すること等も可能である。
【０１１８】
いずれにしても、このとき、ユーザＵ１は自身で氏名を入力する操作などを行う必要がなく、操作負担が小さい。
【０１１９】
ただし図５のデータ項目「パスワード」は、基本的にこのときユーザＵ１が入力する必要がある。また、ユーザＵ１の「来店回数」も入力または生成される必要のあるデータである。
【０１２０】
ここで新たに入力または生成されたパスワードの値「あいうえお」や来店回数の値「１」は、店舗端末１９から個別ポイントサーバ１３に供給されてユーザ管理テーブルＴＥ１の行Ｌ３に格納され、さらに統括ポイントサーバ１２へ届けられてユーザ管理テーブルＴＢ３の行Ｌ２のなかの該当する値と置き換えられる。これも、前記ステップＳ１０の通信となる。
【０１２１】
例えば、図１０の状態では、パスワードの値と来店回数の値は空値を示す「−」となっているが、統括ポイントサーバ１２は、各「−」をそれぞれ前記「あいうえお」と「１」に置き換えて、当該置き換えが終了した旨を、個別ポイントサーバ１３へ返す（Ｓ１１）。これを受けて個別ポイントサーバ１３が、当該置き換えが終了した旨を前記店舗端末１９へ返すと、ユーザＵ１の会員登録が終了して、個別ポイントサーバ１３および店舗端末１９は、当該終了を認識する。
【０１２２】
なお、ここでは、企業ＥＰ１が統括ポイントサーバ１２にパスワードや来店回数のデータ項目を開示し、前記ユーザ管理テーブルＴＢ３にそれらのデータ項目を設けてあるために、当該「あいうえお」と「１」を統括ポイントサーバ１２に送信しているが、これらのデータ項目を企業ＥＰ１が開示しなければ、これらの値を統括ポイントサーバ１２に送信する必要もない。
【０１２３】
特に、パスワードの値「あいうえお」などは、セキュリティ強化の観点からも、インターネット１１上に送信しないほうが望ましいといえる。
【０１２４】
以上の処理では、ステップＳ１０、Ｓ１１に示すように、個別ポイントサーバ１３が通信を行うのは統括ポイントサーバ１２だけであり、統括ポイントサーバ１２が通信を行うのも個別ポイントサーバ１３だけである。
【０１２５】
すなわち、ユーザＵ１が会員登録されているか否かを検査するために、通信システム１０中の他のノード（例えば、１４や１５）などに対して問い合わせを行う必要のない、極めて効率的なシステム構成となっている。
【０１２６】
また、以上の例では、ユーザＵ１がすでに企業ＥＰ２と統括ポイントサーバ１２に会員登録している場合であったが、会員登録していない場合でも効率性の高さは同様である。
【０１２７】
すなわち、ステップＳ１０で統括ポイントサーバ１２に問い合わせが行われたことを受けて制御部４１が前記ユーザ管理データベースＴＢ３を検索した結果、該当する電子メールアドレス「ＡＡ＠ＢＢＢ」を含む行が存在しなければ、その事実だけをもって、通信システム１０内のいずれの企業ＥＰ１〜ＥＰ３にも、ユーザＵ１の会員登録が行われていないことを保証することが可能である。
【０１２８】
このように、本実施形態では、ユーザＵ１が企業ＥＰ１〜ＥＰ３のいずれかの企業に会員登録している場合だけでなく、いずれの企業にも会員登録していないケースでも、通信システム１０中の他のノード（例えば、１４や１５）などに対して問い合わせを行う必要がないから、極めて効率的なシステム構成となっているといえる。
【０１２９】
ここでは、ユーザＵ１が企業ＥＰ１に会員登録しようとしたが、会員登録ではなく、共通ポイントを企業ＥＰ１の企業側ネットワーク１６に含まれるいずれかの店舗（拠点）で商品など交換して消費しようとした場合にも同様のことが成立する。
【０１３０】
企業ＥＰ１に当該ユーザＵ１が会員登録を済ませていない場合、個別ポイントサーバ１３では当該ユーザＵ１の現時点の共通ポイントのポイント値が不明であるから、統括ポイントサーバ１２にそのポイント値を問い合わせる必要が生じる（Ｓ１０）。
【０１３１】
また、このとき、ポイント値とともに電子メールアドレスや氏名などの返送も受けて（Ｓ１１）、店頭端末１９側でユーザＵ１のユーザ認証を行うことも可能である。
【０１３２】
商品とポイント値の交換は、返送されたポイント値の範囲内でのみ許容されることは当然である。
【０１３３】
一方、すでにユーザＵ１が企業ＥＰ１に会員登録している場合には、企業側ネットワーク１６と個別ポイントサーバ１３だけで処理し、統括ポイントサーバ１２への問い合わせを省略することも可能である。
【０１３４】
以上では、ユーザＵ１が企業ＥＰ１の企業側ネットワーク１６に設けられた店舗端末１９を操作して、会員登録やポイントの消費を行う場合の動作について説明したが、企業ＥＰ２やＥＰ３の企業側ネットワーク１７，１８に設けられた店舗端末２０，２１を操作して、会員登録やポイントの消費を行うケースの動作も同様である。
【０１３５】
例えば、当該ユーザＵ１が企業ＥＰ２の企業側ネットワーク１７に設けられた店舗端末２０を操作して、会員登録やポイントの消費を行う場合には、図４のステップＳ１２およびＳ１３に示すように、個別ポイントサーバ１４と統括ポイントサーバ１２のあいだでのみ通信が発生する。
【０１３６】
同様に、当該ユーザＵ１が企業ＥＰ３の企業側ネットワーク１８に設けられた店舗端末２１を操作して、会員登録やポイントの消費を行う場合には、図４のステップＳ１４およびＳ１５に示すように、個別ポイントサーバ１５と統括ポイントサーバ１２のあいだでのみ通信が発生する。
【０１３７】
（Ａ−３）実施形態の効果
本実施形態によれば、異なる顧客管理システムを持つ企業（ＥＰ１〜ＥＰ３）を統括ポイントサーバ（１２）によって適正に統合し、高いインターオペラビリティを実現することができる。
【０１３８】
また、本実施形態では、統括ポイントサーバ（１２）と各個別ポイントサーバ（１３〜１５）のあいだの通信回数を抑制でき、極めて効率的である。
【０１３９】
（Ｂ）他の実施形態
上記実施形態にかかわらず、前記電子メールアドレスや端末ＩＤのかわりに、その他のユーザ識別子を利用することも可能である。例えば、ユーザの住所および氏名などが利用可能である。
【０１４０】
住所および氏名をユーザ識別子とすれば、全ユーザを完全にカバーすることができる。また、例えば、いわゆる住民基本台帳ネットワークシステム上で住民個人を一意に識別するために付与されるコードなども、このユーザ識別子として利用可能である。住民基本台帳カード（一種のＩＣカード）を利用して、当該コードを自動的に送信できる場合には、前記店舗端末を当該住民基本台帳カードに対応させることで、ユーザの操作負担を軽減することも可能となる。
【０１４１】
また、上記実施形態では、通信システム１０内で共通ポイントだけを有効なものとしたが、共通ポイントとともに、個別ポイントも有効なものとしてもよいことは上述した通りである。
【０１４２】
ただしその場合には、各個別ポイントサーバ１３〜１５は、各ユーザの共通ポイントを管理するための機能に加えて当該個別ポイントを管理するための機能を備える必要があり、ユーザ側でも前記携帯通信端末や、前記カードまたはシール等の形態で、個別ポイントと共通ポイントを分けて管理する必要がある。
【０１４３】
個別ポイントは、当然、その個別ポイントを発行した企業の企業側ネットワークでのみ消費可能である。
【０１４４】
サーバ側のポイント管理としては、共通ポイントは統括ポイントサーバ１２で管理し、個別ポイントは各個別ポイントサーバ１３〜１５側で管理するようにしてもよい。この場合、各企業側ネットワークでユーザ（例えば、Ｕ１）が共通ポイントを消費する場合には、その個別ポイントサーバ（例えば、１３）から統括ポイントサーバ１２側へ、当該ユーザＵ１の共通ポイントのポイント値に関する問い合わせを行い、問い合わせの結果として得られたポイント値の範囲内でのみ共通ポイントの消費を許容することになる。また、消費後には、統括ポイントサーバ１２側で管理しているポイント値を消費量に応じて減少する必要がある。
【０１４５】
また、上記実施形態のように、共通ポイントのポイント値を、個別ポイントサーバ１３〜１５側でも管理するようにした場合、個別ポイントサーバ１３〜１５は、個別ポイントだけでなく、共通ポイントの管理まで行う必要があるが、共通ポイントの消費の際、逐一、統括ポイントサーバ１２に問い合わせる必要性が低くなり、効率が高まる。ただしこの場合には、共通ポイントのポイント値を個別ポイントサーバ側と統括ポイントサーバ側で同期させる必要があることは当然である。
【０１４６】
また、上記実施形態のように、各企業側ネットワーク１６〜１８内で使用可能なポイントを共通ポイントに制限せず、通信システム１０に参加したあとでも企業側ネットワーク（例えば、１６）内で個別ポイントを使用可能とすれば、各企業が参加前のサービスの仕組みをそのまま維持しやすいという利点がある。例えば、通信システム１０から離脱したあとには、その企業が、維持していたサービスの仕組みをそのまま利用して、ふたたび個別ポイントだけを利用する形態にもどすことができる。
【０１４７】
なお、上記実施形態にかかわらず、ユーザＵ１が会員登録する際、いずれの企業ＥＰ１〜ＥＰ３にも会員登録せずに統括ポイントサーバ１２だけに会員登録したり、これと反対に、統括ポイントサーバ１２には会員登録せず、いずれかの企業（例えば、ＥＰ１）だけに会員登録することを認めるようにしてもよい。これによって、（統括ポイントサーバ１２には会員登録せず、いずれかの企業（例えば、ＥＰ１）だけに会員登録することを認めた場合には、会員登録やポイントの消費に際して他の個別ポイントサーバにも問い合わせを行う必要が生じるから、効率は低下するものの、）システムの柔軟性が高くなり、ユーザの多様な要望に対応することが可能になる。
【０１４８】
もちろん、いずれの企業ＥＰ１〜ＥＰ３にも会員登録せずに統括ポイントサーバ１２だけに会員登録するか、統括ポイントサーバ１２には会員登録せず、いずれかの企業（例えば、ＥＰ１）だけに会員登録するかは、前記店舗端末（例えば、１９）を利用して示されるユーザの意思によって決まる。
【０１４９】
なお、統括ポイントサーバ１２には会員登録せず、いずれかの企業（例えば、ＥＰ１）だけに会員登録したユーザからは、会員登録の際、または、ポイントを消費するたびに、前記効率の低下に応じた手数料を徴収（そのユーザのポイント値の減少の形で徴収してもよい）するようにしてもよい。これにより、効率の低下よる通信料金のアップなどを、ある程度、補うことができる。
【０１５０】
また、上記実施形態ではデータ項目名称の表記の相違を統括ポイントサーバ１２側で吸収するようにしたが、企業が異なれば、顧客管理システムのデータ項目の値として許されるデータ形式が相違することも多いが、前記ユーザ管理テーブルＴＢ３では、可能性のあるあらゆるデータ形式を許容するようにするとよい。
【０１５１】
例えば、データ項目「氏名」の値として企業ＥＰ１が漢字による値（氏名）の表記を許していても、企業ＥＰ３では片仮名（あるいはローマ字など）による値の表記しか許していないケースなどがあり得るからである。
【０１５２】
また、不足している値を、前記再利用によってユーザ管理テーブル（例えば、ＴＥ１，ＴＢ３など）に格納する場合、格納先が個別ポイントサーバであるケースでは、格納の際に、値のデータ形式を格納先のデータ形式に変換するようにするとよい。片仮名から漢字への変換や、漢字から片仮名への変換は、変換結果が必ずしも一義的ではないが、例えば、前記店舗端末（例えば、１９）のディスプレイ装置上に「あなたは山田太郎　様ですね」などと画面表示した際に、その変換結果が正しくなるまで変換を繰り返して、変換結果の正しさを確保するようにしてもよい。
【０１５３】
上記実施形態にかかわらず、ユーザＵ１が企業ＥＰ１〜ＥＰ３のうち最初の企業に会員登録する際に、前記統括ポイントサーバ１２の持つ図１０のユーザ管理テーブルＴＢ３の全データ項目（ポイント値などは除く）に応じた情報を入力させるようにしてもよい。
【０１５４】
この場合、企業ＥＰ１〜ＥＰ３のうち２番目以降にユーザＵ１が会員登録する企業では、ユーザＵ１は新たな情報を入力する必要がなくなる利点がある。必要な情報は最初の会員登録の際にすべてユーザ管理テーブルＴＢ３に登録してあり、２番目以降の会員登録では、その値を再利用できるからである。
【０１５５】
上記実施形態では、統括ポイントサーバ１２は特定の企業側ネットワークに直接、接続されていなかったが、統括ポイントサーバ１２を企業側ネットワークに接続するようにしてもよい。
【０１５６】
また、上記実施形態では、処理能力にかかる負荷は統括ポイントサーバ１２に集中する傾向があるため、個別ポイントサーバの数が上述した３つよりも、はるかに多い場合などには、統括ポイントサーバ１２の機能を、前記木構造と同様な木構造の各節に分散配置することで、負荷を分散するようにしてもよい。
【０１５７】
さらに、上記実施形態で前記透過登録を行う場合などには、統括ポイントサーバ１２のユーザ管理テーブル（場合によっては、個別ポイントサーバ１３〜１５のユーザ管理テーブル）内のデータ項目のなかに、必要なデータ項目が空値「−」のままで欠けている状態になることが起こり得るが、この欠けた情報は、通信システム１０の外部で個人情報を蓄積しているデータベースから取得することも可能である。このようなデータベースの例としては、個人信用情報機関などが持つデータベースがあげられる。
【０１５８】
透過登録とは、通信システム１０内の他の企業（例えば、ＥＰ２，ＥＰ３）の顧客管理システムがどのようなデータ項目を備えているかに依存せず、ユーザがいま会員登録を行おうとしている企業（ここでは、ＥＰ１）の顧客管理システムのデータ項目だけをユーザＵ１に入力させ、そのデータ項目によって企業ＥＰ１だけでなく、統括ポイントサーバ１２に対する会員登録をも行うことを指す。
【０１５９】
なお、上記実施形態では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０１６０】
【発明の効果】
以上に説明したように、本発明によれば、インターオペラビリティが高く、なおかつ、効率的である。
【図面の簡単な説明】
【図１】実施形態に係る通信システムの全体構成例を示す概略図である。
【図２】実施形態で使用する統括ポイントサーバの主要部の構成例を示す概略図である。
【図３】実施形態で使用する個別ポイントサーバの主要部の構成例を示す概略図である。
【図４】実施形態の動作を示すシーケンス図である。
【図５】実施形態で使用するテーブルの構成例を示す概略図である。
【図６】実施形態で使用するテーブルの構成例を示す概略図である。
【図７】実施形態で使用するテーブルの構成例を示す概略図である。
【図８】実施形態で使用するテーブルの構成例を示す概略図である。
【図９】実施形態で使用するテーブルの構成例を示す概略図である。
【図１０】実施形態で使用するテーブルの構成例を示す概略図である。
【符号の説明】
１０…通信システム、１１…インターネット、１２…統括ポイントサーバ、１３〜１５…個別ポイントサーバ、１６〜１８…企業側ネットワーク、１９〜２１…店舗端末、３２…透過登録要求部、３３、４５…ユーザ管理データベース、４２…透過登録対応部、４３…項目名管理部、４４…企業管理データベース、ＴＥ１〜ＴＥ１、ＴＢ３…ユーザ管理データベース、ＴＢ１…項目名対応テーブル、ＴＢ２…企業管理テーブル。
【図１】
2004062494.tif 000003
【図２】
2004062494.tif 000004
【図３】
2004062494.tif 000005
【図４】
2004062494.tif 000006
【図５】
2004062494.tif 000007
【図６】
2004062494.tif 000008
【図７】
2004062494.tif 000009
【図８】
2004062494.tif 000010
【図９】
2004062494.tif 000011
【図１０】
2004062494.tif 000012