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

Abstract

情報処理装置は、記憶部と制御部とを有する。上記記憶部は、インターネット上の第１のサービス及び第２のサービスの双方にアカウントを有するユーザに対する他のユーザからのアクションを示すアクション情報を記憶する。上記制御部は、上記記憶されたアクション情報を基に、上記第１のサービスにおける上記ユーザの第１のページに、上記アクションの存在を上記ユーザへ通知する第１の通知情報を第１の表示態様で表示させる。また制御部は、上記第２のサービスにおける上記ユーザの第２のページに、上記アクションの存在を上記ユーザへ通知する、上記第１のサービスへのリンクを含む第２の通知情報を、上記第１の表示態様とは異なる第２の表示態様で表示させる。

Description

本発明は、インターネット上における複数のサービス間の連携処理を制御可能な情報処理装置、当該情報処理装置における情報処理方法及びプログラムに関する。

現在、インターネット上では様々なサービスが提供されており、一人のユーザが複数のサービスにアカウントを有している場合もある。例えば、あるＳＮＳ（Social Networking Service）を利用しているユーザが、ブログサービスを利用して自身のブログを作成している場合もある。

また、これらのサービスの中には、そのサービスにアカウントを有するユーザに対する他のユーザからの何らかのアクションを受け付け、それをユーザに通知する情報を表示する機能を有するものもある。例えばＳＮＳにおいては、あるユーザが投稿したコンテンツに対する他のユーザのコメントが表示されたり、当該コンテンツが好き、支持できるといった他のユーザの意思を示す情報が表示されたりする（いいね！またはナイス！機能）。また、ブログサービス（ブログ作成機能を提供するサービス）でも、あるユーザが公開した日記に対して他のユーザが投稿したコメントが表示される。

ところで、このように他のユーザからアクションがあった場合には、アクションの対象ユーザは、当該アクションの内容をなるべく早く知りたいと思うのが自然である。下記特許文献１には、ＳＮＳとブログを連携させて、ＳＮＳに登録されている情報をブログ上に表示させたり、ブログに登録された情報をＳＮＳに表示させたりするシステムが開示されている。これによりユーザは、ＳＮＳを閲覧しなくてもブログ上でＳＮＳでの他のユーザのアクションに関する通知情報を知ることができ、また逆にブログを閲覧しなくてもＳＮＳ上で他のユーザからのコメント等の通知情報を知ることができる。

特開２００７−３２３３１１号公報

しかしながら、単に同一の通知情報が複数のサービスで表示される場合、ユーザはどれか１つのサービスのページを閲覧すれば当該情報を得られることになるため、サービス間の回遊性が下がってしまう可能性がある。

以上のような事情に鑑み、本発明の目的は、インターネット上の複数のサービス間でユーザの回遊性を向上させることができる情報処理装置、情報処理方法及びプログラムを提供することにある。

上述の課題を解決するため、本発明の一形態に係る情報処理装置は、記憶部と制御部とを有する。上記記憶部は、インターネット上の第１のサービス及び第２のサービスの双方にアカウントを有するユーザに対する他のユーザからのアクションを示すアクション情報を記憶する。上記制御部は、上記記憶されたアクション情報を基に、上記第１のサービスにおける上記ユーザの第１のページに、上記アクションの存在を上記ユーザへ通知する第１の通知情報を第１の表示態様で表示させる。また制御部は、上記第２のサービスにおける上記ユーザの第２のページに、上記アクションの存在を上記ユーザへ通知する、上記第１のサービスへのリンクを含む第２の通知情報を、上記第１の表示態様とは異なる第２の表示態様で表示させる。

これにより情報処理装置は、第１のサービスにおいて表示される通知情報を、第２のサービスにおいて、第１のサービスとは表示形態を異ならせて第１のサービスへのリンク付きで表示することで、ユーザの通知情報に対する興味を引き、第１のサービスへ誘導することができる。これにより第１のサービスと第２のサービスとの間の回遊性が向上する。
ここで第１のサービス及び第２のサービスは、例えばＳＮＳ、ブログサービス、ミニブログサービス、オークションサービス、Ｑ＆Ａサービス、口コミサイトサービス（レビューの投稿が可能なサービス）等、あらゆる種類のサービスで有りうる。また第１のサービスと第２のサービスは同種のサービスであってもよいし、異種のサービスであってもよい。またアクションとは、例えばあるユーザが投稿したコンテンツに対して他のユーザが行う、コメントの投稿、当該コンテンツが好き、支持できるといった意思を示すための操作（いいね！またはナイス！ボタンの押下）、ＳＮＳ上であるユーザと新たに繋がるためのリクエスト送信、あるユーザのコンテンツを自身のＳＮＳページのタイムライン上で表示させる（フォローする）ための設定操作またはそのためのリクエスト送信等をいうが、これらに限られない。

上記第１の通知情報は上記アクションに関する詳細情報へのリンクを有してもよい。この場合上記制御部は、上記第１のページで上記第１の通知情報から上記詳細情報へのアクセスが検出された場合に、当該第１の通知情報に対応する上記第２の通知情報が表示されないように上記第２のページを制御してもよい。

これにより情報処理装置は、ユーザが同一の情報を第１のサービスと第２のサービスの双方で閲覧することで煩わしさを感じるのを防ぐことができる。

上記制御部は、上記第１の通知情報に第１の詳細度を有する第１の詳細情報を含ませ、上記第２の通知情報に、上記第１の詳細度よりも小さい第２の詳細度を有し、上記第１の詳細情報へのリンクを含む第２の詳細情報を含ませてもよい。

