JP6463313B2 - プログラム、情報処理装置、情報処理方法及び情報処理システム - Google Patents

Description

本発明は、プログラム、情報処理装置、情報処理方法及び情報処理システムに関する。

サーバと通信接続された複数の端末からなるシステムにおいて、あるときに端末Ａで指定された特定の状態（Ｗｅｂブラウザで表示しているＷｅｂページ）を、別の端末Ｂでも共有するために、端末Ａと端末Ｂを通信ネットワークを介して同期する技術が、従来から存在する（例えば特許文献１参照）。
しかしながら、この技術を所定の情報セキュリティをもって実現するためには、端末Ａと端末Ｂのうち一方から他方に対する認証処理を行う必要がある。このような認証処理を実現するためにサーバでは各端末に対応したユーザ情報を管理する必要がある。しかしながら、ユーザ情報の管理には細心の注意が必要であり、また諸事情によってユーザ情報をサーバや端末に保持できないこともある。
そこで、通信接続を介さずに特定の状態の共有を行うことが要求されるが、この要求に応えるためには、あまりにも多い情報量では共有することに多大な労力を必要とするので、ユーザが簡単に記憶や伝達ができる程度の情報量をもって行われることが望ましい。

人間が記憶するには多過ぎる量の情報を、ある程度の量まで短縮する技術の一例として、ウェブ上の任意のＵＲＬをより短い文字列に短縮しておき、元の長いＵＲＬと、当該ＵＲＬが登録されたときに生成される短いＵＲＬとを紐付け、短いＵＲＬにアクセスがあったときに、元の長いＵＲＬへ転送する技術が存在する（例えば、特許文献２参照）。

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

しかしながら、上述のＵＲＬを短縮する技術であっても、英数小文字のみの識別子であるＵＲＬの桁数は極端に短くすることができないため、口頭での伝達に向かない。
また、ＵＲＬを短縮する方法は、新たなデータを登録するたびに識別子の組合せが消費されるため、スケーラビリティがない。
また、ＵＲＬは、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒの名称が表すとおり、Ｗｅｂ上の情報の場所を示すものであり、その場所で提供される情報（上記の特定の状態に相当）は、Ｗｅｂページ作成者によって任意に指定され得るものである。具体的には、あるＵＲＬで識別されている企業のトップページの内容を示す情報は任意に指定されるものであるが、既存のＵＲＬは、この情報の一意性を保証することができず、そのままでは、任意に指定される情報の伝達には適さない。したがって、このＵＲＬを短縮するサービスである短縮ＵＲＬ技術もこの情報の伝達には適していない。

本発明は、このような状況に鑑みてなされたものであり、あるデバイスで示された特定の状態を、特別なユーザ認証処理をせずとも即座にユーザ間、及び、デバイス間で共有する技術の確立を目的とする。

上記目的を達成するために、本発明の一態様の情報処理プログラムは、
再現性があり且つユーザによって任意に指定される特定の状態を当該指定に基づき表示可能な複数の端末との間で通信をするサーバに、
前記複数の端末のうち第１端末から、前記特定の状態と一意に対応付けられる第１識別子を用いたアクセスを受付ける受付ステップと、
前記第１識別子を用いたアクセスをしてきた前記第１端末において、前記特定の状態の指定が継続しているか否かを監視する監視ステップと、
前記第１端末による前記第１識別子を用いたアクセスが受け付けられたとき、第２識別子を生成する生成ステップと、
生成された前記第２識別子を、前記第１端末に表示させる制御を実行する表示制御ステップと、
当該第１端末において前記特定の状態の指定が継続している期間又は当該期間が終了してから所定期間では、前記特定の状態に対応する前記第１識別子と、生成された前記第２識別子との対応付けを管理し、その後、当該第１端末において前記特定の状態の指定の終了又は当該終了から所定期間の経過が監視されたとき、当該第１識別子と当該第２識別子との対応付けを破棄する管理ステップと、
前記管理ステップにおいて前記管理が継続されている間に、前記複数の端末のうち第２端末から前記第２識別子が通知された場合、当該第２識別子に対応付けられた前記第１識別子に対応する前記特定の状態を、当該第２端末で再現可能にするための制御を実行する状態再現ステップと、
を含む制御処理を実行させる。

本発明の一態様の情報処理装置、情報処理方法及び情報処理システムは、上述の本発明の一態様の情報処理プログラムに対応する情報処理装置、情報処理方法及び情報処理システムである。

本発明によれば、あるデバイスで示された特定の状態を、特別なユーザ認証処理をせずとも即座にユーザ間、及び、デバイス間で共有する技術の確立を目的とする。

本発明の一実施形態に係る情報処理システムの構成を示す図である。 図１の情報処理システムのうち、ユーザ端末１のハードウェア構成を示すブロック図である。 図１の情報処理システムのうち、本発明の情報処理装置の一実施形態に係るサーバ２のハードウェア構成を示すブロック図である。 口頭伝達可能な識別子を用いてデッキの情報をユーザ間や異種デバイス間で共有する方法の概要を示す図である。 ユーザ端末１―１と、ユーザ端末１―２と、サーバ２の機能的構成のうち、ゲームデータ共有制御を実行するための機能的構成例を示す機能ブロック図である。 第１識別子の特定手法及び当該第１識別子を用いるＵＲＬ生成手法の一例を示す図である。 ユーザ端末１に表示させる第１識別子及び第２識別子の表示の実装例を示す図である。 Ｕｓｅｒ−Ａが口頭で第２識別子を通知し、Ｕｓｅｒ−ＢがＵｓｅｒ−Ａのデッキの情報を共有する様子を示す図である。 ユーザのデッキの情報へのアクセスの手順を示す図である。 ＳＮＳ上でのデッキの情報の共有例を示す図である。 ユーザ端末１−１、ユーザ端末１−２及びサーバ２のゲームデータ共有処理の流れを示すアローチャートである。 本実施形態におけるフォーラム、掲示板、ＳＮＳ内にデッキの情報Ｐが表示される場合の実装例を示す図である。

以下、本発明の実施形態について、サーバと端末とをネットワーク通信接続させて行うネットワークゲームを一例として、図面を用いて説明する。

図１は、本発明の一実施形態に係る情報処理システムの構成を示している。
図１に示す情報処理システムは、ｍ人（ｍは１以上の任意の整数値）のユーザの夫々により使用されるユーザ端末１−１乃至１−ｍと、サーバ２とを含むシステムである。ユーザ端末１−１乃至１−ｍの夫々と、サーバ２とは、インターネット等の所定のネットワークＮを介して相互に接続されている。

サーバ２は、ユーザ端末１−１乃至１−ｍの夫々に対してゲームの実行環境を提供し、ユーザ端末１−１乃至１−ｍの夫々において実行されるゲームに関する各種各様のサービスを提供する。
ユーザ端末１−１乃至１−ｍの夫々は、各ユーザにより操作されるスマートフォン等で構成され、ゲームの実行等各種処理を実行する。
なお、以下、ユーザ端末１−１乃至１−ｍの夫々を個々に区別する必要がない場合、これらをまとめて「ユーザ端末１」と呼ぶ。

図２は、図１の情報処理システムのうち、ユーザ端末１のハードウェア構成を示すブロック図である。

ユーザ端末１は、上述した様にスマートフォン等で構成される。
ユーザ端末１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２３と、バス２４と、入出力インターフェース２５と、タッチ操作入力部２６と、表示部２７と、入力部２８と、記憶部２９と、通信部３０と、ドライブ３１と、を備えている。

ＣＰＵ２１は、ＲＯＭ２２に記録されているプログラム、又は、記憶部２９からＲＡＭ２３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ２３には、ＣＰＵ２１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ２１、ＲＯＭ２２及びＲＡＭ２３は、バス２４を介して相互に接続されている。このバス２４にはまた、入出力インターフェース２５も接続されている。入出力インターフェース２５には、タッチ操作入力部２６、表示部２７、入力部２８、記憶部２９、通信部３０、及びドライブ３１が接続されている。

タッチ操作入力部２６は、例えば表示部２７の表示面に積層される静電容量式又は抵抗膜式（感圧式）の位置入力センサにより構成され、タッチ操作がなされた位置の座標を検出する。
ここで、タッチ操作とは、タッチ操作入力部２６に対する物体の接触の操作をいう。タッチ操作入力部２６に対して接触する物体は、例えばユーザの指やタッチペン等である。
表示部２７は、液晶等のディスプレイにより構成され、ゲームに関する画像等、各種画像を表示する。
このように、本実施形態では、タッチ操作入力部２６と表示部２７とにより、タッチパネルが構成されている。

