JP2013225290A - 管理サーバ、その制御方法、並びに管理サーバ及び端末装置のプログラム - Google Patents
管理サーバ、その制御方法、並びに管理サーバ及び端末装置のプログラム Download PDFInfo
- Publication number
- JP2013225290A JP2013225290A JP2013007054A JP2013007054A JP2013225290A JP 2013225290 A JP2013225290 A JP 2013225290A JP 2013007054 A JP2013007054 A JP 2013007054A JP 2013007054 A JP2013007054 A JP 2013007054A JP 2013225290 A JP2013225290 A JP 2013225290A
- Authority
- JP
- Japan
- Prior art keywords
- user
- application
- information
- management server
- users
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims description 173
- 230000008859 change Effects 0.000 claims description 31
- 230000004044 response Effects 0.000 claims description 25
- 238000001514 detection method Methods 0.000 claims description 4
- 238000007726 management method Methods 0.000 description 197
- 230000008569 process Effects 0.000 description 158
- 230000004048 modification Effects 0.000 description 62
- 238000012986 modification Methods 0.000 description 62
- 101100368978 Arabidopsis thaliana TBL14 gene Proteins 0.000 description 35
- 101100541005 Oryza sativa subsp. japonica XOAT7 gene Proteins 0.000 description 35
- 230000006870 function Effects 0.000 description 34
- 101100368976 Arabidopsis thaliana TBL12 gene Proteins 0.000 description 23
- 101100540999 Oryza sativa subsp. japonica XOAT1 gene Proteins 0.000 description 23
- 239000000284 extract Substances 0.000 description 20
- 238000010586 diagram Methods 0.000 description 19
- 238000004891 communication Methods 0.000 description 16
- 101100368979 Arabidopsis thaliana TBL15 gene Proteins 0.000 description 14
- 101100541004 Oryza sativa subsp. japonica XOAT6 gene Proteins 0.000 description 14
- 101100368980 Arabidopsis thaliana TBL16 gene Proteins 0.000 description 4
- 230000008901 benefit Effects 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 238000013500 data storage Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000000605 extraction Methods 0.000 description 3
- 230000008685 targeting Effects 0.000 description 3
- 230000007704 transition Effects 0.000 description 3
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 230000006855 networking Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000007480 spreading Effects 0.000 description 1
Images
Classifications
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/70—Game security or game management aspects
- A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
- A63F13/795—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for finding other players; for building a team; for providing a buddy list
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/52—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail for supporting social networking services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
- H04L67/306—User profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/535—Tracking the activity of the user
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
- A63F13/85—Providing additional services to players
- A63F13/87—Communicating with other players during game play, e.g. by e-mail or chat
-
- A—HUMAN NECESSITIES
- A63—SPORTS; GAMES; AMUSEMENTS
- A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
- A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
- A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
- A63F2300/55—Details of game data or player data management
- A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
- A63F2300/556—Player lists, e.g. online players, buddy list, black list
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- General Business, Economics & Management (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Transfer Between Computers (AREA)
Abstract
【解決手段】管理サーバ3Aは、アプリケーションの種類を示す種別情報を受付ける受付部11と、種別情報が示すアプリケーションを利用していることを第1条件、アプリケーションについて要求利用者と仲間関係が構築されていないことを第2条件、アプリケーションにおいて仲間上限数に達していないことを第3条件としたとき、要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち各条件の全てを充足する候補利用者の一部又は全部を特定する特定部12と、特定部12で特定した一部又は全部の候補利用者を選択できるように要求利用者の端末装置に表示させる表示制御部14とを備える。
【選択図】図1
Description
また、従来のゲームシステムでは、仲間候補の提示について要求があった利用者に対して、仲間相手の候補となる利用者を抽出し、これを提示することが行われていた(非特許文献1)。
本発明は、この点に鑑みてなされたものであり、あるアプリケーションで、他のアプリケーションで仲間関係となった利用者と仲間関係を容易に構築可能とすることを解決課題とする。
さらに、前記特定部は、前記第1の仲間関係テーブルを参照して、前記要求利用者が利用したことのある利用済みアプリケーションに対応する種別情報と関連付けて備えられている前記利用者情報の組のうち、仲間申請を行った利用者の利用者情報が前記要求利用者の利用情報と一致する仲間申請を受諾した利用者の利用者情報を抽出するとともに、仲間申請を受諾した利用者の利用者情報が前記要求利用者の利用情報と一致する仲間申請を行った利用者の利用者情報を抽出し、抽出した利用者情報の利用者を、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者とすることが好ましい。
この発明において、仲間申請が可能な人数は、利用済みアプリケーションごとに特定し、利用済みアプリケーションごとに要求利用者の端末装置に表示させてもよいし、複数の利用済みアプリケーションの合計の仲間申請が可能な人数を特定し、これを要求利用者の端末装置に表示させてもよい。
<1.アプリケーションシステムの構成>
図1は、本発明の実施形態に係るアプリケーションシステム100のブロック図である。このアプリケーションシステム100は、インターネットなどの通信網1、利用者の端末装置2、管理サーバ3A、アプリケーションサーバ3B、3C、3D…を備える。アプリケーションサーバ3B、3C、3D…は、利用者同士のコミュニケーションを可能にするSNSサイトを各利用者に対して提供するとともに、各種のサービスを利用者に提供する。利用者同士のコミュニケーションとは、利用者の間でメッセージの授受を行うことをいう。メッセージの授受は、例えば、掲示板、メール、チャット等を用いて行われる。この例ではアプリケーションサーバ3B、3C、3D…が提供するサービスはゲームb、ゲームc、ゲームd…である。各アプリケーションサーバ3B、3C、3D…の利用者は、同じゲーム(アプリケーション)の利用者と仲間関係を構築し、仲間同士で挨拶やコメントなどのコミュニケーションを行うことによってゲーム上で交換価値があるポイントを獲得できる。また、ゲーム上での戦闘では、仲間の応援が得られるなど、仲間の数が多いほどゲームが有利に進行する。
また、ログイン識別情報UserIDと参照識別情報RefIDの対応づけをID管理テーブルTBL16で管理することで、例えばログイン識別情報UserIDが第三者に盗まれた場合には、新たなログイン識別情報UserIDを発行し、これを参照識別情報RefIDと紐づければよい。即ち、ID管理テーブルを更新するだけで、他のテーブルには影響を与えることがない。
また、仲間関係が構築された後で仲間関係が解除された場合には、そのレコードを削除する。なお、レコードを削除せずに、レコードの有効/無効を示す項目を新たに追加し、仲間関係が解除されたレコードを無効とするようにしてもよい。仲間関係を解除した相手と仲間関係を再び構築する場合には新たなレコードを作成すればよい。
受付部11は、仲間の候補となる候補利用者を提示することを要求する要求利用者が端末装置2を操作して指定したアプリケーションの種類を示す種別情報AppIDを受け付ける。ここで、種別情報AppIDは端末装置2から提供されてもよいし、あるいは、アプリケーションサーバ3B、3C、3D…から提供されてもよい。
仲間申請において、特定部12は、受付部11で受付けた種別情報AppIDが示すアプリケーションを利用していることを第1条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第2条件、当該アプリケーションにおいて仲間上限数に達していないことを第3条件としたとき、要求利用者が利用したことのある利用済みアプリケーションのうち仲間に誘おうとするアプリケーション以外において仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定する。即ち、仲間申請では、仲間に誘おうとするゲーム以外で要求利用者と仲間関係が構築されている他の利用者であることを前提とし、仲間に誘おうとするゲームを対象として仲間申請を行うのであるから、当該ゲームを既に利用していることが必要である(第1条件)。また。これらから仲間になるように誘うのであるから、まだ仲間関係にないのは当然である(第2条件)。さらに、仲間上限数を考慮する必要がある(第3条件)。
一方、招待において、特定部12は、受付部11で受付けた種別情報AppIDが示すアプリケーションを利用していないことを条件としたとき、前記条件を充足する候補利用者の一部又は全部を特定する。
指示部13は、受付部11で受付けた種別情報AppIDが示すアプリケーションに対応したアプリケーションサーバ3B、3C、3D、…に対して、要求利用者が候補利用者の中から選択した利用者に対して仲間申請を要求する指示を行う。これにより、仲間申請された利用者はアプリケーションサーバ3B、3C、3D、…にアクセスした際に、仲間申請がなされていることに気がつく。すなわち、仲間申請された利用者は、自身のマイページ等で仲間申請が来ていることが知らされる。
情報取得部15は、後述する問合処理において、受付部11で受付けた所定の仲間に人気のある所定のアプリケーションに関する利用情報を取得する。詳しくは後述する。
通知部16は、端末装置2に表示された候補利用者の中から選択した候補利用者に対して、招待申請を通知する。詳しくは後述する。
アプリケーションシステム100では、ある利用者がプレイしているゲームに当該ゲームをプレイしていない他の利用者を招待したり、あるいは当該ゲームをプレイしている他の利用者(他のゲームでの仲間を含む)に対して仲間申請を行うことができる。また、利用者は自身がプレイしている複数のゲームでの仲間に人気が高いゲームや各ゲームをプレイしている仲間数などを問い合わせることができる。以下、招待と仲間申請に共通の共通処理、仲間申請に係る仲間申請処理、招待に係る招待処理、及び各種の問い合わせに関する問合処理について説明する。
図8に共通処理に関するアプリケーションシステムの動作シーケンスを示す。端末装置2の利用者が、ウェブブラウザ上で動作したり、端末装置2にインストールされて動作するアプリケーションを起動して、アプリケーションのログインページにアクセスすると、端末装置2のディスプレイ25には、ログイン画面が表示される。このログイン画面には、ログイン識別情報UserIDとパスワードPSWとを入力する入力ボックスが表示される。利用者が、入力ボックスに入力して送信ボタンを押すと、端末装置2のCPU20は、入力したログイン識別情報UserID及びパスワードを含むログイン要求を管理サーバ3Aに送信する。
管理サーバ3AのCPU30はマイページ閲覧要求を受信すると、ID管理テーブルTBL16を参照して、ログイン識別情報UserIDに対応した参照識別情報RefIDを取得し、さらに利用者情報テーブルTBL11を参照して、参照識別情報RefID及びゲームbの種別情報AppIDに対応する利用者識別情報UIDを取得する(S3)。
なお、ステップS3で取得した利用者識別情報UIDを端末装置2へ通知し、それ以降、管理サーバ3Aを介さずに、端末装置2とアプリケーションサーバ3Bとの間で通信を行わせるようにしてもよい。
まず、CPU30は、受信したアクセス要求に含まれる利用者識別情報UIDaxと、他の利用者を誘うゲームの種別情報AppIDxとを取得する(S100)。ここで、取得した種別情報AppIDxは「00000001」であり「ゲームb」を示しており、仲間申請や招待の対象となるゲームである。また、取得した利用者識別情報UIDaxは「XCV56714」とする。
また、CPU30は、上述した第1の条件を充足する他の利用者を、S109の抽出結果を用いて特定してもよい。また、CPU30が、関係テーブルTBL13を参照して、利用者Aが仲間に誘おうとするゲームにおいて利用者Aと仲間関係が構築されている他の利用者の利用者識別情報UID*xをS105の抽出結果を用いて特定してもよい。そして、CPU30は、第1条件を充足する他の利用者から、S105の抽出結果で特定される他の利用者を除いて、まだ仲間になっていない非仲間の利用者の利用者識別情報UID*xを抽出する。
この後、CPU30は、処理を図10に示すS107に戻す。そして、S102で抽出した全ての種別情報AppIDxについてS107からS119の処理を終了すると、仲間の人数が多い順にゲームを配置した仲間探しページを生成し(S120)、処理を終了する。
なお、S104の処理で仲間申請が不能である旨のフラグがセットされている場合には、S110の処理で集計したプレイしている仲間数の替わりに、その表示を非表示にしたり、「申請可能人数に達しているため申請できません」といった表示をする。
なお、この例では、CPU30は、利用済みアプリケーションごとに、利用者Aが招待可能な仲間の人数と利用者Aが仲間申請能な仲間の人数とを端末装置2に合わせて表示させたが、どちらか一方のみを表示させるように一部の機能だけを具備させてもよい。さらに、人数を表示させるのではなく、仲間申請または招待の候補となる利用者のユーザ名を表示されるようにしてもよいし、人数と候補となる利用者のユーザ名の両方を表示させるようにしてもよい。
また、この例では、CPU30は、仲間申請が可能な人数について、利用済みアプリケーションごとに特定し、利用済みアプリケーションごとに端末装置2に表示させたが、CPU30は、複数の利用済みアプリケーションの合計の仲間申請が可能な人数を特定し、これを要求利用者の端末装置2に表示させてもよい。また、招待可能な人数も仲間申請と同様に複数の利用済みアプリケーションの合計の人数を特定し、これを要求利用者の端末装置2に表示させてもよい。
また、本実施形態によれば、利用済みゲームを選択できる画面を要求利用者の端末装置2に表示させ、選択した利用済みゲームについて仲間関係にあることが候補利用者の要件となるので、要求利用者は、招待しようとするゲームと類似する利用済みゲームを選択するなど、好みに合わせた選択が可能となる。
図14に仲間申請処理に関するアプリケーションシステムの動作シーケンスを示す。まず、端末装置2において利用者Aが仲間申請において仲間を選択すると(S140)、端末装置2のCPU20は、仲間申請要求を管理サーバ3Aに送信する。仲間申請要求には、申請元利用者識別情報UID_Fromと申請先利用者識別情報UID_Toが含まれている。
また、管理サーバ3Aは、仲間申請応答を端末装置2に返信する。端末装置2のCPU20は、仲間申請応答を受信すると、マイページなどに仲間申請中であることを表示する。
第1条件:利用者Aが利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち、利用者Aが利用しているアプリケーションを利用している利用者。
第2条件:当該アプリケーションについて利用者Aと仲間関係が構築されていない利用者。
第3条件:当該アプリケーションにおいて仲間上限数に達していない利用者。
これによって、異なるアプリケーションで形成された信頼関係を新しいアプリケーションでも活用できるようになる。つまり、あるゲームを利用者がプレイしている場合に、全く見知らぬ相手に仲間申請するのではなく、他のゲームで仲間になった気心の知れた利用者に仲間申請をすることができるので、新たなゲームを始める場合に、仲間関係を構築し易いといった利点がある。
また、本実施形態によれば、管理サーバ3Aの関係テーブルTBL13に、仲間関係となる利用者情報の組を記憶するから、各種のアプリケーションで構築される仲間関係を一元的に管理することができる。さらに、種別情報と利用者情報とを対応づけて記憶する利用者情報テーブルTBL11を備えるので、この利用者情報テーブルTBL11を参照することによって第1条件を充足することができる。
また、本実施形態によれば、申請側と承諾側との組を関係テーブルTBL13に記憶することにより、一つの利用者情報をキーとして当該利用者情報と仲間関係にある全ての利用者情報を記憶する必要はないので、データの記憶容量を削減することが可能となる。
さらに、本実施形態によれば、第1の仲間上限数テーブルTBL12を用いて、アプリケーションごとに定められる仲間上限数を管理サーバ3Aで一元的に管理するので、第3条件を充足させることが可能となる。
また、本実施形態によれば、利用済みアプリケーションを選択できるように利用者Aの端末装置2に表示させ、選択した利用済みアプリケーションについて仲間関係にあることが候補利用者の要件となるので、仲間申請を要求する利用者は、仲間関係を構築しようとするアプリケーションと類似する利用済みアプリケーションを選択することができたり、具体的にどのアプリケーションのどの仲間を誘いたいかがあらかじめ決まっている場合に探し易くなる。
さらに、本実施形態によれば、仲間申請が可能な人数を知ることができるので、仲間申請を要求する利用者に利便性が大幅に向上する。
図15に招待処理に関するアプリケーションシステムの動作シーケンスを示す。まず、端末装置2において利用者Aが招待において仲間を選択すると(S150)、端末装置2のCPU20は、招待要求を管理サーバ3Aに送信する。図16に招待用の詳細ページの一例を示す。この例では、図12に示す仲間探しページにおいて利用者Aがゲームbを選択したものとする。招待用の詳細ページには、領域142に、利用者Aがゲームbについて他のゲームで仲間の利用者を、あと何人、招待可能かが表示される。招待可能な人数は、図12に示す領域124に表示される人数と同じであり、上述したS112の処理で取得される。また、領域143〜145には、招待の候補となる利用者のユーザ名と、チェックボックス143b、144b、145bが表示される。チェックボックス143b、144b、145bにチェックを設定して、ボタン148をクリックすることにより、仲間の招待を行うことができる。なお、招待は、複数の相手に同時に行うことができる。
また、本実施形態によれば、招待申請が可能な人数を知ることができるので、要求利用者に利便性が大幅に向上する。
領域142に表示される招待可能な人数は、上述したS111及びS112の処理で取得される。まず、CPU30は、招待の対象となるゲームをプレイしていないことを条件として、この条件を満たす候補利用者を抽出する。つまり、CPU30は、利用者情報テーブルTBL11を参照して、招待の対象となるゲーム以外のあるゲームにおいて利用者Aと仲間関係が構築されている仲間の利用者識別情報UID*xの中で、招待するゲームをプレイしていない候補利用者の利用者識別情報UID*xを抽出する(S111)。具体的には、利用者情報テーブルTBL11を参照して、S109で抽出した仲間の利用者識別情報UID*xに対応する仲間の参照識別情報RefID*を取得し、さらに、当該仲間の利用者識別情報UID*xと、取得した参照識別情報RefID*と、当該参照識別情報RefID*に対応する一又は複数の種別情報AppIDxとの組を取得する。そして、取得した一又は複数の組の中から、招待するゲームの種別情報AppIDxを含まない組の候補利用者の利用者識別情報UID*xと参照識別情報RefID*、つまり、招待の対象となるゲームをプレイしていない候補利用者の利用者識別情報UID*xと参照識別情報RefID*とを抽出する。
次に、CPU30は、インバイトテーブルTBL14を参照して、利用者Aを示す参照識別情報RefIDaが招待元として、且つ候補利用者の利用者識別情報UID*xに対応する参照識別情報RefID*xが招待先としてインバイトテーブルTBL14に記録されている組以外の組を抽出し、集計する(S112)。即ち、インバイトテーブルTBL14に記録された招待中または招待済みの利用者を除外して、利用者Aが新たに招待可能な候補利用者とその人数とを特定する。
本実施形態においては、拒否と承認をまとめて第1状態としている。したがって、招待を拒否された場合だけでなく、招待が承認された場合にも候補利用者から除外される。招待を承認した利用者は、そもそも招待の対象となるゲームを既に利用しているから、招待する必要がない。このようなデータ構造を採用することにより、拒否した利用者と招待された利用者を同時に排除できるので処理負荷が軽減される。
このように本実施形態によれば、あるゲームを利用者がプレイしている場合に、全く見知らぬ相手を招待するのではなく、他のゲームで仲間になった気心の知れた利用者を招待することができるので、新たなゲームを他のゲームの仲間に広めることができ、さらに他のゲームの仲間が当該ゲームに参加した場合には、当該ゲームでも仲間関係を構築し易いといった利点がある。
また、特定部12としてのCPU30は、S112において、インバイトテーブルTBL14を参照して招待可能な候補利用者の利用者識別情報UID*xを含むレコードを抽出する際、状態情報Statが「1」であるレコードについては、抽出対象のレコードから除外する。つまり、特定部12は、状態情報Statが「1」の場合には招待が承認又は拒否されている場合なので、そのような相手には再度招待しないように制御している。したがって、本実施形態によれば、招待の状態を示す状態情報と利用者情報とを対応づけてインバイトテーブルTBL14で管理するので、インバイトテーブルTBL14を参照することによって、招待の状態を知ることができる。そして、状態情報が拒否を示す場合には、候補利用者から除かれるので、招待を拒否しているに拘わらず再度の招待があるといった迷惑行為を未然に防止することがきる。
また、本実施形態によれば、招待申請中の利用者も候補利用者から除かれるから、申請中に拘わらず、再度、招待を申請するといった無駄をなくし、管理サーバ3Aの処理負荷を軽減することができる。
問合処理は、利用者Aの仲間の利用者が利用しているアプリケーションに関する利用情報を管理サーバ3Aに問い合わせる処理である。利用情報には、仲間の中で人気のあるゲームのランキングやあるゲームを利用している仲間数、仲間申請できる人数、招待できる人数などが含まれる。
問合処理は、仲間に人気のゲームを知ることができるランキング処理と、あるゲームを特定して、特定したゲームを遊んでいる仲間の人数を問い合わせる仲間数処理を含む。
まず、ランキング処理について説明する。ランキング処理には、第1ランキング処理と第2ランキング処理とがある。第1ランキング処理は、特定のゲームで仲間関係にある利用者において人気のあるゲームの順位付けを行う処理である。一方、第2ランキング処理は、不特定のゲームで仲間関係にある利用者において人気のあるゲームの順位付けを行う処理である。
より具体的には、CPU30は、(Group= Friends)*{(UID_To=UIDax)+(UID_From=UIDax)}*(Stat=1)を充足するレコードを抽出し、それらに含まれる一又は複数の利用者識別情報UID*xを特定する。
次に、CPU30は、抽出した利用者識別情報UID*xの数を種別情報AppIDxごとに集計する(S202)。さらに、CPU30は、仲間の利用者識別情報UID*xの集計数に基づいて、種別情報AppIDxで特定されるゲームの人気順を特定する。さらに、CPU30は、アプリ情報テーブルTBL15を参照して、抽出した種別情報AppIDxに対応するゲーム名、説明情報、及びアイコン情報を取得する。この後、CPU30は、第1ランキングページを生成する。この際、CPU30は、遊んでいる仲間の多い順にゲームの説明などを配置して第1ランキングページを生成する。
端末装置2は、管理サーバ3Aから第1ランキングページを含むアクセス応答を受信すると、第1ランキングページをディスプレイ25に表示する(S162)。
即ち、CPU30は、S201において複数のゲームのうち、図9に表示されるゲームにおける利用者Aの利用者識別情報UIDaxを特定し、さらに、当該ゲームにおいて利用者Aと仲間関係が構築されている利用者を利用者識別情報UID*xで特定し、さらに、特定した利用者、即ち、仲間がプレイしている各ゲームのランキングと、各ゲームをプレイしている仲間数とを示す利用情報を取得する情報取得部15として機能する。
本実施形態によれば、情報取得部15は、仲間の間で人気アプリページへのアクセス要求要求に対応づけられたアプリケーションにおいて、要求利用者である利用者Aの仲間が利用しているアプリケーションに関する利用情報を取得する。そして、表示制御部14はこれを端末装置2に表示させるので、要求利用者は特定のアプリケーションを介した仲間に関して様々な情報を得ることが可能となる。
なお、ボタン113による人気アプリのランキングは、利用者の対象がある特定のゲームの仲間であることに対して、ボタン114による人気アプリのランキングは、利用者の対象が、当該利用者がプレイしている複数のゲームのいずれかで仲間であることである。仮に利用者が1つのゲームしかプレイしていない場合には、ボタン113による人気アプリのランキングの内容と、ボタン113による人気アプリのランキングの内容が同一になる。
より具体的には、(Group= Friends)*{(RefID_To=RefIDa)+(RefID_From=RefIDa)}*(Stat=1)を充足するレコードを抽出し、それらに含まれる一又は複数の種別情報AppIDxと利用者識別情報UID*xとの組みを特定する。
即ち、CPU30は、S172において複数のゲームのうち、利用者Aが利用したことがあるゲームの種別情報AppIDxを特定し、さらに、利用者と仲間関係が構築されている利用者を利用者識別情報UID*xで特定し、さらに特定した利用者、即ち、仲間がプレイしている各ゲームのランキングと、各ゲームをプレイしている仲間数とを示す利用情報を取得する情報取得部15として機能する。
本実施形態によれば、仲間内で利用されている人数の多い順にアプリケーション(ゲーム)が表示されるので、利用者は、アプリケーション(ゲーム)の人気ランキングを一見して知ることができる。
また、本実施形態によれば、情報取得部15は、要求利用者である利用者Aが利用済みのアプリケーションにおいて仲間関係が構築されている仲間について、当該仲間が利用しているアプリケーションに関する利用情報を取得する。そして、表示制御部14はこれを端末装置2に表示させる。したがって、要求利用者である利用者Aは、仲間が利用しているアプリケーションの関して様々な情報を得ることが可能となる。
より具体的には、(Group= Friends)*(AppID= AppIDx)*{(RefID_To=RefIDa)+(RefID_From=RefIDa)}を充足するレコードを抽出し、それらに含まれる一又は利用者識別情報UID*xを抽出する。
また、本実施形態によれば、アプリケーション(ゲーム)を利用している利用者数が端末装置2に表示されるので、相対的なランキングよりも詳細な情報を利用者は得るこができる。
本発明は上述した実施形態に限定されるものではなく、以下の変形が可能である。また、各変形例は適宜組み合わせることができる。
(1)上述した実施形態では、アプリケーションの一例としてゲームを取り上げて説明したが本発明はこれに限定されるものではない。招待や人気アプリのランキングについては、どのようなものであってもよい。例えば、占いや診断のアプリケーション、便利ツールのアプリケーション、写真画像処理のアプリケーションであってもよい。仲間申請については、仲間関係を構築して利用するチャットや掲示板のアプリケーションが好適である。
次に、CPU30は、抽出した利用者識別情報UID*xの数を種別情報AppIDxごとに集計する(S173)。さらに、CPU30は、仲間の利用者識別情報UID*xの集計数に基づいて、種別情報AppIDxで特定されるゲームの人気順を特定する(S174)。次に、CPU30は、アプリ情報テーブルTBL15を参照して、抽出した種別情報AppIDxに対応するゲーム名、説明情報、及びアイコン情報を取得する。この後、CPU30は、ランキングページを生成する(S176)。この際、CPU30は、遊んでいる仲間の多い順にゲームの説明などを配置して第2ランキングページを生成する。端末装置2は、管理サーバ3Aから第2ランキングページを含むアクセス応答を受信すると、第2ランキングページをディスプレイ25に表示する。このような処理により、所定期間内にアプリケーションを利用している仲間の候補利用者のみについて、アプリケーションごとにランキングを表示することが可能になる。
本変形例によれば、アプリケーションの利用から所定期間内の候補利用者に限定しているので、アプリケーションを試しに利用し、その後、利用しなくなった利用者については候補利用者から除くので、着目するアプリケーションについて実際に使用している利用者を候補利用者とすることができるといった利点がある。
また、本変形例によれば、日時情報を参照することによって、所定期間において仲間内であるアプリケーションを利用している人数を特定するので、ある期間においてあるアプリケーションを仲間内で利用している人数を一見して知ることができる。
なお、本変形例では、第2ランキング処理において、各ゲームにおける仲間数を特定する場合に、所定期間内にゲームを利用していることを条件に加えた場合について説明したが、本変形例は、第1ランキング処理にも適用可能である。第1ランキング処理に本変形例を適用する場合には、図23に示すS201とS202の間に、図24に示すS300に相当する処理を行えばよい。
さらに、申請元において状態情報Statが「0」(申請中)を示すレコードが10件をこえないように制限をしてもよい。くわえて、招待した相手がそのゲームを開始した場合に、例えば、招待者にインセンティブ(ポイント等)を付与してもよい。
ゲームのマイページから「仲間申請」や「招待する」や「ランキング」の処理へ遷移する場合には、アプリケーションサーバ3B、3C、3D…から「ゲームb」と「Xさん」からの要求であることの情報が通知される。管理サーバ3AのSNSサイトのマイページから遷移する場合には、同様の情報を与えればよい。SNSサイトでは「Xさん」のマイページにログインしていることから、仲間申請要求や招待要求が「Xさん」であることは把握できる。このため、どのゲームを誘うのかを選択する手段を設ける。つまり、どのゲームへの「仲間申請」なのか「招待」なのか、またはどのゲームでの仲間に人気のあるアプリケーションの「ランキング」なのかを選択できるようにする。また、ゲームを指定しない「ランキング」も選択できるようにする。これらの選択は、SNSサイトのマイページに選択のためにボタンを設ければよい。なお、ゲームを指定した「ランキング」は、上述した実施形態の第1ランキング処理であり、ゲームを指定しない「ランキング」は、上述した実施形態の第2ランキング処理である。
また、仲間上限数が各アプリケーションで固定化されていてもよい。その場合、例えば、アプリ情報テーブルTBL15で種別情報AppIDに関連付けて固定化された仲間上限数が記録されていてもよい。さらに、アプリケーションによって仲間上限数が固定化されているものと変動するものを含む場合、アプリ情報テーブルTBL15に種別情報AppIDに関連付けて仲間上限数が記憶されていれば固定化されているものとし、記憶されていなければ(null)仲間上限数テーブルTBL12を参照するようにしてもよい。
本変形例によれば、アプリケーションサーバから仲間上限数を取得する取得部を備えるので、仲間上限数を取得することが可能となる。
アプリケーションサーバ3B、3C、3D、…から種別情報及び利用者識別情報UIDと関連付けられた仲間上限数Limitの通知を受けた端末装置2は、検出部27によって端末装置2の利用者の仲間上限数が変化したことを検出する(S401)。そして、端末装置2の通知部28は、変化した後の仲間上限数を管理サーバ3Aに通知する。
端末装置2から変化した後の仲間上限数の通知を受けた管理サーバ3AのCPU30は、仲間上限数テーブルTBL12に変化した後の仲間上限数を記憶させる(S402)。
なお、本変形例においては、アプリケーションサーバ3B、3C、3D、…の通知部52は、前記管理部51で管理する前記利用実績の度合いに応じた仲間上限数Limitを、種別情報及び利用者識別情報UIDと関連付けて前記管理サーバ3Aに通知するようにしてもよい。
本発明はこれに限定されるものではなく、以下の態様をとり得る。第1に、CPU30は、状態情報Statが第1状態である場合に、招待の候補利用者から除いてもよい。即ち、
状態情報Statが招待中を示す第2状態において、再度、招待を認めてもよい。
また、状態情報Statにおいて、Stat=1を拒否、Stat=2を承認といったように、拒否と承認を区別して管理してもよい。この場合、CPU30は、状態情報Statが「0」拒否を示す場合に招待の候補利用者から除いてもよい。
これらを、総合すると、CPU30は、状態情報Statによって示される招待の状態が少なくとも拒否である場合に、利用者を候補利用者から除外する。
具体的には、図35に示す処理が行われる。図35は、図11に対応するフローチャートである。本変形例では、例えば、特定部12は、S111の処理が行われた後に、管理部51に対して、招待を拒否した利用者のリストを要求する。そして、特定部12は、当該リスト中の利用者とS111で抽出した利用者との間で一致する利用者が存在した場合には、当該利用者を、招待を拒否した利用者として特定する(S500)。
次に、CPU30は、インバイトテーブルTBL14を参照して、利用者Aを示す参照識別情報RefIDaが招待元、且つ候補利用者の利用者識別情報UID*xに対応する参照識別情報RefID*が招待先としてインバイトテーブルTBL14に記録されている場合には、当該利用者識別情報UID*xを、候補利用者の利用者識別情報UID*xから除外し、残りの候補利用者の利用者識別情報UID*xを抽出する。そして、CPU30は、抽出した候補利用者の利用者識別情報UID*xの中から、S500で特定した利用者の利用者識別情報UID*xを除外し、残りの利用者識別情報UID*xを集計する(S501)。
この変形例によれば、招待した利用者と招待を拒否した利用者とを対応づけて管理するので、一度、拒否された利用者を再度、招待することを未然に防止することができる。
しかし、本発明はこれに限定されるものではなく、CPU30は、日時情報Dateに基づいて状態情報Statを書き換えるのではなく、状態情報Statが招待中を示している場合に、招待の年月日を示す日時情報Dateから所定期間が経過した場合に、拒否されたとみなして取り扱ってもよい。例えば、本変形例では、図36に示す処理が行われる。図36は、図11に対応するフローチャートである。図36に示すように、CPU30は、招待を拒否した利用者と、招待中(第2状態)であって、招待日から所定期間が経過した利用者とを特定する(S510)。所定期間の経過は、招待の年月日を示す日時情報Dateに基づいて判断すればよい。
この変形例によれば、招待を申請中の利用者に対して、再度の招待申請を許容する。これにより、招待を承認するか否かをまよっている利用者に対して、再び招待することによって、ゲームへの参加を促すことができる。しかしながら、何度も招待するのは迷惑である。そこで、本変形例は、状態情報が申請中を示していても、招待の日時から所定期間が経過すると、状態情報が申請中を示していても、候補利用者から除外している。これにより、ゲームへの参加を促しつつ、迷惑行為を防止することが可能となる。また、拒否と承認を一つの状態として管理できるので、データ構造を簡素化できる。
なお、インバイトテーブルTBL14に、レコードの有効/無効を示す項目を新たに追加し、所定期間が過ぎた場合にレコードを無効とするようにしてもよい。
この変形例によれば、招待申請を通知した日時から所定期間が経過しても招待された利用者から応答がない場合、前記状態情報の状態を招待の申請中から招待の拒否へ書き換えるので、候補利用者に該当するか否かの判定を簡素化することができる。
また、招待を拒否された場合だけでなく、招待が承認された場合にも候補利用者から除外される。招待を承認した利用者は、そもそも招待の対象となるゲームを既に利用しているから、招待する必要がない。このようなデータ構造を採用することにより、拒否した利用者と招待された利用者を同時に排除できるので処理負荷が軽減される。
さらに、CPU30は、仲間申請可能な利用者の数と招待可能な利用者の数と並べて表示させるページを生成し、さらに仲間申請が可能な候補利用者と招待可能な利用者とを選択的に端末装置2に表示させてもよい。
具体的には、図39及び図40に示す処理が行われる。図39は、図18の第2ランキング処理に対応する本変形例におけるランキング処理のフローチャートである。図40は、図10及び図11に示す仲間申請可能な人数及び招待可能な人数の算出処理に対応する本変形例の処理のフローチャートである。
まず、CPU30は、図39に示すように、受信したアクセス要求に含まれる利用者識別情報UIDaxを取得する(S170)。次に、CPU30は、利用者情報テーブルTBL11を参照して、利用者識別情報UIDaxから利用者Aの参照識別情報RefIDaを取得する(S171)。さらに、CPU30は、関係テーブルTBL13を参照して、グループ情報Groupが「Friends」を示し、利用者Aの参照識別情報RefIDaに対応する種別情報AppIDxと利用者識別情報UID*xとの組みを特定する(S172)。
より具体的には、CPU30は、(Group= Friends)*{(RefID_To=RefIDa)+(RefID_From=RefIDa)}*(Stat=1)を充足するレコードを抽出し、それらに含まれる一又は複数の種別情報AppIDxと利用者識別情報UID*xとの組みを特定する。
利用者Aの全ての仲間の利用者識別情報UID*xを抽出した後、CPU30は、S172で抽出した組みにおいて、利用者識別情報UID*xの数を種別情報AppIDxごとに集計する(S173)。さらに、CPU30は、仲間の利用者識別情報UID*xの集計数に基づいて、種別情報AppIDxで特定されるゲームの人気順を特定する(S174)。
次に、CPU30は、抽出した全ての種別情報AppIDxと利用者識別情報UID*xとの組みに対してS700〜S713の処理が終了したか否かを判定する(S601)。全ての組みに対してS700〜S713の処理が終了していない場合には(S601:NO)、CPU30は、一つの種別情報AppIDxに着目し、当該種別情報AppIDxに対応するゲームに招待可能な利用者の人数の算出処理と、当該種別情報AppIDxに対応するゲームにおいて仲間申請可能な人数の算出処理とを行う。
次に、CPU30は、利用者A自身が仲間上限数に達しているか否かの判断を行う処理(S701〜S703)を行う。まず、CPU30は、仲間上限数テーブルTBL12を参照して、利用者Aの利用者識別情報UIDaxに対応する仲間上限数を取得する(S702)。
そして、CPU30は、取得した仲間上限数が、図39のS173で集計した種別情報AppIDxごとの仲間の利用者識別情報UID*xの数のうち、着目する種別情報AppIDxについての仲間の利用者識別情報UID*xの数を超えるか否かを判定する(S702)。この判定条件が否定される場合は(S702:NO)、着目する種別情報AppIDxに対応するゲームについて、既に利用者Aにおける仲間の利用者識別情報UID*xの総数が、仲間上限数に達しているので、仲間申請が不能となる。したがって、CPU30は、仲間申請が不能である旨のフラグをセットする(S703)。しかし、前記判定条件が否定される場合は(S702:YES)、着目する種別情報AppIDxに対応するゲームについて、利用者Aにおける仲間の利用者識別情報UID*xの総数は、未だ仲間上限数に達していないので、フラグをセットすることなく次の処理に移行する。
即ち、インバイトテーブルTBL14には招待中または招待済みの招待元の利用者と招待先の利用者とが組がレコードとして記録されており、このようなレコードに記録されている利用者というのは、過去に一度でも招待したことのある利用者ということになる。そこで、このように過去に一度でも招待したことのある利用者については、再度招待しないようにしている。これにより、利用者Aが招待可能な他の利用者とその人数とを特定することができる。集計された招待可能な仲間の数は、本変形例の第2ランキングページにおいてゲームごとに表示される(後述する図41の領域225を参照)。
まず、CPU30は、関係テーブルTBL13を参照して、着目する種別情報AppIDxについて、まだ仲間になっていない非仲間の利用者の利用者識別情報UID*xを抽出する(S706)。CPU30は、着目する種別情報AppIDxに対応するゲーム以外で仲間申請を行う利用者Aと仲間関係がある他の利用者であって、当該ゲームを既に利用している利用者を抽出し(第1条件)、さらに、関係テーブルTBL13を参照して、当該ゲームにおいて利用者Aと仲間関係が構築されていない利用者(第2条件)を抽出する。
S711において、CPU30は、仲間申請可能な非仲間の利用者識別情報UID*xを特定し、非仲間の人数を集計する。非仲間の集計数は、当該ゲーム以外の他のゲームにおいて仲間関係にあり当該ゲームにおいて仲間関係にない利用者の人数である。非仲間の集計数は、本変形例の第2ランキングページにおいてゲームごとに表示される(後述する図41の領域226を参照)。
この後、CPU30は、処理を図39に示すS601に戻す。そして、S172で抽出した全ての種別情報AppIDxについてS700からS713の処理を終了すると(S601:YES)、アプリ情報テーブルTBL15を参照して、抽出した種別情報AppIDxに対応するゲーム名、説明情報、及びアイコン情報を取得する。この後、CPU30は、S173で集計した各種別情報AppIDxに対応するゲームをプレイしている仲間数、S512で記憶させた各種別情報AppIDxに対応するゲームについて招待可能な人数及び仲間申請可能な人数、並びに、S175で取得した各種別情報AppIDxに対応するゲーム名、説明情報、及びアイコン情報に基づいて、ランキングページを生成する(S176)。この際、CPU30は、遊んでいる仲間の多い順にゲームの説明などを配置して第2ランキングページを生成する。端末装置2は、管理サーバ3Aから第2ランキングページを含むアクセス応答を受信すると、第2ランキングページをディスプレイ25に表示する。
なお、S703の処理で仲間申請が不能である旨のフラグがセットされている場合には、仲間申請可能な人数の替わりに、その表示を非表示にしたり、「申請可能人数に達しているため申請できません」といった表示をする。
領域221にはアプリ情報テーブルTBL15から読み出したアイコン情報に基づいてアイコンが表示され、領域222にはアプリケーション名(ゲーム名)が表示される。これらの情報は、上述したS175の処理で取得される。次に領域223には、利用者Aがプレイしているゲームのいずれかで、利用者Aと仲間関係にありゲームbを遊んだことのある他の利用者の人数が表示される。この情報は、上述したS173の処理で取得される。領域224には、ゲームbの説明が表示される。この情報は、上述したS175の処理で取得される。なお、ここで表示されるゲームは利用者Aがプレイしていないものも含まれる。
また、領域225には、利用者Aがゲームbについて他のゲームで仲間の利用者を、あと何人、招待可能かが表示される。招待可能な人数は、S705の処理で集計される。そして、領域226には、利用者Aがゲームbにおいて、新たに仲間申請可能な利用者の数が表示される。仲間申請可能な人数は、S711の処理で集計される。
また、本変形例によれば、要求されたアプリケーションにおいて仲間関係が構築されている利用者がアプリケーションを利用しており(第1条件)、当該アプリケーションについて要求利用者と仲間関係が構築されておらず(第2条件)、当該アプリケーションにおいて仲間上限数に達していない(第3条件)利用者の数を表示することが可能となる。これにより、要求されたアプリケーションについて、仲間申請可能な人数を知ることができ、利便性が向上する。
さらに、本変形例によれば、要求されたアプリケーションについて、招待可能な仲間の人数を知ることができ、利便性が向上する。
なお、本変形例は、第2ランキング処理を行う際に、ランクキング表示された各ゲームに招待可能な人数、及び、各ゲームにおいて新たに仲間申請可能な人数を表示する例について説明した。しかし、本変形例は、第1ランキング処理を行う際にも同様に適用可能である。第1ランキング処理を行う際に本変形例を適用する場合には、図9に示す画面において表示されているゲーム(図9の例ではゲームb)に対応する種別情報AppIDxについて、図40に示すS700からS712までの処理を行うようにすればよい。
このように、本変形例によれば、アプリケーションサーバに設けられた第2の利用者情報テーブルTBL11a及び第2の関係テーブルTBL13aと、管理サーバ3Aに設けられた第1の利用者情報テーブルTBL11及び第1の関係テーブルTBL13との同期を取るので、アプリケーションサーバにおける個別のアプリケーションの管理を管理サーバ3Aに容易に反映させることができる。
また、本変形例によれば、アプリケーションサーバに設けられた第2の仲間上限数テーブルTBL12aと、管理サーバ3Aに設けられた第1の仲間上限数テーブルTBL12との同期を取るので、アプリケーションサーバにおける個別のアプリケーションにおける仲間上限数の管理を管理サーバ3Aに容易に反映させることができる。
さらに、反映させた個別のアプリケーションの管理に基づいて、上述したような問合処理を行うことができる。
また、図47に示すように、通信網1を介して管理サーバ3Aと通信可能なストレージサーバ70に、利用者情報テーブル(アクセステーブル)TBL11、仲間上限数テーブルTBL12、関係テーブルTBL13を記憶させるようにしてもよい。また、通信網1を介してアプリケーションサーバ3B、3C、3D…と通信可能なストレージサーバ80に、利用者情報テーブルTBL11a、仲間上限数テーブルTBL12a、関係テーブルTBL13aを記憶させるようにしてもよい。
この場合には、管理サーバ3Aは、必要に応じてストレージサーバ70にアクセスし、各テーブルから情報を読み取るようにすればよい。また、アプリケーションサーバ3B、3C、3D…は、必要に応じてストレージサーバ60にアクセスし、各テーブルから情報を読み取るようにすればよい。
なお、ここでいう「コンピュータ」とは、OSや周辺機器等のハードウェアを含むものとする。また、「コンピュータ」は、インターネットやWAN、LAN、専用回線等の通信回線を含むネットワークを介して接続された複数のコンピュータ装置を含んでもよい。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM、コンピュータに内蔵されるハードディスク等の非一過性の記録媒体であっても良い。
さらに「コンピュータ読み取り可能な記録媒体」とは、ネットワークを介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ(RAM)のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、上述した機能の一部を実現するためのものであってもよい。さらに、上述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよい。また、本発明における機能またはその一部を実現するためのプログラムを配信する配信サーバ及び当該配信サーバに備えられた記憶媒体、及び当該配信サーバの外部に存在し、当該プログラムを前記配信サーバにより配信するために記憶している記憶媒体も、本発明の範囲に含まれる。
また、上述した機能の一部または全部を、LSI(Large Scale Integration)等の集積回路として実現してもよい。上述した各機能は個別にプロセッサ化してもよいし、一部、または全部を集積してプロセッサ化してもよい。また、集積回路化の手法はLSIに限らず専用回路、または汎用プロセッサで実現してもよい。また、半導体技術の進歩によりLSIに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いてもよい。
仲間申請処理に関する発明の他、上述した実施形態及び変形例から、以下に述べる招待処理に関する発明及び問合処理に関する発明なども導かれる。
(1)招待処理に関する発明
あるアプリケーションで、他のアプリケーションで仲間関係となった利用者を他のアプリケーションに招待可能とするため、本発明に係る管理サーバは、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能なサーバであって、招待の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付ける受付部と、前記受付部で受付けた種別情報が示すアプリケーションを利用していないことを条件としたとき、前記条件を充足する候補利用者の一部又は全部を特定する特定部と、前記特定部で特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させる表示制御部と、前記要求利用者が、前記端末装置に表示された候補利用者の中から選択した候補利用者に対して招待申請を通知する通知部と、を備える。
なお、前記条件に、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されていることを付加してもよい。この場合には、要求利用者と他のアプリケーションで仲間関係が構築されている利用者を誘うことができるので、過去に形成された仲間に新たなアプリケーションを広めることが可能となる。
また、通知部は、選択された候補利用者に対して招待申請を通知するのであれば、どのような方法であってもよく、例えば、登録されたメールアドレスに対して招待申請のメールを送信してもよいし、あるいは、選択された候補利用者が管理するページに招待申請があった旨を表示するようにしてもよい。また、他のソーシャルメディアや掲示板へ招待記事を投稿をするように送信してもよい。
この発明によれば、各種のアプリケーションの種別情報と全ての利用者の利用者識別情報とを対応づけて記憶する利用者情報テーブルを備えるので、複数のアプリケーションの利用者を一元的に管理することが可能となる。
さらに、前記特定部は、前記仲間関係テーブルを参照して、前記要求利用者が利用したことのある利用済みアプリケーションに対応する種別情報と関連付けて記憶されている前記利用者情報の組のうち、仲間申請を行った利用者の利用者情報が前記要求利用者の利用情報と一致する仲間申請を受諾した利用者の利用者情報を抽出するとともに、仲間申請を受諾した利用者の利用者情報が前記要求利用者の利用者情報と一致する仲間申請を行った利用者の利用者情報を抽出し、抽出した利用者情報の利用者を、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築される候補利用者とすることが好ましい。
この発明によれば、利用済みアプリケーションを選択できるように要求利用者の端末装置に表示させ、選択した利用済みアプリケーションについて仲間関係にあることが候補利用者の要件となるので、要求利用者は、招待しようとするアプリケーションと類似する利用済みアプリケーションを選択するなど、好みに合わせた選択が可能となる。
この発明によれば、招待申請が可能な人数を知ることができるので、要求利用者に利便性が大幅に向上する。なお、招待申請が可能な人数は、利用済みアプリケーションごとに特定し、利用済みアプリケーションごとに要求利用者の端末装置に表示させてもよいし、複数の利用済みアプリケーションの合計の招待申請が可能な人数を特定し、これを要求利用者の端末装置に表示させてもよい。
この発明によれば、招待の状態を示す状態情報と利用者情報とを対応づけて招待テーブルで管理するので、招待テーブルを参照することによって、招待の状態を知ることができる。そして、状態情報が拒否を示す場合には、候補利用者から除かれるので、招待を拒否しているに拘わらず再度の招待があるといった迷惑行為を未然に防止することがきる。
この発明によれば、拒否と承認をまとめて第1状態としている。したがって、招待を拒否された場合だけでなく、招待が承認された場合にも候補利用者から除外される。招待を承認した利用者は、そもそも招待の対象となるアプリケーションを既に利用しているから、招待する必要がない。このようなデータ構造を採用することにより、拒否した利用者と招待された利用者を同時に排除できるので処理負荷が軽減される。
この発明によれば、招待申請中の利用者も候補利用者から除かれるから、申請中に拘わらず、再度、招待を申請するといった無駄をなくし、管理サーバの処理負荷を軽減することができる。
より具体的には、前記状態情報の示す状態は、招待を拒否又は承認したことを示す第1状態と、招待の申請中であることを示す第2状態とを含み、前記状態情報が少なくとも招待の拒否を示すとは、前記状態情報の状態が前記第1状態であり、前記状態情報が招待の申請中を示すとは、前記状態情報の状態が前記第2状態であることが好ましい。この場合には、拒否と承認を一つの状態として管理できるので、データ構造を簡素化できる。
この発明によれば、招待申請を通知した日時から所定期間が経過しても招待された利用者から応答がない場合、前記状態情報の状態を招待の申請中から招待の拒否へ書き換えるので、候補利用者に該当するか否かの判定を簡素化することができる。
この発明によれば、招待を拒否された場合だけでなく、招待が承認された場合にも候補利用者から除外される。招待を承認した利用者は、そもそも招待の対象となるアプリケーションを既に利用しているから、招待する必要がない。このようなデータ構造を採用することにより、拒否した利用者と招待された利用者を同時に排除できるので処理負荷が軽減される。
各種のアプリケーションにおける仲間全体の状況を利用者に知らせる管理サーバなどを提供するといった課題を解決するため、本発明に係る管理サーバは、種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能であって、利用者の端末装置の操作に基づく要求を受ける受付部と、前記複数のアプリケーションのうち、前記受付部で受け付けた要求の利用者である要求利用者が利用したことがある利用済みアプリケーションにおいて、前記要求利用者と仲間関係が構築されている利用者が利用しているアプリケーションに関する利用情報を取得する情報取得部と、前記情報取得部で取得した前記利用情報を前記要求利用者の端末装置に表示させる表示制御部と、を備える。
なお、利用情報は、例えば、人気ゲームランキング、遊んでいる人数、仲間申請できる人数、招待できる人数の情報を含む。
また、利用者の端末装置の操作に基づく要求には、管理サーバが提供するページを閲覧している要求利用者が端末装置を操作することによって、端末装置から管理サーバに直接送信される要求の他に、複数のアプリケーションサーバのいずれかが提供するページを閲覧している要求利用者が端末装置を操作することによって、アプリケーションサーバから管理サーバに送信される要求がある。
また、より具体的には、上述した管理サーバは、アプリケーションの種類を示す種別情報に関連付けて仲間関係となる利用者情報の組を記憶する仲間関係テーブルを備え、前記要求には、アプリケーションの種類を示す種別情報が含まれており、前記情報取得部は、前記仲間関係テーブルを参照して、前記要求利用者の利用者情報と仲間関係にある利用者の利用者情報と前記種別情報との組みを抽出し、抽出した前記利用者情報と前記種別情報との組みに基づいて前記利用情報を取得することが好ましい。
利用者の端末装置の操作に基づく要求には、管理サーバが提供するページを閲覧している要求利用者が端末装置を操作することによって、端末装置から管理サーバに直接送信される要求の他に、複数のアプリケーションサーバのいずれかが提供するページを閲覧している要求利用者が端末装置を操作することによって、アプリケーションサーバから管理サーバに送信される要求がある。
また、要求が端末装置から管理サーバに送信される場合、前記要求には、複数のアプリケーションのうち要求利用者が選択したアプリケーションを示す種別情報が含まれており、前記情報取得部は、前記要求に含まれる種別情報に基づいて、前記要求に対応づけられたアプリケーションを特定してもよい。一方、要求がアプリケーションサーバから送信される場合、前記情報取得部は、送信元であるアプリケーションサーバで提供するアプリケーションを前記要求に対応づけられたアプリケーションとして特定してもよい。
また、より具体的には、上述した管理サーバは、アプリケーションの種類を示す種別情報に関連付けて仲間関係となる利用者情報の組を記憶する仲間関係テーブルと、前記種別情報とアプリケーションの内容を示すアプリ情報とを関連付けて記憶したアプリ情報テーブルとを備え、前記要求には、アプリケーションの種類を示す種別情報が含まれており、前記情報取得部は、前記仲間関係テーブルを参照して、前記要求利用者の利用者情報と仲間関係にある利用者の利用者情報と前記種別情報との組みを抽出し、前記アプリ情報テーブルを参照して抽出した前記種別情報に対応するアプリ情報を前記利用情報として取得してもよい。
この場合、表示制御部は、要求利用者と仲間関係が構築されている利用者の数の多い順にアプリケーションの種類を表示するが、具体的には、前記情報取得部は、利用者の数をアプリケーションごとに集計し、アプリケーションごとの集計数を前記利用情報として生成し、表示制御部は、集計した利用者の数の多い順にアプリケーションの種類を表示すればよい。
なお、表示制御部は、所定期間内にアプリケーションを利用している利用者の数の多い順にアプリケーションの種類を表示するが、具体的には、前記情報取得部は、前記要求利用者と仲間関係が構築されている利用者のいずれかが利用しているアプリケーションを対象として、前記アクセステーブルを用いて、前記要求利用者と仲間関係が構築されている利用者であって、且つ所定期間内にアプリケーションを利用している利用者の数をアプリケーションごとに集計し、アプリケーションごとの集計数を前記利用情報として生成し、表示制御部は、集計した利用者の数の多い順にアプリケーションの種類を表示すればよい。
この発明によれば、アプリケーションを利用している利用者数が端末装置に表示されるので、相対的なランキングよりも詳細な情報を利用者は得るこができる。
この発明によれば、日時情報を参照することによって、所定期間において仲間内であるアプリケーションを利用している人数を特定するので、ある期間においてあるアプリケーションを仲間内で利用している人数を一見して知ることができる。
この発明によれば、要求されたアプリケーションにおいて仲間関係が構築されている利用者がアプリケーションを利用しており(第1条件)、当該アプリケーションについて要求利用者と仲間関係が構築されておらず(第2条件)、当該アプリケーションにおいて仲間上限数に達していない(第3条件)利用者の数を表示することが可能となる。これにより、要求されたアプリケーションについて、仲間申請可能な人数を知ることができ、利便性が向上する。さらに仲間申請が可能な候補利用者の一部または全部を選択できるように端末装置に表示させて、利用者が候補利用者の中から選択して仲間申請が可能にするようにしてもよい。
この発明よれば、要求されたアプリケーションについて、招待可能な仲間の人数を知ることができ、利便性が向上する。さらに、招待が可能な候補利用者の一部または全部を選択できるように端末装置に表示させて、利用者が候補利用者の中から選択して招待が可能にするようにしてもよい。
さらに、仲間申請可能な利用者の数と招待可能な利用者の数と並べて表示させ、さらに仲間申請が可能な候補利用者と招待可能な利用者とを選択的に端末装置に表示させるようにすると、例えば、具体的にどのアプリケーションのどの仲間を誘いたいかがあらかじめ決まっているような場合に、その相手が要求されたアプリケーションを未だ利用していないことが判明した場合に、招待可能な利用者の表示に切り替えることで、仲間申請でなく招待をすることができるようになる。このように、あるアプリケーションに仲間申請したい相手が当該アプリケーションを利用していない場合もあり得るので、仲間申請の機能と招待の機能を組にして端末装置で利用者に提供させることは、利用者にとって利便性が高まることになる。
Claims (13)
- 種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバであって、
仲間の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付ける受付部と、
前記受付部で受付けた種別情報が示すアプリケーションを利用していることを第1条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第2条件、当該アプリケーションにおいて仲間上限数に達していないことを第3条件としたとき、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定する特定部と、
前記特定部で特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させる表示制御部と、
前記受付部で受付けた種別情報が示すアプリケーションに対応したアプリケーションサーバに対して、前記要求利用者が前記候補利用者の中から選択した利用者に対して仲間申請を要求する指示を行う指示部と、
を備えることを特徴とする管理サーバ。 - 前記特定部は、前記種別情報に関連付けて当該種別情報が示すアプリケーションを利用している利用者情報を備える第1の利用者情報テーブルを参照して前記第1条件を充足する候補利用者を特定し、前記種別情報に関連付けて仲間関係となる利用者情報の組を備える第1の仲間関係テーブルを参照して前記第2条件を充足する候補利用者を特定する、
ことを特徴とする請求項1に記載の管理サーバ。 - 前記第1の利用者情報テーブルの内容と、前記アプリケーションサーバが提供するアプリケーションを利用する利用者を示す利用者情報を備える第2の利用者情報テーブルの内容とを同期させる利用者情報同期部と、前記第1の仲間関係テーブルの内容と、前記アプリケーションサーバが提供するアプリケーションについて、仲間関係となる利用者情報の組を備える第2の仲間関係テーブルの内容とを同期させる仲間関係同期部と、
を備えることを特徴とする請求項2に記載の管理サーバ。 - 前記第1の仲間関係テーブルが備える前記利用者情報の組は、仲間申請を行った利用者の利用者情報と、仲間申請を受諾した利用者の利用者情報とからなる、ことを特徴とする請求項2または3に記載の管理サーバ。
- 前記受付部で受付けた種別情報に対応する前記アプリケーションサーバにおいて設定された利用者の仲間上限数を取得する取得部を備え、
前記特定部は、前記取得部が取得した仲間上限数を利用者情報と関連付けて備える第1の仲間上限数テーブルを参照して前記第3条件を充足する候補利用者を特定する、
ことを特徴とする請求項1乃至4のうちいずれか1項に記載の管理サーバ。 - 前記取得部は、前記第1の仲間上限数テーブルの内容と、前記アプリケーションサーバで管理する仲間上限数と利用者情報とを関連付けて備える第2の仲間上限数テーブルの内容とを同期させる仲間上限数同期部を備える、
ことを特徴とする請求項5に記載の管理サーバ。 - 前記受付部で受付けた種別情報に対応する前記アプリケーションサーバに対して利用者の仲間上限数を問い合わせる要求を送信し、前記要求に対する応答として当該アプリケーションサーバから仲間上限数を取得する取得部を備え、
前記特定部は、前記取得部で取得した仲間上限数に基づいて前記第3条件を充足する候補利用者を特定する、
ことを特徴とする請求項1乃至4のうちいずれか1項に記載の管理サーバ。 - 前記特定部は、前記アプリケーションの利用日時を示す日時情報を利用者識別情報と関連付けて備えるアクセステーブルを参照して所定期間内にアプリケーションを利用していることを前記第1条件に加えて、前記第1条件を充足する候補利用者を特定する、
ことを特徴とする請求項1乃至7のうちいずれか1項に記載の管理サーバ。 - 前記表示制御部は、前記要求利用者が利用したことのある利用済みアプリケーションを選択できるように前記要求利用者の端末装置に表示させ、
前記特定部は、前記端末装置において前記要求利用者が選択した利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定する、
ことを特徴とする請求項1乃至8のうちいずれか1項に記載の管理サーバ。 - 前記特定部は、前記要求利用者が利用したことのある利用済みアプリケーションについて、仲間申請が可能な人数を特定し、
前記表示制御部は、前記特定部が特定した仲間申請が可能な人数を前記要求利用者の端末装置に表示させる、
ことを特徴とする請求項1乃至8のうちいずれか1項に記載の管理サーバ。 - 種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバのコンピュータに用いられるプログラムであって、
前記コンピュータを、
仲間の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付ける受付部と、
前記受付部で受付けた種別情報が示すアプリケーションを利用していることを第1条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第2条件、当該アプリケーションにおいて仲間上限数に達していないことを第3条件としたとき、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定する特定部と、
前記特定部で特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させる表示制御部と、
前記受付部で受付けた種別情報が示すアプリケーションに対応したアプリケーションサーバに対して、前記要求利用者が前記候補利用者の中から選択した利用者に対して仲間申請を要求する指示を行う指示部として機能させる、
ことを特徴とするプログラム。 - 種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバおよび利用者の端末装置と通信可能な管理サーバの制御方法であって、
仲間の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付け、
受付けた種別情報が示すアプリケーションを利用していることを第1条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第2条件、当該アプリケーションにおいて仲間上限数に達していないことを第3条件としたとき、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定し、
特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させ、
受付けた種別情報が示すアプリケーションに対応したアプリケーションサーバに対して、前記要求利用者が前記候補利用者の中から選択した利用者に対して仲間申請を要求する、
ことを特徴とする管理サーバの制御方法。 - 種類の異なる複数のアプリケーションのそれぞれに対応した複数のアプリケーションサーバと接続された管理サーバと通信可能な利用者の端末装置のコンピュータに用いられるプログラムであって、
前記複数のアプリケーションサーバの各々は、仲間の上限数を利用者ごとに管理しており、
前記管理サーバは、仲間の候補となる候補利用者を提示することを要求する要求利用者が端末装置を操作して指定したアプリケーションの種類を示す種別情報を受付ける受付部と、前記受付部で受付けた種別情報が示すアプリケーションを利用していることを第1条件、当該アプリケーションについて前記要求利用者と仲間関係が構築されていないことを第2条件、当該アプリケーションにおいて仲間上限数に達していないことを第3条件としたとき、前記要求利用者が利用したことのある利用済みアプリケーションにおいて仲間関係が構築されている利用者のうち前記各条件の全てを充足する候補利用者の一部又は全部を特定する特定部と、前記特定部で特定した前記一部又は全部の候補利用者を選択できるように前記要求利用者の端末装置に表示させる表示制御部と、前記受付部で受付けた種別情報が示すアプリケーションに対応したアプリケーションサーバに対して、前記要求利用者が前記候補利用者の中から選択した利用者に対して仲間申請を要求する指示を行う指示部と、を備え、
前記端末装置のコンピュータを、
当該端末装置の利用者の仲間上限数が変化したことを検出する検出部と、
前記検出部によって前記仲間上限数が変化したことが検出されると、変化した後の仲間上限数を前記管理サーバに通知する通知部として、
機能させること特徴とするプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013007054A JP5551801B2 (ja) | 2012-02-06 | 2013-01-18 | 管理サーバ、その制御方法、並びに管理サーバ及び端末装置のプログラム |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012023157 | 2012-02-06 | ||
JP2012023157 | 2012-02-06 | ||
JP2012061621 | 2012-03-19 | ||
JP2012061621 | 2012-03-19 | ||
JP2013007054A JP5551801B2 (ja) | 2012-02-06 | 2013-01-18 | 管理サーバ、その制御方法、並びに管理サーバ及び端末装置のプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2013225290A true JP2013225290A (ja) | 2013-10-31 |
JP5551801B2 JP5551801B2 (ja) | 2014-07-16 |
Family
ID=48947361
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013007054A Active JP5551801B2 (ja) | 2012-02-06 | 2013-01-18 | 管理サーバ、その制御方法、並びに管理サーバ及び端末装置のプログラム |
Country Status (4)
Country | Link |
---|---|
US (1) | US9486710B2 (ja) |
JP (1) | JP5551801B2 (ja) |
KR (1) | KR101449391B1 (ja) |
WO (1) | WO2013118595A1 (ja) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107113224A (zh) * | 2015-01-02 | 2017-08-29 | 连股份有限公司 | 提供由特定条件控制的聊天软件服务的方法和系统及记录介质 |
JP2017191460A (ja) * | 2016-04-13 | 2017-10-19 | 任天堂株式会社 | 情報処理システム、サーバ、情報処理方法及びプログラム |
JP2018114395A (ja) * | 2012-08-06 | 2018-07-26 | グリー株式会社 | コンピュータ装置、表示制御方法及び表示制御プログラム |
JP2019507629A (ja) * | 2016-02-23 | 2019-03-22 | ソニー インタラクティブ エンタテインメント アメリカ リミテッド ライアビリテイ カンパニー | ゲームの選択及び招待プロセス |
JP2022022395A (ja) * | 2019-09-02 | 2022-02-03 | グリー株式会社 | ゲームプログラム、コンピュータの制御方法およびコンピュータ |
JP7529979B2 (ja) | 2020-06-29 | 2024-08-07 | 株式会社Mixi | 情報処理装置、プログラム、及び情報処理方法 |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6864477B2 (ja) * | 2017-01-06 | 2021-04-28 | 任天堂株式会社 | 情報処理装置、情報処理システム、情報処理方法及びプログラム |
US10237409B1 (en) * | 2017-02-13 | 2019-03-19 | West Corporation | Multimode service communication configuration for performing transactions |
US9986095B1 (en) * | 2017-02-13 | 2018-05-29 | West Corporation | Multimode service communication configuration for performing transactions |
CN111226250B (zh) * | 2018-09-26 | 2023-09-22 | 乐天集团股份有限公司 | 受理系统、受理方法、以及储存介质 |
JP6878533B2 (ja) * | 2019-09-09 | 2021-05-26 | 株式会社バンダイ | プログラム、情報処理装置及びゲームシステム |
CN112035202B (zh) * | 2020-08-25 | 2021-11-23 | 北京字节跳动网络技术有限公司 | 好友活跃信息的显示方法、装置、电子设备和存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2000054616A (ja) * | 1998-08-10 | 2000-02-22 | Masaru Morino | 伸縮体 |
JP2004244951A (ja) * | 2003-02-14 | 2004-09-02 | Meiko:Kk | 梯子における手摺りの取付け構造 |
JP2007170098A (ja) * | 2005-12-26 | 2007-07-05 | Techno Ace:Kk | 梯子 |
JP2011202363A (ja) * | 2010-03-24 | 2011-10-13 | Akimasa Kawahara | 梯子 |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3446697B2 (ja) | 1999-12-10 | 2003-09-16 | 日本電気株式会社 | コンテンツ利用制御システム |
JP4192401B2 (ja) | 2000-05-15 | 2008-12-10 | カシオ計算機株式会社 | 通信対戦システム及びサーバ装置 |
JP2002157204A (ja) | 2000-11-17 | 2002-05-31 | Square Co Ltd | ゲーム装置、サーバシステム、情報サービス方法、記録媒体およびプログラム |
JP2003071138A (ja) * | 2001-08-31 | 2003-03-11 | Square Co Ltd | ゲームシステム、ゲーム制御方法およびその記録媒体ならびにコンピュータプログラム |
KR20040081906A (ko) * | 2003-03-17 | 2004-09-23 | 주식회사 케이티 | 상호 정보제공 및 정보획득 환경에서의 상호 보상 서비스제공 방법 |
JP4168972B2 (ja) | 2004-05-10 | 2008-10-22 | 株式会社セガ | 会員登録されたユーザを起点に会員未登録の他のユーザに会員サービスを提供するシステム、サーバ、サービス提供方法およびプログラム |
CA2608691C (en) * | 2005-05-17 | 2016-01-05 | Adscape Media Inc. | Method and system for enhancing video games and video game systems |
US20070173324A1 (en) * | 2006-01-20 | 2007-07-26 | Microsoft Corporation | Computer-based gaming groups |
US20070244570A1 (en) * | 2006-04-17 | 2007-10-18 | 900Seconds, Inc. | Network-based contest creation |
US7917594B2 (en) | 2007-03-30 | 2011-03-29 | Verizon Patent And Licensing Inc. | Method and system for notifying an invitee user when an inviting user accesses a social networking application |
US8024431B2 (en) * | 2007-12-21 | 2011-09-20 | Domingo Enterprises, Llc | System and method for identifying transient friends |
JP4724706B2 (ja) | 2007-12-25 | 2011-07-13 | ソフトバンクモバイル株式会社 | メニュー情報管理方法及びそのシステム |
US20090197681A1 (en) | 2008-01-31 | 2009-08-06 | Microsoft Corporation | System and method for targeted recommendations using social gaming networks |
US8195656B2 (en) * | 2008-02-13 | 2012-06-05 | Yahoo, Inc. | Social network search |
US9235644B2 (en) | 2008-07-14 | 2016-01-12 | Qualcomm Incorporated | Operator, device and platform independent aggregation, cross-platform translation, enablement and distribution of user activity catalogs |
JP4992854B2 (ja) * | 2008-08-06 | 2012-08-08 | 日本電気株式会社 | コミュニティ管理システム、及びコミュニティ管理方法 |
CN102483788B (zh) * | 2009-09-10 | 2015-07-08 | 索尼计算机娱乐公司 | 信息处理系统、信息处理方法、信息处理设备、信息处理设备控制方法、信息处理终端、信息处理终端控制方法、信息存储介质以及程序 |
JP5155272B2 (ja) * | 2009-09-14 | 2013-03-06 | ヤフー株式会社 | コミュニティ管理プラットフォーム装置 |
JP5457146B2 (ja) * | 2009-11-25 | 2014-04-02 | 株式会社バンダイナムコゲームス | サーバシステム、及びアイテム管理方法 |
US8388450B1 (en) | 2011-09-26 | 2013-03-05 | Zynga Inc. | Expanding the gaming social network with unrelated players |
-
2013
- 2013-01-18 JP JP2013007054A patent/JP5551801B2/ja active Active
- 2013-01-28 KR KR1020147024823A patent/KR101449391B1/ko active IP Right Grant
- 2013-01-28 WO PCT/JP2013/051710 patent/WO2013118595A1/ja active Application Filing
-
2014
- 2014-08-06 US US14/453,053 patent/US9486710B2/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2000054616A (ja) * | 1998-08-10 | 2000-02-22 | Masaru Morino | 伸縮体 |
JP2004244951A (ja) * | 2003-02-14 | 2004-09-02 | Meiko:Kk | 梯子における手摺りの取付け構造 |
JP2007170098A (ja) * | 2005-12-26 | 2007-07-05 | Techno Ace:Kk | 梯子 |
JP2011202363A (ja) * | 2010-03-24 | 2011-10-13 | Akimasa Kawahara | 梯子 |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2018114395A (ja) * | 2012-08-06 | 2018-07-26 | グリー株式会社 | コンピュータ装置、表示制御方法及び表示制御プログラム |
CN107113224A (zh) * | 2015-01-02 | 2017-08-29 | 连股份有限公司 | 提供由特定条件控制的聊天软件服务的方法和系统及记录介质 |
US11606322B2 (en) | 2015-01-02 | 2023-03-14 | Line Corporation | Methods, systems and recording mediums for providing messenger service having specific condition |
US11929970B2 (en) | 2015-01-02 | 2024-03-12 | Line Corporation | Methods, systems and recording mediums for providing messenger service having specific condition |
JP2019507629A (ja) * | 2016-02-23 | 2019-03-22 | ソニー インタラクティブ エンタテインメント アメリカ リミテッド ライアビリテイ カンパニー | ゲームの選択及び招待プロセス |
JP7057755B2 (ja) | 2016-02-23 | 2022-04-20 | ソニー・インタラクティブエンタテインメント エルエルシー | ゲームの選択及び招待プロセス |
JP2017191460A (ja) * | 2016-04-13 | 2017-10-19 | 任天堂株式会社 | 情報処理システム、サーバ、情報処理方法及びプログラム |
US10581787B2 (en) | 2016-04-13 | 2020-03-03 | Nintendo Co., Ltd. | Systems and methods of friend registration |
JP2022022395A (ja) * | 2019-09-02 | 2022-02-03 | グリー株式会社 | ゲームプログラム、コンピュータの制御方法およびコンピュータ |
JP7529979B2 (ja) | 2020-06-29 | 2024-08-07 | 株式会社Mixi | 情報処理装置、プログラム、及び情報処理方法 |
Also Published As
Publication number | Publication date |
---|---|
US9486710B2 (en) | 2016-11-08 |
KR101449391B1 (ko) | 2014-11-07 |
WO2013118595A1 (ja) | 2013-08-15 |
KR20140129094A (ko) | 2014-11-06 |
US20140351338A1 (en) | 2014-11-27 |
JP5551801B2 (ja) | 2014-07-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5705888B2 (ja) | 管理サーバ、その制御方法、及びそのプログラム | |
JP5551801B2 (ja) | 管理サーバ、その制御方法、並びに管理サーバ及び端末装置のプログラム | |
WO2013118597A1 (ja) | 管理サーバ、その制御方法、及びそのプログラムを記録したコンピュータ読み取り可能な非一過性記録媒体 | |
JP5695699B2 (ja) | 管理装置、その制御方法及びプログラム、アプリケーションシステム、並びに識別情報関連付け方法 | |
JP5726944B2 (ja) | 管理装置、その制御方法、及びプログラム | |
JP5758947B2 (ja) | 端末装置、その制御方法及びプログラム、並びにアプリケーションシステム | |
JP2007018415A (ja) | ネットワーク要素検索方法、及びネットワーク要素検索プログラム | |
JP6124000B2 (ja) | 管理装置、サービス提供システム、管理装置の制御方法、及び、管理装置のプログラム。 | |
JP5634468B2 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、情報処理装置 | |
JP6097953B2 (ja) | 管理装置、管理装置と通信可能な端末装置、サービス提供システム、管理装置の制御方法、端末装置のプログラム及び管理装置のプログラム | |
JP2014038594A (ja) | 管理装置、サービス提供システム、管理装置の制御方法、及び、管理装置のプログラム。 | |
JP2014010798A (ja) | 管理装置、サービス提供システム、管理装置の制御方法、及び、管理装置のプログラム | |
JP2023009200A (ja) | ゲーム情報処理装置,情報処理装置の制御方法及び制御プログラム | |
JP6265320B2 (ja) | 情報処置装置、管理装置、サービス提供システム、管理装置の制御方法、情報処理装置のプログラム、及び管理装置のプログラム | |
JP2014021737A (ja) | 管理装置、サービス提供システム、管理装置の制御方法、及び、管理装置のプログラム | |
JP5222418B1 (ja) | ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム | |
JP7260831B1 (ja) | 情報処理装置、情報処理方法、及びプログラム | |
JP6075894B2 (ja) | 管理装置、管理装置と通信可能な端末装置、サービス提供システム、管理装置の制御方法、及び管理装置のプログラム | |
JP2014038415A (ja) | 催事管理装置の管理方法、催事管理装置、及び、催事管理装置のプログラム | |
JP6175730B2 (ja) | 管理装置、管理装置と通信可能な端末装置、サービス提供システム、管理装置の制御方法、端末装置のプログラム及び管理装置のプログラム | |
JP5763600B2 (ja) | ゲーム制御装置、プログラム、ゲームシステム | |
JP2009276899A (ja) | ネットワークシステム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20130920 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20140421 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20140520 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20140522 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5551801 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |