WO2016098465A1 - 情報処理システム、サーバ、プログラム、及び情報処理方法 - Google Patents

情報処理システム、サーバ、プログラム、及び情報処理方法 Download PDF

Info

Publication number
WO2016098465A1
WO2016098465A1 PCT/JP2015/080692 JP2015080692W WO2016098465A1 WO 2016098465 A1 WO2016098465 A1 WO 2016098465A1 JP 2015080692 W JP2015080692 W JP 2015080692W WO 2016098465 A1 WO2016098465 A1 WO 2016098465A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
log data
game
demand
terminal
Prior art date
Application number
PCT/JP2015/080692
Other languages
English (en)
French (fr)
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 株式会社Ｃｙｇａｍｅｓ
Priority to CN201580076133.XA priority Critical patent/CN107249707B/zh
Priority to KR1020177019878A priority patent/KR101944455B1/ko
Publication of WO2016098465A1 publication Critical patent/WO2016098465A1/ja
Priority to US15/627,023 priority patent/US10293254B2/en

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/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • 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/45—Controlling the progress of the video game
    • A63F13/49—Saving the game status; Pausing or ending the game
    • A63F13/497—Partially or entirely replaying previous game actions
    • 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/50—Controlling the output signals based on the game progress
    • A63F13/53—Controlling the output signals based on the game progress involving additional visual information provided to the game scene, e.g. by overlay to simulate a head-up display [HUD] or displaying a laser sight in a shooting game
    • A63F13/533—Controlling the output signals based on the game progress involving additional visual information provided to the game scene, e.g. by overlay to simulate a head-up display [HUD] or displaying a laser sight in a shooting game for prompting the player, e.g. by displaying a game menu
    • 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
    • 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
    • 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/30—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 output arrangements for receiving control signals generated by the game device
    • A63F2300/308—Details of the user interface
    • 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/53—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 details of basic data processing
    • A63F2300/535—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 details of basic data processing for monitoring, e.g. of user parameters, terminal parameters, application parameters, network parameters
    • 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

