JP2020204878A - プレスリリース配信装置、プレスリリース配信方法及びプログラム - Google Patents

Abstract

【課題】周知力が高く且つ迅速な周知を可能とするプレスリリース配信装置、プレスリリース配信方法及びプログラムを提供することにある。【解決手段】プレスリリース配信装置１００は、プレスリリース配信依頼をクライアントから受け付けるプレスリリース配信依頼受付部１１１と、ＳＮＳのインフルエンサーに対してプレスリリース配信依頼が新たに受け付けられたことを通知するプレスリリース配信制御部１４０と、前記インフルエンサーに対して前記プレスリリース配信依頼を提供するプレスリリース配信依頼提供部１２１と、前記インフルエンサーが前記プレスリリース配信依頼に係る投稿をＳＮＳに投稿した旨の報告を当該インフルエンサーから受け付ける投稿報告受付部１２２とを備えた。【選択図】図１

Description

本発明は、ネットワークを介してプレスリリースを広く周知するプレスリリース配信装置に関する。

従来、企業や組織は、企業情報・商品情報・イベント情報など各種情報を広く周知させたい場合、新聞社・放送局・出版社・通信社などの報道機関に対して周知させたい情報を提供し、報道機関が新聞・テレビ・ラジオ・雑誌・インターネットなどの各種メディアを用いて当該情報を大衆に伝達するという形態がとられている。なお、本願では、企業や組織が周知する情報そのものを「プレスリリース」と言う。また、本願では、「プレスリリース」の語を、企業や組織が情報を周知するために公開・提供する行為の意味でも用いる。プレスリリースはニュースリリースとも呼ばれる。

従来の形態では、効率的且つ効果的にプレスリリースを周知するためには、メディア及び報道機関を適切に選択することが重要である。しかし、メディア等の適切な選定には経験的知識が必要であるという問題がある。また、効率的且つ効果的にプレスリリースを周知するためには、プレスリリースを多数の報道機関に提供する必要がある。このため、企業や組織は繁雑な作業を必要としていた。

このような課題を解決するために、企業や組織から報道機関へのプレスリリースの伝達を、ネットワークに配備した配信サーバが仲介するシステムが提案されている（例えば特許文献１）。

特許第２００６−２０９４５４号公報

上述のように、従来のプレスリリースの周知形態は、最終的な大衆への伝達は報道機関が行っている。ここで、報道機関は、企業や組織から受領したプレスリリースの全てを大衆へ伝達するのではなく、報道するに値するものであると自身が判断したプレスリリースのみを大衆へ伝達する。このため、企業や組織はプレスリリースを行っても、必ずしも大衆に伝達されるとは限らない。

そこで、プレスリリースを広告という形態で周知させることが考えられる。近年ではインターネットを用いた広告が普及してきている。インターネットを用いた広告では、ポータルサイト、動画配信サイト、ＳＮＳ（Social Networking Service）サイトなど、多くの消費者がアクセスするサイトに、プレスリリースを画像や動画という形態で表示させる。しかし、当該サイトへのアクセスは消費者の意思により行われるものであり、周知力が十分でないだけでなく周知までに時間を要するという問題がある。また、近年は消費者が用いるＷｅｂブラウザ等に広告ブロック機能が設けられていることもあり、広告が表示されない場合もある。一方、メールやメッセージングソフトを用いてプレスリリースを直接配信することも考えられる。しかし、メール等ではそもそも配信先となる消費者のアドレス情報が必要であり、また消費者にとっては迷惑メールであると判断されることも多く、充分な周知ができないという問題がある。

本発明は上記事情に鑑みてなされたものであり、その目的とするところは、周知力が高く且つ迅速な周知を可能とするプレスリリース配信装置、プレスリリース配信方法及びプログラムを提供することにある。

上記目的を達成するために、本願発明は、ネットワークを介してプレスリリースを周知するプレスリリース配信装置であって、プレスリリース配信依頼をクライアントから受け付けるプレスリリース配信依頼受付部と、ＳＮＳのインフルエンサーに対してプレスリリース配信依頼が新たに受け付けられたことを通知するプレスリリース配信依頼通知部と、前記インフルエンサーに対して前記プレスリリース配信依頼を提供するプレスリリース配信依頼提供部と、前記インフルエンサーが前記プレスリリース配信依頼に係る投稿をＳＮＳに投稿した旨の報告を当該インフルエンサーから受け付ける投稿報告受付部とを備えたことを特徴とする。

本発明によれば、企業等のクライアントがプレスリリース配信装置に対してプレスリリース配信依頼を行うと、当該プレスリリース配信依頼がＳＮＳのインフルエンサーに提供される。一方、プレスリリース配信装置では、インフルエンサーがＳＮＳへのプレスリリースに係る投稿を行った報告を受け付ける。これにより、インフルエンサーによりプレスリリースのＳＮＳへの投稿が促進されるので、周知力が高いものとなる。また、本発明によれば、クライアントから新たなプレスリリース配信依頼があると、その旨がインフルエンサーに通知される。これにより、迅速な周知が期待できる。

プレスリリース配信システムの構成及びプレスリリース配信サービスの流れを説明する図 プレスリリース配信装置の機能ブロック図 クライアントＤＢのデータ構造の一例 インフルエンサーＤＢのデータ構造の一例 プレスリリースＤＢのデータ構造の一例 投稿履歴ＤＢのデータ構造の一例 プレスリリース配信依頼受付画面の一例 インフルエンサー端末に表示されたプレスリリース配信依頼リストの一例 インフルエンサー端末に表示されたプレスリリース配信依頼の詳細画面の一例 投稿完了報告に対する処理のフローチャート

本発明の一実施の形態に係るプレスリリース配信システムについて図面を参照して説明する。

［用語の説明］
本願において「運営者」とは、後述するプレスリリース配信装置を用いて「クライアント」に対してプレスリリース配信サービスを提供する者を意味する。「管理者」とは、後述するプレスリリース配信装置を管理する者を意味する。「運営者」と「管理者」とは同一の者であっても異なるものであってもよい。本実施の形態では、「運営者」と「管理者」は同一の者であるものとする。

