JP4959542B2 - 顧客情報関連付けシステム、顧客情報関連付け方法、顧客情報関連付けプログラム及びその記録媒体 - Google Patents

Description

本発明は、所定のサービスを提供する事業者と、そのサービスの需要家（顧客）との間で交わされる契約に係る契約情報に当該契約に係る顧客属性情報を関連付ける顧客情報関連付けシステムに関する。

従来から、電力会社は、顧客からの相談、意見等の連絡を受け付けて対応するために、カスタマセンタにおいて顧客対応システムを構築し、運用している。特許文献１には、顧客受付システムの例が開示されている。
特開２００４−３６３９７２号公報

ところが、従来の顧客対応システムには、いくつかの問題がある。まず、顧客対応業務の履歴が、当該業務ごとに別々の顧客対応システムで管理されているため、特定の顧客に対する対応履歴をまとめて参照することができない。次に、顧客からの申出内容を記載した帳票の処理と、電力契約の新規締結、変更、解約を含む異動の処理とが別々の顧客対応システムで行われ、それらの結果データ同士が関連付けられていないため、顧客の申出内容や契約の異動内容等を一連のものとして参照することができない。

従って、電力会社の担当者が顧客からの申出を受け付けた場合に、顧客は申出の対象となる物件について詳しく言わない（例えば、住所の一部だけを言う）ことが多いので、顧客がどういう立場（顧客属性）でどの物件について申出をされたのかがすぐに分からない。例えば、顧客が不動産（土地、マンションや貸家等）の所有者の場合には、その申出が、その不動産に関するものなのか、顧客の自宅に関するものなのかが分からない。次に、自宅以外の不動産に関するときには、電力会社が借地代を支払う土地の地権者としての申出なのか、それとも、電力会社に料金を支払う貸家等の管理者としての申出なのかが分からない。また、不動産所有者は、一本の電話で複数の事項（部屋ごとの給電の入切。その日時がばらばらである等）を依頼してくることがあるので、すぐにすべての依頼内容を把握するのは困難である。さらに、申出の裏付けをとるために、複数の顧客対応システムに分散しているデータをチェックする必要があり、その作業に膨大な時間がかかっていた。

本発明は、上記課題を鑑みてなされたものであり、その主たる目的は、所定のサービスを提供する事業者の顧客対応システムにおいて、特定の契約に係る複数の顧客属性情報をまとめて参照できるようにすることにある。

上記課題を解決するために、本発明は、顧客情報関連付けシステムであって、所定のサービスを提供する事業者と、前記サービスの需要家との間で交わされる契約に係り、当該契約に固有の番号である契約番号を含む契約情報と、前記需要家が有する顧客属性に係る情報であって、同じ前記顧客属性を有する前記需要家ごとに固有の番号である属性者番号及び前記契約番号を含む第１の顧客属性情報と、前記契約情報及び第２の顧客属性情報の両方に関連付けられる情報であって、自らに固有の情報番号及び前記契約番号を含む中間情報と、前記顧客属性に係る情報であって、前記属性者番号及び前記情報番号を含む前記第２の顧客属性情報と、を記憶する記憶部と、前記契約番号を取得し、取得した前記契約番号をキーとして前記記憶部内の前記第１の顧客属性情報を検索し、前記契約番号と、検索した結果該当した前記第１の顧客属性情報の前記属性者番号とを関連付けて前記記憶部に記憶するとともに、取得した前記契約番号をキーとして前記記憶部内の前記中間情報を検索し、検索した結果該当した前記中間情報の前記情報番号をキーとして前記記憶部内の前記第２の顧客属性情報を検索し、前記契約番号と、検索した結果該当した前記第２の顧客属性情報の前記属性者番号とを関連付けて前記記憶部に記憶する処理部と、を備えることを特徴とする。

この構成によれば、顧客が電力会社にとって複数の顧客属性（例えば、土地の地権者や貸家の管理者等）を有する場合に、カスタマセンタでの顧客対応において、申出をしてきた顧客の契約番号からキーデータ（属性者番号）を特定し、そのキーデータを用いて顧客属性情報を検索することによって、当該顧客の立場（顧客属性）に関する情報をすぐに参照できる。これによれば、電力会社の担当者は、当該顧客の有する立場及び申出の立場を把握できるので、説明の詳しくない顧客にも円滑に対応することができる。
さらに、顧客の立場に関する情報（顧客属性情報）に契約番号が含まれておらず、契約番号によって直接関連付けられない場合であっても、関連する顧客属性情報を特定可能なデータ（情報番号）及び契約番号を含む中間情報があるときには、その中間情報を介して当該顧客属性情報及び契約情報を関連付けることができる。これによれば、契約番号を含む中間情報がある場合に、契約に直接には関連しない顧客属性情報には別のキーデータ（情報番号）で関連付けを行うことによって、すべての顧客属性情報に契約番号を付与することなく、情報量が膨大になるのを抑止することができる。なお、複数の中間情報を介して契約情報と、顧客属性情報とを関連付けるようにしてもよい。

また、本発明は、顧客情報関連付けシステムであって、前記第１の顧客属性情報が、地権者に係る情報であって、前記属性者番号としての地権者番号及び前記契約番号を含む地権者情報であることを特徴とする。

また、本発明は、顧客情報関連付けシステムであって、前記中間情報が、町内会・自治会に係る情報であって、前記情報番号としての町内会・自治会番号及び前記契約番号を含む町内会・自治会情報であり、前記第２の顧客属性情報が、町内会・自治会役員に係る情報であって、前記属性者番号としての町内会・自治会役員番号及び前記情報番号としての前記町内会・自治会番号を含む町内会・自治会役員情報であることを特徴とする。

また、本発明は、顧客情報関連付けシステムであって、前記処理部が、前記契約番号を取得し、前記記憶部において、前記契約番号に関連付けて記憶されている前記属性者番号を読み出し、読み出した前記属性者番号を含む前記第１の顧客属性情報又は前記第２の顧客属性情報を検索することを特徴とする。

この構成によれば、１の契約情報が特定された場合に、当該契約情報に関連する顧客属性情報を取得し、表示することにより、オペレータは、当該契約情報に係る契約者の顧客属性を知り、当該契約者の状況や事情を把握することができるので、当該契約者に対する対応を円滑に行うことができる。

