(57)【要約】【課題】サービスの改善又は新機能の追加についての提案等を適切に評価する。【解決手段】提供サービスに対して登録された意見に対して賛同を表す情報を当該提供サービスのユーザである賛同者の端末から受信するステップと、受信した賛同を表す情報に応じて、意見の内容（例えばサービス内容改善又は新機能追加）、意見の提案者の属性（例えば利用頻度が高い、大口顧客企業に属するなど）及び意見の賛同者の属性のうち少なくともいずれかに基づき決定された判定基準を満たしたか判断する判断ステップと、判断基準を満たしたと判断された場合に、意見を重要な意見と識別するステップとを含む。このように意見の内容、意見の提案者の属性、意見の賛同者の属性などにより判断基準を変化させることで、例えばサービス提供者が例えば必要性の高い意見や顧客拡大・維持に繋がる意見といった重要な意見を容易に特定できるようになる。【選択図】　図１
2004086346.tif 000002
【特許請求の範囲】
【請求項１】
提供サービスに対して登録された意見に対して賛同を表す情報を当該提供サービスのユーザである賛同者の端末から受信するステップと、
受信した前記賛同を表す情報に応じて、前記意見の内容、前記意見の提案者の属性及び前記意見の賛同者の属性のうち少なくともいずれかに基づき決定された判定基準を満たしたか判断する判断ステップと、
前記判断基準を満たしたと判断された場合に、前記意見を重要な意見と識別するステップと、
を含む意見評価方法。
【請求項２】
前記判断ステップにおいて、
前記意見の内容に基づき当該意見が前記提供サービスのサービス内容改善に関するものであると判断された場合には、前記提供サービスのサービス内容改善に関する意見に対応する判断基準が用いられることを特徴とする請求項１記載の意見評価方法。
【請求項３】
前記判断ステップにおいて、
前記意見の提案者の属性に基づき特定される当該意見の提案者の優良度に対応する判断基準が用いられることを特徴とする請求項１又は２記載の意見評価方法。
【請求項４】
前記判断ステップにおいて、
前記意見の賛同者の属性に基づき特定される当該意見の賛同者の優良度に対応する判断基準が用いられることを特徴とする請求項１乃至３のいずれか１つ記載の意見評価方法。
【請求項５】
前記意見の提案者の属性に基づき特定される当該意見の提案者の優良度が所定のレベル以上の場合には、前記優良度に対応して前記ユーザのうち特定のユーザを抽出するステップと、
抽出された前記特定のユーザに対して前記意見の内容を優先提示するステップと、
をさらに含む請求項１乃至４のいずれか１つ記載の意見評価方法。
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】
本発明は、サービスの改善又は新機能の追加についての提案等の評価技術に関する。
【０００２】
【従来の技術】
ＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｅｒｖｉｃｅ　Ｐｒｏｖｉｄｅｒ）サービスにはＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ　Ｒｅｓｏｕｒｃｅ　Ｐｌａｎｎｉｎｇ）やＥＣ（Ｅｌｅｃｔｒｉｃ　Ｃｏｍｍｅｒｃｅ）を始め様々なものがある。しかし、ＡＳＰサービスを行う企業は、本業ではない業界や業種向けに少ない経験を元にサービスとしての場をシステム構築し、顧客企業などに提供していることが多い。従って、システム利用企業にとっては満足の行かない不完全な部分を抱えていることも多いが、改良案を提案する手段が無く、提案してもその見返りが無いような場合もあった。
【０００３】
利用者から意見を収集する従来技術として、絶版本の復刻サイトや、ユーザの商品アイデアを商品化するビジネスモデルでは、その企画案への賛同数（あるいは購入予定者数）が所定値を超えるとメーカに発注するというプロセスが採用されている場合が多い。すなわち、メーカはいわば売り切り限定商品を開発・生産することになる。
【０００４】
一方、ＡＳＰサービスのカスタマイズの場合は、カスタマイズ実施後も継続して多くのユーザに使用されるため、そのカスタマイズが本当に全ユーザ数拡大や大口顧客企業（ビックユーザ）引き留めにつながるか否かを見極める必要がある。従って、単純に画一的な賛同者数を基準にして提案されたカスタマイズ実施の可否を決定することは妥当ではない。
【０００５】
【非特許文献１】
アットコスメ［２００２年６月２５日検索］
ｈｔｔｐ：／／ｃｏｓｍｅ．ｎｅｔ／ｃｏｓｍｅ／ｅｖｅｎｔ／ｐａｓｔ／ｐｏｗｄｅｒ／ｈｔｍｌ／０５．ｈｔｍｌ
【非特許文献２】
復刊ドットコム［２００２年６月２７日検索］
ｈｔｔｐ：／／ｗｗｗ．ｆｕｋｋａｎ．ｃｏｍ
【０００６】
【発明が解決しようとする課題】
従って本発明の目的は、サービスの改善又は新機能の追加についての提案等を適切に評価するための技術を提供することである。
【０００７】
【課題を解決するための手段】
本発明に係る意見評価方法は、提供サービスに対して登録された意見に対して賛同を表す情報を当該提供サービスのユーザである賛同者の端末から受信するステップと、受信した賛同を表す情報に応じて、意見の内容（例えばサービス内容改善又は新機能追加）、意見の提案者の属性（例えば利用頻度が高い、大口顧客企業に属するなど）及び意見の賛同者の属性（例えば利用頻度が高い、大口子顧客企業に属するなど）のうち少なくともいずれかに基づき決定された判定基準を満たしたか判断する判断ステップと、判断基準を満たしたと判断された場合に、意見を重要な意見と識別するステップとを含む。
【０００８】
このように意見の内容、意見の提案者の属性、意見の賛同者の属性などにより判断基準を変化させることで、例えばサービス提供者が例えば必要性の高い意見や顧客拡大・維持に繋がる意見といった重要な意見を容易に特定できるようになる。すなわち、判断基準を各種条件に応じて動的に変化させ、適切な判断基準にて意見の重要性を判断するものである。
【０００９】
また、上で述べた判断ステップにおいて、意見の内容に基づき当該意見が提供サービスのサービス内容改善に関するものであると判断された場合には、提供サービスのサービス内容改善に関する意見に対応する判断基準が用いられるような構成であってもよい。
【００１０】
さらに、上で述べた判断ステップにおいて、意見の提案者の属性に基づき特定される当該意見の提案者の優良度に対応する判断基準が用いられるような構成であってもよい。提案者が優良ユーザであれば的を得た重要な意見である可能性が高いためである。
【００１１】
また、上で述べた判断ステップにおいて、意見の賛同者の属性に基づき特定される当該意見の賛同者の優良度に対応する判断基準が用いられるような構成であってもよい。賛同者が優良ユーザであれば処理対象の意見が的を得た重要な意見である可能性が高いためである。
【００１２】
さらに、意見の提案者の属性に基づき特定される当該意見の提案者の優良度が所定のレベル以上の場合には、優良度に対応してユーザのうち特定のユーザを抽出するステップと、抽出された特定のユーザに対して意見の内容を優先提示するステップとをさらに含む。例えば優良ユーザを抽出し、当該優良ユーザに対して例えばシステムアクセス時に意見内容を提示して、当該意見に賛同するか判断してもらうことにより、早期に意見の採否を確定させることができる。
【００１３】
なお、本発明に係る意見評価方法はプログラム及びコンピュータ・ハードウエアにて実施することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介して配布される場合もある。尚、中間的な処理結果はメモリに一時保管される。
【００１４】
【発明の実施の形態】
［処理の概要］
本実施の形態では、提案者の端末から提案データを受信すると、主に以下のような２つ観点で当該提案に対する投票の処理を振り分ける。
（１）提案者がヘビーユーザ（所定基準以上にＡＳＰサービスを利用しているユーザ。高利用者とも呼び、優良ユーザでもある。）か否か？
（２）提案内容が新機能か？又は現機能の欠点を改良・改善するための提案か？
（１）の場合、ＡＳＰサービスをよく利用している提案者の提案については、あまり利用しない提案者の提案よりも優先して当該提案の採否を決定すべきである。低利用者はＡＳＰサービスの機能について十分理解していないままに思い付きで提案してくる可能性が高い。従って、低利用者の提案については、優先的に当該提案の採否を判定する必要性は低く、従来通り単純に掲示板に掲載して、自主的に賛同の意思を示すユーザについて賛同者数をカウントして、基準に達したか判断する。なお、判断基準についても全賛同者数について設定された基準を満たした場合のみ、ＡＳＰ運営者に通知して、当該提案の検討を促す。
【００１５】
一方、高利用者は、ＡＳＰサービスを十分利用した上で提案するので、その内容は検討価値の高いものと思われる。そのため、全賛同者数について設定された通常の基準に達する以前に、ある特定の利用者から一定の賛同を得られればＡＳＰ運営者に通知して、早めに当該提案の検討を促すほうが良い。そこで、本実施の形態では、高利用者の提案ならば、全賛同者数についての基準より低い数の、特定の者についての判定基準を設定し、その低い判定基準を満たせば全賛同者数についての基準を満たしていなくとも、ＡＳＰ運営者に通知するような優先判定措置を採る。
【００１６】
さらに、本実施の形態では、高利用者の提案に対する優先判定措置として、単に掲示板一覧に掲載してユーザが閲覧するのを待つのではなく、低い判定基準を早期に満たすべく、特定の利用者がＡＳＰサービスにアクセスした時に、その提案内容を優先提示して、賛否の入力を促す。
【００１７】
この優先提示については、ＡＳＰサービスにアクセスした時だけではなく、例えば提案に関連する画面を特定のユーザが開いた時に実施するような構成であってもよい。この場合には、提案者に当該提案内容を思いついた画面を提案登録時に特定させ、当該画面の識別子を提案データに対応して登録しておけばよい。
【００１８】
また、高利用者の提案に対する優先判定措置を行う場合、本実施の形態では、さらに（２）の提案内容の種別によって、提案内容を優先的に提示する対象ユーザやその順序、判定基準を異なるようにしている。例えば、高利用者の提案内容が現機能の欠陥に対する改善案の場合、その改善が、特に所定基準以上のユーザを登録している大口利用（ビックユーザ）企業に所属するユーザに対して効果・魅力があることが大切である。何故ならば、現機能の欠陥への不満が続けば大口顧客が離れていってしまい、それに伴う損失が非大口顧客の場合より甚大だからである。従って、現機能改善に対する提案については、ビックユーザ企業のユーザ、それも、本ＡＳＰサービスを使い込んでいるヘビーユーザから優先的に提示するものとする。提案者自身がビックユーザ企業に所属するならば、同じ企業のヘビーユーザに最初に打診する。採用される判断基準については、提案者と同じビックユーザ企業に属するヘビーユーザについての基準と、提案者がヘビーユーザではあるがビックユーザ企業に所属していない場合における全ビックユーザ企業に属するヘビーユーザについての基準とを設けるが、両者の基準値は異なる。本実施の形態では、提案者と同一ビックユーザ企業に属するヘビーユーザにより支持される方を重要視し、低い賛同者数でも当該提案の検討に入るようにする。
【００１９】
一方、高利用者の提案内容が新機能追加の場合、その機能追加によって、より多くの新規顧客獲得をもたらすことが期待される。従って、改善案の場合とは異なり、現在ビックユーザ企業でない企業から、賛同が得られるかどうかが指標になる。そこで、新機能提案の場合は、まず、非ビックユーザ企業に属するヘビーユーザに対して、優先提示してゆく。そして、非ビックユーザ企業に属するヘビーユーザについての基準を達成することができたならば、第二段階として、ビックユーザ企業に属するヘビーユーザに優先提示する。この第二段階を用意する理由は、新機能がビックユーザ企業にとってもある程度価値があるものであることを確かめるためである。採用される判断基準については、ある程度非ビックユーザ企業に属するヘビーユーザから指示がなければ、当該新機能を導入する意味が無いので、非ビックユーザ企業に属するヘビーユーザについての基準を、第二段階におけるビックユーザ企業に属するヘビーユーザの基準よりも高くする。
【００２０】
以上のような複数の判定処理パターンを持つことで、柔軟な提案評価を実施し、効果的に提案をＡＳＰ運営者に告知することができる。
【００２１】
［具体的な実施の形態］
図１に本実施の形態に係るシステム概要図を示す。例えばインターネットであるネットワーク１１０には、ＡＳＰシステム１００と、ＡＳＰシステム１００のユーザが操作し且つ例えばパーソナル・コンピュータである１又は複数のユーザ端末１２０と、ＡＳＰシステム１００の管理・運営を行っているＡＳＰ運営者が操作し且つ例えばパーソナル・コンピュータである１又は複数のＡＳＰ運営者端末１３０とが接続されている。
【００２２】
ＡＳＰシステム１００には、所定のＡＳＰサービスを提供するための処理部（図示せず）と共に、提案に対する賛否の投票を特定のユーザに促すなどの処理を実施する投票処理部１０１と、ユーザにより入力された提案に対する賛否の投票の集計処理を実施する集計処理部１０２と、掲示板に掲載される提案データを管理する掲示板データ管理部１０７と、投票処理部１０１により参照され且つＡＳＰサービス利用企業及びその社員ユーザを管理するための企業別ＩＤ管理ＤＢ１０３と、投票処理部１０１により参照され且つ各ユーザの利用実績データを管理するための個人別利用実績ＤＢ１０４と、投票処理部１０１及び集計処理部１０２により管理され、且つ判断基準についてのデータを保持する投票基準管理テーブル及び各提案についての投票状況を管理する投票管理テーブルを保持する投票管理ＤＢ１０５と、集計処理部１０２により管理され且つ投票履歴を蓄積する投票履歴ＤＢ１０６と、掲示板データ管理部１０７により管理され且つ提案データを格納する提案データＤＢ１０８とが含まれる。
【００２３】
ユーザ端末１２０には、ウェブ（Ｗｅｂ）ブラウザプログラム１２１と電子メールプログラム１２２とが備えられており、ブラウザプログラム１２１によりＡＳＰシステム１００にアクセスして、例えばＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）ファイル等の表示を行ったり、電子メールプログラム１２２によりＡＳＰシステム１００その他に電子メールを送信したりする。なお、提案を行う場合には、電子メール形式で提案データを送信する場合もあれば、ブラウザプログラム１２１により提案データを送信する場合もある。ＡＳＰ運営者端末１３０には、Ｗｅｂブラウザプログラム１３１と電子メールプログラム１３２とが設けられており、例えばブラウザプログラム１３１によりＡＳＰシステム１００にアクセスして、例えば管理用のＨＴＭＬファイル等の表示を行ったり、電子メールプログラム１３２によりＡＳＰシステム１００から検討すべき提案データについて電子メールを受信して、表示装置に表示したりする。
【００２４】
次に図２に企業別ＩＤ管理ＤＢ１０３に格納される企業別ＩＤ管理テーブルの一例を示す。図２に示した企業別ＩＤ管理テーブルの例では、企業ＩＤの列２０１と、個人ＩＤ数の列２０２と、個人ＩＤの列２０３とが含まれている。このようにして、各企業におけるユーザ数を個人ＩＤ数の列２０２の値で判断することができる。例えば５００以上の値を有する企業をビックユーザ企業と判断する。
【００２５】
図３に個人別利用実績ＤＢ１０４に格納される個人別利用実績テーブルの一例を示す。図３に示した個人別利用実績テーブルの例では、個人ＩＤの列３０１と、所属企業の列３０２と、一月当りの利用回数の列３０３と、一月当りの利用時間（分）の列３０４と、１回当りの平均利用時間（分）の列とが設けられている。このようにして各ユーザの利用状況に関する情報を得ることができ、例えば１回当りの平均利用時間が２０分以上のユーザをヘビーユーザとして特定することができるようになる。
【００２６】
図４に投票管理ＤＢ１０５に格納される投票基準管理テーブルの一例を示す。図４に示した投票基準管理テーブルでは、提案者種別の列４０１と、提案の内容種別の列４０２と、提案者と同一ビックユーザ企業に属するヘビーユーザの賛同者数についての基準（以下「目標自ビック」と呼ぶ）の列４０３と、全ビックユーザ企業に属するヘビーユーザの賛同者数についての基準（以下「目標自＋他ビック」と呼ぶ）の列４０４と、非ビックユーザ企業に属するヘビーユーザの賛同者数についての基準（以下「目標非ビック」と呼ぶ）の列４０５と、ヘビーユーザ又は非ヘビーユーザ全体の賛同数についての基準（以下「目標全体」と呼ぶ）の列４０７と、登録期限の基準日数の列４０７とが含まれる。
【００２７】
本実施の形態において、提案者種別には、ヘビーユーザと、非ヘビーユーザとが含まれ、ヘビーユーザによる提案であれば特定のユーザ（ビックユーザ企業のヘビーユーザなど）による比較的少数の賛同を得ればＡＳＰ運営者に提案を通知して、当該提案の検討を依頼するようになっている。一方、非ヘビーユーザによる提案であれば特別な取り扱いは行わず、全賛同者数がその基準に達しない限り、当該提案の検討を依頼しないようになっている。
【００２８】
また内容種別については、サービスの欠陥改善についての提案なのか（「欠陥」と記す）、サービスの新規機能追加についての提案なのか（「新規」と記す）、その両方なのか（「一般」と記す）が、提案内容から特定される。なお、提案入力画面にて、「欠陥」「新規」を提案者に入力させるようにしても良いし、記述内容を解析して「欠陥」「新規」を特定するようにしてもよい。図４の例では、「一般」となるのは、非ヘビーユーザの場合であるから、提案者が非ヘビーユーザであると判断された場合には提案内容の種別を特定する必要は無い。
【００２９】
なお、提案者がヘビーユーザであってビックユーザ企業に属しており、提案内容種別が「欠陥」であった場合、賛同者がヘビーユーザであって且つ提案者と同一のビックユーザ企業に属していれば、当該賛同者により「目標自ビック」「目標自＋他ビック」及び「目標全体」に対する実績賛同者数が１インクリメントされる。そして、いずれかの実績賛同者数が対応する基準を満たしていれば、ＡＳＰ運営者に対して当該提案を通知して検討を依頼する。また、提案者がヘビーユーザであって、提案内容種別が「欠陥」であった場合、賛同者がヘビーユーザであって且つ提案者が属する企業とは別のビックユーザ企業に属していれば、当該賛同者により「目標自＋他ビック」及び「目標全体」に対する実績賛同者数が１インクリメントされる。そして、そのいずれかの基準を満たしていれば、ＡＳＰ運営者に対して当該提案を通知して検討を依頼する。提案者がヘビーユーザであって、提案内容種別が「欠陥」であった場合、賛同者が非ヘビーユーザであれば、当該賛同者により「目標全体」に対する実績賛同者数が１インクリメントされる。そして、「目標全体」の基準を満たしていれば、ＡＳＰ運営者に対して当該提案を通知して検討を依頼する。このように、賛同者の属性によっても、適用される基準は変化する。
【００３０】
また、提案者がヘビーユーザであって、提案内容種別が「新規」であった場合、賛同者がヘビーユーザであってビックユーザ企業に属していれば、当該賛同者により「目標自＋他ビック」及び「目標全体」に対する実績賛同者数が１インクリメントされる。本実施の形態では、「目標全体」の基準を達成するか、又は別の賛同者により「目標非ビック」の基準が達成され且つ「目標自＋他ビック」の基準が達成された場合には、ＡＳＰ運営者に対して当該提案を通知して検討を依頼する。提案者がヘビーユーザであって、提案内容種別が「新規」であった場合、賛同者がヘビーユーザであって非ビックユーザ企業に属していれば、当該賛同者により「目標非ビック」及び「目標全体」に対する実績賛同者数が１インクリメントされる。本実施の形態では、「目標全体」の基準を達成するか、又は別の賛同者により「目標自＋他ビック」の基準が達成され且つ「目標非ビック」の基準が達成された場合には、ＡＳＰ運営者に対して当該提案を通知して検討を依頼する。提案者がヘビーユーザであって、提案内容種別が「新規」であった場合、賛同者が非ヘビーユーザであれば、当該賛同者により「目標全体」に対する実績賛同者数が１インクリメントされる。そして、「目標全体」の基準を満たしていれば、ＡＳＰ運営者に対して当該提案を通知して検討を依頼する。このように、賛同者の属性によっても、適用される基準は変化する。
【００３１】
提案者が非ヘビーユーザであれば、賛同者がいずれの属性を有していようとも「目標全体」に対する実績賛同者数が１インクリメントされ、当該「目標全体」の基準を達していればＡＳＰ運営者に対して当該提案を通知して検討を依頼する。
【００３２】
図５に投票管理ＤＢ１０５に格納された投票管理テーブルの一例を示す。図５に示した投票管理テーブルの例では、提案ＩＤの列５０１と、内容種別の列５０２と、「目標自ビック」の列５０３と、「目標自＋他ビック」の列５０４と、「目標非ビック」の列５０５と、「目標全体」の列５０６と、提案者と同一ビックユーザ企業に属するヘビーユーザである賛同者の実績数（以下「実績自ビック」と呼ぶ）の列５０７と、全ビックユーザ企業に属するヘビーユーザである賛同者の実績数（以下「実績自＋他ビック」と呼ぶ）の列５０８と、非ビックユーザ企業に属するヘビーユーザである賛同者の実績数（以下「実績非ビック」と呼ぶ）の列５０９と、全賛同者の実績数（以下「実績全体」と呼ぶ）の列５１０と、提案者個人ＩＤの列５１１と、提案者企業ＩＤの列５１２と、提案登録時刻の列５１３と、掲示板表示期限の列５１４と、提案可否フラグの列５１５と、終了フラグの列５１６とが含まれる。
【００３３】
投票処理部１０１は、受信した提案データのために、投票管理テーブルに新たなレコードを生成する。提案ＩＤは例えば投票処理部１０１により発行され、レコードはこの提案ＩＤにより特定される。そして、当該提案データの提案者がヘビーユーザか否か及び提案内容が「欠陥」又は「新規」であるかという判別結果及び投票基準管理テーブルの値に基づき、内容種別の列５０２と、目標自ビックの列５０３と、目標自＋他ビックの列５０４と、目標非ビックの列５０５と、目標全体の列５０６とに値を登録する。また、提案者の個人ＩＤの列５１１、所属企業ＩＤの列５１２、登録時刻の列５１３、及び掲示板表示期限の列５１４にも、提案者のユーザＩＤ、企業ＩＤ、登録時刻、投票基準管理テーブルの登録期限のデータに基づく掲示板表示期限をそれぞれ登録する。集計処理部１０２は、特定の提案ＩＤについて賛同を表す情報をユーザ端末１２０から受信すると、投票管理テーブルを提案ＩＤで検索して、賛同者の属性から実績自ビックの列５０７、実績自＋他ビックの列５０８、実績非ビックの列５０９、実績全体の列５１０に登録されている少なくとも１つの値を１インクリメントする。
【００３４】
図６に投票履歴ＤＢ１０６に格納された投票履歴テーブルの一例を示す。図６に示した投票履歴テーブルの例では、投票者の個人ＩＤの列６０１と、所属企業ＩＤの列６０２と、投票時刻又はアクセス時刻の列６０３と、投票対象の提案ＩＤの列６０４と、投票種別の列６０５と、賛否フラグの列６０６とが含まれている。本実施の形態では、掲示板に掲示されている状態では、「賛同しない」という投票はできないが、特定ユーザへの優先提示の場合には「賛同する」又は「賛同しない」という投票を行うことができるようになっている。このようにすれば、後に説明するように特定ユーザとして抽出されたユーザに何度も同じ提案についてポップアップ画面を表示させることが無くなる。掲示板を見て賛同を表明したユーザの場合には投票種別の列６０５に「ＫＥＩＪＩＢＡＮ」というコードが登録される。一方、特定ユーザとして抽出されたユーザについては、投票種別の列６０５に「ＡＣＣＥＳＳ」というコードが登録される。上で述べたように、投票種別の列６０５に「ＫＥＩＪＩＢＡＮ」というコードが登録されると、賛否フラグの列６０６には「○（賛同を表す）」のみが登録されるが、「ＡＣＣＥＳＳ」というコートが登録されると、賛否フラグの列６０６には「○」又は「×（「賛同しない」を表す）」も登録される。
【００３５】
以下、図１に示したシステムの処理を図７乃至図１４を用いて説明する。最初に、ＡＳＰシステム１００は、ユーザ端末１２０からネットワーク１１０を介して提案データを受信し、一旦記憶装置に格納する（ステップＳ１）。上でも述べたが、ユーザは、メールで提案データを送信しても良いし、ブラウザプログラム１２１により送信してもよい。そして、投票処理部１０１は、提案ＩＤを発行すると共に、提案データ及び個人別利用実績ＤＢ１０４に格納された個人別利用実績テーブルなどから提案者及び提案者の属する企業などを識別し（ステップＳ３）、掲示板データ管理部１０７は提案ＩＤ及び提案データを提案データＤＢ１０８に登録・保存する（ステップＳ５）。この際、投票処理部１０１は、当該提案のためのレコードを投票管理ＤＢ１０５の投票管理テーブルに生成し、提案ＩＤ、提案者ＩＤ及び提案者の所属する企業ＩＤ等のデータを登録する。
【００３６】
そして、投票処理部１０１は、提案者がヘビーユーザであるかを、個人別利用実績ＤＢ１０４に格納された個人別利用実績テーブルのデータに基づき判断する（ステップＳ７）。もし、提案者がヘビーユーザではないと判断された場合には（ステップＳ７：Ｎｏルート）、掲示板データ管理部１０７は提案データＤＢ１０８に掲示板表示対象であることを当該提案ＩＤに対応して登録し（ステップＳ９）、投票処理部１０１は、投票管理ＤＢ１０５に格納された投票基準管理テーブルを参照して非ヘビーユーザの判断基準のデータを読み出し、当該提案ＩＤに対応して投票管理テーブルに登録する。そして、掲示板集計処理を実施する（ステップＳ１１）。掲示板集計処理については後に図１３を用いて説明する。ステップＳ１１の後に端子Ａを介して処理を終了する。
【００３７】
一方、提案者がヘビーユーザであると判断された場合には（ステップＳ７：Ｙｅｓルート）、投票処理部１０１は提案内容が新機能の追加についての提案かを判断する（ステップＳ１３）。もし、新機能の追加についての提案であると判断された場合には（ステップＳ１３：Ｙｅｓルート）、新機能投票処理を実施する（ステップＳ１５）。この新機能投票処理については後に図１４を用いて説明する。ステップＳ１５の後に端子Ａを介して処理を終了する。
【００３８】
また、提案内容がサービス内容の改善についての提案であると識別された場合には（ステップＳ１３：Ｎｏルート）、投票処理部１０１は、提案者の所属する企業がビックユーザ企業であるかを、企業別ＩＤ管理ＤＢ１０３に格納された企業別ＩＤ管理テーブルを参照して判断する（ステップＳ１７）。もし、提案者の所属企業がビックユーザ企業である場合には（ステップＳ１７：Ｙｅｓルート）、まず掲示板データ管理部１０７は提案データＤＢ１０８に掲示板表示対象であることを当該提案ＩＤに対応して登録し（ステップＳ２３）、投票処理部１０１は、投票管理ＤＢ１０５に格納された投票基準管理テーブルを参照して提案者がヘビーユーザであって提案内容が「欠陥」についての判断基準のデータを読み出し、当該提案ＩＤに対応して投票管理テーブルに登録する。これにより、当該提案についての掲示板表示が行われるようになる。例えばユーザがユーザ端末１２０を操作して、ブラウザプログラム１２１にＡＳＰシステム１００の提案事項についての掲示板ページへアクセスさせると、例えば図８のような表示がなされる。図８の例では、各提案につき、項番（提案ＩＤ）、種別（「欠陥」又は「新規」）、提案タイトル、投票期限についての情報が表示されるようになっている。また、各提案にはチェックボックス８０１，８０２が設けられており、提案内容を表示させるための表示ボタン８０３も設けられている。ここで、例えば案０３５という提案を表示させる場合には、チェックボックス８０２にチェックを付して、表示ボタン８０３をクリックすると、図９に示すような提案内容を表示させることができるようになっている。図９の例では、提案ＩＤ、提案種別、提案内容、理由、投票期限、賛同ボタン９０１及び前のページに戻るための戻るボタン９０２とが含まれる。ユーザは、このページで提案内容を確認の上、当該提案に賛同する場合には賛同ボタン９０１をクリックし、賛同しない場合には例えば戻るボタン９０２をクリックして図８のページに戻る。
【００３９】
図７の説明に戻って、投票処理部１０１は、個人別利用実績ＤＢ１０４に格納された個人別利用実績テーブルを参照して、提案者所属企業のヘビーユーザを抽出し、リストアップする（ステップＳ２５）。抽出された提案者所属企業のヘビーユーザのリストは、記憶装置に保持される。そして、リストアップされたユーザのアクセス時（例えばログイン時）に提案内容をポップアップ表示させる（ステップＳ２７）。なお、投票履歴ＤＢ１０６を参照して、既に同一提案につき投票しているか否かを確認の上ポップアップ表示させるかを決定する。より具体的には、ポップアップ表示するためのＨＴＭＬファイルなどをユーザ端末１２０に送信し、当該ＨＴＭＬファイルなどを受信したユーザ端末１２０がブラウザプログラム１２１により表示装置に表示する。例えば図１０に示すような表示がなされる。図１０の例では、ウインドウ１００１が、ＡＳＰシステム１００のログイン後の初期メニュー画面である。ウインドウ１００１には、ユーザＩＤ、現在時刻、使用時間、発注ボタン、取消しボタン、履歴ボタン、問合せボタン、終了ボタンなどが含まれている。一方、ポップアップウインドウ１００２には、提案ＩＤ、提案種別、提案内容、提案理由、投票期限といった図９で示した内容と同じものと、賛同ボタン１００３と、賛同しないボタン１００４とが設けられている。ユーザは賛同する場合には賛同ボタン１００３をクリックする。賛同しない場合には賛同しないボタン１００４をクリックする。このクリックに応じてユーザ端末１２０は、賛同を表す情報又は賛同しないことを表す情報をＡＳＰシステム１００に送信する。なお、賛同ボタン１００３又は賛同しないボタン１００４をクリックすると、ポップアップウインドウ１００２が閉じるような構成の場合もある。ユーザがいずれのボタンをも押さずにポップアップウインドウ１００２を閉じると、次のアクセス時にも再度同じポップアップウインドウ１００２が開く場合がある。
【００４０】
ＡＳＰシステム１００の集計処理部１０２は、ユーザ端末１２０から賛否を表す情報を受信し、投票履歴ＤＢ１０６に、個人ＩＤ、企業ＩＤ、投票時刻、提案ＩＤ、投票種別（ここではＡＣＣＥＳＳ）、賛否フラグを含む投票履歴を登録すると共に、賛同を表す情報を受信した場合には、投票管理ＤＢ１０５に格納された投票管理テーブルの当該提案ＩＤのレコードにおいて「実績自ビック」の列５０７のカウント値と「実績自＋他ビック」の列５０８のカウント値と「実績全体」の列５１０のカウント値とを１インクリメントして登録する（ステップＳ２９）。そして、集計処理部１０２は、賛同者数が目標数以上になったか判断する（ステップＳ３１）。具体的には、「実績自ビック」の値が「目標自ビック」の値以上になったか、「実績自＋他ビック」の値が「目標自＋他ビック」の値以上になったか、又は「実績全体」の値が「目標全体」の値以上になったかを判断する。
【００４１】
もし、賛同者数が目標数以上ではない、すなわち賛同者数が目標数未満である場合には（ステップＳ３１：Ｎｏルート）、投票処理部１０１は所定のタイミングになったか判断する（ステップＳ３３）。所定のタイミングとは、例えば提案データの登録時刻から所定時間たった時、又はステップＳ２５においてリストアップされたユーザのうち所定人数の回答を得た時である。もし、所定のタイミングとなっていない場合には（ステップＳ３３：Ｎｏルート）、ステップＳ２７に戻る。すなわち、ステップＳ２５においてリストアップされたユーザによるアクセス時に、提案データのポップアップ表示を行う。このようにして、提案者と同一ビックユーザ企業に属するヘビーユーザについては、能動的に掲示板を見に行かずとも、アクセス時に提案内容が提示されるので、当該ヘビーユーザからの応答を比較的早く得ることができるようになる。一方、所定のタイミングになったと判断された場合（ステップＳ３３：Ｙｅｓルート）、端子Ｄを介して図１１のステップＳ３５に遷移する。これはなかなか賛同者が集まらない場合である。また、賛同者数が目標数以上となった場合（ステップＳ３１：Ｙｅｓルート）、端子Ｅを介して図１１のステップＳ４３に移行する。
【００４２】
さらにステップＳ１７において提案者の所属企業がビックユーザ企業ではないと判断された場合（ステップＳ１７：Ｎｏルート）、投票処理部１０１は企業別ＩＤ管理ＤＢ１０３に格納された企業別ＩＤ管理テーブルを参照してビックユーザ企業を特定し、さらに個人別利用実績ＤＢ１０４に格納された個人別利用実績テーブルを参照してビックユーザ企業に所属するヘビーユーザを抽出し、リストアップする（ステップＳ１９）。抽出されたビックユーザ企業のヘビーユーザのリストは、記憶装置に保持される。そして、掲示板データ管理部１０７は提案データＤＢ１０８に掲示板表示対象であることを当該提案ＩＤに対応して登録する（ステップＳ２３）。また、投票処理部１０１は、投票管理ＤＢ１０５に格納された投票基準管理テーブルを参照して提案者がヘビーユーザであって提案内容が「欠陥」についての判断基準のデータを読み出し、当該提案ＩＤに対応して投票管理テーブルに登録する。その後の処理は端子Ｂを介して図１１のステップＳ３７に遷移する。
【００４３】
端子Ｄを介してステップＳ３５に遷移した場合、投票処理部１０１は企業別ＩＤ管理ＤＢ１０３に格納された企業別ＩＤ管理テーブルを参照して、提案者の所属企業以外の他のビックユーザ企業を特定し、個人別利用実績ＤＢ１０４に格納された個人別利用実績テーブルを参照して特定されたビックユーザ企業のヘビーユーザを抽出し、リストアップする（ステップＳ３５）。抽出された他のビックユーザ企業のヘビーユーザのリストは、記憶装置に保持される。そして、投票処理部１０１は、ステップＳ３５又はステップＳ１９でリストアップされたユーザのアクセス時に提案内容をポップアップ表示する（ステップＳ３７）。なお、投票履歴ＤＢ１０６を参照して、既に同一提案につき投票しているか否かを確認の上ポップアップ表示させるかを決定する。ここではステップＳ２７と同様の処理を実施する。このように、ビックユーザ企業のヘビーユーザに、優先して提案内容を提示し、賛否を登録してもらうことにより、早期に当該提案の採否をＡＳＰ運営者に決定させることができるようになる。
【００４４】
ポップアップ表示に対応してユーザが賛同ボタン又は賛同しないボタンをクリックすると、賛否を表す情報をユーザ端末１２０がＡＳＰシステム１００へ送信する。ＡＳＰシステム１００の集計処理部１０２は、賛否を表す情報を受信し、投票履歴ＤＢ１０６に投票履歴を登録すると共に、賛同を表す情報を受信した場合には、投票管理ＤＢ１０５に格納された投票管理テーブルの当該提案ＩＤのレコードにおいて「実績自＋他ビック」の列５０８のカウント値と「実績全体」の列５１０のカウント値とを１インクリメントして登録する（ステップＳ３９）。そして、集計処理部１０２は、賛同者数が目標数以上になったか判断する（ステップＳ４１）。具体的には、「実績自＋他ビック」の値が「目標自＋他ビック」の値以上になったか、又は「実績全体」の値が「目標全体」の値以上になったかを判断する。
【００４５】
もし、賛同者数が目標数以上となった場合には（ステップＳ４１：Ｙｅｓルート）、集計処理部１０２は、当該提案内容をＡＳＰ運営者に通知する（ステップＳ４３）。端子Ｅを介して遷移してきた場合も同様である。例えば図１２に示すような通知をＡＳＰシステム１００は例えば電子メールで送信し、ＡＳＰ運営者端末１３０では電子メールプログラム１３２で受信し、表示装置に表示する。図１２の例では、提案ＩＤ、提案者情報（ユーザＩＤ、所属企業属性及び個人属性）、提案種別、提案内容、理由、登録時刻、基準値達成時刻、基準達成段階（達成基準種別）、投票結果情報とが含まれている。基準達成段階及び投票結果情報を含めることにより、ＡＳＰ運営者はいずれのユーザ層に支持される提案なのかを把握できるようになる。提案内容を通知すると、集計処理部１０２は、投票管理ＤＢ１０５に格納された投票管理テーブルにおいて提案可否フラグの列５１５に提案可を表すコードと、終了フラグの列５１６に終了を表す「１」とを登録して、処理を終了する。
【００４６】
一方、賛同者数が目標数未満である場合には（ステップＳ４１：Ｎｏルート）、所定のタイミングになったか判断する（ステップＳ４５）。所定のタイミングは、例えばステップＳ１９又はステップＳ３５で抽出されたユーザのうち所定人数賛否を表す情報を返信してきた時、又は登録時刻から所定時刻経過した時である。もし、所定のタイミングになっていないと判断された場合には（ステップＳ４５：Ｎｏルート）、ステップＳ３７に戻る。一方、所定のタイミングになったと判断された場合には（ステップＳ４５：Ｙｅｓルート）、掲示板集計処理に移行し（ステップＳ４７）、処理を終了する。
【００４７】
以上説明したように、提案者がヘビーユーザであって所属企業がビックユーザ企業である場合には、同一ビックユーザ企業に所属するヘビーユーザに優先的に賛否を判断してもらい、もし賛同が得られない場合には他のビックユーザ企業に属するヘビーユーザに賛否を判断してもらう。このように段階的に優先提示対象を広げる構成を採用している。これにより早期にビックユーザ企業に支持される提案であるかを判断できるようになり、早期にサービス内容の改善を図ることができるようになる。また、提案者がヘビーユーザではあるが所属企業がビックユーザ企業ではない場合には、ビックユーザ企業に所属するヘビーユーザに優先的に賛否を判断してもらう。これにより、ビックユーザ企業のニーズを早期に把握でき、対処も早期に実施できるようになる。ビックユーザ企業のヘビーユーザによる支持が所定のタイミングまでに得られなければ、通常どおり掲示板での投票にてＡＳＰ運営者に通知するか否かを決定することができる。
【００４８】
次に図１３を用いて掲示板集計処理について説明する。掲示板表示については、図８及び図９を用いて説明したように、ユーザ端末１２０からのアクセスに応じて提案内容を提示するものであり、従来と変わらないのでここでは詳細に述べない。集計処理部１０２は、現在時刻が投票管理ＤＢ１０５の投票管理テーブルの掲示板表示期限の列５１４に登録された提示期限以前であるか判断する（ステップＳ５１）。すなわち、現在時刻が提示期限を経過するまで以下の処理を繰り返すことを意味する。なお、現在時刻が提示期限を経過した場合には（ステップＳ５１：Ｎｏルート）、当該提案ＩＤに対応して、投票管理ＤＢ１０５に格納された投票管理テーブルの終了フラグの列５１６に終了を表す「１」を登録し、提案データＤＢ１０８に当該提案ＩＤに対応して削除を表すデータを登録する（ステップＳ７１）。そして当該提案についての処理を終了する。集計処理部１０２は、さらに投票管理ＤＢ１０５に格納された投票管理テーブルにおいて提案可否フラグの列５１５に提案不可を表すコードも登録する。
【００４９】
一方、現在時刻が提示期限以前であれば（ステップＳ５１：Ｙｅｓルート）、集計処理部１０２は、賛同を表すデータを受信すると（ステップＳ５３）、当該賛同者の情報等を投票履歴ＤＢ１０６の投票履歴テーブルに登録する（ステップＳ５５）。そして、投票処理部１０１は、個人別利用実績ＤＢ１０４に格納された個人別利用実績テーブルに基づき当該賛同者がヘビーユーザか否か判断する（ステップＳ５７）。さらに、投票処理部１０１は、企業別ＩＤ管理ＤＢ１０３に格納された企業別ＩＤ管理テーブルに基づき、賛同者がビックユーザ企業に属するか否かを判断する（ステップＳ５９）。なお、ここで、提案者の属する企業と賛同者の属する企業が同一であるか否かも判断することができる。
【００５０】
そして、投票管理ＤＢ１０５に格納された投票管理テーブルにおいて、集計処理部１０２は、該当する属性枠の実績賛同者数を１インクリメントして、登録する（ステップＳ６１）。もし、提案内容が「欠陥」であり且つ提案者がヘビーユーザであって所属企業がビックユーザ企業の場合、賛同者がヘビーユーザであって提案者と同一のビックユーザ企業に属しているならば、「実績自ビック」及び「実績自＋他ビック」の各値を１インクリメントする。提案内容が「欠陥」であり且つ提案者がヘビーユーザであって所属企業がビックユーザ企業である場合、賛同者がヘビーユーザであって提案者の所属企業とは別のビックユーザ企業に属しているならば、「実績自＋他ビック」の値を１インクリメントする。提案内容が「欠陥」であり且つ提案者がヘビーユーザであっても賛同者が非ビックユーザであれば、ステップＳ６１はスキップされる。提案内容が「欠陥」であり且つ提案者がヘビーユーザであるが所属企業が非ビックユーザ企業の場合、賛同者がヘビーユーザであってビックユーザ企業に属していれば、「実績自＋他ビック」の値を１インクリメントする。
【００５１】
提案内容が「新規」であり且つ提案者がヘビーユーザである場合、賛同者がヘビーユーザであってビックユーザ企業に属しているならば、「実績自＋他ビック」の値を１インクリメントする。提案内容が「新規」であり且つ提案者がヘビーユーザである場合、賛同者がヘビーユーザであって非ビックユーザ企業に属しているならば、「実績非ビック」の値を１インクリメントする。提案者が非ヘビーユーザであれば、ステップＳ６１はスキップされる。
【００５２】
また、集計処理部１０２は、投票管理ＤＢ１０５に格納された投票管理テーブルにおいて、当該提案に対応する総賛同者数、すなわち「実績全体」の値を１インクリメントし、登録する（ステップＳ６３）。そして、集計処理部１０２は、目標数を達したか判断する（ステップＳ６５）。提案者がヘビーユーザであって提案内容が「欠陥」である場合には、「実績自ビック」の値が「目標自ビック」の値以上になったか（賛同者が提案者と同一ビックユーザ企業に属しており且つ賛同者がヘビーユーザの場合）、「実績自＋他ビック」の値が「目標自＋他ビック」の値以上になったか（賛同者がビックユーザ企業に属しており且つ賛同者がヘビーユーザの場合）、又は「実績全体」の値が「目標全体」の値以上になったかを判断する。提案者がヘビーユーザであって提案内容が「新規」である場合には、「実績非ビック」の値が「目標非ビック」の値以上であって且つ「実績自＋他ビック」の値が「目標自＋他ビック」の値以上となったか（賛同者がヘビーユーザの場合）、又は「実績全体」の値が「目標全体」の値以上となったかを判断する。また提案者が非ヘビーユーザであれば、「実績全体」の値が「目標全体」の値以上であるか判断する。なお、目標数を達していない場合にはステップＳ５１に戻る。
【００５３】
目標数に達したと判断された場合には、これ以上ユーザに賛同を表す情報を送信してもらう必要はないので、掲示板における賛同ボタンを非表示にする設定を行う（ステップＳ６７）。例えば提案データＤＢ１０８において提案ＩＤに対応して「非表示」のフラグをセットする。又は、提案ＩＤに対応して投票管理ＤＢ１０５に格納された投票管理テーブルにおける終了フラグを「１」にセットすることにより「非表示」設定とする場合もある。そして、集計処理部１０２はＡＳＰ運営者（管理者）に対して当該提案について通知を実施する（ステップＳ６９）。これは図１１のステップＳ４３と同様の処理を実施する。そして処理を終了する。
【００５４】
このように、特定のユーザに優先提示した後又は優先提示中若しくは優先提示がない場合であっても、掲示板に提示した状態で自発的に賛同を表す情報をユーザ端末１２０から受信した場合には、提案者の属性、賛同者の属性、提案の内容に応じた賛同者数をカウントアップすると共に、同じく提案者の属性、賛同者の属性、提案の内容に応じた基準と比較して、提案の通知の是非を判断する。掲示板に提示されている状態で賛同を表す情報を受信した場合であっても、判断基準は単純な総賛同者数ではないように設定されている場合もあるので、早期に提案の通知の是非を決定できる場合もある。
【００５５】
図１４を用いて新規機能追加についての提案を処理するための処理フローを説明する。最初に、掲示板データ管理部１０７は提案データＤＢ１０８に掲示板表示対象であることを当該提案ＩＤに対応して登録し（ステップＳ８１）、投票処理部１０１は、投票管理ＤＢ１０５に格納された投票基準管理テーブルを参照して提案者がヘビーユーザであって提案内容が「新規」についての判断基準のデータを読み出し、当該提案ＩＤに対応して投票管理テーブルに登録する。そして、投票処理部１０１は、企業別ＩＤ管理ＤＢ１０３に格納された企業別ＩＤ管理テーブルを参照して非ビックユーザ企業を特定し、さらに個人別利用実績ＤＢ１０４に格納された個人別利用実績テーブルを参照して非ビックユーザ企業のヘビーユーザを抽出し、リストアップする（ステップＳ８３）。抽出されたヘビーユーザのリストは、記憶装置に保持される。そして、投票処理部１０１は、リストアップされたユーザのアクセス時に提案内容をポップアップ表示する（ステップＳ８５）。なお、投票履歴ＤＢ１０６を参照して、既に同一提案につき投票しているか否かを確認の上ポップアップ表示させるかを決定する。より具体的には、ポップアップ表示するためのＨＴＭＬファイルなどをユーザ端末１２０に送信し、当該ＨＴＭＬファイルなどを受信したユーザ端末１２０がブラウザプログラム１２１により表示装置に表示する。例えば図１０に示すような表示がなされる。ここでは、新規機能追加が、非ビックユーザ企業のヘビーユーザに受け入れられるかを優先的に確認するものである。
【００５６】
集計処理部１０２は、ユーザ端末１２０から賛否を表す情報を受信し、投票履歴ＤＢ１０６に投票履歴を登録すると共に、賛同を表す情報を受信した場合には、投票管理ＤＢ１０５に格納された投票管理テーブルの当該提案ＩＤのレコードにおいて「実績非ビック」の列５０９のカウント値と「実績全体」の列５１０のカウント値とを１インクリメントして登録する（ステップＳ８７）。そして、集計処理部１０２は、「実績非ビック」の列５０９のカウント値が「目標非ビック」の値以上になったか判断する（ステップＳ８９）。もし、「実績非ビック」の列５０９のカウント値が「目標非ビック」の値未満である場合には（ステップＳ８９：Ｎｏルート）、所定のタイミングになったか判断する（ステップＳ９１）。所定のタイミングとは、例えば提案データの登録時刻から所定時間たった時、又はステップＳ８３においてリストアップされたユーザのうち所定人数の回答を得た時である。もし、所定のタイミングとなっていない場合には（ステップＳ９１：Ｎｏルート）、ステップＳ８５に戻る。すなわち、ステップＳ８３においてリストアップされたユーザによるアクセス時に、提案データのポップアップ表示を行う。一方、所定のタイミングとなった場合には（ステップＳ９１：Ｙｅｓルート）、掲示板集計処理を実施する（ステップＳ９３）。そして処理を終了する。
【００５７】
ステップＳ８９で「実績非ビック」の列５０９のカウント値が「目標非ビック」の値以上であると判断された場合には（ステップＳ８９：Ｙｅｓルート）、当該提案は非ビックユーザ企業において一定の支持を得たことになる。従って、投票処理部１０１は、企業別ＩＤ管理ＤＢ１０３に格納された企業別ＩＤ管理テーブルを参照してビックユーザ企業を特定し、さらに個人別利用実績ＤＢ１０４に格納された個人別利用実績テーブルを参照してビックユーザ企業のヘビーユーザを抽出し、リストアップする（ステップＳ９５）。抽出されたヘビーユーザのリストは、記憶装置に保持される。そして、投票処理部１０１は、リストアップされたユーザのアクセス時に提案内容をポップアップ表示する（ステップＳ９７）。なお、投票履歴ＤＢ１０６を参照して、既に同一提案につき投票しているか否かを確認の上ポップアップ表示させるかを決定する。例えば図１０に示すような表示がなされる。
【００５８】
集計処理部１０２は、ユーザ端末１２０から賛否を表す情報を受信し、投票履歴ＤＢ１０６に投票履歴を登録すると共に、賛同を表す情報を受信した場合には、投票管理ＤＢ１０５に格納された投票管理テーブルの当該提案ＩＤのレコードにおいて「実績自＋他ビック」の列５０８のカウント値と「実績全体」の列５１０のカウント値とを１インクリメントして登録する（ステップＳ９９）。そして、集計処理部１０２は、「実績自＋他ビック」の列５０８のカウント値が「目標自＋他ビック」の値以上になったか判断する（ステップＳ１０１）。新規機能追加が、ビックユーザにも支持されるものかを優先的に判定するものである。
【００５９】
もし、「実績自＋他ビック」の列５０８のカウント値が「目標自＋他ビック」の値未満である場合には（ステップＳ１０１：Ｎｏルート）、所定のタイミングになったか判断する（ステップＳ１０３）。所定のタイミングとは、例えば提案データの登録時刻から所定時間たった時、又はステップＳ９５においてリストアップされたユーザのうち所定人数の回答を得た時である。もし、所定のタイミングとなっていない場合には（ステップＳ１０３：Ｎｏルート）、ステップＳ９７に戻る。すなわち、ステップＳ９５においてリストアップされたユーザによるアクセス時に、提案データのポップアップ表示を行う。一方、所定のタイミングとなった場合には（ステップＳ１０３：Ｙｅｓルート）、掲示板集計処理を実施する（ステップＳ１０５）。そして処理を終了する。
【００６０】
「実績自＋他ビック」の列５０８のカウント値が「目標自＋他ビック」の値以上であると判断された場合には、集計処理部１０２は、当該提案内容をＡＳＰ運営者に通知する（ステップＳ１０７）。図１２に示すような通知を例えば電子メールで送信する。そして集計処理部１０２は、投票管理ＤＢ１０５に格納された投票管理テーブルにおいて提案可否フラグの列５１５に提案可を表すコードと、終了フラグの列５１６に終了を表す「１」とを登録して、処理を終了する。
【００６１】
このようにすれば、新規機能の追加の提案の場合には、現在の非ビックユーザ企業の賛同が得られて利用の拡大に繋がる提案であって、且つ現在のビックユーザ企業の賛同も得られれば、特に優良顧客の維持・拡大に繋がる提案であることが確認できる。但し、早期に非ビックユーザ企業又はビックユーザ企業の支持を得られなかった場合でも、掲示板表示も行われるので、自主的に賛同を表す情報を送信するユーザがいればＡＳＰ運営者（管理者）に検討を依頼する場合もある。
【００６２】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、ＡＳＰシステム１００は１台のコンピュータではなく、複数台のコンピュータにて構成されるようにしてもよい。ＡＳＰシステム１００に示した処理部は、プログラムモジュールに直接対応しなくとも良い。また、データベース構成も図１に示したような構成に限定されるものではなく、説明したのと同様のデータを格納できれば良い。テーブル構成も同様である。
【００６３】
基準値については、提供されるサービスに応じて異なる値、又は値の組み合わせを採用してもよい。また、ＡＳＰサービスの例を示したが、他のサービスにも適用可能である。
【００６４】
（付記１）
提供サービスに対して登録された意見に対して賛同を表す情報を当該提供サービスのユーザである賛同者の端末から受信するステップと、
受信した前記賛同を表す情報に応じて、前記意見の内容、前記意見の提案者の属性及び前記意見の賛同者の属性のうち少なくともいずれかに基づき決定された判定基準を満たしたか判断する判断ステップと、
前記判断基準を満たしたと判断された場合に、前記意見を重要な意見と識別するステップと、
を含む意見評価方法。
【００６５】
（付記２）
前記判断ステップにおいて、
前記意見の内容に基づき当該意見が前記提供サービスのサービス内容改善に関するものであると判断された場合には、前記提供サービスのサービス内容改善に関する意見に対応する判断基準が用いられることを特徴とする付記１記載の意見評価方法。
【００６６】
（付記３）
前記判断ステップにおいて、
前記意見の提案者の属性に基づき特定される当該意見の提案者の優良度に対応する判断基準が用いられることを特徴とする付記１又は２記載の意見評価方法。
【００６７】
（付記４）
前記判断ステップにおいて、
前記意見の賛同者の属性に基づき特定される当該意見の賛同者の優良度に対応する判断基準が用いられることを特徴とする付記１乃至３のいずれか１つ記載の意見評価方法。
【００６８】
（付記５）
前記優良度が、少なくとも前記意見の提案者自身の属性と前記意見の提案者が属するグループについての属性に基づき特定されることを特徴とする付記３記載の意見評価方法。
【００６９】
（付記６）
前記優良度が、少なくとも前記意見の賛同者自身の属性と前記意見の賛同者が属するグループについての属性に基づき特定されることを特徴とする付記４記載の意見評価方法。
【００７０】
（付記７）
前記意見の提案者の属性に基づき特定される当該意見の提案者の優良度が所定のレベル以上の場合には、前記優良度に対応して前記ユーザのうち特定のユーザを抽出するステップと、
抽出された前記特定のユーザに対して前記意見の内容を優先提示するステップと、
をさらに含む付記１乃至６のいずれか１つ記載の意見評価方法。
【００７１】
（付記８）
前記判断基準が、前記賛同者のうち所定の条件を満たした賛同者についての第一基準と、全賛同者数についての第二基準とを含み、
前記判断ステップにおいて、前記第一基準又は前記第二基準のいずれかを満たしたか判断することを特徴とする付記１記載の意見評価方法。
【００７２】
（付記９）
付記１乃至８のいずれか１つ記載の意見評価方法をコンピュータに実行させるためのプログラム。
【００７３】
（付記１０）
提供サービスに対して登録された意見に対して賛同を表す情報を当該提供サービスのユーザである賛同者の端末から受信する手段と、
受信した前記賛同を表す情報に応じて、前記意見の内容、前記意見の提案者の属性及び前記意見の賛同者の属性のうち少なくともいずれかに基づき決定された判定基準を満たしたか判断する判断手段と、
前記判断基準を満たしたと判断された場合に、前記意見を重要な意見と識別する手段と、
を有する意見評価装置。
【００７４】
【発明の効果】
以上述べたように本発明によれば、サービスの改善又は新機能の追加についての提案等を適切に評価することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るシステム概要図である。
【図２】企業別ＩＤ管理テーブルの一例を示す図である。
【図３】個人別利用実績テーブルの一例を示す図である。
【図４】投票基準管理テーブルの一例を示す図である。
【図５】投票管理テーブルの一例を示す図である。
【図６】投票履歴テーブルの一例を示す図である。
【図７】本発明の実施の形態に係るメインの処理フロー（その１）を示す図である。
【図８】掲示板表示の一例を示す図である。
【図９】掲示板内容表示の一例を示す図である。
【図１０】提案内容のポップアップ表示の一例を示す図である。
【図１１】本発明の実施の形態に係るメインの処理フロー（その２）を示す図である。
【図１２】ＡＳＰ運営者への提案通知の一例を示す図である。
【図１３】掲示板集計処理の処理フローを示す図である。
【図１４】新規機能追加の提案に対する処理のの処理フローを示す図である。
【符号の説明】
１００　ＡＳＰシステム　　１０１　投票処理部　　１０２　集計処理部
１０３　企業別ＩＤ管理ＤＢ　　１０４　個人別利用実績ＤＢ
１０５　投票管理ＤＢ　　１０６　投票履歴ＤＢ
１０７　掲示板データ管理部　　１０８　提案データＤＢ
１１０　ネットワーク　　１２０　ユーザ端末
１２１，１３１　ブラウザプログラム
１２２，１３２　電子メールプログラム
１３０　ＡＳＰ運営者
【図１】
2004086346.tif 000003
【図２】
2004086346.tif 000004
【図３】
2004086346.tif 000005
【図４】
2004086346.tif 000006
【図５】
2004086346.tif 000007
【図６】
2004086346.tif 000008
【図７】
2004086346.tif 000009
【図８】
2004086346.tif 000010
【図９】
2004086346.tif 000011
【図１０】
2004086346.tif 000012
【図１１】
2004086346.tif 000013
【図１２】
2004086346.tif 000014
【図１３】
2004086346.tif 000015
【図１４】
2004086346.tif 000016