JP6943766B2

JP6943766B2 - 情報処理システム、サーバ、情報処理装置、情報処理プログラム、および、情報処理方法

Info

Publication number: JP6943766B2
Application number: JP2017547230A
Authority: JP
Inventors: 裕介別府; 豊武久; 忍福本; 潔水木
Original assignee: Nintendo Co Ltd
Current assignee: Nintendo Co Ltd
Priority date: 2015-10-27
Filing date: 2015-10-27
Publication date: 2021-10-06
Anticipated expiration: 2035-10-27
Also published as: EP3312793A1; EP3312793A4; US20180147486A1; JPWO2017072855A1; WO2017072855A1

Description

本発明は、アプリケーションを提供するサーバと、提供されたアプリケーションを実行する端末側の情報処理装置とを含む情報処理システムに関する。

従来、サーバから端末側の情報処理装置へアプリケーションを提供し、提供されたアプリケーションを端末側の情報処理装置によって利用する情報処理システムがある（例えば、特許文献１参照）。

特開２０１２−０１８６５７号公報

ユーザによるアプリケーションの取得の機会を拡大することが望まれる。

それ故、本発明の目的は、ユーザによるアプリケーションの取得の機会を拡大することができる情報処理システム等を提供することである。

上記の課題を解決すべく、本発明は、以下の（１）〜（２１）の構成を採用した。

（１）
本発明の一例は、第１の種類のプラットホームを有する第１の情報処理装置と互換性を有し、かつ、第１の種類とは異なる第２の種類のプラットホームを有する第２の情報処理装置と互換性を有しない第１のアプリケーションを記憶するサーバである。
サーバは、提示情報送信手段と、受信手段と、特定手段と、アプリ送信手段とを備える。提示情報送信手段は、第１のアプリケーションに関する提示情報を第２の情報処理装置へ送信する。受信手段は、第２の情報処理装置において提示された提示情報に対応する第１のアプリケーションの取得に関する指示を示す指示情報を、当該第２の情報処理装置から受信する。特定手段は、受信された指示情報に関する第１のアプリケーションを受信すべき第１の情報処理装置を特定する。アプリ送信手段は、第２の情報処理装置から受信される指示情報に応じて、提示情報が示す第１のアプリケーションを、特定された第１の情報処理装置へ送信する。

（２）
提示情報送信手段は、第２の情報処理装置と互換性を有し、第１の情報処理装置と互換性を有しない第２のアプリケーションを実行中である第２の情報処理装置へ提示情報を送信してもよい。

（３）
提示情報送信手段は、第２のアプリケーションに関連する第１のアプリケーションに関する提示情報を第２の情報処理装置へ送信してもよい。

（４）
第１のアプリケーションは、第２のアプリケーションによって生成されるセーブデータの少なくとも一部のデータを利用することが可能なアプリケーションであってもよい。

（５）
サーバは、第２の情報処理装置に関する識別情報と、第１の情報処理装置に関する識別情報との関連付けを示す関連付け情報を記憶してもよい。特定手段は、関連付け情報に基づいて第１の情報処理装置を特定してもよい。

（６）
サーバは、第２の情報処理装置における第２のアプリケーションの実行開始時および／または実行中において、当該第２の情報処理装置のユーザに関するユーザ識別情報を当該第２の情報処理装置から受信してもよい。このとき、サーバは、第２の情報処理装置に関する識別情報であるユーザ識別情報と、第１の情報処理装置に関する識別情報との関連付けを示す関連付け情報を記憶してもよい。特定手段は、第２の情報処理装置における第２のアプリケーションの実行開始時および／または実行中においてサーバへ送信されたユーザ識別情報と、関連付け情報とに基づいて第１の情報処理装置を特定してもよい。

（７）
サーバは、第１の情報処理装置に関する識別情報として、第１の情報処理装置に固有の識別情報を記憶してもよい。

（８）
サーバは、ユーザ識別情報に関連付けて、当該ユーザ識別情報が示すユーザに関するユーザ情報を記憶してもよい。提示情報送信手段は、第２の情報処理装置へ送信すべき提示情報の内容を、当該第２の情報処理装置から受信したユーザ識別情報に関連付けられるユーザ情報に基づいて決定してもよい。

（９）
アプリ送信手段は、第１のアプリケーションをサーバから第１の情報処理装置へ送信する旨のユーザ指示の有無にかかわらず自動的に、当該第１のアプリケーションを第１の情報処理装置へ送信してもよいし、当該第１のアプリケーションを送信可能である旨の通知を第１の情報処理装置へ送信してもよい。

（１０）
アプリ送信手段は、第２の情報処理装置から指示情報を受信した後において、第１のアプリケーションの取得に関する所定の条件が満たされたことに応じて、第１の情報処理装置への第１のアプリケーションの送信、および／または、第１の情報処理装置への第１のアプリケーションに関する通知の送信を試みてもよい。

（１１）
提示情報送信手段は、提示情報をサーバから第２の情報処理装置へ送信する旨のユーザ指示の有無にかかわらず自動的に、当該提示情報を第２の情報処理装置へ送信してもよい。

（１２）
第１のアプリケーションおよび第２のアプリケーションは、ゲームアプリケーションであってもよい。

（１３）
第１の情報処理装置は、ゲーム装置であってもよい。第２の情報処理装置は、スマートデバイスであってもよい。

（１４）
本発明の他の一例は、サーバと、第１の種類のプラットホームを有する第１の情報処理装置と、第１の種類とは異なる第２の種類のプラットホームを有する第２の情報処理装置とを含む情報処理システムである。
サーバは、記憶手段と、提示情報送信手段と、受信手段とを備える。記憶手段は、第１の情報処理装置と互換性を有し、かつ、第２の情報処理装置と互換性を有しない第１のアプリケーションを記憶する。提示情報送信手段は、第１のアプリケーションに関する提示情報を第２の情報処理装置へ送信する。受信手段は、第２の情報処理装置において提示された提示情報に対応する第１のアプリケーションの取得に関する指示を示す指示情報を、当該第２の情報処理装置から受信する。
情報処理システムは、指示情報に関する第１のアプリケーションを受信すべき第１の情報処理装置を特定する特定手段を備える。
サーバは、第２の情報処理装置から受信される指示情報に応じて、提示情報が示す第１のアプリケーションを、特定された第１の情報処理装置へ送信するアプリ送信手段をさらに備える。

（１５）
第２の情報処理装置は、第２の情報処理装置と互換性を有し、第１の情報処理装置と互換性を有しない第２のアプリケーションの実行中において、提示情報をサーバから受信し、受信した提示情報に基づく画像を表示部に表示してもよい。

（１６）
第２の情報処理装置は、第２のアプリケーションに関連する第１のアプリケーションに関する提示情報に基づく画像を表示部に表示してもよい。

（１７）
サーバは、第２の情報処理装置に関する識別情報と、第１の情報処理装置に関する識別情報との関連付けを示す関連付け情報を記憶してもよい。特定手段は、関連付け情報に基づいて第１の情報処理装置を特定してもよい。

（１８）
第２の情報処理装置は、サーバから受信した提示情報に基づく画像を表示し、当該画像が表示された後で入力可能となる所定の入力指示が行われたことに応じて指示情報をサーバへ送信してもよい。

（１９）
第２の情報処理装置は、サーバから受信した提示情報に基づく画像を表示部に表示した後、所定の入力指示を行うための受付画像を表示部に表示してもよい。このとき、第２の情報処理装置は、所定の入力指示が行われた後で、表示部における受付画像の表示を終了し、第２のアプリケーションによって生成される画像を表示してもよい。

（２０）
本発明の他の一例は、第１の種類のプラットホームによって利用され、かつ、第１の種類とは異なる第２の種類のプラットホームによって利用できないアプリケーションを記憶するサーバである。
サーバは、提示情報送信手段と、特定手段と、アプリ送信手段とを備える。提示情報送信手段は、アプリケーションに関する提示情報を第２の種類のプラットホームを有する第２の情報処理装置へ送信する。特定手段は、提示情報が示すアプリケーションを受信先となる、第１の種類のプラットホームを有する第１の情報処理装置を特定する。アプリ送信手段は、第２の情報処理装置から受信される指示情報に応じて、提示情報が示すアプリケーションを、特定された第１の情報処理装置へ送信する。

（２１）
本発明の他の一例は、第１の種類の情報処理装置において実行可能であり、かつ、第１の種類とは異なる第２の種類の情報処理装置において実行不可能なアプリケーションを記憶するサーバである。
サーバは、提示情報送信手段と、受信手段と特定手段と、アプリ送信手段とを備える。提示情報送信手段は、アプリケーションに関する提示情報を第２の種類の情報処理装置へ送信する。受信手段は、第２の情報処理装置において提示された提示情報に対応する第１のアプリケーションの取得に関する指示を示す指示情報を、当該第２の情報処理装置から受信する。特定手段は、受信された指示情報に関する第１のアプリケーションを受信すべき第１の種類の情報処理装置を特定する。アプリ送信手段は、第２の種類の情報処理装置から受信される指示情報に応じて、提示情報が示すアプリケーションを、特定された第１の種類の情報処理装置へ送信する。

なお、本発明の別の一例は、上記（１）〜（１３），（２０），（２１）におけるサーバと同様の機能を有する情報処理システムであってもよいし、当該サーバの各手段として情報処理装置のコンピュータを機能させる情報処理プログラムであってもよい。また、本発明の別の一例は、上記（１４）〜（１９）における情報処理システムに含まれる情報処理装置（サーバ側の情報処理装置または端末側の情報処理装置）であってもよいし、当該情報処理装置の各手段として情報処理装置のコンピュータを機能させる情報処理プログラムであってもよい。本発明の別の一例は、上記の情報処理システムにおいて実行される情報処理方法であってもよい。

本発明によれば、ユーザによるアプリケーションの取得の機会を拡大することができる。

本実施形態における情報処理システムの構成の一例を示すブロック図スマートフォンの構成の一例を示すブロック図ゲーム機の構成の一例を示すブロック図自社サービスサーバの構成の一例を示す図自社アカウントが設定される場合における処理の流れの一例を示す図管理サーバに記憶されるユーザ管理情報の一例を示す図スマートフォンにおいて実行される基本的な処理の流れの一例を示す図管理サーバに記憶されるユーザ管理情報の一例を示す図ゲーム機において実行される基本的な処理の流れの一例を示す図スマートフォンを用いてゲーム機アプリを購入する処理の概要の一例を示す図スマートフォンを用いてゲーム機アプリを購入する処理の流れの一例を示す図スマートフォンに表示される、広告画像を含むゲーム画像の一例を示す図スマートフォンに表示される、購入ページの画像の一例を示す図ゲーム機に表示される画像の一例を示す図セーブデータを共有する処理の概要の一例を示す図セーブデータサーバが記憶するデータの一例を示す図スマートフォンアプリとゲーム機アプリとでセーブデータを共有する処理の流れの一例を示す図スマートフォンアプリ提供サービスの利用に応じてポイントを管理する処理の概要の一例を示す図スマートフォンアプリ提供サーバからスマートフォンがデータを取得する場合における、ポイントを管理する処理の流れの一例を示す図ゲームサーバからスマートフォンがデータを取得する場合における、ポイントを管理する処理の流れの一例を示す図スマートフォンに表示される購入画像の一例を示す図スマートフォンとゲーム機とでフレンドリストを共有する処理の概要の一例を示す図管理サーバに記憶されるユーザ管理情報の一例を示す図フレンドリストを変更する処理の流れの一例を示す図基本リスト追加処理の流れの一例を示すフローチャートスマートフォンアプリを実行する場合のスマートフォンにおける処理の流れの一例を示すフローチャートゲーム機における処理の流れの一例を示すフローチャート管理サーバにおける処理の流れの一例を示すフローチャート

［１．システムの全体構成］
以下、図面を参照して、本実施形態に係る情報処理システム、サーバ、情報処理装置、情報処理プログラム、および、情報処理方法について説明する。まず、本実施形態に係る情報処理システムの全体構成と、情報処理システムに含まれる各端末および各サーバの概要とについて説明する。図１は、本実施形態における情報処理システムの構成の一例を示すブロック図である。図１に示すように、情報処理システムは、自社サービスサーバ１と、スマートフォンアプリ提供サーバ２と、スマートフォン３と、ゲーム機４とを含む。これらの端末またはサーバ１〜４は、インターネットおよび／またはモバイル通信網等のネットワーク５に接続可能である。

以下においては、図１に示す情報処理システムにおいて、本実施形態を実施する事業者が、自社サービスサーバ１を用いてスマートフォン３およびゲーム機４に対してサービスを提供する場合を例として説明する。なお、本実施形態において、情報処理システムは、自社サービスサーバ１とは別に、スマートフォン３に対してアプリケーションを提供するサービスを行うためのアプリ提供サーバ２を含む。本実施形態においては、アプリ提供サーバ２によるサービス提供は、自社サービスサーバ１を用いる事業者とは異なる事業者によって行われるものとする。つまり、スマートフォンアプリ提供サーバ２の運営者（換言すれば、スマートフォンアプリ提供サーバ２によるサービスの運営者）は、自社サービスサーバ１の運営者（換言すれば、自社サービスサーバ１によるサービスの運営者）とは異なっている。

なお、本明細書において、自社サービスサーバ１を用いて本実施形態を実施する事業者を「実施事業者」（あるいは「自社」）と呼ぶ。また、アプリ提供サーバ２を用いる事業者を「他の事業者」（あるいは「他社」）と呼ぶ。なお、実施事業者とは、自社サービスサーバ１を用いたサービス（「自社サービス」と呼ぶ。）を実質的に運営する者を指す。実施事業者は、自社サービスサーバ１の所有者である必要はなく、また、自社サービスサーバ１を管理したりメンテナンスしたりする者である必要はない。

本実施形態において、実施事業者は、スマートフォン３用のアプリケーション（以下、「スマートフォンアプリ」と呼ぶ。）、および、ゲーム機４用のアプリケーション（以下、「ゲーム機アプリ」と呼ぶ。）をユーザに提供するサービスを行う。また、実施事業者は、上記サービスに付随する各種のサービス（例えば、後述するような、オンラインゲームのゲームサーバやセーブデータサーバの提供、広告等の情報の提供、ポイントに応じた特典の付与等）を行う。なお、本実施形態においては、実施事業者はスマートフォンアプリおよびゲーム機アプリとして、ゲームアプリケーションを提供する場合を例として説明する。ただし、スマートフォンアプリおよびゲーム機アプリは、ゲームアプリケーションに限らず、任意のアプリケーションであってもよい。

図１に示すように、自社サービスサーバ１は、スマートフォン３およびゲーム機４（換言すれば、スマートフォン３およびゲーム機４を所有するユーザ）に対してネットワークサービスを提供する。詳細は後述するが、本実施形態においては、自社サービスサーバ１は、次のサービスを行う。
・ゲーム機アプリの提供
自社サービスサーバ１は、電子商取引によってゲーム機アプリをゲーム機４に提供するサービスを行う。すなわち、自社サービスサーバ１は、ゲーム機４からのアプリ取得要求（例えば、アプリケーションを購入する要求）に応じて、当該ゲーム機４にアプリケーションを提供する。なお、詳細は後述するが、本実施形態においては、ユーザは、ゲーム機４から自社サービスサーバ１への要求だけでなく、スマートフォン３から自社サービスサーバ１への要求によって、自社サービスサーバ１からゲーム機４へゲーム機アプリをダウンロードすることも可能である。
・スマートフォンアプリおよびゲーム機アプリを実行するための環境の提供
自社サービスサーバ１は、例えば、ゲームアプリケーション（例えば、オンラインゲーム等）のためのゲームサーバやセーブデータサーバを含み、ゲームアプリケーションに用いるデータ（すなわち、ゲームデータ）をスマートフォン３またはゲーム機４とやり取りする。また、自社サービスサーバ１は、スマートフォンアプリおよびゲーム機アプリで利用可能なフレンドリストの管理を行う。

スマートフォンアプリ提供サーバ２は、アプリケーションを提供するサービス（「アプリ提供サービス」と呼ぶ。）を行うためのサーバであり、具体的には、スマートフォンアプリをスマートフォン３に提供するサービスを行う（図１参照）。すなわち、本実施形態においては、スマートフォンアプリ提供サーバ２は、スマートフォン３からのアプリ取得要求（例えば、アプリケーションを購入する要求）に応じて、当該スマートフォン３にアプリケーションを提供する。スマートフォンアプリ提供サーバ２およびこれによって提供されるサービスは、既存のものであってもよい。例えば、スマートフォンアプリ提供サーバ２は、「Ｇｏｏｇｌｅｐｌａｙ（登録商標）」や「ＡＰＰＳＴＯＲＥ（登録商標）」といった既存のアプリ提供サービスを行うためのサーバであってもよい。

本実施形態においては、実施事業者は、自身で開発したスマートフォンアプリのユーザへの提供を、スマートフォンアプリ提供サーバ２を運営する他の事業者に依頼する（図１に示す一点鎖線の矢印を参照）。すなわち、本実施形態においては、実施事業者が開発したスマートフォンアプリは、スマートフォンアプリ提供サーバ２におけるアプリ提供サービスによってユーザに提供される。つまり、アプリケーションを実行するための環境が自社サービスサーバ１によって提供されるスマートフォンアプリは、スマートフォンアプリ提供サーバ２におけるアプリ提供サービスによってスマートフォン３において取得（具体的には、インストール）される。なお、自社サービスに対応するスマートフォンアプリ（換言すれば、自社サービスにおけるサービス提供を受けることができるスマートフォンアプリ）は、実施事業者によって開発されたものに限らず、他の開発者（例えば、実施事業者の許諾を受けた他の者）によって開発されたものであってもよい。

自社サービスサーバ１におけるサービス、および、スマートフォンアプリ提供サーバ２におけるサービスにおいては、ユーザはそれぞれ異なるアカウントによって管理される。本実施形態においては、自社サービスサーバ１におけるサービスにおいて用いられるアカウントを「自社アカウント」と呼び、スマートフォンアプリ提供サーバ２におけるサービスにおいて用いられるアカウントを「他社アカウント」と呼ぶ（図１参照）。

スマートフォン３は、ユーザが有する情報処理装置の一例であり、スマートデバイスの一例と言うこともできる。すなわち、「スマートデバイス」の用語の意味には、スマートフォンが含まれる。スマートフォン３は、既製のものであってよく、例えば、アンドロイド（登録商標）やｉＯＳといった、既存のＯＳ（オペレーティングシステム）が組み込まれた（換言すれば、既製のプラットホームを有する）ものであってもよい。つまり、スマートフォン３は、本実施形態における処理を実行するための機能を既製のスマートフォンにインストールすることで実現されてもよい。

なお、スマートフォン３は、多機能情報端末の一例と言うこともできる。ここで、多機能情報端末とは、例えば次の機能を有する情報処理装置を指す。
・アプリケーション（例えば、ブラウザ、メーラー、あるいは、ゲームアプリケーション等）を実行する機能
・画像（動画であってもよい）および音声を出力する機能
・ネットワーク通信機能（例えば、無線ＬＡＮを介して通信を行う機能、あるいは、モバイル通信網を介して通信を行う機能等）
上記の他、多機能情報端末は、カメラによる撮影機能や、近距離無線通信機能（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＮＦＣ（ＮｅａｒＦｉｅｌｄＣｏｍｍｕｎｉｃａｔｉｏｎ）による通信を行う機能）や、位置検出機能（例えば、ＧＰＳ機能）等を有していてもよい。

ゲーム機４は、ユーザが有する情報処理装置の一例であり、スマートフォン３とは異なる種類の情報処理装置の一例である。ゲーム機４は、ゲームアプリケーションを実行するが、他の種類のアプリケーションを実行することも可能である。本実施形態においては、スマートフォン３が既製の情報処理装置であるのに対して、ゲーム機４は、実施事業者によって製造されてユーザに対して提供される情報処理装置である。ゲーム機４は、実施事業者が提供するゲーム機アプリを実行可能な情報処理装置である。

なお、図１においては、スマートフォン３およびゲーム機４を１つずつ示しているが、本実施形態において、情報処理システムには、それぞれ複数のスマートフォンおよびゲーム機が含まれる。

また、本実施形態においては、スマートフォン３およびゲーム機４を１人のユーザが所有する場合（図１参照）を例として説明する。すなわち、以下においては、自社サービスサーバ１における自社サービスが、スマートフォン３およびゲーム機４の両方を所有するユーザに対して提供される場合を例として説明する。ただし、本実施形態において、自社サービスの提供を受けるユーザの全てが、スマートフォン３およびゲーム機４の両方を所有している必要はない。スマートフォンのみを所有するユーザは、自社サービスのうち、スマートフォンに関するサービスの提供を受けることが可能であるし、ゲーム機のみを所有するユーザは、自社サービスのうち、ゲーム機に関するサービスの提供を受けることが可能である。

なお、本実施形態において、「ユーザ」とは、「ネットワークサービスのアカウントに対応付けられるユーザ」という意味を含む。すなわち、本実施形態においては、ネットワークサービスの１つのアカウントを１人のユーザとみなす。したがって、情報処理システムは、複数の人間が１つのアカウントを共用する場合は当該複数の人間をまとめて１人のユーザとみなす。したがって、例えば、ある人物Ａがスマートフォン３を所有し、その人物の家族である人物Ｂがゲーム機４を所有する場合、人物Ａと人物Ｂとを１人のユーザと見なす。反対に、１人の人間が複数のアカウントを有する場合はアカウント毎に異なるユーザとみなす。

［２．各装置の構成］
次に、図２〜図４を参照して、本実施形態における情報処理システムに含まれる各装置またはサーバの構成の具体例について説明する。

（スマートフォンの構成の具体例）
図２は、スマートフォン３の構成の一例を示すブロック図である。図２に示すように、スマートフォン３は、入力部の一例として、タッチパネル１１およびボタン１２を備える。また、スマートフォン３は、表示部１５を備える。タッチパネル１１は、表示部１５の画面上に設けられる。表示部１５は、スマートフォン３の処理部１３において実行される情報処理によって生成された画像（例えば、アプリケーションの画像等）を表示する。ボタン１２は、例えば、スマートフォン３の電源のオン／オフを切り替えたり、表示部１５における画面表示のオン／オフを切り替えたりするために用いられる。なお、スマートフォン３は、スピーカ、マイク、および／または、カメラ等を備えていてもよい。

スマートフォン３は、処理部１３および記憶部１４を備える。処理部１３は、スマートフォン３の各部１１，１２，１４〜１６に電気的に接続される。処理部１３は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）およびメモリを有する。スマートフォン３においては、ＣＰＵがメモリを用いて、記憶部１４に記憶されたプログラムを実行することによって各種の情報処理が実行される。記憶部１４は、処理部１３において実行されるプログラム、処理部１３による情報処理に用いられるデータ、および、当該情報処理によって得られたデータ等を記憶する。

なお、スマートフォン３は、アプリケーションを実行するためのプラットホームを備えている。ここで、スマートフォン３のプラットホームとは、処理部１３を構成するハードウェア（すなわち、ＣＰＵ等）と、記憶部１４に記憶されているＯＳ（オペレーティングシステム。システムプログラムとも言う）とによって実現される、アプリケーションを実行するための構成を指す。本実施形態においては、スマートフォン３のプラットホームは、アンドロイド（登録商標）やｉＯＳといった、（実施事業者が開発したＯＳではなく）既存のＯＳを用いたプラットホームである。上記記憶部１４に記憶されたアプリケーションプログラムは、上記プラットホーム上で実行される。なお、スマートフォン３が有するプラットホームは、スマートフォンアプリと互換性を有し、ゲーム機アプリとは互換性を有しない。

スマートフォン３は、モバイル通信網（換言すれば、携帯電話通信網）に接続して通信を行うモバイル通信部１６を備える。本実施形態において、スマートフォン３（具体的には、処理部１３）は、モバイル通信部１６を用いて（換言すれば、モバイル通信部１６を介して）ネットワーク５に接続することによって他の装置（例えば、サーバ１および２等）と通信を行う。なお、スマートフォン３がネットワーク５を介した通信を行うための通信部の構成は任意である。なお、スマートフォン３は、モバイル通信部１６とは別の通信手段を備えていてもよい。例えば、スマートフォン３は、Ｗｉ−Ｆｉの認証を受けた通信モジュールによって無線ＬＡＮに接続する機能を有していてもよい。

なお、スマートフォン３は、図２に示す構成に加えて、他の構成を備えていてもよい。例えば、スマートフォン３は、ＮＦＣによる通信を行う機能、および／または、スマートフォン３の位置を検出する機能（例えば、ＧＰＳ機能）等を有していてもよい。

本実施形態においては、ユーザが有する汎用の多機能情報端末の一例として、スマートフォン３を例示した。ここで、他の実施形態においては、情報処理システムは、スマートフォン３に代えて、他の種類の多機能情報端末を含んでいてもよい。情報処理システムは、例えば腕時計型あるいはメガネ型の端末のように、ユーザに装着可能な情報処理装置（いわゆるウェアラブル端末）を多機能情報端末として含む構成であってもよい。

（ゲーム機の構成の具体例）
図３は、ゲーム機４の構成の一例を示すブロック図である。図３に示すように、ゲーム機４は、入力部の一例として、タッチパネル２１、ボタン２２、および、方向入力スティック２３を備える。また、ゲーム機４は、表示部２８を備える。なお、ゲーム機４は、スピーカ、マイク、および／またはカメラ等を備えていてもよい。

タッチパネル２１は、表示部２８の画面上に設けられる。表示部２８は、ゲーム機４の処理部２４において実行される情報処理によって生成された画像（例えば、ゲーム画像等）を表示する。

ボタン２２は、ゲーム機４の制御を行う指示（例えば、電源のオン／オフ等）、および／または、ゲーム機４で実行されるアプリケーションにおける入力指示を行うための入力部である。ゲーム機４は、例えば、ゲーム機４の電源のオン／オフまたは画面表示のオン／オフを切り替えるためのボタン、および、ゲーム機４において実行されるゲームアプリケーションにおいて所定のゲーム入力を行うためのボタンを備えていてもよい。このように、ゲーム機４は、ボタン２２として、複数個のボタンを備えていてもよい。さらに、ゲーム機４は、ゲーム用のボタン（すなわち、ゲーム機４で実行されるゲームアプリケーションにおける入力指示を行うために用いられるボタン）として、複数個のボタンを備えていてもよい。

また、方向入力スティック２３は、上下左右の少なくとも４方向に関する方向入力を行うことが可能な操作部の一例である。方向入力スティック２３は、例えば、アナログスティックまたはスライドスティック（スライドパッドとも言う）である。方向入力スティック２３は、ゲーム機４のハウジングの主面に平行な全方向（すなわち、上下左右および斜め方向を含む、３６０°の方向）に傾倒可能（またはスライド可能）なスティック部材を有する。ユーザは、スティック部材を傾倒（またはスライド）することによって傾倒方向に応じた方向の入力（および、傾倒した角度に応じた大きさの入力）が可能である。なお、ゲーム機４は、方向入力が可能な操作部として、十字キーを備えていてもよい。方向入力スティック２３は、例えば、ゲーム機４において実行されるゲームアプリケーションにおいて方向入力を行うために用いられる。

また、ゲーム機４は、ゲームカードコネクタ２６を備える。ゲームカードコネクタ２６は、ゲーム機４に装着されたゲームカードと接続するためのコネクタである。ここで、ゲーム機４は、ゲーム機４に専用のゲームカードを着脱可能に装着可能なスロットを備える。なお、「専用のゲームカード」とは、ゲーム機４に装着可能であり、かつ、ゲーム機４とは異なる種類の装置（少なくとも、スマートフォン３）に装着することができない記憶媒体であるという意味である。本実施形態において、ゲームカードは、上記の実施事業者によって、または、実施事業者の許諾を得た他者によって製造される。上記スロットに装着されたゲームカードは、ゲームカードコネクタ２６に接続され、ゲーム機４の処理部２４によってアクセス可能となる。ゲームカードは、例えば、ゲーム機４において実行可能なプログラム（例えば、ゲームアプリケーションのプログラム）、および／または、ゲーム機４において実行されるプログラムにおいて用いられるデータ（例えば、ゲームアプリケーションで用いられるゲームデータやセーブデータ）を記憶する。

ゲーム機４は、処理部２４および記憶部２５を備える。処理部２４は、ゲーム機４の各部２１〜２３，２５〜２８に電気的に接続される。処理部２４は、ＣＰＵおよびメモリを有する。ゲーム機４においては、ＣＰＵがメモリを用いて、記憶部２５に記憶されたプログラム、および／または、ゲーム機４に装着されたゲームカードに記憶されたプログラムを実行することによって各種の情報処理が実行される。記憶部２５は、処理部２４において実行されるプログラム、処理部２４による情報処理に用いられるデータ、および、当該情報処理によって得られたデータ等を記憶する。

なお、ゲーム機４は、アプリケーションを実行するためのプラットホームを備えている。ゲーム機４のプラットホームとは、処理部２４を構成するハードウェア（すなわち、ＣＰＵ等）と、記憶部２５に記憶されているＯＳとによって実現される、アプリケーションを実行するための構成を指す。本実施形態においては、ゲーム機４のプラットホームは、ゲーム機４に専用のＯＳを用いたプラットホームである。上記記憶部２５またはゲームカードに記憶されたアプリケーションは、上記プラットホーム上で実行される。なお、ゲーム機４が有するプラットホームは、ゲーム機アプリと互換性を有し、スマートフォンアプリとは互換性を有しない。

ゲーム機４は、ネットワーク５を介して他の装置と通信を行う機能を有する無線通信部２７を備える。無線通信部２７は、例えば、Ｗｉ−Ｆｉの認証を受けた通信モジュールであって、無線ＬＡＮに接続することが可能であってもよい。ゲーム機４（具体的には、処理部２４）は、無線通信部２７を用いて（換言すれば、無線通信部２７を介して）ネットワーク５に接続することによって他の装置（例えば、サーバ１および２等）と通信を行う。なお、ゲーム機４がネットワーク５を介した通信を行うための通信部の構成は任意である。また、ゲーム機４は、周囲の装置（例えば、ゲーム機４と同種のゲーム機）と近距離無線通信を行う機能を有する近距離通信部を備えていてもよい。近距離通信部は、例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）の規格に基づく通信を行う通信モジュールであってもよいし、赤外線通信を行う通信モジュールであってもよい。なお、他の実施形態においては、ゲーム機４は、モバイル通信網に接続して通信を行うモバイル通信部１６を備えていてもよい。

なお、ゲーム機４は、図３に示す構成に加えて、他の構成を備えていてもよい。例えば、ゲーム機４は、ＮＦＣによる通信を行う機能、および／または、ゲーム機４の位置を検出する機能（例えば、ＧＰＳ機能）等を有していてもよい。

（スマートフォン３とゲーム機４との相違点）
上記のように、スマートフォン３とゲーム機４とは、互いに異なる種類の情報処理装置である。具体的には、スマートフォン３とゲーム機４とは、次の点で異なっていることから、異なる種類の情報処理装置であると言うことができる。

まず、スマートフォン３とゲーム機４とでは、アプリケーションを実行するためのプラットホームが異なっている。すなわち、スマートフォン３は、既存のＯＳに基づくプラットホームによってアプリケーション（すなわち、スマートフォンアプリ）を実行するのに対して、ゲーム機４は、既存のＯＳとは異なる、ゲーム機４に専用のＯＳに基づくプラットホームによってアプリケーション（すなわち、ゲーム機アプリ）を実行する。スマートフォン３は、スマートフォンアプリと互換性を有し、ゲーム機アプリと互換性を有しないのに対して、ゲーム機４は、ゲーム機アプリと互換性を有し、スマートフォンアプリと互換性を有しない。このように、スマートフォン３とゲーム機４とでは、実行可能なアプリケーションが異なっている。

また、スマートフォン３は、モバイル通信網（換言すれば、携帯電話通信網）を介して通信を行う機能（モバイル通信網を介した通話機能と言うこともできる）を有しているのに対して、ゲーム機４は、当該機能を有していない点で、両者は異なっている。

また、ゲーム機４は、方向入力可能な操作装置（本実施形態では、方向入力スティック２３）を備えているのに対して、スマートフォン３は、このような操作装置を備えていない点で、両者は異なっている。ゲームアプリケーションにおいては一般的に、方向入力を行う機会が多いことから、方向入力可能な操作装置は、ゲーム操作用の操作装置であると言うことができる。ゲーム機４は、このようなゲーム操作用の操作部を備えるので、ゲームに適した情報処理装置であることから、ゲーム用の情報処理装置と言うことができる。スマートフォン３は、汎用の情報処理装置である（換言すれば、多機能情報端末である）のに対して、ゲーム機４は、ゲーム用の情報処理装置である点で、両者は異なっている。なお、上記のように、ゲーム機４は、ゲーム用の情報処理装置であるが、ゲーム用途でのみ利用可能であるわけではない。例えば、ゲーム機４は、ブラウザアプリケーションがインストールされることによってブラウザ機能を有していてもよいし、動画再生アプリケーションがインストールされることによって動画再生機能を有していてもよいし、カメラを備えることによって撮影機能を有していてもよい。

また、ゲーム機４は、専用のゲームカードが装着可能であるのに対して、スマートフォン３は、このゲームカードを装着することができない点で、両者は異なっている。

本実施形態においては、スマートフォン３とゲーム機４との間には少なくとも上記４つの相違点があるが、上記４つのうち少なくとも１つの相違点があれば、２つの情報処理装置は異なる種類の情報処理装置であると言うことができる。すなわち、他の実施形態においては、情報処理システムにおける端末装置である２種類の情報処理装置の間には、上記４つのうち少なくとも１つの相違点が存在すればよい。例えば、ゲーム機４は、モバイル通信網を介した通信を行う機能を必ずしも有していなくてもよいし、専用のゲームカードを必ずしも装着可能でなくてもよい。

（自社サービスサーバの構成の具体例）
図４は、自社サービスサーバ１の構成の一例を示す図である。図４に示すように、自社サービスサーバ１は、サービスを提供するための各種の機能に応じた複数のサーバを含む。なお、本明細書では、「サーバ」とは、１つの情報処理装置（すなわち、サーバ装置）を指す他、そのサーバの機能が複数のサーバ装置によって実現される場合にはサーバ装置群（すなわち、サーバシステム）全体を指す意味である。つまり、「サーバ」とは、サーバ装置であってもよいし、サーバシステムであってもよい。なお、本実施形態においては、自社サービスサーバ１は、複数のサーバ３１〜３４を含むものとするが、他の実施形態においては、１つのサーバ装置によって構成されてもよい。また、本実施形態においては、各サーバ３１〜３４はそれぞれ、１つのサーバ装置によって構成されてもよいし、機能および／または役割に応じて分けられた複数のサーバ装置を含む構成であってもよい。

自社サービスサーバ１は、管理サーバ３１を含む。管理サーバ３１は、自社サービスの提供を受けるユーザに関する情報の管理等を行う。具体的には、管理サーバ３１は、自社サービスの提供を受けるユーザのアカウント（すなわち、上記自社アカウント）を管理する。また、管理サーバ３１は、自社アカウントに対応するユーザ（換言すれば、自社アカウントを有するユーザ）について、各種の情報を管理する。なお、本実施形態においては、管理サーバ３１は、ユーザのフレンドリスト、ユーザに付与されるポイント、ユーザに関する履歴情報（例えば、アプリケーションの利用履歴や、購入履歴）、個人情報（例えば、名前、性別、年齢、住所等）等の情報を、自社アカウントに関連付けて管理する。

自社サービスサーバ１は、ゲーム機アプリ提供サーバ３２を含む。ゲーム機アプリ提供サーバ３２は、ユーザからのアプリ取得要求（例えば、アプリケーションを購入する要求）に応じて、ゲーム機４に対してゲーム機アプリを提供する。ゲーム機アプリ提供サーバ３２は、記憶部を備えており、提供すべきゲーム機アプリのデータを当該記憶部に記憶する。ゲーム機アプリ提供サーバ３２は、例えば、ゲーム機アプリを購入することができるショップサイトを提供するショップサーバである。すなわち、ゲーム機アプリ提供サーバ３２は、ゲーム機アプリを紹介するウェブページをゲーム機４に対して提示し、当該ウェブページにおいてゲーム機アプリに対する取得要求（例えば、購入要求）を受け付け、取得要求に応じてゲーム機４に対してゲーム機アプリのダウンロードを許可する。なお、ゲーム機アプリ提供サーバ３２は、既存のショップサーバと同じ機能および／または構成であってもよい。

自社サービスサーバ１は、セーブデータサーバ３３を含む。セーブデータサーバ３３は、スマートフォンアプリおよびゲーム機アプリに関して、ゲームアプリケーションのセーブデータを記憶部に記憶するサーバである。

自社サービスサーバ１は、ゲームサーバ３４を含む。ゲームサーバ３４は、スマートフォン３またはゲーム機４において、（スマートフォンアプリまたはゲーム機アプリである）ゲームアプリケーションのゲームを実行するための環境を提供する。例えば、ゲームサーバ３４は、ゲームアプリケーションを実行する端末（スマートフォン３またはゲーム機４）からの要求に応じて、必要に応じてゲーム処理を実行し、要求に応じたゲームデータを当該端末へ送信する。

