特許 5770804 通知管理方法、通知管理サーバ及び通知管理プログラム

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】5770804

(24)【登録日】2015年7月3日

(45)【発行日】2015年8月26日

(54)【発明の名称】通知管理方法、通知管理サーバ及び通知管理プログラム

(51)【国際特許分類】

   G06F 3/048 20130101AFI20150806BHJP

   G06F 13/00 20060101ALI20150806BHJP

   A63F 13/30 20140101ALI20150806BHJP

   A63F 13/79 20140101ALI20150806BHJP

   A63F 13/85 20140101ALI20150806BHJP

【ＦＩ】

   G06F3/048 654C

   G06F13/00 550A

   A63F13/30

   A63F13/79

   A63F13/85

【請求項の数】10

【全頁数】17

(21)【出願番号】特願2013-204206(P2013-204206)

(22)【出願日】2013年9月30日

(65)【公開番号】特開2015-69490(P2015-69490A)

(43)【公開日】2015年4月13日

【審査請求日】2013年9月30日

(73)【特許権者】

【識別番号】504437801

【氏名又は名称】グリー株式会社

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(72)【発明者】

【氏名】村田 慶介

【審査官】 岩橋 龍太郎

(56)【参考文献】

【文献】 特開２００３−３２５９８３（ＪＰ，Ａ）

【文献】 特開２０１１−１８６５８１（ＪＰ，Ａ）

【文献】 特開２００１−２０４９７２（ＪＰ，Ａ）

【文献】 特開２００５−２１７５２２（ＪＰ，Ａ）

【文献】 特開２０１３−２５５５２６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ３／０４８

Ｇ０６Ｆ ３／１４

Ｇ０６Ｆ １３／００

Ａ６３Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

ユーザ端末におけるアプリケーションの使用状況、及びユーザ端末に対する通知を記憶する記憶部と、
ネットワークを介して、ユーザ端末に接続された制御部とを用いて、複数のアプリケーションを管理する方法であって、
前記制御部が、
ユーザ端末におけるアプリケーションの使用状況に応じて通知方法を決定するための転送方法決定情報を保持し、
ユーザ端末に対する新たな通知を受信した場合、前記記憶部に記憶し、
前記記憶部において、前記ユーザ端末のアプリケーションの使用状況を確認し、
前記使用状況において、アプリケーションの使用中でないと判定した場合には、前記転送方法決定情報を用いて、通知表示のための別のアプリケーションを起動させる必要がある通知方法を決定し、前記通知方法により通知し、
前記使用状況において、複数のアプリケーションを利用するユーザにおいてアプリケーションの使用中と判定した場合には、前記転送方法決定情報を用いて、前記ユーザ端末において使用中のアプリケーション表示内において出力する通知方法を決定し、前記記憶部に記憶された前記通知について、前記ユーザ端末において使用中のアプリケーション表示内において、前記通知に関連する他のアプリケーションについての情報を、前記通知の通知種別に応じて統合して出力するためのリンク情報を出力することを特徴とする通知管理方法。

【請求項2】

前記制御部が、
前記通知の内容に応じて緊急性を評価し、
前記緊急性の評価結果に応じて、前記通知方法を決定することを特徴とする請求項１に記載の通知管理方法。

【請求項3】

前記制御部が、
前記ユーザ端末において使用中のアプリケーションの状態を評価し、
前記緊急性の評価結果とアプリケーションの状態の評価結果との比較に基づいて、前記通知方法を決定することを特徴とする請求項２に記載の通知管理方法。

【請求項4】

前記記憶部には、ユーザ端末において、アプリケーション表示内において出力した通知の対応履歴を記憶し、
前記制御部が、
新たな通知を受信した場合、前記記憶部において、前記通知と共通する過去の通知に対する対応履歴を特定し、
前記対応履歴に基づいて、前記通知方法を決定することを特徴とする請求項１〜３のいずれか１項に記載の通知管理方法。

【請求項5】

