(57)【要約】  レシパのレポート承認に係る負担を抑えながら、レポート掲載ページの質悪化の抑制とレポート掲載数の低下抑制との両立を図りつつ、レシパとレポータとの間のコミュニケーション促進を図る。  本発明に係る情報処理装置は、レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、レシパ、レポータそれぞれに紐付く情報に基づいて評価する親密度評価部と、親密度が一定度以上のレポータである親密レポータがレポートを投稿した場合は、レシパに当該レポートについての承認を要求した後、レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、親密度が一定度以上でないレポータである非親密レポータがレポートを投稿した場合は、レシパに当該レポートについての承認を要求する一方で、時間経過に応じたレポート承認処理を行わない承認制御部とを備えている。
2018034000.tif 000002
【特許請求の範囲】
【請求項１】
レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価部と、
前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータがレポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御部と、を備える
情報処理装置。
【請求項２】
前記レポータが過去に投稿したレポートについての情報信頼度を評価した結果に基づき、前記レポータが不適レポータであるか否かを判定する不適レポータ判定部を備え、
前記承認制御部は、
未承認の前記レポートについて前記レシパに承認を要求する前に、当該レポートが前記不適レポータにより投稿されたレポートである不適レポートか否かを判定し、前記不適レポートであると判定した場合は当該レポートについての承認を要求しない
請求項１に記載の情報処理装置。
【請求項３】
前記不適レポータ判定部は、
前記不適レポータであるか否かを、前記レポータが同一又は類似画像を用いたレポートを複数のレシピに対して投稿しているか否かに基づき判定する
請求項１に記載の情報処理装置。
【請求項４】
前記親密度評価部は、
前記レシパによる前記レポータに対する過去のレポート承認回数に基づき前記親密度を評価する
請求項１に記載の情報処理装置。
【請求項５】
前記親密度評価部は、
前記レポータによる投稿レシピに対する前記レシパのレポート投稿回数に基づき前記親密度を評価する
請求項１に記載の情報処理装置。
【請求項６】
前記親密度評価部は、
前記レポータによる投稿レシピに対する前記レシパの投稿レポートについての承認回数に基づき前記親密度を評価する
請求項５に記載の情報処理装置。
【請求項７】
前記承認制御部は、
前記レシパの過去におけるレポート承認行動を分析した結果に基づき、前記承認を要求するタイミングを調整する
請求項１に記載の情報処理装置。
【請求項８】
前記承認制御部は、
前記レシパの投稿レシピに対する投稿レポートとして複数の未承認レポートがある場合は、前記レシパに対する承認の要求として、個々の未承認レポートに対する承認指示操作が可能な形式による要求を行う
請求項１に記載の情報処理装置。
【請求項９】
前記承認制御部は、
前記レシパに対する承認の要求として前記レポータの前記親密レポータへの登録指示操作が可能な形式による要求を行う
請求項１に記載の情報処理装置。
【請求項１０】
前記承認制御部は、
承認され且つ前記レシパからの返信入力が行われたレポートであることを条件に、前記レポートが前記ウェブサイトに掲載されるように制御を行う
請求項１に記載の情報処理装置。
【請求項１１】
前記承認制御部は、
前記レシパの投稿レシピに対する投稿レポートに複数の未承認レポートがある場合は、前記レシパに対する承認の要求として、個々の未承認レポートに対する前記返信入力が可能な形式による要求を行う
請求項１０に記載の情報処理装置。
【請求項１２】
前記承認制御部は、
前記返信入力として、返信内容が定型の内容とされた情報である定型返信情報の入力を受け付ける
請求項１０に記載の情報処理装置。
【請求項１３】
レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価ステップと、
前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータがレポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御ステップと、を情報処理装置が実行する
情報処理方法。
【請求項１４】
レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価機能と、
前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータがレポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御機能と、を情報処理装置に実現させる
プログラム。
【請求項１５】
レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価機能と、
前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータがレポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御機能と、を情報処理装置に実現させるプログラムを記憶した
記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置と情報処理方法、情報処理装置を実現するプログラム、及びプログラムを記憶した記憶媒体に関するものであり、特には、ウェブサイトに投稿されたレシピに対するレポートの承認に係る処理技術の分野に関する。
【背景技術】
【０００２】
料理についてのレシピの投稿を受け付け、投稿されたレシピを掲載するウェブサイト（以下「レシピサイト」と表記）が広く知られている。各ユーザは、例えばサイト側で用意された所定の入力ページに対して使用食材や調味料といった材料情報や各材料の分量等の情報入力を行うことで、レシピを投稿できる。以下、レシピの投稿者を「レシパ」と表記する。【０００３】
また、レシピサイトにおいて各ユーザは、サイトを通じて提示されたレシピを閲覧し、該レシピに従って料理を作成することができる。さらに、レシピに従って料理を作成したユーザは、作成した料理についての感想やレシパに対するコメント等を「レポート」としてサイトに投稿することができる。以下、レポートの投稿者のことを「レポータ」と表記する。投稿されたレポートは、一般的に、レシパ側の承認を経た上でサイトに掲載される。
なお、レシピサイトによっては、レポートの投稿に応じて投稿者にポイント等のインセンティブが付与されることがある。【０００４】
さらに、レシピサイトにおいて、投稿されたレポートについてはレシパが返信コメントを入力することも可能とされている。【０００５】
なお、関連する従来技術については例えば下記特許文献１を挙げることができる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１２−１４６１０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ここで、レシピサイトにおいては、例えばサイトの利用促進等の目的のため、レポートの掲載ページをレシパとレポータとのコミュニケーションの場として発展させたいとの要望がある。
しかし、レシパが投稿レポートについて承認を行うことは、特に人気レシパ（レシピの被閲覧数の多いレシパ）やレシピ投稿数の多いレシパ等にとっては負担となり、承認が滞りがちとなる虞がある。承認が滞ることは、レシパとレポータとの間のコミュニケーション機会の喪失に繋がる虞があり、望ましくない。【０００８】
この際、レポートをサイト側で自動承認することも考えられるが、際限なくレポートが承認されてしまうとレシパの意に反したレポートが掲載されたり、不十分な内容のレポートでもレポータにポイントが付与されてしまう等の問題が生じる虞がある。【０００９】
本発明は上記した事情に鑑み為されものであり、レシパのレポート承認に係る負担を抑えながら、レポート掲載ページの質悪化の抑制とレポート掲載数の低下抑制との両立を図りつつ、レシパとレポータとの間のコミュニケーション促進を図ることを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係る情報処理装置は、レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価部と、前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータがレポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御部と、を備えるものである。【００１１】
本発明によると、親密レポータの投稿レポートは時間経過に応じて自動承認されるため、それらのレポートについてレシパの承認の手間が省かれる。また、自動承認を行っていることで、レポートの掲載数の低下抑制を図ることが可能とされる。
また、本発明では、非親密レポータによるレポートは自動承認の対象外とされており、レシパによる手動承認が要求される。このため、掲載レポートの質悪化の抑制が図られる。
さらに、上記のように非親密レポータによるレポートにレシパの手動承認を要求していることは、レシパに非親密レポータとのコミュニケーション機会を与えていることになるため、両者のコミュニケーション促進を図ることが可能とされる。そして、このようにコミュニケーション促進が図られることは、レシパと非親密レポータとの間の親密度向上に寄与し、次回に非親密レポータからレポート投稿があった際に当該レポートが自動承認される可能性が高まる。自動承認される可能性が高まることは、レシパのレポート承認に係る負担抑制に寄与するものである。【００１２】
上記した本発明に係る情報処理装置においては、前記レポータが過去に投稿したレポートについての情報信頼度を評価した結果に基づき、前記レポータが不適レポータであるか否かを判定する不適レポータ判定部を備え、前記承認制御部は、未承認の前記レポートについて前記レシパに承認を要求する前に、当該レポートが前記不適レポータにより投稿されたレポートである不適レポートか否かを判定し、前記不適レポートであると判定した場合は当該レポートについての承認を要求しないことが可能である。【００１３】
これにより、レシパが未承認のレポートのうちシステム側で事前に不適と判定されたレポータのレポートは承認が要求されない。このため、当該レポートについてレシパによる承認の手間が省かれる。【００１４】
上記した本発明に係る情報処理装置においては、前記不適レポータ判定部は、前記不適レポータであるか否かを、前記レポータが同一又は類似画像を用いたレポートを複数のレシピに対して投稿しているか否かに基づき判定することが可能である。【００１５】
これにより、レポートについての情報信頼度の評価として、レシピに対するレポートに適した評価を行うことが可能とされる。【００１６】
上記した本発明に係る情報処理装置においては、前記親密度評価部は、前記レシパによる前記レポータに対する過去のレポート承認回数に基づき前記親密度を評価するが可能である。【００１７】
レシパによるレポータに対する過去のレポート承認回数は、両者の間のコミュニケーション頻度を推し量る指標として機能する。
また、投稿レポートが自動承認されなかったレポータは、前記レシパへのレポート投稿を繰り返すうちに、その投稿レポートが自動承認されるように図られる。換言すれば、レシパは、同一レポータに対してレポート承認を繰り返すうち該レポータに対するレポート承認を行う手間が省かれるようになる。【００１８】
上記した本発明に係る情報処理装置においては、前記親密度評価部は、前記レポータによる投稿レシピに対する前記レシパのレポート投稿回数に基づき前記親密度を評価することが可能である。【００１９】
レポータによる投稿レシピに対するレシパのレポート投稿回数としても、両者の間のコミュニケーション頻度を推し量る指標として機能する。【００２０】
上記した本発明に係る情報処理装置においては、前記親密度評価部は、前記レポータによる投稿レシピに対する前記レシパの投稿レポートについての承認回数に基づき前記親密度を評価することが可能である。【００２１】
これにより、レシパとレポータとの間の親密度がより適切に評価される。【００２２】
上記した本発明に係る情報処理装置においては、前記承認制御部は、前記レシパの過去におけるレポート承認行動を分析した結果に基づき、前記承認を要求するタイミングを調整するが可能である。【００２３】
これにより、例えばレポートへの承認が遅滞傾向にあるレシパには早めに承認を要求する等、レシパによるレポート承認行動の特性に応じた適切なタイミングにより承認要求を行うことが可能とされる。【００２４】
上記した本発明に係る情報処理装置においては、前記承認制御部は、前記レシパの投稿レシピに対する投稿レポートとして複数の未承認レポートがある場合は、前記レシパに対する承認の要求として、個々の未承認レポートに対する承認指示操作が可能な形式による要求を行うことが可能である。【００２５】
これにより、レシパによるレポート承認の容易性が増す。【００２６】
上記した本発明に係る情報処理装置においては、前記承認制御部は、前記レシパに対する承認の要求として前記レポータの前記親密レポータへの登録指示操作が可能な形式による要求を行うことが可能である。【００２７】
これにより、レシパは非親密レポータを手動により親密レポータに登録することが可能とされる。
十分な親密性を感じるか否かはレシパ個人の性格やレポータとのコミュニケーション内容等の条件で異なり得るものであり、コミュニケーションが僅かであっても十分な親密性が築かれるケースも想定され得る。このため、親密レポータの登録として、親密度に基づく自動登録のみでなく手動登録が可能とされることで、自動承認の対象者数の増加が見込まれる。【００２８】
上記した本発明に係る情報処理装置においては、前記承認制御部は、承認され且つ前記レシパからの返信入力が行われたレポートであることを条件に、前記レポートが前記ウェブサイトに掲載されるように制御を行うが可能である。【００２９】
これにより、投稿レポートを掲載させるにあたり、レシパはレポートに対する返信という形式でのコミュニケーションをレポータに対してとることが必須とされる。【００３０】
上記した本発明に係る情報処理装置においては、前記承認制御部は、前記レシパの投稿レシピに対する投稿レポートに複数の未承認レポートがある場合は、前記レシパに対する承認の要求として、個々の未承認レポートに対する前記返信入力が可能な形式による要求を行うことが可能である。【００３１】
これにより、投稿レポートに対する返信入力の容易性が増す。【００３２】
上記した本発明に係る情報処理装置においては、前記承認制御部は、前記返信入力として、返信内容が定型の内容とされた情報である定型返信情報の入力を受け付けることが可能である。【００３３】
これによりレシパは、投稿レポートへの返信入力を例えば定型文やスタンプ等の入力で済ませることが可能とされる。【００３４】
また、本発明に係る情報処理方法は、レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価ステップと、前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータがレポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御ステップと、を情報処理装置が実行する情報処理方法である。
このような情報処理方法によっても、上記した本発明に係る情報処理装置と同様の作用が得られる。【００３５】
さらに、本発明に係るプログラムは、上記情報処理方法として実行する処理を情報処理装置に実行させるプログラムである。
さらにまた、本発明に係る記憶媒体は、上記プログラムを記憶した記憶媒体である。これらのプログラムや記憶媒体により上記の情報処理装置を実現する。
【発明の効果】
【００３６】
本発明によれば、レシパのレポート承認に係る負担を抑えながら、レポート掲載ページの質悪化の抑制とレポート掲載数の低下抑制との両立を図りつつ、レシパとレポータとの間のコミュニケーション促進を図ることができる。
【図面の簡単な説明】
【００３７】
【図１】第１の実施の形態のネットワークシステムの例を示した図である。
【図２】レポートの掲載例を示した図である。
【図３】実施の形態のネットワークシステムを構成するコンピュータ装置のハードウェア構成を示したブロック図である。
【図４】第１の実施の形態としての承認制御手法に係る機能をブロック化して示した機能ブロック図である。
【図５】親密情報ＤＢ（データベース）の記憶情報の例を示した図である。
【図６】第１の実施の形態における承認要求についての説明図である。
【図７】親密レポータの判定に係る処理のフローチャートである。
【図８】不適レポータの判定に係る処理のフローチャートである。
【図９】遅滞傾向ユーザの判定に係る処理のフローチャートである。
【図１０】承認要求に係る処理のフローチャートである。
【図１１】自動承認に係る処理のフローチャートである。
【図１２】第２の実施の形態としての承認制御手法に係る機能をブロック化して示した機能ブロック図である。
【図１３】第２の実施の形態における承認要求についての説明図である。
【図１４】第２の実施の形態としての承認制御手法を実現するための処理を示したフローチャートである。
【発明を実施するための形態】
【００３８】
以下、実施の形態を次の順序で説明する。
＜１．第１の実施の形態＞
［1-1．ネットワークシステムの概要］
［1-2．コンピュータ装置のハードウェア構成］
［1-3．第１の実施の形態としての承認制御手法］
［1-4．処理手順］
［1-5．第１の実施の形態のまとめ］
＜２．第２の実施の形態＞
［2-1．第２の実施の形態としての承認制御手法］
［2-2．処理手順］
［2-3．第２の実施の形態のまとめ］
＜３．プログラム及び記憶媒体＞
＜４．変形例＞
【００３９】
＜１．第１の実施の形態＞
［1-1．ネットワークシステムの概要］
図１に、本実施の形態で前提とするネットワークシステム１の例を示す。
ネットワークシステム１においては、例えばインターネットとしてのネットワーク２を介して、レシピサイト運営システム３におけるレシピサイトサーバ３１と複数のユーザ端末４のそれぞれが互いに通信可能とされている。
【００４０】
ユーザ端末４は、ウェブブラウザを備えたコンピュータ装置である。ユーザ端末４としては、例えば高機能携帯電話機（スマートフォン）や携帯電話機、携帯情報端末（タブレット端末）、携帯型又は据置型のパーソナルコンピュータ（ＰＣ）などが挙げられるが、ユーザ端末４の種類はこれらに限定されない。
ユーザ端末４は、ＨＴＴＰ（Hypertext Transfer Protocol）要求をレシピサイト運営システム３におけるレシピサイトサーバ３１等に送信することでウェブページや所定の処理を要求する。またユーザ端末４は、ＨＴＴＰ要求に応じて送られてきたウェブページデータ（例えばＨＴＭＬ（HyperText Markup Language）データ等）を受信し、該ウェブページデータに基づいてウェブブラウザによりウェブページの表示処理を行う。これにより、ユーザは所望のウェブページを閲覧したり操作したりすることができる。
【００４１】
レシピサイト運営システム３は、それぞれコンピュータ装置で構成されたレシピサイトサーバ３ａ、ユーザＤＢ（データベース）３２、レシピＤＢ３３、レポートＤＢ３４、及び親密情報ＤＢ３５を備えている。これらの各装置は、例えばＬＡＮ（Local Area Network）等のネットワークを介して互いに通信可能とされている。
【００４２】
レシピサイトサーバ３１は、料理のレシピの投稿受け付けやレシピの提示が行われるウェブサイトであるレシピサイトに関する各種処理を行う情報処理装置である。
また、ユーザＤＢ３２には、レシピサイトを利用するユーザに関する各種の情報が記憶される。
【００４３】
ここで、ユーザは、レシピサイトを利用するにあたり、レシピサイト運営システム３に会員登録を行うことができる。会員登録の際にユーザは、ユーザＩＤ（ユーザ識別情報）、パスワード、氏名、メールアドレスなどの連絡先情報等、必要情報を登録する。ユーザは、登録したユーザＩＤ及びパスワードによりレシピサイトにログインすることで、レシピサイトが提供する要ログインの各種サービスを受けることができる。例えば、以下で説明するレシピの投稿やレシピに対する作成レポートの投稿等である。
【００４４】
ユーザＤＢ３２には、会員としてのユーザに係る各種の情報がユーザＩＤごとに記憶されている。ユーザＤＢ３２には、ユーザに係る情報として上記の必要情報が記憶されている。さらに、ユーザＤＢ３２には、レシピの閲覧やお気に入りレシピの登録等、レシピサイトにおけるユーザの各種行動履歴に係る情報（以下「行動履歴情報」と表記）等も記憶されている。
なお、本例における行動履歴情報については後述する。
【００４５】
レシピサイトサーバ３１は、ユーザ端末４から送られてきたＨＴＴＰ要求に基づいて様々な処理を行う。例えば、レシピの投稿受け付けを行うためのウェブページをユーザに提示し、該ウェブページへの入力情報に基づいてレシピ情報（レシピの内容を示す情報）をレシピＤＢ３３に登録する処理を行う。
【００４６】
レシピ情報は、例えばレシピ名、料理ＩＤ、ジャンル、人数、使用食材とその分量、使用調味料とその分量、調理手順、及び料理画像の各情報で構成される。
なお、料理ＩＤは、レシピ情報に従って作成される料理を識別するための識別子である。また、ジャンルの情報は、料理が属するジャンルの情報であり、例えば「肉料理」「魚料理」「サラダ」「飲み物」等の各種分類が挙げられる。人数の情報は、レシピ情報に従って作成される対象料理が何人前であるかを表す情報とされる。また料理画像は、完成状態の料理を表すべき画像であり、例えばユーザによる投稿画像が用いられる。
【００４７】
投稿されたレシピには、レシピを一意に特定可能とするための識別子であるレシピＩＤが割り付られ、レシピ情報は該レシピＩＤと対応づけられて（紐付けられて）レシピＤＢ３３に記憶される。
【００４８】
ここで、以下、レシピを投稿したユーザのことを「レシパ」と表記する。
【００４９】
レシピサイトサーバ３１は、レシピＤＢ３３の記憶情報に基づき、レシピサイト上にレシピを掲載する処理を行う。具体的に、本例のレシピサイトサーバ３１は、ユーザによって指定された検索キーワード等の検索条件に基づきレシピの検索処理を行い、検索条件に合致したレシピを掲載したウェブページをユーザに提示する処理を行う。
【００５０】
また、レシピサイトサーバ３１は、レシピ情報に従って料理を作成したユーザより、作成レポートの投稿受け付けを行う。作成レポートは、レシピごとに投稿可能な情報とされ、例えば料理を作成した感想やレシパに対するコメント等の情報を含むべき情報とされている。本実施の形態では、作成レポートとしてはテキスト情報のみでなく、作成した料理を表す画像の投稿も可能とされている。
レシピサイトサーバ３１は、作成レポートの投稿受け付けを行うためのウェブページをユーザに提示し、該ウェブページへの入力情報に基づいて作成レポートをレポートＤＢ３４に登録する処理を行う。
【００５１】
投稿された作成レポートには、作成レポートを一意に特定可能とするための識別子であるレポートＩＤが割り付られる。レシピサイトサーバ３１は、投稿された作成レポートの情報と投稿者のユーザＩＤとをレポートＩＤと対応づけてレポートＤＢ３４に記憶させる。
【００５２】
以下、作成レポートを投稿したユーザのことを「レポータ」と表記する。
【００５３】
また、レシピサイトサーバ３１は、投稿された作成レポートに対するレシパからの返信コメントの入力を受け付ける。さらに、レシピサイトサーバ３１は、返信コメントに対するレポータからのコメントの入力を受け付ける。
レシピサイトサーバ３１は、これらレシパからの返信コメントや返信コメントに対するレポータによるコメントの入力があった場合は、入力された返信コメントや返信コメントに対するコメントの情報を、該当する作成レポートのレポートＩＤと対応づけてレポートＤＢ３４に記憶させる。
【００５４】
図２は、作成レポートの掲載例を示した図である。
本例では、或るレシピに対して投稿された作成レポートは、該レシピの掲載ページにおいて掲載される。以下、レシピの掲載ページのことを「レシピページ」と表記する。
レシピページには、例えば上述したレシピの検索処理等を経てユーザにより指定されたレシピに対応するレシピ情報が掲載される。具体的に、この場合のレシピページには、レシピ情報を掲載する領域として、レシピ名の情報が掲載されるレシピ名掲載領域Ａｒ１、料理写真が掲載される料理写真掲載領域Ａｒ２、使用材料とその分量に関する情報として使用食材、使用調味料及びそれらの分量の情報がそれぞれ掲載される材料・分量掲載領域Ａｒ３、調理手順の情報が掲載される調理手順掲載領域Ａｒ４が設けられている。さらに、この場合のレシピページには、当該レシピページの掲載レシピに対して投稿された作成レポートが掲載されるレポート掲載領域Ａｒ５が設けられている。
【００５５】
レポート掲載領域Ａｒ５においては、複数の作成レポートを掲載可能とされている。個々の作成レポートの掲載領域においては、投稿された写真画像、及びテキストを掲載する領域が設けられていると共に、レシパからの返信コメントや該返信コメントに対するレポータからのコメントの入力があった場合には、それらのコメント情報の提示を指示するためのボタン（図中「その他のコメントを見る」）が提示される。
【００５６】
ここで、投稿された作成レポートは、本実施の形態ではレシパによる承認を受けたことを条件としてレシピページに掲載される。なお、本例のレシピページは、作成レポートが掲載されるという意味で、レポート掲載ページとも換言できる。
【００５７】
図１に戻り、ユーザＤＢ３２には、上述した行動履歴情報として、先に例示したレシピの閲覧等の行動についての履歴情報の他、レシピの投稿や作成レポートの投稿、レシパによる作成レポートの承認、及び作成レポートへのレシパによる返信といった各種行動についての履歴情報が記憶される。本例では、これら各種行動についての行動履歴情報は、レシピサイトサーバ３１がユーザの行動を監視した結果に基づきユーザＤＢ３２に記憶させる。
【００５８】
具体的に、レシピサイトサーバ３１は、レシピ閲覧履歴情報については、ユーザが閲覧したレシピのレシピＩＤを該ユーザのユーザＩＤと対応づけて記憶させる。また、レシピ投稿履歴情報については、ユーザが投稿したレシピのレシピＩＤを該ユーザのユーザＩＤと対応づけて記憶させ、レポート投稿履歴情報についてはユーザが投稿した作成レポートのレポートＩＤ、及び該作成レポートの投稿先レシピのレシピＩＤを該ユーザのユーザＩＤと対応づけて記憶させる。
さらに、承認履歴情報については、ユーザが承認を行った作成レポートのレポートＩＤと、該作成レポートを投稿したレポータのユーザＩＤとを該ユーザのユーザＩＤと対応づけて記憶させ、レポートへの返信履歴情報についてはユーザが返信コメントの入力を行った作成レポートのレポートＩＤを該ユーザのユーザＩＤと対応づけて記憶させる。
なお、上記のレシピ閲覧履歴情報、レシピ投稿履歴情報、レポート投稿履歴情報、承認履歴情報、返信履歴情報等、ユーザＤＢ３２に記憶される各行動履歴情報には、ユーザが該当する行動を行った日時の情報も記憶される。
【００５９】
また、本例のユーザＤＢ３２においては、不適フラグＦｉ、及び遅滞傾向フラグＦｄがユーザＩＤごとに対応づけられて記憶されているが、これら不適フラグＦｉ、遅滞傾向フラグＦｄについては後述する。
【００６０】
なお、図１において、レシピサイト運営システム３が備える親密情報ＤＢ３５の記憶情報については後述する。
【００６１】
また、図１において、ネットワーク２の構成は多様な例が想定される。例えば、インターネットを始めとして、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が想定される。
またネットワーク２の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線等の有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。
【００６２】
［1-2．コンピュータ装置のハードウェア構成］
図３に、図１で示したレシピサイトサーバ３１をはじめとした各装置（ユーザＤＢ３２、レシピＤＢ３３、レポートＤＢ３４、親密情報ＤＢ３５、及びユーザ端末４）を構成するコンピュータ装置のハードウェア構成を示す。
図３において、コンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ（Read Only Memory）１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ（Random Access Memory）１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、及びＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インタフェース１０５も接続されている。
入出力インタフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力部１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ（表示装置）、並びにスピーカなどよりなる出力部１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、外部装置との間で相互通信を行うための通信部１０９が接続されている。
入出力インタフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。
【００６３】
このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、特にレシピサイトサーバ３１としてのコンピュータ装置においては以降で説明する情報処理や通信が実行される。
【００６４】
なお、レシピサイトサーバ３１をはじめとして図１で示した各装置は、図３のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮ等によりシステム化されていてもよいし、インターネット等を利用したＶＰＮ等により遠隔地に配置されたものでもよい。
【００６５】
［1-3．第１の実施の形態としての承認制御手法］
図４の機能ブロック図を参照して、レシピサイトサーバ３１が実現する第１の実施の形態としての承認制御に係る各種機能について説明する。
図示するようにレシピサイトサーバ３１は、機能ごとに分けて親密度評価処理部Ｆ１、不適レポータ判定処理部Ｆ２、及び承認制御処理部Ｆ３を有するものとして表すことができる。
【００６６】
親密度評価処理部Ｆ１は、レシパとレポータとの親密度を、レシパ、レポータそれぞれに紐付く情報に基づいて評価する。
本例における親密度評価処理部Ｆ１は、ユーザＤＢ３２に記憶された行動履歴情報に基づいてレシパとレポータとの親密度を評価する。具体的に、親密度評価処理部Ｆ１は、レシパによるレポータに対する過去のレポート承認回数に基づいて両者の間の親密度を評価する。例えば、ユーザＡがレシパ、ユーザＢがユーザＡの投稿レシピに対する作成レポートを投稿したレポータであるとすると、ユーザＢがユーザＡの投稿レシピに対して過去に投稿した作成レポートのうち、ユーザＡにより承認された作成レポートの数を上記の「レポート承認回数」として特定する。
【００６７】
レシピサイトにおいて、レシパによるレポータに対する過去のレポート承認回数は、両者の間のコミュニケーション頻度を推し量る指標として機能する。このため、上記のレポート承認回数を特定することで、レシパとレポータとの間の親密度を適切に評価することができる。
ここで、後述するように本実施の形態では、レシパとの間の親密度が一定度以上である「親密レポータ」としてのレポータについては、該レシパへの投稿レポートが自動承認されるようになる。このため、上記のように親密度を適切に評価できるということは、親密の確度が比較的高いレポータを自動承認することができるということを意味する。
【００６８】
また、親密度評価処理部Ｆ１は、レポータによる投稿レシピに対してレシパが過去に作成レポートを投稿している場合には、該レポータによる投稿レシピに対する該レシパのレポート投稿回数に基づき、親密度を評価する。またこの際、親密度評価処理部Ｆ１は、レポータによる投稿レシピに対するレシパの投稿レポートについての承認回数も考慮する。
具体的に、本例の親密度評価処理部Ｆ１は、レポータによる投稿レシピに対してレシパが過去に作成レポートを投稿している場合には、上記した「レポート承認回数」を特定すると共に、レポータによる投稿レシピに対するレシパのレポート投稿回数、及び該レシパの投稿レポートに対してレポータが承認を行った回数を特定する。そして、これら特定した回数の値に基づいて、レシパとレポータとの間の親密度を計算する。本例では、これら特定した回数の値の合計値を親密度として計算する。
【００６９】
ここで、レポータによる投稿レシピに対するレシパのレポート投稿回数としても、両者の間のコミュニケーション頻度を推し量る指標として機能する。従って、上記による親密度の評価を行うことで、レシパとレポータ両者間の親密度を適切に評価することができる。さらには、親密の確度が比較的高いレポータを自動承認することができる。
【００７０】
また、上記のように親密度の評価にあたってレシパの投稿レポートに対するレポータによる承認回数を考慮していることで、レシパとレポータとの間の親密度がより適切に評価され、親密の確度がさらに高いレポータを自動承認することができる。
【００７１】
なお、上記した親密度の評価において、「承認」は、少なくともユーザの手動による承認のみを対象とすればよい。或いは、後述する自動承認を対象に含めることもできる。
【００７２】
続いて、不適レポータ判定処理部Ｆ２は、レポータが過去に投稿したレポートについての情報信頼度を評価した結果に基づき、レポータが不適レポータであるか否かを判定する。
ここで、レシピサイトとしては、レシピに対する作成レポートの投稿ごとにレポータに対してポイント等のインセンティブの付与を行う場合があり、その場合には、インセンティブの荒稼ぎ等を目的として、情報信頼性の低い作成レポートを比較的大量に投稿するレポータが出現することがある。この種のレポータについては、その投稿レポートについてレシパに承認を要求することはレシパの承認に係る負担を徒に増大させることに繋がるため望ましくない。このため本実施の形態では、この種のレポータを「不適レポータ」として特定し、後述するように、不適レポータからの投稿レポートが承認要求の対象から除外されるようにする。
【００７３】
本例の不適レポータ判定処理部Ｆ２は、不適レポータであるか否かを、レポータが同一又は類似画像を用いたレポートを複数のレシピに対して投稿しているか否かに基づき判定する。
ポイント等の荒稼ぎを目的とした不適レポータにとって、作成レポートの投稿にあたり作成した料理の写真をいちいち撮影することは手間であり、同一画像、又は全体的な明るさや色味を僅かに変更する等の比較的軽微な画像加工を施す等した類似画像を複数のレシピそれぞれへの投稿レポート間で使い回すといった事象が確認されている。具体的には、例えば或る「料理ｒ」についてのレシピとして、レシパＡによるレシピａ、レシパＢによるレシピｂ、レシパＣによるレシピｃが投稿されている場合において、それらレシピａ、レシピｂ、レシピｃのそれぞれに同一又は類似画像を用いた作成レポートが投稿されるといったケースである。
この点に鑑み、本例では複数のレシピへの投稿レポートに用いられるそれぞれの画像間の類似性に基づき、不適レポータの判定を行う。
【００７４】
不適レポータ判定処理部Ｆ２は、不適レポータの判定にあたり、先ずは対象とするレポータが過去に投稿した作成レポートのうち、投稿先レシピが異なる複数の作成レポートを特定し、それらの作成レポートに用いられている各画像を取得する。そして、取得した各画像について、取得した他の全ての画像との間の類似度をそれぞれ計算し、類似度が一定値以上の関係となっている画像を同一又は類似画像として特定する。この際、対象とするレポータは例えば料理ごとに同一又は類似画像を使い分けることも考えられ、その場合には、同一又は類似画像として複数の組が特定され得る。例えば、取得した画像の総数が「１０」であった場合に、そのうち「画像ｇ１、画像ｇ２、画像ｇ３」による組と、「画像ｇ５、画像ｇ６、画像ｇ７」による組とが、それぞれ類似度≧一定値の関係となっている画像として特定される等である。
【００７５】
なお、画像間の類似度を評価する手法としては、周知の手法を採用することができる。例えば、比較対象とする各画像から検出したエッジの一致度合いを類似度として計算することができる。或いは、例えば４×４画素サイズによる領域等、画像を構成する各領域ごとに対象とする画像間で画素値の平均値の差を計算し、該差の合計値を類似度として計算するなどの手法も採ることができ、類似度を評価する手法は特定の手法に限定されるものではない。
【００７６】
不適レポータ判定処理部Ｆ２は、特定した同一又は類似画像の数が一定値以上であれば、対象とするレポータが不適レポータであると判定する。これは、対象とするレポータによる投稿レポートの情報信頼性が一定度以下であれば、該レポータを不適レポータと判定していることに相当する。
ここで、上記のように同一又は類似画像が複数組特定された場合、すなわち同一又は類似画像の数が複数計算された場合には、それらの数のうち最大の数が一定値以上であれば、対象とするレポータが不適レポータであると判定する。
なお以下、同一又は類似画像については「同一・類似画像」と表記する。
【００７７】
不適レポータ判定処理部Ｆ２は、不適レポータと判定したレポータについては、該レポータのユーザＩＤと対応づけられてユーザＤＢ３２に記憶された不適フラグＦａをＯＦＦ（例えば「０」）からＯＮ（例えば「１」）に変更する処理を行う。
【００７８】
承認制御処理部Ｆ３は、親密度評価処理部Ｆ１が評価したレシパとレポータとの間の親密度に基づき、レポータが投稿した作成レポートの承認に係る制御を行う。具体的に、承認制御処理部Ｆ３は、親密度が一定度以上のレポータである親密レポータがレポートを投稿した場合は、レシパに当該レポートについての承認を要求した後、レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、親密度が一定度以上でないレポータである非親密レポータがレポートを投稿した場合は、レシパに当該レポートについての承認を要求する一方で、時間経過に応じたレポート承認処理を行わない。
すなわち、承認の要求については、親密レポータによる投稿レポート、及び非親密レポータによる投稿レポートの双方を対象として行われるが、時間経過に応じたレポート承認処理、つまりレシピサイトサーバ３１による自動承認は親密レポータによる投稿レポートのみを対象として行われるものである。
【００７９】
先ず、承認制御処理部Ｆ３が行う親密レポータの判定について説明する。
本例では、レシピに対する作成レポートが投稿されるごとに、親密度評価処理部Ｆ１によりレシパとレポータとの間の親密度計算が行われ、承認制御処理部Ｆ３は、計算された親密度に基づき、レポータが親密レポータであるか否かを判定する。本例の承認制御処理部Ｆ３は、上述のように親密度評価処理部Ｆ１がレポータによる投稿レシピに対してレシパが過去に作成レポートを投稿している場合か否かで異なる親密度計算手法を採ることに対応して、それぞれ異なる閾値を用いて親密レポータか否かの判定を行う。具体的に、レポータによる投稿レシピに対してレシパが過去に作成レポートを投稿していない場合に計算された親密度については、親密度が当該場合に対応して設定された閾値（以下「第一親密閾値」と表記）以上であるか否かにより親密レポータか否かを判定し、レポータによる投稿レシピに対してレシパが過去に作成レポートを投稿している場合に計算された親密度については、親密度が当該場合に対応して設定された閾値（以下「第二親密閾値」と表記）以上であるか否かにより親密レポータか否かを判定する。
【００８０】
レポータが親密レポータであると判定した場合、承認制御処理部Ｆ３は該レポータが親密レポータである旨を表す情報を親密情報ＤＢ３５に記憶させる。具体的には、レシパのユーザＩＤに対応づけて、親密レポータと判定したレポータのユーザＩＤを対応づけて記憶させる。
【００８１】
図５は、親密情報ＤＢ３５の記憶情報を例示した図である。
上記のような承認制御処理部Ｆ３による記憶処理が行われることで、親密情報ＤＢ３５には、レシパとしてのユーザごとに、該ユーザにとっての親密レポータが何れのユーザであるかを表す情報が構築される。
【００８２】
承認制御処理部Ｆ３は、上記のような親密レポータの判定結果に基づき、作成レポートの承認についての制御を行う。具体的に承認制御処理部Ｆ３は、或るレシパによる投稿レシピに対し該レシパにとっての親密レポータが作成レポートを投稿した場合は、レシパに当該作成レポートについての承認を要求した後、レシパから当該作成レポートについての手動による承認がなくても、時間経過に応じたレポート承認処理を行う。
また、或るレシパによる投稿レシピに対し該レシパにとって親密レポータでない非親密レポータが作成レポートを投稿した場合は、レシパに当該作成レポートについての承認を要求する一方で、当該作成レポートにつての時間経過に応じたレポート承認処理を行わない。
【００８３】
図６を参照し、作成レポートについての承認要求について説明する。
本例の場合、承認要求は、対象とするレシパに対して電子メールを送信することで行われる。以下、このように承認を要求する電子メールのことを「承認要求メール」と表記する。
本例では、作成レポートについての承認要求は、対象とするレシパの投稿レシピに対する投稿レポートとして複数の未承認レポートがある場合は、それら複数の未承認レポートについての承認をまとめて要求する形式で行う。
図６では、このように複数の未承認レポートについての承認をまとめて要求する形式による承認要求メールの例を示している。
【００８４】
この場合の承認要求メールにおいては、未承認レポートについての承認を要求するメッセージが提示されると共に、承認を要求する未承認レポートを特定するための情報、具体的に図６の例では未承認レポートの投稿内容を表す画像やテキストの情報がそれぞれ提示される。
【００８５】
さらに、本例における承認要求メールには、個々の未承認レポートに対する承認指示操作を可能とするための承認チェックボックスＣｂ１が未承認レポートごとに設けられている。ユーザは、未承認レポートについて承認を行う場合は、該当する未承認レポートに対して設けられた承認チェックボックスｃｂ１にチェックを入れ、承認要求メールに設けられた送信ボタンＢ１を操作する。これにより、チェックの入れられた未承認レポートについての承認を指示する情報がレシピサイトサーバ３１に返信され、レシピサイトサーバ３１（承認制御処理部Ｆ３）は該情報に基づいて該当する未承認レポートについての承認処理を行う。
【００８６】
このように本例では、レシパに対する承認の要求として、個々の未承認レポートに対する承認指示操作が可能な形式による要求を行っている。これにより、レシパによるレポート承認の容易性が増し、レポート掲載数低下の抑制効果を高めることができる。また、レシパと非親密レポータとの間のコミュニケーション促進を図ることができる。
【００８７】
また、この場合の承認要求メールには、未承認レポートを投稿したレポータの親密レポータへの登録指示操作を可能とするための登録チェックボックスｃｂ２が設けられている。なお、登録チェックボックスｃｂ２は、承認が要求される作成レポートの投稿レポータに非親密レポータが含まれている場合にのみ、承認要求メールに設けられるものである。該当する非親密レポータが複数存在する場合、登録チェックボックスｃｂ２はそれら非親密レポータごとに設けられる。
ユーザは、親密レポータへの登録を行う場合は、該当する登録チェックボックスｃｂ２にチェックを入れ、承認要求メールに設けられた送信ボタンＢ１を操作する。これにより、チェックの入れられたレポータを親密レポータに登録指示する情報がレシピサイトサーバ３１に返信され、レシピサイトサーバ３１は該情報に基づいて該当するレポータを親密レポータとして登録する処理を行う。具体的には、親密情報ＤＢ３５を対象とした情報記憶処理として、該当するレシパのユーザＩＤに対して登録対象とされたレポータのユーザＩＤを対応づけて記憶させる処理を行う。
【００８８】
上記のようにレシパに対する承認の要求としてレポータの親密レポータへの登録指示操作が可能な形式による要求を行うことで、レシパは非親密レポータを手動により親密レポータに登録することが可能とされる。
十分な親密性を感じるか否かはレシパ個人の性格やレポータとのコミュニケーション内容等の条件で異なり得るものであり、コミュニケーションが僅かであっても十分な親密性が築かれるケースも想定され得る。このため、親密レポータの登録として、親密度に基づく自動登録のみでなく手動登録が可能とされることで、自動承認の対象者数の増加が見込まれる。従って、ユーザのレポート承認に係る手間の抑制効果を高めることができる。
また、承認要求において親密レポータへの登録指示操作を可能としている点で、親密レポータの登録を促すための情報を承認要求とは別途にユーザに送信する必要がなくなり、レシピサイトサーバ３１の処理負担軽減を図ることができる。
【００８９】
上述のように承認制御処理部Ｆ３は、親密レポータが投稿した作成レポートについては、承認要求を行った後、時間経過に応じて自動的に承認処理を行う。本例の承認制御処理部Ｆ３は、当該作成レポートについての承認処理については、当該作成レポートの承認要求を行った日時からの経過時間が一定時間以上となったことに応じて実行する。
【００９０】
なお、本例の承認制御処理部Ｆ３は、上記のような自動的な承認処理、及びレシパの操作に基づく承認処理として、作成レポートごとに用意された承認フラグＦａをＯＦＦ（例えば「０」）からＯＮ（例えば「１」）に変更する処理を行う。
承認フラグＦａは、本例ではレポートＤＢ３４においてレポートＩＤごとに対応づけられて記憶された情報とされている。
【００９１】
ここで、承認制御処理部Ｆ３は、未承認のレポートについてレシパに承認を要求する前に、当該レポートが不適レポータにより投稿されたレポートである不適レポートか否かを判定する。そして、不適レポートであると判定した場合は、当該レポートについての承認を要求しない。本例では、上述した不適レポータ判定処理部Ｆ２の処理により、不適レポータとしてのユーザがユーザＤＢ３２に記憶された不適フラグＦｉのＯＮ／ＯＦＦにより管理される。承認制御処理部Ｆ３は、対象とするレポートを投稿したユーザに対応づけられている不適フラグＦｉがＯＮであれば、当該レポートを不適レポートと判定し、当該レポートについては承認要求の対象から除外する。
【００９２】
これにより、未承認レポートのうちシステム側で事前に不適と判定されたレポータの作成レポートについては、レシパに承認が要求されない。このため、当該レポートについてレシパによる承認の手間が省かれ、従って、レシパのレポート承認に係る負担抑制効果を高めることができる。
【００９３】
また、承認制御処理部Ｆ３は、レシパの過去におけるレポート承認行動を分析した結果に基づき、承認を要求するタイミングを調整する。
具体的に、本例では、上記のレポート承認行動の分析として、レシパの過去の承認済みレポートについて承認要求から承認を行うまでに要した時間を分析する。具体的には、レシパの過去の承認済みレポートについて、承認要求から承認を行うまでに要した時間の平均値を計算し、該平均値の大きさに応じて承認を要求するタイミングを調整する。
本例では、該平均値が大きいほど（つまり承認が滞りがちであるほど）、承認を要求するタイミングが早められるように承認の要求タイミングを調整する。
【００９４】
承認を要求するタイミングの調整手法として、例えば以下の手法を採る。
先ず前提として、本例では、１つの投稿レシピごとに、以下の（条件１）又は（条件２）を満たすことに応じて該投稿レシピに対する未承認レポートについての承認要求を行う。
（条件１）未承認レポート数が所定の閾値（以下「数閾値ｔｈ」と表記）以上。
（条件２）最古の未承認レポートの投稿日時からの経過時間が所定の閾値（以下「時間閾値ＴＨ」と表記）以上。
この前提において、上記した平均値が大きいほど、数閾値ｔｈ、及び時間閾値ＴＨとして小さな値を用いる。
【００９５】
本例では、承認要求のタイミングは２段階に調整する。具体的に、承認制御処理部Ｆ３は、上記の平均値が所定値以上であるレシパを「遅滞傾向ユーザ」と判定し、ユーザＤＢ３２においてユーザＩＤごとに対応づけられて記憶された遅滞傾向フラグＦｉのうち、当該レシパのユーザＩＤに対応づけられている遅滞傾向フラグＦｉをＯＦＦ（例えば「０」）からＯＮ（例えば「１」）に変更する。
承認制御処理部Ｆ３は、対象とするレシパが遅滞傾向フラグＦｉ＝ＯＮである遅滞傾向ユーザである場合は、遅滞傾向フラグＦｉ＝ＯＦＦである非遅滞傾向ユーザである場合よりも、上記の数閾値ｔｈ、及び時間閾値ＴＨとしてより値の小さい閾値を用いる。これにより、承認が滞りがちなレシパについては、承認を要求するタイミングが通常よりも早められるようになる。
【００９６】
ここで、上記のように承認制御処理部Ｆ３は、レシパとの間の親密度が一定度以上の親密レポータによる投稿レポートを自動承認の対象としている。この場合において、親密度評価処理部Ｆ１が前述のように「レシパによるレポータの過去のレポート承認回数」に基づいて親密度を評価することによると、投稿レポートが自動承認されなかったレポータは、レシパへのレポート投稿を繰り返すうちに、その投稿レポートが自動承認されるように図られる。換言すれば、レシパは、同一レポータに対してレポート承認を繰り返すうち該レポータに対するレポート承認を行う手間が省かれるようになるものであり、この点においてレシパの承認に係る負担抑制が図られる。
【００９７】
［1-4．処理手順］
図７乃至図１１のフローチャートを参照して、上記した第１の実施の形態としての手法を実現するために実行すべき処理の手順を説明する。なお、図７乃至図１１に示す処理は、レシピサイトサーバ３１におけるＣＰＵ１０１が例えばレシピサイトサーバ３１におけるＲＯＭ１０２や記憶部１０８等の所定の記憶装置に記憶されたプログラムに基づき実行するものである。
【００９８】
図７は、親密レポータの判定に係る処理を示している。
図７において、レシピサイトサーバ３１はステップＳ１０１で、作成レポートが投稿されるまで待機し、作成レポートが投稿された場合は、ステップＳ１０２でレポータ及び対象レシピのレシパを特定する。すなわち、投稿されたレポートのレポータとしてのユーザ、及び該レポートが対象とするレシピ、換言すれば該レポートの投稿先としてのレシピを投稿したレシパとしてのユーザのそれぞれについて、ユーザＩＤを特定する。
【００９９】
ステップＳ１０２に続くステップＳ１０３でレシピサイトサーバ３１は、レシパによるレポータへのレポート承認回数を特定する。すなわち、ユーザＤＢ３２に記憶されている前述した承認履歴情報に基づき、レシパによるレポータへの過去におけるレポート承認回数を特定する。
【０１００】
ステップＳ１０３に続くステップＳ１０４でレシピサイトサーバ３１は、レシパが過去にレポータの投稿レシピに対してレポート投稿しているか否かを判定する。該判定は、ユーザＤＢ３２に記憶されている前述したレポート投稿履歴情報、及びレシピ投稿履歴情報に基づき行うことができる。
【０１０１】
ステップＳ１０４において、レシパが過去にレポータの投稿レシピに対してレポート投稿していなければ、レシピサイトサーバ３１はステップＳ１０５に進み、特定した回数情報に基づきレシパとレポータとの間の親密度を計算する。本例では、ステップＳ１０３で特定したレポート承認回数を該親密度として扱う。このため、ステップＳ１０５の計算処理は不要とすることができる。
そして、ステップＳ１０５に続くステップＳ１０６でレシピサイトサーバ３１は、親密度が前述した第一親密閾値以上であるか否かを判定し、親密度が第一親密閾値以上であれば、ステップＳ１１１に進んで親密レポータ登録処理を行う。すなわち、ステップＳ１０２で特定したレポータとレシパとについて、該レポータのユーザＩＤを該レシパのユーザＩＤに対応づけて親密情報ＤＢ３５に記憶させる処理を行う。
また、ステップＳ１０６で親密度が第一親密閾値以上でないと判定した場合、レシピサイトサーバ３１はステップＳ１１１の処理をパスして図７に示す処理を終える。
【０１０２】
一方、ステップＳ１０４において、レシパが過去にレポータの投稿レシピに対してレポート投稿していると判定した場合、レシピサイトサーバ３１はステップＳ１０７に進み、レポータによる投稿レシピに対するレシパのレポート投稿回数を特定する。該レポート投稿回数は、ユーザＤＢ３２に記憶されているレポート投稿履歴情報、及びレシピ投稿履歴情報に基づき特定することができる。
【０１０３】
ステップＳ１０７に続くステップＳ１０８でレシピサイトサーバ３１は、レポータによるレシパへのレポート承認回数を特定する。すなわち、レポータによる投稿レシピに対するレシパの投稿レポートのうち、レポータにより承認された投稿レポートの数を特定する。
【０１０４】
ステップＳ１０８に続くステップＳ１０９でレシピサイトサーバ３１は、特定した回数情報、すなわちステップＳ１０３、Ｓ１０７、及びＳ１０８で特定した回数情報に基づき、レシパとレポータとの間の親密度を計算する。具体的に、本例ではそれら特定した回数の値の合計値を該親密度として計算する。
【０１０５】
ステップＳ１０９に続くステップＳ１１０でレシピサイトサーバ３１は、親密度が前述した第二親密閾値以上であるか否かを判定し、親密度が第二親密閾値以上であれば、ステップＳ１１１に進んで親密レポータ登録処理を行う。
ステップＳ１１１の処理を実行したことに応じ、レシピサイトサーバ３１は図７に示す処理を終える。
【０１０６】
一方、ステップＳ１１０において親密度が第二親密閾値以上でなければ、レシピサイトサーバ３１はステップＳ１１１の処理をパスして図７に示す処理を終える。
【０１０７】
なお、ステップＳ１０９の計算処理について、親密度の計算手法は上記の手法に限定されるものではない。
例えば、ステップＳ１０７で特定したレポート投稿回数に対し、ステップＳ１０８で特定した承認回数に応じた数値を加算又は乗算した値を求め、該値を、ステップＳ１０３で特定したレポート承認回数に対して加算した値を親密度として求める等、親密度の計算手法は多様に考えられるものである。
【０１０８】
図８は、不適レポータの判定に係る処理を示している。
本例では、不適レポータの判定に係る処理は、レポートＤＢ３４における記憶情報に基づき、例えばバッチ処理により時間軸上で繰り返し行われる。
先ず、ステップＳ２０１でレシピサイトサーバ３１は、ユーザ識別値ｕを開始値ｕＳにセットする。ユーザ識別値ｕは、処理対象とするユーザを識別するための識別値であり、開始値ｕＳは、後述する終了値ｕＥと共に、処理対象とするユーザの範囲（ユーザ数）を特定する値として設定されるものである。
【０１０９】
ステップＳ２０１に続くステップＳ２０２でレシピサイトサーバ３１は、ｕ番目ユーザによる作成レポート投稿回数がｎ以上（ｎは２以上の自然数）であるか否かを判定する。ｕ番目ユーザによる作成レポート投稿回数がｎ以上でない場合、レシピサイトサーバ３１は後述するステップＳ２０９に処理を進める。すなわち、本例では不適レポータの判定を画像間の類似度に基づき行うため、判定にあたり必要とされる複数の画像を取得不能であることが予測される場合は、以下で説明する不適レポータ判定に関する処理（Ｓ２０３乃至Ｓ２０８）がパスされるものである。
【０１１０】
ステップＳ２０２において、ｕ番目ユーザによる作成レポート投稿回数がｎ以上であった場合、レシピサイトサーバ３１はステップＳ２０３に進み、投稿先レシピが異なる作成レポートがあるか否かを判定し、投稿先レシピが異なる作成レポートがなかった場合は、ステップＳ２０９に処理を進める。
【０１１１】
一方、ステップＳ２０３において投稿先レシピが異なる作成レポートがあると判定した場合、レシピサイトサーバ３１はステップＳ２０４で各作成レポートの投稿画像を取得する。すなわち、投稿先レシピが異なる作成レポートとしての各作成レポートの投稿画像を取得する。
【０１１２】
ステップＳ２０４に続くステップＳ２０５でレシピサイトサーバ３１は、画像間の類似度を評価する。すなわち、前述したように本例では、取得した各画像について、取得した他の全ての画像との間の類似度をそれぞれ計算する。
【０１１３】
ステップＳ２０５に続くステップＳ２０６でレシピサイトサーバ３１は、同一・類似画像があるか否かを判定する。前述のように本例では、類似度が一定値以上の関係となっている画像を同一・類似画像として特定する。
同一・類似画像がなければ、レシピサイトサーバ３１はステップＳ２０９に処理を進める。つまりこの場合、ｕ番目のユーザは不適レポータと判定されない。
【０１１４】
一方、同一・類似画像があれば、レシピサイトサーバ３１はステップＳ２０７に進み、同一・類似画像の数がｍ以上（ｍは２以上の自然数）であるか否かを判定する。ここで、前述のように、同一・類似画像としては複数の組が特定され得るものであり、同一・類似画像として複数の組が特定された場合、すなわち同一・類似画像の数が複数計算された場合、ステップＳ２０７ではそれらの数のうち最大の数がｍ以上であるか否かを判定する。
同一・類似画像の数がｍ以上でなければ、レシピサイトサーバ３１はステップＳ２０９に処理を進める。
【０１１５】
同一・類似画像の数がｍ以上であれば、レシピサイトサーバ３１はステップＳ２０８に進み、ｕ番目ユーザについての不適設定処理を行う。すなわち、ｕ番目ユーザのユーザＩＤと対応づけられてユーザＤＢ３２に記憶されている不適フラグＦａをＯＮとする処理を行う。
【０１１６】
ステップＳ２０８に続くステップＳ２０９でレシピサイトサーバ３１は、ユーザ識別値ｕが終了値ｕＥ以上であるか否かを判定する。これは、上述した開始値ｕＳと終了値ｕＥとで設定された処理対象範囲内の全ユーザについて、対象処理（ステップＳ２０２乃至Ｓ２０８の処理）を完了したか否かを判定していることに相当する。
ユーザ識別値ｕが終了値ｕＥ以上でなければ、レシピサイトサーバ３１はステップＳ２１０に進んでユーザ識別値ｕを１インクリメントした上で、上述したステップＳ２０２に戻る。
一方、ユーザ識別値ｕが終了値ｕＥ以上であれば、レシピサイトサーバ３１は図８に示す処理を終える。
【０１１７】
なお、図８に示した処理は、既に不適レポータとして判定済みのユーザを処理対象から除外して行うこともできる。
【０１１８】
図９は、遅滞傾向ユーザの判定に係る処理を示している。
本例において、遅滞傾向ユーザの判定に係る処理は、前述した承認履歴情報に基づき、例えばバッチ処理により時間軸上で繰り返し行われる。
図９において、レシピサイトサーバ３１は、ステップＳ３０１でユーザ識別値ｕを開始値ｕＳにセットした上で、ステップＳ３０２においてｕ番目ユーザのレポート承認回数が複数回であるか否かを判定する。ｕ番目ユーザのレポート承認回数が複数回でなければ、レシピサイトサーバ３１は後述するステップＳ３０８に処理を進める。前述のように、本例ではレシパによる投稿レポートの承認に関して、レポート投稿から承認までに要した時間の平均値に基づき遅滞傾向ユーザの判定を行うため、レポート承認回数が複数回でなければ、以下で説明する遅滞傾向ユーザの判定のための処理（Ｓ３０３乃至Ｓ３０７）は行わない。
【０１１９】
一方、ｕ番目ユーザのレポート承認回数が複数回であれば、レシピサイトサーバ３１はステップＳ３０３に進み、各承認済レポートについて、投稿から承認までに要した時間を計算する。すなわち、承認履歴情報に基づき特定されるｕ番目ユーザの各承認済レポートについて、レポート投稿から承認までに要した時間を計算する。承認済レポートのレポート投稿日時の情報は、該承認済レポートのレポートＩＤと前述したレポート投稿履歴情報とに基づき特定することができる。
【０１２０】
ステップＳ３０３に続くステップＳ３０４でレシピサイトサーバ３１は、計算した時間の平均値を計算し、ステップＳ３０５で該平均値が所定値以上であるか否かを判定する。
該平均値が所定値以上であれば、レシピサイトサーバ３１はステップＳ３０６でｕ番目ユーザの遅滞傾向フラグＦｄをＯＮとする処理を実行してステップＳ３０８に進み、該平均値が所定値以上でなければ、レシピサイトサーバ３１はステップＳ３０７でｕ番目ユーザの遅滞傾向フラグＦｄをＯＦＦとする処理を実行しステップＳ３０８に進む。
【０１２１】
ステップＳ３０８でレシピサイトサーバ３１は、ユーザ識別値ｕが終了値ｕＥ以上であるか否かを判定し、ユーザ識別値ｕが終了値ｕＥ以上でなければ、ステップＳ３０９に進んでユーザ識別値ｕを１インクリメントした上でステップＳ３０２に戻る。
一方、ユーザ識別値ｕが終了値ｕＥ以上であれば、レシピサイトサーバ３１は図９に示す処理を終える。
【０１２２】
図１０は、承認要求に係る処理を示している。
本例では、図１０に示す処理としても、例えばバッチ処理により時間軸上で繰り返し行われる。
図１０において、レシピサイトサーバ３１はステップＳ４０１で、処理対象レシパを特定する。すなわち、前述したレシピ投稿履歴情報から特定されるレシパのうちから処理対象とする一人のレシパを特定する。
ステップＳ４０１に続くステップＳ４０２でレシピサイトサーバ３１は、未承認レポートがあるか否かを判定する。すなわち、ステップＳ４０１で特定したレシパによる投稿レシピに対する投稿レポートに、未承認レポートがあるか否かを判定する。該判定は、レポート投稿履歴情報と承認履歴情報とに基づき行うことができる。
【０１２３】
ステップＳ４０２において未承認レポートがないと判定した場合、レシピサイトサーバ３１は図１０に示す処理を終える。つまり、この場合はレシパに対して承認を要求すべきレポートは存在しないため、以下で説明する承認要求に係る処理（Ｓ４０４乃至Ｓ４１２）は実行されない。
【０１２４】
ステップＳ４０２において未承認レポートがあると判定した場合、レシピサイトサーバ３１はステップＳ４０３に進み、要承認要求レポートがあるか否かを判定する。すなわち、ステップＳ４０２で特定された未承認レポートに、不適レポート以外のレポートがあるか否かを判定する。なお、不適レポートは、不適フラグＦｉがＯＮであるユーザによって投稿された作成レポートとして特定されるものである。
ここで、処理対象のレシパによる投稿レシピを投稿先レシピとする未承認レポートのうち、不適レポートを除いた未承認レポートのことを「要承認要求レポート」と表記する。
ステップＳ４０３において要承認要求レポートがないと判定した場合、レシピサイトサーバ３１は図１０に示す処理を終える。
【０１２５】
一方、ステップＳ４０３において要承認要求レポートがあると判定した場合、レシピサイトサーバ３１はステップＳ４０４に進んで要承認要求レポートの数を特定した上で、ステップＳ４０５で最古の要承認要求レポートの投稿日時を特定する。以下、該最古の要承認要求レポートの投稿日時のことを「最古投稿日時」と表記する。
【０１２６】
ステップＳ４０５に続くステップ４０６でレシピサイトサーバ３１は、処理対象レシパは遅滞傾向ユーザか否かを判定する。すなわち、遅滞傾向フラグＦｄがＯＮであるユーザか否かを判定する。
処理対象レシパが遅滞傾向ユーザでなければ、レシピサイトサーバ３１はステップＳ４０７に進み、要承認要求レポート数が数閾値ｔｈ１以上か否かを判定し、要承認要求レポート数が数閾値ｔｈ１以上でなければ、ステップＳ４０８に進んで最古投稿日時からの経過時間が時間閾値ＴＨ１以上であるか否かを判定する。最古投稿日時からの経過時間が時間閾値ＴＨ１以上でなかった場合、レシピサイトサーバ３１は図１０に示す処理を終える。つまり、この場合は前述した（条件１）（条件２）の何れも成立していないため、承認要求は行われない。
【０１２７】
ステップＳ４０７において要承認要求レポート数が数閾値ｔｈ１以上であった場合、又はステップＳ４０８で最古投稿日時からの経過時間が時間閾値ＴＨ１以上であった場合、レシピサイトサーバ３１はステップＳ４１１に進み、要承認要求レポートについての承認要求処理を行う。すなわち、要承認要求レポートについての承認を要求する承認要求メールを処理対象レシパとしてのユーザに対して送信する処理を行う。
この際、承認要求メールとしては、上述したチェックボックスｃｂ１を設けた形式による電子メールを生成する。また、要承認要求レポートに、処理対象レシパにとっての非親密レポータからの投稿レポートが含まれている場合には、該当するレポータについての前述した登録チェックボックスｃｂ２を設けた形式による電子メールを生成する。
【０１２８】
ステップＳ４１１の承認要求処理を実行したことに応じ、レシピサイトサーバ３１はステップＳ４１２で承認要求日時の記憶処理を実行する。すなわち、ステップＳ４１１の処理で承認が要求された作成レポートのうち、承認の要求が初回であった作成レポートを対象として、該作成レポートのレポートＩＤに該作成レポートの承認要求日時（例えばステップＳ４１１の要求処理の実行日時）を対応づけてレポートＤＢ３４に記憶させる処理を行う。
ステップＳ４１２の処理を実行したことに応じ、レシピサイトサーバ３１は図１０に示す処理を終える。
【０１２９】
また、上述したステップＳ４０６において、処理対象レシパは遅滞傾向ユーザであると判定した場合、レシピサイトサーバ３１はステップＳ４０９に進み、要承認要求レポート数が数閾値ｔｈ２以上か否かを判定し、要承認要求レポート数が数閾値ｔｈ２以上でなければ、ステップＳ４１０に進んで最古投稿日時からの経過時間が時間閾値ＴＨ２以上であるか否かを判定する。最古投稿日時からの経過時間が時間閾値ＴＨ２以上でなかった場合、レシピサイトサーバ３１は図１０に示す処理を終える。
ここで、数閾値ｔｈ２は、数閾値ｔｈ１よりも小さな値であり、時間閾値ＴＨ２は時間閾値ＴＨ１よりも小さな値である。これにより、処理対象ユーザが遅滞傾向ユーザである場合は、通常よりも早いタイミングで承認要求が行われるようになる。
【０１３０】
ステップＳ４０９において要承認要求レポート数が数閾値ｔｈ２以上であった場合、又はステップＳ４１０で最古投稿日時からの経過時間が時間閾値ＴＨ２以上であった場合、レシピサイトサーバ３１はステップＳ４１１の承認要求処理を実行し、続くステップＳ４１２の承認要求日時の記憶処理を実行した上で、図１０に示す処理を終える。
【０１３１】
図１１は、自動承認に係る処理を示している。
本例では、図１１に示す処理としても、例えばバッチ処理により時間軸上で繰り返し行われる。
図１１において、レシピサイトサーバ３１はステップＳ５０１で、処理対象レシパを特定する処理を行い、続くステップＳ５０２で未承認レポートがあるか否かを判定する。ステップＳ５０１、Ｓ５０２の処理は、それぞれ図１０で説明したステップＳ４０１、Ｓ４０２と同様の処理である。
【０１３２】
ステップＳ５０２において未承認レポートがないと判定した場合、レシピサイトサーバ３１は図１１に示す処理を終える。つまり、この場合は自動承認すべきレポートは存在しないため、以下で説明する自動承認に係る処理（Ｓ５０４乃至Ｓ５０９）は実行されない。
【０１３３】
ステップＳ５０２において未承認レポートがあると判定した場合、レシピサイトサーバ３１はステップＳ５０３に進み、要承認要求レポートがあるか否かを判定し、要承認要求レポートがないと判定した場合は図１１に示す処理を終え、要承認要求レポートがあると判定した場合はステップＳ５０４に処理を進める。
【０１３４】
ステップＳ５０４でレシピサイトサーバ３１は、要承認要求レポートの数（以下「Ｄ」と表記）を特定し、続くステップＳ５０５で処理対象レポート識別値ｄを初期値「０」にセットする。処理対象レポート識別値ｄは、要承認要求レポートのうち処理対象とする要承認要求レポートを識別するための値である。
【０１３５】
ステップＳ５０５に続くステップＳ５０６でレシピサイトサーバ３１は、ｄ番目レポートは親密レポータによる投稿レポートであるか否かを判定する。該判定は、ｄ番目レポートのレポートＩＤとレポートＤＢ３４の記憶情報と処理対象レシパのユーザＩＤと親密情報ＤＢ５５の記憶情報とに基づき行うことができる。具体的に、該判定は、ｄ番目レポートのレポートＩＤとレポートＤＢ３４の記憶情報とに基づきｄ番目レポートの投稿レポータのユーザＩＤを特定し、該特定したユーザＩＤが、親密情報ＤＢ５５の記憶情報において処理対象レシパのユーザＩＤと対応づけられているか否かを判定することで行う。
【０１３６】
ステップＳ５０６において、ｄ番目レポートは親密レポータによる投稿レポートでないと判定した場合、レシピサイトサーバ３１は後述するステップＳ５１０に処理を進める。つまりこの場合、ｄ番目レポートについての自動承認は行われない。
【０１３７】
一方、ステップＳ５０６においてｄ番目レポートは親密レポータによる投稿レポートであると判定した場合、レシピサイトサーバ３１はステップＳ５０７に進み、ｄ番目レポートについての承認要求日時を特定する。具体的には、先のステップＳ４１２の処理によりレポートＤＢ３４に記憶された承認要求日時のうち、ｄ番目レポートのレポートＩＤと対応づけられている承認要求日時を特定する。
【０１３８】
ステップＳ５０７に続くステップＳ５０８でレシピサイトサーバ３１は、特定した承認要求日時からの経過時間が一定時間以上であるか否かを判定し、該経過時間が一定時間以上でなければステップＳ５１０に処理を進め、該経過時間が一定時間以上であれば、ステップＳ５０９に進んでｄ番目レポートについての承認処理を行う。すなわち、レポートＤＢ３４においてｄ番目レポートのレポートＩＤと対応づけられている承認フラグＦａをＯＮとする処理を行う。
【０１３９】
ステップＳ５０８に続くステップＳ５０９でレシピサイトサーバ３１は、処理対象レポート識別値ｄが上述した「Ｄ」以上であるか否かを判定し、処理対象レポート識別値ｄが上述した「Ｄ」以上でなければ、ステップＳ５１１に進んで処理対象レポート識別値ｄを１インクリメントした上で、ステップＳ５０５に戻る。
一方、処理対象レポート識別値ｄが上述した「Ｄ」以上であれば、レシピサイトサーバ３１は図１１に示す処理を終える。
【０１４０】
図１１に示す処理が繰り返し実行されることで、各レシパに対する要承認要求レポート（不適レポート以外の未承認レポート）のうち、親密レポータからの投稿レポートについては、承認要求日時からの経過時間に応じて自動承認が行われる。
【０１４１】
なお、上記では、親密度の評価として、ユーザＤＢ３２に記憶された行動履歴情報に基づく評価を行う例を挙げたが、親密度は、例えばレシピサイトとの間でユーザＩＤ（又はユーザ氏名等のユーザを識別可能な情報）が連携されたＳＮＳ（Social Networking Service）におけるユーザ間の友人関係情報（友人登録された関係にあるユーザを管理する情報）を用いて評価することもできる。或いは、レシピサイトサーバ３１が例えばユーザ端末４等の所定の情報処理装置に記憶されている連絡帳（例えば電話帳や電子メールのアドレス帳）の情報にアクセス可能とされる場合には、該連絡帳の情報を用いて親密度を評価することもできる。例えば、レシパとしてのユーザが使用するユーザ端末４に記憶された連絡帳情報において対象とするレポータの氏名情報が登録されているか否かの情報を用いて、親密度を評価する等である。
【０１４２】
また、上記では、不適レポータの判定にあたって行う投稿レポートの情報信頼度の評価として、投稿レポートに用いられる画像の類似度に基づく評価を行う例を挙げたが、該情報信頼度の評価としては、画像の類似度に基づく評価に限定されず、例えば投稿レポート間での文字の一致度合いに基づく評価を行うこともできる。例えば、文字の一致度合いが一定度合い以上の関係となっている作成レポートの数が多ければ、対象とするレポータは同一コメントを使い回している可能性が高いと推定され、該レポータによる投稿レポートは情報信頼度が低いと評価できる。或いは、対象とするレポータが対象とするレシピを閲覧（該レシピの閲覧が複数回の場合は最後の閲覧）してから該レシピに対する作成レポートを投稿するまでに要した時間の長さに基づく評価を行うこともできる。該時間が短い投稿レポートが多いほど、対象とするレポータによる投稿レポートの情報信頼度は低いと評価できる。
【０１４３】
さらに、上記では、承認要求のタイミング調整にあたり行うレポート承認行動の分析として、レシパの承認済みレポートについての承認要求から承認を行うまでに要した時間を分析する例を挙げたが、該分析としては、過去に承認要求が行われた作成レポートの総数のうち未承認のまま放置されている作成レポートの数が占める割合を分析する等、他の手法による分析を行うこともできる。
【０１４４】
また、上記では、承認要求を電子メールにより行う場合を例示したが、承認要求は、レシピサイトにおける特定のウェブページ上での要求、又はユーザ端末４へのプッシュ通知による要求等として行うこともできる。
【０１４５】
また、上記では、レシパに対する承認要求をバッチ処理により行う例を挙げたが、レシパに対する承認要求は、該レシパによる投稿レシピに対するレポート投稿が行われるごとに行うこともできる。
この場合、不適レポータの判定処理としても、該レシパによる投稿レシピに対するレポート投稿が行われるごとに行うことができる。
【０１４６】
［1-5．第１の実施の形態のまとめ］
上記のように第１の実施の形態の情報処理装置（レシピサイトサーバ３１）は、レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、レシパ、レポータそれぞれに紐付く情報に基づいて評価する親密度評価部（親密度評価処理部Ｆ１）を備える。
また、親密度が一定度以上のレポータである親密レポータがレポートを投稿した場合は、レシパに当該レポートについての承認を要求した後、レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、親密度が一定度以上でないレポータである非親密レポータがレポートを投稿した場合は、レシパに当該レポートについての承認を要求する一方で、時間経過に応じたレポート承認処理を行わない承認制御部（承認制御処理部Ｆ３）と、を備えている。
【０１４７】
このような第１の実施の形態の情報処理装置によると、親密レポータの投稿レポートは時間経過に応じて自動承認されるため、それらのレポートについてレシパの承認の手間が省かれる。また、自動承認を行っていることで、レポートの掲載数の低下抑制を図ることが可能とされる。
また、第１の実施の形態では、非親密レポータによるレポートは自動承認の対象外とされており、レシパによる手動承認が要求される。このため、掲載レポートの質悪化の抑制が図られる。
さらに、上記のように非親密レポータによるレポートにレシパの手動承認を要求していることは、レシパに非親密レポータとのコミュニケーション機会を与えていることになるため、両者のコミュニケーション促進を図ることが可能とされる。そして、このようにコミュニケーション促進が図られることは、レシパと非親密レポータとの間の親密度向上に寄与し、次回に非親密レポータからレポート投稿があった際に当該レポートが自動承認される可能性が高まる。自動承認される可能性が高まることは、レシパのレポート承認に係る負担抑制に寄与するものである。
【０１４８】
上記のように第１の実施の形態によれば、レシパのレポート承認に係る負担を抑えながら、レポート掲載ページの質悪化の抑制とレポート掲載数の低下抑制との両立を図りつつ、レシパとレポータとの間のコミュニケーション促進を図ることができる。
【０１４９】
また、第１の実施の形態の情報処理装置においては、レポータが過去に投稿したレポートについての情報信頼度を評価した結果に基づき、レポータが不適レポータであるか否かを判定する不適レポータ判定部（不適レポータ判定処理部Ｆ２）を備え、承認制御部は、未承認の前記レポートについてレシパに承認を要求する前に、当該レポートが不適レポータにより投稿されたレポートである不適レポートか否かを判定し、不適レポートであると判定した場合は当該レポートについての承認を要求しない。
【０１５０】
これにより、レシパが未承認のレポートのうちシステム側で事前に不適と判定されたレポータのレポートは承認が要求されない。このため、当該レポートについてレシパによる承認の手間が省かれる。
従って、レシパのレポート承認に係る負担抑制効果を高めることができる。
【０１５１】
さらに、第１の実施の形態の情報処理装置においては、不適レポータ判定部は、不適レポータであるか否かを、レポータが同一又は類似画像を用いたレポートを複数のレシピに対して投稿しているか否かに基づき判定している。
【０１５２】
これにより、レポートについての情報信頼度の評価として、レシピに対するレポートに適した評価を行うことが可能となり、不適レポータの判定精度の向上を図ることができる。
【０１５３】
さらにまた、第１の実施の形態の情報処理装置においては、親密度評価部は、レシパによるレポータに対する過去のレポート承認回数に基づき親密度を評価している。
【０１５４】
レシパによるレポータに対する過去のレポート承認回数は、両者の間のコミュニケーション頻度を推し量る指標として機能する。従って、両者間の親密度を適切に評価することができ、親密の確度が比較的高いレポータを自動承認することができる。
また、投稿レポートが自動承認されなかったレポータは、前記レシパへのレポート投稿を繰り返すうちに、その投稿レポートが自動承認されるように図られる。換言すれば、レシパは、同一レポータに対してレポート承認を繰り返すうち該レポータに対するレポート承認を行う手間が省かれるようになるものであり、この点においてレシパの承認に係る負担抑制が図られる。
【０１５５】
また、第１の実施の形態の情報処理装置においては、親密度評価部は、レポータによる投稿レシピに対するレシパのレポート投稿回数に基づき親密度を評価している。
【０１５６】
レポータによる投稿レシピに対するレシパのレポート投稿回数としても、両者の間のコミュニケーション頻度を推し量る指標として機能する。
従って、両者間の親密度を適切に評価することができ、親密の確度が比較的高いレポータを自動承認することができる。
【０１５７】
さらに、第１の実施の形態の情報処理装置においては、親密度評価部は、レポータによる投稿レシピに対するレシパの投稿レポートについての承認回数に基づき親密度を評価している。
【０１５８】
これにより、レシパとレポータとの間の親密度がより適切に評価される。
従って、親密の確度がさらに高いレポータを自動承認することができる。
【０１５９】
さらにまた、第１の実施の形態の情報処理装置においては、承認制御部は、レシパの過去におけるレポート承認行動を分析した結果に基づき、承認を要求するタイミングを調整している。
【０１６０】
これにより、例えばレポートへの承認が遅滞傾向にあるレシパには早めに承認を要求する等、レシパによるレポート承認行動の特性に応じた適切なタイミングにより承認要求を行うことが可能とされる。
従って、承認が滞ることに伴いレシピサイトでのコミュニケーション機会が喪失されてしまう可能性の低減を図ることができる。
【０１６１】
また、第１の実施の形態の情報処理装置においては、承認制御部は、レシパの投稿レシピに対する投稿レポートとして複数の未承認レポートがある場合は、レシパに対する承認の要求として、個々の未承認レポートに対する承認指示操作が可能な形式による要求を行っている。
【０１６２】
これにより、レシパによるレポート承認の容易性が増す。
従って、レポート掲載数低下の抑制効果を高めることができる。また、レシパと非親密レポータとの間のコミュニケーション促進を図ることができる。
【０１６３】
さらに、第１の実施の形態の情報処理装置においては、承認制御部は、レシパに対する承認の要求としてレポータの親密レポータへの登録指示操作が可能な形式による要求を行っている。
【０１６４】
これにより、レシパは非親密レポータを手動により親密レポータに登録することが可能とされる。
十分な親密性を感じるか否かはレシパ個人の性格やレポータとのコミュニケーション内容等の条件で異なり得るものであり、コミュニケーションが僅かであっても十分な親密性が築かれるケースも想定され得る。このため、親密レポータの登録として、親密度に基づく自動登録のみでなく手動登録が可能とされることで、自動承認の対象者数の増加が見込まれる。
従って、ユーザのレポート承認に係る手間の抑制効果を高めることができる。
【０１６５】
＜２．第２の実施の形態＞
［2-1．第２の実施の形態としての承認制御手法］
続いて、第２の実施の形態について説明する。
第２の実施の形態は、投稿レポートの掲載を、レシパによる承認、及びレシパからの返信入力を条件として行うものである。
なお、第２の実施の形態において、ネットワークシステム１の構成は、レシピサイトサーバ３１に代えてレシピサイトサーバ３１Ａが設けられた点が異なり、他の構成要素については第１の実施の形態の場合と同様である。
第２の実施の形態において、既に第１の実施の形態で説明済みとなった部分については、特に断りがない限り、同一符号や同一ステップ番号を付して説明を省略する。
【０１６６】
図１２の機能ブロック図を参照して、レシピサイトサーバ３１Ａが実現する第２の実施の形態としての承認制御に係る各種機能について説明する。
レシピサイトサーバ３１Ａは、レシピサイトサーバ３１と比較して、承認制御処理部Ｆ３に代えて承認制御処理部Ｆ３Ａを有する点が異なる。
【０１６７】
承認制御処理部Ｆ３Ａは、レシパに対する承認の要求として、未承認レポートに対する返信入力が可能な形式による要求を行う。この際、レシパの投稿レシピに対する投稿レポートに複数の未承認レポートがあれば、承認制御処理部Ｆ３Ａは承認の要求として、個々の未承認レポートに対する返信入力が可能な形式による要求を行う。
【０１６８】
図１３を参照して、第２の実施の形態における承認要求について説明する。
図１３では、承認制御処理部Ｆ３Ａがレシパに送信する送信要求メールとして、承認を要求すべき未承認レポートが複数であった場合に対応した送信要求メールの例を示している。
この場合の送信要求メールは、図６に示した送信要求メールと比較して、未承認レポートごとにコメント入力欄ｒｐが設けられた点が異なる。コメント入力欄ｒｐは、対応する未承認レポートについての返信コメントを入力するための欄であり、レシパとしてのユーザは該コメント入力欄ｒｐにテキスト入力を行うことができる。
ユーザは、送信要求メールに設けられた送信ボタンＢ１を操作することで、コメント入力欄ｒｐに入力したテキスト情報を、対応する未承認レポートに対する返信情報としてレシピサイトサーバ３１Ａに返信することができる。
【０１６９】
上記のように、承認の要求として、個々の未承認レポートに対する返信入力が可能な形式による要求を行うことで、投稿レポートに対する返信入力の容易性が増し、レポート掲載数低下の抑制効果を高めることができる。また、レシパと非親密レポータとの間のコミュニケーション促進も図られる。
【０１７０】
また、承認制御処理部Ｆ３Ａは、承認され且つレシパからの返信入力が行われたレポートであることを条件に、レポートがレシピサイトに掲載されるように制御を行う。
第２の実施の形態のレシピサイト運営システム３では、投稿されレポートＤＢ３４に登録された各作成レポートのレポートＩＤには、前述した承認フラグＦａと共に返信フラグＦｒが対応づけられる。返信フラグＦｒは、ＯＮ（例えば「１」）が返信済、ＯＦＦ（例えば「０」）が未返信を表す。本例では、返信フラグＦｒはレポートＤＢ３４においてレポートＩＤごとに記憶される。
【０１７１】
ここで、第２の実施の形態において、レシピサイトサーバ３１Ａは、対象とするレシピに対する投稿レポートをレシピサイトに掲載するにあたっては、それらの投稿レポートのうち、承認フラグＦａと返信フラグＦｒの双方がＯＮである投稿レポートのみを掲載する。
この前提の下で、承認制御処理部Ｆ３Ａは、第１の実施の形態における承認制御処理部Ｆ３と同様に、レシパの操作入力に応じた承認処理、及び親密レポータの投稿レポートについての自動的な承認処理を行って、承認フラグＦａをＯＮとする。
さらに、承認制御処理部Ｆ３Ａは、例えば上述したような承認要求メールにおけるコメント入力欄ｒｐに返信情報が入力され、該入力された返信情報を受信したことに応じて、該コメント入力欄ｒｐに対応する未承認レポートについての返信フラグＦｒをＯＮとする処理を行う。
これにより、承認され且つレシパからの返信入力が行われたレポートがレシピサイトに掲載されるようになる。
【０１７２】
［2-2．処理手順］
上記により説明した第２の実施の形態としての承認制御手法を実現するための処理について説明する。
レシピサイトサーバ３１Ａとしても、レシピサイトサーバ３１と同様、先の図７乃至図１１に示した処理と同様の処理を実行する。
但しこの場合、図１０に示したステップＳ４１１の承認要求処理では、先の図１３に示したように未承認レポート（本例では要承認要求レポート）に対し返信コメントを入力するためのコメント入力欄ｒｐを設けた形式による送信要求メールを生成して処理対象レシパとしてのユーザに送信する処理を行う。この際、処理対象レシパの投稿レシピに対する投稿レポートに複数の要承認要求レポートがあれば、承認制御処理部Ｆ３Ａは個々の要承認要求レポートに対しコメント入力欄ｒｐを設けた形式による承認要求メールを生成・送信する。
【０１７３】
第２の実施の形態におけるレシピサイトサーバ３１Ａは、図１４に示す処理を実行する。
なお、図１４に示す処理は、レシピサイトサーバ３１ＡにおけるＣＰＵ１０１が例えばレシピサイトサーバ３１ＡにおけるＲＯＭ１０２や記憶部１０８等の所定の記憶装置に記憶されたプログラムに基づき実行する。
【０１７４】
図１４において、レシピサイトサーバ３１ＡはステップＳ６０１で、投稿レポートへの返信があったか否かを判定する。すなわち、ステップＳ４１１で送信した送信要求メールに対する返信情報、具体的には該送信要求メールにおける送信ボタンＢ１が操作されることに伴い受信した該送信要求メールへの入力情報に、コメント入力欄ｒｐに対する入力情報が含まれているか否かを判定する。
【０１７５】
ステップＳ６０１において投稿レポートへの返信がなかったと判定した場合、レシピサイトサーバ３１Ａは図１４に示す処理を終える。
一方、ステップＳ６０１において投稿レポートへの返信があったと判定した場合、レシピサイトサーバ３１ＡはステップＳ６０２に進み、該当するレポートについての返信設定処理を行う。すなわち、ステップＳ６０１で入力情報の受信が確認されたコメント入力欄ｒｐに対応する作成レポートを特定し、該特定した作成レポートのレポートＩＤと対応づけられてレポートＤＢ３４に記憶されている返信フラグＦｒをＯＮとする処理を行う。
ステップＳ６０２の処理を実行したことに応じ、レシピサイトサーバ３１Ａは図１４に示す処理を終える。
【０１７６】
なお、上記では、投稿レポートに対するレシパの返信入力として、テキスト入力を受け付ける例を示したが、該返信入力としては、返信内容が定型の内容とされた情報である定型返信情報の入力を受け付けることもできる。
定型返信情報としては、例えば定型文や、スタンプ等の画像による情報を挙げることができる。この場合における返信入力の受け付けとしては、レシパに提示した複数種類の定型返信情報について、レシパからの任意の定型返信情報の選択入力を受け付ける等の形態により行うことが可能である。
【０１７７】
上記のような定型返信情報による返信入力が可能とされることで、レシパは、投稿レポートへの返信入力を例えば定型文やスタンプ等の入力で済ませることが可能とされる。
従って、投稿レポートをサイトに掲載させるにあたってのレシパの負担抑制を図ることができる。
【０１７８】
［2-3．第２の実施の形態のまとめ］
上記のように第２の実施の形態の情報処理装置（レシピサイトサーバ３１Ａ）においては、承認制御部（承認制御処理部Ｆ３Ａ）は、承認され且つレシパからの返信入力が行われたレポートであることを条件に、レポートがウェブサイトに掲載されるように制御を行っている。
【０１７９】
これにより、投稿レポートを掲載させるにあたり、レシパはレポートに対する返信という形式でのコミュニケーションをレポータに対してとることが必須とされる。
従って、レポート掲載ページがレシパとレポータとの間のコミュニケーションの場としてより活性化することに寄与できる。
【０１８０】
また、第２の実施の形態の情報処理装置においては、承認制御部は、レシパの投稿レシピに対する投稿レポートに複数の未承認レポートがある場合は、レシパに対する承認の要求として、個々の未承認レポートに対する返信入力が可能な形式による要求を行っている。
【０１８１】
これにより、投稿レポートに対する返信入力の容易性が増す。
従って、レポート掲載数低下の抑制効果を高めることができる。また、レシパと非親密レポータとの間のコミュニケーション促進を図ることができる。
【０１８２】
さらに、第２の実施の形態の情報処理装置においては、承認制御部は、返信入力として、返信内容が定型の内容とされた情報である定型返信情報の入力を受け付けている。
【０１８３】
これによりレシパは、投稿レポートへの返信入力を例えば定型文やスタンプ等の入力で済ませることが可能とされ、投稿レポートをサイトに掲載させるにあたってのレシパの負担抑制を図ることができる。
【０１８４】
＜３．プログラム及び記憶媒体＞
以上、本発明に係る情報処理装置の実施の形態としてのレシピサイトサーバ（３１又は３１Ａ）を説明してきたが、実施の形態のプログラムは、該レシピサイトサーバの処理を情報処理装置（ＣＰＵ等）に実行させるプログラムである。
【０１８５】
実施の形態のプログラムは、レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価機能と、前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータがレポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御機能と、を情報処理装置に実現させる。
すなわち、このプログラムは、例えばレシピサイトサーバ３１等の情報処理装置に図７乃至図１１等により説明した処理を実行させるプログラムに相当する。
【０１８６】
このようなプログラムにより、上述したレシピサイトサーバ３１（又は３１Ａ）としての情報処理装置を実現できる。
そして、このようなプログラムはコンピュータ装置等の機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭ等に予め記憶しておくことができる。或いはまた、半導体メモリ、メモリーカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的あるいは永続的に格納（記憶）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。
【０１８７】
＜４．変形例＞
本発明は上記により説明した具体例に限定されず、各種の変形例が考えられる。
例えば、親密レポータの登録に係る制御機能として、レシパによる操作に応じ親密レポータの登録解除を行う機能が付加されてもよい。これにより、誤操作や一時の気の迷い等により登録されてしまった親密レポータの投稿レポートについて、レシパの意に反した自動承認が行われてしまうことの防止を図ることができる。
【符号の説明】
【０１８８】
１  ネットワークシステム、２  ネットワーク、３、３Ａ  レシピサイト運営システム、３１、３１Ａ  レシピサイトサーバ、３２  ユーザＤＢ（データベース）、３３  レシピＤＢ、３４  レポートＤＢ、３５  親密情報ＤＢ、４  ユーザ端末、１０１  ＣＰＵ、Ｆ１  親密度評価処理部、Ｆ２  不適レポータ判定処理部、Ｆ３、Ｆ３Ａ  承認制御処理部、Ａｒ１  レシピ名掲載領域、Ａｒ２  料理写真掲載領域、Ａｒ３  材料・分量掲載領域、Ａｒ４  調理手順掲載領域、Ａｒ５  レポート掲載領域、ｃｂ１  承認チェックボックス、ｃｂ２  登録チェックボックス、Ｂ１  送信ボタン、ｒｐ  コメント入力欄
【図１】
2018034000.tif 000003
【図２】
2018034000.tif 000004
【図３】
2018034000.tif 000005
【図４】
2018034000.tif 000006
【図５】
2018034000.tif 000007
【図６】
2018034000.tif 000008
【図７】
2018034000.tif 000009
【図８】
2018034000.tif 000010
【図９】
2018034000.tif 000011
【図１０】
2018034000.tif 000012
【図１１】
2018034000.tif 000013
【図１２】
2018034000.tif 000014
【図１３】
2018034000.tif 000015
【図１４】
2018034000.tif 000016
【手続補正書】
【提出日】平成29年10月2日(2017.10.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価部と、
前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御部と、を備える
情報処理装置。
【請求項２】
前記レポータが過去に投稿した前記レポートについての情報信頼度を評価した結果に基づき、前記レポータが不適レポータであるか否かを判定する不適レポータ判定部を備え、
前記承認制御部は、
未承認の前記レポートについて前記レシパに承認を要求する前に、当該レポートが前記不適レポータにより投稿されたレポートである不適レポートか否かを判定し、前記不適レポートであると判定した場合は当該レポートについての承認を要求しない
請求項１に記載の情報処理装置。
【請求項３】
前記不適レポータ判定部は、
前記不適レポータであるか否かを、前記レポータが同一又は類似画像を用いた前記レポートを複数のレシピに対して投稿しているか否かに基づき判定する
請求項１に記載の情報処理装置。
【請求項４】
前記親密度評価部は、
前記レシパによる前記レポータに対する過去のレポート承認回数に基づき前記親密度を評価する
請求項１に記載の情報処理装置。
【請求項５】
前記親密度評価部は、
前記レポータによる投稿レシピに対する前記レシパのレポート投稿回数に基づき前記親密度を評価する
請求項１に記載の情報処理装置。
【請求項６】
前記親密度評価部は、
前記レポータによる投稿レシピに対する前記レシパの投稿レポートについての承認回数に基づき前記親密度を評価する
請求項５に記載の情報処理装置。
【請求項７】
前記承認制御部は、
前記レシパの過去におけるレポート承認行動を分析した結果に基づき、前記承認を要求するタイミングを調整する
請求項１に記載の情報処理装置。
【請求項８】
前記承認制御部は、
前記レシパの投稿レシピに対する投稿レポートとして複数の未承認レポートがある場合は、前記レシパに対する承認の要求として、個々の未承認レポートに対する承認指示操作が可能な形式による要求を行う
請求項１に記載の情報処理装置。
【請求項９】
前記承認制御部は、
前記レシパに対する承認の要求として前記レポータの前記親密レポータへの登録指示操作が可能な形式による要求を行う
請求項１に記載の情報処理装置。
【請求項１０】
前記承認制御部は、
承認され且つ前記レシパからの返信入力が行われたレポートであることを条件に、前記レポートが前記ウェブサイトに掲載されるように制御を行う
請求項１に記載の情報処理装置。
【請求項１１】
前記承認制御部は、
前記レシパの投稿レシピに対する投稿レポートに複数の未承認レポートがある場合は、前記レシパに対する承認の要求として、個々の未承認レポートに対する前記返信入力が可能な形式による要求を行う
請求項１０に記載の情報処理装置。
【請求項１２】
前記承認制御部は、
前記返信入力として、返信内容が定型の内容とされた情報である定型返信情報の入力を受け付ける
請求項１０に記載の情報処理装置。
【請求項１３】
レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価ステップと、
前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御ステップと、を情報処理装置が実行する
情報処理方法。
【請求項１４】
情報処理装置が読み取り可能なプログラムであって、
レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価機能と、
前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御機能と、を情報処理装置に実現させる
プログラム。
【請求項１５】
レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価機能と、
前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御機能と、を情報処理装置に実現させる情報処理装置が読み取り可能なプログラムを記憶した
記憶媒体。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
本発明に係る情報処理装置は、レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価部と、前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御部と、を備えるものである。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】変更
【補正の内容】
【００１２】
上記した本発明に係る情報処理装置においては、前記レポータが過去に投稿したレポートについての情報信頼度を評価した結果に基づき、前記レポータが不適レポータであるか否かを判定する不適レポータ判定部を備え、前記承認制御部は、未承認の前記レポートについて前記レシパに承認を要求する前に、当該レポートが前記不適レポータにより投稿された前記レポートである不適レポートか否かを判定し、前記不適レポートであると判定した場合は当該レポートについての承認を要求しないことが可能である。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１４
【補正方法】変更
【補正の内容】
【００１４】
上記した本発明に係る情報処理装置においては、前記不適レポータ判定部は、前記不適レポータであるか否かを、前記レポータが同一又は類似画像を用いた前記レポートを複数のレシピに対して投稿しているか否かに基づき判定することが可能である。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００３４
【補正方法】変更
【補正の内容】
【００３４】
また、本発明に係る情報処理方法は、レシピを掲載するウェブサイトにレシピを投稿したユーザであるレシパと、前記レシパによる投稿レシピに対するレポートを投稿したユーザであるレポータとの親密度を、前記レシパ、前記レポータそれぞれに紐付く情報に基づいて評価する親密度評価ステップと、前記親密度が一定度以上のレポータである親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求した後、前記レシパからの手動による承認がなくても時間経過に応じたレポート承認処理を行い、前記親密度が前記一定度以上でないレポータである非親密レポータが前記レポートを投稿した場合は、前記レシパに当該レポートについての承認を要求する一方で、前記時間経過に応じたレポート承認処理を行わない承認制御ステップと、を情報処理装置が実行する情報処理方法である。
このような情報処理方法によっても、上記した本発明に係る情報処理装置と同様の作用が得られる。
【国際調査報告】
2018034000.tif 000017
2018034000.tif 000018
2018034000.tif 000019
2018034000.tif 000020