また、「クライアント」とは、企業や組織などプレスリリースの配信を希望する者を意味する。すなわち「クライアント」は運営者からプレスリリース配信サービスの提供を受ける者である。

「インフルエンサー」とは、ＳＮＳ（Social Networking Service）のアカウントを有するＳＮＳ利用者であって、特に当該インフルエンサーのアカウントが多数の他のＳＮＳ利用者のアカウントと紐付けされており、ＳＮＳを介して世間に与える影響力が大きい者を意味する。インフルエンサーがＳＮＳに投稿したコンテンツは、インフルエンサーのアカウントに紐付けされた他のＳＮＳ利用者（フォロワーと言う）に対して公開されるだけでなく、当該フォロワーのフォロワーに対して再投稿や引用や評価等が繰り返し行われることにより、広く一般に拡散される。本願発明では、インフルエンサーによるＳＮＳへの投稿により、プレスリリースに係る情報の拡散を図るものである。ＳＮＳの具体例としては、Ｔｗｉｔｔｅｒ（登録商標）、Ｉｎｓｔａｇｒａｍ（登録商標）、Ｆａｃｅｂｏｏｋ（登録商標）などが挙げられる。

［本願発明の概要］
図１を参照して本願発明に係るプレスリリース配信システムの構成及びプレスリリース配信サービスの流れについて説明する。図１は、プレスリリース配信システムの構成及びプレスリリース配信サービスの流れを説明する図である。

プレスリリース配信システムは、図１に示すように、プレスリリース配信装置１００と、管理者が使用する管理者端末１０と、クライアントが使用するクライアント端末２０と、インフルエンサーが使用するインフルエンサー端末３０とを備えている。プレスリリース配信装置１００は、インターネットやＬＡＮ（Local Area Network）などの図示しないネットワークを介して、管理者端末１０、クライアント端末２０、インフルエンサー端末３０と通信可能である。また、少なくともインフルエンサー端末３０は、インターネットを介して任意のＳＮＳサーバ２００と通信可能である。

管理者端末１０、クライアント端末２０、インフルエンサー端末３０は、ＰＣ（Personal Computer）や、スマートフォンなどの携帯通信端末などの周知の情報処理端末により実現される。

以下、プレスリリース配信サービスの流れについて説明する。プレスリリース配信装置１００は、予めクライアントに対してクラインアント用アカウントを発行する。同様に、プレスリリース配信装置１００は、予めインフルエンサーに対してインフルエンサー用アカウントを発行する。これらの処理は、管理者が管理者端末１０を用いてプレスリリース配信装置１００に指示することにより行う（ステップＳ０）。

プレスリリース配信装置１００は、クライアント端末２０からプレスリリース配信依頼を受け付ける（ステップＳ１）。プレスリリース配信装置１００は、インフルエンサー端末３０に対して新規のプレスリリース配信依頼を受け付けたことを通知する（ステップＳ２）。また、プレスリリース配信装置１００は、アクセスしてきたインフルエンサー端末３０に対してプレスリリース配信依頼を提供する（ステップＳ３）。プレスリリース配信依頼の内容を確認したインフルエンサーは、インフルエンサー端末３０を用いてＳＮＳサーバ２００に対してプレスリリースに係る情報を投稿する（ステップＳ４）。プレスリリースをＳＮＳサーバ２００に投稿したインフルエンサーは、インフルエンサー端末３０を用いてプレスリリース配信装置１００にアクセスし、投稿完了報告を行う（ステップＳ５）。管理者は、管理者端末１０を用いてプレスリリース配信装置１００にアクセスして前記投稿完了報告を参照し、当該投稿が正当なものであるかを承認する（ステップＳ６）。このような処理により、クライアントが配信を依頼したプレスリリースは、インフルエンサーによりＳＮＳサーバ２００に投稿され、ＳＮＳの仕様に則ってＳＮＳ利用者の間に広く拡散される。

管理者（運営者）は、本プレスリリース配信サービスの対価をクライアントに請求する。クライアントは、当該請求に対して対価を管理者（運営者）に支払う。この請求処理及び支払い処理のタイミングは不問である。また、この請求処理及び支払い処理は、プレスリリース配信装置１００が行ってもよいし、他の決済サーバと連携して行ってもよい。あるいは、この請求処理及び支払い処理は、プレスリリース配信システムを介することなく、従来周知の方法により行ってもよい。

また、管理者（運営者）は、後述する報酬金を、投稿を行ったインフルエンサーに対して支払う。インフルエンサーに対する支払いは、インフルエンサーからの申請時に複数件のプレスリリースの投稿に対する報酬金をまとめて行ってもよいし、プレスリリースの投稿毎に行ってもよい。また、支払い処理は、プレスリリース配信装置１００が行ってもよいし、他の決済サーバと連携して行ってもよい。あるいは、この支払い処理は、プレスリリース配信システムを介することなく、従来周知の方法により行ってもよい。

［拡散促進のための手段］
本願発明に係るプレスリリース配信システムでは、プレスリリースの拡散力は、ＳＮＳサーバ２００に投稿するインフルエンサーの数に大きく依存する。そこで、本願発明では、以下のように、インフルエンサーに対して投稿を促進する仕組みを設けている。

プレスリリース配信装置１００は、１つのプレスリリース配信依頼について、所定の人数を上限として上記ステップＳ５の投稿完了報告が早い順（先着順）に、インフルエンサーに対して所定の金額の報酬金を付与する処理を行う。このことは、予めインフルエンサーに周知しておく。これにより、インフルエンサーには報酬金が得られるかもしれないという期待感が生じるので、インフルエンサーの投稿が促進される。しかも、報酬金が得られるものは先着順で所定の上限数に限定されているので、インフルエンサーの投稿が迅速に行われることが期待される。これにより、プレスリリースが広く且つ迅速に拡散することが期待される。なお、報酬金の支払い処理については上述したとおりである。

