JP2004013403A - 顧客属性判定サーバおよびプログラム - Google Patents
顧客属性判定サーバおよびプログラム Download PDFInfo
- Publication number
- JP2004013403A JP2004013403A JP2002164283A JP2002164283A JP2004013403A JP 2004013403 A JP2004013403 A JP 2004013403A JP 2002164283 A JP2002164283 A JP 2002164283A JP 2002164283 A JP2002164283 A JP 2002164283A JP 2004013403 A JP2004013403 A JP 2004013403A
- Authority
- JP
- Japan
- Prior art keywords
- customer
- information
- attribute
- payment
- undetermined
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 claims description 37
- 238000012545 processing Methods 0.000 abstract description 40
- 230000010365 information processing Effects 0.000 abstract description 32
- 238000010586 diagram Methods 0.000 description 12
- 230000000694 effects Effects 0.000 description 12
- 238000004891 communication Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 230000012447 hatching Effects 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】顧客情報に含まれる未確定な顧客属性を適切に判定できる顧客属性判定サーバを提供することである。
【解決手段】ワークＤＢ生成部１２は、顧客ＤＢ２１から読み出した顧客情報と、決済履歴ファイル３１から読み出した決済履歴情報とに従って、統合情報を生成し、ワークＤＢ１１に格納する。決済履歴情報処理部１３は、生成した統合情報と決済履歴情報との関係に従って、統合情報における未確定な法人区分（属性情報）に「法人」を設定する。また、アクセスログ処理部１５は、アクセスログ取得部１４が取得したアクセスログＬとの関係に従って、未確定な法人区分に「法人」を設定する。顧客ＤＢ更新部１６は、更新後の統合情報に従って、顧客ＤＢ２１を更新する。
【選択図】 図５
【解決手段】ワークＤＢ生成部１２は、顧客ＤＢ２１から読み出した顧客情報と、決済履歴ファイル３１から読み出した決済履歴情報とに従って、統合情報を生成し、ワークＤＢ１１に格納する。決済履歴情報処理部１３は、生成した統合情報と決済履歴情報との関係に従って、統合情報における未確定な法人区分（属性情報）に「法人」を設定する。また、アクセスログ処理部１５は、アクセスログ取得部１４が取得したアクセスログＬとの関係に従って、未確定な法人区分に「法人」を設定する。顧客ＤＢ更新部１６は、更新後の統合情報に従って、顧客ＤＢ２１を更新する。
【選択図】 図５
Description
【０００１】
【発明の属する技術分野】
この発明は、顧客情報に含まれる未確定な顧客属性を適切に判定することのできる顧客属性判定サーバおよびプログラムに関する。
【０００２】
【従来の技術】
従来より、小売業者や通信販売業者等において、顧客の個人情報や販売実績情報等をデータベース化して、顧客管理や販売促進に利用してきた。近年では、インターネットを利用した商品等の販売（ネット販売）の普及に伴って、ＥＣ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ）サイトを運営する販売業者等においても、データベースマーケティングの技術が用いられている。
【０００３】
具体的にこれらの業者には、顧客に関する種々の顧客情報が顧客ＤＢ（データベース）に蓄積されている。そして、この顧客ＤＢを用いて、顧客に対する販売促進活動が行われている。最近では、顧客一人一人の利用・販売実績や嗜好などに応じた適切な販売促進活動を行うことが、費用対効果の関係からも重要となってきた。つまり、全顧客に対して一律に販売促進活動を行っても、費用に応じた効果が期待できず、そのような業者は、適切な販売促進活動を行っている業者との競争に負けてしまうというのが実状である。
そのため、各業者は、できるだけ正確な顧客情報を集めて顧客ＤＢに蓄積し、蓄積した顧客情報を有効活用して、個々の顧客に応じた販売促進活動を行うことを目指している。
【０００４】
ところで、販売促進活動の戦略・戦術を決める上で最も重要となるのが、その顧客が法人顧客（法人）であるか又は、一般顧客（個人）であるかという点である。これは、法人と個人とでは、購買目的から、購買数量・金額、購買決定要因、そして、購買の過程に至るまでが、大きく異なり、有効となる販売促進活動に違いが生じるためである。
そこで、個々の顧客に対して、法人・個人を区別し、適切な販売促進活動を行うことにより、活動費用に対する効果を大幅に向上させることが期待できる。
【０００５】
【発明が解決しようとする課題】
しかしながら、現実には、各業者において、法人・個人を区別できている顧客の数が極端に少ない。つまり、顧客ＤＢに蓄積した各顧客情報には、法人・個人を区別するための項目等が設けられているにも拘わらず、この項目に有効な情報が設定されている割合が極めて少ない（ほとんどが未設定のままである）。
これは、顧客情報の登録時に、このような項目が欠落していることに起因する。このような欠落項目を補完するために、電話による確認やアンケート調査なども考えられるが、多大な労力や費用が発生してしまうため、そのままに放置されているのが実状である。また、顧客ＤＢ中の顧客情報を常に最新の状態に維持し続けることも困難である。
【０００６】
一方で、企業情報（紳士録）等が登録された調査機関等のデータベースを活用して、法人・個人の区別がされていない顧客ＤＢ（顧客情報）に、有効な情報を設定することも考えられる。それでも、調査機関等のデータベースは、一般に、大企業等の情報を管理するに止まり、中小規模の企業や個人企業についての情報が含まれていないため、あまり実用的でない。
【０００７】
そのため、法人・個人等のような顧客情報に含まれる未確定な顧客属性を適切に判定する手法の確立が望まれていた。
【０００８】
この発明は、上記実状に鑑みてなされたもので、顧客情報に含まれる未確定な顧客属性を適切に判定することのできる顧客属性判定サーバおよびプログラムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、本発明の第１の観点に係る顧客属性判定サーバは、未確定の顧客属性が含まれる顧客情報を外部の記憶装置から読み出す顧客情報読み出し手段と、
顧客が行った決済取引の内容を示す決済情報を取得する決済情報取得手段と、前記顧客情報読み出し手段が読み出した顧客情報と、前記決済情報取得手段が取得した決済情報との関係に従って、該顧客情報に含まれる未確定の顧客属性を判定する顧客属性判定手段と、
前記顧客属性判定手段が判定した顧客属性に従って、前記顧客情報読み出し手段が読み出した顧客情報における未確定の顧客属性を更新し、更新後の顧客情報を外部の記憶装置に書き戻す顧客情報書き出し手段と、
を備えることを特徴とする。
【００１０】
この発明によれば、顧客情報読み出し手段は、未確定の顧客属性（例えば、法人区分等）が含まれる顧客情報を外部の記憶装置（例えば、顧客ＤＢ）から読み出す。決済情報取得手段は、顧客が行った決済取引の内容を示す決済情報を、例えば、外部の決済システムから取得する。顧客属性判定手段は、顧客情報読み出し手段が読み出した顧客情報と、決済情報取得手段が取得した決済情報との関係に従って、該顧客情報に含まれる未確定の顧客属性を判定する。顧客情報書き出し手段は、顧客属性判定手段が判定した顧客属性に従って、顧客情報読み出し手段が読み出した顧客情報における未確定の顧客属性を更新し、更新後の顧客情報を外部の記憶装置に書き戻す。この結果、顧客情報に含まれる未確定な顧客属性を適切に判定することができる。
【００１１】
上記の顧客属性判定サーバは、顧客による所定システムの利用に伴い生じた、確定済みの顧客属性が含まれるアクセス情報を、例えば、ネットワークを介して取得するアクセス情報取得手段を更に備え、
前記顧客属性判定手段は、顧客情報読み出し手段が読み出した顧客情報と、前記アクセス情報取得手段が取得したアクセス情報との関係に従って、該顧客情報に含まれる未確定の顧客属性を判定してもよい。
【００１２】
上記目的を達成するため、本発明の第２の観点に係る顧客属性判定サーバは、確定済み及び未確定の顧客属性が含まれる顧客情報を、外部の顧客データベースから読み出す顧客情報読み出し手段と、
顧客が行った決済取引における決済手法の固有情報が含まれる決済情報を外部の決済システムから取得する決済情報取得手段と、
前記顧客情報読み出し手段が読み出した顧客情報と、前記決済情報取得手段が取得した決済情報とから、同一顧客単位に統合した統合情報を生成する統合情報生成手段と、
前記統合情報生成手段が生成した統合情報における確定済みの顧客属性及び、固有情報の関係に従って、該統合情報における未確定の顧客属性を判定する顧客属性判定手段と、
前記顧客属性判定手段が判定した顧客属性に従って、前記統合情報生成手段が生成した統合情報における未確定の顧客属性を更新する統合情報更新手段と、
前記統合情報更新手段により未確定の顧客属性が更新された統合情報に従って、外部の顧客データベースに顧客情報を書き戻す顧客情報書き出し手段と、
を備えることを特徴とする。
【００１３】
この発明によれば、顧客情報読み出し手段は、確定済み及び未確定の顧客属性（例えば、法人区分等）が含まれる顧客情報を、外部の顧客データベースから読み出す。決済情報取得手段は、顧客が行った決済取引における決済手法の固有情報（例えば、口座番号やクレジット番号等）が含まれる決済情報を外部の決済システムから取得する。統合情報生成手段は、顧客情報読み出し手段が読み出した顧客情報と、決済情報取得手段が取得した決済情報とから、同一顧客単位に統合した統合情報を生成する。顧客属性判定手段は、統合情報生成手段が生成した統合情報における確定済みの顧客属性及び、固有情報の関係に従って、該統合情報における未確定の顧客属性を判定する。統合情報更新手段は、顧客属性判定手段が判定した顧客属性に従って、統合情報生成手段が生成した統合情報における未確定の顧客属性を更新する。顧客情報書き出し手段は、統合情報更新手段により未確定の顧客属性が更新された統合情報に従って、外部の顧客データベースに顧客情報を書き戻す。この結果、顧客情報に含まれる未確定な顧客属性を適切に判定することができる。
【００１４】
上記の顧客属性判定サーバは、顧客による所定システムの利用に伴い生じた、確定済みの顧客属性が含まれるアクセス情報を、所定のネットワークを介して取得するアクセス情報取得手段と、
前記アクセス情報取得手段が取得したアクセス情報を、前記統合情報生成手段が生成した統合情報に基づいて名寄せする名寄せ手段と、を更に備え、
前記顧客属性判定手段は、前記統合情報生成手段が生成した統合情報と、前記名寄せ手段が名寄せしたアクセス情報との関係に従って、該統合情報における未確定の顧客属性を判定してもよい。
【００１５】
上記目的を達成するため、本発明の第３の観点に係るプログラムは、
コンピュータに、未確定の顧客属性が含まれる顧客情報を外部の記憶装置から読み出す顧客情報読み出しステップと、顧客が行った取引の内容を示す取引内容情報を取得する取引内容情報取得ステップと、前記顧客情報読み出しステップにて読み出された顧客情報と、前記取引内容情報取得ステップにて取得された取引内容情報との関係に従って、該顧客情報に含まれる未確定の顧客属性を判定する顧客属性判定ステップと、前記顧客属性判定ステップにて判定された顧客属性に従って、前記顧客情報読み出しステップにて読み出された顧客情報における未確定の顧客属性を更新し、更新後の顧客情報を外部の記憶装置に書き戻す顧客情報書き出しステップと、を実行させることを特徴とする。
【００１６】
【発明の実施の形態】
本発明の実施の形態にかかる法人判定サーバについて、以下図面を参照して説明する。
【００１７】
図１は、この発明の実施の形態に適用される法人判定サーバを含んだシステムの構成の一例を示すブロック図である。図示するように、このシステムは、法人判定サーバ１と、顧客管理システム２と、決済システム３とから構成される。なお、法人判定サーバ１は、ネットワークＮと接続されている。
【００１８】
法人判定サーバ１は、汎用のサーバ装置等からなり、顧客管理システム２（顧客ＤＢ２１）の顧客情報と、決済システム３（決済履歴ファイル３１）の決済履歴情報との突き合わせを行い、顧客情報における未確定の顧客属性（一例として、後述する法人区分）を自動的に判定する。また、法人判定サーバ１は、ネットワークＮから取得したアクセスログＬとも突き合わせを行い、未確定の顧客属性を自動的に判定する。
なお、法人判定サーバ１の詳細については、後述する。
【００１９】
顧客管理システム２は、例えば、販売業者等に配置されたホスト機やサーバ装置等からなり、顧客に関する種々の顧客情報を管理する。具体的に顧客管理システム２は、顧客ＤＢ２１を備えており、この顧客ＤＢ２１にて顧客情報を管理する。
【００２０】
顧客ＤＢ２１は、一例として、図２に示すような、氏名、法人区分、住所、及び、電話番号等の項目（１レコード）からなる顧客情報を記憶する。ここで、法人区分とは、その顧客が法人であるか又は、個人であるかを表すための項目である。つまり、法人顧客の場合には、「法人」が設定され、また、個人顧客の場合には、「個人」が設定される。なお、法人・個人が未確定である場合には、「不定」が設定される。
【００２１】
図１に戻って、決済システム３は、例えば、所定の決済処理を行うホスト機やサーバ装置等からなり、顧客による決済取引の内容を示す決済履歴情報を管理する。なお、決済システム３は、顧客管理システム２とは別個に運営される基幹システムであり、保持する情報（顧客に関する決済履歴情報）も顧客管理システム２にて管理される情報と異なる。
具体的に決済システム３は、決済履歴ファイル３１を備えており、この決済履歴ファイル３１にて、決済履歴情報を管理する。
【００２２】
決済履歴ファイル３１は、一例として、図３に示すような、氏名、支払口座番号、支払クレジット番号、商品名、及び、販売金額等の項目（１レコード）からなる決済履歴情報を記憶する。ここで、支払口座番号及び支払クレジット番号は、決済取引における決済手法を特定する固有の決済特定情報（固有情報）である。
つまり、支払口座番号は、決済手段として金融機関からの口座引き落としが使用された場合に、その金融機関（店舗）及び口座番号を表すコード情報である。一方、支払クレジット番号は、決済手段としてクレジット会社の与信が使用された場合に、そのクレジット会社におけるクレジットカード番号を表すコード情報である。
【００２３】
図１に戻って、ネットワークＮは、インターネットやイントラネット等からなる。そして、顧客によりネットワークＮ上の所定システムが利用された際に、利用取引内容等を示すアクセスログＬが法人判定サーバ１に送信される。
アクセスログＬは、一例として、図４に示すように、氏名、法人区分、住所、電話番号、アクセス時刻、パス、及び、商品名等の項目（１ログレコード）からなる情報である。
なお、このようなアクセスログＬは、顧客の大切な個人情報となるため、予め顧客の同意が得られた情報だけが、活用されるものとする。
【００２４】
以下、法人判定サーバ１について、図５を参照して、詳細に説明する。図５は、法人判定サーバ１の構成の一例を示すブロック図である。
法人判定サーバ１は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、メモリ、ハードディスク、ネットワークカード等のハードウェア構成からなるサーバ装置であり、図示するように、ワークＤＢ１１と、ワークＤＢ生成部１２と、決済履歴情報処理部１３と、アクセスログ取得部１４と、アクセスログ処理部１５と、顧客ＤＢ更新部１６とを含んで構成される。
【００２５】
ワークＤＢ１１は、顧客情報に含まれる未確定な法人区分を、確定（判定）するために使用されるデータベースであり、例えば、上述の図２に示す顧客ＤＢ２１の顧客情報と、図３の決済履歴ファイル３１の決済履歴情報とが統合された統合情報を記憶する。
ワークＤＢ１１は、例えば、図６に示すような、氏名、法人区分、支払口座番号、支払クレジット番号、住所、及び、電話番号等の項目からなる統合情報を記憶する。
【００２６】
図５に戻って、ワークＤＢ生成部１２は、顧客ＤＢ２１から読み出した顧客情報と、決済履歴ファイル３１から読み出した決済履歴情報とを統合し、上述の統合情報を生成してワークＤＢ１１に格納する。
なお、このワークＤＢ生成部１２とは、詳細には、法人判定サーバ１にて実行されるアプリケーションプログラムの機能の１つを抽象化したものである。
【００２７】
決済履歴情報処理部１３は、ワークＤＢ１１に記憶された統合情報（構成レコード）の関連や、決済履歴ファイル３１から新たに読み出された決済履歴情報と統合情報との関係に従って、統合情報中の未確定な法人区分（顧客属性）を判定により確定する。
なお、この決済履歴情報処理部１３も、詳細には、法人判定サーバ１にて実行されるアプリケーションプログラムの機能の１つを抽象化したものである。
【００２８】
アクセスログ取得部１４は、ネットワークＮから送信されるアクセスログＬを取得し、アクセスログ処理部１５に供給する。
アクセスログ処理部１５は、ワークＤＢ１１に記憶された統合情報と、アクセスログ取得部１４により取得されたアクセスログＬ（構成するログレコード）との関係に従って、統合情報中の未確定な法人区分を判定により確定する。
なお、このアクセスログ処理部１５も、詳細には、法人判定サーバ１にて実行されるアプリケーションプログラムの機能の１つを抽象化したものである。
【００２９】
顧客ＤＢ更新部１６は、決済履歴情報処理部１３及びアクセスログ処理部１５により、ワークＤＢ１１における統合情報の未確定な法人区分が確定されると、統合情報に従って、顧客ＤＢ２１の顧客情報を更新する。
同様に、この顧客ＤＢ更新部１６も、詳細には、法人判定サーバ１にて実行されるアプリケーションプログラムの機能の１つを抽象化したものである。
【００３０】
以下、この発明の実施の形態にかかる法人判定サーバ１の動作について、図面を参照して説明する。なお、後述するワークＤＢ生成部１２、決済履歴情報処理部１３、及び、アクセスログ処理部１５がそれぞれ実行する処理は、具体的には、法人判定サーバ１のＣＰＵによって、ハードディスク等に記憶された各プログラムが読み出され、そして、メモリ等の資源が適宜利用されて実行される。
【００３１】
最初に、ワークＤＢ生成部１２が実行するワークＤＢ生成処理について、図７のフローチャート等を参照して説明する。このワークＤＢ生成処理は、顧客ＤＢ２１に確定済み及び未確定の法人区分（顧客属性）が含まれる顧客情報が格納され、また、決済履歴ファイル３１に所定数の決済履歴情報が格納された状態で、開始される。
【００３２】
まず、ワークＤＢ生成部１２は、顧客ＤＢ２１から氏名及び法人区分等の項目が含まれる顧客情報を読み出し、ワークＤＢ１１に格納する（ステップＳ１１）。
具体的にワークＤＢ生成部１２は、図８（ａ）に示すような複数レコードから構成される顧客情報をワークＤＢ１１に格納する。
【００３３】
ワークＤＢ生成部１２は、ワークＤＢ１１に格納した各レコードに決済特定情報を格納するための領域を確保する（ステップＳ１２）。
具体的にワークＤＢ生成部１２は、図８（ｂ）において網掛けにて示すように、支払口座番号及び支払クレジット番号からなる決済特定情報を格納するためのエリアをワークＤＢ１１の各レコードに確保する。
【００３４】
ワークＤＢ生成部１２は、所定の順番に従って、ワークＤＢ１１の１つのレコードから氏名の項目を読み出し、この氏名をキーにして、決済履歴ファイル３１から合致する決済履歴情報（レコード）を検索する（ステップＳ１３）。
ワークＤＢ生成部１２は、検索により対象となる決済履歴情報が存在するか否かを判別する（ステップＳ１４）。ワークＤＢ生成部１２は、対象の決済履歴情報が存在しないと判別すると、後述するステップＳ１６に処理を進める。
【００３５】
一方、対象の決済履歴情報が存在すると判別した場合に、ワークＤＢ生成部１２は、その決済履歴情報（レコード）から決済特定情報を読み出し、読み出した決済特定情報をワークＤＢ１１のレコードに格納する（ステップＳ１５）。すなわち、ワークＤＢ生成部１２は、検索した決済履歴情報（レコード）から支払口座番号や支払クレジット番号の項目を読み出し、読み出した情報をワークＤＢ１１の同一顧客のレコードにセットする。
具体的にワークＤＢ生成部１２は、図８（ｃ）において網掛けにて示すように、ワークＤＢ１１のレコードに、支払口座番号や支払クレジット番号の項目をセットする。
【００３６】
ワークＤＢ生成部１２は、ＤＢの生成が完了したか否かを判別する（ステップＳ１６）。すなわち、ワークＤＢ１１の全レコードに対して、決済履歴ファイル３１の検索を行って、同一顧客の決済特定情報を読み出してレコードにセット済みであるか否かを判別する。
ワークＤＢ生成部１２は、ＤＢの生成が完了していないと判別した場合に、ステップＳ１３に処理を戻し、上述のステップＳ１３〜Ｓ１６の処理を繰り返し実行する。一方、ＤＢの生成が完了したと判別すると、ワークＤＢ生成部１２は、ワークＤＢ生成処理を終える。
【００３７】
このようなワークＤＢ生成処理により、顧客ＤＢ２１の顧客情報と、決済履歴ファイル３１の決済履歴情報とが同一顧客単位に統合され、統合された統合情報がワークＤＢ１１に格納される。
【００３８】
次に、決済履歴情報処理部１３が実行する第１の法人判定処理について、図９に示すフローチャート等を参照して説明する。この第１の法人判定処理は、上述した図７に示すワークＤＢ生成処理により、ワークＤＢ１１が生成された後に開始される。
【００３９】
まず、決済履歴情報処理部１３は、ワークＤＢ１１にて法人区分が確定されているレコードと同一の決済特定情報を有するレコードを、ワークＤＢ１１内にて検索する（ステップＳ２０）。
具体的に決済履歴情報処理部１３は、図１０（ａ）の統合情報において、法人区分が既に「法人」と設定されているレコードｒ１の決済特定情報（この場合、支払口座番号）と同じ決済特定情報を有するレコード（法人区分が「不定」のレコード）を検索する。
【００４０】
決済履歴情報処理部１３は、検索により対象となるレコードが存在するか否かを判別する（ステップＳ２１）。決済履歴情報処理部１３は、対象のレコードが存在しないと判別した場合、後述するステップＳ２３に処理を進める。
【００４１】
一方、対象のレコードが存在すると判別した場合に、決済履歴情報処理部１３は、対象レコードの法人区分に「法人」を設定する（ステップＳ２２）。
具体的に図１０（ａ）に示すように、レコードｒ１の支払口座番号と同じ支払口座番号を有するレコードｒ２が検索されたとする。この場合、レコードｒ２は、レコードｒ１と氏名が異なるにも拘わらず同一の支払口座番号を使用して決済が行われているため、法人であると判定できる。従って、決済履歴情報処理部１３は、レコードｒ２の法人区分を「法人」に確定する。
【００４２】
決済履歴情報処理部１３は、このような検索及び確定を、法人区分が既に「法人」と設定されている全レコードを対象にして行う。
ここまでの処理により、法人区分が「法人」として確定済みの顧客と、同じ決済手段を用いる別名称の顧客が存在する場合に、その顧客も法人であると判定でき、その顧客の法人区分を「法人」に確定できる。
【００４３】
続いて、決済履歴情報処理部１３は、法人区分が未確定（「不定」）のレコードの内、同一の決済特定情報であり、かつ、異なる氏名となるレコードを、ワークＤＢ１１内にて検索する（ステップＳ２３）。
具体的に決済履歴情報処理部１３は、図１０（ｂ）の統合情報において、法人区分が「不定」と設定されているレコードの内、決済特定情報が同一で、かつ、氏名が異なるレコードを検索する。
【００４４】
決済履歴情報処理部１３は、検索により対象となるレコードが存在するか否かを判別する（ステップＳ２４）。決済履歴情報処理部１３は、対象のレコードが存在しないと判別した場合、後述するステップＳ２６に処理を進める。
【００４５】
一方、対象のレコードが存在すると判別した場合に、決済履歴情報処理部１３は、対象レコードの法人区分に「法人」を設定する（ステップＳ２５）。
具体的に、図１０（ｂ）に示すように、法人区分が「不定」と設定されているレコードの内、支払口座番号が同一で、かつ、氏名が異なるレコードｒ３，ｒ４が検索されたとする。この場合、レコードｒ３，ｒ４は、それぞれ氏名が異なるにも拘わらず同一の支払口座番号を使用して決済が行われているため、法人であると判定できる。従って、決済履歴情報処理部１３は、レコードｒ３，ｒ４の法人区分を「法人」に確定する。
【００４６】
決済履歴情報処理部１３は、このような検索及び確定を、法人区分が未だ「不定」と設定されている全レコードを対象にして行う。
ここまでの処理により、法人区分が未確定の顧客同士が、同じ決済手段を用いている場合に、無関係の個人同士が同じ決済手段を使うことが原則あり得ないことから、それらの顧客も法人であると判定でき、それぞれの法人区分を「法人」に確定できる。
【００４７】
続いて、決済履歴情報処理部１３は、新たな決済履歴情報を決済履歴ファイル３１から読み出す（ステップＳ２６）。
決済履歴情報処理部１３は、読み出した決済履歴情報と同一の決済特定情報で、かつ、異なる氏名となるレコードをワークＤＢ１１から検索する（ステップＳ２７）。
具体的に決済履歴情報処理部１３は、図１０（ｃ）に示すように、決済履歴ファイル３１から読み出したレコードｒ５の決済特定情報と、同じ決済特定情報を有するレコードをワークＤＢ１１から検索する。
【００４８】
決済履歴情報処理部１３は、検索により対象となるレコードが存在するか否かを判別する（ステップＳ２８）。決済履歴情報処理部１３は、対象のレコードが存在しないと判別した場合、第１の法人判定処理を終了する。
【００４９】
一方、対象のレコードが存在すると判別した場合に、決済履歴情報処理部１３は、対象レコードの法人区分に「法人」を設定する（ステップＳ２９）。
具体的に、図１０（ｃ）に示すように、レコードｒ５の支払口座番号と同じ支払口座番号を有するレコードｒ６が検索されたとする。この場合、レコードｒ６は、レコードｒ５と氏名が異なるにも拘わらず同一の支払口座番号を使用して決済を行っているため、法人であると判定できる。従って、決済履歴情報処理部１３は、レコードｒ６の法人区分を「法人」に確定する。
【００５０】
決済履歴情報処理部１３は、このような検索及び確定を、新たに決済履歴ファイル３１から読み出された全ての決済履歴情報を対象にして行う。
ここまでの処理により、新たな決済履歴情報を利用して、同じ決済手段を用いている顧客が見つかった場合に、無関係の個人同士が同じ決済手段を使うことが原則あり得ないことから、この顧客の法人区分も「法人」に確定できる。
【００５１】
このように、上述した図９に示す第１の法人判定処理によって、顧客情報に含まれる未確定な顧客属性（この場合、法人区分）を適切に判定することができる。
【００５２】
次に、アクセスログ処理部１５が実行する第２の法人判定処理について、図１１に示すフローチャート等を参照して説明する。この第２の法人判定処理は、例えば、上述した図９に示す第１の法人判定処理が終了し、アクセスログ取得部１４にて取得されたアクセスログＬがアクセスログ処理部１５に供給された後に、開始される。
【００５３】
まず、アクセスログ処理部１５は、アクセスログ取得部１４から供給されたアクセスログＬの内、法人区分が「法人」と設定されているログレコードを抽出する（ステップＳ３１）。
アクセスログ処理部１５は、抽出したログレコードを、ワークＤＢ１１の統合情報を基準として名寄せする（ステップＳ３２）。
【００５４】
アクセスログ処理部１５は、名寄せしたログレコードと、同一の属性情報となるレコードをワークＤＢ１１から検索する（ステップＳ３３）。
具体的にアクセスログ処理部１５は、図１２（ａ）に示すように、法人区分が「法人」と設定されているログレコードｒ７の属性情報（この場合、住所及び電話番号）と同じ属性情報を有するレコードをワークＤＢ１１から検索する。
【００５５】
アクセスログ処理部１５は、検索により対象となるレコードが存在するか否かを判別する（ステップＳ３４）。アクセスログ処理部１５は、対象のレコードが存在しないと判別した場合、後述するステップＳ３６に処理を進める。
【００５６】
一方、対象のレコードが存在すると判別した場合に、アクセスログ処理部１５は、対象レコードの法人区分に「法人」を設定する（ステップＳ３５）。
具体的に、図１２（ａ）に示すように、ログレコードｒ７の属性情報と同じ属性情報（この場合、住所及び電話番号）を有するレコードｒ８が検索されたとする。この場合、レコードｒ８は、ログレコードｒ７と住所及び電話番号が同一であるため、同一法人であると判定できる。従って、アクセスログ処理部１５は、レコードｒ８の法人区分を「法人」に確定する。
【００５７】
アクセスログ処理部１５は、このような検索及び確定を、全てのログレコードを対象にして行う。
ここまでの処理により、法人区分が「法人」として確定済みの顧客と、同じ住所及び電話番号を有する顧客が存在する場合に、その顧客も法人であると判定でき、その顧客の法人区分を「法人」に確定できる。
【００５８】
続いて、アクセスログ処理部１５は、今回、法人区分を「法人」に確定したレコードと、同一の決済特定情報となるレコードを、ワークＤＢ１１内にて検索する（ステップＳ３６）。
具体的にアクセスログ処理部１５は、図１２（ｂ）に示すように、今回（ステップＳ３５にて）、法人と確定したレコードｒ８と、決済特定情報（この場合支払口座番号）が同一となるレコードを、ワークＤＢ１１から検索する。
【００５９】
アクセスログ処理部１５は、検索により対象となるレコードが存在するか否かを判別する（ステップＳ３７）。アクセスログ処理部１５は、対象のレコードが存在しないと判別した場合、第２の法人判定処理を終了する。
【００６０】
一方、対象のレコードが存在すると判別した場合に、アクセスログ処理部１５は、対象レコードの法人区分に「法人」を設定する（ステップＳ３８）。
具体的に、図１２（ｂ）に示すように、レコードｒ８の支払口座番号と同じ支払口座番号を有するレコードｒ９が検索されたとする。この場合、レコードｒ９は、レコードｒ８と氏名が異なるにも拘わらず同一の支払口座番号を使用して決済を行っているため、法人であると判定できる。従って、アクセスログ処理部１５は、レコードｒ９の法人区分を「法人」に確定する。
【００６１】
決済履歴情報処理部１３は、このような検索及び確定を、今回（ステップＳ３５にて）、法人と確定した全てのレコードを対象にして行う。
ここまでの処理により、法人区分が「法人」として確定済みの顧客と、同じ決済手段を用いる別名称の顧客が存在する場合に、その顧客も法人であると判定でき、その顧客の法人区分を「法人」に確定できる。
【００６２】
このように、上述した図１１に示す第２の法人判定処理によって、顧客情報に含まれる未確定な顧客属性（この場合、法人区分）を適切に判定することができる。
【００６３】
上述した決済履歴情報処理部１３による第１の法人判定処理及び、アクセスログ処理部１５による第２の法人判定処理が行われると、顧客ＤＢ更新部１６は、更新後のワークＤＢ１１の内容を顧客ＤＢ２１に反映する。
具体的に顧客ＤＢ更新部１６は、図１３に示すような、法人区分が確定した統合情報に従って、顧客ＤＢ２１を更新する。
【００６４】
この結果、法人判定サーバ１は、顧客情報に含まれる未確定な顧客属性（この場合、法人区分）を適切に判定し、そして確定することができる。
【００６５】
上記の実施の形態では、顧客管理システム２と別個に構築され運営されている決済システム３（決済履歴ファイル３１）を活用して、顧客ＤＢ２１における未確定な属性情報を判定（確定）した。しかしながら、この決済システム３（決済履歴ファイル３１）は、一例であり、信頼性の高い属性情報を含んだ他のシステムを活用して顧客ＤＢ２１における未確定な属性情報を判定（確定）してもよい。
【００６６】
また、上記の実施の形態では、判定（確定）対象となる未確定な属性情報として、法人区分を一例として説明したが、対象となるのは法人区分に限られず顧客情報における他の属性情報であってもよい。
【００６７】
また、上記の実施の形態では、決済特定情報として支払口座番号及び支払クレジット番号を使用する場合について説明したが、他の情報（例えば、電子マネーのコード番号等）を決済特定情報として使用してもよい。
【００６８】
なお、この発明の実施の形態にかかる法人判定サーバは、専用機器によらず、通常のコンピュータシステムを用いて実現可能である。例えば、通信機能を備えたコンピュータに上述のいずれかを実行するためのプログラムを格納した媒体（フレキシブルディスク、ＣＤ−ＲＯＭ等）から当該プログラムをインストールすることにより、上述の処理を実行する法人判定サーバを構成することができる。
【００６９】
また、コンピュータにプログラムを供給するための手法は、任意である。例えば、通信回線、通信ネットワーク、通信システム等を介して供給してもよい。一例を挙げると、通信ネットワークの掲示板（ＢＢＳ）に当該プログラムを掲示し、これをネットワークを介して搬送波に重畳して配信する。
そして、このプログラムを起動し、ＯＳの制御下で、他のアプリケーションプログラムと同様に実行することにより、上述の処理を実行することができる。
【００７０】
【発明の効果】
以上説明したように、本発明によれば、顧客情報に含まれる未確定な顧客属性を適切に判定することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る法人判定サーバを含んだシステムの構成の一例を示す模式図である。
【図２】顧客ＤＢの構成の一例を示す模式図である。
【図３】決済履歴ファイルの構成の一例を示す模式図である。
【図４】アクセスログの構成の一例を示す模式図である。
【図５】本発明の実施の形態に係る法人判定サーバの構成の一例を示すブロック図である。
【図６】ワークＤＢの構成の一例を示す模式図である。
【図７】本発明の実施の形態に係るワークＤＢ生成処理を説明するためのフローチャートである。
【図８】（ａ）〜（ｃ）共に、ワークＤＢ生成処理にて生成されるワークＤＢの具体例を説明するための模式図である。
【図９】本発明の実施の形態に係る第１の法人判定処理を説明するためのフローチャートである。
【図１０】（ａ）〜（ｃ）共に、第１の法人判定処理の具体的な動作を説明するための模式図である。
【図１１】本発明の実施の形態に係る第２の法人判定処理を説明するためのフローチャートである。
【図１２】（ａ），（ｂ）共に、第２の法人判定処理の具体的な動作を説明するための模式図である。
【図１３】第１及び第２の法人判定処理後のワークＤＢの一例を示す模式図である。
【符号の説明】
１ 法人判定サーバ
１１ ワークＤＢ
１２ ワークＤＢ生成部
１３ 決済履歴情報処理部
１４ アクセスログ取得部
１５ アクセスログ処理部
１６ 顧客ＤＢ更新部
２ 顧客管理システム
２１ 顧客ＤＢ
３ 決済システム
３１ 決済履歴ファイル
【発明の属する技術分野】
この発明は、顧客情報に含まれる未確定な顧客属性を適切に判定することのできる顧客属性判定サーバおよびプログラムに関する。
【０００２】
【従来の技術】
従来より、小売業者や通信販売業者等において、顧客の個人情報や販売実績情報等をデータベース化して、顧客管理や販売促進に利用してきた。近年では、インターネットを利用した商品等の販売（ネット販売）の普及に伴って、ＥＣ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ）サイトを運営する販売業者等においても、データベースマーケティングの技術が用いられている。
【０００３】
具体的にこれらの業者には、顧客に関する種々の顧客情報が顧客ＤＢ（データベース）に蓄積されている。そして、この顧客ＤＢを用いて、顧客に対する販売促進活動が行われている。最近では、顧客一人一人の利用・販売実績や嗜好などに応じた適切な販売促進活動を行うことが、費用対効果の関係からも重要となってきた。つまり、全顧客に対して一律に販売促進活動を行っても、費用に応じた効果が期待できず、そのような業者は、適切な販売促進活動を行っている業者との競争に負けてしまうというのが実状である。
そのため、各業者は、できるだけ正確な顧客情報を集めて顧客ＤＢに蓄積し、蓄積した顧客情報を有効活用して、個々の顧客に応じた販売促進活動を行うことを目指している。
【０００４】
ところで、販売促進活動の戦略・戦術を決める上で最も重要となるのが、その顧客が法人顧客（法人）であるか又は、一般顧客（個人）であるかという点である。これは、法人と個人とでは、購買目的から、購買数量・金額、購買決定要因、そして、購買の過程に至るまでが、大きく異なり、有効となる販売促進活動に違いが生じるためである。
そこで、個々の顧客に対して、法人・個人を区別し、適切な販売促進活動を行うことにより、活動費用に対する効果を大幅に向上させることが期待できる。
【０００５】
【発明が解決しようとする課題】
しかしながら、現実には、各業者において、法人・個人を区別できている顧客の数が極端に少ない。つまり、顧客ＤＢに蓄積した各顧客情報には、法人・個人を区別するための項目等が設けられているにも拘わらず、この項目に有効な情報が設定されている割合が極めて少ない（ほとんどが未設定のままである）。
これは、顧客情報の登録時に、このような項目が欠落していることに起因する。このような欠落項目を補完するために、電話による確認やアンケート調査なども考えられるが、多大な労力や費用が発生してしまうため、そのままに放置されているのが実状である。また、顧客ＤＢ中の顧客情報を常に最新の状態に維持し続けることも困難である。
【０００６】
一方で、企業情報（紳士録）等が登録された調査機関等のデータベースを活用して、法人・個人の区別がされていない顧客ＤＢ（顧客情報）に、有効な情報を設定することも考えられる。それでも、調査機関等のデータベースは、一般に、大企業等の情報を管理するに止まり、中小規模の企業や個人企業についての情報が含まれていないため、あまり実用的でない。
【０００７】
そのため、法人・個人等のような顧客情報に含まれる未確定な顧客属性を適切に判定する手法の確立が望まれていた。
【０００８】
この発明は、上記実状に鑑みてなされたもので、顧客情報に含まれる未確定な顧客属性を適切に判定することのできる顧客属性判定サーバおよびプログラムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、本発明の第１の観点に係る顧客属性判定サーバは、未確定の顧客属性が含まれる顧客情報を外部の記憶装置から読み出す顧客情報読み出し手段と、
顧客が行った決済取引の内容を示す決済情報を取得する決済情報取得手段と、前記顧客情報読み出し手段が読み出した顧客情報と、前記決済情報取得手段が取得した決済情報との関係に従って、該顧客情報に含まれる未確定の顧客属性を判定する顧客属性判定手段と、
前記顧客属性判定手段が判定した顧客属性に従って、前記顧客情報読み出し手段が読み出した顧客情報における未確定の顧客属性を更新し、更新後の顧客情報を外部の記憶装置に書き戻す顧客情報書き出し手段と、
を備えることを特徴とする。
【００１０】
この発明によれば、顧客情報読み出し手段は、未確定の顧客属性（例えば、法人区分等）が含まれる顧客情報を外部の記憶装置（例えば、顧客ＤＢ）から読み出す。決済情報取得手段は、顧客が行った決済取引の内容を示す決済情報を、例えば、外部の決済システムから取得する。顧客属性判定手段は、顧客情報読み出し手段が読み出した顧客情報と、決済情報取得手段が取得した決済情報との関係に従って、該顧客情報に含まれる未確定の顧客属性を判定する。顧客情報書き出し手段は、顧客属性判定手段が判定した顧客属性に従って、顧客情報読み出し手段が読み出した顧客情報における未確定の顧客属性を更新し、更新後の顧客情報を外部の記憶装置に書き戻す。この結果、顧客情報に含まれる未確定な顧客属性を適切に判定することができる。
【００１１】
上記の顧客属性判定サーバは、顧客による所定システムの利用に伴い生じた、確定済みの顧客属性が含まれるアクセス情報を、例えば、ネットワークを介して取得するアクセス情報取得手段を更に備え、
前記顧客属性判定手段は、顧客情報読み出し手段が読み出した顧客情報と、前記アクセス情報取得手段が取得したアクセス情報との関係に従って、該顧客情報に含まれる未確定の顧客属性を判定してもよい。
【００１２】
上記目的を達成するため、本発明の第２の観点に係る顧客属性判定サーバは、確定済み及び未確定の顧客属性が含まれる顧客情報を、外部の顧客データベースから読み出す顧客情報読み出し手段と、
顧客が行った決済取引における決済手法の固有情報が含まれる決済情報を外部の決済システムから取得する決済情報取得手段と、
前記顧客情報読み出し手段が読み出した顧客情報と、前記決済情報取得手段が取得した決済情報とから、同一顧客単位に統合した統合情報を生成する統合情報生成手段と、
前記統合情報生成手段が生成した統合情報における確定済みの顧客属性及び、固有情報の関係に従って、該統合情報における未確定の顧客属性を判定する顧客属性判定手段と、
前記顧客属性判定手段が判定した顧客属性に従って、前記統合情報生成手段が生成した統合情報における未確定の顧客属性を更新する統合情報更新手段と、
前記統合情報更新手段により未確定の顧客属性が更新された統合情報に従って、外部の顧客データベースに顧客情報を書き戻す顧客情報書き出し手段と、
を備えることを特徴とする。
【００１３】
この発明によれば、顧客情報読み出し手段は、確定済み及び未確定の顧客属性（例えば、法人区分等）が含まれる顧客情報を、外部の顧客データベースから読み出す。決済情報取得手段は、顧客が行った決済取引における決済手法の固有情報（例えば、口座番号やクレジット番号等）が含まれる決済情報を外部の決済システムから取得する。統合情報生成手段は、顧客情報読み出し手段が読み出した顧客情報と、決済情報取得手段が取得した決済情報とから、同一顧客単位に統合した統合情報を生成する。顧客属性判定手段は、統合情報生成手段が生成した統合情報における確定済みの顧客属性及び、固有情報の関係に従って、該統合情報における未確定の顧客属性を判定する。統合情報更新手段は、顧客属性判定手段が判定した顧客属性に従って、統合情報生成手段が生成した統合情報における未確定の顧客属性を更新する。顧客情報書き出し手段は、統合情報更新手段により未確定の顧客属性が更新された統合情報に従って、外部の顧客データベースに顧客情報を書き戻す。この結果、顧客情報に含まれる未確定な顧客属性を適切に判定することができる。
【００１４】
上記の顧客属性判定サーバは、顧客による所定システムの利用に伴い生じた、確定済みの顧客属性が含まれるアクセス情報を、所定のネットワークを介して取得するアクセス情報取得手段と、
前記アクセス情報取得手段が取得したアクセス情報を、前記統合情報生成手段が生成した統合情報に基づいて名寄せする名寄せ手段と、を更に備え、
前記顧客属性判定手段は、前記統合情報生成手段が生成した統合情報と、前記名寄せ手段が名寄せしたアクセス情報との関係に従って、該統合情報における未確定の顧客属性を判定してもよい。
【００１５】
上記目的を達成するため、本発明の第３の観点に係るプログラムは、
コンピュータに、未確定の顧客属性が含まれる顧客情報を外部の記憶装置から読み出す顧客情報読み出しステップと、顧客が行った取引の内容を示す取引内容情報を取得する取引内容情報取得ステップと、前記顧客情報読み出しステップにて読み出された顧客情報と、前記取引内容情報取得ステップにて取得された取引内容情報との関係に従って、該顧客情報に含まれる未確定の顧客属性を判定する顧客属性判定ステップと、前記顧客属性判定ステップにて判定された顧客属性に従って、前記顧客情報読み出しステップにて読み出された顧客情報における未確定の顧客属性を更新し、更新後の顧客情報を外部の記憶装置に書き戻す顧客情報書き出しステップと、を実行させることを特徴とする。
【００１６】
【発明の実施の形態】
本発明の実施の形態にかかる法人判定サーバについて、以下図面を参照して説明する。
【００１７】
図１は、この発明の実施の形態に適用される法人判定サーバを含んだシステムの構成の一例を示すブロック図である。図示するように、このシステムは、法人判定サーバ１と、顧客管理システム２と、決済システム３とから構成される。なお、法人判定サーバ１は、ネットワークＮと接続されている。
【００１８】
法人判定サーバ１は、汎用のサーバ装置等からなり、顧客管理システム２（顧客ＤＢ２１）の顧客情報と、決済システム３（決済履歴ファイル３１）の決済履歴情報との突き合わせを行い、顧客情報における未確定の顧客属性（一例として、後述する法人区分）を自動的に判定する。また、法人判定サーバ１は、ネットワークＮから取得したアクセスログＬとも突き合わせを行い、未確定の顧客属性を自動的に判定する。
なお、法人判定サーバ１の詳細については、後述する。
【００１９】
顧客管理システム２は、例えば、販売業者等に配置されたホスト機やサーバ装置等からなり、顧客に関する種々の顧客情報を管理する。具体的に顧客管理システム２は、顧客ＤＢ２１を備えており、この顧客ＤＢ２１にて顧客情報を管理する。
【００２０】
顧客ＤＢ２１は、一例として、図２に示すような、氏名、法人区分、住所、及び、電話番号等の項目（１レコード）からなる顧客情報を記憶する。ここで、法人区分とは、その顧客が法人であるか又は、個人であるかを表すための項目である。つまり、法人顧客の場合には、「法人」が設定され、また、個人顧客の場合には、「個人」が設定される。なお、法人・個人が未確定である場合には、「不定」が設定される。
【００２１】
図１に戻って、決済システム３は、例えば、所定の決済処理を行うホスト機やサーバ装置等からなり、顧客による決済取引の内容を示す決済履歴情報を管理する。なお、決済システム３は、顧客管理システム２とは別個に運営される基幹システムであり、保持する情報（顧客に関する決済履歴情報）も顧客管理システム２にて管理される情報と異なる。
具体的に決済システム３は、決済履歴ファイル３１を備えており、この決済履歴ファイル３１にて、決済履歴情報を管理する。
【００２２】
決済履歴ファイル３１は、一例として、図３に示すような、氏名、支払口座番号、支払クレジット番号、商品名、及び、販売金額等の項目（１レコード）からなる決済履歴情報を記憶する。ここで、支払口座番号及び支払クレジット番号は、決済取引における決済手法を特定する固有の決済特定情報（固有情報）である。
つまり、支払口座番号は、決済手段として金融機関からの口座引き落としが使用された場合に、その金融機関（店舗）及び口座番号を表すコード情報である。一方、支払クレジット番号は、決済手段としてクレジット会社の与信が使用された場合に、そのクレジット会社におけるクレジットカード番号を表すコード情報である。
【００２３】
図１に戻って、ネットワークＮは、インターネットやイントラネット等からなる。そして、顧客によりネットワークＮ上の所定システムが利用された際に、利用取引内容等を示すアクセスログＬが法人判定サーバ１に送信される。
アクセスログＬは、一例として、図４に示すように、氏名、法人区分、住所、電話番号、アクセス時刻、パス、及び、商品名等の項目（１ログレコード）からなる情報である。
なお、このようなアクセスログＬは、顧客の大切な個人情報となるため、予め顧客の同意が得られた情報だけが、活用されるものとする。
【００２４】
以下、法人判定サーバ１について、図５を参照して、詳細に説明する。図５は、法人判定サーバ１の構成の一例を示すブロック図である。
法人判定サーバ１は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、メモリ、ハードディスク、ネットワークカード等のハードウェア構成からなるサーバ装置であり、図示するように、ワークＤＢ１１と、ワークＤＢ生成部１２と、決済履歴情報処理部１３と、アクセスログ取得部１４と、アクセスログ処理部１５と、顧客ＤＢ更新部１６とを含んで構成される。
【００２５】
ワークＤＢ１１は、顧客情報に含まれる未確定な法人区分を、確定（判定）するために使用されるデータベースであり、例えば、上述の図２に示す顧客ＤＢ２１の顧客情報と、図３の決済履歴ファイル３１の決済履歴情報とが統合された統合情報を記憶する。
ワークＤＢ１１は、例えば、図６に示すような、氏名、法人区分、支払口座番号、支払クレジット番号、住所、及び、電話番号等の項目からなる統合情報を記憶する。
【００２６】
図５に戻って、ワークＤＢ生成部１２は、顧客ＤＢ２１から読み出した顧客情報と、決済履歴ファイル３１から読み出した決済履歴情報とを統合し、上述の統合情報を生成してワークＤＢ１１に格納する。
なお、このワークＤＢ生成部１２とは、詳細には、法人判定サーバ１にて実行されるアプリケーションプログラムの機能の１つを抽象化したものである。
【００２７】
決済履歴情報処理部１３は、ワークＤＢ１１に記憶された統合情報（構成レコード）の関連や、決済履歴ファイル３１から新たに読み出された決済履歴情報と統合情報との関係に従って、統合情報中の未確定な法人区分（顧客属性）を判定により確定する。
なお、この決済履歴情報処理部１３も、詳細には、法人判定サーバ１にて実行されるアプリケーションプログラムの機能の１つを抽象化したものである。
【００２８】
アクセスログ取得部１４は、ネットワークＮから送信されるアクセスログＬを取得し、アクセスログ処理部１５に供給する。
アクセスログ処理部１５は、ワークＤＢ１１に記憶された統合情報と、アクセスログ取得部１４により取得されたアクセスログＬ（構成するログレコード）との関係に従って、統合情報中の未確定な法人区分を判定により確定する。
なお、このアクセスログ処理部１５も、詳細には、法人判定サーバ１にて実行されるアプリケーションプログラムの機能の１つを抽象化したものである。
【００２９】
顧客ＤＢ更新部１６は、決済履歴情報処理部１３及びアクセスログ処理部１５により、ワークＤＢ１１における統合情報の未確定な法人区分が確定されると、統合情報に従って、顧客ＤＢ２１の顧客情報を更新する。
同様に、この顧客ＤＢ更新部１６も、詳細には、法人判定サーバ１にて実行されるアプリケーションプログラムの機能の１つを抽象化したものである。
【００３０】
以下、この発明の実施の形態にかかる法人判定サーバ１の動作について、図面を参照して説明する。なお、後述するワークＤＢ生成部１２、決済履歴情報処理部１３、及び、アクセスログ処理部１５がそれぞれ実行する処理は、具体的には、法人判定サーバ１のＣＰＵによって、ハードディスク等に記憶された各プログラムが読み出され、そして、メモリ等の資源が適宜利用されて実行される。
【００３１】
最初に、ワークＤＢ生成部１２が実行するワークＤＢ生成処理について、図７のフローチャート等を参照して説明する。このワークＤＢ生成処理は、顧客ＤＢ２１に確定済み及び未確定の法人区分（顧客属性）が含まれる顧客情報が格納され、また、決済履歴ファイル３１に所定数の決済履歴情報が格納された状態で、開始される。
【００３２】
まず、ワークＤＢ生成部１２は、顧客ＤＢ２１から氏名及び法人区分等の項目が含まれる顧客情報を読み出し、ワークＤＢ１１に格納する（ステップＳ１１）。
具体的にワークＤＢ生成部１２は、図８（ａ）に示すような複数レコードから構成される顧客情報をワークＤＢ１１に格納する。
【００３３】
ワークＤＢ生成部１２は、ワークＤＢ１１に格納した各レコードに決済特定情報を格納するための領域を確保する（ステップＳ１２）。
具体的にワークＤＢ生成部１２は、図８（ｂ）において網掛けにて示すように、支払口座番号及び支払クレジット番号からなる決済特定情報を格納するためのエリアをワークＤＢ１１の各レコードに確保する。
【００３４】
ワークＤＢ生成部１２は、所定の順番に従って、ワークＤＢ１１の１つのレコードから氏名の項目を読み出し、この氏名をキーにして、決済履歴ファイル３１から合致する決済履歴情報（レコード）を検索する（ステップＳ１３）。
ワークＤＢ生成部１２は、検索により対象となる決済履歴情報が存在するか否かを判別する（ステップＳ１４）。ワークＤＢ生成部１２は、対象の決済履歴情報が存在しないと判別すると、後述するステップＳ１６に処理を進める。
【００３５】
一方、対象の決済履歴情報が存在すると判別した場合に、ワークＤＢ生成部１２は、その決済履歴情報（レコード）から決済特定情報を読み出し、読み出した決済特定情報をワークＤＢ１１のレコードに格納する（ステップＳ１５）。すなわち、ワークＤＢ生成部１２は、検索した決済履歴情報（レコード）から支払口座番号や支払クレジット番号の項目を読み出し、読み出した情報をワークＤＢ１１の同一顧客のレコードにセットする。
具体的にワークＤＢ生成部１２は、図８（ｃ）において網掛けにて示すように、ワークＤＢ１１のレコードに、支払口座番号や支払クレジット番号の項目をセットする。
【００３６】
ワークＤＢ生成部１２は、ＤＢの生成が完了したか否かを判別する（ステップＳ１６）。すなわち、ワークＤＢ１１の全レコードに対して、決済履歴ファイル３１の検索を行って、同一顧客の決済特定情報を読み出してレコードにセット済みであるか否かを判別する。
ワークＤＢ生成部１２は、ＤＢの生成が完了していないと判別した場合に、ステップＳ１３に処理を戻し、上述のステップＳ１３〜Ｓ１６の処理を繰り返し実行する。一方、ＤＢの生成が完了したと判別すると、ワークＤＢ生成部１２は、ワークＤＢ生成処理を終える。
【００３７】
このようなワークＤＢ生成処理により、顧客ＤＢ２１の顧客情報と、決済履歴ファイル３１の決済履歴情報とが同一顧客単位に統合され、統合された統合情報がワークＤＢ１１に格納される。
【００３８】
次に、決済履歴情報処理部１３が実行する第１の法人判定処理について、図９に示すフローチャート等を参照して説明する。この第１の法人判定処理は、上述した図７に示すワークＤＢ生成処理により、ワークＤＢ１１が生成された後に開始される。
【００３９】
まず、決済履歴情報処理部１３は、ワークＤＢ１１にて法人区分が確定されているレコードと同一の決済特定情報を有するレコードを、ワークＤＢ１１内にて検索する（ステップＳ２０）。
具体的に決済履歴情報処理部１３は、図１０（ａ）の統合情報において、法人区分が既に「法人」と設定されているレコードｒ１の決済特定情報（この場合、支払口座番号）と同じ決済特定情報を有するレコード（法人区分が「不定」のレコード）を検索する。
【００４０】
決済履歴情報処理部１３は、検索により対象となるレコードが存在するか否かを判別する（ステップＳ２１）。決済履歴情報処理部１３は、対象のレコードが存在しないと判別した場合、後述するステップＳ２３に処理を進める。
【００４１】
一方、対象のレコードが存在すると判別した場合に、決済履歴情報処理部１３は、対象レコードの法人区分に「法人」を設定する（ステップＳ２２）。
具体的に図１０（ａ）に示すように、レコードｒ１の支払口座番号と同じ支払口座番号を有するレコードｒ２が検索されたとする。この場合、レコードｒ２は、レコードｒ１と氏名が異なるにも拘わらず同一の支払口座番号を使用して決済が行われているため、法人であると判定できる。従って、決済履歴情報処理部１３は、レコードｒ２の法人区分を「法人」に確定する。
【００４２】
決済履歴情報処理部１３は、このような検索及び確定を、法人区分が既に「法人」と設定されている全レコードを対象にして行う。
ここまでの処理により、法人区分が「法人」として確定済みの顧客と、同じ決済手段を用いる別名称の顧客が存在する場合に、その顧客も法人であると判定でき、その顧客の法人区分を「法人」に確定できる。
【００４３】
続いて、決済履歴情報処理部１３は、法人区分が未確定（「不定」）のレコードの内、同一の決済特定情報であり、かつ、異なる氏名となるレコードを、ワークＤＢ１１内にて検索する（ステップＳ２３）。
具体的に決済履歴情報処理部１３は、図１０（ｂ）の統合情報において、法人区分が「不定」と設定されているレコードの内、決済特定情報が同一で、かつ、氏名が異なるレコードを検索する。
【００４４】
決済履歴情報処理部１３は、検索により対象となるレコードが存在するか否かを判別する（ステップＳ２４）。決済履歴情報処理部１３は、対象のレコードが存在しないと判別した場合、後述するステップＳ２６に処理を進める。
【００４５】
一方、対象のレコードが存在すると判別した場合に、決済履歴情報処理部１３は、対象レコードの法人区分に「法人」を設定する（ステップＳ２５）。
具体的に、図１０（ｂ）に示すように、法人区分が「不定」と設定されているレコードの内、支払口座番号が同一で、かつ、氏名が異なるレコードｒ３，ｒ４が検索されたとする。この場合、レコードｒ３，ｒ４は、それぞれ氏名が異なるにも拘わらず同一の支払口座番号を使用して決済が行われているため、法人であると判定できる。従って、決済履歴情報処理部１３は、レコードｒ３，ｒ４の法人区分を「法人」に確定する。
【００４６】
決済履歴情報処理部１３は、このような検索及び確定を、法人区分が未だ「不定」と設定されている全レコードを対象にして行う。
ここまでの処理により、法人区分が未確定の顧客同士が、同じ決済手段を用いている場合に、無関係の個人同士が同じ決済手段を使うことが原則あり得ないことから、それらの顧客も法人であると判定でき、それぞれの法人区分を「法人」に確定できる。
【００４７】
続いて、決済履歴情報処理部１３は、新たな決済履歴情報を決済履歴ファイル３１から読み出す（ステップＳ２６）。
決済履歴情報処理部１３は、読み出した決済履歴情報と同一の決済特定情報で、かつ、異なる氏名となるレコードをワークＤＢ１１から検索する（ステップＳ２７）。
具体的に決済履歴情報処理部１３は、図１０（ｃ）に示すように、決済履歴ファイル３１から読み出したレコードｒ５の決済特定情報と、同じ決済特定情報を有するレコードをワークＤＢ１１から検索する。
【００４８】
決済履歴情報処理部１３は、検索により対象となるレコードが存在するか否かを判別する（ステップＳ２８）。決済履歴情報処理部１３は、対象のレコードが存在しないと判別した場合、第１の法人判定処理を終了する。
【００４９】
一方、対象のレコードが存在すると判別した場合に、決済履歴情報処理部１３は、対象レコードの法人区分に「法人」を設定する（ステップＳ２９）。
具体的に、図１０（ｃ）に示すように、レコードｒ５の支払口座番号と同じ支払口座番号を有するレコードｒ６が検索されたとする。この場合、レコードｒ６は、レコードｒ５と氏名が異なるにも拘わらず同一の支払口座番号を使用して決済を行っているため、法人であると判定できる。従って、決済履歴情報処理部１３は、レコードｒ６の法人区分を「法人」に確定する。
【００５０】
決済履歴情報処理部１３は、このような検索及び確定を、新たに決済履歴ファイル３１から読み出された全ての決済履歴情報を対象にして行う。
ここまでの処理により、新たな決済履歴情報を利用して、同じ決済手段を用いている顧客が見つかった場合に、無関係の個人同士が同じ決済手段を使うことが原則あり得ないことから、この顧客の法人区分も「法人」に確定できる。
【００５１】
このように、上述した図９に示す第１の法人判定処理によって、顧客情報に含まれる未確定な顧客属性（この場合、法人区分）を適切に判定することができる。
【００５２】
次に、アクセスログ処理部１５が実行する第２の法人判定処理について、図１１に示すフローチャート等を参照して説明する。この第２の法人判定処理は、例えば、上述した図９に示す第１の法人判定処理が終了し、アクセスログ取得部１４にて取得されたアクセスログＬがアクセスログ処理部１５に供給された後に、開始される。
【００５３】
まず、アクセスログ処理部１５は、アクセスログ取得部１４から供給されたアクセスログＬの内、法人区分が「法人」と設定されているログレコードを抽出する（ステップＳ３１）。
アクセスログ処理部１５は、抽出したログレコードを、ワークＤＢ１１の統合情報を基準として名寄せする（ステップＳ３２）。
【００５４】
アクセスログ処理部１５は、名寄せしたログレコードと、同一の属性情報となるレコードをワークＤＢ１１から検索する（ステップＳ３３）。
具体的にアクセスログ処理部１５は、図１２（ａ）に示すように、法人区分が「法人」と設定されているログレコードｒ７の属性情報（この場合、住所及び電話番号）と同じ属性情報を有するレコードをワークＤＢ１１から検索する。
【００５５】
アクセスログ処理部１５は、検索により対象となるレコードが存在するか否かを判別する（ステップＳ３４）。アクセスログ処理部１５は、対象のレコードが存在しないと判別した場合、後述するステップＳ３６に処理を進める。
【００５６】
一方、対象のレコードが存在すると判別した場合に、アクセスログ処理部１５は、対象レコードの法人区分に「法人」を設定する（ステップＳ３５）。
具体的に、図１２（ａ）に示すように、ログレコードｒ７の属性情報と同じ属性情報（この場合、住所及び電話番号）を有するレコードｒ８が検索されたとする。この場合、レコードｒ８は、ログレコードｒ７と住所及び電話番号が同一であるため、同一法人であると判定できる。従って、アクセスログ処理部１５は、レコードｒ８の法人区分を「法人」に確定する。
【００５７】
アクセスログ処理部１５は、このような検索及び確定を、全てのログレコードを対象にして行う。
ここまでの処理により、法人区分が「法人」として確定済みの顧客と、同じ住所及び電話番号を有する顧客が存在する場合に、その顧客も法人であると判定でき、その顧客の法人区分を「法人」に確定できる。
【００５８】
続いて、アクセスログ処理部１５は、今回、法人区分を「法人」に確定したレコードと、同一の決済特定情報となるレコードを、ワークＤＢ１１内にて検索する（ステップＳ３６）。
具体的にアクセスログ処理部１５は、図１２（ｂ）に示すように、今回（ステップＳ３５にて）、法人と確定したレコードｒ８と、決済特定情報（この場合支払口座番号）が同一となるレコードを、ワークＤＢ１１から検索する。
【００５９】
アクセスログ処理部１５は、検索により対象となるレコードが存在するか否かを判別する（ステップＳ３７）。アクセスログ処理部１５は、対象のレコードが存在しないと判別した場合、第２の法人判定処理を終了する。
【００６０】
一方、対象のレコードが存在すると判別した場合に、アクセスログ処理部１５は、対象レコードの法人区分に「法人」を設定する（ステップＳ３８）。
具体的に、図１２（ｂ）に示すように、レコードｒ８の支払口座番号と同じ支払口座番号を有するレコードｒ９が検索されたとする。この場合、レコードｒ９は、レコードｒ８と氏名が異なるにも拘わらず同一の支払口座番号を使用して決済を行っているため、法人であると判定できる。従って、アクセスログ処理部１５は、レコードｒ９の法人区分を「法人」に確定する。
【００６１】
決済履歴情報処理部１３は、このような検索及び確定を、今回（ステップＳ３５にて）、法人と確定した全てのレコードを対象にして行う。
ここまでの処理により、法人区分が「法人」として確定済みの顧客と、同じ決済手段を用いる別名称の顧客が存在する場合に、その顧客も法人であると判定でき、その顧客の法人区分を「法人」に確定できる。
【００６２】
このように、上述した図１１に示す第２の法人判定処理によって、顧客情報に含まれる未確定な顧客属性（この場合、法人区分）を適切に判定することができる。
【００６３】
上述した決済履歴情報処理部１３による第１の法人判定処理及び、アクセスログ処理部１５による第２の法人判定処理が行われると、顧客ＤＢ更新部１６は、更新後のワークＤＢ１１の内容を顧客ＤＢ２１に反映する。
具体的に顧客ＤＢ更新部１６は、図１３に示すような、法人区分が確定した統合情報に従って、顧客ＤＢ２１を更新する。
【００６４】
この結果、法人判定サーバ１は、顧客情報に含まれる未確定な顧客属性（この場合、法人区分）を適切に判定し、そして確定することができる。
【００６５】
上記の実施の形態では、顧客管理システム２と別個に構築され運営されている決済システム３（決済履歴ファイル３１）を活用して、顧客ＤＢ２１における未確定な属性情報を判定（確定）した。しかしながら、この決済システム３（決済履歴ファイル３１）は、一例であり、信頼性の高い属性情報を含んだ他のシステムを活用して顧客ＤＢ２１における未確定な属性情報を判定（確定）してもよい。
【００６６】
また、上記の実施の形態では、判定（確定）対象となる未確定な属性情報として、法人区分を一例として説明したが、対象となるのは法人区分に限られず顧客情報における他の属性情報であってもよい。
【００６７】
また、上記の実施の形態では、決済特定情報として支払口座番号及び支払クレジット番号を使用する場合について説明したが、他の情報（例えば、電子マネーのコード番号等）を決済特定情報として使用してもよい。
【００６８】
なお、この発明の実施の形態にかかる法人判定サーバは、専用機器によらず、通常のコンピュータシステムを用いて実現可能である。例えば、通信機能を備えたコンピュータに上述のいずれかを実行するためのプログラムを格納した媒体（フレキシブルディスク、ＣＤ−ＲＯＭ等）から当該プログラムをインストールすることにより、上述の処理を実行する法人判定サーバを構成することができる。
【００６９】
また、コンピュータにプログラムを供給するための手法は、任意である。例えば、通信回線、通信ネットワーク、通信システム等を介して供給してもよい。一例を挙げると、通信ネットワークの掲示板（ＢＢＳ）に当該プログラムを掲示し、これをネットワークを介して搬送波に重畳して配信する。
そして、このプログラムを起動し、ＯＳの制御下で、他のアプリケーションプログラムと同様に実行することにより、上述の処理を実行することができる。
【００７０】
【発明の効果】
以上説明したように、本発明によれば、顧客情報に含まれる未確定な顧客属性を適切に判定することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係る法人判定サーバを含んだシステムの構成の一例を示す模式図である。
【図２】顧客ＤＢの構成の一例を示す模式図である。
【図３】決済履歴ファイルの構成の一例を示す模式図である。
【図４】アクセスログの構成の一例を示す模式図である。
【図５】本発明の実施の形態に係る法人判定サーバの構成の一例を示すブロック図である。
【図６】ワークＤＢの構成の一例を示す模式図である。
【図７】本発明の実施の形態に係るワークＤＢ生成処理を説明するためのフローチャートである。
【図８】（ａ）〜（ｃ）共に、ワークＤＢ生成処理にて生成されるワークＤＢの具体例を説明するための模式図である。
【図９】本発明の実施の形態に係る第１の法人判定処理を説明するためのフローチャートである。
【図１０】（ａ）〜（ｃ）共に、第１の法人判定処理の具体的な動作を説明するための模式図である。
【図１１】本発明の実施の形態に係る第２の法人判定処理を説明するためのフローチャートである。
【図１２】（ａ），（ｂ）共に、第２の法人判定処理の具体的な動作を説明するための模式図である。
【図１３】第１及び第２の法人判定処理後のワークＤＢの一例を示す模式図である。
【符号の説明】
１ 法人判定サーバ
１１ ワークＤＢ
１２ ワークＤＢ生成部
１３ 決済履歴情報処理部
１４ アクセスログ取得部
１５ アクセスログ処理部
１６ 顧客ＤＢ更新部
２ 顧客管理システム
２１ 顧客ＤＢ
３ 決済システム
３１ 決済履歴ファイル
Claims (5)
- 未確定の顧客属性が含まれる顧客情報を外部の記憶装置から読み出す顧客情報読み出し手段と、
顧客が行った決済取引の内容を示す決済情報を取得する決済情報取得手段と、前記顧客情報読み出し手段が読み出した顧客情報と、前記決済情報取得手段が取得した決済情報との関係に従って、該顧客情報に含まれる未確定の顧客属性を判定する顧客属性判定手段と、
前記顧客属性判定手段が判定した顧客属性に従って、前記顧客情報読み出し手段が読み出した顧客情報における未確定の顧客属性を更新し、更新後の顧客情報を外部の記憶装置に書き戻す顧客情報書き出し手段と、
を備えることを特徴とする顧客属性判定サーバ。 - 顧客による所定システムの利用に伴い生じた、確定済みの顧客属性が含まれるアクセス情報を取得するアクセス情報取得手段を更に備え、
前記顧客属性判定手段は、顧客情報読み出し手段が読み出した顧客情報と、前記アクセス情報取得手段が取得したアクセス情報との関係に従って、該顧客情報に含まれる未確定の顧客属性を判定する、
ことを特徴とする請求項１に記載の顧客属性判定サーバ。 - 確定済み及び未確定の顧客属性が含まれる顧客情報を、外部の顧客データベースから読み出す顧客情報読み出し手段と、
顧客が行った決済取引における決済手法の固有情報が含まれる決済情報を外部の決済システムから取得する決済情報取得手段と、
前記顧客情報読み出し手段が読み出した顧客情報と、前記決済情報取得手段が取得した決済情報とから、同一顧客単位に統合した統合情報を生成する統合情報生成手段と、
前記統合情報生成手段が生成した統合情報における確定済みの顧客属性及び、固有情報の関係に従って、該統合情報における未確定の顧客属性を判定する顧客属性判定手段と、
前記顧客属性判定手段が判定した顧客属性に従って、前記統合情報生成手段が生成した統合情報における未確定の顧客属性を更新する統合情報更新手段と、
前記統合情報更新手段により未確定の顧客属性が更新された統合情報に従って、外部の顧客データベースに顧客情報を書き戻す顧客情報書き出し手段と、
を備えることを特徴とする顧客属性判定サーバ。 - 顧客による所定システムの利用に伴い生じた、確定済みの顧客属性が含まれるアクセス情報を、所定のネットワークを介して取得するアクセス情報取得手段と、
前記アクセス情報取得手段が取得したアクセス情報を、前記統合情報生成手段が生成した統合情報に基づいて名寄せする名寄せ手段と、を更に備え、
前記顧客属性判定手段は、前記統合情報生成手段が生成した統合情報と、前記名寄せ手段が名寄せしたアクセス情報との関係に従って、該統合情報における未確定の顧客属性を判定する、
ことを特徴とする請求項３に記載の顧客属性判定サーバ。 - コンピュータに、未確定の顧客属性が含まれる顧客情報を外部の記憶装置から読み出す顧客情報読み出しステップと、顧客が行った取引の内容を示す取引内容情報を取得する取引内容情報取得ステップと、前記顧客情報読み出しステップにて読み出された顧客情報と、前記取引内容情報取得ステップにて取得された取引内容情報との関係に従って、該顧客情報に含まれる未確定の顧客属性を判定する顧客属性判定ステップと、前記顧客属性判定ステップにて判定された顧客属性に従って、前記顧客情報読み出しステップにて読み出された顧客情報における未確定の顧客属性を更新し、更新後の顧客情報を外部の記憶装置に書き戻す顧客情報書き出しステップと、を実行させるためのプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002164283A JP2004013403A (ja) | 2002-06-05 | 2002-06-05 | 顧客属性判定サーバおよびプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002164283A JP2004013403A (ja) | 2002-06-05 | 2002-06-05 | 顧客属性判定サーバおよびプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004013403A true JP2004013403A (ja) | 2004-01-15 |
Family
ID=30432463
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002164283A Pending JP2004013403A (ja) | 2002-06-05 | 2002-06-05 | 顧客属性判定サーバおよびプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004013403A (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007304796A (ja) * | 2006-05-10 | 2007-11-22 | Mitsubishi Electric Corp | データベース解析システム及びデータベース解析方法及びプログラム |
| JP2015146128A (ja) * | 2014-02-03 | 2015-08-13 | ヤフー株式会社 | 情報提供装置、情報提供システム、情報提供プログラムおよび情報提供方法 |
| JP2018106759A (ja) * | 2018-04-02 | 2018-07-05 | ヤフー株式会社 | 名寄せ装置、名寄せ方法及び名寄せプログラム |
| JP6971449B1 (ja) * | 2020-09-03 | 2021-11-24 | ゼネリックソリューション株式会社 | 営業支援装置 |
| US11444273B2 (en) | 2017-07-26 | 2022-09-13 | Lg Energy Solution, Ltd. | Method for manufacturing lithium electrode |
-
2002
- 2002-06-05 JP JP2002164283A patent/JP2004013403A/ja active Pending
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007304796A (ja) * | 2006-05-10 | 2007-11-22 | Mitsubishi Electric Corp | データベース解析システム及びデータベース解析方法及びプログラム |
| JP2015146128A (ja) * | 2014-02-03 | 2015-08-13 | ヤフー株式会社 | 情報提供装置、情報提供システム、情報提供プログラムおよび情報提供方法 |
| US11444273B2 (en) | 2017-07-26 | 2022-09-13 | Lg Energy Solution, Ltd. | Method for manufacturing lithium electrode |
| JP2018106759A (ja) * | 2018-04-02 | 2018-07-05 | ヤフー株式会社 | 名寄せ装置、名寄せ方法及び名寄せプログラム |
| JP6971449B1 (ja) * | 2020-09-03 | 2021-11-24 | ゼネリックソリューション株式会社 | 営業支援装置 |
| WO2022050261A1 (ja) * | 2020-09-03 | 2022-03-10 | ゼネリックソリューション株式会社 | 営業支援装置 |
| JP2022042617A (ja) * | 2020-09-03 | 2022-03-15 | ゼネリックソリューション株式会社 | 営業支援装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5132311B2 (ja) | 小売販売分析を行なう方法 | |
| JPH11312273A (ja) | 顧客サービス装置、方法、カード並びに顧客サービス処理プログラムを記録したコンピュータ読取り可能な記録媒体 | |
| US20040243485A1 (en) | Method and system for providing product catalog information for electronic stores | |
| US20220284443A1 (en) | Information processing system | |
| US20220366469A1 (en) | Smart link for outside network input/output | |
| US11631092B2 (en) | Methods and apparatus for maintaining and/or updating one or more item taxonomies | |
| US20020198772A1 (en) | Encouraging house card use through price guarantees | |
| CA2438368A1 (en) | A method and system for creating navigational information for an electronic store from virtual and master catalog links | |
| JP2004013403A (ja) | 顧客属性判定サーバおよびプログラム | |
| JP2009175874A (ja) | ポイント管理装置及び方法、ならびに、コンピュータプログラム | |
| US11494831B2 (en) | System and method of providing customer ID service with data skew removal | |
| US20090313563A1 (en) | System and method for providing data links | |
| KR20020007163A (ko) | 컴퓨터 네트워크를 통한 쇼핑을 보조하기 위한 가상 희망리스트 생성 시스템 및 방법 | |
| JP5207195B2 (ja) | 排出量取引システム及び排出量取引方法 | |
| US20030195812A1 (en) | Method, system, and computer program product for tracing cross-channel customers | |
| JP2020024566A (ja) | 広告管理システム、広告管理方法、および広告管理プログラム | |
| JP2008299794A (ja) | Ｐｏｓ端末、商品ポイント管理システム、管理方法、プログラム、及び記録媒体 | |
| JP5993717B2 (ja) | 広告提供システム | |
| JPH11175616A (ja) | 顧客情報配布方法及びその実施システム | |
| Arnold et al. | Semi-automatic identification of counterfeit offers in online shopping platforms | |
| JP7401020B2 (ja) | 商品情報管理装置、商品情報管理方法、プログラム | |
| WO2001086529A1 (fr) | Procede d'aide a la distribution, serveur d'aide a la distribution, support d'enregistrement, programme d'aide a la distribution et terminal du courtier | |
| JP4122944B2 (ja) | 書籍流通管理方法及び書籍流通管理システムならびにコンピュータプログラム | |
| CA3098007C (en) | System and method for merging accounts | |
| KR102454401B1 (ko) | 연쇄 거래 대상 책의 등록 정보를 관리하는 서버를 이용한 책 거래 장치, 시스템 및 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041109 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050308 |