Definitions

  • the present invention relates to an information processing system, a server, a program, and an information processing method.
  • Patent Document 1 In recent years, in order to share a game experience on a terminal such as a smartphone among players, a large amount of moving image data recording a game screen being played has been uploaded on the net (Patent Document 1,). 2). The environment for that is being prepared, and many development tools for recording such moving image data have been provided.
  • moving image data in which a game screen being played is recorded is generally called “play video” in many cases.
  • moving image data indicating the execution contents of the game shot including the player itself.
  • Such moving image data is generally called “game live video”.
  • game live video is also included, that is, these moving image data are collectively referred to as “play video”. That is, in this specification, “play moving image” is a broad concept of an image showing the execution content of a predetermined game.
  • the present invention has been made in view of such a situation, and an object thereof is to effectively give a player who is playing a game a continuous motivation for creating and uploading a play video.
  • an information processing system includes: An information processing system including a plurality of terminals capable of executing a game and a server, The server Among the plurality of terminals, log data of the first event is acquired from a terminal that has generated the first event processed as negative in the game, and a second event processed as positive in the game is generated
  • Event acquisition means for acquiring log data of the second event from the terminal that has been made, Based on each of the acquired log data, the one related to the second event is selected from one or more of the first events, and based on the selection result, the degree of potential demand for the image related to the second event
  • Event detection means for detecting the first event and the second event during execution of the game
  • Log providing means for providing log data of the first event and
  • the server of one embodiment of the present invention includes: In a server that communicates with a plurality of terminals that can execute a game, Among the plurality of terminals, log data of the first event is obtained from a terminal that generated the first event processed as negative in the game, and a second event processed as positive in the game is generated Event acquisition means for acquiring log data of the second event from the terminal that has been made, Based on each of the acquired log data, the one related to the second event is selected from one or more of the first events, and based on the selection result, the degree of potential demand for the image related to the second event A degree calculating means for calculating Informing means for informing a terminal that has generated the second event that the degree satisfies a predetermined condition to prompt recording of image data related to the second event; Is provided.
  • the log data includes one or more types of attribute information obtained when the game is executed
  • the degree calculation means is Calculating a correlation amount between the log data of the second event and each of the log data of the one or more first events;
  • the first event having the log data for which the correlation amount satisfies a predetermined criterion may be selected as related to the second event.
  • log data can include log data indicating the progress of the game and log data indicating the state of the player of the game.
  • the log data is represented by a vector on a multidimensional vector space
  • the degree calculation means calculates the distance in the multidimensional vector space between the vector representing the log data of the second event and each of the vectors representing the log data of one or more first events as the correlation amount. Can be calculated as
  • the degree calculation means is The greater the number of selections of the first event associated with the second event, the higher the degree of potential demand for images related to the second event.
  • the server further includes management means for managing image data related to a predetermined event of the game executed in the past or location data of the image data,
  • the degree calculation means is Of the image data managed by the management means or the image data specified by the location data, obtain the number of accesses to the image data related to the second event, As the number of accesses increases, the degree of potential demand for images related to the second event can be reduced.
  • the first program according to one aspect of the present invention is an information processing method corresponding to the server according to one aspect of the present invention.
  • the second program of one embodiment of the present invention is a program that is executed by a computer that controls a terminal in the information processing system of one embodiment of the present invention described above. That is, The log data of the first event is acquired from the terminal that generated the first event processed as negative in the game, and the second event from the terminal that generated the second event processed as positive in the game Event acquisition function to acquire log data of Based on each of the acquired log data, the one related to the second event is selected from one or more of the first events, and based on the selection result, the degree of the potential demand for the image related to the second event A notification function for performing notification for prompting recording of image data related to the second event to a terminal that has generated the second event satisfying a predetermined condition.
  • a computer that controls a terminal that communicates with a server comprising An event detection step of detecting the first event and the second event during execution of the game; A log providing step of providing log data of the first event and the second event to the server; A presenting step of presenting the content of the notification from the server; The control process including is executed.
  • An information processing method corresponding to the second program of one aspect of the present invention is also provided as an information processing method of one aspect of the present invention.
  • continuous motivation for creating and uploading a play video can be effectively given to a player who is executing a game, and The player can create and upload a play video required by the player, and can realize a cycle that quickly satisfies the demand for the play video.
  • FIG. 2 is a diagram for explaining detection of a demand-stimulating event in the information system of FIG. 1 and recommendation of a play video based on detection of a supply possibility event in the terminal 2-2 of FIG. It is a figure for demonstrating the method of measuring the correlation amount between the vectors defined in the multidimensional feature space. It is a flowchart which shows the video recording recommendation process performed by the information processing system of FIG.
  • the “moving image” includes an image displayed by each of the following first to third processes.
  • the first process refers to a process in which a series of still images composed of a plurality of images are continuously switched and displayed over time for each movement of an object (for example, a game character) in a planar image (2D image).
  • an object for example, a game character
  • 2D image planar image
  • two-dimensional animation so-called flip-flopping processing, corresponds to the first processing.
  • the second process refers to a process in which motions corresponding to respective actions of an object (for example, a game character) in a stereoscopic image (3D model image) are set and the motions are changed and displayed over time.
  • a three-dimensional animation corresponds to the second process.
  • the third process refers to a process in which videos (that is, moving images) corresponding to respective actions of an object (for example, a game character) are prepared and the video is played over time.
  • FIG. 1 shows the configuration of an information processing system according to an embodiment of the present invention.
  • the information processing system shown in FIG. 1 is configured by connecting a server 1 and terminals 2-1 and 2-2 to each other via a predetermined network such as the Internet (not shown). Note that only two terminals 2-1 and 2-2 are shown in FIG. 1, but this is for ease of explanation of the present invention. Actually, a large number of terminals can be connected to the server 1 in the information processing system.
  • Each of the server 1 and the terminals 2-1 and 2-2 in this embodiment is applied to a computer and its peripheral devices.
  • Each unit in the present embodiment is configured by hardware included in a computer and its peripheral devices, and software that controls the hardware.
  • the above hardware includes a storage unit, a communication unit, a display unit, and an input unit in addition to a CPU (Central Processing Unit) as a control unit.
  • a storage unit for example, a memory (RAM: Random Access Memory, ROM: Read Only Memory, etc.), a hard disk drive (HDD: Hard Disk Drive), an optical disk (CD: Compact Disk, DVD: Digital Versatile drive, etc.).
  • Examples of the communication unit include various wired and wireless interface devices.
  • Examples of the display unit include various displays such as a liquid crystal display.
  • Examples of the input unit include a keyboard and a pointing device (mouse, tracking ball, etc.).
  • the terminals 2-1 and 2-2 of the present embodiment are configured as smartphones, and also have a touch panel that has both an input unit and a display unit.
  • the input unit of the touch panel includes, for example, a capacitance type or resistance type position input sensor stacked in the display area of the display unit, and detects the coordinates of the position where the touch operation is performed.
  • the touch operation refers to an operation of touching or approaching an object (such as a user's finger or a touch pen) with respect to a touch panel (more precisely, an input unit) serving as a display medium.
  • touch position the position where the touch operation is performed
  • the coordinates of the touch position are referred to as “touch coordinates”.
  • the software includes a computer program and data for controlling the hardware.
  • the computer program and data are stored in the storage unit, and are appropriately executed and referenced by the control unit. Further, the computer program and data can be distributed via a communication line, and can also be recorded and distributed on a computer-readable medium such as a CD-ROM.
  • Each of the server 1 and the terminals 2-1 and 2-2 has a functional configuration as shown in FIG. 1 in order to perform various operations by such cooperation of hardware and software.
  • the server 1 includes an event acquisition unit 11, a demand log storage unit 12, a demand degree calculation unit 13, a play video record recommendation notification unit 14, a play video storage unit 15, and a play video management unit 16. .
  • the event acquisition unit 11 is a terminal (example of FIG. 1) that has generated a first event processed as negative in a predetermined game among a plurality of terminals (terminals 2-1 and 2-2 in the example of FIG. 1). Then, the log data of the first event is acquired from the terminal 2-1). The event acquisition unit 11 also logs data of the second event from the terminal (terminal 2-2 in the example of FIG. 1) that has generated the second event processed as positive in the game among the plurality of terminals. To get.
  • the game includes a plurality of events.
  • at least some of the plurality of events are selectively processed as positive or negative according to the player's operation or the like.
  • “positive” and “negative” mean a pair of concepts. That is, it suffices if two pairs of processing are selectively performed according to the player's operation, and the contents of the processing are not particularly limited.
  • the first event processed as negative includes an event processed as a failed situation in the game.
  • the first event includes, for example, game over, failure to acquire rare items, failure to make NPC (Non-Player Character) a friend, and failure to find a story branch point.
  • NPC Non-Player Character
  • a player who has experienced it desires to view a play video related to the first event (for example, a play video of another person showing a process until it is processed as a successful situation). It can be understood that the event is highly likely. Therefore, hereinafter, such a first event is referred to as a “demand-stimulating event”.
  • the second event processed as positive includes an event processed as a successful situation in the game. Specifically, for example, clearing a stage, acquiring rare items, making an NPC a friend, finding a story branch point, and the like are included in the second event. Such a second event may meet the demands of other players by publishing a play video related to the second event (for example, a play video showing a process until it is processed as a successful situation). Is a high event. Therefore, hereinafter, such a second event is referred to as a “supply possibility event”.
  • the log data here is data indicating a history such as a situation that changes every moment in the game. That is, the log data here is not static data having the same content regardless of the acquisition timing but dynamic data (real-time data) whose content changes according to the acquisition timing.
  • the log data is data composed of an aggregate of an arbitrary number of arbitrary types of elements using attribute information in the game as an element.
  • the log data includes log data indicating the progress of the game and log data indicating the state of the player of the game. That is, the log data of the demand-stimulating event is history data indicating the progress of the game and the situation of the player when the player experiences the demand-stimulating event.
  • the log data of the supply possibility event is history data indicating the progress of the game and the state of the player when the player experiences the supply possibility event.
  • a demand-stimulating event is generated in the terminal 2-1
  • a supply possibility event is generated in the terminal 2-2. That is, in the example of FIG. 1, among the event acquisition units 11, the demand stimulation event acquisition unit 21 acquires log data of a demand stimulation event that has occurred in the terminal 2-1, while the supply possibility event acquisition unit 22 It is assumed that log data of a supply possibility event that has occurred in the terminal 2-2 is acquired. However, it goes without saying that a demand-stimulating event and a supply possibility event can occur at any terminal (including terminals 2-1 and 2-2) that is executing the game.
  • a terminal (terminal 2-1 in the example of FIG. 1) that transmits log data of demand-stimulating events to such a server 1, as shown in FIG.
  • the data generation part 32, the log data holding part 33, the demand rousing event detection part 34, and the log data transmission control part 35 function.
  • the game execution unit 31 executes a predetermined game.
  • the log data generation unit 32 sequentially generates log data during execution of the predetermined game.
  • the log data holding unit 33 holds log data sequentially generated in this way. In other words, the progress of the game and the state of the player change every moment, but log data indicating the progress of the game and the state of the player is sequentially acquired (in real time) and held.
  • the demand stimulation event detection unit 34 detects that a demand stimulation event has occurred.
  • the log data transmission control unit 35 performs control to transmit log data generated at a predetermined timing during the execution of the game to the server 1.
  • a time when a demand-stimulating event is detected by the demand-stimulating event detection unit 34 corresponds to a predetermined timing. That is, in the present embodiment, log data is sequentially generated in real time, but is not always transmitted to the server 1 and is transmitted as log data of a demand-stimulating event only when a demand-stimulating event is detected.
  • the demand log storage unit 12 stores log data of demand-stimulating events transmitted from various terminals including the terminal 2-1.
  • the predetermined event in the game may be a demand-stimulating event for a certain player, or may not be a demand-stimulating event for another player (a case of a supply possibility event).
  • the number of players that have become demand-stimulating events differs for each event in the game. For example, in an event that is difficult to clear, it is expected that the number of players who have become demand-stimulating events will increase. Therefore, the log data of the demand-stimulating event can be stored in the demand log storage unit 12 for each of various events in the game. Further, from the viewpoint of the same event, log data of a plurality of demand-stimulating events for each of a plurality of players who have experienced the event in various situations can be stored in the demand log storage unit 12.
  • the demand degree calculation unit 13 Based on the log data of the supply possibility event acquired by the supply possibility event acquisition unit 22 and the log data of a plurality of demand stimulating events stored in the demand log storage unit 12, the demand degree calculation unit 13 Select one or more demand-stimulating events related to the possibility event. Based on the selection result, the demand degree calculation unit 13 calculates the degree of potential demand of the play video of the supply possibility event (hereinafter referred to as “play video demand degree”).
  • the selection method of the demand stimulation event relevant to a supply possibility event is not specifically limited, In the present embodiment, the following methods are applied. That is, the demand degree calculation unit 13 calculates the correlation amount between the log data of the supply possibility event and each of the log data of one or more demand-stimulating events. Then, the demand degree calculation unit 13 selects a demand-stimulating event having log data whose correlation amount satisfies a predetermined criterion as being related to the supply possibility event.
  • the calculation method of the play video demand degree by the demand degree calculation unit 13 is not particularly limited, but the following technique is applied in the present embodiment.
  • the demand degree calculation part 13 raises a play animation demand degree, so that there are many selection numbers of the demand stimulation event relevant to the target supply possibility event.
  • the play video storage unit 15 described later stores a large number of play videos for games that have been executed in the past. And the access of each play moving image memorize
  • storage part 15 is managed by the play moving image management part 16 mentioned later.
  • the demand level calculation unit 13 obtains the number of accesses to the play video related to the target supply event among the play videos already uploaded to the play video storage unit 15. make low.
  • V, E a demand score demandScore (V, E) is adopted in the present embodiment. Details of the demand score demandScore (V, E) will be described later.
  • the play video record recommendation notification unit 14 plays the supply possibility event for a terminal (terminal 2-2 in the example of FIG. 1) that has generated a supply possibility event in which the play video demand degree satisfies a predetermined condition. Informs the user to record a moving image.
  • the predetermined condition is not particularly limited, and for example, a predetermined threshold value may be provided, and a condition that the play video demand level exceeds the threshold value may be employed.
  • the method of notification is not particularly limited. A specific example of notification according to the present embodiment will be described later with reference to FIG.
  • the log data of the supply possibility event can be transmitted to such a server 1 to notify the recording of the play video of the supply possibility event.
  • the game execution unit 41, the log data generation unit 42, the log data holding unit 43, the supply possibility event detection unit 44, the log data transmission control unit 45, and the notification content presentation unit 46 functions.
  • the game execution unit 41 executes a predetermined game.
  • the log data generation unit 42 sequentially generates log data during execution of the predetermined game.
  • the log data holding unit 43 holds log data sequentially generated in this way. That is, the log data indicating the progress of the game and the state of the player are acquired and held sequentially (in real time) as in the terminal 2-1.
  • the supply possibility event detection unit 44 detects that a supply possibility event has occurred.
  • the log data transmission control unit 45 executes control to transmit log data generated at a predetermined timing during execution of the game to the server 1.
  • the time when the supply possibility event is detected by the supply possibility event detection unit 44 corresponds to the predetermined timing. That is, in this embodiment, the log data is sequentially generated in real time, but is not always transmitted to the server 1, and the log data when the supply possibility event is detected (the situation of the supply possibility event). Only log data indicating, etc.) is transmitted.
  • the notification content presentation unit 46 presents the content of the notification to the player when notification for prompting the recording of the play video of the supply possibility event is made.
  • the presenting method is not particularly limited, but in the present embodiment, a method of displaying an image (for example, a screen 103 described later) is employed.
  • the player who has received the notification desires to record the play video of the supply possibility event
  • the player performs a predetermined instruction operation (an operation of pressing a “Yes” button in the screen 103 in the example of FIG. 2 described later).
  • the play video generation unit 47 When receiving the instruction operation, the play video generation unit 47 generates a play video of the supply possibility event and uploads it to the server 1.
  • the play video management unit 16 of the server 1 associates the play video of the supply possibility event uploaded from the terminal 2-2 with the log data previously acquired by the supply possibility event acquisition unit 22, and the play video storage unit 15 is stored.
  • the play video storage unit 15 stores various types of play videos (mainly play videos of supply possibility events) for a predetermined game.
  • FIG. 2 is a diagram for explaining detection of a demand-stimulating event in the terminal 2-1 in FIG. 1 and recommendation of a play video based on detection of a supply possibility event in the terminal 2-2 in FIG.
  • step Sa a demand-stimulating event is detected and counted.
  • the screen 101 shows a situation where the game is over at a certain stage in the game executed by the player of the terminal 2-1.
  • a failure situation that is, the first event processed as negative
  • log data of the demand-stimulating event is accumulated in the demand log storage unit 12 of the server 1.
  • Log data of such demand-stimulating events is acquired every time a demand-stimulating event occurs in any terminal, not limited to the terminal 2-1, is accumulated in the demand log storage unit 12, and is appropriately tabulated for each event. Is called.
  • step Sb a supply possibility event is detected.
  • the screen 102 shows a situation where the player of the terminal 2-2 has cleared the stage.
  • a successful situation i.e., a second event that is treated as positive
  • a play animation demand degree is calculated based on the total result of step Sa. If the play video demand level is high (if a predetermined condition is satisfied), it is considered that there is a potential demand for viewing the play video (play video showing the process until the stage is cleared) of the supply possibility event.
  • a screen 103 that recommends creating and uploading the play video is presented to the terminal 2-2.
  • step Sc When a play video of such a supply possibility event is uploaded to the server 1, in step Sc, a demand-stimulating event has occurred through a recommendation engine (not shown) as a high-demand moving image (play video). Delivered to the terminal 2-1 and the like.
  • the play video demand level will be described more specifically below.
  • the degree of play video demand for a predetermined supply possibility event changes based on the number of demand-stimulating events associated with the supply possibility event. Then, whether or not the supply possibility event and the demand stimulating event are related is performed based on the correlation amount of each log data of the supply possibility event and the demand stimulating event.
  • the calculation method of the correlation amount is not particularly limited, but the following method is employed in the present embodiment.
  • the log data of the present embodiment includes a plurality of types of attribute information obtained when the game is executed, and a vector configured with each of the plurality of types of attribute information as elements, that is, a vector on a multidimensional vector space It is represented by Therefore, the demand degree calculation unit 13 is on a multidimensional vector space of a vector representing log data of a supply possibility event and a vector representing log data of each demand stimulating event stored in the demand log storage unit 12. Is calculated as a correlation amount.
  • FIG. 3 is a diagram for explaining a method of measuring the amount of correlation between vectors defined in a multidimensional feature space.
  • the actual feature space is an n-dimensional (n is an arbitrary integer value of 1 or more) vector space
  • each feature axis is obtained when the game is executed. It corresponds to predetermined types of attribute information, for example, individual items and skills in the game. Therefore, the state (log data) in a game of a certain player can be expressed as one vector on this multidimensional vector space.
  • each situation (log data) of three players is represented by vectors A to C, respectively.
  • the distance between vectors indicating the player's situation is used as the correlation amount.
  • vector B is closer than vector C. Therefore, the situation (log data) of the player corresponding to the vector A is more related to the situation (log data) of the player corresponding to the vector B than the situation (log data) of the player corresponding to the vector C (similarity). It will be).
  • one log data can be described as a combination ⁇ P, Q> of log data P indicating the player's state and log data Q indicating the progress of the game.
  • the log data P indicating the player's state is an n-dimensional vector such as the following equation (1) that shows player's in-game attribute information such as the player's level, various parameters, owned items, owned skills, etc. It is a representation. ... (1)
  • p i represents a real number from 0 to 1 corresponding to the i-th attribute among the attribute information in the game of the player.
  • These values are preferably subjected to infinity norm normalization. For example, in a game with a maximum level of 100, level 1 can be expressed as 0.01 and level 100 can be expressed as 1 by normalizing the level value with the maximum value.
  • the number of items of a type that is worth owning it can be normalized by the maximum value that can be owned.
  • the number of these attributes may be hundreds to thousands depending on the game content. For example, when there are 500 types of items in the game and there are 500 types of skills, the value of n is 1000 or more.
  • the log data Q indicating the progress of the game can be expressed as a set of data indicating the progress of the game or the location of the game in the virtual space. For example, in an action game that scrolls horizontally, a sequence of a finite number of cell IDs representing the position reached by the player can be included in the log data Q. Furthermore, in RPG (Roll-Playing Game), the progress of the game is expressed using a finite number of scene numbers, so that the sequence of scene numbers can also be included in the log data Q.
  • log data Q indicating the progress of the game can be easily defined using these data, and the following formula (2 ) As an m-dimensional vector. ... (2)
  • q i has a value of 1 if the play video contains the i-th state of the game progress state of the player, and 0 if it does not.
  • the log data of the demand stimulation event is described as ⁇ P ⁇ , Q ⁇ >
  • the log data of the supply possibility event is ⁇ Describe as P + , Q + >.
  • the degree of play video demand for a predetermined supply possibility event is not only the number of demand-stimulating events related to the supply possibility event, but also the play video related to the supply possibility event. It also changes based on whether it has already been uploaded. For this reason, it is assumed that the log data of the predetermined event is also associated with the play video of the predetermined event already uploaded to the play video storage unit 15 (hereinafter referred to as “existing play video”).
  • existing play video The log data associated with such an existing play video is described as ⁇ P, Q> in order to clearly distinguish the log data of the above-described important call event and supply possibility event.
  • the play video demand level is calculated as a score. Therefore, hereinafter, such a score is referred to as a “demand score”.
  • Step SA is a step of detecting a demand-stimulating event.
  • the terminal 2-1 is used, but actually, the game playing status of all terminals (not shown) managed by the server 1 is monitored, and a demand-stimulating event is detected. Every time a demand-stimulating event is detected, log data ⁇ P-, Q-> of the demand-stimulating event is accumulated in the demand log storage unit 12.
  • Step SB is a step of detecting a supply possibility event.
  • the terminal 2-2 is used, but actually, the game play status of all the terminals (not shown) managed by the server 1 is monitored and a supply possibility event is detected.
  • log data ⁇ P +, Q +> of the supply possibility event is acquired by the demand degree calculation unit 13. Therefore, the demand degree calculation unit 13 executes the processes of the following steps SC to SF.
  • Step SC is a step of selecting an existing play moving image related to the supply possibility event detected in step SB and making it a data set V.
  • the demand score is lowered as the number of accesses of the existing play video increases (the more overlaps).
  • an existing play video having log data whose correlation amount with the supply possibility event satisfies a predetermined condition is an existing play video related to the supply possibility event.
  • the demand level calculation unit 13 calculates the correlation amount between the log data ⁇ P + , Q + > of the supply possibility event and the log data ⁇ P, Q> of each existing play video by the following formula: Calculated by two inner products as shown in (3). ... (3)
  • scoreP (P + , P) is a correlation between the log data P + indicating the state of the player who has generated the supply possibility event and the log data P indicating the state of the player who uploaded each existing play video. Indicates the weight value of the quantity.
  • ScoreQ (Q + , Q) is a weight of the correlation amount between the log data Q + indicating the progress of the game in the supply possibility event and the log data Q indicating the progress of the game indicated by each existing play video. Indicates the value. The higher the weight value, the more similar the progress of the game.
  • the demand degree calculation unit 13 measures the correlation amount of each existing play video with respect to the supply possibility event by the following equation (4) obtained by combining these two weight values. ... (4) That is, the demand level calculation unit 13 calculates the correlation amount rel ( ⁇ P + , Q + >,) as the product of the above two weight values for each existing play video in which scoreQ (Q + , Q) exceeds a predetermined threshold value t. ⁇ P, Q>) is calculated.
  • the demand degree calculation unit 13 selects an existing play video in which the correlation amount rel ( ⁇ P + , Q + >, ⁇ P, Q>) exceeds a predetermined threshold, and a set of the selected existing play videos Is defined as a data set V.
  • Step SD is a step of selecting a demand-stimulating event related to the supply possibility event detected in step SB and making it a data set E.
  • the demand score is considered to increase as the number of demand-stimulating events related to the supply possibility event increases.
  • a demand-stimulating event having log data whose correlation amount with a supply possibility event satisfies a predetermined condition (similar to a certain level or more) is a demand-stimulating event related to the supply possibility event.
  • the degree-of-demand calculating unit 13 calculates the correlation amount between the log data ⁇ P + , Q + > of the supply possibility event and the log data ⁇ P ⁇ , Q ⁇ > of each demand triggering event. This is calculated according to the same formula as formula (3).
  • the demand degree calculation unit 13 measures the correlation amount of each demand-stimulating event with respect to the supply possibility event by the following equation (5). ...
  • the demand level calculation unit 13 correlates rel ( ⁇ P + , Q + >, ⁇ P ⁇ , Q ⁇ >) for each demand-stimulating event in which scoreQ (Q + , Q ⁇ ) exceeds a predetermined threshold t. Is calculated.
  • the demand degree calculation unit 13 selects a demand-stimulating event in which the correlation amount rel ( ⁇ P + , Q + >, ⁇ P ⁇ , Q ⁇ >) exceeds a predetermined threshold, and selects the demand demanding event. Is defined as a data set E.
  • Step SE is a step of calculating a demand score from the data set V and the data set E.
  • the demand score is lowered as the number of accesses of the existing play video related to the data included in the data set V, that is, the supply possibility event is larger. Therefore, the demand score demandScore (V, E) of the present embodiment is calculated as the following equation (6).
  • rel (Ej) in Expression (6) is calculated for the demand-stimulating event E j of the j-th element of the data set E. ...
  • pageview (V i ) and feedback (V i ) indicate the number of page views of the play video of the i-th element of the data set V and the number of social feedbacks to the play video. That is, in this embodiment, the number of views (page view number) and the number of evaluations (number of social feedback) are adopted as the number of accesses to the existing play video.
  • the play video recording recommendation notifying unit 14 When the demand score calculated according to the above equation (6) satisfies a predetermined condition (for example, when exceeding a predetermined threshold), the play video recording recommendation notifying unit 14 generates the supply possibility event 2-2. The player is advised to record and upload the play video of the supply possibility event. That is, in the example of FIG. 2, the screen 103 is displayed on the terminal 2-2.
  • FIG. 4 is a flowchart for explaining the flow of the recording recommendation process according to the present embodiment.
  • step S1 the game execution unit 41 of the terminal 2-2 executes the game.
  • step S2 the log data generation unit 42 sequentially generates log data as the game progresses, and causes the log data holding unit 43 to hold the log data.
  • step S3 the supply possibility event detection unit 44 determines whether or not a supply possibility event has occurred.
  • Step S3 If the supply possibility event has not yet occurred, it is determined as NO in Step S3, and the process proceeds to Step S9.
  • step S9 the game execution unit 41 determines whether or not the game execution has ended.
  • YES is determined in step S9, and the recording recommendation process is ended.
  • the game is continued, it is determined as NO in Step S9, and the process returns to Step S2. That is, when the game is continued, the loop processing of Step S2, Step S3 No, and Step S9 No is repeated until the supply possibility event occurs, and log data is continuously generated. However, log data is not transmitted to the server 1.
  • step S11 the supply possibility event acquisition unit 22 of the server 1 determines whether or not supply possibility log data has been received. If the supply possibility log data has not been received, it is determined as NO in Step S11, and the process proceeds to Step S17.
  • step S ⁇ b> 17 the server 1 determines whether an instruction to end the process is given.
  • the instruction to end the process is not particularly limited, and for example, power-off of the server 1 can be employed. If an instruction to end the process is given, YES is determined in step S17, and the recording recommendation process ends. On the other hand, when the instruction to end the process is not given, it is determined as NO in Step S17, and the process returns to Step S11. In other words, unless an instruction to end the process is given, the loop process of step S11No and step S17No is repeated until the supply possibility event is received, and the server 1 enters a standby state.
  • Step S3 If a supply possibility event occurs during the game being executed on the terminal 2-2, it is determined as YES in Step S3, and the process proceeds to Step S4.
  • step S4 the log data transmission control unit 45 of the terminal 2-2 transmits the log data held in the log data holding unit 43 to the server 1 as log data of the supply possibility event.
  • step S11 the server 1 side determines YES in step S11, and the process proceeds to step S12.
  • step S12 the demand degree calculation unit 13 of the server 1 calculates the play video demand degree.
  • the processing of the above-described steps SC to SE is executed, and the demand score demandScore (V, E) shown in Expression (6) is calculated as the play video demand degree.
  • step S ⁇ b> 13 the play video recording recommendation notification unit 14 determines whether or not the play video demand level satisfies a predetermined requirement.
  • the predetermined requirement is not particularly limited, but in the present embodiment, since the demand score is adopted as the degree of demand for play video, the requirement that the demand score exceeds a predetermined threshold is adopted. And Therefore, when the demand score does not exceed the predetermined threshold, it is determined as NO in Step S13, and the process proceeds to Step S17. That is, when the end of the process is not instructed, the server 1 is in a standby state until the next supply possibility log data is received. On the other hand, when the demand score exceeds a predetermined threshold value, it is determined as YES in Step S13, and the process proceeds to Step S14.
  • step S14 the play video recording recommendation notifying unit 14 of the server 1 notifies the terminal 2-2 that has generated the supply possibility event to urge recording of the play video of the supply possibility event. That is, in step S6, the notification content presentation unit 46 of the terminal 2-2 presents the content of the notification to the player.
  • the notification presentation method is not particularly limited, but in this embodiment, a method of displaying the screen 103 of FIG. 2 on the terminal 2-2 is adopted.
  • step S7 the play video generation unit 47 of the terminal 2-2 determines whether or not there is a recording instruction.
  • the recording instruction is performed by pressing the “Yes” button on the screen 103 in FIG. Therefore, if the “Yes” button on the screen 103 in FIG. 2 has not been pressed, it is determined as NO in Step S7, and the process proceeds to Step S9. That is, in this case, although the recording of the play video is recommended, it is not accepted by the player, and the play video of the supply possibility event is not recorded. In this case, when the game further progresses and log data is sequentially generated and a new supply possibility event occurs, the processing from step S4 described above is executed.
  • Step S 7 when the “Yes” button on the screen 103 in FIG. 2 is pressed, it is determined as YES in Step S7, and the process proceeds to Step S8.
  • step S ⁇ b> 8 the play video generation unit 47 records the play video of the supply possibility event and uploads it to the server 1.
  • step S16 the play video management unit 16 of the server 1 determines whether or not the play video has been uploaded.
  • the determination method is not particularly limited, for example, in the present embodiment, a method of determining that the image has not been uploaded is employed when the image is not uploaded within a predetermined time. If it is determined that the file has not been uploaded, that is, NO is determined in step S15, and the process proceeds to step S17. That is, the server 1 enters a standby state.
  • step S ⁇ b> 16 the play video management unit 16 records the uploaded play video of the supply possibility event in the play video storage unit 15.
  • the play video recorded in the play video storage unit 15 is an existing play video for other supply possibility events that may occur in the future.
  • the play moving image management part 16 manages the log data of the supply possibility event received by the process of step S11 (YES) in association with a play moving image as log data.
  • the information processing system of the present embodiment can be used for various types of positive and negative events (defeat enemies / cannot defeat, clear / cannot clear the stage, defeat enemies with difficult difficulty / cancellation techniques) It can be applied to games of various genres because it is possible to recommend the aggregation of demand for play video and the creation of play video.
  • the information processing system of the present embodiment can automatically detect potentially high demand scenes and situations, and can strongly motivate a player who has played successfully in the scene to create a play video. Therefore, the creator of the moving image is provided with an opportunity for the moving image to be viewed by a large number of users, and the game player can be informed of a new way of playing the game.
  • the information processing system of this embodiment applies a play video shooting timing recommendation method that recommends players to shoot play videos in scenes and situations where demand from other players is estimated to be high. is doing. Therefore, the information processing system of the present embodiment, for example, a situation where a beginner is stuck at a certain stage or a situation where a specific boss cannot be defeated (first event processed as negative, that is, a demand-stimulating event), It will be aggregated as demand for play videos. Next, when a player plays to solve the situation (second event processed as a positive event, that is, a supply possibility event), the play content is high in demand as a play video. It is recommended to save and upload (share) as a play video.
  • first event processed as negative that is, a demand-stimulating event
  • a terminal that executes a game such as the terminals 2-1 and 2-2 may be a game dedicated terminal, but is often a terminal that is not dedicated to a game such as a smartphone.
  • Many users (players) who play games on terminals not dedicated to such games are so-called casual users.
  • casual users For such a casual user, it is not obvious what kind of play video is desired for other users, that is, what is the play video that is in demand from other users. For this reason, conventionally, it has not been easy for a casual user to create a moving image that satisfies the demands of other users.
  • the anxiety that casual users may not be evaluated by other users has been a high psychological hurdle that hinders the creation and release of play videos.
  • a game in which a tool kit for creating a play video is not spread to prevent such a casual user from creating a play video.
  • it is a toolkit for creating a play video that does not capture the game's play time, but provides an opportunity to create a pinpoint play video such as an interesting play, a beautiful play, a play that defeats a boss vividly, etc. It seems that it will contribute to the spread of games with embedded.
  • it is important to realize a matching mechanism between the demand for various play videos from various players and the content of play videos created by casual users.
  • Such a matching mechanism is realized by the information processing system of this embodiment.
  • the information processing system of the present embodiment has the following advantages.
  • the recommendation function for creating a play video can be implemented together with an SDK (Software Development Kit) for recording an arbitrary game video. That is, an information processing system can be constructed without depending on a specific play video recording method.
  • the information processing system of the present embodiment can be applied to any game title that can be interrupted.
  • the above-mentioned recommendation for recording a play video does not depend on a specific game genre, and can be applied to a wide range of game genres such as action, RPG, shooting, and simulation.
  • the log data of the event is shown as a vector on the multi-dimensional vector space.
  • the present invention is not particularly limited to this, that is, the log data is not necessarily expressed as such.
  • Various methods such as the upper node and the node in the network graph can be selected.
  • the similarity between two histograms can be measured using a distance measure called a histogram intersection or a distance measure called Earth Move's Distance.
  • Two nodes in the tree structure or network graph structure can measure the distance between the nodes as the number of hops.
  • any data structure that can provide a significant distance measure between two distribution data can be used.
  • the storage location of the play video is the play video storage unit 15 of the server 1 in the above-described embodiment, but is not particularly limited thereto, and is in a location different from the server 1 (for example, Netflix (registered trademark)).
  • Video storage that is, the play video does not necessarily have to be uploaded to the server 1, and the server 1 may manage it by uploading it to another location and using the location data (for example, URL (Uniform Resource Locator)). That is, when uploading a play video from the terminal 2-2, it is not uploaded to the server 1, but is uploaded to Youtube (registered trademark) or the like to acquire a URL, and only the URL is transmitted to the server 1. Also good.
  • an information processing system to which the present invention is applied can take various embodiments having the following configurations, including the information processing system as the embodiment of FIG. 1 described above. That is, an information processing system to which the present invention is applied is An information processing system including a plurality of terminals capable of executing a game and a server.
  • the server (for example, server 1 in FIG. 1) Among the plurality of terminals, log data of the first event from a terminal (for example, the terminal 2-1 in FIG. 1) that has generated a first event (for example, the demand-stimulating event described above) processed as negative in the game.
  • the log data of the second event is acquired from the terminal (for example, the terminal 2-2 in FIG.
  • Event acquisition means for example, event acquisition unit 11 in FIG. 1
  • the one related to the second event is selected from one or more of the first events, and based on the selection result, the degree of potential demand for the image related to the second event
  • a degree calculating means for example, the demand degree calculating unit 13 in FIG. 1) for calculating (for example, the demand score represented by the above-described equation (6));
  • Notifying means for example, the play video recording recommendation notifying unit 14 in FIG. 1) for notifying the terminal that has generated the second event that the degree satisfies the predetermined condition to urge recording of a moving image related to the second event.
  • Event detecting means for detecting the first event and the second event during the execution of the game (for example, demand demand event detecting unit 34, supply possibility event detecting unit 44 in FIG. 1)
  • Log providing means for example, log data transmission control unit 35, log data transmission control unit 45 in FIG. 1 for providing each log data of the first event and the second event to the server;
  • Presenting means for presenting the content of the notification from the server (for example, the notification content presentation unit 46); Is provided.
  • the series of processes described above can be executed by hardware or can be executed by software.
  • the functional configuration of FIG. 1 is merely an example, and is not particularly limited. That is, it is sufficient that the information processing system has a function capable of executing the above-described series of processes as a whole, and what functional block is used to realize this function is not particularly limited to the example of FIG.
  • the location of the functional block is not particularly limited to that in FIG. 1 and may be arbitrary.
  • the functional block of the server 1 may be transferred to the terminal 2-2 or the like, and conversely, the functional block of the terminal 2-2 may be transferred to the server 1 or the like.
  • one functional block may be constituted by hardware alone, software alone, or a combination thereof.
  • a program constituting the software is installed on a computer or the like from a network or a recording medium.
  • the computer may be a computer incorporated in dedicated hardware.
  • the computer may be a computer capable of executing various functions by installing various programs, for example, a general-purpose smartphone or personal computer other than a server.
  • the recording medium including such a program is not only constituted by a removable medium (not shown) distributed separately from the apparatus main body in order to provide the user with the program, but is also provided to the user in a state of being pre-installed in the apparatus main body. It is composed of a provided recording medium or the like.
  • the step of describing the program recorded on the recording medium is not limited to the processing performed in time series along the order, but is not necessarily performed in time series, either in parallel or individually.
  • the process to be executed is also included.
  • the term “system” means an overall apparatus configured by a plurality of devices, a plurality of means, and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Optics & Photonics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

　ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えること。　サーバ１のイベント取得部１１は、ゲーム内で負として処理された需要喚起イベントを発生させた端末２－１等から当該需要喚起イベントのログデータを取得する。イベント取得部１１は、ゲーム内で正として処理された供給可能性イベントを発生させた端末２－２から当該供給可能性イベントのログデータを取得する。需要度合演算部１３は、取得された夫々のログデータに基づいて１以上の需要喚起イベントの中から供給可能性イベントと関連するものを選択し、その選択結果に基づいて潜在需要の度合を演算する。プレイ動画記録推薦報知部１４は、当該度合が所定条件を満たす供給可能性イベントを発生させた端末２－２に対して、当該供給可能性イベントのプレイ動画の記録を促す報知を行う。

