JP6679708B2 - プログラム、ユーザ端末、通知方法、及び通知システム - Google Patents

Description

本発明は、ユーザに対する通知を行うプログラム、ユーザ端末、通知方法、及び通知システムに関する。

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

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

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

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

特開２００１−８７５４３公報（第１頁、図１） 特開２０１３−１６３０３０公報（第１頁、図１） 特開２０１３−６３２９６公報（第１頁、図１）

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

しかしながら、多くのアプリケーションが提供されている場合、これらのアプリケーションが個別独立に管理されていることがある。例えば、各アプリケーションの提供者（プ
ロバイダ）が異なる場合には、他プロバイダにおいて管理されているアプリケーションの状況を把握することができない。

このため、ユーザが特定のアプリケーションを使用している場合、他のアプリケーションにおける状態が変化したことを把握できないことがある。例えば、ゲームに登場するキャラクタの体力回復状況を把握できなければ、タイムリーなゲーム利用が困難である。また、他のユーザから応援等の協力要請を迅速に把握ができなければ、的確な対応が困難である。

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

本発明は、上述した問題に鑑みてなされたものであり、その目的は、ユーザに対して効率的に通知を行なうことにある。

上記課題を解決するプログラムは、ゲームに関する通知を行うための通知プログラムであって、ユーザが使用するユーザ端末の制御部に、前記ユーザ端末で第１ゲームを使用している状態で、使用中ではない第２ゲームであって当該第２ゲームを使用する他のユーザからの協力要請をサーバから受信した場合に、前記第１ゲーム内で協力要請に関する情報を当該ユーザ端末のディスプレイに表示させる。

上記課題を解決するユーザ端末は、ゲームに関する通知を行うユーザ端末であって、前記ユーザ端末で第１ゲームを使用している状態で、使用中ではない第２ゲームであって当該第２ゲームを使用する他のユーザからの協力要請をサーバから受信した場合に、前記第１ゲーム内で協力要請に関する情報を当該ユーザ端末のディスプレイに表示させる。

上記課題を解決する通知方法は、ゲームに関する通知を行う通知方法であって、ユーザが使用するユーザ端末が、前記ユーザ端末で第１ゲームを使用している状態で、使用中ではない第２ゲームであって当該第２ゲームを使用する他のユーザからの協力要請をサーバから受信した場合に、前記第１ゲーム内で協力要請に関する情報を当該ユーザ端末のディスプレイに表示させる。

上記課題を解決する通知システムは、ユーザが使用するユーザ端末と、当該ユーザ端末に接続された管理サーバとを含む通知システムであって、前記管理サーバが、第２ゲームを使用する他のユーザが使用する他ユーザ端末から、前記ユーザ端末を送信先とする前記第２ゲームにおける協力要請を取得し、前記協力要請を前記ユーザ端末に送信し、前記ユーザ端末が、第１ゲームを使用し、且つ前記第２ゲームを使用していない状態で、前記協力要請に関する情報を受信した場合に、前記第１ゲーム内で協力要請に関する情報を当該ユーザ端末のディスプレイに表示する。

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

第１の実施形態のシステム概略図。 第１の実施形態の処理手順の説明図であって、（ａ）はログイン管理処理、（ｂ）は通知転送処理の説明図。 第１の実施形態の画面例の説明図。 第２の実施形態の処理手順の説明図。 第３の実施形態の処理手順の説明図。 第４の実施形態の処理手順の説明図。

（第１の実施形態）
以下、通知方法の一実施形態を図１〜図３に従って説明する。本実施形態は、複数のアプリケーション（例えば、ゲーム）を利用するユーザに対して、各種通知を行なう場合を想定する。

図１に示すように、本実施形態では、インターネット等のネットワークを介して接続されたユーザ端末１０、管理サーバ２０、複数のゲームサーバ３０を用いる。
ユーザ端末１０は、ユーザ登録されたユーザのコンピュータ端末（スマートフォン等の情報処理端末）である。このユーザ端末１０は、ゲームサーバ３０から提供されるゲームに参加する場合に用いられる。また、ユーザ端末１０においてローカルカレンダを管理したり、各種ＳＮＳ（ソーシャルネットワークサービス）に参加したりする場合にも用いられる。

ゲームサーバ３０は、インターネットにおいて、各種ゲームを提供しているサーバコンピュータである。本実施形態では、ゲームサーバ３０は、ユーザ端末１０に対してゲームサービスを提供する。更に、ゲームサーバ３０は、例えば、対戦ゲーム等において、ゲームにおけるキャラクタの体力が回復した場合や、仲間と協力して敵と戦う場面において他のユーザに協力要請を行なう場合等に、管理サーバ２０に対して通知（体力情報や協力要請）を送信する。

管理サーバ２０は、ユーザ端末１０に対して、複数のアプリケーションを利用するユーザを管理するコンピュータシステムである。具体的には、管理サーバ２０は、ユーザを取りまとめ、各種ゲームサーバ３０から提供されるゲームサービスを管理する基盤システム（プラットフォーム）として機能する。この管理サーバ２０は、ＣＰＵ、ＲＡＭ及びＲＯＭ等からなる制御部２１、ユーザ情報記憶部２２、通知情報記憶部２３を備える。