さらに本願発明に係るプレスリリース配信システムでは、各インフルエンサーに対して「ランク」という評価値及びポイントを設定する。インフルエンサーのランクは、初期値として最低値を設定する。また、インフルエンサーのポイントは、初期値として最低値であるゼロを設定する。プレスリリース配信装置１００は、上記ステップＳ５の投稿完了報告を受け付けると、インフルエンサーに対して所定のルールでポイントを付与する。ここで、付与ポイントは、報酬金の付与対象者よりも非付与対象者の方が大きくなるように設定する。また、プレスリリース配信装置１００は、上記ステップＳ５の投稿完了報告を受け付けると、所定の確率で、インフルエンサーに対して所定のボーナスポイントを付与する。さらに、プレスリリース配信装置１００は、上記ステップＳ５の投稿完了報告を受け付けると、インフルエンサーに対して、投稿したＳＮＳサーバ２００におけるインフルエンサーのフォロワー数に応じた所定のボーナスポイントを付与する。

プレスリリース配信装置１００は、インフルエンサーの累積ポイントに応じてランクを設定する。具体的には、累積ポイントが多いほど高いランクを設定する。このように、報酬金が得られない場合であってもポイントが得られるよう処理することで、プレスリリースの配信を開始してから時間がたってもインフルエンサーの投稿意欲が著しく低下することを防止している。

また、プレスリリース配信装置１００は、上記ステップＳ２の通知処理において、ランクに応じてインフルエンサー端末３０への通知タイミングを変動させる。具体的には、ランクが高いほど早いタイミングで通知を行う。すなわち、プレスリリース配信装置１００は、クライアント端末２０からプレスリリース配信依頼を受け付けると、まず、最も高いランクのインフルエンサーのインフルエンサー端末３０に対して通知を行う。その後、所定の時間間隔で、ランクの高い順にインフルエンサーのインフルエンサー端末３０に対して通知を行う処理を繰り返す。

このように、本願発明に係るプレスリリース配信システムでは、インフルエンサーにとっては、プレスリリースの投稿を早く行うほど報酬金が付与される確率が高くなる。そして、ランクが高いほど新着プレスリリースの通知を早く受けることができる。一方、ランクは、プレスリリースの投稿による付与されるポイントに基づき決定される。このような仕組みにより、インフルエンサーによるＳＮＳサーバ２００への投稿が促進され、拡散力が大きなものとなる。

また、プレスリリース配信装置１００は、各プレスリリース配信依頼に対して報酬金付与の上限数を設定する。この報酬金付与の上限数は、インフルエンサーからみると報酬金が得られる期待値を意味する。プレスリリース配信装置１００は、上記ステップＳ３においてプレスリリース配信依頼をインフルエンサー端末３０に提示する際に、前記期待値に対応した表示、すなわち前記上限数に対応した表示を付与する。例えば、上限数が１０人のときはハートマークを１つ表示し、上限数が３０人のときにはハートマークを２つ表示し、上限数が１００人のときにはハートマークを３つ表示する等である。そして、管理者（運営者）は、予めインフルエンサーに対して、上限数に対応する表示（ハートマーク）によって報酬金が付与される期待値が異なることを周知しておく。これにより、上限数の表示によってインフルエンサーの関心度を制御し、結果として拡散力を制御することができる。すなわち、報酬金付与の上限数が高いほど拡散力が大きくなる。そこで、本願発明では、報酬金付与の上限数に応じて、クライアントに請求する料金を設定する。クライアントは、前記ステップＳ１におけるプレスリリース配信依頼において、報酬金を付与可能な上限数に対応する料金プランを選択することができる。換言すれば、料金プランにより、報酬金を付与可能な上限数が決定される。

［プレスリリース配信装置の詳細］
次に、図２を参照してプレスリリース配信装置の詳細について説明する。図２はプレスリリース配信装置の機能ブロック図である。

プレスリリース配信装置１００は、図２に示すように、クライアントＤＢ１０１と、インフルエンサーＤＢ１０２と、プレスリリースＤＢ１０３と、投稿履歴ＤＢ１０４と、クライアント用インタフェース１１０と、インフルエンサー用インタフェース１２０と、管理者用インタフェース１３０と、プレスリリース配信制御部１４０と、ＳＮＳ情報収集部１５０とを備えている。

プレスリリース配信装置１００は、サーバ装置など周知の情報処理装置により構成される。プレスリリース配信装置１００の実装形態は不問であり、例えば各部を複数のハードウェア装置に分散して実装してもよい。典型的には、プレスリリース配信装置１００は、インターネット上に配備されたクラウドサーバに実装される。プレスリリース配信装置１００は、例えば、コンピュータにプログラムをインストールすることにより実装される。

クライアントＤＢ１０１のデータ構造の一例について図３を参照して説明する。クライアントＤＢ１０１は、クライアントに関する各種情報を記憶するものであり、図３に示すように、クライアントを一意に識別するクライアントＩＤ、パスワード等の認証情報、名前、住所、電話番号、メールアドレス等の情報を記憶する。

インフルエンサーＤＢ１０２のデータ構造の一例について図４を参照して説明する。インフルエンサーＤＢ１０２は、インフルエンサーに関する各種情報を記憶するものであり、図４に示すように、インフルエンサーを一意に識別するインフルエンサーＩＤ、パスワード等の認証情報、名前、住所、電話番号、メールアドレス、性別、生年月日、興味のあるカテゴリー、報酬を受け取るための口座番号などの金融機関情報などインフルエンサーの属性情報を記憶する。インフルエンサーＤＢ１０２は、少なくとも、インフルエンサーに対する通知を受領するための通知先アドレス情報を含む。前述の電話番号やメールアドレスがこの通知先アドレス情報に該当する。興味のあるカテゴリーは、複数記憶してもよい。この場合、１つを主カテゴリーとして記憶し、他を副カテゴリーとして記憶してもよい。

また、インフルエンサーＤＢ１０２は、さらに、インフルエンサーが利用する各ＳＮＳにおけるアカウント（ユーザＩＤ）、当該アカウントのフォロワー数など、インフルエンサーのＳＮＳ情報を記憶する。ＳＮＳ情報は、複数のＳＮＳについて記憶することができる。本実施の形態では、ＳＮＳ情報は、ＳＮＳ（Ａ）とＳＮＳ（Ｂ）の情報について記憶する。

また、インフルエンサーＤＢ１０２は、さらに、現在のランク・ポイント・報酬金残高、出金履歴情報等、本プレスリリース配信システムにおけるインフルエンサーのステータス情報を記憶する。ここで、ステータス情報は、インフルエンサーの登録状況を示す情報であり、「審査前」、「承認」、「却下」というステータスから選択される。

プレスリリースＤＢ１０３のデータ構造の一例について図５を参照して説明する。プレスリリースＤＢ１０３は、クライアント端末２０から受け付けたプレスリリース配信依頼に関する各種情報を記憶するものであり、図５に示すように、プレスリリース配信依頼を一意に識別するプレスリリースＩＤと、依頼元であるクライアントのクライアントＩＤと、プレスリリースタイトル、料金プラン情報、投稿用プレスリリーステキスト・投稿用ハッシュタグ・ＳＮＳにおけるメンション用アカウント・投稿用ＵＲＬ（Uniform Resource Locator）・投稿用画像などの投稿用情報、プレスリリース原文、配信期間、配信ステータス、依頼受付日時等の情報を記憶する。

ここで、投稿用情報は、インフルエンサーがＳＮＳサーバ２００に投稿する際に参照される情報である。換言すれば、投稿用情報は、クライアントがインフルエンサーに対して希望する投稿内容の一例を示すものである。インフルエンサーは、投稿先のＳＮＳサーバ２００の仕様に応じて、投稿用情報に含まれる各情報を適宜選択するとともに、必要に応じて適宜編集を行ったうえで、ＳＮＳサーバ２００に投稿を行う。

投稿用プレスリリーステキストは、プレスリリース原文の要約であり、所定の文字数に制限されている。これは、ＳＮＳの種類によっては投稿文字数が制限されているためである。投稿用プレスリリーステキストは、複数のＳＮＳ毎に記憶してもよい。なお、インフルエンサーは、ＳＮＳサーバ２００に対して、当該投稿用プレスリリーステキストをそのまま投稿してもよいし、投稿用プレスリリースやプレスリリース原文等を参照して自身で編集して投稿してもよい。

投稿用ハッシュタグは、ＳＮＳサーバ２００において検索や集計等で用いられるキーワードである。メンション用アカウントは、ＳＮＳサーバ２００において投稿に関連付けられたアカウントを示すものであり、通常は当該ＳＮＳサーバ２００におけるクライアントの有するアカウントである。

投稿用ＵＲＬは、ＳＮＳサーバ２００への投稿時に、投稿用プレスリリーステキストと共に投稿される情報であり、プレスリリースに関連する情報が掲載されたＷｅｂページのＵＲＬである。当該投稿用ＵＲＬは、例えば、新製品に関するプレスリリース配信依頼の場合、クライアントが自身のＷｅｂサイト等に掲載したプレスリリースのＵＲＬや、当該新製品の情報を掲載したページのＵＲＬである。

投稿用画像は、ＳＮＳサーバ２００への投稿時に、投稿用プレスリリーステキストと共に投稿される情報である。

プレスリリース原文は、クライアントが周知したいプレスリリースそのものであり、テキストや画像等の情報からなる。プレスリリース原文は、例えば、クライアントが自信のＷｅｂサイト等に掲載したプレスリリースのコピーである。

配信期間とは、クライアントがインフルエンサーへのプレスリリース配信を希望する期間を意味する。すなわち、この配信期間は、プレスリリース配信装置１００が当該プレスリリース配信依頼をインフルエンサーに提供する期間である。なお、インフルエンサーによりＳＮＳサーバ２００に投稿されたプレスリリースに関する情報は、ＳＮＳサーバ２００の仕様やＳＮＳ利用者による行動によりＳＮＳサーバ２００上で拡散するが、この拡散期間と前記配信期間は無関係である点に留意されたい。前記配信期間は、配信開始日時と配信終了日時を含む。

配信ステータスは、プレスリリース配信依頼の経時的な処理段階を示すものである。本実施の形態では、配信ステータスは、「下書き」、「審査待ち」、「配信前」、「配信中」、「配信済」というステータスから選択される。

「下書き」は、クライアントがクライアント端末２０を用いてプレスリリース配信装置１００に対してプレスリリース配信依頼に係る各情報を入力している途中であり、まだ正式に配信依頼を行っていない段階を意味する。「審査待ち」は、クライアントが入力したプレスリリース配信依頼に対して、管理者による審査が未だ完了していない段階を意味する。「配信前」は、管理者による審査が終了したが、未だ配信期間が到来していない段階を意味する。「配信中」は、インフルエンサーに対してプレスリリース配信依頼を提供している段階を意味する。「配信済」は、配信期間が終了した段階を意味する。

なお、プレスリリースＤＢ１０３は、さらに、ＳＮＳサーバ２００の投稿を行うインフルエンサーを絞り込むための配信条件情報を記憶してもよい。配信条件情報としては、例えば、インフルエンサーの性別、年齢、住所、興味のあるカテゴリー、ＳＮＳ種別、フォロワー数などの各種情報を任意に組み合わせることができる。

