JP2018049504A - 投稿情報管理システム、投稿情報管理方法、およびプログラム - Google Patents
投稿情報管理システム、投稿情報管理方法、およびプログラム Download PDFInfo
- Publication number
- JP2018049504A JP2018049504A JP2016185249A JP2016185249A JP2018049504A JP 2018049504 A JP2018049504 A JP 2018049504A JP 2016185249 A JP2016185249 A JP 2016185249A JP 2016185249 A JP2016185249 A JP 2016185249A JP 2018049504 A JP2018049504 A JP 2018049504A
- Authority
- JP
- Japan
- Prior art keywords
- information
- posted
- posting
- state
- user terminal
- 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
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
【課題】信頼性が低い投稿情報を表示させないようにするための新しい手法が求められている。【解決手段】投稿情報管理システムは、投稿された投稿情報と、投稿情報に対する投票の情勢と、投稿情報の状態とを管理する。また、投稿情報の状態に基づいて投稿情報を、投票を受け付け可能な状態でユーザ端末に提供する。投稿情報に対する投票を複数のユーザ端末から受信すると、管理部で管理されている情勢を更新する。そして、更新された情勢に基づいて、投稿情報をユーザ端末に表示すべきか否かを判定する。投稿情報をユーザ端末に表示すべきでないと判定された場合、投稿情報の状態を、ユーザ端末において表示が行われる状態から、ユーザ端末において表示が行われない状態に遷移させる。【選択図】図1
Description
本発明は、口コミなどに代表されるような投稿情報を管理する技術に関する。
各種の口コミがインターネット上で投稿されている。口コミは、第三者の意見を自分自身の知識として取り入れられる便利なツールである。しかしながら、口コミの全てが正しい情報とは限らない。信頼性が低い情報もある。
信頼性が低い情報を削除すべきか否かは、表現の自由との関係で判断することが難しい。信頼性が低い情報を削除しないまま放置すると、口コミが掲載されているサイト自体の信用が失われる。一方で、信頼性が低い情報を客観的な情報無しに削除することは、表現の自由が担保されなくなり、この結果、口コミを掲載するサイトに対する不信感が増加してしまう。
特許文献1には、実際に店舗などを訪問したユーザからの投稿は、信頼性が高いものとして取り扱う技術が開示されている。特許文献1では、口コミを投稿したユーザのクライアント端末の位置データを用いて、口コミの投稿情報の信頼度を評価する。
実際に店舗を訪問したユーザであっても、事実に基づかない情報を書き込む場合というのは起こり得る。むしろ、些細な誤解などから信頼性が低い情報を書き込んでしまう場合も起こり得る。信頼性が低い情報を表示させないようにするための新しい手法が求められている。
本発明の一実施形態に係る投稿情報管理システムは、投稿された投稿情報と、前記投稿情報に対する投票の情勢と、前記投稿情報の状態とを管理する管理部と、前記状態に基づいて、前記投稿情報を、前記投稿情報に対する投票を受け付け可能な状態でユーザ端末に提供する提供部と、前記投稿情報に対する投票を複数のユーザ端末から受信し、前記管理部で管理されている前記情勢を更新する更新部と、前記更新部において更新された前記情勢に基づいて、前記投稿情報を前記ユーザ端末に表示すべきか否かを判定する判定部と、前記判定部によって前記投稿情報を前記ユーザ端末に表示すべきでないと判定された場合、前記投稿情報の状態を、前記ユーザ端末において表示が行われる状態から、前記ユーザ端末において表示が行われない状態に遷移させる状態遷移部とを有するものとすることができる。
本発明によれば、投稿情報に対する投票結果に基づいて、投稿情報をユーザ端末で表示させない処理を行う。ユーザからの投票という客観的な情報に基づいて投稿情報を表示させない処理を行うことにより、口コミを掲載するサイトの健全性を高めるとともに、ユーザの表現の自由も担保することができる。
以下、図面を参照しながら本発明の実施形態について詳細に説明する。なお、以下の実施形態において説明する構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
<実施形態1>
<全体の構成>
図1は、本実施形態に係る投稿情報管理システム100を含む全体の構成の一例を示す図である。投稿情報管理システム100は、投稿受付部111、提供部112、更新部113、通知部114、管理部151、判定部152、および状態遷移部153を含む。投稿情報管理システム100は、ユーザ端末10と通信する。なお、図1は構成の一例を示したものに過ぎず、他の構成を含んでもよい。また、図1に記載された構成の全てが必須の要件であるとは限らない。
<全体の構成>
図1は、本実施形態に係る投稿情報管理システム100を含む全体の構成の一例を示す図である。投稿情報管理システム100は、投稿受付部111、提供部112、更新部113、通知部114、管理部151、判定部152、および状態遷移部153を含む。投稿情報管理システム100は、ユーザ端末10と通信する。なお、図1は構成の一例を示したものに過ぎず、他の構成を含んでもよい。また、図1に記載された構成の全てが必須の要件であるとは限らない。
投稿情報管理システム100は、単一の情報処理装置を用いて実現されてもよいし、複数の情報処理装置を用いて実現されてもよい。例えば、投稿情報管理システム100のうち、ユーザ端末10との間で情報のやり取りを行う投稿受付部111、提供部112、更新部113、および通知部114を、ウェブサーバ110として構成してもよい。データの管理などを行う管理部151、判定部152、および状態遷移部153を、データベース(DB)サーバ150として構成してもよい。この例に限られず、各部の処理を複数のサーバが分散して処理を行う形態でもよい。本実施形態においては、図1に示すように、ウェブサーバ110及びDBサーバ150によって投稿情報管理システム100が構成されている例を用いて説明する。
ウェブサーバ110及びDBサーバ150は、情報処理装置として実現することができる。図1に示す各部は、例えばハードウェアまたはソフトウェアによって実装することができる。ソフトウェアによって実装される場合、ハードウェアを制御するプログラムコードがCPU、MPUなどのコンピュータの各種のプロセッサによって実行されてもよい。例えば、情報処理装置は、CPU、メモリ、HDD、及びネットワークインタフェースを有してよい。図1に示す各サーバに含まれる各部は、各サーバのHDDに格納されたプログラムが一時的にメモリに読み出され、各サーバのCPUがメモリに読み出されたプログラムを実行することで、各サーバのCPUが図1に示す各部として機能することができる。また、プログラムコードの機能を実現するための回路等のハードウェアを設けてもよい。プログラムコードの一部をハードウェアで実現し、残りの部分を各種プロセッサが実行してもよい。
投稿情報管理システム100は、ユーザが使用するユーザ端末10との間で通信が可能に構成されており、ユーザ端末10に投稿情報を提供したり、ユーザ端末10から投稿情報の投稿を受け付けたり、投稿情報に対する投票をユーザ端末10から受信したりする。本実施形態においては、複数のユーザのユーザ端末を総称してユーザ端末10と呼ぶこととする。
ユーザ端末10は、パーソナルコンピュータ、タブレット、モバイル端末など任意の種類の端末であってよい。投稿情報管理システム100は、ユーザをログイン管理しており、ログインしたユーザを一意に特定することが可能である。
<ウェブサーバの構成>
ウェブサーバ110の有する各構成について説明する。
ウェブサーバ110の有する各構成について説明する。
投稿受付部111は、ユーザ端末10から投稿された投稿情報を受け付ける。投稿情報とは、投稿対象に対する投稿内容を含む情報である。投稿対象とは、様々なものが挙げられる。例えば、商品、飲食施設、宿泊施設、レジャー施設、生活サービス、医療機関、相談機関などが挙げられる。もちろん、これらに限定されるものではなく、あらゆる対象が投稿対象となり得る。投稿内容は、例えば感想、評価などのいわゆる口コミのテキスト文章である。このように、投稿情報には、投稿対象に対する口コミが記述されたテキスト文章が含まれる。また、投稿情報には、口コミが記述されたテキスト文章のほか、投稿対象に関連する画像データ、動画データ、または音声データが含まれていてもよい。また、投稿情報には、投稿対象に対する評価点が含まれていてもよい。投稿情報を受け付ける形態の例としては次のようなものが挙げられる。ウェブサーバ110は、各投稿対象に関する説明が記載されているウェブページをユーザ端末10に提供する。ユーザ端末10は、このウェブページに含まれる投稿欄に対して投稿情報を投稿する。投稿受付部111は、このようにして投稿された投稿情報を受け付けることができる。
投稿情報は、口コミのような形態でもよいし、別の形態でもよい。別の形態としては、特定の投稿対象の使用方法や活用方法などを、繰り返し投稿するような日記形式のものでもよい。その他、何かしらの投稿が行われる形態であれば、いずれの形態でもよい。投稿受付部111は、このように投稿された投稿情報を受け付ける。
提供部112は、管理部151で管理されている投稿情報を、その投稿情報に対する投票をユーザから受け付け可能な状態でユーザ端末10に提供する。例えば、提供部112は、ユーザ端末10からの投稿情報の表示要求に応じてその要求元のユーザ端末10に投稿情報を提供(送信)する。提供部112は、投稿情報を、その投稿情報に対する投票用のユーザインタフェースがユーザ端末10で表示可能な状態で、ユーザ端末10に送信することができる。
図2(a)は、提供部112が、投稿情報を、その投稿情報に対する投票をユーザから受け付け可能な状態でユーザ端末10に提供し、提供された投稿情報を含む画面200がユーザ端末10のディスプレイにおいて表示されている例を示している。画面200には、投稿情報として、ユーザ名201、タイトル202、評価点203、口コミ本文204を含む情報が表示されている。また、投稿情報に対する投票を受け付けるための投票を促すメッセージ210、「正」を投票する第一の投票ボタン211、および「誤」を投票する第二の投票ボタン212を含むユーザインタフェースが表示されている。また、画面200には、この投稿情報に対する投票の情勢を示す投票数が共に表示されている。この例では、投票数が、第一の投票ボタン211および第二の投票ボタン212に含まれる例を示している。画面200では、この投稿情報に対する「正」の投票数が10あり、「誤」の投票数が20あることが示されている。なお、画面200は一例に過ぎずこれに限られるものではない。例えば、ユーザ名のほかに、年代、性別、所在地、職業や、ユーザの画像が表示されていてもよい。
なお、提供部112は、既にユーザXが投票済みの投稿情報X1に関しては、ユーザXに対しては、その投稿情報X1に対する投票をユーザXから受け付け不可能な状態で提供する。図2(b)は、既に投票済みのユーザに対して投稿情報を提供する画面250の例を示している。画面250は、ユーザXが、「誤」に既に投票済みの例を示している。画面250においては、投票済みのボタンである「誤」を投票する第二の投票ボタン252が、ボタン押下済みの状態が継続された状態となっており、投票が行えない状態となっている。つまり、図2(b)の画面250は、その投稿情報に対する投票をユーザから受け付け不可能な状態でユーザ端末10に提供される画面である。この画面250において「正」を投票する第一の投票ボタン251を押下しても、既にユーザXは「誤」に投票済みであるので、投票が受け付けられない。投票をユーザから受け付け不可能な状態で表示される他の例としては、例えば第一の投票ボタン251及び第二の投票ボタン252がグレー表示となっていてもよい。あるいは、「正」を投票する第一の投票ボタン251、および「誤」を投票する第二の投票ボタン252自体が非表示状態となっていてもよい。
このように、本実施形態においては、一つの投稿情報に対してユーザが1回だけ投票を行うことが可能である。なお、本実施形態では、一つの投稿情報に対してユーザが1回だけ投票を行う形態を例に挙げて説明するが、これに限られるものではない。誤って投票した場合のやり直しを可能にするように、投票済みの内容を変更(例えば、「正」から「誤」に変更)できてもよい。
図1に戻りウェブサーバ110の構成についての説明を続ける。
更新部113は、投稿情報に対する投票をユーザ端末10から受信し、管理部151で管理されている投稿情報に関する情勢を更新する。投稿情報に関する情勢とは、例えば口コミに対するユーザの投票結果(途中経過の状態も含む)の情報のことである。本実施形態では、口コミに対する投票として、ユーザから「正」か「誤」の2つの投票ボタンを用いた投票が行われるものとする。つまり、第一のカテゴリ「正」に投票するか、第二のカテゴリ「誤」に投票するかをユーザが選択できるように、2つの投票ボタンを用いた投票が行われるものとする。投稿情報に関する情勢とは、この正誤の投票数であってよい。あるいは、正誤の投票のそれぞれに所定の重みを乗じて加算した重み付け加算の結果の値でもよい。更新部113が、管理部151に管理されている投稿情報に関する情勢を更新することで、後述する判定部152は、この更新された投稿情報の情勢に基づいて、投稿情報を表示すべきか否かの判定を行うことができる。詳細は後述する。なお、ここでは第一のカテゴリおよび第二のカテゴリとして正誤を用いる例を説明したが、投稿情報に対する肯定的なカテゴリと否定的なカテゴリの名称を用いてよい。例えば、「正」の代わりに「納得」「なるほど」「参考になった」といったカテゴリの名称を用いてもよい。また、肯定的なカテゴリ、否定的なカテゴリに限られるものではなく、任意のカテゴリを使用することができる。
通知部114は、投稿情報の状態が、ユーザ端末10において表示が行われない状態に遷移する可能性があることを、その投稿情報を投稿したユーザに通知する。投稿情報の削除を、その投稿情報を投稿したユーザに予告することで、その投稿情報を投稿したユーザに、自身の投稿内容を再検証させる契機を与えることができる。再検証した結果、自身の投稿内容に誤りがあることをユーザ自身が発見した場合には、そのユーザは、再度の投稿を行う場合があり得る。詳細については後述する。
<DBサーバの構成>
次に、DBサーバ150の構成について説明する。
次に、DBサーバ150の構成について説明する。
管理部151は、投稿された投稿情報と、投稿情報に対する投票の情勢と、投稿情報の状態とを管理する。投票の情勢とは、先に説明したように、投稿情報に対する正誤の投票数でもよいし、正誤の投票のそれぞれに所定の重み付けを行って加算した重み付け加算の結果の値でもよい。
図3は、管理部151が管理する各種の管理DBの一例を示す図である。図3に示す管理DBは一例に過ぎず、この例に限定されるものではない。
ユーザ管理DB300は、本システムで登録されている各ユーザの情報を管理するDBである。ユーザ管理DB300は、ユーザIDが「U1001」で特定されるユーザは、ニックネームが「ユーザA」であり、ポイントが500ポイント得られていることを示している。ポイントは、投稿情報を投稿したことに応じて付与されてもよいし、投稿情報に対する投票結果に応じて付与されてもよいし、いずれの場合に付与されてもよい。ユーザ管理DB300には、その他、ユーザの性別、生年月日、職業、住所などのユーザに関する情報が管理されてもよい。
投稿情報管理DB310は、投稿受付部111において投稿情報の受付を行うたびに、レコードが増える。投稿情報管理DB310においては、投稿対象IDが「G21」で特定される投稿対象(例えばレストランR)に対して、ユーザID「U1001」のユーザによって投稿情報ID「P101」の投稿が行われた場合の例を示している。投稿情報ID「P101」の投稿の投稿種別は「公開中」であることを示している。投稿種別には、例えば「公開中」「下書き」「過去投稿」「削除」などが含まれる。投稿種別は、現在の投稿の状態の種別を示している。図3の投稿情報管理DB310では、投稿情報ID「P101」の投稿内容として「とても悪かった」との投稿がなされており、投稿対象IDが「G21」で特定されるレストランに対する評価点として1.0点が投稿ユーザ(図3の例ではユーザIDがU1001のユーザ)によって付されたことを示している。また、投稿情報管理DB310には、投稿情報ID「P101」の投稿に対する投票数が関連付けて管理されている。この例では、「正」の投票数が3であり「誤」の投票数が50であることを示している。図3の例においては、投稿表示終了日時に所定の日時の設定がなされている。本実施形態においては、投稿種別が「公開中」であり、投稿表示終了日時に所定の日時の設定がなされている場合、投稿情報の状態は、削除準備状態になっていることを示す。投稿情報の状態に関しては、後述する。
投票管理DB320は、投稿情報に対する投票が行われるごとに逐次レコードを増やしていく。投稿情報管理DB310の「正」の数や「誤」の数は、投票管理DB320の集計値である。
投稿対象管理DB330は、投稿対象に対する総合評価点を格納する。管理部151は、同じ投稿対象に対する複数のユーザからの評価点に従って算出された総合評価点(第一の評価点)を、投稿対象に関連付けて管理する。図3の例においては、投稿対象IDが「G21」で特定される投稿対象に対して、総合評価点が3.3であることを示している。総合評価点は、投稿対象に対する各ユーザの投稿情報に含まれる評価点を元に算出される値である。算出方法としては、ユーザの信頼性に応じて重み付けを行った評価点の平均を算出するなどの方法を採用してもよい。
判定部152は、更新部113において更新された、管理部151で管理されている投票の情勢に基づいて、投稿情報をユーザ端末10に表示すべきか否かを判定する。例えば、第二のカテゴリ(誤)の値に対する第一のカテゴリ(正)の値が所定の閾値以内であれば、その投稿情報をユーザ端末10に表示すべきでないと判定する。すなわち、正/誤の値が所定の閾値以内であればその投稿情報をユーザ端末10に表示すべきでないと判定する。判定による手法には、このような正誤比を用いるほかに、各種の手法を用いることができる。詳細は後述する。
状態遷移部153は、投稿情報をユーザ端末10に表示すべきでないと判定部152によって判定された場合、その投稿情報の状態を、ユーザ端末10において表示が行われる状態から、ユーザ端末10において表示が行われない状態に遷移させる。
図4は、本実施形態に係る投稿情報の状態の遷移を示す図である。投稿情報の状態は、先に説明した、図3の投稿情報管理DB310の「正」の数や「誤」の数、あるいは、これらの数に所定の重み付けを行った値などの集計結果に基づいて決定される。
投稿受付部111において投稿を受け付けた時点において、すなわち、新規の投稿がユーザによって行われた時点においては、その投稿情報の状態は、通常状態410である。この通常状態410は、第一のカテゴリ(正)の投票数から、第二のカテゴリ(誤)の投票数を差し引いた第一の数が、第二の数以上でありかつ第三の数以下の投稿を示す第一態様とすることができる。図4の例では、説明を簡略化するために単純な値を用いて説明する。例えば新規の投稿がユーザによって行われた時点においては、何も投票が行われていないので第一の数は0である。ここで、第二の数を−20、第三の数を20とすると、第一の数が、−20以上かつ20以下であるか否かに応じて投稿情報の状態が遷移する。状態遷移部153は、第一の値が例えば30であった場合、すなわち、正の投票数が誤の投票数よりも多い場合、その投稿情報の状態を、高評価状態450(第一の数が第三の数より大きい投稿を示す第二態様)に遷移させる。逆に、第一の数が例えば−30であった場合、すなわち、誤の投票数が正の投票数よりも多い場合、状態遷移部153は、その投稿情報の状態を、低評価状態420(第一の数が第二の数よりも小さい投稿を示す第三態様)に遷移させる。
状態遷移部153は、高評価状態450と通常状態410との間の状態遷移、および通常状態410と低評価状態420との間の状態遷移に関しては、いずれの方向においても状態遷移をさせることが可能である。
低評価状態420から、さらに第二のカテゴリの投票数が多くなると、状態遷移部153は、その投稿情報の状態を、低評価状態420から削除準備状態430に遷移させる。削除準備状態430は、投稿情報が、ユーザ端末10においてその投稿情報の表示が行われる状態から、ユーザ端末10においてその投稿情報の表示が行われない状態に遷移した状態である。換言すれば、削除準備状態430は、削除が行われることが確定した状態である。状態遷移部153は、削除準備状態430から低評価状態420に状態を遷移させることはできない。
提供部112は、管理部151の投稿情報管理DB310の集計結果に基づいて決定される投稿情報の状態に基づいて投稿情報の提供を行う。提供部112は、投稿情報の状態が、削除準備状態430に遷移された場合、その投稿情報の本文を非表示にした状態で投稿情報をユーザ端末10に提供する。
図5は、削除準備状態430の投稿情報がユーザ端末10において表示される画面500の例を示す図である。画面500には、投稿情報として、ユーザ名501、タイトル502、及び評価点503が表示されている。画面500では、投稿情報の本文の代わりに、削除がされる予定であることを示すメッセージ510が表示されている。また、ユーザ名501は、ニックネームではなく、XXXXとマスク表示に変更されている。削除される予定であることを投稿ユーザや他のユーザに知らせることができればよいので、削除準備状態430の投稿情報を表示する画面500では、ユーザ名は匿名扱いに変更されている。ユーザ名とともにユーザの画像が表示される形態では、この画像を非表示にしてもよい。なお、ユーザ名のほか、年代、性別、所在地を表示する形態の場合には、これらは個人を特定する情報ではないので、そのまま表示してもよい。また、「正」の投票ボタン及び「誤」の投票ボタンは、非表示状態となっている。すなわち、「正」の投票ボタン及び「誤」の投票ボタンは、投票が不可な状態である。つまり、仮にまだその投稿情報に対する投票を行っていないユーザであっても、削除準備状態430の投稿情報に対しては投稿が行われない。なお、画面500には、これまでの投票数520が表示されている。
このように、本実施形態においては、投票の情勢が、その投稿情報の信頼性が低いことを示す場合に直ちに投稿情報を削除するのではなく、一旦、本文を非表示の状態で所定の期間(例えば1日)表示を続ける。投稿情報が何の前触れなしに削除されてしまうと、ユーザの不信感を引き起こす可能性がある。本実施形態では、ある程度の削除準備期間を設けた削除の予告を行うことで、投稿情報を提供するサイトの信頼性を向上させることができる。
削除準備状態430に投稿情報の状態が遷移すると、所定の時間が経過した後に、状態遷移部153は、削除準備状態430から削除状態440に遷移させる。管理部151は、投稿情報管理DB310の集計結果に基づいて決定される投稿情報の状態が削除状態に遷移された場合、当該投稿情報の投稿種別を「削除」に変更する。投稿情報の投稿種別が「削除」に変更された場合、当該投稿情報を投稿情報管理DB310から削除してもよいし、投稿情報がシステム上で削除扱いになるように処理してもよい。つまり、管理部151は、投稿情報を物理的に削除しなくてもよい。
管理部151が投稿情報の投稿種別を「削除」に変更した場合、その投稿対象の評価点が変わる可能性がある。そこで、管理部151は、投稿種別が「削除」に変更された投稿情報を除いて再度投稿対象に対する総合評価点を算出し、算出した総合評価点で、投稿対象管理DB330に格納される総合評価点を更新する。なお、管理部151は、投稿情報の投稿種別を「削除」に変更した場合に総合評価点を再度算出してもよいし、投稿情報の状態が削除準備状態に遷移された時点で、総合評価点の再算出を行ってもよい。
<フローチャート>
図6は、本実施形態に係る投稿情報管理システムの制御方法の一例を示すフローチャートである。図6の処理は、ある投稿情報に着目し、投稿情報が投稿情報管理システムに受け付けられてから削除されるまでの一連の投稿情報管理方法の処理を示すフローチャートである。
図6は、本実施形態に係る投稿情報管理システムの制御方法の一例を示すフローチャートである。図6の処理は、ある投稿情報に着目し、投稿情報が投稿情報管理システムに受け付けられてから削除されるまでの一連の投稿情報管理方法の処理を示すフローチャートである。
ステップS610において投稿受付部111は、ユーザ端末10から投稿情報を受け付ける。受け付けられた投稿情報は、管理部151において管理される。
ステップS620において提供部112は、ユーザ端末10からの要求に応じて、ステップS610において受け付けた投稿情報を、ユーザ端末10に提供する。
ステップS630において更新部113は、ステップS620で提供された投稿情報に対する投票を受信する。そして、ステップS640において更新部113は、受信した投票内容に応じて管理部151で管理されている投票の情勢を更新する。例えば、投票されたカテゴリの投票数を増加させる。
ステップS650において判定部152は、ステップS640で更新された情勢に基づいて、ステップS610で受け付けた投稿情報をユーザ端末10に表示すべきか否かを判定する。ステップS650の判定処理の詳細を説明する。
判定処理としては、二つのカテゴリである「正」「誤」の投票数の差(あるいは正誤の比率)を用いてもよい。ある程度の投票数が集まるまでは、判定処理に用いない処理を行ってもよい。
本実施形態においては、第一の値(判定値)を、例えば式(1)のように求めることができる。ここで、positiveは、「正」の投票数であり、negativeは、「誤」の投票数である。
第一の値=(positive * α) / (negative * β) 式(1)
ここで、αとβはパラメータである。任意のパラメータを用いて、第一の値を算出することができる。この第一の値が所定の閾値を下回る場合に、投稿情報を表示すべきでないと判定する(ステップS650でNOと判定する)ことができる。また、二項分布に基づく母比率の信頼区間を用いてもよい。例えば、信頼区間95%での上限値を第一の値とし、この第一の値が所定の閾値を下回る場合に、投稿情報を表示すべきでないと判定してもよい。また、ユーザの情報に応じて重みを付けた値を用いてもよい。例えば、都道府県別では、ユーザの登録数が異なる。したがって、例えば1票の重みを、ユーザの多いエリア(A県)では相対的に低くし、ユーザの少ないエリア(例えばZ県)では相対的に高くすることで、調整を行うことができる。また、より細分化して例えば「市」や「町」などの単位によって重み付けを変えてもよい。また、所在地に応じた重み付けのほか、性別や年齢に応じて重み付けを変えてもよいし、これらの組み合わせに応じて適宜重み付けを変えてもよい。
ここで、αとβはパラメータである。任意のパラメータを用いて、第一の値を算出することができる。この第一の値が所定の閾値を下回る場合に、投稿情報を表示すべきでないと判定する(ステップS650でNOと判定する)ことができる。また、二項分布に基づく母比率の信頼区間を用いてもよい。例えば、信頼区間95%での上限値を第一の値とし、この第一の値が所定の閾値を下回る場合に、投稿情報を表示すべきでないと判定してもよい。また、ユーザの情報に応じて重みを付けた値を用いてもよい。例えば、都道府県別では、ユーザの登録数が異なる。したがって、例えば1票の重みを、ユーザの多いエリア(A県)では相対的に低くし、ユーザの少ないエリア(例えばZ県)では相対的に高くすることで、調整を行うことができる。また、より細分化して例えば「市」や「町」などの単位によって重み付けを変えてもよい。また、所在地に応じた重み付けのほか、性別や年齢に応じて重み付けを変えてもよいし、これらの組み合わせに応じて適宜重み付けを変えてもよい。
また、投票数というものは、投稿情報が投稿されてからの経過時間に比例して少なくなる傾向がある。したがって、投稿情報の投稿された日時からの経過時間に応じて、所定の閾値を変更してもよい。例えば、投稿情報の投稿された日時から経過時間が長い場合には、経過時間が短い場合と比べて、所定の閾値が高くなるように変更する。つまり、正誤比を緩めることで、所定の閾値を下回る第一の値が増えることになり、判定結果が得られやすくなる。また、時間が経過するに連れて、例えば店舗などの運営が開店当初は芳しくなかった状態から、ノウハウが蓄積されて大幅に改善されるといったように、投稿情報が投稿された時点とは、投稿対象の状態が異なっている場合も想定される。このように、過去の蓄積された投票数が必ずしも適切ではない場合もあるので、投稿情報の投稿された日時からの経過時間に応じて、所定の閾値を変えることで柔軟な判定結果を得ることができる。
ステップS650で投稿情報を表示すべきであると判定した場合、ステップS660に処理が進む。そうでない場合、ステップS680に処理が進む。
ステップS660において判定部は、ステップS610で受け付けた投稿情報が削除される可能性があるかを判定する。例えば、ステップS640で用いた所定の閾値の代わりに、その所定の閾値よりも高い第二の閾値を用いてステップS640と同様の判定処理を行えばよい。ステップS660において削除される可能性があると判定された場合、ステップS670に進む。ステップS670において通知部114は、ユーザ端末10において表示が行われない状態に遷移する可能性があることを、ステップS610で受け付けた投稿情報を投稿したユーザに通知する。通知の方法は、予め登録されているメールアドレスにメールを送信する方法でもよいし、投稿情報管理システム100にユーザがログインした際にメッセージをユーザ端末10に表示する方法でもよい。削除される可能性があることを通知されたユーザは、自身の投稿情報を確認する可能性がある。自身の投稿内容を確認して誤りなどに気が付いた場合には、そのユーザは、投稿内容を修正した再投稿を行う場合がある。このように、ユーザに通知をすることで再投稿が行われる契機となる可能性がある。ステップS670の処理の後、及びステップS660において削除される可能性がないと判定された場合、ステップS620に戻り、処理を繰り返す。
ステップS680において状態遷移部153は、ステップS610で受け付けた投稿情報の状態を、削除準備状態に遷移させる。ステップS680の状態においても、ステップS620と同等の処理は行われる。すなわち、削除準備状態においても、提供部112は、ユーザ端末10からの要求に応じて、ステップS610において受け付けた投稿情報を、ユーザ端末10に提供する。ステップS690において管理部151は、所定期間が経過後に投稿情報を削除する。
次に、ステップS670において通知部114からの通知を受けたユーザが、再投稿を行った場合の例を説明する。ここで、再投稿とは、同一の投稿対象に対して同一ユーザが再度の投稿を行うことを意味するものである。
図7は、投稿対象について口コミ投票を行ったユーザYが再投稿を行った場合にユーザ端末10に表示される画面の例を示す図である。なお、再投稿は通知部114からの通知を必要とするものではなく、任意のタイミングでユーザYが行うことが可能である。本実施形態においては、同一の投稿対象については、2回まで再投稿を行うことを可能とする。図7の投稿710および投稿720は、過去にユーザYが行った投稿(第一の投稿情報)である。過去の投稿分についても、投稿情報および正誤の投票数は引き続き表示がされる。再投稿730は、ユーザYが新規で再投稿をした内容(第二の投稿情報)である。過去の投稿分の正誤の投票数は、再投稿には引き継がれない。したがって、判定部152が判定する場合には、再投稿730については、正誤の値が投稿710及び投稿720からリセットされた状態で判定が行われることになる。かかる処理によれば、不正な意図で再投稿がされることを防止できるからである。例えば、仮にユーザYが不正な意図を持っていると仮定する。そして、過去の投稿720では「正」の投票数を多数得ている状態であるとする。このとき、ユーザYが、これまでの投稿内容とは全く異なる内容(「誤」の投票数が圧倒的に多くなるような内容)で再投稿をした場合、従前の投票数を引き継いでしまうと、このような真逆の内容が「正」である事態が生じてしまうからである。
なお、再投稿730がある場合には、従前の投稿720に投稿をしたことがないユーザであっても、従前の投稿720に対する投票はできなくなる。つまり、最新の投稿に対する投票のみを許容する形態とすることができる。
図8は、図7の再投稿730を閲覧したユーザが、「誤」に投票をした場合の画面例を示す図である。図7で表示されていた投票を促すメッセージ731は、図8では表示されない。また、「誤」の投票数が一つ増えており、「誤」の投票ボタン832がボタン押下継続の状態となっている。
図9は、図8の状態から削除準備状態に遷移した場合に表示される画面例を示している。投票の結果、口コミが非表示となっていること、及び、評価点と口コミ内容とが削除される予定であるメッセージが表示されている。投票受付ボタンは表示されない。過去の投票数は表示されている。ユーザ名にはマスク処理が施される。ユーザ画像は、表示されない。
図10は、日記の形式における追記の例を示す図である。日記の場合には、投稿対象に対し使用方法や活用方法などを投稿するように、継続的な投稿を受け付ける形態である。日記の形式においてもこれまで説明したものと同様に、投票機能を設けることが可能である。なお、日記の形式においては、再投稿ということは行うことができず、既存の内容に追記をすることが可能である。日記の場合も口コミの場合と同様に、既に投票が行われた日記記事に関しては、投票を促すメッセージは表示されない。また、投票が不可能な状態となる。削除準備状態に遷移した場合も図9で示した口コミの場合と同様に、日記が非表示となっていること、及び、評価点と日記内容とが削除される予定であるメッセージが表示される。投票受付ボタンは表示されない。過去の投票数は表示される。ユーザ名にはマスク処理が施される。ユーザ画像は、表示されない。なお、このように、日記と口コミとで表示態様を共通化してもよいし、部分的に変更してもよい。
図11は提供部112が提供する、投票に用いられる各種のユーザインタフェースの例を示す図である。これまでの例においては、第一のカテゴリ(正)と第二のカテゴリ(誤)との二つのカテゴリに対する投票が行われる例を説明した。図11(a)では、第一のカテゴリと第二のカテゴリとの間の中間的なカテゴリとして、第三のカテゴリと第四のカテゴリとが含まれる例を示す図である。第三のカテゴリは、第四のカテゴリよりも第一のカテゴリ寄りのカテゴリである。このように、中間的なカテゴリが選択された場合には、値を適宜変更して集計が行われればよい。例えば、ボタン1101が選択された場合に「正」を1.0加算する場合、ボタン1102が選択された場合に「正」を0.75加算し「誤」を0.25加算する。つまり、1票を「正」と「誤」に分配する。同様に、ボタン1103が選択された場合に「正」を0.25加算し、「誤」を0.75加算する。ボタン1104が選択された場合に「誤」を1.0加算する。必要に応じて先に説明した重み付けを行ってもよい。
図11(b)は、図11(a)よりもさらに段階的に値を調整することが可能なボリュームボタン1151、1152を用いる場合の例を示している。ボリュームボタン1152のスライドバーが最も「正」に移動された位置で投票ボタン1154が押下されると、「正」に1.0票が加算される。ボリュームボタン1152のスライドバーが最も「誤」に移動された位置で投票ボタン1154が押下されると、「誤」に1.0票が加算される。ボリュームボタン1152の位置に応じて、例えば、「正」に0.9票(かつ「誤」に0.1票)、「正」に0.8票(かつ「誤」に0.2票)などのように、加算される票数が変わる。ここでは変化する幅は0.1段階ずつである場合を例に挙げたが、これに限られるものではない。なお、ボリュームボタン1152が中央にある場合での投票は、「正」に0.5票かつ「誤」に0.5票として投票を受け付けてもよいし、あるいはボリュームボタン1152が中央にある場合には、投票を受け付けなくしてもよい。このように、選択された位置に応じて適宜値を変更し、投票ボタン1153、1154を押下することで調整された値の投票を受信することができる。
図11(c)は、投稿されたテキスト文章の中で、ドラッグされた(選択された)文字数に応じて値を変更する例を示している。ユーザは、投稿内容の文章のうち、同意する箇所をドラッグしてボタン1162を押下する。すると、ドラッグされた文字数に応じた値が加算される。なお、投稿内容の文章を全てドラッグしてボタン1162を押下すると、1.0票が加算される。投稿内容の一部をドラックしてボタン1162を押下すると、例えば0.3票が加算される。なお、ユーザは、投稿内容の文章のうち、同意しない箇所をドラッグしてボタン1163が押下されるとドラッグした文字数に応じて「誤」の値が調整される。このように、全体の文字数に占める割合に応じて、調整される「正」の値や「誤」の値が変更されるように構成してもよい。図11で示した形態は一例に過ぎず、これに限られるものではない。
以上説明したように、本実施形態によれば、投稿情報に対する投票結果に基づいて、投稿情報をユーザ端末で表示させない処理を行う。ユーザからの投票という客観的な情報に基づいて投稿情報を表示させない処理を行うことにより、口コミを掲載するサイトの健全性を高めるとともに、ユーザの表現の自由も担保することができる。
<変形例1>
これまでの説明では、カテゴリとして主に「正」と「誤」のように相対するカテゴリを用意し、いずれかの方向性をユーザが投票する例を説明した。しかしながら、この例に限られるものではない。例えば、ユーザが、「正」にも「誤」にも判断がつかない場合がある。このようなユーザの意思を反映させるために、例えば「どちらでもない」というカテゴリを設け、「どちらでもない」といった投票ボタンを表示させる形態を採用してもよい。「どちらでもない」というカテゴリに投票された票数の扱いは、投稿情報を削除する際には、無効票として母数に含めなくてもよいし、母数に含めてもよい。また、所定の重みをつけて母数に含めてもよい。「どちらでもない」というカテゴリを設けた場合には、例えば図11(b)で示したボリュームボタン1151、1152が中間を指す場合に、「どちらでもない」に1票が加算されるように構成してもよい。
これまでの説明では、カテゴリとして主に「正」と「誤」のように相対するカテゴリを用意し、いずれかの方向性をユーザが投票する例を説明した。しかしながら、この例に限られるものではない。例えば、ユーザが、「正」にも「誤」にも判断がつかない場合がある。このようなユーザの意思を反映させるために、例えば「どちらでもない」というカテゴリを設け、「どちらでもない」といった投票ボタンを表示させる形態を採用してもよい。「どちらでもない」というカテゴリに投票された票数の扱いは、投稿情報を削除する際には、無効票として母数に含めなくてもよいし、母数に含めてもよい。また、所定の重みをつけて母数に含めてもよい。「どちらでもない」というカテゴリを設けた場合には、例えば図11(b)で示したボリュームボタン1151、1152が中間を指す場合に、「どちらでもない」に1票が加算されるように構成してもよい。
<変形例2>
図3のユーザ管理DB300で説明したように、本実施形態ではユーザに対してポイントを管理することができる。このポイントは、例えば投稿を行ったユーザに対して付与されてよい。本実施形態においては、投稿情報に対する投票の情勢に応じて、ユーザにポイントを付与することができる。例えば、投稿情報の状態が高評価状態450に遷移された場合には、その投稿情報を投稿したユーザにポイントが付与される。あるいは、「正」の投票数が第一の閾値を超えている投稿情報に対して、「正」の投票数に応じたポイントを付与してもよい。また、「正」の投票数から「誤」の投票数を差し引きした数に応じたポイントを付与してもよい。投票の情勢に応じて、投稿情報を投稿したユーザにポイントが付与されるので、信頼性の高い投稿情報がユーザから投稿されることが期待できる。
図3のユーザ管理DB300で説明したように、本実施形態ではユーザに対してポイントを管理することができる。このポイントは、例えば投稿を行ったユーザに対して付与されてよい。本実施形態においては、投稿情報に対する投票の情勢に応じて、ユーザにポイントを付与することができる。例えば、投稿情報の状態が高評価状態450に遷移された場合には、その投稿情報を投稿したユーザにポイントが付与される。あるいは、「正」の投票数が第一の閾値を超えている投稿情報に対して、「正」の投票数に応じたポイントを付与してもよい。また、「正」の投票数から「誤」の投票数を差し引きした数に応じたポイントを付与してもよい。投票の情勢に応じて、投稿情報を投稿したユーザにポイントが付与されるので、信頼性の高い投稿情報がユーザから投稿されることが期待できる。
<実施形態2>
実施形態2では、投稿情報に対する投票の情勢に応じて、投稿情報に関する表示の態様を変更する形態を説明する。
実施形態2では、投稿情報に対する投票の情勢に応じて、投稿情報に関する表示の態様を変更する形態を説明する。
図12は、本実施形態における投票情報管理システムを含む構成の一例を示すブロック図である。図12は、図1に示す構成に対して変更部1201が追加されている。その他の構成については図1に示す例と同様とすることができるので、その他の構成については説明を省略する。なお、実施形態1でも説明したように、図12に示す構成の全てが必須の構成であるとは限らない。
変更部1201は、更新部113において更新された、管理部151で管理されている投票の情勢に基づいて、投稿情報がユーザ端末で表示される表示態様を変更する。例えば図4で説明したような投稿情報の各種の状態に基づいて表示態様を変更することができる。
図13および図14は、高評価状態、通常状態、低評価状態、および削除準備状態のそれぞれで表示態様を異ならせる例を示している。すなわち、通常状態を第一態様、高評価状態を第二態様、低評価状態を第三態様、削除準備状態を第四態様として、表示態様を異ならせる例を示している。なお、ここでは4つの異なる表示態様を例に挙げて説明しているが、投稿情報の状態をより細分化して管理する場合には、その細分化のレベルに応じた表示態様を採用することが可能である。また、例えば高評価状態と低評価状態と削除準備状態の3つの表示態様であってもよい。表示態様の細分化のレベルは、適宜自由に設計することができる。図13(a)は、投票に用いられるインタフェース(投票ボタン)を変更する例を示している。ここではハッチングの種類を変える例を示しているが、投票ボタンの色を変えてもよいし、大きさを変更してもよい。図13(b)は、投稿情報の枠を変更する例を示している。ここでは、線の種類や太さを変える例を示しているが、線の色を変えてもよい。図14(a)は、投稿情報の背景を変更する形態を示している。色を変更してもよいし、グラデーションなどで表示態様を変更してもよいし、点灯制御を行ってもよい。図14(b)に示すように、文章の一部が選択されるような形態においては、「正」と多く選択された箇所や「誤」と多く選択された箇所の文字の大きさ、色、フォントなどを変更してもよい。図13および図14に示す形態は一例に過ぎず、これに限られるものではない。
本実施形態によれば、投稿情報に対する投票の情勢(例えば投票数、投票比率など)に応じて、投稿情報または投票に用いられるユーザインタフェースの表示態様を変更することができる。これにより、投稿情報を閲覧するユーザは、信頼性が高い投稿であるのか、信頼性が低い投稿であるのかを視覚的に判断することができる。実施形態1で説明したように、単純な正誤数だけでは信頼性が高い投稿であるのか低い情報であるのかの判別が難しい場合がある。本実施形態では、各種の条件などを考慮した投稿情報の情勢に基づいて表示態様を変えることで、投稿情報を閲覧するユーザは、投稿情報の状態を直ちに把握することができる。また、信頼性の高い投稿情報のみを選別して閲覧するといった利用形態も可能となる。
10 ユーザ端末
100 投稿情報管理システム
110 ウェブサーバ
111 投稿受付部
112 提供部
113 更新部
114 通知部
150 DBサーバ
151 管理部
152 判定部
153 状態遷移部
100 投稿情報管理システム
110 ウェブサーバ
111 投稿受付部
112 提供部
113 更新部
114 通知部
150 DBサーバ
151 管理部
152 判定部
153 状態遷移部
Claims (14)
- 投稿された投稿情報と、前記投稿情報に対する投票の情勢と、前記投稿情報の状態とを管理する管理部と、
前記状態に基づいて、前記投稿情報を、前記投稿情報に対する投票を受け付け可能な状態でユーザ端末に提供する提供部と、
前記投稿情報に対する投票を複数のユーザ端末から受信し、前記管理部で管理されている前記情勢を更新する更新部と、
前記更新部において更新された前記情勢に基づいて、前記投稿情報を前記ユーザ端末に表示すべきか否かを判定する判定部と、
前記判定部によって前記投稿情報を前記ユーザ端末に表示すべきでないと判定された場合、前記投稿情報の状態を、前記ユーザ端末において表示が行われる状態から、前記ユーザ端末において表示が行われない状態に遷移させる状態遷移部と
を有する、投稿情報管理システム。 - 前記判定部は、投票された第二のカテゴリへの投票数に基づく値に対する、前記第二のカテゴリよりも肯定的なカテゴリを示す第一のカテゴリへの投票数に基づく値の比に関する第一の値が、所定の閾値を下回る場合、前記投稿情報を前記ユーザ端末に表示すべきでないと判定する、請求項1に記載の投稿情報管理システム。
- 前記判定部は、投票したユーザの情報に応じた重みを前記第一のカテゴリへの投票のそれぞれに乗じた値と、投票したユーザの情報に応じた重みを前記第二のカテゴリへの投票のそれぞれに乗じた値とを用いて前記判定を行う、請求項2に記載の投稿情報管理システム。
- 前記判定部は、信頼区間の上限値を前記第一の値として用いる、請求項2または3に記載の投稿情報管理システム。
- 前記所定の閾値は、前記投稿情報が投稿された日時からの経過時間に応じて変わる、請求項2から4のいずれか一項に記載の投稿情報管理システム。
- 前記第一の値が前記所定の閾値を下回らず、かつ、前記所定の閾値よりも高い第二の閾値を下回る場合、
前記投稿情報の状態が、前記ユーザ端末において表示が行われない状態に遷移する可能性があることを、前記投稿情報を投稿したユーザに通知する通知部をさらに有する、請求項2から5のいずれか一項に記載の投稿情報管理システム。 - 前記管理部は、
前記投稿情報を投稿した投稿ユーザの情報をさらに管理し、
前記第一のカテゴリの投票数と前記第二のカテゴリの投票数とに基づいて、当該投稿情報を投稿した投稿ユーザにポイントを付与する。請求項2から6のいずれか一項に記載の投稿情報管理システム。 - 前記提供部は、前記投稿情報の状態が、前記ユーザ端末において表示が行われない状態に遷移された場合、当該投稿情報の本文を非表示にした状態で当該投稿情報を前記ユーザ端末に提供し、
前記管理部は、前記投稿情報の状態が、前記ユーザ端末において表示が行われない状態に遷移された場合、所定の期間が経過した後に、当該投稿情報を削除する、請求項1から7のいずれか一項に記載の投稿情報管理システム。 - 前記提供部は、前記管理部で管理されている前記投稿情報に対する票数を、前記投稿情報と共に前記ユーザ端末に提供する、請求項1から8のいずれか一項に記載の投稿情報管理システム。
- 前記管理部で管理されている第一の投稿情報に対する再投稿である第二の投稿情報が投稿された場合、
前記提供部は、前記第一の投稿情報を、前記第一の投稿情報に対する投票を受け付け不可能な状態で、前記第一の投稿情報に対する票数と共に前記ユーザ端末に提供し、
前記判定部は、前記第一の投稿情報に対する投票結果を用いることなく、前記第二の投稿情報に対する投票の結果に基づいて、前記第二の投稿情報を前記ユーザ端末に表示すべきか否かを判定する、請求項9に記載の投稿情報管理システム。 - 前記投稿情報は、投稿対象に対するユーザの評価点を含み、
前記管理部は、
同じ投稿対象に対する複数のユーザからの評価点に従って算出された第一の評価点を、前記投稿対象に関連付けて管理し、
前記投稿情報の状態が、前記ユーザ端末において表示が行われない状態に遷移した場合、当該投稿情報に含まれる評価点を除いて第一の評価点を再度算出する、請求項1から10のいずれか一項に記載の投稿情報管理システム。 - 前記更新部において更新された前記情勢に基づいて、前記投稿情報がユーザ端末で表示される表示態様を変更する変更部をさらに有し、
前記変更部は、前記表示態様を、
第一のカテゴリの投票数から、前記第一のカテゴリとは異なる第二のカテゴリの投票数を差し引いた第一の数が、第二の数以上でありかつ第三の数以下の投稿を示す第一態様、
前記第一の数が前記第三の数より大きい投稿を示す第二態様、
前記第一の数が前記第二の数より小さい投稿を示す第三態様、および
前記ユーザ端末で投稿情報の本文が表示されない第四態様、
の少なくとも1つの表示態様に変更する、請求項1から11のいずれか一項に記載の投稿情報管理システム。 - 投稿された投稿情報と、前記投稿情報に対する投票の情勢と、前記投稿情報の状態とを管理する管理部を有する投稿情報管理システムにおける投稿情報管理方法であって、
前記状態に基づいて、前記投稿情報を、前記投稿情報に対する投票を受け付け可能な状態でユーザ端末に提供する提供ステップと、
前記投稿情報に対する投票を複数のユーザ端末から受信し、前記管理部で管理されている前記情勢を更新する更新ステップと、
前記更新ステップにおいて更新された前記情勢に基づいて、前記投稿情報を前記ユーザ端末に表示すべきか否かを判定する判定ステップと、
前記判定ステップにおいて前記投稿情報を前記ユーザ端末に表示すべきでないと判定された場合、前記投稿情報の状態を、前記ユーザ端末において表示が行われる状態から、前記ユーザ端末において表示が行われない状態に遷移させる状態遷移ステップと
を有する、投稿情報管理方法。 - コンピュータを、請求項1から12のいずれか一項に記載の投稿情報管理システムにおける各部として機能させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016185249A JP2018049504A (ja) | 2016-09-23 | 2016-09-23 | 投稿情報管理システム、投稿情報管理方法、およびプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016185249A JP2018049504A (ja) | 2016-09-23 | 2016-09-23 | 投稿情報管理システム、投稿情報管理方法、およびプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2018049504A true JP2018049504A (ja) | 2018-03-29 |
Family
ID=61767691
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016185249A Pending JP2018049504A (ja) | 2016-09-23 | 2016-09-23 | 投稿情報管理システム、投稿情報管理方法、およびプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2018049504A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2019185768A (ja) * | 2018-04-05 | 2019-10-24 | 裕一郎 河野 | 記事評価システム |
JP2019194795A (ja) * | 2018-05-02 | 2019-11-07 | 三井住友カード株式会社 | 口コミ促進支援システム、方法、およびプログラム |
JP2020035022A (ja) * | 2018-08-27 | 2020-03-05 | 日本電信電話株式会社 | 評価更新装置、方法、及びプログラム |
JP2020198511A (ja) * | 2019-05-31 | 2020-12-10 | 株式会社東芝 | 災害情報投稿処理システム、災害情報投稿処理方法及び災害情報投稿処理サーバ装置 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007080170A (ja) * | 2005-09-16 | 2007-03-29 | Naoki Fukui | 電子掲示板システム |
JP2014154067A (ja) * | 2013-02-13 | 2014-08-25 | So-Net Corp | 情報処理装置および情報処理方法 |
JP2015143919A (ja) * | 2014-01-31 | 2015-08-06 | 株式会社 ディー・エヌ・エー | コンテンツの配信システム、配信プログラム及び配信方法 |
-
2016
- 2016-09-23 JP JP2016185249A patent/JP2018049504A/ja active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007080170A (ja) * | 2005-09-16 | 2007-03-29 | Naoki Fukui | 電子掲示板システム |
JP2014154067A (ja) * | 2013-02-13 | 2014-08-25 | So-Net Corp | 情報処理装置および情報処理方法 |
JP2015143919A (ja) * | 2014-01-31 | 2015-08-06 | 株式会社 ディー・エヌ・エー | コンテンツの配信システム、配信プログラム及び配信方法 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2019185768A (ja) * | 2018-04-05 | 2019-10-24 | 裕一郎 河野 | 記事評価システム |
JP2019194795A (ja) * | 2018-05-02 | 2019-11-07 | 三井住友カード株式会社 | 口コミ促進支援システム、方法、およびプログラム |
JP2020035022A (ja) * | 2018-08-27 | 2020-03-05 | 日本電信電話株式会社 | 評価更新装置、方法、及びプログラム |
WO2020045107A1 (ja) * | 2018-08-27 | 2020-03-05 | 日本電信電話株式会社 | 評価更新装置、方法、及びプログラム |
JP7024663B2 (ja) | 2018-08-27 | 2022-02-24 | 日本電信電話株式会社 | 評価更新装置、方法、及びプログラム |
US12013908B2 (en) | 2018-08-27 | 2024-06-18 | Nippon Telegraph And Telephone Corporation | Evaluation updating device, method, and program |
JP2020198511A (ja) * | 2019-05-31 | 2020-12-10 | 株式会社東芝 | 災害情報投稿処理システム、災害情報投稿処理方法及び災害情報投稿処理サーバ装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Bennett et al. | Examining the impact of social media on mood and body dissatisfaction using ecological momentary assessment | |
Hocevar et al. | Source credibility, expertise, and trust in health and risk messaging | |
Sjoberg et al. | The effect of bureaucratic responsiveness on citizen participation | |
Robinson et al. | Social media and suicide prevention: a systematic review | |
US11676221B2 (en) | Systems and methods for encouragement of data submission in online communities | |
Houghton et al. | Who needs social networking? An empirical enquiry into the capability of Facebook to meet human needs and satisfaction with life | |
US9154575B2 (en) | Soft matching user identifiers | |
Kingori et al. | ‘If I went to my mom with that information, I’m dead’: sexual health knowledge barriers among immigrant and refugee Somali young adults in Ohio | |
Aaby et al. | Large diversity in Danish health literacy profiles: perspectives for care of long-term illness and multimorbidity | |
JP2018049504A (ja) | 投稿情報管理システム、投稿情報管理方法、およびプログラム | |
Signorelli et al. | Third Italian national survey on knowledge, attitudes, and sexual behaviour in relation to HIV/AIDS risk and the role of health education campaigns | |
JP6540118B2 (ja) | メッセージ表示プログラム、メッセージ表示方法、および情報処理装置 | |
Hutcheson et al. | Enrolment, achievement and retention on ‘traditional’and ‘Use of Mathematics’ pre-university courses | |
Horn et al. | Embedded library services: Beyond chance encounters for students from low SES backgrounds | |
Norris et al. | Direct and indirect experiences with heterosexism: How slurs impact all students | |
Bishop et al. | The real and ideal experiences of what culturally competent counselling or psychotherapy service provision means to lesbian, gay and bisexual people | |
Štulhofer et al. | Is early exposure to pornography a risk factor for sexual compulsivity? Findings from an online survey among young heterosexual adults | |
JP7494476B2 (ja) | マッチング支援システム、マッチング支援装置、信頼度算出方法、及び信頼度算出プログラム | |
Pérez Jolles et al. | Involving Latina/o parents in patient‐centered outcomes research: Contributions to research study design, implementation and outcomes | |
US8904502B1 (en) | Systems and methods for rating organizations using user defined password gates | |
JP7496116B2 (ja) | 支援要請制御装置 | |
JP2023065723A (ja) | 投稿情報管理システム、投稿情報管理プログラム及び投稿情報管理方法 | |
Taylor et al. | Trust in Health Care and Science: Toward Common Ground on Key Concepts | |
Jaeger | Public libraries and local e-government | |
JP2008140286A (ja) | ソーシャルネットワーキングサービスを用いた分譲マンション販売支援システム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20190910 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20200525 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20201113 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20210506 |