JP7843435B1 - 情報処理装置、及びプログラム - Google Patents

Abstract

【課題】広告規制に内容が準拠した広告をより確実に自動生成するための技術を提供する。
【解決手段】サービス提供会社１は、サービス提供用にサーバ１Ａを設置している。このサーバ１Ａは、顧客である事業者２についての事業者情報を、例えばサーバ２Ａ、及び検索・オンライン地図サービスサイト４から取得する。事業者２は、自身が事業を行う事業分野、広告を自動生成するタイミング、広告の掲載先等を設定情報により指定する。サーバ１Ａは、設定情報を参照し、取得した事業者情報を用いて、指定されたタイミングで、指定された事業分野で制定された広告規制に内容が準拠した広告を自動生成する。自動生成した広告は、事業者２の承認を得た後、設定情報で指定された掲載先に掲載させる。
【選択図】図１

Description

本発明は、情報処理装置、及びプログラムに関する。

製品を製造、若しくは販売、或いはサービスを提供する事業者にとって、広告は、顧客を獲得し、売り上げを向上させるための有効な手段である。近年のネットワークの普及に伴い、Ｗｅｂサイトで閲覧可能な広告（デジタル広告）の重要性が高くなっている。このような広告には、製品、若しくはサービスを紹介する等のＷｅｂページ（オンラインページ）へのリンクが貼られているのが普通である。現在では、そのような広告を自動的に生成させることも行われている（例えば特許文献１参照）。

特開２０１１－６５６５８号公報

事業者が事業を行う事業分野のうちには、広告についての規制、或いはガイドライン（以降、これらを「広告規制」と総称する）が設けられているものがある。例えば医療分野では、医療広告ガイドライン、医薬品医療機器等法が制定されている。そのため、例えば医療機関は、医療広告ガイドラインに準拠した内容の広告を掲載させなければならない。それにより、体験談、症例写真、過度な強調表現等は広告に使用できない。
同様に、化粧品・健康食品分野では、薬機法、健康増進法が、金融・投資商品分野では、金融商品取引法、金融庁ガイドラインが、不動産分野では、宅地建物取引業法、不動産公正取引協議会規約がそれぞれ制定されている。それにより、それらの事業分野でも、制定された広告規制に準拠した内容の広告を掲載させなければならない。このような広告規制は、上記以外の事業分野にも存在する。広告を自動生成させる場合、このような事情も考慮する必要がある。

本発明は、広告規制に内容が準拠した広告をより確実に自動生成するための技術を提供することを目的とする。

本発明の一態様の情報処理装置は、顧客である事業者についての事業者情報を前記事業者および検索・オンライン地図サービスサイトから取得する事業者情報取得部と、予め定められた設定を基に、前記事業者情報を用いて、前記事業者用の広告を自動生成する広告生成部と、前記事業者の事業分野に存在する広告規制に、自動生成された前記広告の内容が準拠しているか否か確認する確認部と、前記確認部により、前記広告の内容が前記広告規制に準拠していないと確認された場合に、前記広告生成部に前記広告を前記広告規制に準拠した内容に再度、自動生成させる再生成指示部と、を備え、前記検索・オンライン地図サービスサイトは、施設情報サービスを含み、該施設情報サービスを利用する前記事業者により前記事業者情報が登録される構成とし、前記広告確認部および前記再生成指示部は、前記広告の再度の生成および生成された前記広告の確認を前記広告規制に準拠していない箇所が抽出できなくなるまで繰り返し行う構成とした情報処理装置である。

本発明では、回答者からより有用な情報をより確実に得ることができる。

本発明の一実施形態に係る情報処理装置により提供される広告掲載支援サービスの例の概要を説明する図である。 本発明の一実施形態に係る情報処理装置であるサーバ上に実現される機能的構成例を示す図である。 本発明の一実施形態に係る情報処理装置であるサーバのハードウェア構成例を示す図である。 本発明の一実施形態に係る情報処理装置であるＡＰサーバ上に実現される機能的構成例を示す図である。 広告生成処理の例を示すフローチャートである。

以下、本発明の実施形態について、図面を用いて説明する。
図１は、本発明の一実施形態に係る情報処理装置により提供される広告掲載支援サービスの例の概要を説明する図である。

広告掲載支援サービス（以降「支援サービス」と略記）は、個人、或いは企業等である事業者２を顧客に、その事業者２用の広告を自動生成し、その事業者２が指定のＷｅｂサイトへの掲載をサポートするサービスである。それにより、顧客である事業者２は、この支援サービスの利用により、自身が製造、若しくは販売する製品、或いは提供するサービスを紹介し、売り上げを向上させるための広告の掲載をより容易に行うことができる。

事業者２が製造、若しくは販売する製品、及び提供するサービスの種類は特に限定されない。混乱を避けるため、製品、及びサービスの総称として「プロダクト」を用いる。また、理解と容易とするために、特に断らない限り、事業者２の例として医療機関を想定することとする。顧客である事業者２をより明確にするために、医療機関に関わらず、顧客とする事業者２には２を符号として付す。

図１に例として示す医療機関２は、外部への情報発信、予約受付等のための自機関Ｗｅｂサイトを提供するサーバ２Ａを設置している。管理者端末２Ｂは、自機関Ｗｅｂサイトの更新、インターネットを含む各種ネットワークを介したＷｅｂサイトへのアクセスが可能な通信機能を搭載の情報処理装置、例えばＰＣ（Personal Computer）である。
医療機関２は、来訪者に対してサービス（医療サービス）を提供するサービス提供事業者である。医療機関２でなくとも、来訪する施設を設けた事業者であれば、事業分野に関係なく、サービスをプロダクトとするサービス提供事業者である。

自機関Ｗｅｂサイトは、ネットワーク（インターネット）を介した通信が可能な情報処理装置、例えばＰＣ、タブレット端末、或いはスマートフォンを利用可能な一般人向けに、自機関が提供する医療サービスの利用を促すために構築されたものである。図１では、その一般人をユーザ３、そのユーザ３が使用する情報処理装置をユーザ端末３Ａと示している。

医療機関２にとって、自機関が提供する医療サービスの利用者を確保することが重要である。そのためには、ユーザ３のうちから自機関の医療サービスを利用しようとする者を探し出すことが望まれる。そのような者の確保のために、検索・オンライン地図サービスサイト４を利用することも有効である。

検索・オンライン地図サービスサイト４は、検索サービスだけでなく、アクセスしたユーザ３に対し、地図情報を閲覧可能にするオンライン地図サービスを提供する。閲覧のために提供する地図情報には、存在する各種施設が示されているものが含まれる（以降、特に断らない限り、地図情報としては、このようなものを想定する）。検索・オンライン地図サービスサイト４は、何らかの施設がユーザ３によって地図上で指定された場合、指定された施設についての情報を提供することができる。その情報とは、例えば医療機関であれば、診療中か否か、診療中であれば診療終了時間、住所、電話番号、公式サイトが有ればそのサイトへのリンクが貼られたリンクボタン、口コミがあれば口コミ等を示す画面（施設詳細画面）により表示される。それにより、医療機関を指定したユーザは、表示される情報、更にはリンクボタンをクリック操作して公式サイトを閲覧し、その医療機関を利用するか否かの検討を行うことができる。通常、公式サイトでは、予約申込が可能となっている。

検索・オンライン地図サービスサイト４は、このような情報の表示を希望する事業者向けに、施設情報提供サービスを提供している。それにより、医療機関２は、施設情報提供サービスの利用により、検索・オンライン地図サービスサイト４を閲覧するユーザ３のうちから、自機関の医療サービスを利用する者を獲得できる可能性がある。検索サービスを利用した場合、検索結果として提示された自機関のリンクボタンへのクリック操作により、自機関のＷｅｂサイトを閲覧し、自機関の医療サービスを利用する者を獲得できる可能性がある。検索・オンライン地図サービスサイト４に構築されたサービス提供システム４Ａは、検索サービスの提供、ユーザ３が望む地図情報の表示、施設情報提供サービスの提供を可能にするシステムである。