入力部２８は、各種ハードウェア釦等で構成され、ユーザの指示操作に応じて各種情報を入力する。
記憶部２９は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部３０は、インターネットを含むネットワークＮを介して他の装置（図１の例ではサーバ２や他のユーザ端末１）との間で行う通信を制御する。

ドライブ３１は、必要に応じて設けられる。ドライブ３１には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア４１が適宜装着される。ドライブ３１によってリムーバブルメディア４１から読み出されたプログラムは、必要に応じて記憶部２９にインストールされる。また、リムーバブルメディア４１は、記憶部２９に記憶されている各種データも、記憶部２９と同様に記憶することができる。

図３は、図１の情報処理システムのうち、本発明の情報処理装置の一実施形態に係るサーバ２のハードウェア構成を示すブロック図である。

サーバ２は、ＣＰＵ５１と、ＲＯＭ５２と、ＲＡＭ５３と、バス５４と、入出力インターフェース５５と、出力部５６と、入力部５７と、記憶部５８と、通信部５９と、ドライブ６０とを備えている。
サーバ２の構成は、ユーザ端末１のタッチパネルを除いた構成と基本的に同様であるので、ここではその説明は省略する。

このような図２のユーザ端末１及び図３のサーバ２の各種ハードウェアと各種ソフトウェアとの協働により、ユーザ端末１でゲームの実行が可能になる。
即ち、本実施形態の情報処理システムは、複数のユーザが参加可能なゲームに対する各種制御を実行できる。特に、情報処理システムは、特別なユーザ認証をせずとも当該ゲームに関するデータをユーザ間及び異種デバイス間で瞬時に共有する制御（以下、「データ共有制御」と呼ぶ）として、次のような制御を実行することができる。

即ち、本実施形態の情報処理システムは、カードゲームや箱庭ゲーム（ミニスケープ）等のユーザが多種多様な特定の状態を指定するゲームを対象とする制御を実行する。ここでいうデータとは、ゲームの特定の状態を示すデータを意味する。
ゲームの特定の状態とは、再現性がありかつユーザによって任意に指定される状態をいう。例えばカードゲームであれば、ユーザにより指定された特定の複数種類のカードの組合せで構成されるカードデッキ（以下、単にデッキと呼ぶ）が、特定の状態の一例である。

本実施形態の情報処理システムは、ユーザにより指定されたデータを、多様な媒体を通じて、異種のデバイス（異種のユーザ端末１）の間で容易に共有可能にすることができる。
ユーザにより指定されたデータ、即ちゲームの特定の状態を示すデータを共有可能にするために、コードが用いられる。さらに、多様な媒体を通じて、異種のデバイスの間で当該データを容易に共有可能にするためには、ユーザが覚えやすい程度に短縮変換された短縮コードを用いると好適である。
ただし、本実施形態の情報処理システムは、ユーザによって任意に指定される膨大な種類になり得るデータ（即ち膨大な種類になり得るゲームの特定の状態）に対して短縮コードを直接割り当てるのではなく、そのデータを指定するためのアクセスを行う“コネクション”に対して短縮コードを割り当てる。この“コネクション”はユーザ端末１（ユーザ）がサーバ２に対して任意のタイミングで行うアクセスであり、且つ永続しないものである。即ち、ゲームアプリケーションソフトウェアを通じてサーバ２にアクセスしている最中（或いはアクセス終了から所定期間まで）のユーザ端末１の数は最大でも登録ユーザ数までであり、データの種類に比べれば限定的な数として考えることができる。
本実施形態の情報処理システムは、短縮コードとして、例えば４文字程度の極めて短い短縮コードを採用することができる。具体的には例えば、１０の１０００乗以上の組み合わせを有する複雑なデータ（ゲームの特定の状態）に対しても、４文字程度の極めて短い短縮コードを用いることで、当該データを一意に識別することができる。

即ち、本実施形態では、データを様々なメディア（紙媒体、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）、無線通信等）上で流通させる際に用いる識別子（以下、「第１識別子」と呼ぶ）とは独立させて、当該データをゲームアプリケーションソフトウェア（以下、「アプリケーションソフトウェア」を適宜「アプリケーション」あるいは「アプリ」と短縮して呼ぶ）に読み込ませるときに用いる識別子（以下、「第２識別子」と呼ぶ）が、４文字程度の極めて短い短縮コードにより実現される。
そして、本実施形態では、この第１識別子と第２識別子との対応関係を動的に管理する２段階識別子管理方式が採用されている。これにより、情報の表現能力と入力の容易性を併せ持つ、データの流通や入力が実現可能になる。

具体的には例えば本実施形態の情報処理システムでは、再現性があり且つユーザによって任意に指定される特定の状態を示すデータに対して、一意の第１識別子が特定される。 この第１識別子は、内容依存の一意性を有する。従って、異なるユーザが指定したデータであっても、同じゲームアプリケーション内の同一の特定の状態を示すデータに対しては、必ず同一の第１識別子が特定される。
換言すると、ゲーム内の特定の状態が異なる場合は、必ず異なる第１識別子が特定される。
第１識別子は、図示しない第１識別子特定部によって特定される情報である。第１識別子特定部は、所定のアプリケーション（本実施形態ではゲームアプリケーション）に適用するために設計された特定のアルゴリズムによって、所定のアプリケーションにおいて再現性のある特定の状態を一意に示す情報として、第１識別子を特定する。第１識別子が特定されるタイミングは任意のタイミングでよいので、第１識別子特定部は第１識別子を特定して管理する機能を追加で有していてもよい。また、この第１識別子特定部の存在場所は、特に限定されない。つまり、第１識別子特定部は、サーバ２に備えられていてもよいし、サーバ２と連携する別の装置に備えられていてもよい。
ここで本実施形態では、流通用の第１識別子はそのままの形態で用いられるのではなく、当該第１識別子をＵＲＬ文字列内にエンコードしたもの、即ち当該第１識別子をパラメーターとして含むＵＲＬが用いられる。
つまり本実施形態では、ユーザが当該ＵＲＬに存在するデータ（第１識別子により特定されるゲームの特定の状態）をＷｅｂブラウザ等で閲覧することが、当該特定の状態を指定していることを意味する。そして、当該ＵＲＬへのアクセスが継続し、コネクションが成立している期間が、特定の状態の指定が継続している期間に該当する。
なお、第１識別子としてＵＲＬを用いるのは一例であり、これに限定されない。別の例については後述する。

上述した様に、ユーザが、特定の状態を指定して、当該特定の状態を示すデータを閲覧するためには、ユーザ端末１を操作して、当該特定の状態に対応する第１識別子をパラメーターとして含むＵＲＬにアクセスし、当該ＵＲＬの場所にあるデータを所定のＷｅｂブラウザ等で閲覧する必要がある。 この特定の状態の指定が継続している期間のみ、即ち当該ＵＲＬへのコネクションが成立している期間のみ、換言すると、当該データが閲覧されている期間のみ有効な一時的な識別子が、第２識別子として生成される。
この第２識別子は、例えば４文字程度の文字列として生成され、第１識別子と紐づけられた上で、ユーザに提示される。これにより、提示されたユーザ又は当該ユーザから口頭等で伝達された他ユーザは、この４文字程度の文字列を、実行中のゲーム内等で入力する操作をするだけで、対応するデータ、即ち指定が継続されている特定の状態を示すデータを取得することができる。

以上説明したように、ゲームの特定の状態を示すデータの種類数は、当該データの各構成要素（例えばカードゲームならばカード）の膨大な組み合わせに応じて、膨大な種類数になる。このような膨大な種類数のデータに対しては、内容依存の一意性を有する第１識別子が割り当てられる。
つまり、第１識別子は、特定のユーザの情報（ユーザを識別するためのＩＤや個人情報など）は含まれておらず、データの内容のみに依存するため、ゲーム内で指定される特定の状態が同一であれば、どのユーザも同一のＵＲＬの場所にアクセスすることになる。
具体的には例えばカードゲームの場合、ゲームの特定の状態はデッキになるが、異なるユーザの同一のデッキ構成には、必ず同一の第１識別子が対応付けられる。したがって、本実施形態によるゲームのデータの共有にはユーザを特定するための情報を用いる必要性がなく、更にはユーザによる認証の必要がない。従って、ユーザ情報を管理しているゲームサーバ（本実施形態ではサーバ２）にアクセスせずともデータの共有が可能である。以上の通りであるので、本実施形態の情報処理システムによれば、例えばゲームの運営者ではないサードパーティが用意したゲームサーバ以外のサーバを利用しても容易に実現することができる。

一方、第２識別子は、ゲームの特定の状態ではなく、第１識別子を用いたアクセス（コネクション）に対して割り当てられる。ここで、複数のユーザ端末１のうち同時にアクセスするユーザ端末１の台数は、ゲームの特定の状態の種類数に比較して圧倒的に少ないため、第２識別子は、上述した様に、４文字程度の文字列で実現可能になる。
そして、この第２識別子と第１識別子とを紐付けて管理することで、結果として、ゲームの特定の状態を示すデータという膨大な組み合わせを、あたかも極めて短いコード（第２識別子）で表現することができる。
これにより、情報の表現能力と入力の容易性を併せ持つデータの流通や入力が実現可能になる。また、ゲームの特定の状態を示すデータを共有する際においても、ユーザの認証は不要になる。

カードゲームを例にさらに説明すると、当該カードゲーム内においてユーザが指定するデータのうち、特に、“デッキ”と呼ばれるデータは、ゲームで用いられる複数のカードの組み合わせを示すデータであり、ゲームの特定の状態を示すデータである。
本実施形態の第１識別子と第２識別子の紐付けの方式を採用することで、同一のデッキを、異なるユーザ間や、同一ユーザであっても異なるデバイス間で、極めて手軽に送受信可能にすることが可能になる。
具体的には例えば、同一ユーザが、ログイン等の処理を行わずに、スマートフォン（ユーザ端末２）上に登録されているデッキを、パーソナルコンピュータ（別のユーザ端末２）等で編集し、それを即座にスマートフォンへ反映するというような、一時的なデバイス間の共有処理が実現可能になる。或いは、ユーザが、その場にいる別のユーザ（友達）に対して即座に、自分のデッキを伝えるような、一時的なユーザ間の共有処理も実現可能になる。

具体的には例えば、４，０００種類のカードから、重複ありの４０枚を選択してデッキを構成するカードゲームが採用されているものとする。
このようなカードゲームでは、カードの組み合わせ数は膨大であり、４０枚のカードから構成されるデッキ（ゲームの状態）は、４０００＾４０（＝１．２×１０＾１４４）という膨大な種類数が存在することになる。
従って、これらの膨大な種類のデッキを、一意に識別する識別子を単純に付与すると、整数を用いた場合で１４４桁、数字とアルファベットといくつかの記号を含む、６４文字の組み合わせとして表現した場合でも８０桁の識別子が必要となる。このように長い文字列として表現される識別子は、人がその場で記憶することが難しく、例えばユーザ同士の口頭でのコミュニケーションや、イベント会場でデッキを観衆にアナウンスする場合などに用いることはできない。
一方で、ユーザが指定したデッキを一意に特定するためには、８０桁の識別子を用いざるを得ない。そこで、ユーザが指定したデッキを一意に特定するために、この８０桁の識別子が、第１識別子として採用される。
そして、ユーザがその場で容易に記憶して、例えばユーザ同士の口頭でのコミュニケーションや、イベント会場でデッキを観衆にアナウンスする場合等に用いることができるように、第１識別子と紐付けられた、４桁程度の第２識別子が用いられるのである。
この第２識別子は、ユーザが第１識別子を用いたアクセスをして、当該第１識別に対応付けられたデッキの閲覧を継続している間だけ有効となるものである。つまり、ユーザによるアクセス（第１識別子に対応付けられたデッキの閲覧）に対して、第２識別子が割り当てられる。
ここで、上述した様に、ゲーム内の特定の状態数よりも、ゲームを同時にプレイするユーザ数のほうが圧倒的に少数である。このため、第２識別子として、４桁程度の非常に短い識別子を採用することができるのである。

また、ユーザは、デッキを他のユーザと共有するだけではなく、ログイン等の処理を行わずに、スマートフォン（第１のユーザ端末１）上に登録されているデッキをパーソナルコンピュータ（第２のユーザ端末１）で編集し、それを即座に当該スマートフォンへ反映するという、一時的なデバイス間でのデッキの共有を望む場合もある。
このような共有も、第１識別子と第２識別子の紐付けを動的に行っていることにより、容易に実現可能になる。つまり、１人のユーザが、デバイス間のやり取りのために仮に何千回も登録処理を行ったとしても、識別子の数が不足しないというスケーラビリティを実現することができる。

さらに以下、このようなゲームのデータの共有について、図４を参照して説明する。
図４は、口頭伝達可能な識別子を用いてデッキの情報をユーザ間や異種デバイス間で共有する方法の概要を示す図である。

本実施形態の情報処理システムは、ゲーム内の各種状況のうちユーザにより指定された特定の状態を永続的に識別できる第１識別子と、第１識別子を用いたサーバ２へのアクセス（特定の状態の指定を継続していること）を一時的に識別できる第２識別子とを動的に関連付けるスケーラブルな２段階識別子管理を実行する。これにより、ユーザからみた場合には、４文字程度の極めて少ない情報量の第２識別子を用いるだけで、膨大な組み合わせのゲーム内の各種特定の状態のうち、ユーザにより指定された特定の状態を識別し、異種のデバイス間やユーザ間で、当該特定の状態を再現可能なデータの転送が可能になる。
ここで、スケーラブルな２段階識別子管理とは、ゲーム内の特定の状態数が膨大な数となった場合においても、ユーザが入力する第２識別子の桁数が増加せず、かつ、他ユーザや他デバイスへデータを転送するためのデータ登録処理の回数が膨大な数となった場合においても、ユーザが入力する第２識別子の桁数が増加しないことを意味する。

図４の上段に表されているのが、ゲーム内の特定の状態である。具体的には図４の例では、カードゲーム内において使用されるカードデッキが表されている。
図４の中段に表されているのが、ゲーム内の特定の状態を永続的に識別することができる第１識別子である。図４に示す通り、図中の左から右の順に従いゲーム内の特定の状態が異なっており、異なるゲーム内の各特定の状態の夫々に対して第１識別子が割り当てられる。
図４の下段に表されているのが、その中段に表されている第１識別子に対応する第２識別子である。第１識別子を用いたアクセス（ここでは第１識別子を含んだＵＲＬにアクセス）があるたびに、セッション期間（ユーザにより、第１識別子に対応する特定の状態が指定されている期間）のみ有効な第２識別子が生成される。

さらに、以下、第１識別子及び第２識別子について詳しく説明する。
第１識別子は、ゲームの膨大な種類の特定の状態を識別できる、永続的にユニークな識別子である。第１識別子は、ある特定のゲームアプリケーション内においては特定の状態を示すデータを常に一意に識別することを永続的にできるため、雑誌等の紙媒体や、ＳＮＳ等のネットワークサービスを経由して、データを流通させる用途に適している。さらに、第１識別子を、ＵＲＬとして表現することにより、既存のＵＲＬを流通させる仕組みをそのまま利用して第１識別子を流通させることができる。
第２識別子は、４文字程度と短い文字列で表され、所定のユーザ端末１から即座にゲームを実行している他のユーザ端末１に対してデータを転送する用途で用いられるのに適している。本実施形態では、この第２識別子は、第１識別子を用いたアクセスがあるたびに、動的に生成される。
即ち、ユーザ端末１が、第１識別子を用いたアクセス（後述するように例えば第１識別子を含むＵＲＬにアクセス）すると、当該第１識別子に対応するゲームの特定の状態（例えばデッキの情報等）がユーザに閲覧可能になる。このとき、サーバ２は、このアクセスによるセッション（特定の状態の指定）に対して、第２識別子を割当て、当該特定の状態に対応する第１識別子と紐付ける。この第２識別子が別のユーザ端末１に入力されると、当該第２識別子と紐付けられた当該第１識別子に対応する特定の状態（デッキ）が獲得される。

以上図４を用いて説明したゲームデータ共有制御を実行すべく、図２のユーザ端末１と図３のサーバ２は、図５に示すような機能的構成を有している。
図５は、ユーザ端末１―１と、ユーザ端末１―２と、サーバ２の機能的構成のうち、ゲームデータ共有制御を実行するための機能的構成例を示す機能ブロック図である。
なお、ユーザ端末１−１とユーザ端末１−２は、便宜的に選択されたものであって、図５に示すユーザ端末１−１の機能ブロックとユーザ端末１−２の機能ブロックとは併せて、全てのユーザ端末１において機能するものである。

図５に示すように、サーバ２のＣＰＵ５１においては、受付部１０１と、状態監視部１０２と、第２識別子生成部１０３と、対応付け管理部１０４と、表示制御部１０５と、状態再現部１０６とが機能する。
また、サーバ２の記憶部５８においては、対応付け管理ＤＢ１１１が設けられる。