Description

情報処理システム、サーバ、プログラム、及び情報処理方法
　本発明は、情報処理システム、サーバ、プログラム、及び情報処理方法に関する。
　近年、スマートフォン等の端末上でのゲーム体験をプレイヤー同士で共有するために、プレイ中のゲーム画面を録画した動画像データが、数多くネット上にアップロードされるようになっている（特許文献１，２参照）。そのための環境も整いつつあり、このような動画像データを記録するための開発ツールも多数提供されるようになっている。
　ここで、プレイ中のゲーム画面を録画した動画像データは、一般的に「プレイ動画」と呼ばれている場合が多い。
　このような動画像データの他、プレイヤーそのものも含めて撮影されたゲームの実行内容を示す動画像データも存在する。このような動画像データは、一般的に「ゲーム実況動画」と呼ばれている。
　ただし、以下においては、「ゲーム実況動画」も含めて、即ち、これらの動画像データを総称して「プレイ動画」と呼ぶことにする。
　即ち、本明細書では、「プレイ動画」とは、所定のゲームの実行内容を示す画像という広義な概念である。
　今後、プレイ動画を作成可能なツールキットが組み込まれたゲームが数多く登場すると予想される。この場合のプレイ動画は、プレイ時間の間ずっと撮影されたものではなく、面白いプレイ、美しいプレイ、ボスを鮮やかに倒すプレイ等の、ピンポイントのものが多くなると予想される。
　このようなピンポイントのプレイ動画が数多くアップロードされることによって、プレイ動画の共有と視聴のサイクルが確立し、その結果として、上記のようなプレイ動画作成機能を有するゲームが普及するものと思われる。
米国特許出願公開第２０１４／００９４３０２号明細書 米国特許出願公開第２０１４／０２２８１１２号明細書
　しかしながら、特許文献１及び２を含め従来の技術では、他のプレイヤーから必要とされるプレイ動画をピンポイントで作成することは容易ではなく、視聴されることの少ないプレイ動画が大量に蓄積され、プレイ動画の共有と視聴のサイクルの確立が阻害されることになると予想される。
　このため、カジュアルなプレイヤー（ユーザー）が、質の高いプレイ動画、即ち他プレイヤーから必要とされるプレイ動画を容易に作成することを支援する新たな仕組み要求されている。
　本発明は、このような状況に鑑みてなされたものであり、ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えることを目的とする。
　上記目的を達成するため、本発明の一態様の情報処理システムは、
　ゲームを実行し得る複数の端末と、サーバとを含む情報処理システムであって、
　前記サーバは、
　　前記複数の端末のうち、前記ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、前記ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得手段と、
　取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算する度合演算手段と、
　当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、当該第２イベントに関する動画像の記録を促す報知を行う報知手段と、
　を備え、
　前記複数の端末の少なくとも一部は、
　　前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出手段と、
　　前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供手段と、
　　前記サーバからの前記報知の内容を提示する提示手段と、
　を備える。
　これにより、ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えることができる。
　本発明の一態様のサーバは、
　ゲームを実行し得る複数の端末と通信をするサーバにおいて、
　前記複数の端末のうち、前記ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得手段と、
　取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算する度合演算手段と、
　前記度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する画像データの記録を促す報知を行う報知手段と、
　を備える。
　これにより、ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えることができる。
　さらに、前記ログデータは、前記ゲームの実行時に得られる属性情報を１種類以上含み、
　前記度合演算手段は、
　　前記第２イベントの前記ログデータと、１以上の前記第１イベントの前記ログデータの夫々との相関量を算出し、
　　前記相関量が所定基準を満たす前記ログデータを有する前記第１イベントを、前記第２イベントと関連するものとして選択するようにすることができる。
　これにより、適切な潜在需要の度合を算出することが可能になり、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えるための報知をより適切にすることができる。
　さらに、前記ログデータは、前記ゲームの進行状況を示すログデータと、前記ゲームのプレイヤーの状態を示すログデータとを含むようにすることができる。
　これにより、ゲーム実行中のプレイヤーに対して、当該ゲームの進行状況や当該プレイヤーの状態と相関のある別のプレイヤーからの閲覧需要があることを報知できるので、当該プレイ動画データをアップロードすべき動機付けを適切に与えることができる。
　また、前記ログデータは、多次元ベクトル空間上のベクトルで表され、
　前記度合演算手段は、前記第２イベントの前記ログデータを表すベクトルと、１以上の前記第１イベントの前記ログデータを表すベクトルの夫々との前記多次元ベクトル空間上の距離を、前記相関量として算出するようにすることができる。
　これにより、さらに一段と適切な潜在需要の度合を算出することが可能になり、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えるための報知をより適切にすることができる。
　また、前記度合演算手段は、
　前記第２イベントと関連する前記第１イベントの選択数が多いほど、当該第２イベントに関する画像の潜在需要の前記度合を高めるようにすることができる。
　これにより、さらに一段と適切な潜在需要の度合を算出することが可能になり、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えるための報知をより適切にすることができる。
　また、前記サーバは、過去に実行された前記ゲームの所定イベントに関する画像データ又は当該画像データの所在データを管理する管理手段をさらに備え、
　前記度合演算手段は、
　　前記管理手段により管理されている前記画像データ又は前記所在データにより特定される画像データのうち、前記第２イベントに関連する画像データへのアクセス数を求め、
　　当該アクセス数が多いほど、当該第２イベントに関する画像の潜在需要の前記度合を低下させるようにすることができる。
　これにより、さらに一段と適切な潜在需要の度合を算出することが可能になり、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えるための報知をより適切にすることができる。
　本発明の一態様の第１のプログラムは、上述の本発明の一態様のサーバに対応する情報処理方法である。
　本発明の一態様の第２プログラムは、上述の本発明の一態様の情報処理システムにおける端末を制御するコンピュータに実行させるプログラムである。
　即ち、
　ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得機能と、
　取得された前記ログデータの夫々に基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算し、当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する画像データの記録を促す報知を行う報知機能と、
　を備えるサーバとの間で通信する端末を制御するコンピュータに、
　前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出ステップと、
　前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供ステップと、
　前記サーバからの前記報知の内容を提示する提示ステップと、
　を含む制御処理を実行させる。
　これにより、ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えることができる。
　本発明の一態様の上記第２プログラムに対応する情報処理方法も、本発明の一態様の情報処理方法として提供される。
　本発明によれば、ゲーム実行中のプレイヤーに対して、プレイ動画の作成及びアップロードについての継続的な動機付けを効果的に与えることができると共に、ゲームを実行中のプレイヤーに対して、他のプレイヤーが必要とするプレイ動画を作成及びアップロートすることを促し、プレイ動画の需要を迅速に満たすサイクルを実現することができる。
本発明の一実施形態に係る情報システムの機能的構成を示す機能ブロック図である。 図１の情報システムにおける、需要喚起イベントの検出と、図１の端末２－２における供給可能性イベントの検出に基づくプレイ動画の推薦とを説明するための図である。 多次元の特徴空間内で定義されたベクトル間の相関量を計量する手法について説明するための図である。 図１の情報処理システムが実行される録画推奨処理を示すフローチャートである。
　以下、本発明の実施形態について、図面を用いて説明する。
　なお、以下において、単に「画像」と呼ぶ場合には、「動画像」と「静止画像」との両方を含むものとする。
　また、「動画像」には、次の第１処理乃至第３処理の夫々により表示される画像を含むものとする。
　第１処理とは、平面画像（２Ｄ画像）におけるオブジェクト（例えばゲームキャラクタ）の夫々の動作に対して、複数枚からなる一連の静止画像を時間経過とともに連続的に切り替えて表示させる処理をいう。具体的には例えば、２次元アニメーション、いわゆるパラパラ漫画的な処理が第１処理に該当する。
　第２処理とは、立体画像（３Ｄモデルの画像）におけるオブジェクト（例えばゲームキャラクタ）の夫々の動作に対応するモーションを設定しておき、時間経過とともに当該モーションを変化させて表示させる処理をいう。具体的には例えば、３次元アニメーションが第２処理に該当する。
　第３処理とは、オブジェクト（例えばゲームキャラクタ）の夫々の動作に対応した映像（即ち動画）を準備しておき、時間経過とともに当該映像を流していく処理をいう。
　図１は、本発明の一実施形態に係る情報処理システムの構成を示している。
　図１に示す情報処理システムは、サーバ１と、端末２－１，２－２の各々が、図示せぬインターネット等の所定のネットワークを介して相互に接続されることで構成されている。なお、図１には２台の端末２－１，２－２しか図示されていないが、これは本発明の説明を容易にするためである。実際には、情報処理システムにおけるサーバ１には、多数の端末が接続され得る。
　本実施形態におけるサーバ１及び端末２－１，２－２の夫々は、コンピュータ及びその周辺装置に適用される。本実施形態における各部は、コンピュータ及びその周辺装置が備えるハードウェア並びに当該ハードウェアを制御するソフトウェアによって構成される。
　上記ハードウェアには、制御部としてのＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）の他、記憶部、通信部、表示部及び入力部が含まれる。記憶部としては、例えば、メモリ（ＲＡＭ：Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ、ＲＯＭ：Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ等）、ハードディスクドライブ（ＨＤＤ：Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）、光ディスク（ＣＤ：Ｃｏｍｐａｃｔ　Ｄｉｓｋ、ＤＶＤ：Ｄｉｇｉｔａｌ　Ｖｅｒｓａｔｉｌｅ　Ｄｉｓｋ等）ドライブ等が挙げられる。通信部としては、例えば、各種有線及び無線インターフェース装置が挙げられる。表示部としては、例えば、液晶ディスプレイ等の各種ディスプレイが挙げられる。入力部としては、例えば、キーボードやポインティング・デバイス（マウス、トラッキングボール等）が挙げられる。
　なお、本実施形態の端末２－１，２－２は、スマートフォンとして構成され、入力部と表示部を兼ね備えたタッチパネルも有している。
　タッチパネルの入力部は、例えば表示部の表示領域に積層される静電容量式又は抵抗膜式の位置入力センサにより構成され、タッチ操作がなされた位置の座標を検出する。ここで、タッチ操作とは、表示媒体たるタッチパネル（正確にはそのうちの入力部）に対する物体（ユーザの指やタッチペン等）の接触又は近接の操作をいう。なお、以下、タッチ操作がなされた位置を「タッチ位置」と呼び、タッチ位置の座標を「タッチ座標」と呼ぶ。
　また、上記ソフトウェアには、上記ハードウェアを制御するコンピュータ・プログラムやデータが含まれる。コンピュータ・プログラムやデータは、記憶部により記憶され、制御部により適宜実行、参照される。また、コンピュータ・プログラムやデータは、通信回線を介して配布されることも可能であり、ＣＤ－ＲＯＭ等のコンピュータ可読媒体に記録して配布されることも可能である。
　サーバ１及び端末２－１，２－２の夫々は、このようなハードウェアとソフトウェアの協働による各種動作をすべく、図１に示すような機能的構成を有している。
　サーバ１は、イベント取得部１１と、需要ログ記憶部１２と、需要度合演算部１３と、プレイ動画記録推薦報知部１４と、プレイ動画記憶部１５と、プレイ動画管理部１６とを備えている。
　イベント取得部１１は、複数の端末（図１の例では端末２－１，２－２）のうち、所定のゲーム内で負として処理された第１イベントを発生させた端末（図１の例では端末２－１）から当該第１イベントのログデータを取得する。
　また、イベント取得部１１は、複数の端末のうち、当該ゲーム内で正として処理された第２イベントを発生させた端末（図１の例では端末２－２）から当該第２イベントのログデータを取得する。
　ここで、ゲームは、複数のイベントを含むものとする。また、複数のイベントのうち少なくとも一部は、プレイヤーの操作等に応じて正又は負として選択的に処理されるものとする。
　なお、ここでいう「正」と「負」は、対になる概念という意である。つまり、プレイヤーの操作に応じて、対になる２つの処理が選択的に行われれば足り、それらの処理内容等は特に限定されない。
　例えば、負として処理される第１イベントには、ゲーム内で失敗的な状況として処理されるイベントが含まれる。
　具体的には例えば、ゲームオーバー、レアアイテムの獲得の失敗、ＮＰＣ（Ｎｏｎ－Ｐｌａｙｅｒ　Ｃｈａｒａｃｔｅｒ）を仲間にすることに失敗、及びストーリー分岐点を見つけられない等が、第１イベントに含まれる。
　このような第１イベントとは、それを経験したプレイヤーが、第１イベントに関連するプレイ動画（例えば成功的な状況として処理されるまでの過程を示す他人のプレイ動画等）の視聴を所望する可能性が高いイベントであると把握できる。そこで以下、このような第１イベントを「需要喚起イベント」と呼ぶ。
　これに対して例えば、正として処理される第２イベントには、ゲーム内で成功的な状況として処理されるイベントが含まれる。
　具体的には例えば、ステージクリア、レアアイテムの獲得、ＮＰＣを仲間にする、ストーリー分岐点を見つける等が、第２イベントに含まれる。
　このような第２イベントは、当該第２イベントに関連するプレイ動画（例えば成功的な状況として処理されるまでの過程を示すプレイ動画）を公開することにより、他のプレイヤーの需要を満たす可能性が高いイベントである。そこで以下、このような第２イベントを「供給可能性イベント」と呼ぶ。
　また、ここでいうログデータとは、ゲーム内において時々刻々と変化する状況等の履歴を示すデータである。即ち、ここでいうログデータとは、取得タイミングによらず同一内容となる静的データではなく、取得タイミングに応じて内容が変化する動的なデータ（リアルタイムデータ）である。
　例えば本実施形態では、ログデータは、ゲーム内の属性情報を要素として、任意の個数の任意の種類の要素の集合体からなるデータである。そして本実施形態では、ログデータには、ゲームの進行状況を示すログデータと、ゲームのプレイヤーの状態を示すログデータとが含まれている。
　つまり、需要喚起イベントのログデータとは、プレイヤーが当該需要喚起イベントを体験した時点における、ゲームの進行状況及びプレイヤーの状況を示す履歴のデータである。
　これに対して、供給可能性イベントのログデータとは、プレイヤーが当該供給可能性イベントを体験した時点における、ゲームの進行状況及びプレイヤーの状況を示す履歴のデータである。
　なお、以下、説明の簡略上、需要喚起イベントは端末２－１において発生され、供給可能性イベントは端末２－２において発生されるものとする。
　つまり、図１の例では、イベント取得部１１のうち、需要喚起イベント取得部２１は、端末２－１で発生した需要喚起イベントのログデータを取得する一方、供給可能性イベント取得部２２は、端末２－２で発生した供給可能性イベントのログデータを取得するものとする。
　ただし、需要喚起イベントも供給可能性イベントも、ゲームを実行中の任意の端末（端末２－１，２－２含む）で発生し得る点については言うまでもない。
　ここで、このようなサーバ１に対して、需要喚起イベントのログデータを送信する端末（図１の例では端末２－１）においては、図１に示すように、ゲーム実行部３１と、ログデータ生成部３２と、ログデータ保持部３３と、需要喚起イベント検出部３４と、ログデータ送信制御部３５とが機能する。
　ゲーム実行部３１は、所定のゲームを実行する。
　ログデータ生成部３２は、当該所定のゲームの実行中においてログデータを逐次生成する。ログデータ保持部３３は、このようにして逐次生成されるログデータを保持する。
　即ち、ゲームの進行状況やプレイヤーの状態は刻々と変化していくが、このようなゲームの進行状況やプレイヤーの状態を示すログデータが逐次（リアルタイム）取得されて保持されていく。
　需要喚起イベント検出部３４は、需要喚起イベントが発生したことを検出する。
　ログデータ送信制御部３５は、ゲームの実行中において所定のタイミングで生成されたログデータを、サーバ１に送信する制御を実行する。本実施形態では、需要喚起イベント検出部３４によって需要喚起イベントが検出されたときが所定のタイミングに該当する。つまり、本実施形態では、ログデータは、リアルタイムに逐次生成されていくが、サーバ１に常に送信されるわけではなく、需要喚起イベントが検出されたときのみ、需要喚起イベントのログデータとして送信される。
　需要ログ記憶部１２は、このような端末２－１を含む各種端末から送信されてきた、需要喚起イベントのログデータを記憶する。
　ここで、ゲーム内の所定イベントは、あるプレイヤーにとっては需要喚起イベントになる場合もあるし、別のプレイヤーにとっては需要喚起イベントとはならない場合（供給可能性イベントになる場合）もある。つまり、需要喚起イベントとなったプレイヤーの数は、ゲーム内の各種イベント毎に異なる。例えばクリアが難しいイベントでは、需要喚起イベントとなったプレイヤーの数が多くなると予想される。
　従って、需要喚起イベントのログデータは、ゲーム内の各種各様なイベント毎に需要ログ記憶部１２に記憶され得る。また、同一イベントの観点でみると、各種各様な状況で当該イベントを体験した複数のプレイヤーの夫々についての複数の需要喚起イベントのログデータが、需要ログ記憶部１２に記憶され得る。
　需要度合演算部１３は、供給可能性イベント取得部２２により取得された供給可能性イベントのログデータ、及び需要ログ記憶部１２に記憶された複数の需要喚起イベントのログデータに基づいて、当該供給可能性イベントと関連する需要喚起イベントを１以上選択する。
　そして、需要度合演算部１３は、その選択結果に基づいて、当該供給可能性イベントのプレイ動画の潜在需要の度合（以下、「プレイ動画需要度合」と呼ぶ）を演算する。
　なお、供給可能性イベントと関連する需要喚起イベントの選択手法は、特に限定されないが、本実施形態では次のような手法が適用されている。
　即ち、需要度合演算部１３は、供給可能性イベントのログデータと、１以上の需要喚起イベントのログデータの夫々との相関量を算出する。
　そして、需要度合演算部１３は、相関量が所定基準を満たすログデータを有する需要喚起イベントを、供給可能性イベントと関連するものとして選択する。
　また、需要度合演算部１３によるプレイ動画需要度合の演算手法は、特に限定されないが、本実施形態では次のような手法が適用されている。
　即ち、上述したように、あるプレイヤーにとっては供給可能性イベントとなったイベントであっても、別プレイヤーにとっては、需要喚起イベントになる場合もある。このような別プレイヤーにとっては、供給可能性イベントのプレイ動画（成功の状況に至るまでの過程を示すプレイ動画）の視聴を所望する可能性が高い。
　従って、本実施形態では、需要度合演算部１３は、対象の供給可能性イベントと関連する需要喚起イベントの選択数が多いほど、プレイ動画需要度合を高める。
　一方で、対象の供給可能性イベントのプレイ動画が別ユーザから既にアップロードされていれば、需要喚起イベントとなったユーザにとっては、既にアップロードされたプレイ動画を視聴すれば足りる場合もある。このような場合、新たな供給可能性イベントのプレイ動画の需要は減少すると把握することもできる。
　本実施形態では、後述するプレイ動画記憶部１５には、過去に実行されたゲームについてのプレイ動画が多数アップロードされて記憶されている。そして、後述するプレイ動画管理部１６によって、プレイ動画記憶部１５に記憶された各プレイ動画のアクセスが管理されている。
　需要度合演算部１３は、プレイ動画記憶部１５に既にアップロード済みのプレイ動画のうち、対象の供給イベントに関連するプレイ動画へのアクセス数を求め、当該アクセス数が多いほど、プレイ動画需要度合を低くする。
　なお、プレイ動画需要度合の具体例として、本実施形態では需要スコアｄｅｍａｎｄＳｃｏｒｅ（Ｖ，Ｅ）が採用されている。需要スコアｄｅｍａｎｄＳｃｏｒｅ（Ｖ，Ｅ）の詳細については、後述する。
　プレイ動画記録推薦報知部１４は、プレイ動画需要度合が所定の条件を満たす供給可能性イベントを発生させた端末（図１の例では端末２－２）に対して、当該供給可能性イベントのプレイ動画の記録を促す報知を行う。
　なお、所定の条件は、特に限定されず、例えば所定の閾値を設け、プレイ動画需要度合が当該閾値を超えたという条件を採用してもよい。
　報知の仕方は、特に限定されない。本実施形態の報知の具体例については、図２を参照して後述する。
　このようなサーバ１に対して、供給可能性イベントのログデータを送信して、当該供給可能性イベントのプレイ動画の記録を促す報知がなされ得る端末（図１の例では端末２－２）においては、図１に示すように、ゲーム実行部４１と、ログデータ生成部４２と、ログデータ保持部４３と、供給可能性イベント検出部４４と、ログデータ送信制御部４５と、報知内容提示部４６とが機能する。
　ゲーム実行部４１は、所定のゲームを実行する。
　ログデータ生成部４２は、当該所定のゲームの実行中においてログデータを逐次生成する。ログデータ保持部４３は、このようにして逐次生成されるログデータを保持する。即ち、ゲームの進行状況やプレイヤーの状態を示すログデータが逐次（リアルタイム）に取得されて保持されていく点は端末２－１と同様である。
　供給可能性イベント検出部４４は、供給可能性イベントが発生したことを検出する。
　ログデータ送信制御部４５は、ゲームの実行中において所定のタイミングで生成されたログデータを、サーバ１に送信する制御を実行する。本実施形態では、供給可能性イベント検出部４４によって供給可能性イベントが検出されたときが所定のタイミングに該当する。つまり、本実施形態では、ログデータは、リアルタイムに逐次生成されていくが、サーバ１に常に送信されるわけではなく、供給可能性イベントが検出されたときのログデータ（供給可能性イベントの状況等を示すログデータ）のみが送信される。
　報知内容提示部４６は、供給可能性イベントのプレイ動画の記録を促す報知がなされた場合、当該報知の内容をプレイヤーに提示する。
　なお、提示の手法は特に限定されないが、本実施形態では、画像（例えば後述の画面１０３）を表示する手法が採用されている。
　当該報知を受けたプレイヤーは、供給可能性イベントのプレイ動画の記録を所望する場合、所定の指示操作（後述の図２の例では画面１０３内の「はい」のボタンを押下する操作）をする。
　プレイ動画生成部４７は、当該指示操作を受け付けると、供給可能性イベントのプレイ動画を生成し、サーバ１にアップロードする。
　サーバ１のプレイ動画管理部１６は、端末２－２からアップロードされた供給可能性イベントのプレイ動画を、先に供給可能性イベント取得部２２により取得されたログデータと関連付けて、プレイ動画記憶部１５に記憶させる。
　即ち、プレイ動画記憶部１５は、所定のゲームについての各種各様なプレイ動画（主に供給可能性イベントのプレイ動画）を記憶する。
　さらに以下、図２以降の図面を参照して、本実施形態の情報処理システムについて詳細に説明する。
　図２は、図１の端末２－１における需要喚起イベントの検出と、図１の端末２－２における供給可能性イベントの検出に基づくプレイ動画の推薦とを説明するための図である。
　ステップＳａにおいて、需要喚起イベントの検出と集計が行われる。
　具体的には例えば、画面１０１は、端末２－１のプレイヤーが実行するゲームにおいて、あるステージでゲームオーバーになってしまった状況を示している。このような失敗的な状況（即ち、負として処理される第１イベント）が当該ステージの需要喚起イベントとして検出され、当該需要喚起イベントのログデータがサーバ１の需要ログ記憶部１２に蓄積される。
　このような需要喚起イベントのログデータは、端末２－１に限らず任意の端末において、需要喚起イベントが発生する毎に取得され、需要ログ記憶部１２に蓄積され、適宜イベント毎に集計が行われる。
　ステップＳｂにおいて、供給可能性イベントの検出が行われる。
　具体的には例えば、画面１０２は、端末２－２のプレイヤーが上記ステージをクリアした状況を示している。このような成功的な状況（即ち、正として処理される第２イベント）が当該ステージの供給可能性イベントとして検出される。
　そして、当該供給可能性イベントについて、ステップＳａの集計結果に基づいてプレイ動画需要度合が算出される。
　当該プレイ動画需要度合が高ければ（所定の条件を満たせば）、当該供給可能性イベントのプレイ動画（ステージをクリアするまでの過程を示すプレイ動画）の閲覧を所望する潜在的需要があるとみなされ、当該プレイ動画を作成してアップロードすることを推奨する画面１０３が端末２－２に提示される。
　なお、このような供給可能性イベントのプレイ動画がサーバ１にアップロードされた場合、ステップＳｃにおいて、需要の高い動画像（プレイ動画）として、図示せぬリコメンデーションエンジンを通じて、需要喚起イベントが発生した端末２－１等に配信される。
　このように、プレイ動画の推薦（画面１０３の提示）をするか否かは、プレイ動画需要度合に基づいて行われる。そこで、以下、プレイ動画需要度合についてより具体的に説明する。
　上述したように、所定の供給可能性イベントについてのプレイ動画需要度合は、当該供給可能性イベントと関連する需要喚起イベントの数の多少に基づいて変化する。そして、当該供給可能性イベントと需要喚起イベントとが関連するか否かは、当該供給可能性イベントと需要喚起イベントとの各ログデータの相関量に基づいて行われる。
　ここで、相関量の演算手法は、特に限定されないが、本実施形態では次のような手法が採用されている。
　即ち、本実施形態のログデータは、ゲームの実行時に得られる属性情報を複数種類含んでおり、複数種類の属性情報の夫々を各要素として構成されるベクトル、即ち、多次元ベクトル空間上のベクトルで表されている。
　そこで、需要度合演算部１３は、供給可能性イベントのログデータを表すベクトルと、需要ログ記憶部１２に記憶されている各需要喚起イベントのログデータを表すベクトルの夫々との多次元ベクトル空間上の距離を、相関量として算出する。
　図３を参照して、このような相関量の演算手法のさらなる詳細について説明する。
　図３は、多次元の特徴空間内で定義されたベクトル間の相関量を計量する手法について説明するための図である。
　ここでは図解のため３次元で表現しているが、実際の特徴空間はｎ次元（ｎは、１以上の任意の整数値）のベクトル空間であり、各特長軸は、ゲームの実行時に得られる所定種類の属性情報、例えばゲーム内の個別のアイテムやスキル等に対応している。従って、あるプレイヤーのゲーム内の状態（ログデータ）は、この多次元ベクトル空間上の１つのベクトルとして表すことができる。
　図３では、３人のプレイヤーの各状況（ログデータ）がベクトルＡ乃至Ｃの夫々で表されている。
　このようなプレイヤーの状況を示すベクトル間の距離、即ちベクトル同士の内積が、相関量として用いられている。
　図３の例では、ベクトルＡについては、ベクトルＣよりもベクトルＢの方が近距離である。従って、ベクトルＡに対応するプレイヤーの状況（ログデータ）は、ベクトルＣに対応するプレイヤーの状況（ログデータ）よりも、ベクトルＢに対応するプレイヤーの状況（ログデータ）と関連している（類似している）ことになる。
　ここで、１つのログデータは、プレイヤーの状態を示すログデータＰと、ゲームの進行状態を示すログデータＱとの組み合わせ＜Ｐ，Ｑ＞として記述できる。
　先ず、プレイヤーの状態を示すログデータＰは、プレイヤーのレベルや各種パラメータ、所有アイテム、所有スキル等のプレイヤーのゲーム内の属性情報を、次の式（１）で示すようなｎ次元のベクトルとして表現したものである。
Figure JPOXMLDOC01-appb-M000001
 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・（１）