また、本実施形態においては、アプリケーション毎にゲームサーバ３４が設けられる。本実施形態においては、実施事業者は複数のアプリケーションを提供しており、自社サービスサーバ１には、各アプリケーションに対応する複数のゲームサーバ３４が含まれるものとする（図４参照）。ただし、自社サービスサーバ１によって提供される複数のスマートフォンアプリおよびゲーム機アプリのうちには、ゲームサーバが設けられないアプリケーションがあってもよい。つまり、自社サービスサーバ１によって提供される複数のスマートフォンアプリおよびゲーム機アプリのうちには、ゲームサーバとの通信を必要としないアプリケーションがあってもよい。また、自社サービスサーバ１は、実施事業者以外の事業者によって提供されるゲームアプリケーションのゲームサーバを含んでいてもよい。

ゲームサーバ３４は、必要に応じて、管理サーバ３１、ゲーム機アプリ提供サーバ３２、および、セーブデータサーバ３３と通信を行う。例えば、ゲームサーバ３４は、自身において実行するゲーム処理においてフレンドリストを用いる場合、管理サーバ３１にアクセスしてフレンドリストを取得する。また、例えば、ゲームサーバ３４は、自身に対応するゲーム機アプリに関してゲーム機アプリ提供サーバ３２においてゲームデータ（ゲーム機アプリ自体であってもよい）の購入が行われた場合、ゲーム機アプリ提供サーバ３２にアクセスして、購入内容を示す情報を取得し、購入内容に応じたゲームデータをゲーム機４へ送信する。また、ゲームサーバ３４は、端末（スマートフォン３またはゲーム機４）においてゲーム処理が実行される際に、所定のタイミングで、セーブデータサーバ３３からセーブデータを取得したり、セーブデータサーバ３３にセーブデータを保存させたりする。

また、図４においては図示していないが、各サーバ３１〜３３の間においても、ゲームサーバ３４と各サーバ３１〜３３との間と同様、必要に応じてサーバ間で互いに通信が行われる。

各サーバ３１〜３４は、ＣＰＵおよびメモリを有する情報処理装置（すなわち、サーバ装置）を１以上含む。サーバにおいては、ＣＰＵがメモリを用いて、サーバに記憶された情報処理プログラムを実行することによって各種の情報処理が実行される。また、上記情報処理装置は、ネットワーク５を介して他の装置と通信を行う通信部を備える。ＣＰＵは、通信部を用いて（換言すれば、通信部を介して）ネットワーク５に接続することによって他の装置（例えば、他のサーバや、スマートフォン３や、ゲーム機４等）と通信を行う。

（スマートフォンアプリ提供サーバの構成）
上述のように、スマートフォンアプリ提供サーバ２で提供されるサービスは、既存のアプリ提供サービスであってもよい。したがって、スマートフォンアプリ提供サーバ２は、既存のショップサーバと同じ機能および／または構成であってもよい。例えば、スマートフォンアプリ提供サーバ２は、スマートフォンアプリを紹介するウェブページをスマートフォン３に対して提示し、当該ウェブページにおいてスマートフォンアプリに対する取得要求（例えば、購入要求）を受け付け、取得要求に応じてスマートフォン３に対してスマートフォンアプリのダウンロードを許可する。スマートフォンアプリ提供サーバ２は、ＣＰＵおよびメモリを有する情報処理装置（すなわち、サーバ装置）を１以上含む構成であり、ＣＰＵがメモリを用いて、サーバに記憶された情報処理プログラムを実行することによって各種の情報処理が実行される。また、上記情報処理装置は、ネットワーク５を介して他の装置と通信を行う通信部を備える。ＣＰＵは、通信部を用いて（換言すれば、通信部を介して）ネットワーク５に接続することによって他の装置（例えば、他のサーバや、スマートフォン３等）と通信を行う。

［３．情報処理システムにおける処理の概要］
以下、本実施形態における情報処理システムにおいて実行される処理動作について説明する。本実施形態においては、自社サービスサーバ１（換言すれば、自社サービス）によって、異なる種類の情報処理装置であるスマートフォン３とゲーム機４との間の橋渡しを行う。すなわち、自社サービスサーバ１は、スマートフォン３に対してゲーム機４に関する広告を提示したり、スマートフォンアプリに関する利用実績に応じてゲーム機４に関する特典を付与したり、スマートフォンアプリとゲーム機アプリとでセーブデータやフレンドリストを共有することを可能にしたりすることで、スマートフォン３とゲーム機４との間の橋渡しを行う。詳細は後述するが、このように異なる種類の情報処理装置間の橋渡しを行うことによって、ユーザの利便性を向上したり、アプリケーションの取得や利用をユーザに促したり、アプリケーションの興趣性を向上したりすることができる。また、本実施形態においては、スマートフォンアプリ提供サーバ２とスマートフォン３とからなるシステムは、既存のものを用いることができる。したがって、本実施形態においては、既存のシステム（スマートフォンアプリ提供サーバ２およびスマートフォン３）を利用するユーザに対して、新たなゲーム機４の購入、および／または、当該ゲーム機４を用いた新たなサービスの利用を促すことができる。以下、これらの効果を奏する処理動作のいくつかの例について説明する。

（３−１）自社アカウントの設定
まず、図５および図６を参照して、自社アカウントの設定処理について説明する。具体的には、自社アカウントを有していないユーザに対して、新たに自社アカウントを設定するための処理について説明する。

図５は、自社アカウントが設定される場合における処理の流れの一例を示す図である。なお、図５では、ユーザは、自社アカウントを有していない一方、スマートフォン３を所有しており、かつ、他者アカウントを有している場合を例として説明する。なお、他者アカウントの設定方法は任意であり、従来の設定方法が用いられてもよい。

図５に示すように、ユーザが自社アカウントを登録する際、まず、スマートフォン３は、ユーザの操作に応じて、自社アカウントを設定するための設定要求の情報を管理サーバ３１へ送信する（ステップＳ１）。この設定要求に応じて、管理サーバ３１は、自社アカウントを設定する処理を実行する（ステップＳ２）。具体的には、管理サーバ３１は、スマートフォン３のユーザについてユーザ管理情報を新たに作成して、自身が備える記憶部に記憶する。

図６は、管理サーバに記憶されるユーザ管理情報の一例を示す図である。図６に示すように、管理サーバ３１は、自社サービスのユーザ毎（換言すれば、アカウント毎）にユーザ管理情報を記憶する。図６に示すように、ユーザ管理情報には各種の情報が含まれる。ただし、上記ステップＳ２の処理においては、管理サーバ３１は、自社アカウントＩＤと、スマートフォンの識別情報であるスマートフォンＩＤとを少なくとも含むユーザ管理情報を生成して記憶する。上記ステップＳ２の処理の時点においては、自社アカウントＩＤおよびスマートフォンＩＤ以外の情報はユーザ管理情報に含まれていなくてもよい。

なお、スマートフォン３と管理サーバ３１との間で実行される、自社アカウントを設定する処理（ステップＳ１およびＳ２）の具体的な内容は、任意であり、従来におけるアカウント設定方法が用いられてもよい。例えば、管理サーバ３１は、設定要求に応じて、スマートフォンＩＤの送信をスマートフォン３に対して要求する。スマートフォン３は、この要求に応じて、自身のスマートフォンＩＤの情報を管理サーバ３へ送信する。スマートフォンＩＤは、送信元のスマートフォン３を特定するための情報である。ただし、スマートフォンＩＤは、スマートフォン３の装置に固有の情報である必要は無い。例えば、スマートフォンＩＤは、スマートフォン３で受信可能な（および、他の端末でも受信可能な）電子メールのメールアドレスを示す情報であってもよい。

管理サーバ３１は、スマートフォン３から送信されたスマートフォンＩＤと、自社アカウントＩＤとを関連付けて、ユーザ管理情報として記憶する。ここで、自社アカウントの設定内容（具体的には、ＩＤの番号または名前等）は、管理サーバ３１において設定されてもよいし、ユーザの入力によって設定されてもよい。また、自社アカウントＩＤとして、上記自社サービスとは別のネットワークサービスにおける他のアカウント情報が流用されてもよい。例えば、実施事業者とは別の事業者が行うネットワークサービスのアカウント（例えば、ＳＮＳ（ソーシャルネットワーキングサービス）のアカウント）のＩＤ、あるいは、実施事業者が行う上記自社サービスとは別のネットワークサービスのアカウントのＩＤが、自社アカウントＩＤとして設定可能であってもよい。このとき、スマートフォン３は、自身に記憶されている他のアカウント情報を自動的に（すなわち、ユーザが入力することなく）取得して、管理サーバ３１へ送信してもよい。

また、管理サーバ３１は、自社アカウントＩＤに関連付けられるパスワードをユーザに設定させる。このとき、管理サーバ３１は、設定されたパスワードを自社アカウントＩＤに関連付けて記憶する（図６）。また、管理サーバ３１は、ユーザに関する情報（例えば、名前、年齢、性別、住所、および、趣味等）をユーザに入力させ、入力された情報を自社アカウントＩＤに関連付けて記憶してもよい。

次に、管理サーバ３１は、他社アカウント情報をスマートフォン３に対して要求する（ステップＳ３）。この要求に応じて、スマートフォン３は、他社アカウントＩＤを含む他社アカウント情報を管理サーバ３１へ送信する（ステップＳ４）。例えば、スマートフォン３は、上記要求に応じて、他社アカウントＩＤの入力を受け付け、ユーザが入力した他社アカウントＩＤを管理サーバ３１へ送信する。なお、他の実施形態においては、スマートフォン３は、上記要求に応じた他社アカウントＩＤの送信を自動的に行ってもよい。また、他の実施形態においては、スマートフォン３は、上記ステップＳ１の処理において、自社アカウントＩＤおよび／またはパスワードとともに他社アカウント情報を管理サーバ３１へ送信してもよい。例えば、スマートフォン３は、自社アカウントＩＤおよび／またはパスワードをユーザに入力させる際に、他社アカウントＩＤもユーザに入力させるようにしてもよい。

スマートフォン３から他社アカウント情報を受信すると、管理サーバ３１は、ステップＳ２で設定した自社アカウントＩＤと、受信した他社アカウントＩＤとを関連付けて記憶する（ステップＳ５）。すなわち、管理サーバ３１は、スマートフォン３のユーザに関するユーザ管理情報に、受信した他社アカウントＩＤを加えて記憶する（図６参照）。

以上のステップＳ１〜Ｓ５の処理によって、自社アカウントが設定され、かつ、自社アカウントと他社アカウントとの関連付けが設定される。この時点（ステップＳ５の処理の完了時点）で、ユーザは、スマートフォン３を用いて自社サービスの提供を受けることができる。なお、スマートフォン３によってアカウントを設定したユーザは、ゲーム機４を所有していなくてもよい。

ゲーム機４においても自社サービスの提供を受けることを望む場合、ユーザは、ゲーム機４を自社サービスに登録するための登録要求をゲーム機４から管理サーバ３１へ送信する。すなわち、ゲーム機４は、ユーザの操作に応じて、上記登録要求を管理サーバ３１へ送信する（ステップＳ６）。例えば、自社サービスに対してゲーム機４を用いて最初にログインが行われる場合に、ゲーム機４は、上記登録要求を管理サーバ３１へ送信するようにしてもよい。

上記の登録要求は、自社アカウントＩＤ（およびパスワード）と、ゲーム機ＩＤとを含む。自社アカウントＩＤおよびパスワードは、ユーザによって入力される。ゲーム機ＩＤは、送信元のゲーム機を特定するための情報である。例えば、ゲーム機ＩＤは、ゲーム機毎に固有に付された番号である。ゲーム機４は、自身に予め設定されたゲーム機ＩＤを記憶部２５に記憶している。ゲーム機４は、ユーザによって入力された自社アカウントＩＤおよびパスワードと、記憶部２５に記憶されたゲーム機ＩＤとを含む登録要求を生成して、登録要求の情報を管理サーバ３１へ送信する。

管理サーバ３１は、ゲーム機４から受信した登録要求に基づいて、自社サービスにおけるゲーム機４の登録を行う。具体的には、管理サーバ３１は、登録要求に含まれる自社アカウントＩＤのユーザに関するユーザ管理情報に、当該登録要求に含まれるゲーム機ＩＤを加えて記憶する（ステップＳ７）。これによって、上記ユーザに関して、自社アカウントＩＤとゲーム機ＩＤとが関連付けられたことになる（図６参照）。また、自社アカウントＩＤについてスマートフォンＩＤとゲーム機ＩＤとが関連付けられることによって、ユーザが所有するスマートフォン３とゲーム機４との関連付けが行われたことになる。詳細は後述するが、本実施形態においては、自社サービスサーバ１がユーザの所有するゲーム機４へ何らかの情報を送信する場合に、ゲーム機ＩＤを用いて送信先のゲーム機が特定される。

なお、登録要求に含まれる自社アカウントＩＤとパスワードとの組が正しくない場合、管理サーバ３１は、ゲーム機４の登録を行わないようにしてもよい。

以上のように、本実施形態においては、スマートフォン３によって自社アカウントを登録したユーザは、ゲーム機４においても自社アカウントを利用してサービスを受けることができる。つまり、本実施形態においては、ユーザは、単一の自社アカウントについて、スマートフォン３およびゲーム機４の両方を用いてログインすることができ、スマートフォン３およびゲーム機４のどちらによっても自社サービスを利用することができる。

上記のように、本実施形態においては、管理サーバ３１は、スマートフォン３およびゲーム機４において単一の自社アカウントを用いる。ここで、他の実施形態においては、管理サーバ３１は、１人のユーザに対する自社アカウントとして、スマートフォン３用のアカウントとゲーム機４用のアカウントとを設定するようにしてもよい。この場合、管理サーバ３１は、ユーザ管理情報として、スマートフォン３用のアカウントとゲーム機４用のアカウントとの関連づけを示す情報を記憶しておくことによって、スマートフォン３とゲーム機４との対応（換言すれば、同じユーザが所有するスマートフォン３とゲーム機４との組）を特定することができる。

図５においては、ユーザがまずスマートフォン３を用いて自社アカウントの登録を行い、その後、ゲーム機４（換言すれば、ゲーム機ＩＤ）を自社アカウントに追加する場合を説明した。本実施形態においては、ユーザがまずゲーム機４を用いて自社アカウントの登録を行い、その後、スマートフォン３（換言すれば、スマートフォンＩＤ）を自社アカウントに追加することも可能である。すなわち、まず、ゲーム機４が、自社アカウントを設定する要求を管理サーバ３１に対して行うことによって、ゲーム機４からの要求に基づく自社アカウントの設定処理が行われる。この設定処理は、スマートフォン３に代えてゲーム機４から要求が行われる点、および、スマートフォンＩＤに代えてゲーム機ＩＤを含むユーザ管理情報が管理サーバ３１に記憶される点を除いて、ステップＳ１〜Ｓ５の処理と同様である。その後、ゲーム機４によって設定された自社アカウントに対してスマートフォン３を登録するための処理が実行される。この処理は、ゲーム機４に代えてスマートフォン３から上記登録要求を行う点、および、ゲーム機ＩＤに代えてスマートフォンＩＤが登録される点を除いて、ステップＳ６〜Ｓ７の処理と同様である。

また、本実施形態においては、他社アカウントを有していないユーザであっても、自社アカウントを登録することが可能である。このとき、スマートフォン３（またはゲーム機４）および管理サーバ３１が上記ステップＳ１およびＳ２の処理を実行することによって、上記ユーザについて自社アカウントを登録することができる。そして、自社アカウントを有するユーザが他社アカウントを登録した後で、スマートフォン３（またはゲーム機４）および管理サーバ３１が上記ステップＳ４およびＳ５の処理を実行することによって、管理サーバ３１において他社アカウントと自社アカウントとを関連付けて記憶することができる。

（３−２）スマートフォンにおける基本的な処理
次に、スマートフォンにおける基本的な処理として、スマートフォンアプリが起動されてから終了されるまでの処理例について説明する。図７は、スマートフォンにおいて実行される基本的な処理の流れの一例を示す図である。なお、スマートフォン３において実行される処理は、図７に示す処理に限らず、起動されるスマートフォンアプリによっては、図７に示していない処理（後述する）が実行されることがある。

図７において、スマートフォン３は、ユーザによる起動指示に応じて、スマートフォンアプリを起動（すなわち、実行開始）する（ステップＳ１１）。上記起動指示は、例えば、表示部１５に表示されるメニュー画面に含まれる、スマートフォンアプリのアイコンを指定する指示である。

本実施形態においては、スマートフォンアプリが起動されると、スマートフォン３は、自社サービス（具体的には、当該スマートフォンアプリのゲームに関するサービス）に対して自社アカウントＩＤでログインする（ステップＳ１２）。具体的には、スマートフォン３は、ログイン要求を示す情報をゲームサーバ３４へ送信する。この情報には、ユーザの自社アカウントＩＤおよびパスワードが含まれる。なお、ログイン要求の情報が送信されるゲームサーバ３４は、起動されたスマートフォンアプリに対応するゲームサーバである。

上記のように、本実施形態においては、スマートフォン３におけるログインは、自社サービスに対応するスマートフォンアプリの実行中に行われる。すなわち、スマートフォンアプリは、自社サービスへログインする機能を有している。

なお、端末（スマートフォン３またはゲーム機４）において、自社アカウントＩＤおよびパスワードは、自社アカウントＩＤおよびパスワードの入力を受け付けるログイン画面において、ユーザによって入力されてもよい。また、端末は、予め設定された自社アカウントＩＤおよびパスワードを記憶しておき、当該自社アカウントＩＤおよびパスワードを、ログイン要求を示す情報に含めるようにしてもよい。また、ログインは、シングルサインオンによって行われてもよい。すなわち、自社サービスとは異なる所定の他のサービスに対して端末がログイン中である場合に、自社アカウントＩＤおよびパスワードが要求されずに自社サービスに対してログイン可能であってもよい。

また、本実施形態においては、スマートフォンアプリが起動された場合、スマートフォン３は、アプリケーションに固有の識別情報（「アプリＩＤ」と呼ぶ）であって、起動されたアプリケーションのアプリＩＤの情報をゲームサーバ３４へ送信する。アプリＩＤの情報は、上記ログイン要求の情報とともに（またはログイン要求の情報に含められて）送信されてもよい。

上記ログイン要求の情報をスマートフォン３から受信すると、ゲームサーバ３４は、スマートフォン３によるログインを許可するか否かを管理サーバ３１に対して確認する（ステップＳ１３）。具体的には、ゲームサーバ３４は、ログインの確認のためのログイン確認要求の情報を管理サーバ３１へ送信する。ログイン確認要求の情報は、スマートフォン３から受信したログイン要求の情報に含まれる自社アカウントＩＤおよびパスワードを含む。また、ログイン確認要求の情報は、起動されたスマートフォンアプリのアプリＩＤを含む。

管理サーバ３１は、ログイン確認要求の情報をゲームサーバ３４から受信すると、ログイン処理を実行する（ステップＳ１４）。ログイン処理は、スマートフォン３からのログイン要求が正当であるか否かを判定し、正当である場合にログインを許可する処理である。ログイン処理は、管理サーバ３１に記憶されるユーザ管理情報を用いて実行される。なお、他の実施形態においては、ログイン要求の情報は、スマートフォン３から管理サーバ３１へ直接（つまり、ゲームサーバ３４を介さずに）送信されてもよい。つまり、管理サーバ３１は、自社アカウントＩＤおよびパスワードの情報をスマートフォン３から直接取得してもよい。

図８は、管理サーバに記憶されるユーザ管理情報の一例を示す図である。なお、図８では、ユーザ管理情報に含まれる各種の情報のうち、図７および図９に示す処理において用いられる情報のみを示している。図７に示すように、ユーザ管理情報には、自社アカウントＩＤおよびパスワードが含まれている。したがって、ログイン処理において、管理サーバ３１は、ゲームサーバ３４から受信した自社アカウントＩＤおよびパスワードが、管理サーバ３１に記憶されているユーザ管理情報に含まれる自社アカウントＩＤおよびパスワードと一致するか否かを判定する。

受信した自社アカウントＩＤおよびパスワードが、ユーザ管理情報に含まれる自社アカウントＩＤおよびパスワードと一致する場合、管理サーバ３１は、スマートフォン３からのログイン要求が正当であると判定する。この場合、管理サーバ３１は、ログインを承認する旨の通知をゲームサーバ３４へ送信する。

一方、受信した自社アカウントＩＤおよびパスワードが、ユーザ管理情報に含まれる自社アカウントＩＤおよびパスワードと一致しない場合、管理サーバ３１は、スマートフォン３からのログイン要求が正当でないと判定する。この場合、管理サーバ３１は、ログインを承認しない旨の通知をゲームサーバ３４へ送信する。図示しないが、この場合、ゲームサーバ３４は、ログインが失敗した旨の通知をスマートフォン３へ送信し、スマートフォン３は、ログインが失敗した旨をユーザに対して通知する。

なお、図８に示すように、ユーザ管理情報には、ログイン状態情報が含まれる。ログイン状態情報は、関連付けられる自社アカウントが現在ログイン中であるか否かを示す。したがって、ログインが行われる場合（ログインが承認される場合）、管理サーバ３１は、ログイン中であること、および、ログイン要求を行った端末の種類（すなわち、スマートフォンであるかゲーム機）を示すログイン状態情報を記憶する。このように、本実施形態においては、管理サーバ３１は、ログインを行っている端末の種類を管理する。なお、他の実施形態においては、ログイン状態情報は、単にログインが行われているかを示すものであってもよい。

また、スマートフォン３において、実行中のアプリケーション（スマートフォンアプリ）において自社サービスに対してログインが行われている状態で、他のアプリケーションが起動された場合、スマートフォン３は、ログイン要求の情報を送信しなくてもよい。また、上記の場合、スマートフォン３は、ログイン要求の情報を送信してもよく、このとき、管理サーバ３１は、ログイン中であるか否か再度確認するようにしてもよい。

また、スマートフォン３およびゲーム機４のいずれか一方の端末から、ある自社アカウントでログインがすでに行われている状態において、他方の端末から当該自社アカウントでログイン要求が行われた場合、管理サーバ３１は、当該一方および他方の両方の端末によってログインが行われていることを示すログイン状態情報を記憶する。なお、他の実施形態においては、上記の場合、管理サーバ３１は、上記他方の端末からのログイン要求に対してログインを承認しないようにしてもよい。

上記においては、スマートフォンアプリの起動時にログインが行われるものとしたが、ログインのタイミングは、スマートフォンアプリの実行中における任意のタイミングであってよい。例えば、スマートフォンアプリの実行中において、例えばメニュー画面からアイコンを選択する等の操作に応じて、ユーザがログイン操作を行うことが可能であってもよい。

また、他の実施形態においては、スマートフォン３は、スマートフォンアプリの実行中でない状態で、自社サービスへのログインを行うことが可能であってもよい。例えば、スマートフォン３は、スマートフォンアプリの実行中でない状態で、ログインを行う旨の指示をユーザから受け付けるようにしてもよい。

また、スマートフォンアプリは、自社サービスに対するログインを行わなくても実行可能なアプリケーションであってもよいし、自社サービスに対するログインを条件として実行可能なアプリケーションであってもよい。

また、上記ステップＳ１４の処理において、管理サーバ３１は、ログイン確認要求の情報をゲームサーバ３４から受信すると、当該情報に含まれるアプリＩＤ（スマートフォン３において起動されたスマートフォンアプリのアプリＩＤ）に基づいてアプリ実行情報を更新する。ここで、図８に示すように、管理サーバ３１は、自社アカウント毎にアプリ実行情報を自身の記憶部に記憶している。アプリ実行情報は、端末において実行中のアプリケーションを示す情報である。上記アプリＩＤを取得した場合、管理サーバ３１は、取得されたアプリＩＤを示す情報を追加するようにアプリ実行情報を更新する。なお、更新されるアプリ実行情報は、ログイン確認要求に含まれる自社アカウントＩＤに関連付けられるアプリ実行情報である。

以上のように、本実施形態においては、端末におけるアプリケーションの実行状態が管理サーバ３１において管理（記憶とも言える）される。なお、アプリ実行情報は、アプリケーションの実行が開始された時間の情報を含んでいてもよい。

なお、管理サーバ３１は、上記のようにして取得されるアプリＩＤおよび／またはアプリ実行情報に基づいて、端末におけるアプリケーションの利用履歴を作成して記憶するようにしてもよい。

図７において、ログインを承認する旨の通知を受信したゲームサーバ３４は、ゲームデータをスマートフォン３へ送信する（ステップＳ１５）。このゲームデータは、スマートフォンアプリにおいてゲーム処理を開始するために用いられるデータである。すなわち、上記ゲームデータを受信すると、スマートフォン３は、スマートフォンアプリにおけるゲーム処理を開始する（ステップＳ１６）。なお、スマートフォン３がゲームサーバ３４から取得するゲームデータは、後述するセーブデータサーバ３３に記憶されているセーブデータを含んでいてもよい。

なお、スマートフォンアプリの起動時にログインが行われない場合についてもログインが行われる場合と同様、スマートフォン３は、スマートフォンアプリの起動時において上記ゲームデータを取得する旨の要求の情報をゲームサーバ３４へ送信する。ゲームサーバ３４は、上記要求に応じてゲームデータをスマートフォン３へ送信する。また、ゲームサーバ３４は、スマートフォン３において起動されたスマートフォンアプリのアプリＩＤを管理サーバ３１へ送信し、管理サーバ３１は、上記ステップＳ１４の処理と同様に、取得されたアプリＩＤを示す情報を追加するようにアプリ実行情報を更新する。

ここで、本実施形態においては、スマートフォンアプリは、アプリケーションの起動時にスマートフォン３がゲームサーバ３４へアクセス可能であることを条件として実行される。換言すれば、スマートフォン３は、スマートフォンアプリの起動時にゲームサーバ３４から受信されるゲームデータによってスマートフォンアプリにおける処理（すなわち、ゲーム処理）の実行を開始することができる。例えば、上記ステップＳ１１の処理において、スマートフォン３がゲームサーバ３４と通信できなかった場合、スマートフォン３においては、スマートフォンアプリの実行が開始されず、スマートフォンアプリを起動する際の待機状態が継続する結果となる。なお、上記の場合において、スマートフォン３は、一定時間が経過してもゲームサーバ３４と通信できなければ（すなわち、ゲームサーバ３４からゲームデータを受信できなければ）、スマートフォンアプリの起動を中止してもよいし、ユーザに対する通知を行うようにしてもよい。

スマートフォンアプリの実行中において、スマートフォン３は、スマートフォンアプリのプログラムに基づいてゲーム処理を実行する（ステップＳ１７）。ここで、スマートフォンアプリにおいては、スマートフォン３とゲームサーバ３４との間で適宜のタイミングで通信が行われることによってゲーム処理が進められる。すなわち、スマートフォン３は、適宜のタイミングで処理要求の情報がゲームサーバ３４へ送信される。この処理要求の情報は、ゲーム処理に用いられるゲームデータをゲームサーバ３４に対して要求したり、ゲーム処理の実行をゲームサーバ３４に対して要求したりするためのものである。例えば、プレイ中のゲームステージがユーザによってクリアされたことに応じて、スマートフォン３は、次のゲームステージのゲームを開始するために必要なデータをゲームサーバ３４に対して要求する。

上記処理要求の情報を受信すると、ゲームサーバ３４は、要求に応じたゲーム処理を実行し、ゲームデータをスマートフォン３へ送信する（ステップＳ１８）。ゲームサーバ３４は、例えば、スマートフォン３からの要求に応じたゲームデータをスマートフォン３へ送信したり、スマートフォン３からの要求に応じたゲーム処理を実行し、実行の結果得られたゲームデータをスマートフォン３へ送信したりする。

スマートフォン３におけるスマートフォンアプリの実行中、上記ステップＳ１７およびＳ１８の処理が繰り返される。そして、ユーザによる終了指示に応じて、スマートフォン３は、スマートフォンアプリを終了する（ステップＳ１９）。

一方、ゲームサーバ３４は、スマートフォン３（換言すれば、スマートフォン３に対応する自社アカウント）がログアウトしたことを判断する（ステップＳ２０）。この判断の具体的な方法は任意であるが、本実施形態において、ゲームサーバ３４は、スマートフォン３からのアクセス（換言すれば、上記ステップＳ１７における処理要求）に基づいて上記判断を行う。具体的には、ゲームサーバ３４は、ログイン中のスマートフォン３から所定時間以上アクセスがない場合、当該スマートフォン３がログアウトしたと判断する。一方、ログイン中のスマートフォン３から所定時間よりも短い間隔でアクセスが行われている間は、ゲームサーバ３４は、当該スマートフォン３がログイン状態を維持していると判断する。

なお、他の実施形態においては、スマートフォンアプリを終了する場合、スマートフォン３は、自社アカウントＩＤでログインしていた自社サービスからログアウトする旨の通知を行うようにしてもよい。すなわち、スマートフォン３は、ログアウト要求の情報をゲームサーバ３４へ送信する。また、他の実施形態においては、スマートフォン３は、スマートフォンアプリの実行中において、ユーザによるログアウト指示に応じて、ログアウト要求の情報を管理サーバ３１へ送信してもよい。ログアウト要求の情報は、ログインしていた自社アカウントＩＤの情報を含む。また、ログアウト要求の情報は、実行を終了するスマートフォンアプリのアプリＩＤを含む。スマートフォン３からログアウト要求の情報を受信した場合、ゲームサーバ３４は、スマートフォン３がログアウトしたと判断する。

スマートフォン３がログアウトしたと判断した場合、ゲームサーバ３４は、ログアウト通知の情報を管理サーバ３１へ送信する（図７）。このログアウト通知の情報は、当該スマートフォン３に対応する自社アカウントＩＤと、当該ゲームサーバ３４によって管理されるスマートフォンアプリのアプリＩＤとを含む。

ゲームサーバ３４からログアウト通知の情報を受信すると、管理サーバ３１は、ログアウト処理を実行する（ステップＳ２１）。すなわち、管理サーバ３１は、上記ログアウト通知の情報に含まれる自社アカウントＩＤに関連付けられるログイン状態情報として、上記スマートフォン３がログアウトされていることを示す情報を記憶する。また、管理サーバ３１は、ログアウト通知の情報を受信すると、当該情報に含まれるアプリＩＤの情報を削除するようにアプリ実行情報を更新する。

なお、上記ログアウト通知の情報を受信した際に、ログアウト通知により特定されるスマートフォン３が、実行を終了したスマートフォンアプリとは異なる他のスマートフォンアプリを実行中である場合、管理サーバ３１は、当該スマートフォン３のログイン状態を維持する。すなわち、上記の場合、管理サーバ３１は、ログイン状態情報を更新しない。これによって、ログイン状態情報は、上記スマートフォン３がログインしていることを示す情報のままとなる。なお、スマートフォン３が上記他のスマートフォンアプリを実行中であるか否かは、上記アプリ実行情報に基づいて判定することができる。

なお、スマートフォン３がログアウトしたか否かの確認は、管理サーバ３１によって行われてもよい。例えば、管理サーバ３１は、スマートフォン３によるゲームサーバ３４への最終アクセス時刻の情報をゲームサーバ３４から受信し、この最終アクセス時刻の情報に基づいて、スマートフォン３がログアウトしたか否かを判断してもよい。

（３−３）ゲーム機における基本的な処理
次に、ゲーム機４における基本的な処理として、ゲーム機４が起動されてから停止される（例えば、電源オフにされる、あるいは、スリープ状態にされる）までの処理例について説明する。図９は、ゲーム機において実行される基本的な処理の流れの一例を示す図である。なお、ゲーム機４において実行される処理は、図９に示す処理に限らず、起動されるゲーム機アプリによっては、図９に示していない処理（後述する）が実行されることがある。

まず、ゲーム機４が起動される（例えば、電源オンにされる、あるいは、スリープ状態から復帰される）と、ゲーム機４は、自社サービス（具体的には、当該ゲーム機アプリのゲームに関するサービス）に対して自社アカウントＩＤでログインする（ステップＳ３１）。具体的には、ゲーム機４は、ログイン要求を示す情報を管理サーバ３１へ送信する。この情報には、ユーザの自社アカウントＩＤおよびパスワードが含まれる。

上記のように、本実施形態においては、ゲーム機４においては、スマートフォン３とは異なり、ゲーム機アプリが実行されていない期間にログインが行われる。なお、ゲーム機４におけるログインのタイミングは、ゲーム機４の起動時のタイミングに限らない。例えば、ゲーム機４におけるログインのタイミングは、ユーザがログインの指示を行ったタイミングであってもよい。なお、他の実施形態においては、ゲーム機４においてもスマートフォン３と同様、ゲーム機アプリの実行中に、実行中のゲーム機アプリからログインが行われてもよい。

管理サーバ３１は、ログイン要求の情報をゲーム機４から受信すると、ログイン処理を実行する（ステップＳ３２）。すなわち、管理サーバ３１は、上記ステップＳ１４のログイン処理と同様、ログイン要求が正当であるか否かを判定する。また、管理サーバ３１は、必要に応じて、ログイン状態情報の更新を行う。ただし、ステップＳ３２のログイン処理においては、アプリ実行情報の更新は行われない。また、管理サーバ３１は、ログインを承認する旨の通知、または、承認しない旨の通知をゲーム機４へ送信する。図示しないが、ログインを承認しない旨の通知を受信した場合、ゲーム機４は、ログインが失敗した旨をユーザに対して通知する。

ゲーム機４においては、ユーザによる起動指示に応じて、ゲーム機アプリを起動（すなわち、実行開始）する（ステップＳ３３）。上記起動指示は、例えば、表示部２８に表示されるメニュー画面に含まれる、ゲーム機アプリのアイコンを指定する指示である。ゲーム機アプリが起動されると、ゲーム機４は、アプリ起動通知の情報を管理サーバ３１へ送信する。アプリ起動通知の情報は、ログインに用いられた自社アカウントＩＤと、起動されたゲーム機アプリのアプリＩＤとを含む。

上記アプリ起動通知の情報をゲーム機４から受信すると、管理サーバ３１は、当該アプリ起動通知の情報に含まれるアプリＩＤに基づいてアプリ実行情報を更新する（ステップＳ３４）。ステップＳ３４の処理は、上記ステップＳ１４のログイン処理におけるアプリ実行情報の更新処理と同様である。すなわち、管理サーバ３１は、アプリ起動通知の情報に含まれる自社アカウントＩＤに関連付けられるアプリ実行情報を、取得されたアプリＩＤを示す情報を追加するように更新する。

ゲーム機アプリの起動後、ゲーム機４は、ゲーム機アプリにおけるゲーム処理を開始する（ステップＳ３５）。なお、本実施形態において、ゲーム機アプリのゲーム処理の開始時に用いられるセーブデータは、ゲーム機４の記憶部２５（または、ゲーム機４に装着されたゲームカード）において記憶されている。そのため、ゲーム機アプリの起動時においては、ゲーム機４は、ゲームサーバ３４にアクセスしないものとする。このように、ゲーム機アプリは、スマートフォンアプリとは異なり、アプリ起動時にゲーム機４が自社サービスサーバ１（管理サーバ３１あるいはゲームサーバ３４）へアクセス可能であることを条件とせずに実行される。

上記のように、本実施形態においては、ゲーム機アプリを起動するゲーム機４は、ゲーム機アプリの起動時において、ゲームサーバ３４との通信を行わないものとする。ただし、他の実施形態においては、ゲーム機アプリの起動時において、ゲーム機４は、ゲームサーバ３４との通信を行うようにしてもよい。すなわち、ゲーム機４は、アプリ起動時においてゲームサーバ３４と通信を行い、ゲームサーバ３４から受信されるゲームデータを用いてゲーム処理を開始してもよい。なお、ゲーム機アプリの起動時においてゲーム機４がゲームサーバ３４と通信を行う場合であっても、ゲーム機アプリは、アプリ起動時にゲーム機４が自社サービスサーバ１へアクセス可能であることを条件とせずに実行されてもよい。すなわち、アプリ起動時にゲーム機４がゲームサーバ３４との通信を試みたものの、ゲームサーバ３４と通信できなかった場合であっても、ゲーム機アプリの実行が開始されてもよい。

ゲーム機アプリの実行中において、ゲーム機４は、ユーザの指示に応じて、サーバ通信処理を実行する（ステップＳ３６）。ここで、サーバ通信処理は、ゲームサーバ３４との通信を行うゲーム処理である。サーバ通信処理は、例えば、ゲームサーバ３４を介して他のユーザとマルチプレイを行うためのゲーム処理や、後述するセーブデータサーバ３３に記憶されるセーブデータを用いたゲーム処理である。サーバ通信処理において、ゲーム機４は、ゲームサーバ３４との間で適宜のタイミングで通信を行うことによってゲーム処理を進める。

また、ユーザによる終了指示があると、ゲーム機４は、実行中のゲーム機アプリを終了する（ステップＳ３８）。

