特開 2024-107561 情報処理システム、情報処理方法及び情報処理プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024107561

(43)【公開日】2024-08-09

(54)【発明の名称】情報処理システム、情報処理方法及び情報処理プログラム

(51)【国際特許分類】

   G06Q 30/0251 20230101AFI20240802BHJP

【ＦＩ】

G06Q30/0251

【審査請求】有

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023011548

(22)【出願日】2023-01-30

(71)【出願人】

【識別番号】520337558

【氏名又は名称】株式会社ＦＡＮＡＴＩＣ

(74)【代理人】

【識別番号】100145838

【弁理士】

【氏名又は名称】畑添 隆人

(74)【代理人】

【識別番号】100103137

【弁理士】

【氏名又は名称】稲葉 滋

(74)【代理人】

【識別番号】100216367

【弁理士】

【氏名又は名称】水谷 梨絵

(72)【発明者】

【氏名】野田 大介

【テーマコード（参考）】

5L030

5L049

【Ｆターム（参考）】

5L030BB08

5L049BB08

(57)【要約】

【課題】ユーザが望む対象に係る情報の通知を、簡便な手続きで受け取り可能とすることを課題とする。
【解決手段】情報処理システム５に、顧客のユーザ端末から外部ＳＮＳに保持されている顧客に係るリソースへのアクセスを認可するための認可処理の開始指示を受信した場合に、ユーザ端末を外部ＳＮＳによって提供される認可処理のためのＡＰＩにアクセスさせるアクセス指示部６１と、認可が得られた場合に、外部ＳＮＳから顧客のＳＮＳユーザＩＤを取得するＳＮＳユーザＩＤ取得部６３と、顧客が関連情報の通知を希望するフォロー対象の対象ＩＤを特定する対象ＩＤ特定部６４と、顧客のＳＮＳユーザＩＤを対象ＩＤに紐付ける紐付け部６５と、を備えた。
【選択図】図２

【特許請求の範囲】

【請求項1】

顧客のユーザ端末から、外部ＳＮＳに保持されている該顧客に係るリソースへのアクセスを認可するための認可処理の開始指示を受信した場合に、該ユーザ端末を、該外部ＳＮＳによって提供される前記認可処理のためのＡＰＩにアクセスさせる、アクセス指示手段と、
前記認可が得られた場合に、前記外部ＳＮＳから、該外部ＳＮＳにおける前記顧客のＳＮＳユーザＩＤを取得するＳＮＳユーザＩＤ取得手段と、
前記顧客が関連情報の通知を希望する対象であるフォロー対象の対象ＩＤを特定する対象ＩＤ特定手段と、
前記顧客のＳＮＳユーザＩＤを、前記対象ＩＤに紐付ける紐付け手段と、
を備える情報処理システム。

【請求項2】

前記開始指示と併せて前記ユーザ端末から送信された、前記対象に関連する情報を、前記ユーザ端末を識別可能な情報と紐付けて保存する関連情報保存手段を更に備え、
前記対象ＩＤ特定手段は、前記ＳＮＳユーザＩＤ取得手段によって前記顧客のＳＮＳユーザＩＤが取得されたことを契機として、前記関連情報保存手段によって保存された情報に基づいて、前記開始指示に紐付けられたフォロー対象の対象ＩＤを特定する、
請求項１に記載の情報処理システム。

【請求項3】

前記関連情報保存手段は、前記開始指示と併せて前記ユーザ端末から送信された、該開始指示を該ユーザ端末に送信させるための第一のプログラムを含むＷｅｂページのアドレス情報を、前記ユーザ端末を識別可能な情報と紐付けて保存し、
前記対象ＩＤ特定手段は、
前記ＳＮＳユーザＩＤ取得手段によって前記顧客のＳＮＳユーザＩＤが取得されたことを契機として、前記関連情報保存手段によって保存された、前記ユーザ端末に係る前記Ｗｅｂページのアドレス情報を特定し、
前記ユーザ端末に対して、前記ＳＮＳユーザＩＤを特定可能な情報を通知し、
通知された前記ＳＮＳユーザＩＤを特定可能な情報及び前記対象ＩＤの組み合わせを該ユーザ端末から受信し、前記開始指示に紐付けられたフォロー対象の対象ＩＤを特定する、
請求項２に記載の情報処理システム。

【請求項4】

前記対象ＩＤ特定手段は、通知された前記ＳＮＳユーザＩＤを特定可能な情報を、前記Ｗｅｂページに含まれる前記対象ＩＤと組み合わせて該情報処理システムに対して送信させるための、該Ｗｅｂページに含まれる第二のプログラムを前記ユーザ端末に実行させることで、前記ＳＮＳユーザＩＤを特定可能な情報及び前記対象ＩＤの組み合わせを該ユーザ端末から受信し、前記開始指示に紐付けられたフォロー対象の対象ＩＤを特定する、
請求項３に記載の情報処理システム。

【請求項5】

前記関連情報保存手段は、前記開始指示と併せて前記ユーザ端末から送信された、該開始指示を該ユーザ端末に送信させるためのプログラムに含まれる前記対象ＩＤを、前記ユーザ端末を識別可能な情報と紐付けて保存し、
前記対象ＩＤ特定手段は、前記ＳＮＳユーザＩＤ取得手段によって前記顧客のＳＮＳユーザＩＤが取得されたことを契機として、前記関連情報保存手段によって保存された前記ユーザ端末に係る前記対象ＩＤを特定することで、前記開始指示に紐付けられたフォロー対象の対象ＩＤを特定する、
請求項２に記載の情報処理システム。

【請求項6】

前記開始指示は、前記ユーザ端末において前記対象が紐付けられた操作要素が顧客によって操作されたことに応じて該ユーザ端末から送信された開始指示である、
請求項１に記載の情報処理システム。

【請求項7】

前記フォロー対象は、オンライン店舗のスタッフである、
請求項１に記載の情報処理システム。

【請求項8】

前記フォロー対象に係る組織のＷｅｂサイトにおいて新たに公開された前記関連情報に係る、前記対象ＩＤを含む更新情報を取得する更新情報取得手段と、
前記更新情報に含まれる対象ＩＤに紐付けられている前記顧客のＳＮＳユーザＩＤを索出し、索出されたＳＮＳユーザＩＤを配信先に決定する配信先決定手段と、
前記外部ＳＮＳに対して、前記配信先決定手段によって決定された前記顧客のＳＮＳユーザＩＤが配信先に指定されたメッセージであって、該顧客に対して前記対象ＩＤに係るフォロー対象の関連情報が新たに公開されたことを通知するメッセージの配信リクエストを送信する配信リクエスト手段と、
を更に備える、請求項１に記載の情報処理システム。

【請求項9】

前記認可処理のためのＡＰＩは、前記認可処理に加えて、前記組織からの前記顧客に対する前記外部ＳＮＳにおけるメッセージ配信を許可する配信許可処理を併せて実行するＡＰＩであり、
前記配信リクエスト手段は、前記外部ＳＮＳに対して、前記組織のＳＮＳユーザＩＤが配信元に指定された前記メッセージの配信リクエストを送信する、
請求項８に記載の情報処理システム。

【請求項10】

前記更新情報取得手段は、該更新情報取得手段による前回の前記更新情報の取得の後に新たに公開された、前記関連情報に係る更新情報を取得する、
請求項８に記載の情報処理システム。

【請求項11】

コンピュータが、
顧客のユーザ端末から、外部ＳＮＳに保持されている該顧客に係るリソースへのアクセスを認可するための認可処理の開始指示を受信した場合に、該ユーザ端末を、該外部ＳＮＳによって提供される前記認可処理のためのＡＰＩにアクセスさせる、アクセス指示ステップと、
前記認可が得られた場合に、前記外部ＳＮＳから、該外部ＳＮＳにおける前記顧客のＳＮＳユーザＩＤを取得するＳＮＳユーザＩＤ取得ステップと、
前記顧客が関連情報の通知を希望する対象であるフォロー対象の対象ＩＤを特定する対象ＩＤ特定ステップと、
前記顧客のＳＮＳユーザＩＤを、前記対象ＩＤに紐付ける紐付けステップと、
を実行する方法。

【請求項12】

コンピュータを、
顧客のユーザ端末から、外部ＳＮＳに保持されている該顧客に係るリソースへのアクセスを認可するための認可処理の開始指示を受信した場合に、該ユーザ端末を、該外部ＳＮＳによって提供される前記認可処理のためのＡＰＩにアクセスさせる、アクセス指示手段と、
前記認可が得られた場合に、前記外部ＳＮＳから、該外部ＳＮＳにおける前記顧客のＳＮＳユーザＩＤを取得するＳＮＳユーザＩＤ取得手段と、
前記顧客が関連情報の通知を希望する対象であるフォロー対象の対象ＩＤを特定する対象ＩＤ特定手段と、
前記顧客のＳＮＳユーザＩＤを、前記対象ＩＤに紐付ける紐付け手段と、
として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ユーザが所望する情報の通知を受けられるようにするための技術に関する。

【背景技術】

【0002】

従来、ユーザをログインさせたいサイト（例えば、オンライン店舗やソーシャルネットワーキングサービス等）に、外部のソーシャルネットワーキングサービス（ＳＮＳ）のユーザアカウントを用いたログイン（以下、「外部ＳＮＳログイン」と称する。）を可能とする技術が用いられている。ここで、外部ＳＮＳログインは、当該サイトが外部ＳＮＳから対象ユーザの情報を取得することについての当該対象ユーザからの認可を得て、対象ユーザの情報を取得して当該サイトのユーザ情報（当該サイトで保持しているユーザのアカウントＩＤ。メールアドレス等。）と紐付けることで当該サイトへのユーザのログインを実現するものであり、例えば、Ｏｐｅｎ Ａｕｔｈｏｒｉｚａｔｉｏｎ ２．０（ＯＡｕｔｈ２．０）を用いて実現することが可能である（非特許文献１を参照）。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】Ｌｏｄｄｅｒｓｔｅｄｔ，ＭｃＧｌｏｉｎ，Ｈｕｎｔ著「ＲＦＣ６８１９ － ＯＡｕｔｈ ２．０ Ｔｈｒｅａｔ Ｍｏｄｅｌ ａｎｄ Ｓｅｃｕｒｉｔｙ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ」Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ、２０１３年１月

【発明の概要】

【発明が解決しようとする課題】

【0004】

従来、ユーザが何らかの対象（例えば、オンライン店舗のスタッフ等）について関連情報の通知を得たい場合に、対象に関連する組織（例えば、オンライン店舗）のＳＮＳアカウントをフォローすることが行われている。しかし、単にオンライン店舗のＳＮＳアカウントをフォローした場合、ユーザが望む対象以外に係る情報も通知されることとなる。また、対象についての関連情報の通知希望を個別に登録することも行われているが、これにはメールアドレスの登録等煩雑な手続きが求められていた。

【0005】

本開示は、上記した問題に鑑み、ユーザが望む対象に係る情報の通知を、簡便な手続きで受け取り可能とすることを課題とする。

【課題を解決するための手段】

【0006】