この制御部２１は、管理プログラムを実行することにより、ユーザ管理部２１１、通知取得部２１２、ユーザ状況判定部２１３、通知転送部２１４として機能する。
ユーザ管理部２１１は、各種アプリケーションを利用するユーザを管理する処理を実行する。

通知取得部２１２は、ゲームサーバ３０から送信された各種通知を取得する処理を実行する。本実施形態では、例えば、ゲームサーバ３０が送信した体力情報や協力要請に関する通知を取得する。

ユーザ状況判定部２１３は、ユーザ端末１０における状態を判定する処理を実行する。ここでは、状態として、ユーザ端末１０がオンラインかどうかを判定する。
通知転送部２１４は、ユーザ端末１０に通知を送信する処理を実行する。この通知転送部２１４は、ユーザ端末１０の状況に応じて転送方法を決定する転送方法決定情報を保持している。

ユーザ情報記憶部２２には、ユーザを認証するための情報や、ユーザが利用しているゲームに関するユーザ管理情報が記録される。このユーザ管理情報は、プラットフォームに
おいてユーザ登録された場合に記録され、ユーザ端末１０の利用状況によりステータスが更新される。ユーザ管理情報には、ユーザＩＤ、ログインパスワード、利用ゲーム、ステータスに関するデータが記録される。

ユーザＩＤデータ領域は、各ユーザを特定するための識別子に関するデータが記録される。
ログインパスワードデータ領域には、このユーザが管理サーバ２０にログインする場合に、ユーザを認証するためのデータが記録される。

利用ゲームデータ領域には、このユーザが利用しているゲームを特定するための識別子（ゲームＩＤ）に関するデータが記録される。
ステータスデータ領域には、ユーザ端末１０の状態を特定するためのデータが記録される。このステータスにより、オンラインかどうかを判定することができる。

通知情報記憶部２３には、各ユーザに対する通知管理情報が記録される。この通知管理情報は、ゲームサーバ３０から通知を取得した場合に記録される。通知管理情報には、ユーザＩＤ、ゲームＩＤ、取得時刻、通知種別、通知内容に関するデータが記録される。

ユーザＩＤデータ領域には、各ユーザを特定するための識別子に関するデータが記録される。
ゲームＩＤデータ領域には、このユーザに対する通知に関わるゲームを特定するための識別子に関するデータが記録される。

取得時刻領域には、この通知を取得した年月日及び時刻に関するデータが記録される。
通知種別データ領域には、受信した通知の種類を特定するためのデータが記録される。本実施形態では、通知種別として、ゲーム内のキャラクタの体力ゲージや協力要請がある。

通知内容データ領域には、通知の内容に関するデータが記録される。例えば、体力ゲージにおいては、ユーザが用いるキャラクタ、体力ゲージ（パワー、フォース）の回復状況がある。また、協力要請においては、他のユーザから取得したメッセージがある。

次に、図２、図３を用いて、管理サーバ２０を用いて実行される通知管理方法の処理手順を説明する。ここでは、ログイン管理処理、通知転送処理の順番に説明する。
（ログイン管理処理）
まず、図２（ａ）を用いて、ログイン管理処理を説明する。

ここでは、まず、管理サーバ２０の制御部２１は、アクセス取得処理を実行する（ステップＳ１−１）。具体的には、ゲームを行なう場合、ユーザ端末１０を用いて、管理サーバ２０にアクセスする。この場合、管理サーバ２０の制御部２１のユーザ管理部２１１は、ユーザ端末１０のディスプレイにログイン画面を出力する。そして、ユーザは、このログイン画面において、ユーザＩＤ、ログインパスワードを入力する。そして、ユーザ管理部２１１は、ユーザ端末１０のログイン画面に入力されたユーザＩＤ、ログインパスワードを取得する。

次に、管理サーバ２０の制御部２１は、ユーザ認証処理を実行する（ステップＳ１−２）。具体的には、制御部２１のユーザ管理部２１１は、ユーザ端末１０から取得したユーザＩＤ、ログインパスワードが、ユーザ情報記憶部２２に登録されている場合には、ログイン認証を完了する。そして、ログイン認証の完了により、ログインユーザのユーザＩＤが特定される。この場合、ユーザ管理部２１１は、ユーザ情報記憶部２２のユーザ管理情
報に、ステータスとして、管理サーバ２０へのログインを記録する。

次に、管理サーバ２０の制御部２１は、アプリケーション選択処理を実行する（ステップＳ１−３）。具体的には、制御部２１のユーザ管理部２１１は、ユーザ端末１０のディスプレイに、ログインユーザが利用しているゲームを一覧表示させた選択画面を出力する。ここでは、アプリケーションＡのゲームを選択する場合を想定する。この場合、ユーザ管理部２１１は、ユーザ端末１０からアプリケーション選択情報を取得する。このアプリケーション選択情報には、ゲームＩＤに関するデータを含める。

