(57)【要約】【課題】  ユーザにとって効果的な買い替え条件を提供でき、修理受付側がユーザに不信感を持たれにくい提案をすることを目的とする。【解決手段】  商品の修理を受け付け、ユーザに商品の買い替えを訴求する情報処理装置であって、複数のユーザの提案してきた提案履歴情報を記憶する記憶手段と、前記記憶手段から取得した前記ユーザの提案履歴情報から、提案を拒否されたことがあるか判断する第１の判断手段と、前記第１の判断手段により、前記ユーザの提案履歴情報の提案が拒否されたことがなければ、該ユーザに商品の買い替えを提案する商品提案手段と、を有することを特徴とする。【選択図】図１
2017142734.tif 000002
【特許請求の範囲】
【請求項１】
商品の修理を受け付け、ユーザに商品の買い替えを訴求する情報処理装置であって、
複数のユーザの提案してきた提案履歴情報を記憶する記憶手段と、
前記記憶手段から取得した前記ユーザの提案履歴情報から、提案を拒否されたことがあるか判断する第１の判断手段と、
前記第１の判断手段により、前記ユーザの提案履歴情報の提案が拒否されたことがなければ、該ユーザに商品の買い替えを提案する商品提案手段と、
を有することを特徴とする情報処理装置。
【請求項２】
商品情報を記憶する商品情報記憶手段と、
前記第１の判断手段により、前記ユーザの提案履歴情報の提案が拒否されたことがある場合、前記商品情報記憶手段から取得した商品情報から、該ユーザの改善点要望が改善されている商品があるか判断する第２の判断手段と、
前記商品提案手段は、前記第２の判断手段により前記ユーザの改善点要望が改善されている商品がある場合、前記改善されている商品の買い替えを提案することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記商品の保証期間を過ぎているかどうかを判断する保証期間判断手段と、
前記保証期間判断手段により、前記商品の保証期間を過ぎている場合、該商品のユーザ購入後の期間が第１の所定の期間以上であるかどうか判断する購入後期間判断手段と、
前記商品提案手段は、前記購入後期間判断手段により、前記商品のユーザ購入後の期間が第１の所定の期間以上であれば、該ユーザに商品の買い替えを提案することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記記憶手段の提案履歴情報には、修理依頼履歴情報も記憶されており、
前記記憶手段に記憶された修理依頼履歴情報より、前回修理依頼から第２の所定期間未満の修理依頼かどうかを判断する修理依頼判断手段と、
前記商品提案手段は、前記修理依頼判断手段により、前回修理依頼から第２の所定期間未満の修理依頼であった場合に、前記ユーザに商品の買い替えを提案することを特徴とする請求項１乃至３に記載の情報処理装置。
【請求項５】
複数のユーザの提案してきた提案履歴情報を記憶する記憶手段を有する、商品の修理を受け付け、ユーザに商品の買い替えを訴求する情報処理装置における情報処理方法であって、
前記記憶手段から取得した前記ユーザの提案履歴情報から、提案を拒否されたことがあるか判断する第１の判断ステップと、
前記第１の判断ステップにより、前記ユーザの提案履歴情報の提案が拒否されたことがなければ、該ユーザに商品の買い替えを提案する商品提案ステップと、
を有することを特徴とする情報処理方法。
【請求項６】
請求項１乃至４のいずれか１項に記載の情報処理装置として、コンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、修理受付業務における買い替えを提案する情報処理装置の制御に関する。
【背景技術】
【０００２】
サービスセンターの担当者は、不特定多数のユーザからの修理受付業務において、修理料金を見積もり後にユーザに見積書を提示する業務を行っている。
【０００３】
製品の保証期間外での修理が発生した場合、修理の料金により、修理するか他の製品に買い替えるかをユーザに選択させることがある。
【０００４】
そのユーザの判断を助けるための情報を提供する修理受付システムとして、特許文献１〜３が開示されている。
【０００５】
特許文献１には、買い替え機種提案システムにおいて、ユーザビリティを改善できる買い替え機種を提案するものが開示されている。
【０００６】
また、特許文献２には、故障した製品の修理費用と、同種の製品の購入費用との見積もりとを同時に供給可能なシステムが開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１２−１５９９５１号公報
【特許文献２】特開２００２−２０７８９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、特許文献１及び２に記載の技術では、買い替え判断について、費用やユーザビリティと言う点しか考慮されていない。ユーザからの修理受付業務において、過去に買い替えを拒否された提案などは、再度同じ提案をすべきでない場合もある。また、初期不良と思われる状況で買い替え提案をすることは、ユーザの不信感をもたらす。
【０００９】
本発明は、ユーザにとって効果的な買い替え条件を提供でき、修理受付側がユーザに不信感を持たれにくい提案をすることを目的とする
【課題を解決するための手段】
【００１０】
本発明は、商品の修理を受け付け、ユーザに商品の買い替えを訴求する情報処理装置であって、複数のユーザの提案してきた提案履歴情報を記憶する記憶手段と、前記記憶手段から取得した前記ユーザの提案履歴情報から、提案を拒否されたことがあるか判断する第１の判断手段と、前記第１の判断手段により、前記ユーザの提案履歴情報の提案が拒否されたことがなければ、該ユーザに商品の買い替えを提案する商品提案手段と、を有することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、ユーザにとって効果的な買い替え条件を提供でき、修理受付側がユーザに不信感を持たれにくい提案をする効果を有する。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態の情報処理システムの構成を示すシステム構成図である。
【図２】本発明の実施形態の各種端末のハードウエア構成を示す図である。
【図３】本発明の実施形態の情報処理装置における制御処理手段の一例を示すフローチャートである。
【図４】本発明の実施形態における提案履歴ＤＢのデータ構成の一例を示した模式図である。
【図５】本発明の実施形態における顧客ＤＢのデータ構成の一例を示した模式図である。
【図６】本発明の実施形態におけるクライアント端末１００の出力部２１０に出力される画面イメージを示した一例である。
【発明を実施するための形態】
【００１３】
以下、本発明の好ましい実施の形態について図面を参照しながら詳細に説明する。
【００１４】
図１は、本発明に係る情報処理システムの構成を示すシステム構成図である。
【００１５】
図１において、情報処理システムは、製品買い替え提案サーバ２００と、製品買い替え提案サーバ２００に情報を入力するクライアント端末１００とを有し、ネットワーク１１０を介して接続されている。
【００１６】
ユーザは、クライアント端末１００を使用して製品買い替え提案サーバ２００に直接もしくは間接的にアクセスし、製品買い替え提案サーバ２００から選定された買い替え製品の候補をクライアント端末１００を介して受取る。
【００１７】
製品買い替え提案サーバ２００は、顧客ＤＢ、商品情報ＤＢと、顧客へのこれまで提案してきた買い替え製品提案してきた履歴を記憶した提案履歴ＤＢと接続されている。
【００１８】
図２は、本発明の実施形態のクライアント端末１００、製品買い替え提案サーバ２００などの各種端末のハードウエア構成を示す図である。
【００１９】
図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。
【００２０】
また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。
【００２１】
ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。
【００２２】
入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。また、印刷装置等では、タッチパネル、ボタン、スイッチ等が挙げられる。
【００２３】
出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶ディスプレイ等が挙げられる。
【００２４】
外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザーファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。
【００２５】
通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して外部機器との通信制御処理を実行する。
【００２６】
本発明を実現するためのプログラム（図１４）は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。
【００２７】
以下、図３を参照して、本発明における実施形態の流れを説明する。
【００２８】
図３は、本発明の実施形態の製品買い替え提案サーバ２００における制御処理手段の一例を示すフローチャートであり、図中のＳ３０１〜Ｓ３０９は各ステップを示す。各ステップの処理は、製品買い替え提案サーバ２００の外部メモリ２１１に格納されたアプリケーションプログラムを、それぞれの装置のＣＰＵ２０１がＲＡＭ２０３上にロードして実行することにより実現される。
【００２９】
図３のフローチャートは、クライアント端末１００から製品買い替え提案サーバ２００に、故障機器情報の入力があり、修理依頼があった場合に開始される処理の流れである。
【００３０】
まず、ステップＳ３０１において、製品買い替え提案サーバ２００のＣＰＵ２０１は、クライアント端末１００から故障機器情報の入力を受け付ける。入力を受け付けた製品買い替え提案サーバ２００は、受け付けた情報から、顧客情報を抽出し、顧客ＤＢ１１１から顧客の情報、提案履歴ＤＢ１１２から過去に提案した買い替え提案候補の情報をそれぞれ取得する。取得する顧客ＤＢの例を図５を参照して説明する。
【００３１】
図５は、本発明に係る顧客ＤＢのデータ構成の一例を示した模式図である。
【００３２】
図５の５０１はユーザを特定するユーザ名で、５０１より右欄に示された値は、５０１のユーザが所有する製品に関する情報の一例であり、１行が一つのデータに該当する。すなわち、図５は４つの異なるデータの例が記載されている。
【００３３】
顧客ＤＢのデータとして、５０２には保証書を有しているかどうかを示しており、５０３は保証期間、５０５は購入日、５０７は前回修理日（前回修理依頼）などを記憶している。前記項目から、保証範囲内／外の判断５０４や購入期間５０６、前回故障からの期間５０８などを算出している。なお、備考５０９は説明を分かり易くするためにつけた各データにおけるコメントである。
【００３４】
次に、図４参照して提案履歴ＤＢの例を説明する。
【００３５】
図４は、本発明に係る提案履歴ＤＢ（修理依頼履歴情報ＤＢ）のデータ構成の一例を示した模式図である。
【００３６】
図４の４００の４０１行は４０３のユーザに提案したことのある履歴情報を示した図であり、４０７の「製品Ａ」が故障した際に４０８の製品を提案した結果の承認・拒否結果４０４と拒否の場合の拒否理由（改善点要望）４０５を記憶している。図３のフローチャートの説明に戻る。
【００３７】
次に、図３のステップＳ３０２において、製品買い替え提案サーバ２００のＣＰＵ２０１は、ステップＳ３０１で取得した顧客情報から、該当する顧客の製品が保証期間内か外かを判断する。保証期間内であり、かつ保証内の修理と判断すると、本発明の処理を終了し、図示しない修理依頼を行う処理を行う。図５の顧客ＤＢの例では、５００の１行目のデータがこの場合に該当する。
【００３８】
一方、ステップＳ３０２において、保証期間外と判断された場合は、ステップＳ３０３へと処理を遷移し、ステップＳ３０３において、製品買い替え提案サーバ２００のＣＰＵ２０１は、該当する顧客の製品が購入後所定の期間以上経過しているかを判断する。製品購入後、所定の期間以内の場合は、直ぐに買い換え提案をすると顧客の不信感を買うことになるため、買い替えは提案せず、ステップＳ３０５へと遷移し、修理見積を表示させるための修理見積価格の算出、価格の送信を行う。一方、製品購入後、所定の期間以上経過している場合は、続く買い替え提案処理を行うため、ステップＳ３０４へと処理を遷移する。図５の顧客ＤＢを参照して説明する。
【００３９】
図５の５００の２行目の例では購入期間が１０日であり、図３のように所定の期間が１ヶ月の場合には、２行目の例では所定の期間より短い。そのため、２行目の例では、ステップＳ３０５へと処理を遷移する。一方、３行目以降の例では、購入期間が１年２ヶ月であり、所定の期間（１ヶ月）以上経過しているので、ステップＳ３０４へと処理を遷移する。図３のフローチャートの説明に戻る。
【００４０】
次に、ステップＳ３０４において、製品買い替え提案サーバ２００のＣＰＵ２０１は、顧客が修理を依頼している製品が、連続で故障しているかどうかを判断する。連続で故障しているかどうかは、図５の例では、現在日時５１０から前回修理完了日５０７を引いた日時を算出（５０８）し、算出した期間が所定の期間以上かどうかで判断する。算出した期間が所定の期間以内であれば、連続で故障したと判断して、買い替え提案を行う処理（ステップＳ３０６以降）へと遷移する。一方、算出した期間が所定の期間以上であれば、連続で故障したと判断せず、修理見積依頼の処理（ステップＳ３０５）へと遷移する。この判断により保証期間を過ぎた製品が連続で故障した場合には、買い替えを提案し、保証期間を過ぎた製品でも連続で故障していない場合は、買い替えを提案する前に修理見積価格表示へと進ませることにより、顧客への故障ついでの便乗販売と考えられるリスクを低減することができる。
【００４１】
図５の５００の例を参照すると、３行目の例では購入期間が１年２ヶ月であり、保証期間を既に過ぎている。また、５０８のように、前回の故障からの期間は２ヶ月経過しており、連続で故障したとみなされる１ヶ月以上の期間が空いている。そのため、３行目の例では、ステップＳ３０５へと処理を遷移する。一方、５００の例の４行目の例では、保証期間が過ぎており、また、５０８列のように前回の故障から２０日しか経過していないため、連続で故障したとみなされる。
【００４２】
次に、ステップＳ３０６において、製品買い替え提案サーバ２００のＣＰＵ２０１は、ステップＳ３０１で取得した提案履歴ＤＢのデータから、過去に拒否された提案があるかどうかを判断する。過去に拒否された提案がある場合は、ステップＳ３０７へと処理を遷移し、拒否されて提案がない場合は、ステップS３０８へと処理を遷移する。具体的に、図４の提案履歴ＤＢのデータを参照して説明する。
【００４３】
図５の４行目の例を参照すると、ユーザは「岡村氏」であり、図４の４００において、購入提案先であるユーザ４０３が「岡村氏」である過去の提案履歴としては、４０１の行である。なお、４０２の行は、今回提案する内容であり、履歴情報とは異なるが、わかりやすくするために表示している。
【００４４】
４０１の「岡村氏」に対する過去提案履歴から、４０４のように提案は「拒否」されており、拒否の理由（改善点要望）４０５としては「手ぶれ補正の精度」が足りないためという情報が登録されている。すなわち、「岡村氏」は、買い換え元「製品Ａ」４０７から買い替え先である「製品Ｂ」４０８に買い換えることは、手ぶれ補正の精度が足りないため拒否したことを示している。従って、図４の４００の例では、過去に拒否された提案があるため、ステップＳ３０７へと処理を遷移する。図３のフローチャートの説明に戻る。
【００４５】
次に、ステップＳ３０７において、製品買い替え提案サーバ２００のＣＰＵ２０１は、ステップＳ３０１で取得した提案履歴ＤＢのデータから、過去に拒否された提案以外で拒否理由が改善されている製品がないか判断する。過去に拒否された提案以外で拒否理由が改善されている製品がある場合は、ステップＳ３０８へと処理を遷移し、他製品を提案するための処理へと遷移する。一方、過去に拒否された提案以外で拒否理由が改善されている製品がない場合は、他の製品を提案するための処理には移行せず、ステップＳ３０５の処理へと移行する。図４の提案履歴ＤＢのデータを参照して説明する。
【００４６】
図４の４０２行のユーザである「岡村氏」に他の製品を提案する場合、４０１行のデータのように過去に提案が拒否されていると、同じ製品を提案しても拒否される可能性が高く、またユーザも一度拒否した製品を再度提案してくるメーカに対して不信感を抱く可能性がある。そのため、ステップＳ３０７において、一度提案を拒否された場合は、提案を拒否された際にクライアント端末１００から入力された拒否の理由（改善点要望）４０５を取得し、拒否の理由が改善点４０９に登録されている情報と一致しているかどうかを判断する。４０１行目の拒否の理由（改善点要望）４０５と同じ改善点４０９のデータがある場合は、前回拒否された提案を改善した製品があることを意味するので、その改善された製品（４０６行）で以前に提案され購入（承認）された製品４０８である「製品Ｃ」を提案する。図３のフローチャートの説明に戻る。
【００４７】
次に、ステップＳ３０８において、製品買い替え提案サーバ２００のＣＰＵ２０１は、ステップＳ３０７で提案条件に改善があると判断された製品の情報を商品情報ＤＢから取得する。なお、提案条件が改善されているかどうかの情報を取得するため、ステップＳ３０７の処理の前に、複数の製品の改善点情報（図４の４０９）を取得して、ステップＳ３０７の判断で参照してもよい。図４の提案履歴ＤＢのデータ４１０を参照して説明する。
【００４８】
図４の４１０のデータにおいて、４０１行のユーザである岡村氏（４０３列）は過去の提案では、「手ぶれ補正の精度」が不満（４０５）で買い換え提案を拒否（４０４）した経歴を持つ。今回の提案では、前回の拒否理由であった「手ぶれ補正の精度」が改善されている（４０９）製品として、４０６行目の製品Ｃがあるため、その製品Ｃを提案製品（４０８）としてリストアップする（４１２行）。ステップＳ３０８において製品Ｃの商品情報を不図示の商品情報ＤＢから取得する。図３のフローチャートの説明に戻る。
【００４９】
次に、ステップＳ３０９において、ステップＳ３０８において取得した商品情報から販売価格などの買い替え提案情報を取得し、クライアント端末１００に送信するデータを付与する。
【００５０】
次に、ステップＳ３０５において、製品買い替え提案サーバ２００のＣＰＵ２０１は、今回の修理見積費用を算出するために修理回答者もしくは過去の修理履歴から算出される見積額の入力を受け付ける。また、ステップＳ３０９において取得した他の製品への買い替え情報も併せて取得し、クライアント端末１００に表示するためにクライアント端末１００に送信する。送信した後、クライアント端末１００の出力部２１０に表示される例を図６を参照して説明する。
【００５１】
図６は、本発明に係るクライアント端末１００の出力部２１０に出力される画面イメージを示した一例である。
【００５２】
図６の６００は、修理依頼側のクライアント端末１００の出力部２１０に出力される画面イメージ例であり、左側の６１１部分には買い換え製品に関する情報、右側の６１２部分には修理した際の見積金額などの情報が表示されている。
【００５３】
６１１内には、買い替え提案製品として、製品Ｃ（６０１欄）が指定されており、製品Ｃの改善点が６０２欄に表示されている。また、買い替え提案による見積価格を６０３で表示している。
【００５４】
６１２内には、故障製品の修理情報として修理見積価格情報（６１３欄）が表示されている
【００５５】
６１１と６１２の情報から、修理依頼のユーザが買い換えるか、修理を依頼するかを判断し『買替する』ボタン６２２、もしくは『修理する』ボタン６２３を押下する処理を実行する。『買替する』ボタン６２２が押下されると、６１１内の情報を参照して図示しない購入画面を表示し、製品買い替え提案サーバ２００のＣＰＵ２０１は、製品の買い替えを促す。一方、『修理する』ボタン６２３が押下された場合は、図示しない修理見積画面に遷移し、修理依頼のユーザに製品修理を促す。
【００５６】
以上の処理により、本発明は、ユーザにとって効果的な買い替え条件を提供でき、修理受付側がユーザに不信感を持たれにくい提案をする効果を有する。また、
【００５７】
なお、本実施形態では、上記のような構成で考えたが、データの構成や表示画面イメージおよびその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
【００５８】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【００５９】
なお、本実施形態中に示した各変形例を組み合わせた構成もすべて本発明に含まれるものである。
【００６０】
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【００６１】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【００６２】
本実施形態における図３に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【００６３】
以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【００６４】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【００６５】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【００６６】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６７】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６８】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【００６９】
さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【符号の説明】
【００７０】
１００  クライアント端末
１１０  ネットワーク
１１１  顧客ＤＢ
１１２  提案履歴ＤＢ
１１３  商品情報ＤＢ
２００  製品買い替え提案サーバ
【図１】
2017142734.tif 000003
【図２】
2017142734.tif 000004
【図３】
2017142734.tif 000005
【図４】
2017142734.tif 000006
【図５】
2017142734.tif 000007
【図６】
2017142734.tif 000008