本開示の一例は、顧客のユーザ端末から、外部ＳＮＳに保持されている該顧客に係るリソースへのアクセスを認可するための認可処理の開始指示を受信した場合に、該ユーザ端末を、該外部ＳＮＳによって提供される前記認可処理のためのＡＰＩにアクセスさせる、アクセス指示手段と、前記認可が得られた場合に、前記外部ＳＮＳから、該外部ＳＮＳにおける前記顧客のＳＮＳユーザＩＤを取得するＳＮＳユーザＩＤ取得手段と、前記顧客が関連情報の通知を希望する対象であるフォロー対象の対象ＩＤを特定する対象ＩＤ特定手段と、前記顧客のＳＮＳユーザＩＤを、前記対象ＩＤに紐付ける紐付け手段と、を備える情報処理システムである。

【0007】

本開示は、情報処理装置、システム、コンピュータによって実行される方法又はコンピュータに実行させるプログラムとして把握することが可能である。また、本開示は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的又は化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。

【発明の効果】

【0008】

本開示によれば、ユーザが望む対象に係る情報の通知を、簡便な手続きで受け取り可能とすることが可能となる。

【図面の簡単な説明】

【0009】

【図1】実施形態に係るシステムの構成を示す概略図である。

【図2】実施形態に係るシステムの機能構成の概略を示す図である。

【図3】実施形態に係る投稿処理の流れの概要を示すフローチャートである。

【図4】実施形態に係る投稿データ設定処理の流れの概要を示すフローチャートである。

【図5】実施形態に係る表示データ生成処理の流れの概要を示すフローチャートである。

【図6】実施形態に係るスタッフページの構成を示す図である。

【図7】実施形態に係るフォロー処理の流れの概要を示すシーケンス図（１）である。

【図8】実施形態に係るフォロー処理の流れの概要を示すシーケンス図（２）である。

【図9】実施形態に係るフォロー処理の流れの概要を示すシーケンス図（３）である。

【図10】実施形態に係るフォロー処理の流れの概要を示すシーケンス図（４）である。

【図11】実施形態における、スタッフのフォローが完了したことを通知するポップアップの例を示す図である。

【図12】実施形態に係るメッセージ配信処理の流れの概要を示すフローチャートである。

【発明を実施するための形態】

【0010】

以下、本開示に係る情報処理システム、方法及びプログラムの実施の形態を、図面に基づいて説明する。但し、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理システム、方法及びプログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の態様に応じた具体的構成が適宜採用され、また、種々の改良や変形が行われてよい。

【0011】

本実施形態では、本開示に係る情報処理システム、方法及びプログラムを、オンライン店舗支援システムにおいて実施した場合の実施の形態について説明する。但し、本開示に係る情報処理システム、方法及びプログラムは、ユーザが所望する情報の通知を受けられるようにするための技術について広く用いることが可能であり、本開示の適用対象は、実施形態において示した例に限定されない。

【0012】

＜システムの構成＞
図１は、本実施形態に係るシステムの構成を示す概略図である。本実施形態に係るシステムは、ネットワークに接続されることで互いに通信可能な投稿管理サーバ１、配信管理サーバ５、及び店舗側ユーザ端末９ａを備え、更に、ネットワークを介して外部のソーシャルネットワーキングサービス（以下、「外部ＳＮＳ」と称する）８、オンライン店舗及び顧客側ユーザ端末９ｂに接続される。

【0013】

投稿管理サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置１４、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）等の通信ユニット１５、等を備える情報処理装置である。但し、投稿管理サーバ１の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、投稿管理サーバ１は、単一の筐体からなる装置に限定されない。投稿管理サーバ１は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。

【0014】

配信管理サーバ５は、ＣＰＵ５１、ＲＯＭ５２、ＲＡＭ５３、ＥＥＰＲＯＭやＨＤＤ等の記憶装置５４、ＮＩＣ等の通信ユニット５５、等を備える情報処理装置である。但し、配信管理サーバ５の具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、配信管理サーバ５は、単一の筐体からなる装置に限定されない。配信管理サーバ５は、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。

【0015】

外部ＳＮＳ８は、ＣＰＵ、ＲＯＭ、ＲＡＭ、記憶装置及び通信ユニット等（図示は省略する）を備える外部の情報処理システムであり、ユーザ間のオンライン交流を可能とするソーシャルネットワーキングサービスを提供する。本実施形態において、外部ＳＮＳ８は、投稿管理サーバ１及び配信管理サーバ５を管理又は運営するサービス提供主体とは異なるサービス提供主体によって提供される外部のシステムであり、ユーザの認可を得ることなく当該ユーザに関するリソースを取得することが制限されている。

【0016】

店舗側ユーザ端末９ａは、オンライン店舗のスタッフ（オンライン店舗を提供する事業者のスタッフであり、実店舗のスタッフを含む）によって使用されるコンピュータであり、顧客側ユーザ端末９ｂは、オンライン店舗の顧客によって使用されるコンピュータである。ユーザ端末９ａ、９ｂは、何れも、ＣＰＵ、ＲＯＭ、ＲＡＭ、記憶装置、通信ユニット、入力装置、出力装置等（図示は省略する）を備えるコンピュータであり、例えば、所謂スマートフォンやタブレット、パーソナルコンピュータ等であってよい。但し、ユーザ端末９ａ、９ｂの具体的なハードウェア構成に関しては、実施の態様に応じて適宜省略や置換、追加が可能である。また、ユーザ端末９ａ、９ｂは、単一の筐体からなる装置に限定されない。ユーザ端末９ａ、９ｂは、所謂クラウドや分散コンピューティングの技術等を用いた、複数の装置によって実現されてよい。

【0017】

ユーザは、これらのユーザ端末９ａ、９ｂを介して投稿管理サーバ１を利用する。但し、ユーザは、１のユーザ端末から、店舗側ユーザとして本開示に係る情報処理システムを利用し、同時に、顧客側ユーザとして本開示に係る情報処理システムを利用することも可能である。

【0018】

図２は、本実施形態に係るシステムの機能構成の概略を示す図である。投稿管理サーバ１は、記憶装置１４に記録されているプログラムが、ＲＡＭ１３に読み出され、ＣＰＵ１１によって実行されて、投稿管理サーバ１に備えられた各ハードウェアが制御されることで、商品データベース２１、スタッフデータベース２２、データ取得部２４、投稿データ設定部２５、画像データ特定部２６、表示データ生成部２９及び表示データ送信部３０を備える情報処理装置として機能する。なお、本実施形態及び後述する他の実施形態では、投稿管理サーバ１の備える各機能は、汎用プロセッサであるＣＰＵ１１によって実行されるが、これらの機能の一部又は全部は、１又は複数の専用プロセッサによって実行されてもよい。

【0019】

商品データベース２１は、オンライン店舗によって取り扱われている商品の商品データが蓄積されるデータベースである。本実施形態において、商品データは、投稿管理サーバ１が、オンライン店舗のサーバに対してデータクローリングを行い、得られたデータを商品毎にまとめることにより生成される。データクローリングによって商品データを取得することで、商品フィードの受け渡しを行うための仕組みを既存のオンライン店舗のサーバに組み込む等の開発負担をかけることなく、本実施形態に係るシステムを導入することが可能となる。但し、商品データの生成方法は、本実施形態に例示されたクローリングを行う手法に限定されない。商品データは、オンライン店舗のデータベースを参照する方法や、オンライン店舗のサーバから商品フィードを取得する方法によって得られてもよい。

【0020】

スタッフデータベース２２は、オンライン店舗のスタッフに係るデータ（以下、「スタッフデータ」）が蓄積されるデータベースである。本実施形態において、スタッフデータベース２２には、スタッフ毎に、スタッフＩＤ、プロフィール画像、スタッフ名称、店舗ＩＤ、その他スタッフに関する情報（評価等）が蓄積される。

【0021】

データ取得部２４は、動画又は静止画の画像データを取得する。

【0022】

投稿データ設定部２５は、画像データの動画又は静止画に写り込んでいる商品の商品データと当該画像データとを紐付けるための投稿データを設定する。

【0023】

画像データ特定部２６は、投稿データに基づいて、対象商品に係る画像データを特定する。

【0024】

表示データ生成部２９は、画像データ特定部２６によって特定された画像データに係る動画又は静止画（リンク付きサムネイルも含む）を表示させるための表示データ（本実施形態では、ＨＴＭＬで記述された表示データ）を生成する。

【0025】

表示データ送信部３０は、オンライン店舗のサーバから受信された要求に応じて、表示データ生成部２９によって生成された表示データを送信する。

【0026】

店舗側ユーザ端末９ａは、記憶装置に記録されているプログラム（スタッフ用アプリケーション）が、ＲＡＭに読み出され、ＣＰＵによって実行されて、店舗側ユーザ端末９ａに備えられた各ハードウェアが制御されることで、商品情報取得部３１、投稿データ生成部３２及びデータ送信部３３を備える情報処理端末として機能する。なお、本実施形態及び後述する他の実施形態では、店舗側ユーザ端末９ａの備える各機能は、汎用プロセッサであるＣＰＵによって実行されるが、これらの機能の一部又は全部は、１又は複数の専用プロセッサによって実行されてもよい。

【0027】

商品情報取得部３１は、商品データを蓄積する商品データベース２１から商品情報を取得する。

【0028】

投稿データ生成部３２は、画像データの動画又は静止画に写り込んでいる商品と当該画像データとを紐付ける投稿データを生成する。

【0029】

データ送信部３３は、画像データ及び投稿データを投稿管理サーバ１に送信する。

【0030】

配信管理サーバ５は、記憶装置５４に記録されているプログラムが、ＲＡＭ５３に読み出され、ＣＰＵ５１によって実行されて、配信管理サーバ５に備えられた各ハードウェアが制御されることで、アクセス指示部６１、関連情報保存部６２、ＳＮＳユーザＩＤ取得部６３、対象ＩＤ特定部６４、紐付け部６５、更新情報取得部６６、配信先決定部６７、及び配信リクエスト部６８を備える情報処理装置として機能する。なお、本実施形態及び後述する他の実施形態では、配信管理サーバ５の備える各機能は、汎用プロセッサであるＣＰＵ５１によって実行されるが、これらの機能の一部又は全部は、１又は複数の専用プロセッサによって実行されてもよい。

【0031】

アクセス指示部６１は、顧客のユーザ端末（顧客側ユーザ端末９ｂ）から、外部ＳＮＳ８に保持されている当該顧客に係るリソースへのアクセスを認可するための認可処理の開始指示を受信した場合に、当該顧客側ユーザ端末９ｂを、外部ＳＮＳ８によって提供される認可処理のためのＡＰＩにアクセスさせる（リダイレクトレスポンス）。本実施形態において、リソースへのアクセスを認可するために用いられるプロトコルにはＯＡｕｔｈが採用されており、ここで受信される開始指示はＯＡｕｔｈの開始指示である。但し、リソースへのアクセスを認可するために用いられるプロトコルは、ＯＡｕｔｈに限定されない。また、本実施形態において、認可処理のためのＡＰＩは、認可処理に加えて、組織（本実施形態では、スタッフが所属するオンライン店舗、又は配信管理サーバ５の管理主体）からの顧客に対する外部ＳＮＳ８におけるメッセージ配信を許可する（例えば、所謂「友だち／フレンド」として登録する）配信許可処理（友だち／フレンド追加）を併せて実行するＡＰＩである。