次に、管理サーバ２０の制御部２１は、ゲームログイン通知処理を実行する（ステップＳ１−４）。具体的には、制御部２１のユーザ管理部２１１は、選択されたアプリケーションＡのゲームサーバ３０に対して、ログインを通知する。この場合、ユーザ管理部２１１は、ユーザ情報記憶部２２のユーザ管理情報に、ステータスとして、ログイン「ゲームＡ」を記録する。

（通知転送処理）
次に、図２（ｂ）を用いて、通知転送処理を説明する。
ここでは、まず、管理サーバ２０の制御部２１は、通知の受信処理を実行する（ステップＳ２−１）。具体的には、制御部２１の通知取得部２１２は、ゲームサーバ３０から、各ユーザ宛の通知を取得する。ここでは、ユーザがログインしていないアプリケーションのゲームサーバ３０から、通知を取得する。この場合、通知取得部２１２は、取得した通知の通知種別を特定する。そして、通知取得部２１２は、ユーザＩＤ、ゲームＩＤ、取得時刻、通知種別、通知内容を記録した通知管理情報を生成し、通知情報記憶部２３に登録する。

次に、管理サーバ２０の制御部２１は、状態検知処理を実行する（ステップＳ２−２）。具体的には、制御部２１のユーザ状況判定部２１３は、通知の宛先であるユーザＩＤが記録されたユーザ管理情報を、ユーザ情報記憶部２２から抽出する。そして、ユーザ状況判定部２１３は、ユーザ管理情報に記録されているステータスを特定する。

次に、管理サーバ２０の制御部２１は、オンラインかどうかについての判定処理を実行する（ステップＳ２−３）。具体的には、制御部２１のユーザ状況判定部２１３は、ユーザ管理情報のステータスとして、「ログイン」情報が記録されている場合には、オンラインと判定する。

「ログイン」情報が記録されておらず、オンラインでないと判定した場合（ステップＳ２−３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、通常表示処理を実行する（ステップＳ２−４）。具体的には、制御部２１の通知転送部２１４は、転送方法決定情報を用いて、オンラインでない場合に対応する通常方法（例えば、電子メール、プッシュ通知、ＳＮＳアプリケーションの個人用のボードへの掲載等）により、通知を転送する。このような通常方法による通知を確認する場合には、通知表示のための別のアプリケーションを起動させる必要がある。

一方、オンラインと判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ゲーム内表示処理を実行する（ステップＳ２−５）。具体的には、制御部２１の通知転送部２１４は、ユーザ管理情報におけるステータスに基づいて、ログインしているゲームを特定する。そして、通知転送部２１４は、ゲーム画面にオンライン通知を出力する。

この場合、図３に示すように、ユーザ端末１０のディスプレイには、ゲーム画面５００
が出力される。このゲーム画面５００には、新規通知リンク５０１が出力される。この新規通知リンク５０１には、新たな通知を受けたことを示すメッセージが含まれる。

新規通知リンク５０１が選択された場合、管理サーバ２０の制御部２１は、このログインユーザのユーザＩＤに関連付けられた通知管理情報を、通知情報記憶部２３において検索する。この場合、通知転送部２１４は、抽出した通知管理情報を、通知種別毎に、受信時刻が新しい順番に並べ替える。そして、通知転送部２１４は、通知情報記憶部２３から抽出した通知管理情報をユーザ端末１０のディスプレイに出力する。

この場合、図３に示すように、ユーザ端末１０のディスプレイには、詳細表示画面５１０が出力される。この詳細表示画面５１０には、他のアプリケーションＢ，Ｃ，Ｄの各ゲームサーバ３０から取得した通知の通知種別に対応して、「体力ゲージ」タブ、「協力要請」タブが含まれる。「体力ゲージ」タブが選択された場合、このユーザのキャラクタについて、各ゲームサーバ３０から取得した体力ゲージ画面５１１が表示される。また、「協力要請」タブが選択された場合には、ゲームサーバ３０から取得した他のユーザの協力要請画面５１２が表示される。

上記実施形態によれば、以下のような効果を得ることができる。
（１）上記実施形態では、ユーザ端末１０に対して、複数のアプリケーションを利用するユーザを管理するプラットフォームとして、管理サーバ２０を用いる。この管理サーバ２０は、制御部２１、ユーザ情報記憶部２２、通知情報記憶部２３を備える。これにより、プラットフォームにおける通知情報記憶部２３により、ユーザにおいて、複数のアプリケーションに係わる通知を統合して把握することができる。従って、アプリケーションプロバイダが異なる場合であっても、ユーザに対して通知を提供することができ、全体的なアプリケーション利用の活性化を促進することができる。