　ここで、piは、プレイヤーのゲーム内の属性情報のうち、ｉ番目の属性に対応する０～１の実数を示す。これらの値は、無限大ノルム正規化が行われていることが好ましい。例えば、最大レベルが１００のゲームでは、レベルの値を最大値で正規化することにより、レベル１を０．０１とし、レベル１００を１として表現することができる。また、多く所有することに価値があるタイプのアイテムについて、その所有数を表現するときは、所有可能な最大値で正規化することができる。これらの属性の数は、ゲーム内容に応じて、数百～数千になる場合がある。例えば、ゲーム内に５００種類のアイテムがあり、スキルが５００種類ある時、ｎの値は１０００以上となる。
　次に、ゲームの進行状態を示すログデータＱは、ゲームの進行状態、あるいは、ゲームの仮想空間上の場所を示すデータの集合として表現することができる。例えば、横にスクロールするアクションゲームにおいて、プレイヤーの到達した位置を表す有限個のセルＩＤのシーケンスをログデータＱに含めることができる。さらに、ＲＰＧ（Ｒｏｌｌ－Ｐｌａｙｉｎｇ　Ｇａｍｅ）では、有限個のシーン番号を用いてゲームの進行状態を表現しているので、このシーン番号のシーケンスもログデータＱに含めることができる。一般に、ゲームソフトウェアはゲームの進行状態を管理するためのフラグやＩＤを内蔵しているので、ゲームの進行状態を示すログデータＱはそれらのデータを用いて容易に定義でき、次の式（２）で示すようなｍ次元のベクトルとして表現される。
Figure JPOXMLDOC01-appb-M000002
 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・（２）