【0032】

本実施形態において、開始指示及びこれに伴うＡＰＩアクセスは、顧客側ユーザ端末９ｂにおいて対象が紐付けられた操作要素（例えば、後述するスタッフページに設置されたフォローボタン）が顧客によって操作されたことに応じて当該顧客側ユーザ端末９ｂから送信された開始指示及びアクセスである。

【0033】

関連情報保存部６２は、開始指示と併せて顧客側ユーザ端末９ｂから送信された、対象に関連する情報を、顧客側ユーザ端末９ｂを識別可能な情報（例えば、セッション情報及び／又はＣｏｏｋｉｅ）と紐付けて保存する。関連情報保存部６２は、対象に関連する情報として、開始指示を当該顧客側ユーザ端末９ｂに送信させるためのフォロー開始スクリプトが呼び出されるフォローボタン表示用タグ（第一のプログラム）を含むＷｅｂページ（本実施形態では、スタッフページ）のアドレス情報を、顧客側ユーザ端末９ｂを識別可能な情報と紐付けて保存する。

【0034】

ＳＮＳユーザＩＤ取得部６３は、認可が得られた場合に、外部ＳＮＳ８から、外部ＳＮＳ８における顧客のＳＮＳユーザＩＤを取得する。

【0035】

対象ＩＤ特定部６４は、ＳＮＳユーザＩＤ取得部６３によって顧客のＳＮＳユーザＩＤが取得されたことを契機として、関連情報保存部６２によって保存された（開始指示と併せて受信された）情報に基づいて、開始指示に紐付けられたフォロー対象の対象ＩＤ（本実施形態では、スタッフＩＤ）を特定する。ここで特定される対象ＩＤは、顧客が関連情報の通知を希望する対象であるフォロー対象（本実施形態では、オンライン店舗のスタッフ）の対象ＩＤである。

【0036】

バリエーションの説明において後述するように、対象ＩＤの具体的な特定方法は本実施形態における例示に限定されないが、本実施形態では、対象ＩＤ特定部６４は、以下に説明する一連の処理を実行することによって、顧客が関連情報の通知を希望する対象であるフォロー対象の対象ＩＤを特定する。はじめに、対象ＩＤ特定部６４は、ＳＮＳユーザＩＤ取得部６３によって顧客のＳＮＳユーザＩＤが取得されたことを契機として、関連情報保存部６２によって保存された、顧客側ユーザ端末９ｂに係るＷｅｂページのアドレス情報を特定する。そして、対象ＩＤ特定部６４は、顧客側ユーザ端末９ｂに対して、ＳＮＳユーザＩＤを特定可能な情報（本実施形態では、ハッシュ値。）を通知し、通知されたＳＮＳユーザＩＤを特定可能な情報及び対象ＩＤの組み合わせを当該顧客側ユーザ端末９ｂから受信し、開始指示に紐付けられたフォロー対象の対象ＩＤを特定する。なお、本実施形態では、セキュリティ保持のため、ＳＮＳユーザＩＤを特定可能な情報としてハッシュ値を用いる例について説明するが、ＳＮＳユーザＩＤを特定可能な情報は本開示における例示に限定されない。ＳＮＳユーザＩＤを特定可能な情報には、例えば、ＳＮＳユーザＩＤに対して一意に紐付けられた任意の値が用いられてもよいし、ＳＮＳユーザＩＤ自体が用いられてもよい。

【0037】

ここで、対象ＩＤ特定部６４は、通知されたＳＮＳユーザＩＤを特定可能な情報を、Ｗｅｂページに含まれる対象ＩＤと組み合わせて当該情報処理システムに対して送信させるための、当該Ｗｅｂページに含まれるフォロー情報送信スクリプトが呼び出されるタグ（第二のプログラム）を顧客側ユーザ端末９ｂに実行させることで、ＳＮＳユーザＩＤを特定可能な情報及び対象ＩＤの組み合わせを当該顧客側ユーザ端末９ｂから受信し、開始指示に紐付けられたフォロー対象の対象ＩＤを特定する。

【0038】

紐付け部６５は、ＳＮＳユーザＩＤ取得部６３によって取得された、外部ＳＮＳ８における顧客のＳＮＳユーザＩＤを、対象ＩＤ特定部６４によって特定された、当該顧客が関連情報の通知を希望する対象であるフォロー対象（例えば、オンライン店舗のスタッフ）の対象ＩＤに紐付ける。

【0039】

更新情報取得部６６は、フォロー対象に係る組織のＷｅｂサイト（本実施形態では、スタッフが所属するオンライン店舗）において、当該更新情報取得部６６による前回の更新情報の取得の後に新たに公開された関連情報（例えば、投稿データ）に係る、対象ＩＤ（本実施形態では、スタッフＩＤ）を含む更新情報を取得する。

【0040】

配信先決定部６７は、更新情報に含まれる対象ＩＤに紐付けられている顧客のＳＮＳユーザＩＤを索出し、索出されたＳＮＳユーザＩＤを配信先に決定する。

【0041】

配信リクエスト部６８は、外部ＳＮＳ８に対して、組織のＳＮＳユーザＩＤが配信元に、配信先決定部６７によって決定された顧客のＳＮＳユーザＩＤが配信先に指定されたメッセージであって、当該顧客に対して対象ＩＤに係るフォロー対象の関連情報が新たに公開されたことを通知するメッセージの配信リクエストを送信する。

【0042】

＜処理の流れ＞
次に、本実施形態に係るシステムにおいて実行される処理の流れを説明する。なお、以下に説明する処理の具体的な内容及び処理順序は、本開示を実施するための一例である。具体的な処理内容及び処理順序は、本開示の実施の形態に応じて適宜選択されてよい。

【0043】

図３は、本実施形態に係る投稿処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、店舗側ユーザ端末９ａにおいてスタッフ用アプリケーションが起動されたことを契機として実行される。

【0044】

ここで、スタッフが用いるスマートフォンやタブレット、パーソナルコンピュータ等の店舗側ユーザ端末９ａには、予めスタッフ用アプリケーションがインストールされており、当該アプリケーションは、予め当該店舗側ユーザ端末９ａを用いるスタッフがスタッフＩＤやパスワード等のログイン情報（ログインの方法は、本実施形態における例示に限定されない）を入力して投稿管理サーバ１によるログイン認証を受けることで、当該スタッフが勤務する店舗及び当該スタッフのスタッフＩＤに関連づけられている。

【0045】

ステップＳ１０１では、商品情報が取得される。スタッフ用アプリケーションを実行する店舗側ユーザ端末９ａの商品情報取得部３１は、対象店舗（店舗側ユーザ端末９ａを操作するスタッフに紐付けられたオンライン店舗）で取り扱われている商品情報を、投稿管理サーバ１からダウンロードする。商品情報は、投稿管理サーバ１において、商品データベース２１から必要な情報が抽出されることで生成される。例えば、投稿管理サーバ１は、商品データベース２１中の、店舗毎に用意された商品データテーブルから、商品名、商品ＩＤ（品番や商品コード等）、商品画像データ等を抽出し、これらを商品情報として、アプリケーションが実行される店舗側ユーザ端末９ａに送信する。なお、商品情報が店舗側ユーザ端末９ａにダウンロードされるタイミングは限定されない。商品情報は、アプリケーションが起動したタイミングでダウンロードされてもよいし、バックグラウンドでダウンロードされてもよいし、後述する商品選択のタイミングでダウンロードされてもよい。その後、処理はステップＳ１０２へ進む。

【0046】

ステップＳ１０２及びステップＳ１０３では、スタッフ画像データが特定される。ここで、スタッフ画像データとは、商品が映りこむようにスタッフが撮像を行うこと等によって生成された（換言すれば、スタッフによって作成された）画像（以下、「スタッフ画像」と称する）のデータであり、撮像には、店舗側ユーザ端末９ａに内蔵されたカメラが用いられてもよいし、店舗側ユーザ端末９ａ以外の撮像装置が用いられてもよい。なお、スタッフ画像は、スタッフ自身が商品を身につけて撮像された画像であってもよいが、スタッフ自身が被写体として撮像された画像に限定されない。本フローチャートに示された処理の実行に際して、スタッフは、予めスタッフ画像データを作成し、店舗側ユーザ端末９ａに保存しておく。但し、スタッフ画像データの作成タイミングは、ステップＳ１０３のタイミングであってもよい。

【0047】

スタッフ用アプリケーションを実行する店舗側ユーザ端末９ａは、ユーザに対してアップロードするスタッフ画像データが動画であるか静止画であるかを選択させるためのインターフェースを表示し、ユーザによる選択を受け付けることで、アップロードされるスタッフ画像データが動画であるか静止画であるかを特定する（ステップＳ１０２）。そして、店舗側ユーザ端末９ａは、当該店舗側ユーザ端末９ａの画像データフォルダ等にアクセスし、ステップＳ１０２で選択された種類の画像データの一覧を表示し、ユーザによる選択結果を受け付ける等の方法で、ユーザが所望するスタッフ画像データを特定する（ステップＳ１０３）。但し、画像データの選択手順は本実施形態における例示に限定されない。例えば、ステップＳ１０２における動画／静止画の選択処理はスキップされてもよい。その後、処理はステップＳ１０４へ進む。

【0048】

ステップＳ１０４では、スタッフ画像データが編集される。スタッフ用アプリケーションを実行する店舗側ユーザ端末９ａは、スタッフ画像データをユーザが編集可能とするための動画／静止画編集機能を提供し、ユーザの操作に応じてスタッフ画像データを編集する。ここで提供される編集機能は、例えば、スタッフ画像データに係る動画又は静止画に任意の文字やステッカー、線、図形等を追加可能なものである。但し、提供される編集機能の内容は限定されない。例えば、動画の尺や画像のサイズ、色調、フィルタ等を変更可能な編集機能が提供されてもよい。スタッフ画像データの編集が完了すると、処理はステップＳ１０５へ進む。

【0049】

ステップＳ１０５では、スタッフ画像に含まれる商品が特定され、商品情報の表示形式の指定が受け付けられる。店舗側ユーザ端末９ａは、ステップＳ１０１で受信された商品情報に含まれる商品からユーザによる商品の選択を受け付けることで、スタッフ画像データに写り込んでいる商品を特定する。本実施形態では、店舗側ユーザ端末９ａは、ユーザに対して検索キーワードの入力欄を提供し、ユーザによって入力された検索ワード（例えば、品番、商品コード、商品名、等）をキーに商品情報を検索し、索出された商品情報をユーザに提示してユーザに選択させ、ユーザによる選択結果を受け付けることで、商品を特定する。なお、本実施形態では、予め商品情報を店舗側ユーザ端末９ａにダウンロードしておいて、店舗側ユーザ端末９ａにおいて商品情報を検索する態様を採用しているが、検索キーワードを投稿管理サーバ１に送信して商品データベース２１を検索させ、投稿管理サーバ１から検索結果として商品情報を得て商品を特定することとしてもよい。

【0050】