（２）上記実施形態では、管理サーバ２０の制御部２１は、ゲーム内表示処理を実行する（ステップＳ２−５）。ユーザ端末１０のディスプレイに出力される詳細表示画面５１０には、各ゲームサーバ３０から取得した体力ゲージ画面５１１が表示される。これにより、ゲーム内表示では、使用中のゲームアプリケーションで通知を行なうため、通知表示のための別アプリケーションの起動が不要である。通常方法では、使用中のアプリケーションに加えて、通知表示のための別のアプリケーションを起動させる必要があるが、ゲーム内表示においては、使用している画面内に表示されるため、ユーザへのリアルタイムの報知が成功する可能性が高い。そして、ゲームにおけるキャラクタの体力が回復している場合には、他のゲームも実施することができる。従って、他のゲームにおける状況をタイムリーに把握し、状況に応じた回遊性を向上させることができる。

（３）上記実施形態では、管理サーバ２０の制御部２１は、ゲーム内表示処理を実行する（ステップＳ２−５）。ユーザ端末１０のディスプレイに出力される詳細表示画面５１０には、各ゲームサーバ３０から取得した他のユーザの協力要請画面５１２が表示される。これにより、他のユーザからの協力要請をタイムリーに把握し、状況に応じて、他のゲームへの展開を図ることができる。従って、ゲーム間の回遊性を向上させることができる。

（４）上記実施形態では、オンラインでないと判定した場合（ステップＳ２−３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、通常表示処理を実行する（ステップＳ２−４）。この場合には、従来通りの通知を行なうことができる。

（第２の実施形態）
上記第１の実施形態においては、ユーザ端末１０の状況に応じて、通知の表示方法を変
更する。第２の実施形態においては、通知元との関連性に応じて、オンライン通知の要否を判断する。この場合、ユーザ情報記憶部２２に、ユーザ毎に、他のユーザやゲームとの関係を示すユーザ関連性情報を記録する。

このユーザ関連性情報においては、例えば、ユーザ間の相互の関連性を評価した評価値を記録する。ここでは、ＳＮＳの友達や、複数のアプリケーション（例えばゲーム）を共通して利用している仲間等のように、つき合いが多いユーザに対して高い評価値を設定する。

更に、このユーザ関連性情報には、ゲームの利用頻度を評価した評価値を記録しておく。ここでは、利用頻度が高いゲームに対して、高い評価値を設定する。
また、制御部２１の通知転送部２１４には、ユーザとの関連性を評価するための基準値に関するデータを保持させておく。そして、管理サーバ２０の制御部２１は、これらの評価値、基準値を用いて、通知転送処理を実行する。

（通知転送処理）
図４を用いて、この通知転送処理を説明する。
まず、管理サーバ２０の制御部２１は、ステップＳ２−１と同様に、通知の受信処理を実行する（ステップＳ３−１）。

この場合、管理サーバ２０の制御部２１は、ステップＳ２−２と同様に、状態検知処理を実行する（ステップＳ３−２）。
次に、管理サーバ２０の制御部２１は、ステップＳ２−３同様に、オンラインかどうかについての判定処理を実行する（ステップＳ３−３）。

オンラインでないと判定した場合（ステップＳ３−３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２−４と同様に、通常表示処理を実行する（ステップＳ３−４）。

一方、オンラインと判定した場合（ステップＳ３−３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ユーザとの関係の評価処理を実行する（ステップＳ３−５）。具体的には、制御部２１の通知転送部２１４は、ユーザ情報記憶部２２に記録されたユーザ関連性情報を用いて、新着通知の送信元（ゲームや他のユーザ等）の評価値を取得する。そして、通知転送部２１４は、ユーザ関連性情報から抽出した、ゲームや他のユーザ等の評価値を合計した総合評価値を算出する。

次に、管理サーバ２０の制御部２１は、関連性が高いかどうかについての判定処理を実行する（ステップＳ３−６）。具体的には、制御部２１の通知転送部２１４は、総合評価値が基準値より高いかどうかを判定する。

総合評価値が基準値以下であり、関連性が低いと判定した場合（ステップＳ３−６において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２−４と同様に、通常表示処理を実行する（ステップＳ３−４）。

一方、総合評価値が基準値より高く、関連性が高いと判定した場合（ステップＳ３−６において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２−５と同様に、ゲーム内表示処理を実行する（ステップＳ３−７）。

本実施形態によれば、以下のような効果を得ることができる。
（５）上記実施形態では、管理サーバ２０の制御部２１は、ユーザとの関係の評価処理
を実行する（ステップＳ３−５）。そして、関連性が低いと判定した場合（ステップＳ３−６において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、通常表示処理を実行する（ステップＳ３−４）。一方、関連性が高いと判定した場合（ステップＳ３−６において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ゲーム内表示処理を実行する（ステップＳ３−７）。これにより、ユーザとの関連性が高いゲームや他のユーザの状況を考慮して、タイムリーな通知を行なうことができる。

（第３の実施形態）
上記第１の実施形態においては、ユーザ端末１０の状況に応じて、通知の表示方法を変更する。第３の実施形態においては、ユーザ端末１０の状況と、通知の緊急性に応じて、オンライン通知の要否を判断する。この場合、通知転送部２１４は、通知の緊急性を評価するための緊急性評価情報や、ユーザ端末１０の状態を評価した状況評価情報を保持する。