施設情報提供サービスを利用する医療機関２は、自機関についての情報を登録する必要がある。その情報は、例えば自機関の名称、住所、連絡先（例えば電話番号）、自機関のＷｅｂサイトのＵＲＬ（Uniform Resource Locator）、診療時間、休診日、診療科目（診療内容）等である。施設情報提供サービスは、普通、口コミの投稿が可能である。その場合、自機関についての情報には、投稿されたレビュー（例えば星評価＋コメント）、コメントへの医療機関２からの返信も含まれる。以降、投稿されたコメントは「口コミ」と表記する。

医療機関２は、具体的には管理者端末２Ｂを使用する医療機関２の管理者は、施設情報提供サービスを利用する場合、このような情報を登録し、登録した情報を必要に応じて更新する。ここでの更新には、登録済みの情報の更新だけでなく、登録済みの情報の削除、新たな情報の追加が含まれる。新たな情報の追加には、口コミへの返信も含まれる。口コミ自体は、医療機関２によって登録されるものではない。以降、これら登録する情報をまとめて「事業者情報」と表記する。この事業者情報を構成する情報は、事業者２により、或いはその事業分野等によって変化する。また、登録するＷｅｂサイトによって、事業者情報の構成が異なる場合が多い。例えば医療機関２では、自機関Ｗｅｂサイトと、施設情報提供サービス（検索・オンライン地図サービスサイト４）とで事業者情報の構成が異なる場合がある。
検索・オンライン地図サービスサイト４は、サービス提供システム４Ａ、及び施設情報提供サービスを含め周知である。このことから、より詳細な説明は量略する。

施設情報提供サービスの利用により登録される事業者情報は、検索サービスで検索結果を表示する際の優先度の決定に用いられると考えられる。事業者情報の更新頻度が高いほど、優先度も高くなると考えられている。しかし、施設情報提供サービスを利用したとしても、医療機関２が十分な数のユーザ３を確保できるとは限らない。このことから、サービス提供会社１は、十分な数のユーザ３をより確実に確保できるように、支援サービスを提供する。

サービス提供会社１は、その支援サービスの提供のために、少なくとも１台のサーバ１Ａを設置している（図４）。図１では、サーバ１Ａはサービス提供会社１内に示しているが、サーバ１Ａは、サービス提供会社１外に設置しても良い。つまり、クラウドサービスを利用し、サーバ１Ａを設置するようにしても良い。

医療機関２は、顧客として登録、つまり決済用の決済情報を含む顧客情報を登録し、支援サービスを利用する。上記事業者情報は、登録するか、或いはそれを取得可能なＵＲＬを登録すれば良い。そのＵＲＬは複数、登録（指定）可能である。図１に示す例では、自機関のＷｅｂサイト上の一つ以上のＷｅｂページのＵＲＬ、及び検索・オンライン地図サービスサイト４で事業者情報が確認可能な一つ以上のＷｅｂページのＵＲＬを登録することができる。
顧客として登録された事業者２には、識別情報、例えば顧客ＩＤ（IDentification）が割り当てられる。この顧客ＩＤにより、事業者情報を含む各種情報は管理される。

事業者情報を取得可能なＵＲＬの登録は、支援サービスを利用するうえでの各種設定のうちの一つである。医療機関２は他に、広告の自動生成、或いは広告の掲載に関わる各種設定を行う必要がある。ここでの各種設定としては、例えば広告が想定する事業分野、広告を自動生成するタイミング（例えば曜日、及び時刻）、タイミング毎の広告の内容、広告の掲載先等が含まれる。これらを示す情報は何れも設定情報の一部として、サービス提供会社１に登録（保存）される。
広告の掲載先は特に限定されない。図１では、広告の掲載先の例としてＳＮＳ（Social Networking Service）５を示している。ＳＮＳサイト５への広告の掲載は、その広告を投稿として投稿（入稿）することで行われる。

広告の自動生成は、事業者情報を用いて行われる。それにより、医療機関２では、例えば名称、住所、電話番号、診療時間、休診日、診療科目等を少なくとも確認可能な広告が自動生成される。そのような広告を自動生成することにより、ＳＮＳサイト５の閲覧者であるユーザ３は、自身が利用の対象になる医療機関２か否かの判断を広告の内容から行うことができる。

ＳＮＳサイト５では、投稿を表示させる優先順位の決定に投稿日時が考慮される。それにより、ＳＮＳサイト５では、他のＷｅｂサイトとは異なり、ユーザ３のうちでＳＮＳサイト５にユーザ端末３Ａをアクセスさせた者である閲覧者が広告としての投稿を見る可能性は、投稿のタイミングにも依存することになる。そのため、休診日を除く日に広告を投稿させた場合、診療を行っている日に広告を目にする閲覧者数を或る程度は確実に確保できるようになる。この結果、より安定的に、閲覧者のうちから医療機関２を利用する者を確保できると期待できる。

ＳＮＳサイト５には、アクセスしたユーザ端末３Ａに投稿を送信して表示させるとともに、投稿を可能にする複数台のサーバ群５Ａが設置されている。広告配信管理システム５Ｂは、例えばそのサーバ群５Ａ上に分散システムとして実現されている。図１では広告配信管理システム５Ｂを便宜的に示している。

広告配信管理システム５Ｂは、閲覧者（ユーザ３）に対する精密な広告配信を実現する。また、広告を投稿（入稿）した広告主に対し多様な情報を提供する。提供可能な情報としては、例えば配信実績情報、ユーザ行動情報、コンバージョン情報、ユーザ属性情報等がある。ここでは、これらをまとめたものをアクセス情報と呼ぶことにする。アクセス情報の構成自体は、特に限定されない。

配信実績情報は、例えば広告が表示された回数であるインプレッション数、広告を見た閲覧者数であるリーチ数、等を含む情報である。
ユーザ行動情報は、クリック数、ＣＴＲ（Click Through Rate）、広告へのエンゲージメント（いいね・コメント・シェアなど）、等を含む情報である。
コンバージョン情報は、Ｗｅｂサイト訪問数、コンバージョン率（ＣＶＲ）、等を含む情報である。
ユーザ属性情報等は、閲覧者の年齢層、性別、地域、デバイス種別、等を示す情報である。

サービス提供会社１は、広告主である医療機関２の代理人となることができる。そのため、上記のような各種情報が含まれるアクセス情報を広告配信管理システム５Ｂから取得するようにしても良い。アクセス情報の取得は、オペレータに行わせても良いが、ＡＰＩ（Application Programming Interface）を用いて自動的に行わせるようにしても良い。広告配信管理システム５Ｂを含むＳＮＳサイト５は周知であるため、より詳細な説明は省略する。

サービス提供会社１は、ＳＮＳサイト５（の広告配信管理システム５Ｂ）から代理で取得したアクセス情報を医療機関２に提供するとともに、そのアクセス情報を、より望ましい広告の生成に利用する。それにより、ＳＮＳサイト５に投稿した広告により、より多くのユーザ３が医療機関２に来訪すると期待できる。

顧客として想定する医療機関２は、医療サービスを提供する事業者である。医療サービスは医療分野のサービスである。そのため、医療機関２用の広告は、医療広告ガイドラインに準拠した内容とする必要がある。本実施形態で上記事業分野を設定させるのは、事業分野別に制定されている広告規制に対応可能にするためである。それにより、サービス提供会社１（のサーバ１Ａ）は、設定（指定）された事業分野に制定されている広告規制に準拠した内容の広告を自動的に生成する。広告規制は、法律（法令）、政令・省令、条例、ガイドライン・指針、或いは業界ルール・自主規制、等である。