これにより情報処理装置は、第２の通知情報の詳細度を小さくすることで、それに興味のあるユーザが第１のサービスの第１の詳細情報へ誘導することができるとともに、通知情報が第２のサービスを利用中のユーザの作業の邪魔になるのを回避することができる。例えば、第１の詳細情報には、ユーザが投稿した記事やコメントの情報及びそれに対してアクションを行った他のユーザ及び当該アクションの内容等が表示される。一方、第２の詳細情報には、上記アクションの事実のみが、その主体（他のユーザを示す情報）や内容を示す情報へのリンク付きで表示される。

上記制御部は、所定数のアクションの存在を示す複数の第１の通知情報を第１の順序で表示するように上記第１のページを制御し、上記所定数のアクションの存在を示す複数の第２の通知情報を上記第１の順序とは異なる第２の順序で表示するように上記第２のページを制御してもよい。

これにより情報処理装置は、第１のページと第２のページの双方で、同じアクションに関する通知情報がユーザに閲覧されてしまうのを極力防ぐことができる。

上記記憶部は、上記ユーザが上記第２のページにアクセスして滞在する時間を所定アクセス分平均した平均滞在時間情報を記憶してもよい。この場合上記制御部は、上記平均滞在時間情報を基に、上記第２の通知情報を、上記ユーザが上記第２のページにアクセスしてから上記平均滞在時間の所定割合の時間が経過したときに表示させるように上記第２のページを制御してもよい。

これにより情報処理装置は、ユーザが第２のページにアクセスしてから離脱しそうなタイミングで第２の通知情報を表示させることで、ユーザの第２のサービスにおける滞在時間を減らさせる（閲覧動作を邪魔する）ことなく、ユーザを第１のサービスにスムースに誘導することができる。

上記制御部は、上記第１のページがアクセスされている間に上記第２のページがアクセスされた場合、上記第１のページで表示された複数の第１の通知情報のうち所定数の第１の通知情報に対応する所定数の第２の通知情報が、上記第２のページで表示されないように上記第２のページを制御してもよい。

これにより情報処理装置は、第１のページと第２のページとが同時にアクセスされた場合には、第１のページに表示された所定数の通知情報はユーザによって既読とみなし、第２のページではそれら所定数の情報を表示させないことで、ユーザが同じ情報を何度も閲覧してしまうことを極力防ぐことができる。ここで所定数とは例えば３個、５個、１０個等であるが、これらに限られない。

上記第１の通知情報及び上記第２の通知情報は、複数の異なるアクション毎に、種類の異なる複数の通知情報を有してもよい。この場合上記記憶部は、上記種類の異なるアクション毎の重要度を示す重要度情報を記憶してもよい。またこの場合上記制御部は、上記重要度情報を基に、上記複数の第１の通知情報のうち、所定以上の重要度を有する通知情報を上記第２の通知情報として表示するように上記第２のページを制御してもよい。

これにより情報処理装置は、第２のページには第１のページに表示された通知情報のうち重要度の高い情報を表示させることで、通知情報の表示が第２のサービスを利用中のユーザの邪魔になるのを極力防ぎながら、通知すべき情報を通知し、第１のサービスへユーザを誘導することができる。

上記記憶部は、上記第１のページへの複数の他のユーザのアクセス履歴を示すアクセス履歴情報を記憶してもよい。この場合上記制御部は、上記複数の他のユーザのアクションを通知する情報を上記第１の通知情報として表示するように上記第１のページを制御し、上記アクセス履歴情報を基に、上記複数の他のユーザのうち、上記第１のページへの所定値以上のアクセス頻度を有する他のユーザのアクションを通知する情報を上記第２の通知情報として表示するように上記第２のページを制御してもよい。

これにより情報処理装置は、第２のページには、他のユーザのうち、ユーザに関心の高いユーザによるアクションの通知情報のみを表示させることで、通知情報の表示が第２のサービスを利用中のユーザの邪魔になるのを極力防ぎながら、第１のサービスへユーザを誘導することができる。

例えば、ＳＮＳにおいて他のユーザのページに表示される友達（またはフォロー）推薦領域を介して第１のページを何度も閲覧している他のユーザは、ユーザと友達になることまたはユーザをフォローすることに興味がある可能性が高い。したがって情報処理装置は、そのような他のユーザのアクションに関する通知情報のみを第２のページに表示させることで、ユーザを第１のサービスに誘導させ、上記他のユーザとの繋がりを促進させることができる。

本発明の他の形態に係る情報処理方法は、インターネット上の第１のサービス及び第２のサービスの双方にアカウントを有するユーザに対する他のユーザからのアクションを示すアクション情報を記憶すること、上記記憶されたアクション情報を基に、上記第１のサービスにおける上記ユーザの第１のページに、上記アクションの存在を上記ユーザへ通知する第１の通知情報を第１の表示態様で表示させること、及び、上記第２のサービスにおける上記ユーザの第２のページに、上記アクションの存在を上記ユーザへ通知する、上記第１のサービスへのリンクを含む第２の通知情報を、上記第１の表示態様とは異なる第２の表示態様で表示させることを含む。

本発明のまた別の形態に係るプログラムは、情報処理装置に、記憶ステップと、第１の表示ステップと、第２の表示ステップとを実行させる。上記記憶ステップは、インターネット上の第１のサービス及び第２のサービスの双方にアカウントを有するユーザに対する他のユーザからのアクションを示すアクション情報を記憶する。上記第１の表示ステップは、上記記憶されたアクション情報を基に、上記第１のサービスにおける上記ユーザの第１のページに、上記アクションの存在を上記ユーザへ通知する第１の通知情報を第１の表示態様で表示させる。上記第２の表示ステップは、上記第２のサービスにおける上記ユーザの第２のページに、上記アクションの存在を上記ユーザへ通知する、上記第１のサービスへのリンクを含む第２の通知情報を、上記第１の表示態様とは異なる第２の表示態様で表示させる。

以上のように、本発明によれば、インターネット上の複数のサービス間でユーザの回遊性を向上させることができる。