受付部１０１は、ユーザ端末１−１のアクセス部１２２から、特定の状態と一意に対応付けられる第１識別子を用いたアクセスを受付ける。
ここで、第１識別子を用いたアクセスの手法は、第１識別子を用いれば足り、特に限定されないが、本実施形態では、第１識別子を含むＵＲＬにアクセスする手法が採用されている。以下、この手法について図６を用いて具体的に説明する。

図６は、第１識別子の特定手法及び当該第１識別子を用いるＵＲＬ生成手法の一例を示す図である。
図６の例では、１万種類のカードから選択した４０枚のカードの組をデッキ（指定されたゲームの特定の状態）として編成するゲームを想定している。図６においては、１枚のカードは、中に数字が付されたボックスとして描画されている。ボックス（カード）内の数字は、カードの通し番号であり、当然ながら実際のカードに必ずしも印字されているわけではない。
図６のカードの通し番号を、“０１２３４５６７８９ＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺａｂｃｄｅｆｇｈｉｊｋｌｍＮＯＰＱＲＳＴＵＶＷＸＹＺ−＿”の６４文字の組み合わせとして表現する６４ビット符号化を行い、ドット記号“．”でそれぞれのカードを区切ることにより、ＵＲＬ内に埋め込み可能な文字列として特定してデッキ全体を表現することができる。
図６のボックス下に表されている文字列が、デッキの内容を６４ビット符号化した文字列である。これをＵＲＬに展開したものが、図６の矢印の下に表されている。本実施例では、このＵＲＬをＳＮＳを通じて共有、拡散することができる。

図５に戻り、状態監視部１０２は、第１識別子を用いたアクセスをしてきたユーザ端末１−１において、特定の状態の指定が継続しているか否かを監視する。
このように、ユーザ端末１−１における特定の状態の指定は、サーバ２が監視可能なように行われる。つまり、第１識別子を用いたアクセスがユーザ端末１−１からなされてきた場合、状態監視部１０２は、当該第１識別子に対応する特定の状態の指定がなされたものとして、その監視を開始する。
ここで、特定の状態の指定の継続の判断手法は、ネットワーク通信技術を利用した様々な手法が採用可能であり、特に限定されない。例えば、ユーザ端末１−１からのネットワーク接続の継続中は、特定の状態の指定が継続していると判断する手法を採用してもよい。ここで、ネットワーク接続とは、物理的な通信接続のみならず、論理的な通信接続を含めた広義な概念をいう。ここで論理的な通信接続とは、物理的な通信接続が一時的に切断されても、例えばクッキーやトークン等の技術を用いることで、ある特定の端末が継続的にサーバにアクセスしていることを、サーバが認識していることを意味する。また例えば、ユーザ端末１−１に周期的にｐｉｎｇリクエストを送信しその応答が途絶えない間若しくは途絶えてから一定時間経過するまでの間、特定の状態の指定の継続と判断する手法を採用してもよい。また、例えば、ユーザ端末１−１から周期的にサーバ２にｐｉｎｇメッセージを送信し、その送信が途絶えない間もしくは途絶えてから一定時間経過するまでの間、特定の状態の指定の継続と判断する手法を採用してもよい。

第２識別子生成部１０３は、ユーザ端末１−１による第１識別子を用いたアクセスが受付部１０１により受付けられたとき、第２識別子を生成する。

対応付け管理部１０４は、ユーザ端末１−１において特定の状態の指定が継続している期間又は当該期間が終了してから所定期間では、特定の状態に対応する第１識別子と、生成された第２識別子との対応付けを管理し、その後、当該ユーザ端末１−１において特定の状態の指定の終了又は当該終了から所定期間の経過が監視されたとき、当該第１識別子と当該第２識別子との対応付けを破棄する。
具体的には、対応付け管理部１０４は、第２識別子生成部１０３により生成された第２識別子と、当該第２識別子が生成される際に受け付けられたアクセスで用いられた第１識別子とを対応付けて、管理ＤＢ１１１に登録することで、第１識別子と第２識別子の対応付けを管理する。
その後、対応付け管理部１０４は、ユーザ端末１−１において特定の状態の指定の終了又は当該終了から所定期間の経過が監視されたとき、第１識別子と第２識別子との登録を対応付け管理ＤＢ１１１から削除することにより、第１識別子と第２識別子との対応付けを破棄する。即ち、第２識別子が無効になる。

表示制御部１０５は、第２識別子生成部１０３により生成された第２識別子を、第１識別子を用いてアクセスしてきたユーザ端末１−１に表示させる制御を実行する。

図７は、ユーザ端末１に表示させる第１識別子及び第２識別子の表示の実装例を示す図である。
図７の上方に示す様に、ユーザ端末１−１を操作するユーザによりデッキが生成されると、そのデッキの構成が表示されると共に、その下方に第１識別子が表示される。
この第１識別子を用いたアクセス（第１識別子を含むＵＲＬへのアクセス）がなされ、その結果として、上述した様にサーバ２において、例えば第２識別子“ｔｒ０ｎ”が生成され、当該第１識別子と対応付けられると、サーバ２の表示制御部１０５の制御により、第２識別子“ｔｒ０ｎ”は、図７の下方の［Ｃｏｄｅ：］と表示された右方のボックスに表示される。
この第２識別子は、ユーザ端末１−１を操作するユーザにより図７のデッキが指定されている間、即ち、この例では、図７の画面がユーザ端末１−１に表示されてユーザにより閲覧されている間、有効である。
具体的には図７の下方にある円により、第２識別子の残りの有効時間がアニメーションで表示される。ユーザ端末１−１において図７の画面を開き続けていると第２識別子の有効期限は自動更新される。なお、画面を開き続けているか否かの判定は、上述した特定の状態の指定の継続の判断によって行われる。

例えば、ユーザ端末１−１を操作するユーザは、異なるデバイスであるユーザ端末１−２を用いて、所定のアプリケーションプログラムやデッキビルディングを行うためのＷｅｂサイトにおいて、第２識別子“ｔｒ０ｎ”を入力することができる。
或いはまた例えば、ユーザ端末１−１を操作するユーザから口頭等により第２識別子を伝達された別のユーザは、自分が操作するユーザ端末１−２を用いて、所定のアプリケーションプログラムやデッキビルディングを行うためのＷｅｂサイトにおいて、第２識別子“ｔｒ０ｎ”を入力することができる。

図５に戻り、このようにユーザ端末１−２により第２識別子が入力されると、当該第２識別子はサーバの状態再現部１０６に通知される。
そこで、状態再現部１０６は、当該第２識別子に対応付けられた第１識別子に対応する特定の状態を、ユーザ端末１−２で再現可能にするための制御を実行する。
具体的には例えば図７の例で説明すると、状態再現部１０６は、第２識別子に対応付けられた第１識別子で特定されるデッキの情報（図７の画面情報に表示されたデッキと同一デッキの情報）を再現し、ユーザ端末１−２に表示する。

このように、ユーザ間やデバイス間でのゲームの特定の状態（デッキの構成）の共有のキーとして、“ｔｒ０ｎ”のような４桁程度の短い第２識別子を用いることができる。その結果、デッキの構造等複雑な情報のやり取りが極めて容易に実現可能になる。

ユーザ端末１−１とユーザ端末１−２についても、機能的構成の概略について説明する。
先ず、図５に示すように、ユーザ端末１―１のＣＰＵ２１においては、状態指定解除部１２１と、アクセス部１２２と、表示制御部１２３とが機能する。

状態指定解除部１２１は、特定の状態の指定又は解除を行う。
具体的には、状態指定解除部１２１は、ユーザ端末１−１のタッチパネルを通じてユーザがある特定の状態を指定した場合（例えばデッキを生成又は選択した場合）、その指定を受付け、指定された特定の状態を、下記表示制御部１２３を介してタッチパネルに表示させると共にユーザ端末１−１の記憶部２９やサーバ２の記憶部５８に保存させる。また、ユーザは、過去に指定した状態（例えば生成済みのデッキ）を例えば記憶部２９あるいは記憶部５８から読み出し、新たに指定することができる。この場合、状態指定解除部１２１は、その指定を受付け、指定された特定の状態を下記表示制御部１２３を介してタッチパネルに表示させる。
特定の状態が指定されると、下記アクセス部１２２により、当該特定の状態に対応する第１識別子を用いたアクセスが行われる。これにより、サーバ２において、特定の状態の指定が開始したことが認識される。
その後、状態指定解除部１２１は、サーバ２側で認識できるような形態で、特定の状態の指定を解除する。
この特定の状態の指定の解除（終了）の手法は、サーバ２側で認識できる手法、つまりサーバ２側で採用される特定の状態の指定の終了の判断手法にあわせた手法であれば足りる。
例えばネットワーク接続の切断により特定の状態の指定の終了と判断する手法がサーバ２側で採用されている場合には、状態指定解除部１２１は、サーバ２とのネットワーク接続を切断することで、特定の状態の指定を解除する。
また例えば、ユーザ端末１−１に周期的にｐｉｎｇリクエストを送信しその応答が途絶えてから一定時間経過したことにより、特定の状態の指定の終了と判断する手法がサーバ２側で採用している場合には、状態指定解除部１２１は、特定の状態の指定を継続する際にはｐｉｎｇリクエストの応答を生成し、特定の状態を解除する場合には応答の生成を禁止する処理を実行する。