　ここで、qiは、プレイヤーのゲームの進行状態のうちｉ番目の状態を、プレイ動画が含んでいる場合は１の値となり、含んでいない場合は０の値となる。
　なお、以下、重要喚起イベントと供給可能性イベントとのログデータを明確に区別すべく、需要喚起イベントのログデータを＜Ｐ－，Ｑ－＞と記述し、供給可能性イベントのログデータを＜Ｐ＋，Ｑ＋＞と記述する。
　さらに本実施形態では、所定の供給可能性イベントについてのプレイ動画需要度合は、当該供給可能性イベントと関連する需要喚起イベントの数の多少のみならず、当該供給可能性イベントと関連するプレイ動画が既にアップロードされているか否かに基づいても変化する。
　このため、プレイ動画記憶部１５に既にアップロードされている所定イベントのプレイ動画（以下、「既存プレイ動画」と呼ぶ）についても、当該所定ベントのログデータが対応付けられているものとする。このような既存プレイ動画に対応付けられたログデータを、上述の重要喚起イベントと供給可能性イベントとのログデータを明確に区別すべく、＜Ｐ，Ｑ＞と記述するものとする。
　このようにして定義された３種類のログデータを用いたプレイ動画需要度合の具体的な演算例について、ステップＳＡ乃至ＳＥの５段階にわけて説明する。
　なお、以下の例では、プレイ動画需要度合は、スコアとして算出される。そこで以下、このようなスコアを「需要スコア」と呼ぶ。
　ステップＳＡは、需要喚起イベントを検出するステップである。
　図１の例では端末２－１のみであるが、実際には、サーバ１により管理される図示せぬ全端末のゲームのプレイ状況がモニタリングされ、需要喚起イベントが検出される。
　需要喚起イベントが検出される毎に、需要喚起イベントのログデータ＜Ｐ－，Ｑ－＞が需要ログ記憶部１２に蓄積される。
　ステップＳＢは、供給可能性イベントを検出するステップである。
　図１の例では端末２－２のみであるが、実際には、サーバ１により管理される図示せぬ全端末のゲームのプレイ状況がモニタリングされ、供給可能性イベントが検出される。
　供給可能性イベントが検出されると、供給可能性イベントのログデータ＜Ｐ＋，Ｑ＋＞が需要度合演算部１３に取得される。
　そこで、需要度合演算部１３は、次のステップＳＣ乃至ＳＦの処理を実行する。
　ステップＳＣは、ステップＳＢで検出された供給可能性イベントと関連する既存プレイ動画を選択して、データ集合Ｖとするステップである。
　需要スコアは、当該供給可能性イベントと関連する既存プレイ動画が存在する場合には、当該既存プレイ動画のアクセス数が多いほど（重複するほど）低下させると好適である。
　そこで、本実施形態では、供給可能性イベントとの相関量が所定条件を満たす（一定以上に類似している）ログデータを有する既存プレイ動画が、当該供給可能性イベントと関連する既存プレイ動画として抽出される。
　具体的には、需要度合演算部１３は、当該供給可能性イベントのログデータ＜Ｐ＋，Ｑ＋＞と、各既存プレイ動画のログデータ＜Ｐ，Ｑ＞との相関量を、次の式（３）で示すような２つの内積によって算出する。
Figure JPOXMLDOC01-appb-M000003
 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・（３）