本発明の第１の実施形態に係るシステムのネットワーク構成を示した図である。 本発明の第１の実施形態における通知サーバのハードウェア構成を示したブロック図である。 本発明の第１の実施形態における通知サーバに記憶されるデータベースの具体例を示した図である。 本発明の第１の実施形態における通知サーバの動作の流れを示したフローチャートである。 本発明の第１の実施形態におけるＳＮＳのホームページの例を示した図である。 本発明の第１の実施形態におけるＳＮＳのホームページにおける通知情報一覧の表示例を示した図である。 本発明の第１の実施形態におけるブログのトップページにおける通知情報一覧の表示例を示した図である。 本発明の第１の実施形態において、ＳＮＳで通知情報が閲覧された場合の、ブログのトップページにおける通知情報一覧の表示例を示した図である。 本発明の第２の実施形態におけるブログのトップページにおける通知情報一覧の表示例を示した図である。 本発明の第３の実施形態におけるブログのトップページにおける通知情報一覧の表示例を示した図である。 本発明の第４の実施形態における通知サーバの動作の流れを示したフローチャートである。 本発明の第５の実施形態における通知サーバの動作の流れを示したフローチャートである。 本発明の第６の実施形態における通知サーバの動作の流れを示したフローチャートである。 本発明の第６の実施形態におけるブログのトップページにおける通知情報一覧の表示例を示した図である。 本発明の第７の実施形態における通知サーバの動作の流れを示したフローチャートである。

以下、本発明に係る実施形態を、図面を参照しながら説明する。

＜第１の実施形態＞
まず、本発明の第１の実施形態を説明する。

［システムのネットワーク構成］
図１は、本実施形態に係るシステムのネットワーク構成を示した図である。

同図に示すように、このシステムは、インターネット５０上の通知サーバ１００、ＳＮＳサーバ２００、ブログサーバ３００及び複数のユーザ端末４００を有する。

ＳＮＳサーバ２００は、ユーザ端末４００に対してＳＮＳを提供する。具体的には、ＳＮＳサーバ２００は、当該ＳＮＳにアカウントを有するユーザのユーザ端末４００の要求に応じて、当該ユーザ端末４００が有するブラウザを介して、当該ＳＮＳにおける当該ユーザのページを表示させる。またＳＮＳサーバ２００は、当該ユーザの投稿を受け付けて当該ページに表示させたり、当該ユーザに対する他のユーザからのアクションを受け付け、当該アクションの存在を通知する通知情報を当該ページに表示させたりする。

ブログサーバ３００は、ユーザ端末４００に対してブログサービスを提供する。具体的には、ブログサーバ３００は、当該ブログサービスにアカウントを有するユーザのユーザ端末４００の要求に応じて、上記ブラウザを介して、当該ブログサービスにおける当該ユーザのページを表示させる。当該ページでは、ユーザ端末４００のユーザがブログを作成及び更新するためのユーザインタフェースや、他のユーザのブログを検索及び閲覧できる機能等が提供される。

通知サーバ１００は、上記ＳＮＳサーバ２００及びブログサーバ３００とインターネット５０を介して接続されており、通知情報記憶部１１０及びＡＰＩ（Application Program Interface）１２０を有する。通知サーバ１００は、ＳＮＳサーバ２００から、あるユーザ（例えばユーザＡ）に対する他のユーザ（例えばユーザＢ）からのアクションに関する情報（以下、アクション情報）を、ＡＰＩ１２０を介して受信する。そして通知サーバ１００は、当該アクション情報を基に、上記アクションの存在を通知するための通知情報を作成して通知情報記憶部１１０に記憶する。そして通知サーバ１００は、ＳＮＳサーバ２００またはブログサーバ３００からＡＰＩ１２０を介して受信したリクエストに応じて、当該通知情報をＳＮＳサーバ２００及びブログサーバ３００へ送信して、ＳＮＳ及びブログにおけるユーザＡのページに表示させる。

また通知サーバ１００は、上記ＳＮＳサーバ２００及びブログサーバ３００から、上記ＡＰＩ１２０を介して、上記通知情報が閲覧されたことを示す既読情報を受信し、上記通知情報記憶部１１０に記憶する。当該既読情報は、通知情報がＳＮＳサーバ２００またはブログサーバ３００へ送信される際に利用される。これらの処理の詳細については後述する。

ここでアクションとは、例えば、あるユーザが投稿したコンテンツに対して他のユーザが行う、コメントの投稿操作、当該コンテンツが好き（支持できる）といった意思を示すための操作（いいね！またはナイス！ボタンの押下）、ＳＮＳ上であるユーザと新たに繋がるためのリクエスト送信操作（友達リクエスト）、あるユーザのコンテンツを自身のＳＮＳページのタイムライン上で表示させる（フォローする）ための設定操作またはそのためのリクエスト送信操作等をいうが、これらに限られない。

ユーザ端末４００は、例えばデスクトップＰＣ（Personal Computer）、ノートブックＰＣ、タブレットＰＣ、スマートフォン、携帯電話機等、ブラウザを有しインターネット５０に接続可能なあらゆる情報処理装置であり得る。同図では、ユーザ端末４００Ａとユーザ端末４００Ｂの２台のみが示されているが、実際にはユーザ端末４００の数は３台以上で有り得る。

［通知サーバのハードウェア構成］
図２は、上記通知サーバ１００のハードウェア構成を示した図である。同図に示すように、通知サーバ１００は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、入出力インタフェース１５、及び、これらを互いに接続するバス１４を備える。

ＣＰＵ１１は、必要に応じてＲＡＭ１３等に適宜アクセスし、各種演算処理を行いながら通知サーバ１００の各ブロック全体を統括的に制御する。ＲＯＭ１２は、ＣＰＵ１１に実行させるＯＳ、プログラムや各種パラメータなどのファームウェアが固定的に記憶されている不揮発性のメモリである。ＲＡＭ１３は、ＣＰＵ１１の作業用領域等として用いられ、ＯＳ、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。