本実施形態において、ゲームサーバ３４は、ゲーム機４におけるゲーム機アプリの実行が終了したことを確認する（ステップＳ３９）。この判断の具体的な方法は任意であるが、本実施形態においては、ゲームサーバ３４は、ゲーム機アプリによる当該ゲームサーバ３４へのアクセス（換言すれば、上記サーバ通信処理によるアクセス）に基づいて、上記判断を行う。具体的には、ゲームサーバ３４は、ゲーム機アプリによるアクセスが所定時間以上ない場合、当該ゲーム機アプリの実行が終了したと判断する。一方、ゲーム機アプリによるアクセスが所定時間よりも短い間隔で行われている間は、ゲームサーバ３４は、ゲーム機アプリが実行中であると判断する。

なお、他の実施形態においては、ゲーム機４は、実行中のゲーム機アプリを終了した場合、ゲーム機アプリを終了した旨を示す情報を管理サーバ３１へ送信してもよい。この情報は、ログインしている自社アカウントＩＤと、終了するゲーム機アプリのアプリＩＤとを含む。上記情報を受信した場合、ゲームサーバ３４は、当該情報によって特定されるゲーム機アプリの実行が終了したと判断する。

ゲーム機４においてゲーム機アプリが終了したと判断した場合、ゲームサーバ３４は、ゲーム機アプリが終了した旨を示す終了通知の情報を管理サーバ３１へ送信する（図９）。終了通知の情報は、終了したゲーム機アプリのアプリＩＤと、当該ゲーム機アプリを実行していたゲーム機４がログインしている自社アカウントＩＤとを含む。

上記終了通知を受信すると、管理サーバ３１は、アプリ実行情報の更新処理を実行する（ステップＳ４０）。すなわち、管理サーバ３１は、終了通知の情報に含まれる自社アカウントＩＤに関連付けられるアプリ実行情報を、当該終了通知の情報に含まれるアプリＩＤを示す情報を削除するように更新する。

本実施形態において、管理サーバ３１は、ゲーム機４（換言すれば、ゲーム機４に対応する自社アカウント）がログアウトしたことを判断する（ステップＳ４１）。この判断の具体的な方法は任意であるが、本実施形態において、管理サーバ３１は、ゲーム機４からのアクセスに基づいて上記判断を行う。この「ゲーム機４からのアクセス」は、上記ステップＳ３９におけるアクセスとは異なり、特定のゲーム機アプリによるアクセスではなく、ゲーム機４のＯＳによるアクセスである。具体的には、本実施形態においては、ゲーム機４のＯＳは、管理サーバ３１に対して、所定のタイミングで、所定の要求を示す情報を自動的に行う。この所定の要求は、例えば、管理サーバ３１からゲーム機４へ情報（例えば、ＯＳやゲーム機アプリの更新に関する情報、および／または、ユーザに対するお知らせに関する情報等）を送信する旨の要求である。上記所定のタイミングは、例えば、所定時間に１回の割合で到来するタイミング等である（後述するステップＳ６２参照）。したがって、管理サーバ３１は、上記要求をゲーム機４から継続的に受信しているか否かによって、ゲーム機４が起動中であるか停止されているかを判断することができる。

具体的には、管理サーバ３１は、ゲーム機４から所定時間以上、ゲーム機４のＯＳによる上記アクセス（換言すれば、上記所定の要求）がない場合、当該ゲーム機４がログアウトしたと判断する。一方、ゲーム機４から所定時間よりも短い間隔で上記アクセスが行われている間は、管理サーバ３１は、当該ゲーム機４がログイン状態を維持していると判断する。

なお、他の実施形態においては、ゲーム機４が停止される（例えば、電源オフにされる、あるいは、スリープ状態にされる）と、ゲーム機４は、ログアウト要求の情報を管理サーバ３１へ送信してもよい。また、他の実施形態においては、ゲーム機４は、ユーザによるログアウト指示に応じて、ログアウト要求の情報を管理サーバ３１へ送信してもよい。ログアウト要求の情報は、ログインしていた自社アカウントＩＤの情報を含む。ゲーム機４からログアウト要求を受信した場合、管理サーバ３１は、当該ゲーム機４がログアウトしたと判断する。

ゲーム機４がログアウトしたと判断した場合、管理サーバ３１は、ログアウト処理を実行する（ステップＳ４２）。すなわち、管理サーバ３１は、当該ゲーム機４に対応する自社アカウントＩＤに関連付けられるログイン状態情報として、当該ゲーム機４がログアウトされていることを示す情報を記憶する。

なお、他の実施形態においては、管理サーバ３１は、ゲーム機４のログアウトに関する判断を、スマートフォン３のログアウトに関する判断（上記ステップＳ２０）と同様の方法で行うようにしてもよい。すなわち、管理サーバ３１は、上記ステップＳ３９の処理において、ゲーム機４におけるゲーム機アプリの実行が終了したと判断した場合、ゲーム機４がログアウトしたと判断してもよい。

（スマートフォンアプリの処理とゲーム機アプリの処理との違い）
ここで、スマートフォンアプリとゲーム機アプリとは、互いに異なる種類の情報処理装置において実行可能なアプリケーションであり、異なる種類のアプリケーションであると言うことができる。また、スマートフォンアプリのゲーム処理とゲーム機アプリのゲーム処理は、次の点で相違していると言える。

上記のように、本実施形態において、スマートフォンアプリは、当該スマートフォンアプリの処理を実行するために、スマートフォン３がサーバ（すなわち、ゲームサーバ３４）へアクセス可能であることを条件とする。一方、ゲーム機アプリは、ゲーム機アプリの処理を実行するために、ゲーム機４がサーバへアクセス可能であることを条件としないアプリケーションである。

また、スマートフォンアプリとゲーム機アプリとでは、アプリケーションにおける処理実行中にゲームサーバ３４にアクセスする条件が異なる。すなわち、スマートフォンアプリにおいては、ゲーム処理の進行に関する条件が満たされたことに応じて自動的に（すなわち、ゲームサーバ３４にアクセスする旨のユーザ指示の有無にかかわらず）、スマートフォン３がゲームサーバ３４にアクセスし、ゲームサーバ３４からゲームデータを取得する（ステップＳ１７）。これに対して、ゲーム機アプリにおいては、ゲームサーバ３４にアクセスするユーザの指示があったことに応じて、ゲーム機４がゲームサーバ３４にアクセスし、ゲームサーバ３４からゲームデータを取得する（ステップＳ３６）。例えば、ゲーム機４は、ゲーム内容をセーブする指示をユーザが行ったことに応じて、セーブデータをゲームサーバ３４へ送信したり、他のユーザとマルチプレイを行う指示をユーザが行ったことに応じてゲームサーバ３４と通信を行ったりする。なお、通常、スマートフォンアプリは、ゲームサーバ３４にアクセスする頻度がゲーム機アプリよりも高いと言える。

（３−４）スマートフォンを用いてゲーム機アプリを購入する処理
次に、図１０〜図１４を参照して、スマートフォン３を用いてゲーム機アプリを購入し、購入されたゲーム機アプリをゲーム機４にダウンロードする処理例について説明する。本実施形態においては、スマートフォン３におけるスマートフォンアプリの実行中において、ゲーム機アプリの広告がユーザに対して提示され、ユーザは、スマートフォン３を用いて当該ゲーム機アプリを購入することができる。そして、購入されたゲーム機アプリは、当該ユーザの所有するゲーム機４にダウンロードされる。これによれば、スマートフォン３においてスマートフォンアプリを利用するユーザに対してゲーム機アプリを購入する動機付けを与えることができ、スマートフォンアプリをきっかけとしてゲーム機アプリの利用を促進することができる。以下、詳細について説明する。

図１０は、スマートフォン３を用いてゲーム機アプリを購入する処理の概要の一例を示す図である。また、図１１は、スマートフォン３を用いてゲーム機アプリを購入する処理の流れの一例を示す図である。

まず、スマートフォン３は、スマートフォンアプリ提供サーバ２から提供されるスマートフォンアプリ（ここでは、ゲームアプリケーション）を予めダウンロードし、インストールしておく（図１０に示す（１））。

図１１において、スマートフォン３は、ユーザによる起動指示に応じて、スマートフォンアプリを起動（すなわち、実行開始）し、ログインを行う（ステップＳ５０）。なお、ステップＳ５０の処理は、図７に示すステップＳ１１およびＳ１２の処理と同様の処理である。ステップＳ５０の処理に応じて、ゲームサーバ３４は、図７に示すステップＳ１３の処理と同様のログイン確認処理と、ステップＳ１５の処理と同様のゲームデータの送信処理とを実行する（ステップＳ５１）。すなわち、ゲームサーバ３４は、管理サーバ３１に対してログインの確認を行い、管理サーバ３１によってログインが承認された場合、ゲームデータをスマートフォン３へ送信する（ステップＳ５１）。このとき、管理サーバ３１は、図７に示すステップＳ１４と同様のログイン処理を実行する（ステップＳ５２）。スマートフォン３は、受信したゲームデータを用いてゲーム処理を開始する（ステップＳ５３）。なお、ステップＳ５０〜Ｓ５３の一連の処理は、上記“（３−２）スマートフォンにおける基本的な処理”で述べたステップＳ１１〜Ｓ１６の処理と同様である。

（広告情報の提示）
ここで、本処理例では、ログインを承認する旨の通知を管理サーバ３１から受信した場合、ゲームサーバ３４は、ゲームデータと広告情報とをスマートフォン３へ送信する（図１０に示す（２）、図１１に示すステップＳ５１）。このように、本実施形態においては、ゲームサーバ３４は、スマートフォンアプリにおいて自社サービスにログインしている間において広告情報をスマートフォン３へ送信する。

ただし、他の実施形態においては、ゲームサーバ３４は、ログイン中でない期間に広告情報をスマートフォン３へ送信してもよい。例えば、スマートフォンアプリの実行中において、スマートフォン３とゲームサーバ３４との間でゲームデータの送受信が行われる場合、ログイン中でなくても、ゲームデータとともに広告情報をスマートフォン３へ送信してもよい。

スマートフォン３は、広告情報を受信すると、スマートフォンアプリ内において、当該広告情報に基づく広告画像を表示する（図１１に示すステップＳ５４）。これによって、スマートフォンアプリを利用するユーザに対して広告が提示される。

ここで、広告情報は、スマートフォン３において提示される広告を示す情報であり、本実施形態においては、ゲーム機アプリに関する広告を示す。広告に対応するゲーム機アプリは、任意であるが、例えば、実行中のスマートフォンアプリ（すなわち、後述する広告画像が表示されるスマートフォンアプリ）に関連するゲーム機アプリである。具体的には、広告に対応するゲーム機アプリは、スマートフォンアプリと同じシリーズのゲームアプリケーション（例えば、スマートフォンアプリの続編のゲームアプリケーション）であってもよい。また、広告に対応するゲーム機アプリは、実行中のスマートフォンアプリのゲームデータを利用可能なゲームアプリケーション（例えば、スマートフォンアプリに登場するキャラクタを用いたゲームアプリケーション）であってもよい。また、広告に対応するゲーム機アプリは、実行中のスマートフォンアプリとセーブデータを共有することが可能なゲームアプリケーションであってもよい（後述する“（３−５）スマートフォンアプリとゲーム機アプリでセーブデータを共有する処理”参照）。また、広告に対応するゲーム機アプリは、実行中のスマートフォンアプリとアプリフレンドリストが共通の内容に設定されるゲームアプリケーションであってもよい（後述する“（３−７）スマートフォンとゲーム機とでフレンドリストを共有する処理”参照）。

ここで、管理サーバ３１に記憶されるユーザ管理情報には、ユーザ関連情報が記憶される。広告情報の内容は、このユーザ関連情報に基づいて決定されてもよい。ユーザ関連情報とは、例えば、ユーザの履歴情報（例えば、アプリケーションの利用履歴や、購入履歴）、および／または、個人情報（例えば、名前、性別、年齢、住所、地域等）等の情報である。例えば、履歴情報は、上述のログイン状態情報の履歴に基づいて生成されて記憶されてもよい。例えば、管理サーバ３１は、上述のログイン要求およびログアウト通知に基づいて、ユーザがログインまたはログアウトした履歴を示す情報を生成したり、上述のアプリ起動通知および終了通知に基づいて、ユーザがアプリケーションを利用した履歴を示す情報を生成したりしてもよい。また、個人情報は、自社アカウントの登録時にユーザによって入力された情報に基づくものであってもよい。

また、他の実施形態においては、管理サーバ３１は、スマートフォンアプリのアプリＩＤと、広告情報の内容とを関連付けた情報を記憶しておき、当該情報に基づいて広告情報を決定してもよい。すなわち、管理サーバ３１は、スマートフォン３において実行中のスマートフォンアプリのアプリＩＤをスマートフォン３から取得し（ログイン処理時に取得しておいてもよい）、取得したアプリＩＤに関連付けられる広告情報の内容に決定してもよい。また、他の実施形態においては、広告情報の内容は、実行中のスマートフォンアプリと、ユーザ関連情報とに基づいて決定されてもよい。

本実施形態において、管理サーバ３１は、ユーザ関連情報に基づいて広告情報の内容を決定する。例えば、管理サーバ３１は、上記履歴情報に基づいてユーザの趣味嗜好を推測することで広告情報の内容を決定してもよい。具体的には、管理サーバ３１は、推測されたユーザの趣味嗜好に応じたゲーム機アプリに関する広告情報を決定してもよい。管理サーバ３１は、決定した広告情報をゲームサーバ３４へ送信する。例えば、管理サーバ３１は、上述したログインを承認する旨の通知とともに、広告情報をゲームサーバ３４へ送信する。ゲームサーバ３４は、管理サーバ３１から受信した広告情報をスマートフォン３へ送信する。なお、他の実施形態においては、管理サーバ３１が広告情報を直接スマートフォン３へ送信してもよい。

また、他の実施形態においては、広告情報の決定は、管理サーバ３１に代えてゲームサーバ３４で行われてもよいし、管理サーバ３１とゲームサーバ３４との協働によって行われてもよい。例えば、管理サーバ３１がユーザ関連情報の一部または全部をゲームサーバ３４へ送信し、ゲームサーバ３４は、受信したユーザ関連情報に基づいて広告情報の内容を決定してもよい。なお、広告情報の内容は、後述するポイント情報（詳細は後述するが、スマートフォンアプリの利用実績を示す情報と言える。後述する“（３−６）スマートフォンアプリの提供サービスの利用に応じて自社サービスサーバ１においてポイントを管理する処理”参照）に基づいて決定されてもよい。例えば、ポイント情報が表すポイント数（換言すれば、ユーザに付与されたポイント数）に応じて、広告情報の内容が決定されてもよい。

上記ステップＳ５４の処理において、スマートフォン３は、広告情報に基づいて広告画像を生成し、スマートフォンアプリの画像（ここではゲーム画像）に広告画像を含めて表示部１５に表示する。図１２は、スマートフォン３に表示される、広告画像を含むゲーム画像の一例を示す図である。図１２においては、スマートフォン３の表示部１５にはゲーム画像４１とともに広告画像４２が表示される。広告画像４２は、例えば「このゲームの新作がゲーム機○○で登場！」（「○○」はゲーム機の商品名である）といった、ゲーム機アプリを紹介するメッセージを含む。なお、広告画像４２の内容は任意であり、広告を表すメッセージおよび／または絵柄を含むものであってもよい。また、広告画像４２は、動画であってもよい。

なお、広告画像４２は、スマートフォンアプリによるゲーム画像が表示部１５に表示される期間における任意のタイミングで表示されてよい。例えば、広告画像４２は、図１２に示すように、ゲーム中におけるゲーム画像とともに表示されてもよい。また例えば、スマートフォンアプリにおいてお知らせを表示する画面が用意されている場合、当該お知らせの１つとして広告画像４２が表示されてもよい。また、スマートフォン３は、広告情報を受信したことを示す通知画像をまず表示部１５に表示し、広告画像４２を表示する旨のユーザ指示（例えば、通知画像をタッチする指示）に応じて広告画像４２を表示するようにしてもよい。

（ゲーム機アプリの購入）
本実施形態においては、ユーザは、スマートフォンアプリを利用している状態で、上記広告画像に関するゲーム機アプリを購入することが可能である。以下、ゲーム機アプリを購入するための処理について説明する。

スマートフォン３の表示部１５に上記広告画像４２が表示される状態において、ユーザによる所定の操作が行われた場合、スマートフォン３は、広告画像４２が示すゲーム機アプリを購入するための購入ページを表示部１５に表示する。所定の操作は、例えば、広告画像４２を指定する操作（より具体的には、広告画像４２をタッチする操作）である。スマートフォン３は、上記所定の操作に応じて、購入ページを取得する要求（ページ取得要求と呼ぶ）の情報をゲーム機アプリ提供サーバ３２へ送信する（図１１に示すステップＳ５５）。本実施形態において、購入ページは、ゲーム機アプリ提供サーバ３２によって提供されるウェブページである。スマートフォン３からのページ取得要求の情報を受信したゲーム機アプリ提供サーバ３２は、ページ取得要求に対応する購入ページを当該スマートフォン３へ送信する（図１０に示すステップＳ５６）。

なお、本実施形態においては、スマートフォン３において受信される広告情報は上記購入ページのリンク情報（例えば、ＵＲＬを示す情報）を含んでおり、スマートフォン３は、当該リンク情報に基づいて上記ページ取得要求の情報をゲーム機アプリ提供サーバ３２へ送信する。そして、ゲーム機アプリ提供サーバ３２は、リンク情報に対応する購入ページのデータをスマートフォン３へ送信する。なお、他の実施形態においては、ページ取得要求の情報は、広告情報が表すゲーム機アプリを示す情報（例えば、アプリケーションのＩＤ）を含んでいてもよい。このとき、ゲーム機アプリ提供サーバ３２は、受信した情報が示すゲーム機アプリの購入ページのデータをスマートフォン３へ送信する。

スマートフォン３は、ゲーム機アプリ提供サーバ３２から受信した購入ページを表示部１５に表示する（図１０に示すステップＳ５７）。このとき、スマートフォン３は、上述の購入ページを取得する操作（すなわち、ユーザによる広告画像４２を指定する操作）に応じてスマートフォンアプリによる処理を一時中断する。例えば、スマートフォン３は、ゲーム処理に対する入力の受付を停止し、ゲームの進行を一時停止する。そして、スマートフォン３は、ブラウザアプリを用いて購入ページを表示部１５に表示する。つまり、表示部１５に表示される画像は、スマートフォンアプリによるゲーム画像から、ブラウザアプリによる購入ページの画像へと切り替わる。これに応じて、スマートフォン３は、購入ページに対する入力の受付を開始する。

図１３は、スマートフォン３に表示される、購入ページの画像の一例を示す図である。図１３に示すように、購入ページ画像４３は、ゲーム機アプリを購入するためのウェブページであり、ゲーム機アプリに関する情報（例えば、価格やゲーム内容の紹介に関する情報）を表す。また、購入ページ画像４３は、購入指示を行うための指示画像４４を含む。

なお、本実施形態においては、購入ページは、いわゆるショッピングサイトを提供するゲーム機アプリ提供サーバ３２によって提供されるウェブページであるが、購入ページの種類は任意である。例えば他の実施形態においては、ゲーム機アプリを紹介するホームページ内におけるウェブページであってもよい。このとき、上記ホームページを提供するサーバがゲーム機アプリ提供サーバ３２とは別であれば、購入ページは、当該サーバから取得されてもよい。また、購入ページは、サーバから取得されるウェブページに限らず、スマートフォンアプリによって生成される画像であってもよい。

また、スマートフォン３は、表示部１５に表示される画像を、スマートフォンアプリによるゲーム画像から購入ページへと切り替える必要はなく、例えば、スマートフォンアプリによるゲーム画像の上に（換言すれば、手前に）購入ページの画像が重ねて表示されてもよい。なお、スマートフォン３は、複数のアプリケーションをマルチタスクにより実行してもよい。このとき、スマートフォン３は、スマートフォンアプリとブラウザアプリとをマルチタスクにより実行し、スマートフォンアプリによる画像（すなわち、ゲーム画像）の上に、ブラウザアプリによる画像（すなわち、購入ページ）を表示するようにしてもよい。

ユーザは、購入ページ画像４３に含まれる指示画像４４を指定することによって、ゲーム機アプリを購入する指示を行うことができる。すなわち、スマートフォン３は、ユーザによる指示画像４４を指定する操作（例えば、指示画像４４をタッチする操作）に応じて、ゲーム機アプリに関する購入要求の情報をゲーム機アプリ提供サーバ３２へ送信する（図１０に示す（３）、図１１に示すステップＳ５８）。購入要求の情報には、ログインしているアカウントを特定可能な情報が含まれる。なお、本実施形態においては、購入要求の情報は、自社アカウントＩＤを含む。

ゲーム機アプリ提供サーバ３２は、購入要求の情報を受信すると、課金処理を実行する（図１１に示すステップＳ５９）。課金処理とは、ユーザに対して料金を課す処理であり、具体的には、料金を請求する通知をユーザに対して行う処理である。本実施形態においては、スマートフォン３において、上記購入ページにおいてゲーム機アプリに対する購入指示が行われると、当該ゲーム機アプリに関する課金を行う旨をユーザに通知する課金ページが表示される。すなわち、ゲーム機アプリ提供サーバ３２は、上記課金ページをスマートフォン３へ送信する。スマートフォン３は、ゲーム機アプリ提供サーバ３２から課金ページを受信して表示部１５に表示する。

本実施形態においては、ユーザは、上記課金ページにおいて、課金された料金の支払いを行うことができる。すなわち、課金ページにおいては支払方法（換言すれば決済方法）を選択することが可能であり、ユーザが選択した方法によって、ゲーム機アプリの料金の支払いが行われる。なお、料金の決済方法は任意であり、どのような方法であってもよい。例えば、自社サービスサーバ１は、自社サービスにおいて利用可能なポイント（仮想通貨とも言える）を管理し、このポイントを用いて決済を行うようにしてもよい。また、自社サービスサーバ１は、いわゆるキャリア決済によって決済を行うようにしてもよい。なお、キャリア決済とは、スマートフォン３の利用料金と合わせて、スマートフォン３の通信事業者（すなわち、通信キャリア）によって決済が行われる方法である。また、自社サービスサーバ１は、実施事業者とは異なる他の事業者による決済代行サービスを用いて決済を行ってもよい。上記の他、自社サービスサーバ１は、カード決済や、銀行振り込みによる決済を行ってもよい。本実施形態においては、上記の複数の決済方法のうちのいくつかのうちからユーザが決済方法を選択する。

課金ページにおいて決済方法を選択する指示がユーザによって行われると、スマートフォン３は、ユーザが支払いを行う旨を示す支払指示情報をゲーム機アプリ提供サーバ３２へ送信する。この支払指示情報には、上記によって選択された決済方法を示す情報が含まれる。支払指示情報を受信すると、ゲーム機アプリ提供サーバ３２は、必要に応じて決済処理を実行する。決済処理は、課金の通知に応じてユーザによって支払われる料金を徴収する処理を指す。例えば、上記のポイントを用いて決済が行われる場合、ゲーム機アプリ提供サーバ３２は、上記購入要求の情報に含まれる自社アカウントＩＤに関連付けて記憶されるポイントから、ゲーム機アプリの料金に応じた数のポイントを減算する。また、料金の徴収が実施事業者以外の他の事業者によって行われる決済方法の場合（例えば、上述のキャリア決済や決済代行サービスによる決済方法の場合）、ゲーム機アプリ提供サーバ３２は、料金の徴収を依頼する通知を、徴収を行う他の事業者のサーバへ通知し、徴収が完了した場合に徴収完了の通知を当該他の事業者のサーバから受信する。

ゲーム機アプリ提供サーバ３２は、支払指示情報を受信すると、課金および決済に関する指示を受け付けた旨の通知をスマートフォン３へ送信する。この通知を受信すると、スマートフォン３は、処理の実行を一時停止していたスマートフォンアプリを再開する（図１１に示すステップＳ６１）。具体的には、スマートフォン３は、課金ページの表示を停止し（例えば、課金ページを表示するためのブラウザアプリを終了し）、スマートフォンアプリによるゲーム画像を表示部１５に表示する。そして、スマートフォン３は、ゲーム処理に対する入力の受付を再開する。なお、再開時に表示される上記ゲーム画像は、スマートフォンアプリが一時停止された時点で表示されていたゲーム画像であってもよい。このように、表示部１５に表示される画像は、ブラウザアプリによる課金ページから、スマートフォンアプリによるゲーム画像へと切り替わる。以上のようにして、スマートフォン３において、スマートフォンアプリ（換言すれば、スマートフォンアプリによるゲーム）が再開される。

なお、ユーザによって購入指示が行われた時点（ステップＳ５８の時点）で自社アカウントに対するログインがまだ行われていない場合には、ゲーム機アプリ提供サーバ３２は、スマートフォン３（換言すれば、スマートフォン３のユーザ）に対してログインを要求し、ログインが行われたことを条件として課金処理（および、必要に応じて決済処理）を実行するようにしてもよい。

また、上記購入要求の情報を受信した場合、ゲーム機アプリ提供サーバ３２は、管理サーバ３１へ購入通知の情報を送信する。この購入通知の情報は、購入要求の情報に含まれている自社アカウントＩＤの情報を含む。また、本実施形態においては、購入通知の情報には、購入内容を示す情報が含まれる。

ゲーム機アプリ提供サーバ３２から購入通知の情報を受信すると、管理サーバ３１は、購入されたゲーム機アプリの送信先となるゲーム機を特定する（図１１に示すステップＳ６０）。管理サーバ３１は、購入通知の情報に含まれる自社アカウントＩＤの情報に基づいて、購入を行ったユーザに対応する自社アカウントを特定し、特定された自社アカウントに関連付けられるゲーム機を、送信先のゲーム機として特定する。

具体的には、送信先のゲーム機の特定は、ゲーム機アプリ提供サーバ３２から受信した自社アカウントＩＤの情報と、管理サーバ３１に記憶されているユーザ管理情報とに基づいて行われる。図６に示すように、ユーザ管理情報においては、自社アカウントＩＤと、ゲーム機ＩＤとが関連付けられて記憶されている。管理サーバ３１は、ゲーム機アプリ提供サーバ３２から受信した自社アカウントＩＤの情報に関連付けられるゲーム機ＩＤが示すゲーム機を、送信先のゲーム機として特定する。管理サーバ３１は、特定した送信先のゲーム機を示す情報（本実施形態においては、ゲーム機ＩＤの情報）をゲーム機アプリ提供サーバ３２へ送信する。

また、本実施形態においては、管理サーバ３１は、購入通知の情報に含まれる購入内容を示す情報に基づいて、自身に記憶されるポイント情報を更新する（詳細は、後述の“（３−６）スマートフォンアプリの提供サービスの利用に応じて自社サービスサーバ１においてポイントを管理する処理”にて述べる）。

ゲーム機アプリ提供サーバ３２は、送信先ゲーム機ＩＤの情報を管理サーバ３１から受信した後で、当該送信先ゲーム機ＩＤが示すゲーム機４へ、購入要求に係るゲーム機アプリのデータを送信する。なお、上記ゲーム機アプリのデータの送信は、当該ゲーム機アプリの料金の決済（換言すれば、支払い）が完了したことが確認されたことを条件として実行されてもよい。

また、１つの自社アカウントに対して複数のゲーム機が関連付けられている（すなわち、ユーザ管理情報において、１つの自社アカウントＩＤに対して複数の送信先ゲーム機ＩＤが関連付けられている）場合もあり得る。この場合、管理サーバ３１は、複数のゲーム機のうち、ゲーム機アプリの送信先となるゲーム機を選択し、選択したゲーム機の送信先ゲーム機ＩＤの情報をゲーム機アプリ提供サーバ３２へ送信してもよい。なお、選択方法は任意であるが、例えば、管理サーバ３１は、ユーザによる指示に従って１つのゲーム機を選択してもよいし、自社アカウントに登録された時期に基づいてゲーム機を選択してもよい（例えば、最後に登録されたゲーム機を選択するようにしてもよい）。

また、１つの自社アカウントに対して関連付けられる複数のゲーム機は、互いに異なる種類（例えば、プラットホームが異なる）のゲーム機であってもよい。例えば、１つの自社アカウントに対して、据置型のゲーム機と、携帯型のゲーム機とが関連付けられていてもよい。このとき、管理サーバ３１は、ゲーム機アプリの送信先となるゲーム機として、当該ゲーム機アプリに対応するゲーム機（すなわち、当該ゲーム機アプリを実行可能なゲーム機）を選択してもよい。これによれば、管理サーバ３１は、ゲーム機アプリの送信先となるゲーム機を適切に選択することができる。例えば、管理サーバ３１は、ゲーム機アプリのアプリＩＤと、ゲーム機の種類を示す情報とを関連付けた情報を記憶しておき、当該情報に基づいて、ゲーム機アプリの送信先となるゲーム機を選択するようにしてもよい。

送信先のゲーム機を示す情報を管理サーバ３１から受信すると、ゲーム機アプリ提供サーバ３２は、当該送信先のゲーム機へゲーム機アプリを送信する（図１０に示す（４）、図１１に示すステップＳ６２）。本実施形態においては、ゲーム機アプリ提供サーバ３２は、ゲーム機アプリをプッシュ送信でゲーム機４へ送信する。本明細書において、プッシュ送信とは、実際にプッシュで情報を送信する通信方法だけでなく、ユーザから見て見かけ上プッシュで情報が送信されているように見える通信方法を含む意味である。すなわち、本明細書において、プッシュ送信（「プッシュ配信」とも言う。ただし、本明細書において、「プッシュ配信」とは、複数の装置へ情報を送信する態様だけでなく、１つの装置へ情報を送信する態様をも指す意味である。）とは、情報（ここではゲーム機アプリ）を送信する旨のユーザ指示の有無にかかわらず自動的に、当該情報を送信先へ送信する通信方法を指す。したがって、本明細書では、ゲーム機アプリ提供サーバ３２がゲーム機４からの要求がなくても当該ゲーム機４へゲーム機アプリを送信する態様の他、上記のユーザ指示の有無にかかわらずゲーム機４がゲーム機アプリ提供サーバ３２へ要求を送信し、当該要求に応じてゲーム機アプリ提供サーバ３２がゲーム機アプリをゲーム機４へ送信する態様も、「プッシュ送信」と呼ぶ。

本実施形態では、ゲーム機４は、ゲーム機アプリ提供サーバ３２（および管理サーバ３１）に対して、所定のタイミングで、情報を送信する旨の要求を示す情報を自動的に（換言すれば、ユーザの指示の有無にかかわらず）行う。所定のタイミングとは、具体的には、（ａ）ゲーム機４が起動されたタイミング、（ｂ）ゲーム機４においてアプリケーションが起動されたタイミング、（ｃ）ゲーム機４においてアプリケーションの実行が終了されたタイミング、（ｄ）ゲーム機４においてネットワークを介した通信が可能となったタイミング、および、（ｅ）所定時間に１回の割合で到来するタイミングである。上記のようなタイミングで、ゲーム機４は、ユーザの指示がなくても、上記の要求を示す情報をゲーム機アプリ提供サーバ３２へ送信する。なお、他の実施形態においては、ゲーム機４は、上記（ａ）〜（ｅ）のうちいくつかのタイミングで上記要求の情報を送信してもよい。

上記の要求をゲーム機４から受信すると、ゲーム機アプリ提供サーバ３２は、送信すべきゲーム機アプリがある場合には、当該ゲーム機アプリのデータをゲーム機４へ送信する。ゲーム機４は、ゲーム機アプリ提供サーバ３２から送信されるゲーム機アプリのデータを受信し、ゲーム機アプリをインストールする。これによって、ゲーム機４においてゲーム機アプリの利用が可能となる。なお、他の実施形態においては、ゲーム機アプリ提供サーバ３２は、ゲーム機４からの上記要求によらないタイミングで送信してもよい。

なお、ゲーム機４は、ゲーム機アプリが取得される旨の通知を、適宜のタイミングでユーザに対して行うようにしてもよい。図１４は、ゲーム機４に表示される画像の一例を示す図である。ゲーム機アプリがインストールされた後において、ゲーム機４の表示部２８には、メニュー画像４５が表示される。メニュー画像４５は、アイコン画像４６と、メッセージ画像４７とを含む。アイコン画像４６は、新たにインストールされたゲーム機アプリを示すアイコンの画像である。このアイコンを指定する指示が行われたことに応じて、ゲーム機４は、アイコンが示すアプリケーションを起動する。図１４に示すように、新たにインストールされたゲーム機アプリを示すアイコン画像４６は、他のアイコン画像とは異なる表示態様で表示される。これによって、ゲーム機４は、新しいアプリケーションが追加されたことをユーザに通知することができる。また、メッセージ画像４７は、アプリケーションが追加されたことを示すメッセージを表す。これによっても、ゲーム機４は、新しいアプリケーションが追加されたことをユーザに通知することができる。

また、ゲーム機４は、ゲーム機アプリが取得される前において、ゲーム機アプリを取得可能である旨の通知をユーザに対して行うようにしてもよい。例えば、ゲーム機アプリ提供サーバ３２は、まず、ゲーム機アプリを送信可能である旨の通知をプッシュ送信でゲーム機４へ送信する。この通知に応じて、ゲーム機４は、ゲーム機アプリを取得可能である旨の通知をユーザに対して行う。ゲーム機４による上記通知は、上記の所定のタイミングにおいて行われてもよいし、上記所定のタイミングとは異なるタイミングにおいて行われてもよい。

上記の通知を行った後、ゲーム機４は、ゲーム機アプリを取得する旨の指示をユーザから受け付けるようにしてもよい。そして、ゲーム機４は、ユーザから指示があったことに応じて（換言すれば、指示があったことを条件として）ゲーム機アプリを取得（およびインストール）するようにしてもよい。このように、ゲーム機アプリ提供サーバ３２は、上記の通知をプッシュ送信でゲーム機４へ送信し、その後、ユーザによる取得指示があったことを条件としてゲーム機アプリをゲーム機４へ送信するようにしてもよい。

（上記処理による作用効果）
以上のように、本実施形態においては、自社サービスサーバ１は、第１の種類のプラットホームを有する第１の情報処理装置（すなわち、ゲーム機４）と互換性を有し、かつ、第１の種類とは異なる第２の種類のプラットホームを有する第２の情報処理装置（すなわち、スマートフォン３）と互換性を有しないアプリケーション（すなわち、ゲーム機アプリ）を記憶する。自社サービスサーバ１は、ゲーム機アプリに関する提示情報（本実施形態においては、広告情報）をスマートフォン３へ送信する（図１１に示すステップＳ５１）。自社サービスサーバ１は、スマートフォン３において提示された提示情報に対応するアプリケーションの取得に関する指示を示す指示情報（本実施形態においては、上述の購入要求の情報、または、支払指示情報）を、当該スマートフォン３から受信する（図１１に示すステップＳ５９）。また、自社サービスサーバ１は、受信された指示情報に関するアプリケーションを受信すべきゲーム機４を特定する（図１１に示すステップＳ６０）。自社サービスサーバ１は、スマートフォン３から受信される指示情報（本実施形態においては、上述の購入要求の情報、または、支払指示情報）に応じて、提示情報が示すアプリケーションを、特定されたゲーム機４へ送信する（図１１に示すステップＳ６２）。

従来、サーバから端末側の情報処理装置へアプリケーションを提供し、提供されたアプリケーションを端末側の情報処理装置によって利用する情報処理システムにおいては、ユーザによるアプリケーションの取得の機会を拡大することが望まれている。これに関して、上記実施形態によれば、ユーザは、ゲーム機アプリを、スマートフォン３を用いて取得することができる。つまり、本実施形態によれば、実施事業者は、自社サービスサーバ１の機能によって、スマートフォンアプリを利用するユーザに対して、ゲーム機アプリをＰＲすることができる。また、本実施形態によれば、スマートフォンアプリを利用するユーザに対してゲーム機アプリを購入および／または利用する動機付けを与えることができ、スマートフォンアプリをきっかけとしてゲーム機アプリの利用を促進することができる。このように、本実施形態によれば、ユーザは、あるアプリケーションについて互換性を有しないプラットホームを有する情報処理装置を用いて当該アプリケーションを取得できるので、当該アプリケーションの取得の機会を拡大することができる。

なお、ゲーム機アプリを送信するゲーム機を特定する処理（上記ステップＳ６０）は、端末側において（すなわち、スマートフォン３において）実行されてもよい。例えば、スマートフォン３は、自身と対応付けられるゲーム機のゲーム機ＩＤを記憶部２５に記憶しておき、上記ステップＳ５８の処理において、当該ゲーム機ＩＤを含む購入要求の情報を送信するようにしてもよい。

また、本実施形態においては、相対的に汎用性の高い（換言すれば、所持しているユーザが相対的に多い）情報処理装置であるスマートデバイス（すなわち、スマートフォン３）によって、相対的に汎用性の低い（換言すれば、所持しているユーザが相対的に少ない）情報処理装置であるゲーム機４のゲーム機アプリの取得を促すことができる。つまり、本実施形態によれば、スマートフォン３を利用するユーザをゲーム機４のユーザへと引き込むことができ、アプリケーションの利用に関して、スマートフォン３からゲーム機４への橋渡しを行うことができる。

上記「提示情報」は、アプリケーションに関する任意の情報でよい。本実施形態においては、上記提示情報は広告情報であるが、他の実施形態においては、提示情報は、広告の態様に限らず、アプリケーションに関する情報をユーザに提示することができる他の態様の情報であってもよい。