　ここで、ｓｃｏｒｅＰ（Ｐ＋，Ｐ）は、当該供給可能性イベントを発生させたプレイヤーの状態を示すログデータＰ＋と、各既存プレイ動画をアップロードしたプレイヤーの状態を示すログデータＰとの相関量の重み値を示す。この重み値が高いほど、プレイヤーの状態が類似していることになる。
　また、ｓｃｏｒｅＱ（Ｑ＋，Ｑ）は、当該供給可能性イベントにおけるゲームの進行状態を示すログデータＱ＋と、各既存プレイ動画が示すゲームの進行状態を示すログデータＱとの相関量の重み値を示す。この重み値が高いほど、ゲームの進行状態が類似していることになる。
　需要度合演算部１３は、これら２つの重み値を組み合わせた次の式（４）により、当該供給可能性イベントに対する各既存プレイ動画の相関量を計量する。
Figure JPOXMLDOC01-appb-M000004
 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・（４）
　即ち、需要度合演算部１３は、ｓｃｏｒｅＱ（Ｑ＋，Ｑ）が所定の閾値ｔを上回る各既存プレイ動画について、上記２つの重み値の積として、相関量ｒｅｌ（＜Ｐ＋，Ｑ＋＞，＜Ｐ，Ｑ＞）を算出する。
　そして、需要度合演算部１３は、当該相関量ｒｅｌ（＜Ｐ＋，Ｑ＋＞，＜Ｐ，Ｑ＞）が所定の閾値を超える既存プレイ動画を選択して、選択された既存プレイ動画の集合をデータ集合Ｖと定義する。
　ステップＳＤは、ステップＳＢで検出された供給可能性イベントと関連する需要喚起イベントを選択して、データ集合Ｅとするステップである。
　需要スコアは、当該供給可能性イベントと関連する需要喚起イベントの数が多いほど上昇すると考えられる。
　そこで、本実施形態では、供給可能性イベントとの相関量が所定条件を満たす（一定以上に類似している）ログデータを有する需要喚起イベントが、当該供給可能性イベントと関連する需要喚起イベントとして抽出される。
　具体的には、需要度合演算部１３は、当該供給可能性イベントのログデータ＜Ｐ＋，Ｑ＋＞と、各需要喚起イベントのログデータ＜Ｐ－，Ｑ－＞との相関量を、上述の式（３）と同様の式に従って算出する。
　そして、需要度合演算部１３は、次の式（５）により、当該供給可能性イベントに対する各需要喚起イベントの相関量を計量する。
Figure JPOXMLDOC01-appb-M000005
 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・（５）
　即ち、需要度合演算部１３は、ｓｃｏｒｅＱ（Ｑ＋，Ｑ－）が所定の閾値ｔを上回る各需要喚起イベントについて、相関量ｒｅｌ（＜Ｐ＋，Ｑ＋＞，＜Ｐ－，Ｑ－＞）を算出する。
　そして、需要度合演算部１３は、当該相関量ｒｅｌ（＜Ｐ＋，Ｑ＋＞，＜Ｐ－，Ｑ－＞）が所定の閾値を超える需要喚起イベントを選択して、選択された需要喚起ベントの集合をデータ集合Ｅと定義する。
　ステップＳＥは、データ集合Ｖとデータ集合Ｅから需要スコアを算出するステップである。
　上述のように、データ集合Ｅに含まれるデータ数、即ち供給可能性イベントと関連する需要喚起イベントの数が多いほど、需要スコアを上昇させると好適である。一方、データ集合Ｖに含まれるデータ、即ち供給可能性イベントと関連のある既存プレイ動画のアクセス数が多いほど、需要スコアを低下させると好適である。
　そこで、本実施形態の需要スコアｄｅｍａｎｄＳｃｏｒｅ（Ｖ，Ｅ）は、次の式（６）のように算出される。なお、式（６）のｒｅｌ（Ｅｊ）は、データ集合Ｅのｊ番目の要素の需要喚起イベントＥｊについて計算したものである。
Figure JPOXMLDOC01-appb-M000006
 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・（６）
