JP5482841B2 - サーバ装置、サーバプログラム、および、端末プログラム - Google Patents

Description

本発明は、ネットワークを介して端末装置を利用するユーザを認証する技術に関する。

スマートフォン等の端末装置で実行されるゲーム等のアプリ（アプリケーションプログラム）の利用を許可する等を目的に、アプリの動作によりネットワークを介してサーバ装置にアクセスしてきた端末装置のユーザをサーバ装置で認証することが行われている。

従来、端末装置のユーザの認証には、端末装置が１人のユーザにより利用される実態を考慮して、端末装置のＭＡＣ（Media Access Control）アドレスそのものや、ＭＡＣアドレスをもとにした値が端末識別キー（端末ＩＤ）として用いられていた。

ＭＡＣアドレスは通信インタフェースのハードウェア毎にユニークな値が割り当てられているため、端末装置の特定が一意に行え、ひいてはユーザを一意に特定できるものである。

また、ＭＡＣアドレス以外のハードウェア由来の識別子として、例えば、端末装置に内蔵された装置のシリアル番号情報、無線タグや近距離無線チップのＩＤ等も端末識別キーとして用いることができる。

なお、出願人は出願時点までに本発明に関連する公開された先行技術文献を発見することができなかった。よって、先行技術文献情報を開示していない。

上述したように、従来は端末装置を利用するユーザの認証にＭＡＣアドレス等のハードウェア由来の識別子が用いられていたが、昨今の個人情報保護の高まりから、これらの個人特定につながりやすい情報へのアクセスが、ゲーム等の不特定のアプリから自由に行なえることが禁止される傾向にある。

すなわち、ＭＡＣアドレス等のハードウェア由来の識別子は、端末装置との結び付きが強すぎるが故にユーザとの結び付きも強すぎるものであり、個人情報との対応付けが比較的容易であり、いったん流出すれば個人情報が容易に流出してしまう危険があるためである。

従って、今後はＭＡＣアドレス等のハードウェア由来の識別子を用いることなく端末装置を利用するユーザを認証する手法が求められるが、現状では有効な手法が存在しない。

本発明は上記の点に鑑み提案されたものであり、その目的とするところは、ＭＡＣアドレス等のハードウェア由来の識別子を用いることなく端末装置を利用するユーザを認証することにある。

上記の課題を解決するため、本発明にあっては、端末装置の所定アプリにより起動されたブラウザアプリからユーザＩＤもしくはセッションＩＤの両方もしくは一方が欠けたもしくは無効の状態の認証要求を受信した場合に、欠けたもしくは無効のＩＤを新たに生成し、ユーザＩＤおよびセッションＩＤを対応付けてデータベースに保存し、ユーザＩＤおよびセッションＩＤを要求元の前記ブラウザアプリに応答し、ユーザＩＤおよびセッションＩＤを前記所定アプリに保存させる手段と、前記所定アプリからユーザＩＤおよびセッションＩＤを伴う認証要求を受信した場合に、前記データベースを参照し、同じユーザＩＤおよびセッションＩＤの組が保存されているか否かを確認することにより認証を行ない、認証結果を要求元の前記所定アプリに応答する手段とを備えるようにしている。

本発明にあっては、ＭＡＣアドレス等のハードウェア由来の識別子を用いることなく端末装置を利用するユーザを認証することができる。

本発明の一実施形態にかかるシステムの構成例を示す図である。 端末装置のハードウェア構成例を示す図である。 アプリダウンロードサーバおよびゲーム管理サーバのハードウェア構成例を示す図である。 セッション管理データベースのデータ構造例を示す図である。 実施形態の処理例を示すシーケンス図である。 端末装置上の画面例を示す図（その１）である。 端末装置上の画面例を示す図（その２）である。 端末装置上の画面例を示す図（その３）である。

以下、本発明の好適な実施形態につき説明する。

＜構成＞
図１は本発明の一実施形態にかかるシステムの構成例を示す図である。

図１において、システムは、ユーザ（プレイヤ）が所持するスマートフォン、携帯電話等の端末装置１と、移動無線基地局やＷｉ−Ｆｉステーション等のアクセスポイント２と、インターネット等のネットワーク３と、アプリダウンロードサーバ４と、ゲーム管理サーバ５とを備えている。

端末装置１は、ゲームアプリ１１とブラウザアプリ１２とを備えている。

ゲームアプリ１１は、所定のゲームを実行する機能を有している。

ブラウザアプリ１２は、インターネットの標準プロトコルであるＨＴＴＰ（Hyper Text Transfer Protocol）等に従い、ＨＴＭＬ（Hyper Text Markup Language）等の言語で記述されたページデータの要求・取得・表示およびフォームデータの送信等を行う機能を有している。