アクセス部１２２は、特定の状態が指定された場合、当該特定の状態に対応する第１識別子を用いたアクセスを行う制御を実行する。
表示制御部１２３は、上述したように特定の状態が指定されると、当該特定の状態（必要に応じて第１識別子）をタッチパネルに表示させると共に、当該第１識別子と対応する第２識別子がサーバ２により生成されて通知されてきた場合、当該第２識別子をタッチパネルに表示させる制御を実行する。即ち、表示制御部１２３は、例えば図７に示すような画面をタッチパネルに表示させる制御を実行する。

以上、ユーザ端末１−１の機能的構成の概略について説明した。次に、ユーザ端末１−２の機能的構成の概略について説明する。

ユーザ端末１−２のＣＰＵ２１においては、第２識別子入力受付部１３１と、通知制御実行部１３２と、閲覧制御実行部１３３とが機能する。

第２識別子入力受付部１３１は、ユーザ端末１−１の表示部２７に表示された第２識別子であって、ユーザ端末１−２を操作するユーザ（ユーザ端末１−１と同一人の場合もあるし異人の場合もある）によりタッチパネル等により入力された第２識別子の入力を受付ける。
ここで、ユーザ端末１−１のユーザがＵｓｅｒ−Ａであり、ユーザ端末１−２のユーザが異人のＵｓｅｒ−Ｂであるとして、図８を用いて、ユーザ端末１−１に表示される第２識別子と、ユーザ端末１−２に入力される第２識別子との対応関係について説明する。

図８は、Ｕｓｅｒ−Ａが口頭で第２識別子を通知し、Ｕｓｅｒ−ＢがＵｓｅｒ−Ａのデッキの情報を共有する様子を示す図である。
図８に示す通り、Ｕｓｅｒ−Ａが、自分自身のデッキをＵｓｅｒ−Ｂ側で再現させるために、第２識別子“ｔｒ０ｎ”を口頭でＵｓｅｒ−Ｂに通知している。
ここで、第２識別子“ｔｒ０ｎ”は、Ｕｓｅｒ−Ａが所有するユーザ端末１−１がデッキを表示した時（特定の状態を指定した時）に、当該デッキに対応する第１識別子を用いたアクセスがなされた結果として、サーバ２により生成されて、ユーザ端末１−１に表示されたものである（図７参照）。
第２識別子“ｔｒ０ｎ”は、デッキの情報がユーザ端末１−１の画面上に表示されている限り（つまり、特定の状態の指定が継続している限り）、有効化されて管理され続ける。
この第２識別子“ｔｒ０ｎ”を口頭で伝達されたＵｓｅｒ−Ｂは、ユーザ端末１−２のタッチパネル等を用いて、当該第２識別子“ｔｒ０ｎ”を入力する。

図５に戻り、ユーザ端末１−２の第２識別子入力受付部１３１は、この入力された第２識別子“ｔｒ０ｎ”を受付ける。
通知制御実行部１３２は、第２識別子入力受付部１３１により入力された第２識別子、例えば図８の例では“ｔｒ０ｎ”をサーバ２に通知する制御を実行する。
すると、上述した様に、サーバ２の状態再現部１０６は、当該第２識別子（図８の例では“ｔｒ０ｎ”）に対応付けられた第１識別子に対応する特定の状態（図８の例では、同図に図示されるデッキの情報）を、ユーザ端末１−２で再現可能にするための制御を実行する。
閲覧制御実行部１３３は、このサーバ２の状態再現部１０６の制御のもと、当該第２識別子（図８の例では“ｔｒ０ｎ”）に対応付けられた第１識別子に対応する特定の状態（図８の例では、同図に図示されるデッキの情報）をユーザ（図８の例ではＵｓｅｒ−Ｂ）に閲覧させる制御を実行する。

このようにして、Ｕｓｅｒ−ＡとＵｓｅｒ−Ｂ同士のペアリング処理（例えば、ゲーム内でフレンドになる）や、両者のユーザ端末１同士のペアリング処理を行わずとも、口頭で伝達可能な短い文字列（この場合、“ｔｒ０ｎ”）である第２識別子を通知するだけで、デッキの情報を共有することが可能になる。
即ち、本実施形態では、デッキの情報を対象として短縮コードが割り当てられるのではなく、デッキの情報そのものには、普遍的かつ永続的な第１識別子が割り当てられる。そして、その永続的な第１識別子を用いたアクセスを条件として、短い文字列等の第２識別子が生成され、第１識別子と第２識別子とが対応付けられる。その結果として、ユーザの立場にたてば、第２識別子の短い文字列等を口頭の発音のみで伝達するだけで、結果として、デッキの情報を伝達することが実現可能とすることができる。
数理的には、例えば、４，０００枚のカードを４０枚組み合わせるとき、４，０００＾４０（＝１．２×１０＾１４４）のバリエーションが存在し、それらを４文字のコードだけでは表現することが出来ない。
しかし、それらのバリエーションへのネットワーク接続を同時に行うユーザ数には、一定の上限があり、数十万程度であるため、１，６７９，６１６通りの組み合わせを表現可能な４桁の英数文字を第２識別子として表現することで、結果として、４，０００枚のカードの中から任意に選択した４０枚組のデッキの情報を伝達することが可能になる。

以上、ゲームデータ共有制御を実現するためのユーザ端末１−１、ユーザ端末１−２及びサーバ２の機能的構成について説明した。
次に、図９を参照して、ユーザ端末１−１とユーザ端末１−２のユーザ側からのゲームデータ共有の流れを説明する。

図９は、ユーザのデッキの情報へのアクセスの手順を示す図である。
なお、ユーザ端末１−１及びユーザ端末１−２は、同一のユーザが所有する異なる端末（例えば、スマートフォンとパーソナルコンピュータ）でもよいし、異なるユーザが所有する異なる端末でも良い。
第１の手順として、ユーザは、ユーザ端末１−１を操作して、第１識別子をＳＮＳから取得したり、自身のデッキの第１識別子であればゲームのセーブデータから読み込んで取得する。そして、ユーザは、第１識別子により一意に対応付けられるデッキ（ゲーム内の特定の状態）を、ユーザ端末１−１のタッチパネル等に表示されるＷｅｂブラウザやゲームアプリを通じて閲覧する。
第２の手順として、ゲーム内のデッキ（特定の状態）をＷｅｂブラウザやゲームアプリを通じて閲覧すると、その閲覧行為が継続している間（例えば、ネットワークの接続が確立している間）だけ有効な第２識別子（ここでは“ｔｒ０ｎ”）がユーザ端末１−１のタッチパネル等に表示されるため、ユーザは表示された第２識別子（ここでは“ｔｒ０ｎ”）を視認する。
第３の手順として、ユーザは、ユーザ端末１−１に表示された第２識別子（ここでは“ｔｒ０ｎ”）を、ユーザ端末１−２のタッチパネル等を用いて入力する。ここで、ユーザが異人であれば、第３の手順を行うユーザ（第２のユーザ）は、第２の手順で視認したユーザ（第１のユーザ）から、第２識別子（ここでは“ｔｒ０ｎ”）を口頭等で予め伝達してもらう必要がある。
第４の手順として、第３の手順を受けてサーバ２により、第３の手順で入力された第２識別子（ここでは“ｔｒ０ｎ”）に対応する第１識別子のゲーム内の特定の状態がユーザ端末１−２に再現される。このようにして、ユーザは、第１の手順で取得された第１の識別子に対応するデッキの情報にアクセスすることが可能になる。
なお、ユーザ端末１−１によるデッキの閲覧が終了すると（ゲーム内の特定の状態の指示が解除されると）、第２識別子（ここでは“ｔｒ０ｎ”）と第１識別子との対応付けは破棄される。