この緊急性評価情報においては、例えば、通知に含まれるキーワードに基づいて緊急性を評価した通知評価値を記録する。ここでは、強い敵が登場しているバトルにおける協力要請など、送信元ユーザの協力要請が強いと予想される場合に、高い評価値を設定する。

また、状況評価情報には、ユーザ端末１０がログインしているアプリケーション（ゲーム）の進捗状況を評価した状況評価値を記録する。例えば、ゲームにおいて、バトル実行中のように、ログインユーザが、目を離せない状況の場合には、高い状況評価値を設定する。

そして、管理サーバ２０の制御部２１は、これらの評価値を用いて、通知転送処理を実行する。
（通知転送処理）
図５を用いて、この通知転送処理を説明する。

まず、管理サーバ２０の制御部２１は、ステップＳ２−１と同様に、通知の受信処理を実行する（ステップＳ４−１）。
この場合、管理サーバ２０の制御部２１は、ステップＳ２−２と同様に、状態検知処理を実行する（ステップＳ４−２）。

次に、管理サーバ２０の制御部２１は、ステップＳ２−３同様に、オンラインかどうかについての判定処理を実行する（ステップＳ４−３）。
オンラインでないと判定した場合（ステップＳ４−３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２−４と同様に、通常表示処理を実行する（ステップＳ４−４）。

一方、オンラインと判定した場合（ステップＳ４−３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、通知の緊急性の評価処理を実行する（ステップＳ４−５）。具体的には、制御部２１の通知転送部２１４は、保持している緊急性評価情報を用いて、通知に含まれるキーワードに基づいて、緊急性評価値を算出する。

次に、管理サーバ２０の制御部２１は、現在のゲーム状況の特定処理を実行する（ステップＳ４−６）。具体的には、制御部２１の通知転送部２１４は、ログインしているゲームサーバ３０から、ゲームの進捗状況（ステータス）を取得する。そして、通知転送部２１４は、保持している状況評価情報を用いて、アプリケーションの進捗状況に基づいて、状況評価値を算出する。

次に、管理サーバ２０の制御部２１は、通知の緊急性が高いかどうかについての判定処理を実行する（ステップＳ４−７）。具体的には、制御部２１の通知転送部２１４は、緊急性評価値と、状況評価値とを比較する。ここで、緊急性評価値が状況評価値よりも高い場合には、通知の緊急性が高いと判定する。

緊急性評価値が状況評価値以下であり、通知の緊急性が低いと判定した場合（ステップＳ４−７において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２−４と同様に、通常表示処理を実行する（ステップＳ４−４）。

一方、緊急性評価値が状況評価値よりも高く、通知の緊急性が高いと判定した場合（ステップＳ４−７において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２−５と同様に、ゲーム内表示処理を実行する（ステップＳ４−８）。

本実施形態によれば、以下のような効果を得ることができる。
（６）上記実施形態では、管理サーバ２０の制御部２１は、通知の緊急性の評価処理（ステップＳ４−５）、現在のゲーム状況の特定処理（ステップＳ４−６）を実行する。そして、管理サーバ２０の制御部２１は、通知の緊急性が高いかどうかについての判定処理を実行する（ステップＳ４−７）。ここで、通知の緊急性が低いと判定した場合（ステップＳ４−７において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、通常表示処理を実行する（ステップＳ４−４）。一方、通知の緊急性が高いと判定した場合（ステップＳ４−７において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ゲーム内表示処理を実行する（ステップＳ４−８）。これにより、ログインユーザにおける状況を考慮して、的確かつタイムリーな通知を行なうことができる。

（第４の実施形態）
上記第１の実施形態においては、ユーザ端末１０の状況に応じて、通知の表示方法を変更する。第４の実施形態においては、通知に対する対応履歴に応じて、オンライン通知の要否を判断する。この場合、通知情報記憶部２３には、各通知管理情報に関連付けて、通知を受けたときのユーザ端末１０の状況、通知に対する対応実績についての対応履歴情報を記録する。本実施形態では、対応実績として、新規通知リンクの選択による詳細情報の閲覧の有無を記録する。

また、制御部２１の通知転送部２１４には、通知に対する対応実績を評価するための基準値に関するデータを保持させておく。そして、管理サーバ２０の制御部２１は、この対応履歴情報を用いて、通知転送処理を実行する。

（通知転送処理）
図６を用いて、この通知転送処理を説明する。
まず、管理サーバ２０の制御部２１は、ステップＳ２−１と同様に、通知の受信処理を実行する（ステップＳ５−１）。

この場合、管理サーバ２０の制御部２１は、ステップＳ２−２と同様に、状態検知処理を実行する（ステップＳ５−２）。
次に、管理サーバ２０の制御部２１は、ステップＳ２−３同様に、オンラインかどうかについての判定処理を実行する（ステップＳ５−３）。