　ここで、ｐａｇｅｖｉｅｗ（Ｖｉ）とｆｅｅｄｂａｃｋ（Ｖｉ）は、データ集合Ｖのｉ番目の要素のプレイ動画のページビュー数と当該プレイ動画へのソーシャルフィードバックの回数を示す。即ち、既存プレイ動画のアクセス数として、本実施形態では、閲覧数（ページビュー数）と、評価数（ソーシャルフィードバックの回数）とが採用されている。
　プレイ動画記録推薦報知部１４は、上述の式（６）に従って算出された需要スコアが所定の条件を満たす場合（例えば所定の閾値を超える場合）、供給可能性イベントを発生させた端末２－２のプレイヤーに対して、当該供給可能性イベントのプレイ動画を記録してアップロードをするすることを勧める報知をする。即ち図２の例では画面１０３が端末２－２に表示される。
　次に、図４を参照して、供給可能性イベントを発生させた端末２－２と、サーバ１との間で実行される処理の関係について説明する。このような処理は、供給可能性イベントのプレイ動画の録画の推奨が行われるため、以下、「録画推奨処理」と呼ぶ。
　図４は、本実施形態に関わる録画推奨処理の流れを説明するフローチャートである。
　ステップＳ１において、端末２－２のゲーム実行部４１は、ゲームを実行する。
　ステップＳ２において、ログデータ生成部４２は、ゲームの進行に合わせてログデータを逐次生成し、ログデータ保持部４３に保持させる。
　ステップＳ３において、供給可能性イベント検出部４４は、供給可能性イベントが発生したか否かを判定する。
　供給可能性イベントが未だ発生していない場合、ステップＳ３においてＮＯであると判定されて、処理はステップＳ９に進む。
　ステップＳ９において、ゲーム実行部４１は、ゲーム実行が終了したか否かを判定する。
　ゲーム実行が終了した場合、ステップＳ９においてＹＥＳと判定され、録画推奨処理は終了する。
　これに対して、ゲームが続行されている場合、ステップＳ９においてＮＯであると判定され、処理はステップＳ２に戻される。
　即ち、ゲームが続行されている場合には、供給可能性イベントが発生するまでの間、ステップＳ２、ステップＳ３Ｎｏ、及びステップＳ９Ｎｏのループ処理が繰り返されて、ログデータが逐次生成され続ける。ただし、ログデータはサーバ１に送信されない。
　この間、ステップＳ１１において、サーバ１の供給可能性イベント取得部２２は、供給可能性ログデータを受信したか否かを判定する。
　供給可能性ログデータが未受信の場合、ステップＳ１１においてＮＯであると判定されて、処理はステップＳ１７に進む。
　ステップＳ１７において、サーバ１は、処理の終了が指示されたか否かを判定する。
　処理の終了の指示は、特に限定されず、例えばサーバ１の電源遮断等を採用することができる。
　処理の終了の指示がなされた場合、ステップＳ１７においてＹＥＳと判定され、録画推奨処理は終了する。
　これに対して、処理の終了の指示がなされていない場合、ステップＳ１７においてＮＯであると判定され、処理はステップＳ１１に戻される。
　即ち、処理の終了の指示がなされていなければ、供給可能性イベントが受信されるまでの間、ステップＳ１１Ｎｏ、及びステップＳ１７Ｎｏのループ処理が繰り返されて、サーバ１は待機状態になる。
　端末２－２において実行されているゲーム中に供給可能性イベントが発生すると、ステップＳ３においてＹＥＳであると判定されて、処理はステップＳ４へ進む。
　ステップＳ４において、端末２－２のログデータ送信制御部４５は、ログデータ保持部４３に保持されているログデータを、当該供給可能性イベントのログデータとしてサーバ１に送信する。
　この場合、サーバ１側では、ステップＳ１１においてＹＥＳであると判定されて、処理はステップＳ１２に進む。
　ステップＳ１２において、サーバ１の需要度合演算部１３は、プレイ動画需要度合を演算する。
　本実施形態では、上述のステップＳＣ乃至ＳＥの処理が実行されて、式（６）に示す需要スコアｄｅｍａｎｄＳｃｏｒｅ（Ｖ，Ｅ）が、プレイ動画需要度合として演算される。
　ステップＳ１３において、プレイ動画記録推薦報知部１４は、プレイ動画需要度合が所定要件を満たすか否かを判定する。
　ここで、所定要件は、特に限定されないが、本実施形態ではプレイ動画需要度合として需要スコアが採用されていることから、需要スコアが所定の閾値を超えていることという要件が採用されているものとする。
　従って、需要スコアが所定の閾値を超えない場合、ステップＳ１３においてＮＯであると判定されて、処理はステップＳ１７に進む。即ち、処理の終了が指示されていない場合、次の供給可能性ログデータが受信されるまでの間、サーバ１は待機状態になる。
　これに対して、需要スコアが所定の閾値を超える場合、ステップＳ１３においてＹＥＳであると判定されて、処理はステップＳ１４に進む。
　ステップＳ１４において、サーバ１のプレイ動画記録推薦報知部１４は、供給可能性イベントを発生させた端末２－２に対して、供給可能性イベントのプレイ動画の記録を促す報知を行う。
　即ち、ステップＳ６において、端末２－２の報知内容提示部４６は、当該報知の内容をプレイヤーに提示する。
　なお、報知の提示手法は、特に限定されないが、本実施形態では、図２の画面１０３を端末２－２に表示させる手法が採用されている。
　ステップＳ７において、端末２－２のプレイ動画生成部４７は、録画の指示があったか否かを判定する。
　本実施形態では、録画の指示は、図２の画面１０３の「はい」のボタンの押下操作により行われる。
　従って、図２の画面１０３の「はい」のボタンの押下操作がなされていない場合、ステップＳ７においてＮＯであると判定されて、処理はステップＳ９に進む。即ち、この場合、プレイ動画の録画は推奨されたものの、プレイヤーに受け入れられず、供給可能性イベントのプレイ動画は録画されない。この場合、さらにゲームが進んでログデータが逐次生成され、新たな供給可能性イベントが発生すると、上述のステップＳ４以降の処理が実行されることになる。
　これに対して、図２の画面１０３の「はい」のボタンの押下操作がなされると、ステップＳ７においＹＥＳであると判定されて、処理はステップＳ８に進む。
　ステップＳ８において、プレイ動画生成部４７は、供給可能性イベントのプレイ動画を録画して、サーバ１にアップロードする。
　この間、ステップＳ１６において、サーバ１のプレイ動画管理部１６は、プレイ動画がアップロードされたか否かを判定する。
　判定手法は、特に限定されないが、例えば本実施形態では、所定時間経過内にアップされない場合、アップロードされなかったと判定する手法が採用されている。
　アップロードされなかったと判定された場合、即ちステップＳ１５においてＮＯであると判定されて、処理はステップＳ１７に進む。即ち、サーバ１は待機状態になる。
　これに対して、アップロードされた場合にはステップＳ１５においてＹＥＳであると判定されて、処理はステップＳ１６に進む。
　ステップＳ１６において、プレイ動画管理部１６は、アップロードされた、供給可能性イベントのプレイ動画をプレイ動画記憶部１５に記録する。
　なお、プレイ動画記憶部１５に記録された当該プレイ動画は、今後発生し得る他の供給可能性イベントにとって、既存プレイ動画となる。このため、プレイ動画管理部１６は、ステップＳ１１（ＹＥＳ）の処理で受信された供給可能性イベントのログデータを、ログデータとして、プレイ動画に対応付けて管理する。
　このようなステップＳ１６の処理が終了すると、処理はステップＳ１７に進む。即ち、サーバ１は待機状態になる。
　以上説明した本実施形態の情報処理システムは、多様なイベントの正負の種類（敵を倒す／倒せない、ステージをクリアする／クリアできない、難易度の高い必殺技で敵を倒す／必殺技が出せない、など）に応じて、プレイ動画の需要の集計と、プレイ動画の作成を推薦することが可能であるため、様々なジャンルのゲームに適用することができる。
　本実施形態の情報処理システムは、潜在的に需要が高いシーンや状況を自動的に検出し、当該シーンで成功的なプレイをしたプレイヤーへ、プレイ動画を作成することを強く動機づけることが出来るため、動画の作成者には、動画が多数のユーザに見られる機会を提供するとともに、ゲームのプレイヤーには、ゲームの新たなプレイの仕方を伝達できる。
　詳細には、本実施形態の情報処理システムは、他プレイヤーからの需要が高いと推定されるシーンや状況において、プレイ動画を撮影することを、プレイヤーに推薦する、プレイ動画撮影タイミング推薦方式を適用している。
　従って、本実施形態の情報処理システムは、例えば、初心者がある特定のステージで行き詰っている状況や、特定のボスが倒せない状況（負として処理される第１イベント、即ち需要喚起イベント）を、プレイ動画の需要として集計していく。
　次に、あるプレイヤーが、当該の状況を解決するプレイをしたときに（正として処理される第２イベント、即ち供給可能性イベント）、そのプレイ内容が、プレイ動画として需要の高いものであることを示し、プレイ動画として保存してアップロード（共有）することを推薦する。
　これにより、自動的に、プレイ動画の需要と供給のマッチングを行うとともに、潜在的に需要が高いシーンや状況において、プレイ動画を作成することを強く動機づけることが出来る。
　つまり、プレイヤーがゲーム内で実行したイベントの種類に応じて、プレイ動画が公開されたときの需要をリアルタイムに計算し、需要の高いシーンのみをピンポイントで撮影することを推薦することができる。
　より具体的に言えば、端末２－１，２－２等ゲームを実行する端末は、ゲーム専用端末の場合もあるが、スマートフォン等、ゲーム専用ではない端末である場合も多い。このようなゲーム専用ではない端末でゲームをするユーザ（プレイヤー）の多くは、いわゆるカジュアルユーザである。
　このようなカジュアルユーザにとって、他ユーザにとって望まれるプレイ動画、即ち他ユーザからの需要があるプレイ動画がどのようなものであるかは、自明ではない。
　このため、従来、カジュアルユーザにとって、他ユーザの需要を満たす動画像をピンポイントで作成することは容易ではなかった。また、カジュアルユーザにとって、他ユーザから評価されないかもしれないという不安が、プレイ動画を作成して公開することを阻害する、高い心理的ハードルとなっていた。
　ここで、ＹｏｕＴｕｂｅ（登録商標）等の動画サイト上では、人気のある動画像ほどランキングの上位に位置する傾向が強く、カジュアルユーザによる動画投稿が、他のカジュアルユーザに閲覧される可能性は低い。また、既存の人気動画や公式動画は、高度に編集されており、カジュアルユーザが気軽に作成できるものではない。したがって、既存技術は、動画像をアップロードすべき適切なタイミング、および、適切な内容を、カジュアルユーザに提示するメカニズムを持たないため、一般利用者にプレイ動画作成を継続的に動機づけることは難しい。
　従って、このようなカジュアルユーザに対して、プレイ動画の作成の契機づけを与えないことには、プレイ動画作成のツールキットが組み込まれたゲームも普及しない。
　特に、ゲームのプレイ時間をずっと撮影したものではなく、面白いプレイ、美しいプレイ、ボスを鮮やかに倒すプレイ等の、ピンポイントのプレイ動画の作成の契機づけを与えることが、プレイ動画作成のツールキットが組み込まれたゲームの普及に貢献すると思われる。
　即ち、多様なプレイヤーからの多様なプレイ動画の需要と、カジュアルユーザが作成するプレイ動画の内容との、マッチング・メカニズムの実現が重要である。このようなマッチング・メカニズムが、本実施形態の情報処理システムにより実現されたことになる。
　即ち、本実施形態の情報処理ステムを適用することで、プレイヤーに「今のプレイ」の需要が高いことを伝え、動画のアップロードを動機づけることが可能になる。これにより、プレイ動画への潜在的な需要を迅速に充足させる、プレイ動画の共有と視聴のサイクルを確立することが容易に実現可能になる。その結果、プレイ動画作成機能を有するゲームの普及に貢献すると思われる。
　さらに、本実施形態の情報処理システムは、次のような利点も有している。
　例えば、潜在的なプレイ動画作成者を発掘できるという利点がある。即ち、プレイ動画を撮影するつもりはなかったプレイヤーにも、実際には、自分のプレイ内容を見ることで、他の人が助かることを伝えることにより、新たな動画作成者として発掘することが出来る。プレイ動画により、ゲームへのコミットメントを強化することになるため、プレイヤーはゲームを継続する可能性が高くなる。
　また例えば、互換性の点でも利点がある。即ち、プレイ動画作成の推薦機能は、任意のゲーム動画を録画すＳＤＫ（Ｓｏｆｔｗａｒｅ　Ｄｅｖｅｌｏｐｍｅｎｔ　Ｋｉｔ）とともに実装することができる。即ち、特定のプレイ動画録画方法に依存することなく情報処理システムの構築が可能になる。
　また例えば、独自性の点でも利点がある。即ち、ゲーム内容と連動したプレイ動画作成の推薦は、独自性が高い。
　また例えば、汎用性の点でも利点がある。本実施形態の情報処理システムは、途中中断することが可能な、任意のゲームタイトルに適用することができる。また、上述のプレイ動画録画の推薦は、特定のゲームのジャンルに依存しておらず、アクション、ＲＰＧ、シューティング、シミュレーションなど、幅広いゲームのジャンルに適用することが可能である。
　以上本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。
　上述の実施形態では、イベントのログデータを多次元ベクトル空間上のベクトルとして示したが、特にこれに限定されず、即ちログデータを必ずしもそのように表す必要はなく、例えば、ヒストグラムや、ツリー構造上のノード、ネットワークグラフ中のノードなど、多様な手法が選択可能である。
　ヒストグラムとして表現した場合、２つのヒストグラム間の類似性は、ヒストグラム・インターセクションと呼ばれる距離尺度や、Ｅａｒｔｈ　Ｍｏｖｅｒ’ｓ　Ｄｉｓｔａｎｃｅと呼ばれる距離尺度を用いて計量することが可能である。ツリー構造やネットワークグラフ構造中の２つのノードは、ノード間の距離を、ホップ数として計量することができる。本発明では、２つの分布データの間に、有意な距離尺度を与えることができる、任意のデータ構造を用いることが可能である。
　また、例えばプレイ動画の記憶場所は、上述の実施形態ではサーバ１のプレイ動画記憶部１５とされたが、特にこれに限定されず、サーバ１とは別の場所（例えばＹｏｕＴｕｂｅ（登録商標）における動画ストレージ）としてもよい。
　即ち、プレイ動画は、必ずしもサーバ１にアップロードする必要はなく、別の場所にアップロードしてその所在データ（例えばＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ））でサーバ１は管理してもよい。
　つまり、端末２－２からプレイ動画をアップロードする際、サーバ１にアップロードするのではなく、ＹｏｕＴｕｂｅ（登録商標）等にアップロードしてＵＲＬを取得し、当該ＵＲＬのみをサーバ１に送信するようにしてもよい。
　換言すると、本発明が適用される情報処理システムは、上述の図１の実施形態としての情報処理システムを含め、次のような構成を有する各種各様の実施形態を取ることができる。
　即ち、本発明が適用される情報処理システムは、
　ゲームを実行し得る複数の端末と、サーバとを含む情報処理システムである。
　前記サーバ（例えば図１のサーバ１）は、
　　前記複数の端末のうち、前記ゲーム内で負として処理された第１イベント（例えば上述の需要喚起イベント）を発生させた端末（例えば図１の端末２－１）から当該第１イベントのログデータを取得し、前記ゲーム内で正として処理された第２イベント（例えば上述の供給可能性イベント）を発生させた端末（例えば図１の端末２－２）から当該第２イベントのログデータを取得するイベント取得手段（例えば図１のイベント取得部１１）と、
　取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合（例えば上述の式（６）で示す需要スコア）を演算する度合演算手段（例えば図１の需要度合演算部１３）と、
　当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、当該第２イベントに関する動画像の記録を促す報知を行う報知手段（例えば図１のプレイ動画記録推薦報知部１４）と、
　を備える。
　前記複数の端末の少なくとも一部（例えば図１の端末２－１，２－２）は、
　　前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出手段（例えば図１の需要喚起イベント検出部３４，供給可能性イベント検出部４４）と、
　　前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供手段（例えば図１のログデータ送信制御部３５，ログデータ送信制御部４５）と、
　　前記サーバからの前記報知の内容を提示する提示手段（例えば報知内容提示部４６）と、
　を備える。
　これにより、ゲーム実行中のプレイヤーに対して、プレイ内容を録画したプレイ動画に閲覧需要があることを報知し、当該プレイ動画データをアップロードすべき動機付けを与えることができる。
　上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
　換言すると、図１の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図１の例に限定されない。また、機能ブロックの存在場所も、図１に特に限定されず、任意でよい。例えば、サーバ１の機能ブロックを端末２－２等に移譲させてもよいし、逆に端末２－２の機能ブロックをサーバ１等に移譲させてもよい。
　また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。
　一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
　コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。
　このようなプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。
　なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
　また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。
　１・・・サーバ、２－１，２－２・・・端末、１１・・・イベント取得部、１２・・・需要ログ記憶部、１３・・・需要度合演算部、１４・・・プレイ動画記録推薦報知部、１５・・・プレイ動画記憶部、１６・・・プレイ動画管理部、２１・・・需要喚起イベント取得部、２２・・・供給可能性イベント取得部、３１・・・ゲーム実行部、３２・・・ログデータ生成部、３３・・・ログデータ保持部、３４・・・需要喚起イベント検出部、３５・・・ログデータ送信制御部、４１・・・ゲーム実行部、４２・・・ログデータ生成部、４３・・・ログデータ保持部、４４・・・供給可能性イベント検出部、４５・・・ログデータ送信制御部、４６・・・報知内容提示部、４７・・・プレイ動画生成部