通常、医療機関２を利用しようとするユーザ３は、その医療機関２に来訪する必要がある。しかし、医療機関２に、自己都合で来訪した来訪者に対応可能な余裕があるとは限らない。このようなこともあり、本実施形態では、医療機関２を含め、訪問者に対してサービスをプロダクトとして提供する事業者２を想定した広告には、来訪日時の予約を想定したＷｅｂページへのリンクが貼られたリンクボタンを配置させるようにしている。それにより、医療機関２にとっても都合の良い日時の予約をユーザ３がより容易に行えるようにしている。

予約を想定したＷｅｂページ自体は、特に限定されない。そのＷｅｂページは、来訪日時を指定し予約をするためのものであっても良く、医療機関２についての説明等が記載されたものであっても良い。何れにしても、ユーザ３が直接的に、或いは間接的に予約の申し込みが容易に可能なＷｅｂページであれば良い。このＷｅｂページは、他と区別するために、以降「予約用Ｗｅｂページ」と表記する。また、混乱を避けるために、予約用Ｗｅｂページは、希望する日時をユーザ３が指定し、予約の申し込みを行うものと更に想定する。

その予約用Ｗｅｂページは、医療機関２の自機関Ｗｅｂサイト（サーバ２Ａ）上のものであっても良いが、サーバ１Ａにより提供されるものであっても良い。事業者２のうちには、自Ｗｅｂサイトを用意していないところもあると考えられる。このことから、本実施形態では、予約用Ｗｅｂページを提供し、事業者２に代わって予約の申し込みを受付可能としている。ここでは、混乱を避けるために、以降、予約の申し込みの受け付けはサービス提供会社１が行うものと想定する。

この想定では、サービス提供会社１は、例えばユーザ３がリンクボタンをクリック操作した時点で判明している予約可能な日時を示す予約用Ｗｅｂページを生成し、ユーザ端末３Ａに送信する。そのような予約用Ｗｅｂページを送信することにより、ユーザ３は、予約可能な日時のうちで自身にとって都合の良い日時をより確実に予約できる。ユーザ３による予約の申し込みは、予約申込情報として医療機関２に通知される。この予約申込情報は、例えば申込日時、予約日時、氏名、電話番号等を含む情報群である。予約申込情報の通知は、例えばメール等で医療機関２に行っても良い。

このように、本実施形態では、顧客である事業者２が事業を行う事業分野に制定されている広告規制が存在する場合、存在する広告規制に内容が準拠した広告を自動生成し、広告を定められたＷｅｂサイトに掲載させる。広告規制に内容を準拠させることにより、事業者２にとっては、生成された広告の内容が広告規制に準拠しているか否かの確認を行う必要性が回避されることになる。例えその確認を行うとしても、より容易、且つ迅速に行えるようになる。このことから、単に広告を自動生成させる場合と比較して、生成後の広告の内容確認を事業者２はより容易に行えることとなる。

事業者２には、何らかの伝えるべき情報が新たに発生する場合があり得る。医療機関２では、例えば臨時休診、診療時間の変更、担当医師の変更、等が生じる場合がある。それらは何れも、医療サービスを利用する者に対して伝えるべき情報である。

そのような情報は、例え自機関Ｗｅｂサイトを有する医療機関２であっても、直ちに自機関Ｗｅｂサイトに反映させるとは限らない。これは、検索・オンライン地図サービスサイト４であっても同様である。また、掲載（入稿）の前に、生成後の広告の内容確認を望む事業者２が居る。このようなことから、本実施形態では、事業者２の承認後に、生成した広告の掲載を行うようにしている。それにより、生成後の広告の事業者２による変更（編集）を可能にさせている。

施設情報提供サービスを利用する事業者２は、登録した事業者情報の更新は自身で行わなければならない。そのため、自Ｗｅｂサイトを有する事業者２は、自Ｗｅｂサイト、施設情報提供サービスの両方で、事業者情報の更新を行わなければならない。これは面倒である。このことから、本実施形態では、例えば事業者２の自Ｗｅｂサイトを基準とし、その自Ｗｅｂサイトで公開している事業者情報が更新された場合、その事業者情報の内容に合わせて、施設情報提供サービスに登録されている事業者情報の自動更新を可能としている。そのようにして、必要な事業者情報の更新作業を事業者２がより容易に行えるようにさせている。

医療機関２では、事業者情報であっても、医療広告ガイドラインに準拠した内容とする必要がある。このことから、本実施形態では、自機関のＷｅｂサイトの事業者情報、施設情報提供サービスの事業者情報の何れであっても、医療広告ガイドラインに準拠した内容か否かの確認を行うようにしている。それにより、準拠していない内容の情報を抽出するとともに、準拠した内容を修正例（修正案）として生成し提案するようにしている。提案した修正例への更新は、医療機関２の承認を得た後に自動的に行うようにしている。医療機関２による承認を条件に情報の更新を行うようにしたのは、閲覧者に誤った内容の情報を提供するのをより回避させるためである。

施設情報提供サービスでは、口コミの投稿が可能である。それにより、本実施形態では、事業者情報の確認時、新たな口コミが投稿されたか否かの確認を行い、新たな口コミが確認された場合、それに対する返信文案を生成し提案するようにしている。提案した返信文案は、修正案と同様に、医療機関２の承認を得た後に自動的に掲載させるようにしている。医療機関２による承認を条件にしたのは、口コミの投稿者の大部分は医療サービスの利用者だと考えられるからである。そのため、医療サービスを利用した際の情報を返信文に加えたいと医療機関２側が考える可能性がある。

このように、本実施形態では、施設情報提供サービスを利用している事業者２であった場合、登録した事業者情報の更新、内容的に不適切な箇所（不適切と推定可能な箇所）の修正支援、及び新たに投稿された口コミへの返信文の自動生成を状況に応じて行うようにしている。そのような対応により、事業者２にとっては、口コミの投稿への対応を含め、事業者情報の更新頻度をより高く維持させることがより容易になる。事業者情報の内容は、医療広告ガイドラインに準拠した状態に維持させることがより容易となる。このようなことから、事業者２にとっては高い利便性が得られることとなる。事業者情報の更新頻度をより高く維持させることは、検索サービスによる検索結果で医療機関２をより上位に配置させるようにするうえで効果があると考えられる。

図２は、本発明の一実施形態に係る情報処理装置であるサーバ上に実現される機能的構成例を示す図である。なお、この機能的構成例は１例であり、機能的構成自体は特に限定されない。各種の変形が可能である。

図２に示すように、サーバ１Ａ上には、機能的構成として、送受信処理部２１、設定情報記憶部２２、アクセス処理部２３、登録情報確認処理部２４、返信文生成処理部２５、広告生成処理部２６、広告確認処理部２７、アクセス解析処理部２８、及び出力処理部２９は実現されている。
送受信処理部２１は、ネットワークを介した情報の送受信のための処理を行う。事業者２のサーバ２Ａ、管理者端末２Ｂ、検索・オンライン地図サービスサイト４のサービス提供システム４Ａ、ＳＮＳサイト５のサーバ群５Ａ（広告配信管理システム５Ｂ）との間の通信を可能にする。

設定情報記憶部２２は、管理者端末２Ｂにより送信された設定情報の保存に用いられる。その設定情報自体は、上記のように、例えば事業者情報を取得可能な一つ以上のＵＲＬ、広告が想定する事業分野、広告を自動生成するタイミング、タイミング毎の広告の内容、広告の掲載先等を表すことが可能な情報群である。医療機関２の場合、予約可能な日時（利用情報）を確認可能なＷｅｂページのＵＲＬが更に含まれていても良い。この設定情報は、送受信処理部２１によって設定情報記憶部２２に記憶される。