オンラインでないと判定した場合（ステップＳ５−３において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２−４と同様に、通常表示処理を実行する（ステップＳ５−４）。

一方、オンラインと判定した場合（ステップＳ５−３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、現在のゲーム状況の特定処理を実行する（ステップＳ５−５）。具体的には、制御部２１の通知転送部２１４は、ユーザがログインしているアプリケーションのゲームサーバ３０から、ゲームの進捗状況（ステータス）を取得する。

次に、管理サーバ２０の制御部２１は、通知履歴の検索処理を実行する（ステップＳ５−６）。具体的には、制御部２１の通知転送部２１４は、通知情報記憶部２３において、ゲームＩＤ、通知種別、ユーザ端末１０の状況に関連付けられた対応履歴情報を検索する。

次に、管理サーバ２０の制御部２１は、対応実績があるかどうかについての判定処理を実行する（ステップＳ５−７）。具体的には、制御部２１の通知転送部２１４は、対応履歴情報を用いて、閲覧した場合の割合（閲覧頻度）を算出する。そして、閲覧頻度が基準値より高い場合には、対応実績があると判定する。

閲覧頻度が基準値以下で、対応実績がないと判定した場合（ステップＳ５−７において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２−４と同様に、通常表示処理を実行する（ステップＳ５−４）。

一方、閲覧頻度が基準値よりも高く、対応実績があると判定した場合（ステップＳ５−７において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ステップＳ２−５と同様に、ゲーム内表示処理を実行する（ステップＳ５−８）。

そして、管理サーバ２０の制御部２１は、対応履歴の記録処理を実行する（ステップＳ５−９）。具体的には、制御部２１の通知転送部２１４は、通知情報記憶部２３には、この通知管理情報に関連付けて、通知を受けたときのユーザ端末１０の状況、詳細情報の閲覧「あり」を記録する。

本実施形態によれば、以下のような効果を得ることができる。
（７）上記実施形態では、管理サーバ２０の制御部２１は、通知履歴の検索処理を実行する（ステップＳ５−６）。対応実績がないと判定した場合（ステップＳ５−７において「ＮＯ」の場合）、管理サーバ２０の制御部２１は、通常表示処理を実行する（ステップＳ５−４）。一方、対応実績があると判定した場合（ステップＳ５−７において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ゲーム内表示処理を実行する（ステップＳ５−８）。これにより、対応履歴に応じて、的確かつタイムリーな通知を行なうことができる。従って、不必要な通知を抑制し、ユーザの趣向に応じた通知を行なうことができる。

なお、上記実施形態は以下のように変更してもよい。
・上記各実施形態では、管理サーバ２０の制御部２１は、通知の受信処理を実行する（ステップＳ２−１）。これに代えて、通知転送部２１４が、各ゲームサーバ３０から、使用中ではない他の利用ゲームの体力情報を取得するようにしてもよい。そして、体力ゲージ値が最大値になった場合には、ゲーム内表示処理を実行する。

・上記第３の実施形態では、管理サーバ２０の制御部２１は、現在のゲーム状況の特定処理（ステップＳ４−６）、通知の緊急性が高いかどうかについての判定処理（ステップＳ４−７）を実行する。ここでは、ゲームの進捗状況に応じて高い状況評価値を付与する。状況評価値の付与方法は、これに限定されるものではない。例えば、使用中のゲームにおけるキャラクタの体力ゲージ値に応じて状況評価値を設定するようにしてもよい。ここでは、体力ゲージ値が低い場合には、状況評価値を低く設定する。これにより、使用中の
ゲームにおけるキャラクタの体力が少ない場合には、ゲーム内表示処理（ステップＳ４−７）が実行し、回遊性を向上させることができる。

また、状況評価情報において、ユーザの利用ゲームの体力情報を含めて保持するようにしてもよい。ここでは、管理サーバ２０の制御部２１の通知転送部２１４は、各ゲームサーバ３０から、各ゲームにおけるログインユーザのキャラクタの体力ゲージ値を取得して保持する。そして、通知転送部２１４は、使用中のゲームにおける体力ゲージ値と、他の利用ゲームの体力ゲージ値との比較に基づいて、状況評価値を設定するようにしてもよい。ここでは、使用中のゲームにおける体力ゲージ値が、他の利用ゲームの体力ゲージ値よりも相対的に低くなった場合、状況評価値を低くする。これにより、使用中のゲームにおける状況と、他のゲームにおける状況との比較に応じて、ゲーム内表示の要否を判定することができる。

更に、制御部２１は、他の利用ゲームにおけるキャラクタの体力に基づいて、ゲーム内表示の表示順番の並び替えを行なうようにしてもよい。この場合には、通知転送部２１４は、各ゲームサーバ３０から取得したキャラクタの体力ゲージ値が高いものから順番に並び替えて表示する。