次に、本実施形態のＳＮＳ上での活用を説明する。
図１０は、ＳＮＳ上でのデッキの情報の共有例を示す図である。
図１０の左方に示すように、第１ＳＮＳ上のＯＧＰ（Ｏｐｅｎ Ｇｒａｐｈ Ｐｒｏｔｃｏｌ）に第１識別子を含むＵＲＬとデッキ（ゲーム内の特定の状態）の情報が表示されている。第１ＳＮＳの利用者は、ＯＧＰ上のＵＲＬをクリックすることにより、第１識別子に対応付けられたデッキ（ゲーム内の特定の状態）にアクセスをすることができる。
また、図１０の右方に示すように、第２ＳＮＳ上のＯＧＰに長方形のボタンとデッキが表示されている。この長方形のボタンは、第１識別子を含むＵＲＬと対応付けられており、第２ＳＮＳの利用者は、ＯＧＰ上の長方形のボタンをクリックすることにより、第１識別子に対応付けられたデッキ（ゲーム内の特定の状態）にアクセスをすることができる。
このような処理ができるのは、第１識別子が、本実施例のシステム内部の識別子であるだけでなく、ＵＲＬに埋め込むことが可能な識別子であって、ＳＮＳを通じた広域なデッキの情報の流通に適した識別子であるためである。
これにより、ＳＮＳのＯＧＰのフォーマットに従って記述されたＷｅｂページを、図１０のようにサムネイル化して、デッキの情報を拡散することができる。

次に、図１１を参照して、図５のような機能的構成を有するユーザ端末１−１、ユーザ端末１−２及びサーバ２が実行する、ゲームデータ共有処理の流れを説明する。
図１１は、ユーザ端末１−１、ユーザ端末１−２及びサーバ２のゲームデータ共有処理の流れを示すアローチャートである。

ステップＳ１において、ユーザ端末１−１の状態指定解除部１２１は、特定の状態の指定を行う。
ステップＳ２において、ユーザ端末１−１のアクセス部１２２は、特定の状態に対応する第１識別子を用いたアクセスを行う。

ステップＳ２０において、サーバ２の受付部１０１は、ユーザ端末１−１からの第１識別子を用いたアクセスを受付ける。
ステップＳ２１において、サーバ２の状態監視部１０２は、ステップＳ２０のアクセスに基づいて第１識別子を認識する。
ステップＳ２２において、サーバ２の第２識別子生成部１０３は、第２識別子を生成する。
ステップＳ２３において、サーバ２の対応付け管理部１０４は、ステップＳ２１で認識された第１識別子と、ステップＳ２２で生成された第２識別子との対応付けを行う。
ステップＳ２４において、サーバ２の表示制御部１０５は、ステップＳ２２で生成された第２識別子を、ユーザ端末１−１に通知する。

ステップＳ３において、ユーザ端末１−１の表示制御部１２３は、ステップＳ２４でサーバ２から通知された第２識別子をタッチパネルに表示させる。
ここでユーザ端末１−１のタッチパネルに表示された第２識別子は、ユーザ端末１−２を操作するユーザに伝達される。
ここで、ユーザ端末１−１とユーザ端末１−２とのユーザが同一人であれば、「伝達される」とは自身の頭に記憶しておくこと等を意味する。ユーザ端末１−１とユーザ端末１−２とのユーザが異人である場合、「伝達される」とは口頭等により伝達されることを意味する。

ステップＳ３１において、ユーザ端末１−２の第２識別子入力受付部１３１は、第２識別子の入力を受付ける。
ステップＳ３２において、ユーザ端末１−２の通知制御実行部１３２は、ステップＳ３１で受付けられた第２識別子をサーバ２に通知する。

ステップＳ２５において、サーバ２の状態再現部１０６は、ステップＳ３２で通知された第２識別子を認識する。
ステップＳ２６において、状態再現部１０６は、ステップＳ２５で認識した第２識別子に対応する第１識別子を認識する。
ステップＳ２７において、状態再現部１０６は、ステップＳ２６で認識された第１識別子に対応する特定の状態をユーザ端末１−２で再現する制御を実行する。
即ち、ステップＳ３３において、ユーザ端末１−２の閲覧制御実行部１３３は、ステップＳ２７での制御を受けて、特定の状態を、ユーザ端末１−２のユーザに閲覧させる制御を実行する。

なお、ステップＳ４において、ユーザ端末１−１の状態指定解除部１２１が、特定の状態の解除を行った場合、ステップＳ２８において、サーバ２の対応付け管理部１０４は、第１識別子と第２識別子との対応付けを破棄する。

次に、本実施形態のＳＮＳ等で１つのＷｅｂページ内に複数のデッキの情報（即ち複数の特定の状態）が表示される場合の実装例について説明する。

例えば、Ｗｅｂページ内に表示されるオンライン・フォームや、Ｗｅｂ掲示板、ＳＮＳ等では、１つのＵＲＬで識別されるＷｅｂページ内に複数のデッキの情報を含めて掲載することができる。
１つのＷｅｂページ内に複数のデッキの情報が含まれている場合、当該ＷｅｂページのＵＲＬからだけでは複数のうちのどのデッキの情報が指定（表示）されているのかを特定することが困難である。そこで、例えば複数のデッキの情報のそれぞれの表示に紐づけられたＪａｖａＳｃｒｉｐｔ（登録商標）コードによって、ユーザが複数のデッキの情報のうちのどのデッキの情報を指定（表示）しているのかを特定し、この特定したデッキの情報によって生成されるコードを第１識別としてサーバに送信することによって第２識別子との対応付けをし、特定したデッキの情報と第２識別子とを対応付けて表示するという手法が提案される。

図１２は、本実施形態におけるフォーラム、掲示板、ＳＮＳに複数のデッキの情報Ｐが表示される場合の実装例を示す図である。
図１２（Ａ）は、フォーラム、掲示板、ＳＮＳにおいて表示対象となる複数のデッキの情報Ｐの一例を示す図である。
図１２（Ｂ）は、ユーザ端末１の表示部２７に表示されるデッキの情報Ｐの一部を示す図である。
図１２のデッキの情報Ｐは、所定の１つのデッキ（ゲームの特定の状態）と当該デッキに対応する第１識別子（第１識別子を含むＵＲＬ）とを含む。本実施形態では、ユーザ端末１の表示部２７の表示領域Ｐ１乃至Ｐ４の領域の夫々に、図１２（Ａ）の複数のデッキの情報Ｐのうち、選択された４つのデッキの情報Ｐが表示される。
即ち、図１２（Ａ）のように、複数のデッキの情報Ｐは、縦方向に並んで配置されており、この中で４つのデッキの情報Ｐが選択されて、ユーザ端末１の表示部２７の表示領域Ｐ１乃至Ｐ４の領域の夫々に表示される。
例えば、図１２（Ａ）の範囲ＲＧ１が選択されている場合には、当該範囲ＲＧ１に含まれる４つのデッキの情報Ｐが、ユーザ端末１の表示部２７の表示領域Ｐ１乃至Ｐ４の夫々に表示される。
ここで、ユーザが図１２（Ａ）の範囲ＲＧ２を選択したい場合には、ユーザ端末１の表示部２７（タッチパネル）に対して、スクロールの操作をすればよい。
スクロールされて、図１２（Ａ）の範囲ＲＧ２が選択されると、当該範囲ＲＧ２に含まれる４つのデッキの情報Ｐが、ユーザ端末１の表示部２７の表示領域Ｐ１乃至Ｐ４の夫々に表示される。
つまり、スクロール操作により、ユーザ端末１の表示部２７の表示領域Ｐ１乃至Ｐ４の領域の夫々に表示されるデッキの情報Ｐも変化する。

以下実装例について説明する。
図１２（Ａ）に示すように、デッキの情報Ｐを共有することができるオンライン・フォームや、掲示板、ＳＮＳでは、ユーザ同士のデッキの情報Ｐが、１ページ内に縦に長く配置される。このようなフォーラムでは、１つのＵＲＬで識別されるページ内に大量のデッキの情報Ｐが掲載されることになるため、従来の短縮ＵＲＬなどの方式を用いることはできない。
本実施形態では、ユーザが当該情報を閲覧しているかどうか（ゲームの特定の状態を指示しているかどうか）に応じて第２識別子の有効期限を管理するため、例えば１つのＵＲＬで特定される１つのＷｅｂページ内に複数のデッキの情報Ｐが掲載される場合にも適用することができる。