前記制御部が、
前記ユーザ端末において使用中のアプリケーションの状態を評価し、
前記状態に対応する対応履歴を特定することを特徴とする請求項４に記載の通知管理方法。

【請求項6】

前記通知に関連する他のアプリケーションについての情報を、前記通知の通知種別に応じて異なるタブが付加された画面に出力することを特徴とする請求項１〜５のいずれか１項に記載の通知管理方法。

【請求項7】

前記他のアプリケーションには、ゲームに関するものが含まれ、
前記ゲームにおいてユーザが用いるキャラクタの体力の回復状況を取得し、
前記リンク情報には、前記回復状況を示す情報を含めることを特徴とする請求項１〜６のいずれか１項に記載の通知管理方法。

【請求項8】

前記他のアプリケーションには、ゲームに関するものが含まれ、
前記ゲームについての他のユーザからの協力要請を取得し、
前記リンク情報には、前記他のユーザからの協力要請を含めることを特徴とする請求項１〜７のいずれか１項に記載の通知管理方法。

【請求項9】

ユーザ端末におけるアプリケーションの使用状況、及びユーザ端末に対する通知を記憶する記憶部と、
ネットワークを介して、ユーザ端末に接続された制御部とを備え、
前記制御部が、
ユーザ端末におけるアプリケーションの使用状況に応じて通知方法を決定するための転
送方法決定情報を保持し、
ユーザ端末に対する新たな通知を受信した場合、前記記憶部に記憶し、
前記記憶部において、前記ユーザ端末のアプリケーションの使用状況を確認し、
前記使用状況において、アプリケーションの使用中でないと判定した場合には、転送方法決定情報を用いて、通知表示のための別のアプリケーションを起動させる必要がある通知方法を決定し、前記通知方法により通知し、
前記使用状況において、複数のアプリケーションを利用するユーザにおいてアプリケーションの使用中と判定した場合には、前記転送方法決定情報を用いて、前記ユーザ端末において使用中のアプリケーション表示内において出力する通知方法を決定し、前記記憶部に記憶された前記通知について、前記ユーザ端末において使用中のアプリケーション表示内において、前記通知に関連する他のアプリケーションについての情報を、前記通知の通知種別に応じて統合して出力するためのリンク情報を出力することを特徴とする通知管理サーバ。

【請求項10】

ユーザ端末におけるアプリケーションの使用状況、及びユーザ端末に対する通知を記憶する記憶部と、
ネットワークを介して、ユーザ端末に接続された制御部とを用いて、複数のアプリケーションを管理するプログラムであって、
前記制御部を、
ユーザ端末におけるアプリケーションの使用状況に応じて通知方法を決定するための転送方法決定情報を保持し、
ユーザ端末に対する新たな通知を受信した場合、前記記憶部に記憶し、
前記記憶部において、前記ユーザ端末のアプリケーションの使用状況を確認し、
前記使用状況において、アプリケーションの使用中でないと判定した場合には、転送方法決定情報を用いて、通知表示のための別のアプリケーションを起動させる必要がある通知方法を決定し、前記通知方法により通知し、
前記使用状況において、複数のアプリケーションを利用するユーザにおいてアプリケーションの使用中と判定した場合には、前記転送方法決定情報を用いて、前記ユーザ端末において使用中のアプリケーション表示内において出力する通知方法を決定し、前記記憶部に記憶された前記通知について、前記ユーザ端末において使用中のアプリケーション表示内において、前記通知に関連する他のアプリケーションについての情報を、前記通知の通知種別に応じて統合して出力するためのリンク情報を出力する手段
として機能させることを特徴とする通知管理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ユーザに対する通知を管理する通知管理方法、通知管理サーバ及び通知管理プログラムに関する。

【背景技術】

【0002】

近年、ネットワークを介して各種ゲームが提供されている。このようなゲームには、ソーシャル・ネットワーキング・サービス（ＳＮＳ）上で提供されるソーシャルゲームもある。

【0003】