設定情報には、上記のように、情報として、アクセスすべきＷｅｂページのＵＲＬが一つ以上、含まれる。アクセス処理部２３は、設定情報を参照し、送受信処理部２１を制御して、アクセスすべきＷｅｂページにアクセスするための処理を行う。
設定情報には、上記のように、情報として、事業者情報が取得可能なＷｅｂページのＵＲＬが複数、含まれる場合がある。登録情報確認処理部２４は、各Ｗｅｂページから取得される事業者情報に対応する。具体的には上記のように、事業者情報毎の内容の確認だけでなく、それぞれのＷｅｂページから取得された事業者情報の間での不具合の有無を確認する。例えば事業者情報の間で内容が一致していない情報の存在は、不具合である。登録情報確認処理部２４は、そのような不具合が有ることを確認した場合、例えば不具合が存在する情報、各情報の内容を医療機関２の管理者に通知するための処理を行う。設定情報により、優先度の高いＷｅｂページのＵＲＬが指定されている場合、優先度の高いＷｅｂページで得られた情報の内容が修正案として提示される。このように、本実施形態では、優先度の指定を可能にすることにより、内容が一致しない情報が抽出された場合、優先度の低いほうの情報の内容が不適切であると推定し、その情報の内容の修正案を提示するようにしている。

それにより、医療機関２の承認により、優先度の高いＷｅｂサイトの事業者情報の内容に、優先度の低いＷｅｂサイトの事業者情報の内容の自動更新が可能である。この自動更新により、事業者２は、事業者情報間の不具合をより容易に解消させることができる。２つの事業者情報中の情報の内容が共に不適切であった場合、事業者２が適切な内容を指定することにより、その情報はともに指定された内容に自動更新される。承認が必要な事項の管理者への通知は、例えば送受信処理部２１を用いてメールにより行っても良い。承認が可能な各種情報を事業者２に確認させ承認をさせる方法としては、周知の方法を採用しても良い。このことから、特に詳細な説明は省略する。

検索・オンライン地図サービスサイト４にアクセスし開かせた医療機関２の施設詳細画面に記載された内容が実際とは異なることを確認したユーザは、その医療機関２に対して少なからず負の印象を持つ可能性が高い。例えば施設詳細画面では診療中と記載されていたにも関わらず、実際には診療が終了していたことを確認したユーザ３が、施設詳細画面を見て利用を検討する者の存在を軽視していると考える恐れがある。そのように考えたユーザ３のうちには、人に話す、或いは口コミを投稿する、等の行為を行う者も居ると考えられる。これは、医療機関２にとって望ましくない。それにより、不具合の存在を確認し通知することは、医療機関２の利用を回避しようとする者を抑える意味で有効である。

登録情報確認処理部２４が事業者情報を確認することにより、新たな口コミが投稿されていた場合、その口コミが特定される。返信文生成処理部２５は、特定された口コミへの返信文を自動生成する。自動生成された返信文は、上記のように、事業者２の承認により、特定された口コミの返信文として自動的に掲載される。事業者２は、自動生成された返信文の編集を行うことも可能である。

広告生成処理部２６は、設定情報により指定されたタイミング、内容で広告を自動生成するものである。広告の自動生成には、アクセス処理部２３の制御により取得された事業者情報が用いられる。
広告確認処理部２７は、設定情報で指定された事業分野に制定されている広告規制に、自動生成された広告の内容が準拠しているか否かの確認を行う。その確認の結果、準拠していない内容が存在する場合、広告確認処理部２７は、例えばその内容を広告生成処理部２６に渡し、広告の再生成を行わせる。それにより、最終的に生成された広告は、制定された広告規制に内容が準拠したものとなる。

アクセス情報は、アクセス処理部２３に送受信処理部２１を制御させ、ＡＰＩを用いて、広告配信管理システム５Ｂから取得させることが可能である。或いはサービス提供会社１のオペレータが、広告配信管理システム５Ｂから取得したものをサーバ１Ａに送信させても良い。アクセス解析処理部２８は、このようにして取得されたアクセス情報の解析を行うものである。

上記のように、広告は、設定情報により、例えば曜日毎に、内容を変えて生成させることが可能である。このことから、アクセス情報に対する解析は、例えば現在の曜日で過去に生成された広告、及びその広告で得られたアクセス情報を用いて行われる。そのために、広告生成処理部２６は、同じ曜日であっても、生成する広告のデザインをランダムに、或いは計画的に変化させて生成するようになっていても良い。デザインの変更とは、具体的には例えば広告のファーマット、コンテンツの内容、その種類、その数、各項目の配置等のうちの何れか一つ以上を変えることである。このような広告の生成により、本実施形態では、曜日による広告へのアクセス傾向の相違を排除させつつ、アクセス情報の解析を通して、ユーザ３にとってより望ましい広告のデザイン、その細部を特定（推測）するようにしている。この解析結果は、広告生成処理部２６により参照される。

上記のように、生成された広告の投稿は、医療機関２の管理者による承認後に行うようになっている。出力処理部２９は、生成された広告の管理者による承認、承認後の広告の投稿のための処理を行う。その承認、及び広告の投稿は何れも、送受信処理部２１の制御により実現される。また、出力処理部２９は、事業者２の承認により、何れかの事業者情報の更新を行う。

以降は、本実施形態について更に詳細に説明する。
図３は、本発明の一実施形態に係る情報処理装置であるサーバのハードウェア構成例を示す図である。このハードウェア構成例は、サーバ１ＡがＡＰサーバであった場合の一例である。ハードウェア構成自体は、特に限定されるものではない。例えばＣＰＵ（Central Processing Unit）１０１、ＧＰＵ（Graphics Processing Unit）１０４は一つのみ示しているが、それらはともに複数、搭載されていても良い。

サーバ１ＡがＡＰサーバ（以降、「ＡＰサーバ１Ａ」と表記）であった場合、ＡＰサーバ１Ａは他にＷｅｂサーバ、及びＤＢ（DataBase）と組み合わせて用いられる（図４）。そのＡＰサーバ１Ａは、図３に示すように、ＣＰＵ１０１、ＲＯＭ（Read Only Memory）１０２、ＲＡＭ（Random Access Memory）１０３、ＧＰＵ１０４、ＮＩＣ（Network Interface Card）１０５、補助記憶装置１０６、メディアドライブ１０７、及びＩ／ＦＣ（InterFace Controller）群１０８がバス１０９に接続されている構成である。ＧＰＵ１０４にはＶＲＡＭ（Video RAM）１０４Ａが接続されている。

ＮＩＣ１０５は、ネットワークを介した通信を可能にする。通信を行う対象は、主にＷｅｂサーバとＤＢサーバである。ネットワークを介した通信は、無線通信、及び有線通信のうちの何れであっても良い。複数の通信規格に対応したものであっても良い。図３には、ＮＩＣ１０５を１つのみ示しているが、対応する通信規格が異なる複数のＮＩＣ１０５が搭載されていても良い。

補助記憶装置１０６は、データを永続的に記憶可能な装置であり、例えばハードディスク装置、或いはＳＳＤ（Solid State Drive）等である。メディアドライブ１０７は、記録媒体であるメディア１０７Ａが着脱自在なものである。メディア１０７Ａは、例えばＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ等である。

Ｉ／ＦＣ群１０８は、入力装置１０８Ａ、及び表示装置１０８Ｂを含む各種周辺機器、或いは外部機器との通信を可能にする各種Ｉ／ＦＣを含む。入力装置１０８Ａ、及び表示装置１０８Ｂは、必要に応じて一時的にＩ／ＦＣ群１０８に接続される。
補助記憶装置１０６には、プログラムとして、ＯＳ（Operating System）、及びそのＯＳ上で動作する各種アプリケーション・プログラムが保存されている。各種アプリケーション・プログラムの一つとして、支援サービスの提供を可能にするためのアプリケーション・プログラムが存在する。以降、そのアプリケーションは「支援サービスアプリ」と表記する。

ＲＯＭ１０２も、データを永続的に記憶可能な装置であり、例えばファームウェア、及び各種データが記憶されている。ＣＰＵ１０１は、ＲＯＭ１０２に記憶されたファームウェアをＲＡＭ１０３に読み出して実行する。その後、ファームウェアにより、補助記憶装置１０６に記憶されているＯＳをＲＡＭ１０３に読み出して実行する。支援サービスアプリを含む各種アプリケーション・プログラムは、ＯＳにより、ＲＡＭ１０３に読み出されて実行される。ＧＰＵ１０４は、補助記憶装置１０６に記憶されＶＲＡＭ１０４Ａに読み出された各種アプリケーション・プログラムを実行することができる。