入出力インタフェース１５には、表示部１６、操作受付部１７、記憶部１８、通信部１９等が接続される。

表示部１６は、例えばＬＣＤ（Liquid Crystal Display）、ＯＥＬＤ（Organic ElectroLuminescence Display）、ＣＲＴ（Cathode Ray Tube）等を用いた表示デバイスである。

操作受付部１７は、例えばマウス等のポインティングデバイス、キーボード、タッチパネル、その他の入力装置である。操作受付部１７がタッチパネルである場合、そのタッチパネルは表示部１６と一体となり得る。

記憶部１８は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリ（ＳＳＤ；Solid State Drive）、その他の固体メモリ等の不揮発性メモリである。当該記憶部１８には、上記ＯＳや各種アプリケーション、各種データが記憶される。特に本実施形態において、記憶部１８は、上記通知情報記憶部１１０として機能し、後述する通知情報データベースを記憶している。また記憶部１８には、上記通知情報の記憶処理及び送受信処理を制御するプログラムも記憶される。

通信部１９は、インターネット５０に接続するためのＮＩＣ等であり、ＳＮＳサーバ２００及びブログサーバ３００との間の通信処理を担う。

［ＳＮＳサーバ及びブログサーバのハードウェア構成］
上記ＳＮＳサーバ２００及びブログサーバ３００のハードウェア構成も、上記通知サーバ１００のハードウェア構成と同様であるため、詳細な説明を省略する。

［通知サーバのデータベース構成］
図３は、上記通知サーバ１００に記憶される通知情報データベースの具体例を示した図である。

同図に示すように、通知情報データベースには、アクションを行ったユーザのユーザ名、上記ＳＮＳにおける当該ユーザのページのＵＲＬ、アクションの種別及び日時、アクション対象のコンテンツのＵＲＬ、既読／未読の区別をそれぞれ示すデータが記憶されている。

ユーザ名、ユーザＵＲＬ、アクション種別／日時、コンテンツＵＲＬの各情報は、通知サーバ１００が通知情報を作成する際に利用される。既読／未読情報は、ＳＮＳサーバ２００またはブログサーバ３００から通知情報のリクエストを受信した際に、一方のサーバで既に閲覧された通知情報が他方のサーバで表示されないように、当該通知情報を削除するために利用される。

当該データベース内の通知情報は、常に最新の所定数が記憶されるように、ＳＮＳサーバ２００からアクション情報を受信する度に更新される。また既読／未読情報は、ＳＮＳサーバ２００またはブログサーバ３００から既読情報を受信する度に更新される。

［通知サーバの動作］
次に、以上のように構成された通知サーバ１００の動作について説明する。

図４は、本実施形態における通知サーバ１００が、ＳＮＳサーバ２００またはブログサーバ３００に通知情報を表示させる際の動作の流れを示したフローチャートである。当該動作は、通知サーバ１００の上記ＣＰＵ１１や通信部１９等のハードウェアと、プログラム（ソフトウェア）との協働により実行される。以下の説明では、便宜上、ＣＰＵ１１を動作主体とする。

同図に示すように、ＣＰＵ１１はまず、あるユーザに対する他のユーザのアクションを示すアクション情報をＳＮＳサーバ２００から受信したか否かを判断する（ステップ４１）。

アクション情報を受信した場合（Ｙｅｓ）、ＣＰＵ１１は、当該受信したアクション情報を上記通知情報データベースに保存する（ステップ４２）。

続いてＣＰＵ１１は、ＳＮＳサーバ２００及びブログサーバ３００の一方から、通知情報のリクエストを受信したか否かを判断する（ステップ４３）。

通知情報のリクエストを受信した場合（Ｙｅｓ）、ＣＰＵ１１は、通知情報記憶部１１０に記憶された通知情報を用いて、直近の所定数（例えば３０個）の通知情報の一覧を作成する（ステップ４４）。

続いてＣＰＵ１１は、通知情報のリクエスト元ではない、他方のサーバから、通知情報の既読情報を受信済みか否かを判断する（ステップ４５）。

既読情報を受信済みの場合（Ｙｅｓ）、上記通知情報の一覧から、既読情報に対応する通知情報を削除する（ステップ４６）。

そしてＣＰＵ１１は、上記既読情報に対応する通知情報を削除した一覧を、上記リクエスト元のサーバへ送信して表示させる（ステップ４７）。

既読情報を受信していない場合（ステップ４５のＮｏ）には、作成した一覧をリクエスト元のサーバへ送信して表示させる（ステップ４７）。

図５は、本実施形態におけるＳＮＳサーバ２００によってユーザ端末４００の表示部に表示されるＳＮＳのホームページの例を示した図である。

同図に示すように、ＳＮＳのホームページ上では、当該ＳＮＳにアカウントを有するユーザ（例えばユーザ名：ＴＡＲＯ）のタイムラインが表示される。当該タイムラインには、当該ユーザが投稿したコンテンツ（記事や写真等）や、当該ユーザのアクティビティ（コメントやシェア等）が、最新のものから時系列順に表示される。

また、当該タイムライン上では、上記ユーザのコンテンツやアクティビティに対して他のユーザが行ったアクションを示す情報も表示される。例えば、ユーザ（ＴＡＲＯ）の最新のつぶやきに対しては、他のユーザ（aaaaaとddddd）が"ナイス"し、その１つ前のつぶやきに対しては、他のユーザ（ccccc）が"ナイス"したことを示すメッセージ５２がそれぞれ表示される。また、上記最新のつぶやきに対して他のユーザ（aaaaa、bbbbb、ccccc）がそれぞれ投稿したコメント５３も表示される。

さらに、上記ホームページ上には、上記アクションに関する通知情報の一覧へのリンク５４も表示される。図６は、ユーザが当該リンク５４を押下した場合の通知情報一覧画面の表示例を示した図である。