更に、本実施形態において、店舗側ユーザ端末９ａは、スタッフ画像内で画像に重畳して表示される商品情報の表示形式の指定も受け付ける。具体的には、店舗側ユーザ端末９ａは、特定された商品の情報を画像内に表示する形式（フォーマット）を、予め用意された複数種類の形式からユーザに選択させることで、商品情報の表示形式の指定を受け付ける。本実施形態では、特定された商品の情報を画像内に表示する形式（フォーマット）として、予めデザインされた、互いに異なるデザインの商品パネルが複数種類提示され、ユーザが提示された商品パネルの中から所望のデザインを選択することで、画像に含まれる商品が特定され、商品情報の表示形式の指定が受け付けられる。その後、処理はステップＳ１０６へ進む。

【0051】

ステップＳ１０６では、画像内への商品情報（商品パネル）の表示位置／フレームが決定される。ステップＳ１０５において商品が特定され、商品情報の表示形式（商品パネルのデザイン）の指定が受け付けられると、店舗側ユーザ端末９ａは、スタッフ画像（動画／静止画）及び当該スタッフ画像に重畳された商品パネルを表示し、当該商品パネルを表示させるスタッフ画像内の位置、及び当該商品パネルを表示させるスタッフ画像内のフレームを指定するユーザ操作を受け付けることで、商品パネルの表示位置／フレームを決定する。このようなインターフェースが提供されることで、スタッフは、商品パネルをスタッフ画像（動画／静止画）中の任意の位置に設置することが出来る。その後、処理はステップＳ１０９へ進む。

【0052】

ステップＳ１０９では、投稿データが生成される。店舗側ユーザ端末９ａの投稿データ生成部３２は、ステップＳ１０５からステップＳ１０６において特定された各種情報に基づいて、ステップＳ１０３で選択され、ステップＳ１０４で編集されたスタッフ画像データに対して商品を紐付けるための投稿データを生成する。

【0053】

本実施形態において、投稿データは、画像毎に生成され、画像ＩＤ、検索用タグ（１又は複数設定可能。）、スタッフＩＤ、商品ＩＤ、商品パネルの表示形式、商品パネルの表示フレーム（フレーム番号等を用いて指定される。）、及び商品パネルの表示位置（座標等を用いて指定される。）を含む。ここで、画像ＩＤは、システム内でユニークであればよく、店舗側ユーザ端末９ａによって付されてもよいし、投稿管理サーバ１によって発行されてもよい。また、商品ＩＤは、ステップＳ１０５で特定された商品の商品ＩＤであり、投稿管理サーバ１から取得された商品情報から取得される。また、スタッフＩＤは、スタッフデータベース２２によって管理される、当該店舗側ユーザ端末９ａを操作しているスタッフのＩＤであり、本実施形態では、予めスタッフ用アプリケーションにログインしているスタッフのスタッフＩＤが設定される。但し、スタッフＩＤは、処理の途中でスタッフＩＤを入力させる方法等によって特定されてもよい。また、検索用タグは、画像データに付されて当該画像データを発見し易くするための、Ｗｅｂページに表示されることでオンライン店舗を閲覧する顧客ユーザから可視な検索用タグであり、ユーザが検索用タグをクリック／タップすることで同じ検索用タグが付されている画像データを一覧できるＷｅｂページを開くことが可能なリンクが付されてＷｅｂページに表示される。投稿データが生成されると、処理はステップＳ１１０へ進む。

【0054】

ステップＳ１１０では、スタッフ画像データ及び投稿データが送信される。店舗側ユーザ端末９ａのデータ送信部３３は、ステップＳ１０３で選択され、ステップＳ１０４で編集されたスタッフ画像データと、ステップＳ１０５からステップＳ１０９までの処理で生成された投稿データとの組み合わせを、ネットワークを介して投稿管理サーバ１に送信（アップロード）する。その後、本フローチャートに示された処理は終了する。

【0055】

なお、本実施形態では、店舗側ユーザ端末９ａにおいて投稿データを生成して投稿管理サーバ１に送信する態様について説明しているが、投稿データの生成は、店舗側ユーザ端末９ａ及び投稿管理サーバ１のどちらで行われてもよいし、分担して行われてもよい。例えば、投稿管理サーバ１が、店舗側ユーザ端末９ａから投稿データを生成するための情報を受信し、受信された内容に基づいて投稿管理サーバ１が投稿データを生成することとしてもよい。

【0056】

図４は、本実施形態に係る投稿データ設定処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、上述した投稿処理のステップＳ１１０で店舗側ユーザ端末９ａから送信されたデータが受信されたことを契機として実行される。

【0057】

ステップＳ２０１では、スタッフ画像データ及び投稿データが受信される。データ取得部２４は、店舗側ユーザ端末９ａから送信されたスタッフ画像データ及び投稿データを受信する。なお、本実施形態では、店舗側ユーザ端末９ａにおいて投稿データが生成された後にスタッフ画像データ及び投稿データが送信される例について説明しているが、スタッフ画像データ及び投稿データの送信タイミングは、本実施形態において説明した例に限定されない。例えば、スタッフ画像データは編集前又は編集完了の時点で投稿管理サーバ１に送信され（編集もサーバサイドで行われてもよい）、その後投稿データが生成されて投稿管理サーバ１に送信されてもよい。また、上述のように、投稿データはサーバサイドで生成されてもよい。この場合、店舗側ユーザ端末９ａからは投稿データを生成するための情報（具体的には、ステップＳ１０５からステップＳ１０６で取得された情報、スタッフＩＤ及びその他の必要な情報）が送信されるのみで、投稿データの送信は省略される。その後、処理はステップＳ２０２へ進む。

【0058】

ステップＳ２０２では、スタッフ画像データ及び投稿データが保存される。投稿データ設定部２５は、ステップＳ２０１で受信されたスタッフ画像データ及び投稿データを保存することで、スタッフ画像データと商品とを紐付ける。本実施形態では、投稿管理サーバ１は、投稿データの画像ＩＤ及び商品ＩＤを参照することで、スタッフ画像データが紐付けられた商品を特定可能である。但し、投稿データの具体的な態様は本実施形態における例示に限定されず、スタッフ画像データと商品とを紐付ける手法は、本実施形態における例示に限定されない。例えば、商品データに画像ＩＤその他の情報を記録する方法や、スタッフ画像データの管理用データに商品ＩＤその他の情報を記録する方法等、様々な手法でスタッフ画像データと商品とを紐付けることが可能である。その後、処理はステップＳ２０３へ進む。

【0059】

ステップＳ２０３では、スタッフ画像データ及び投稿データが承認される。投稿管理サーバ１は、システムの管理者に新たなスタッフ画像データ及び投稿データが受信されたことを通知し、これらのスタッフ画像データ及び投稿データの承認操作を求める。この通知及び承認操作の要求は、既存のメールシステムやウェブシステムを用いて行うことが可能である。例えば、通知メールを受信した管理者は、管理者の端末において通知メールに指定されたＷｅｂページを開き、Ｗｅｂページ内の承認ボタンをクリック／タップすることで、受信されたスタッフ画像データ及び投稿データの承認操作を行う。このため、当該Ｗｅｂページには、管理者がスタッフ画像データ及び投稿データの承認を行なってよいか否かを判断するための各種情報が表示される。具体的には、投稿データに含まれている情報（画像ＩＤ、検索用タグ、スタッフＩＤ、商品ＩＤ、商品パネルの表示形式、商品パネルの表示フレーム、及び商品パネルの表示位置）に加えて、画像の内容、店舗名、スタッフ名、商品名、及び現在のステータス（承認／未承認）等が表示される。また、管理者は、承認に際して、公開タイミング（今すぐ公開／日時を指定して公開）や任意のコメントを設定可能であってよい。なお、承認操作が行われなかった場合、受信されたスタッフ画像データ及び投稿データの公開は保留され、本フローチャートに示された処理は終了する。一方、承認操作が行われた場合、スタッフ画像データは公開状態となり、本フローチャートに示された処理は終了する。

【0060】

図５は、本実施形態に係る表示データ生成処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、オンライン店舗のサーバから送信された、オンライン店舗のＷｅｂページに含ませるための表示データのリクエストが受け付けられたことを契機として実行される。

【0061】

オンライン店舗のサーバは、インターネットブラウザや電子商取引アプリケーション等の、オンライン店舗を閲覧可能なアプリケーションを実行する顧客側ユーザ端末９ｂから送信されたオンライン店舗のＷｅｂページのリクエストを受け付けると、リクエストされたＷｅｂページを顧客側ユーザ端末９ｂに送信する。この際、顧客側ユーザ端末９ｂに送信されるＷｅｂページのコンテンツのうち、商品名、商品画像（動画／静止画）、商品価格、カラーバリエーション（あれば）、商品詳細（商品の説明）、ショッピングカートへの追加ボタン、等、従来オンライン店舗によって提供されていたコンテンツについては、オンライン店舗のサーバによって生成／管理されているデータが用いられる。一方、Ｗｅｂページ中に所定の埋め込みタグが記載されている場合、オンライン店舗のサーバは、当該埋め込みタグの記載箇所のための表示データを、投稿管理サーバ１にリクエストする。ここで、埋め込みタグとは、Ｗｅｂページにおいてスタッフ画像を埋め込みたい箇所に記載される指示コードであり、上述の検索用タグとは異なる。

【0062】

即ち、本実施形態に係るシステムによれば、オンライン店舗の管理者は、オンライン店舗のＷｅｂページにおけるスタッフ画像を埋め込みたい箇所に、所定の埋め込みタグを記載することで、アップロードされて承認されたスタッフ画像を自動的に反映させることが出来る。

【0063】

ステップＳ３０１及びステップＳ３０２では、表示データのリクエストが受け付けられ、対象商品の商品データが取得される。投稿管理サーバ１は、オンライン店舗のサーバから送信された、商品詳細ページやショッピングカートページ、スタッフページ等のＷｅｂページに含ませるための表示データのリクエストを受け付ける（ステップＳ３０１）。

【0064】

オンライン店舗のサーバから送信される表示データのリクエストには、必要に応じて、当該Ｗｅｂページに表示される商品を特定可能な情報が含まれる。例えば、顧客側ユーザ端末９ｂからリクエストされたＷｅｂページが商品詳細ページである場合、オンライン店舗のサーバは、商品を特定可能な情報を、リクエストのＵＲＬから抽出された商品ＩＤ等に基づいて取得し、リクエストに含めることが出来る。また、例えば、顧客側ユーザ端末９ｂからリクエストされたＷｅｂページがショッピングカートページである場合、オンライン店舗のサーバは、商品を特定可能な情報を、対象顧客のショッピングカートデータから抽出された商品ＩＤ等に基づいて取得し、リクエストに含めることが出来る。また、例えば、顧客側ユーザ端末９ｂからリクエストされたＷｅｂページがスタッフページである場合、オンライン店舗のサーバは、商品を特定可能な情報を、対象顧客のリクエストのＵＲＬから抽出されたスタッフＩＤ等に基づいて取得し、リクエストに含めることが出来る。

【0065】

リクエストが受け付けられると、表示データ生成部２９は、リクエストに含まれる商品を特定可能な情報に基づいて商品データベース２１を検索することで、リクエストに応じて送信する表示データに含まれるべき１又は複数の対象商品の商品ＩＤを特定し、商品ＩＤに対応する商品データを取得する（ステップＳ３０２）。その後、処理はステップＳ３０３へ進む。