また、本実施形態においては、自社サービスサーバ１は、スマートフォン３と互換性を有し、ゲーム機４と互換性を有しないアプリケーション（すなわち、スマートフォンアプリ）を実行中であるスマートフォン３へ提示情報を送信する（図１１に示すステップＳ５２）。これによれば、スマートフォン３においてユーザがスマートフォンアプリを実行することで提示情報が提示されるので、提示情報をユーザに対して自然に（換言すれば、大きな違和感を与えることなく）提示することができる。また、ユーザがスマートフォン３を使用するタイミングで提示情報を送信することができるので、効果的に提示情報を提供することができる。そのため、（ユーザが提示情報を見ないために）提示情報を無駄に送信してしまう可能性を低減することができ、自社サービスサーバ１とスマートフォン３との間の通信を効率良く行うことができる。

本実施形態においては、自社サービスサーバ１は、スマートフォンアプリに関連するゲーム機アプリ（例えば、スマートフォンアプリと同じシリーズのゲームアプリケーション）に関する提示情報をスマートフォン３へ送信する。また、詳細は後述するが、本実施形態においては、ゲーム機アプリは、スマートフォンアプリによって生成されるセーブデータの少なくとも一部のデータを利用することが可能なアプリケーションであってもよい（後述の“（３−５）スマートフォンアプリとゲーム機アプリでセーブデータを共有する処理”参照）。上記によれば、ユーザが利用中のアプリケーションに関連するアプリケーションについての提示情報を提示することができるので、ユーザが興味を引きやすい提示情報を提示することができる。これによって、提示情報の広告効果を向上することができる。

本実施形態においては、自社サービスサーバ１は、スマートフォンに関する識別情報（本実施形態においては、自社アカウントＩＤ）と、ゲーム機に関する識別情報（本実施形態においては、送信先ゲーム機ＩＤ）との関連付けを示す関連付け情報（すなわち、図１１に示すユーザ管理情報）を記憶している。自社サービスサーバ１は、関連付け情報に基づいてゲーム機を特定する。上記によれば、関連付け情報によって、ゲーム機アプリの送信先となるゲーム機４を容易に特定することができる。

上記「スマートフォンに関する識別情報」は、例えば、スマートフォンから送信される識別情報（例えば、上記自社アカウントＩＤや、スマートフォンに固有の識別情報）であってもよいし、スマートフォンと関連付けられる識別情報（例えば、上記自社アカウントＩＤや、スマートフォンのメールアドレス）であってもよいし、スマートフォンのユーザを表す識別情報（例えば、上記自社アカウントＩＤや、スマートフォンのユーザに設定されたアカウント名）であってもよい。

本実施形態においては、自社サービスサーバ１は、スマートフォン３におけるスマートフォンアプリの実行開始時および／または実行中において、スマートフォン３のユーザに関するユーザ識別情報（本実施形態においては、自社アカウントＩＤ）を当該スマートフォン３から受信する（図１１に示すステップＳ５１またはＳ５２）。自社サービスサーバ１は、スマートフォン３に関する識別情報として、上記ユーザ識別情報（すなわち、自社アカウントＩＤ）を記憶する。自社サービスサーバ１は、スマートフォン３におけるスマートフォンアプリの実行開始時および／または実行中において自社サービスサーバ１へ送信されたユーザ識別情報と関連付け情報とに基づいてゲーム機４を特定する。

上記によれば、スマートフォンアプリの実行時に自社サービスサーバ１へ送信される識別情報を用いて、ゲーム機アプリの送信先となるゲーム機を特定することができる。これによれば、自社サービスサーバ１は、スマートフォン３から取得される情報を用いて送信先のゲーム機を特定することができるので、特定処理を効率良く実行することができる。

本実施形態においては、自社サービスサーバ１は、ゲーム機に関する識別情報として、ゲーム機に固有の識別情報（本実施形態においては、送信先ゲーム機ＩＤ）を記憶する。これによれば、送信先となるゲーム機を確実に特定することができる。

本実施形態においては、自社サービスサーバ１は、上記ユーザ識別情報（すなわち、自社アカウントＩＤ）に関連付けて、当該ユーザ識別情報に対応するユーザに関するユーザ情報（本実施形態においては、ユーザ関連情報）を記憶している。自社サービスサーバ１は、スマートフォン３へ送信すべき提示情報の内容を、当該スマートフォン３から受信したユーザ識別情報に関連付けられるユーザ情報に基づいて決定する。これによれば、自社サービスサーバ１は、スマートフォンのユーザに応じて提示情報の内容を変化させることができるので、ユーザに適した内容の提示情報を提示することができる。

本実施形態においては、自社サービスサーバ１は、ゲーム機アプリを自社サービスサーバ１からゲーム機４へ送信する旨のユーザ指示の有無にかかわらず自動的に、当該ゲーム機アプリをゲーム機４へ送信する（図１１に示すステップＳ６２）。これによれば、ユーザは、ゲーム機アプリを取得するための操作をゲーム機４において行う必要がないので、ゲーム機アプリを取得する際の利便性を向上することができる。

なお、上記「ユーザ指示の有無にかかわらず自動的に（情報を送信する）」とは、次のような態様を含む意味である。
（１）ゲーム機４からの要求なしに、自社サービスサーバ１から情報を送信する態様
（２）ユーザによる指示なしにゲーム機４が情報の送信を要求し、当該要求に応じて自社サービスサーバ１から情報を送信する態様
なお、上記（１）または（２）の態様には、サーバから端末（ここでは、ゲーム機４）への情報の送信に関する設定をユーザが行うことができる場合において、ユーザが、上記（１）あるいは（２）の態様となるように設定を行った場合が含まれる。

また、他の実施形態においては、自社サービスサーバ１は、ゲーム機アプリを自社サービスサーバ１からゲーム機４へ送信する旨のユーザ指示の有無にかかわらず自動的に、当該ゲーム機アプリを送信可能である旨の通知をゲーム機４へ送信してもよい。これによれば、取得可能なゲームアプリがあることをユーザに通知することができる。また、ユーザは、通知を受信するための操作をゲーム機４において行う必要がないので、ゲーム機アプリの利便性を向上することができる。

本実施形態においては、自社サービスサーバ１は、スマートフォン３から指示情報を受信した後において、ゲーム機アプリの取得に関する所定の条件（本実施形態においては、ゲーム機アプリの料金の決済が完了したこと）が満たされたことに応じて、ゲーム機４へのゲーム機アプリの送信、および／または、ゲーム機４へのゲーム機アプリに関する通知（例えば、ゲーム機アプリを取得可能である旨の通知）の送信を試みる。これによれば、例えばゲーム機アプリの決済が完了した後で、当該ゲーム機アプリを送信することができる。そのため、例えば、支払等の手続が完了していない状態でゲーム機アプリがゲーム機４にダウンロードされる可能性を低減することができる。

本実施形態においては、スマートフォン３は、自社サービスサーバ１から受信した提示情報に基づく画像を表示し（図１１に示すステップＳ５４、図１２）、当該画像が表示された後で入力可能となる所定の入力指示が行われたことに応じて指示情報を自社サービスサーバ１へ送信する（図１１に示すステップＳ５８）。

上記によれば、提示情報に基づく画像が表示された後で入力指示が可能となるので、ユーザが誤って入力指示を行ってしまう可能性を低減することができる。

本実施形態においては、スマートフォン３は、自社サービスサーバ１から受信した提示情報に基づく画像を表示部１５に表示した後、上記所定の入力指示を行うための受付画像（本実施形態においては、図１３に示す購入ページおよび課金ページ）を表示部１５に表示する（図１１に示すステップＳ５７）。上記所定の入力指示が行われた後で、スマートフォン３は、表示部１５における受付画像の表示を終了し、スマートフォンアプリによって生成される画像（ここでは、ゲーム画像）を表示する。例えば、スマートフォン３は、受付画像である課金ページの画像から、スマートフォンアプリによって生成されるゲーム画像へと、表示部１５の表示を切り替えてもよいし、当該ゲーム画像の上に重ねて表示されていた課金ページの画像を消去することによってゲーム画像を上に表示するようにしてもよい。

上記によれば、ゲーム機アプリを取得するための入力指示の後、スマートフォンアプリの画像が表示されるので、ユーザは、容易にスマートフォンアプリの利用を再開することができる。これによって、スマートフォンアプリの利便性を向上することができる。

（上記処理の変形例）
なお、本実施形態においては、自社サービスサーバ１は、スマートフォン３からの要求（具体的には、ログイン要求）に応じて広告情報をスマートフォン３へ送信した。ここで、他の実施形態においては、自社サービスサーバ１は、プッシュ送信で広告情報をゲーム機４へ送信してもよい。すなわち、自社サービスサーバ１は、自社サービスサーバ１からスマートフォン３へ広告情報を送信する旨のユーザ指示の有無にかかわらず自動的に、当該広告情報をスマートフォン３へ送信してもよい。これによれば、自社サービスサーバ１は、広告情報をより多くの機会にスマートフォン３へ送信することができる。

例えば、自社サービスサーバ１は、スマートフォン３においてスマートフォンアプリが実行されていない場合に広告情報を送信してもよい。このとき、スマートフォン３においては、広告情報に基づく広告画像をスマートフォンアプリ外で（すなわち、スマートフォンアプリを実行せずに）表示部１５に表示するようにしてもよい。例えば、スマートフォン３は、アプリケーションを起動する指示を受け付けるメニュー画面（および／または待ち受け画面）において広告画像を表示するようにしてもよい。また、例えば、自社サービスサーバ１は、電子メールを用いて広告情報をスマートフォン３へ送信してもよく、スマートフォン３は、メーラーのアプリケーションにおいて広告画像を表示してもよい。また、他の実施形態においては、スマートフォン３は、スマートフォンアプリが実行されていない期間に受信した広告情報に基づく広告画像を、スマートフォンアプリの実行中に（換言すれば、スマートフォンアプリ内で）表示するようにしてもよい。

また、他の実施形態においては、ゲーム機アプリの購入操作をユーザがスマートフォンアプリ内で行うことができるようにしてもよい。すなわち、スマートフォンアプリは、ゲーム機アプリの購入指示を受け付けてゲーム機アプリ提供サーバ３２へ購入要求を行う機能を有していてもよい。また、スマートフォンアプリは、ゲーム機アプリ提供サーバ３２からの課金の通知に対して決済の指示（換言すれば、上述した、決済方法を選択する指示）を受け付けてゲーム機アプリ提供サーバ３２へ決済に関する通知（すなわち、上記支払指示情報）を行う機能を有していてもよい。これによれば、スマートフォン３は、スマートフォンアプリを実行することで（すなわち、ブラウザを起動する必要なく）ゲーム機アプリの購入を行うことができる。

（３−５）スマートフォンアプリとゲーム機アプリでセーブデータを共有する処理
次に、図１５〜図１７を参照して、スマートフォンアプリとゲーム機アプリとでセーブデータを共有する処理例について説明する。本実施形態においては、所定のスマートフォンアプリとゲーム機アプリとの組み合わせについて、セーブデータ（の一部）が共有される。例えば、あるゲームアプリケーションのスマートフォンアプリと、そのゲームアプリケーションと一部のゲームステージを共有するゲームアプリケーションのゲーム機アプリとの間で、当該ゲームステージに関するゲーム内容を表すセーブデータが共有される。これによれば、スマートフォンアプリのセーブデータをゲーム機アプリにおいて利用することができ、また、ゲーム機用ゲームのセーブデータをスマートフォンアプリにおいて利用することができる。そのため、スマートフォンアプリとゲーム機アプリとのいずれか一方を利用するユーザに対して、他方のアプリを利用する動機付けを与えることができる。以下、セーブデータを共有する処理について詳細を説明する。

図１５は、セーブデータを共有する処理の概要の一例を示す図である。また、図１６は、セーブデータサーバが記憶するデータの一例を示す図である。本実施形態において、図１５および図１６に示すように、セーブデータサーバ３３は、スマートフォン用セーブファイルと、ゲーム機用セーブファイルとを関連付けて自身の記憶部に記憶する。スマートフォン用セーブファイルは、スマートフォンアプリで利用されるセーブデータを含むデータファイルである。ゲーム機用セーブファイルは、ゲーム機アプリで利用されるセーブデータを含むデータファイルである。図１６に示すように、これらのセーブファイルは、セーブファイルに対応するアプリケーション（スマートフォンアプリまたはゲーム機アプリ）毎に、かつ、ユーザ毎に（換言すれば、自社アカウント毎に）記憶される。

図１５に示すように、スマートフォン用セーブファイルは、スマートフォン用セーブデータと、共通セーブデータとを含む。また、ゲーム機用セーブファイルは、ゲーム機用セーブデータと、共通セーブデータとを含む。スマートフォン用セーブデータは、スマートフォンアプリにおいて利用されるセーブデータである。ゲーム機用セーブデータは、ゲーム機アプリにおいて利用されるセーブデータである。また、共通セーブデータは、スマートフォンアプリとゲーム機アプリとの両方で利用されるセーブデータである。

本実施形態においては、図１５に示すように、各セーブファイルに含まれる各共通セーブデータについて、セーブデータサーバ３３は同期をとる。すなわち、各共通セーブデータは、内容が一致するように管理される。なお、スマートフォン用セーブファイルに含まれる共通セーブデータと、ゲーム機用セーブファイルに含まれる共通セーブデータとは、データの内容は同じで、データの形式が異なっていてもよい。すなわち、これら２つの共通セーブデータは、互いに同じ内容を表すデータである一方、スマートフォン用セーブファイルに含まれる共通セーブデータは、スマートフォン３（換言すればスマートフォンアプリ）において読み取り可能なデータ形式であり、ゲーム機用セーブファイルに含まれる共通セーブデータは、ゲーム機４（換言すればゲーム機アプリ）において読み取り可能なデータ形式であってもよい。

また、他の実施形態においては、スマートフォン用セーブファイルに含まれる共通セーブデータと、ゲーム機用セーブファイルに含まれる共通セーブデータとは、データの内容が完全に一致していなくてもよく、その一部についてデータ内容が異なっていてもよい。例えば、スマートフォン用セーブファイルに含まれる共通セーブデータの一部が、スマートフォンアプリのゲームに登場するキャラクタＡを表すのに対して、ゲーム機用セーブファイルに含まれる共通セーブデータの一部（スマートフォン用セーブファイルに含まれる共通セーブデータの一部に対応する部分）は、ゲーム機アプリのゲームに登場する他のキャラクタＢを表してもよい。

上記のように、本実施形態においては、セーブデータサーバ３３は、スマートフォンアプリに利用される共通セーブデータと、ゲーム機アプリに利用される共通セーブデータとを別のデータとして記憶する（図１５参照）。ただし、他の実施形態においては、セーブデータサーバ３３は、スマートフォンアプリに利用される共通セーブデータと、ゲーム機アプリに利用される共通セーブデータとして、単一のデータを記憶してもよい。

図１６に示すように、セーブデータサーバ３３は、ユーザセーブ情報を、自社アカウント毎（換言すれば、ユーザ毎）に記憶する。ユーザセーブ情報は、自社アカウントＩＤの情報と、アプリセーブ情報とを含む。なお、他の実施形態においては、ユーザセーブ情報は、自社アカウントＩＤに代えて、自社アカウントを特定可能な、および／または、セーブファイルを利用する装置（スマートフォン３またはゲーム機４）を特定可能な、任意の情報を含んでいてもよい。例えば、ユーザセーブ情報は、自社アカウントＩＤに代えて（またはともに）、スマートフォンＩＤの情報とゲーム機ＩＤの情報とを含んでいてもよい。

アプリセーブ情報は、スマートフォンアプリを識別するためのアプリＩＤ（「スマートフォンアプリＩＤ」と呼ぶ）と、ゲーム機アプリを識別するためのアプリＩＤ（「ゲーム機アプリＩＤ」と呼ぶ）とを含む。アプリセーブ情報において関連付けられるスマートフォンアプリＩＤおよびゲーム機アプリＩＤは、互いに関連付けられるアプリケーションの組、換言すれば、同じ内容の共通セーブデータが記憶されるアプリケーションの組である。また、アプリセーブ情報は、スマートフォンアプリＩＤが示すスマートフォンアプリに利用されるスマートフォン用セーブファイルと、ゲーム機アプリＩＤが示すゲーム機アプリに利用されるゲーム機用セーブファイルとを含む。なお、図１６に示すように、アプリセーブ情報は、上記のスマートフォンアプリとゲーム機アプリの組毎に作成されてセーブデータサーバに記憶される。

ここで、スマートフォンアプリと、それに関連付けられるゲーム機アプリとは、ゲーム内容の少なくとも一部が共通する。例えば、スマートフォンアプリのゲームとゲーム機アプリのゲームとでは、共通するゲーム空間（あるいは、ゲームステージ）が存在してもよい。このとき、共通セーブデータは、共通するゲーム空間に関するゲーム内容（具体的には、ゲーム空間を構築するためのデータ）を表すものであってもよい。また例えば、スマートフォンアプリのゲームとゲーム機アプリのゲームとでは、共通するキャラクタが登場してもよい。このとき、共通セーブデータは、共通するキャラクタに関するゲーム内容（具体的には、キャラクタのパラメータ）を表すものであってもよい。

なお、ある自社アカウントのユーザが、組となるスマートフォンアプリとゲーム機アプリとのうち一方のみを利用可能である場合（すなわち、スマートフォン３にスマートフォンアプリがインストールされていないか、あるいは、ゲーム機４にゲーム機アプリがインストールされていない場合）には、アプリセーブ情報は、当該ユーザが利用可能なアプリケーションに関するＩＤとセーブファイルとのみを含んでいてもよい。

また、上記の場合、自社サービスサーバ１は、組となるスマートフォンアプリとゲーム機アプリとのうち一方のみを利用可能なユーザに対しては、セーブファイルのうちの共通セーブデータの利用を制限（例えば、禁止）してもよい。そして、自社サービスサーバ１は、組となるスマートフォンアプリとゲーム機アプリとの両方をユーザが利用可能となったことに応じて、共通セーブデータの利用を許可するようにしてもよい。これによれば、組となるスマートフォンアプリとゲーム機アプリとのうち一方のみを所有するユーザに対して、他方のアプリケーションを取得（例えば購入）する動機付けを与えることができる。

図１７は、スマートフォンアプリとゲーム機アプリとでセーブデータを共有する処理の流れの一例を示す図である。図１７においては、まずスマートフォン３におけるスマートフォンアプリの利用に応じて、セーブデータサーバに記憶されるセーブデータが更新され、その後、ゲーム機４におけるゲーム機アプリにおいて、更新されたセーブデータを用いる場合における処理の流れを説明する。

まず、スマートフォン３は、ユーザによる起動指示に応じて、スマートフォンアプリを起動（すなわち、実行開始）し、ログインを行う（ステップＳ７１）。これに応じて、自社サービスサーバ１は、ログイン処理を行い、ログインが承認された場合、ゲームデータをスマートフォン３へ送信する（ステップＳ７２）。そして、スマートフォン３は、受信したゲームデータを用いてゲーム処理を開始する。なお、上記の一連の処理は、上記“（３−２）スマートフォンにおける基本的な処理”で述べたステップＳ１１〜Ｓ１６の処理と同様である。

また、上述したように、スマートフォンアプリを起動したことに応じて、管理サーバ３１において、スマートフォン３においてスマートフォンアプリが実行中であることが管理される。

また、本処理例において、ログインに応じてゲームサーバ３４からスマートフォン３へ送信されるゲームデータには、スマートフォン用セーブファイル（またはその一部）が含まれていてもよい。このとき、ゲームサーバ３４は、セーブデータサーバ３３から、ログイン要求があった自社アカウントに関するスマートフォン用セーブファイルをセーブデータサーバ３３から取得する。具体的には、ゲームサーバ３４は、セーブデータの取得要求の情報をセーブデータサーバ３３へ送信する。この情報は、スマートフォン３からのログイン要求の情報に含まれる自社アカウントＩＤとスマートフォンアプリＩＤとを含む。セーブデータサーバ３３は、上記情報に含まれる自社アカウントＩＤに関連付けられるアプリセーブ情報であって、上記情報に含まれるスマートフォンアプリＩＤに対応するアプリセーブ情報を特定し、特定されたアプリセーブ情報に含まれるスマートフォン用セーブファイルをゲームサーバ３４へ送信する。ゲームサーバ３４は、セーブデータサーバ３３から受信したスマートフォン用セーブファイル（またはその一部）を含むゲームデータをスマートフォン３へ送信する。

なお、ログインを行っていない場合（ログインが承認されなかった場合を含む）も上記と同様に、スマートフォン３は、自社アカウントＩＤおよびスマートフォンアプリＩＤをゲームサーバ３４へ送信する。これによって、ゲームサーバ３４は、上記と同様の処理によって、スマートフォン３へスマートフォン用セーブファイルを送信することができる。

ゲームサーバ３４からゲームデータを受信すると、スマートフォン３は、スマートフォンアプリの実行（換言すれば、スマートフォンアプリによるゲーム処理）を開始する。図１７では図示していないが、図７に示すステップＳ１７の処理として説明したように、スマートフォンアプリの実行中においては、スマートフォン３とゲームサーバ３４との間でゲームデータの送受信が行われる。

ここで、スマートフォン３は、スマートフォンアプリの実行中において、適宜のタイミングでゲームサーバ３４へゲームデータを送信する（ステップＳ７３）。例えば、スマートフォン３は、１回のゲームが終了したタイミング、１つのステージをクリアしたタイミング、ゲームデータをセーブする指示がユーザによって行われたタイミング、および、課金の対象となる処理（例えば、ゲーム内に登場するアイテムを購入したり、追加のゲームステージを購入したりする処理）が実行されたタイミング等にゲームデータを送信する。なお、スマートフォン３が１回に送信するゲームデータは、セーブデータサーバ３３に記憶されているスマートフォン用セーブファイルの全体でなくてもよい。なお、スマートフォン３は、ゲームデータとともに、ログインに用いた自社アカウントＩＤと、当該ゲームデータに対応するスマートフォンアプリＩＤとをゲームサーバ３４へ送信する。

ゲームサーバ３４は、スマートフォン３からゲームデータを受信すると、必要に応じてスマートフォン用セーブファイルを更新する（ステップＳ７４）。具体的には、スマートフォン３から受信したゲームデータに基づいて、セーブデータサーバ３３に記憶されているスマートフォン用セーブファイルを更新する。ゲームサーバ３４は、上記ゲームデータに基づいて新たに保存（換言すれば、記憶）すべきスマートフォン用セーブファイルを生成し、生成したスマートフォン用セーブファイルをセーブデータサーバ３３へ送信してもよい。なお、ゲームサーバ３４は、スマートフォン３からゲームデータとともに受信される自社アカウントＩＤおよびスマートフォンアプリＩＤをセーブデータサーバ３３へ送信することによって、更新すべきスマートフォン用セーブファイルを指定する。セーブデータサーバ３３は、指定されたスマートフォン用セーブファイル（すなわち、自社アカウントＩＤに関連付けられ、かつ、スマートフォンアプリＩＤに関連付けられるアプリセーブ情報に含まれるスマートフォン用セーブファイル）について更新を行う。

また、スマートフォン用セーブファイルの更新タイミングは任意である。例えば、ゲームサーバ３４は、スマートフォン３から受信したゲームデータによって、スマートフォン用セーブファイルの内容に変更がある場合に、スマートフォン用セーブファイルの更新を行うようにしてもよい。また例えば、ゲームサーバ３４は、ゲームデータをセーブする指示がユーザによって行われたことに応じてゲームデータが送信された場合に、スマートフォン用セーブファイルの更新を行うようにしてもよい。

セーブデータサーバ３３は、スマートフォン用セーブファイルの共通セーブデータに変更があった場合、当該スマートフォン用セーブファイルに関連付けられるゲーム機用セーブファイルの共通セーブデータを同期させる（ステップＳ７５）。すなわち、ゲーム機用セーブファイルの共通セーブデータは、スマートフォン用セーブファイルの共通セーブデータと同じ内容に更新される。

なお、他の実施形態においては、セーブデータサーバ３３は、２つの共通セーブデータの内容を完全に一致させなくてもよい。すなわち、セーブデータサーバ３３は、スマートフォン用セーブファイルの共通セーブデータと、ゲーム機用セーブファイルの共通セーブデータとを、一方の共通セーブデータの変更を他方の共通セーブデータに反映するように共通セーブデータを更新してもよい。例えば、スマートフォンアプリではキャラクタＡが登場し、ゲーム機アプリではキャラクタＡに代えてキャラクタＢが登場する場合において、スマートフォン用セーブファイルに含まれる共通セーブデータがキャラクタＡに関するデータを含む場合、ゲーム機用セーブファイルに含まれる共通セーブデータにおいては、キャラクタＡに関するデータに代えて、キャラクタＢに関するデータが含まれてもよい。このとき、セーブデータサーバ３３は、キャラクタＡおよびキャラクタＢのうち一方に関するデータの変更に応じて、他方のデータを変更してもよい。例えば、キャラクタＡのレベルが上がった場合、それに応じてキャラクタＢのレベルを上げるようにキャラクタＢのデータが変更されてもよい。

以上のようにして、スマートフォン３におけるスマートフォンアプリの実行の結果、セーブデータサーバ３３に記憶されるスマートフォン用セーブファイルの共通セーブデータに変更があった場合には、当該スマートフォンアプリに対応するゲーム機アプリのゲーム機用セーブファイルの共通セーブデータも変更される。

また、図１７においては、スマートフォン３は、ユーザの指示に応じて、スマートフォンアプリを終了する（ステップＳ７６）。一方、自社サービスサーバ１側では、図７に示すステップＳ２０およびＳ２１の処理によってスマートフォン３のログアウトが判断されてログアウト処理が実行される（ステップＳ７７）。すなわち、ゲームサーバ３４は、上記ステップＳ２０の処理によってスマートフォン３がログアウトしたことを判断し、これに応じて、管理サーバ３１は、上記ステップＳ２１のログアウト処理を実行する。

一方、ゲーム機４は、ゲーム機４が起動されると、自社サービスに対して自社アカウントＩＤでログインする（ステップＳ７８）。これに応じて、管理サーバ３１は、ログイン処理を実行する（ステップＳ７９）。ステップＳ７８およびＳ７９の処理は、図９に示すステップＳ３１およびＳ３２の処理と同様である。

その後、ゲーム機４は、ユーザによる起動指示に応じて、ゲーム機アプリ（ここでは、上記スマートフォンアプリに対応するゲーム機アプリ、すなわち、セーブデータを共有するゲーム機アプリ）を起動する（ステップＳ８０）。ステップＳ８０の処理は、図９に示すステップＳ３３の処理と同様である。すなわち、図１７では図示しないが、ゲーム機４は、アプリ起動通知の情報を管理サーバ３１へ送信し、管理サーバ３１は、当該アプリ起動通知の情報に含まれるアプリＩＤに基づいてアプリ実行情報を更新する。これによって、管理サーバ３１において、ゲーム機４においてゲーム機アプリが実行中であることが管理される。

なお、本実施形態において、ゲーム機アプリの起動時に用いられるセーブデータは、ゲーム機４の記憶部２５（または、ゲーム機４に装着されたゲームカード）においても記憶されている（後述するステップＳ８３参照）。そのため、ゲーム機アプリの起動時においては、ゲーム機４は、セーブデータサーバ３３からセーブファイルを取得しないものとする。ただし、他の実施形態においては、スマートフォン３と同様、ゲーム機４は、ゲーム機アプリの起動時において、ユーザの指示の有無にかかわらず、セーブデータサーバ３３からセーブファイル（少なくとも、共通セーブデータ）を取得してもよい。また、他の実施形態においては、ゲーム機４は、ゲーム機アプリの実行中でない期間に、当該ゲーム機アプリのセーブファイル（少なくとも、共通セーブデータ）を取得するようにしてもよい。例えば、ゲーム機アプリの実行中でない期間に、ゲーム機４がネットワーク（換言すれば、セーブデータサーバ３３）と通信可能となった場合、ゲーム機４は、ゲーム機アプリのセーブファイルを取得する要求を示す情報をセーブデータサーバ３３へ送信してもよい。

ゲーム機アプリの実行中において、ゲーム機４は、セーブデータ利用処理を実行する（ステップＳ８１）。ここで、セーブデータ利用処理は、セーブデータサーバ３３に記憶される最新のセーブデータ（すなわち、ゲーム機用セーブファイル）を利用する処理である。例えば、セーブデータ利用処理は、ゲーム機用セーブファイルに含まれる共通セーブデータを利用するゲーム処理である。セーブデータ利用処理は、上述したサーバ通信処理（図９に示すステップＳ３６）の１つと言うことができる。

セーブデータ利用処理を実行する際、ゲーム機４は、まず、ゲーム機用セーブファイルの取得要求を示す情報をセーブデータサーバ３３へ送信する。この情報は、上記ステップＳ７８において行われたログインに用いられた自社アカウントＩＤと、実行中のゲーム機アプリのゲーム機アプリＩＤとを含む。なお、本実施形態においては、ゲーム機アプリの実行中において、ゲーム機４は、セーブデータサーバ３３と通信を行うが、ゲーム機４とセーブデータサーバ３３との通信は、ゲームサーバ３４を介して行われてもよいし、直接（つまり、ゲームサーバ３４を介さずに）行われてもよい。

取得要求の情報を受信したセーブデータサーバ３３は、送信すべきゲーム機用セーブファイルを当該情報に基づいて特定し、特定されたゲーム機用セーブファイルをゲーム機４へ送信する（ステップＳ８２）。具体的には、セーブデータサーバ３３は、取得要求の情報に含まれる自社アカウントＩＤに対応するユーザセーブ情報のうち、当該情報に含まれるゲーム機アプリＩＤに対応するアプリセーブ情報に含まれるゲーム機用セーブファイルをゲーム機４へ送信する。

セーブデータサーバ３３からゲーム機用セーブファイルを受信すると、ゲーム機４は、受信したゲーム機用セーブファイルを用いてセーブデータ利用処理を実行する。ここで、上記ステップＳ８２の処理において送信されるゲーム機用セーブファイルは、それに含まれる共通セーブデータが上記ステップＳ７５においてスマートフォン用セーブファイルの変更に応じて変更されたものである。つまり、送信されるゲーム機用セーブファイル（の共通セーブデータ）は、スマートフォンアプリにおけるゲーム処理に応じて更新されたものである。したがって、ゲーム機４は、スマートフォンアプリにおけるゲーム処理に応じて更新された共通セーブデータを利用してゲーム処理（すなわち、セーブデータ利用処理）を実行することができる。

また、ゲーム機アプリの実行中において、ゲーム機４は、セーブ処理を実行する（ステップＳ８３）。セーブ処理は、ゲーム機アプリの実行結果であるゲーム内容を表すセーブデータを生成し、ゲーム機４の記憶部２５（または、ゲーム機４に装着されたゲームカード）に記憶する処理である。セーブ処理は、例えば、ゲーム内容をセーブする指示がユーザによって行われた場合、および／または、所定のゲーム処理（例えば、ゲームにおける不正を防止する目的等で、自動的にセーブが行われることがある。）が行われた場合に実行される。

上記セーブ処理が実行される場合、ゲーム機４は、セーブデータをセーブデータサーバ３３へ送信する。このとき、ゲーム機４は、ログインに用いられた自社アカウントＩＤと、実行中のゲーム機アプリに関するゲーム機アプリＩＤとをセーブデータと関連付けてセーブデータサーバ３３へ送信する。

セーブデータサーバ３３は、ゲーム機４からセーブデータを受信し、ゲーム機用セーブファイルを必要に応じて更新する（ステップＳ８４）。具体的には、セーブデータサーバ３３は、ゲーム機４から受信したゲームデータに基づいて、セーブデータサーバ３３に記憶されているゲーム機用セーブファイルを更新する。セーブデータサーバ３３は、ゲーム機４からのセーブデータに関連付けられて受信される自社アカウントＩＤに関連付けられ、かつ、ゲーム機アプリＩＤに関連付けられるアプリセーブ情報に含まれるゲーム機用セーブファイルを更新する。

セーブデータサーバ３３は、ゲーム機用セーブファイルの共通セーブデータに変更があった場合、当該ゲーム機用セーブファイルに関連付けられるスマートフォン用セーブファイルの共通セーブデータを同期させる（ステップＳ８５）。すなわち、スマートフォン用セーブファイルの共通セーブデータは、ゲーム機用セーブファイルの共通セーブデータと同じ内容に更新される。

なお、図示しないが、ゲーム機４は、ユーザによる所定のアプリ終了指示に応じて、実行中のゲーム機アプリを終了する。その結果、図９に示す上記ステップＳ３９およびＳ４０の処理によって、管理サーバ３１は、上記ゲーム機アプリの実行が終了されたことを判断する。また、ゲーム機４は、ユーザによる所定の停止指示に応じて、起動を停止する。その結果、図９に示す上記ステップＳ４１の処理によって、管理サーバ３１は、ゲーム機４がログアウトしたことを判断し、図９に示す上記ステップＳ４２のログアウト処理を実行する。

以上のようにして、ゲーム機４におけるゲーム機アプリの実行の結果、セーブデータサーバ３３に記憶されるゲーム機用セーブファイルの共通セーブデータに変更があった場合には、当該ゲーム機アプリに対応するスマートフォンアプリのスマートフォン用セーブファイルの共通セーブデータも変更される。そして、その後にスマートフォン３においてスマートフォンアプリが実行される場合には、変更後の共通セーブデータを含むスマートフォン用セーブファイルを用いてゲーム処理が実行される。

（共通セーブデータが同時に利用される場合）
ここで、本実施形態においては、アプリセーブ情報において互いに関連付けられるスマートフォンアプリとゲーム機アプリとの一方のアプリケーションが実行中である状態において、他方のアプリケーションにおける共通セーブデータの利用を許可すると、当該一方のアプリケーションにおいて利用する共通セーブデータの内容が変更されてしまうおそれがある。このとき、当該一方のアプリケーションにおけるゲーム処理に不都合や矛盾が生じてしまうおそれがある。

そこで、本実施形態においては、セーブデータサーバ３３は、アプリセーブ情報において互いに関連付けられるスマートフォンアプリおよびゲーム機アプリのうち一方のアプリケーションが実行中である場合、他方のアプリケーションにおける共通セーブデータの利用を制限する。例えば、スマートフォン３においてスマートフォンアプリが実行中である状態において、当該スマートフォンアプリに関連付けられるゲーム機アプリがゲーム機４において起動されて実行される場合、セーブデータサーバ３３は、ゲーム機４からの上記共通セーブデータに対するアクセスを禁止する。なお、セーブデータサーバ３３は、共通セーブデータの更新のみを禁止し、読み出しを許可してもよいし、更新および読み出しを禁止してもよい。また、セーブデータサーバ３３は、ゲーム機用セーブファイルのうち、共通セーブデータ以外の部分についてはアクセスを許可してもよい。

具体的には、セーブファイル（スマートフォン用セーブファイルまたはゲーム機用セーブファイル）に対するアクセスの要求がゲームサーバ３４からあった場合、セーブデータサーバ３３は、管理サーバ３１に記憶されるアプリ実行情報に基づいて、セーブファイルに含まれる共通セーブデータの利用を許可するか否かを判定する。なお、上記の判定に用いられるアプリ実行情報は、上記アクセスの要求に係る自社アカウントに対応するユーザ管理情報に含まれるアプリ実行情報である。例えば、互いに関連付けられるアプリケーション（スマートフォンアプリおよびゲーム機アプリ）のうち、後から起動されたアプリケーションからのアクセス要求である場合、セーブデータサーバ３３は、共通セーブデータの利用を禁止する。この場合、セーブデータサーバ３３は、共通セーブデータを除くセーブファイルをゲームサーバ３４へ送信する。一方、互いに関連付けられるアプリケーションのうち、先に起動されたアプリケーションからのアクセス要求である場合、セーブデータサーバ３３は、共通セーブデータの利用を許可する。この場合、セーブデータサーバ３３は、共通セーブデータを含むセーブファイルをゲームサーバ３４へ送信する。なお、互いに関連付けられるアプリケーションのうち、先に起動されたアプリケーションであるか、それとも、後に起動されたアプリケーションであるかの判定は、アプリケーションの実行が開始された時間の情報を含むアプリ実行情報を管理サーバ３１に記憶しておくことで行うことができる。

なお、スマートフォンアプリとゲーム機アプリとの両方が実行中である場合に、どちらのアプリケーションについて共通セーブデータの利用を制限するかは、どのように決められてもよい。例えば、他の実施形態においては、セーブデータサーバ３３は、所定の一方のアプリケーションについて共通セーブデータの利用を制限するようにしてもよい。このとき、上記所定の一方のアプリは、アプリケーション毎に予め設定されてもよいし、ユーザによって設定されてもよい。また、上記の場合に共通セーブデータの利用が制限されるアプリケーションの決定方法は、関連付けられるスマートフォンアプリとゲーム機アプリとの組毎に設定されてもよい。

上記のように、本実施形態によれば、一方のアプリケーションによる共通セーブデータへのアクセスを制限することによって、他方のアプリケーションにおけるゲーム処理に不都合や矛盾が生じる可能性を低減することができる。