同図に示すように、通知情報一覧６１では、他のユーザが行ったアクションを通知する複数の通知情報６２が一覧表示される。通知情報６２の数は例えば３０件であるが、これに限られない。

各通知情報６２は、アクションの主体であるユーザ名、アクションの対象となったコンテンツ（投稿、シェア、コメント、写真等）、アクションの種別に関する情報、及びアクションの日時に関する情報を含む。アクション主体のユーザ名を示すテキストにはその詳細に関するリンク６３が設けられ、当該リンク６３がクリック（またはタッチ）されると、上記一覧画面が、ＳＮＳにおける当該ユーザ名に対応するユーザのページに切り替わる。またアクション対象となったコンテンツを示すテキストにもその詳細に関するリンク６４が設けられており、当該リンクがクリック（またはタッチ）されると、上記一覧画面が、上記図５で示したタイムライン上の、上記コンテンツが掲載された位置に切り替わる。

図７は、ブログサービスのトップページにおける通知情報一覧の表示例を示した図である。

同図に示すように、ブログサービスのトップページでは、ブログ作成に関する各種情報に加えて、ＳＮＳからの通知情報一覧７１が表示される。同図は、ブログサーバ３００から通知サーバ１００に通知情報のリクエストがあった時点でＳＮＳからの既読情報が受信されていない場合の表示例を示している。この場合に表示される通知情報７２の内容は、上記図６で示したＳＮＳにおける通知情報と同様である。すなわち、通知情報７２は、アクション主体のユーザ名、アクション対象のコンテンツ、アクション種別及びアクション日時に関する情報を含み、アクション主体についてはリンク７３が設けられ、アクション対象コンテンツについてはリンク７４が設けられる。

一方、ブログサーバ３００から通知サーバ１００に通知情報のリクエストがあった時点で、ＳＮＳからの既読情報が受信されている場合には、その既読情報に対応する通知情報は、通知サーバ１００の送信前に一覧から削除される。図８は、この場合におけるブログサービスのトップページに表示される通知情報一覧の例を示した図である。

同図に示すように、例えば、図６で示した通知情報のうち、先頭の２つの通知情報（他のユーザ（aaaaa及びddddd）からの"ナイス"に関する通知情報）に設定されたアクション主体に関するリンク６３またはアクション対象コンテンツに関するリンク６４がクリックされると、その事実が既読情報としてＳＮＳサーバ２００から通知サーバ１００へ送信される。

その場合、通知サーバ１００は、ブログサーバ３００から通知情報のリクエストを受信すると、上記２つの通知情報を、通知サーバ１００が作成した一覧上から削除した上で

ブログサーバ３００へ送信する。したがってこの場合には、図７と図８とを比較すると分かるとおり、ブログサービスの通知情報一覧７１において、上記他のユーザ（aaaaa及びddddd）の"ナイス"に関する通知情報は表示されない。

図示しないが、ＳＮＳサーバ２００から通知サーバ１００へ通知情報のリクエストがあった時点で、ブログサーバ３００から既読情報が受信されている場合の処理も同様となる。

このように、本実施形態において通知サーバ１００は、ＳＮＳにおける通知情報をブログサービスにおいても表示させる際に、一方のサービスにおいて既読とされた（そこから詳細情報へのリンク先へアクセスされた）通知情報を、他方のサービスでは表示させないように制御することができる。これにより通知サーバ１００は、ＳＮＳ及びブログサービス間でのユーザの回遊性を向上させることができると共に、ユーザが同一の情報を双方のサービス上で閲覧することで煩わしさを感じるのを防ぐことができる。

＜第２の実施形態＞
次に、本発明の第２の実施形態を説明する。本実施形態及びこれ以降の実施形態においては、上記第１の実施形態と同様の構成及び機能を有する点については説明を省略し、第１実施形態と異なる点について説明する。

上述の第１の実施形態では、通知サーバ１００は、一方のサービスで既読とされた通知情報を他方のサービスで表示させないことで、両サービスにおける通知情報の表示態様が同一とならないよう制御していた。しかし本実施形態では、通知サーバ１００は、両サービス間で表示される通知情報の詳細度を異ならせることで両サービスにおける通知情報の表示態様を異ならせている。

図９は、本実施形態のブログサービスのトップページにおける通知情報の表示例を示した図である。

本実施形態のＳＮＳのホームページには、上記第１の実施形態と同様の通知情報一覧が表示される。一方、本実施形態のブログサービスのトップページには、図９に示すように、通知情報一覧７１として、他のユーザによるアクションを簡略化して通知するテキスト情報９１と、そのアクションの詳細情報へのリンク９２とが表示される。

テキスト情報９１には、例えば、単にユーザのコンテンツに対して特定のアクションがあった旨の情報が含まれ、アクションの主体や日時は表示されない。また当該テキスト自体にはアクション対象のコンテンツに関するリンク等は含まれず、その代わりに、詳細情報へのリンク９２が用意されている。

詳細情報へのリンク９２がクリック（またはタッチ）されると、上記第１の実施形態の図７で示したのと同様の通知情報が表示される。

この場合通知サーバ１００は、ＳＮＳサーバ２００から通知情報のリクエストがあった際には、上記図７で示したような通知情報一覧を作成して送信する。一方、ブログサーバ３００から通知情報のリクエストがあった際には、ＳＮＳサーバ２００用の通知情報を簡略化した図９に示すような通知情報を作成して送信し、上記詳細情報のリンク９２についてリクエストがあった際には、上記図７で示したような通知情報一覧を送信する。

このように本実施形態では、通知サーバ１００は、ＳＮＳとブログサービスにおいて表示される通知情報の詳細度を異ならせることで、ユーザをブログサービスからＳＮＳへ誘導することができるとともに、通知情報がブログサービス上で作業中のユーザの邪魔になるのを極力回避することができる。