支援サービスアプリは、メディア１０７Ａに記憶させて配布しても良い。インターネットを含むネットワークを介した通信が可能な場合、ネットワークを介して配信するようにしても良い。ネットワークを介して配信する場合、支援サービスアプリは、それを配信する情報処理装置が直接的に、或いは間接的にアクセス可能な記録媒体に記憶させれば良い。つまり、記憶媒体は、配信する情報処理装置と通信可能な別の情報処理装置が直接的に、或いは間接的にアクセス可能なものであっても良い。

図４は、本発明の一実施形態に係る情報処理装置であるＡＰサーバ上に実現される機能的構成例を示す図である。この機能的構成例は、Ｗｅｂサーバ２００、及びＤＢサーバ３００が存在する場合のものであり、主に上記支援サービスアプリをＣＰＵ１０１、及びＧＰＵ１０４がそれぞれ実行することにより実現される。なお、機能的構成は、特に限定されない。各種の変形が可能である。また、図４では、図１と同じ、或いは基本的に同じものには同一の符号を付している。

支援サービスアプリは、図２に示す各部２１～２８を実現させるプログラムである。各部２１～２８は、同じ情報処理装置上に実現させなくとも良い。つまり、各部２１～２８は、２台以上の情報処理装置に分散させて配置させるようにしても良い。
支援サービスアプリは、ＣＰＵ１０１に実行させる部分と、ＧＰＵ１０４に実行させる部分とに大別される。ここでは、ＣＰＵ１０１に実行させる部分は「ＣＰＵ用実行アプリ」、ＧＰＵ１０４に実行させる部分は「ＧＰＵ用実行アプリ」と表記して区別する。

図４に示すように、ＡＰサーバ１ＡのＣＰＵ１０１上には、ＣＰＵ用実行アプリを実行する結果、機能的構成として、送受信処理部２１、アクセス処理部２３、登録情報確認指示部１０１１、アクセス情報解析指示部１０１２、広告生成指示部１０１３、広告確認指示部１０１４、広告編集処理部１０１５、及び広告掲載処理部１０１６が実現される。

また、ＡＰサーバ１ＡのＧＰＵ１０４上には、ＧＰＵ用実行アプリを実行する結果、機能的構成として、図４に示すように、登録情報確認部１０４１、返信文生成部１０４２、アクセス情報解析部１０４３、広告生成部１０４４、及び広告確認部１０４５が実現される。これらは何れも生成ＡＩ（Artificial Intelligence）である。

このような機能的構成がＣＰＵ１０１上、及びＧＰＵ１０４上にそれぞれ実現される一方、補助記憶装置１０６上には、設定情報記憶部２２、承認対象記憶部１０６１、広告記憶部１０６２、アクセス情報記憶部１０６３、及び登録情報記憶部１０６４が情報（データ）の格納領域として確保される。図４には、便宜的に主なもののみを示している。

各記憶部２２、１０６１～１０６４にそれぞれ記憶される情報は、例えば以下のようなものである。
設定情報記憶部２２には、上記設定情報が記憶される。顧客登録した事業者２は、例えば顧客ＩＤを識別情報として一意的に管理される。そのために、設定情報は、顧客ＩＤが付加されたものとなっている。

承認対象記憶部１０６１は、生成された広告、事業者情報の更新案等の保存用に確保された格納領域である。事業者情報の更新案には、個別の情報の修正案、口コミへの返信文案、等が含まれる。
広告記憶部１０６２は、掲載（投稿）済みの広告の格納用に確保された格納領域である。広告記憶部１０６２に記憶された広告は、アクセス情報の解析に用いられる。
アクセス情報記憶部１０６３は、上記アクセス情報の格納用に確保された格納領域である。

登録情報記憶部１０６４は、登録された事業者情報の格納用に確保された格納領域である。今回、取得した事業者情報の他に、同じＷｅｂページから直前に取得した事業者情報が存在する場合、直前に取得した事業者情報も保存される。
設定情報記憶部２２に記憶される設定情報、広告記憶部１０６２に記憶される広告の全て、或いは大部分、及びアクセス情報記憶部１０６３に記憶されるアクセス情報の全て、或いは大部分は、ＤＢサーバ３００から取得して保存される。

各記憶部２２、１０６１～１０６４に記憶されたデータは、実際にはＲＡＭ１０３、若しくはＶＲＡＭ１０４Ａに読み出されて処理される。各記憶部２２、１０６１～１０６４へのデータの記憶は、ＲＡＭ１０３、若しくはＶＲＡＭ１０４Ａを介して行われる。また、ＣＰＵ１０１は、Ｗｅｂサーバ２００、及びＤＢサーバ３００との通信はＮＩＣ１０５を介して行う。ＣＰＵ１０１とＮＩＣ１０５間のデータの送受信は、ＲＡＭ１０３を介して行われる。図４では便宜的に、このようなことを無視している。以降の説明でも同様に無視する。

ＧＰＵ１０４上に実現された各部１０４１～１０４４は、例えば以下のような機能を有する。
上記のように、設定情報により、事業者情報を確認可能なＷｅｂページのＵＲＬを複数（通常は２つ）指定することができる。登録情報確認部１０４１は、各ＵＲＬでそれぞれ指定される各Ｗｅｂページから確認される事業者情報自身、及び事業者情報の間の不具合の有無を確認可能な機能である。そのために、事業分野、事業者情報が一つ以上プロンプト入力される。直前に取得された事業者情報が存在する場合、その事業者情報もプロンプト入力される。事業者情報は、上記のように、複数の情報を有する情報群である。

事業者２が例えば検索・オンライン地図サービスサイトにのみ事業者情報を登録し、且つ支援サービスの利用を開始したような場合、入力可能な事業者情報は一つのみである。このことから、事業者情報は一つのみ入力される。事業者情報の一つのみであった場合、事業分野に制定されている広告規制に各情報の内容が準拠されているか否か、情報間の内容の不具合の有無、等の確認が行われる。事業分野は、その事業分野で制定されている広告規制を指定するために入力される。

情報間の内容の不具合とは、例えば診療時間の項目では「土曜日 ９：００～１３：３０」となっていながら、利用者へのメッセージでは「土曜日の診療時間は９時から１３時となっております。」と内容に不整合があることである。確認結果としては、例えば広告規制に内容が準拠していない情報の抽出結果、広告規制に内容が準拠していない情報が抽出された場合、その情報の変更案、不具合の有無の判定結果、不具合が有りと判定された場合、不具合を解消するための変更案、等が返される。表記ゆれ等を更に確認し、その確認結果を返すようにしても良い。判定された不具合はエラーとして扱われる。

同じＷｅｂページ（例えば検索・オンライン地図サービスサイト）から取得した２つの事業者情報、つまり同じＷｅｂページから前回、取得した事業者情報が更に入力されている場合、この２つの事業者情報間の差分の確認が更に行われる。そのような確認により、前回、事業者情報を取得してからの変更箇所を特定し、特定結果が返される。このような特定により、新たに投稿された口コミの存在を確認することができる。口コミ以外の情報では、変更後の内容だけでなく、変更前の内容を併せて返すようにしても良い。情報の変更、つまり更新はエラーとして扱われない。

別のＷｅｂページからそれぞれ事業者情報事業者が取得され入力された場合、それら事業者情報間の差分の確認が更に行われ、その確認結果が返される。その確認により、内容が異なる情報が抽出された場合、抽出された情報の種類、及び各情報の内容を併せて返すようにしても良い。事業者情報間の優先度が設定されている場合、上記のように、優先度の低いほうの内容が不適切であると推定され、優先度の高いほうの内容が変更案とされる。事業者情報間に存在する差分は多くの場合、エラーとして扱われる。