なお、請求項におけるサービスとは、公益事業者が提供する電気、ガス、水道及び電話を含むライフラインやインターネット・サービス・プロバイダ（ＩＳＰ：Internet Service Provider）が提供するインターネット接続のサービス等を含む。本発明は、顧客情報関連付け方法、顧客情報関連付けプログラム及びその記録媒体を含む。その他、本願が開示する課題及びその解決方法は、発明を実施するための最良の形態の欄、及び図面により明らかにされる。

本発明によれば、所定のサービスを提供する事業者の顧客対応システムにおいて、特定の契約に係る複数の顧客属性情報をまとめて参照することができる。

以下、図面を参照しながら、本発明を実施するための最良の形態を説明する。
本発明の実施の形態に係るカスタマセンタシステムは、例えば、電力会社において、顧客からの申出の受付履歴や内容を管理し、関連する契約情報や顧客情報を予め対応付けて、その対応付けられた情報を参照することによって、次回からの顧客対応が円滑に進むようにするものである。

≪システムの構成と概要≫
図１は、カスタマセンタシステムの構成概要を示す図である。カスタマセンタシステム１００は、顧客端末２００による顧客からの申出を受け付けて、所定の応答を行う。例えば、顧客端末２００から、インターネットを通じて意見を受けたり、通常の電話回線を通じて要望を受けたりする。また、フリーダイヤルで相談や転宅等の連絡を受けて、その内容に応じて応答を行う。顧客端末２００は、電力会社の顧客、すなわち、電力の需要家が利用する端末であり、具体的には、固定電話、携帯電話やＰＣ（Personal Computer）等によって構成される。

カスタマセンタシステム１００は、営業ポータルシステム１、顧客応答システム２、バッチ処理システム３及び顧客ＤＢ４を備える。営業ポータルシステム１は、受付履歴管理や申出内容管理等の機能を有し、顧客端末２００から意見・要望を受け付けるとともに、顧客ＤＢ４に対して電話番号以外による顧客情報検索要求を行い、検索結果を取得する。顧客応答システム２は、顧客端末２００からフリーダイヤルで相談や連絡を受けて、顧客の電話番号による顧客情報検索要求を顧客ＤＢ４に対して行うとともに、顧客ＤＢ４から検索結果を取得し、その検索結果の内容に応じた応答を顧客端末２００に対して行う。なお、顧客の電話番号に関しては、顧客応答システム２が顧客端末２００から通知された番号を取得するようにしてもよいし、顧客からの電話を受けたオペレータが顧客に番号登録の可否を確認してから番号を入力するようにしてもよい。

バッチ処理システム３は、夜間等においてバッチ処理を行う。具体的には、顧客ＤＢ４から契約番号を逐次取得し、その契約番号に従った名寄せ処理や関連付け処理を顧客ＤＢ４に対して行う。ここで、名寄せ処理は、関連する契約情報同士を対応付けるものである。また、関連付け処理は、関連する顧客情報同士を対応付けるものである。その詳細は、後記する。顧客ＤＢ４は、電力会社の顧客に関する情報を格納したものであり、営業ポータルシステム１や顧客応答システム２からの顧客情報検索要求に対して、速やかに検索結果を出力できるように、バッチ処理システム３による名寄せ処理や関連付け処理を予め受けることになる。その詳細は、後記する。

営業ポータルシステム１、顧客応答システム２及びバッチ処理システム３は、１又は複数のコンピュータからなるコンピュータシステムであり、ＣＰＵ（Central Processing Unit）がプログラムを実行することによって実現される処理部、不揮発性記憶装置（フラッシュメモリやハードディスク装置等）によって実現される記憶部等からなる。営業ポータルシステム１及び顧客応答システム２は、外部と情報の送受信を行うＮＩＣ（Network Interface Card）等によって実現される通信部を含む。顧客ＤＢ４は、不揮発性記憶装置内に構築されるデータベース（ＤＢ：Data Base）である。

≪データの構成≫
図２は、顧客ＤＢの構成を示す図である。顧客ＤＢ４は、関連付けＤＢ５、需給契約ＤＢ６、地権者ＤＢ７、町内会・自治会ＤＢ８、町内会・自治会役員ＤＢ９、集合住宅入居者ＤＢ１０、集合住宅ＤＢ１１、家主ＤＢ１２及び不動産ＤＢ１３を備える。

関連付けＤＢ５は、契約番号をキーとした顧客情報検索が円滑にできるようにしたインデックス情報（具体的には、契約関連情報５１及び名寄せ関連情報５２）を格納する。需給契約ＤＢ６は、契約情報６１を格納する。地権者ＤＢ７は、地権者情報７１を格納する。町内会・自治会ＤＢ８は、町内会・自治会情報８１を格納する。町内会・自治会役員ＤＢ９は、町内会・自治会役員情報９１を格納する。集合住宅入居者ＤＢ１０は、集合住宅入居者情報１０１を格納する。集合住宅ＤＢ１１は、集合住宅情報１１１を格納する。家主ＤＢ１２は、家主情報１２１を格納する。不動産ＤＢ１３は、不動産情報１３１を格納する。以下、各情報の詳細について説明する。

図３は、関連付けＤＢに格納されたインデックス情報の構成を示す図である。なお、図３に示すインデックス情報は、バッチ処理システム３により生成されるが、その処理については後記する。

図３（ａ）は、インデックス情報のうち、契約関連情報５１の構成を示す模式図である。契約関連情報５１は、契約番号に対して、その契約番号に関連する顧客情報のインデックス情報を対応付けたものである。契約関連情報５１は、契約番号５１１、地権者番号５１２、町内会・自治会番号５１３、町内会・自治会役員番号５１４、集合住宅入居者番号５１５、集合住宅番号５１６、家主番号５１７及び不動産番号５１８を含むレコードからなる。

まず、契約番号５１１は地権者番号５１２に関係付けられる。次に、契約番号５１１は町内会・自治会番号５１３に関係付けられ、その町内会・自治会番号５１３は町内会・自治会役員番号５１４に関係付けられる。そして、契約番号５１１は集合住宅入居者番号５１５に関係付けられ、その集合住宅入居者番号５１５は集合住宅番号５１６に関係付けられ、その集合住宅番号５１６は家主番号５１７及び不動産番号５１８に関係付けられる。この構成によれば、契約番号５１１が指定された場合に、その契約番号５１１に関連する各情報のインデックス情報（キーデータ）がすぐに取れるので、そのインデックス情報を用いて各ＤＢから関連する各情報を速やかに取得することができる。なお、図３（ａ）はインデックス情報のつながりを示しているので、すべてのインデックス情報を見せているが、契約関連情報５１としては、必ずしもすべてのインデックス情報を含まなくてもよい。例えば、集合住宅入居者番号５１５及び集合住宅番号５１６は、家主番号５１７及び不動産番号５１８を取得するために必要であって、インデックス情報としては不要だとすれば、契約関連情報５１の構成から外してもよい。