＜第３の実施形態＞
次に、本発明の第３の実施形態を説明する。

本実施形態では、通知サーバ１００は、ＳＮＳとブログサービスにおいて表示される通知情報一覧の表示順を異ならせることとしている。

図１０は、本実施形態のブログサービスのトップページにおける通知情報の表示例を示した図である。

本実施形態のＳＮＳのホームページには、上記第１及び第２の実施形態と同様の通知情報一覧が表示される。一方、本実施形態のブログサービスのトップページには、図１０に示すように、ＳＮＳのホームページに表示される通知情報一覧とはその表示順が逆とされた通知情報一覧７１が表示される。

すなわち、ＳＮＳのホームページにおける通知情報一覧６１は、直近の所定数（例えば３０件）の通知情報のうち、最新の通知情報ほど上部に表示されるように構成されるが、それとは逆に、ブログのトップページにおける通知情報一覧７１は、最新の通知情報ほど下部に表示されるように構成される。

この場合通知サーバ１００は、ＳＮＳサーバ２００から通知情報のリクエストがあった際には、上記図７で示したような通知情報一覧を作成して送信する。一方、ブログサーバ３００から通知情報のリクエストがあった際には、ＳＮＳサーバ２００用の通知情報一覧の表示順を逆にした図１０に示すような通知情報一覧を作成して送信する。

このように本実施形態では、通知サーバ１００は、ＳＮＳとブログサービスにおいて表示される通知情報の表示順序を異ならせることで、双方のページで、同じアクションに関する通知情報がユーザに閲覧されてしまうのを極力防ぐことができる。これは、通常、ユーザは、上部に表示される通知情報ほど先に閲覧すると考えられるためである。

＜第４の実施形態＞
次に、本発明の第４の実施形態を説明する。

本実施形態では、通知サーバ１００は、ＳＮＳとブログサービスにおいて表示される通知情報の表示タイミングを異ならせることとしている。

図１１は、本実施形態における通知サーバ１００の動作の流れを示したフローチャートである。同図は、ブログサービスにおける通知情報の表示処理を説明するものであり、ＳＮＳにおける通知情報の表示処理は、上述の各実施形態と同様である。

同図に示すように、通知サーバ１００のＣＰＵ１１は、ユーザ端末４００からブログサーバ３００（ブログサービスのトップページ）へアクセスがあったか否かを判断する（ステップ１１１）。ユーザ端末４００からブログサーバ３００へアクセスがあった際には、ブログサーバ３００は通知情報リクエストのために通知サーバ１００のＡＰＩ１２０へアクセスするため、通知サーバ１００は当該ＡＰＩ１２０へのアクセスの有無によりブログサーバ３００へのアクセスの有無を判断することができる。またこの際、アクセス元のユーザ端末４００を特定するための情報（例えばＩＰアドレス等）も通知サーバ１００に送信される。

ブログサービスへアクセスがあったと判断した場合（Ｙｅｓ）、ＣＰＵ１１は、その時点からタイマーを起動することで、ユーザ端末４００のユーザによるブログサービスでの滞在時間の計測を開始する（ステップ１１２）。

続いてＣＰＵ１１は、上記滞在時間が、上記アクセス元のユーザ端末４００の、ブログサービスにおける平均滞在時間の所定割合を経過したか否かを判断する（ステップ１１３）。当該平均滞在時間は、所定期間（例えば１週間、１ヶ月等）における上記ユーザ端末４００のブログサービスへのアクセス履歴の解析により、通知サーバ１００によって予め算出され、記憶部１８に保存される。そのため、通知サーバ１００は、ブログサーバ３００から上記アクセス履歴情報を定期的に受信する。しかし、ブログサーバ３００が所定期間内の平均滞在時間を算出し、それを通知サーバ１００へ通知しても構わない。また上記所定割合とは、例えば９割等である。

滞在時間が平均滞在時間の所定割合を経過したと判断した場合（Ｙｅｓ）、ＣＰＵ１１は、上記ＳＮＳサーバ２００へ送信されるのと同様の通知情報一覧を作成し、それをブログサーバ３００へ送信して表示させる（ステップ１１４）。したがって例えば平均滞在時間が１０分の場合、ブログサーバ３００へのアクセスから９分が経過した場合に通知情報一覧が表示されることになる。

このように本実施形態では、通知サーバ１００は、ユーザがブログサービスにアクセスしてから離脱しそうなタイミングで通知情報一覧を表示させることで、ユーザのブログサービスにおける滞在時間を減らさせる（閲覧動作を邪魔する）ことなく、ユーザをＳＮＳにスムースに誘導することができる。

＜第５の実施形態＞
次に、本発明の第５の実施形態を説明する。

本実施形態では、通知サーバ１００は、ユーザからＳＮＳとブログサービスとが同時にアクセスされている場合に、ＳＮＳとブログサービスとで表示される通知情報の数を異ならせることとしている。

図１２は、本実施形態における通知サーバ１００の動作の流れを示したフローチャートである。

同図に示すように、通知サーバ１００のＣＰＵ１１はまず、ユーザ端末４００からＳＮＳサーバ２００にアクセスがあったか否かを判断する（ステップ１２１）。

ＳＮＳサーバ２００にアクセスがあったと判断した場合、ＣＰＵ１１は、上述の各実施形態でＳＮＳにおいて表示されたのと同様の通知情報一覧を作成してＳＮＳサーバ２００へ送信する（ステップ１２２）。

続いて通知サーバ１００は、ユーザ端末４００からＳＮＳサーバ２００へのアクセス継続中に、ユーザ端末４００からブログサーバ３００にもアクセスがあったか否かを判断する（ステップ１２３）。