各Ｗｅｂページから取得される事業者情報の構成は同じであるとは限らない。例えば医療機関２が自機関のＷｅｂサイトで口コミの投稿を可能とさせていない場合、口コミは差分を確認する対象とはならない。差分の確認は、事業者情報中の同じ種類の情報間で行われる。

登録情報確認部１０４１は、上記のように、入力された事業者情報に応じて、３つの視点で確認を行い、その確認結果を返す。それにより、例えば医療機関２では、診療時間、或いは担当医が変更された場合、診療時間、或いは担当医が変更されたことを強調して広告に示すようなことが可能となる。
返信文生成部１０４２は、口コミに対する返信文の案を自動生成する機能である。そのために、例えば返信文の案を生成すべき口コミがプロンプト入力される。事業者２の事業分野、等を更に入力するようにしても良い。

アクセス情報解析部１０４３は、得られたアクセス情報から、広告の閲覧者にとってより望ましい広告についての情報（以降「生成提案情報」と表記）を生成する。そのために、アクセス情報解析部１０４３によるアクセス情報の解析は、広告の自動生成の前に行われる。プロンプト入力として、例えば現在の曜日、その曜日で過去に得られたアクセス情報、及びその曜日で過去に掲載された広告等が与えられる。それにより、アクセス情報解析部１０４３は、過去に掲載された広告のデザイン、その内容と、アクセス結果（インプレッション数、リーチ数、ＣＴＲ等）との間の傾向を推定し、より望ましいと考えられる広告のデザイン、内容の提案を制定提案情報により行う。アクセス情報、広告はともに、対応する事業者２を特定可能なように、顧客ＩＤが付加されるか、或いは顧客ＩＤと紐付けられている。これは他の情報でも同様である。

広告生成部１０４４は、掲載（投稿）の対象となる広告を生成する機能である。設定情報では、上記のように、広告を自動生成するタイミング（例えば曜日、及び時刻）、タイミング毎の広告の内容、広告を自動生成すべきタイミング（例えば曜日、及び時刻）毎に、広告の内容を指定することが可能な情報群である。このことから、例えば事業分野（を指定する情報）、事業者情報の他に、広告に記すべき内容がプロンプト入力される。入力すべき生成提案情報が存在する場合、その生成提案情報もプロンプト入力される。事業者２が医療機関２であった場合、予約が可能な日時の確認を閲覧者が可能なように、現時点で予約が可能な日時を特定できれば、特定できた日時も併せてプロンプト入力される。医療機関２がＷｅｂサイトを構築したサーバ２Ａを設置していた場合、予約可能な日時の特定は、サーバ２Ａにアクセスして行えば良い。なお、広告に掲載する文章の言語を指定する情報も併せて入力させるようにしても良い。言語を指定する情報は複数、入力させるようにしても良い。それにより、多言語の広告を自動生成させるようにしても良い。

広告確認部１０４５は、生成された広告の内容が事業者２の事業分野に制定されている広告規制に準拠しているか否かの確認を行う。そのために、例えば生成された広告の他に、事業分野がプロンプト入力される。確認結果として、例えば広告規制に内容が全て準拠しているか否か、内容が全て準拠していない場合、準拠していない箇所が返される。

ＣＰＵ１０１上に実現された各部２１、２３、１０１１～１０１６は、例えば以下のような機能を有する。
送受信処理部２１は、Ｗｅｂサーバ２００との間でリクエストを含む各種データの送受信のための処理を行う。ユーザ端末２０、及び管理者端末２Ｂとの間の通賃は、Ｗｅｂサーバ２００を介して行われる。また、広告の掲載もＷｅｂサーバ２００を介して行われる。顧客である事業者２のログイン等にはＷｅｂサーバ２００が対応する。

アクセス処理部２３は、事業者２毎にその設定情報を参照し、各種情報の取得を行う。本実施形態では、広告を生成すべきタイミングで、事業者情報を取得するようにしている。アクセス処理部２３の制御により、送受信処理部２１は、Ｗｅｂサーバ２００を介してアクセスすべきＷｅｂページにアクセスし、そのアクセスにより取得された事業者情報は、送受信処理部２１からアクセス処理部２３に渡される。そのようにして渡された事業者情報は、アクセス処理部２３により、例えば顧客ＩＤが付加された後、登録情報記憶部１０６４に保存される。説明上、便宜的に、特に断らない限り、以降２つの事業者情報が取得されるものと想定する。アクセス情報は、ここではサービス提供会社１の管理者が端末を用いて取得し、ＡＰサーバ１Ａに送信するものと想定する。その想定では、ＡＰサーバ１Ａに受信されたアクセス情報は、送受信処理部２１により、アクセス情報記憶部１０６３に記憶される。

事業者情報の記憶した旨は、例えばアクセス処理部２３から登録情報確認指示部１０１１に通知される。登録情報記憶部１０６４に各Ｗｅｂページから取得した２つの事業者情報が記憶されている場合、その通知により、登録情報確認指示部１０１１は、登録情報記憶部１０６４に記憶されている４つの事業者情報を読み出して登録情報確認部１０４１に渡し（プロンプト入力し）、事業者情報の確認を指示する。登録情報確認指示部１０１１は、その指示により返される確認結果（上記３つの視点での確認結果）を承認対象記憶部１０６１に保存する。確認を行った結果、登録情報確認部１０４１がエラーとして扱う不具合等を一つ以上抽出した場合、その抽出結果は事業者２が確認すべきエラーとして提示される。

登録情報確認部１０４１が新たに投稿された口コミを確認結果として返した場合、登録情報確認指示部１０１１は、返された口コミを返信文生成部１０４２に渡し（プロンプト入力し）、返信文の生成を指示する。その指示により返される返信文を承認対象記憶部１０６１に保存する。保存された返信文は、案として事業者２に提示される。

アクセス情報解析指示部１０１２は、対象となるアクセス情報の存在をアクセス情報記憶部１０６３、更にはＤＢサーバ２００にそれぞれアクセスして確認する。その結果、アクセス情報の存在を確認できた場合、確認できたアクセス情報、及び各アクセス情報に対応する広告をアクセス情報解析部１０４３に渡し（プロンプト入力し）、その解析を指示する。その解析結果は生成提案情報として、アクセス情報解析指示部１０１２から広告生成指示部１０１３に渡される。このようなことから、送受信処理部２１により保存されるアクセス情報以外のアクセス情報、及び既に掲載された広告は、アクセス情報解析指示部１０１２により、ＤＢサーバ２００から取得され、アクセス情報記憶部１０６３、及び広告記憶部１０６２に格納される。

広告生成指示部１０１３は、事業分野、事業者情報、広告に指定された内容、及び広告に記すべき情報（医療機関２であれば予約可能日時等）を広告生成部１０４４に渡し（プロンプト入力し）、広告の生成を指示する。渡された解析結果（生成提案情報）が存在する場合、その解析結果も渡される。広告生成指示部１０１３は、広告生成部１０４４から広告の生成結果を受け取り、承認対象記憶部１０６１に保存する。広告の生成結果を保存した旨は、広告確認指示部１０１４に通知される。
広告確認指示部１０１４は、その通知により、承認対象記憶部１０６１に保存された広告を事業分野とともに広告確認部１０４５に渡し（プロンプト入力し）、保存された広告の内容が広告規制に準拠しているか否かの確認を指示する。

広告確認部１０４５は、上記のように、例えば広告規制に準拠していない箇所を抽出して返す。そのような箇所が返された場合、広告確認指示部１０１４は、抽出した箇所を広告生成指示部１０１３に渡し、広告の再生成の必要性を通知する。それにより、広告生成指示部１０１３は、例えば抽出された箇所を変更すべき内容として加えて広告生成指示部１０１３に渡し、広告の再生成を指示する。

このような広告の再度の生成、生成された広告の確認は、広告規制に準拠していない箇所が抽出できなくなるまで繰り返し行われる。そのため、最終的に生成された広告は、広告規制に準拠していない箇所が抽出できなかったものとなる。最終的に生成された広告は、承認対象として承認対象記憶部１０６１に保存される。

