KR101449391B1 - 관리 서버 - Google Patents

관리 서버 Download PDF

Info

Publication number
KR101449391B1
KR101449391B1 KR1020147024823A KR20147024823A KR101449391B1 KR 101449391 B1 KR101449391 B1 KR 101449391B1 KR 1020147024823 A KR1020147024823 A KR 1020147024823A KR 20147024823 A KR20147024823 A KR 20147024823A KR 101449391 B1 KR101449391 B1 KR 101449391B1
Authority
KR
South Korea
Prior art keywords
user
application
friend
information
candidate
Prior art date
Application number
KR1020147024823A
Other languages
English (en)
Other versions
KR20140129094A (ko
Inventor
세이켄 가네오카
유지 오사토
가즈히코 다지마
요시유키 시모후레
가즈야 무라카미
히로키 도우시타
Original Assignee
가부시키가이샤 코나미 데지타루 엔타테인멘토
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 가부시키가이샤 코나미 데지타루 엔타테인멘토 filed Critical 가부시키가이샤 코나미 데지타루 엔타테인멘토
Publication of KR20140129094A publication Critical patent/KR20140129094A/ko
Application granted granted Critical
Publication of KR101449391B1 publication Critical patent/KR101449391B1/ko

Links

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)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (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

관리 서버는, 애플리케이션의 종류를 나타내는 종별 정보를 접수하는 접수부와, 종별 정보가 나타내는 애플리케이션을 이용하고 있을 것을 제1 조건, 당해 애플리케이션에 대하여 상기 요구 이용자와 친구 관계가 구축되어 있지 않을 것을 제2 조건, 당해 애플리케이션에서 친구 상한수에 달하지 않았을 것을 제3 조건으로 했을 때, 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정하는 특정부와, 특정부에서 특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부를 구비한다.

Description

관리 서버{MANAGEMENT SERVER}
본 발명은, 어떤 서비스에서 친구가 된 사람을 다른 서비스에 초대하는 기술에 관한 것이다.
최근 들어, 인터넷상에서의 애플리케이션을 제공하는 서비스가 급속하게 보급되고 있다. 이러한 종류의 서비스의 하나로서, SNS(Social Networking Service) 등의 사이트에서 제공하는 게임이 있다. 이 경우, 게임 시스템은, 메일이나 채팅 또는 게시판 등을 커뮤니케이션의 툴로서 제공하는 경우가 많다. 그리고, 이용자는, 커뮤니케이션의 툴을 사용하여 다른 이용자와 서로 아는 친구 관계를 구축한다. 친구가 된 이용자는, 강한 적과 공동으로 싸우기 위해 다른 이용자의 게임에 참가하기도 한다.
또한, 종래의 게임 시스템에서는, 친구 후보의 제시에 대해 요구가 있었던 이용자에 대하여, 친구 상대의 후보가 되는 이용자를 추출하여, 이것을 제시하는 일이 행하여지고 있었다(비특허문헌 1).
「소셜 게임 종합 정보지 어플리 STYLE Vol.2」, 가부시끼가이샤 이스트·프레스, 2011년 4월 1일, p.37
그런데, 상기 게임 시스템에서는, 복수의 게임이 제공되는 경우가 많고, 게임의 종류마다 게임 서버가 설치되어 있었다. 그리고, 종래의 게임 시스템에서는, 게임 서버마다 친구 관계를 관리하고 있어, 친구 관계는 게임마다 독립되어 있었다. 그리고 각 게임에서 친구가 될 수 있는 대상으로서, SNS상에서 이미 친구로 되어 있는 상대(실제 친구)나, 게임측에서 임의로 선정한 상대(가상 친구)로 한정되어 있었다. 게임측에서 임의로 선정한 알지 못하는 상대라도, 게임을 진행시켜나가면서 신뢰 관계가 구축되어 가는 경우도 있다. 신뢰 관계가 구축된 가상 친구라면, 다른 게임에서도 친구가 되고 싶어하는 요청이 생긴다. 그러나, 실제 친구라면 SNS상의 메일 기능을 이용하여 교류의 기회를 얻을 수 있지만, 가상 친구는, 친구 관계가 구축되어 있는 게임 내에서밖에는 교류할 수 없다. 따라서, 어떤 게임에서 친구로서 초대하는 경우에, 다른 게임에서 친구 관계가 구축된 상대를 선택할 수 없다는 과제가 있었다. 이 과제를 해결하는 수단으로서, 친구로서 초대하고 싶은 게임에 있어서, 상대를 검색시키는 기능을 구비시키는 것도 생각할 수 있다. 그러나, 다수의 이용자가 있는 가운데, 동일한 이름으로 등록되어 있는 경우도 있을 수 있는 경우나, 검색하는 처리 부하의 문제가 있는 등의 이유로 실현이 어려웠다. 또한 친구로서 초대하고 싶은 상대가, 초대하고 싶은 게임을 이미 플레이하고 있는지 여부도 알 수 없다는 과제가 있었다. 친구를 초대하기 위해서는, 상대가 그 게임을 플레이하고 있을 것이 당연히 필요해지기 때문이다.
본 발명은 이러한 점을 감안하여 이루어진 것으로, 어떤 애플리케이션에서, 다른 애플리케이션에서 친구 관계가 된 이용자와 친구 관계를 용이하게 구축 가능하게 하는 것을 해결 과제로 한다.
이상의 과제를 해결하기 위하여 본 발명이 채용하는 구성을 이하에 설명한다.
상술한 과제를 해결하기 위해서, 본 발명에 따른 관리 서버는, 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말 장치와 통신 가능한 것으로서, 친구의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보를 접수하는 접수부와, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있을 것을 제1 조건, 당해 애플리케이션에 대하여 상기 요구 이용자와 친구 관계가 구축되어 있지 않을 것을 제2 조건, 당해 애플리케이션에 있어서 친구 상한수에 달하지 않았을 것을 제3 조건으로 했을 때, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정하는 특정부와, 상기 특정부에서 특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부와, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션에 대응한 애플리케이션 서버에 대하여 상기 요구 이용자가 상기 후보 이용자 중에서 선택한 이용자에 대하여 친구 신청을 요구하는 지시를 행하는 지시부를 구비한다.
애플리케이션으로서는, 게임 애플리케이션을 예시할 수 있는데, 본 발명은 이것에 한정되는 것은 아니며, 어떠한 것이어도 됨은 물론이다.
상술한 관리 서버에 있어서, 상기 특정부는, 상기 종별 정보에 관련지어서 당해 종별 정보가 나타내는 애플리케이션을 이용하고 있는 이용자 정보를 구비하는 제1 이용자 정보 테이블을 참조하여 상기 제1 조건을 충족하는 후보 이용자를 특정하고, 상기 종별 정보에 관련지어서 친구 관계가 되는 이용자 정보의 조를 구비하는 제1 친구 관계 테이블을 참조하여 상기 제2 조건을 충족하는 후보 이용자를 특정하는 것이 바람직하다.
본 발명에서는, 제1 이용자 정보 테이블과 제1 친구 관계 테이블은, 관리 서버의 기억부에 구비해도 되고, 관리 서버와 통신 가능한 외부의 기억 장치에 구비해도 된다.
상술한 발명에 있어서, 상기 제1 이용자 정보 테이블의 내용과, 상기 애플리케이션 서버가 제공하는 애플리케이션을 이용하는 이용자를 나타내는 이용자 정보를 구비하는 제2 이용자 정보 테이블의 내용을 동기시키는 이용자 정보 동기부와, 상기 제1 친구 관계 테이블의 내용과, 상기 애플리케이션 서버가 제공하는 애플리케이션에 대해서, 친구 관계가 되는 이용자 정보의 조를 구비하는 제2 친구 관계 테이블의 내용을 동기시키는 친구 관계 동기부를 구비한다.
본 발명에서, 동기의 타이밍은 임의이다. 예를 들어, 애플리케이션 서버에서 이용자 정보가 변경된 경우나, 승인에 의해 친구 관계가 구축된 경우에는, 즉시 동기를 행해도 된다. 또는, 소정의 시각에 일괄적으로 동기시켜도 된다. 제2 이용자 정보 테이블과 제2 친구 관계 테이블은, 복수의 애플리케이션 서버의 일부 또는 모두에 구비하도록 해도 되고, 관리 서버 및 복수의 애플리케이션 서버의 일부 또는 모두와 통신 가능한 외부의 기억 장치에 구비하도록 해도 된다.
상술한 관리 서버에 있어서, 상기 제1 친구 관계 테이블이 구비하는 상기 이용자 정보의 조는, 친구 신청을 행한 이용자의 이용자 정보와, 친구 신청을 승낙한 이용자의 이용자 정보를 포함하는 것이 바람직하다.
또한, 상기 특정부는, 상기 제1 친구 관계 테이블을 참조하여, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에 대응하는 종별 정보와 관련지어서 구비되어 있는 상기 이용자 정보의 조 중, 친구 신청을 행한 이용자의 이용자 정보가 상기 요구 이용자의 이용 정보와 일치하는 친구 신청을 수락한 이용자의 이용자 정보를 추출함과 함께, 친구 신청을 수락한 이용자의 이용자 정보가 상기 요구 이용자의 이용 정보와 일치하는 친구 신청을 행한 이용자의 이용자 정보를 추출하고, 추출한 이용자 정보의 이용자를, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자로 하는 것이 바람직하다.
상술한 관리 서버에 있어서, 상기 접수부에서 접수한 종별 정보에 대응하는 상기 애플리케이션 서버에서 설정된 이용자의 친구 상한수를 취득하는 취득부를 구비하고, 상기 특정부는, 상기 취득부가 취득한 친구 상한수를 이용자 정보와 관련지어서 구비하는 제1 친구 상한수 테이블을 참조하여 상기 제3 조건을 충족하는 후보 이용자를 특정하는 것이 바람직하다.
보다 구체적으로는, 상기 취득부는, 상기 제1 친구 상한수 테이블의 내용과, 상기 애플리케이션 서버에서 관리하는 친구 상한수와 이용자 정보를 관련지어서 구비하는 제2 친구 상한수 테이블의 내용을 동기시키는 친구 상한수 동기부를 구비하는 것이 바람직하다. 본 발명에서, 동기의 타이밍은 임의이다. 예를 들어, 애플리케이션 서버에서 친구 상한수가 변경된 경우에는, 즉시 동기를 취하는 것이 바람직하지만, 약간의 지연을 허용하는 것이라면, 소정의 시각에 일괄적으로 동기시켜도 된다. 제2 친구 상한수 테이블은, 복수의 애플리케이션 서버의 일부 또는 모두에 구비해도 되고, 관리 서버 및 복수의 애플리케이션 서버의 일부 또는 모두와 통신 가능한 외부의 기억 장치에 구비해도 된다.
상술한 관리 서버에 있어서, 상기 접수부에서 접수한 종별 정보에 대응하는 상기 애플리케이션 서버에 대하여 이용자의 친구 상한수를 문의하는 요구를 송신하고, 상기 요구에 대한 응답으로서 당해 애플리케이션 서버로부터 친구 상한수를 취득하는 취득부를 구비하고, 상기 특정부는, 상기 취득부에서 취득한 친구 상한수에 기초하여 상기 제3 조건을 충족하는 후보 이용자를 특정하는 것이 바람직하다.
상술한 관리 서버에 있어서, 상기 특정부는, 상기 애플리케이션의 이용 일시를 나타내는 일시 정보를 이용자 식별 정보와 관련지어서 구비하는 액세스 테이블을 참조하여 소정 기간 내에 애플리케이션을 이용하고 있을 것을 상기 제1 조건에 추가하여, 상기 제1 조건을 충족하는 후보 이용자를 특정하는 것이 바람직하다.
또한, 본 발명은 각종 테이블의 구조를 한정하는 것이 아니다. 예를 들어, 이용자 정보 테이블과 액세스 테이블은 동일한 테이블로 구성해도 된다. 액세스 테이블은, 관리 서버에 구비해도 되고, 관리 서버와 통신 가능한 외부의 기억 장치에 구비해도 된다.
상술한 관리 서버에 있어서, 상기 표시 제어부는, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션을 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키고, 상기 특정부는, 상기 단말 장치에서 상기 요구 이용자가 선택한 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정하는 것이 바람직하다.
본 발명에서, 이용 완료 애플리케이션은, 각 이용 완료 애플리케이션마다 표시시켜도 되고, 복수의 이용 완료 애플리케이션을 특정하여, 이들을 요구 이용자의 단말 장치에 표시시켜도 된다.
상술한 관리 서버에 있어서, 상기 특정부는, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에 대해서, 친구 신청이 가능한 인원수를 특정하고, 상기 표시 제어부는, 상기 특정부가 특정한 친구 신청이 가능한 인원수를 상기 요구 이용자의 단말 장치에 표시시키는 것이 바람직하다.
본 발명에서, 친구 신청이 가능한 인원수는, 이용 완료 애플리케이션마다 특정하여, 이용 완료 애플리케이션마다 요구 이용자의 단말 장치에 표시시켜도 되고, 복수의 이용 완료 애플리케이션의 합계의 친구 신청이 가능한 인원수를 특정하여, 이것을 요구 이용자의 단말 장치에 표시시켜도 된다.
상술한 발명은, 관리 서버의 컴퓨터에 사용되는 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체로서 파악할 수 있다. 이 경우, 본 발명에 따른 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체는, 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말 장치와 통신 가능한 관리 서버의 컴퓨터에 사용되고, 상기 프로그램은, 상기 컴퓨터를, 친구의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보를 접수하는 접수부와, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있을 것을 제1 조건, 당해 애플리케이션에 대하여 상기 요구 이용자와 친구 관계가 구축되어 있지 않을 것을 제2 조건, 당해 애플리케이션에서 친구 상한수에 달하지 않았을 것을 제3 조건으로 했을 때, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정하는 특정부와, 상기 특정부에서 특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부와, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션에 대응한 애플리케이션 서버에 대하여 상기 요구 이용자가 상기 후보 이용자 중에서 선택한 이용자에 대하여 친구 신청을 요구하는 지시를 행하는 지시부로서 기능시키는 것을 특징으로 한다.
상술한 발명은, 관리 서버의 제어 방법으로서도 파악할 수 있다. 이 경우, 본 발명에 따른 관리 서버의 제어 방법은, 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말 장치와 통신 가능한 관리 서버를 제어하는 방법이며, 친구의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보를 접수하고, 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있을 것을 제1 조건, 당해 애플리케이션에 대하여 상기 요구 이용자와 친구 관계가 구축되어 있지 않을 것을 제2 조건, 당해 애플리케이션에서 친구 상한수에 달하지 않았을 것을 제3 조건으로 했을 때, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정하고, 특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키고, 접수한 종별 정보가 나타내는 애플리케이션에 대응한 애플리케이션 서버에 대하여 상기 요구 이용자가 상기 후보 이용자 중에서 선택한 이용자에 대하여 친구 신청을 요구하는 것을 특징으로 한다.
상술한 발명은, 단말 장치의 컴퓨터에 사용되는 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체로서 파악할 수 있다. 이 경우, 본 발명에 따른 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체는, 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버와 접속된 관리 서버와 통신 가능한 이용자의 단말 장치의 컴퓨터에 사용되는 프로그램이며, 상기 복수의 애플리케이션 서버의 각각은, 친구의 상한수를 이용자마다 관리하고 있고, 상기 관리 서버는, 친구의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보를 접수하는 접수부와, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있을 것을 제1 조건, 당해 애플리케이션에 대하여 상기 요구 이용자와 친구 관계가 구축되어 있지 않을 것을 제2 조건, 당해 애플리케이션에서 친구 상한수에 달하지 않았을 것을 제3 조건으로 했을 때, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정하는 특정부와, 상기 특정부에서 특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부와, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션에 대응한 애플리케이션 서버에 대하여 상기 요구 이용자가 상기 후보 이용자 중에서 선택한 이용자에 대하여 친구 신청을 요구하는 지시를 행하는 지시부를 구비하고, 상기 프로그램은, 상기 단말 장치의 컴퓨터를, 당해 단말 장치의 이용자의 친구 상한수가 변화한 것을 검출하는 검출부와, 상기 검출부에 의해 상기 친구 상한수가 변화한 것이 검출되면, 변화한 후의 친구 상한수를 상기 관리 서버에 통지하는 통지부로서 기능시키는 것을 특징으로 한다.
도 1은 본 발명의 실시 형태에 따른 애플리케이션 시스템의 블록도이다.
도 2는 관리 서버의 구성을 도시하는 블록도이다.
도 3은 이용자 정보 테이블의 데이터 구조의 일례를 나타내는 설명도이다.
도 4는 친구 상한수 테이블의 데이터 구조의 일례를 나타내는 설명도이다.
도 5는 관계 테이블의 데이터 구조의 일례를 나타내는 설명도이다.
도 6은 인바이트 테이블의 데이터 구조의 일례를 나타내는 설명도이다.
도 7은 단말 장치의 구성을 도시하는 블록도이다.
도 8은 공통 처리에 관한 애플리케이션 시스템의 동작 시퀀스를 나타내는 시퀀스도이다.
도 9는 마이 페이지의 메뉴에서 「친구를 초대하기」를 선택한 경우에 표시되는 화면의 일례이다.
도 10은 친구 처리의 처리 내용을 나타내는 흐름도이다.
도 11은 친구 처리의 처리 내용을 나타내는 흐름도이다.
도 12는 친구 찾기 페이지의 일례를 나타내는 설명도이다.
도 13은 상세 페이지의 일례를 나타내는 설명도이다.
도 14는 친구 신청 처리에 관한 애플리케이션 시스템의 동작 시퀀스를 나타내는 시퀀스도이다.
도 15는 초대 처리에 관한 애플리케이션 시스템의 동작 시퀀스를 나타내는 시퀀스도이다.
도 16은 초대용 상세 페이지의 일례를 나타내는 설명도이다.
도 17은 랭킹 처리에 관한 애플리케이션 시스템의 동작 시퀀스를 나타내는 시퀀스도이다.
도 18은 랭킹 처리의 내용을 나타내는 흐름도이다.
도 19는 랭킹 페이지의 일례를 나타내는 설명도이다.
도 20은 친구수 처리에 관한 애플리케이션 시스템의 동작 시퀀스를 나타내는 시퀀스도이다.
도 21은 친구수 처리의 내용을 나타내는 흐름도이다.
도 22는 친구수 페이지의 일례를 나타내는 설명도이다.
도 23은 랭킹 처리의 내용을 나타내는 흐름도이다.
도 24는 변형예에 따른 친구 처리의 처리 내용을 나타내는 흐름도이다.
도 25는 변형예에 따른 랭킹 처리의 내용을 나타내는 흐름도이다.
도 26은 변형예에 따른 친구수 처리의 내용을 나타내는 흐름도이다.
도 27은 변형예에서의 관리 서버의 기능을 도시하는 블록도이다.
도 28은 변형예에서의 공통 처리에 관한 애플리케이션 시스템의 동작 시퀀스를 나타내는 시퀀스도이다.
도 29는 변형예에 따른 친구 처리의 처리 내용을 나타내는 흐름도이다.
도 30은 변형예에 따른 친구 처리의 처리 내용을 나타내는 흐름도이다.
도 31은 변형예에 따른 단말 장치의 구성을 도시하는 블록도이다.
도 32는 변형예에 따른 애플리케이션 서버의 구성을 도시하는 블록도이다.
도 33은 변형예에 따른 친구 상한수 통지 처리의 처리 내용을 나타내는 흐름도이다.
도 34는 변형예에서의 관리 서버의 기능을 도시하는 블록도이다.
도 35는 변형예에서의 처리 내용을 나타내는 흐름도이다.
도 36은 변형예에서의 처리 내용을 나타내는 흐름도이다.
도 37은 변형예에서의 관리 서버의 기능을 도시하는 블록도이다.
도 38은 변형예에서의 처리 내용을 나타내는 흐름도이다.
도 39는 변형예에서의 랭킹 처리의 내용을 나타내는 흐름도이다.
도 40은 변형예에서의 랭킹 처리의 내용을 나타내는 흐름도이다.
도 41은 변형예에서의 랭킹 페이지의 일례를 나타내는 설명도이다.
도 42는 변형예에 따른 애플리케이션 시스템의 블록도이다.
도 43은 제2 이용자 정보 테이블의 데이터 구조의 일례를 나타내는 설명도이다.
도 44는 제2 친구 상한수 테이블의 데이터 구조의 일례를 나타내는 설명도이다.
도 45는 제2 관계 테이블의 데이터 구조의 일례를 나타내는 설명도이다.
도 46은 변형예에 따른 애플리케이션 시스템의 블록도이다.
도 47은 변형예에 따른 애플리케이션 시스템의 블록도이다.
이하, 실시 형태로서, 본 발명에 따른 관리 서버를 사용한 애플리케이션 시스템에 대해서, 도면을 참조하면서 설명한다.
<1. 애플리케이션 시스템의 구성>
도 1은, 본 발명의 실시 형태에 따른 애플리케이션 시스템(100)의 블록도이다. 이 애플리케이션 시스템(100)은, 인터넷 등의 통신망(1), 이용자의 단말 장치(2), 관리 서버(3A), 애플리케이션 서버(3B, 3C, 3D…)를 구비한다. 애플리케이션 서버(3B, 3C, 3D…)는, 이용자끼리의 커뮤니케이션을 가능하게 하는 SNS 사이트를 각 이용자에 대하여 제공함과 함께, 각종 서비스를 이용자에게 제공한다. 이용자끼리의 커뮤니케이션이란, 이용자의 사이에서 메시지의 교환을 행하는 것을 말한다. 메시지의 교환은, 예를 들어 게시판, 메일, 채팅 등을 사용하여 행하여진다. 이 예에서는, 애플리케이션 서버(3B, 3C, 3D…)가 제공하는 서비스는 게임 b, 게임 c, 게임 d… 이다. 각 애플리케이션 서버(3B, 3C, 3D…)의 이용자는, 동일한 게임(애플리케이션)의 이용자와 친구 관계를 구축하여, 친구끼리 인사나 코멘트 등의 커뮤니케이션을 행함으로써 게임상에서 교환 가치가 있는 포인트를 획득할 수 있다. 또한, 게임상에서의 전투에서는, 친구의 응원을 얻을 수 있는 등, 친구의 수가 많을수록 게임이 유리하게 진행된다.
친구 관계는, 신청원의 이용자가 친구 신청을 행하고, 이것을 신청처의 이용자가 승인함으로써 구축된다. 뿐만 아니라, 애플리케이션 시스템(100)에서는, 어떤 게임을 플레이하고 있는 이용자가, 당해 게임을 플레이하고 있지 않은 다른 이용자를 당해 게임에 초대할 수 있도록 되어 있다.
또한, 관리 서버(3A)는, 이용자끼리의 커뮤니케이션을 가능하게 하는 SNS 사이트를 각 이용자에 대하여 제공함과 함께, 포털 사이트로서도 기능한다. 즉, 관리 서버(3A)는, 각 애플리케이션 서버(3B, 3C, …)에서 구축된 친구 관계를 일원적으로 관리하고 있다.
이용자의 단말 장치(2)는, 통신망(1)을 통한 통신이 가능하며, 예를 들어 퍼스널 컴퓨터나 휴대 전화기가 해당된다. 애플리케이션 시스템(100)은, 이용자에 대하여 이용자끼리의 커뮤니티 기능이나 게임 또는 서비스 및 상품의 판매를 제공하는 것이 가능하다.
도 2에 관리 서버의 구성을 나타낸다. 이 도에 도시한 바와 같이, 관리 서버(3A)는, 장치 전체를 제어하는 CPU(Central Processing Unit)(30), CPU(30)의 작업 영역으로서 기능하는 RAM(Random Access Memory)(31), 부트 프로그램 등을 기억한 ROM(Read Only Memory)(32), 각종 프로그램이나 데이터를 기억하는 하드 디스크(33), 키보드나 마우스 등을 포함하는 입력부(34), 화상을 표시하는 디스플레이(35), 통신망(1)을 통해 외부의 장치와 통신을 행하는 통신 인터페이스(36) 및 콤팩트 디스크 등의 정보 기록 매체를 판독하는 판독 장치(37)를 구비한다.
하드 디스크(33)에는, 이용자 정보 테이블(TBL11), 친구 상한수 테이블(TBL12), 관계 테이블(TBL13), 인바이트 테이블(TBL14), 애플리케이션 정보 테이블(TBL15) 및 ID 관리 테이블(TBL16) 등이 기억되어 있다.
도 3에 이용자 정보 테이블(TBL11)의 데이터 구조를 나타낸다. 이용자 정보 테이블(TBL11)에는 복수의 레코드가 기록되어 있다. 1개의 레코드는, 레코드를 일의적으로 식별하는 레코드 식별 정보(ID), 애플리케이션의 종별을 나타내는 종별 정보(AppID), 이용자를 일의적으로 식별하는 참조 식별 정보(RefID), 애플리케이션과 이용자를 일의적으로 식별하는 이용자 식별 정보(UID) 및 마지막으로 로그인한 일자를 나타내는 라스트 로그인 정보(LastLogin)를 구비한다.
참조 식별 정보(RefID)는, 이용자에게 알리지 않고, 시스템의 내부에서 사용된다. 참조 식별 정보(RefID)는, ID 관리 테이블(TBL16)에서, 이용자에게 기지인 로그인 식별 정보(UserID)와 참조 식별 정보(RefID)가 대응지어져서 관리되고 있다. 참조 식별 정보(RefID)는, 이용자가 동일하면, 애플리케이션의 종별이 상이해도 동일하지만, 이용자 식별 정보(UID)는, 애플리케이션마다 상이하다. 즉, 이용자 식별 정보(UID)의 기능은, 종별 정보(AppID)의 기능과 참조 식별 정보(RefID)의 기능을 조합한 것에 상당한다. 단, 이용자 식별 정보(UID)만으로부터 애플리케이션의 종별을 특정할 수 있을 필요는 없다.
예를 들어, ID=1, 2, 3의 각 레코드에는 참조 식별 정보(RefID)가 「00000011」인 동일한 이용자가 할당되어 있고, ID=1, 2, 3의 각 레코드는, 종별 정보(AppID)가 상이하고, 이용자 식별 정보(UID)도 상이하다.
또한, 로그인 식별 정보(UserID)와 참조 식별 정보(RefID)의 대응짓기를 ID 관리 테이블(TBL16)에서 관리함으로써, 예를 들어 로그인 식별 정보(UserID)를 제3자에게 도둑맞았을 경우에는, 새로운 로그인 식별 정보(UserID)를 발행하고, 이것을 참조 식별 정보(RefID)와 연결시키면 된다. 즉, ID 관리 테이블을 갱신하기만 할 뿐, 다른 테이블에는 영향을 주지 않는다.
도 4에 친구 상한수 테이블(TBL12)의 데이터 구조를 나타낸다. 친구 상한수 테이블(TBL12)에는 복수의 레코드가 기록되어 있다. 1개의 레코드는, 레코드 식별 정보(ID), 이용자 식별 정보(UID) 및 친구 상한수(Limit)가 대응지어져서 기억된다. 상술한 바와 같이, 각 애플리케이션 서버(3B, 3C, 3D, …)는, 애플리케이션으로서 게임을 제공하지만, 게임마다 친구의 상한수가 정해져 있고, 또한, 이용자의 레벨에 따라서 상한수가 변동된다. 각 애플리케이션 서버(3B, 3C, 3D, …)는, 이용자의 친구 상한수가 변화하면, 이용자 식별 정보(UID)와 친구 상한수(Limit)의 조합을 관리 서버(3A)에 친구 상한수 통지를 송신하도록 되어 있다. 관리 서버(3A)는, 친구 상한수 통지를 수신하면, 친구 상한수 테이블(TBL12)의 내용을 갱신한다. 이에 의해, 관리 서버(3A)는, 각 이용자의 친구 상한수(Limit)를 일원적으로 관리할 수 있다.
도 5에 관계 테이블(TBL13)의 데이터 구조를 나타낸다. 관계 테이블(TBL13)에는 복수의 레코드가 기록되어 있다. 1개의 레코드는, 레코드 식별 정보(ID), 종별 정보(AppID), 관계의 종별을 나타내는 그룹 정보(Group), 신청원의 이용자의 참조 식별 정보(RefID)인 신청원 참조 식별 정보(RefID_From), 신청처의 이용자의 참조 식별 정보(RefID)인 신청처 참조 식별 정보(RefID_To), 신청원의 이용자의 이용자 식별 정보(UID)인 신청원 이용자 식별 정보(UID_From), 신청처의 이용자의 이용자 식별 정보(UID)인 신청처 이용자 식별 정보(UID_To) 및 신청의 상태를 나타내는 상태 정보(Stat)가 대응지어져서 기억된다.
친구 관계를 기억하는 경우에, 신청원과 신청처를 나누어서 기억한 것은, 기억 용량을 삭감하는 이점이 있다. 가령, 어떤 이용자 식별 정보(UID)와 당해 이용자와 친구 관계에 있는 모든 이용자의 이용자 식별 정보(UID)를 대응지어서 기억했다고 하면, 2배의 기억 용량이 필요해진다. 예를 들어, 이용자 A가 신청원이며 이용자 B가 신청처라고 하자. 각 이용자마다 친구 관계에 있는 이용자의 이용자 식별 정보를 기억하는 경우에는, 이용자 A에 대하여 이용자 B가 친구 관계에 있는 것을 기억하고, 또한, 이용자 B에 대하여 이용자 A가 친구 관계에 있는 것을 기억할 필요가 있다. 이에 반해, 본 실시 형태에서는, 신청처의 이용자 식별 정보와 신청원의 이용자 식별 정보를 대응지어서 1개의 레코드에 기억하므로 기억 용량을 절반으로 할 수 있다. 또한, 상태 정보(Stat)를 갱신하는 경우에도 절반의 처리가 된다.
어떤 이용자와 다른 이용자의 관계에는, 친구 관계, 라이벌 관계 및 블록 관계가 있다. 친구 관계는, 어떤 이용자로부터 친구 신청이 있음이 다른 이용자에게 전달되어, 다른 이용자가 승낙함으로써 성립한다. 라이벌 관계는, 어떤 이용자가 라이벌로 생각하는 다른 이용자를 신청함으로써 성립하며, 다른 이용자의 승낙을 필요로 하지 않는 관계이다. 예를 들어, 동일한 게임을 플레이하고 있고, 신경이 쓰이는 다른 이용자를 라이벌로서 등록하는 경우에 사용된다. 블록 관계는, 라이벌 관계와 마찬가지로 막고 싶은 다른 이용자를 신청함으로써 성립하며, 다른 이용자의 승낙을 필요로 하지 않는 관계이다. 거부했음에도 불구하고 친구 신청이 자주 있거나, 게시판에서의 발언 등으로 폐를 끼치고 있는 다른 이용자를 등록하는 경우에 사용된다.
그룹 정보(Group)는, 레코드가 친구 관계를 나타내는 경우에 「Friends」, 레코드가 라이벌 관계를 나타내는 경우에 「Rival」, 레코드가 블록 관계를 나타내는 경우에 「Block」을 기록한다. 또한, 상태 정보(Stat)는, 친구 신청중으로 「0」, 승인 완료로 「1」, 거부 완료로 「2」를 기록한다. 또한, 라이벌 관계와 블록 관계는, 신청만으로 성립하기 때문에, 상태 정보(Stat)는 기록할 필요가 없으므로, 「null」로 설정하고 있다. 또한, 라이벌 관계 및 블록 관계에서는 상태 정보(Stat)를 일률적으로 「0」으로 해도 된다.
예를 들어, ID=1의 레코드는, 종별 정보(AppID)가 「00000001」인 게임에 있어서, 참조 식별 정보(RefID)가 「00000011」인 이용자로부터 참조 식별 정보(RefID)가 「00003120」인 이용자에 대하여 친구 신청해서 승인된 것을 나타내고 있다. 참조 식별 정보(RefID)가 「00000011」인 이용자가 친구 신청을 행한 타이밍에서 ID=1의 레코드가 생성되고, 상태 정보(Stat)가 「0」으로 세트된다. 이 후, 참조 식별 정보(RefID)가 「00003120」인 이용자가 친구 신청을 수령하고, 승인 또는 거부한 타이밍에서, 상태 정보(Stat)가 승인 「1」 또는 거부 「2」로 갱신된다.
관계 테이블(TBL13)을 참조하여, 종별 정보(AppID)를 특정한 게임에 한정하면, 그 게임에서의 이용자의 친구 관계를 파악할 수 있다. 상태 정보(Stat)로부터, 이미 친구 관계에 있는 상대나, 친구 신청중인 친구를 파악할 수 있다.
또한, 친구 관계가 구축된 후에 친구 관계가 해제된 경우에는, 그 레코드를 삭제한다. 또한, 레코드를 삭제하지 않고, 레코드의 유효/무효를 나타내는 항목을 새롭게 추가하여, 친구 관계가 해제된 레코드를 무효로 하도록 해도 된다. 친구 관계를 해제한 상대와 친구 관계를 다시 구축하는 경우에는 새로운 레코드를 작성하면 된다.
도 6에 초대의 이력을 관리하는 인바이트 테이블(TBL14)의 데이터 구조를 나타낸다. 인바이트 테이블(TBL14)의 1개의 레코드는, 레코드 식별 정보(ID), 종별 정보(AppID), 초대원의 이용자의 참조 식별 정보(RefID)인 신청원 참조 식별 정보(RefID_From), 초대처의 이용자의 참조 식별 정보(RefID)인 신청처 참조 식별 정보(RefID_To), 초대의 연월일을 나타내는 일시 정보(Date) 및 초대의 상태를 나타내는 상태 정보(Stat)가 대응지어져서 기억된다. 상태 정보(Stat)가 「0」인 경우에는 초대를 신청중인 것을 나타내고, 상태 정보(Stat)가 「1」인 경우에는 초대를 승인 또는 거부한 것을 나타낸다.
인바이트 테이블(TBL14)을 참조함으로써, 누가 누구에게 어느 게임에 초대했는지를 알 수 있다. 예를 들어, 예를 들어 ID=1의 레코드는, 종별 정보(AppID)가 「00000001」인 게임에 있어서, 참조 식별 정보(RefID)가 「00000011」인 이용자가 참조 식별 정보(RefID)가 「00003120」인 이용자를 초대하여 승인 또는 거부된 것을 나타내고 있다. 참조 식별 정보(RefID)가 「00000011」의 이용자가 초대를 행한 타이밍에서 ID=1의 레코드가 생성되고, 상태 정보(Stat)가 「0」으로 세트된다. 이 후, 참조 식별 정보(RefID)가 「00003120」인 이용자가 초대를 수령하고, 승인 또는 거부한 타이밍에서, 상태 정보(Stat)가 「1」로 갱신된다.
상태 정보(Stat)가 「1」인 경우에는 초대가 승인 또는 거부되었고, 이 경우, 관리 서버(3A)는, 승인 또는 거부된 상대에게는 다시 초대할 수 없도록 제어하고 있다. 또한, CPU(30)는, 초대 연월일을 나타내는 일시 정보(Date)에 기초하여, 초대하고 나서 소정 기간을 초과하여, 초대 신청중이 계속된 경우에는, 강제적으로 상태 정보(Stat)를 거부 「1」로 재기입한다. 또한, 레코드의 유효/무효를 나타내는 항목을 새롭게 추가하여, 소정 기간이 지난 경우에 레코드를 무효로 하도록 해도 된다.
이어서, 도 2에 도시하는 애플리케이션 정보 테이블(TBL15)의 1개의 레코드는, 레코드 식별 정보(ID), 종별 정보(AppID), 애플리케이션명(게임명)을 나타내는 애플리케이션명 정보, 애플리케이션(게임)의 내용을 나타내는 설명 정보 및 애플리케이션에 대응하는 아이콘을 나타내는 아이콘 정보가 대응지어져서 기억되어 있다.
관리 서버(3A)의 CPU(30)는, 소정의 제어 프로그램을 실행함으로써, 도 1에 도시하는 접수부(11), 특정부(12), 지시부(13), 표시 제어부(14), 정보 취득부(15) 및 통지부(16)로서 기능한다.
접수부(11)는, 친구의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치(2)를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보(AppID)를 접수한다. 여기서, 종별 정보(AppID)는, 단말 장치(2)로부터 제공되어도 되고, 또는, 애플리케이션 서버(3B, 3C, 3D…)로부터 제공되어도 된다.
친구 신청에 있어서, 특정부(12)는, 접수부(11)에서 접수한 종별 정보(AppID)가 나타내는 애플리케이션을 이용하고 있을 것을 제1 조건, 당해 애플리케이션에 대하여 상기 요구 이용자와 친구 관계가 구축되어 있지 않을 것을 제2 조건, 당해 애플리케이션에서 친구 상한수에 달하지 않았을 것을 제3 조건으로 했을 때, 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션 중 친구에게 초대하려고 하는 애플리케이션 이외에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정한다. 즉, 친구 신청에서는, 친구에게 초대하려고 하는 게임 이외에서 요구 이용자와 친구 관계가 구축되어 있는 다른 이용자인 것을 전제로 하여, 친구에게 초대하려고 하는 게임을 대상으로 해서 친구 신청을 행하는 것이기 때문에, 당해 게임을 이미 이용하고 있을 필요가 있다(제1 조건). 또한. 이것으로부터 친구가 되도록 초대하는 것이기 때문에, 아직 친구 관계가 아닌 것은 당연하다(제2 조건). 또한, 친구 상한수를 고려할 필요가 있다(제3 조건).
한편, 초대에 있어서, 특정부(12)는, 접수부(11)에서 접수한 종별 정보(AppID)가 나타내는 애플리케이션을 이용하고 있지 않을 것을 조건으로 했을 때, 상기 조건을 충족하는 후보 이용자의 일부 또는 모두를 특정한다.
표시 제어부(14)는, 특정부(12)에서 특정한 일부 또는 모든 후보 이용자를 선택할 수 있도록 요구 이용자의 단말 장치(2)에 표시시킨다. 보다 구체적으로는, 후보 이용자를 선택 가능한 페이지를 생성한다(후술하는 도 13 참조). 여기서, 특정부(12)에서 특정한 일부의 후보 이용자를 선택할 수 있도록 한다는 것은, 모든 후보 이용자 중, 소정 개수 단위로 페이지를 전환하여, 순서대로 후보 이용자를 요구 이용자에게 선택 가능하게 하는 형태나, 모든 후보 이용자 중에서 랜덤 또는 소정의 규칙에 따라서 추출된 후보 이용자를 요구 이용자에게 선택 가능하게 하는 형태가 포함된다. 또한, 하기 정보 취득부(15)에 의해 취득한 애플리케이션에 관한 이용 정보를 요구 이용자의 단말 장치(2)에 표시시킨다.
지시부(13)는, 접수부(11)에서 접수한 종별 정보(AppID)가 나타내는 애플리케이션에 대응한 애플리케이션 서버(3B, 3C, 3D, …)에 대하여 요구 이용자가 후보 이용자 중에서 선택한 이용자에 대하여 친구 신청을 요구하는 지시를 행한다. 이에 의해, 친구 신청된 이용자는 애플리케이션 서버(3B, 3C, 3D, …)에 액세스했을 때에, 친구 신청이 이루어져 있음을 알게 된다. 즉, 친구 신청된 이용자는, 자신의 마이 페이지 등에서 친구 신청이 되어 있음을 알게 된다.
정보 취득부(15)는, 후술하는 문의 처리에 있어서, 접수부(11)에서 접수한 소정의 친구에게 인기가 있는 소정의 애플리케이션에 관한 이용 정보를 취득한다. 상세하게는 후술한다.
통지부(16)는, 단말 장치(2)에 표시된 후보 이용자 중에서 선택한 후보 이용자에 대하여 초대 신청을 통지한다. 상세하게는 후술한다.
도 7에 단말 장치(2)의 구성을 나타낸다. 단말 장치(2)는, 장치 전체를 제어하는 CPU(20), CPU(20)의 작업 영역으로서 기능하는 RAM(21), 부트 프로그램 등을 기억한 ROM(22), 각종 프로그램이나 데이터를 기억하는 기억 장치(23), 텐 키 등을 포함하는 입력부(24), 화상을 표시하는 디스플레이(25) 및 통신망(1)을 통해 외부의 장치와 통신을 행하는 통신 인터페이스(26)를 구비한다.
<2. 애플리케이션 시스템의 동작>
애플리케이션 시스템(100)에서는, 어떤 이용자가 플레이하고 있는 게임에 당해 게임을 플레이하고 있지 않은 다른 이용자를 초대하거나, 또는 당해 게임을 플레이하고 있는 다른 이용자(다른 게임에서의 친구를 포함함)에 대하여 친구 신청을 행할 수 있다. 또한, 이용자는 자신이 플레이하고 있는 복수의 게임에서의 친구에게 인기가 많은 게임이나 각 게임을 플레이하고 있는 친구수 등을 문의할 수 있다. 이하, 초대와 친구 신청에 공통인 공통 처리, 친구 신청에 관한 친구 신청 처리, 초대에 관한 초대 처리 및 각종 문의에 관한 문의 처리에 대하여 설명한다.
<2-1: 공통 처리>
도 8에 공통 처리에 관한 애플리케이션 시스템의 동작 시퀀스를 나타낸다. 단말 장치(2)의 이용자가, 웹브라우저 상에서 동작하거나, 단말 장치(2)에 인스톨되어 동작하는 애플리케이션을 기동하여, 애플리케이션의 로그인 페이지에 액세스하면, 단말 장치(2)의 디스플레이(25)에는, 로그인 화면이 표시된다. 이 로그인 화면에는, 로그인 식별 정보(UserID)와 패스워드(PSW)를 입력하는 입력 박스가 표시된다. 이용자가, 입력 박스에 입력하여 송신 버튼을 누르면, 단말 장치(2)의 CPU(20)는, 입력한 로그인 식별 정보(UserID) 및 패스워드를 포함하는 로그인 요구를 관리 서버(3A)에 송신한다.
로그인 요구를 관리 서버(3A)의 CPU(30)가 수신하면, 관리 서버(3A)의 CPU(30)는 인증 처리를 실행한다(S1). 구체적으로는, CPU(30)는, 로그인 식별 정보(UserID)와 패스워드의 조합이 기억되어 있는지 여부를 판정하고, 판정 조건을 충족하는 경우에는 로그인을 허가하고, 판정 조건이 충족되지 않은 경우에는 로그인을 거절한다. 그리고, CPU(30)는, 판정 결과를 나타내는 로그인 응답을 단말 장치(2)에 송신한다. 또한, 도 8에 나타내는 예에서는, 로그인이 허가된 것으로 한다. 한번, 단말 장치(2)에서 입력된 로그인 식별 정보(UserID)와 패스워드의 조합은, 단말 장치(2)에 소정 기간 기억되어, 당해 소정 기간 내이면 로그인을 생략 가능하게 해도 된다.
이 후, 이용자가 메뉴를 선택하여 게임 b를 선택했다고 하자(S2). 이 경우, 단말 장치(2)의 CPU(20)는, 게임 b의 마이 페이지 열람 요구를 관리 서버(3A)에 송신한다.
관리 서버(3A)의 CPU(30)는, 마이 페이지 열람 요구를 수신하면, ID 관리 테이블(TBL16)을 참조하여, 로그인 식별 정보(UserID)에 대응한 참조 식별 정보(RefID)를 취득하고, 또한 이용자 정보 테이블(TBL11)을 참조하여, 참조 식별 정보(RefID) 및 게임 b의 종별 정보(AppID)에 대응하는 이용자 식별 정보(UID)를 취득한다(S3).
이 후, 관리 서버(3A)의 CPU(30)가, 이용자 식별 정보(UID)를 포함하는 마이 페이지 열람 요구를 게임 b를 제공하는 애플리케이션 서버(3B)에 송신하면, 애플리케이션 서버(3B)는, 이용자 식별 정보(UID)에 대응하는 게임 b의 마이 페이지를 생성하고, 이것을 페이지 열람 응답으로서, 관리 서버(3A)를 통해 단말 장치(2)에 송신한다.
또한, 스텝 S3에서 취득한 이용자 식별 정보(UID)를 단말 장치(2)에 통지하고, 그 이후, 관리 서버(3A)를 통하지 않고, 단말 장치(2)와 애플리케이션 서버(3B)와의 사이에서 통신을 행하게 하도록 해도 된다.
단말 장치(2)의 CPU(20)는, 마이 페이지 열람 응답을 수신하면, 디스플레이(25)에 게임 b의 마이 페이지를 표시한다(S5). 이용자가 마이 페이지의 메뉴에서 「친구를 초대하기」를 선택하면, 예를 들어 도 9에 나타내는 화면이 표시된다. 이 화면에서, 이용자가 「알아서 신청」의 버튼(112)을 클릭하면, 애플리케이션 서버(3B)는, 당해 이용자와 친구 관계가 구축되어 있지 않은 다른 이용자를 추출하고, 추출한 이용자의 리스트의 페이지를 생성하여 단말 장치(2)에 통지한다. 이용자는, 리스트 중에서 친구가 되고 싶은 이용자를 선택한다. 관리 서버(3A)의 CPU(30)는, 이용자에 의해 선택된 이용자에게 친구 신청이 있음을 당해 이용자의 마이 페이지에 표시하는 것 등으로 전달한다. 또한, 이용자의 현재의 친구수가 게임 b에서의 친구 상한수에 달한 경우에는, 「알아서 신청」의 버튼(112)을 조작할 수 없도록 무효화되어 있거나, 버튼(112)이 표시되지 않도록 되어 있다.
한편, 이 화면에서, 이용자가 버튼(111)을 클릭하여 「다른 게임에서 찾기」를 선택하면, 관리 서버(3A)의 친구 페이지로 이행한다. 즉, 버튼(111)은 SNS 사이트의 친구 페이지에의 링크가 정의된 것이다. 또한, 이 링크의 정의에는, 게임 b를 나타내는 종별 정보(AppID)와 이용자를 나타내는 이용자 식별 정보(UID)가 포함된다. 관리 서버(3A)의 CPU(30)가 친구 페이지로의 액세스 요구를 수신하면, 관리 서버(3A)의 CPU(30)는 친구 처리를 실행하고(S7), 액세스 응답을 답신한다.
이어서, 친구 처리의 처리 내용을 도 10 및 도 11을 참조하여 설명한다. 이하의 설명에서는, 「다른 게임에서 찾기」를 선택한 이용자를 이용자 A라 칭하여, 이용자 A에 관한 정보에는 「a」를 첨자로서 부가하고, 다른 이용자의 정보에는 「*」를 첨자로서 부가한다. 또한, 종별 정보(AppID)는, 이용자 A와 다른 이용자에게 공통의 정보이며, 게임마다 일의적으로 정해지는 정보이므로, 「x」를 첨자로서 부가한다. 또한, 이용자 식별 정보(UID)는, 게임마다 부여되는 정보이며, 동일한 이용자라도 게임이 상이하면 이용자 식별 정보(UID)도 상이하다. 따라서, 이용자 A의 이용자 식별 정보(UID)에는 「ax」를 첨자로서 부가하고, 다른 이용자의 이용자 식별 정보(UID)에는 「*x」를 첨자로서 부가한다.
먼저, CPU(30)는, 수신한 액세스 요구에 포함되는 이용자 식별 정보(UIDax)와, 다른 이용자를 초대하는 게임의 종별 정보(AppIDx)를 취득한다(S100). 여기서, 취득한 종별 정보(AppIDx)는 「00000001」이며 「게임 b」를 나타내고 있고, 친구 신청이나 초대의 대상이 되는 게임이다. 또한, 취득한 이용자 식별 정보(UIDax)는 「XCV56714」로 한다.
이어서, CPU(30)는, 이용자 A 자신이 친구 상한수에 달하였는지 여부의 판단을 행하는 처리(S101 내지 S104)를 행한다. 먼저, CPU(30)는, 관계 테이블(TBL13)을 참조하여, 이용자 A의 이용자 식별 정보(UIDax)와 친구 관계(Stat=1) 또는 친구 신청중(Stat=0)에 있는 이용자의 이용자 식별 정보(UID*x)를 추출하고, 그 수를 집계한다(S101). 또한, CPU(30)는, 친구 상한수 테이블(TBL12)을 참조하여, 착안하는 이용자 A의 이용자 식별 정보(UIDax)에 대응하는 친구 상한수를 취득한다(S102).
이어서, CPU(30)는, 취득한 친구 상한수가 친구의 이용자 식별 정보(UID*x)의 집계수를 초과하는지 여부를 판정한다(S103). 이 판정 조건이 부정되는 경우에는, 이미 이용자 A에게 있어서의 친구의 이용자 식별 정보(UID*x)는 다른 이용자를 초대하는 대상이 되는 게임에 대하여 친구 상한수에 달하였으므로, 친구 신청이 불가능하게 된다. 이 경우, CPU(30)는, 친구 신청이 불가능하다는 취지의 플래그를 세트한다(S104).
이어서, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, 이용자 식별 정보(UIDax)로부터 이용자 A의 참조 식별 정보(RefIDa)를 취득한다(S105). 또한, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, 이용자 A의 참조 식별 정보(RefIDa)에 대응하는 종별 정보(AppIDx)와 이용자 식별 정보(UIDax)의 조합을 하나 또는 복수 특정한다(S106). 예를 들어, 이용자 정보 테이블(TBL11)의 기억 내용이 도 3에 도시하는 것이며, 이용자 A의 참조 식별 정보(RefIDa)가 「00000011」인 것으로 한다. 이 경우, 종별 정보(AppIDx)와 이용자 식별 정보(UIDax)의 조합은, (AppID=00000001, UID=XCV56714), (AppID=00000002, UID=YUJ85224), (AppID=00000003, UID=23150QWE)이 된다. 또한, 추출한 모든 종별 정보(AppIDx)와 이용자 식별 정보(UIDax)의 조합에는, 친구 신청이나 초대의 대상이 되는 게임에서의 조(AppID=00000001, UID=XCV56714)가 포함되어 있으므로, 이후의 처리에서는 당해 게임을 제외한 조를, 추출한 모든 종별 정보(AppIDx)와 이용자 식별 정보(UIDax)의 조합으로서 설명한다. 즉, 당해 게임에서 이미 친구로 되어 있는 이용자에 대해서는, 친구 신청이나 초대의 대상이 될 수 없기 때문이다.
이어서, CPU(30)는, 추출한 모든 종별 정보(AppIDx)와 이용자 식별 정보(UIDax)의 조합에 대하여 S108 내지 S119의 처리가 종료되었는지 여부를 판정한다(S107). S108 내지 S119의 처리가 종료된 경우에는, 친구 처리를 종료한다. 한편, 추출한 종별 정보(AppIDx)와 이용자 식별 정보(UIDax)의 조 중, S108 내지 S119의 처리가 종료되지 않은 경우에는, 미처리의 종별 정보(AppIDx)와 이용자 식별 정보(UIDax)의 조 중 1개에 착안한다.
이 후, CPU(30)는, 애플리케이션 정보 테이블(TBL15)을 참조하여, 착안하는 종별 정보(AppIDx)에 대응하는 애플리케이션명이나 아이콘 정보를 취득한다(S108). 취득한 애플리케이션명(게임명)은, 후술하는 친구 찾기 페이지의 영역(122)에 표시되고(도 12 참조), 아이콘 정보로 나타내지는 아이콘은 영역(121)에 표시된다.
이어서, CPU(30)는, 착안하는 애플리케이션에서의 친구수를 계수하는 처리(S109 내지 S110)를 행한다. 먼저, CPU(30)는, 관계 테이블(TBL13)을 참조하여, 착안하는 이용자 식별 정보(UIDax)에 대응하는 친구의 이용자 식별 정보(UID*x)를 추출한다(S109). 이에 의해, 이용자 A가 다른 이용자를 초대하려고 하는 게임 이외의 어떤 게임에서, 이용자 A와 친구 관계가 구축되어 있는 친구의 이용자 식별 정보(UID*x)가 추출된다. 보다 구체적으로는, 어떤 게임에서의 이용자 A의 이용자 식별 정보(UIDax)와 신청원 이용자 식별 정보(UID_From)가 일치하는 레코드로부터 신청처 참조 식별 정보(RefID_To)를 추출함과 함께, 이용자 식별 정보(UIDax)와 신청처 이용자 식별 정보(UID_To)가 일치하는 레코드로부터 신청원 참조 식별 정보(RefID_From)를 추출한다. 그리고, 추출한 신청처 참조 식별 정보(RefID_To)와 추출한 신청원 참조 식별 정보(RefID_From)에 대응하는 이용자 식별 정보(UID)가, 이용자 A와 친구 관계가 구축되어 있는 친구의 이용자 식별 정보(UID*x)가 된다.
이어서, CPU(30)는, 추출한 친구의 이용자 식별 정보(UID*x)의 수를 집계한다(S110). 집계된 친구의 수는, 친구 찾기 페이지에서 게임마다 표시되는 친구수로서 표시된다(후술하는 도 12의 영역(123)을 참조).
이어서, 주목하는 애플리케이션에 초대하는 것이 가능한 이용자를 특정하는 처리(S111 내지 S112)를 행한다. 먼저, CPU(30)는, 초대의 대상이 되는 게임을 플레이하고 있지 않은 이용자를 후보 이용자로 했을 때, 이용자 정보 테이블(TBL11)을 참조하여, S109에서 추출한 친구의 이용자 식별 정보(UID*x) 중에서, 초대하는 게임을 플레이하고 있지 않은 후보 이용자의 이용자 식별 정보(UID*x)를 추출한다(S111). 구체적으로는, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, S109에서 추출한 친구의 이용자 식별 정보(UID*x)에 대응하는 친구의 참조 식별 정보(RefID*)를 취득하고, 또한, 취득한 참조 식별 정보(RefID*)에 대응하는 하나 또는 복수의 종별 정보(AppIDx)를 취득한다. 그리고, 취득한 하나 또는 복수의 종별 정보(AppIDx)에 초대하는 게임의 종별 정보(AppIDx)가 포함되어 있지 않은 경우에, 초대하는 게임을 플레이하고 있지 않은 후보 이용자의 이용자 식별 정보(UID*x)와 참조 식별 정보(RefID*)를 추출한다. 이와 같이, 본 실시 형태에 따르면, 각종 게임의 종별 정보와 모든 이용자의 이용자 식별 정보(UID)를 대응짓는 이용자 정보 테이블(TBL11)을 구비하므로, 복수의 게임의 이용자를 일원적으로 관리하는 것이 가능하게 된다.
이어서, CPU(30)는, 인바이트 테이블(TBL14)을 참조하여, 이용자 A를 나타내는 참조 식별 정보(RefIDa)가 초대원, 또한 후보 이용자의 이용자 식별 정보(UID*x)에 대응하는 참조 식별 정보(RefID*)가 초대처로서 인바이트 테이블(TBL14)에 기록되어 있는 경우에는, 당해 이용자 식별 정보(UID*x)를, 후보 이용자의 이용자 식별 정보(UID*x)로부터 제외하고, 나머지 후보 이용자의 이용자 식별 정보(UID*x)를 추출하여, 집계한다(S112). 즉, 인바이트 테이블(TBL14)에는 초대중 또는 초대 완료의 초대원의 이용자와 초대처의 이용자가 조로 기록되어 있으므로, 과거에 한번이라도 초대한 적이 있는 이용자의 조로는, 다시 초대하지 않도록 하고 있다. 이에 의해, 이용자 A가 초대 가능한 다른 이용자와 그 인원수를 특정할 수 있다. 집계된 초대 가능한 친구의 수는, 친구 찾기 페이지에서 게임마다 표시된다(후술하는 도 12의 영역(124)을 참조).
이어서, CPU(30)는, 착안하는 애플리케이션에서 친구 신청이 가능한 이용자를 특정하는 처리(S113 내지 S118)를 행한다. 또한, S104의 처리에서 친구 신청이 불가능한 취지의 플래그가 세트되어 있는 경우, CPU(30)는, 당해 처리를 행하지 않고, S119로 진행한다. 먼저, CPU(30)는, 관계 테이블(TBL13)을 참조하여, 아직 친구로 되어 있지 않은 비친구의 이용자의 이용자 식별 정보(UID*x)를 추출한다(S113). CPU(30)는, 친구에게 초대하려고 하는 게임 이외에서 친구 신청을 행하는 이용자 A와 친구 관계에 있는 다른 이용자로서, 당해 게임을 이미 이용하고 있는 이용자를 추출하고(제1 조건), 또한, 관계 테이블(TBL13)을 참조하여, 당해 게임에서 이용자 A와 친구 관계가 구축되어 있지 않은 이용자(제2 조건)를 추출한다. 따라서, 본 실시 형태에 따르면, 친구 신청에 있어서 신청측과 승낙측의 조를 관계 테이블(TBL13)에 기억함으로써, 하나의 이용자 정보를 키로 해서 당해 이용자 정보와 친구 관계에 있는 모든 이용자 정보를 기억할 필요는 없으므로, 데이터의 기억 용량을 삭감하는 것이 가능하게 된다.
상술한 S105에서, 이용자 A가 이용하고 있는 게임의 종별을 나타내는 종별 정보(AppIDx)와 그들 게임의 이용자 A의 이용자 식별 정보(UIDax)가 특정되고, S106 이후에서는, 추출된 종별 정보(AppIDx)와, 당해 종별 정보(AppIDx)에 대응하는 게임을 이용하고 있는 다른 이용자의 이용자 식별 정보(UIDax)의 조의 하나에 착안하고 있다. 즉, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, 이용자 A가 이용하고 있는 게임을 이용하고 있는 다른 이용자(제1 조건)를 추출하고 있다.
또한, CPU(30)는, 상술한 제1 조건을 충족하는 다른 이용자를, S109의 추출 결과를 사용하여 특정해도 된다. 또한, CPU(30)가, 관계 테이블(TBL13)을 참조하여, 이용자 A가 친구에게 초대하려고 하는 게임에서 이용자 A와 친구 관계가 구축되어 있는 다른 이용자의 이용자 식별 정보(UID*x)를 S105의 추출 결과를 사용하여 특정해도 된다. 그리고, CPU(30)는, 제1 조건을 충족하는 다른 이용자로부터, S105의 추출 결과에서 특정되는 다른 이용자를 제외하고, 아직 친구로 되어 있지 않은 비친구의 이용자의 이용자 식별 정보(UID*x)를 추출한다.
이어서, CPU(30)는, S113에서 추출한 모든 비친구의 이용자 식별 정보(UID*x)에 대해서, S115 내지 S119의 처리가 완료했는지 여부를 판정한다(S114). 판정 조건이 충족되는 경우, CPU(30)는 처리를 S118로 진행시킨다. 한편, 판정 조건이 충족되지 않은 경우, CPU(30)는 처리를 S115로 진행시켜, 관계 테이블(TBL13)을 참조하여 착안하는 비친구의 이용자 식별 정보(UID*x)의 친구수를 집계한다. 이 경우, CPU(30)는, 상술한 S109와 마찬가지로, 비친구의 이용자 식별 정보(UID*x)와 신청원 이용자 식별 정보(UID_From)가 일치하는 레코드로부터 신청처 참조 식별 정보(RefID_To)를 추출함과 함께, 비친구의 이용자 식별 정보(UID*x)와 신청처 이용자 식별 정보(UID_To)가 일치하는 레코드로부터 신청원 참조 식별 정보(RefID_From)를 추출한다. 그리고, 추출한 신청처 참조 식별 정보(RefID_To)와 추출한 신청원 참조 식별 정보(RefID_From)에 대응하는 이용자 식별 정보(UID)의 수가, 비친구의 이용자 식별 정보(UID*x)의 수가 되고, CPU(30)는 이것을 집계한다.
이어서, CPU(30)는, 친구 상한수 테이블(TBL12)을 참조하여 착안하는 비친구의 이용자 식별 정보(UID*x)의 친구 상한수를 취득한다(S116). 이 후, CPU(30)는, 취득한 친구 상한수와 집계한 친구수를 비교하여, 집계수가 친구 상한수에 달하지 않은 경우에, 비친구의 이용자를 친구 신청 가능하다고 판단하고(제3 조건을 충족), 집계수가 친구 상한수에 달한 경우에 비친구의 이용자를 친구 신청 불가능하다고 판단한다(S117). 이어서, CPU(30)는 처리를 S114로 되돌리고, S114의 판정 조건이 충족될 때까지 S114부터 S117을 반복하여, S114의 판정 조건이 충족되면, 처리를 S118로 진행시킨다.
S118에서, CPU(30)는, 친구 신청 가능한 비친구의 이용자 식별 정보(UID*x)를 특정하고, 비친구의 인원수를 집계한다. 비친구의 집계수는, 당해 게임 이외의 다른 게임에서 친구 관계에 있고 당해 게임에서 친구 관계가 아닌 이용자의 인원수이다. 비친구의 집계수는, 친구 찾기 페이지에서 게임마다 표시된다(후술하는 도 12의 영역(125)을 참조).
이어서, CPU(30)는, 착안하는 종별 정보(AppIDx)에 대응하는 게임에 대해서, S104의 처리로 취득한 게임 정보, S110의 처리에서 집계한 플레이하고 있는 친구수, S112의 처리에서 집계한 초대 가능한 인원수 및 S118의 처리에서 집계한 친구 신청 가능한 인원수를 일시적으로 변수 영역이나 워크 에리어에 기억시킨다(S119).
이 후, CPU(30)는, 처리를 도 10에 도시하는 S107로 되돌린다. 그리고, S102에서 추출한 모든 종별 정보(AppIDx)에 대하여 S107부터 S119의 처리를 종료하면, 친구의 인원수가 많은 순서대로 게임을 배치한 친구 찾기 페이지를 생성하고(S120), 처리를 종료한다.
또한, S104의 처리에서 친구 신청이 불가능한 취지의 플래그가 세트되어 있는 경우에는, S110의 처리에서 집계한 플레이하고 있는 친구수 대신에, 그 표시를 비표시로 하거나, 「신청 가능 인원수에 달했기 때문에 신청할 수 없습니다」라는 표시를 한다.
설명을 도 8로 되돌린다. 관리 서버(3A)에서 친구 처리가 종료되고(S7), 친구 찾기 페이지가 생성되면, 관리 서버(3A)의 CPU(30)는 친구 찾기 페이지를 포함하는 친구 응답을 단말 장치(2)에 송신한다. 단말 장치(2)의 CPU(20)는, 친구 응답을 수신하면, 친구 찾기 페이지를 디스플레이(25)에 표시한다. 도 12에 친구 찾기 페이지의 일례를 나타낸다. 이 예에서는, 게임 표시 영역(120, 130, 140)이 설치되어 있고, 이용하고 있는 친구의 인원수가 많은 순서대로 게임을 게임 표시 영역(120)→게임 표시 영역(130)→게임 표시 영역(135)에 표시한다.
먼저, 영역(121)에는 애플리케이션 정보 테이블(TBL15)로부터 판독한 아이콘 정보에 기초하여 아이콘이 표시되고, 영역(122)에는 애플리케이션명(게임명)이 표시된다. 이들 정보는, 상술한 S108의 처리로 취득된다. 다음으로 영역(123)에는, 이용자 A와 친구 관계에 있는 친구의 인원수가 표시된다. 이 정보는, 상술한 S110의 처리로 취득된다. 다음으로 영역(124)에는, 이용자 A가 초대 가능한 친구의 인원수가 표시된다. 이 정보는, 상술한 S112의 처리로 취득된다. 또한, 영역(125)에는, 이용자 A가 친구 신청 가능한 친구의 인원수가 표시된다. 이 정보는, 상술한 S118의 처리로 취득된다.
또한, 이 예에서는, CPU(30)는, 이용 완료 애플리케이션마다, 이용자 A가 초대 가능한 친구의 인원수와 이용자 A가 친구 신청 가능한 친구의 인원수를 단말 장치(2)에 함께 표시시켰지만, 어느 한쪽만을 표시시키도록 일부의 기능만을 구비시켜도 된다. 또한, 인원수를 표시시키는 것이 아니라, 친구 신청 또는 초대의 후보가 되는 이용자의 유저명이 표시되도록 해도 되고, 인원수와 후보가 되는 이용자의 유저명 양쪽을 표시시키도록 해도 된다.
또한, 이 예에서는, CPU(30)는, 친구 신청이 가능한 인원수에 대해서, 이용 완료 애플리케이션마다 특정하고, 이용 완료 애플리케이션마다 단말 장치(2)에 표시시켰지만, CPU(30)는, 복수의 이용 완료 애플리케이션의 합계의 친구 신청이 가능한 인원수를 특정하고, 이것을 요구 이용자의 단말 장치(2)에 표시시켜도 된다. 또한, 초대 가능한 인원수도 친구 신청과 마찬가지로 복수의 이용 완료 애플리케이션의 합계 인원수를 특정하고, 이것을 요구 이용자의 단말 장치(2)에 표시시켜도 된다.
이어서, 영역(120), 영역(130), 영역(135)에 표시되는 게임 중 어느 하나를 이용자가 선택하면(도 8에 나타내는 S9), 단말 장치(2)의 CPU(20)는, 상세 페이지 요구를 관리 서버(3A)에 송신한다. 관리 서버(3A)의 CPU(30)는 상세 페이지 요구를 수신하면, 선택된 게임에 대응하는 상세 페이지를 생성하여(S10), 상세 페이지를 포함하는 상세 페이지 응답을 단말 장치(2)에 반송한다. 단말 장치(2)의 CPU(20)는, 상세 페이지 응답을 수신하면, 상세 페이지를 디스플레이(25)에 표시시킨다.
도 13에 상세 페이지의 일례를 나타낸다. 이 예에서는, 도 12에 나타내는 친구 찾기 페이지에서 이용자 A가 게임 b를 선택한 것으로 한다. 도 13에 도시한 바와 같이 상세 페이지에는, 버튼(140)과 버튼(141)이 표시된다. 버튼(140)은 초대에 대응하고 있고, 버튼(141)은 친구 신청에 대응하고 있다. 도 13에 나타내는 상태에서 이용자가 「초대하기」라고 표시된 버튼(140)을 클릭하면, 도 16에 나타내는 초대용의 상세 페이지로 전환된다.
또한, 도 13에 나타내는 친구 신청용의 상세 페이지에는, 영역(142)에, 이용자 A가 게임 b에 대하여 다른 게임에서 친구인 이용자를, 앞으로 몇 사람, 친구 신청 가능한지가 표시된다. 친구 신청 가능한 인원수는, 도 12에 나타내는 영역(125)에 표시되는 인원수와 동일하며, 상술한 S118의 처리로 취득된다. 또한, 이용자 A 자신의 친구 상한수가, 당해 인원수보다 적은 경우에는, 친구 상한수로부터 현재의 친구수의 차가 되는 인원수가 표시된다. 또한, 영역(143 내지 145)에는, 친구 신청의 후보가 되는 이용자의 유저명과, 체크 박스(143b, 144b, 145b)가 표시된다. 체크 박스(143b, 144b, 145b)에 체크를 설정하고, 버튼(146)을 클릭함으로써, 친구 신청을 행할 수 있다. 또한, 친구 신청은, 복수의 상대에게 동시에 행할 수 있다.
또한, 본 실시 형태에 따르면, 이용 완료 게임을 선택할 수 있는 화면을 요구 이용자의 단말 장치(2)에 표시시켜, 선택한 이용 완료 게임에 대하여 친구 관계에 있을 것이 후보 이용자의 요건이 되므로, 요구 이용자는, 초대하려고 하는 게임과 유사한 이용 완료 게임을 선택하는 등, 기호에 맞춘 선택이 가능하게 된다.
<2-2: 친구 신청 처리>
도 14에 친구 신청 처리에 관한 애플리케이션 시스템의 동작 시퀀스를 나타낸다. 먼저, 단말 장치(2)에 있어서 이용자 A가 친구 신청에서 친구를 선택하면(S140), 단말 장치(2)의 CPU(20)는, 친구 신청 요구를 관리 서버(3A)에 송신한다. 친구 신청 요구에는, 신청원 이용자 식별 정보(UID_From)와 신청처 이용자 식별 정보(UID_To)가 포함되어 있다.
친구 신청 요구를 관리 서버(3A)의 CPU(30)가 수신하면, CPU(30)는, 관계 테이블(TBL13)의 기억 내용을 갱신한다(S141). 구체적으로는, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여 신청원 이용자 식별 정보(UID_From)에 대응하는 신청원 참조 식별 정보(RefID_From) 및 신청처 이용자 식별 정보(UID_To)에 대응하는 신청처 참조 식별 정보(RefID_To)를 취득하고, 상태 정보(Stat)를 「신청중」(Stat=0)으로 설정한 레코드를 생성하여, 관계 테이블(TBL13)에 기록한다. 이때, 종별 정보(AppID)는, 친구 신청 요구에 포함되어 있는 것이면, 이것을 사용해도 되고, 또는, 이용자 정보 테이블(TBL11)을 참조하여 신청원 이용자 식별 정보(UID_From) 또는 신청처 이용자 식별 정보(UID_To)에 대응하는 종별 정보(AppID)를 취득해도 된다.
여기서, 이용자 A가 친구 신청하려고 하는 것이 게임 b이며, 게임 b에서는 친구 관계는 아니지만, 게임 c에서 친구 관계에 있는 다른 이용자에게 친구 신청하는 경우를 상정한다. 이 경우, 관리 서버(3A)의 CPU(30)는, 친구 신청 통지를 신청처의 게임 b를 관리하는 애플리케이션 서버(3B)에 대하여 신청처의 다른 이용자의 이용자 식별 정보(UID)와 함께 송신한다. 즉, CPU(30)는, 게임 b를 제공하는 애플리케이션 서버(3B)에 대하여 이용자 A가 후보 이용자 중에서 선택한 이용자에 대하여 친구 신청을 요구하는 지시를 행하는 지시부로서 기능한다. 애플리케이션 서버(3B)는, 친구 신청 통지를 수신하면, 신청처의 다른 이용자의 마이 페이지에서, 이용자 A로부터 친구 신청 통지가 있음을 표시할 수 있도록 관리 테이블을 갱신한다(S142).
또한, 관리 서버(3A)는, 친구 신청 응답을 단말 장치(2)에 답신한다. 단말 장치(2)의 CPU(20)는, 친구 신청 응답을 수신하면, 마이 페이지 등에 친구 신청중인 것을 표시한다.
이렇게 본 실시 형태에 따르면, 관리 서버(3A)는 제1 조건 내지 제3 조건을 충족하는 후보 이용자를 선택할 수 있도록 이용자 A의 단말 장치(2)에 표시시킨다. 여기서, 제1 조건 내지 제3 조건은 이하와 같다.
제1 조건: 이용자 A가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중, 이용자 A가 이용하고 있는 애플리케이션을 이용하고 있는 이용자.
제2 조건: 당해 애플리케이션에 대하여 이용자 A와 친구 관계가 구축되어 있지 않은 이용자.
제3 조건: 당해 애플리케이션에서 친구 상한수에 달하지 않은 이용자.
이에 의해, 서로 다른 애플리케이션에서 형성된 신뢰 관계를 새로운 애플리케이션에서도 활용할 수 있게 된다. 즉, 어떤 게임을 이용자가 플레이하고 있는 경우에, 전혀 모르는 상대에게 친구 신청하는 것이 아니라, 다른 게임에서 친구가 된 친숙한 이용자에게 친구 신청을 할 수 있으므로, 새로운 게임을 시작하는 경우에, 친구 관계를 구축하기 쉽다는 이점이 있다.
또한, 본 실시 형태에 따르면, 관리 서버(3A)의 관계 테이블(TBL13)에, 친구 관계가 되는 이용자 정보의 조를 기억하므로, 각종 애플리케이션에서 구축되는 친구 관계를 일원적으로 관리할 수 있다. 또한, 종별 정보와 이용자 정보를 대응지어서 기억하는 이용자 정보 테이블(TBL11)을 구비하므로, 이 이용자 정보 테이블(TBL11)을 참조함으로써 제1 조건을 충족할 수 있다.
또한, 본 실시 형태에 따르면, 신청측과 승낙측의 조를 관계 테이블(TBL13)에 기억함으로써, 하나의 이용자 정보를 키로 해서 당해 이용자 정보와 친구 관계에 있는 모든 이용자 정보를 기억할 필요는 없으므로, 데이터의 기억 용량을 삭감하는 것이 가능하게 된다.
또한, 본 실시 형태에 따르면, 제1 친구 상한수 테이블(TBL12)을 사용하여, 애플리케이션마다 정해지는 친구 상한수를 관리 서버(3A)에서 일원적으로 관리하므로, 제3 조건을 충족시키는 것이 가능하게 된다.
또한, 본 실시 형태에 따르면, 이용 완료 애플리케이션을 선택할 수 있도록 이용자 A의 단말 장치(2)에 표시시켜, 선택한 이용 완료 애플리케이션에 대하여 친구 관계에 있을 것이 후보 이용자의 요건이 되므로, 친구 신청을 요구하는 이용자는, 친구 관계를 구축하려고 하는 애플리케이션과 유사한 이용 완료 애플리케이션을 선택할 수 있거나, 구체적으로 어느 애플리케이션의 어느 친구를 초대하고 싶은지가 미리 결정되어 있는 경우에 찾기 쉬워진다.
또한, 본 실시 형태에 따르면, 친구 신청이 가능한 인원수를 알 수 있으므로, 친구 신청을 요구하는 이용자에게 편리성이 대폭 향상된다.
<2-3: 초대 처리>
도 15에 초대 처리에 관한 애플리케이션 시스템의 동작 시퀀스를 나타낸다. 먼저, 단말 장치(2)에 있어서 이용자 A가 초대에서 친구를 선택하면(S150), 단말 장치(2)의 CPU(20)는, 초대 요구를 관리 서버(3A)에 송신한다. 도 16에 초대용의 상세 페이지의 일례를 나타낸다. 이 예에서는, 도 12에 나타내는 친구 찾기 페이지에서 이용자 A가 게임 b를 선택한 것으로 한다. 초대용의 상세 페이지에는, 영역(142)에, 이용자 A가 게임 b에 대하여 다른 게임에서 친구인 이용자를, 앞으로 몇 사람, 초대 가능한지가 표시된다. 초대 가능한 인원수는, 도 12에 나타내는 영역(124)에 표시되는 인원수와 동일하며, 상술한 S112의 처리로 취득된다. 또한, 영역(143 내지 145)에는, 초대의 후보가 되는 이용자의 유저명과, 체크 박스(143b, 144b, 145b)가 표시된다. 체크 박스(143b, 144b, 145b)에 체크를 설정하고, 버튼(148)을 클릭함으로써, 친구의 초대를 행할 수 있다. 또한, 초대는, 복수의 상대에게 동시에 행할 수 있다.
또한, 본 실시 형태에 따르면, 초대 신청이 가능한 인원수를 알 수 있으므로, 요구 이용자에게 편리성이 대폭 향상된다.
영역(142)에 표시되는 초대 가능한 인원수는, 상술한 S111 및 S112의 처리로 취득된다. 먼저, CPU(30)는, 초대의 대상이 되는 게임을 플레이하고 있지 않을 것을 조건으로 하고, 이 조건을 만족하는 후보 이용자를 추출한다. 즉, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, 초대의 대상이 되는 게임 이외의 어떤 게임에서 이용자 A와 친구 관계가 구축되어 있는 친구의 이용자 식별 정보(UID*x) 중에서, 초대하는 게임을 플레이하고 있지 않은 후보 이용자의 이용자 식별 정보(UID*x)를 추출한다(S111). 구체적으로는, 이용자 정보 테이블(TBL11)을 참조하여, S109에서 추출한 친구의 이용자 식별 정보(UID*x)에 대응하는 친구의 참조 식별 정보(RefID*)를 취득하고, 또한, 당해 친구의 이용자 식별 정보(UID*x)와, 취득한 참조 식별 정보(RefID*)와, 당해 참조 식별 정보(RefID*)에 대응하는 하나 또는 복수의 종별 정보(AppIDx)의 조를 취득한다. 그리고, 취득한 하나 또는 복수의 조 중에서, 초대하는 게임의 종별 정보(AppIDx)를 포함하지 않는 조의 후보 이용자의 이용자 식별 정보(UID*x)와 참조 식별 정보(RefID*), 즉, 초대의 대상이 되는 게임을 플레이하고 있지 않은 후보 이용자의 이용자 식별 정보(UID*x)와 참조 식별 정보(RefID*)를 추출한다.
이어서, CPU(30)는, 인바이트 테이블(TBL14)을 참조하여, 이용자 A를 나타내는 참조 식별 정보(RefIDa)가 초대원으로서, 또한 후보 이용자의 이용자 식별 정보(UID*x)에 대응하는 참조 식별 정보(RefID*)x가 초대처로서 인바이트 테이블(TBL14)에 기록되어 있는 조 이외의 조를 추출하여, 집계한다(S112). 즉, 인바이트 테이블(TBL14)에 기록된 초대중 또는 초대 완료의 이용자를 제외하고, 이용자 A가 새롭게 초대 가능한 후보 이용자와 그 인원수를 특정한다.
도 15에서, 초대 요구를 관리 서버(3A)의 CPU(30)가 수신하면, CPU(30)는, 인바이트 테이블(TBL14)의 기억 내용을 갱신한다(S151). 구체적으로는, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여 신청원 이용자 식별 정보(UID_From)에 대응하는 신청원 참조 식별 정보(RefID_From), 신청처 이용자 식별 정보(UID_To)에 대응하는 신청처 참조 식별 정보(RefID_To) 및 종별 정보(AppID)를 취득하고, 상태 정보(Stat)를 「신청중」(Stat=0)으로 설정한 레코드를 생성하여, 인바이트 테이블(TBL14)에 기록한다. 도 6에 도시한 바와 같이, 인바이트 테이블(TBL14)의 1개의 레코드는, 레코드 식별 정보(ID), 종별 정보(AppID), 초대원의 이용자의 참조 식별 정보(RefID)인 신청원 참조 식별 정보(RefID_From), 초대처의 이용자의 참조 식별 정보(RefID)인 신청처 참조 식별 정보(RefID_To), 초대 연월일을 나타내는 일시 정보(Date) 및 초대 상태를 나타내는 상태 정보(Stat)가 대응지어져서 기억된다. 상태 정보(Stat)가 「0」인 경우에는 초대를 신청중인 것을 나타내고, 상태 정보(Stat)가 「1」인 경우에는 초대를 승인 또는 거부한 것을 나타낸다. CPU(30)는, 상태에 따라서 상태 정보(Stat)의 내용을 재기입한다. 도 6에 나타내는 예에서는, CPU(30)는, 참조 식별 정보(RefID)가 「00000011」인 이용자가 초대를 행한 타이밍에서 인바이트 테이블(TBL14)에서의 ID=1의 레코드를 생성하고, 상태 정보(Stat)를 「0」으로 재기입한다. 이 후, 재기입부(53)는, 참조 식별 정보(RefID)가 「00003120」인 이용자가 초대를 수령하고, 승인 또는 거부한 타이밍에서, 상태 정보(Stat)를 「1」로 재기입한다.
본 실시 형태에서는, 거부와 승인을 통합하여 제1 상태로 하고 있다. 따라서, 초대가 거부되었을 경우뿐만 아니라, 초대가 승인되었을 경우에도 후보 이용자로부터 제외된다. 초대를 승인한 이용자는, 애당초 초대의 대상이 되는 게임을 이미 이용하고 있기 때문에, 초대할 필요가 없다. 이러한 데이터 구조를 채용함으로써, 거부한 이용자와 초대받은 이용자를 동시에 배제할 수 있으므로 처리 부하가 경감된다.
여기서, 이용자 A가 초대하려고 하는 게임이 게임 b이며, 게임 c에서 친구 관계에 있는 다른 이용자 B를 초대하는 경우를 상정한다. 이용자 A는 단말 장치(2-1)를 관리하고 있고, 이용자 B는 단말 장치(2-2)를 관리하고 있다고 하자. 이 경우, 관리 서버(3A)의 CPU(30)는, 초대가 있음을 통지하는 초대 메일을 단말 장치(2-2)에 송신한다. 또는, 관리 서버(3A)의 CPU(30)는, 이용자 B의 관리 서버(3A)의 SNS 사이트의 마이 페이지에 이용자 A가 게임 b에 초대하고 있음을 알리는 메시지를 표시하도록 해도 된다. 또한, 관리 서버(3A)의 CPU(30)는, 다른 소셜 미디어나 게시판에 초대 기사를 투고하도록 송신해도 된다. 이렇게 CPU(30)는, 도 1에 도시한 바와 같이, 이용자 A가, 단말 장치(2-1)에 표시된 후보 이용자 중에서 선택한 후보 이용자에 대하여 초대 신청을 통지하는 통지부(16)로서 기능한다.
또한, 관리 서버(3A)의 CPU(30)는, 초대 응답을 단말 장치(2-1)에 답신한다. 단말 장치(2-1)의 CPU(20)는, 초대 응답을 수신하면, 초대중인 것을 표시한다.
이렇게 본 실시 형태에 따르면, 어떤 게임을 이용자가 플레이하고 있는 경우에, 전혀 모르는 상대를 초대하는 것이 아니라, 다른 게임에서 친구가 된 친숙한 이용자를 초대할 수 있으므로, 새로운 게임을 다른 게임의 친구에게 널리 퍼지게 할 수 있고, 또한 다른 게임의 친구가 당해 게임에 참가한 경우에는, 당해 게임에서도 친구 관계를 구축하기 쉽다는 이점이 있다.
또한, 특정부(12)로서의 CPU(30)는, S112에서, 인바이트 테이블(TBL14)을 참조하여 초대 가능한 후보 이용자의 이용자 식별 정보(UID*x)를 포함하는 레코드를 추출할 때, 상태 정보(Stat)가 「1」인 레코드에 대해서는, 추출 대상의 레코드로부터 제외한다. 즉, 특정부(12)는, 상태 정보(Stat)가 「1」인 경우에는 초대가 승인 또는 거부되어 있는 경우이므로, 그러한 상대에게는 다시 초대하지 않도록 제어하고 있다. 따라서, 본 실시 형태에 따르면, 초대의 상태를 나타내는 상태 정보와 이용자 정보를 대응지어서 인바이트 테이블(TBL14)에서 관리하므로, 인바이트 테이블(TBL14)을 참조함으로써, 초대 상태를 알 수 있다. 그리고, 상태 정보가 거부를 나타내는 경우에는, 후보 이용자로부터 제외되므로, 초대를 거부했음에도 불구하고 다시 초대하는 등 폐를 끼치는 행위를 미연에 방지할 수 있다.
또한, 본 실시 형태에 따르면, 초대 신청중인 이용자도 후보 이용자로부터 제외되기 때문에, 신청중임에도 불구하고 다시 초대를 신청하는 헛수고를 없애서, 관리 서버(3A)의 처리 부하를 경감할 수 있다.
<2-4: 문의 처리>
문의 처리는, 이용자 A의 친구인 이용자가 이용하고 있는 애플리케이션에 관한 이용 정보를 관리 서버(3A)에 문의하는 처리이다. 이용 정보에는, 친구 중에서 인기 있는 게임의 랭킹이나 어떤 게임을 이용하고 있는 친구수, 친구 신청할 수 있는 인원수, 초대할 수 있는 인원수 등이 포함된다.
문의 처리는, 친구에게 인기 있는 게임을 알 수 있는 랭킹 처리와, 어떤 게임을 특정하여, 특정한 게임을 즐기고 있는 친구의 인원수를 문의하는 친구수 처리를 포함한다.
먼저, 랭킹 처리에 대하여 설명한다. 랭킹 처리에는, 제1 랭킹 처리와 제2 랭킹 처리가 있다. 제1 랭킹 처리는, 특정한 게임에서 친구 관계에 있는 이용자에게 있어서 인기 있는 게임의 순위 부여를 행하는 처리이다. 한편, 제2 랭킹 처리는, 불특정한 게임에서 친구 관계에 있는 이용자에게 있어서 인기 있는 게임의 순위 부여를 행하는 처리이다.
이용자 A의 단말 장치(2)의 디스플레이에는, 도 9에 나타내는 화면이 표시된다. 이 화면에서 버튼(113)은 제1 랭킹 처리에 대응하고 있고, 버튼(114)은 제2 랭킹 처리에 대응하고 있다.
도 17에 랭킹 처리에 관한 애플리케이션 시스템의 동작 시퀀스를 나타낸다. 버튼(113)(도 9)을 클릭하여 「이 친구에게 인기 있는 게임을 보기」(제1 랭킹 처리)를 선택하면(S160), 관리 서버(3A)의 인기 애플리케이션 페이지로 이행한다. 즉, 버튼(113)은 SNS 사이트의 인기 애플리케이션 페이지로의 링크가 정의된 것이다. 또한, 이 링크의 정의에는, 이용자를 나타내는 이용자 식별 정보(UID)의 링크 정보가 포함된다. 관리 서버(3A)의 CPU(30)는, 종별 정보(AppID)에서 나타나는 게임에서의 친구의 사이에서 인기 애플리케이션 페이지로의 액세스 요구를 수신하면, 제1 랭킹 페이지를 생성하는 제1 랭킹 처리를 실행한다(S161).
도 23에 제1 랭킹 처리의 내용을 나타낸다. 먼저, CPU(30)는, 수신한 액세스 요구에 포함되는 이용자 식별 정보(UIDax)를 취득한다(S200). 이어서, CPU(30)는, 관계 테이블(TBL13)을 참조하여, 그룹 정보(Group)가 「Friends」를 나타내고, 이용자 A의 이용자 식별 정보(UIDax)에 대응하는 친구인 이용자의 이용자 식별 정보(UID*x)를 특정한다(S201).
보다 구체적으로는, CPU(30)는, (Group=Friends)*{(UID_To=UIDax)+(UID_From=UIDax)}*(Stat=1)을 충족하는 레코드를 추출하고, 그것들에 포함되는 하나 또는 복수의 이용자 식별 정보(UID*x)를 특정한다.
이어서, CPU(30)는, 추출한 이용자 식별 정보(UID*x)의 수를 종별 정보(AppIDx)마다 집계한다(S202). 또한, CPU(30)는, 친구의 이용자 식별 정보(UID*x)의 집계수에 기초하여, 종별 정보(AppIDx)로 특정되는 게임의 인기순을 특정한다. 또한, CPU(30)는, 애플리케이션 정보 테이블(TBL15)을 참조하여, 추출한 종별 정보(AppIDx)에 대응하는 게임명, 설명 정보 및 아이콘 정보를 취득한다. 이 후, CPU(30)는, 제1 랭킹 페이지를 생성한다. 이때, CPU(30)는, 즐기고 있는 친구가 많은 순서대로 게임의 설명 등을 배치하여 제1 랭킹 페이지를 생성한다.
단말 장치(2)는, 관리 서버(3A)로부터 제1 랭킹 페이지를 포함하는 액세스 응답을 수신하면, 제1 랭킹 페이지를 디스플레이(25)에 표시한다(S162).
즉, CPU(30)는, S201에서 복수의 게임 중, 도 9에 표시되는 게임에서의 이용자 A의 이용자 식별 정보(UIDax)를 특정하고, 또한, 당해 게임에서 이용자 A와 친구 관계가 구축되어 있는 이용자를 이용자 식별 정보(UID*x)로 특정하고, 또한, 특정한 이용자, 즉, 친구가 플레이하고 있는 각 게임의 랭킹과, 각 게임을 플레이하고 있는 친구수를 나타내는 이용 정보를 취득하는 정보 취득부(15)로서 기능한다.
본 실시 형태에 따르면, 정보 취득부(15)는, 친구의 사이에서 인기 애플리케이션 페이지로의 액세스 요구에 대응지어진 애플리케이션에 있어서, 요구 이용자인 이용자 A의 친구가 이용하고 있는 애플리케이션에 관한 이용 정보를 취득한다. 그리고, 표시 제어부(14)는, 이것을 단말 장치(2)에 표시시키므로, 요구 이용자는 특정한 애플리케이션을 통한 친구에 관해서 다양한 정보를 얻는 것이 가능하게 된다.
또한, 버튼(114)(도 9)을 클릭하여 「다른 친구에게 인기 있는 게임을 보기」를 선택하면(S163), 관리 서버(3A)의 인기 애플리케이션 페이지로 이행한다. 즉, 버튼(113)은 SNS 사이트의 인기 애플리케이션 페이지로의 링크가 정의된 것이다. 또한, 이 링크의 정의에는, 이용자를 나타내는 이용자 식별 정보(UID)의 링크 정보가 포함된다. 관리 서버(3A)의 CPU(30)는, 이용자가 플레이한 복수 게임에서의 친구의 사이에서 인기 애플리케이션 페이지로의 액세스 요구를 수신하면, 제2 랭킹 페이지를 생성하는 제2 랭킹 처리를 실행한다(S164). 단말 장치(2)의 CPU(20)는, 관리 서버(3A)로부터 제2 랭킹 페이지를 포함하는 액세스 응답을 수신하면, 제2 랭킹 페이지를 디스플레이(25)에 표시한다(S165).
또한, 버튼(113)에 의한 인기 애플리케이션의 랭킹은, 이용자의 대상이 어떤 특정한 게임의 친구인 것에 반해, 버튼(114)에 의한 인기 애플리케이션의 랭킹은, 이용자의 대상이, 당해 이용자가 플레이하고 있는 복수의 게임 중 어느 하나에서 친구인 것이다. 가령 이용자가 하나의 게임밖에 플레이하고 있지 않은 경우에는, 버튼(113)에 의한 인기 애플리케이션의 랭킹 내용과, 버튼(113)에 의한 인기 애플리케이션의 랭킹 내용이 동일해진다.
도 18에 랭킹 처리의 내용을 나타낸다. 먼저, CPU(30)는, 수신한 액세스 요구에 포함되는 이용자 식별 정보(UIDax)를 취득한다(S170). 이어서, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, 이용자 식별 정보(UIDax)로부터 이용자 A의 참조 식별 정보(RefIDa)를 취득한다(S171). 또한, CPU(30)는, 관계 테이블(TBL13)을 참조하여, 그룹 정보(Group)가 「Friends」를 나타내고, 이용자 A의 참조 식별 정보(RefIDa)에 대응하는 종별 정보(AppIDx)와 이용자 식별 정보(UIDax)의 조합을 특정한다(S172).
보다 구체적으로는, (Group=Friends)*{(RefID_To=RefIDa)+(RefID_From=RefIDa)}*(Stat=1)을 충족하는 레코드를 추출하고, 그것들에 포함되는 하나 또는 복수의 종별 정보(AppIDx)와 이용자 식별 정보(UID*x)의 조합을 특정한다.
이어서, CPU(30)는, 추출한 이용자 식별 정보(UID*x)의 수를 종별 정보(AppIDx)마다 집계한다(S173). 또한, CPU(30)는, 친구의 이용자 식별 정보(UID*x)의 집계수에 기초하여, 종별 정보(AppIDx)로 특정되는 게임의 인기순을 특정한다(S174). 이어서, CPU(30)는, 애플리케이션 정보 테이블(TBL15)을 참조하여, 추출한 종별 정보(AppIDx)에 대응하는 게임명, 설명 정보 및 아이콘 정보를 취득한다. 이 후, CPU(30)는, 랭킹 페이지를 생성한다(S176). 이때, CPU(30)는, 즐기고 있는 친구가 많은 순서대로 게임의 설명 등을 배치하여 제2 랭킹 페이지를 생성한다. 단말 장치(2)는, 관리 서버(3A)로부터 제2 랭킹 페이지를 포함하는 액세스 응답을 수신하면, 제2 랭킹 페이지를 디스플레이(25)에 표시한다.
즉, CPU(30)는, S172에서 복수의 게임 중, 이용자 A가 이용한 적이 있는 게임의 종별 정보(AppIDx)를 특정하고, 또한, 이용자와 친구 관계가 구축되어 있는 이용자를 이용자 식별 정보(UID*x)로 특정하고, 또한 특정한 이용자, 즉, 친구가 플레이하고 있는 각 게임의 랭킹과, 각 게임을 플레이하고 있는 친구수를 나타내는 이용 정보를 취득하는 정보 취득부(15)로서 기능한다.
도 19에 제2 랭킹 페이지의 일례를 나타낸다. 이 예에서는, 랭킹 표시 영역(220, 230, 240)이 설치되어 있고, 랭킹이 높은 순서대로 게임을 랭킹 표시 영역(220)→랭킹 표시 영역(230)→랭킹 표시 영역(240)에 표시한다.
본 실시 형태에 따르면, 친구들 내에서 이용되고 있는 인원수가 많은 순서대로 애플리케이션(게임)이 표시되므로, 이용자는, 애플리케이션(게임)의 인기 랭킹을 한눈에 알 수 있다.
먼저, 영역(221)에는 애플리케이션 정보 테이블(TBL15)로부터 판독한 아이콘 정보에 기초하여 아이콘이 표시되고, 영역(222)에는 애플리케이션명(게임명)이 표시된다. 이들 정보는, 상술한 S175의 처리로 취득된다. 다음으로 영역(223)에는, 이용자 A가 플레이하고 있는 게임 중 어느 하나에서, 이용자 A와 친구 관계에 있고 게임 b를 즐긴 적이 있는 다른 이용자의 인원수가 표시된다. 이 정보는, 상술한 S173의 처리로 취득된다. 다음으로 영역(224)에는, 게임 b의 설명이 표시된다. 이 정보는, 상술한 S175의 처리로 취득된다. 또한, 여기에서 표시되는 게임은 이용자 A가 플레이하고 있지 않은 것도 포함된다.
이렇게 본 실시 형태에 따르면, 게임마다 이용자의 친구가 플레이하고 있는 친구수를 알 수 있으므로, 친구들 내에서 인기 있는 게임을 알 수 있다. 이에 의해, 이용자는 새로운 게임을 선택하는 경우의 기준을 얻을 수 있다.
또한, 본 실시 형태에 따르면, 정보 취득부(15)는, 요구 이용자인 이용자 A가 이용 완료의 애플리케이션에 있어서 친구 관계가 구축되어 있는 친구에 대해서, 당해 친구가 이용하고 있는 애플리케이션에 관한 이용 정보를 취득한다. 그리고, 표시 제어부(14)는 이것을 단말 장치(2)에 표시시킨다. 따라서, 요구 이용자인 이용자 A는, 친구가 이용하고 있는 애플리케이션에 관해서 다양한 정보를 얻는 것이 가능하게 된다.
이어서, 친구수 처리에 대하여 설명한다. 도 20에 친구수 처리에 관한 애플리케이션 시스템의 동작 시퀀스를 나타낸다. 관리 서버(3A)가 제공하는 이용자마다의 SNS 사이트의 마이 페이지에는, 게임을 특정하여 친구수를 문의할 수 있는 친구수 버튼이 준비되어 있다.
이용자 A가 단말 장치(2)에 있어서, 어떤 게임에 관한 친구수 버튼을 클릭하여 친구수를 선택하면(S180), 단말 장치(2)의 CPU(20)는, 친구수 요구를 관리 서버(3A)에 송신한다. 관리 서버(3A)의 CPU(30)는, 친구수 요구를 수신하면, 친구수 페이지를 생성하는 친구수 처리를 실행한다(S181).
도 21에 친구수 처리의 내용을 나타낸다. 먼저, CPU(30)는, 수신한 친구수 요구에 포함되는 이용자 식별 정보(UIDax)와 착안하는 게임의 종별 정보(AppIDx)를 취득한다(S190). 이어서, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, 이용자 식별 정보(UIDax)로부터 이용자 A의 참조 식별 정보(RefIDa)를 취득한다(S191). 또한, CPU(30)는, 관계 테이블(TBL13)을 참조하여, 그룹 정보(Group)가 「Friends」를 나타내고, 종별 정보(AppID)가 「AppIDx」를 나타내고, 또한, 이용자 A의 참조 식별 정보(RefIDa)에 대응하는 친구인 이용자의 이용자 식별 정보(UID*x)를 추출한다(S192).
보다 구체적으로는, (Group=Friends)*(AppID=AppIDx)*{(RefID_To=RefIDa)+(RefID_From=RefIDa)}을 충족하는 레코드를 추출하고, 그것들에 포함되는 하나 또는 복수의 이용자 식별 정보(UID*x)를 추출한다.
이어서, CPU(30)는, 추출한 이용자 식별 정보(UID*x)의 수를 집계한다(S193). 또한, CPU(30)는, 애플리케이션 정보 테이블(TBL15)을 참조하여, 종별 정보(AppIDx)에 대응하는 게임명, 설명 정보 및 아이콘 정보를 취득한다. 이 후, CPU(30)는, 친구수 페이지를 생성한다(S195).
도 22에 친구수 페이지의 일례를 나타낸다. 이 예에서는, 친구수 표시 영역(320)에 처리 결과가 표시된다. 구체적으로는, 영역(321)에는 애플리케이션 정보 테이블(TBL15)로부터 판독한 아이콘 정보에 기초하여 아이콘이 표시되고, 영역(322)에는 애플리케이션명(게임명)이 표시된다. 이들 정보는, 상술한 S194의 처리로 취득된다. 다음으로 영역(323)에는, 이용자 A와 친구 관계에 있고 게임 b를 즐긴 적이 있는 다른 이용자의 인원수가 표시된다. 이 정보는, 상술한 S193의 처리로 취득된다. 다음으로 영역(324)에는, 게임 b의 설명이 표시된다. 이 정보는, 상술한 S194의 처리로 취득된다.
이렇게 본 실시 형태에 따르면, 게임을 지정하여 이용자의 친구가 플레이하고 있는 친구수를 알 수 있으므로, 이용자는 신경이 쓰이는 게임에 대해서, 친구들 내에서 당해 게임이 어느 정도 인기가 있는지를 알 수 있다.
또한, 본 실시 형태에 따르면, 애플리케이션(게임)을 이용하고 있는 이용자수가 단말 장치(2)에 표시되므로, 상대적인 랭킹보다 상세한 정보를 이용자는 얻을 수 있다.
<3. 변형예>
본 발명은 상술한 실시 형태에 한정되는 것은 아니며, 이하의 변형이 가능하다. 또한, 각 변형예는 적절히 조합할 수 있다.
(1) 상술한 실시 형태에서는, 애플리케이션의 일례로서 게임을 들어 설명했지만 본 발명은 이것에 한정되는 것은 아니다. 초대나 인기 애플리케이션의 랭킹에 대해서는, 어떤 것이어도 된다. 예를 들어, 점이나 진단 애플리케이션, 편리 툴 애플리케이션, 사진 화상 처리의 애플리케이션이어도 된다. 친구 신청에 대해서는, 친구 관계를 구축하여 이용하는 채팅이나 게시판의 애플리케이션이 적합하다.
(2) 상술한 실시 형태에서는, 친구의 후보 이용자를 특정하는 경우, 또는 랭킹 처리, 또는, 특정한 게임을 특정한 친구수 처리에 있어서, 마지막으로 로그인한 일시는 문제로 삼지 않았지만, 본 발명은 이것에 한정되는 것이 아니다. 예를 들어, 액세스 테이블의 일례로서 이용자 정보 테이블(TBL11)을 사용하여, 이용자 정보 테이블(TBL11)에 이용자 식별 정보(UID)와 관련지어서 기억되어 있는 라스트 로그인 정보(LastLogin)를 사용하여, 친구 신청의 대상이 되는 애플리케이션을 이용하고 있는 후보 이용자를 특정하는 경우, 또는 애플리케이션마다 이용하고 있는 친구수를 특정하는 경우에, 또는, 특정한 게임에서의 친구수를 특정하는 경우에, 소정 기간 내에 애플리케이션을 이용하고 있을 것을 조건에 첨가해도 된다.
예를 들어, 도 10에 도시하는 친구 처리 대신으로서, 도 24에 나타내는 친구 처리를 행하도록 해도 된다. 도 24는, 도 10에 대응하는 친구 처리의 흐름도이며, 스텝 S109의 처리 후에, 스텝 S250과 스텝 S251의 처리가 추가되어 있다. 관리 서버(3A)의 CPU(30)는, 도 10에 도시하는 친구 처리와 마찬가지로, 스텝 S100부터 스텝 S109까지의 처리를 행한다. 그 후, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, 스텝 S109에서 추출한 친구의 이용자 식별 정보(UID*x) 및 착안하는 종별 정보(AppIDx)의 조와 일치하는 조의 최종 로그인 날짜를 취득한다(S250). 최종 로그인 날짜는, 이용자 정보 테이블(TBL11)의 라스트 로그인 정보(LastLogin)의 필드에 기억되어 있다. 그리고, CPU(30)는, 취득한 최종 로그인 날짜와, 처리가 행하여지고 있는 현재의 일자로부터, 최종 로그인 날짜가 소정 기간 내인 친구의 이용자 식별 정보(UID*x) 및 착안하는 종별 정보(AppIDx)의 조를 추출하고, 또한, 추출한 조에서의 친구의 이용자 식별 정보(UID*x)를 추출한다(S251). 이러한 처리에 의해, 소정 기간 내에 애플리케이션을 이용하고 있는 친구의 후보 이용자만을 특정하는 것이 가능해진다.
또한, 도 18에 나타내는 랭킹 처리 대신으로서, 도 25에 나타내는 랭킹 처리를 행하도록 해도 된다. 도 25는, 도 18에 나타내는 제2 랭킹 처리에 대응하는 랭킹 처리의 흐름도이며, 스텝 S172와 스텝 S173의 처리의 사이에, 스텝 S252와 스텝 S253의 처리가 추가되어 있다. 관리 서버(3A)의 CPU(30)는, 도 18에 나타내는 랭킹 처리와 마찬가지로, 수신한 액세스 요구에 포함되는 이용자 식별 정보(UIDax)를 취득한다(S170). 이어서, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, 이용자 식별 정보(UIDax)로부터 이용자 A의 참조 식별 정보(RefIDa)를 취득한다(S171). 또한, CPU(30)는, 관계 테이블(TBL13)을 참조하여, 그룹 정보(Group)가 「Friends」를 나타내고, 이용자 A의 참조 식별 정보(RefIDa)에 대응하는 종별 정보(AppIDx)와 친구의 이용자 식별 정보(UID*x)의 조합을 특정한다(S172). 그 후, CPU(30)는, 이용자 정보 테이블(TBL11)의 라스트 로그인 정보(LastLogin)를 참조하여, 스텝 S172에서 특정한 친구의 이용자 식별 정보(UID*x) 및 종별 정보(AppIDx)의 조와 일치하는 조의 최종 로그인 날짜를 취득한다(S252). 최종 로그인 날짜는, 이용자 정보 테이블(TBL11)의 라스트 로그인 정보(LastLogin)의 필드에 기억되어 있다. 그리고, CPU(30)는, 취득한 최종 로그인 날짜와, 처리가 행하여지고 있는 현재의 일자로부터, 최종 로그인 날짜가 소정 기간 내인 친구의 이용자 식별 정보(UID*x) 및 종별 정보(AppIDx)의 조를 추출하고, 또한, 추출한 조에서의 친구의 이용자 식별 정보(UID*x)를 추출한다(S253).
이어서, CPU(30)는, 추출한 이용자 식별 정보(UID*x)의 수를 종별 정보(AppIDx)마다 집계한다(S173). 또한, CPU(30)는, 친구의 이용자 식별 정보(UID*x)의 집계수에 기초하여, 종별 정보(AppIDx)로 특정되는 게임의 인기순을 특정한다(S174). 이어서, CPU(30)는, 애플리케이션 정보 테이블(TBL15)을 참조하여, 추출한 종별 정보(AppIDx)에 대응하는 게임명, 설명 정보 및 아이콘 정보를 취득한다. 이 후, CPU(30)는, 랭킹 페이지를 생성한다(S176). 이때, CPU(30)는, 즐기고 있는 친구가 많은 순서대로 게임의 설명 등을 배치하여 제2 랭킹 페이지를 생성한다. 단말 장치(2)는, 관리 서버(3A)로부터 제2 랭킹 페이지를 포함하는 액세스 응답을 수신하면, 제2 랭킹 페이지를 디스플레이(25)에 표시한다. 이러한 처리에 의해, 소정 기간 내에 애플리케이션을 이용하고 있는 친구의 후보 이용자에 대해서만, 애플리케이션마다 랭킹을 표시하는 것이 가능해진다.
또한, 도 21에 나타내는 친구수 처리 대신으로서, 도 26에 나타내는 친구수 처리를 행하도록 해도 된다. 도 26은, 도 21에 대응하는 친구수 처리의 흐름도이며, 스텝 S192와 스텝 S193의 처리의 사이에, 스텝 S254와 스텝 S255의 처리가 추가되어 있다. 관리 서버(3A)의 CPU(30)는, 도 21에 나타내는 친구수 처리와 마찬가지로, 스텝 S190부터 스텝 S192까지의 처리를 행한다. 그 후, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, 스텝 S192에서 추출한 친구의 이용자 식별 정보(UID*x) 및 착안하는 종별 정보(AppIDx)의 조와 일치하는 조의 최종 로그인 날짜를 취득한다(S254). 최종 로그인 날짜는, 이용자 정보 테이블(TBL11)의 라스트 로그인 정보(LastLogin)의 필드에 기억되어 있다. 그리고, CPU(30)는, 취득한 최종 로그인 날짜와, 처리가 행하여지고 있는 현재의 일자로부터, 최종 로그인 날짜가 소정 기간 내인 친구의 이용자 식별 정보(UID*x) 및 착안하는 종별 정보(AppIDx)의 조를 추출하고, 또한, 추출한 조에서의 친구의 이용자 식별 정보(UID*x)를 추출한다(S255). 이 이후의 처리는 도 21에 나타내는 친구수 처리와 마찬가지이다. 이러한 처리에 의해, 소정 기간 내에 애플리케이션을 이용하고 있는 친구의 후보 이용자에 대해서만, 친구수를 표시하는 것이 가능해진다.
게임 중에는 시험 삼아 플레이해 보고, 마음에 들지 않아서 그 후 전혀 플레이하지 않는 게임도 있는데, 소정 기간 내에 애플리케이션을 이용하고 있을 것을 조건으로 함으로써, 그 게임을 플레이하고 있는 이용자에 대하여 친구 신청을 행할 수 있게 된다. 또한, 친구 신청할 때에 이용자가 소정 기간으로서, 「1개월」 「1주일」과 같이 선택 가능하게 해도 된다. 또한, 소정 기간은, 애플리케이션의 종별에 따라서 서로 다른 기간이 설정되도록 해도 된다. 또한, 본 발명은 이용자 식별 정보(UID)와 라스트 로그인 정보(LastLogin)를 대응지어서 기억하는 것이라면, 어떤 테이블을 사용해도 되고, 이것을 이용자 정보 테이블(TBL11)과는 별도로 설치해도 된다.
본 변형예에 의하면, 애플리케이션의 이용으로부터 소정 기간 내의 후보 이용자에 한정하고 있으므로, 애플리케이션을 시험 삼아 이용하고, 그 후, 이용하지 않게 된 이용자에 대해서는 후보 이용자로부터 제외하기 때문에, 착안하는 애플리케이션에 대하여 실제로 사용하고 있는 이용자를 후보 이용자로 할 수 있다는 이점이 있다.
또한, 본 변형예에 의하면, 일시 정보를 참조함으로써, 소정 기간에서 친구들 내에서 이용되고 있는 인원수가 많은 순서대로 애플리케이션이 표시되므로, 어떤 기간에서 친구들 내에서 이용하고 있는 애플리케이션의 인기 랭킹을 한눈에 알 수 있다. 애플리케이션을 시험 삼아 이용하고, 그 후, 이용하지 않게 되는 경우도 생각할 수 있으며, 이러한 시험 사용을 랭킹의 대상에서 제외하고 싶은 경우도 있다. 본 변형예에 의하면, 소정 기간에 이용되고 있는 애플리케이션을 랭킹의 대상으로 하기 때문에, 시험 사용을 제외한 랭킹을 행하는 것이 가능하게 된다.
또한, 본 변형예에 의하면, 일시 정보를 참조함으로써, 소정 기간에서 친구들 내에서 어떤 애플리케이션을 이용하고 있는 인원수를 특정하므로, 어떤 기간에서 어떤 애플리케이션을 친구들 내에서 이용하고 있는 인원수를 한눈에 알 수 있다.
또한, 본 변형예에서는, 제2 랭킹 처리에 있어서, 각 게임에서의 친구수를 특정하는 경우에, 소정 기간 내에 게임을 이용하고 있을 것을 조건에 첨가한 경우에 대해 설명했지만, 본 변형예는, 제1 랭킹 처리에도 적용 가능하다. 제1 랭킹 처리에 본 변형예를 적용하는 경우에는, 도 23에 나타내는 S201과 S202의 사이에, 도 24에 나타내는 S300에 상당하는 처리를 행하면 된다.
(3) 상술한 실시 형태에서, 초대는, 복수의 이용자에 대하여 행할 수 있었지만, 이것에 제한을 두어도 된다. 구체적으로는, 소정 기간(예를 들어, 1일, 1주일)에 초대할 수 있는 이용자의 수에 제한을 두어도 된다. 또는, 다수의 초대 메일이 오는 것을 방지하기 위해서, 초대 메일의 수에 상한을 설정해도 된다. 이 경우에는, 인바이트 테이블(TBL14)에서 신청처의 이용자의 상태 정보(Stat)가 「0」(신청중)을 나타내는 레코드가 10건 미만인 이용자에게밖에는 「초대하기」를 할 수 없도록 해도 된다. 또한, 신청을 받는 측에서 수신을 제한하도록 해도 된다. 예를 들어, 상태 정보(Stat)가 「0」(신청중)을 나타내는 레코드가 10건을 초과하는 경우에는, 초대 메일을 신청처에 송신하지 않고 초대를 거부로 해도 된다.
또한, 신청원에 있어서 상태 정보(Stat)가 「0」(신청중)을 나타내는 레코드가 10건을 넘지 않도록 제한을 해도 된다. 뿐만 아니라, 초대한 상대가 그 게임을 개시했을 경우에, 예를 들어 초대자에게 인센티브(포인트 등)를 부여해도 된다.
(4) 상술한 실시 형태에서는, 「친구 신청」이나 「초대하기」나 「랭킹」의 처리는, 애플리케이션 서버(3B, 3C, 3D…)에서의 게임의 마이 페이지로부터 천이하는 예를 설명했지만, 본 발명은 이것에 한정되는 것은 아니며, 관리 서버(3A)의 SNS 사이트의 마이 페이지로부터 천이할 수 있도록 해도 된다.
게임의 마이 페이지로부터 「친구 신청」이나 「초대하기」나 「랭킹」의 처리로 천이하는 경우에는, 애플리케이션 서버(3B, 3C, 3D…)로부터 「게임 b」와 「X씨」로부터의 요구인 것의 정보가 통지된다. 관리 서버(3A)의 SNS 사이트의 마이 페이지로부터 천이하는 경우에는, 마찬가지의 정보를 부여하면 된다. SNS 사이트에서는 「X씨」의 마이 페이지에 로그인하고 있으므로, 친구 신청 요구나 초대 요구가 「X씨」인 것은 파악할 수 있다. 이 때문에, 어느 게임을 초대하는 것인지를 선택하는 수단을 설치한다. 즉, 어느 게임에 대한 「친구 신청」인가 「초대」인가, 또는 어느 게임에서의 친구에게 인기 있는 애플리케이션의 「랭킹」인가를 선택할 수 있도록 한다. 또한, 게임을 지정하지 않는 「랭킹」도 선택할 수 있도록 한다. 이 선택은, SNS 사이트의 마이 페이지에 선택을 위해 버튼을 설치하면 된다. 또한, 게임을 지정한 「랭킹」은, 상술한 실시 형태의 제1 랭킹 처리이며, 게임을 지정하지 않는 「랭킹」은, 상술한 실시 형태의 제2 랭킹 처리이다.
(5) 상술한 실시 형태에서는, 각 게임에서의 이용자마다의 친구 상한수를 관리 서버(3A)에서 일원적으로 관리했지만, 본 발명은 이것에 한정되는 것은 아니며, 각 애플리케이션 서버(3B, 3C, 3D…)에서 관리하도록 하고, 관리 서버(3A)로부터 필요에 따라서 각 애플리케이션 서버(3B, 3C, 3D…)에 문의하도록 해도 된다. 이 경우, 관리 서버(3A)의 CPU(30)는, 접수부(11)에서 접수한 종별 정보에 대응하는 애플리케이션 서버(3B, 3C, …)에서 설정된 이용자의 친구 상한수를 취득하는 취득부(9)로서 기능한다(도 27 참조). 또는, 관리 서버(3A)의 CPU(30)는, 접수부(11)에서 접수한 종별 정보(AppID)에 대응하는 애플리케이션 서버(3B, 3C, …)에 대하여 이용자의 친구 상한수를 문의하는 요구를 송신하고, 요구에 대한 응답으로서 당해 애플리케이션 서버(3B, 3C, …)로부터 친구 상한수를 취득하는 취득부(9)로서 기능해도 된다(도 27 참조).
도 28은, 도 8의 공통 처리에 관한 애플리케이션 시스템의 동작 시퀀스에 대응하는 본 변형예의 동작 시퀀스를 나타낸다. 도 28에 나타내는 동작 시퀀스에서는, 관리 서버(3A)의 CPU(30)가 친구 처리를 실행할 때(S7), 필요에 따라 애플리케이션 서버(3B, 3C, …)에 대하여 이용자의 친구 상한수를 문의하는 요구를 송신하고, 요구에 대한 응답으로서 당해 애플리케이션 서버(3B, 3C, …)로부터 친구 상한수를 취득한다. 구체적으로는, 도 29 및 도 30에 도시한 바와 같이 친구 상한수의 취득 처리가 행하여진다. 도 29는 도 10에 대응하는 본 변형예의 친구 처리의 흐름도이며, 도 30은 도 11에 대응하는 본 변형예의 친구 처리의 흐름도이다. 도 29에 도시한 바와 같이, 본 변형예에서는, 도 10에 도시하는 스텝 S102 대신에 스텝 S300의 처리가 행하여진다. 즉, CPU(30)는, 애플리케이션 서버(3B, 3C, …)에 대하여 착안하는 이용자 A의 이용자 식별 정보(UIDax)에 대응하는 친구 상한수를 요구하고, 애플리케이션 서버(3B, 3C, …)로부터 이용자 A의 이용자 식별 정보(UIDax)에 대응하는 친구 상한수를 취득한다(S300). 또한, 도 30에 도시한 바와 같이, 본 변형예에서는, 도 11에 도시하는 스텝 S116 대신에 스텝 S301의 처리가 행하여진다. 즉, CPU(30)는, 추출된 종별 정보(AppIDx)에 대응하는 애플리케이션을 제공하는 애플리케이션 서버(3B, 3C, …) 중 어느 하나의 애플리케이션 서버에 대하여 착안하는 비친구의 이용자 식별 정보(UID*x)의 친구 상한수를 요구하고, 당해 애플리케이션 서버로부터 당해 친구 상한수를 취득한다(S301).
또한, 친구 상한수 이외의 데이터라도 각 애플리케이션 서버(3B, 3C, 3D…)에서 관리하는 것이 가능한 것은, 마찬가지로, 각 애플리케이션 서버(3B, 3C, 3D…)에서 관리하도록 하고, 관리 서버(3A)로부터 필요에 따라서 각 애플리케이션 서버(3B, 3C, 3D…)에 문의하도록 해도 된다.
또한, 친구 상한수가 각 애플리케이션에서 고정화되어 있어도 된다. 그 경우, 예를 들어 애플리케이션 정보 테이블(TBL15)에서 종별 정보(AppID)에 관련지어서 고정화된 친구 상한수가 기록되어 있어도 된다. 또한, 애플리케이션에 의해 친구 상한수가 고정화되어 있는 것과 변동하는 것을 포함하는 경우, 애플리케이션 정보 테이블(TBL15)에 종별 정보(AppID)에 관련지어서 친구 상한수가 기억되어 있으면 고정화되어 있는 것으로 하고, 기억되어 있지 않으면(null) 친구 상한수 테이블(TBL12)을 참조하도록 해도 된다.
본 변형예에 의하면, 애플리케이션 서버로부터 친구 상한수를 취득하는 취득부를 구비하므로, 친구 상한수를 취득하는 것이 가능하게 된다.
(6) 상술한 실시 형태에서는, 관리 서버(3A)의 SNS 사이트의 마이 페이지로부터 랭킹의 선택이나 친구수의 선택을 실행할 수 있도록 했지만, 본 발명은 이것에 한정되는 것은 아니며, 애플리케이션 서버(3B, 3C, 3D…)가 제공하는 화면(페이지)에서 이용자의 조작에 기초하는 요구(랭킹 요구, 친구수 요구)를 접수하고, 애플리케이션 서버(3B, 3C, 3D…)가 관리 서버(3A)에 요구하는 것이어도 된다. 또한, 친구수 요구의 경우에는, 이용자가 어느 게임에 대하여 친구수의 제공을 희망하는지를 선택할 수 있도록 되어 있다.
(7) 상술한 실시 형태에서는, 친구 상한수가 변화하면, 각 애플리케이션 서버(3B, 3C, 3D, …)로부터 관리 서버(3A)에 통지가 송신되었지만, 본 발명은 이것에 한정되는 것이 아니다. 예를 들어, 애플리케이션(게임)에서, 친구 상한수의 변화에 영향을 주는 사상(게임이라면 레벨이 올라갔을 때 등)이 발생한 경우에, 친구 상한수의 변화의 유무에 관계없이 친구 상한수를 통지하도록 해도 된다. 또한, 단말 장치(2)로부터 관리 서버(3A)에 통지해도 된다. 이 경우, 단말 장치(2)의 CPU(20)는, 도 31에 도시한 바와 같이, 단말 장치(2)의 이용자의 친구 상한수가 변화한 것을 검출하는 검출부(27)와, 검출부(27)에 의해 친구 상한수가 변화한 것이 검출되면, 변화한 후의 친구 상한수를 관리 서버(3A)에 통지하는 통지부(28)로서 기능한다.
또한, 종류가 상이한 복수의 애플리케이션(게임) 각각에서의 친구 관계가 구축된 이용자 식별 정보(UID)를 애플리케이션(게임)의 종류를 나타내는 종별 정보에 관련지어서 일원적으로 관리하는 관리 서버와 통신 가능한 애플리케이션 서버(3B, 3C, 3D, …)에, 도 32에 도시한 바와 같이 관리부(51)와 통지부(52)를 구비하도록 해도 된다. 관리부(51)는, 이용자(플레이어)의 소정의 이용 실적의 정도(레벨이나 게임 진행도를 나타내는 스테이지수)에 관련지어서 친구 관계를 구축할 수 있는 친구 상한수(Limit)를 관리한다. 통지부(52)는, 애플리케이션(게임)의 이용중(게임 진행중)에 상기 이용 실적을 나타내는 정도가 갱신되어 친구 상한수가 변경된 경우에, 상기 관리부(51)에서 관리하는 상기 이용 실적의 정도에 따른 친구 상한수(Limit)를, 종별 정보 및 이용자 식별 정보(UID)와 관련지어서 상기 단말 장치(2)에 통지한다. 또한, 통지부(52)는, 애플리케이션의 이용중에 상기 이용 실적을 나타내는 정도가 갱신된 경우에 통지하도록 해도 된다.
본 변형예에서는, 도 33에 도시한 바와 같이, 애플리케이션 서버(3B, 3C, 3D, …)의 관리부(51)가 이용자의 상기 소정의 이용 실적의 정도에 관련지어서 친구 관계를 구축할 수 있는 친구 상한수(Limit)를 관리한다(S400). 그리고, 애플리케이션 서버(3B, 3C, 3D, …)의 통지부(52)는, 애플리케이션의 이용중에 상기 이용 실적을 나타내는 정도가 갱신되어 친구 상한수가 변경된 경우에, 상기 관리부(51)에서 관리하는 상기 이용 실적의 정도에 따른 친구 상한수(Limit)를, 종별 정보 및 이용자 식별 정보(UID)와 관련지어서 상기 단말 장치(2)에 통지한다.
애플리케이션 서버(3B, 3C, 3D, …)로부터 종별 정보 및 이용자 식별 정보(UID)와 관련지어진 친구 상한수(Limit)의 통지를 받은 단말 장치(2)는, 검출부(27)에 의해 단말 장치(2)의 이용자의 친구 상한수가 변화한 것을 검출한다(S401). 그리고, 단말 장치(2)의 통지부(28)는, 변화한 후의 친구 상한수를 관리 서버(3A)에 통지한다.
단말 장치(2)로부터 변화한 후의 친구 상한수의 통지를 받은 관리 서버(3A)의 CPU(30)는, 친구 상한수 테이블(TBL12)에 변화한 후의 친구 상한수를 기억시킨다(S402).
또한, 본 변형예에서는, 애플리케이션 서버(3B, 3C, 3D, …)의 통지부(52)는 상기 관리부(51)에서 관리하는 상기 이용 실적의 정도에 따른 친구 상한수(Limit)를, 종별 정보 및 이용자 식별 정보(UID)와 관련지어서 상기 관리 서버(3A)에 통지하도록 해도 된다.
또한 관리 서버는, 상기 복수의 애플리케이션(게임) 중 다른 애플리케이션(게임)에서 친구 관계가 구축되어 있는 이용자를 대상으로 친구의 후보가 되는 이용자를 제시하는 것을 상기 관리 서버에 대하여 요구하는 요구부와, 상기 요구부의 요구에 따라서 행하여지는 상기 관리 서버의 처리의 결과로서, 요구 이용자가 선택한 이용자에 대한 친구 신청의 요구를, 상기 관리 서버로부터 친구 신청의 대상이 되는 플레이어 정보와 관련지어서 접수하는 접수부로 구성되어도 된다. 또한, 상기 통지부는, 상기 친구 신청을 접수한 이용자의 승낙 또는 거부에 따른 통지를 상기 관리 서버에 통지하도록 해도 된다.
(8) 상술한 실시 형태에서는, CPU(30)는, 인바이트 테이블(TBL14)을 참조하여, 이용자 A가 초대원으로 되어 있는 초대처의 이용자를 특정하고, 특정된 이용자를 후보 이용자로부터 제외했다(S112). 인바이트 테이블(TBL14)에는, 초대중(Stat=0), 거부 또는 승낙(Stat=1)이 기록되어 있으므로, 이들에 해당하는 이용자가 제외된다. 즉, 상태 정보(Stat)가 거부 또는 승낙을 나타내는 제1 상태(Stat=1) 및 상태 정보(Stat)가 초대중을 나타내는 제2 상태(Stat=0)의 이용자는 초대의 후보 이용자로부터 제외된다.
본 발명은 이것에 한정되는 것이 아니며, 이하의 형태를 취할 수 있다. 첫번째, CPU(30)는, 상태 정보(Stat)가 제1 상태인 경우에, 초대의 후보 이용자로부터 제외해도 된다. 즉, 상태 정보(Stat)가 초대중을 나타내는 제2 상태에서, 다시 초대를 인정해도 된다.
또한, 상태 정보(Stat)에 있어서, Stat=1을 거부, Stat=2를 승인이라고 하는 등, 거부와 승인을 구별하여 관리해도 된다. 이 경우, CPU(30)는, 상태 정보(Stat)가 「0」거부를 나타내는 경우에 초대의 후보 이용자로부터 제외해도 된다.
이들을 종합하면, CPU(30)는, 상태 정보(Stat)에 의해 나타나는 초대의 상태가 적어도 거부인 경우에, 이용자를 후보 이용자로부터 제외한다.
또한, 관리 서버(3A)는, 도 34에 도시한 바와 같이, 인바이트 테이블(TBL14) 대신에, 초대한 이용자와 초대를 거부한 이용자를 관리하는 관리부(51)를 구비하고, 특정부(12)는, 관리부(51)를 사용하여, 요구 이용자가 초대한 이용자 중, 초대를 거부한 이용자를 특정하고, 특정한 이용자를 상기 후보 이용자로부터 제외하도록 해도 된다.
구체적으로는, 도 35에 나타내는 처리가 행하여진다. 도 35는, 도 11에 대응하는 흐름도이다. 본 변형예에서는, 예를 들어 특정부(12)는, S111의 처리가 행하여진 후에, 관리부(51)에 대하여 초대를 거부한 이용자의 리스트를 요구한다. 그리고, 특정부(12)는, 당해 리스트 중의 이용자와 S111에서 추출한 이용자의 사이에서 일치하는 이용자가 존재했을 경우에는, 당해 이용자를, 초대를 거부한 이용자로서 특정한다(S500).
이어서, CPU(30)는, 인바이트 테이블(TBL14)을 참조하여, 이용자 A를 나타내는 참조 식별 정보(RefIDa)가 초대원, 또한 후보 이용자의 이용자 식별 정보(UID*x)에 대응하는 참조 식별 정보(RefID*)가 초대처로서 인바이트 테이블(TBL14)에 기록되어 있는 경우에는, 당해 이용자 식별 정보(UID*x)를, 후보 이용자의 이용자 식별 정보(UID*x)로부터 제외하고, 나머지 후보 이용자의 이용자 식별 정보(UID*x)를 추출한다. 그리고, CPU(30)는, 추출한 후보 이용자의 이용자 식별 정보(UID*x) 중에서 S500에서 특정한 이용자의 이용자 식별 정보(UID*x)를 제외하고, 나머지 이용자 식별 정보(UID*x)를 집계한다(S501).
이 변형예에 의하면, 초대한 이용자와 초대를 거부한 이용자를 대응지어서 관리하므로, 한번, 거부된 이용자를 다시 초대하는 것을 미연에 방지할 수 있다.
(9) 상술한 실시 형태에서는, CPU(30)는, 인바이트 테이블(TBL14)에 기록된 초대 연월일을 나타내는 일시 정보(Date)에 기초하여, 초대하고 나서 소정 기간을 초과하여 초대 신청중이 계속된 경우에는, 강제적으로 상태 정보(Stat)를 거부 또는 승인(제1 상태)을 나타내는 「1」로 재기입하였다.
그러나, 본 발명은 이것에 한정되는 것은 아니며, CPU(30)는, 일시 정보(Date)에 기초하여 상태 정보(Stat)를 재기입하는 것이 아니라, 상태 정보(Stat)가 초대중을 나타내고 있는 경우에, 초대 연월일을 나타내는 일시 정보(Date)로부터 소정 기간이 경과한 경우에, 거부된 것으로 간주하여 취급해도 된다. 예를 들어, 본 변형예에서는, 도 36에 나타내는 처리가 행하여진다. 도 36은, 도 11에 대응하는 흐름도이다. 도 36에 도시한 바와 같이, CPU(30)는, 초대를 거부한 이용자와, 초대중(제2 상태)이며, 초대일로부터 소정 기간이 경과한 이용자를 특정한다(S510). 소정 기간의 경과는, 초대 연월일을 나타내는 일시 정보(Date)에 기초하여 판단하면 된다.
이어서, CPU(30)는, 인바이트 테이블(TBL14)을 참조하여, 이용자 A를 나타내는 참조 식별 정보(RefIDa)가 초대원, 또한 후보 이용자의 이용자 식별 정보(UID*x)에 대응하는 참조 식별 정보(RefID*)가 초대처로서 인바이트 테이블(TBL14)에 기록되어 있는 경우에는, 당해 이용자 식별 정보(UID*x)를, 후보 이용자의 이용자 식별 정보(UID*x)로부터 제외하고, 나머지 후보 이용자의 이용자 식별 정보(UID*x)를 추출한다. 그리고, CPU(30)는, 추출한 이용자 식별 정보(UID*x) 중에서, S510에서 특정한 이용자의 이용자 식별 정보(UID*x)를 포함하는 레코드를 제외하고, 나머지 이용자 식별 정보(UID*x)를 집계한다(S511).
이 변형예에 의하면, 초대를 신청중인 이용자에 대하여 다시 초대 신청을 허용한다. 이에 의해, 초대를 승인할지 여부를 고민하고 있는 이용자에 대하여 다시 초대함으로써, 게임에 대한 참가를 재촉할 수 있다. 그러나, 몇 번이나 초대하는 것은 번거롭다. 따라서, 본 변형예는, 상태 정보가 신청중을 나타내고 있어도, 초대의 일시로부터 소정 기간이 경과하면, 상태 정보가 신청중을 나타내고 있어도, 후보 이용자로부터 제외하고 있다. 이에 의해, 게임에 대한 참가를 재촉하면서, 폐를 끼치는 행위를 방지하는 것이 가능하게 된다. 또한, 거부와 승인을 하나의 상태로서 관리할 수 있으므로, 데이터 구조를 간소화할 수 있다.
또한, CPU(30)는, 초대 연월일을 나타내는 일시 정보(Date)에 기초하여, 초대하고 나서 소정 기간을 초과하여 초대 신청중(제2 상태)이 계속된 경우에는, 강제적으로 인바이트 테이블(TBL14)의 상태 정보(Stat)를 거부 「1」(제1 상태)로 재기입하도록 해도 된다. 이 경우에는, CPU(30)는, 도 37에 도시한 바와 같이 재기입부(53)로서 기능한다. 구체적으로는, 예를 들어 도 38에 나타내는 처리가 행하여진다. 도 38은, 도 15에 도시하는 바와 같이 관리 서버(3A)로부터 단말 장치(2)에 초대 메일을 송신한 후에, 정기적으로 실행되는 처리의 흐름도이다. 도 37에 도시한 바와 같이, CPU(30)는, 단말 장치(2)에 초대 메일을 송신한 후, 인바이트 테이블(TBL14)의 일시 정보(Date)를 판독한다(S520). 그리고, CPU(30)는, 일시 정보(Date)에 기초하여, 초대하고 나서 소정 기간이 경과했는지 여부를 판단한다(S521). CPU(30)는, 소정 기간이 경과하지 않았다고 판단했을 경우에는(S521: "아니오"), 처리를 종료한다. 그러나, CPU(30)는, 소정 기간이 경과했다고 판단한 경우에는(S521: "예"), 인바이트 테이블(TBL14)의 상태 정보(Stat)를 거부 「1」로 재기입한다(S522).
또한, 인바이트 테이블(TBL14)에, 레코드의 유효/무효를 나타내는 항목을 새롭게 추가하여, 소정 기간이 지난 경우에 레코드를 무효로 하도록 해도 된다.
이 변형예에 의하면, 초대 신청을 통지한 일시로부터 소정 기간이 경과해도 초대받은 이용자에게서 응답이 없을 경우, 상기 상태 정보의 상태를 초대의 신청중에서 초대의 거부로 재기입하기 때문에, 후보 이용자에 해당하는지 여부의 판정을 간소화할 수 있다.
또한, 초대가 거부된 경우뿐만 아니라, 초대가 승인된 경우에도 후보 이용자로부터 제외된다. 초대를 승인한 이용자는, 애당초 초대의 대상이 되는 게임을 이미 이용하고 있으므로, 초대할 필요가 없다. 이러한 데이터 구조를 채용함으로써, 거부한 이용자와 초대된 이용자를 동시에 배제할 수 있으므로 처리 부하가 경감된다.
(10) 상술한 문의 처리에 있어서, CPU(30)는, 도 10 및 도 11을 참조하여 설명한 처리를 실행하여 친구 신청 가능한 인원수나 초대 가능한 인원수를 단말 장치(2)에 표시시켜도 된다.
또한, CPU(30)는, 친구 신청 가능한 이용자의 수와 초대 가능한 이용자의 수를 배열하여 표시시키는 페이지를 생성하여, 또한 친구 신청이 가능한 후보 이용자와 초대 가능한 이용자를 선택적으로 단말 장치(2)에 표시시켜도 된다.
구체적으로는, 도 39 및 도 40에 나타내는 처리가 행하여진다. 도 39는, 도 18의 제2 랭킹 처리에 대응하는 본 변형예에서의 랭킹 처리의 흐름도이다. 도 40은, 도 10 및 도 11에 도시하는 친구 신청 가능한 인원수 및 초대 가능한 인원수의 산출 처리에 대응하는 본 변형예의 처리 흐름도이다.
먼저, CPU(30)는, 도 39에 도시한 바와 같이, 수신한 액세스 요구에 포함되는 이용자 식별 정보(UIDax)를 취득한다(S170). 이어서, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, 이용자 식별 정보(UIDax)로부터 이용자 A의 참조 식별 정보(RefIDa)를 취득한다(S171). 또한, CPU(30)는, 관계 테이블(TBL13)을 참조하여, 그룹 정보(Group)가 「Friends」를 나타내고, 이용자 A의 참조 식별 정보(RefIDa)에 대응하는 종별 정보(AppIDx)와 이용자 식별 정보(UID*x)의 조합을 특정한다(S172).
보다 구체적으로는, CPU(30)는, (Group=Friends)*{(RefID_To=RefIDa)+(RefID_From=RefIDa)}*(Stat=1)을 충족하는 레코드를 추출하고, 그것들에 포함되는 하나 또는 복수의 종별 정보(AppIDx)와 이용자 식별 정보(UID*x)의 조합을 특정한다.
이어서, CPU(30)는, 특정한 조에 포함되는 모든 이용자 식별 정보(UID*x) 중에서, 중복되는 이용자 식별 정보(UID*x)를 제외하고, 유니크한 이용자 식별 정보(UID*x)를 모두 추출한다(S600). 이 처리에 의해, 이용자 A의 모든 친구의 이용자 식별 정보(UID*x)가 추출된다. 추출한 모든 친구의 이용자 식별 정보(UID*x)는 후술하는 초대 가능한 이용자의 인원수 산출 처리 시에 사용된다.
이용자 A의 모든 친구의 이용자 식별 정보(UID*x)를 추출한 후, CPU(30)는, S172에서 추출한 조합에 있어서, 이용자 식별 정보(UID*x)의 수를 종별 정보(AppIDx)마다 집계한다(S173). 또한, CPU(30)는, 친구의 이용자 식별 정보(UID*x)의 집계수에 기초하여, 종별 정보(AppIDx)로 특정되는 게임의 인기순을 특정한다(S174).
이어서, CPU(30)는, 추출한 모든 종별 정보(AppIDx)와 이용자 식별 정보(UID*x)의 조합에 대하여 S700 내지 S713의 처리가 종료되었는지 여부를 판정한다(S601). 모든 조합에 대하여 S700 내지 S713의 처리가 종료되지 않은 경우에는(S601: "아니오"), CPU(30)는, 하나의 종별 정보(AppIDx)에 착안하여, 당해 종별 정보(AppIDx)에 대응하는 게임에 초대 가능한 이용자의 인원수의 산출 처리와, 당해 종별 정보(AppIDx)에 대응하는 게임에서 친구 신청 가능한 인원수의 산출 처리를 행한다.
먼저, CPU(30)는, 이용자 정보 테이블(TBL11)을 참조하여, 착안하는 AppIDx에서의 이용자 A의 참조 식별 정보(RefIDa)에 대응하는 이용자 식별 정보(UIDax)를 취득한다(S700). 예를 들어, 착안하는 종별 정보(AppIDx)가 「00000001」이며, 이용자 A의 참조 식별 정보(RefIDa)가 「00000011」인 것으로 하면, 이용자 식별 정보(UIDax)는 「XCV56714」가 된다.
이어서, CPU(30)는, 이용자 A 자신이 친구 상한수에 달하였는지 여부의 판단을 행하는 처리(S701 내지 S703)를 행한다. 먼저, CPU(30)는, 친구 상한수 테이블(TBL12)을 참조하여, 이용자 A의 이용자 식별 정보(UIDax)에 대응하는 친구 상한수를 취득한다(S702).
그리고, CPU(30)는, 취득한 친구 상한수가, 도 39의 S173에서 집계한 종별 정보(AppIDx)마다의 친구의 이용자 식별 정보(UID*x)의 수 중, 주목하는 종별 정보(AppIDx)에 대한 친구의 이용자 식별 정보(UID*x)의 수를 초과하는지 여부를 판정한다(S702). 이 판정 조건이 부정되는 경우에는(S702: "아니오"), 착안하는 종별 정보(AppIDx)에 대응하는 게임에 대해서, 이미 이용자 A에게 있어서의 친구의 이용자 식별 정보(UID*x)의 총 수가, 친구 상한수에 달하였으므로, 친구 신청이 불가능하게 된다. 따라서, CPU(30)는, 친구 신청이 불가능한 취지의 플래그를 세트한다(S703). 그러나, 상기 판정 조건이 부정되는 경우에는(S702: "예"), 착안하는 종별 정보(AppIDx)에 대응하는 게임에 대해서, 이용자 A에게 있어서의 친구의 이용자 식별 정보(UID*x)의 총 수는, 아직 친구 상한수에 달하지 않았으므로, 플래그를 세트하지 않고 다음의 처리로 이행한다.
이어서, 주목하는 종별 정보(AppIDx)에 대응하는 게임에 초대하는 것이 가능한 이용자를 특정하는 처리(S704 내지 S705)를 행한다. 먼저, CPU(30)는, 초대의 대상이 되는 게임을 플레이하고 있지 않은 이용자를 후보 이용자로 했을 때, 도 39의 S600에서 추출한 모든 친구의 이용자 식별 정보(UID*x) 중에서 주목하는 종별 정보(AppIDx)에 대응하는 게임을 플레이하고 있지 않은 후보 이용자의 이용자 식별 정보(UID*x)를 추출한다(S704). 구체적으로는, CPU(30)는, 모든 친구의 이용자 식별 정보(UID*x) 중, 하나의 이용자 식별 정보(UID*x)에 착안하여, 이용자 정보 테이블(TBL11)을 참조해서, 착안하는 하나의 이용자 식별 정보(UID*x)에 대응하는 친구의 참조 식별 정보(RefID*)를 취득한다. 또한, CPU(30)는, 취득한 참조 식별 정보(RefID*)에 대응하는 하나 또는 복수의 종별 정보(AppIDx)를 취득한다. 그리고, CPU(30)는, 취득한 하나 또는 복수의 종별 정보(AppIDx)에, 착안하는 종별 정보(AppIDx)가 포함되어 있는지 여부를 판단한다. 포함되어 있지 않은 경우에는, 당해 참조 식별 정보(RefID*)에 대응하는 친구는, 착안하는 종별 정보(AppIDx)에 대응하는 게임을 플레이하고 있지 않은 경우이므로, 당해 참조 식별 정보(RefID*)에 대응하는 이용자 식별 정보(UID*x)를 후보 이용자의 이용자 식별 정보(UID*x)로서 추출한다. 이상의 처리를, 도 39의 S600에서 추출한 모든 친구의 이용자 식별 정보(UID*x)에 대하여 행한다.
이어서, CPU(30)는, 인바이트 테이블(TBL14)을 참조하여, 착안하는 종별 정보(AppIDx)를 포함하는 레코드 중, 이용자 A를 나타내는 참조 식별 정보(RefIDa)가 초대원으로서 기록되고, 또한 후보 이용자의 이용자 식별 정보(UID*x)에 대응하는 참조 식별 정보(RefID*)가 초대처로서 기록되어 있는 레코드를 추출한다. 그리고, CPU(30)는, 추출한 레코드에 포함되는 후보 이용자의 참조 식별 정보(RefID*)에 대응하는 이용자 식별 정보(UID*x)를, S704에서 추출한 후보 이용자의 이용자 식별 정보(UID*x)로부터 제외하고, 인바이트 테이블(TBL14)에 기록되어 있지 않은 후보 이용자의 이용자 식별 정보(UID*x)를 추출하여, 집계한다(S705).
즉, 인바이트 테이블(TBL14)에는 초대중 또는 초대 완료의 초대원의 이용자와 초대처의 이용자의 조가 레코드로서 기록되어 있고, 이러한 레코드에 기록되어 있는 이용자라는 것은, 과거에 한번이라도 초대한 적이 있는 이용자가 된다. 따라서, 이렇게 과거에 한번이라도 초대한 적이 있는 이용자에 대해서는, 다시 초대하지 않도록 하고 있다. 이에 의해, 이용자 A가 초대 가능한 다른 이용자와 그 인원수를 특정할 수 있다. 집계된 초대 가능한 친구의 수는, 본 변형예의 제2 랭킹 페이지에서 게임마다 표시된다(후술하는 도 41의 영역(225)을 참조).
이어서, CPU(30)는, 착안하는 종별 정보(AppIDx)에 대응하는 애플리케이션에서 친구 신청이 가능한 이용자를 특정하는 처리(S706 내지 S711)를 행한다. 또한, S703의 처리에서 친구 신청이 불가능한 취지의 플래그가 세트되어 있는 경우, CPU(30)는, 당해 처리를 행하지 않고, 플래그를 리셋하고, S712로 진행한다.
먼저, CPU(30)는, 관계 테이블(TBL13)을 참조하여, 착안하는 종별 정보(AppIDx)에 대해서, 아직 친구로 되어 있지 않은 비친구인 이용자의 이용자 식별 정보(UID*x)를 추출한다(S706). CPU(30)는, 착안하는 종별 정보(AppIDx)에 대응하는 게임 이외에서 친구 신청을 행하는 이용자 A와 친구 관계에 있는 다른 이용자이며, 당해 게임을 이미 이용하고 있는 이용자를 추출하고(제1 조건), 또한, 관계 테이블(TBL13)을 참조하여, 당해 게임에서 이용자 A와 친구 관계가 구축되어 있지 않은 이용자(제2 조건)를 추출한다.
이어서, CPU(30)는, S706에서 추출한 모든 비친구의 이용자 식별 정보(UID*x)에 대해서, S708 내지 S710의 처리가 완료했는지 여부를 판정한다(S707). 판정 조건이 충족되는 경우(S707: "예"), CPU(30)는 처리를 S711로 진행시킨다. 한편, 판정 조건이 충족되지 않은 경우(S707: "아니오"), CPU(30)는 처리를 S708로 진행시키고, 관계 테이블(TBL13)을 참조하여 착안하는 비친구의 이용자 식별 정보(UID*x)의 친구수를 집계한다. 이 경우, CPU(30)는, 관계 테이블(TBL13)을 참조하여, 비친구의 이용자 식별 정보(UID*x)와 신청원 이용자 식별 정보(UID_From)가 일치하는 레코드로부터 신청처 참조 식별 정보(RefID_To)를 추출함과 함께, 비친구의 이용자 식별 정보(UID*x)와 신청처 이용자 식별 정보(UID_To)가 일치하는 레코드로부터 신청원 참조 식별 정보(RefID_From)를 추출한다. 그리고, 추출한 신청처 참조 식별 정보(RefID_To)와 추출한 신청원 참조 식별 정보(RefID_From)에 대응하는 이용자 식별 정보(UID*x)의 수가, 비친구의 이용자 식별 정보(UID*x)의 수가 되고, CPU(30)는 이것을 집계한다.
이어서, CPU(30)는, 친구 상한수 테이블(TBL12)을 참조하여 착안하는 비친구의 이용자 식별 정보(UID*x)의 친구 상한수를 취득한다(S709). 이 후, CPU(30)는, 취득한 친구 상한수와 집계한 친구수를 비교하여, 집계수가 친구 상한수에 달하지 않은 경우에, 비친구의 이용자를 친구 신청 가능하다고 판단하고(제3 조건을 충족), 집계수가 친구 상한수에 달한 경우에 비친구의 이용자를 친구 신청 불가능하다고 판단한다(S710). 이어서, CPU(30)는 처리를 S707로 되돌려서, S707의 판정 조건이 충족될 때까지 S707부터 S710을 반복하여, S707의 판정 조건이 충족되면, 처리를 S711로 진행시킨다.
S711에서, CPU(30)는, 친구 신청 가능한 비친구의 이용자 식별 정보(UID*x)를 특정하고, 비친구의 인원수를 집계한다. 비친구의 집계수는, 당해 게임 이외의 다른 게임에서 친구 관계에 있고 당해 게임에서 친구 관계가 아닌 이용자의 인원수이다. 비친구의 집계수는, 본 변형예의 제2 랭킹 페이지에서 게임마다 표시된다(후술하는 도 41의 영역(226)을 참조).
이어서, CPU(30)는, 착안하는 종별 정보(AppIDx)에 대응하는 게임에 대해서, S705의 처리에서 집계한 초대 가능한 인원수 및 S711의 처리에서 집계한 친구 신청 가능한 인원수를 일시적으로 변수 영역이나 워크 에리어에 기억시킨다(S712).
이 후, CPU(30)는, 처리를 도 39에 나타내는 S601로 되돌린다. 그리고, S172에서 추출한 모든 종별 정보(AppIDx)에 대하여 S700부터 S713의 처리를 종료하면(S601: "예"), 애플리케이션 정보 테이블(TBL15)을 참조하여, 추출한 종별 정보(AppIDx)에 대응하는 게임명, 설명 정보 및 아이콘 정보를 취득한다. 이 후, CPU(30)는, S173에서 집계한 각 종별 정보(AppIDx)에 대응하는 게임을 플레이하고 있는 친구수, S512에서 기억시킨 각 종별 정보(AppIDx)에 대응하는 게임에 대하여 초대 가능한 인원수 및 친구 신청 가능한 인원수, 및 S175에서 취득한 각 종별 정보(AppIDx)에 대응하는 게임명, 설명 정보 및 아이콘 정보에 기초하여, 랭킹 페이지를 생성한다(S176). 이때, CPU(30)는, 즐기고 있는 친구가 많은 순서대로 게임의 설명 등을 배치하여 제2 랭킹 페이지를 생성한다. 단말 장치(2)는, 관리 서버(3A)로부터 제2 랭킹 페이지를 포함하는 액세스 응답을 수신하면, 제2 랭킹 페이지를 디스플레이(25)에 표시한다.
또한, S703의 처리에서 친구 신청이 불가능한 취지의 플래그가 세트되어 있는 경우에는, 친구 신청 가능한 인원수 대신에, 그 표시를 비표시로 하거나, 「신청 가능 인원수에 달했기 때문에 신청할 수 없습니다」라는 표시를 한다.
도 41에 본 변형예에서의 제2 랭킹 페이지의 일례를 나타낸다. 이 예에서는, 랭킹 표시 영역(220, 230, 240)이 설치되어 있고, 랭킹이 높은 순서대로 게임을 랭킹 표시 영역(220)→랭킹 표시 영역(230)→랭킹 표시 영역(240)에 표시한다.
영역(221)에는 애플리케이션 정보 테이블(TBL15)로부터 판독한 아이콘 정보에 기초하여 아이콘이 표시되고, 영역(222)에는 애플리케이션명(게임명)이 표시된다. 이들 정보는, 상술한 S175의 처리로 취득된다. 다음으로 영역(223)에는, 이용자 A가 플레이하고 있는 게임 중 어느 하나에서, 이용자 A와 친구 관계에 있고 게임 b를 즐긴 적이 있는 다른 이용자의 인원수가 표시된다. 이 정보는, 상술한 S173의 처리로 취득된다. 영역(224)에는, 게임 b의 설명이 표시된다. 이 정보는, 상술한 S175의 처리로 취득된다. 또한, 여기에서 표시되는 게임은 이용자 A가 플레이하고 있지 않은 것도 포함된다.
또한, 영역(225)에는, 이용자 A가 게임 b에 대하여 다른 게임에서 친구의 이용자를, 앞으로 몇 사람 초대 가능한지가 표시된다. 초대 가능한 인원수는, S705의 처리에서 집계된다. 그리고, 영역(226)에는, 이용자 A가 게임 b에서, 새롭게 친구 신청 가능한 이용자의 수가 표시된다. 친구 신청 가능한 인원수는, S711의 처리에서 집계된다.
이상과 같이, 본 변형예에 의하면, 구체적으로 어느 애플리케이션의 어느 친구를 초대하고 싶은지가 미리 결정되어 있는 경우에, 그 상대가 요구된 애플리케이션을 아직 이용하고 있지 않은 것이 판명되면, 초대 가능한 이용자의 표시로 전환함으로써, 친구 신청이 아니라 초대를 할 수 있게 된다. 이와 같이, 어떤 애플리케이션에 친구 신청하고 싶은 상대가 당해 애플리케이션을 이용하고 있지 않은 경우도 있을 수 있으므로, 친구 신청의 기능과 초대의 기능을 조로 해서 단말 장치(2)에서 이용자에게 제공시키는 것은, 이용자에게 있어서 편리성이 높아지게 된다.
또한, 본 변형예에 의하면, 요구된 애플리케이션에서 친구 관계가 구축되어 있는 이용자가 애플리케이션을 이용하고 있고(제1 조건), 당해 애플리케이션에 대하여 요구 이용자와 친구 관계가 구축되어 있지 않고(제2 조건), 당해 애플리케이션에서 친구 상한수에 달하지 않은(제3 조건) 이용자의 수를 표시하는 것이 가능하게 된다. 이에 의해, 요구된 애플리케이션에 대해서, 친구 신청 가능한 인원수를 알 수 있어, 편리성이 향상된다.
또한, 본 변형예에 의하면, 요구된 애플리케이션에 대해서, 초대 가능한 친구의 인원수를 알 수 있어, 편리성이 향상된다.
또한, 본 변형예는, 제2 랭킹 처리를 행할 때에, 랭킹 표시된 각 게임에 초대 가능한 인원수 및 각 게임에서 새롭게 친구 신청 가능한 인원수를 표시하는 예에 대하여 설명하였다. 그러나, 본 변형예는, 제1 랭킹 처리를 행할 때에도 마찬가지로 적용 가능하다. 제1 랭킹 처리를 행할 때에 본 변형예를 적용하는 경우에는, 도 9에 나타내는 화면에서 표시되어 있는 게임(도 9의 예에서는 게임 b)에 대응하는 종별 정보(AppIDx)에 대해서, 도 40에 나타내는 S700부터 S712까지의 처리를 행하도록 하면 된다.
(11) 상술한 실시 형태 및 변형예에서는, 관리 서버(3A)에 있어서, 이용자 정보 테이블(TBL11), 친구 상한수 테이블(TBL12) 및 관계 테이블(TBL13)을 설치하고, 각종 정보를 집약하여 관리하였다. 이러한 일원적인 관리를 행하는 경우에, 애플리케이션 서버(3B, 3C, 3D…)의 일부 또는 모두에 있어서, 개별의 이용자 정보 테이블(TBL11a), 개별의 친구 상한수 테이블(TBL12a), 및 개별의 관계 테이블(TBL13a)을 설치하고, 이용자 정보 테이블(TBL11)과 이용자 정보 테이블(TBL11a), 친구 상한수 테이블(TBL12)과 친구 상한수 테이블(TBL12a) 및 관계 테이블(TBL13)과 관계 테이블(TBL13a)의 동기를 취하도록 해도 된다.
도 42에 변형예에 따른 애플리케이션 시스템(100)의 블록도를 나타낸다. 이 예에서는, 애플리케이션 서버(3B)가, 개별의 이용자 정보 테이블(TBL11a), 개별의 친구 상한수 테이블(TBL12a), 및 개별의 관계 테이블(TBL13a)을 구비하고, 다른 애플리케이션 서버(3C, 3D…)는, 그들 테이블을 구비하지 않는 것으로 한다. 단, 다른 애플리케이션 서버(3C, 3D…)에서도 그들 테이블을 구비해도 된다.
이하의 설명에서는, 관리 서버(3A)와 애플리케이션 서버(3B)의 테이블을 구별하기 위해서, 관리 서버(3A)에 설치된 이용자 정보 테이블(TBL11), 친구 상한수 테이블(TBL12) 및 관계 테이블(TBL13)을 제1 이용자 정보 테이블(TBL11), 제1 친구 상한수 테이블(TBL12) 및 제1 관계 테이블(TBL13)이라고 칭하고, 애플리케이션 서버(3B)에 설치된, 이용자 정보 테이블(TBL11a), 친구 상한수 테이블(TBL12a) 및 관계 테이블(TBL13a)을, 제2 이용자 정보 테이블(TBL11a), 제2 친구 상한수 테이블(TBL12a) 및 제2 관계 테이블(TBL13a)이라고 칭한다.
도 43에 제2 이용자 정보 테이블(TBL11a)의 데이터 구조를 나타낸다. 이 도에 도시한 바와 같이 제2 이용자 정보 테이블(TBL11a)에는, 복수의 레코드가 기록되어 있다. 1개의 레코드는, 레코드를 일의적으로 식별하는 레코드 식별 정보(ID), 이용자를 일의적으로 식별하는 이용자 식별 정보(UID) 및 마지막으로 로그인한 일자를 나타내는 라스트 로그인 정보(LastLogin)를 포함한다. 여기서, 도 3에 도시하는 제1 이용자 정보 테이블(TBL11)에 기억되어 있는 참조 식별 정보(RefID)를 제2 이용자 정보 테이블(TBL11a)에 기억하지 않는 것은, 참조 식별 정보(RefID)는, 관리 서버(3A)에서의 관리용의 식별 정보이며, 애플리케이션 서버(3B)에서는 관리할 필요가 없기 때문이다. 또한, 제1 이용자 정보 테이블(TBL11)에 기억되어 있는 종별 정보(AppID)를 제2 이용자 정보 테이블(TBL11a)에 기억하지 않는 것은, 애플리케이션 서버(3B)가 제공하는 것은 게임 b이며 애플리케이션의 종별은 일의적으로 특정되기 때문에, 종별 정보(AppID)를 기억할 필요가 없기 때문이다.
도 44에 제2 친구 상한수 테이블(TBL12a)의 데이터 구조를 나타낸다. 이 도에 도시한 바와 같이 제2 친구 상한수 테이블(TBL12a)에는 복수의 레코드가 기록되어 있다. 1개의 레코드는, 레코드 식별 정보(ID), 이용자 식별 정보(UID) 및 친구 상한수(Limit)가 대응지어져서 기억된다. 도 4에 도시하는 제1 친구 상한수 테이블(TBL12)에는, 모든 애플리케이션 서버(3B, 3C, 3D…)에서 관리하는 친구 상한수(Limit)가 집약되어 있는 데 반해, 도 44에 나타내는 제2 친구 상한수 테이블(TBL12a)은, 애플리케이션 서버(3B)에서 관리하는 게임 b에 관한 친구 상한수(Limit)가 기억되어 있는 점에서 상이하다.
도 45에 제2 관계 테이블(TBL13a)의 데이터 구조를 나타낸다. 제2 관계 테이블(TBL13a)에는 복수의 레코드가 기록되어 있다. 1개의 레코드는, 레코드 식별 정보(ID), 종별 정보(AppID), 관계의 종별을 나타내는 그룹 정보(Group), 신청원인 이용자의 이용자 식별 정보(UID)인 신청원 이용자 식별 정보(UID_From), 신청처인 이용자의 이용자 식별 정보(UID)인 신청처 이용자 식별 정보(UID_To) 및 신청의 상태를 나타내는 상태 정보(Stat)가 대응지어져서 기억된다. 도 5에 도시하는 제2 관계 테이블(TBL13)에서 기억하는 신청원의 이용자의 참조 식별 정보(RefID)인 신청원 참조 식별 정보(RefID_From) 및 신청처의 이용자의 참조 식별 정보(RefID)인 신청처 참조 식별 정보(RefID_To)를 기억하지 않는 것은, 참조 식별 정보(RefID)는, 관리 서버(3A)에서의 관리용의 식별 정보이며, 애플리케이션 서버(3B)에서는 관리할 필요가 없기 때문이다.
설명을 도 42로 되돌린다. 애플리케이션 서버(3B)는, 또한 동기부(50)를 구비한다. 동기부(50)는, 관리 서버(3A)의 이용자 정보 동기부(10), 친구 상한수 동기부(18) 및 친구 관계 동기부(19)와 연계하여, 제2 이용자 정보 테이블(TBL11a), 제2 친구 상한수 테이블(TBL12a) 및 제2 관계 테이블(TBL13a)과, 제1 이용자 정보 테이블(TBL11), 제1 친구 상한수 테이블(TBL12) 및 제1 관계 테이블(TBL13)의 기억 내용을 동기시키도록 동작한다. 구체적으로는 애플리케이션 서버(3B)의 CPU가, 소정의 API(Application Programming Interface)를 실행함으로써 실현된다.
이용자 정보 동기부(10)는, 제1 이용자 정보 테이블(TBL11)의 기억 내용과 제2 이용자 정보 테이블(TBL11a)의 기억 내용을 동기시킨다. 구체적으로는, 애플리케이션 서버(3B)에서, 제2 이용자 정보 테이블(TBL11a)의 기억 내용에 변화가 있으면, 동기부(50)는 변경 내용을 나타내는 이용자 정보 변경 통지를 관리 서버(3A)에 송신한다. 관리 서버(3A)의 이용자 정보 동기부(10)는, 이용자 정보 변경 통지를 수신하면, 제1 이용자 정보 테이블(TBL11)의 기억 내용을 갱신한다. 예를 들어, 새로운 이용자 식별 정보(UID)가 추가된 경우, 이용자 식별 정보(UID)가 삭제된 경우, 라스트 로그인 정보(LastLogin)가 변경된 경우가 해당한다.
또한, 동기부(50)는, 소정의 타이밍에 이용자 정보 변경 통지를 관리 서버(3A)에 송신하면 된다. 예를 들어, 이용자 식별 정보(UID) 및 라스트 로그인 정보(LastLogin)의 변경이 있으면 즉시 이용자 정보 변경 통지를 송신해도 되고, 소정 시각에 변경분을 통합하여 송신해도 된다. 또한, 이용자 정보 동기부(10)가 소정의 타이밍에 이용자 정보의 변경을 애플리케이션 서버(3B)에 문의하면, 동기부(50)는, 전회의 문의로부터의 변경 내용을 포함하는 이용자 정보 변경 통지를 관리 서버(3A)에 송신해도 된다. 이 경우, 관리 서버(3A)의 이용자 정보 동기부(10)는 이용자 정보 변경 통지를 수신하면, 제1 이용자 정보 테이블(TBL11)의 기억 내용을 갱신한다.
친구 상한수 동기부(18)는, 접수부(11)에서 접수한 종별 정보(AppID)에 대응하는 애플리케이션 서버에서 설정된 이용자의 친구 상한수(Limit)를 취득하는 취득부로서 기능한다. 친구 상한수 동기부(18)는, 제1 친구 상한수 테이블(TBL12)의 기억 내용과 제2 친구 상한수 테이블(TBL12a)의 기억 내용을 동기시킨다. 구체적으로는, 애플리케이션 서버(3B)에 있어서, 제2 친구 상한수 테이블(TBL12a)의 기억 내용에 변화가 있으면, 동기부(50)는 변경 내용을 나타내는 친구 상한수 변경 통지를 관리 서버(3A)에 송신한다. 관리 서버(3A)의 친구 상한수 동기부(18)는, 친구 상한수 변경 통지를 수신하면, 제1 친구 상한수 테이블(TBL12a)의 기억 내용을 갱신한다.
친구 관계 동기부(19)는, 제1 관계 테이블(TBL13)의 기억 내용과 제2 관계 테이블(TBL13a)의 기억 내용을 동기시킨다. 구체적으로는, 애플리케이션 서버(3B)에 있어서, 제2 관계 테이블(TBL13)의 기억 내용에 변화가 있으면, 동기부(50)는 변경 내용을 나타내는 친구 관계 변경 통지를 관리 서버(3A)에 송신한다. 관리 서버(3A)의 친구 관계 동기부(19)는, 친구 관계 변경 통지를 수신하면, 제1 관계 테이블(TBL13)의 기억 내용을 갱신한다.
동기부(50)는, 애플리케이션 서버(3B)에 있어서, 친구 신청이 승인되어 친구 관계가 성립한 경우에, 친구 관계 변경 통지를 관리 서버(3A)에 송신한다. 친구 신청이 거부되어 불성립이 되었을 경우, 동기부(50)는, 친구 관계 변경 통지를 관리 서버(3A)에 송신하여 제1 관계 테이블(TBL13)의 기억 내용과 제2 관계 테이블(TBL13a)의 기억 내용을 동기시켜도 되지만, 이 점은 필수가 아니며, 친구 관계 변경 통지를 송신하지 않고 동기를 취하지 않아도 된다. 또한, 상태 정보(Stat)에 대해서도 기억 내용을 동기시키도록 하면, 관리 서버(3A)에서 친구 신청중인 것을 알 수 있다.
또한, 애플리케이션 서버(3B)에 있어서, 친구 관계가 해제되면, 제2 관계 테이블(TBL13a)에 친구 관계가 해제된 것이 반영되는데, 동기부(50)는 이것을 검지하여, 친구 관계 변경 통지를 관리 서버(3A)에 송신한다. 친구 관계 동기부(19)는, 친구 관계 변경 통지를 수신하면, 친구 관계가 해제된 것을 제1 관계 테이블(TBL13)의 기억 내용에 반영시킨다.
관리 서버(3A)와 연계하지 않는 애플리케이션 서버에서는, 제2 이용자 정보 테이블(TBL11a), 제2 친구 상한수 테이블(TBL12a) 및 제2 관계 테이블(TBL13a)을 사용하여, 당해 애플리케이션 서버로 닫힌 서비스를 제공하고 있다. 이 변형예에 의하면, 그러한 애플리케이션 서버에서도, API 등에 의해 동기부(50)를 추가함으로써, 애플리케이션 시스템(100)에 용이하게 도입하는 것이 가능하게 된다.
이와 같이, 본 변형예에 의하면, 애플리케이션 서버에 설치된 제2 이용자 정보 테이블(TBL11a) 및 제2 관계 테이블(TBL13a)과, 관리 서버(3A)에 설치된 제1 이용자 정보 테이블(TBL11) 및 제1 관계 테이블(TBL13)의 동기를 취하므로, 애플리케이션 서버에서의 개별의 애플리케이션의 관리를 관리 서버(3A)에 용이하게 반영시킬 수 있다.
또한, 본 변형예에 의하면, 애플리케이션 서버에 설치된 제2 친구 상한수 테이블(TBL12a)과, 관리 서버(3A)에 설치된 제1 친구 상한수 테이블(TBL12)의 동기를 취하므로, 애플리케이션 서버에서의 개별의 애플리케이션에서의 친구 상한수의 관리를 관리 서버(3A)에 용이하게 반영시킬 수 있다.
또한, 반영시킨 개별의 애플리케이션의 관리에 기초하여, 상술한 바와 같은 문의 처리를 행할 수 있다.
(12) 상술한 실시 형태 및 각 변형예에서는, 이용자 정보 테이블(액세스 테이블)(TBL11), 친구 상한수 테이블(TBL12), 관계 테이블(TBL13), 인바이트 테이블(TBL14)을, 관리 서버(3A)의 하드 디스크(33)에 기억시키는 예에 대하여 설명하였다. 그러나, 본 발명은 이러한 예에 한정되는 것은 아니며, 도 46에 도시한 바와 같이, 통신망(1)을 통해 관리 서버(3A)와 통신 가능한 스토리지 서버(60)에, 이용자 정보 테이블(액세스 테이블)(TBL11), 친구 상한수 테이블(TBL12), 관계 테이블(TBL13), 인바이트 테이블(TBL14)을 기억시키도록 해도 된다. 이 경우에는, 관리 서버(3A)는, 필요에 따라 스토리지 서버(60)에 액세스하여, 각 테이블로부터 정보를 판독하도록 하면 된다.
또한, 도 47에 도시한 바와 같이, 통신망(1)을 통해 관리 서버(3A)와 통신 가능한 스토리지 서버(70)에, 이용자 정보 테이블(액세스 테이블)(TBL11), 친구 상한수 테이블(TBL12), 관계 테이블(TBL13)을 기억시키도록 해도 된다. 또한, 통신망(1)을 통해 애플리케이션 서버(3B, 3C, 3D…)와 통신 가능한 스토리지 서버(80)에, 이용자 정보 테이블(TBL11a), 친구 상한수 테이블(TBL12a), 관계 테이블(TBL13a)을 기억시키도록 해도 된다.
이 경우에는, 관리 서버(3A)는, 필요에 따라 스토리지 서버(70)에 액세스하여, 각 테이블로부터 정보를 판독하도록 하면 된다. 또한, 애플리케이션 서버(3B, 3C, 3D…)는, 필요에 따라 스토리지 서버(60)에 액세스하여, 각 테이블로부터 정보를 판독하도록 하면 된다.
(13) 상술한 실시 형태 및 각 변형예에서는, 관리 서버(3A) 또는 단말 장치(2)에서 실행되는 프로그램은, 컴퓨터 판독 가능한 기록 매체에 기억시켜도 된다. 이 기록 매체를 사용하면, 예를 들어 상기 컴퓨터에 상기 프로그램을 인스톨할 수 있다.
또한, 여기에서 말하는 「컴퓨터」란, OS나 주변기기 등의 하드웨어를 포함하는 것으로 한다. 또한, 「컴퓨터」는, 인터넷이나 WAN, LAN, 전용 회선 등의 통신 회선을 포함하는 네트워크를 통해 접속된 복수의 컴퓨터 장치를 포함해도 된다. 또한, 「컴퓨터 판독 가능한 기록 매체」란, 플렉시블 디스크, 광자기 디스크, ROM, CD-ROM, 컴퓨터에 내장되는 하드 디스크 등의 비일시적 기록 매체이어도 된다.
또한 「컴퓨터 판독 가능한 기록 매체」란, 네트워크를 통해 프로그램이 송신된 경우의 서버나 클라이언트가 되는 컴퓨터 시스템 내부의 휘발성 메모리(RAM)와 같이, 일정 시간 프로그램을 유지하고 있는 것도 포함하는 것으로 한다. 또한, 상기 프로그램은, 상술한 기능의 일부를 실현하기 위한 것이어도 된다. 또한, 상술한 기능을 컴퓨터 시스템에 이미 기록되어 있는 프로그램과의 조합으로 실현할 수 있는 것, 소위 차분 파일(차분 프로그램)이어도 된다. 또한, 본 발명에서의 기능 또는 그 일부를 실현하기 위한 프로그램을 배신하는 배신 서버 및 당해 배신 서버에 구비된 기억 매체 및 당해 배신 서버의 외부에 존재하고, 당해 프로그램을 상기 배신 서버에 의해 배신하기 위해 기억하고 있는 기억 매체도, 본 발명의 범위에 포함된다.
또한, 상술한 기능의 일부 또는 모두를, LSI(Large Scale Integration) 등의 집적 회로로서 실현해도 된다. 상술한 각 기능은 개별로 프로세서화해도 되고, 일부 또는 모두를 집적하여 프로세서화해도 된다. 또한, 집적 회로화의 방법은 LSI에 한하지 않고 전용 회로 또는 범용 프로세서로 실현해도 된다. 또한, 반도체 기술의 진보에 의해 LSI를 대체하는 집적 회로화의 기술이 출현한 경우, 당해 기술에 의한 집적 회로를 사용해도 된다.
<4. 실시 형태 및 변형예로부터 유도되는 발명>
친구 신청 처리에 관한 발명 외에, 상술한 실시 형태 및 변형예로부터, 이하에 설명하는 초대 처리에 관한 발명 및 문의 처리에 관한 발명 등도 유도된다.
(1) 초대 처리에 관한 발명
어떤 애플리케이션에서, 다른 애플리케이션에서 친구 관계가 된 이용자를 다른 애플리케이션에 초대 가능하게 하기 위해서, 본 발명에 따른 관리 서버는, 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말 장치와 통신 가능한 서버이며, 초대의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보를 접수하는 접수부와, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있지 않을 것을 조건으로 했을 때, 상기 조건을 충족하는 후보 이용자의 일부 또는 모두를 특정하는 특정부와, 상기 특정부에서 특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부와, 상기 요구 이용자가, 상기 단말 장치에 표시된 후보 이용자 중에서 선택한 후보 이용자에 대하여 초대 신청을 통지하는 통지부를 구비한다.
본 발명에 의하면, 복수의 애플리케이션 서버와 통신 가능한 관리 서버는, 요구 이용자가 지정한 초대의 대상이 되는 애플리케이션을 이용하고 있지 않은 후보 이용자를 특정한다. 따라서, 요구 이용자는, 자신이 이용하고 있는 애플리케이션이며, 이것을 이용하고 있지 않은 후보 이용자 중에서 초대의 대상이 되는 이용자를 선택할 수 있다. 이에 의해, 다른 이용자를 자신이 이용하고 있는 애플리케이션 서비스에 용이하게 초대할 수 있다.
또한, 상기 조건에, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 것을 부가해도 된다. 이 경우에는, 요구 이용자와 다른 애플리케이션에서 친구 관계가 구축되어 있는 이용자를 초대할 수 있으므로, 과거에 형성된 친구에게 새로운 애플리케이션을 널리 퍼뜨리는 것이 가능하게 된다.
또한, 통지부는, 선택된 후보 이용자에 대하여 초대 신청을 통지하는 것이라면, 어떤 방법이어도 좋으며, 예를 들어 등록된 메일 어드레스에 대하여 초대 신청의 메일을 송신해도 되고, 또는, 선택된 후보 이용자가 관리하는 페이지에 초대 신청이 있다는 취지를 표시하도록 해도 된다. 또한, 다른 소셜 미디어나 게시판에 초대 기사를 투고하도록 송신해도 된다.
상술한 관리 서버에 있어서, 상기 종별 정보에 관련지어서 당해 종별 정보가 나타내는 애플리케이션을 이용하고 있는 이용자 정보를 기억하는 이용자 정보 테이블을 구비하고, 상기 특정부는, 상기 이용자 정보 테이블을 참조하여, 상기 조건을 충족하는 후보 이용자를 특정하는 것이 바람직하다.
본 발명에 의하면, 각종 애플리케이션의 종별 정보와 모든 이용자의 이용자 식별 정보를 대응지어서 기억하는 이용자 정보 테이블을 구비하므로, 복수의 애플리케이션의 이용자를 일원적으로 관리하는 것이 가능하게 된다.
상술한 관리 서버에 있어서, 상기 종별 정보에 관련지어서, 친구 관계가 되는 친구 신청을 행한 이용자의 이용자 정보와 친구 신청을 수락한 이용자의 이용자 정보의 조를 기억하는 친구 관계 테이블을 구비하고, 상기 특정부는, 상기 조건 외에도, 상기 친구 관계 테이블을 참조하여, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되는 이용자를 상기 후보 이용자로서 특정하는 것이 바람직하다.
본 발명에 의하면, 친구 신청에 있어서 신청측과 승낙측의 조를 기억함으로써, 하나의 이용자 정보를 키로 해서 당해 이용자 정보와 친구 관계에 있는 모든 이용자 정보를 기억할 필요는 없으므로, 데이터의 기억 용량을 삭감하는 것이 가능하게 된다.
또한, 상기 특정부는, 상기 친구 관계 테이블을 참조하여, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에 대응하는 종별 정보와 관련지어서 기억되어 있는 상기 이용자 정보의 조 중, 친구 신청을 행한 이용자의 이용자 정보가 상기 요구 이용자의 이용 정보와 일치하는 친구 신청을 수락한 이용자의 이용자 정보를 추출함과 함께, 친구 신청을 수락한 이용자의 이용자 정보가 상기 요구 이용자의 이용자 정보와 일치하는 친구 신청을 행한 이용자의 이용자 정보를 추출하고, 추출한 이용자 정보의 이용자를, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되는 후보 이용자로 하는 것이 바람직하다.
상술한 관리 서버에 있어서, 상기 표시 제어부는, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션을 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키고, 상기 특정부는, 상기 단말 장치에서 상기 요구 이용자가 선택한 이용 완료 애플리케이션에서 상기 조건을 충족하는 후보 이용자의 일부 또는 모두를 특정하는 것이 바람직하다.
본 발명에 의하면, 이용 완료 애플리케이션을 선택할 수 있도록 요구 이용자의 단말 장치에 표시시키고, 선택한 이용 완료 애플리케이션에 대하여 친구 관계에 있을 것이 후보 이용자의 요건이 되므로, 요구 이용자는, 초대하려고 하는 애플리케이션과 유사한 이용 완료 애플리케이션을 선택하는 등, 기호에 맞춘 선택이 가능하게 된다.
상술한 관리 서버에 있어서, 상기 특정부는, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에 대해서, 초대가 가능한 인원수를 특정하고, 상기 표시 제어부는, 상기 특정부가 특정한 초대 가능한 인원수를 상기 요구 이용자의 단말 장치에 표시시키는 것이 바람직하다.
본 발명에 의하면, 초대 신청이 가능한 인원수를 알 수 있으므로, 요구 이용자에게 편리성이 대폭 향상된다. 또한, 초대 신청이 가능한 인원수는, 이용 완료 애플리케이션마다 특정하여, 이용 완료 애플리케이션마다 요구 이용자의 단말 장치에 표시시켜도 되고, 복수의 이용 완료 애플리케이션의 합계의 초대 신청이 가능한 인원수를 특정하고, 이것을 요구 이용자의 단말 장치에 표시시켜도 된다.
상술한 관리 서버에 있어서, 상기 종별 정보에 관련지어서, 초대를 한 이용자의 이용자 정보와 초대를 받은 이용자의 이용자 정보의 조와, 초대의 상태를 나타내는 상태 정보를 기억한 초대 테이블을 구비하고, 상기 특정부는, 상기 초대 테이블을 참조하여, 상기 접수부에서 접수한 종별 정보와 관련지어서 기억되어 있고, 상기 요구 이용자의 이용자 정보와 초대한 이용자의 이용자 정보가 일치하고, 또한 상기 상태 정보가 적어도 거부를 나타내는 레코드의 초대를 받은 이용자의 이용자 정보를 특정하여, 특정한 이용자를 상기 후보 이용자로부터 제외하는 것이 바람직하다.
본 발명에 의하면, 초대의 상태를 나타내는 상태 정보와 이용자 정보를 대응지어서 초대 테이블에서 관리하므로, 초대 테이블을 참조함으로써, 초대의 상태를 알 수 있다. 그리고, 상태 정보가 거부를 나타내는 경우에는, 후보 이용자로부터 제외되므로, 초대를 거부했음에도 불구하고 다시 초대를 하여 폐를 끼치는 행위를 미연에 방지할 수 있다.
상술한 관리 서버에 있어서, 상기 상태 정보가 나타내는 상태는, 초대를 거부 또는 승인한 것을 나타내는 제1 상태를 포함하고, 상기 상태 정보가 적어도 초대의 거부를 나타낸다는 것은, 상기 상태 정보가 상기 제1 상태인 것이 바람직하다.
본 발명에 의하면, 거부와 승인을 통합하여 제1 상태로 하고 있다. 따라서, 초대가 거부된 경우뿐만 아니라, 초대가 승인된 경우에도 후보 이용자로부터 제외된다. 초대를 승인한 이용자는, 애당초 초대의 대상이 되는 애플리케이션을 이미 이용하고 있기 때문에, 초대할 필요가 없다. 이러한 데이터 구조를 채용함으로써, 거부한 이용자와 초대받은 이용자를 동시에 배제할 수 있으므로 처리 부하가 경감된다.
상술한 관리 서버에 있어서, 상기 상태 정보가 나타내는 상태는, 초대 신청중인 것을 나타내는 제2 상태를 포함하고, 상기 특정부는, 상기 초대 테이블을 참조하여, 상기 접수부에서 접수한 종별 정보와 관련지어서 기억되어 있고, 상기 요구 이용자의 이용자 정보와 초대한 이용자의 이용자 정보가 일치하고, 또한 상기 상태 정보가 상기 제2 상태를 나타내는 레코드의 초대를 받은 이용자의 이용자 정보를 추출하여, 추출한 이용자와 상기 특정한 이용자를, 상기 후보 이용자로부터 제외하는 것이 바람직하다.
본 발명에 의하면, 초대 신청중인 이용자도 후보 이용자로부터 제외되기 때문에, 신청중임에도 불구하고 다시 초대를 신청한다는 헛수고를 없애고, 관리 서버의 처리 부하를 경감할 수 있다.
상술한 관리 서버에 있어서, 초대한 이용자와 초대를 거부한 이용자를 관리하는 관리부를 구비하고, 상기 특정부는, 상기 관리부를 사용하여, 상기 요구 이용자가 초대한 이용자로서 관리되어 있는 경우, 초대를 거부한 이용자를 특정하고, 특정한 이용자를 상기 후보 이용자로부터 제외하는 것이 바람직하다. 본 발명에 의하면, 초대한 이용자와 초대를 거부한 이용자를 대응지어서 관리하므로, 일단 거부된 이용자를 다시 초대하는 것을 미연에 방지할 수 있다.
상술한 관리 서버에 있어서, 상기 종별 정보에 관련지어서, 초대를 한 이용자의 이용자 정보와 초대를 받은 이용자의 이용자 정보의 조와, 초대의 상태를 나타내는 상태 정보와, 초대한 일시를 나타내는 초대 일시 정보를 기억한 초대 테이블을 구비하고, 상기 특정부는, 상기 초대 테이블을 참조하여, 상기 접수부에서 접수한 종별 정보와 관련지어서 기억되어 있어, 상기 요구 이용자의 이용자 정보와 초대한 이용자의 이용자 정보가 일치하고, 또한 상기 상태 정보가 적어도 초대의 거부를 나타내는 레코드와, 상기 상태 정보가 초대의 신청중을 나타내고, 상기 초대 일시 정보가 나타내는 일시로부터 소정 기간이 경과한 레코드에 대해서, 초대를 받은 이용자의 이용자 정보를 특정하고, 특정한 이용자를 상기 후보 이용자로부터 제외하는 것이 바람직하다.
본 발명에 의하면, 초대를 신청중인 이용자에 대하여 다시 초대 신청을 허용한다. 이에 의해, 초대를 승인할지 여부를 고민하고 있는 이용자에 대하여 다시 초대함으로써, 애플리케이션 서비스에 대한 참가를 재촉할 수 있다. 그러나, 몇 번이고 초대하는 것은 폐를 끼친다. 따라서, 본 발명은 상태 정보가 신청중을 나타내고 있어도, 초대의 일시로부터 소정 기간이 경과하면, 후보 이용자로부터 제외하고 있다. 이에 의해, 애플리케이션 서비스에 대한 참가를 재촉하면서, 폐를 끼치는 행위를 방지하는 것이 가능하게 된다.
보다 구체적으로는, 상기 상태 정보가 나타내는 상태는, 초대를 거부 또는 승인한 것을 나타내는 제1 상태와, 초대 신청중인 것을 나타내는 제2 상태를 포함하고, 상기 상태 정보가 적어도 초대의 거부를 나타낸다는 것은, 상기 상태 정보의 상태가 상기 제1 상태이며, 상기 상태 정보가 초대의 신청중을 나타낸다는 것은, 상기 상태 정보의 상태가 상기 제2 상태인 것이 바람직하다. 이 경우에는, 거부와 승인을 하나의 상태로서 관리할 수 있으므로, 데이터 구조를 간소화할 수 있다.
상술한 관리 서버에 있어서, 상기 종별 정보에 관련지어서, 초대를 한 이용자의 이용자 정보와 초대를 받은 이용자의 이용자 정보의 조와, 초대의 상태를 나타내는 상태 정보와, 초대한 일시를 나타내는 초대 일시 정보를 기억한 초대 테이블을 구비하고, 상기 특정부는, 상기 초대 테이블을 참조하여, 상기 접수부에서 접수한 종별 정보와 관련지어서 기억되어 있어, 상기 요구 이용자의 이용자 정보와 초대한 이용자의 이용자 정보가 일치하고, 또한 상기 상태 정보가 적어도 초대의 거부를 나타내는 레코드에 대해서, 초대받은 이용자의 이용자 정보를 특정하고, 특정한 이용자를 상기 후보 이용자로부터 제외하고, 상기 초대 신청을 통지한 일시로부터 소정 기간이 경과해도 초대받은 이용자에게서 응답이 없는 경우, 상기 상태 정보의 상태를 초대의 신청중에서 초대의 거부로 재기입하는 재기입부를 구비하는 것이 바람직하다.
본 발명에 의하면, 초대 신청을 통지한 일시로부터 소정 기간이 경과해도 초대받은 이용자에게서 응답이 없는 경우, 상기 상태 정보의 상태를 초대의 신청중에서 초대의 거부로 재기입하므로, 후보 이용자에 해당하는지 여부의 판정을 간소화할 수 있다.
보다 구체적으로는, 상기 상태 정보의 상태는, 초대의 거부 또는 승인을 나타내는 제1 상태와, 초대 신청중인 것을 나타내는 제2 상태를 포함하고, 상기 상태 정보가 적어도 초대의 거부를 나타낸다는 것은, 상기 상태 정보가 상기 제1 상태인 경우이며, 상기 재기입부는, 상기 초대 신청을 통지한 일시로부터 소정 기간이 경과해도 초대받은 이용자에게서 응답이 없을 경우, 상기 상태 정보의 상태를 상기 제2상태에서 상기 제1 상태로 재기입하는 것이 바람직하다.
본 발명에 의하면, 초대가 거부된 경우뿐만 아니라, 초대가 승인된 경우에도 후보 이용자로부터 제외된다. 초대를 승인한 이용자는, 애당초 초대의 대상이 되는 애플리케이션을 이미 이용하고 있기 때문에, 초대할 필요가 없다. 이러한 데이터 구조를 채용함으로써, 거부한 이용자와 초대받은 이용자를 동시에 배제할 수 있으므로 처리 부하가 경감된다.
이어서, 본 발명은 관리 서버의 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체로서 파악된다. 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말 장치와 통신 가능한 관리 서버의 컴퓨터에 사용되는 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체이며, 상기 프로그램은, 상기 컴퓨터를, 초대의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보를 접수하는 접수부와, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있지 않을 것을 조건으로 했을 때, 상기 조건을 충족하는 후보 이용자의 일부 또는 모두를 특정하는 특정부와, 상기 특정부에서 특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부와, 상기 요구 이용자가, 상기 단말 장치에 표시된 후보 이용자 중에서 선택한 후보 이용자에 대하여 초대 신청을 통지하는 통지부로서 기능시키는 것을 특징으로 한다.
이어서, 본 발명은 관리 서버의 제어 방법으로서도 파악된다. 이 제어 방법은, 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말 장치와 통신 가능한 관리 서버의 제어하는 방법이며, 초대의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보를 접수하고, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있지 않을 것을 조건으로 했을 때, 상기 조건을 충족하는 후보 이용자의 일부 또는 모두를 특정하고, 상기 특정부에서 특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시켜, 상기 요구 이용자가, 상기 단말 장치에 표시된 후보 이용자 중에서 선택한 후보 이용자에 대하여 초대 신청을 통지하는 것을 특징으로 한다.
(2) 문의 처리에 관한 발명
각종 애플리케이션에서의 친구 전체의 상황을 이용자에게 알리는 관리 서버 등을 제공한다는 과제를 해결하기 위해서, 본 발명에 따른 관리 서버는, 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말기 장치와 통신 가능하며, 이용자의 단말 장치의 조작에 기초하는 요구를 받는 접수부와, 상기 복수의 애플리케이션 중, 상기 접수부에서 접수한 요구의 이용자인 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에 있어서, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자가 이용하고 있는 애플리케이션에 관한 이용 정보를 취득하는 정보 취득부와, 상기 정보 취득부에서 취득한 상기 이용 정보를 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부를 구비한다.
본 발명에 의하면, 정보 취득부는, 요구 이용자의 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 친구가 이용하고 있는 애플리케이션에 관한 이용 정보를 취득하고, 표시 제어부는 이것을 단말 장치에 표시시키므로, 요구 이용자는 친구가 이용하고 있는 애플리케이션에 관해서 다양한 정보를 얻는 것이 가능하게 된다.
또한, 이용 정보는, 예를 들어 인기 게임 랭킹, 즐기고 있는 인원수, 친구 신청할 수 있는 인원수, 초대할 수 있는 인원수의 정보를 포함한다.
또한, 이용자의 단말 장치의 조작에 기초하는 요구에는, 관리 서버가 제공하는 페이지를 열람하고 있는 요구 이용자가 단말 장치를 조작함으로써, 단말 장치로부터 관리 서버에 직접 송신되는 요구 이외에, 복수의 애플리케이션 서버 중 어느 하나가 제공하는 페이지를 열람하고 있는 요구 이용자가 단말 장치를 조작함으로써, 애플리케이션 서버로부터 관리 서버에 송신되는 요구가 있다.
또한, 보다 구체적으로는, 상술한 관리 서버는, 애플리케이션의 종류를 나타내는 종별 정보에 관련지어서 친구 관계가 되는 이용자 정보의 조를 기억하는 친구 관계 테이블을 구비하고, 상기 요구에는, 애플리케이션의 종류를 나타내는 종별 정보가 포함되어 있고, 상기 정보 취득부는, 상기 친구 관계 테이블을 참조하여, 상기 요구 이용자의 이용자 정보와 친구 관계에 있는 이용자의 이용자 정보와 상기 종별 정보와의 조합을 추출하여, 추출한 상기 이용자 정보와 상기 종별 정보의 조에 기초하여 상기 이용 정보를 취득하는 것이 바람직하다.
또한, 본 발명에 따른 관리 서버는, 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말기 장치와 통신 가능하며, 이용자의 단말 장치의 조작에 기초하는 요구를 받는 접수부와, 상기 복수의 애플리케이션 중, 상기 요구에 대응지어진 애플리케이션에 있어서, 상기 접수부에서 접수한 요구의 이용자인 요구 이용자와 친구 관계가 구축되어 있는 이용자가 이용하고 있는 애플리케이션에 관한 이용 정보를 취득하는 정보 취득부와, 상기 정보 취득부에서 취득한 상기 이용 정보를 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부를 구비하는 것을 특징으로 한다.
본 발명에 의하면, 정보 취득부는, 요구에 대응지어진 애플리케이션에 있어서, 요구 이용자의 친구가 이용하고 있는 애플리케이션에 관한 이용 정보를 취득하고, 표시 제어부는 이것을 단말 장치에 표시시키므로, 요구 이용자는 특정한 애플리케이션을 통한 친구에 관해서 다양한 정보를 얻는 것이 가능하게 된다.
이용자의 단말 장치의 조작에 기초하는 요구에는, 관리 서버가 제공하는 페이지를 열람하고 있는 요구 이용자가 단말 장치를 조작함으로써, 단말 장치로부터 관리 서버에 직접 송신되는 요구 이외에, 복수의 애플리케이션 서버 중 어느 하나가 제공하는 페이지를 열람하고 있는 요구 이용자가 단말 장치를 조작함으로써, 애플리케이션 서버로부터 관리 서버에 송신되는 요구가 있다.
또한, 요구가 단말 장치로부터 관리 서버에 송신되는 경우, 상기 요구에는, 복수의 애플리케이션 중 요구 이용자가 선택한 애플리케이션을 나타내는 종별 정보가 포함되어 있고, 상기 정보 취득부는, 상기 요구에 포함되는 종별 정보에 기초하여, 상기 요구에 대응지어진 애플리케이션을 특정해도 된다. 한편, 요구가 애플리케이션 서버로부터 송신되는 경우, 상기 정보 취득부는, 송신원인 애플리케이션 서버에서 제공하는 애플리케이션을 상기 요구에 대응지어진 애플리케이션으로서 특정해도 된다.
또한, 보다 구체적으로는, 상술한 관리 서버는, 애플리케이션의 종류를 나타내는 종별 정보에 관련지어서 친구 관계가 되는 이용자 정보의 조를 기억하는 친구 관계 테이블과, 상기 종별 정보와 애플리케이션의 내용을 나타내는 애플리케이션 정보를 관련지어서 기억한 애플리케이션 정보 테이블을 구비하고, 상기 요구에는, 애플리케이션의 종류를 나타내는 종별 정보가 포함되어 있고, 상기 정보 취득부는, 상기 친구 관계 테이블을 참조하여, 상기 요구 이용자의 이용자 정보와 친구 관계에 있는 이용자의 이용자 정보와 상기 종별 정보의 조합을 추출하고, 상기 애플리케이션 정보 테이블을 참조하여 추출한 상기 종별 정보에 대응하는 애플리케이션 정보를 상기 이용 정보로서 취득해도 된다.
상술한 관리 서버에 있어서, 상기 표시 제어부는, 상기 이용 정보로서, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자 중 어느 하나가 이용하고 있는 애플리케이션을 대상으로 하여, 각 애플리케이션을 이용하고 있는 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자의 수가 많은 순서대로 애플리케이션의 종류의 일부 또는 모두를 표시하는 것이 바람직하다.
본 발명에 의하면, 친구들 내에서 이용되고 있는 인원수가 많은 순서대로 애플리케이션이 표시되므로, 이용자는, 애플리케이션의 인기 랭킹을 한눈에 알 수 있다.
이 경우, 표시 제어부는, 요구 이용자와 친구 관계가 구축되어 있는 이용자의 수가 많은 순서대로 애플리케이션의 종류를 표시하는데, 구체적으로는, 상기 정보 취득부는, 이용자의 수를 애플리케이션마다 집계하여, 애플리케이션마다의 집계수를 상기 이용 정보로서 생성하고, 표시 제어부는, 집계한 이용자의 수가 많은 순서대로 애플리케이션의 종류를 표시하면 된다.
상술한 관리 서버에 있어서, 애플리케이션의 종류를 나타내는 종별 정보, 상기 애플리케이션의 이용 일시를 나타내는 일시 정보 및 이용자를 특정하는 이용자 정보를 관련지어서 기억하는 액세스 테이블을 구비하고, 상기 표시 제어부는, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자 중 어느 하나가 이용하고 있는 애플리케이션을 대상으로 하여, 상기 액세스 테이블을 사용해서, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자이며, 또한 소정 기간 내에 애플리케이션을 이용하고 있는 이용자의 수가 많은 순서대로 애플리케이션의 종류의 일부 또는 모두를 표시하는 것이 바람직하다.
본 발명에 의하면, 일시 정보를 참조함으로써, 소정 기간에서 친구들 내에서 이용되고 있는 인원수가 많은 순서대로 애플리케이션이 표시되므로, 어떤 기간에서 친구들 내에서 이용하고 있는 애플리케이션의 인기 랭킹을 한눈에 알 수 있다. 애플리케이션을 시험 삼아 이용하고, 그 후, 이용하지 않게 되는 일도 생각할 수 있으며, 시험 사용을 랭킹의 대상으로부터 제외하고 싶은 경우도 있다. 본 발명에 의하면, 소정 기간에 이용되고 있는 애플리케이션을 랭킹의 대상으로 하기 때문에, 시험 사용을 제외한 랭킹을 행하는 것이 가능하게 된다.
또한, 표시 제어부는, 소정 기간 내에 애플리케이션을 이용하고 있는 이용자의 수가 많은 순서대로 애플리케이션의 종류를 표시하는데, 구체적으로는, 상기 정보 취득부는, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자 중 어느 하나가 이용하고 있는 애플리케이션을 대상으로 하여, 상기 액세스 테이블을 사용해서, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자이며, 또한 소정 기간 내에 애플리케이션을 이용하고 있는 이용자의 수를 애플리케이션마다 집계하여, 애플리케이션마다의 집계수를 상기 이용 정보로서 생성하고, 표시 제어부는, 집계한 이용자의 수가 많은 순서대로 애플리케이션의 종류를 표시하면 된다.
상술한 관리 서버에 있어서, 상기 정보 취득부는, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자 중 어느 하나가 이용하고 있는 애플리케이션을 대상으로 하여, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자의 수를 애플리케이션마다 특정하여 상기 이용 정보를 생성하고, 상기 표시 제어부는, 애플리케이션마다 상기 이용자의 수를 표시하는 것이 바람직하다.
본 발명에 의하면, 애플리케이션을 이용하고 있는 이용자수가 단말 장치에 표시되므로, 상대적인 랭킹보다 상세한 정보를 이용자는 얻을 수 있다.
상술한 관리 서버에 있어서, 애플리케이션의 종류를 나타내는 종별 정보, 상기 애플리케이션의 이용 일시를 나타내는 일시 정보 및 이용자를 특정하는 이용자 정보를 관련지어서 기억하는 액세스 테이블을 구비하고, 상기 정보 취득부는, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자 중 어느 하나가 이용하고 있는 애플리케이션을 대상으로 하여, 상기 액세스 테이블을 사용해서, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자이며, 또한 소정 기간 내에 애플리케이션을 이용하고 있는 이용자의 수를 애플리케이션마다 특정하여 상기 이용 정보를 생성하고, 상기 표시 제어부는, 애플리케이션마다 상기 이용자의 수를 표시하는 것이 바람직하다.
본 발명에 의하면, 일시 정보를 참조함으로써, 소정 기간에서 친구들 내인 애플리케이션을 이용하고 있는 인원수를 특정하므로, 어떤 기간에서 어떤 애플리케이션을 친구들 내에서 이용하고 있는 인원수를 한눈에 알 수 있다.
상술한 관리 서버에 있어서, 상기 접수부는, 애플리케이션의 종류를 나타내는 종별 정보를 포함하는 요구를 접수하고, 상기 정보 취득부는, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있을 것을 제1 조건, 당해 애플리케이션에 대하여 상기 요구 이용자와 친구 관계가 구축되어 있지 않을 것을 제2 조건, 당해 애플리케이션에서 친구 상한수에 달하지 않았을 것을 제3 조건으로 했을 때, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 친구 신청이 가능한 이용자수를 특정하여 상기 이용자 정보로서 취득하는 것을 특징으로 한다.
본 발명에 의하면, 요구된 애플리케이션에서 친구 관계가 구축되어 있는 이용자가 애플리케이션을 이용하고 있고(제1 조건), 당해 애플리케이션에 대하여 요구 이용자와 친구 관계가 구축되어 있지 않고(제2 조건), 당해 애플리케이션에서 친구 상한수에 달하지 않은(제3 조건) 이용자의 수를 표시하는 것이 가능하게 된다. 이에 의해, 요구된 애플리케이션에 대해서, 친구 신청 가능한 인원수를 알 수 있어, 편리성이 향상된다. 또한 친구 신청이 가능한 후보 이용자의 일부 또는 모두를 선택할 수 있도록 단말 장치에 표시시켜서, 이용자가 후보 이용자 중에서 선택하여 친구 신청이 가능하게 하도록 해도 된다.
상술한 관리 서버에 있어서, 상기 접수부는, 애플리케이션의 종류를 나타내는 종별 정보를 포함하는 요구를 접수하고, 상기 정보 취득부는, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있지 않을 것을 조건으로 했을 때, 상기 조건을 충족하는 이용자의 수인 초대가 가능한 이용자수를 상기 이용자 정보로서 취득하는 것이 바람직하다.
본 발명에 의하면, 요구된 애플리케이션에 대해서, 초대 가능한 친구의 인원수를 알 수 있어, 편리성이 향상된다. 또한, 초대가 가능한 후보 이용자의 일부 또는 모두를 선택할 수 있도록 단말 장치에 표시시켜서, 이용자가 후보 이용자 중에서 선택하여 초대가 가능하게 하도록 해도 된다.
또한, 친구 신청 가능한 이용자의 수와 초대 가능한 이용자의 수를 배열하여 표시시키고, 또한 친구 신청이 가능한 후보 이용자와 초대 가능한 이용자를 선택적으로 단말 장치에 표시시키도록 하면, 예를 들어 구체적으로 어느 애플리케이션의 어느 친구를 초대하고 싶은지가 미리 결정되어 있는 경우에, 그 상대가 요구된 애플리케이션을 아직 이용하고 있지 않은 것이 판명되었을 경우에, 초대 가능한 이용자의 표시로 전환함으로써, 친구 신청이 아니라 초대를 할 수 있게 된다. 이와 같이, 어떤 애플리케이션에 친구 신청하고 싶은 상대가 당해 애플리케이션을 이용하고 있지 않은 경우도 있을 수 있으므로, 친구 신청의 기능과 초대의 기능을 조로 하여 단말 장치에서 이용자에게 제공시키는 것은, 이용자에게 있어서 편리성이 높아지게 된다.
상술한 발명은, 관리 서버의 컴퓨터에 사용되는 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체로서 파악할 수 있다. 이 경우, 본 발명에 따른 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체는, 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말 장치와 통신 가능한 관리 서버의 컴퓨터에 사용되고, 상기 프로그램은, 상기 컴퓨터를, 이용자의 단말 장치의 조작에 기초하는 요구를 받는 접수부와, 상기 복수의 애플리케이션 중, 상기 접수부에서 접수한 요구의 이용자인 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자가 이용하고 있는 애플리케이션에 관한 이용 정보를 취득하는 정보 취득부와, 상기 정보 취득부에서 취득한 상기 이용 정보를 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부로서 기능시키는 것을 특징으로 한다.
상술한 발명은, 관리 서버의 제어 방법으로서도 파악할 수 있다. 이 경우, 본 발명에 따른 관리 서버의 제어 방법은, 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말 장치와 통신 가능한 관리 서버를 제어하는 방법이며, 이용자의 단말 장치의 조작에 기초하는 요구를 받는 접수부, 상기 복수의 애플리케이션 중, 상기 접수부에서 접수한 요구의 이용자인 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서, 상기 요구 이용자와 친구 관계가 구축되어 있는 이용자가 이용하고 있는 애플리케이션에 관한 이용 정보를 취득하고, 상기 취득한 상기 이용 정보를 상기 요구 이용자의 단말 장치에 표시시키는 것을 특징으로 한다.
1 : 통신망 2 : 단말 장치
3A : 서버 장치 3B, 3C, 3D : 애플리케이션 서버
TBL11 : 이용자 정보 테이블 TBL12 : 친구 상한수 테이블
TBL13 : 관계 테이블 TBL14 : 인바이트 테이블
11 : 접수부 12 : 특정부
13 : 지시부 14 : 표시 제어부
15 : 정보 취득부 16 : 통지부
30 : CPU 100 : 애플리케이션 시스템

Claims (13)

  1. 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말 장치와 통신 가능한 관리 서버로서,
    친구의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보를 접수하는 접수부와,
    상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있을 것을 제1 조건, 당해 애플리케이션에 대하여 상기 요구 이용자와 친구 관계가 구축되어 있지 않을 것을 제2 조건, 당해 애플리케이션에서 친구 상한수에 달하지 않았을 것을 제3 조건으로 했을 때, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정하는 특정부와,
    상기 특정부에서 특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부와,
    상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션에 대응한 애플리케이션 서버에 대하여 상기 요구 이용자가 상기 후보 이용자 중에서 선택한 이용자에 대하여 친구 신청을 요구하는 지시를 행하는 지시부
    를 구비하는 것을 특징으로 하는 관리 서버.
  2. 제1항에 있어서,
    상기 특정부는, 상기 종별 정보에 관련지어서 당해 종별 정보가 나타내는 애플리케이션을 이용하고 있는 이용자 정보를 구비하는 제1 이용자 정보 테이블을 참조하여 상기 제1 조건을 충족하는 후보 이용자를 특정하고, 상기 종별 정보에 관련지어서 친구 관계가 되는 이용자 정보의 조를 구비하는 제1 친구 관계 테이블을 참조하여 상기 제2 조건을 충족하는 후보 이용자를 특정하는 것을 특징으로 하는 관리 서버.
  3. 제2항에 있어서,
    상기 제1 이용자 정보 테이블의 내용과, 상기 애플리케이션 서버가 제공하는 애플리케이션을 이용하는 이용자를 나타내는 이용자 정보를 구비하는 제2 이용자 정보 테이블의 내용을 동기시키는 이용자 정보 동기부와, 상기 제1 친구 관계 테이블의 내용과, 상기 애플리케이션 서버가 제공하는 애플리케이션에 대해서, 친구 관계가 되는 이용자 정보의 조를 구비하는 제2 친구 관계 테이블의 내용을 동기시키는 친구 관계 동기부
    를 구비하는 것을 특징으로 하는 관리 서버.
  4. 제2항에 있어서,
    상기 제1 친구 관계 테이블이 구비하는 상기 이용자 정보의 조는, 친구 신청을 행한 이용자의 이용자 정보와, 친구 신청을 수락한 이용자의 이용자 정보를 포함하는 것을 특징으로 하는 관리 서버.
  5. 제1항에 있어서,
    상기 접수부에서 접수한 종별 정보에 대응하는 상기 애플리케이션 서버에서 설정된 이용자의 친구 상한수를 취득하는 취득부를 구비하고,
    상기 특정부는, 상기 취득부가 취득한 친구 상한수를 이용자 정보와 관련지어서 구비하는 제1 친구 상한수 테이블을 참조하여 상기 제3 조건을 충족하는 후보 이용자를 특정하는 것을 특징으로 하는 관리 서버.
  6. 제5항에 있어서,
    상기 취득부는, 상기 제1 친구 상한수 테이블의 내용과, 상기 애플리케이션 서버에서 관리하는 친구 상한수와 이용자 정보를 관련지어서 구비하는 제2 친구 상한수 테이블의 내용을 동기시키는 친구 상한수 동기부를 구비하는 것을 특징으로 하는 관리 서버.
  7. 제1항에 있어서,
    상기 접수부에서 접수한 종별 정보에 대응하는 상기 애플리케이션 서버에 대하여 이용자의 친구 상한수를 문의하는 요구를 송신하고, 상기 요구에 대한 응답으로서 당해 애플리케이션 서버로부터 친구 상한수를 취득하는 취득부를 구비하고,
    상기 특정부는, 상기 취득부에서 취득한 친구 상한수에 기초하여 상기 제3 조건을 충족하는 후보 이용자를 특정하는 것을 특징으로 하는 관리 서버.
  8. 제1항에 있어서,
    상기 특정부는, 상기 애플리케이션의 이용 일시를 나타내는 일시 정보를 이용자 식별 정보와 관련지어서 구비하는 액세스 테이블을 참조하여 소정 기간 내에 애플리케이션을 이용하고 있을 것을 상기 제1 조건에 추가하여, 상기 제1 조건을 충족하는 후보 이용자를 특정하는 것을 특징으로 하는 관리 서버.
  9. 제1항에 있어서,
    상기 표시 제어부는, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션을 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키고,
    상기 특정부는, 상기 단말 장치에서 상기 요구 이용자가 선택한 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정하는 것을 특징으로 하는 관리 서버.
  10. 제1항에 있어서,
    상기 특정부는, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에 대해서, 친구 신청이 가능한 인원수를 특정하고,
    상기 표시 제어부는, 상기 특정부가 특정한 친구 신청이 가능한 인원수를 상기 요구 이용자의 단말 장치에 표시시키는 것을 특징으로 하는 관리 서버.
  11. 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말 장치와 통신 가능한 관리 서버의 컴퓨터에 사용되는 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체로서,
    상기 프로그램은, 상기 컴퓨터를,
    친구의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보를 접수하는 접수부와,
    상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있을 것을 제1 조건, 당해 애플리케이션에 대하여 상기 요구 이용자와 친구 관계가 구축되어 있지 않을 것을 제2 조건, 당해 애플리케이션에서 친구 상한수에 달하지 않았을 것을 제3 조건으로 했을 때, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정하는 특정부와,
    상기 특정부에서 특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부와,
    상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션에 대응한 애플리케이션 서버에 대하여 상기 요구 이용자가 상기 후보 이용자 중에서 선택한 이용자에 대하여 친구 신청을 요구하는 지시를 행하는 지시부로서 기능시키는 것을 특징으로 하는
    프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체.
  12. 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버 및 이용자의 단말 장치와 통신 가능한 관리 서버의 제어 방법으로서,
    친구의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보를 접수하고,
    접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있을 것을 제1 조건, 당해 애플리케이션에 대하여 상기 요구 이용자와 친구 관계가 구축되어 있지 않을 것을 제2 조건, 당해 애플리케이션에서 친구 상한수에 달하지 않았을 것을 제3 조건으로 했을 때, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정하고,
    특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키고,
    접수한 종별 정보가 나타내는 애플리케이션에 대응한 애플리케이션 서버에 대하여 상기 요구 이용자가 상기 후보 이용자 중에서 선택한 이용자에 대하여 친구 신청을 요구하는 것을 특징으로 하는
    관리 서버의 제어 방법.
  13. 종류가 상이한 복수의 애플리케이션 각각에 대응한 복수의 애플리케이션 서버와 접속된 관리 서버와 통신 가능한 이용자의 단말 장치의 컴퓨터에 사용되는 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체로서,
    상기 복수의 애플리케이션 서버의 각각은, 친구의 상한수를 이용자마다 관리하고 있고,
    상기 관리 서버는, 친구의 후보가 되는 후보 이용자를 제시할 것을 요구하는 요구 이용자가 단말 장치를 조작하여 지정한 애플리케이션의 종류를 나타내는 종별 정보를 접수하는 접수부와, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션을 이용하고 있을 것을 제1 조건, 당해 애플리케이션에 대하여 상기 요구 이용자와 친구 관계가 구축되어 있지 않을 것을 제2 조건, 당해 애플리케이션에서 친구 상한수에 달하지 않았을 것을 제3 조건으로 했을 때, 상기 요구 이용자가 이용한 적이 있는 이용 완료 애플리케이션에서 친구 관계가 구축되어 있는 이용자 중 상기 각 조건의 모두를 충족하는 후보 이용자의 일부 또는 모두를 특정하는 특정부와, 상기 특정부에서 특정한 상기 일부 또는 모든 후보 이용자를 선택할 수 있도록 상기 요구 이용자의 단말 장치에 표시시키는 표시 제어부와, 상기 접수부에서 접수한 종별 정보가 나타내는 애플리케이션에 대응한 애플리케이션 서버에 대하여 상기 요구 이용자가 상기 후보 이용자 중에서 선택한 이용자에 대하여 친구 신청을 요구하는 지시를 행하는 지시부를 구비하고,
    상기 프로그램은, 상기 단말 장치의 컴퓨터를,
    당해 단말 장치의 이용자의 친구 상한수가 변화한 것을 검출하는 검출부와,
    상기 검출부에 의해 상기 친구 상한수가 변화한 것이 검출되면, 변화한 후의 친구 상한수를 상기 관리 서버에 통지하는 통지부로서 기능시키는 것을 특징으로 하는
    프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체.
KR1020147024823A 2012-02-06 2013-01-28 관리 서버 KR101449391B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JPJP-P-2012-023157 2012-02-06
JP2012023157 2012-02-06
JP2012061621 2012-03-19
JPJP-P-2012-061621 2012-03-19
PCT/JP2013/051710 WO2013118595A1 (ja) 2012-02-06 2013-01-28 管理サーバ

Publications (2)

Publication Number Publication Date
KR20140129094A KR20140129094A (ko) 2014-11-06
KR101449391B1 true KR101449391B1 (ko) 2014-11-07

Family

ID=48947361

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020147024823A KR101449391B1 (ko) 2012-02-06 2013-01-28 관리 서버

Country Status (4)

Country Link
US (1) US9486710B2 (ko)
JP (1) JP5551801B2 (ko)
KR (1) KR101449391B1 (ko)
WO (1) WO2013118595A1 (ko)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6224591B2 (ja) * 2012-08-06 2017-11-01 グリー株式会社 表示システム、同システムにおける表示方法及び表示プログラム
KR101613809B1 (ko) 2015-01-02 2016-04-19 라인 가부시키가이샤 특정 조건에 의해 제어되는 메신저 서비스를 제공하는 방법과 시스템 및 기록 매체
US20170239563A1 (en) * 2016-02-23 2017-08-24 Sony Interactive Entertainment America Llc Game selection and invitation process
JP6908972B2 (ja) * 2016-04-13 2021-07-28 任天堂株式会社 情報処理システム、サーバ、情報処理方法及びプログラム
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
WO2020065760A1 (ja) * 2018-09-26 2020-04-02 楽天株式会社 受付システム、受付方法、及びプログラム
JP6993388B2 (ja) * 2019-09-02 2022-01-13 グリー株式会社 ゲームプログラム、コンピュータの制御方法およびコンピュータ
JP6878533B2 (ja) * 2019-09-09 2021-05-26 株式会社バンダイ プログラム、情報処理装置及びゲームシステム
CN112035202B (zh) * 2020-08-25 2021-11-23 北京字节跳动网络技术有限公司 好友活跃信息的显示方法、装置、电子设备和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040081906A (ko) * 2003-03-17 2004-09-23 주식회사 케이티 상호 정보제공 및 정보획득 환경에서의 상호 보상 서비스제공 방법
KR20080015452A (ko) * 2005-05-17 2008-02-19 구글 인코포레이티드 비디오 게임 및 비디오 게임 시스템의 향상 방법 및 시스템
KR20090008351A (ko) * 2006-04-17 2009-01-21 야후! 인크. 네트워크 기반 콘테스트 생성
KR20100103735A (ko) * 2008-02-13 2010-09-27 야후! 인크. 소셜 네트워크 검색

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3172713B2 (ja) * 1998-08-10 2001-06-04 勝 森野 伸縮体
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 ゲームシステム、ゲーム制御方法およびその記録媒体ならびにコンピュータプログラム
JP2004244951A (ja) * 2003-02-14 2004-09-02 Meiko:Kk 梯子における手摺りの取付け構造
JP4168972B2 (ja) 2004-05-10 2008-10-22 株式会社セガ 会員登録されたユーザを起点に会員未登録の他のユーザに会員サービスを提供するシステム、サーバ、サービス提供方法およびプログラム
JP4758223B2 (ja) * 2005-12-26 2011-08-24 株式会社テクノエース 梯子
US20070173324A1 (en) * 2006-01-20 2007-07-26 Microsoft Corporation Computer-based gaming groups
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
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 日本電気株式会社 コミュニティ管理システム、及びコミュニティ管理方法
EP2477135B1 (en) * 2009-09-10 2019-04-17 Sony Interactive Entertainment Inc. Information processing system, information processing method, information storage medium and program
JP5155272B2 (ja) * 2009-09-14 2013-03-06 ヤフー株式会社 コミュニティ管理プラットフォーム装置
JP5457146B2 (ja) * 2009-11-25 2014-04-02 株式会社バンダイナムコゲームス サーバシステム、及びアイテム管理方法
JP2011202363A (ja) * 2010-03-24 2011-10-13 Akimasa Kawahara 梯子
US8388450B1 (en) 2011-09-26 2013-03-05 Zynga Inc. Expanding the gaming social network with unrelated players

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040081906A (ko) * 2003-03-17 2004-09-23 주식회사 케이티 상호 정보제공 및 정보획득 환경에서의 상호 보상 서비스제공 방법
KR20080015452A (ko) * 2005-05-17 2008-02-19 구글 인코포레이티드 비디오 게임 및 비디오 게임 시스템의 향상 방법 및 시스템
KR20090008351A (ko) * 2006-04-17 2009-01-21 야후! 인크. 네트워크 기반 콘테스트 생성
KR20100103735A (ko) * 2008-02-13 2010-09-27 야후! 인크. 소셜 네트워크 검색

Also Published As

Publication number Publication date
WO2013118595A1 (ja) 2013-08-15
JP2013225290A (ja) 2013-10-31
KR20140129094A (ko) 2014-11-06
JP5551801B2 (ja) 2014-07-16
US20140351338A1 (en) 2014-11-27
US9486710B2 (en) 2016-11-08

Similar Documents

Publication Publication Date Title
KR101711266B1 (ko) 관리 서버, 그 제어 방법, 및 그 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체
KR101449391B1 (ko) 관리 서버
KR20140129106A (ko) 관리 서버, 그 제어 방법, 및 그 프로그램을 기록한 컴퓨터 판독 가능한 비일시적 기록 매체
JP5695699B2 (ja) 管理装置、その制御方法及びプログラム、アプリケーションシステム、並びに識別情報関連付け方法
US20140351710A1 (en) Virtual social group management system, virtual social group management method, and computer program
US10681170B2 (en) Systems and methods for determining the popularity of a user based on aggregated popularity measurements of other users
WO2013161924A1 (ja) 端末装置、その制御方法及びコンピュータ読み取り可能な記録媒体、並びにアプリケーションシステム
JP5265794B1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム
JP2007018415A (ja) ネットワーク要素検索方法、及びネットワーク要素検索プログラム
KR20150028910A (ko) 친구 검색 기반 소셜 네트워크 게임 서비스 제공 시스템
JP2014038594A (ja) 管理装置、サービス提供システム、管理装置の制御方法、及び、管理装置のプログラム。
JP6265320B2 (ja) 情報処置装置、管理装置、サービス提供システム、管理装置の制御方法、情報処理装置のプログラム、及び管理装置のプログラム
JP2014089647A (ja) 情報提供装置のプログラム、情報提供装置の制御方法、情報提供装置、及び、情報提供システム
JP2023009200A (ja) ゲーム情報処理装置，情報処理装置の制御方法及び制御プログラム
JP5692731B2 (ja) ゲーム制御装置、プログラム、ゲームシステム
JP6097953B2 (ja) 管理装置、管理装置と通信可能な端末装置、サービス提供システム、管理装置の制御方法、端末装置のプログラム及び管理装置のプログラム
JP2014021737A (ja) 管理装置、サービス提供システム、管理装置の制御方法、及び、管理装置のプログラム
WO2013140829A1 (ja) ゲーム制御装置、ゲーム制御方法、プログラム、記録媒体、ゲームシステム
JP6075894B2 (ja) 管理装置、管理装置と通信可能な端末装置、サービス提供システム、管理装置の制御方法、及び管理装置のプログラム
JP2014038415A (ja) 催事管理装置の管理方法、催事管理装置、及び、催事管理装置のプログラム
KR101495632B1 (ko) 소셜 네트워크 게임용 플랫폼
JP6175730B2 (ja) 管理装置、管理装置と通信可能な端末装置、サービス提供システム、管理装置の制御方法、端末装置のプログラム及び管理装置のプログラム
JP2014053834A (ja) データ共有システム
JP2014035586A (ja) イベント管理装置、イベント管理装置の制御方法、イベント管理装置のプログラム

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20170922

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20180921

Year of fee payment: 5