投稿履歴ＤＢ１０４のデータ構造の一例について図６を参照して説明する。投稿履歴ＤＢ１０４は、インフルエンサー端末３０から受け付けたプレスリリースの投稿完了報告を記憶するものであり、図６に示すように、投稿完了報告を一意に識別する投稿完了報告ＩＤと、前述のプレスリリースＩＤと、投稿を行ったインフルエンサーのインフルエンサーＩＤと、投稿先のＳＮＳ種別と、ＳＮＳサーバ２００における投稿のＵＲＬと、報告受付日時、投稿ステータス等の情報を記憶する。

ここで、投稿ステータスは、投稿完了報告の経時的な処理段階又は状態を示すものである。本実施の形態では、投稿ステータスは、「承認前」、「承認」、「却下」というステータスから選択される。

「承認前」は、インフルエンサーが報告した投稿完了報告に対して、管理者による審査が未だ完了していない段階を意味する。「承認」は、管理者による審査の結果、インフルエンサーによるＳＮＳサーバ２００への投稿が正当である状態を意味する。「却下」は、管理者による審査の結果、インフルエンサーによるＳＮＳサーバ２００への投稿が正当でない状態を意味する。なお、管理者による審査の内容は、投稿内容に指定のハッシュタグやＵＲＬが含まれているか否か等の形式的・書式的なもののほか、投稿内容がプレスリリースの内容が正確に記載されているか否か、表現が適切であるか否かなど実体的なものを含んでいてもよい。

クライアント用インタフェース１１０は、クライアント端末２０とのインタフェースである。クライアント用インタフェース１１０とクライアント端末２０との間のインタフェース形態は不問である。本実施の形態では、Ｗｅｂインタフェースにより両者間の通信を実現している。このため、クライアント端末２０は、周知のＷｅｂブラウザが実装された汎用的な情報処理端末であればよい。

クライアント用インタフェース１１０は、図２に示すように、プレスリリース配信依頼受付部１１１と、クライアント用管理部１１９とを備えている。また、クライアント用インタフェース１１０は、図示しない認証処理部を備えており、クライアントＤＢ１０１を参照してクライアントの認証処理を行う。

プレスリリース配信依頼受付部１１１は、クライアント端末２０からプレスリリース配信依頼を受け付ける。プレスリリース配信依頼は、プレスリリースタイトル、料金プラン情報、投稿用プレスリリーステキスト・投稿用ハッシュタグ・ＳＮＳにおけるメンション用アカウント・投稿用ＵＲＬ・投稿用画像などの投稿用情報、プレスリリース原文、配信期間を含む。プレスリリース配信依頼受付部１１１は、例えば、図７に示すようなプレスリリース配信依頼受付画面をクライアント端末２０に表示させ、クライアント端末２０から入力された情報を受け付ける。

プレスリリース配信依頼受付部１１１は、クライアントからの「申請する」との指示により、当該プレスリリース配信依頼に対してプレスリリースＩＤを付与し、認証処理により取得したクライアントＩＤ、「審査待ち」との配信ステータス、現在日時とともに、入力された情報をプレスリリースＤＢ１０３に記憶する。なお、クライアントがプレスリリース配信依頼を一時的にプレスリリース配信装置１００に保存しておきたいときは、プレスリリース配信依頼受付部１１１に対して「下書きを保存する」と指示する。これに対して、プレスリリース配信依頼受付部１１１は、配信ステータスとして「下書き」に設定して、入力された情報をプレスリリースＤＢ１０３に保存する。

クライアント用管理部１１９は、クライアント及びそのプレスリリース配信依頼に関するその他の各種機能を提供する。例えば、クライアント情報の登録・編集・閲覧機能、プレスリリース配信依頼の履歴参照機能を提供する。クライアント情報の登録・編集・閲覧機能は、主として、クライアントＤＢ１０１に対して情報処理を行う。また、プレスリリース配信依頼の履歴参照機能は、主として、プレスリリースＤＢ１０３及び投稿履歴ＤＢ１０４並びにインフルエンサーＤＢ１０２を参照して、一覧リストや個別情報リストという形態で情報をクライアント端末２０に提供する。情報提示の形態は不問である。また、必要に応じて、情報の加工（統計的処理やプライバシー保護のための処理）を行ってもよい。例えば、プレスリリース配信依頼についてＳＮＳサーバ２００の投稿状況、特に、インフルエンサーによる投稿数、及び、当該投稿数がインフルエンサーのフォロワーを介して拡散されたＳＮＳ利用者の数（リーチ数）などをクライアント端末２０に提供する。このように、クライアントは、プレスリリース配信依頼の進捗状況や配信結果を確認することができる。

インフルエンサー用インタフェース１２０は、インフルエンサー端末３０とのインタフェースである。インフルエンサー用インタフェース１２０とインフルエンサー端末３０との間のインタフェース形態は不問である。本実施の形態では、Ｗｅｂインタフェース及びインフルエンサー端末３０にインストールした専用アプリケーションにより両者間の通信を実現している。このため、インフルエンサー端末３０は、周知のＷｅｂブラウザが実装された汎用的な情報処理端末に専用アプリケーションをインストールしている。

インフルエンサー用インタフェース１２０は、図２に示すように、プレスリリース配信依頼提供部１２１と、投稿完了報告受付部１２２と、インフルエンサー用管理部１２９とを備えている。また、インフルエンサー用インタフェース１２０は、図示しない認証処理部を備えており、インフルエンサーＤＢ１０２を参照してインフルエンサーの認証処理を行う。

プレスリリース配信依頼提供部１２１は、配信期間内にあるプレスリリース配信依頼をプレスリリースＤＢ１０３から抽出し、インフルエンサー端末３０に対して提供する。ここで、プレスリリース配信依頼提供部１２１は、インフルエンサー端末３０からの指示に応じて、プレスリリース配信依頼のリスト又はプレスリリース配信依頼毎の詳細情報を提供する。インフルエンサー端末３０は、提供されたプレスリリース配信依頼のリストを表示し、当該リストから任意のプレスリリース配信依頼を１つ選択することにより詳細情報を個別に表示することができる。