また、他の実施形態においては、セーブデータサーバ３３は、一方のアプリケーションが実行中である状態において他方のアプリケーションにおいて共通セーブデータに対するアクセス（具体的には、更新）があった場合、当該一方のアプリケーションを実行する端末へ通知を行うようにしてもよい。例えば、上記ステップＳ７５およびＳ８５の処理において、セーブデータサーバ３３は、更新した共通セーブデータを利用する端末へ、共通セーブデータが更新されたことを示す通知を送信してもよい。なお、この通知は、ゲームサーバ３４を介して上記端末へ送信されてもよいし、セーブデータサーバ３３から直接上記端末へ送信されてもよい。

上記通知を受信した端末は、更新後の共通セーブデータを含むセーブファイルを取得する要求をゲームサーバ３４に対して行ってもよい。また、上記端末は、共通セーブデータに変更があったことをユーザに通知してもよい。ゲームサーバ３４は、上記の通知を行った後、当該通知を行った端末へ、更新後の共通セーブデータを含むセーブファイルを送信してもよい。これによれば、上記一方のアプリケーションにおいて、他方のアプリケーションによって更新された後の共通セーブデータを利用することができる。

なお、アプリセーブ情報において互いに関連付けられる複数のアプリケーションが実行中となる場合に、これらのアプリケーションに対して自社サービスサーバ１がどのような対応をとることが適切か（例えば、後から起動されたアプリケーションに対して共通セーブデータの利用を制限するのか、それとも、先に起動されたアプリケーションに対して通知を行うのか等）は、アプリケーションの内容によって異なることがある。したがって、セーブデータサーバ３３は、上記の場合に取るべき対応を、アプリセーブ情報において互いに関連付けられるアプリケーションの組毎に設定してもよい。

なお、他の実施形態においては、セーブデータサーバ３３は、端末においてログインが行われていることを条件として、共通セーブデータの利用を当該端末に許可するようにしてもよい。すなわち、セーブデータサーバ３３は、セーブファイルに対するアクセスの要求がゲームサーバ３４からあった場合、管理サーバ３１に記憶されるログイン状態情報に基づいて、セーブファイルに含まれる共通セーブデータの利用を許可するか否かを判定してもよい。また、このとき、管理サーバ３１は、スマートフォン３およびゲーム機４のうち一方の端末においてログインが行われている状態において他方の端末からのログイン要求があった場合、当該他方の端末のログインを制限してもよい。これによれば、当該他方の端末において共通セーブデータの利用を制限することができる。

（上記処理による作用効果）
以上のように、本実施形態においては、自社サービスサーバ１は、第１の種類のプラットホームを有する第１の情報処理装置（すなわち、スマートフォン３／ゲーム機４）と通信を行い、第１の種類のプラットホームとは異なる第２の種類のプラットホームを有する第２の情報処理装置（すなわち、ゲーム機４／スマートフォン３）と通信を行う。自社サービスサーバ１（具体的には、セーブデータサーバ３３）は、共通ゲームデータ（本実施形態においては、スマートフォン用セーブファイルに含まれる共通セーブデータ、および、ゲーム機用セーブファイルに含まれる共通セーブデータ）を少なくとも記憶する（図１５参照）。共通ゲームデータは、スマートフォン３と互換性を有し、ゲーム機４と互換性を有しない第１のゲームアプリケーション（すなわち、スマートフォンアプリ）において利用可能なゲーム内容であって、かつ、ゲーム機４と互換性を有し、スマートフォン３と互換性を有しない第２のゲームアプリケーション（すなわち、ゲーム機アプリ）において利用可能なゲーム内容を示す。自社サービスサーバ１は、スマートフォン３におけるスマートフォンアプリの実行によって生成されたゲームデータを取得し、取得されたゲームデータに基づいて共通ゲームデータを更新する（図１７に示すステップＳ７４およびＳ７５）。また、自社サービスサーバ１は、スマートフォンアプリの実行によって生成されたゲームデータに基づいて更新された共通ゲームデータの少なくとも一部（本実施形態においては、ゲーム機用セーブファイルに含まれる共通セーブデータ）を、ゲーム機アプリによる利用のためにゲーム機４へ送信する（図１７に示すステップＳ８２）。

従来、端末側の情報処理装置において実行されるアプリケーションで用いるデータをサーバに保存する情報処理システムにおいては、端末で利用されるアプリケーションにおける利便性、および／または、アプリケーションの興趣性を向上することが望まれている。これに関して、上記実施形態によれば、異なるプラットホームのアプリケーション間でゲームデータを共有することができる。これによれば、端末（スマートフォン３またはゲーム機４）で利用されるアプリケーションの利便性を向上したり、あるいは、アプリケーションの興趣性を向上したりすることができる。また、スマートフォンアプリとゲーム機アプリとのうちの一方のアプリケーションを利用するユーザに対して、他方のアプリケーションを利用する動機付けを与えることができ、ユーザによるアプリケーションの取得を促進することができる。

また、本実施形態においては、相対的に汎用性の高い（換言すれば、所持しているユーザが相対的に多い）情報処理装置であるスマートデバイス（すなわち、スマートフォン３）におけるスマートフォンアプリの実行に応じて、共通ゲームデータが更新される。そして、相対的に汎用性の低い（換言すれば、所持しているユーザが相対的に少ない）情報処理装置であるゲーム機４におけるゲーム機アプリによる利用のために、当該共通ゲームデータがゲーム機４へ送信される。したがって、本実施形態によれば、スマートフォンアプリを利用するユーザに対してゲーム機アプリを利用する動機付けを与えることができ、スマートフォン３を利用するユーザをゲーム機４のユーザへと引き込むことができる。

また、本実施形態においては、自社サービスサーバ１（具体的には、セーブデータサーバ３３）は、ゲーム機４におけるゲーム機アプリの実行によって生成されたゲームデータを取得し、取得されたゲームデータに基づいて共通ゲームデータを更新する（図１７に示すステップＳ８４およびＳ８５）。そして、自社サービスサーバ１は、ゲーム機アプリの実行によって生成されたゲームデータに基づいて更新された共通ゲームデータの少なくとも一部を、スマートフォンアプリによる利用のためにスマートフォン３へ送信する（図１７に示すステップＳ７２）。

上記によれば、スマートフォンアプリとゲーム機アプリとの間で、一方における共通ゲームデータを他方の共通ゲームデータに反映させる処理が、双方向に行われる。これによれば、スマートフォンアプリを利用するユーザに対してゲーム機アプリを利用する動機付けを与えることができるとともに、ゲーム機アプリを利用するユーザに対してスマートフォンアプリを利用する動機付けを与えることができる。

なお、他の実施形態では、スマートフォンアプリとゲーム機アプリとのうちの一方のアプリケーションにおける共通ゲームデータを他方の共通ゲームデータに反映させる処理は、双方向に行われる必要はない。例えば、他の実施形態においては、スマートフォンアプリの共通セーブデータの内容を反映するようにゲーム機アプリの共通セーブデータが更新される一方、ゲーム機アプリの共通セーブデータの内容を反映するようにスマートフォンアプリの共通セーブデータが更新されなくてもよい。すなわち、ゲーム機アプリの共通セーブデータがスマートフォンアプリの実行によって更新される一方、スマートフォンアプリの共通セーブデータはゲーム機アプリの実行によって更新されなくてもよい。換言すれば、スマートフォンアプリおよびゲーム機アプリのうち一方は、共通セーブデータに対する読み出しおよび書き込みが可能であり、他方は、共通セーブデータの読み出しが可能で、書き込みが不可能であってもよい。

本実施形態においては、自社サービスサーバ１（具体的には、セーブデータサーバ３３）は、共通ゲームデータを含む第１のアプリ用データ（すなわち、スマートフォン用セーブファイル）と、共通ゲームデータを含む第２のアプリ用データ（すなわち、ゲーム機用セーブファイル）とを記憶する（図１５および図１６参照）。自社サービスサーバ１は、スマートフォンアプリによる利用のためにスマートフォン用セーブファイルをスマートフォン３へ送信し（図１７に示すステップＳ７２）、ゲーム機アプリによる利用のためにゲーム機用セーブファイルをゲーム機４へ送信する（図１７に示すステップＳ８２）。なお、他の実施形態においては、スマートフォン用セーブファイルの少なくとも一部がスマートフォン３へ送信されてもよいし、ゲーム機用セーブファイルの少なくとも一部がゲーム機４へ送信されてもよい。

上記によれば、サーバは、スマートフォンアプリに利用される共通セーブデータと、ゲーム機アプリに利用される共通セーブデータとをそれぞれ記憶する。これによれば、共通セーブデータの利便性を向上したり、共通セーブデータに対するアクセス管理を容易にしたりすることができる。例えば、２つの共通セーブデータを完全に一致させないようにすることが可能になる（完全に一致させてもよい）。また例えば、２つの共通セーブデータを異なるデータ形式で記憶することが可能になる。

本実施形態においては、上記第１のアプリ用データは、スマートフォンアプリにおいて利用可能な第１のゲームデータ（すなわち、スマートフォン用セーブデータ）をさらに含む。また、上記第２のアプリ用データは、ゲーム機アプリにおいて利用可能な第２のゲームデータ（すなわち、ゲーム機用セーブデータ）をさらに含む。

上記によれば、自社サービスサーバ１は、共通セーブデータに加えて、アプリケーションにおいて利用可能なゲームデータ（例えば、当該アプリケーションに専用のゲームデータ）をアプリ用データに含めて記憶することができる。

さらに、本実施形態においては、自社サービスサーバ１は、スマートフォン３におけるスマートフォンアプリの実行によって生成されたゲームデータを取得し、取得されたゲームデータに基づいて、スマートフォン用セーブファイルを更新し（図１７に示すステップＳ７４）、さらに、ゲーム機用セーブファイルに含まれる共通ゲームデータを更新する（図１７に示すステップＳ７５）。また、自社サービスサーバ１は、ゲーム機４におけるゲーム機アプリの実行によって生成されたゲームデータを取得し、取得されたゲームデータに基づいて、ゲーム機用セーブファイルを更新し（図１７に示すステップＳ８４）、さらに、スマートフォン用セーブファイルに含まれる共通ゲームデータを更新する（図１７に示すステップＳ８５）。

上記によれば、スマートフォン用セーブファイルおよびゲーム機用セーブファイルのいずれか一方が更新された場合、他方のセーブファイルに含まれる共通ゲームデータも更新される。これによって、２つの共通セーブデータについて一方の変更を他方に反映させることができる。

他の実施形態においては、自社サービスサーバ１は、スマートフォンアプリにおいて利用可能な第１のゲームデータ（すなわち、スマートフォン用セーブデータ）と、ゲーム機アプリにおいて利用可能な第２のゲームデータ（すなわち、ゲーム機用セーブデータ）と、共通ゲームデータとを記憶してもよい。このとき、自社サービスサーバ１は、スマートフォンアプリによる利用のためにスマートフォン用セーブデータと共通ゲームデータとをスマートフォン３へ送信し、ゲーム機アプリによる利用のためにゲーム機用セーブデータと共通ゲームデータとをゲーム機４へ送信する。

上記によれば、サーバは、スマートフォンアプリおよびゲーム機アプリに利用する共通セーブデータとして、単一のデータを記憶するので、サーバにおいて記憶されるデータのデータ量を低減することができる。

さらに、上記他の実施形態において、自社サービスサーバ１は、スマートフォン３におけるスマートフォンアプリの実行によって生成されたゲームデータを取得した場合、当該取得されたゲームデータに基づいて、スマートフォン用セーブデータと共通ゲームデータとを更新してもよい。また、自社サービスサーバ１は、ゲーム機４におけるゲーム機アプリの実行によって生成されたゲームデータを取得した場合、当該取得されたゲームデータに基づいて、ゲーム機用セーブデータと共通ゲームデータとを更新してもよい。

上記によれば、サーバは、スマートフォンアプリの実行に応じて共通ゲームデータを更新することができるとともに、ゲーム機アプリの実行に応じて共通ゲームデータを更新することができる。

本実施形態においては、自社サービスサーバ１は、共通ゲームデータが更新された（例えば、図１７に示すステップＳ７４およびＳ７５）後においてゲーム機４から要求（すなわち、ステップＳ８１の処理における取得要求）があったことに応じて、当該ゲーム機４へ当該共通ゲームデータの少なくとも一部を送信する（図１７に示すステップＳ８２）。

本実施形態においては、自社サービスサーバ１は、セーブデータサーバ３３と、ゲーム処理サーバ（すなわち、ゲームサーバ３４）とを含む。セーブデータサーバ３３は、共通ゲームデータを記憶する。ゲームサーバ３４は、セーブデータサーバ３３とは別に設けられ、スマートフォン３がスマートフォンアプリにおけるゲーム処理を実行する場合にアクセスするサーバである。

上記によれば、ゲーム処理用のサーバ（すなわち、ゲームサーバ３４）と、ゲームデータ保存用のサーバ（すなわち、セーブデータサーバ３３）とが別個に設けられる。これによれば、例えばゲームアプリケーション毎に異なるゲームサーバが設けられる場合であっても、各ゲームアプリケーションのゲームデータをセーブデータサーバ３３において管理することができる。

本実施形態において、スマートフォンアプリは、ゲーム機アプリよりも簡易なアプリケーションであってもよい。ここで、「スマートフォンアプリがゲーム機アプリよりも簡易である」とは、次の意味を含む。
・ゲーム内容が簡易である（より具体的には、ゲームのルールが単純である、ゲームのステージ数が少ない、ゲームに登場するキャラクタが少ない、または、操作方法が単純である、等）
・ゲーム処理が簡易である（アプリケーションのデータサイズが小さい、ゲーム画像の解像度が低い、または、端末側で実行されるゲーム処理の割合が低い（ゲームサーバ側で実行されるゲーム処理の割合が高い）等）

上記によれば、ユーザは、簡易なスマートフォンアプリをまず体験し、スマートフォンアプリを気に入った場合に、より本格的なゲーム機アプリを取得（例えば購入）することができる。したがって、実施事業者にとっては、ユーザが利用しやすいスマートフォンアプリを提供することで、ゲーム機アプリを取得する動機付けをユーザに与えることができる。

また、本実施形態において、スマートフォンアプリは、スマートフォン３におけるスマートフォンアプリの起動時において、当該スマートフォン３がサーバ（すなわち、ゲームサーバ３４）へアクセス可能であることを条件とするアプリケーションである。一方、ゲーム機アプリは、ゲーム機４におけるゲーム機アプリの起動時において、当該ゲーム機４がサーバへアクセス可能であることを条件としないアプリケーションである。

また、スマートフォンアプリとゲーム機アプリとでは、ユーザに対して提供される方法が異なっている。すなわち、スマートフォンアプリは、スマートフォンアプリ提供サーバ２からスマートフォン３へダウンロードされることによって取得される。一方、ゲーム機アプリは、自社サービスサーバ１（具体的には、ゲーム機アプリ提供サーバ３２）からゲーム機４へダウンロードされることによって取得される。なお、ゲーム機アプリは、当該ゲーム機アプリを記憶したゲームカードが店頭等においてユーザに取得されることによって提供されてもよい。

また、自社サービスに係る各スマートフォンアプリのうちの一部または全部のスマートフォンアプリは、スマートフォン３に対するインストールに対しては課金されないアプリケーションであり、自社サービスに係る各ゲーム機アプリのうちの一部または全部のゲーム機アプリは、ゲーム機４に対するインストールに対して課金されるアプリケーションであってもよい。なお、「自社サービスに係るアプリケーション」とは、自社サービスサーバ１によってサービスが提供されるアプリケーション（具体的には、スマートフォンアプリまたはゲーム機アプリ）を指す。すなわち、上記各スマートフォンアプリの一部または全部は、無料でスマートフォン３にインストールすることができ、スマートフォンアプリの利用に応じて課金が行われる種類のアプリケーションであってもよい。例えば、スマートフォンアプリで利用されるデータ（具体的には、ゲームアプリケーションにおいて、ゲーム内に登場するアイテムのデータや、ゲーム内で用いられるお金のデータ）の取得に対して課金が行われてもよい。また例えば、スマートフォンアプリの利用回数および／または利用時間に応じて課金が行われてもよい。一方、ゲーム機アプリについては、ゲーム機４に対するインストールに対して課金される場合において、ゲーム機アプリの利用に応じて課金が行われてもよいし、行われなくてもよい。

上記のように、スマートフォンアプリのインストールに対して課金を行わないことによって、ユーザに対してスマートフォンアプリをインストールさせやすくすることができ、スマートフォンアプリをユーザに利用してもらいやすくすることができる。上述のように、本実施形態においては、スマートフォンアプリの利用によってゲーム機アプリを取得する動機付けを与えることができるので、上記のようにスマートフォンアプリをユーザに利用してもらいやすくすることによって、ゲーム機アプリについてもユーザに利用する動機付けを与えることができる。

（変形例）
本実施形態においては、セーブデータサーバ３３は、同じ内容の共通ゲームデータを利用するスマートフォンアプリとゲーム機アプリとの組を示す情報（すなわち、アプリセーブ情報）を記憶する。このとき、共通セーブデータは、特定の組毎に異なるゲーム内容（例えば、同じシリーズのゲームに関するゲーム内容）を示すデータであった。ここで、共通セーブデータは、異なる組について同じ内容を示す情報を含んでいてもよい。すなわち、共通セーブデータは、各組のゲームアプリケーション（スマートフォンアプリおよびゲーム機アプリ）について共通に利用可能なデータを含んでいてもよい。例えば、共通セーブデータは、自社アカウントのユーザに関するアバターに関するデータを含んでいてもよい。このとき、アバターに関するデータは、異なる組に属するスマートフォンアプリおよび／またはゲーム機アプリにおいて利用することが可能であってもよい。

また、他の実施形態においては、共通セーブデータは、各ゲームアプリケーション（自社サービスに係る各スマートフォンアプリおよび各ゲーム機アプリ）について共通に利用可能なデータを有し、各組毎に異なるゲーム内容を示すデータを含まなくてもよい。例えば、図１５に示す例において、スマートフォン用セーブファイル（またはゲーム機用セーブファイル）は、共通セーブデータを含み、スマートフォン用セーブデータ（またはゲーム機用セーブデータ）を含まなくてもよい。このとき、セーブデータサーバ３３は、スマートフォンアプリとゲーム機アプリとの組を示す情報を記憶していなくてもよい。例えば、共通セーブデータは、上記アバターに関するデータのみを含んでいてもよく、セーブデータサーバ３３は、当該アバターに関するデータのみを利用するゲームアプリケーションについて、スマートフォンアプリとゲーム機アプリとの組を示す情報を記憶していなくてもよい。

（３−６）スマートフォンアプリの提供サービスの利用に応じて自社サービスサーバ１においてポイントを管理する処理
次に、図１８〜図２１を参照して、スマートフォンアプリ提供サービスの利用に応じて、自社サービスサーバ１においてポイントを管理する処理について説明する。上述のように、本実施形態においては、スマートフォンアプリは、直接的には、スマートフォンアプリ提供サーバ２を用いたアプリ提供サービスを運営する他の事業者によって提供される。したがって、スマートフォンアプリに関するデータをユーザが購入するための処理は、スマートフォンアプリ提供サーバとスマートフォン３との間で行われる。

ここで、本実施形態においては、スマートフォンアプリに関するデータの購入に応じたポイントを自社サービスサーバ１において管理する。このポイントは、例えば、スマートフォンアプリの購入に関するユーザの履歴を実施事業者が確認するために用いられる。つまり、上記ポイントによって、スマートフォンアプリの利用（ここでは購入）の実績をサーバ側（すなわち、実施事業者側）で把握することができる。また、上記ポイントは、ポイントに応じた特典をユーザに付与するために用いられる。これによれば、ユーザにとっては、スマートフォンアプリに関する購入によって、自社サービスにおいてもポイントが付与されることになるので、ユーザによるスマートフォンアプリの利用を促進することができる。さらに、ポイントが付与されることによって、ユーザによる自社サービスの利用（例えば、ゲーム機アプリの利用）を促進することもできる。以下、ポイントを管理する処理について詳細を説明する。

ここで、本実施形態においては、購入に係るデータ（すなわち、購入によってスマートフォン３において取得されるデータ）は、スマートフォンアプリ提供サーバ２からスマートフォン３へ提供される場合と、ゲームサーバ３４からスマートフォン３へ提供される場合とがある。前者は、例えば、購入に係るデータが、スマートフォンアプリのプログラムデータである場合である。後者は、例えば、購入に係るデータが、スマートフォンアプリ内で用いられるゲームデータである場合である。

（スマートフォンアプリ提供サーバからデータを取得する場合の処理例）
まず、購入に係るデータがスマートフォンアプリ提供サーバ２からスマートフォン３へ提供される場合の処理例について説明する。図１８は、スマートフォンアプリ提供サービスの利用に応じてポイントを管理する処理の概要の一例を示す図である。また、図１９は、スマートフォンアプリ提供サーバからスマートフォンがデータを取得する場合における、ポイントを管理する処理の流れの一例を示す図である。例えば、スマートフォンアプリのプログラムをスマートフォン３にダウンロードする場合には、図１９に示す一連の処理が実行される。

図１９において、ユーザはまず、スマートフォン３を用いてスマートフォンアプリの購入操作を行う。具体的には、スマートフォン３は、ユーザの指示に応じて、スマートフォンアプリ提供サーバ２にアクセスし、スマートフォンアプリ提供サーバ２のサービスに他社アカウントＩＤでログインする。そして、ユーザが指定するスマートフォンアプリを購入するための購入要求の情報を送信する（図１８に示す（１）、図１９に示すステップＳ９１）。

なお、スマートフォンアプリを購入するための具体的な処理内容は任意である。例えば、スマートフォン３は、スマートフォンアプリ提供サーバ２が提供するショップサイトにアクセスして他社アカウントＩＤでログインする。なお、この他社アカウントＩＤは、購入を行うユーザに関して、自社アカウントを登録する際に自社アカウントＩＤと関連付けて登録された他社アカウントＩＤである。つまり、ユーザは、自社アカウントＩＤと関連付けて登録された他社アカウントＩＤでログインする。

なお、他社アカウントにログインするタイミングは任意であり、スマートフォン３がショップサイトにアクセス中の任意のタイミングであってよい。例えば、スマートフォン３がショップサイトへのアクセスを開始するタイミングでログインが行われてもよいし、後述の購入指示が行われるタイミングでログインが行われてもよい。

スマートフォン３は、ショップサイト内における、ユーザが指定したスマートフォンアプリのための購入ページを表示部１５に表示した状態で、スマートフォンアプリを購入する旨の購入指示を受け付ける。ユーザによって購入指示が行われたことに応じて、スマートフォン３は、スマートフォンアプリを購入するための購入要求の情報をスマートフォンアプリ提供サーバ２へ送信する。

スマートフォン３から購入要求の情報を受信すると、スマートフォンアプリ提供サーバ２は、購入要求に応じた課金処理を実行し、さらに、必要に応じて決済処理を実行する（図１９に示すステップＳ９２）。これらの課金処理および決済処理の具体的な処理内容は任意である。例えば、スマートフォンアプリ提供サーバ２は、上記ステップＳ１９と同様の処理を実行してもよい。

上記課金処理および決済処理の結果、スマートフォン３（換言すれば、ユーザ）がスマートフォンアプリを取得するための取得条件が満たされると、スマートフォンアプリ提供サーバ２は、購入に係るデータをスマートフォン３へ送信する（図１８に示す（２）、図１９に示すステップＳ９３）。上記取得条件は、任意であるが、例えば、決済が完了したこと（すなわち、料金が支払われた）、あるいは、決済が行われる準備が完了した（すなわち、料金の引き落としの準備が完了した）こと等である。また、購入に係るデータは、ここではスマートフォンアプリのプログラムデータであるとするが、これに限らず、スマートフォンアプリにおいて用いられるデータ（例えば、アイテムのデータ、ゲーム内で利用されるお金のデータ、および、追加ステージのデータ等）でもよい。

なお、スマートフォン３は、受信したデータに基づいて適宜の処理を実行する。例えば、スマートフォンアプリのプログラムデータを受信する場合、スマートフォン３は、当該スマートフォンアプリのインストールを行う。

以上で説明したステップＳ９１〜Ｓ９３の処理については、従来のアプリ提供サービスにおいて実行されている処理と同様であってもよい。

本実施形態においては、上記取得条件が満たされると、スマートフォンアプリ提供サーバ２は、購入情報を自社サービスサーバ１（具体的には、管理サーバ３１）へ送信する（図１８に示す（３）、図１９に示すステップＳ９４）。購入情報は、スマートフォンアプリについて行われた購入に関する情報である。本実施形態においては、購入情報は、購入額の情報、および、購入されたデータの内容を示す情報（例えば、スマートフォンアプリＩＤ）を含む。また、購入情報は、データの取得に用いられた他社アカウントのＩＤを含む。なお、購入情報は、上記取得条件が満たされた場合に送信されるので、当該取得条件が満たされたことを通知する情報であるとも言える。

購入情報を受信すると、管理サーバ３１は、自社アカウント（換言すれば、ユーザ）に対してポイントを付与する（図１８に示す（４））。具体的には、まず、管理サーバ３１は、スマートフォンアプリに関する購入が行われた他社アカウントに対応する自社アカウントを特定する（図１９に示すステップＳ９５）。自社アカウントは、購入情報に含まれる他社アカウントＩＤに基づいて特定される。ここで、上述のように、管理サーバ３１は、自社アカウントＩＤと他社アカウントＩＤとを関連付けるユーザ管理情報を記憶している（図６および図１８参照）。管理サーバ３１は、ユーザ管理情報において、購入情報に含まれる他社アカウントのＩＤに関連付けられる自社アカウントＩＤが示す自社アカウントを特定する。

なお、他の実施形態においては、スマートフォンアプリ提供サーバ２からの購入情報に自社アカウントＩＤが含まれており、管理サーバ３１は、自社アカウントＩＤに従って自社アカウントを特定してもよい。このとき、スマートフォンアプリ提供サーバ２は、自社アカウントＩＤと他社アカウントＩＤとを関連付ける情報を記憶しており、当該情報に基づいて自社アカウントＩＤを特定してもよい。また、スマートフォン３からスマートフォンアプリ提供サーバ２へ送信される購入要求に自社アカウントＩＤが含まれていてもよく、スマートフォンアプリ提供サーバ２は、購入要求に含まれる自社アカウントＩＤを購入情報に含めて管理サーバ３１へ送信してもよい。

次に、管理サーバ３１は、特定した自社アカウントについてポイントを付与する（図１９に示すステップＳ９６）。ここで、本実施形態においては、管理サーバ３１が記憶するユーザ管理情報においては、自社アカウントＩＤに対してポイント情報が関連付けられている（図１８参照）。ポイント情報は、それに関連付けられる自社アカウントＩＤが示す自社アカウント（換言すれば、ユーザ）に付与されるポイントを示す。上記ステップＳ９６の処理において、管理サーバ３１は、記憶部に記憶されるポイント情報を更新する。すなわち、管理サーバ３１は、ポイント情報を記憶部から読み出し、読み出したポイント情報が示すポイント数に、付与すべきポイント数を加算し、加算後のポイント数を示すポイント情報を、更新後のポイント情報として記憶部に記憶する。

本実施形態において、管理サーバ３１は、付与する（換言すれば、加算する）ポイントの内容（すなわち、付与するポイント数）を購入情報に基づいて決定する。ここで、付与するポイントの内容は任意である。本実施形態においては、管理サーバ３１は、購入情報に含まれる購入額に応じた数のポイントを付与する。具体的には、購入額から、スマートフォンアプリ提供サーバ２におけるサービスの手数料を引いた額に対する所定の割合となるように、付与すべきポイント数が決定される。なお、上記手数料は、実施事業者に代わって他の事業者がスマートフォンアプリをユーザに提供するサービスの手数料である。

また、管理サーバ３１は、購入されたデータの内容に応じた数のポイントを付与するようにしてもよい。例えば、購入されたスマートフォンアプリの種類に応じた数のポイントが付与されてもよい。すなわち、管理サーバ３１は、購入情報に含まれるスマートフォンアプリＩＤに基づいて、購入されたスマートフォンアプリを特定し、スマートフォンアプリに応じて異なる量のポイントを付与するようにしてもよい。また、管理サーバ３１は、付与したポイント数と関連付けて、購入されたアプリケーションのアプリＩＤをポイント情報として記憶してもよい。

以上のようにして、自社アカウントに関連付けられるポイントについて、スマートフォンアプリに関する購入に応じたポイントが管理される。ここで、上記ポイントは、ユーザが購入を行うことに応じて付与されるので、購入の実績を示す指標であると言える。したがって、実施事業者は、自身では直接提供しないスマートフォンアプリについての購入実績を、上記ポイントによって把握することができる。

また、本実施形態においては、自社サービスサーバ１は、自社アカウントのユーザに対して、ポイントに応じた特典を付与する（図１８に示す（５））。具体的には、まず、自社サービスサーバ１は、ポイントが所定の付与条件を満たしたか否かを判定する。そして、ポイントが所定の付与条件を満たしたと判定された場合、自社サービスサーバ１は、特典を付与する処理を実行する。なお、上記付与条件は、任意であり、例えば、予め定められた所定数のポイントに到達したことである。なお、付与条件は複数種類設定され、付与条件毎に特典が関連付けられていてもよく、付与条件が満たされる度に、満たされた付与条件に関連付けられる特典が付与されてもよい。

ここで、ユーザに付与される特典の内容は、任意である。例えば、特典の内容は、購入情報に基づいて決定されてもよく、具体的には、購入情報に含まれるスマートフォンアプリＩＤに基づいて決定されてもよい。すなわち、管理サーバ３１は、購入情報を受信した場合、当該購入情報に含まれるスマートフォンアプリＩＤが示すスマートフォンアプリに関連するゲーム機アプリを特典としてもよい。なお、「スマートフォンアプリに関連するゲーム機アプリ」は、上記“（３−４）スマートフォンを用いてゲーム機アプリを購入する処理”で説明した例と同じものであってもよいし、上記“（３−５）スマートフォンアプリとゲーム機アプリでセーブデータを共有する処理”で説明した、スマートフォンアプリとセーブデータを共有するゲーム機アプリであってもよい。また、特典は、スマートフォンアプリであってもよい。

また、ユーザに付与される特典の内容は、上述のユーザ関連情報に基づいて決定されてもよい。例えば、管理サーバ３１は、ユーザ関連情報に含まれる履歴情報に基づいてユーザの趣味嗜好を推測することによって、特典の内容を決定してもよい。管理サーバ３１は、上述した、ユーザの履歴情報に基づいて広告情報の内容を決定する方法と同様の方法（“（３−４）スマートフォンを用いてゲーム機アプリを購入する処理”を参照）で、特典の内容を決定してもよい。

また、管理サーバ３１は、ユーザがゲーム機４を所有していない場合には、ゲーム機４を特典としてもよい。ゲーム機４を所有していないユーザに対して、特典としてゲーム機４を付与することによって、ゲーム機アプリを購入する動機付けを当該ユーザに与えることができる。なお、ユーザがゲーム機４を所有しているか否かの判定は、ユーザ管理情報にゲーム機ＩＤが含まれるか否かによって行うことができる。すなわち、管理サーバ３１は、上記付与条件をポイントが満たした場合、当該ポイントに対応する自社アカウントに関するユーザ管理情報において、ゲーム機ＩＤが登録されているか否かを判定する。管理サーバ３１は、ユーザ管理情報においてゲーム機ＩＤが登録されていない場合、ゲーム機４を特典として決定し、ユーザ管理情報においてゲーム機ＩＤが登録されている場合、ゲーム機アプリを特典として決定してもよい。

以上のように、特典は、ネットワークを介して送信可能なデータであってもよいし、データではない物であってもよいし、何らかのサービスであってもよい。特典として、ネットワークを介して自社サービスサーバ１から送信可能なデータが付与される場合、自社サービスサーバ１は、特典を付与する処理として、当該データを送信する処理を行う。例えば、ゲーム機アプリ提供サーバ３２が、ゲーム機アプリに関するデータをゲーム機４へ送信する。なお、特典となるデータは、ゲーム機アプリのプログラムデータであってもよいし、ゲーム機アプリで用いられるゲームデータ（アイテム、アプリ内で利用されるお金、キャラクタ、および／または、追加ステージ等のデータ）でもよい。なお、送信先となるゲーム機４は、付与条件を満たしたポイント情報と同じユーザ管理情報に含まれるゲーム機ＩＤに基づいて決定される。以上のように、ゲーム機アプリに関するデータを特典として付与することで、当該ゲーム機アプリを利用する動機付けをユーザに与えることができる。

また、特典が付与される場合、管理サーバ３１は、特典を付与する処理として、特典に関する通知を端末（スマートフォン３および／またはゲーム機４）へ送信する処理を実行してもよい。すなわち、管理サーバ３１は、特典を付与する場合（すなわち、上記付与条件が満たされた場合）、特典を付与する旨の通知を端末へ送信する。本実施形態においては、管理サーバ３１は、ユーザがゲーム機４を所有している場合にはゲーム機４へ通知を送信し、ユーザがゲーム機４を所有していない場合にはスマートフォン３へ通知を送信する。これによれば、特典に関する通知を確実に行うことができる。なお、上述したように、ユーザがゲーム機４を所有しているか否かの判定は、ユーザ管理情報にゲーム機ＩＤが含まれるか否かによって行うことができる。また、送信先となるゲーム機４またはスマートフォン３は、ユーザ管理情報に含まれるゲーム機ＩＤまたはスマートフォンＩＤによって特定される。

なお、上記通知の送信先となる端末は、どのように決定されてもよい。例えば、他の実施形態においては、管理サーバ３１は、スマートフォン３に通知を送信するようにしてもよいし、スマートフォン３とゲーム機４との両方に通知を送信するようにしてもよい。

また、本実施形態において、管理サーバ３１は、上記の通知をプッシュ送信で端末へ送信する。ただし、他の実施形態においては、管理サーバ３１は、ユーザの指示に応じて行われる端末からの問合せに応じて上記の通知を当該端末へ送信するようにしてもよい。

（スマートフォンでアプリ実行中に購入する場合）
次に、購入に係るデータがゲームサーバ３４からスマートフォン３へ提供される場合の処理例について説明する。図２０は、ゲームサーバからスマートフォンがデータを取得する場合における、ポイントを管理する処理の流れの一例を示す図である。例えば、スマートフォンアプリで用いられるゲームデータを取得する場合（例えば、ゲーム内で用いられるお金やアイテムを購入する場合）には、図２０に示す一連の処理が実行される。

図２０に示す一連の処理において、まず、スマートフォン３は、ユーザによる起動指示に応じて、スマートフォンアプリを起動（すなわち、実行開始）し、ログインを行う（ステップＳ１００）。これに応じて、ゲームサーバ３４は、管理サーバ３１に対してログインの確認を行い、管理サーバ３１によってログインが承認された場合、ゲームデータをスマートフォン３へ送信する（ステップＳ１０１）。このとき、管理サーバ３１は、上述のログイン処理を実行する（ステップＳ１０２）。スマートフォン３は、受信したゲームデータを用いてゲーム処理を開始する。なお、ステップＳ１００〜Ｓ１０２の一連の処理は、上述のステップＳ１１〜Ｓ１３（または、上述のステップＳ５０〜Ｓ５２）の一連の処理と同じであるので、詳細な説明を省略する。

図２０において、ユーザは、スマートフォンアプリ内で（すなわち、スマートフォンアプリの機能を用いて）、スマートフォンアプリに関する購入操作を行う。例えば、スマートフォン３は、スマートフォンアプリの実行中における任意のタイミングで（例えば、ユーザが所定の指示を行ったことに応じて）、上記購入操作を行うための購入画像を表示部１５に表示する。購入画像は、スマートフォンアプリ内で表示される画像、すなわち、スマートフォンアプリの実行によって生成される画像である。

なお、他の実施形態においては、スマートフォン３は、上記購入画像に代えて、スマートフォンアプリ提供サーバ２によって提供されるウェブページである購入ページにおいて購入操作を受け付けるようにしてもよい。すなわち、スマートフォン３は、スマートフォンアプリ内における所定のユーザ指示に応じて、上記購入ページを取得する要求を示す情報をスマートフォンアプリ提供サーバ２へ送信する。当該要求の情報を受信したスマートフォンアプリ提供サーバ２は、購入ページをスマートフォン３へ送信する。スマートフォン３は、ブラウザアプリを用いて購入ページを表示部１５に表示する。

図２１は、スマートフォン３に表示される購入画像の一例を示す図である。図２１において、表示部１５に表示される購入画像５１は、スマートフォンアプリ内で用いられる宝石を購入するための画像である。購入画像５１は、宝石の購入指示を行うための指示画像５２（図２１では、購入する宝石の個数に応じた複数の指示画像）を含む。なお、宝石は、購入可能なアイテムの一例である。宝石は、例えば、スマートフォンアプリのゲームにおいて、アイテムやキャラクタを取得したり、ゲームをプレイしたりすることに利用することができる。なお、宝石は、ユーザが購入することによって取得される他、一定条件下でユーザに付与されてもよい。例えば、ログインを行ったことに応じて所定個数の宝石が無料で付与されたり、一定期間毎に所定個数の宝石が無料で付与されたりしてもよい。ユーザは、購入画像５１に含まれる指示画像５２を指定することによって、宝石を購入する指示を行うことができる。