【0066】

ステップＳ３０３では、投稿データに基づいてスタッフ画像データが取得される。画像データ特定部２６は、ステップＳ３０２で取得された商品ＩＤに係る投稿データを抽出し、抽出された投稿データに記録されている画像ＩＤを取得することで、リクエストに係る対象商品のスタッフ画像データを全て特定する。その後、処理はステップＳ３０６へ進む。

【0067】

ステップＳ３０６及びステップＳ３０７では、リクエストに係る表示データが生成され、送信される。表示データ生成部２９は、ステップＳ３０２からステップＳ３０３で取得された各種データ等に基づいて、リクエストに係る表示データを生成する（ステップＳ３０６）。ここで、表示データ生成部２９は、オンライン店舗サーバが生成するＷｅｂページに埋め込まれるスタッフ画像に、投稿データにおいて設定された商品パネルが、設定された表示位置／フレームにおいて表示されるように、表示データを生成する。以下、ここで生成された表示データが埋め込まれたスタッフページの具体例を説明する。

【0068】

図６は、本実施形態に係るスタッフページの構成を示す図である。図中の括弧書きは、当該括弧書き部分に、括弧内に記載された属性の情報が表示されることを示す。顧客側ユーザ端末９ｂは、顧客の操作に従って、オンライン店舗サイトのサーバーにアクセスし、当該サイトに用意されたスタッフページを表示する。スタッフページは、オンライン店舗又は当該オンライン店舗に対応する実店舗において顧客に小売のためのサービスを提供するスタッフ毎に用意されたＷｅｂページであり、スタッフデータベース２２から取得された当該スタッフの情報（プロフィール画像、スタッフ名称、店舗名、支店名等）に加えて、当該スタッフが使用しているＳＮＳアカウントへのリンク、プロフィール文、当該スタッフを検索するための検索用タグ、当該スタッフをフォローするためのフォローボタン、当該スタッフによって投稿された投稿データの内容、当該スタッフがおすすめする商品やサービスのブランド名、商品名、商品画像（動画／静止画）、商品価格、当該スタッフによるコメント、カラーバリエーション（あれば）、商品詳細（商品の説明）、スタッフ画像（動画／静止画）、ショッピングカートへの追加ボタン、等が掲載されている。ユーザは、当該スタッフページを参照して、商品等をカートに追加し、購入することができる。

【0069】

ここで、商品名、商品画像データ、商品価格等は、オンライン店舗のサーバによって生成される。そして、図中の破線の枠で囲まれた部分が、埋め込みタグに従って投稿管理サーバ１によって生成されてオンライン店舗に提供される表示データである。スタッフ画像を表示するためのスタッフ画像データは、当該スタッフのスタッフＩＤに紐付けられている投稿データに基づいて取得される。

【0070】

なお、商品画像が表示される領域には、商品画像データに基づく商品画像のみならず、スタッフ画像データに基づくスタッフ画像が表示されてもよい。例えば、当該商品画像領域には、対象商品に係る商品画像及びスタッフ画像が自動的に切り替わりながら連続で表示されてもよい。オンライン店舗の管理者は、商品画像が表示される領域に、所定の埋め込みタグを記載することで、対象商品に係る商品画像及びスタッフ画像を自動的に切り替えながら連続で表示させることが出来る。

【0071】

表示データが生成されると、表示データ送信部３０は、生成された表示データを、リクエストの送信元であるオンライン店舗のサーバに対して送信する（ステップＳ３０７）。その後、本フローチャートに示された処理は終了する。

【0072】

投稿管理サーバ１の表示データ送信部３０によって送信された表示データを受信したオンライン店舗のサーバは、Ｗｅｂページ中の埋め込みタグが記載されている箇所に当該表示データを埋め込む（ページ内の埋め込みタグを、当該埋め込みタグについて定義されたルールに従って当該表示データで置換する）ことで、Ｗｅｂページを完成させ、完成したＷｅｂページのデータを顧客側ユーザ端末９ｂに送信する。

【0073】

このようにして、スタッフ画像はオンライン店舗に埋め込まれ、顧客はオンライン店舗に埋め込まれたスタッフ画像を閲覧する。なお、スタッフ画像は、上記説明したスタッフページに加えて、オンライン店舗のトップページ、商品詳細ページ、ショッピングカートページ、動画一覧ページ、スタッフランキングページ、スタッフページ、及びメールマガジン等に表示されてよい。

【0074】

また、埋め込みタグは、ページ等を閲覧した顧客による再生開始操作が行われた場合に、スタッフ画像（及び商品画像）を連続で再生するためのコードが実行されるタグであってもよい。このようにすることで、（１）様々な商品が紐付いた様々なスタッフによる画像（動画／静止画）が連続再生されるトップページ、（２）様々な商品が紐付いた様々なスタッフによる画像（動画／静止画）が連続再生される画像一覧ページ、（３）様々な商品が紐付いた当該スタッフによる画像（動画／静止画）が連続再生されるスタッフページ、（４）当該商品が紐付いた様々なスタッフによる画像（動画／静止画）が連続再生される商品詳細ページ、といったページを、顧客側ユーザ端末９ｂに表示させることが可能となる。

【0075】

例えば、オンライン店舗のトップページ（図示は省略する）は、オンライン店舗毎に生成され、顧客側ユーザ端末９ｂからの要求に応じてオンライン店舗のサーバから送信されて顧客側ユーザ端末９ｂに表示されるＷｅｂページであり、少なくともオンライン店舗名、商品画像及びスタッフ画像等を含む。ここで、商品画像を表示するための商品画像データは、顧客側ユーザ端末９ｂからの要求に応じてオンライン店舗のサーバによって生成される。また、スタッフ画像を表示するためのスタッフ画像データは、当該オンライン店舗が取り扱う商品に係る投稿データに基づいて取得される。そして、トップページには、当該オンライン店舗が取り扱う商品に係る商品画像及びスタッフ画像が自動的に切り替わりながら連続で表示される。

【0076】

そして、上記説明した商品詳細ページ、ショッピングカートページ、オンライン店舗のトップページ、動画一覧ページ、スタッフランキングページ、スタッフページ、及びメールマガジン等に含まれるスタッフ画像が顧客側ユーザ端末９ｂで再生されると、再生されるスタッフ画像には、投稿データで設定された商品パネルが重畳表示される。そして、この商品パネルには当該商品パネルの商品に係る商品詳細ページへのリンクが設定されており、ユーザは、この商品パネルをクリック／タップすることで、商品詳細ページを投稿管理サーバ１に要求することが出来る。

【0077】

図７から図１０は、本実施形態に係るフォロー処理の流れの概要を示すシーケンス図である。本シーケンス図に示された処理は、顧客側ユーザ端末９ｂにおいて顧客がスタッフページ内に表示されたフォローボタンを操作したことを契機として実行され、図７から図１０に向けて順に処理される。

【0078】

上記説明したスタッフページには、顧客が当該スタッフページに係るスタッフからの情報発信を継続的に受け取りたい場合に当該スタッフをフォローするためのフォローボタンが配置されており、当該フォローボタンが操作されることで、顧客側ユーザ端末９ｂは、当該フォローボタンに関連付けられたフォロー開始スクリプト（第一のプログラム）を実行する。但し、ここで「フォロー」とは、所謂ＳＮＳにおける、「ＳＮＳアカウントのフォロー」とは異なる。本実施形態において、顧客は、フォローボタンを操作することで、スタッフのＳＮＳアカウントをフォローするのではなく、店舗のＳＮＳアカウントから発信される情報のうち、フォローしたスタッフに係る情報（例えば、スタッフページの更新情報等）の通知対象として設定される。

【0079】

そして、スタッフページには、スタッフＩＤが設定されており、更に、当該スタッフＩＤと外部ＳＮＳ８における顧客のＳＮＳユーザＩＤに係るハッシュ値とを同梱して「フォロー情報送信」するためのフォロー情報送信スクリプト（第二のプログラム）が含まれている。但し、顧客側ユーザ端末９ｂによって最初に取得されて表示された時点においては、外部ＳＮＳ８における顧客のＳＮＳユーザＩＤが未取得であるため、当該フォロー情報送信スクリプトは実行されない。

【0080】

ステップＳ４０１及びステップＳ４０２では、ＯＡｕｔｈ開始の通信が受信され、オンライン店舗のＳＮＳユーザＩＤが取得される。配信管理サーバ５は、顧客側ユーザ端末９ｂにおいて顧客がスタッフページ内に表示されたフォローボタンを操作したことによってフォロー開始スクリプト（第一のプログラム）を実行した顧客側ユーザ端末９ｂから送信された、ＯＡｕｔｈ開始の通信を受信する（ステップＳ４０１）。なお、この際、顧客側ユーザ端末９ｂは、配信管理サーバ５に対して、操作されたフォローボタンが配置されているスタッフページを特定可能な情報を通知する。本実施形態に係るシステムでは、スタッフページを特定可能な情報として、スタッフページのＵＲＬが通知される。但し、スタッフページを特定可能な情報は、スタッフＩＤ等、その他の情報であってもよい。

【0081】

ＯＡｕｔｈ開始の通信、及びスタッフページのＵＲＬを受信した配信管理サーバ５の関連情報保存部６２は、スタッフページのＵＲＬを、顧客側ユーザ端末９ｂを特定可能な情報（例えば、セッション情報及び／又はＣｏｏｋｉｅ）に紐付けて保存する。更に、配信管理サーバ５は、スタッフページのＵＲＬに基づいて、当該スタッフページに対応するオンライン店舗の外部ＳＮＳ８におけるＳＮＳユーザＩＤを取得する（ステップＳ４０２）。ここで、配信管理サーバ５は、予め、オンライン店舗のドメイン情報と当該オンライン店舗のＳＮＳユーザＩＤとを紐付けた店舗データを有しており、配信管理サーバ５は、この店舗データを参照することで、スタッフページＵＲＬに基づいて対応するオンライン店舗のＳＮＳユーザＩＤを取得する。その後、処理はステップＳ４０３へ進む。

【0082】

ステップＳ４０３では、顧客側ユーザ端末９ｂからの通信が外部ＳＮＳ８の認可サーバにリダイレクトされる。配信管理サーバ５のアクセス指示部６１は、顧客側ユーザ端末９ｂに対して、顧客側ユーザ端末９ｂのブラウザを外部ＳＮＳ８の認可サーバによって提供される外部ＳＮＳログインＡＰＩにリダイレクトするためのリダイレクトレスポンスを送信する（ステップＳ４０３）。ここで、外部ＳＮＳログインＡＰＩとは、外部ＳＮＳ８のユーザアカウントを用いて外部ＳＮＳ８以外のサイトへのログインを行わせる機能（外部ＳＮＳログイン）を提供するＡＰＩである。また、送信されるリダイレクトレスポンスには、ステップＳ４０２で取得されたオンライン店舗のＳＮＳユーザＩＤが含まれる。リダイレクトレスポンスを受信した顧客側ユーザ端末９ｂは、オンライン店舗のＳＮＳユーザＩＤを含む認可リクエストを外部ＳＮＳ８の認可サーバに送信する。

【0083】