図３（ｂ）は、インデックス情報のうち、名寄せ関連情報５２の構成を示す。名寄せ関連情報５２は、契約情報６１同士で関連のあるものを対応付けたものである。名寄せ関連情報５２は、契約番号５２１、条件ＩＤ５２２及び名寄せ契約番号５２３を含むレコードからなる。契約番号５２１は、名寄せの中心となる契約情報６１の契約番号であり、各レコードのキーになるものである。この契約番号５２１の契約情報６１に対して名寄せ処理が行われる。条件ＩＤ５２２は、名寄せ条件ごとに固有のＩＤであり、名寄せの信頼性を示す度合いでもある。また、名寄せされた契約情報を表示する順序にも用いることができる。名寄せ処理は、この条件ＩＤ５２２に対応する名寄せ条件ごとに行われる。名寄せ契約番号５２３は、名寄せの対象となる契約情報６１の契約番号であり、具体的には、契約番号５２１の契約情報６１に対して、条件ＩＤ５２２の名寄せ条件に従って名寄せの対象となる契約情報６１の契約番号である。なお、１つの契約番号５２１に対して複数の条件ＩＤ５２２に合う名寄せ契約番号５２３が存在しうる。また、１つの契約番号５２１及び１つの条件ＩＤ５２２に対して複数の名寄せ契約番号５２３が存在しうる。この構成によれば、契約番号５２１が指定された場合に、その契約番号５２１に対する名寄せ契約番号５２３を特定できるので、その名寄せ契約番号５２３を用いて需給契約ＤＢ６から該当する契約情報６１を速やかに取得することができる。

図４は、契約情報及び地権者情報の構成を示す図である。図４（ａ）は、契約情報の構成を示す。契約情報６１は、契約番号６１１、契約種別６１２、契約者氏名６１３、住所６１４、電話番号６１５、支払者番号６１６、支払者氏名６１７、住所６１８、口座番号６１９、電話番号６２０、転居先住所６２１及び転居先電話番号６２２を含むレコードからなる。

契約番号６１１は、顧客と電力会社との間に締結された電力の需給契約に固有の番号であり、電力会社の営業所のコードを含む。この項目データにより契約情報６１が地権者情報７１、町内会・自治会情報８１及び集合住宅入居者情報１０１に関連付けられる（図３（ａ）参照）。契約種別６１２は、契約の種別である。契約者氏名６１３は、電力会社と当該契約を行った契約者の氏名である。住所６１４は、契約者の住所である。電話番号６１５は、契約者の電話番号である。支払者番号６１６は、当該契約に従って支払いを行う支払者に固有の番号である。名寄せは、支払者が同一である（支払者情報が合致する）と判定される契約情報を探すものであると言うことができる。支払者氏名６１７は、支払者の氏名である。住所６１８は、支払者の住所である。口座番号６１９は、支払者の口座番号であり、金融機関、店舗及び預金種別を示すコードを含む。電話番号６２０は、支払者の電話番号である。転居先住所６２１は、契約者が転居する場合の転居先の住所である。転居先電話番号６２２は、契約者が転居する場合の転居先の電話番号である。なお、契約番号６１１が検索のキーデータとなる。

図４（ｂ）は、地権者情報の構成を示す。地権者情報７１は、地権者番号７１１、地権者氏名７１２、住所７１３、電話番号７１４、振込先７１５及び契約番号７１６を含むレコードからなる。地権者番号７１１は、地権者に固有の番号である。地権者氏名７１２は、地権者の氏名である。住所７１３は、地権者の住所である。電話番号７１４は、地権者の電話番号である。振込先７１５は、電力会社が地権者に借地料等を振り込む先を示すものであり、金融機関、店舗、預金種別、口座番号等を含む。契約番号７１６は、地権者が電力会社と交わした契約の番号である。なお、地権者番号７１１が検索のキーデータとなる。

図５は、町内会・自治会情報及び町内会・自治会役員情報の構成を示す図である。図５（ａ）は、町内会・自治会情報の構成を示す。町内会・自治会情報８１は、町内会・自治会番号８１１、町内会・自治会名称８１２、住所８１３及び契約番号８１４を含むレコードからなる。町内会・自治会番号８１１は、町内会・自治会に固有の番号であり、この項目データにより町内会・自治会情報８１が町内会・自治会役員情報９１に関連付けられる（図３（ａ）参照）。町内会・自治会名称８１２は、町内会・自治会の名称である。住所８１３は、町内会・自治会に係る施設（例えば、公民館）の住所である。契約番号８１４は、町内会・自治会が電力会社と交わした契約の番号である。なお、町内会・自治会番号８１１が検索のキーデータとなる。

図５（ｂ）は、町内会・自治会役員情報の構成を示す。町内会・自治会役員情報９１は、町内会・自治会役員番号９１１、町内会・自治会番号９１２、役職９１３、役員氏名９１４、住所９１５及び電話番号９１６を含むレコードからなる。町内会・自治会役員番号９１１は、町内会・自治会役員（個人）に固有の番号である。町内会・自治会番号９１２は、町内会・自治会に固有の番号である。役職９１３は、町内会・自治会役員の役職（例えば、会長、副会長、会計、書記等）である。役員氏名９１４は、町内会・自治会役員の氏名である。住所９１５は、町内会・自治会役員の住所である。電話番号９１６は、町内会・自治会役員の電話番号である。なお、町内会・自治会役員番号９１１が検索のキーデータとなる。

図６は、集合住宅入居者情報、集合住宅情報、家主情報及び不動産情報の構成を示す図である。図６（ａ）は、集合住宅入居者情報の構成を示す。集合住宅入居者情報１０１は、集合住宅入居者番号１０１１、集合住宅番号１０１２、部屋番号１０１３、契約番号１０１４及び公街灯番号１０１５を含むレコードからなる。集合住宅入居者番号１０１１は、集合住宅の入居者に固有の番号である。集合住宅番号１０１２は、集合住宅に固有の番号であり、この項目データにより集合住宅入居者情報１０１が集合住宅情報１１１に関連付けられる（図３（ａ）参照）。部屋番号１０１３は、当該入居者が入っている部屋に固有の番号であり、階番号を含む。契約番号１０１４は、当該入居者が電力会社と交わしている契約の番号である。公街灯番号１０１５は、部屋の前の通路に設置された街灯に固有の番号である。なお、集合住宅入居者番号１０１１が検索のキーデータとなる。