なお、プレスリリース配信依頼提供部１２１は、プレスリリース配信依頼に条件情報が含まれている場合、当該条件を満たすインフルエンサーのインフルエンサー端末３０に対してプレスリリース配信依頼を提示する。図８はインフルエンサー端末に表示されたプレスリリース配信依頼のリストの一例、図９はインフルエンサー端末に表示されたプレスリリース配信依頼の詳細情報の一例である。図８の例では、１つのプレスリリース配信依頼について画像とタイトルの組を表示している。インフルエンサーは、図９に示す詳細情報を参照することにより、自身が利用する所定のＳＮＳサーバ２００に投稿する。

ここで、プレスリリース配信依頼提供部１２１は、図８及び図９に示すように、プレスリリース配信依頼について、報酬金が得られる期待値に対応した表示、すなわち報酬金付与の上限数に対応した表示を付与する。図８及び図９の例では、ハートマークの数が期待値に対応する。

なお、プレスリリース配信依頼のリストの順序については不問である。本実施の形態では、プレスリリース配信依頼の依頼受付日時順（降順）としたが、他のルールによって順序を決定してもよい。例えば、プレスリリース配信依頼についての前記期待値の順や料金プランの順としてもよい。

また、プレスリリース配信依頼提供部１２１は、インフルエンサー端末３０からの指示により投稿完了報告受付部１２２に処理を移行する。図９の例では、プレスリリース配信依頼提供部１２１は、インフルエンサー端末３０において「投稿完了報告」ボタンの押下を検出すると、投稿完了報告受付部１２２に処理を移行する。

投稿完了報告受付部１２２について図１０のフローチャートを参照して説明する。投稿完了報告受付部１２２は、図１０に示すように、インフルエンサー端末３０からＳＮＳサーバ２００への投稿完了報告を受け付ける（ステップＳ１０１）。この投稿完了報告は、ＳＮＳサーバ２００において投稿を個別に表示するためのＵＲＬを含む。投稿完了報告受付部１２２は、投稿完了報告を受け付けると、投稿ステータスを「承認前」に設定して投稿履歴ＤＢ１０４に記憶する（ステップＳ１０２）。ここで、インフルエンサーＩＤは、前述した認証処理により取得する。また、本実施の形態では、投稿完了報告受付部１２２はプレスリリース配信依頼提供部１２１からの処理の移行により機能するので、プレスリリースＩＤは当該移行時にプレスリリース配信依頼提供部１２１から引き継ぐかたちで取得する。

また、本実施の形態では、投稿完了報告受付部１２２はプレスリリース配信依頼提供部１２１からの処理の移行により機能するので、投稿完了報告を受け付け可能な期間は、プレスリリース配信依頼をインフルエンサー端末３０に提供する期間、すなわちプレスリリース配信依頼の配信期間と一致する。

後述するように、管理者は管理者端末１０を用いて投稿完了報告の審査を行い、投稿ステータスを「承認」又は「却下」に変更する（ステップＳ１０３）。投稿完了報告受付部１２２は、投稿ステータスが「承認」に変更された投稿完了報告に対して、以下のような処理を行う（ステップＳ１０４）。

投稿完了報告受付部１２２は、投稿完了報告が先着順で所定の報酬金付与の上限数の範囲内にある場合には、インフルエンサーに対して所定の報酬金を付与するとともに、所定のポイントを付与する（ステップＳ１０５，Ｓ１０６）。ここで、報酬金付与の上限数は、前述したようにプレスリリース配信依頼の料金プランにより決定される。一方、投稿完了報告の順序が所定の報酬金付与の上限数の範囲を超える場合には、インフルエンサーに対して所定のポイントのみを付与する（ステップＳ１０７）。ここで付与するポイントは、前記ステップＳ１０６で報酬金付与対象者に付与するポイントよりも大きく設定する。

次に、投稿完了報告受付部１２２は、インフルエンサーに対して、投稿したＳＮＳサーバ２００における当該インフルエンサーのフォロワー数に応じた追加のボーナスポイントを付与する（ステップＳ１０８）。次に、投稿完了報告受付部１２２は、所定の確率で、インフルエンサーに対して追加のポイントを付与する（ステップＳ１０８）。

次に、投稿完了報告受付部１２２は、インフルエンサーの累積ポイントに応じて、当該インフルエンサーのランクを変更する（ステップＳ１０９）。

なお、インフルエンサーに対する報酬金及びポイントの付与、並びにランクの変更は、インフルエンサーＤＢ１０２を更新することにより行う。

インフルエンサー用管理部１２９は、インフルエンサー及びその投稿完了報告に関する各種機能を提供する。例えば、インフルエンサー情報の登録・編集・閲覧機能、投稿完了報告の履歴参照機能、報酬金の出金申請機能を提供する。インフルエンサー情報の登録・編集・閲覧機能は、主として、インフルエンサーＤＢ１０２に対して情報処理を行う。また、投稿完了報告の履歴参照機能は、主として、プレスリリースＤＢ１０３及び投稿履歴ＤＢ１０４を参照して、一覧リストや個別情報リストという形態で情報をインフルエンサー端末３０に提供する。情報提示の形態は不問である。また、報酬金の出金申請機能は、主として、インフルエンサーＤＢ１０２の出金履歴情報に対して情報処理を行う。

管理者用インタフェース１３０は、管理者端末１０とのインタフェースである。管理者用インタフェース１３０と管理者端末１０との間のインタフェース形態は不問である。本実施の形態では、Ｗｅｂインタフェースにより両者間の通信を実現している。このため、管理者端末１０は、周知のＷｅｂブラウザが実装された汎用的な情報処理端末であればよい。

管理者用インタフェース１３０は、図２に示すように、管理者用管理部１３９を備えている。また、管理者用インタフェース１３０は、図示しない認証処理部を備えており、管理者の認証処理を行う。

管理者用管理部１３９は、クライアントＤＢ１０１、インフルエンサーＤＢ１０２、プレスリリースＤＢ１０３、投稿履歴ＤＢ１０４に対する各種情報の登録・編集・閲覧機能など、システム全体の各種管理機能を提供する。