認可リクエストを受信した外部ＳＮＳ８の認可サーバは、顧客側ユーザ端末９ｂが外部ＳＮＳ８にログインしていない状態である場合、顧客側ユーザ端末９ｂに対して当該ＳＮＳ８へのログイン認証用ＵＲＬを送信することで、顧客側ユーザ端末９ｂに当該ＳＮＳ８へのログイン認証画面を表示させ、顧客に対して認証情報を入力させ、ログインボタンを操作させる。認証情報の入力及びログインボタンの操作を受け付けた顧客側ユーザ端末９ｂは、認証情報を外部ＳＮＳ８に送信し、外部ＳＮＳ８にログインする。ここで、認証情報は、例えば、メールアドレス等のユーザＩＤ及びパスワードであってよい。但し、認証情報はＩＤ及びパスワードに限定されず、例えば生体認証やワンタイムパスワード、電子証明書等のその他の認証情報が用いられてもよいし、複数の認証手段が組み合わせられてもよい。なお、２回目以降の外部ＳＮＳログイン処理である等の理由で、認証情報が顧客側ユーザ端末９ｂに既に記憶されている場合には、ユーザによる認証情報の入力は省略され、ログインボタンの操作のみで、顧客側ユーザ端末９ｂが認証情報を外部ＳＮＳ８に送信し、外部ＳＮＳ８にログインする。

【0084】

認可リクエストを受信した外部ＳＮＳ８の認可サーバは、顧客側ユーザ端末９ｂが外部ＳＮＳ８にログインした状態となった場合、権限委譲の確認用ＵＲＬを送信することで、顧客側ユーザ端末９ｂに権限委譲の確認画面を表示させ、顧客に対して、当該ＳＮＳ８が保有する顧客に関する情報（本実施形態では、当該顧客のＳＮＳユーザＩＤ等。）を配信管理サーバ５に提供してよいか否かを確認する。顧客が顧客側ユーザ端末９ｂにおいて権限委譲に同意することを示す操作（例えば、同意ボタンの押下）を行うと、顧客側ユーザ端末９ｂは、顧客が権限委譲に同意したことを外部ＳＮＳ８の認可サーバに通知し、通知を受けた認可サーバは、顧客側ユーザ端末９ｂに対して認可レスポンスを送信する。

【0085】

ここで、外部ＳＮＳ８の認可サーバが権限委譲への同意の通知を受けた時点において対象のオンライン店舗から対象の顧客への当該ＳＮＳ８におけるメッセージ送信が許可されている状態（例えば、所謂「友だち／フレンド」として登録されている状態。以下、「友だち」として説明する。）となっていない場合、外部ＳＮＳ８は、認可レスポンスの送信前に、顧客側ユーザ端末９ｂに対して、オンライン店舗を友だち登録するためのＵＲＬを送信することで、顧客側ユーザ端末９ｂに友だち追加画面を表示させ、顧客に対して、対象のオンライン店舗を友だちとして登録してよいか否かを確認する。この際、外部ＳＮＳ８は、認可リクエストにおいて受信されたオンライン店舗のＳＮＳユーザＩＤと、ＳＮＳログインにおいて特定された顧客のＳＮＳユーザＩＤとに基づいて、対象のオンライン店舗と顧客とが既に友だち登録されているか否かを判定する。顧客が顧客側ユーザ端末９ｂにおいて友だち追加に同意することを示す操作（例えば、同意ボタンの押下）を行うと、顧客側ユーザ端末９ｂは、顧客が友だち追加に同意したことを外部ＳＮＳ８に通知し、通知を受けた外部ＳＮＳ８は、対象のオンライン店舗から対象の顧客への当該ＳＮＳ８におけるメッセージ送信を許可されている状態に設定する（本実施形態では、「友だち」として登録する）。

【0086】

外部ＳＮＳ８から顧客側ユーザ端末９ｂに対して送信される認可レスポンスには、顧客側ユーザ端末９ｂのブラウザを、配信管理サーバ５による外部ＳＮＳ８からのリソース取得処理をトリガーするためのＵＲＬにアクセスさせるためのリダイレクトＵＲＬが含まれる。ここで送信されるリダイレクトＵＲＬは、配信管理サーバ５についてのＯＡｕｔｈ認可のために予め外部ＳＮＳ８に登録されている配信管理サーバ５のＵＲＬ（ＣａｌｌｂａｃｋＵＲＬ）であり、外部ＳＮＳ８は、認可リクエストに係る配信管理サーバ５又はオンライン店舗を特定可能な情報（例えば、オンライン店舗のＳＮＳユーザＩＤ、又はドメイン情報等）に基づいて、予め登録されているリダイレクトＵＲＬを特定する。なお、本実施形態では、リダイレクトＵＲＬが配信管理サーバ５又はオンライン店舗毎に認可リクエストの受信前に予め登録されている例を挙げて説明しているが、リダイレクトＵＲＬは、認可リクエストの際に認可リクエストと併せて認可サーバに登録されてもよい。

【0087】

また、認可レスポンスに含まれるリダイレクトＵＲＬには、権限委譲の同意が得られたことを示す認可コードがパラメータとして付されている。この認可コードは、後述するトークンリクエストの際に、認可サーバによって、ユーザから権限委譲の同意が得られたサービス（ここでは、配信管理サーバ５）であることを確認するために用いられる。

【0088】

ステップＳ４０４からステップＳ４０８では、認可レスポンスに基づいて、顧客のＳＮＳユーザＩＤが取得される。認可レスポンスを受信した顧客側ユーザ端末９ｂは、指定されたリダイレクトＵＲＬにアクセスすることで、配信管理サーバ５による外部ＳＮＳ８からのリソース取得処理をトリガーする。配信管理サーバ５のＳＮＳユーザＩＤ取得部６３は、顧客側ユーザ端末９ｂからの指定リダイレクトＵＲＬへのアクセスを受信すると（ステップＳ４０４）、外部ＳＮＳ８の認可サーバに対して、顧客のＳＮＳユーザＩＤについてのトークンリクエストを送信する（ステップＳ４０５）。トークンリクエストを受信した認可サーバは、トークンリクエストに付された認可コードを検証することで、トークンリクエストの送信元が、当該顧客（当該ＳＮＳ８にアカウントを有するＳＮＳユーザ）が権限委譲に同意した送信元であることを確認し、対象のＳＮＳユーザについて当該ＳＮＳ８が保有するリソースにアクセスすることを許可するアクセストークンを発行し、発行されたアクセストークンを含むトークンレスポンスを配信管理サーバ５に対して送信する。

【0089】

配信管理サーバ５のＳＮＳユーザＩＤ取得部６３は、顧客についてのリソースにアクセスすることを許可するアクセストークンを含むトークンレスポンスを受信すると（ステップＳ４０６）、外部ＳＮＳ８のリソースサーバに対してアクセストークンを含むリソースアクセスを送信することで、対象の顧客のＳＮＳユーザＩＤを要求する（ステップＳ４０７）。リソースサーバは、受信したアクセストークンを参照することでリソースアクセスの送信元（配信管理サーバ５）がユーザから権限委譲を受けていることを確認し、リソースアクセスの送信元に対して、リソース（ここでは、対象の顧客のＳＮＳユーザＩＤ）を提供する。配信管理サーバ５のＳＮＳユーザＩＤ取得部６３は、外部ＳＮＳ８のリソースサーバから対象の顧客のＳＮＳユーザＩＤを受信する（ステップＳ４０８）その後、処理はステップＳ４０９へ進む。

【0090】

ステップＳ４０９からステップＳ４１２では、フォロー対象の対象ＩＤが特定される。配信管理サーバ５の対象ＩＤ特定部６４は、外部ＳＮＳ８のリソースサーバから対象の顧客のＳＮＳユーザＩＤを受信すると、受信した顧客のＳＮＳユーザＩＤを特定可能な情報（ここでは、顧客のＳＮＳユーザＩＤに基づいて算出されたハッシュ値）を取得し（ステップＳ４０９）、顧客側ユーザ端末９ｂに対して、スタッフページのＵＲＬへのリダイレクトを指示するレスポンスを送信する（ステップＳ４１０）。ここで、対象ＩＤ特定部６４は、上記ステップＳ４０２において保持されたセッション情報及び／又はＣｏｏｋｉｅに基づいて、顧客側ユーザ端末９ｂにおいてＯＡｕｔｈの開始時点で表示されていたスタッフページのＵＲＬ、即ち、レスポンスに含めるべきスタッフページのＵＲＬを特定する。より具体的には、対象ＩＤ特定部６４は、ステップＳ４０４におけるアクセス元の顧客側ユーザ端末９ｂに係るセッション情報及び／又はＣｏｏｋｉｅを用いて、ステップＳ４０２で関連情報保存部６２によって保存された紐付けデータを検索することによって、レスポンスに含めるべきスタッフページのＵＲＬを特定する。また、ここで顧客側ユーザ端末９ｂに対して送信される当該ＵＲＬには、顧客のＳＮＳユーザＩＤに基づいて算出されたハッシュ値が、パラメータとして付与される。

【0091】

レスポンスを受信した顧客側ユーザ端末９ｂは、当該レスポンスに含まれるリダイレクト指示に従って、スタッフページのＵＲＬにアクセスし、オンライン店舗サイトのサーバーからスタッフページを取得、表示する。上述の通り、このスタッフページには、スタッフＩＤと顧客のＳＮＳユーザＩＤに係るハッシュ値とを同梱して「フォロー情報送信」するためのフォロー情報送信スクリプト（第二のプログラム）が含まれている。顧客側ユーザ端末９ｂは、スタッフページに設置されたスタッフＩＤと、当該スタッフページのＵＲＬにパラメータとして付与された顧客のＳＮＳユーザＩＤに係るハッシュ値と、を参照して、当該フォロー情報送信スクリプトを実行し、配信管理サーバ５に対してフォロー情報を送信する。配信管理サーバ５の対象ＩＤ特定部６４は、顧客側ユーザ端末９ｂからフォロー情報を受信すると（ステップＳ４１１）、受信されたＳＮＳユーザＩＤに係るハッシュ値に対応するＳＮＳユーザＩＤを特定する（ステップＳ４１２）。その後、処理はステップＳ４１３へ進む。

【0092】

ステップＳ４１３及びステップＳ４１４では、顧客のＳＮＳユーザＩＤがスタッフＩＤに紐付けられ、フォロー済みレスポンスが送信される。配信管理サーバ５の紐付け部６５は、特定されたＳＮＳユーザＩＤと、受信されたスタッフＩＤとを紐付け、フォロー管理テーブルに記録する（ステップＳ４１３）。なお、この際、当該フォロー関係を識別するためのフォローＩＤが発行され、ＳＮＳユーザＩＤ及びスタッフＩＤと併せてフォロー管理テーブルに記録されてもよい。なお、本実施形態ではフォロー管理にテーブルを用いる例を説明するが、フォロー管理のためにＳＮＳユーザＩＤとスタッフＩＤとを紐付けるデータの管理形式は、テーブルに限定されない。顧客によるスタッフのフォロー（顧客のＳＮＳユーザＩＤとスタッフＩＤとの紐付け）が完了すると、配信管理サーバ５は、顧客側ユーザ端末９ｂに対して、フォロー済みレスポンスを送信する（ステップＳ４１４）。本実施形態において、フォロー済みレスポンスは、スタッフページＵＲＬ及びポップアップ情報を送信することによって実行される。フォロー済みレスポンスを受信した顧客側ユーザ端末９ｂは、フォロー済みレスポンスに含まれるスタッフページＵＲＬ及びポップアップ情報に従って、ポップアップ付きスタッフページを表示し、顧客に対して、スタッフのフォローが完了したことを通知する。その後、本シーケンス図に示された処理は終了する。