図６（ｂ）は、集合住宅情報の構成を示す。集合住宅情報１１１は、集合住宅番号１１１１、集合住宅名称１１１２、住所１１１３、家主番号１１１４及び不動産番号１１１５を含むレコードからなる。集合住宅番号１１１１は、集合住宅に固有の番号である。集合住宅名称１１１２は、集合住宅の名称である。住所１１１３は、集合住宅のある住所である。家主番号１１１４は、集合住宅を所有する家主に固有の番号であり、この項目データにより集合住宅情報１１１が家主情報１２１に関連付けられる（図３（ａ）参照）。不動産番号１１１５は、集合住宅の不動産としての固有の番号であり、この項目データにより集合住宅情報１１１が不動産情報１３１に関連付けられる（図３（ａ）参照）。なお、集合住宅番号１１１１が検索のキーデータとなる。

図６（ｃ）は、家主情報の構成を示す。家主情報１２１は、家主番号１２１１、家主氏名１２１２、住所１２１３及び電話番号１２１４を含むレコードからなる。家主番号１２１１は、家主に固有の番号である。家主氏名１２１２は、家主の氏名である。住所１２１３は、家主の住所である。電話番号１２１４は、家主の電話番号である。なお、家主番号１２１１が検索のキーデータとなる。

図６（ｄ）は、不動産情報の構成を示す。不動産情報１３１は、不動産番号１３１１、不動産名称１３１２、住所１３１３及び電話番号１３１４を含むレコードからなる。不動産番号１３１１は、不動産に固有の番号である。不動産名称１３１２は、不動産の名称である。住所１３１３は、不動産のある住所である。電話番号１３１４は、不動産の管理者の電話番号である。なお、不動産番号１３１１が検索のキーデータとなる。

図７は、名寄せ条件マトリクスの構成を示す図である。名寄せ条件マトリクス（名寄せ条件データ）３１は、バッチ処理システム３の記憶部に記憶され、顧客ＤＢ４の名寄せ処理を行う際にバッチ処理システム３の処理部から参照される。名寄せ条件マトリクス３１は、条件番号３１１、契約番号３１２、口座番号３１３、支払者番号３１４、氏名カナ３１５、住所コード３１６、住所補足３１７、電話番号３１８、名寄せ結果３１９及び条件ＩＤ３２０を含むレコードからなる。名寄せ処理においては、各レコードの比較対象となる各項目データに関して、１の契約情報６１と、その他の契約情報６１とが逐次比較照合される。

条件番号３１１は、１の名寄せ条件に固有の番号であり、一連番号として付与される。契約番号３１２は、契約情報６１の契約番号６１１を示す。口座番号３１３は、契約情報６１の口座番号６１９を示す。支払者番号３１４は、契約情報６１の支払者番号６１６を示す。氏名カナ３１５は、支払者氏名６１７のうち、カナの部分を示す。住所コード３１６は、契約情報６１の住所６１８の一部を示し、上５桁３１６１及び下６桁３１６２からなる。住所補足３１７は、契約情報６１の住所６１８の一部を示す。電話番号３１８は、契約情報６１の電話番号６２０を示し、市外局番３１８１、局番３１８２及び加入番号３１８３からなる。名寄せ結果３１９は、「ＯＫ」のとき名寄せ条件に合致すれば名寄せできることを示し、「確認」のとき名寄せ条件に合致した後にオペレータに確認が必要であることを示す。条件ＩＤ３２０は、１の名寄せ条件に固有の番号であるとともに、名寄せの信頼性の度合いをも示す。また、名寄せされた契約情報を表示する順序にも用いることができる。

なお、図７に示すように、名寄せ条件マトリクス３１において、−は関知しないことを示すコードであり、○は完全一致であることを示すコードであり、△は部分一致であることを示すコードである。例えば、条件番号３１１が１の名寄せ条件においては、口座番号３１３が完全一致することが名寄せ条件となる。また、条件番号３１１が４の名寄せ条件においては、氏名カナ３１５が部分一致すること、並びに住所コード３１６及び電話番号３１８が完全一致することが名寄せ条件となる。

条件番号３１１が１６、１７の名寄せ条件には、契約番号３１２が完全一致すること及び氏名カナ３１５が完全一致又は部分一致することが含まれている。これは、例えば、電灯、動力等複数の契約をしている顧客の場合、契約ごとに８桁の同じ契約番号及び１桁の異なる枝番で管理されているので、契約番号が同じであっても枝番が異なれば、異なる契約となるため、名寄せ条件として契約番号が一致するか否か及び支払者の氏名が一致するか否かを確認するものである。

≪システムの処理（バッチ処理）≫
次に、バッチ処理システム３が行うバッチ処理について説明する。バッチ処理には、名寄せ処理及び関連付け処理がある。

図８は、名寄せ処理を示すフローチャートである。名寄せ処理は、名寄せ条件マトリクス３１に従って、需給契約ＤＢ６内の契約情報６１同士を比較照合し、名寄せの結果として関連付けＤＢ５内に名寄せ関連情報５２を生成、記憶するものである。バッチ処理システム３の処理部は、需給契約ＤＢ６内の契約情報６１に付与されている契約番号６１１を逐次取得する（Ｓ８０１）。そして、取得した契約番号６１１ごとにＳ８０２〜Ｓ８０９のバッチ処理を繰り返す。

まず、処理部は、取得した契約番号６１１をキーとして需給契約ＤＢ６を検索し、該当する契約情報６１を取得する（Ｓ８０２）。次に、名寄せ条件マトリクスの条件番号を示す変数ｎに１を代入する（Ｓ８０３）。その変数ｎは、バッチ処理システム３の所定のメモリ（一時的な記憶領域）に記憶される。