具体的には、図５に示すユーザ端末１−１にインストールされるＷｅｂブラウザの機能を利用することで、ユーザ端末１−１側で現在表示されている範囲（図１２の例では表示の範囲ＲＧ１、ＲＧ２）内にあるＨＴＭＬ要素を抽出することができる。
このとき、ユーザ端末１−１はサーバ２へアクセスし、表示制御部１２３によって表示されているＨＴＭＬ要素内に含まれるデッキの情報Ｐを受付部１０１へ送信する。ここで、デッキの情報Ｐとは第１識別子に相当する情報のことであり、本実施形態においては第１識別子をＨＴＭＬ要素に適用できる形式（ＨＴＭＬ内に埋め込める形式）に変換した情報のことである。第１識別子たるデッキの情報Ｐは、図示しない第１識別子特定部により特定された情報であるが、本実施形態においては、複数の第１識別子（デッキの情報Ｐ）がＷｅｂページのＨＴＭＬ要素内に含められている。
サーバ２がアクセスを受付けると、第２識別子生成部１０３は第２識別子を生成し、対応付け管理部１０４は第１識別子と第２識別子との対応付けを行う。
そして、ユーザ端末１−１はデッキの情報Ｐの第２識別子をサーバ２から取得し、画面上に表示する。

また、Ｗｅｂブラウザは、ユーザが画面をスクロールさせた量を、縦方向のスクロール量（ウィンドウの左上とページの上部の距離）であるｓｃｒｏｌｌＴｏｐ、および、右方向のスクロール量（ウィンドウの左上とページの左端の距離）であるｓｃｒｏｌｌＬｅｆｔとして取得する機能を有する。
この機能を利用することで、図５に示す状態監視部１０２が、この値の変化を定期的に確認することにより、図１２（Ａ）のうちどの範囲が表示されているのか（例えば範囲ＲＧ１なのか範囲ＲＧ２なのか）を検出することができる。状態監視部１０２が、表示範囲が変更されたことを検出した時、当該表示範囲内のデッキの情報Ｐが画面内に表示されているかどうかを判定し、表示範囲内に含まれているデッキの情報Ｐ（あるいはデッキの情報Ｐから生成された第１識別子）をサーバ２へ送信し、当該デッキの情報Ｐに対応する第２識別子をサーバ２から取得し、当該デッキの情報Ｐに関連付けて表示することができる。
ここで、Ｗｅｂブラウザは、例えばＪａｖａＳｃｒｉｐｔ（登録商標）によって定義される図示しない表示情報抽出部としての機能を有している。表示情報抽出部は、上述したように、ユーザ端末１−１にて表示される内容を示すＨＴＭＬ要素から所定の表示範囲内にあるデッキの情報Ｐを抽出する手段であるが、このときの表示範囲（すなわち抽出範囲）の大きさ（あるいは広さ）は特に限定的ではなく、適宜設計し得る。表示範囲の大きさは、図１２における範囲ＲＧ１のようにユーザ端末１−１の表示画面にあわせた大きさとして設計することが好適であるが、本発明の実施においてはこれに拘らない。また、例えば、あるＵＲＬによって特定されるＷｅｂページ全体を表示範囲とみなして、表示情報抽出部はこのＷｅｂページ内に含まれる全てのＨＴＭＬ要素を抽出範囲としてデッキの情報Ｐを抽出してもよい。
即ち、例えば、図１２（Ａ）の表示範囲に含まれる複数のデッキの情報Ｐが表示情報抽出部により抽出された場合には、サーバ２は、夫々のデッキの情報Ｐに対応した複数の第１識別子を取得し、取得した第１識別子の夫々を第２識別子と対応付ける。そして、夫々のデッキの情報Ｐに対応させた第２識別子をユーザ端末１−１の表示部２７に表示させる。
また、例えば、表示範囲から複数のデッキの情報Ｐが表示情報抽出部により抽出された場合であっても、サーバ２は、選択範囲内における中央に最も近い位置のデッキの情報Ｐに対応した第２識別子のみを、ユーザ端末１−１の表示部２７に表示させることとすることもできる。
換言すると、表示範囲の変更の検出後、当該選択範囲内にあるＨＴＭＬ要素内からデッキの情報Ｐが表示情報抽出部により抽出されることになるため、当該デッキの情報Ｐにあたるゲームの特定の状態が指定され、当該特定の状態に対応する第１の識別子を用いたアクセスがなされたことになる。

なお、ユーザ端末１−２におけるゲームの特定の状態の再現の説明については、上述した説明と同様であるので割愛する。

更に、サーバ２は、表示範囲から外れたデッキの情報Ｐに対応した第２識別子は無効化してもよい。
即ち、図５に示す状態監視部１０２は、表示範囲が変更されたことを検出したとき、対応付け管理部１０４および対応付け管理ＤＢ１１１と協動して、表示範囲から外れたデッキの情報Ｐに対応する第１識別子と当該第１識別子に対応付けられた第２識別子との対応付けを解除し、対応付け管理ＤＢ１１１から情報を破棄して管理を完了する。ただし、当該対応付けの放棄は、表示範囲から外れた時に行われても良いし、表示範囲から外れてから所定期間の経過後に行われてもよい。

以上、本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

例えば、上述の実施形態は、カードゲームのデータの共有を対象にするものである。
しかしながら、特にこれに限定されず、デバイス間のデータの共有一般に適用することができる。即ち、ゲームに限定されず、ユーザ間、デバイス間のデータの共有に幅広く適用することができる。

また例えば、上述の実施形態では、説明の便宜上、第１識別子はＵＲＬに含まれるものを一例として用いたが、特にこれに限定されない。
即ち、上述したように、第１識別子は、データの膨大な特定の状態を識別できる永続的にユニークな識別子であれば足りる。従って、例えば、一次元コード、二次元コード等の様々な識別子に適用することができる。

また例えば、上述の実施形態では、説明の便宜上、第２識別子は４桁の数字又は大文字・小文字のアルファベットを一例として用いたが、特にこれに限定されない。
即ち、上述したように、第２識別子は、ユーザがデータを閲覧した時に、当該ユーザの閲覧行為を同時アクセスセッションの中から識別できる一時的な一意性を有する識別子であれば足りる。従って、例えば、４桁である必要もないし、記号と組み合わせることにより、印刷物等を用いた永続的な短縮識別子であってもよい。具体的には、“＋５ｔ７”のように、プレス記号から始まる場合は、無効化されない識別子としてもよい。

また例えば、上述の実施形態では、説明の便宜上、ゲームの処理を用いて説明したが、特にこれに限定されず、再現性があり且つユーザによって任意に指定される特定の状態を取り扱う処理であれば足りる。

また例えば、図５の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理装置に備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図５の例に限定されない。また、機能ブロックの存在場所も、図５に特に限定されず、任意でよい。例えば、サーバ２の機能ブロックをユーザ端末１等に移譲させてもよいし、逆にユーザ端末１の機能ブロックをサーバ２等に移譲させてもよい。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

このようなプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

換言すると、本発明が適用される情報処理プログラムは、上述の図５の実施形態としての情報処理システムを含め、次のような構成を有する各種各様の実施態様を取ることができる。
即ち、本発明が適用される情報処理プログラムは、
再現性があり且つユーザによって任意に指定される特定の状態を当該指定に基づき表示可能な複数の端末との間で通信をするサーバに、
前記複数の端末のうち第１端末から、前記特定の状態と一意に対応付けられる第１識別子を用いたアクセスを受付ける受付ステップ（例えば図５の受付部１０１が実行するステップ）と、
前記第１識別子を用いたアクセスをしてきた前記第１端末において、前記特定の状態の指定が継続しているか否かを監視する監視ステップ（例えば図５の状態監視部１０２が実行するステップ）と、
前記第１端末による前記第１識別子を用いたアクセスが受け付けられたとき、第２識別子を生成する生成ステップ（例えば図５の第２識別子生成部１０３が実行するステップ）と、
生成された前記第２識別子を、前記第１端末に表示させる制御を実行する表示制御ステップ（例えば図５の表示制御部１０５が実行するステップ）と、
当該第１端末において前記特定の状態の指定が継続している期間又は当該期間が終了してから所定期間では、前記特定の状態に対応する前記第１識別子と、生成された前記第２識別子との対応付けを管理し、その後、当該第１端末において前記特定の状態の指定の終了又は当該終了から所定期間の経過が監視されたとき、当該第１識別子と当該第２識別子との対応付けを破棄する管理ステップ（例えば図５の対応付け管理部１０４が実行するステップ）と、
前記管理ステップにおいて前記管理が継続されている間に、前記複数の端末のうち第２端末から前記第２識別子が通知された場合、当該第２識別子に対応付けられた前記第１識別子に対応する前記特定の状態を、当該第２端末で再現可能にするための制御を実行する状態再現ステップ（例えば図５の状態再現部１０６が実行するステップ）と、
を含む制御処理を実行させるプログラム。