【0093】

図１１は、本実施形態における、スタッフのフォローが完了したことを通知するポップアップの例を示す図である。図中の括弧書きは、当該括弧書き部分に、括弧内に記載された属性の情報が表示されることを示す。ポップアップには、「フォローしました」とのメッセージと共に、顧客にフォローされたスタッフのプロフィール画像、スタッフ名称、店舗名、支店名等が表示される。これらのデータは、Ｗｅｂサイトに埋め込まれたスクリプトが実行されることで送信されたリクエストを受けた配信管理サーバ５によってスタッフデータベースから取得され、ポップアップに配置されたものである。また、ポップアップには、「フォロー解除」のボタンが表示されてもよい。

【0094】

顧客が「フォロー解除」の操作を行った場合、顧客側ユーザ端末９ｂは、フォロー解除のためのフォロー解除スクリプトを実行することで、スタッフページに設置されたスタッフＩＤと、当該スタッフページのＵＲＬにパラメータとして付与された顧客のＳＮＳユーザＩＤに係るハッシュ値と、を参照して、当該フォロー解除スクリプトを実行し、配信管理サーバ５に対してフォロー解除の指示を送信する。配信管理サーバ５は、顧客側ユーザ端末９ｂからフォロー解除の指示を受信すると、受信されたＳＮＳユーザＩＤに係るハッシュ値に対応するＳＮＳユーザＩＤを特定し、フォロー管理テーブルに記録されている、特定されたＳＮＳユーザＩＤと受信されたスタッフＩＤとの紐付けを削除する。

【0095】

図１２は、本実施形態に係るメッセージ配信処理の流れの概要を示すフローチャートである。本フローチャートに示された処理は、予め設定された頻度で、定期的に（例えば、１日に１回、予め設定された時刻に）実行される。但し、本フローチャートに示された処理の実行タイミングは本開示における例示に限定されない。本フローチャートに示された処理は、例えば、管理者によるメッセージ配信の指示が受信されたことを契機として実行されてもよい。

【0096】

オンライン店舗のスタッフが、店舗側ユーザ端末９ａ及びスタッフ用アプリケーションを用いてスタッフＩＤを含む投稿データを作成し、当該投稿データを投稿管理サーバ１へ送信すると、投稿管理サーバ１は、受信した投稿データを保存する（例えば、図４のステップＳ２０２を参照）。保存された投稿データは、オンライン店舗サイトから参照可能に配信される。ここで、投稿データは、対象のスタッフに関連する投稿として、スタッフＩＤに関連づけられて投稿管理サーバ１へアップロードされたデータであればよく、上記に例示したスタッフ画像データに係る投稿データに限定されない。

【0097】

ステップＳ５０１では、投稿データの問い合わせが行われる。配信管理サーバ５の更新情報取得部６６は、投稿管理サーバ１に対して、新たに公開された（公開状態となった）投稿データの有無を問い合わせるリクエストを送信する（ステップＳ５０１）。ここで、当該リクエストには、問い合わせ対象のスタッフＩＤが含まれていてもよい。リクエストを受け付けた投稿管理サーバ１は、前回受信したリクエストの後に新たに公開された投稿データを、投稿データの投稿時刻、公開時刻、又は配信管理サーバ５への応答履歴に基づいて特定し、特定された投稿データに係る更新情報（投稿情報）を通知するレスポンスを、配信管理サーバ５に対して送信する。なお、ここでリクエストに問い合わせ対象のスタッフＩＤが含まれている場合には、投稿管理サーバ１は、対象のスタッフＩＤに係る投稿データのみを特定し、特定された投稿データに係る投稿情報を通知するレスポンスを、配信管理サーバ５に対して送信する。また、投稿情報には、投稿データに係るスタッフＩＤ、投稿概要及び対象の投稿データを閲覧可能なページ（例えば、スタッフページや商品詳細ページ）のＵＲＬが含まれる。その後、処理はステップＳ５０２へ進む。

【0098】

ステップＳ５０２及びステップＳ５０３では、投稿情報が取得され、配信先が決定される。配信管理サーバ５更新情報取得部６６は、投稿管理サーバ１によって送信されたレスポンスを受信し、レスポンスに含まれる投稿情報を保存する（ステップＳ５０２）。レスポンスを受信した配信管理サーバ５の配信先決定部６７は、対象の投稿情報に含まれるスタッフＩＤをキーとしてフォロー管理テーブルを検索し、当該スタッフＩＤと紐付けられている顧客のＳＮＳユーザＩＤ（即ち、投稿を行ったスタッフをフォローしている顧客のＳＮＳユーザＩＤ）を索出し、索出されたＳＮＳユーザＩＤを配信先に決定する（ステップＳ５０３）。その後、処理はステップＳ５０４へ進む。

【0099】

ステップＳ５０４では、メッセージの配信がリクエストされる。配信管理サーバ５の配信リクエスト部６８は、投稿情報に基づく新着投稿の配信リクエストを、外部ＳＮＳ８に対して送信する（ステップＳ５０４）。ここで、外部ＳＮＳ８に対する配信リクエストは、外部ＳＮＳ８が提供するメッセージ一斉配信用ＡＰＩを通じて行われ、当該配信リクエストには、配信元、配信先、及び配信内容が含まれる。配信元にはオンライン店舗のＳＮＳユーザＩＤが指定され、配信先にはステップＳ５０３で決定された顧客のＳＮＳユーザＩＤが指定され、配信内容には、顧客に配信したい当該スタッフに係る情報（例えば、「お客様がフォローしているスタッフ〇〇が商品〇〇についての記事を投稿しました！」等のメッセージ、及び投稿データを閲覧可能なページのＵＲＬ）が指定される。なお、メッセージは、定型文にスタッフ名称や商品名等を当てはめる方法、又はＡＩに生成させる方法等で配信管理サーバ５において作成されてよい。即ち、配信リクエスト部６８は、外部ＳＮＳ８に対して、当該ＳＮＳ８でオンライン店舗の友だちとして登録されている顧客（ＳＮＳにおけるメッセージ送信が許可されているユーザ）のうち、対象の投稿情報に係るスタッフをフォローしている顧客のみを指定した配信リクエストを行う。

【0100】

配信リクエストを受信した外部ＳＮＳ８は、配信リクエストに従ったメッセージ配信を行う。具体的には、外部ＳＮＳ８は、オンライン店舗のＳＮＳユーザＩＤを送信者とし、配信リクエストで指定された配信内容をコンテンツとして含むメッセージを、配信リクエストで指定された顧客のＳＮＳユーザＩＤを宛先として送信する。このようにすることで、オンライン店舗は、当該店舗のＳＮＳアカウントから、スタッフをフォローしている顧客のみに対して当該スタッフに係る情報を自動配信しつつ、当該スタッフをフォローしていないその他の顧客への望まれない情報配信を抑制することが出来る。

【0101】

上記説明した処理が実行されることで、本実施形態に開示した情報処理システムによれば、ユーザが関連情報の通知を希望する対象を簡便にフォローすることが可能となり、また、フォローした対象に関連する情報の通知を受けられるようになる。

【0102】

＜バリエーション＞
上記説明した実施形態では、外部ＳＮＳ８のリソースサーバから対象の顧客のＳＮＳユーザＩＤが受信された後、リダイレクト指示を含むレスポンス（ステップＳ４１０）を受信した顧客側ユーザ端末９ｂがスタッフＩＤ及び顧客のＳＮＳユーザＩＤを特定可能な情報（例えば、ハッシュ値）を配信管理サーバ５に送信し、配信管理サーバ５がスタッフＩＤと顧客のＳＮＳユーザＩＤを紐付けてフォロー状態とする態様を説明した。しかし、本開示に係る技術を実装するに際して、処理の順序は上記実施形態における例示に限定されず、その他の処理順序が採用されてもよい。以下、処理順序のバリエーションを例示する。

【0103】

当該バリエーションにおいても、上記説明した実施形態と同様、関連情報保存部６２は、開始指示と併せて顧客側ユーザ端末９ｂから送信された、対象に関連する情報を、顧客側ユーザ端末９ｂを識別可能な情報（例えば、セッション情報及び／又はＣｏｏｋｉｅ）と紐付けて保存する。本バリエーションにおいて、関連情報保存部６２は、対象に関連する情報として、開始指示と併せてユーザ端末から送信された、当該開始指示を当該ユーザ端末に送信させるためのプログラムに含まれる対象ＩＤ（例えば、スタッフＩＤ）を、顧客側ユーザ端末９ｂを識別可能な情報と紐付けて保存する。

【0104】

そして、本バリエーションにおいて、対象ＩＤ特定部６４は、ＳＮＳユーザＩＤ取得部６３によって顧客のＳＮＳユーザＩＤが取得されたことを契機として、関連情報保存部６２によって保存された顧客側ユーザ端末９ｂに係る対象ＩＤを、顧客側ユーザ端末９ｂを識別可能な情報（例えば、セッション情報及び／又はＣｏｏｋｉｅ）に基づいて特定することで、開始指示に紐付けられたフォロー対象の対象ＩＤを特定する。

【0105】

即ち、本バリエーションにおける処理順序について、図７から図１０のシーケンス図を参照して説明すると、本バリエーションでは、ＯＡｕｔｈ開始の通信（ステップＳ４０１）において、配信管理サーバ５に対するスタッフページのＵＲＬ（リクエストＵＲＬ）のパラメータに、スタッフＩＤが含まれており、スタッフページのＵＲＬを受信した配信管理サーバ５の関連情報保存部６２は、パラメータとしてスタッフＩＤを含むスタッフページのＵＲＬを、顧客側ユーザ端末９ｂを特定可能な情報（例えば、セッション情報及び／又はＣｏｏｋｉｅ）に紐付けて保存する。

【0106】

そして、リソースの提供（ステップＳ４０８）で顧客のＳＮＳユーザＩＤが取得された際、対象ＩＤ特定部６４は、顧客側ユーザ端末９ｂを介することなく、配信管理サーバ５内でＯＡｕｔｈ開始指示に係るスタッフＩＤを特定し、紐付け部６５は、特定されたスタッフＩＤと顧客のＳＮＳユーザＩＤとを紐付けてフォロー状態とする。このため、本バリエーションにおいて、ステップＳ４０９におけるハッシュ値の算出処理、ステップＳ４１０で送信されるレスポンスに当該ハッシュ値を含める処理、ステップＳ４１１におけるフォロー情報の受信処理、及びステップＳ４１２におけるハッシュ値に対応するＳＮＳユーザＩＤの特定処理、は省略されてよい。なお、この処理が採用される場合も、配信管理サーバ５は、顧客のＳＮＳユーザＩＤをＵＲＬパラメータに付与して元のページ（上記説明した例では、スタッフページ）に戻るように顧客側ユーザ端末９ｂにレスポンスを返却してよい。