そして、処理部は、名寄せ条件マトリクス３１の条件番号３１１：ｎ（初期値は、１）に従って、取得した契約情報６１から必要な各項目データを抽出する（Ｓ８０４）。例えば、ｎ＝１の場合、名寄せ条件マトリクス３１によれば必要な項目データは口座番号３１３なので、契約情報６１から口座番号６１９を抽出する。続いて、条件番号３１１：ｎに従って、抽出した各項目データと、完全一致又は部分一致する各項目データを有する他の契約情報６１を検索する（Ｓ８０５）。具体的には、需給契約ＤＢ６から他の契約情報６１を読み出しながら、各契約情報６１の各項目データを比較照合し、名寄せできるか否かを確認する。

該当する契約情報６１があった場合には（Ｓ８０６のＹＥＳ）、処理部は、名寄せ条件マトリクス３１の条件番号３１１：ｎに対応する条件ＩＤ３２０及び該当した契約情報６１の契約番号６１１を関連付けＤＢ５に設定する（Ｓ８０７）。具体的には、名寄せ関連情報５２（図３（ｂ）参照）の形式にして関連付けＤＢ５に記憶する。一方、該当する契約情報６１がなかった場合には（Ｓ８０６のＮｏ）、Ｓ８０７の処理をスキップする。

そして、変数ｎに１を加算した値を、ｎに代入する（Ｓ８０８）。続いて、変数ｎが条件番号３１１の最大値Ｎ（図７によれば、Ｎ＝２１）より大きいか否かをチェックする（Ｓ８０９）。ｎがＮより大きくない場合、すなわち、ｎがＮと同じ又はＮより小さい場合には（Ｓ８０９のＮｏ）、Ｓ８０４以降の処理を繰り返す。ｎがＮより大きい場合には（Ｓ８０９のＹｅｓ）、名寄せ条件マトリクス３１内のすべての条件番号について比較照合を行ったことになるので、１の契約番号６１１に対するバッチ処理を終了する。

さらに、バッチ処理終了後、処理部は、名寄せ関連情報５２の条件ＩＤ５２２ごとに、名寄せ条件マトリクス３１の条件ＩＤ３２０に対応する名寄せ結果３１９が「確認」であれば、２つの契約情報６１を画面に表示して、名寄せの可否をオペレータに確認する（Ｓ８１０）。夜間のバッチ処理では、「確認」の名寄せ条件であっても当該契約番号の組み合わせ（契約番号５２１に対する名寄せ契約番号５２３）を名寄せ関連情報５２に一旦設定しておいて、バッチ処理終了後、当該契約情報の組み合わせを表示し、オペレータにより名寄せ不可の入力があったときに、名寄せ関連情報５２の当該レコードを削除する。

図９及び図１０は、関連付け処理を示すフローチャートである。関連付け処理は、顧客ＤＢ４内の各ＤＢの情報を、契約番号等をキーデータとして探索し、その探索結果として契約関連情報５１を関連付けＤＢ５内に生成、記憶するものである。図９を参照して、バッチ処理システム３の処理部は、需給契約ＤＢ６内の契約情報６１に付与されている契約番号６１１を逐次取得する（Ｓ９０１）。そして、取得した契約番号６１１ごとにＳ９０２〜Ｓ９０７及びＳ１００１〜Ｓ１００５の処理を繰り返す。

まず、処理部は、取得した契約番号６１１をキーとして地権者ＤＢ７内を検索し、該当する地権者情報７１を取得する（Ｓ９０２）。そして、取得した地権者情報７１から地権者番号７１１を抽出し、関連付けＤＢ５に設定する（Ｓ９０３）。具体的には、契約関連情報５１（図３（ａ）参照）において、契約番号５１１に地権者番号５１２を関連付ける。

次に、処理部は、契約番号６１１をキーとして町内会・自治会ＤＢ８内を検索し、該当する町内会・自治会情報８１を取得する（Ｓ９０４）。そして、取得した町内会・自治会情報８１から町内会・自治会番号８１１を抽出し、関連付けＤＢ５に設定する（Ｓ９０５）。具体的には、契約関連情報５１において、契約番号５１１に町内会・自治会番号５１３を関連付ける。さらに、抽出した町内会・自治会番号５１３をキーとして町内会・自治会役員ＤＢ９内を検索し、該当する町内会・自治会役員情報９１を取得する（Ｓ９０６）。そして、取得した町内会・自治会役員情報９１から町内会・自治会役員番号９１１を抽出し、関連付けＤＢ５に設定する（Ｓ９０７）。具体的には、契約関連情報５１において、町内会・自治会番号５１３に町内会・自治会役員番号５１４を関連付ける。

続いて、図１０を参照して、処理部は、契約番号６１１をキーにして集合住宅入居者ＤＢ１０内を検索し、該当する集合住宅入居者情報１０１を取得する（Ｓ１００１）。そして、取得した集合住宅入居者情報１０１から集合住宅入居者番号１０１１を抽出し、関連付けＤＢ５に設定する（Ｓ１００２）。具体的には、契約関連情報５１において、契約番号５１１に集合住宅入居者番号５１５を関連付ける。次に、取得した集合住宅入居者情報１０１から集合住宅番号１０１２を抽出し、関連付けＤＢ５に設定する（Ｓ１００３）。具体的には、契約関連情報５１において、集合住宅入居者番号５１５に集合住宅番号５１６を関連付ける。

さらに、抽出した集合住宅番号１０１２をキーとして集合住宅ＤＢ１１内を検索し、該当する集合住宅情報１１１を取得する（Ｓ１００４）。そして、取得した集合住宅情報１１１から家主番号１１１４及び不動産番号１１１５を抽出し、関連付けＤＢ５に設定する（Ｓ１００５）。具体的には、契約関連情報５１において、集合住宅番号５１６に家主番号５１７及び不動産番号５１８を関連付ける。なお、契約番号５１１に電話番号５１９を関連付けるのは、バッチ処理システム３ではなく、顧客応答システム２における申出入力の際にオペレータ操作によって「電話登録」が行われる場合である。

≪システムの処理（顧客情報検索処理）≫
続いて、営業ポータルシステム１及び顧客応答システム２で行われる顧客情報検索処理について説明する。図１１は、顧客端末２００からフリーダイヤルを受け付けた顧客応答システム２が行う顧客情報検索処理を示すフローチャートである。なお、顧客応答システム２は、処理部、記憶部、通信部、キーボードやマウス等によって実現される入力部及びＬＣＤ（Liquid Crystal Display）等によって実現される表示部を備えるものとする。また、図１１のフローチャートに従って説明する中で、随時図１２〜図１７に示す各画面を参照するものとする。