宝石を購入する指示が行われた場合、スマートフォン３は、購入要求の情報をスマートフォンアプリ提供サーバ２へ送信する（ステップＳ１０３）。なお、このとき、スマートフォン３は、購入要求の情報を送信する前に（あるいは、購入要求の情報の送信と同時に）、スマートフォンアプリ提供サーバ２にアクセスし、スマートフォンアプリ提供サーバ２のサービスに他社アカウントＩＤでログインする。なお、スマートフォンアプリ提供サーバ２のサービスへのログインは、スマートフォンアプリの実行中における任意のタイミングで行われてもよいし、スマートフォンアプリの実行前に行われてもよい。また、他社サービスへのログインは、シングルサインオンによって行うことが可能であってもよい。

購入要求の情報を受信すると、スマートフォンアプリ提供サーバ２は、購入要求に応じた課金処理、および、必要に応じて決済処理を実行する（ステップＳ１０４）。ステップＳ１０４の処理も上記ステップＳ９２の処理と同様、課金処理および決済処理の具体的な処理内容は任意である。

上記課金処理および決済処理の結果、スマートフォン３（換言すれば、ユーザ）がスマートフォンアプリに用いるゲームデータ（例えば、宝石のデータ）を取得するための取得条件が満たされると、スマートフォンアプリ提供サーバ２は、購入情報をゲームサーバ３４へ送信する（ステップＳ１０５）。上述のように、購入情報は、購入額の情報、購入されたデータの内容を示す情報、および他社アカウントＩＤを含む。ここでは、購入されたデータの内容を示す情報として、例えば、購入された宝石の個数を示す情報が含まれる。

購入情報を受信すると、ゲームサーバ３４は、購入情報に応じたゲームデータをスマートフォン３へ送信する（ステップＳ１０６）。ここでは、ゲームデータとして、スマートフォン３におけるスマートフォンアプリのゲームにおける宝石を追加するためのデータ（例えば、追加する宝石の数を示すデータ）が送信される。なお、ステップＳ１０６の処理において、ゲームサーバ３４は、必要に応じて、上述のスマートフォン用セーブファイルを更新してもよいし（図１７に示すステップＳ７４）、共通セーブデータに変更がある場合には、さらに、ゲーム機用セーブファイルの共通セーブデータを更新してもよい（図１７に示すステップＳ７５）。

また、ゲームサーバ３４は、スマートフォンアプリ提供サーバ２から受信した購入情報を管理サーバ３１へ送信する（ステップＳ１０７）。なお、ゲームサーバ３４は、受信した購入情報のうち、購入額の情報および他社アカウントＩＤの情報を少なくとも管理サーバ３１へ送信する。これに応じて、管理サーバ３１は、スマートフォンアプリに関する購入が行われた他社アカウントに対応する自社アカウントを特定し（ステップＳ１０８）、特定した自社アカウントについてポイントを付与する（ステップＳ１０９）。なお、ステップＳ１０８およびＳ１０９の処理は、上述のステップＳ９５およびＳ９６の処理と同様である。

なお、図２０においては、スマートフォンアプリ提供サーバ２はゲームサーバ３４へ購入情報を送信するものとしたが、管理サーバ３１へ購入情報を送信してもよい。このとき、管理サーバ３１は、受信した購入情報のうち、購入されたデータの内容を示す情報を少なくともゲームサーバ３４へ送信する。これによって、ゲームサーバ３４は、購入情報に応じたゲームデータをスマートフォン３へ送信することができる。また、他の実施形態においては、スマートフォンアプリ提供サーバ２は、ゲームサーバ３４と管理サーバ３１の両方へ購入情報を送信してもよい。また、スマートフォンアプリ提供サーバ２は、購入されたデータの内容を示す情報をゲームサーバ３４へ送信し、購入額の情報および他社アカウントＩＤの情報を管理サーバ３１へ送信してもよい。

また、図２０において、管理サーバ３１は、自社サービスにログインしていることを条件として、スマートフォンアプリに関する購入に応じたポイントを付与するようにしてもよい。すなわち、上記ステップＳ１０９の処理において、管理サーバ３１は、ステップＳ１０８の処理で特定された自社アカウントについて、スマートフォン３がログイン中であるか否かを判定する。この判定は、管理サーバ３１に記憶されている上述のログイン状態情報に基づいて行うことができる。管理サーバ３１は、上記スマートフォン３がログイン中であると判定される場合、ポイントを付与する処理を実行し、上記スマートフォン３がログイン中でないと判定される場合、ポイントを付与する処理を実行しないようにしてもよい。これによれば、ユーザに対してログインを行う動機付けを与えることができる。また、他の実施形態においては、自社サービスサーバ１は、スマートフォン３がログインしている場合には、ログインしていない場合に比べて多くのポイントを付与するようにしてもよい。

（その他の処理）
図１９および図２０に示す一連の処理に加えて、本実施形態においては、自社サービスサーバ１は、ゲーム機アプリに関する購入情報をさらに取得し、この購入情報に基づいてポイントを付与する。具体的には、管理サーバ３１は、ゲーム機４におけるゲーム機アプリに関するデータの購入に関する情報を含む追加の購入情報を取得する。追加の購入情報は、例えば、ゲーム機４からの購入要求に基づいてゲーム機アプリ提供サーバ３２によって生成され、ゲーム機アプリ提供サーバ３２からゲーム機４へ送信される。なお、追加の購入情報は、購入額の情報、購入されたデータの内容を示す情報、および、自社アカウントＩＤを含む。また、管理サーバ３１は、取得された追加の購入情報に基づいて、当該追加の購入情報に対応するゲーム機４に関する自社アカウントＩＤに関連付けられるポイント情報を更新する。なお、追加の購入情報は自社アカウントＩＤを含むので、この自社アカウントＩＤに基づいて、管理サーバ３１が記憶している複数の自社アカウントに関連付けられるポイント情報のうちから、更新すべきポイント情報を特定することができる。

なお、管理サーバ３１は、スマートフォンアプリに対応する購入情報に基づくポイントと、ゲーム機アプリに対応する購入情報に基づくポイントとを合算して管理してもよいし、これら２種類のポイントを別個に管理してもよい。２種類のポイントを合算する場合、管理サーバ３１は、スマートフォンアプリに関する購入実績と、ゲーム機アプリに関する購入実績とを合わせて管理することができる。

また、本実施形態においては、上記ポイント情報は、ユーザが閲覧可能である。すなわち、管理サーバ３１は、端末（スマートフォン３および／またはゲーム機４）からの要求に応じて、ポイント数を示す情報を端末へ送信するようにしてもよい。例えば、自社サービスサーバ１は、ゲーム機アプリ提供サーバ３２によって提供されるショッピングサイト上でポイント数を閲覧することができるようにしてもよい。なお、自社サービスサーバ１は、自社アカウントＩＤとパスワードとを含む閲覧要求の情報を端末から受信し、当該自社アカウントＩＤとパスワードとによるログインが認証される場合に、当該自社アカウントＩＤに関連付けられるポイント情報が示すポイント数を端末へ提示するようにしてもよい。

なお、他の実施形態においては、ユーザは上記ポイント情報を閲覧できなくてもよい。すなわち、自社サービスサーバ１は、スマートフォン３およびゲーム機４に対してポイント情報の閲覧を許可しなくてもよい。例えば、ポイント情報は、スマートフォンアプリの利用（ここでは購入）の実績を実施事業者が把握する目的のためだけに利用されてもよい。

なお、本実施形態においては、スマートフォンアプリで用いられるゲームデータを取得する場合、他社サービス（すなわち、スマートフォンアプリ提供サーバ２）において課金処理（および、必要に応じて決済処理）が実行されるものとした（図２０）。ここで、他の実施形態においては、上記の場合、自社サービスサーバ１において課金処理（および、必要に応じて決済処理）が実行されてもよい。このとき、管理サーバ３１は、スマートフォン３においてスマートフォンアプリに関するゲームデータが購入される場合、ゲーム機４においてゲーム機アプリに関するゲームデータが購入される場合と同様に、アプリ提供サーバ３２から購入情報を取得し、取得された購入情報に基づいてポイント情報を更新してもよい。

（上記処理による作用効果）
以上のように、本実施形態においては、自社サービスサーバ１は、第１の種類のプラットホームを有する第１の情報処理装置（すなわち、ゲーム機４）と通信を行い、第１の種類のプラットホームとは異なる第２の種類のプラットホームを有する第２の情報処理装置（すなわち、スマートフォン３）と通信を行う。ここで、スマートフォン３は、第２の種類のプラットホームと互換性を有し、かつ、第１の種類のプラットホームと互換性を有しない第２のアプリケーション（すなわち、スマートフォンアプリ）に関するデータを、自社サービスサーバ１と異なる他のアプリ提供サーバ（すなわち、スマートフォンアプリ提供サーバ２）から取得することが可能である。自社サービスサーバ１は、スマートフォン３におけるスマートフォンアプリに関するデータの取得に関するアプリ情報（本実施形態においては、購入情報）を取得する（図１９に示すステップＳ９５、図２０に示すステップＳ１０８）。また、自社サービスサーバ１は、ゲーム機４に関する第１の識別情報（すなわち、自社アカウントＩＤ）と、スマートフォンアプリに関するデータの取得に関する実績情報（本実施形態においては、ポイント情報）とを関連付けた情報（すなわち、ユーザ管理情報）を記憶する（図１８参照）。自社サービスサーバ１は、記憶されるポイント情報のうち、取得された購入情報に対応する自社アカウントＩＤに関連付けられるポイント情報を特定する（図１９に示すステップＳ９５、図２０に示すステップＳ１０８）。なお、「取得された購入情報に対応する自社アカウントＩＤ」とは、例えば、取得された購入情報により特定されるユーザに設定される自社アカウントＩＤ、換言すれば、当該購入情報が示す購入（換言すれば、取得）を行ったユーザに設定される自社アカウントＩＤを指す。自社サービスサーバ１は、取得された購入情報に基づいて、特定されたポイント情報を更新する（図１９に示すステップＳ９６、図２０に示すステップＳ１０９）。

上記において、アプリ情報は、スマートフォン３におけるスマートフォンアプリに関するデータの取得に関する情報に限らず、当該スマートフォンアプリの利用に関する情報であってもよい。このとき、実績情報は、スマートフォンアプリの利用に関する実績を示す情報であってもよい。つまり、本実施形態においては、スマートフォンアプリに関するデータの取得に関する実績を自社サービスサーバ１で管理するものとしたが、他の実施形態においては、スマートフォンアプリにおける利用に関する実績を自社サービスサーバ１で管理するようにしてもよい。

また、本実施形態においては、自社サービスサーバ１は、スマートフォンアプリに関する購入の実績を管理したが、他の実施形態においては、自社サービスサーバ１で管理する実績は、購入に関するものに限らない。すなわち、他の実施形態においては、自社サービスサーバ１は、スマートフォンアプリに関するデータの取得であって、無料での取得に関する実績を管理してもよいし、スマートフォンアプリに関するデータの利用であって、無料での利用に関する実績を管理してもよい。

従来、サーバから端末側の情報処理装置へアプリケーションを提供し、提供されたアプリケーションを端末側の情報処理装置によって利用する情報処理システムにおいては、端末側におけるアプリケーションの利用の実績をサーバ側で把握することができることが望まれている。これに関して、上記実施形態によれば、自社サービスとは異なるサービスである、スマートフォンアプリ提供サーバ２におけるサービスの利用実績（本実施形態においては、購入実績）を、自社サービスサーバ１で管理することができる。実施事業者は、自身が開発したスマートフォンアプリであって、スマートフォンアプリ提供サーバ２によって提供されるスマートフォンアプリに関する実績を把握することができる。

なお、実績情報（本実施形態においては、ポイント情報）は、ユーザがスマートフォンアプリを利用した実績（本実施形態においては、購入の実績）を表す指標と言える。他の実施形態においては、自社サービスサーバ１は、実績情報に応じて特典を付与しなくてもよく、実績情報を顧客情報として実施事業者の内部で利用するだけであってもよい。

一方、実績情報に応じて特典を付与する場合には、特典によって、ユーザによるスマートフォンアプリの利用（ひいては、自社サービスの利用）を促進することができる。また、ゲーム機アプリに関する特典を付与する場合には、ゲーム機アプリの利用を促進することができる。例えば、ゲーム機アプリやゲーム機４自体を特典として付与することによって、ゲーム機アプリを利用する動機付けをユーザに与えることができ、利用を促進することができる。

なお、本実施形態においては、上記実績情報としてポイント情報を用いたが、実績情報は、ポイント情報に限らず、ユーザの利用実績を表す任意の情報であってよい。例えば、他の実施形態においては、実績情報は、これまでの購入金額の総額を示す情報であってもよいし、購入履歴を示す情報であってもよい。また、上記のように、実績情報は、購入に関する情報に限らず、スマートフォンアプリの無料での利用に関する、および／または、スマートフォンアプリのデータの無料での取得に関する履歴を示す情報であってもよい。

本実施形態においては、自社サービスサーバ１は、購入情報に関するスマートフォンアプリに関するデータの取得（本実施形態においては、データの購入）のために用いられる第２の識別情報（すなわち、他社アカウントＩＤ）を取得する。なお、他社アカウントＩＤは、スマートフォンアプリに関するデータの取得のために用いられるものに限らず、スマートフォンアプリの利用のために用いられるものであってもよい。また、自社サービスサーバ１（具体的には、管理サーバ３１）は、自社アカウントＩＤと他社アカウントＩＤとを関連付けて記憶する（図１８参照）。自社サービスサーバ１は、取得された購入情報に関して取得された他社アカウントＩＤに関連付けられる自社アカウントＩＤに関連付けられるポイント情報を特定する。

上記によれば、自社サービスサーバ１は、自社アカウントＩＤと他社アカウントＩＤとを関連付けて記憶しておくことによって、スマートフォンアプリのデータの取得に用いられた他社アカウントＩＤに基づいて、ポイント情報を更新すべき自社アカウントを容易に特定することができる。

なお、他の実施形態においては、自社サービスサーバ１は、自社アカウントＩＤと他社アカウントＩＤとを関連付けた情報を記憶していなくてもよい。例えば、図１８〜図２１に示したポイントを管理する処理を自社サービスサーバ１が実行しない場合には、自社サービスサーバ１は、上記情報を必ずしも記憶していなくてもよい。

本実施形態においては、自社サービスサーバ１は、スマートフォンアプリ提供サーバ２から送信される購入情報を取得する（図１９、図２０）。なお、他の実施形態においては、スマートフォンアプリ提供サーバ２に代えて（またはともに）スマートフォン３が購入情報を自社サービスサーバ１へ送信してもよい。このとき、自社サービスサーバ１は、スマートフォン３から送信される購入情報を取得してもよい。なお、本実施形態のように、自社サービスサーバ１が、スマートフォンアプリ提供サーバ２から送信される購入情報を取得し、当該購入情報を用いてポイントを管理する場合には、ユーザによって購入情報が改ざんされる可能性を低減することができる。

本実施形態においては、スマートフォン３は、他社アカウントＩＤに関連付けられる要求（すなわち、購入要求）をスマートフォンアプリ提供サーバ２へ送信することによって、スマートフォンアプリに関するデータをアプリ提供サーバから取得する（図１９に示すステップＳ９１およびＳ９３）。スマートフォンアプリ提供サーバ２は、要求に応じてスマートフォン３へスマートフォンアプリに関するデータを送信し（図１９に示すステップＳ９３）、当該データの送信に関する購入情報を、当該要求に関連付けられる他社アカウントＩＤと関連付けて（本実施形態においては、他社アカウントＩＤを購入情報に含めて）自社サービスサーバ１へ送信する（図１９に示すステップＳ９４）。

上記によれば、自社サービスサーバ１は、スマートフォンアプリに関するデータがスマートフォンアプリ提供サーバ２からスマートフォン３に取得される場合に、ポイント情報を更新すべき自社アカウントを容易に特定することができる。

本実施形態においては、自社サービスサーバ１は、スマートフォン３がスマートフォンアプリにおける処理を実行する場合にアクセスするゲームサーバ３４を含む。スマートフォン３は、スマートフォンアプリに関するデータを取得するための要求（すなわち、購入要求）を他社アカウントＩＤに関連付けてスマートフォンアプリ提供サーバへ送信する（図２０に示すステップＳ１０３）。自社サービスサーバ１は、要求に応じてスマートフォンアプリ提供サーバ２から送信される、スマートフォンアプリに関するデータの取得に関する条件が満たされたことの通知（すなわち、購入情報）を受信する（図２０に示すステップＳ１０６）。また、ゲームサーバ３４は、スマートフォンアプリ提供サーバからの通知を自社サービスサーバ１（管理サーバ３１であってもよいし、ゲームサーバ３４であってもよい。）が受信したことを条件として、スマートフォンアプリに関するデータをスマートフォン３へ送信する（図２０に示すステップＳ１０６）。

上記によれば、自社サービスサーバ１は、スマートフォンアプリに関するデータがゲームサーバ３４からスマートフォン３に取得される場合に、ポイント情報を更新すべき自社アカウントを容易に特定することができる。また、自社サービスサーバ１は、スマートフォンアプリに関するデータの取得に関する条件が満たされたことを確認した後、当該データをスマートフォン３へ送信することができる。

本実施形態においては、自社サービスサーバ１は、第１の種類のプラットホームと互換性を有し、かつ、第２の種類のプラットホームと互換性を有しない第１のアプリケーション（すなわち、ゲーム機アプリ）を、ゲーム機４へ送信するアプリ送信手段（すなわち、ゲーム機アプリ提供サーバ３２）をさらに備える。

上記によれば、自社サービスサーバ１は、スマートフォンアプリに関する利用実績を、ゲーム機アプリに関するサービスを利用するユーザに関連付けて管理することができる。上述のように、このような利用実績を用いることによって、ゲーム機アプリの利用を促進することができる。

また、自社サービスサーバ１は、このような利用実績をゲーム機アプリに関するマーケティングに用いることもできる。例えば、上記“（３−４）スマートフォンを用いてゲーム機アプリを購入する処理”で述べた、ゲーム機アプリの広告をスマートフォン３へ送信する処理において、上記の利用実績（すなわち、ポイント情報）が用いられてもよい。すなわち、管理サーバ３１は、上記ポイント情報に基づいて広告情報の内容を決定してもよい。

本実施形態においては、自社サービスサーバ１は、ゲーム機４におけるゲーム機アプリに関するデータの取得に関する実績（当該ゲーム機アプリの利用に関する実績でもよい）を示す追加の購入情報をさらに取得する。また、自社サービスサーバ１は、取得された追加の購入情報に基づいて、当該追加の購入情報に対応するゲーム機４に関する自社アカウントＩＤに関連付けられるポイント情報を更新する。

上記によれば、自社サービスサーバ１は、スマートフォンアプリに関する利用実績と、ゲーム機アプリに関する利用実績とを合わせて管理することができる。

本実施形態においては、自社サービスサーバ１は、管理サーバ３１に記憶されているポイント情報の内容が所定の条件（すなわち、取得条件）を満たしたことに応じて、ゲーム機アプリに関するデータ（ゲーム機アプリ自体のプログラムデータであってもよいし、ゲーム機アプリで利用されるゲームデータであってもよい）をゲーム機４へ送信する。

上記によれば、スマートフォンアプリに関する利用実績に応じた特典として、ゲーム機アプリに関するデータがユーザに付与される。これによれば、自社サービスサーバ１は、上記特典によってゲーム機アプリの利用を促進することができる。

本実施形態においては、自社サービスサーバ１は、管理サーバ３１に記憶されているポイント情報の内容が所定の条件（すなわち、取得条件）を満たしたことに応じて、当該ポイント情報に関連付けられる自社アカウントＩＤに対応するゲーム機４へ通知を行う。なお、この通知は、本実施形態においては、上記所定の条件を満たしたことに応じた特典を付与する旨の通知である。

上記によれば、自社サービスサーバ１は、スマートフォンアプリに関する利用実績が所定の条件を満たしたことをユーザに対して通知することができる。例えば、通知が、特典を付与する旨の通知である場合には、特典が付与されることをユーザに対して通知することができる。

本実施形態においては、自社サービスサーバ１は、スマートフォン３における、スマートフォンアプリに関するデータの取得時、および／または、スマートフォンアプリの利用時において、自社アカウントＩＤに基づく所定の処理（具体的には、ユーザの指示に応じて行われるログイン処理）に関する条件が満たされたか否か（すなわち、ログインが行われているか否か）を判定し、判定結果に応じてポイント情報の更新内容を異ならせる（例えば、ログインが行われている場合にポイント情報を更新し、ログインが行われていない場合にはポイント情報を更新しない）。

上記によれば、例えば上記所定の処理がログイン処理である場合には、ログインを行うことの動機付けをユーザに対して与えることができる。

また、本実施形態においては、相対的に汎用性の高い情報処理装置であるスマートデバイス（すなわち、スマートフォン３）におけるスマートフォンアプリの利用実績を、相対的に汎用性の低い情報処理装置であるゲーム機４に対する自社サービスにおいて管理する。これによれば、自社サービスサーバ１は、（ゲーム機アプリの利用実績を取得するだけの場合に比べて）より多くの利用実績を取得することができ、マーケティングや特典の付与に利用可能な有用な情報を取得することができる。

（変形例）
上記においては、スマートフォンアプリ提供サーバ２のような、アプリケーションを提供するサービスを行うシステムにおいて、図１８〜図２０に示す処理例を適用する場合を例として説明した。ここで、他の実施形態においては、アプリケーションを提供するシステムに限らず、物販を行うシステムにおいて上記処理例を適用することも可能である。例えば、第１のアカウントでユーザを管理する第１の物販サービスシステム（例えば、商品を販売するショッピングサイトを提供するショップサーバ）における利用実績（具体的には、購入実績）を、第２のアカウントでユーザを管理する第２のサービスシステム（任意のサービスを提供するサーバでよい）において管理するために、上記の処理例が用いられてもよい。

（３−７）スマートフォンとゲーム機とでフレンドリストを共有する処理
次に、図２２〜図２７を参照して、スマートフォン３とゲーム機４とでフレンドリストを共有する処理について説明する。本実施形態においては、端末（スマートフォン３および／またはゲーム機４）は、アプリケーションにおいて利用されるフレンドリストを記憶する。本実施形態においては、スマートフォン３とゲーム機４とでフレンドリストを共有する（つまり、スマートフォン３とゲーム機４とで同じフレンドリストを利用する）。したがって、本実施形態においては、スマートフォン３においてあるユーザがフレンドとして登録された場合、ゲーム機４においても当該ユーザがフレンドとして登録されることとなる。これによれば、端末において登録されるフレンドの利便性を向上することができる。また、一方の端末でフレンド登録されたユーザについては（後述するように、一定条件下で）他方の端末においてもフレンドとして取り扱われるので、他のユーザとの交流を促進することができる。これによって、スマートフォンアプリとゲーム機アプリとのうちの一方のアプリケーションを利用するユーザに対して、他方のアプリケーションの利用を促進することができる。以下、フレンドリストを共有する処理について詳細を説明する。

ここで、フレンドリストは、端末のユーザ（換言すれば、自社アカウントのユーザ）に対してフレンドとして登録された他のユーザのリストである。また、フレンドとは、スマートフォン３またはゲーム機４において実行されるアプリケーションにおいてユーザが交流することができる他のユーザを指す。例えば、ユーザは、フレンドである他のユーザとの間で、メッセージ、静止画、動画、および／または、音声のやり取りを行ったり、フレンドである他のユーザとゲームを協力してプレイしたりすることができる。また、フレンドである他のユーザについては、フレンドとして登録されていない他のユーザに比べてより多くの権限が与えられてもよい。例えば、あるユーザに関する個人情報（例えば、年齢や住所等）は、当該あるユーザのフレンドである他のユーザに対してのみ閲覧が許可されてもよい。

図２２は、スマートフォンとゲーム機とでフレンドリストを共有する処理の概要の一例を示す図である。また、図２３は、管理サーバに記憶されるユーザ管理情報の一例を示す図である。なお、図２３では、ユーザ管理情報に含まれる各種の情報のうち、本処理例において用いられる情報のみを示している。

（フレンドリストの構成）
図２２に示すように、本実施形態においては、基本フレンドリストと、アプリフレンドリストという２種類のフレンドリストが用意される。

基本フレンドリストは、自社アカウントのユーザに関するフレンドのリストである。本実施形態において、基本フレンドリストは、各端末に記憶される（図２２）。また、基本フレンドリストは、管理サーバ３１においても記憶される。図２３に示すように、ユーザ管理情報には、自社アカウントＩＤに関連付けて基本フレンドリストが記憶される。

一方、アプリフレンドリストは、アプリケーション（スマートフォンアプリまたはゲーム機アプリ）毎に設定され、当該アプリケーションにおいて利用されるフレンドリストである。すなわち、本実施形態においては、各アプリケーションにおいては、基本フレンドリストを用いるのではなく、当該アプリケーションに設定されるアプリフレンドリストを用いて、フレンドに関する処理が実行される。

上記のように、本実施形態においては、アプリケーション毎にアプリフレンドリストが設定される。これによれば、アプリケーション毎にフレンドを登録することができるので、フレンドの利便性を向上することができる。ここで、自社サービスに係る複数のアプリケーションには、いろいろな種類のアプリケーションが含まれており、フレンドの利用方法や利用目的はアプリケーション毎に異なることが考えられる。例えば、レースゲームのようなアプリケーションでは、フレンドは単なるゲーム上の対戦者であるのに対して、他のユーザとの交流を目的としたアプリケーションでは、ユーザがフレンドとチャットを行うことが可能である場合もある。

上記より、ユーザが「フレンドにしてもよい」と考えるレベルは、アプリケーション毎に異なると考えられる。つまり、あるアプリケーションにおいて登録されるフレンドであっても、他のアプリケーションにおいてはフレンドには登録したくないと、ユーザが思うことも考えられる。例えば、ユーザは、ある他のユーザに関して、特定のゲームアプリケーションにおける対戦相手としては許容できるものの、別のアプリケーションにおいてそのユーザとチャットをしたくはないと考えることもあり得る。

そこで、本実施形態においては、自社サービスサーバ１は、アプリケーション毎にアプリフレンドリストを設定する構成を採用している。これによれば、ユーザは、例えば、レースゲームの対戦相手として許容できる他のユーザについては、当該レースゲームのアプリケーションのアプリフレンドリストについてのみフレンド登録を行い、他のアプリフレンドリストについてはフレンド登録を行わないようにすることができる。このように、アプリケーション毎にフレンドを設定可能な構成とすることによって、フレンド設定の利便性を向上することができる。

なお、他の実施形態においては、自社サービスに係る複数のアプリケーションのうち、いくつかの所定のアプリケーションの組については、アプリフレンドリストが共通にされてもよい。上記アプリケーションの組としては、例えば、セーブデータを共有するスマートフォンアプリとゲーム機アプリとの組、あるいは、同じシリーズに属する複数のアプリケーション（例えば、あるゲームアプリケーションと、その続編のゲームアプリケーション）等が考えられる。なお、アプリフレンドリストを共通にする方法は任意である。自社サービスサーバ１は、上記アプリケーションの組に対して１つのアプリフレンドリストを記憶するようにしてもよいし、上記組に含まれるアプリケーション毎にそれぞれアプリフレンドリストを設定し、各アプリフレンドリストの内容を同期させるようにしてもよい。

図２２に示すように、スマートフォン３は、スマートフォンアプリに対応するアプリフレンドリストを記憶する。また、ゲーム機４は、ゲーム機アプリに対応するアプリフレンドリストを記憶する。さらに、図２２には図示しないが、図２３に示すように、管理サーバ３１は、スマートフォンアプリおよびゲーム機アプリに対応するアプリフレンドリストを含むアプリフレンド情報を記憶する。具体的には、管理サーバ３１が記憶するユーザ管理情報は、アプリケーション毎にアプリフレンド情報を含む。アプリフレンド情報は、アプリケーションのアプリＩＤと、当該アプリケーションのアプリフレンドリストとを含む。なお、アプリフレンド情報は、それに関連付けられる自社アカウントに対応する端末において実行可能なアプリケーション毎に記憶される。

なお、スマートフォン３は、基本フレンドリストおよび各アプリフレンドリストを記憶部１４に記憶する。ゲーム機４は、基本フレンドリストおよび各アプリフレンドリストを記憶部２５に記憶する。管理サーバ３１は、基本フレンドリストおよび各アプリフレンドリストを、自身の記憶部に記憶する。

なお、フレンドリスト（基本フレンドリストまたはアプリフレンドリスト）に含まれるフレンドの情報は、当該フレンドであるユーザの自社アカウントＩＤを含む。

詳細は後述するが、本実施形態においては、管理サーバにおいて基本フレンドリストを記憶することによって、スマートフォン３における基本フレンドリストと、ゲーム機４における基本フレンドリストとの内容が同期される。また、いずれかのアプリフレンドリストに対してフレンドの追加があった場合、一定条件下で、フレンドの追加が基本フレンドリストにも反映される。さらに、基本フレンドリストに変更があった場合、一定条件下で、基本フレンドリストの変更が他のアプリフレンドリストにも反映される。

（フレンドリストを変更する処理の具体例）
次に、図２２および図２４を参照して、フレンドリストが変更される場合に実行される処理の一例について説明する。図２４は、フレンドリストを変更する処理の流れの一例を示す図である。以下では、スマートフォン３において、あるスマートフォンアプリＡについてフレンドが新たに登録されたことに応じて、基本フレンドリストおよび他のアプリフレンドリスト（スマートフォンアプリＡ以外の他のスマートフォンアプリのアプリフレンドリスト）が変更される場合を例として説明する。

本処理例においては、まず、スマートフォン３は、あるスマートフォンアプリＡにおいて、新たなフレンドを登録する（図２２に示す（１）、図２４に示すステップＳ１１１）。具体的には、記憶部１４に記憶されている、スマートフォンアプリＡのアプリフレンドリスト（図２２に示す“アプリＡフレンドリスト”）に、上記新たなフレンドの自社アカウントＩＤを追加するように更新する。

ここで、アプリケーション（スマートフォンアプリおよび／またはゲーム機アプリ）においてフレンドが登録（換言すれば、追加）される方法は任意である。例えば、次の方法でフレンドが登録される。
（ａ）他のユーザからのフレンド申請による方法
アプリケーションが、他のユーザに対してフレンド申請を行う機能を有している場合、フレンド申請をユーザが許可することによって、フレンド申請を行った他のユーザがフレンドとして登録される。
（ｂ）情報の交換による方法
ユーザの端末が、他のユーザの端末と通信を行い、自社アカウントに関する情報（例えば、自社アカウントＩＤ）を交換することによって、当該他のユーザがフレンドとして登録される。
（ｃ）電話帳による方法
スマートフォン３に記憶されている電話帳に含まれる他のユーザ（すなわち、電話帳に電話番号が登録されているユーザ）が、所定の条件下でフレンドとして登録されてもよい。例えば、電話帳に含まれる他のユーザをユーザが指定したことに応じて、指定された他のユーザがフレンドとして登録されてもよい。ここで、管理サーバ３１は、スマートフォン３に記憶されている電話帳の情報を取得して記憶しておく。これによって、管理サーバ３１は、指定された他のユーザの電話番号に基づいて当該他のユーザの自社アカウントＩＤを特定することができる。また例えば、管理サーバ３１は、互いに相手のユーザが電話帳に登録されている場合、相手のユーザをフレンドとして登録してもよい。なお、スマートフォン３の電話帳からフレンドを登録する機能は、フレンドが追加されるアプリフレンドリストに対応するアプリケーション（すなわち、スマートフォンアプリ）によってスマートフォン３に実装されてもよいし、他のアプリケーションによってスマートフォン３に実装されてもよい。
（ｄ）他のネットワークサービスのフレンド関係に基づく方法
自社サービスとは異なる他のネットワークサービス（例えば、ＳＮＳ等）においてフレンドとして登録されている他のユーザが、所定の条件下でフレンドとして登録されてもよい。この場合、管理サーバ３１は、自社アカウントと、他のネットワークサービスにおけるアカウントとの関連付けを示す情報を記憶しておく。例えば、管理サーバ３１は、他のネットワークサービスにおけるフレンドのうちからユーザが指定したフレンドのユーザを、フレンドとして登録する。また例えば、管理サーバ３１は、他のネットワークサービスにおけるフレンド関係を示す情報を取得し、他のネットワークサービスにおいて互いに相手のユーザがフレンドとして登録されている場合、当該相手のユーザをフレンドとして登録してもよい。例えば、Ｔｗｉｔｔｅｒ（登録商標）においてユーザ同士が相互フォローの関係にある場合、相手のユーザがフレンドとして登録されてもよい。なお、他のネットワークサービスのフレンドを登録する機能は、フレンドが追加されるアプリフレンドリストに対応するアプリケーションによって端末に実装されてもよいし、他のアプリケーションによって端末に実装されてもよい。

また、ステップＳ１１１の処理において、スマートフォン３は、フレンド登録を行うための情報を取得した方法を示す取得方法情報を記憶しておく。フレンド登録を行うための情報とは、上記（ａ）および（ｂ）の方法における自社アカウントＩＤ、上記（ｃ）の方法における電話番号の情報、あるいは、上記（ｄ）の方法における他のネットワークサービスにおけるアカウント情報等である。

具体的には、スマートフォン３は、フレンドの登録方法が上記（ａ）の方法である場合、アプリケーション内におけるフレンド申請であることを示す情報、あるいは、当該アプリケーション（すなわち、スマートフォンアプリ）のアプリＩＤを、取得方法情報として記憶する。

また、フレンドの登録方法が上記（ｂ）の方法である場合、スマートフォン３は、情報の交換を行った方法（例えば通信方法等）を取得方法情報として記憶する。例えば、自社アカウントに関する情報の交換が、赤外線通信や、Ｂｌｕｅｔｏｏｔｈ（登録商標）といった近距離通信で行われた場合、スマートフォン３は、近距離通信による方法を示す情報を取得方法情報として記憶する。一方、自社アカウントに関する情報の交換が、インターネットやモバイル通信網等の広域ネットワークを介した通信で行われた場合、スマートフォン３は、広域ネットワークを介した通信による方法を示す情報を取得方法情報として記憶する。

また、ペアリングの操作が要求されるような方法で情報の交換が行われた場合、スマートフォン３は、ペアリングが要求される方法を示す情報を取得方法情報として記憶する。例えば、上記情報の交換を行う際に、情報を交換するペアとなる２つのスマートフォン３を特定するために、ペアリングの操作として、互いのスマートフォン３を軽くぶつける操作をユーザに対して要求する方法がある。この方法では、各スマートフォン３は例えば加速度センサ等によって自身がぶつけられたことを検知し、ぶつけられたことが同じタイミングで検知された２つのスマートフォン３をペアとして、情報の交換を行う。このような方法で情報の交換が行われた場合、ユーザ同士は対面していると推測することができる。

また、スマートフォン３が位置情報を検出可能である場合、スマートフォン３は、位置情報に基づいて取得方法情報を生成してもよい。すなわち、スマートフォン３は、情報の交換が行われた時の互いのスマートフォン３の位置関係を示す情報を取得方法情報として記憶してもよい。例えば、取得方法情報は、情報の交換が行われた時の各スマートフォン３の位置を示す情報であってもよいし、当該各スマートフォン３の位置が所定距離以内に含まれるか否かを示す情報であってもよい。

なお、ペアリングが要求される方法は、ペアリングの操作の検知結果に加えて、位置情報に基づいて、情報の交換を行うペアを特定する方法であってもよい。例えば、スマートフォン３は、互いのスマートフォンがぶつけられたことが同じタイミングで検知され、かつ、ぶつけられた時の互いの位置が所定距離以内であることを条件として、当該条件を満たす２つのスマートフォンを、上記ペアとして特定してもよい。なお、このとき、スマートフォン３は、ペアリングが要求される方法を示す情報を取得方法情報として記憶してもよいし、上記位置関係を示す情報を取得方法情報として記憶してもよい。

また、フレンドの登録方法が上記（ｃ）の方法である場合、スマートフォン３は、電話帳を用いた方法であることを示す情報を取得方法情報として記憶する。

フレンドの登録方法が上記（ｄ）の方法である場合、スマートフォン３は、他のネットワークサービスを示す情報を取得方法情報として記憶する。

ステップＳ１１１の次に、スマートフォン３は、ステップＳ１１１でアプリフレンドリストに追加されたフレンド（以下、「追加フレンド」と呼ぶ）を、一定条件下で基本フレンドリストに追加する（ステップＳ１１２）。以下、図２５を参照して、アプリフレンドリストのフレンドを基本フレンドリストに追加する処理（基本リスト追加処理）の詳細について説明する。

図２５は、基本リスト追加処理の流れの一例を示すフローチャートである。本実施形態では、スマートフォン３の処理部１３（具体的には、ＣＰＵ）が図２５に示す各ステップの処理を実行するものとして説明するが、上記フローチャートにおける一部のステップの処理を、ＣＰＵ以外のプロセッサや専用回路が実行するようにしてもよい。