承認対象記憶部１０６１に承認対象として保存された広告は、特に詳細な説明は省略するが、事業者２がアクセス可能となっている。それにより、医療機関２であれば、管理者端末２Ｂに表示させることができる。他に、事業者情報の確認結果、口コミへの返信文案も表示させることができる。それにより、医療機関２の管理者は、事業者情報に存在するエラーと考えられる箇所、その箇所の変更案（修正案）等も確認することができる。

エラーは、承認対象の広告上に反映されている可能性がある。このこともあり、本実施形態では、承認対象の広告の内容を事業者２側で変更することを可能にさせている。それにより、承認された広告は、Ｗｅｂサーバ２００を介してＡＰサーバ１Ａに送信される。ＡＰサーバ１Ａに受信された広告は、送受信処理部２１を介して広告編集処理部１０１５に渡される。それにより、広告が変更されていた場合、広告編集処理部１０１５により、変更後の内容に、承認対象記憶部１０６１に保存されている広告が編集される。広告が承認された旨は、広告編集処理部１０１５から広告掲載処理部１０１６に通知される。

広告掲載処理部１０１６は、その通知により、承認対象記憶部１０６１に保存されている広告を、設定情報により指定された掲載先に掲載させるための処理を行う。それにより、掲載先がＳＮＳサイト５であった場合、広告が投稿として投稿（入稿）されることになる。そのようにして掲載された広告は、例えば広告掲載処理部１０１６により、ＤＢサーバ３００に保存される。

事業者情報に存在すると判定されたエラーには、上記のように、変更案が提示される。それにより、エラーでも広告と同様に、変更案への更新を承認するか否かの問い合わせが行われる。提示された変更案の編集も可能である。このため、事業者が承認した場合、広告掲載処理部１０１６は、提示された変更案、或いは編集後の変更案に、事業者情報を更新する。

図５は、広告生成処理の例を示すフローチャートである。この広告生成処理は、広告の生成のために実行されるものである。本実施形態では、予め定められたタイミングで実行されるタイマインタラプト処理となっている。ＣＰＵ１０１上の各部２１、２３、１０１１～１０１４、及びＧＰＵ１０４上の各部１０４１～１０４４により実現される。次に図５を参照し、この生成処理について詳細に説明する。処理を実行する主体としてはＣＰＵ１０１を想定する。

先ず、ステップＳ１０１では、ＣＰＵ１０１は、対象とする事業者２の設定情報を設定情報記憶部２２から取得する。続くステップＳ１０２では、ＣＰＵ１０１は、取得した設定情報を参照して、広告を生成すべき生成タイミングか否か判定する。その生成タイミングが到来していた場合、ステップＳ１０２の判定はＹＥＳとなってステップＳ１０３に移行する。その生成タイミングが到来していない場合、ステップＳ１０２の判定はＮＯとなり、ここで広告生成処理が終了する。

ステップＳ１０３では、ＣＰＵ１０１は、設定情報を参照して、ＵＲＬで指定されたＷｅｂページにアクセスし、事業者情報を取得する。上記のように、ここでは２つのＷｅｂページから事業者情報をそれぞれ取得したと想定する。次に移行するステップＳ１０４では、ＣＰＵ１０１は、直前に取得した事業者情報を今回、取得した事業者情報と比較し、事業者情報の内容に変更があるか否か判定する。直前に事業者情報を取得してから、事業者２が事業者情報を変更していた場合、事業者情報の内容が一致しないことになる。そのため、ステップＳ１０４の判定はＹＥＳとなってステップＳ１０５に移行する。事業者２が事業者情報を変更していない場合、ステップＳ１０４に判定はＮＯとなってステップＳ１０８に移行する。なお、ここでの比較は、信用度が比較的に高いと考えられる事業者情報、例えば医療機関２では、サーバ２Ａから取得された事業者情報のみを対象に行っても良い。

ステップＳ１０５では、ＣＰＵ１０１は、登録情報記憶部１０６４に保存されている２つ以上の事業者情報を読み出し、事業者情報をＧＰＵ１０４に確認させる。この確認の結果、新たな口コミの存在が特定された場合、ＣＰＵ１０１は、特定された口コミに対する返信文の生成をＧＰＵ１０４に指示する。その後は、ステップＳ１０６に移行して、ＣＰＵ１０１は、承認対象が存在するか否か判定する。上記のように、事業者情報の確認は、最大で３つの視点で行われ、エラーとされる内容が抽出された場合、その内容の変更案が承認対象とされる。新たに投稿された口コミの特定によって生成される返信文案も承認対象である。そのため、３つの視点のうちの１つ以上でエラーとされるものが抽出されるか、或いは返信文案を自動生成させていた場合、承認対象が存在することになる。結果、ステップＳ１０６の判定はＹＥＳとなってステップＳ１０７に移行する。そのような承認対象が存在しない場合、ステップＳ１０６の判定はＮＯとなってステップＳ１０８に移行する。

ステップＳ１０７では、ＣＰＵ１０１は、抽出されたエラー（についての変更案を含む情報）、及び生成された返信文案のうちの少なくとも一方を、事業者２が承認を行うべき承認対象として保存する。それにより、事業者２は、抽出されたエラー、及び生成された返信文案の何れも承認対象として確認することができる。その後はステップＳ１０８に移行する。

ステップＳ１０８では、ＣＰＵ１０１は、広告に利用すべき利用情報の収集を行う。利用情報としては、例えば医療機関２であれば、上記のように、予約可能日時が利用情報として収集される。その収集の対象は、医療機関２のサーバ２Ａを含めることが望ましい。また、医療機関２が臨時休診日、或いはお盆、或いは年末年始等により、長期間の休診日を設けていた場合、そのことは、本日は休診日でない旨を強調する必要が生じる利用情報として扱われる。臨時に休診日となった場合には、休診日は事業者情報の一部であっても、それとは別に強調すべき利用情報として扱われる。このように、利用情報には、直接的に通知すべき情報だけでなく、通知すべき情報の特定に用いるべき情報が含まれる。このような利用情報により、過去に広告（投稿）を閲覧した閲覧者に対して、伝えるべき情報をより効果的に伝えられる広告を生成することが可能となる。なお、広告に用いるべき画像、或いはメッセージ等を事業者２が利用情報として事前に用意できるようにして、事業者２が用意した利用情報を広告に載せることを可能にしても良い。

次に移行するステップＳ１０９では、ＣＰＵ１０１は、アクセス情報があるか否か判定する。上記のように、アクセス情報の解析は、比較対象が必要なことから、同じタイミング、例えば同じ曜日に過去に複数の広告を生成（掲載）していることを条件に行われる。それにより、比較対象となる複数のアクセス情報の存在を確認できた場合、ステップＳ１０９の判定はＹＥＳとなってステップＳ１１０に移行する。そのような複数のアクセス情報を確認できなかった場合、ステップＳ１０９の判定はＮＯとなってステップＳ１１１に移行する。

ステップＳ１１０では、ＣＰＵ１０１は、確認できた複数のアクセス情報、そのアクセス情報に対応する掲載済みの広告を用いた解析をＧＰＵ１０４に行わせる。その解析結果を受け取った後に、ステップＳ１１１に移行する。

ステップＳ１１１では、ＣＰＵ１０１は、上記のように、対象とする事業者２の事業分野、事業者情報、アクセス情報の解析結果（存在する場合）、広告の内容、収集した利用情報等を用いた広告の生成をＧＰＵ１０４に行わせる。続くステップＳ１１２では、ＣＰＵ１０１は、生成された広告、及び事業分野をＧＰＵ１０４に渡し、業務分野に制定された広告規制に、広告の内容が準拠しているか否かの確認を行わせる。その後に移行するステップＳ１１３では、ＣＰＵ１０１は、確認結果が、不具合ありを示しているか否か判定する。