まず、顧客応答システム２では、表示部がトップ画面を表示し、通信部が顧客端末２００からフリーダイヤルを受け付ける（Ｓ１１０１）。図１２（ａ）は、トップ画面の例を示す。トップ画面には、オペレータである入力者１２Ａ１及び所属する受付グループ名１２Ａ２が表示されている。この状態で、通信部が顧客端末２００から電話を受けると、処理部が顧客の電話番号をキーとして需給契約ＤＢ６を検索する（Ｓ１１０２）。顧客の電話番号は、通信部から取得するか、又は、電話を受けたオペレータによる入力内容を取得する。処理部による検索の結果、該当する契約情報６１があれば（Ｓ１１０３のＹＥＳ）、表示部が当該契約情報６１を表示する（Ｓ１１０７）。図１４（ａ）は、契約情報６１を表示した画面の例を示す。当該画面には、電話で連絡して来た人の申出者情報としてご契約番号１４Ａ１、氏名１４Ａ２、支払者１４Ａ３等が表示されている。

Ｓ１１０２の検索の結果、該当する契約情報６１がなければ（Ｓ１１０３のＮＯ）、処理部が第２の電話番号をキーとして関連付けＤＢ５を検索する（Ｓ１１０４）。第２の電話番号は、例えば携帯電話の番号であり、自動的に電話番号を取得できる仕組み（ナンバーディスプレイ）を利用し、顧客の了解を得た後、取得する。関連付けＤＢ５の契約関連情報５１（図３参照）の検索において、第２の電話番号と、電話番号５１９とが一致した場合には、電話番号５１９に対応する契約番号５１１をキーとして需給契約ＤＢ６を検索し、該当する契約情報６１を特定する。検索の結果、該当する契約情報６１があれば（Ｓ１１０５のＹＥＳ）、図１４（ａ）に示すように、表示部がその契約情報６１を表示する（Ｓ１１０７）。

Ｓ１１０４の検索の結果、該当する契約情報６１がなければ（Ｓ１１０５のＮＯ）、処理部が電話番号以外をキーとして需給契約ＤＢを検索する（Ｓ１１０６）。図１３（ａ）は、電話番号による検索で該当する契約情報６１がなかった場合に表示される画面の例を示す。なお、該当する契約情報６１の有無にかかわらず、受付番号１３Ａ１は確定されている。当該画面において、オペレータが申出者情報ボックス１３Ａ２の契約ボタン１３Ａ３をクリックすると、図１３（ｂ）の需給契約者検索画面が表示される。そこで、オペレータが町名氏名タブ１３Ｂ１を選択し、氏名（カナ）１３Ｂ２及び町名（カナ）１３Ｂ３を入力し、検索ボタン１３Ｂ４をクリックすると、入力した氏名（カナ）及び町名（カナ）に該当する住所の一覧（住所一覧１３Ｂ５）が表示される。さらに、その住所一覧１３Ｂ５の住所のうち、いずれかをオペレータが選択（クリック）すれば、対応する契約情報６１が需給契約者一覧１３Ｂ６に表示される。そこで、オペレータが了解ボタン１３Ｂ７をクリックすれば、図１４（ａ）の画面に移行し、該当する契約情報６１が表示部に表示される（Ｓ１１０７）。

また、図１３（ａ）の画面において、オペレータが履歴参照１３Ａ４を選択し、タブ切替１３Ａ５をクリックすると、図１２（ｂ）の画面が表示され、今までの申出の履歴（申出者名１２Ｂ１、契約者名１２Ｂ２や支払者名１２Ｂ３を含む情報）が分かるようになっている。

次に、表示部が関連する契約情報６１を表示する（Ｓ１１０８）。具体的には、図１４（ａ）の画面において、オペレータが申出者情報の右矢印（→）のボタン１４Ａ４をクリックすることによって、図１４（ｂ）に示すように対象契約タブ１４Ｂ１及び関連契約タブ１４Ｂ２が選択できるようになる。オペレータが関連契約タブ１４Ｂ２をクリックすることによって、表示された関連契約を選択した後、オペレータが対象契約タブ１４Ｂ１をさらにクリックすることによって、選択した関連契約が対象契約として確定する。なお、該当する関連契約は複数個重ねて表示することができ、その関連契約を対象契約として特定する操作は、別件入力ボタン１４Ｂ３を用いて別途まとめて行うことができる。また、オペレータが連絡先ＴＥＬ欄１４Ｂ４に電話番号の数字を入力し、電話番号ボタン１４Ｂ５をクリックすると、その入力した電話番号が第２の電話番号（電話番号５１９）として関連付けＤＢ５の契約関連情報５１に追加される。これにより、第２の電話番号から契約番号５１１が特定でき、その契約番号５１１から契約情報６１を特定できるようになる。なお、関連契約タブ１４Ｂ２には、関連付けＤＢ５の名寄せ関連情報５２によって、Ｓ１１０７で表示された契約情報６１に関連付けられた（名寄せされた）契約情報が表示される。

続いて、申出タイトルを選択する（Ｓ１１０９）。具体的には、オペレータが、図１４（ｂ）の画面において対象契約タブ１４Ｂ１の下にある申出入力ボタン１４Ｂ６をクリックすると、図１５（ａ）の画面に移行する。そして、オペレータが図１５（ａ）の画面において申出入力タブ１５Ａ１を選択し、▼（申出タイトルのプルダウンメニューのボタン１５Ａ２）をクリックすると、図１５（ｂ）に示す申出タイトル選択画面（大分類のみ）が表示される。そして、オペレータが大分類の欄１５Ｂ１に示される項目を１つ選択してクリックすると、図１６（ａ）に示すように、大分類の欄１６Ａ１に中分類の欄１６Ａ２及び申出タイトルの欄１６Ａ３が追加された申出タイトル選択画面が表示される。中分類の欄１６Ａ２には、大分類の欄１６Ａ１の「故障受付」に対応して「停電、ブレーカー、温水器、外灯」が表示されている。申出タイトルの欄１６Ａ３には、大分類の欄１６Ａ１の「故障受付」に対応して「停電（屋内一部）」や「停電（屋内全部）」等の具体的な故障の内容が表示されている。この画面において、オペレータが了解ボタン１６Ａ４をクリックすると、図１６（ｂ）に示す受付画面が表示される。この受付画面では、申出入力タブ１６Ｂ１の申出タイトル１６Ｂ２が「停電（屋内一部）」に固定されている。