このようなゲームにおいて、ゲームに登場するキャラクタの状態を管理するための技術も検討されている（例えば、特許文献１参照）。この文献に記載された技術では、他のキャラクタからの攻撃が発生したとき、キャラクタの状態を表すパラメータの値として、ダメージの累積を算出する。そして、ダメージを受けた後の時間的な経過により回復するストレス値に応じてモーション再生手順を決定する。

【0004】

また、ユーザ同士の相乗効果によりユーザの興趣を高めるための技術も検討されている（例えば、特許文献２参照）。この文献に記載されたサーバ装置においては、複数の第１の特性データをユーザ毎に関連付けて記憶し、第２の特性データを複数の第１の特性データが属するグループ毎に関連付けて記憶する。ゲームの実行中に所定のイベントが発生した場合、他のユーザを選択し、ユーザ及び他のユーザに関連付けられている第１の特性データの中に、グループに属する第１の特性データがすべて含まれているか否かを判定する。そして、ユーザ及び他のユーザに関連付けられている第１の特性データに加えて、属する第１の特性データがすべて含まれていると判定されたグループに関連付けられている第２の特性データを用いて所定のアクションを実行する。

【0005】

また、オンラインゲームを観戦するプレーヤが、ゲームプレイを行うプレーヤに対して応援する動機を与えるための技術も検討されている（例えば、特許文献３参照）。この文献に記載されたサーバは、応援情報に基づいて、特定条件を満たすか否かを判断し、特定条件を満たす場合には特殊コマンドの実行の制限を解除する処理を行なう。特殊コマンドの実行の制限が解除されている場合に、プレーヤからの操作情報に基づき特殊コマンドを実行させる処理を行なう。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２００１−８７５４３公報（第１頁、図１）

【特許文献2】特開２０１３−１６３０３０公報（第１頁、図１）

【特許文献3】特開２０１３−６３２９６公報（第１頁、図１）

【発明の概要】

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

【0007】

特許文献１に記載されているように、ゲームに登場するキャラクタの状態は、時間経過とともに状態が変化する。また、特許文献２に記載されているゲームにおいて、複数のユーザが協働するが、特許文献３に記載されているように、他のユーザに対する応援が必要になる場合もある。

【0008】

しかしながら、多くのアプリケーションが提供されている場合、これらのアプリケーションが個別独立に管理されていることがある。例えば、各アプリケーションの提供者（プロバイダ）が異なる場合には、他プロバイダにおいて管理されているアプリケーションの状況を把握することができない。このため、ユーザが特定のアプリケーションを使用している場合、他のアプリケーションにおける状態が変化したことを把握できないことがある。例えば、ゲームに登場するキャラクタの体力回復状況を把握できなければ、タイムリーなゲーム利用が困難である。また、他のユーザから応援等の協力要請を迅速に把握ができなければ、的確な対応が困難である。

【0009】

また、ゲーム等のアプリケーションを使用している場合に、電子メール等による通知を取得する場合がある。この場合には、使用中のアプリケーションに加えて、通知表示のための別のアプリケーション（例えば、メーラー等）を起動させる必要がある。この場合、通知に気がつかなかったり、通知表示のためのアプリケーションの起動に手間がかかったりするという課題がある。

【0010】

本発明は、上述した問題に鑑みてなされたものであり、その目的は、ユーザに対して効率的に通知を行なうための通知管理方法、通知管理サーバ及び通知管理プログラムを提供することにある。

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

【0011】