また、図２５に示すフローチャート（後述する図２６〜図２８におけるフローチャートについても同様）における各ステップの処理は、単なる一例に過ぎず、同様の結果が得られるのであれば、各ステップの処理順序を入れ替えてもよいし、各ステップの処理に加えて（または代えて）別の処理が実行されてもよい。

図２５に示す基本リスト追加処理において、まず、スマートフォン３は、２人のユーザ（すなわち、基本フレンドリストに対応するユーザと、追加フレンドに対応するユーザ）が、対面した状況でフレンド登録が行われたか否かを判定する（ステップＳ１２１）。ステップＳ１２１の判定処理は、上記取得方法情報に基づいて行われる。ここで、ユーザ同士で対面した状況でフレンド登録が行われた場合、ユーザ同士は面識があるので、追加フレンドのユーザは信用できる相手であると言うことができる。上記ステップＳ１２１の処理は、ユーザ同士は面識があるか否かを判定するための処理であり、換言すれば、追加フレンドのユーザが信用できる相手であるか否かを判定するための処理である。

具体的には、上記取得方法情報が、アプリケーション内におけるフレンド申請であることを示す情報である場合（すなわち、上記（ａ）の方法で情報が取得された場合）、追加フレンドのユーザは、当該アプリケーションを利用する多数のユーザのうちの一人にすぎず、ユーザ同士が対面した状況でフレンド登録が行われた可能性は低いと推測することができる。したがって、この場合、スマートフォン３は、対面した状況でフレンド登録が行われなかったと判定する。

また、上記取得方法情報が、近距離通信による方法を示す場合、互いのユーザは、近くにいる状態で通信を行って情報を交換したと推測することができる。したがって、この場合、スマートフォン３は、対面した状況でフレンド登録が行われたと判定する。

一方、上記取得方法情報が、広域ネットワークを介した通信による方法を示す場合、互いのユーザは、離れた状態で通信を行って情報を交換したと可能性が高いと推測できる。したがって、この場合、スマートフォン３は、対面した状況でフレンド登録が行われなかったと判定する。

また、上記取得方法情報が、ペアリングが要求される方法を示す場合、互いのユーザは、近くにいる状態で通信を行って情報を交換したと推測することができる。したがって、この場合、スマートフォン３は、対面した状況でフレンド登録が行われたと判定する。

また、上記取得方法情報が、互いのスマートフォン３の位置関係を示す場合、スマートフォン３は、当該情報に基づいて、情報を交換した時に２人のユーザが近くにいた（すなわち、対面した状態で通信を行って情報を交換した）か否かを推測することができる。したがって、スマートフォン３は、情報を交換した時に２人のユーザが近くにいたか否かによって、対面した状況でフレンド登録が行われたか否かを判定する。

上記ステップＳ１２１の判定において、対面した状況でフレンド登録が行われたと判定される場合、後述するステップＳ１２４の処理が実行される。一方、上記ステップＳ１２１の判定において、対面した状況でフレンド登録が行われなかったと判定される場合、ステップＳ１２２の処理が実行される。

ステップＳ１２２において、スマートフォン３は、追加フレンドが、スマートフォン３の電話帳のユーザから追加されたものであるか否かを判定する。ステップＳ１２２の判定は、上記取得方法情報が、電話帳を用いた方法であることを示すか否かによって行われる。ここで、スマートフォン３の電話帳に登録されているユーザは、当該スマートフォン３のユーザが面識のあるユーザであると推測することができ、このようなユーザは、信用できる相手であると言うことができる。上記ステップＳ１２２の処理は、ユーザ同士は面識があるか否かを判定するための処理であり、換言すれば、登録されたフレンドのユーザが信用できる相手であるか否かを判定するための処理である。

ステップＳ１２２の判定結果が肯定となる場合、後述するステップＳ１２４の処理が実行される。一方、ステップＳ１２２の判定結果が否定となる場合、ステップＳ１２３の処理が実行される。

ステップＳ１２３において、スマートフォン３は、追加フレンドが、所定のネットワークサービスにおけるフレンドから追加されたものであるか否かを判定する。ステップＳ１２２の判定は、上記取得方法情報が、所定のネットワークサービスを示す情報か否かによって行われる。ここで、所定のネットワークサービスとは、例えば、ユーザの実名が登録されるネットワークサービスである。したがって、追加フレンドが、ユーザの実名が登録されるネットワークサービスにおけるフレンドから追加されたものである場合、ステップＳ１２２の判定結果は肯定となり、追加フレンドが、ユーザの実名が登録されないネットワークサービスにおけるフレンドから追加されたものである場合、ステップＳ１２２の判定結果は否定となる。ここで、追加フレンドのユーザの実名がわかっている場合、このようなユーザは信用できる相手と言うことができる。ステップＳ１２３の処理は、登録されたフレンドのユーザが信用できる相手であるか否かを判定するための処理である。

ステップＳ１２３の判定結果が肯定となる場合、後述するステップＳ１２４の処理が実行される。一方、ステップＳ１２３の判定結果が否定となる場合、スマートフォン３は、基本リスト追加処理を終了する。この場合、追加フレンドは基本フレンドリストには登録されず、基本フレンドリストは変更されない。

ステップＳ１２４において、スマートフォン３は、追加フレンドを基本フレンドリストに追加する。具体的には、スマートフォン３は、記憶部１４に記憶されている基本フレンドリストを、追加フレンドの自社アカウントＩＤを追加するように更新する。これによって、スマートフォンアプリＡのアプリフレンドリストの変更に応じて、スマートフォン３に記憶される基本フレンドリストが変更されたことになる（図２２に示す（２））。上記ステップＳ１２４の後、スマートフォン３は、基本リスト追加処理を終了する。

上記のように、本実施形態においては、追加フレンドを基本フレンドリストに追加するか否かの判定処理は、登録されたフレンドのユーザが信用できる相手であるか否かを判定することによって行われた。ここで、上記判定処理は、他の方法で行われてもよい。例えば、他の実施形態においては、スマートフォン３は、追加フレンドを基本フレンドリストに追加するか否かをユーザに対して問い合わせ、追加の要否をユーザの指示に従って決定してもよい。

また、特定のアプリケーションによっては、当該特定のアプリケーションにおけるフレンドはユーザと面識があると推測できる場合も考えられる。上記特定のアプリケーションの例としては、例えば、スマートフォン３の電話帳からアプリフレンドリストが生成されるようなアプリケーションが考えられる。このような場合、スマートフォン３は、上記ステップＳ１１１の処理において、アプリケーションのアプリＩＤを取得方法情報として記憶してもよい。そして、上記ステップＳ１１２の処理において、スマートフォン３は、取得方法情報が示すアプリＩＤが上記特定のアプリケーションに対応する場合には、追加フレンドを基本フレンドリストに追加すると判定してもよい。このように、スマートフォン３は、追加フレンドを基本フレンドリストに追加するか否かの判定処理を、追加されるアプリケーションが特定のアプリケーションであるか否かによって判定してもよい。

なお、アプリフレンドリストにおいてフレンドが削除された場合、スマートフォン３は、削除されたフレンドが基本フレンドリストに含まれていれば、基本フレンドリストからも当該フレンドを削除してもよい。また、他の実施形態においては、上記の場合において、スマートフォン３は、基本フレンドリストは変更しないようにしてもよい。

図２４の説明に戻り、ステップＳ１１２の次に、スマートフォン３は、基本フレンドリストの変更に応じて、一定条件下で他のアプリフレンドリストを変更する（図２２に示す（３）、図２４に示すステップＳ１１３）。ここで、他のアプリフレンドリストとは、スマートフォン３にインストールされているスマートフォンアプリのうち、すでにフレンドが追加されているスマートフォンアプリＡ以外のスマートフォンアプリのアプリフレンドリスト（例えば、図２２に示す“アプリＢフレンドリスト”）である。

本実施形態においては、所定の条件が満たされる場合、基本フレンドリストの変更に応じて上記他のアプリフレンドリストが変更される。ここで、上記所定の条件は任意である。本実施形態において、スマートフォン３は、スマートフォン３にインストールされているスマートフォンアプリのうちの所定のアプリケーションのアプリフレンドリストについて変更を加える。例えば、スマートフォン３は、上記所定のアプリケーションを示す情報として、基本フレンドリストの変更に応じてアプリフレンドリストを変更するか否かを示す設定情報をアプリケーション毎に記憶しておく。そして、上記ステップＳ１１３の処理において、スマートフォン３は、所定のアプリケーションに該当するか否かを上記設定情報に基づいて判定する。なお、上記所定のアプリケーションは、スマートフォン３において予め設定（記憶とも言う）されていてもよいし、ユーザによって設定されてもよい。すなわち、上記設定情報は、スマートフォン３の記憶部１４において予め記憶されていてもよいし、ユーザによって設定されてもよい。

また、他の実施形態においては、上記所定の条件は、アプリフレンドリストに対するフレンド追加に応じて基本フレンドリストを変更する場合に用いられる条件（またはその一部）と同じであってもよい。スマートフォン３は、上記ステップＳ１２１〜Ｓ１２３の判定処理のうち少なくとも１つについて判定を行い、判定結果が肯定となる場合に、上記他のアプリフレンドリストを変更するようにしてもよい。このとき、上記所定の条件は、スマートフォン３にインストールされているアプリケーション毎に設定されてもよい。

また、他の実施形態においては、スマートフォン３は、基本フレンドリストの変更に応じて無条件に上記他のアプリフレンドリストを変更してもよい。このとき、基本フレンドリストとアプリフレンドリストとで内容が一致することになる。

なお、本実施形態においては、上記ステップＳ１１２の処理において基本フレンドリストが変更されていない場合には、上記ステップＳ１１３の処理において、他のアプリフレンドリストは変更されない。ただし、他の実施形態においては、ステップＳ１１２の処理において基本フレンドリストが変更されていない場合であっても、上記ステップＳ１１１の処理においてアプリフレンドリストにフレンドが追加された場合には、スマートフォン３は、フレンドの追加を他のアプリフレンドリストについても一定条件下で反映させてもよい。

また、アプリフレンドリストにおいてフレンドが削除された場合、スマートフォン３は、削除されたフレンドが他のアプリフレンドリストに含まれていれば、当該他のアプリフレンドリストからも当該フレンドを削除してもよい。また、他の実施形態においては、上記の場合において、スマートフォン３は、他のアプリフレンドリストは変更しないようにしてもよい。

基本フレンドリストの変更に応じてアプリフレンドリストを変更するタイミングは任意である。本実施形態においては、スマートフォン３は、共通フレンドリストが変更されたタイミングでアプリフレンドリストを変更してもよいし、スマートフォンアプリが起動されたタイミングで当該スマートフォンアプリのアプリフレンドリストを変更してもよいし、スマートフォンアプリの実行中においてアプリフレンドリストが利用されるタイミングでアプリフレンドリストを変更してもよい。

次に、スマートフォン３は、上記ステップＳ１１１〜Ｓ１１３の処理によって変更されたフレンドリスト（基本フレンドリストおよび／またはアプリフレンドリスト）の情報を管理サーバ３１へ送信する（ステップＳ１１４）。具体的には、スマートフォン３は、フレンドリストを変更する旨の変更要求の情報を管理サーバ３１へ送信する。変更要求の情報は、変更内容を示す変更内容情報と、自社アカウントＩＤと、変更されたアプリフレンドリストを示すアプリＩＤ（アプリフレンドリストが変更された場合）とを含む。なお、変更内容情報は、変更されたフレンドリストの全体（すなわち、全てのフレンド）を示す情報であってもよいし、当該フレンドリストにおける変更箇所を示す情報であってもよい。

なお、上記ステップＳ１１１〜Ｓ１１４の処理が実行されるタイミングは、任意である。例えば、スマートフォンアプリＡの実行中に上記ステップＳ１１１が実行された場合、当該スマートフォンアプリＡの実行中に、ステップ１１２〜Ｓ１１４の処理も（例えば、ステップＳ１１１の処理に続けて）実行されてもよい。また例えば、スマートフォンアプリＡの実行中に上記ステップＳ１１１およびステップＳ１１２の処理が実行され、他のスマートフォンアプリに関するステップＳ１１３の処理は、当該他のスマートフォンアプリが起動された際に実行されてもよい。このとき、ステップＳ１１４の処理は、ステップＳ１１２の処理の後で実行されるとともに、ステップＳ１１３の処理の後で実行されてもよい。

また、基本フレンドリストに対して変更を加える処理は、アプリフレンドリストに対応するスマートフォンアプリではなく、専用のアプリケーション（「フレンドリスト変更アプリ」と呼ぶ）によって実行されてもよい（すなわち、スマートフォン３が専用のアプリケーションを実行することによって実現されてもよい）。一方、アプリフレンドリストに対して変更を加える処理は、当該アプリフレンドリストに対応するスマートフォンアプリによって実行されてもよいし、上記フレンドリスト変更アプリによって実行されてもよい。

変更要求の情報を受信した管理サーバ３１は、自身の記憶部に記憶されているフレンドリストを更新する（ステップＳ１１５）。すなわち、管理サーバ３１は、基本フレンドリストに変更がある場合、変更要求に含まれる自社アカウントＩＤに関連付けて記憶される基本フレンドリストを、当該変更要求に含まれる変更内容情報に基づいて更新する。そして、管理サーバ３１は、更新後の基本フレンドリストを記憶部に記憶する。これによって、スマートフォン３に記憶されている基本フレンドリストと、管理サーバ３１に記憶されている基本フレンドリストとの内容が同期される（図２２に示す（４））。

また、アプリフレンドリストに変更がある場合、管理サーバ３１は、変更要求に含まれる自社アカウントＩＤに関連付けて記憶されるアプリフレンドリストのうち、当該変更要求に含まれるアプリＩＤに関連付けられるアプリフレンドリストを、当該変更要求に含まれる変更内容情報に基づいて更新する。そして、管理サーバ３１は、更新後のアプリフレンドリストを記憶部に記憶する。なお、変更要求が複数のスマートフォンアプリに関する情報を含む場合、管理サーバ３１は、当該複数のスマートフォンアプリのアプリフレンドリストをそれぞれ更新する。これによって、スマートフォン３に記憶されているアプリフレンドリストと、管理サーバ３１に記憶されているアプリフレンドリストとの内容が同期される。

管理サーバ３１は、自身に記憶されている基本フレンドリストを更新した場合、基本フレンドリストに変更があったことを示す変更通知の情報をゲーム機４へ送信する（ステップＳ１１６）。変更通知の情報は、基本フレンドリストに関する変更内容を示す変更内容情報を含む。なお、管理サーバ３１は、変更通知の情報の送信先を、変更された基本フレンドリストと同じユーザ管理情報に含まれるゲーム機ＩＤによって特定することができる。

なお、管理サーバ３１が変更通知の情報を送信するタイミングは任意である。管理サーバ３１は、プッシュ通知（すなわち、プッシュ送信による通知）で変更通知の情報をゲーム機４へ送信してもよい。また、管理サーバ３１は、ゲーム機４からの要求（例えば、上述のログイン要求）があったことに応じて、変更通知の情報を当該ゲーム機４へ送信してもよい。

変更通知の情報を受信すると、ゲーム機４は、自身の記憶部２５に記憶されている基本フレンドリストを変更通知の情報に基づいて更新する（ステップＳ１１７）。すなわち、ゲーム機４は、変更通知の情報に含まれる変更内容情報に従って上記基本フレンドリストを更新し、更新後の基本フレンドリストを記憶部２５に記憶する。これによって、管理サーバ３１に記憶されている基本フレンドリストと、ゲーム機４に記憶されている基本フレンドリストとの内容が同期される（図２２に示す（５））。

また、ゲーム機４において基本フレンドリストが変更されると、ゲーム機４は、基本フレンドリストの変更に応じて、一定条件下でアプリフレンドリスト（図２２に示す“アプリＣフレンドリスト”および“アプリＤフレンドリスト”）を変更する（図２２に示す（６）、図２４に示すステップＳ１１８）。ここで、ゲーム機において、基本フレンドリストの変更に応じてアプリフレンドリストを変更するか否かの条件は任意である。本実施形態においては、ゲーム機４におけるステップＳ１１８の処理は、スマートフォン３における上記ステップＳ１１３の処理と同様の方法で実行されてよい。すなわち、ゲーム機４は、ゲーム機４にインストールされているゲーム機アプリのうちの所定のアプリケーションのアプリフレンドリストについて変更を加えてもよい。また、ゲーム機４は、アプリフレンドリストに対するフレンド追加に応じて基本フレンドリストを変更する場合に用いられる条件（またはその一部）と同じ条件を用いて、アプリフレンドリストについて変更を加えるか否かを判定してもよい。また、スマートフォン３において用いられる条件と、ゲーム機４において用いられる条件とは、同じであってもよいし、異なっていてもよい。

また、上記ステップＳ１１８において、ゲーム機４は、スマートフォン３においてフレンドが追加されたスマートフォンアプリ（すなわち、上述のスマートフォンアプリＡ）に関連するゲーム機アプリのアプリフレンドリストを変更してもよい。ここで、スマートフォンアプリに関連するゲーム機アプリとは、例えば、当該スマートフォンアプリの実行中に広告情報が提示されるゲーム機アプリ（上記“（３−４）スマートフォンを用いてゲーム機アプリを購入する処理”参照）であってもよいし、当該スマートフォンアプリとセーブデータを共有することができるゲーム機アプリ（上記“（３−５）スマートフォンアプリとゲーム機アプリでセーブデータを共有する処理”参照）であってもよい。

以上のように、図２４に示す一連の処理においては、スマートフォン３において基本フレンドリストが変更された場合、ゲーム機４においても基本フレンドリストが変更される。本実施形態においては、ゲーム機４において基本フレンドリストが変更された場合も同様に、スマートフォン３において基本フレンドリストが変更される。すなわち、ゲーム機４におけるあるゲーム機アプリにおいてアプリフレンドリストにフレンドが追加された場合、ゲーム機４は、当該フレンドを基本フレンドリストに一定条件下で追加する。また、ゲーム機４は、基本フレンドリストに追加したフレンドを、他のアプリフレンドリストに一定条件下で追加する。さらに、ゲーム機４は、変更されたフレンドリスト（基本フレンドリストおよび／またはアプリフレンドリスト）の情報に関する変更要求の情報を管理サーバ３１へ送信する。管理サーバ３１は、自身に記憶されているフレンドリストを変更要求の情報に基づいて変更し、基本フレンドリストに関する変更通知を、上記ゲーム機４に対応するスマートフォン３へ送信する。スマートフォン３は、自身に記憶されている基本フレンドリストを変更通知の情報に基づいて変更する。

なお、アプリフレンドリストの変更に応じて基本フレンドリストを変更するか否かを判定するための条件、および、基本フレンドリストの変更に応じてアプリフレンドリストを変更するか否かを判定するための条件は、スマートフォン３とゲーム機４とで同じであってもよいし、異なっていてもよい。

また、本実施形態においては、基本フレンドリストは、アプリフレンドリストの変更に応じて変更される他、ユーザによる基本フレンドリストに対する変更操作によっても変更される。本実施形態においては、端末（すなわち、スマートフォン３および／またはゲーム機４）は、上述のフレンドリスト変更アプリによって、ユーザが基本フレンドリストに対して直接変更を行うことができる。なお、基本フレンドリストに対するフレンドの追加は、上述の（ｂ）〜（ｄ）の方法によって行われる。

また、本実施形態においては、管理サーバ３１が、ユーザに対して、フレンドとして登録される候補となる他のユーザを提示するようにしてもよい。具体的には、管理サーバ３１は、複数のユーザがそれぞれ所有する端末から、電話帳の情報および／または他のネットワークサービスにおいて登録されているフレンドの情報を取得しておく。そして、所定のタイミングで、管理サーバ３１は、ユーザの電話帳に登録されている他のユーザのうちから、「他のユーザの電話帳に当該ユーザが登録されている（つまり、互いに相手が電話帳に登録されている）」という条件を満たす他のユーザを選出する。この選出処理は、例えば、当該ユーザの電話帳に登録されている全ての他のユーザについて行われてもよい。そして、管理サーバ３１は、選出された他のユーザを、フレンドの候補として当該ユーザの端末へ通知する。また、管理サーバ３１は、他のネットワークサービスにおいて登録されているフレンドについても電話帳と同様に、「互いに相手が他のネットワークサービスにおいてフレンドに登録されている」という条件を満たす他のユーザを選出し、選出されたユーザをフレンドの候補として当該ユーザの端末へ通知する。これらの通知には、フレンドの候補となるユーザに関する自社アカウントＩＤが含まれ、さらに、当該ユーザのニックネーム等の情報が含まれていてもよい。

上記の通知はどのような方法で行われてもよい。例えば、管理サーバ３１は、ユーザが所有する端末に対して、上記の通知をプッシュ送信で送信してもよい。また、上記所定のタイミングは任意であるが、例えば、管理サーバ３１は、所定のアプリケーションが起動されたタイミングで、ユーザが所有する端末に対して上記の通知を送信してもよい。なお、上記所定のアプリケーションは、上記のフレンドリスト変更アプリであってもよいし、予め定められた（フレンドリスト変更アプリとは異なるアプリケーションであってもよいし、端末にインストールされている、自社サービスに対応する全てのアプリケーションであってもよい。また、上記ステップＳ１１１の処理において、スマートフォン３は、管理サーバ３１から上記通知を受信し、受信した通知によって提示されるフレンドの候補に基づいて新たなフレンドを登録するようにしてもよい。

上記通知を受信した端末は、フレンドの候補として提示された他のユーザのうちから、フレンドとして登録する他のユーザを指定する入力指示を受け付ける。そして、端末は、ユーザによって指定された他のユーザをフレンドとして登録する。なお、フレンド登録が行われるフレンドリストは、基本フレンドリストであってもよいし、アプリフレンドリストであってもよいし、フレンド登録が行われるフレンドリストをユーザが指定するようにしてもよい。また、他の実施形態においては、管理サーバ３１は、上記選出処理によって選出された他のユーザを自動的に（換言すれば、ユーザの指示の有無にかかわらず）フレンドとして登録するようにしてもよい。

上記によれば、ユーザは、電話帳および／または他のネットワークサービスにおいて登録されている他のユーザについてフレンド登録を行うことができる。これによって、ユーザによるフレンド登録の作業を簡易にすることができる。

また、基本フレンドリストを変更するか否かの判定処理（ステップＳ１１２）は、サーバ側（例えば、管理サーバ３１）によって行われてもよい。このとき、スマートフォン３およびゲーム機４のうちの一方の端末においてアプリフレンドリストに変更があった場合、当該一方の端末は、変更があったことを示す通知の情報を管理サーバ３１へ送信する。この通知の情報には、上記変更要求の情報と同様、変更内容を示す変更内容情報と、自社アカウントＩＤと、変更されたアプリフレンドリストを示すアプリＩＤ（アプリフレンドリストが変更された場合）とを含む。上記の情報を受信すると、管理サーバ３１は、受信した情報に基づいて、基本フレンドリストを変更するか否かを判定し、判定結果に応じて基本フレンドリストを変更する。なお、基本フレンドリストを変更する条件は、上記ステップＳ１１２の処理と同様であってもよい。基本フレンドリストを変更した場合、管理サーバ３１は、上述の変更通知の情報を他方の端末へ送信する。

さらに、管理サーバ３１は、アプリフレンドリストを変更するか否かの判定処理（ステップＳ１１３）を実行してもよい。すなわち、管理サーバ３１は、上記ステップＳ１１３と同様の方法で、基本フレンドリストの変更に応じてアプリフレンドリストを変更する。変更されるアプリフレンドリストは、スマートフォンアプリのアプリフレンドリストと、ゲーム機アプリのアプリフレンドリストとの両方であってよいし、一方であってもよい。スマートフォンアプリのアプリフレンドリストを更新した場合、管理サーバ３１は、上述の変更通知の情報をスマートフォン３へ送信する。ゲーム機アプリのアプリフレンドリストを更新した場合、管理サーバ３１は、上述の変更通知の情報をゲーム機４へ送信する。

また、管理サーバ３１は、フレンドリストを変更するか否かの判定を、上述したユーザ関連情報に基づいて行うようにしてもよい。例えば、あるユーザ（換言すればある自社アカウント）に関する基本フレンドリストにフレンドを追加する場合、管理サーバ３１は、当該あるユーザの地域（すなわち、住んでいる地域または国）と追加するフレンドの地域とに基づいて上記判定を行ってもよい。具体的には、管理サーバ３１は、２人のユーザの地域が同じである場合、フレンドを追加すると判定し、２人のユーザの地域が異なる場合、フレンドを追加しないと判定してもよい。また例えば、管理サーバ３１は、基本フレンドリストの変更に応じてアプリフレンドリストを変更するか否かの判定を、ユーザ関連情報に含まれるアプリケーションの利用履歴の情報に基づいて行うようにしてもよい。例えば、管理サーバ３１は、利用履歴の情報に基づいてアプリケーションの利用頻度を判別し、利用頻度が高いアプリケーションのアプリフレンドリストに対して変更を行うようにしてもよい。

（上記処理による作用効果）
以上のように、本実施形態においては、情報処理システムは、第１の種類のプラットホームを有する第１の情報処理装置（すなわち、スマートフォン３）と、第１の種類とは異なる第２の種類のプラットホームを有する第２の情報処理装置（すなわち、ゲーム機４）とを含む。情報処理システム（具体的には、管理サーバ３１）は、ユーザの情報に関連付けて登録された他のユーザの情報を示すユーザリストであって、スマートフォン３およびゲーム機４において利用可能な基本ユーザリスト（すなわち、基本フレンドリスト）を記憶する（図２２）。管理サーバ３１は、スマートフォン３からのリスト変更通知（すなわち、上述の変更要求）に応じて基本フレンドリストを変更する（図２２に示す（４）、図２４に示すステップＳ１１５）。ゲーム機４は、ゲーム機４において実行される所定のアプリケーションにおいて用いられるアプリ用ユーザリスト（すなわち、アプリフレンドリスト）の内容を、基本フレンドリストに基づいて設定する（図２２に示す（６）、図２４に示すステップＳ１１８）。

従来、アプリケーションにおいてコミュニケーション等を行う他のユーザをフレンドとして登録する情報処理システムにおいては、登録されるフレンドに関する利便性を向上することが望まれている。これに関して、上記実施形態によれば、情報処理システムにおいては、スマートフォン３とゲーム機４とで利用可能な基本フレンドリストと、アプリフレンドリストとが別に設けられる。基本フレンドリストによって、異なる端末間でフレンドリストを共有したり、一方のフレンドリストにおける変更を他方のフレンドリストに反映させたりすることができる。例えば、スマートフォン３で新たにフレンドが登録された場合、そのフレンドがゲーム機４のフレンドとしても登録されることになる。上記によって、各端末において登録されるフレンドに関する利便性を向上することができる。

また、上記によれば、基本フレンドリストとは別にアプリフレンドリストを設けることによって、基本フレンドリストに基づくフレンドリストをアプリケーション毎に設定することができる。例えば、あるアプリケーションにおいて登録されるフレンドであっても、他のアプリケーションにおいてはフレンドには登録したくないとユーザが考える場合もある。これに対して、上記実施形態によれば、アプリケーション毎にフレンドを設定することができるので、各アプリケーションにおけるフレンドの利便性を向上することができる。

なお、上記実施形態においては、管理サーバ３１によって基本フレンドリストを記憶しておくことで、スマートフォン３とゲーム機４との間で基本フレンドリストの同期を取るようにした。ここで、他の実施形態においては、サーバ側で基本フレンドリストを記憶せず、スマートフォン３とゲーム機４とによって基本フレンドリストの同期を取るようにしてもよい。すなわち、スマートフォン３およびゲーム機４のいずれか一方の端末において基本フレンドリストに変更があった場合、当該一方の端末は、上述の変更要求の情報を他方の端末へ送信する。なお、変更要求の情報は、一方の端末からサーバを介して他方の端末へ送信されてもよい。変更要求の情報を受信した他方の端末は、変更要求の情報に基づいて、自身に記憶されている基本フレンドリストを変更する。このように、他の実施形態においては、情報処理システムは、サーバ側で基本フレンドリストを記憶しない態様で基本フレンドリストを管理してもよい。

また、本実施形態においては、スマートフォン３における基本フレンドリストに応じてゲーム機４におけるアプリフレンドリストが変更されるとともに、ゲーム機４における基本フレンドリストに応じてスマートフォン３におけるアプリフレンドリストが変更される。すなわち、管理サーバ３１は、（スマートフォン３からのリスト変更通知に応じて変更するとともに、）ゲーム機４からのリスト変更通知に応じて基本フレンドリストを変更する。そして、スマートフォン３は、スマートフォン３において実行される所定のアプリケーションにおいて用いられるアプリ用ユーザリストの内容を、基本フレンドリストに基づいて設定する。

上記によれば、基本フレンドリストに基づいて、スマートフォン３とゲーム機４との両方におけるアプリフレンドリストが設定される。

また、本実施形態においては、情報処理システムは、携帯電話網を介した通信機能を有するスマートデバイスである第１の情報処理装置（すなわち、スマートフォン３）と、ゲーム操作を行うための方向指示部を備え、ゲームアプリケーションを実行可能なゲーム装置である第２の情報処理装置（すなわち、ゲーム機４）とを含むと言える。ここで、情報処理システム（具体的には、管理サーバ３１）は、ユーザの情報に関連付けて登録された他のユーザの情報を示すユーザリストであって、スマートフォン３およびゲーム機４において利用可能な基本ユーザリスト（すなわち、基本フレンドリスト）を記憶する（図２２）。管理サーバ３１は、スマートフォン３および／またはゲーム機４からのリスト変更通知（すなわち、上述の変更要求）に応じて基本フレンドリストを変更する（図２２に示す（４）、図２４に示すステップＳ１１５）。

上記によれば、情報処理システムにおいては、スマートフォン３とゲーム機４とで利用可能な基本フレンドリストが設けられるので、上述のように、異なる種類の端末間でフレンドリストを共有したり、一方のフレンドリストにおける変更を他方のフレンドリストに反映させたりすることができる。これによって、各端末において登録されるフレンドに関する利便性を向上することができる。

また、本実施形態においては、情報処理システムは、第１の種類のプラットホームを有する第１の情報処理装置（すなわち、スマートフォン３）と、第１の種類とは異なる第２の種類のプラットホームを有する第２の情報処理装置（ゲーム機４）とを含むと言える。情報処理システムは、ユーザの情報に関連付けて登録された他のユーザの情報を示すユーザリストであって、スマートフォン３およびゲーム機４において利用可能な基本ユーザリスト（すなわち、基本フレンドリスト）を記憶する（図２２）。情報処理システムは、スマートフォン３および／またはゲーム機４において実行される所定のアプリケーションにおいて利用されるアプリ用ユーザリスト（すなわち、アプリフレンドリスト）に対して新たなユーザ（すなわち、フレンド）が追加された場合、当該新たなフレンドに関する情報（本実施形態においては、上述の取得方法情報）を取得し、当該新たなフレンドに関する情報の取得方法に関する所定の条件が満たされるか否かを判定する（図２４に示すステップＳ１１２、図２５）。上記所定の条件が満たされると判定される場合、基本フレンドリストへ当該新たなフレンドの情報が追加される（ステップＳ１２４）。

上記によれば、情報処理システムにおいては、スマートフォン３とゲーム機４とで利用可能な基本フレンドリストが設けられるので、上述のように、異なる種類の端末間でフレンドリストを共有したり、一方のフレンドリストにおける変更を他方のフレンドリストに反映させたりすることができる。これによって、各端末において登録されるフレンドに関する利便性を向上することができる。また、上記によれば、アプリフレンドリストに新たなフレンドが追加された場合、当該フレンドに関する情報の取得方法に関する所定の条件に応じて、フレンドの追加が基本フレンドリストにも反映される。したがって、情報の取得方法に応じた適切な内容となるように基本フレンドリストを管理することができる。

本実施形態においては、新たなフレンドに関する情報の取得方法が、新たなフレンドが信用できると推測される所定の方法であることを上記所定の条件として、当該所定の条件が満たされる場合に、基本フレンドリストへ当該新たなユーザの情報が追加される。

上記によれば、上記新たなフレンドが信用できると推測される場合に、当該新たなフレンドは基本フレンドリストに反映される。したがって、ある一部のアプリフレンドリストにおいて登録された、信用できない可能性があるフレンドが、基本フレンドリストに反映される可能性を低減することができる。

なお、上記所定の条件の具体的な例としては、「新たなフレンドに関する情報の取得方法が、ユーザが当該新たなユーザと面識があると推測される所定の方法であること」という条件が考えられる。

より具体的には、上記所定の条件は、次の条件のうち少なくとも１つを含むものであってもよい。
・新たなユーザに関する情報を取得したときの通信方法に関する条件（例えば、近距離通信であるか、それとも、広域ネットワークを介した通信であるか）
・新たなユーザに関する情報を取得したときのスマートフォン３および／またはゲーム機４の位置とその通信相手の装置の位置とに関する条件（例えば、両者の位置が所定距離以内に含まれるか否か）
・新たなユーザに関する情報の取得元となる他のユーザリストに関する条件（例えば、他のユーザリストが、スマートフォン３に記憶される電話帳、または、ユーザの実名が登録されるネットワークサービスにおけるユーザリストであるか否か）

上記の条件を用いることによって、上記新たなフレンドが信用できるか否かを容易に判定することができる。

本実施形態においては、基本ユーザリストは、スマートフォン３およびゲーム機４において共通に利用される共通ユーザリスト（本実施形態においては、図２２に示す基本フレンドリスト）を含む。これによれば、スマートフォン３とゲーム機４とで同じ内容の基本フレンドリストを利用することができる。

なお、他の実施形態においては、スマートフォン３において利用される基本フレンドリストと、ゲーム機４において利用される基本フレンドリストとは、互いの内容が一致するように同期が取られる必要はなく、一方の基本フレンドリストの変更が他方の基本フレンドリストに対して一定条件下で反映されてもよい。例えば、基本フレンドリストは、スマートフォン３において利用される第１の部分リストと、ゲーム機４において利用される第２の部分リストとを含んでいてもよい。このとき、スマートフォン３において所定の条件が満たされたこと（例えば、アプリフレンドリストが変更されたこと）に応じて第１の部分リストが変更され、ゲーム機４において所定の条件が満たされたことに応じて第２の部分リストを変更される。そして、第１の部分リストおよび第２の部分リストのいずれか一方の部分ユーザリストを変更した場合、その変更内容が、所定の条件下で他方の部分リストに反映される（他の実施形態においては、無条件に反映されてもよい）。なお、上記所定の条件は、上記実施形態における、アプリフレンドリストの変更を基本フレンドリストに対して反映させる際に用いられる条件と同様の条件（すなわち、ステップＳ１２１〜Ｓ１２３の判定処理において用いられる条件）であってもよい。

上記によれば、スマートフォン３において利用される基本フレンドリストと、ゲーム機４において利用される基本フレンドリストとを別々に管理することができ、異なる内容となるように管理することもできる。

本実施形態においては、情報処理システムは、スマートフォン３と通信可能であり、かつ、ゲーム機４と通信可能な自社サービスサーバ１（より具体的には、管理サーバ３１）を含む。管理サーバ３１は、基本フレンドリストを識別情報（すなわち、自社アカウントＩＤ）と関連付けて記憶する（図２３）。スマートフォン３は、自社アカウントＩＤを管理サーバ３１へ送信する（ステップＳ１１４）。管理サーバ３１は、スマートフォン３からのリスト変更通知に応じて、当該スマートフォン３から受信した自社アカウントＩＤに関連付けられる基本フレンドリストを変更する（ステップＳ１１５）。

上記によれば、識別情報を用いることによって、管理サーバ３１において基本フレンドリストを識別情報毎（換言すれば、自社アカウント毎）に管理することができる。

本実施形態においては、各端末は、他の端末と識別情報（換言すれば、アカウント情報。具体的には、自社アカウントＩＤ）を交換することによってフレンド登録を行う。すなわち、スマートフォン３（ゲーム機４も同様）が、自身のユーザとは異なる他のユーザの自社アカウントＩＤを、自身とは異なる他のスマートフォン３から取得した場合、基本フレンドリストは、所定の条件下で、取得された識別情報に基づいて変更される（上記（ｂ）の方法）。

上記によれば、アカウント情報を交換することによってフレンド登録を容易に行うことができる。

本実施形態においては、スマートフォン３（ゲーム機４も同様）は、当該スマートフォン３において実行される所定のアプリケーションにおいて用いられるアプリ用ユーザリスト（本実施形態においては、アプリフレンドリスト）が変更された場合に、所定の条件下でリスト変更通知を送信する（ステップＳ１１４）。

上記によれば、アプリフレンドリストの変更を基本フレンドリストに対して反映させることができる。

本実施形態においては、スマートフォン３（ゲーム機４も同様）は、当該スマートフォン３において基本フレンドリストに対して新たなフレンドの情報を追加するための変更操作が行われた場合、リスト変更通知を送信する。

上記によれば、基本フレンドリストの内容をユーザが直接的に（換言すれば、アプリフレンドリストの変更に応じて変更するのではなく）変更することができる。