・上記第３の実施形態では、管理サーバ２０の制御部２１は、通知の緊急性の評価処理（ステップＳ４−５）、現在のゲーム状況の特定処理（ステップＳ４−６）を実行する。そして、管理サーバ２０の制御部２１は、通知の緊急性が高いかどうかについての判定処理（ステップＳ４−７）において、緊急性評価値と状況評価値とを比較する。ここで、緊急性評価値を参照せずに、ゲームの状況評価情報のみに基づいて、ゲーム内表示を実行するか否かを判定するようにしてもよい。例えば、通知転送部２１４は、使用中のゲームの体力ゲージ値が基準値（例えば体力がゼロ）になった場合に、ゲーム内表示処理（ステップＳ４−８）を実行し、体力が残っている場合には通常表示（ステップＳ４−４）を実行する。

・上記各実施形態では、オンラインと判定した場合（ステップＳ２−３において「ＹＥＳ」の場合）、管理サーバ２０の制御部２１は、ゲーム内表示処理を実行する（ステップＳ２−５）。具体的には、制御部２１の通知転送部２１４は、ユーザ管理情報におけるステータスに基づいて、ログインしているゲームを特定する。そして、通知転送部２１４は、ゲーム画面にオンライン通知を出力する。ここで、ログイン先のゲーム種類に応じて、通知方法を変更してもよい。この場合には、ユーザ情報記憶部に、ユーザ毎に、ゲーム内表示が可能なゲームＩＤを記録しておく。管理サーバ２０の制御部２１は、ユーザ端末１０のログイン先のアプリケーションのゲームＩＤを特定する。そして、制御部２１は、ログインしているゲームに応じて、ゲーム内表示の可否を判定する。これにより、使用中にアプリケーションに応じて、ゲーム内通知の要否を判定することができる。

・上記各実施形態では、アプリケーションとしてゲームにおいて、通知を行なう場合を説明したが、通知の対象アプリケーションは、ゲームに限定されるものではない。プラットフォームにおいて提供されている複数のアプリケーションにおいて、通知を行なうことができる。

・上記各実施形態では、各ゲームサーバ３０から通知を取得するが、通知の送信者はゲームサーバ３０に限定されるものではない。電子メール等のように、各ユーザ端末１０から、直接、通知を取得するようにしてもよい。

・上記各実施形態では、通知種別として、ゲーム内のキャラクタの体力ゲージ値や協力要請を用いる。通知の種別は、これらに限定されるものではなく、他のゲームのイベント
やゲーム状況に関する通知を提供するようにしてもよい。

次に、上記実施形態及び別例から把握できる技術的思想について以下に追記する。
［ａ］タイムライン領域に表示する情報を配信するサーバに接続される情報処理装置に、
前記タイムライン領域に所定のオブジェクトを表示するステップと、
前記タイムライン領域において所定のイベントが発生した場合に、前記所定のオブジェクトを非表示にするステップとを実行させる、オブジェクト表示プログラム。
［ｂ］前記情報処理装置に、
前記サーバに対して、前記タイムライン領域において所定のイベントが発生したか否か問い合わせるステップをさらに実行させる、［ａ］に記載のオブジェクト表示プログラム。
［ｃ］前記所定のオブジェクトを表示するステップにおいて、
前記所定のオブジェクトを、前記所定のオブジェクトに係る日時情報に基づく順序で表示する、［ａ］又は［ｂ］に記載のオブジェクト表示プログラム。
［ｄ］タイムライン領域に表示する情報を配信するサーバに接続され、
前記タイムライン領域に所定のオブジェクトを表示し、
前記タイムライン領域において所定のイベントが発生した場合に、前記所定のオブジェクトを非表示にする情報処理装置。
［ｅ］タイムライン領域に表示する情報を配信するサーバに接続される情報処理装置が、前記タイムライン領域に所定のオブジェクトを表示するステップと、
前記情報処理装置が、タイムライン領域において所定のイベントが発生した場合に、前記所定のオブジェクトを非表示にするステップとを含む、オブジェクト表示方法。

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

Claims (13)

1. ゲームに関する通知を行うための通知プログラムであって、
   ユーザが使用するユーザ端末の制御部に、
   前記ユーザ端末で第１ゲームを使用している状態で、使用中ではない第２ゲームであって当該第２ゲームを使用し前記ユーザとの関連性が高い他のユーザからの協力要請をサーバから受信した場合に、前記第１ゲーム内で協力要請に関する情報を当該ユーザ端末のディスプレイに表示させ、前記ユーザとの関連性が低い他のユーザからの協力要請を前記サーバから受信した場合に前記第１ゲーム以外で協力要請に関する通知を実行させる
   プログラム。
2. 前記制御部に、
   使用中の前記第１ゲームの状態に関わらず、前記第１ゲームのゲーム画面内に、前記第２ゲームへのリンクを含む表示を出力させる
   請求項１に記載のプログラム。
3. 前記ユーザと前記他のユーザがソーシャルネットワークサービス上で友達関係にある場合に、前記第１ゲーム内で協力要請に関する情報を表示させる
   請求項１又は２に記載のプログラム。