（１）上記課題を解決する通知管理方法においては、ユーザ端末におけるアプリケーションの使用状況、及びユーザ端末に対する通知を記憶する記憶部と、ネットワークを介して、ユーザ端末に接続された制御部とを用いる。そして、前記制御部が、ユーザ端末におけるアプリケーションの使用状況に応じて通知方法を決定するための転送方法決定情報を保持し、ユーザ端末に対する新たな通知を受信した場合、前記記憶部に記憶し、前記記憶部において、前記ユーザ端末のアプリケーションの使用状況を確認し、前記使用状況にお
いて、アプリケーションの使用中でないと判定した場合には、転送方法決定情報を用いて、通知表示のための別のアプリケーションを起動させる必要がある通知方法を決定し、前記通知方法により通知し、前記使用状況において、複数のアプリケーションを利用するユーザにおいてアプリケーションの使用中と判定した場合には、前記転送方法決定情報を用いて、前記ユーザ端末において使用中のアプリケーション表示内において出力する通知方法を決定し、前記記憶部に記憶された前記通知について、前記ユーザ端末において使用中のアプリケーション表示内において、前記通知に関連する他のアプリケーションについての情報を、前記通知の通知種別に応じて統合して出力するためのリンク情報を出力する。これにより、アプリケーションの使用中であっても、タイムリーに通知を出力することができる。

【0012】

（２）上記通知管理方法においては、前記制御部が、前記通知の内容に応じて緊急性を評価し、前記緊急性の評価結果に応じて、前記通知方法を決定することが好ましい。これにより、通知の緊急性に応じて、アプリケーション表示内における通知の出力要否を決定することができる。

【0013】

（３）上記通知管理方法においては、前記制御部が、前記ユーザ端末において使用中のアプリケーションの状態を評価し、前記緊急性の評価結果とアプリケーションの状態の評価結果との比較に基づいて、前記通知方法を決定することが好ましい。これにより、通知の出力が、使用中のアプリケーションの妨げになる場合には、通知の出力を抑制することができる。

【0014】

（４）上記通知管理方法においては、前記記憶部には、ユーザ端末において、アプリケーション表示内において出力した通知の対応履歴を記憶し、前記制御部が、新たな通知を受信した場合、前記記憶部において、前記通知と共通する過去の通知に対する対応履歴を特定し、前記対応履歴に基づいて、前記通知方法を決定することが好ましい。これにより、通知に対する対応履歴に応じて、アプリケーション表示内における通知の出力要否を決定することができる。

【0015】

（５）上記通知管理方法においては、前記制御部が、前記ユーザ端末において使用中のアプリケーションの状態を評価し、前記状態に対応する対応履歴を特定することが好ましい。これにより、アプリケーションの状態に応じた対応履歴により、アプリケーション表示内における通知の出力要否を決定することができる。
（６）上記通知管理方法においては、前記通知に関連する他のアプリケーションについての情報を、前記通知の通知種別に応じて異なるタブが付加された画面に出力することが好ましい。これにより、タブを選択して通知内容を確認することができる。
（７）上記通知管理方法においては、前記他のアプリケーションには、ゲームに関するものが含まれ、前記ゲームにおいてユーザが用いるキャラクタの体力の回復状況を取得し、前記リンク情報には、前記回復状況を示す情報を含めることが好ましい。これにより、他のゲームにおける状況をタイムリーに把握できる。
（８）上記通知管理方法においては、前記他のアプリケーションには、ゲームに関するものが含まれ、前記ゲームについての他のユーザからの協力要請を取得し、前記リンク情報には、前記他のユーザからの協力要請を含めることが好ましい。これにより、協力要請をタイムリーに把握できる。

【発明の効果】

【0016】

本発明によれば、ユーザに対して効率的に通知を行なうことができる。

【図面の簡単な説明】

【0017】

【図1】第１の実施形態のシステム概略図。

【図2】第１の実施形態の処理手順の説明図であって、（ａ）はログイン管理処理、（ｂ）は通知転送処理の説明図。

【図3】第１の実施形態の画面例の説明図。

【図4】第２の実施形態の処理手順の説明図。

【図5】第３の実施形態の処理手順の説明図。

【図6】第４の実施形態の処理手順の説明図。

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

【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】

１０…ユーザ端末、２０…管理サーバ、２１…制御部、２１１…ユーザ管理部、２１２…通知取得部、２１３…ユーザ状況判定部、２１４…通知転送部、２２…ユーザ情報記憶部、２３…通知情報記憶部、３０…ゲームサーバ。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】