アプリダウンロードサーバ４は、ゲームアプリ１１に対応するプログラムを記憶しており、これを端末装置１にダウンロードおよびインストールさせる機能を有している。

ゲーム管理サーバ５は、端末装置１のゲームアプリ１１からのアクセスに対してユーザの認証や保有ポイントの管理やゲームアプリ１１に対する情報提供等の処理を行う機能を有している。ゲーム管理サーバ５はセッション管理データベース５１を備えている。セッション管理データベース５１のデータ構造については後述する。

図２は端末装置１のハードウェア構成例を示す図である。

図２において、端末装置１は、電源システム１０１と、プロセッサ１０３、メモリコントローラ１０４、周辺インタフェース１０５を含むメインシステム１０２と、記憶部１０６と、外部ポート１０７と、高周波回路１０８と、アンテナ１０９と、オーディオ回路１１０と、スピーカ１１１と、マイク１１２と、近接センサ１１３と、ディスプレイコントローラ１１５、光学センサコントローラ１１６、入力コントローラ１１７を含むＩ／Ｏサブシステム１１４と、タッチ反応型ディスプレイシステム１１８と、光学センサ１１９と、入力部１２０とを備えている。

図３はアプリダウンロードサーバ４およびゲーム管理サーバ５のハードウェア構成例を示す図である。

図３において、アプリダウンロードサーバ４およびゲーム管理サーバ５は、システムバス４０１に接続されたＣＰＵ（Central Processing Unit）４０２、ＲＯＭ（Read Only Memory）４０３、ＲＡＭ（Random Access Memory）４０４、ＮＶＲＡＭ（Non-Volatile Random Access Memory）４０５、Ｉ／Ｆ（Interface）４０６と、Ｉ／Ｆ４０６に接続された、キーボード、マウス、モニタ、ＣＤ／ＤＶＤ（Compact Disk/Digital Versatile Disk）ドライブ等のＩ／Ｏ（Input/Output Device）４０７、ＨＤＤ（Hard Disk Drive）４０８、ＮＩＣ（Network Interface Card）４０９等を備えている。なお、セッション管理データベース５１は、ＨＤＤ４０８に格納されている。

図４はゲーム管理サーバ５におけるセッション管理データベース５１のデータ構造例を示す図である。

図４において、セッション管理データベース５１は、「セッションＩＤ」「ユーザＩＤ」「ＭＡＣアドレス」「保有ポイント」等の項目（フィールド）を含んでいる。

「セッションＩＤ」は、端末装置１のブラウザアプリ１２からのアクセスに対し、端末識別キーとしてゲーム管理サーバ５が割り当てた情報である。「セッションＩＤ」は端末装置１のブラウザアプリ１２にクッキー情報として保存されるとともに、ゲームアプリ１１にも内部的に保存される。

「ユーザＩＤ」は、端末装置１のブラウザアプリ１２からのアクセスに対し、ユーザ識別用にゲーム管理サーバ５が割り当てた情報である。「ユーザＩＤ」はゲームアプリ１１にも内部的に保存される。なお、「ユーザＩＤ」はユーザ個人を特定する情報である必要はなく、ユーザ管理上、同一のユーザであるか否かを特定できれば足りる。

「ＭＡＣアドレス」は、端末装置１のＭＡＣアドレスである。ＭＡＣアドレスを端末識別キーとして認証に用いていた既存の仕組と互換性を持たせるために補助的に管理する情報である。なお、ＭＡＣアドレスに代えて他のハードウェア由来の識別子を用いてもよい。

「保有ポイント」は、セッションＩＤおよびユーザＩＤで特定されるユーザのゲーム上のポイント残高の情報である。

＜動作＞
図５は上記の実施形態の処理例を示すシーケンス図である。

図５において、端末装置１のゲームアプリ１１がユーザにより起動されると（ステップＳ１０１）、ゲームアプリ１１は、内部の所定の記憶領域にセッションＩＤとユーザＩＤが保存されているか否か判断する（ステップＳ１０２）。ゲームアプリ１１からいったんゲーム管理サーバ５に対して認証要求を行った後は、セッションＩＤとユーザＩＤがゲームアプリ１１内に保存されるため、原則として、初回の起動を除いて、セッションＩＤとユーザＩＤが保存されていると判断される。

セッションＩＤとユーザＩＤが保存されていると判断した場合（ステップＳ１０２のＹｅｓ）、ゲームアプリ１１は、予めゲームアプリ１１内に設定されたＵＲＬ等のアドレス情報に基づいてゲーム管理サーバ５にアクセスし、セッションＩＤとユーザＩＤを伴う認証要求を送信する（ステップＳ１０３）。

ゲーム管理サーバ５は、端末装置１のゲームアプリ１１からセッションＩＤとユーザＩＤを受信すると、受信したセッションＩＤとユーザＩＤの組がセッション管理データベース５１に登録されているか否か照合し（ステップＳ１０４）、認証結果を端末装置１のゲームアプリ１１に送信する（ステップＳ１０５）。