特に、管理者用管理部１３９は、上述したように、プレスリリースＤＢ１０３に記憶された配信ステータスが「審査待ち」であるプレスリリース配信依頼を管理者端末１０に提示し、必要に応じてプレスリリース配信依頼に係る情報を編集し、配信ステータスを「配信前」に更新する機能を提供する。ここで、管理者用管理部１３９は、審査結果をクライアントにメール等を用いて通知する。

また、管理者用管理部１３９は、上述したように、投稿履歴ＤＢ１０４に記憶された投稿ステータスが「承認前」の完了投稿報告を管理者端末１０に提示し、必要に応じて投稿完了報告を編集し、投稿ステータスを「承認」又は「却下」に更新する機能を提供する。ここで、管理者用管理部１３９は、審査結果をインフルエンサーにメール等を用いて通知する。

また、管理者用管理部１３９は、インフルエンサーＤＢ１０２の出金履歴情報を参照して、報酬金の出金申請を管理者端末１０に提示し、出金処理を行う機能を提供する。

プレスリリース配信制御部１４０は、プレスリリースＤＢ１０３の各プレスリリース配信依頼を監視し、配信ステータスが「配信前」であり、且つ、現在日時が配信期間内に入ったプレスリリース配信依頼を抽出すると、当該プレスリリース配信依頼の配信ステータスを「配信中」に更新するとともに後述する通知処理を行う。これにより、当該プレスリリース配信依頼はプレスリリース配信依頼提供部１２１によりインフルエンサー端末３０に対して提供可能な状態になる。

前記通知処理では、プレスリリース配信制御部１４０は、インフルエンサーＤＢ１０２に記憶されている各インフルエンサーの通知先アドレス情報に対して、新たなプレスリリース配信依頼が受け付けられたことを示すメッセージを通知する。ここで、プレスリリース配信制御部１４０は、インフルエンサーのランクに応じてメッセージの送信タイミングを決定する。具体的には、ランクが高いほど早いタイミングで通知を行う。すなわち、プレスリリース配信制御部１４０は、まず、最も高いランクのインフルエンサーのインフルエンサー端末３０に対して通知を行う。その後、所定の時間間隔（例えば１分）で、ランクの高い順にインフルエンサーのインフルエンサー端末３０に対して通知を行う処理を繰り返す。この通知はインフルエンサー端末３０の専用アプリケーションにより受領され、インフルエンサー端末３０において所定の通知処理が行われる。

また、プレスリリース配信制御部１４０は、プレスリリースＤＢ１０３の各プレスリリース配信依頼を監視し、配信ステータスが「配信中」であり、且つ、現在日時が配信期間を経過したプレスリリース配信依頼を抽出すると、当該プレスリリース配信依頼の配信ステータスを「配信済」に更新する。これにより、プレスリリース配信依頼提供部１２１によるインフルエンサー端末３０に対するプレスリリース配信依頼の提供が終了する。

ＳＮＳ情報収集部１５０は、定期的にＳＮＳサーバ２００にアクセスし、インフルエンサーＤＢ１０２に記憶されている各インフルエンサーのアカウントについてフォロワー数を取得し、取得したフォロワー数でインフルエンサーＤＢ１０２を更新する。

このようなプレスリリース配信システムによれば、企業等のクライアントがプレスリリース配信装置１００に対してプレスリリース配信依頼を行うと、当該プレスリリース配信依頼がＳＮＳのインフルエンサーに提供される。一方、プレスリリース配信装置１００では、インフルエンサーがＳＮＳへのプレスリリースに係る投稿を行った報告を受け付ける。これにより、インフルエンサーによりプレスリリースのＳＮＳへの投稿が促進されるので、周知力が高いものとなる。また、本発明によれば、クライアントから新たなプレスリリース配信依頼があると、その旨がインフルエンサーに通知される。これにより、迅速な周知が期待できる。

特に、本実施の形態に係るプレスリリース配信システムでは、インフルエンサーに対して投稿完了報告の先着順で報酬金を付与しているので、迅速な周知が期待できる。また、本実施の形態に係るプレスリリース配信システムでは、投稿完了報告毎にポイントを付与し、当該ポイントにインフルエンサーにランクを設定し、当該ランクが高いほど新着プレスリリース配信依頼の通知を早く送出しているので、さらに迅速な周知が期待できる。

以上、本発明の一実施の形態について詳述したが、本発明は上記実施の形態に限定されるものではなく、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよい。

例えば、上記実施の形態では、プレスリリース配信依頼に対して管理者が審査を行っているが、人工知能技術などを用いて当該審査を処理するようにしてもよい。投稿完了報告の審査についても同様である。

また、上記実施の形態では、本プレスリリース配信システムを利用できるインフルエンサーの条件については特に設定していないが、所定の条件を満たすインフルエンサーのみが本プレスリリース配信システムを利用できるようにしてもよい。例えば、ＳＮＳサーバ２００においてフォロワー数が所定数以上であるインフルエンサーのみに限定することなどが考えられる。

また、上記実施の形態では、料金プランは報酬金の付与上限数に連動させていたが、その他の要件と連動させるようにしてもよい。例えば、前記付与条件数に加えて、配信期間、提供対象のインフルエンサーの条件（性別、年齢、地域等）、ランダムで付与する追加のポイントの確率などの任意の要件と料金プランを変動させるようにしてもよい。また、料金プランは定額制にしてもよい。

１０…管理者端末
２０…クライアント端末
３０…インフルエンサー端末
１００…プレスリリース配信装置
１０１…クライアントＤＢ
１０２…インフルエンサーＤＢ
１０３…プレスリリースＤＢ
１０４…投稿履歴ＤＢ
１１０…クライアント用インタフェース
１１１…プレスリリース配信依頼受付部
１１９…クライアント用管理部
１２０…インフルエンサー用インタフェース
１２１…プレスリリース配信依頼提供部
１２２…投稿完了報告受付部
１２９…クライアント用管理部
１３０…管理者用インタフェース
１３９…管理者用管理部
１４０…プレスリリース配信制御部
１５０…ＳＮＳ情報取得部
２００…ＳＮＳサーバ