ブログサーバ３００にもアクセスがあった場合（Ｙｅｓ）、通知サーバ１００は、上記ＳＮＳサーバ２００へ送信した通知情報一覧から、その先頭の所定数（例えば３件、５件、１０件等）を削除した一覧を作成し、ブログサーバ３００へ送信する（ステップ１２４）。

このように本実施形態では、通知サーバ１００は、ＳＮＳサーバ２００とブログサーバ３００とが同時にアクセスされた場合には、ＳＮＳにおいて表示された所定数の通知情報はユーザによって既読とみなし、ブログサービスではそれら所定数の情報を表示させないことで、ユーザが同じ情報を何度も閲覧してしまうことを極力防ぐことができる。

＜第６の実施形態＞
次に、本発明の第６の実施形態を説明する。

本実施形態では、通知サーバ１００は、ＳＮＳとブログサービスとで、表示される通知情報の種別を異ならせることとしている。

図１３は、本実施形態における通知サーバ１００の動作の流れを示したフローチャートである。また図１４は、本実施形態のブログサービスのトップページにおける通知情報の表示例を示した図である。

図１３に示すように、通知サーバ１００のＣＰＵ１１はまず、ユーザ端末４００からＳＮＳサーバ２００にアクセスがあったか否かを判断する（ステップ１３１）。

ＳＮＳサーバ２００にアクセスがあったと判断した場合、ＣＰＵ１１は、上述の各実施形態でＳＮＳにおいて表示されたのと同様の通知情報一覧を作成してＳＮＳサーバ２００へ送信する（ステップ１３２）。

続いてＣＰＵ１１は、ユーザ端末４００からブログサーバ３００にアクセスがあったか否かを判断する（ステップ１３３）。

ブログサーバ３００にアクセスがあったと判断した場合（Ｙｅｓ）、ＣＰＵ１１は、上記ＳＮＳサーバ２００へ送信した通知情報一覧から、所定以上の重要度を有するアクションに関する通知情報のみを抽出する（ステップ１３４）。当該重要度は、予め通知サーバ１００によって設定されていてもよいし、ユーザによって設定されてもよい。当該重要度に関する情報は、通知サーバ１００の記憶部１８に記憶されている。本実施形態では、例えば"ナイス"、"コメント"、"フォロー"等のアクションのうち、新たなユーザの繋がりを生み出す"フォロー"が重要なアクションとみなされ、それに対して高い重要度が設定されているものとする。

そして通知サーバ１００は、上記抽出した重要度が高いアクションのみに関する通知情報の一覧を作成し、ブログサーバ３００へ送信する（ステップ１３５）。

図１４に示すように、本実施形態では、ＳＮＳで表示される通知情報のうち、他のユーザからのフォローに関する通知情報７２のみがリストアップされて表示されている。

このように本実施形態では、通知サーバ１００は、ブログサービスにおいてはＳＮＳにおいて表示された通知情報のうち重要度の高い情報のみを表示させることで、通知情報の表示がブログサービスで作業中にユーザの邪魔になるのを極力防ぎながら、通知すべき情報を通知し、ＳＮＳへユーザを誘導することができる。

＜第７の実施形態＞
次に、本発明の第７の実施形態を説明する。

本実施形態では、通知サーバ１００は、ＳＮＳとブログサービスとで、表示される通知情報の元になるアクションの主体を異ならせることとしている。

図１５は、本実施形態における通知サーバ１００の動作の流れを示したフローチャートである。

同図に示すように、通知サーバ１００のＣＰＵ１１はまず、ユーザ端末４００からＳＮＳサーバ２００にアクセスがあったか否かを判断する（ステップ１５１）。

ＳＮＳサーバ２００にアクセスがあったと判断した場合、ＣＰＵ１１は、上述の各実施形態でＳＮＳにおいて表示されたのと同様の通知情報一覧を作成してＳＮＳサーバ２００へ送信する（ステップ１５２）。

続いて通知サーバ１００は、ユーザ端末４００からブログサーバ３００にアクセスがあったか否かを判断する（ステップ１５３）。

ブログサーバ３００にアクセスがあったと判断した場合（Ｙｅｓ）、ＣＰＵ１１は、上記ＳＮＳサーバ２００へ送信した通知情報一覧から、ＳＮＳにおけるユーザのページに対して所定以上のアクセス頻度を有する他のユーザを抽出する（ステップ１５４）。当該アクセス頻度は、ＳＮＳサーバ２００から例えば定期的に通知サーバ１００へ送信されるアクセス履歴を元に、通知サーバ１００によってユーザ毎に算出される。しかし、当該アクセス頻度は、ＳＮＳサーバ２００によって算出されて通知サーバ１００へ定期的に送信されてもよい。ここで所定以上のアクセス頻度とは、例えば数日に１アクセス以上等であるが、これに限られない。

続いてＣＰＵ１１は、上記通知情報一覧から、上記抽出したユーザのアクションに関する通知情報のみを抽出する（ステップ１５５）。

そしてＣＰＵ１１は、抽出した通知情報の一覧を作成してブログサーバ３００へ送信する（ステップ１５６）。

このように本実施形態では、通知サーバ１００は、ブログサービスにおいては、他のユーザのうち、アクション対象のユーザに関心の高いユーザによるアクションの通知情報のみを表示させることで、通知情報の表示がブログサービスで作業中のユーザの邪魔になるのを極力防ぎながら、ＳＮＳへユーザを誘導することができる。

例えば、ＳＮＳにおいて他のユーザのページに表示される友達（またはフォロー）推薦領域を介して、アクション対象ユーザのページを何度も閲覧している他のユーザは、ユーザと友達になることまたはユーザをフォローすることに興味がある可能性が高い。したがって通知サーバ１００は、そのような他のユーザのアクションに関する通知情報のみをブログサービスで表示させることで、ユーザをＳＮＳへ誘導させ、上記他のユーザとの繋がりを促進させることができる。