ゲームアプリ１１の起動後にセッションＩＤとユーザＩＤがゲームアプリ１１内に保存されていないと判断した場合（既存のＭＡＣアドレスを端末識別キーに用いた仕組のユーザについては、ユーザＩＤは存在するがセッションＩＤが存在しないため、この場合に該当する）（ステップＳ１０２のＮｏ）、もしくは、認証結果が正常（ＯＫ）でなかった場合（ステップＳ１０６のＮｏ）、ゲーム管理サーバ５による認証を行うか否かをユーザに確認する（ステップＳ１０７）。図６はユーザへの確認の画面例を示しており、サーバにより認証が必要な旨の表示と、「認証を行う」ボタンと、「利用しない」ボタンとが設けられている。

図５に戻り、ユーザが認証を行わないと選択した場合（ステップＳ１０７のＮｏ）、ゲームアプリ１１は処理を終了する。

ユーザが認証を行うと選択した場合（ステップＳ１０７のＹｅｓ）、ゲーム管理サーバ５による認証の処理に移行する。この場合、ユーザＩＤもしくはセッションＩＤの両方もしくは一方が欠けたもしくは無効（セッション管理データベース５１と不整合）の状態である。

認証の処理では、先ず、ゲームアプリ１１は、予め設定されているゲーム管理サーバ５の認証用ページのＵＲＬと、存在する場合にはユーザＩＤと、存在する場合にはＭＡＣアドレスとを、ＵＲＬ記述に含め（ユーザＩＤとＭＡＣアドレスはパラメータ部分等に含める）、ブラウザアプリ１２に引き渡してブラウザアプリ１２を起動する（ステップＳ１０８）。

ブラウザアプリ１２は、ゲームアプリ１１により指定されたＵＲＬの示すゲーム管理サーバ５にアクセスし、存在する場合にはユーザＩＤと、存在する場合にはＭＡＣアドレスとを伴う認証要求を送信する（ステップＳ１０９）。ここでは、ゲームアプリ１１から引き渡されたＵＲＬ記述をそのままリクエストとしてゲーム管理サーバ５に送信することを想定している。

ゲーム管理サーバ５は、ブラウザアプリ１２に処理中であることを示す画面データを送信し（ステップＳ１１０）、ブラウザアプリ１２はその画面を表示する（ステップＳ１１１）。図７は処理中画面の例を示す図である。なお、処理中画面を送信・表示することなく、処理を進めてもよい。

図５に戻り、ゲーム管理サーバ５は、ユーザＩＤが指定されている場合には、それと組になるセッションＩＤを新たに生成し、ユーザＩＤが指定されていない場合には、ユーザＩＤとセッションＩＤの組を新たに生成し（ステップＳ１１２）、セッション管理データベース５１に対応付けて保存する（ステップＳ１１３）。

なお、既存のＭＡＣアドレスを端末識別キーに用いた仕組のユーザについては、ユーザＩＤとＭＡＣアドレスが指定されるため、ユーザＩＤとＭＡＣアドレスの組がセッション管理データベース５１に登録されているか否か照合し、両者が対応付けられて登録されていることを条件に、対応するセッションＩＤを新たに生成し、セッション管理データベース５１に対応付けて保存する。

次いで、ゲーム管理サーバ５は、ユーザＩＤとセッションＩＤを端末装置１のブラウザアプリ１２に送信する（ステップＳ１１４）。

これを受信したブラウザアプリ１２は、セッションＩＤをクッキーに保存する（ステップＳ１１５）。

次いで、ゲームアプリ１１に戻ることをユーザに確認する（ステップＳ１１６）。図８はユーザ確認の画面例を示しており、認証が完了した旨の表示と、「アプリに戻る」ボタンが設けられている。なお、ユーザ確認を行わずにゲームアプリ１１に自動的に戻るようにしてもよい。

図５に戻り、ブラウザアプリ１２は、ＵＲＬスキーム等の機構により、ゲームアプリ１１にリダイレクトしてユーザＩＤとセッションＩＤを引き渡す（ステップＳ１１７）。

ゲームアプリ１１は、受け取ったユーザＩＤとセッションＩＤを内部の記憶領域に保存する（ステップＳ１１８）。

その後、もしくは、認証結果が正常（ＯＫ）であった場合（ステップＳ１０６のＹｅｓ）、ゲームアプリ１１は、ゲーム管理サーバ５との通信を伴う既定の処理を実行する（ステップＳ１１９）。

この処理の中で、ゲームアプリ１１は、ゲーム管理サーバ５にアクセスし、セッションＩＤを伴う処理要求を送信する（ステップＳ１２０）。