また、本実施形態においては、ユーザが常に携帯すると推測されるスマートデバイスであるスマートフォン３におけるフレンド登録が、ゲーム機４におけるアプリフレンドリストのフレンドに反映されることとなる。したがって、ユーザがゲーム機４を持ち歩かない場合であっても、スマートフォン３においてフレンドを増やすことで、ゲーム機４におけるフレンドを増やすことができる。したがって、ユーザは、より多くのフレンドを登録することができる。

また、本実施形態における情報処理システムは、ユーザの情報に関連付けて登録された他のユーザの情報を示すユーザリストであって、スマートフォン３において利用可能な第１の基本ユーザリスト（すなわち、スマートフォン３に記憶される基本フレンドリスト、または、管理サーバ３１に記憶される基本フレンドリスト）を記憶する。また、情報処理システムは、ユーザの情報に関連付けて登録された他のユーザの情報を示すユーザリストであって、ゲーム機４において利用可能な第２の基本ユーザリスト（すなわち、ゲーム機４に記憶される基本フレンドリスト、または、管理サーバ３１に記憶される基本フレンドリスト）を記憶する。情報処理システムは、第１の基本ユーザリストに対する変更があった場合、当該変更に応じて第２の基本ユーザリストを変更する（図２４に示すステップＳ１１５またはステップＳ１１７）。

上記によれば、情報処理システムにおいては、スマートフォン３とゲーム機４とで利用可能なユーザリストが設けられるので、異なる種類の端末間でユーザリストを共有したり、一方のユーザリストにおける変更を他方のユーザリストに反映させたりすることができる。これによって、各端末において登録されるフレンドに関する利便性を向上することができる。

また、他の実施形態においては、情報処理システムは、第１の基本ユーザリスト（上記第１の部分リストと言うこともできる。）において新たなユーザが追加される場合、当該新たなユーザに関する情報（例えば、上述の取得方法情報）を取得し、当該新たなユーザに関する情報の取得方法に関する所定の条件が満たされるか否かを判定してもよい。情報処理システムは、所定の条件が満たされると判定される場合、第２の基本ユーザリスト（上記第２の部分リストと言うこともできる。）へ当該新たなユーザの情報を追加してもよい。なお、上記所定の条件は、上記実施形態における、アプリフレンドリストの変更を基本フレンドリストに対して反映させる際に用いられる条件と同様の条件（すなわち、ステップＳ１２１〜Ｓ１２３の判定処理において用いられる条件）であってもよい。

上記によれば、一方の基本ユーザリストに新たなユーザが追加された場合、当該ユーザに関する情報の取得方法に関する所定の条件に応じて、フレンドの追加が他方の基本フレンドリストにも反映される。したがって、情報の取得方法に応じた適切な内容となるように各基本フレンドリストを管理することができる。

また、本実施形態における情報処理システムは、ユーザの情報に関連付けて登録された他のユーザの情報を示すユーザリスト（すなわち、フレンドリスト）を記憶する情報処理システムである。情報処理システム（例えば、スマートフォン３またはゲーム機４）は、第１のユーザリスト（具体的には、アプリフレンドリスト）と、第２のユーザリスト（具体的には、基本フレンドリスト）とを記憶する。情報処理システムは、新たなユーザの情報を追加するための条件が満たされた場合（例えば、アプリフレンドリストに対するフレンド登録が行われた場合）、当該新たなユーザの情報が、少なくともアプリフレンドリストに追加すべき情報であるか、それとも、少なくとも基本フレンドリストに追加すべき情報であるかを分類する（ステップＳ１１２およびＳ１１３）。

上記によれば、新たなフレンドを、複数のフレンドリストに対して分類して登録することができる。

［４．各装置における処理の具体例］
次に、本実施形態の情報処理システムに含まれる各装置（すなわち、各サーバおよび各端末）における処理の具体例について説明する。以下では、上記（３−１）〜（３−７）における処理が実行される場合における各装置における処理の具体例について説明する。

（４−１）スマートフォン３における処理
まず、本実施形態におけるスマートフォン３における処理の具体例について説明する。図２６は、スマートフォンアプリを実行する場合のスマートフォン３における処理の流れの一例を示すフローチャートである。図２６に示す一連の処理は、スマートフォン３においてスマートフォンアプリが起動されることに応じて開始される。本実施形態では、スマートフォン３の処理部１３（具体的には、ＣＰＵ）が、スマートフォンアプリを実行することによって、図２６に示す各ステップの処理を実行するものとして説明するが、上記フローチャートにおける一部のステップの処理を、ＣＰＵ以外のプロセッサや専用回路が実行するようにしてもよい。

まず、ステップＳ１３１において、処理部１３は、ログイン時処理として、上述したステップＳ１２およびＳ１６の処理を実行する。ログイン時処理によって、スマートフォンアプリにおける処理（ここでは、ゲーム処理）の開始に必要なデータが取得され、当該処理が開始される。ステップＳ１３１の次に、ステップＳ１３２の処理が実行される。ステップＳ１３２〜Ｓ１３８の一連の処理は、スマートフォンアプリが終了するまで繰り返し実行される。

ステップＳ１３２において、処理部１３は、上述したステップＳ１７におけるゲーム処理を実行する。なお、ゲーム処理の内容は、実行されるスマートフォンアプリ毎に異なる。ゲーム処理が繰り返し実行されることで、ゲームが進行する。ステップＳ１３２の処理の後、条件が満たされる場合にステップＳ１３３〜Ｓ１３７の処理が実行される。なお、ステップＳ１３３〜Ｓ１３７の処理は、これらの処理を実行する条件が満たされた場合に実行されればよく、ステップＳ１３２〜Ｓ１３７の処理ループにおいて毎回実行される必要はない。

ステップＳ１３３において、処理部１３は、ゲーム機アプリ購入処理を実行する。ゲーム機アプリ購入処理は、ゲーム機アプリの広告を表示し、ユーザによる指示に応じてゲーム機アプリを購入するための処理である。具体的には、ゲーム機アプリ購入処理として、上述のステップＳ５４，Ｓ５５，Ｓ５７，Ｓ５８，およびＳ６１の処理が必要に応じて実行される。すなわち、処理部１３は、広告画像を表示する条件が満たされたことに応じて、ゲーム機アプリに関する広告を表示する（ステップＳ５４）。そして、購入ページを取得するための操作がユーザによって行われた場合には、処理部１３は、購入ページを取得する要求の情報をゲーム機アプリ提供サーバ３２へ送信し（ステップＳ５５）、購入ページを表示部１５に表示する（ステップＳ５７）。さらに、ユーザによって購入操作が行われた場合には、ゲーム機アプリを購入する購入要求の情報をゲーム機アプリ提供サーバ３２へ送信し（ステップＳ５８）、ゲーム機アプリ提供サーバ３２からの通知に応じてスマートフォンアプリの処理を再開する（ステップＳ６１）。

ステップＳ１３４において、処理部１３は、セーブデータ送信処理を実行する。具体的には、処理部１３は、セーブデータを送信する条件が満たされた場合に、上述のステップＳ７３の処理、すなわち、ゲームサーバ３４へゲームデータを送信する処理を実行する。

ステップＳ１３５において、処理部１３は、アプリ内購入処理を実行する。アプリ内購入処理は、スマートフォンアプリ内においてゲームデータ等を購入するための処理である。具体的には、アプリ内購入処理として、上述のステップＳ１０３の処理が必要に応じて実行される。すなわち、処理部１３は、ゲームデータの購入指示がユーザによって行われた場合、処理部１３は、購入要求の情報をスマートフォンアプリ提供サーバ２へ送信し、その後、購入に応じてゲームサーバ３４から送信されてくるゲームデータを受信する。

ステップＳ１３６において、処理部１３は、フレンドリスト変更処理を実行する。フレンドリスト変更処理は、上述の基本フレンドリストおよび／またはアプリフレンドリストに対して変更を行う処理である。具体的には、フレンドリスト変更処理として、上述のステップＳ１１１〜Ｓ１１４の処理が必要に応じて実行される。すなわち、処理部１３は、フレンドを変更する操作がユーザによって行われた場合、実行中のスマートフォンアプリのアプリフレンドリストにおけるフレンドを変更する。さらに、処理部１３は、アプリフレンドリストに対する変更を一定条件下で基本フレンドリストに反映し、基本フレンドリストに対する変更を一定条件下で他のアプリフレンドリストに反映する。

ステップＳ１３７において、処理部１３は、実行中のスマートフォンアプリを終了するか否かを判定する。例えば、処理部１３は、スマートフォンアプリを終了する旨のユーザ指示があったか否かを判定する。ステップＳ１３７の判定結果が否定である場合、ステップＳ１３２の処理が再度実行される。この場合、ステップＳ１３７においてスマートフォンアプリを終了すると判定されるまで、ステップＳ１３２〜Ｓ１３７の一連の処理が繰り返し実行される。一方、ステップＳ１３７の判定結果が肯定である場合、処理部１３は、図２６に示す処理を終了する。

なお、処理部１３は、図２６に示す処理の他、スマートフォンアプリによる処理とは別に、自社アカウントを設定するための処理（上述のステップＳ１およびＳ４）、スマートフォンアプリ提供サーバ２からスマートフォンアプリに関するデータを取得（例えば、購入）するための処理（上述のステップＳ９１）、自社サービスサーバ１からの各種の情報を受信する処理（例えば、特典に関する通知を受信する処理、および、基本フレンドリストに関する変更通知の情報を受信する処理）等を実行する。

（４−２）ゲーム機４における処理
次に、本実施形態におけるゲーム機４における処理の具体例について説明する。図２７は、ゲーム機４における処理の流れの一例を示すフローチャートである。図２７に示す一連の処理は、ゲーム機４が起動されたこと（具体的には、電源がオンにされたこと、あるいは、スリープ状態から復帰されたこと）に応じて開始される。本実施形態では、ゲーム機４の処理部２４（具体的には、ＣＰＵ）が、図２７に示す各ステップの処理を実行するものとして説明するが、上記フローチャートにおける一部のステップの処理を、ＣＰＵ以外のプロセッサや専用回路が実行するようにしてもよい。なお、本実施形態において、図２７に示す一連の処理は、例えば、ゲーム機４の記憶部１４に記憶されているＯＳをＣＰＵが実行することによって実行される。

まず、ステップＳ１４１において、処理部２４は、ログイン時処理として、上述のステップＳ３１の処理を実行する。ステップＳ１４１の次に、ステップＳ１４２の処理が実行される。ステップＳ１４２〜Ｓ１４６の一連の処理は、ゲーム機４における処理が終了する（すなわち、ステップＳ１４６の判定結果が肯定となる）まで繰り返し実行される。

ステップＳ１４２において、処理部２４は受信処理を実行する。ここで、本実施形態においては、自社サービスサーバ１からゲーム機４へプッシュ送信で各種の情報が送信される。例えば、ゲーム機アプリ提供サーバ３２は、上述の“（３−４）スマートフォンを用いてゲーム機アプリを購入する処理”で説明した、ゲーム機アプリのデータをゲーム機４へ送信する。また、管理サーバ３１は、上述の“（３−６）スマートフォンアプリの提供サービスの利用に応じて自社サービスサーバ１においてポイントを管理する処理”で説明した、特典に関する通知をゲーム機４へ送信したり、上述の“（３−７）スマートフォンとゲーム機とでフレンドリストを共有する処理”で説明した、基本フレンドリストに関する変更通知をゲーム機４へ送信したりする。上記受信処理において、処理部２４は、これらの情報（データとも言う）を自社サービスサーバ１から受信する。

具体的には、処理部２４は、自社サービスサーバ１（例えば、管理サーバ３１および／またはゲーム機アプリ提供サーバ３２）に対して、情報を取得する要求を送信する。そして、処理部２４は、この要求に応じて自社サービスサーバ１から送信されてくる各種情報を受信する。なお、本実施形態において、上記受信処理は、ユーザ指示の有無にかかわらず（換言すれば、自動的に）実行される。

ステップＳ１４３において、処理部２４は、フレンドリスト変更処理を実行する。フレンドリスト変更処理は、上述の基本フレンドリストおよび／またはアプリフレンドリストに対して変更を行う処理である。具体的には、フレンドリスト変更処理として、上述のステップＳ１１７〜Ｓ１１８の処理が必要に応じて実行される。すなわち、処理部２４は、上記ステップＳ１４２の処理において管理サーバ３１から上述の変更通知の情報を受信した場合、基本フレンドリストを変更通知の情報に基づいて更新する（ステップＳ１１７）。さらに、処理部２４は、基本フレンドリストに対する変更を一定条件下でアプリフレンドリストに反映する（ステップＳ１１８）。

ステップＳ１４４において、処理部２４は、ゲーム機アプリの起動指示があったか否かを判定する。具体的には、処理部２４は、ゲーム機アプリを実行するためのメニュー画面を表示部２８に表示し、メニュー画面に含まれる、ゲーム機アプリを表すアイコンを指定する入力を受け付ける。上記アイコンが指定された場合、処理部２４は、指定されたアイコンを起動する指示があったと判定する。ステップＳ１４４の判定結果が肯定である場合、ステップＳ１４５の処理が実行される。一方、ステップＳ１４４の判定結果が否定である場合、後述するステップＳ１４６の処理が実行される。

ステップＳ１４５において、処理部２４は、ステップＳ１４４でユーザによって起動が指示されたゲーム機アプリを起動する。このとき、処理部２４は、アプリ起動通知の情報を管理サーバ３１へ送信する（ステップＳ３３）。ステップＳ１４５の処理によって、ゲーム機アプリに応じた内容の処理（ここでは、ゲーム処理）の実行が開始される。

ゲーム機アプリの実行中において、処理部２４は、必要に応じて自社サービスサーバ１と通信を行う。例えば、処理部２４は、セーブファイルをセーブデータサーバ３３から取得したり、セーブデータをセーブデータサーバ３３へ送信したりする。また、実行中のゲーム機アプリにおいてアプリフレンドリストに変更があった場合、処理部２４は、当該アプリフレンドリストに対する変更を一定条件下で基本フレンドリストに反映し、基本フレンドリストに対する変更を一定条件下で他のアプリフレンドリストに反映する。さらに、フレンドリストに変更があった場合、処理部２４は、上述の変更要求の情報を管理サーバ３１へ送信する。

上記ステップＳ１４５において起動されたゲーム機アプリは、例えば、当該ゲーム機アプリを終了する旨のユーザ指示に応じて終了される。このとき、処理部２４は、上述の終了通知の情報を管理サーバ３１へ送信する（ステップＳ３８）。上記ゲーム機アプリの実行が終了されると、ステップＳ１４６の処理が実行される。

ステップＳ１４６において、処理部２４は、ゲーム機４の動作を終了するか否かを判定する。例えば、処理部２４は、ゲーム機４の電源をオフにする操作が行われた場合、または、ゲーム機４をスリープモードに移行する操作が行われた場合、ゲーム機４の動作を終了すると判定する。ステップＳ１４６の判定結果が否定である場合、ステップＳ１４２の処理が再度実行される。この場合、ステップＳ１４６においてゲーム機４の動作を終了すると判定されるまで、ステップＳ１４２〜Ｓ１４６の一連の処理が繰り返し実行される。一方、ステップＳ１４６の判定結果が肯定である場合、処理部２４は、図２７に示す処理を終了する。

なお、処理部２４は、図２７に示す処理の他、自社アカウントを設定するための処理（上述のステップＳ１，Ｓ４，およびＳ６）、ゲーム機アプリ提供サーバ３２からゲーム機アプリに関するデータを取得（例えば、購入）するための処理等を実行する。これらの処理は、ユーザによる指示に応じて実行される。

（４−３）管理サーバ３１における処理
次に、本実施形態における管理サーバ３１における処理の具体例について説明する。図２８は、管理サーバ３１における処理の流れの一例を示すフローチャートである。図２８に示す一連の処理は、管理サーバ３１の動作中において継続的に実行される。本実施形態では、管理サーバ３１の処理部（具体的には、ＣＰＵ）が、図２８に示す各ステップの処理を実行するものとして説明するが、上記フローチャートにおける一部のステップの処理を、ＣＰＵ以外のプロセッサや専用回路が実行するようにしてもよい。なお、本実施形態において、図２８に示す一連の処理は、例えば、管理サーバ３１の記憶部に記憶されている所定のプログラムをＣＰＵが実行することによって実行される。

まず、ステップＳ１５１において、処理部は、アカウント処理を実行する。アカウント処理は、端末からの要求に応じて自社アカウントを設定する処理である。すなわち、処理部は、アカウントを設定する旨の要求の情報を端末から受信した場合、自社アカウントを設定するための処理（ステップＳ２，Ｓ３，およびＳ５）を実行する。また、処理部は、端末を自社アカウントに登録する旨の登録要求の情報を端末から受信した場合、自社アカウントに対して当該端末を登録する処理（ステップＳ７）を実行する。

ステップＳ１５２において、処理部は、上述したステップＳ１４およびＳ３２等に示すログイン処理を実行する。すなわち、処理部は、スマートフォン３からのログイン要求に応じてゲームサーバ３４からログイン確認要求の情報を受信した場合、または、ゲーム機４からのログイン要求の情報を受信した場合、ログイン処理を実行する。

ステップＳ１５３において、処理部は、上述したステップＳ２１，Ｓ４１，およびＳ４２等に示すログアウトに関する処理を実行する。すなわち、処理部は、ゲームサーバ３４からログアウト通知の情報を受信した場合、上記ステップＳ２１のログアウト処理を実行する。また、処理部は、上記ステップＳ４１の処理によってゲーム機４がログアウトしたか否かを確認し、ログアウトしたと判断された場合、上記ステップＳ４２のログアウト処理を実行する。

ステップＳ１５４において、処理部は、上述したステップＳ３４およびＳ３９等に示すアプリ実行情報の更新処理を実行する。すなわち、処理部は、ゲーム機４からアプリ起動通知の情報または終了通知の情報を受信した場合、自身に記憶されているアプリ実行情報を、受信した情報に基づいて更新する（ステップＳ３４およびＳ３９）。

なお、上記ステップＳ１５１〜Ｓ１５４の処理は、これらの処理を実行する条件が満たされた場合に実行されればよく、ステップＳ１５１〜Ｓ１６３の処理ループにおいて毎回実行される必要はない。

ステップＳ１５５において、処理部は、上述の購入通知の情報をゲーム機アプリ提供サーバ３２から受信したか否かを判定する。購入通知の情報を受信した場合、ステップＳ１５６の処理が実行される。一方、購入通知の情報を受信していない場合、ステップＳ１５６の処理がスキップされて、後述するステップＳ１５７の処理が実行される。

ステップＳ１５６において、処理部は、購入されたゲーム機アプリの送信先のゲーム機を特定する処理（ステップＳ６０）を実行する。すなわち、処理部は、送信先のゲーム機を特定し、特定されたゲーム機を示す情報をゲーム機アプリ提供サーバ３２へ送信する。

ステップＳ１５７において、処理部は、スマートフォンアプリ提供サーバ２またはゲームサーバ３４から、スマートフォンアプリに関する購入を示す購入情報を受信したか否かを判定する。購入情報を受信した場合、ステップＳ１５８〜Ｓ１６０の処理が実行される。一方、購入情報を受信していない場合、ステップＳ１５８〜Ｓ１６０の処理がスキップされて、後述するステップＳ１６１の処理が実行される。

ステップＳ１５８において、処理部は、スマートフォンアプリに関する購入が行われた他社アカウントに対応する自社アカウントを特定する（ステップＳ９５またはＳ１０８）。また、ステップＳ１５９において、処理部は、特定した自社アカウントについてポイントを付与する（ステップＳ９６またはＳ１０９）。さらに、ステップＳ１６０において、処理部は、付与されたポイントが上述した付与条件を満たす場合、上記自社アカウントのユーザに対して特典を付与する処理を実行する（図１８に示す（５））。

ステップＳ１６１において、処理部は、フレンドリストを変更するための変更要求の情報を端末から受信したか否かを判定する。変更要求の情報を受信した場合、ステップＳ１６２およびＳ１６３の処理が実行される。一方、変更要求の情報を受信していない場合、ステップＳ１６２およびＳ１６３の処理がスキップされて、上記ステップＳ１５１の処理が再度実行される。

ステップＳ１６２において、処理部は、受信した変更要求の情報に基づいて、記憶部に記憶されているフレンドリストを更新する（ステップＳ１１５）。さらに、ステップＳ１６３において、処理部は、記憶部に記憶されている基本フレンドリストを更新した場合、上述の変更通知の情報を他方の端末へ送信する（ステップＳ１１６）。ここで、他方の端末とは、スマートフォン３およびゲーム機４のうち、変更要求の情報を送信した端末とは異なる方の端末を指す。

上記ステップＳ１６２の後、上記ステップＳ１５１の処理が再度実行される。管理サーバ３１は、ステップＳ１５１〜Ｓ１６２の一連の処理を繰り返し実行する。

［５．変形例］
（上述の処理例に関する変形例）
上記実施形態においては、情報処理システムにおいて上述の（３−４）〜（３−７）の処理例が実行される場合を例として説明した。ここで、他の実施形態においては、情報処理システムは、（３−４）〜（３−７）の処理例のうち、いくつかのみを実行するものであってもよい。

（スマートフォンアプリ提供サーバに関する変形例）
他の実施形態においては、情報処理システムは、複数のスマートフォンアプリ提供サーバを含む構成であってもよい。例えば、情報処理システムは、第１のアプリ提供サービス（例えば、「Ｇｏｏｇｌｅｐｌａｙ（登録商標）」のサービス）を提供するための第１のスマートフォンアプリ提供サーバと、第２のアプリ提供サービス（例えば、「ＡＰＰＳＴＯＲＥ（登録商標）」のサービス）を提供するための第２のスマートフォンアプリ提供サーバとを含む構成であってもよい。このとき、管理サーバ３１は、第１のアプリ提供サービスにログインするための第１の他社アカウントＩＤと、第２のアプリ提供サービスにログインするための第２の他社アカウントＩＤとを、自社アカウントＩＤと関連付けて記憶しておく。これによって、上記２つのアプリ提供サービスにおける他社アカウントを、自社アカウントにそれぞれ関連付けることができる。

（自社アカウントに関する変形例）
他の実施形態においては、スマートフォン３によって自社サービスにログインするためのアカウントと、ゲーム機４によって自社サービスにログインするためのアカウントとが別であってもよい。すなわち、スマートフォン３は、スマートフォン用自社アカウントＩＤを用いて自社サービスにログインし、ゲーム機４は、ゲーム機用自社アカウントＩＤを用いて自社サービスにログインするようにしてもよい。

このとき、自社サービスサーバ１は、上記実施形態における自社アカウントＩＤに代えて、スマートフォン用自社アカウントＩＤと、ゲーム機用自社アカウントＩＤとを関連付けた情報を自身の記憶部に記憶する。この情報によって、自社サービスサーバ１は、スマートフォン３とゲーム機４との対応（換言すれば、同じユーザが所有するスマートフォン３とゲーム機４との組）を特定することができる。

また、各サーバ３１〜３４において自社アカウントＩＤに関連付けて記憶される情報は、スマートフォン用自社アカウントＩＤとゲーム機用自社アカウントＩＤに関連付けて記憶される。これによって、各サーバ３１〜３４は、端末（スマートフォン３またはゲーム機４）と、当該端末に関する情報との対応を特定することができる。

（複数のユーザ間で自社サービスを共有する変形例）
他の実施形態においては、自社サービスサーバ１は、自社アカウントの異なる複数のユーザ間で共有される自社サービスを提供してもよい。すなわち、自社サービスサーバ１は、複数の自社アカウント（換言すれば、ユーザ）に対して１つのグループを設定することが可能であってもよい。このとき、ユーザ管理情報は、当該ユーザ管理情報が示す自社アカウントが属するグループを示すグループＩＤに関連付けられていてもよい。このグループは例えば家族であり、ユーザは、同じ家族である複数のユーザの自社アカウントを１つのグループに含めるように設定を行ってもよい。このとき、自社サービス（の一部）がグループ内のユーザ間で共有されてもよい。具体的には、１つのグループ内に含まれるアカウントについて料金の支払がまとめられて、グループ内の所定のユーザが支払を行うようにしてもよい。また、自社サービスにおいて提供されるコンテンツ（例えば、アプリケーション、音楽、動画等）の利用がグループを単位として許可されてもよい。つまり、あるユーザが自社サービスにおいてコンテンツを購入した場合、当該ユーザと同じグループに含まれる他のユーザも当該コンテンツが利用可能であるようにしてもよい。

また、スマートフォンを用いてゲーム機アプリを購入する処理（図１０参照）においては、スマートフォンを用いて購入要求を行うユーザと、購入に係るゲーム機アプリを受け取るユーザとが、同じグループに属する異なるユーザであってもよい。すなわち、上記処理において、スマートフォンから購入要求が行われた場合、自社サービスサーバ１は、当該購入要求が行われたスマートフォンに対応する自社アカウントと同じグループに属する自社アカウントに対応するゲーム機へ、購入に係るゲーム機アプリを送信するようにしてもよい。

また、スマートフォンアプリとゲーム機アプリでセーブデータを共有する処理（図１５参照）においては、所定のアプリケーションについて、同じグループに属する複数の自社アカウントについて、セーブデータが共有されてもよい。

また、スマートフォンアプリの提供サービスの利用に応じて自社サービスサーバ１においてポイントを管理する処理（図１８参照）においては、同じグループに属する複数の自社アカウントについて、付与されるポイントが共有されてもよい。

また、スマートフォンとゲーム機とでフレンドリストを共有する処理（図２２参照）においては、同じグループに属する複数の自社アカウントについて、基本フレンドリスト、および／または、所定のアプリケーションに関するアプリフレンドリストが共有されてもよい。

（サーバと端末とにおける処理に関する変形例）
他の実施形態においては、上記実施形態においてサーバ側において（すなわち、自社サービスサーバ１および／またはスマートフォンアプリ提供サーバ２において）実行された処理の一部は、端末側において（すなわち、スマートフォン３および／またはゲーム機４において）実行されてもよい。また、他の実施形態においては、上記実施形態において端末側において実行された処理の一部は、サーバ側において実行されてもよい。

上記の実施形態は、ユーザによるアプリケーションの取得の機会を拡大すること等を目的として、例えばスマートフォンおよびゲーム機にアプリケーションを提供するための情報処理システムに利用することができる。

１自社サービスサーバ
２スマートフォンアプリ提供サーバ
３スマートフォン
４ゲーム機
５ネットワーク
１３処理部
１４記憶部
１５表示部
１６モバイル通信部
２３方向入力スティック
２４処理部
２５記憶部
２６ゲームカードコネクタ
２８表示部
３１管理サーバ
３２ゲーム機アプリ提供サーバ
３３セーブデータサーバ
３４ゲームサーバ
４２広告画像
４３購入ページ画像

Claims

第１の種類のプラットホームを有する第１の情報処理装置と互換性を有し、かつ、第１の種類とは異なる第２の種類のプラットホームを有する第２の情報処理装置と互換性を有しない第１のアプリケーションを記憶するサーバであって、
前記第１のアプリケーションに関する提示情報を前記第２の情報処理装置へ送信する提示情報送信手段と、
前記第２の情報処理装置において提示された前記提示情報に対応する前記第１のアプリケーションの取得に関する指示を示す指示情報を、当該第２の情報処理装置から受信する受信手段と、
前記受信された指示情報に関する第１のアプリケーションを受信すべき第１の情報処理装置を特定する特定手段と、
前記第２の情報処理装置から受信される前記指示情報に応じて、前記提示情報が示す第１のアプリケーションを、前記特定された第１の情報処理装置へ送信するアプリ送信手段とを備え、
前記提示情報送信手段は、前記第２の情報処理装置と互換性を有し、前記第１の情報処理装置と互換性を有しない第２のアプリケーションを実行中である第２の情報処理装置へ前記提示情報を送信し、
前記第１のアプリケーションは、前記第２のアプリケーションによって生成されるセーブデータの少なくとも一部のデータを利用することが可能なアプリケーションである、サーバ。
前記提示情報送信手段は、前記第２のアプリケーションに関連する第１のアプリケーションに関する提示情報を前記第２の情報処理装置へ送信する、請求項１に記載のサーバ。
前記サーバは、前記第２の情報処理装置に関する識別情報と、前記第１の情報処理装置に関する識別情報との関連付けを示す関連付け情報を記憶しており、
前記特定手段は、前記関連付け情報に基づいて前記第１の情報処理装置を特定する、請求項１または請求項２に記載のサーバ。
前記サーバは、
前記第２の情報処理装置における前記第２のアプリケーションの実行開始時および／または実行中において、当該第２の情報処理装置のユーザに関するユーザ識別情報を当該第２の情報処理装置から受信し、
前記第２の情報処理装置に関する識別情報である前記ユーザ識別情報と、前記第１の情報処理装置に関する識別情報との関連付けを示す関連付け情報を記憶し、
前記特定手段は、前記第２の情報処理装置における前記第２のアプリケーションの実行開始時および／または実行中において前記サーバへ送信された前記ユーザ識別情報と、前記関連付け情報とに基づいて前記第１の情報処理装置を特定する、請求項１から請求項３のいずれか１項に記載のサーバ。
前記サーバは、前記第１の情報処理装置に関する識別情報として、第１の情報処理装置に固有の識別情報を記憶する、請求項３または請求項４に記載のサーバ。
前記サーバは、前記ユーザ識別情報に関連付けて、当該ユーザ識別情報が示すユーザに関するユーザ情報を記憶しており、
前記提示情報送信手段は、前記第２の情報処理装置へ送信すべき提示情報の内容を、当該第２の情報処理装置から受信したユーザ識別情報に関連付けられるユーザ情報に基づいて決定する、請求項４に記載のサーバ。
前記アプリ送信手段は、前記第１のアプリケーションを前記サーバから前記第１の情報処理装置へ送信する旨のユーザ指示の有無にかかわらず自動的に、当該第１のアプリケーションを前記第１の情報処理装置へ送信する、および／または、当該第１のアプリケーションを送信可能である旨の通知を前記第１の情報処理装置へ送信する、請求項１から請求項６のいずれか１項に記載のサーバ。
前記アプリ送信手段は、前記第２の情報処理装置から前記指示情報を受信した後において、第１のアプリケーションの取得に関する所定の条件が満たされたことに応じて、前記第１の情報処理装置への前記第１のアプリケーションの送信、および／または、前記第１の情報処理装置への前記第１のアプリケーションに関する通知の送信を試みる、請求項７に記載のサーバ。
前記提示情報送信手段は、前記提示情報を前記サーバから前記第２の情報処理装置へ送信する旨のユーザ指示の有無にかかわらず自動的に、当該提示情報を前記第２の情報処理装置へ送信する、請求項１から請求項８のいずれか１項に記載のサーバ。
前記第１のアプリケーションおよび前記第２のアプリケーションは、ゲームアプリケーションである、請求項１から請求項９のいずれか１項に記載のサーバ。
前記第１の情報処理装置は、ゲーム装置であり、
前記第２の情報処理装置は、スマートデバイスである、請求項１から請求項１０のいずれか１項に記載のサーバ。
サーバと、第１の種類のプラットホームを有する第１の情報処理装置と、前記第１の種類とは異なる第２の種類のプラットホームを有する第２の情報処理装置とを含む情報処理システムであって、
前記サーバは、
前記第１の情報処理装置と互換性を有し、かつ、第２の情報処理装置と互換性を有しない第１のアプリケーションを記憶する記憶手段と、
前記第１のアプリケーションに関する提示情報を前記第２の情報処理装置へ送信する提示情報送信手段と、
前記第２の情報処理装置において提示された前記提示情報に対応する前記第１のアプリケーションの取得に関する指示を示す指示情報を、当該第２の情報処理装置から受信する受信手段とを備え、
前記情報処理システムは、前記指示情報に関する第１のアプリケーションを受信すべき第１の情報処理装置を特定する特定手段を備え、
前記サーバは、前記第２の情報処理装置から受信される前記指示情報に応じて、前記提示情報が示す第１のアプリケーションを、前記特定された第１の情報処理装置へ送信するアプリ送信手段をさらに備え、
前記提示情報送信手段は、前記第２の情報処理装置と互換性を有し、かつ、前記第１の情報処理装置と互換性を有しない第２のアプリケーションを実行中である前記第２の情報処理装置へ前記提示情報を送信し、
前記第１のアプリケーションは、前記第２のアプリケーションによって生成されるセーブデータの少なくとも一部のデータを利用することが可能なアプリケーションである、情報処理システム。
第１の種類のプラットホームによって利用され、かつ、第１の種類とは異なる第２の種類のプラットホームによって利用できない第１のアプリケーションを記憶するサーバであって、
前記第１のアプリケーションに関する提示情報を前記第２の種類のプラットホームを有する第２の情報処理装置へ送信する提示情報送信手段と、
前記提示情報が示す第１のアプリケーションの受信先となる、前記第１の種類のプラットホームを有する第１の情報処理装置を特定する特定手段と、
前記第２の情報処理装置から受信される指示情報に応じて、前記提示情報が示す第１のアプリケーションを、特定された第１の情報処理装置へ送信するアプリ送信手段とを備え、
前記提示情報送信手段は、前記第２の種類のプラットホームによって利用され、かつ、前記第１の種類のプラットホームによって利用できない第２のアプリケーションを実行中である前記第２の情報処理装置へ前記提示情報を送信し、
前記第１のアプリケーションは、前記第２のアプリケーションによって生成されるセーブデータの少なくとも一部のデータを利用することが可能なアプリケーションである、サーバ。
第１の種類の情報処理装置において実行可能であり、かつ、第１の種類とは異なる第２の種類の情報処理装置において実行不可能な第１のアプリケーションを記憶するサーバであって、
前記第１のアプリケーションに関する提示情報を前記第２の種類の情報処理装置へ送信する提示情報送信手段と、
前記第２の種類の情報処理装置において提示された前記提示情報に対応する前記第１のアプリケーションの取得に関する指示を示す指示情報を、当該第２の種類の情報処理装置から受信する受信手段と、
前記受信された指示情報に関する第１のアプリケーションを受信すべき第１の種類の情報処理装置を特定する特定手段と、
前記第２の種類の情報処理装置から受信される前記指示情報に応じて、前記提示情報が示す第１のアプリケーションを、特定された第１の種類の情報処理装置へ送信するアプリ送信手段とを備え、
前記提示情報送信手段は、前記第２の種類の情報処理装置において実行可能であり、前記第１の種類の情報処理装置において実行不可能な第２のアプリケーションを実行中である前記第２の種類の情報処理装置へ前記提示情報を送信し、
前記第１のアプリケーションは、前記第２のアプリケーションによって生成されるセーブデータの少なくとも一部のデータを利用することが可能なアプリケーションである、サーバ。
第１の種類のプラットホームを有する第１の情報処理装置と互換性を有し、かつ、第１の種類とは異なる第２の種類のプラットホームを有する第２の情報処理装置と互換性を有しない第１のアプリケーションを記憶するサーバのコンピュータにおいて実行される情報処理プログラムであって、
前記第１のアプリケーションに関する提示情報を前記第２の情報処理装置へ送信する提示情報送信手段と、
前記第２の情報処理装置において提示された前記提示情報に対応する前記第１のアプリケーションの取得に関する指示を示す指示情報を、当該第２の情報処理装置から受信する受信手段と、
前記受信された指示情報に関する第１のアプリケーションを受信すべき第１の情報処理装置を特定する特定手段と、
前記第２の情報処理装置から受信される前記指示情報に応じて、前記提示情報が示す第１のアプリケーションを、前記特定された第１の情報処理装置へ送信するアプリ送信手段として前記コンピュータを機能させ、
前記提示情報送信手段は、前記第２の情報処理装置と互換性を有し、前記第１の情報処理装置と互換性を有しない第２のアプリケーションを実行中である第２の情報処理装置へ前記提示情報を送信し、
前記第１のアプリケーションは、前記第２のアプリケーションによって生成されるセーブデータの少なくとも一部のデータを利用することが可能なアプリケーションである、情報処理プログラム。
サーバと、第１の種類のプラットホームを有する第１の情報処理装置と、前記第１の種類とは異なる第２の種類のプラットホームを有する第２の情報処理装置とを含む情報処理システムにおいて実行される情報処理方法であって、
前記サーバは、前記第１の情報処理装置と互換性を有し、かつ、第２の情報処理装置と互換性を有しない第１のアプリケーションを記憶しており、
前記サーバは、
前記第１のアプリケーションに関する提示情報を前記第２の情報処理装置へ送信し、
前記第２の情報処理装置において提示された前記提示情報に対応する前記第１のアプリケーションの取得に関する指示を示す指示情報を、当該第２の情報処理装置から受信し、
前記情報処理システムは、前記指示情報に関する第１のアプリケーションを受信すべき第１の情報処理装置を特定し、
前記サーバは、
前記第２の情報処理装置から受信される前記指示情報に応じて、前記提示情報が示す第１のアプリケーションを、前記特定された第１の情報処理装置へ送信し、
前記第２の情報処理装置と互換性を有し、前記第１の情報処理装置と互換性を有しない第２のアプリケーションを実行中である第２の情報処理装置へ前記提示情報を送信し、
前記第１のアプリケーションは、前記第２のアプリケーションによって生成されるセーブデータの少なくとも一部のデータを利用することが可能なアプリケーションである、情報処理方法。