［変形例］
本発明は上述の実施形態にのみ限定されるものではなく、本開示の要旨を逸脱しない範囲内において種々変更され得る。

上述の各実施形態では、ＳＮＳにおける通知情報がブログサービスのページにも表示される例が示されたが、本発明はこの両サービス間の処理に限られない。例えば、異なるＳＮＳ間または異なるブログサービス間でのアクション情報に関する通知情報が表示されてもよい。

また本発明は、ＳＮＳ及びブログ以外のサービス間における通知情報の表示処理にも適用可能である。その他のサービスとしては、例えばオークションサービス、Ｑ＆Ａサービス、口コミサイトサービス（レビューの投稿が可能なサービス）等、あらゆる種類のサービスが挙げられる。

またその場合、通知情報の元になるアクションも、上述の各実施形態で説明した"ナイス"、"コメント"、"フォロー"等に限られない。例えばオークションサイト、ＥＣサービスサイト、Ｑ＆Ａサービス等において投稿されたコメント、レビュー、評価（例えば星の数による）等もアクションに含まれる。

また上述の各実施形態では、ＳＮＳにおける他のユーザのアクションに関する通知情報がブログサービスのページにおいて表示される例が示された。しかし、本発明は、逆にブログサービスにおける他のユーザのアクション（例えばブログの投稿に対するコメントやシェア等）に関する通知情報がＳＮＳのページにおいて表示される場合にも適用可能である。

上述の第１〜第７の各実施形態は、矛盾が生じない限り如何様にも組み合わされて実行され得る。

１１…ＣＰＵ
１３…ＲＡＭ
１８…記憶部
１９…通信部
５０…インターネット
５４、６３、６４、７３、７４、９２…リンク
６１…通知情報一覧
６２…通知情報
７１…通知情報一覧
７２…通知情報
１００…通知サーバ
１１０…通知情報記憶部
１２０…ＡＰＩ
２００…ＳＮＳサーバ
３００…ブログサーバ
４００（４００Ａ，４００Ｂ）…ユーザ端末

Claims (6)

1. インターネット上の第１のサービス及び第２のサービスの双方にアカウントを有するユーザに対する複数の他のユーザからのアクションを示すアクション情報と、前記第１のサービスにおける前記ユーザの第１のページへの前記複数の他のユーザのアクセス履歴を示すアクセス履歴情報とを記憶する記憶部と、
   前記記憶されたアクション情報を基に、前記第１のページに、前記複数の他のユーザのアクションの存在を前記ユーザへ通知する第１の通知情報を第１の表示態様で表示させ、前記アクセス履歴情報を基に、前記第２のサービスにおける前記ユーザの第２のページに、前記第１のページへの所定値以上のアクセス頻度を有する他のユーザのアクションの存在を前記ユーザへ通知する、前記第１のサービスへのリンクを含む第２の通知情報を表示させる制御部と
   を具備する情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記第１の通知情報は前記アクションに関する詳細情報へのリンクを有し、
   前記制御部は、前記第１のページで前記第１の通知情報から前記詳細情報へのアクセスが検出された場合に、当該詳細情報へのアクセスが検出されていない第１の通知情報のみに対応する前記第２の通知情報が表示されるように前記第２のページを制御する
   情報処理装置。
3. 請求項１に記載の情報処理装置であって、
   前記記憶部は、前記ユーザが前記第２のページにアクセスして滞在する時間を所定アクセス分平均した平均滞在時間情報を記憶し、
   前記制御部は、前記平均滞在時間情報を基に、前記第２の通知情報を、前記ユーザが前記第２のページにアクセスしてから前記平均滞在時間の所定割合の時間が経過したときに表示させるように前記第２のページを制御する
   情報処理装置。
4. 請求項１に記載の情報処理装置であって、
   前記第１の通知情報及び前記第２の通知情報は、複数の異なるアクション毎に、種類の異なる複数の通知情報を有し、
   前記記憶部は、前記種類の異なるアクション毎の重要度を示す重要度情報を記憶し、
   前記制御部は、前記重要度情報を基に、前記複数の第１の通知情報のうち、所定以上の重要度を有する通知情報を前記第２の通知情報として表示するように前記第２のページを制御する
   情報処理装置。
5. インターネット上の第１のサービス及び第２のサービスの双方にアカウントを有するユーザに対する複数の他のユーザからのアクションを示すアクション情報と、前記第１のサービスにおける前記ユーザの第１のページへの前記複数の他のユーザのアクセス履歴を示すアクセス履歴情報とを記憶し、
   前記記憶されたアクション情報を基に、前記第１のページに、前記複数の他のユーザのアクションの存在を前記ユーザへ通知する第１の通知情報を第１の表示態様で表示させ、
   前記アクセス履歴情報を基に、前記第２のサービスにおける前記ユーザの第２のページに、前記第１のページへの所定値以上のアクセス頻度を有する他のユーザのアクションの存在を前記ユーザへ通知する、前記第１のサービスへのリンクを含む第２の通知情報を表示させる
   情報処理方法。
6. 情報処理装置に、
   インターネット上の第１のサービス及び第２のサービスの双方にアカウントを有するユーザに対する複数の他のユーザからのアクションを示すアクション情報と、前記第１のサービスにおける前記ユーザの第１のページへの前記複数の他のユーザのアクセス履歴を示すアクセス履歴情報とを記憶するステップと、
   前記記憶されたアクション情報を基に、前記第１のページに、前記複数の他のユーザのアクションの存在を前記ユーザへ通知する第１の通知情報を第１の表示態様で表示させるステップと、
   前記アクセス履歴情報を基に、前記第２のサービスにおける前記ユーザの第２のページに、前記第１のページへの所定値以上のアクセス頻度を有する他のユーザのアクションの存在を前記ユーザへ通知する、前記第１のサービスへのリンクを含む第２の通知情報を表示させるステップと
   を実行させるプログラム。

Images