上記目的を達成するために、本願発明は、ネットワークを介してプレスリリースを周知するプレスリリース配信装置であって、プレスリリース配信依頼をクライアントから受け付けるプレスリリース配信依頼受付部と、ＳＮＳのインフルエンサーの通知先アドレスに対してプレスリリース配信依頼が新たに受け付けられたことを通知するプレスリリース配信依頼通知部と、アクセスしてきた前記インフルエンサーに対して前記プレスリリース配信依頼を提供するプレスリリース配信依頼提供部と、前記インフルエンサーが前記プレスリリース配信依頼に係る投稿をＳＮＳに投稿した旨の報告を当該インフルエンサーから受け付け、前記インフルエンサーによる投稿報告の実績に基づき当該インフルエンサーのランクを設定するとともに、前記インフルエンサーによる投稿報告の先着順に所定の上限数の範囲内で当該インフルエンサーに対して報酬金を付与するよう設定する投稿報告受付部とを備え、前記プレスリリース配信依頼通知部は、前記ランクに基づきインフルエンサーへの通知のタイミングを決定する
ことを特徴とする。

インフルエンサーＤＢ１０２のデータ構造の一例について図４を参照して説明する。インフルエンサーＤＢ１０２は、インフルエンサーに関する各種情報を記憶するものであり、図４に示すように、インフルエンサーを一意に識別するインフルエンサーＩＤ、パスワード等の認証情報、名前、住所、電話番号、メールアドレス、性別、生年月日、興味のあるカテゴリー、報酬を受け取るための口座番号などの金融機関情報などインフルエンサーの属性情報を記憶する。インフルエンサーＤＢ１０２は、少なくとも、インフルエンサーに対する通知を当該インフルエンサーが受領するための通知先アドレス情報を含む。前述の電話番号やメールアドレスがこの通知先アドレス情報に該当する。興味のあるカテゴリーは、複数記憶してもよい。この場合、１つを主カテゴリーとして記憶し、他を副カテゴリーとして記憶してもよい。

Claims (10)

1. ネットワークを介してプレスリリースを周知するプレスリリース配信装置であって、
   プレスリリース配信依頼をクライアントから受け付けるプレスリリース配信依頼受付部と、
   ＳＮＳのインフルエンサーに対してプレスリリース配信依頼が新たに受け付けられたことを通知するプレスリリース配信依頼通知部と、
   前記インフルエンサーに対して前記プレスリリース配信依頼を提供するプレスリリース配信依頼提供部と、
   前記インフルエンサーが前記プレスリリース配信依頼に係る投稿をＳＮＳに投稿した旨の報告を当該インフルエンサーから受け付ける投稿報告受付部とを備えた
   ことを特徴とするプレスリリース配信装置。
2. 前記投稿報告受付部は、前記インフルエンサーによる投稿報告の実績に基づき当該インフルエンサーのランクを設定し、
   前記プレスリリース配信依頼通知部は、前記ランクに基づきインフルエンサーへの通知のタイミングを決定する
   ことを特徴とする請求項１記載のプレスリリース配信装置。
3. 前記投稿報告受付部は、前記インフルエンサーによる投稿報告の実績に基づき所定のルールで当該インフルエンサーにポイントを付与し、当該インフルエンサーに付与されたポイントの累積に基づき前記ランクを設定する
   ことを特徴とする請求項２記載のプレスリリース配信装置。
4. 前記投稿報告受付部は、前記インフルエンサーによる投稿報告の先着順に所定の上限数の範囲内で当該インフルエンサーに対して報酬金を付与する
   ことを特徴とする請求項３記載のプレスリリース配信装置。
5. 前記投稿報告受付部は、前記インフルエンサーによる投稿報告の順位が前記所定の上限数の範囲を超えるインフルエンサーに対して、前記所定の上限数の範囲内であるインフルエンサーよりも大きなポイントを付与する
   ことを特徴とする請求項４記載のプレスリリース配信装置。
6. 前記プレスリリース配信依頼受付部は、クライアントに請求する料金に応じて前記上限数を設定するとともに、
   前記プレスリリース配信依頼提供部は、プレスリリース配信依頼に対して前記上限数に対応する表示を付与する
   ことを特徴とする請求項４又は５記載のプレスリリース配信装置。
7. 前記投稿報告受付部は、投稿報告毎に所定の確率でインフルエンサーに追加のポイントを付与する
   ことを特徴とする請求項３乃至６何れか１項記載のプレスリリース配信装置。
8. 前記投稿報告受付部は、投稿報告毎にインフルエンサーのＳＮＳにおけるフォロワー数に応じて追加のポイントを付与する
   ことを特徴とする請求項３乃至７何れか１項記載のプレスリリース配信装置。
9. プレスリリース配信装置がネットワークを介してプレスリリースを周知するプレスリリース配信方法であって、
   プレスリリース配信依頼をクライアントから受け付けるプレスリリース配信依頼受付ステップと、
   ＳＮＳのインフルエンサーに対してプレスリリース配信依頼が新たに受け付けられたことを通知するプレスリリース配信依頼ステップと、
   前記インフルエンサーに対して前記プレスリリース配信依頼を提供するプレスリリース配信依頼提ステップと、
   前記インフルエンサーが前記プレスリリース配信依頼に係る投稿をＳＮＳに投稿した旨の報告を当該インフルエンサーから受け付ける投稿報告受付ステップとを備えた
   ことを特徴とするプレスリリース配信方法。
10. コンピュータを請求項１乃至８何れか１項記載のプレスリリース配信装置の各部として機能させる
    ことを特徴とするプレスリリース配信プログラム。

Images