次に、申出内容１６Ｂ３を入力する（Ｓ１１１０）。これは、オペレータが顧客端末２００（特に、固定電話又は携帯電話）からの電話の声を聞いて、申出タイトルだけでは言い表せない具体的な故障内容を記載するものである。なお、必要に応じて、対応内容１６Ｂ４も入力するものとする。そして、受付が完了したものとし、オペレータが受付完了ボタン１６Ｂ５をクリックすると、図１２（ａ）のトップ画面に戻る（Ｓ１１１１）。

なお、図１６（ｂ）の受付画面において、オペレータが申出入力タブ１６Ｂ１の表示・更新ボタン１６Ｂ６をクリックすると、図１７に示す故障票の画面が表示される。この画面は、営業ポータルシステム１内の申出内容管理システムで管理されている。故障票は、顧客からの故障連絡を受けて実際に対応するために、管轄の営業所に回付される帳票であり、受付画面と同じ受付番号１７１が付与されている。故障票の画面において、回付先１７２は、例えば、図１６（ｂ）に示すご契約番号の上４桁の数字「５１９０」から「東広島」と確定されるが、回付先の変更、追加、削除等が必要な場合には、オペレータが営業所設定ボタン１７３をクリックすることによって編集操作が可能である。そして、起票ボタン１７４をクリックすると、故障票の内容が回付先である営業所等のコンピュータに送信される。

以上本発明の実施の形態について説明したが、図１に示す営業ポータルシステム１、顧客応答システム２及びバッチ処理システム３を機能させるために、各システムの処理部（ＣＰＵ）で実行されるプログラム（顧客情報関連付けプログラムを含む）をコンピュータにより読み取り可能な記録媒体に記録し、その記録したプログラムをコンピュータに読み込ませ、実行させることにより、本発明の実施の形態に係るカスタマセンタシステム１００が実現されるものとする。なお、プログラムをインターネット等のネットワーク経由でコンピュータに提供してもよいし、プログラムが書き込まれた半導体チップ等をコンピュータに組み込んでもよい。

以上説明した本発明の実施の形態によれば、以下の効果がある。すなわち、従来は、同じ顧客であっても、地権者、自治会の役員、アパートの家主、個人といったいろいろな立場で申出があるので、ある顧客から不動産のことを頼まれているのに、その顧客の自宅に行ってしまうことがあった。これに対して、関連付けＤＢ５の契約関連情報５１を利用することによって、その顧客が有する複数の立場（顧客属性）を参照することができ、その中から申出のときの顧客の立場を特定し、確認することができる。

以上、本発明を実施するための最良の形態について説明したが、上記実施の形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明はその趣旨を逸脱することなく変更、改良され得るとともに、本発明にはその等価物も含まれる。例えば、以下のような実施の形態が考えられる。

（１）関連付けＤＢ５に記憶された契約関連情報５１及び名寄せ関連情報５２を組み合わせて利用するようにしてもよい。この場合、名寄せ関連情報５２において１の契約番号５２１に関連付けられる１以上の名寄せ契約番号５２３に対して、契約関連情報５１において地権者番号５１２や集合住宅番号５１６等が関連付けられる。これにより、１の契約情報６１に関連する各ＤＢの情報を広くかつ漏れなく取得することができる。
（２）カスタマセンタシステム１００は、電力会社だけでなく、ガス、水道及び電話を含むライフラインやインターネット接続サービス等を提供する事業者の顧客対応システムにも適用することができる。

カスタマセンタシステムの構成概要を示す図である。 顧客ＤＢの構成を示す図である。 関連付けＤＢに格納されたインデックス情報の構成を示す図であり、（ａ）は契約関連情報の構成を示し、（ｂ）は名寄せ関連情報の構成を示す。 契約情報及び地権者情報の構成を示す図であり、（ａ）は契約情報の構成を示し、（ｂ）は地権者情報の構成を示す。 町内会・自治会情報及び町内会・自治会役員情報の構成を示す図であり、（ａ）は町内会・自治会情報の構成を示し、（ｂ）は町内会・自治会役員情報の構成を示す。 集合住宅入居者情報、集合住宅情報、家主情報及び不動産情報の構成を示す図であり、（ａ）は集合住宅入居者情報の構成を示し、（ｂ）は集合住宅情報の構成を示し、（ｃ）は家主情報の構成を示し、（ｄ）は不動産情報の構成を示す。 名寄せ条件マトリクスの構成を示す図である。 名寄せ処理を示すフローチャートである。 関連付け処理を示すフローチャート（１／２）である。 関連付け処理を示すフローチャート（２／２）である。 顧客情報検索処理を示すフローチャートである。 （ａ）は顧客受付のトップ画面を示し、（ｂ）は履歴参照画面を示す。 （ａ）は電話番号による検索で該当する契約情報がなかった場合に表示される画面を示し、（ｂ）は需給契約者検索画面を示す。 （ａ）は契約情報を表示した画面を示し、（ｂ）は対象契約タブ及び関連契約タブが選択できる画面を示す。 （ａ）は申出入力を行う画面を示し、（ｂ）は申出タイトル選択画面（大分類のみ）を示す。 （ａ）は申出タイトル選択画面（大分類、中分類及び申出タイトル）を示し、（ｂ）は申出入力が完了した画面を示す。 故障票を表示した画面を示す。

符号の説明

１００ カスタマセンタシステム
２００ 顧客端末
１ 営業ポータルシステム
２ 顧客応答システム
３ バッチ処理システム
４ 顧客ＤＢ
５ 関連付けＤＢ
５１ 契約関連情報
５１１ 契約番号
５１２ 地権者番号（属性者番号）
５１３ 町内会・自治会番号（情報番号）
５１４ 町内会・自治会役員番号（属性者番号）
６ 需給契約ＤＢ
６１ 契約情報
６１１ 契約番号
７１ 地権者情報（第１の顧客属性情報）
７１１ 地権者番号（属性者番号）
７１６ 契約番号
８１ 町内会・自治会情報（中間情報）
８１１ 町内会・自治会番号（情報番号）
８１５ 契約番号
９１ 町内会・自治会役員情報（第２の顧客属性情報）
９１１ 町内会・自治会役員番号（属性者番号）
９１２ 町内会・自治会番号（情報番号）

Claims (9)

1. 所定のサービスを提供する事業者と、前記サービスの需要家との間で交わされる契約に係り、当該契約に固有の番号である契約番号を含む契約情報と、
   前記需要家が有する顧客属性に係る情報であって、同じ前記顧客属性を有する前記需要家ごとに固有の番号である属性者番号及び前記契約番号を含む第１の顧客属性情報と、
   前記契約情報及び第２の顧客属性情報の両方に関連付けられる情報であって、自らに固有の情報番号及び前記契約番号を含む中間情報と、
   前記顧客属性に係る情報であって、前記属性者番号及び前記情報番号を含む前記第２の顧客属性情報と、
   を記憶する記憶部と、
   前記契約番号を取得し、
   取得した前記契約番号をキーとして前記記憶部内の前記第１の顧客属性情報を検索し、
   前記契約番号と、検索した結果該当した前記第１の顧客属性情報の前記属性者番号とを関連付けて前記記憶部に記憶するとともに、
   取得した前記契約番号をキーとして前記記憶部内の前記中間情報を検索し、
   検索した結果該当した前記中間情報の前記情報番号をキーとして前記記憶部内の前記第２の顧客属性情報を検索し、
   前記契約番号と、検索した結果該当した前記第２の顧客属性情報の前記属性者番号とを関連付けて前記記憶部に記憶する
   処理部と、
   を備えることを特徴とする顧客情報関連付けシステム。
2. 請求項１に記載の顧客情報関連付けシステムであって、
   前記第１の顧客属性情報は、地権者に係る情報であって、前記属性者番号としての地権者番号及び前記契約番号を含む地権者情報である
   ことを特徴とする顧客情報関連付けシステム。
3. 請求項１に記載の顧客情報関連付けシステムであって、
   前記中間情報は、町内会・自治会に係る情報であって、前記情報番号としての町内会・自治会番号及び前記契約番号を含む町内会・自治会情報であり、
   前記第２の顧客属性情報は、町内会・自治会役員に係る情報であって、前記属性者番号としての町内会・自治会役員番号及び前記情報番号としての前記町内会・自治会番号を含む町内会・自治会役員情報である
   ことを特徴とする顧客情報関連付けシステム。
4. 請求項１に記載の顧客情報関連付けシステムであって、
   前記処理部は、前記契約番号を取得し、前記記憶部において、前記契約番号に関連付けて記憶されている前記属性者番号を読み出し、読み出した前記属性者番号を含む前記第１の顧客属性情報又は前記第２の顧客属性情報を検索する
   ことを特徴とする顧客情報関連付けシステム。
5. 所定のサービスを提供する事業者と、前記サービスの需要家との間で交わされる契約に係り、当該契約に固有の番号である契約番号を含む契約情報と、
   前記需要家が有する顧客属性に係る情報であって、同じ前記顧客属性を有する前記需要家ごとに固有の番号である属性者番号及び前記契約番号を含む第１の顧客属性情報と、
   前記契約情報及び第２の顧客属性情報の両方に関連付けられる情報であって、自らに固有の情報番号及び前記契約番号を含む中間情報と、
   前記顧客属性に係る情報であって、前記属性者番号及び前記情報番号を含む前記第２の顧客属性情報と、
   を記憶する記憶部及び処理部を備えるコンピュータによって、顧客情報の関連付けを行う顧客情報関連付け方法であって、
   前記処理部は、
   前記契約番号を取得するステップと、
   取得した前記契約番号をキーとして前記記憶部内の前記第１の顧客属性情報を検索するステップと、
   前記契約番号と、検索した結果該当した前記第１の顧客属性情報の前記属性者番号とを関連付けて前記記憶部に記憶するステップと、
   取得した前記契約番号をキーとして前記記憶部内の前記中間情報を検索するステップと、
   検索した結果該当した前記中間情報の前記情報番号をキーとして前記記憶部内の前記第２の顧客属性情報を検索するステップと、
   前記契約番号と、検索した結果該当した前記第２の顧客属性情報の前記属性者番号とを関連付けて前記記憶部に記憶するステップと、
   を実行することを特徴とする顧客情報関連付け方法。
6. 請求項５に記載の顧客情報関連付け方法であって、
   前記処理部は、
   前記契約番号を取得するステップと、
   前記記憶部において、前記契約番号に関連付けて記憶されている前記属性者番号を読み出すステップと、
   読み出した前記属性者番号を含む前記第１の顧客属性情報又は前記第２の顧客属性情報を検索するステップと、
   をさらに実行することを特徴とする顧客情報関連付け方法。
7. 所定のサービスを提供する事業者と、前記サービスの需要家との間で交わされる契約に係り、当該契約に固有の番号である契約番号を含む契約情報と、
   前記需要家が有する顧客属性に係る情報であって、同じ前記顧客属性を有する前記需要家ごとに固有の番号である属性者番号及び前記契約番号を含む第１の顧客属性情報と、
   前記契約情報及び第２の顧客属性情報の両方に関連付けられる情報であって、自らに固有の情報番号及び前記契約番号を含む中間情報と、
   前記顧客属性に係る情報であって、前記属性者番号及び前記情報番号を含む前記第２の顧客属性情報と、
   を記憶する記憶部を備えるコンピュータに、
   前記契約番号を取得するステップと、
   取得した前記契約番号をキーとして前記記憶部内の前記第１の顧客属性情報を検索するステップと、
   前記契約番号と、検索した結果該当した前記第１の顧客属性情報の前記属性者番号とを関連付けて前記記憶部に記憶するステップと、
   取得した前記契約番号をキーとして前記記憶部内の前記中間情報を検索するステップと、
   検索した結果該当した前記中間情報の前記情報番号をキーとして前記記憶部内の前記第２の顧客属性情報を検索するステップと、
   前記契約番号と、検索した結果該当した前記第２の顧客属性情報の前記属性者番号とを関連付けて前記記憶部に記憶するステップと、
   を実行させることを特徴とする顧客情報関連付けプログラム。
8. 請求項７に記載の顧客情報関連付けプログラムであって、
   前記コンピュータに、
   前記契約番号を取得するステップと、
   前記記憶部において、前記契約番号に関連付けて記憶されている前記属性者番号を読み出すステップと、
   読み出した前記属性者番号を含む前記第１の顧客属性情報又は前記第２の顧客属性情報を検索するステップと、
   をさらに実行させることを特徴とする顧客情報関連付けプログラム。
9. 請求項７又は請求項８に記載の顧客情報関連付けプログラムを記録した、コンピュータ読み取り可能な記録媒体。