4. 前記制御部に、
   前記協力要請を受信したときに前記第１ゲームを使用していない場合には、当該協力要請に関する情報をプッシュ通知として前記ディスプレイに表示させる
   請求項１〜３のいずれか１項に記載のプログラム。
5. 前記制御部に、
   前記ユーザによる前記第２ゲームへのリンクの選択操作を受け付け、
   前記第１ゲームの画面とは異なる画面で、前記他のユーザからの協力要請のメッセージを表示させる
   請求項１〜４のいずれか１項に記載のプログラム。
6. ゲームに関する通知を行うユーザ端末であって、
   前記ユーザ端末で第１ゲームを使用している状態で、使用中ではない第２ゲームであって当該第２ゲームを使用し前記ユーザ端末を用いるユーザとの関連性が高い他のユーザからの協力要請をサーバから受信した場合に、前記第１ゲーム内で協力要請に関する情報を当該ユーザ端末のディスプレイに表示し、前記ユーザとの関連性が低い他のユーザからの協力要請を前記サーバから受信した場合に前記第１ゲーム以外で協力要請に関する通知を実行する
   ユーザ端末。
7. ゲームに関する通知を行う通知方法であって、
   ユーザが使用するユーザ端末が、
   前記ユーザ端末で第１ゲームを使用している状態で、使用中ではない第２ゲームであって当該第２ゲームを使用し前記ユーザとの関連性が高い他のユーザからの協力要請をサーバから受信した場合に、前記第１ゲーム内で協力要請に関する情報を当該ユーザ端末のディスプレイに表示し、前記ユーザとの関連性が低い他のユーザからの協力要請を前記サーバから受信した場合に前記第１ゲーム以外で協力要請に関する通知を実行する
   通知方法。
8. ユーザが使用するユーザ端末と、当該ユーザ端末に接続されたサーバとを含む通知システムであって、
   前記サーバが、
   第２ゲームを使用する他のユーザが使用する他ユーザ端末から、前記ユーザ端末を送信先とする前記第２ゲームにおける協力要請を受信し、
   前記ユーザ端末を用いるユーザが第１ゲームを利用しているか否かを判定し、
   前記ユーザと前記他のユーザとの関連性を判定し、
   前記ユーザが前記第１ゲームを利用し且つ前記ユーザとの関連性が高い他のユーザからの協力要請を取得した場合には前記第１ゲーム内で協力要請に関する情報を当該ユーザ端末のディスプレイに表示させるための協力要請に関する情報を前記ユーザ端末に送信し、前記ユーザとの関連性が低い他のユーザからの協力要請を受信した場合には前記第１ゲーム以外で協力要請に関する通知を実行するための情報を前記ユーザ端末に送信し、
   前記ユーザ端末が、
   前記第１ゲームを使用し、且つ前記第２ゲームを使用していない状態で、当該第２ゲームを使用し前記ユーザとの関連性が高い他のユーザからの協力要請を前記サーバから受信した場合に、前記第１ゲーム内で協力要請に関する情報を当該ユーザ端末のディスプレイに表示し、前記ユーザとの関連性が低い他のユーザからの協力要請を前記サーバから受信した場合に前記第１ゲーム以外で協力要請に関する通知を実行する
   通知システム。
9. 前記サーバが、
   前記他ユーザ端末から前記協力要請を受信した場合に、前記協力要請が行われた前記第２ゲームの状況に応じて、通知方法を選択し、
   前記選択した通知方法を指定して、前記協力要請に関する情報を前記ユーザ端末に送信する、
   請求項８に記載の通知システム。
10. 前記サーバは、
    前記協力要請に含まれるキーワードに基づいて緊急性を判定し、前記緊急性が所定値よりも高い場合には前記第１ゲーム内で通知を行い、前記緊急性が前記所定値以下である場合には前記第１ゲーム内での通知以外の方法で通知を行う
    請求項９に記載の通知システム。
11. 前記サーバが、
    前記他ユーザ端末から前記協力要請を受信した場合に、前記ユーザ端末で使用されている前記第１ゲームに応じて、通知方法を選択し、
    前記選択した通知方法を指定して、前記協力要請に関する情報を前記ユーザ端末に送信する、
    請求項９又は１０に記載の通知システム。
12. 前記サーバが、
    前記他ユーザ端末から前記協力要請を受信した場合に、記憶部に記録され且つゲーム内表示が可能か否かを示すゲーム識別情報に基づき、前記ユーザ端末で使用されている前記第１ゲームがゲーム内通知が可能か否かに応じて、通知方法を選択し、
    前記選択した通知方法を指定して、前記協力要請を前記ユーザ端末に送信する、
    請求項１１に記載の通知システム。
13. 前記サーバが、
    前記他ユーザ端末から前記協力要請を受信した場合に、記憶部に記録された通知に対する前記ユーザの対応実績に基づき、通知方法を選択し、
    前記選択した通知方法を指定して、前記協力要請を前記ユーザ端末に送信する、
    請求項１１又は１２に記載の通知システム。

Images