【0107】

＜その他のバリエーション＞
上記説明した実施形態では、アクセストークンを得てユーザのリソースを取得する処理（ステップＳ４０５からステップＳ４０８）が、配信管理サーバ５によって処理される例を説明したが、アクセストークンを得てユーザのリソースを取得する処理は、その他の装置によって実行されてもよい。例えば、アクセストークンを得てユーザのリソースを取得する処理は、これらの処理を実行するためのスクリプト（プログラム）を顧客側ユーザ端末９ｂに実行させることによって処理されてもよい。

【0108】

上記説明した実施形態では、オンライン店舗のＷｅｂページと当該Ｗｅｂページのためのスタッフ画像等を含む表示データとが異なるシステムにおいて生成される例について説明したが、オンライン店舗のＷｅｂページと当該Ｗｅｂページのためのスタッフ画像等を含む表示データとは、同一のシステムにおいて生成されてもよい。即ち、オンライン店舗を提供するシステムと、本開示に係るオンライン店舗支援システムとは、統合されていてもよい。

【0109】

更に、上記説明した実施形態では、本開示に係る技術を、商品が販売されるオンライン店舗に適用する例について説明したが、オンライン店舗において販売される対象は、有体物の商品に限定されない。本開示に係る技術は、サービス（役務）や不動産等、様々な販売対象を取り扱うオンライン店舗に対して適用可能である。

【0110】

上記説明した実施形態では、フォロー対象に係る組織がオンライン店舗又は配信管理サーバ５の管理主体であり、フォロー対象が当該オンライン店舗のスタッフである例について説明したが、フォロー対象及び当該フォロー対象に係る組織は、上記例示に限定されない。例えば、組織やオンライン店舗の業種は、アパレル、不動産販売、中古車販売、家電、食品、家具、教育、求人、メディア、士業、占い、楽器等であってよい。また、フォロー対象は、業種がアパレルである場合には、商品カテゴリ、ブランド、メーカー、店舗、人、スタッフ、価格、色、素材、性別、身長、値引き率、サイズ、ランキング、新品、中古等であってよいし、業種が不動産販売である場合には、地域、間取り、賃料レンジ、住宅種別（マンションｏｒ戸建て、新築ｏｒ中古）、電車路線、駅、都道府県等であってよいし、業種が中古車販売である場合には、年式、排気量、走行距離、車種、車検有無、駆動方式（４ＷＤｏｒ２ＷＤ）、車両タイプ（クーペ、ＳＵＶ等）等であってよいし、業種が家電である場合には、部屋の広さ、容量（冷蔵庫など）等であってよいし、業種が食品である場合には商品ブランド等であってよいし、業種が家具である場合には部屋タイプ（リビング・寝室等）等であってよいし、業種が教育である場合には、コース、学年、志望校、資格等であってよいし、業種が求人である場合には、年収、雇用形態、会社名等であってよいし、業種がメディアである場合には、イベント、記事ジャンル等であってよいし、業種が士業である場合には得意分野等であってよいし、業種が占いである場合には、星座、誕生月、九星、干支、２７宿等であってよいし、業種が楽器である場合には、奏法、音楽ジャンル等であってよい。

【符号の説明】

【0111】

１ サーバ（情報処理装置）
９ａ 店舗側ユーザ端末
９ｂ 顧客側ユーザ端末

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【手続補正書】

【提出日】2024-06-06

【手続補正1】

【補正対象書類名】明細書

【補正対象項目名】０００５

【補正方法】変更

【補正の内容】

【0005】

本開示は、上記した問題に鑑み、ユーザが関連情報の通知を希望する対象を簡便にフォロー可能とすることを課題とする。

【手続補正2】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

顧客のユーザ端末から、外部ＳＮＳに保持されている該顧客に係るリソースへのアクセスを認可するための認可処理の開始指示を受信した場合に、該ユーザ端末を、該外部ＳＮＳによって提供される前記認可処理のためのＡＰＩにアクセスさせる、アクセス指示手段と、
前記開始指示と併せて前記ユーザ端末から送信された、前記顧客が関連情報の通知を希望する対象であるフォロー対象を特定可能な情報を、前記ユーザ端末を識別可能な情報と紐付けて保存する関連情報保存手段と、
前記認可が得られた場合に、前記外部ＳＮＳから、該外部ＳＮＳにおける前記顧客のＳＮＳユーザＩＤを取得するＳＮＳユーザＩＤ取得手段と、
前記ＳＮＳユーザＩＤ取得手段によって前記顧客のＳＮＳユーザＩＤが取得されたことを契機として、前記関連情報保存手段によって保存された情報に基づいて、前記開始指示に紐付けられた前記フォロー対象の対象ＩＤを特定する対象ＩＤ特定手段と、
前記顧客のＳＮＳユーザＩＤを、前記対象ＩＤに紐付ける紐付け手段と、
を備える情報処理システム。

【請求項2】

前記関連情報保存手段は、前記開始指示と併せて前記ユーザ端末から送信された、該開始指示を該ユーザ端末に送信させるための第一のプログラムを含むＷｅｂページのアドレス情報を、前記ユーザ端末を識別可能な情報と紐付けて保存し、
前記対象ＩＤ特定手段は、
前記ＳＮＳユーザＩＤ取得手段によって前記顧客のＳＮＳユーザＩＤが取得されたことを契機として、前記関連情報保存手段によって保存された、前記ユーザ端末に係る前記Ｗｅｂページのアドレス情報を特定し、
前記ユーザ端末に対して、前記ＳＮＳユーザＩＤを特定可能な情報を通知し、
通知された前記ＳＮＳユーザＩＤを特定可能な情報を、前記Ｗｅｂページに含まれる前記対象ＩＤと組み合わせて該情報処理システムに対して送信させるための、該Ｗｅｂページに含まれる第二のプログラムを、特定された前記アドレス情報を前記ユーザ端末に通知することで前記ユーザ端末に実行させることで、前記ＳＮＳユーザＩＤを特定可能な情報及び前記対象ＩＤの組み合わせを該ユーザ端末から受信し、前記開始指示に紐付けられたフォロー対象の対象ＩＤを特定する、
請求項１に記載の情報処理システム。

【請求項3】

前記関連情報保存手段は、前記開始指示と併せて前記ユーザ端末から送信された、該開始指示を該ユーザ端末に送信させるためのプログラムに含まれる前記対象ＩＤを、前記ユーザ端末を識別可能な情報と紐付けて保存し、
前記対象ＩＤ特定手段は、前記ＳＮＳユーザＩＤ取得手段によって前記顧客のＳＮＳユーザＩＤが取得されたことを契機として、前記関連情報保存手段によって保存された前記ユーザ端末に係る前記対象ＩＤを特定することで、前記開始指示に紐付けられたフォロー対象の対象ＩＤを特定する、
請求項１に記載の情報処理システム。

【請求項4】

前記開始指示は、前記ユーザ端末において前記対象が紐付けられた操作要素が顧客によって操作されたことに応じて該ユーザ端末から送信された開始指示である、
請求項１に記載の情報処理システム。

【請求項5】

前記フォロー対象は、オンライン店舗のスタッフである、
請求項１に記載の情報処理システム。

【請求項6】

前記フォロー対象に係る組織のＷｅｂサイトにおいて新たに公開された前記関連情報に係る、前記対象ＩＤを含む更新情報を取得する更新情報取得手段と、
前記更新情報に含まれる対象ＩＤに紐付けられている前記顧客のＳＮＳユーザＩＤを索出し、索出されたＳＮＳユーザＩＤを配信先に決定する配信先決定手段と、
前記外部ＳＮＳに対して、前記配信先決定手段によって決定された前記顧客のＳＮＳユーザＩＤが配信先に指定されたメッセージであって、該顧客に対して前記対象ＩＤに係るフォロー対象の関連情報が新たに公開されたことを通知するメッセージの配信リクエストを送信する配信リクエスト手段と、
を更に備える、請求項１に記載の情報処理システム。

【請求項7】

前記認可処理のためのＡＰＩは、前記認可処理に加えて、前記組織からの前記顧客に対する前記外部ＳＮＳにおけるメッセージ配信を許可する配信許可処理を併せて実行するＡＰＩであり、
前記配信リクエスト手段は、前記外部ＳＮＳに対して、前記組織のＳＮＳユーザＩＤが配信元に指定された前記メッセージの配信リクエストを送信する、
請求項６に記載の情報処理システム。

【請求項8】

前記更新情報取得手段は、該更新情報取得手段による前回の前記更新情報の取得の後に新たに公開された、前記関連情報に係る更新情報を取得する、
請求項６に記載の情報処理システム。

【請求項9】

コンピュータが、
顧客のユーザ端末から、外部ＳＮＳに保持されている該顧客に係るリソースへのアクセスを認可するための認可処理の開始指示を受信した場合に、該ユーザ端末を、該外部ＳＮＳによって提供される前記認可処理のためのＡＰＩにアクセスさせる、アクセス指示ステップと、
前記開始指示と併せて前記ユーザ端末から送信された、前記顧客が関連情報の通知を希望する対象であるフォロー対象を特定可能な情報を、前記ユーザ端末を識別可能な情報と紐付けて保存する関連情報保存ステップと、
前記認可が得られた場合に、前記外部ＳＮＳから、該外部ＳＮＳにおける前記顧客のＳＮＳユーザＩＤを取得するＳＮＳユーザＩＤ取得ステップと、
前記ＳＮＳユーザＩＤ取得ステップで前記顧客のＳＮＳユーザＩＤが取得されたことを契機として、前記関連情報保存ステップで保存された情報に基づいて、前記開始指示に紐付けられた前記フォロー対象の対象ＩＤを特定する対象ＩＤ特定ステップと、
前記顧客のＳＮＳユーザＩＤを、前記対象ＩＤに紐付ける紐付けステップと、
を実行する方法。

【請求項10】

コンピュータを、
顧客のユーザ端末から、外部ＳＮＳに保持されている該顧客に係るリソースへのアクセスを認可するための認可処理の開始指示を受信した場合に、該ユーザ端末を、該外部ＳＮＳによって提供される前記認可処理のためのＡＰＩにアクセスさせる、アクセス指示手段と、
前記開始指示と併せて前記ユーザ端末から送信された、前記顧客が関連情報の通知を希望する対象であるフォロー対象を特定可能な情報を、前記ユーザ端末を識別可能な情報と紐付けて保存する関連情報保存手段と、
前記認可が得られた場合に、前記外部ＳＮＳから、該外部ＳＮＳにおける前記顧客のＳＮＳユーザＩＤを取得するＳＮＳユーザＩＤ取得手段と、
前記ＳＮＳユーザＩＤ取得手段によって前記顧客のＳＮＳユーザＩＤが取得されたことを契機として、前記関連情報保存手段によって保存された情報に基づいて、前記開始指示に紐付けられた前記フォロー対象の対象ＩＤを特定する対象ＩＤ特定手段と、
前記顧客のＳＮＳユーザＩＤを、前記対象ＩＤに紐付ける紐付け手段と、
として機能させるためのプログラム。