Claims (10)

  1. 　ゲームを実行し得る複数の端末と、サーバとを含む情報処理システムにおいて、
    　前記サーバは、
    　　前記複数の端末のうち、前記ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、前記ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得手段と、
    　取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算する度合演算手段と、
    　当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、当該第２イベントに関する動画像の記録を促す報知を行う報知手段と、
    　を備え、
    　前記複数の端末の少なくとも一部は、
    　　前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出手段と、
    　　前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供手段と、
    　　前記サーバからの前記報知の内容を提示する提示手段と、
    　を備える、
    　情報処理システム。
  2. 　ゲームを実行し得る複数の端末と通信をするサーバにおいて、
    　前記複数の端末のうち、前記ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得手段と、
    　取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する動画像の潜在需要の度合を演算する度合演算手段と、
    　前記度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する動画像の記録を促す報知を行う報知手段と、
    　を備えるサーバ。
  3. 　前記ログデータは、前記ゲームの実行時に得られる属性情報を１種類以上含み、
    　前記度合演算手段は、
    　　前記第２イベントの前記ログデータと、１以上の前記第１イベントの前記ログデータの夫々との相関量を算出し、
    　　前記相関量が所定基準を満たす前記ログデータを有する前記第１イベントを、前記第２イベントと関連するものとして選択する、
    　請求項２に記載のサーバ。
  4. 　前記ログデータは、前記ゲームの進行状況を示すログデータと、前記ゲームのプレイヤーの状態を示すログデータとを含む
    　請求項３に記載のサーバ。
  5. 　前記ログデータは、多次元ベクトル空間上のベクトルで表され、
    　前記度合演算手段は、前記第２イベントの前記ログデータを表すベクトルと、１以上の前記第１イベントの前記ログデータを表すベクトルの夫々との前記多次元ベクトル空間上の距離を、前記相関量として算出する
    　請求項３又は４に記載のサーバ。
  6. 　前記度合演算手段は、
    　前記第２イベントと関連する前記第１イベントの選択数が多いほど、当該第２イベントに関する動画像の潜在需要の前記度合を高める、
    　請求項２乃至５のうち何れか１項に記載のサーバ。
  7. 　過去に実行された前記ゲームの所定イベントに関する動画像又は当該動画像の所在データを管理する管理手段をさらに備え、
    　前記度合演算手段は、
    　　前記管理手段により管理されている前記動画像又は前記所在データにより特定される動画像のうち、前記第２イベントに関連する動画像へのアクセス数を求め、
    　　当該アクセス数が多いほど、当該第２イベントに関する動画像の潜在需要の前記度合を低下させる、
    　請求項２乃至６のうち何れか１項に記載のサーバ。
  8. 　ゲームを実行し得る複数の端末との通信を含む制御を実行するコンピュータに、
    　前記複数の端末のうち、前記ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得ステップと、
    　取得された夫々の前記ログデータに基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算する度合演算ステップと、
    　前記度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する動画像の記録を促す報知を行う報知ステップと、
    　を含む制御処理を実行させるプログラム。
  9. 　ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得機能と、
    　取得された前記ログデータの夫々に基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算し、当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する動画像の記録を促す報知を行う報知機能と、
    　を備えるサーバとの間で通信する端末を制御するコンピュータに、
    　前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出ステップと、
    　前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供ステップと、
    　前記サーバからの前記報知の内容を提示する提示ステップと、
    　を含む制御処理を実行させるプログラム。
  10. 　ゲーム内で負として処理された第１イベントを発生させた端末から当該第１イベントのログデータを取得し、当該ゲーム内で正として処理された第２イベントを発生させた端末から当該第２イベントのログデータを取得するイベント取得機能と、
    　取得された前記ログデータの夫々に基づいて１以上の前記第１イベントの中から前記第２イベントと関連するものを選択し、その選択結果に基づいて当該第２イベントに関する画像の潜在需要の度合を演算し、当該度合が所定の条件を満たす前記第２イベントを発生させた端末に対して、前記第２イベントに関する動画像の記録を促す報知を行う報知機能と、
    　を備えるサーバとの間で通信する情報処理装置が実行する情報処理方法であって、
    　前記ゲームの実行中において前記第１イベント及び前記第２イベントを検出するイベント検出ステップと、
    　前記第１イベント及び前記第２イベントの各ログデータを前記サーバに提供するログ提供ステップと、
    　前記サーバからの前記報知の内容を提示する提示ステップと、
    　を含む情報処理方法。
PCT/JP2015/080692 2014-12-19 2015-10-30 情報処理システム、サーバ、プログラム、及び情報処理方法 WO2016098465A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201580076133.XA CN107249707B (zh) 2014-12-19 2015-10-30 信息处理系统、服务器、程序和信息处理方法
KR1020177019878A KR101944455B1 (ko) 2014-12-19 2015-10-30 정보 처리 시스템, 서버, 프로그램, 및 정보 처리 방법
US15/627,023 US10293254B2 (en) 2014-12-19 2017-06-19 Information processing system, server, program, and information processing method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014-256988 2014-12-19
JP2014256988A JP5739578B1 (ja) 2014-12-19 2014-12-19 情報処理システム、サーバ、プログラム、及び情報処理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/627,023 Continuation US10293254B2 (en) 2014-12-19 2017-06-19 Information processing system, server, program, and information processing method

Publications (1)

Publication Number Publication Date
WO2016098465A1 true WO2016098465A1 (ja) 2016-06-23

Family

ID=53534127

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/080692 WO2016098465A1 (ja) 2014-12-19 2015-10-30 情報処理システム、サーバ、プログラム、及び情報処理方法

Country Status (5)

Country Link
US (1) US10293254B2 (ja)
JP (1) JP5739578B1 (ja)
KR (1) KR101944455B1 (ja)
CN (1) CN107249707B (ja)
WO (1) WO2016098465A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102502982B1 (ko) 2016-03-03 2023-02-22 엘에스일렉트릭(주) 데이터 기록 장치
JP2017202214A (ja) * 2016-05-13 2017-11-16 株式会社ミクシィ ゲームサイトに個別にログインした複数の遊技者が同じゲームをマルチプレイする状況下で各遊技者ごとに記録された複数のゲーム動画を１つの画面に収めたマルチプレイ動画作品に編成して公開すること
CN108810437A (zh) * 2018-05-28 2018-11-13 努比亚技术有限公司 录屏方法、终端及计算机可读存储介质
JP6538942B1 (ja) * 2018-07-26 2019-07-03 株式会社Ｃｙｇａｍｅｓ 情報処理プログラム、サーバ、情報処理システム、及び情報処理装置
JP6947985B2 (ja) * 2018-12-17 2021-10-13 株式会社カプコン ゲーム動画編集プログラムならびにゲーム動画編集システム
CN111031177A (zh) * 2019-12-09 2020-04-17 上海传英信息技术有限公司 屏幕录制方法、设备及可读存储介质
US11213759B1 (en) 2020-07-22 2022-01-04 Rovi Guides, Inc. Gaming content storage based on gaming performance
CN115237314B (zh) * 2022-04-18 2023-09-08 网易（杭州）网络有限公司 信息推荐方法、装置和电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001224860A (ja) * 2000-02-16 2001-08-21 Namco Ltd ゲーム情報配信システムおよび情報記憶媒体
JP2010239990A (ja) * 2009-03-31 2010-10-28 Copcom Co Ltd ゲームシステム、ゲーム装置、ゲームサーバ
JP2011512172A (ja) * 2008-01-25 2011-04-21 ソニー オンライン エンタテインメント エルエルシー ビデオゲームイベントに関するビデオコンテンツを作成、編集、及び共有するためのシステム及び方法
JP5521104B1 (ja) * 2013-10-22 2014-06-11 株式会社 ディー・エヌ・エー 電子ゲーム提供装置、電子ゲーム装置、電子ゲーム提供プログラム及び電子ゲームプログラム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001137545A (ja) * 1999-11-17 2001-05-22 Square Co Ltd 記録媒体、データアクセス方法、ゲーム進行制御方法およびゲーム装置
JP4030249B2 (ja) * 2000-05-19 2008-01-09 株式会社コナミデジタルエンタテインメント アクションゲームプログラムを記録したコンピュータ読み取り可能な記録媒体、ならびに、アクションゲーム装置およびその制御方法
US6699127B1 (en) * 2000-06-20 2004-03-02 Nintendo Of America Inc. Real-time replay system for video game
JP5184036B2 (ja) * 2007-10-05 2013-04-17 任天堂株式会社 ゲームプログラムおよびゲーム装置
US8515253B2 (en) * 2008-02-15 2013-08-20 Sony Computer Entertainment America Llc System and method for automated creation of video game highlights
WO2014055108A1 (en) 2012-10-03 2014-04-10 Google Inc. Cloud-based gameplay video rendering and encoding
CN103902808B (zh) * 2012-12-27 2017-04-26 索尼互动娱乐美国有限责任公司 用于生成和共享云供应游戏的视频剪辑的系统和方法
US9233305B2 (en) 2013-02-13 2016-01-12 Unity Technologies Finland Oy System and method for managing game-playing experiences

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001224860A (ja) * 2000-02-16 2001-08-21 Namco Ltd ゲーム情報配信システムおよび情報記憶媒体
JP2011512172A (ja) * 2008-01-25 2011-04-21 ソニー オンライン エンタテインメント エルエルシー ビデオゲームイベントに関するビデオコンテンツを作成、編集、及び共有するためのシステム及び方法
JP2010239990A (ja) * 2009-03-31 2010-10-28 Copcom Co Ltd ゲームシステム、ゲーム装置、ゲームサーバ
JP5521104B1 (ja) * 2013-10-22 2014-06-11 株式会社 ディー・エヌ・エー 電子ゲーム提供装置、電子ゲーム装置、電子ゲーム提供プログラム及び電子ゲームプログラム

Also Published As

Publication number Publication date
CN107249707B (zh) 2020-09-08
JP5739578B1 (ja) 2015-06-24
CN107249707A (zh) 2017-10-13
US20170282072A1 (en) 2017-10-05
US10293254B2 (en) 2019-05-21
KR20170097718A (ko) 2017-08-28
KR101944455B1 (ko) 2019-04-17
JP2016116591A (ja) 2016-06-30

Similar Documents

Publication Publication Date Title
JP5739578B1 (ja) 情報処理システム、サーバ、プログラム、及び情報処理方法
JP7461174B2 (ja) 共有インターフェースを介してアクセスされるミニゲーム
CN108295468B (zh) 游戏的信息处理方法、设备和存储介质
JP6005716B2 (ja) 情報処理システム、サーバ、プログラム、及び情報処理方法
JP6017223B2 (ja) ゲームシステム、ゲーム装置、及びプログラム
KR102060000B1 (ko) 정보 처리 시스템, 정보 처리 방법 및 프로그램, 서버, 및 정보 처리 단말
JP5512602B2 (ja) 評価情報収集システム
US20130288799A1 (en) Systems and methods that enable a spectator's experience for online active games
CN115671746A (zh) 游戏风格分类
JP6177967B2 (ja) 評価情報収集システム
US10220316B2 (en) Information processing device, information processing method, program, information storing medium, information processing system, and management device
JP5572250B2 (ja) 評価情報収集システム
CN115885325A (zh) 实时的感兴趣行为通知系统
JP5956512B2 (ja) 評価情報収集システム
US10918951B1 (en) Systems and methods to provide a game based on common media consumption
US20240029437A1 (en) Generating customized summaries of virtual actions and events
JP6389929B2 (ja) 評価情報収集システム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15869673

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20177019878

Country of ref document: KR

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 15869673

Country of ref document: EP

Kind code of ref document: A1