このようにして、特定の状態を示すデータを即座にユーザ間、及び、デバイス間で即座に共有する技術が確立される。
即ち、データを様々なメディア上で流通させる際に用いる第１識別子と、データをアプリケーションに読み込ませるときに用いる第２識別子を独立させ、この２つの識別子の対応関係を動的に管理する２段階識別子管理方法を採用することにより、情報の表現能力と入力の容易性を併せ持つデータ流通・入力を実現する。
ここで、データ内の特定の状態の数よりも、データを閲覧しているユーザの方が圧倒的に少数である。
従って、データ内の特定の状態を識別する第１識別子と、特定の状態を閲覧する行為を識別する第２識別子とを動的に関連付けることにより、１人のユーザが、デバイス間のやり取りのために何千回も登録処理を行ったとしても、識別子の数が不足しないというスケーラビリティを実現する。
これにより、本発明は、ログイン等の処理を行わずに、デバイス上に登録されているデータを異なるデバイスで編集し、それを即座にデバイスへ反映するという、一時的なデバイス間の共有処理を実現することができる。

また、前記受付ステップは、前記第１識別子を用いたアクセスとして、当該第１識別子を要素に含むＵＲＬによるアクセスを受付けるステップを含むことができる。
これにより、雑誌等の紙媒体や、ＳＮＳ等のネットワークサービスを経由して、既存のＵＲＬを流通させる仕組みをそのまま利用することができる。

また、前記生成ステップは、前記第２識別子として、前記第１識別子より情報量が少ない識別子を生成するステップを含むことができる。
これにより、生成される第２識別子は短くシンプルとなるため、ユーザ間での口頭での伝達が可能となり、不特定多数のユーザへのデータ共有や、その場ですぐに見ず知らずのユーザへデータを共有することができる。
また、データ内の特定の状態が膨大な数となった場合においても、ユーザが入力する識別子の数が増加せず、かつ、異なるユーザや異なるデバイスへデータを転送するためのデータ登録処理の回数が膨大な数となった場合においても、ユーザが入力する識別子の数が増加しない。

１・・・ユーザ端末、２・・・サーバ、２１・・・ＣＰＵ、５１・・・ＣＰＵ、５８・・・記憶部、１０１・・・受付部、１０２・・・状態監視部、１０３・・・第２識別子生成部、１０４・・・対応付け管理部、１０５・・・表示制御部、１０６・・・状態再現部、１１１・・・対応付け管理ＤＢ、１２１・・・状態指定解除部、１２２・・・アクセス部、１２３・・・表示制御部、１３１・・・第２識別子入力受付部、１３２・・・通知制御実行部、１３３・・・閲覧制御実行部

Claims (8)

1. 再現性があり且つユーザによって任意に指定される特定の状態を当該指定に基づき表示可能な複数の端末との間で通信をするサーバに、
   前記複数の端末のうち第１端末から、前記特定の状態と一意に対応付けられる第１識別子を用いたアクセスを受付ける受付ステップと、
   前記第１端末による前記第１識別子を用いたアクセスが受け付けられたとき、第２識別子を生成する生成ステップと、
   生成された前記第２識別子を、前記第１端末に表示させる制御を実行する表示制御ステップと、
   前記特定の状態に対応する前記第１識別子と、生成された前記第２識別子との対応付けが維持されていることを条件とし、前記複数の端末のうち第２端末から前記第２識別子が通知された場合、当該第２識別子に対応付けられた前記第１識別子に対応する前記特定の状態を、当該第２端末で再現可能にするための制御を実行する状態再現ステップと、
   を含む制御処理を実行させるプログラム。
2. 前記特定の状態に対応する前記第１識別子と、生成された前記第２識別子との前記対応付けを管理し、その後、所定期間が経過すると、当該第１識別子と当該第２識別子との前記対応付けを破棄する管理ステップ、
   を更に含む制御処理を実行させる、
   請求項１に記載のプログラム。
3. 前記第１端末による前記第１識別子を用いたアクセスが終了してから所定期間では、前記特定の状態に対応する前記第１識別子と、生成された前記第２識別子との前記対応付けを管理し、その後、前記所定期間の経過が監視されたとき、当該第１識別子と当該第２識別子との前記対応付けを破棄する管理ステップ、
   を更に含む制御処理を実行させる、
   請求項１に記載のプログラム。
4. 前記受付ステップは、前記第１識別子を用いたアクセスとして、当該第１識別子を要素に含むＵＲＬによるアクセスを受付けるステップを含む、
   請求項１乃至３のうち何れか１項に記載のプラグラム。
5. 前記生成ステップは、前記第２識別子として、前記第１識別子より情報量が少ない識別子を生成するステップを含む、
   請求項１乃至４のうち何れか１項に記載のプログラム。
6. 再現性があり且つユーザによって任意に指定される特定の状態を当該指定に基づき表示可能な複数の端末との間で通信をするサーバとして機能する情報処理装置において、
   前記複数の端末のうち第１端末から、前記特定の状態と一意に対応付けられる第１識別子を用いたアクセスを受付ける受付手段と、
   前記第１端末による前記第１識別子を用いたアクセスが受け付けられたとき、第２識別子を生成する生成手段と、
   生成された前記第２識別子を、前記第１端末に表示させる制御を実行する表示制御手段と、
   前記特定の状態に対応する前記第１識別子と、生成された前記第２識別子との対応付けが維持されていることを条件とし、前記複数の端末のうち第２端末から前記第２識別子が通知された場合、当該第２識別子に対応付けられた前記第１識別子に対応する前記特定の状態を、当該第２端末で再現可能にするための制御を実行する状態再現手段と、
   を備える情報処理装置。
7. 再現性があり且つユーザによって任意に指定される特定の状態を当該指定に基づき表示可能な複数の端末との間で通信をするサーバが実行する情報処理方法において、
   前記複数の端末のうち第１端末から、前記特定の状態と一意に対応付けられる第１識別子を用いたアクセスを受付ける受付ステップと、
   前記第１端末による前記第１識別子を用いたアクセスが受け付けられたとき、第２識別子を生成する生成ステップと、
   生成された前記第２識別子を、前記第１端末に表示させる制御を実行する表示制御ステップと、
   前記特定の状態に対応する前記第１識別子と、生成された前記第２識別子との対応付けが維持されていることを条件とし、前記複数の端末のうち第２端末から前記第２識別子が通知された場合、当該第２識別子に対応付けられた前記第１識別子に対応する前記特定の状態を、当該第２端末で再現可能にするための制御を実行する状態再現ステップと、
   を含む情報処理方法。
8. 再現性があり且つユーザによって任意に指定される特定の状態を当該指定に基づき表示可能な複数の端末と、サーバとを含む情報処理システムにおいて、
   前記サーバは、
   前記複数の端末のうち第１端末から、前記特定の状態と一意に対応付けられる第１識別子を用いたアクセスを受付ける受付手段と、
   前記第１端末による前記第１識別子を用いたアクセスが受け付けられたとき、第２識別子を生成する生成手段と、
   生成された前記第２識別子を、前記第１端末に表示させる制御を実行する表示制御手段と、
   前記特定の状態に対応する前記第１識別子と、生成された前記第２識別子との対応付けが維持されていることを条件とし、前記複数の端末のうち第２端末から前記第２識別子が通知された場合、当該第２識別子に対応付けられた前記第１識別子に対応する前記特定の状態を、当該第２端末で再現可能にするための制御を実行する状態再現手段と、
   を備え、
   前記複数の端末のうち前記第１端末は、
   前記特定の状態と一意に対応付けられる前記第１識別子を用いたアクセスを行うアクセス手段と、
   前記サーバにおいて、前記特定の状態の指定が継続している期間又は当該期間が終了してから所定期間のみ有効な前記第２識別子が、前記第１識別子と対応付けられて生成された場合、前記サーバの前記表示制御手段による前記制御を受けて、当該第２識別子を表示する表示手段と、
   を備え、
   前記複数の端末のうちの前記第２端末は、
   前記サーバにより生成されて前記第１端末に表示された前記第２識別子の入力を受付けて、前記サーバに通知する制御を実行する第１制御手段と、
   前記サーバにおいて、前記第１制御手段の制御により前記第２識別子が通知された場合、当該サーバの前記状態再現手段による前記制御を受けて、前記特定の状態を再現して前記第２端末のユーザに閲覧させる制御を実行する第２制御手段と、
   を備える情報処理システム。

Images