上記のように、広告規制に内容が準拠していない箇所が一箇所でもあった場合、不具合がありとされる。そのため、ステップＳ１１３の判定はＹＥＳとなって上記ステップＳ１１１に戻り、不具合があった箇所を更にＧＰＵ１０４に渡して広告の生成を行わせる。それにより、不具合が抽出され、ステップＳ１１３の判定がＹＥＳとなった場合、そのステップＳ１１３の判定がＮＯとなるまで、ステップＳ１１１～Ｓ１１３で形成される処理ループが繰り返し実行されることとなる。

ステップＳ１１３の判定がＮＯとなって移行するステップＳ１１４では、ＣＰＵ１０１は、最終的に生成された広告を、事業者２による承認対象として保存する。その保存を行った後、この広告生成処理が終了する。

このようなことから、図２に示す各部２４～２８と、図４に示すＣＰＵ１０１上の各部１０１１～１０１６、及びＧＰＵ１０４上の各部１０４１～１０４４との間の対応関係は、以下のようになる。
登録情報確認処理部２４には、登録情報確認指示部１０１１、及び登録情報確認部１０４１が対応する。
返信文生成処理部２５には、登録情報確認指示部１０１１、及び返信文生成部１０４２が対応する。
広告生成処理部２６には，広告生成指示部１０１３、及び広告生成部１０４４が対応する。
広告確認処理部２７には、広告確認指示部１０１４、及び広告確認部１０４５が対応する。
アクセス解析処理部２８には、アクセス情報解析指示部１０１２、及びアクセス情報解析部１０４３が対応する。
出力処理部２９は、広告掲載処理部１０１６に対応する。

また、送受信処理部２１、及びアクセス処理部２３は、本実施形態における事業者情報取得部に相当する。また、アクセス情報取得部として機能させることが可能である。外部からアクセス情報が送信される場合、送受信処理部２１がアクセス情報取得部に相当することになる。
広告生成処理部２６は、本実施形態における広告生成部に相当する。
広告確認処理部２７は、本実施形態における確認部、及び再生成指示部に相当する。
登録情報確認処理部２４は、本実施形態における情報確認部に相当する。
出力処理部２９は、本実施形態における掲載処理部、及び更新処理部に相当する。

なお、本実施形態では、事業者２の事業分野が１つのみと想定しているが、事業者２が複数の事業分野で事業を行っている場合もある。その場合、１つの事業分野を１つの事業者２として扱えば良い。このため、事業者２の事業分野の数は特に限定されない。
また、広告の掲載先も、複数、あっても良い。例えばネットワークを介してアクセス可能なＷｅｂサイトとしては、ＳＮＳサイト５の他に、検索サイト、動画サイト等がある。そのようなＷｅｂサイトの種類により、望ましい広告の内容も異なるのが普通である。このことから、広告は、掲載先のＷｅｂサイトの種類に応じて生成するのが望ましい。

本実施形態では、生成した広告の掲載先への掲載、事業者情報の更新も自動的に行うようにして、顧客である事業者２にとってより高い利便性を実現させている。しかし、広告の掲載、及び事業者情報の更新は、事業者２が行うようにしても良い。それにより、事業者２が広告の掲載、事業者情報の更新を行うか否かを設定情報により共に指定可能にしても良い。事業者情報の更新案を提示することから、事業者２が事業者情報の更新を行うとしても、その更新はより容易に行えるようになる。

本実施形態で例に挙げた医療機関２は、医療分野のサービスを提供する事業者である。上記のように、対象となる事業分野は医療分野に限定されない。事業分野は、広告規制が制定されている分野であれば良い。そのような事業分野は、上述した分野の他にも存在する。
上記のようなことを含め、本実施形態は様々な変形が可能である。

１ サービス提供会社、１Ａ サーバ、２ 事業者、２Ａ 管理者端末、３ ユーザ、３Ａ ユーザ端末、４ 検索・オンライン地図サービスサイト、４Ａ サービス提供システム、５ ＳＮＳサイト、５Ａ サーバ群、５Ｂ 広告配信管理システム、２１ 送受信処理部、２２ 設定情報記憶部、２３ アクセス処理部、２４ 登録情報確認処理部、２５ 返信文生成処理部、２６ 広告生成処理部、２７ 広告確認処理部、２８ アクセス情報解析処理部、２９ 出力処理部。

Claims (7)

1. 顧客である事業者についての事業者情報を前記事業者および検索・オンライン地図サービスサイトから取得する事業者情報取得部と、
   予め定められた設定を基に、前記事業者情報を用いて、前記事業者用の広告を自動生成する広告生成部と、
   前記事業者の事業分野に存在する広告規制に、自動生成された前記広告の内容が準拠しているか否か確認する広告確認部と、
   前記広告確認部により、前記広告の内容が前記広告規制に準拠していないと確認された場合に、前記広告生成部に前記広告を前記広告規制に準拠した内容に再度、自動生成させる再生成指示部と、
   を備え、
   前記検索・オンライン地図サービスサイトは、施設情報サービスを含み、該施設情報サービスを利用する前記事業者により前記事業者情報が登録される構成とし、
   前記広告確認部は、前記広告規制に準拠していない箇所を抽出する構成とし、
   前記広告確認部および前記再生成指示部は、前記広告の再度の生成および生成された前記広告の確認を前記広告規制に準拠していない箇所が抽出できなくなるまで繰り返し行う構成とした、
   情報処理装置。
2. 前記広告規制に内容が準拠していることが前記広告確認部により確認された前記広告を、予め設定された掲載先に掲載させるための処理を行う掲載処理部、をさらに備える、
   請求項１に記載の情報処理装置。
3. 前記広告生成部は、前記事業者が、来訪者に対してサービスを提供するサービス提供事業者であった場合、前記サービス提供事業者に管理される施設に来訪する来訪日時の予約を想定したＷｅｂページへのリンクが貼られている前記広告を生成可能である、
   請求項１、または２に記載の情報処理装置。
4. 前記掲載先に掲載された前記広告に対するアクセスの内容を表すアクセス情報を取得するアクセス情報取得部と、
   前記アクセス情報を解析する解析部と、をさらに備え、
   前記広告生成部は、前記アクセス情報の解析結果を前記広告の自動生成に反映可能である、
   請求項２に記載の情報処理装置。
5. 前記事業者情報取得部が前記事業者情報を指定されたＷｅｂページから予め定められたタイミングで取得する場合に、前記事業者情報を構成する情報の確認を行い、前記事業者情報の更新案を生成可能な情報確認部と、
   前記情報確認部により前記事業者情報の前記更新案が生成された場合に、前記更新案に前記事業者情報を更新するための処理を行う更新処理部と、をさらに備える、
   請求項１、２、または４に記載の情報処理装置。
6. 前記情報確認部は、前記事業者情報を構成する情報の確認を行った結果、前記情報のうちで内容が不適切と推定可能な情報を抽出した場合に、前記更新案として、前記抽出した情報の修正案を生成可能である、
   請求項５に記載の情報処理装置。
7. 情報処理装置に、
   顧客である事業者についての事業者情報を前記事業者および検索・オンライン地図サービスサイトから取得させ、
   予め定められた設定を基に、前記事業者情報を用いて、前記事業者用の広告を自動生成させ、
   自動生成された前記広告の内容が前記事業者の事業分野に存在する広告規制に準拠していない箇所を抽出させて前記広告規制に準拠しているか否か確認させ、
   前記広告の内容が前記広告規制に準拠していないと確認された場合に、前記広告を前記広告規制に準拠した内容に再度、自動生成させ、
   前記広告の再度の生成および生成された前記広告の確認を前記広告規制に準拠していない箇所が抽出できなくなるまで繰り返し行う、
   処理を実行させるプログラムであって、
   前記検索・オンライン地図サービスサイトは、施設情報サービスを含み、該施設情報サービスを利用する前記事業者により前記事業者情報が登録される構成とした、
   プログラム。