ゲーム管理サーバ５は、受信したセッションＩＤに基づきセッション管理データベース５１を参照して対応するユーザＩＤを取得し（ステップＳ１２１）、処理要求に応じた処理を実行し（ステップＳ１２２）、処理結果を端末装置１のゲームアプリ１１に送信する（ステップＳ１２３）。例えば、当該ユーザの保有ポイントを参照する処理要求であれば、セッション管理データベース５１から保有ポイントを参照して端末装置１のゲームアプリ１１に送信する。

＜総括＞
以上説明したように、本実施形態によれば、ＭＡＣアドレス等のハードウェア由来の識別子を用いることなく端末装置を利用するユーザを認証することができる。従って、個人情報保護の観点からＭＡＣアドレス等のハードウェア由来の識別子にアクセスできない状況においても、端末装置を利用するユーザを認証することができる。

なお、ゲームアプリを用いる場合について説明したが、これに限定されず、任意のアプリ（所定アプリ）に適用することができる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

１ 端末装置
１１ ゲームアプリ
１２ ブラウザアプリ
２ アクセスポイント
３ ネットワーク
４ アプリダウンロードサーバ
５ ゲーム管理サーバ
５１ セッション管理データベース

Claims (5)

1. 端末装置の所定アプリにより起動されたブラウザアプリからユーザＩＤもしくはセッションＩＤの両方もしくは一方が欠けたもしくは無効の状態の認証要求を受信した場合に、欠けたもしくは無効のＩＤを新たに生成し、ユーザＩＤおよびセッションＩＤを対応付けてデータベースに保存し、ユーザＩＤおよびセッションＩＤを要求元の前記ブラウザアプリに応答し、ユーザＩＤおよびセッションＩＤを前記所定アプリに保存させる手段と、
   前記所定アプリからユーザＩＤおよびセッションＩＤを伴う認証要求を受信した場合に、前記データベースを参照し、同じユーザＩＤおよびセッションＩＤの組が保存されているか否かを確認することにより認証を行ない、認証結果を要求元の前記所定アプリに応答する手段と
   を備えたことを特徴とするサーバ装置。
2. 請求項１に記載のサーバ装置において、
   前記ブラウザアプリから前記所定アプリへのリダイレクトにより、ユーザＩＤおよびセッションＩＤを前記所定アプリに保存させる
   ことを特徴とするサーバ装置。
3. 請求項１または２のいずれか一項に記載のサーバ装置において、
   前記ブラウザアプリからユーザＩＤおよびハードウェア由来の端末ＩＤを伴う認証要求を受信した場合に、前記データベースを参照し、同じユーザＩＤおよび端末ＩＤの組が保存されているか否かを確認することにより認証を行ない、認証が正常に行えた場合に対応するセッションＩＤを新たに生成し、ユーザＩＤおよびセッションＩＤをデータベースに対応付けて保存し、ユーザＩＤおよびセッションＩＤを要求元の前記ブラウザアプリに応答し、ユーザＩＤおよびセッションＩＤを前記所定アプリに保存させる
   ことを特徴とするサーバ装置。
4. サーバ装置を構成するコンピュータを、
   端末装置の所定アプリにより起動されたブラウザアプリからユーザＩＤもしくはセッションＩＤの両方もしくは一方が欠けたもしくは無効の状態の認証要求を受信した場合に、欠けたもしくは無効のＩＤを新たに生成し、ユーザＩＤおよびセッションＩＤを対応付けてデータベースに保存し、ユーザＩＤおよびセッションＩＤを要求元の前記ブラウザアプリに応答し、ユーザＩＤおよびセッションＩＤを前記所定アプリに保存させる手段、
   前記所定アプリからユーザＩＤおよびセッションＩＤを伴う認証要求を受信した場合に、前記データベースを参照し、同じユーザＩＤおよびセッションＩＤの組が保存されているか否かを確認することにより認証を行ない、認証結果を要求元の前記所定アプリに応答する手段
   として機能させるサーバプログラム。
5. 端末装置を構成するコンピュータを、
   ブラウザアプリを起動して当該ブラウザアプリからユーザＩＤもしくはセッションＩＤの両方もしくは一方が欠けたもしくは無効の状態の認証要求をサーバ装置に送信する手段、
   前記サーバ装置から、欠けたもしくは無効のＩＤが新たに生成されてデータベースに対応付けて保存されたユーザＩＤおよびセッションＩＤを前記ブラウザアプリからリダイレクトにより受信し、内部的に保存する手段、
   ユーザＩＤおよびセッションＩＤを伴う認証要求を前記サーバ装置に送信し、前記データベースの参照により同じユーザＩＤおよびセッションＩＤの組が保存されているか否かによる認証を受けて、認証結果を受信する手段
   として機能させる端末プログラム。

Images