KR20080056257A - Method and apparatus for monitoring user game-playing behavior and reporting game play data in a gaming environment - Google Patents

Abstract

A computer implemented method, a data processing system, and computer program product are provided for monitoring user game-playing behavior and reporting game play data (314) in a gaming environment. A software agent (301) is provided for monitoring gaming characteristics of the user (300) responsive to a launch of a game by a user (300). The software agent (301) also identifies a game state (718) based on the gaming characteristics. The software agent (301) collects game play data (314) of the user (300) if the game state (718) is changed (408), and reports the game play data (314) for processing.

Description

METHOD AND APPARATUS FOR MONITORING USER GAME-PLAYING BEHAVIOR AND REPORTING GAME PLAY DATA IN A GAMING ENVIRONMENT}

The present invention relates to monitoring gameplay behavior and reporting gameplay data in game environments, specifically gameplay in game environments, and more specifically in game environments.

With the development of the Internet, gamers around the world have been able to play online in both directions, regardless of location or time. In online collaborative games, gamers can share information about the game as well as other interests in the game, such as usability or desired features. For game companies that produce games, their interests are useful sources of information about marketing, game development, and game production. Gamers' interest is also a statistic that helps game companies to identify sales trends. Examples of such statistics are sales charts based on geography, prices, and price-to-sales ratios.

Co-game software such as GamerMetrics analyzes the interests of gamers for game companies. GamerMetrics is a product of ING Entertainment Inc. that handles gamers' activities through the game buying cycle and collects the factors that they decide to buy the game. However, after purchasing the game, no analysis is done because it only monitors gamer activity up to the point of sale. Although there is online co-game software that provides data after sale, the data is quite biased because the game is on sale or charged when playing. In addition, current co-game software does not confirm actual game activity. For example, a user who has to pay a monthly subscription fee is the placenta, even if he logs in to the game server for two days, the activity time is only two hours.

Pre-sale data is important for game companies to determine the kind of games to be produced, but post-sale data is equally important for further monitoring the sales trend. After-sales data can be used to analyze the behavior of the gamer and what the gamer does after buying the game. The after-sale data tells you how many hours of games you play, how long you spend playing games (days, weeks, months, etc.), who plays games, where you play, and so on.

Post-sale data also helps to analyze the popularity and longevity of the game. Whether this post-sales information will develop sequels, work with other competitors on the market, what kind of audience to focus on, develop more game titles, generate detailed demographics for future game development, This will help determine when to develop, budget and marketing constraints for future game development. No solution currently provides this post-sale data, and no solution monitors gameplay data while gamers are offline. Solutions like GamerMetrics analyze only while playing online games. There is also no solution that provides non-biased single-player gameplay data, since all solutions provide gameplay data while two or more gamers play the game.

Also, subscriptions to services like IGN's GamerMetrics and Gamespy are limited because the service is paid. Gamers can subscribe to the service whether in a single player or multiplayer environment. The problem is that the data collected from gamers' activities still comes from network servers operated by IGN.

It is a feature of the present invention to provide a computer implemented method, a data processing apparatus and a computer program medium for monitoring user gameplay behavior and reporting gameplay data in a gaming environment. The game characteristics of the user who starts the game are monitored and the game status is confirmed based on these game characteristics. If there is a change in the game state, the gameplay data of the user is collected and this data is processed.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

1 is a network of data processing apparatus showing features of the present invention;

2 is a block diagram of a data processing apparatus according to the present invention;

3 is a block diagram showing the connection between components of the present invention;

4 is a flowchart of a process of collecting game play data and accumulating credits according to the present invention;

5 is a flow chart of a process of processing user gameplay data in accordance with the present invention;

6 is a flow chart of managing user account credit consumption;

7 is a block diagram of an execution process of a gamer, a software agent, a database server, a web server, and a chat server;

8A-B are block diagrams illustrating the activities of gamers, software agents, servers, and chat servers;

9 is a flowchart for determining a game state;

10A-C are block diagrams illustrating activities and data related to viewing, storing, and transmitting user gameplay data.

11A-B are block diagrams of classes used to implement the present invention;

12A-B are flowcharts illustrating a chat function of the present invention;

13A is a flow chart of collecting gameplay data of a user from the perspective of a server in accordance with the present invention;

FIG. 13B is a flow chart of collecting user gameplay data from the software agent 301 perspective of FIG. 3.

1 to 2 are block diagrams of a data processing environment for implementing an example of the present invention, and are merely examples.

1 shows a network of data processing apparatus showing features of the present invention. The network data processing apparatus 100 is a computer network embodying an example of the present invention. The network 102 included therein is a medium for providing a communication link between various devices connected to a system and a computer. The network 102 includes both wired and wireless communication links or optical fiber cables.

Servers 104 and 106 are connected to network 102 together with storage 108 and clients 110, 112 and 114 are also connected to the network. Clients 110, 112, and 114 include PCs or network computers. The server 104 provides data to the clients 110, 112, and 114 such as a boot file, a computing system image, and an application. Clients 110, 112, and 114 are here clients of server 104, and server 104 is a gamer server that attracts games played by users on the clients. Of course, other servers, clients, devices may be further included in the network data processing apparatus 100.

The processing system 100 of the present embodiment uses Transmission Control Protocol / Internet Protocol (TCP / IP) as the Internet having a worldwide network 102. At the heart of the Internet is a high-speed communications line between major nodes or host computers, which are comprised of thousands of computer systems for commercial, government, and educational purposes that route data and messages. Of course, this processing system 100 may be configured with various types of networks, such as the Internet, LAN, WAN, and the like. The example of FIG. 1 is merely an example and does not limit the present invention.

FIG. 2 is a block diagram of a data processing apparatus 200, which is a computer, such as a server 104 or a client 110 of FIG. 1, and computer usable code for realizing the process for implementing the present invention. I have commands loaded.

This data processing device 200 employs a hub architecture that includes a north bridge and memory controller hub (NB / MCH) 202 and a south bridge and input / output controller hub (SB / ICH) 204. The processing unit 206, main memory 208, and graphics processor 210 are connected to the NB / MCH 202, but the graphics processor 210 is connected to the NB / MCH 202 via an accelerated graphics port (AGP). Sometimes.

The LAN adapter 212 is connected to the SB / ICH 204 and includes an audio adapter 216, a keyboard / mouse adapter 220, a modem 222, a ROM 224, an HDD 226, a CD-ROM drive ( 230, USB and other communication ports 240, PCI / PCIe devices 234 are connected to the SB / ICH 204 via buses 238, 240. PCI / PCIe devices include Ethernet adapters, add-in cards (AICs) or PC cards for notebook computers. PCI uses a cardbus controller, but PCIe does not. The ROM 224 may include a flash binary input / output system (BIOS).

The HDD 226 and the CD-ROM drive 230 are connected to the SB / ICH 204 via the bus 240. The HDD 226 and the CD-ROM drive 230 may use, for example, integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interfaces. Super I / O (SIO) device 236 may also be coupled to SB / ICH 204.

The operating system running on the processing unit 206 regulates various elements in the system. The operating system can use commercially available MS Windows XP. When an object-oriented system such as a Java programming system is used together with an operating system, the operating system can be called from a Java program or application executed in the data processing apparatus 200. Java is a trademark of Sun Microsystems, Inc.

The data processing apparatus 200 may be an IBM eServer pSeries computer system as a server, which adopts an AIX (Advanced Interactive Executive) operating system or a LINUX operating system. eServer, pSeries, and AIX are all trademarks of International Business Machines Inc. in the United States and LINUX is a trademark of Linus Torvalds Inc. in the United States. The data processing apparatus 200 is generally a symmetric multiprocessor (SMP) system in which a plurality of processors are included in the processing apparatus 206, but a single processor system may be adopted.

Instructions for the operating system and the object-oriented programming system and the application or program may be stored in the storage unit HDD 226 and then waited for execution in the main memory 208 by the processing unit 206. The process of the present invention is executed in the processing device 206 using computer program code, which may be stored in a memory, such as main memory 208, ROM 224, or in peripherals 226, 230.

As will be appreciated by those skilled in the art, the hardware of FIGS. 1-2 may vary depending on the situation. Other hardware or peripherals, such as flash memory, nonvolatile memory, optical disk drives, may be used in place of or in combination with the hardware of FIGS. It is also possible to apply the process of the present invention to a multiprocessor data processing apparatus.

In some cases, the data processing apparatus 200 may be a personal digital assistant (PDA). In this case, a nonvolatile memory may be used to store an operating system file or user generated data.

In the case of FIG. 2, buses 238 and 240 may be used. Any type of communication device capable of transmitting data between components or devices may be used. Such a communication device includes a device used for data transmission and reception, such as the modem 222 or the network adapter 212 of FIG. The memory may use main memory 208, ROM 224, or cache as seen in NB / MCH 202 of FIG. 2. The present invention is not limited to the structure described above with reference to FIGS. For example, the data processing apparatus 200 may be a PDA-type tablet computer, laptop computer, or telephone.

It is a feature of the present invention to monitor gameplay behavior of a user and then report gameplay data. In order to generate gameplay data from a user, the present invention provides a software agent that can be downloaded and installed on a game system. The game system includes a computer system such as the data processing apparatus 200 of FIG. 2 or another game entertainment system that supports downloading or installing code. Game entertainment systems include Sony's PlayStation 2 and Microsoft's XBox. The software agent accurately monitors game features to determine whether the user actively plays the game and collects the user's gameplay data when the user's situation changes. Examples of game features monitored by software agents include mouse usage, joystick usage, keyboard usage, CPU utilization, user active windows and user memory usage, and user network connectivity.

Gameplay data is data that shows how a user plays a game. The user starts the software agent to collect gameplay data before starting the game. If the software agent determines that the user actively plays the game according to the game characteristics or determines that the game situation has changed, the user collects the user gameplay data and continuously monitors the gameplay behavior. On the other hand, the software agent may be automatically activated when the user starts the game. User gameplay data includes play time, date the game was played, game title, and other performance statistics. Unlike other general game software, the software agent of the present invention collects gameplay data both online and offline.

User gameplay data is collected while the software is running. Users can connect to the Internet to play games remotely or play games directly on a PC without an Internet connection. The software agent collects gameplay data remotely online or offline. User gameplay data can be used to create dynamic user interfaces for communication between users as well as dynamic services for interactive tips and hints. Examples of dynamic services include, but are not limited to, competition leagues, tournament games, and statistical competition games.

Any time after a software agent has collected your gameplay data online or offline, you can store and process this data while communicating with the server if you have a network connection. If the network is not always connected, it stores gameplay data and sends it when connected. In most cases, the network connection is the Internet. In this embodiment, the software agent and server communicate with each other via a communication security protocol, for example, a secure simple object access protocol (SOAP) -over-hypertext transfer protocol (HTTPS). SOAP is a protocol based on a written message between hosts, and HTTPS is a security means for transmitting data using a hypertext transfer protocol (HTTP). HTTPS is a 40-bit or 128-bit cipher. For example, it features a Web service on top of SOAP that aligns the composed message sent between the server and the client. The format of a compose message is defined using a dedicated Web Service Description Language (WSDL) file.

Software agents and servers provide each other with dynamic and static data. Static data includes agent skin files, game lists, game rules, and configuration files that make up other software agents. Dynamic data includes streaming statistics, chat buddy list, buddy status, local user status (active, rested or inactive), real-time performance statistics, and the like. Agent skin files are image files that are layered over the application window to control the look and feel of the window. If there is no network connection, the collected user gameplay data continues to be accumulated locally in the client gameplay data file until network connection is detected. In the case of a network connection, client gameplay data continues to be accumulated locally. However, client game data is actively sent to the server based on the threshold. For example, if the user is online and has accumulated 10 updates, these updates are sent to the server and the client gameplay datafile is reset. That is, it can be seen that the client game data includes game data stored in the local device or other game data sent to the server in real time.

The server receives the user gameplay data from the software agent and processes it, specifically updating the database. In the illustrated embodiment, the database includes all gameplay data collected for various users. Manage personal accounts of users based on updated data in the database. The user's personal account is credited to be used to buy goods or services in the virtual shopping mall.

The management of the user's personal account includes the deposit of credits into the user account and the management of the consumption of credits in the shopping mall. The user may spend credits on goods or services ordered from the virtual shopping mall. Credit deposits can be based on gameplay data, such as the total time spent in the game, or on incentives, such as points collected by the user. In addition to time and points, other types of incentives such as kill, level, mission completion, status, and win are also used to credit credit.

3 is a block diagram showing a connection between components of the present invention. The software agent 301 is implemented in the data processing apparatus 302 or the game console 310, and the data processing apparatus 302 is implemented as the data processing apparatus 20 of FIG. 2. Game console 310 is implemented as a game entertainment system, such as PlayStation 2 or XBox.

To generate gameplay data, the software agent 301 determines whether the user 300 is actively playing a game while monitoring game features. These game features include mouse use, joystick use, keyboard use, processor utilization, active windows, memory use, and network access. The software agent 301 periodically inquires about the physical state of the mouse 306 to know whether to use the mouse. Similarly, the use of a keyboard or joystick may be known by regularly inquiring about the physical state of the keyboard 308 and joystick 304. In addition, the software agent 301 may periodically inquire about the physical state of a hardware device such as the PDA 328 or the spatphone 332 to determine whether another input device is used.

Other game features, such as processor utilization, active window, memory usage, network connection, can be determined in the operating system of the data processing device 302 without user 300 interference. The software agent 301 may extract these game features by an interface provided by the operating system. Windows XP is a good operating system. When the software agent 301 is implemented in the game console, game controller usage information obtained when the user 300 inputs the game console 310 through the game controller 312 may also be included in the game feature.

Based on the game features, the software agent 301 determines whether the user is actively playing the game. In this embodiment, the software agent 301 continuously monitors the game state and collects data related to the change, for example, when the game state changes from rest to activity, from activity to stop, from stop to rest and so on. Collect client data. User gameplay data is data that reflects how the user 300 plays the game, such as the title of the game being played, the username, the duration of the play, other statistical performance data, and stored points. Performance statistics may include all relevant measurements of the game being played.

The gameplay data collected by the software agent 301 is unique in that it is entirely post-data sampled in a surveillance situation. Such user gameplay data is advantageous over data collected by other game software because it is available after the point of sale. Although this information can be obtained after sale, it is mostly biased and cannot be considered in gameplay. The user gameplay data collected by the software agent 301 not only reflects the current situation after the sale, but also helps the company predict future trends. Game console sales may differ from the number of game consoles in operation. Since the software agent 301 can determine the number of game machines currently operating, it can be useful post market research data for various investors including game planners, buyers, game publishers, developers, analysts, and the like.

The post data characterizing in the present invention demonstrates a characteristic of true post game activity that is not biased. Similar to determining the needs and behaviors of a dining customer, the data obtained from the restaurant or buffet is slightly biased and informant biased, so the data obtained from the restaurant is centered on the information provided by the restaurant. Similarly, in buffets the choice and amount of food to eat is largely overeating. A better way to collect data is to look at your individual's taste for a long time while eating. The data collected will not be biased or biased based on the type of food served at the restaurant or buffet.

In addition to the features of the collected gameplay data, the software agent 301 is superior to current game software in that it collects data both online and offline. Most current co-game software collects data while playing online games with other users over the Internet or local networks. User gameplay data collected between users online is biased or biased and does not reflect aggressive gameplay. Gameplay data collected between users playing games over local networks is not easily available for monitoring by external sources. In addition, current co-game software collects data only when two or more users play a game, and thus cannot collect data about individual games that occur offline.

The software agent 301 determines whether a network connection is possible from the data processing device 302 or the game console 310 while collecting game play data. If network connection is possible, the collected data collected in the client game data file 314 of the data processing device 302 or the game console 310 is collected through a server through the Internet 316 using a communication security protocol such as SOAP-over-HTTPS. In this case, the transmission is performed based on a threshold and a period set in advance, and may be sent every 10 minutes. If there is no network connection, the collected data continues to be collected in the data file 314 until network connection is detected. The data file 314 collects user gameplay data while the user 300 is playing a game offline or online.

The server 320 receives the collected data and processes the extracted data. The server 320 updates the database 322 like the existing data and sends the data to the database 322 through the Internet. Database 322 has a history of gameplay data collected from several users. Data updated by the server 320 in the database 322 may be used for other business functions.

For example, the dynamic statistics obtained from the updated data can be sent directly to the software agent 301 or to the web page of the game console 310 which is the data processing device 302. In this case, the user 300 may immediately receive feedback regarding the status of the personal account.

Another business function that can be implemented by the present invention is the management of a user's personal account. Personal account credits are used by users to purchase goods or services. According to the present invention, the user deposits credit in the account and manages the credit consumption in the virtual shopping mall 324.

The virtual shopping mall 324 includes various products or services that a user can purchase and may be implemented in the web server 321. The user 300 deals with the virtual shopping mall 324 through the data processing device 302, for example, may purchase home appliances, game software, food, gift certificates, movie tickets, and the like.

As described above, the user may write his or her credit on the goods or services ordered from the virtual shopping mall 324. You can collect credits in your account based on real-time gameplay data, such as the time a user spends in the game, or incentives, such as points accumulated by the user in the game. In addition, the software agent 301 may communicate with the chat server 326 via the Internet 316 to facilitate a chat function between the user 300 and another user.

4 is a flowchart of a process of collecting game play data and accumulating credits according to the present invention. This process is done in the software agent 301 of FIG. According to FIG. 4, the process starts when the user downloads the software agent and installs it on the data processing device or game console (step 402).

The user then starts a software agent prior to the game (step 404). The software agent monitors game features (step 406). The software agent determines whether the game state changes based on the game features (step 408). In detail, the method of determining by the software agent will be described with reference to FIGS. 9A to B. If the game state changes, the software agent collects game play data (step 410) and stores the collected data in a game data file of the client (step 412). How the software agent collects this data is described in detail in Figures 13A-B. If the game state does not change, the process returns to step 406 and continues to monitor the game features, and again determines whether the game state has changed in step 408.

The software agent collects gameplay data and stores it in a client game data file. If the threshold for updating the count or period is met (step 413), it is determined whether the user is currently online (step 414). This determination is based on whether a network connection is possible from the data processing apparatus 302 or the game console 310 of FIG. If the user is currently online, the software agent communicates with the server to store and process the collected data (step 416). If it is offline, the process returns to step 410 to continue collecting data and to store the collected data in step 412.

The accumulated data is stored in a client game data file in the user system, that is, the data processing device 302 or the game console 310. The software agent then requests an update of the user's personal account and receives confirmation of the credit from the server (step 418). The user is then notified of the account update (step 420). Step 420 is optional and the process ends.

5 is a flowchart of a process of processing user gameplay data according to the present invention, which is implemented in the server 320 of FIG. According to FIG. 5, the process begins after the software agent communicates with the server in step 416 of FIG. 4. The process begins with the server detecting the communication from the software agent (step 502). The server then updates the collected data to the database (step 504). The gameplay data history of several users is also stored in the database.

When the database is updated with the collected data, the server deposits credits into the user's personal account based on the data (step 506). You can deposit credits in your personal account based on real-time cumulative gameplay data, such as the total time you have invested in the game, or you can deposit based on incentives, such as points you have collected for the game. The user then requests an update of the personal account, and the server sends the account update to the software agent or website (step 508).

When the credit is deposited in the user's personal account, the user can check the balance or pay the price of goods or services in the virtual shopping mall. Another feature of the present invention is to manage the use of account credit in the virtual shopping mall. FIG. 6 is a flowchart of managing consumption of account credit by a user, which is performed by the web server 321 of FIG. 3. According to FIG. 6, the user starts by logging in to the virtual shopping mall (step 602). The web server then tracks the updated data in the database (step 604) and shows the account information to the user (step 606). This step displays an advertisement informing the user that there is credit to purchase the item. For example, a credit can be given to the user because the time the user spent in the game exceeded a threshold.

After displaying the account information, the web server detects the selection of goods or services that the user can purchase in the virtual shopping mall (step 608), and then pays the price of the selected goods or services (step 610). Thus, the process ends.

7 is a block diagram of an execution process of a gamer, a software agent, a database server, a web server, and a chat server. Gamer 700 starts a game using input device 702 including a joystick, keyboard, and mouse, but may also use other game machines, including game controllers.

When the agent 708 is activated, the gamer 700 starts the game (701). Agent 708 monitors the operation of the input device to determine if it is playing a game. This feature is known as user input, and the case for determining user input by the software agent is referred to as entropy confirmation 710. In addition to entropy checking 710, agent 708 also tracks other game characteristics to determine if the user is playing a game, specifically active processes 712, memory usage 714, CPU utilization 716, etc. to be. These characteristics are obtained from an interface provided by the operating system of the data processing device 302 or game console 310 of FIG.

In determining whether the user is active, at rest, or inactive, the agent 708 uses certain algorithms and artificial intelligence in a ruleset file. The ruleset file may be implemented as a general purpose plug-in that the agent 708 can easily interface with. Rulesets define thresholds for attributes or properties that software agents monitor. By this definition, game companies or resources can establish respective criteria for monitoring user behavior.

The ruleset may be defined as GameName, GameID #, threshold_0, threshold_1, ..., threshold_N. GameName is the name of the game being monitored, GameID # is the "tag" which is the random game code of the game being monitored, and threshold_0, threshold_1, ..., threshold_N are the point weights of attribute_0, attribute_1, ..., attribute_N respectively. )to be.

An example of the ruleset may be "h12.exe", 4, 40, 2, 6, 7, 10 ..., GameID # 4, Threshold 40 of attribute_0, Threshold 2 .. of attribute_1 "h12.exe" Is a game. Each attribute maps to a function that knows how to determine whether it is good or bad for a particular cycle. For example, in the window environment, the WindowZorder attribute is used to indicate that the program is in the window environment. The WindowZorder attribute is mapped to a feature called "calWindowZorderWin32" and returns "true" if the attribute's critical point score should be added to the total point score, and "false" if not. The total point score is the static point score that all games must earn in order for the user to be considered "active." If the "calWindowZorderWin32" function returns false, the user is considered "inactive". However, if no user input is detected at entropy confirmation 710, the user is considered to be "rest." The "inactive" state takes precedence over the "rest" state.

Based on the ruleset and entropy check 710, the agent 708 determines whether the user is active, rested, or inactive, then sets the game state 718 and updates the client game data (720). The above process is repeated until the collected game data reaches a threshold value. The agent sends an update when the client is online and continuously collects client game data when offline. Agent 708 resets the local client time data after sending the update (732) and web server 734 resets the client time data. The database server 728 sends the dynamic statistics data requested by the agent to the local client (730). Gamer 700 may also request a user credit update (736). In this case, the agent sends the current accumulated local client game data to the web server 734 and requests the gamer 700 to show the current account balance.

Gamer 700 can change agent configuration (722), for example, changing the functions or options that gamer 700 can do. The gamer 700 also updates the game list 724 to define the games that the agent can monitor. If the agent configuration changes (722) or the game list changes (724), the agent functionality is also updated (726), which affects the data sent to the database server 728. In addition, when the gamer 700 requests a chat (740), the agent 708 manages the chat function (738). The chat function includes a chat message process 742 by the chat server 744 and an external chat process 746 by communication with an external chat server through the chat gateway 748.

8A-B are block diagrams illustrating the activities of gamers, software agents, servers, and chat servers, reflecting the activities involved in executing the cases described in FIG. In FIG. 8A, gamer 800 first starts a software agent (804), and client / agent 802 verifies connection 806 whether gamer 800 has contacted server 808. Gamer 800 accessing server 808 logs in to the server (812). However, if the gamer failed to connect to the server, a prompt is displayed 814 asking if the gamer continues to log in. When the gamer 800 logs in, the client / agent 802 verifies the credentials of the gamer 800 (816), checking locally if offline and remotely if online.

The logged-in gamer 800 selects a start game (818). In response to this selection, the client / agent 802 starts Game.exe (820) to start the game and monitor game characteristics. This activity 818, 820 is related to the game start 701 of FIG. 7. When gamers 800 play a game 822, client / agent 802 tracks various processes, including CPU utilization, memory usage, etc. (824), and performs entropy checks on user inputs (826). This activity 824,826 is described in detail in FIG. Based on the tracked process and the identified entropy, the client / agent 802 determines whether the gamer 800 is active, inactive or at rest. Next, a game state reflecting whether the gamer 800 is active, inactive or at rest is set 828. If the game state is set, the client / agent 802 updates the client game data (830). These activities 824,826,828,830 are related to the cases 710, 712-716, 718, 720 of FIG. 7, respectively.

Gamer 800 manually operates client / agent 802 while online to request credit updates for the personal account (832). The client / agent 802 receiving this request sends a credit update to the server 808 (834), and the server updates the database to process the credit update (838). The server 808 that processed the credit update sends a credit update success message to the client / agent 802, and the client / agent locally displays the received credit update (836). These activities 832, 834, 836, 838 are related to the 736 activity of FIG. 7.

In FIG. 8B, when the gamers 800 are connected to the server 808, the game list is requested to be updated (840). The user executes the game list update through the web browser of the online profile. Once the game list is updated, server 808 updates the support game list stored on the server (846) and sends the updated game list to client / agent 802, which is stored locally in the update game list file. (844). This activity 840,844,846 is related to the processes 724, 726 of FIG.

After the gamer 800 requests the server 808 to synchronize the agent, the server 808 receives the tune request 850 and sends static data to the client / agent 802 to receive the static data 854. Static data includes rulesets, game lists, and other configuration files. In addition to the static data request, client / agent 802 may request 856 dynamic data from server 808. Dynamic data includes streaming statistics, chat buddy list, buddy status, local user status, and real-time performance statistics. The server 808 receiving the dynamic data request sends dynamic data to the client / agent 802 (858), and the client / agent receives the dynamic data (860). These activities 856-860 are related to the dynamic data sending 730 of FIG. 7.

In addition, client / agent 802 may facilitate chat activity. When gamer 800 logs in for chat (862), the client / agent requests a new password from server 808 (864). When the server 808 sends a new password to the client / agent 802 (866), it receives the new password from the client / agent (868) and sends it to the chat server 810 as if it had been typed in the client / agent 802. send. This password is referred to as the current chat password of the client / agent 802. Chat server 810 checks the new password (870) and notifies the client / agent (872) that the chat is ready. Next, the client / agent 802 manages various chat functions (874), and the chat server 810 proceeds to chat (876). These activities 862-876 relate to cases 738-742 of FIG. 7.

If you wish to change the configuration of the client / agent 802 (878), the gamer 800 may change the configuration options locally, such as an agent skin file at any time. The local configuration option 880 can change regardless of network connection status and does not require access to the user's online profile. Most configuration options of the client / agent 802 are accessed through the online profile of the gamer. When there is a change, server 808 processes the configuration update (882) and saves the configuration change (884). These activities 878-884 are related to agent configuration change 722 and agent process update 726 of FIG. 7.

9 is a flowchart for determining a game state, which is implemented in the software agent 301 of FIG. The software agent starts the process taking a snapshot of the operating system of the user system (step 900). The software agent executes this step periodically, eg every minute, during game play and stores a snapshot in the user's system memory.

Next, the software agent obtains the rule set of the category set (step 902). These categories include processor usage, memory usage, network connections, Windows Z orders, and other user inputs. The ruleset defines the threshold for each category being monitored. Using the snapshot of the operating system, the software agent tracks individual point scores assigned to the next category (step 904). For each category, an individual point score is assigned, for example 40 points for processor usage and 35 points for Windows Z orders.

The software agent then determines whether individual point scores have reached the thresholds defined for each category (step 906). When the individual point score reaches a threshold, the score is added to the current cumulative score (step 908). However, if the threshold is not reached, step 914 is reached.

After step 908, the software agent determines whether the current cumulative score is higher than or equal to the point score defined in the active state (step 910). This point score is a predetermined point score, which is a score that the user considers to be "active" in any game. If the current cumulative score is greater than or equal to the predetermined point score for the activity state, the game state is set to "activity" (step 912) and the process ends. "Active" status means that the user is actively participating in the game. If the current cumulative score is not greater than the predetermined point score, the process proceeds to step 914.

In step 914, the software agent determines whether there are additional categories in the category set. If yes, the process returns to step 904 to track the next category. This step is done by examining a snapshot of the operating system. If the active window is in the front, the game state is set to "rest" (step 918). For example, in the "rest" state, a clip may be visible for a few minutes when the user completes a level. Thus, the processor and memory may be active for a few minutes but without any movement by the user. If the active window is not in front, the software agent sets the game state to "inactive" (step 920). The "inactive" state means that the user is not currently playing a game. Thus, the process ends.

10A-C are block diagrams illustrating activities and data related to identifying, storing, and transmitting user gameplay data, with the data flow of FIG. 10A being at the local client side.

In FIG. 10A, the agent 1000 starts the process. The agent 1000 starts the Eamonn engine (1002), and the Imon engine examines the new game and draws a custom game list stored in the local data store 108 from the ruleset file 1016. The custom game list changes as the user updates the game list in their online profile. If the game list changes, the agent 1000 must be tuned to support the new information. And dynamically updates the local ruleset file as needed by the synchronized agent activity 848 described in FIG. 8B.

The new game is tracked (1004) and the gamer 1010 detects that it has started a new game (1012). When a new game is started, the agent 1000 generates a new game object using algorithms and artificial intelligence in the ruleset file 1016 (1022) to confirm the game state (1022). The remaining confirmation comes from entropy harvesting 1020 by agent 1000. Entropy harvesting 1020 monitors user behavior 1018 while gamers 1010 play games, specifically monitoring movement of keyboards, joysticks, mice, and the like. The game state 1022 is determined by combining the variables of the entropy harvest 1020 and the ruleset file 1016. When the game state 1022 changes, the agent 1000 encrypts the client game data at any time (1024) and stores this data in the client game data file 1026. This checking process is repeated until the user game data reaches a certain threshold.

While the client game data 1026 is gathered, the agent 1000 determines how and when this game data 1026 is transmitted to the server in a separate process. This process is the local data transmission 1030 of FIG. 10B. In FIG. 10B, the local data transfer 1030 is manually activated by the gamer 1010 or periodically automatically updated to update credit 1010. Agent 1000 first acquires the network state (1032). If the process is manually activated and the gamer 1010 is offline, the agent 1000 sends a warning message to the gamer 1010 that an internet connection is required to update credits to the personal account, and proceeds. If local data transfer 1030 is automatically activated by the agent and the gamer 1010 is offline, the agent 1000 exits without any message, but if the gamer is online, checks the client game data threshold (1034). Determine if the threshold has been reached. When the threshold is reached, a server update is sent at a controlled size and frequency (1036). If more updates can be made in the client game data 1026, local data transfer 1030 is repeated, but if the threshold is not reached, the agent 1000 exits the process.

10C is a flow diagram of game play data at the server, assuming that the client or agent is ready to send client game data updates. This process begins with sending a client hello (1042) message to the web server 1040 and the server identifies hello (1044). The web server 1040 and the agent 1000 communicate with each other using a communication security protocol such as SOAP-over-HTTPS.

Agent 1000 then starts sending game updates to web server 1040 (1046). The web server 1040 confirms receipt of the client game data (1048) and inputs update data to the database 1051 (1050). After updating the database 1051, the game update confirmation 1052 is returned to the agent 1000. Agent 1000 continues to check for update data (1053) and send a game update to web server 1040 (1048) until all updated client game data in the client game data file is received (1048). The agent 1000 which has sent all game data sends a goodbye message to the web server 1040 to close the server session (1056). Subsequently, the web server 1040 closes the session (1058), including interrupting the connection with the database 1051, sends a goodbye message to the agent 1000, and then proceeds.

As described above, data in the database 1051 is used for various business functions, such as sending dynamic statistics to the agent 1000 (1062), managing gamers' bank account credits (1064), or shopping carts (1060). To manage the consumption of credits in the virtual mall.

11A-B are block diagrams of classes used to implement the present invention. 11B, the gamer invokes the launchGame 1118 function to start the game via the user interface 1124 and initiate a chat using the invokeChat 1114 function of chat 1108 Invoke the viewBiddies 1110 function of the chat 1108 to display a list of friends. In addition, gamers can update all possible options in user interface 1124. When the gamer synchronizes with the software agent, an update is requested by the software agent for the static content 1170 or the dynamic content 1172 and transmitted by the web server 1040 of FIG. 10C.

The EmonnnUser class 1100 contains user information such as a user name 1102 and a password 1104. When the software agent is running, the Imon Engine 1101 searches for a new game, processes entropy, determines the game state, and starts sending local data. The Imon engine 1101 searches for a new game based on the list of supported games. This list includes game names, IDs, and rulesets 1134. If the gamer detects that a new game has started, the Imon engine 1101 generates a game 1106 as shown in FIG. 11A if the started game is on the list. Game state 1130 included in game 1106 of FIG. 11A indicates whether the gamer is active, rested, or inactive. When the software agent detects a user-initiated user action, process entropy 1132 obtains game characteristic data such as mouse, keyboard, joystick movement, CPU utilization, memory usage, and network connection. The process entropy 1132 may include a CPU state 1142, a memory usage 1144, a pid 1146, a windowZlevel 1148, a network state 1133, a keyboard state 1138, a joystick state 1140, 1150 and the like, and the ruleset 1134 is also used to determine the game state. The ruleset 1134 may include a threshold value for each attribute to monitor, such as windowZorder 1137, user inputs 1139, CPU usage 1141, memory usage 1143, network connection 1145, Define.

The emone engine 1101 collects the client game data 1152 such as the user name 1154, the computerGuid 1158, the startTime 1160, the endTime 1162, and the gameState 1164 when it judges that there has been a state change, You can also collect other client game data such as kills, points, levels, mission completion, status, and wins. When the client game data 1152 accumulates, the Imon Engine 1101 sends this data to the server via a communications security protocol such as GSOAP 1174 of FIG. 11B, if there is a network connection or meets a critical limit at regular intervals. . The server then updates the data in database 1176 of FIG. 11B via the Internet.

12A-B are flowcharts illustrating a chat function of the present invention. As shown in Figure 12A, the agent checks the user preferences to determine whether to sign first. If a sign is displayed, the server requests a password (1200), or the chat client stays in a rest state (1202), and the user directly logs in to the web server and requests (1200).

The web server sends a password to the agent (1204), and the client receives the password (1206). When the agent receives a new password from the web server, it sends this password to the chat server as if the client typed it for authentication (1208). This password is considered the client's current chat password. If authentication is successful, a handshake is completed between the agent and the chat server (1212). The agent can log off the chat server to stop the chat (1214) or select a chat function. However, if authentication fails, an error message is returned to the user (1216) and retry.

The present invention has various chat functions. According to FIG. 12B, group chat join 1218, group chat initiation 1220, block other users 1222, remove a friend from subscriber 1224, accept another user's new subscription request 1226, and send another user to the subscriber. Add 1228, send a message to another user 1230, receive another user's message 1232, and the like.

When the user receives a message from another user (1232), the agent determines whether the other user is blocked or on the list. If it is a blocker, it discards the message (1234); if it is on the roster, it displays the message (1238); if it is not on the roster, it displays a prompt asking if the user wants to receive the message (1236). If the user wants to receive the message, display the message (1238), otherwise discard the message.

FIG. 13A is a flow chart of collecting gameplay data of a user from the perspective of a server in accordance with the present invention, and is implemented in server 320 of FIG. The server retrieves a user update of each game list in the user's online profile (step 1300), and then updates the user's game list data on the server (step 1302). A synchronization request is received from the agent (step 1304). The agent makes a tune request to get a new list of games locally. The server sends the game list to the agent with a dynamic library associated with the updated games of the game list (step 1306). It is likely that the dynamic libraries will be different for each supported game. If the agent is not tuned, new game lists and new dynamic libraries are never sent. The server then retrieves the communication request from the software agent (step 1308). The server receives client game data updates from the agent (step 1310) while supporting the designated games for the updated game list.

The server may then deposit credits into the user's personal account based on incentives such as cumulative points (step 1312). Credits may also be added based on cumulative real-time gameplay data, such as the time a user has spent in the game. The server then sends an account update to the software agent at the user's request or for dynamic statistics (step 1314), in which case the user can view the status of the account and the process ends.

FIG. 13B is a flow chart collecting user gameplay data from the software agent 301 perspective of FIG. 3. First, it is determined whether the user starts a new game (step 1320). Next, the dynamic library and the game variable list for the game are stored in the memory (step 1322). The game variable list contains variables that constantly monitor the game. This list is supplied by game developers.

After storing the variable in memory, the software agent uses the game variable list to store additional functions in memory (step 1324). Each game variable has its own function in a dynamic library that can compute this variable. Examples of game variables and corresponding functions are WindowZorder and "calWindowZorderWin32" as described above.

At intervals, the software agent calls the function and stores the data collected by this function (step 1326). This data is encrypted and stored in the client game data file or in a separate file. When a network connection is available and the threshold is reached, client game data is sent to the server (step 1328), which includes data collected by the function. Thus, the process then ends.

In short, the present invention provides a model for collecting user gameplay data online and offline and crediting the user for this data. The user's gameplay data is post-sale market research data, which would be biased and biased if it was before sale. It also provides a software agent that performs various functions such as user account management, chat management, game list management, and the like. It also provides gameplay data for unbiased single-player gamers. In addition, the company utilizes the features of the data to provide unique services, such as dynamic data to launch an interactive environment for users, competitive analysis among users, and data used for effective target advertising in live games. Can also be provided.

The present invention can take the form of complete hardware, complete software, or both. In addition, when implemented in the form of software, it may include firmware, resident software, microcode, which is of course only an example.

The invention may also take the form of a computer program product accessible by a computer medium providing program code for use in a computer or other command execution device. To this end, a computer medium includes any device capable of storing or transmitting a program for use in a computer.

Such computer media may be transmission media in electronic, magnetic, optical, electromagnetic, infrared or semiconductor formats. Examples of computer readable media include semiconductor or solid state memory, magnetic tape, computer diskette, RAM, ROM, magnetic disk, optical disk. Current optical discs include CD-ROM, CD-R / W, DVD. Such media may be tangible or intangible depending on the situation.

A data processing device for storing or executing program code includes a processor directly or indirectly connected to a memory through a bus. The memory includes local memory used during actual execution of program code, mass storage, and cache memory to temporarily store some programs.

I / O devices (including keyboards, displays, pointers, etc.) can be connected to the system either directly or through an I / O controller.

By connecting a network adapter to this system, you can connect data processing devices to other data processing devices, remote printers, or storage devices through private or public networks. Modems, cable modems, and Ethernet cards are currently used network adapters.

Claims (20)

In a computer implementation in a gaming environment: If the user starts the game, monitoring game characteristics generated in the data processing device as a result of the user's game play; Checking a game state based on game characteristics; Collecting gameplay data in response to a change in game state; Reporting gameplay data; And And classifying the game play data. The computer-implemented method of claim 1, wherein the game characteristics include user mouse movements, joystick movements, keyboard movements, user activity, memory usage, and processor utilization. The computer implemented method of claim 1 wherein the monitoring, verifying, collecting and reporting steps are performed by a software agent. The computer-implemented method of claim 1, wherein in the checking step, game characteristics are identified based on a user input or a rule set. 5. The computer-implemented method of claim 4, wherein the ruleset includes a threshold for game characteristics. The method of claim 1, wherein the reporting step, Accumulating game play data in a client game data file on a client side; And And sending the data to the server via a communication protocol if a threshold is reached. The method of claim 6, Updating gameplay data in a database; And Receiving dynamic data from a database; Wherein said dynamic data includes streaming statistics, chat subscribers, chat buddy status, local user status, and real-time performance statistics. The computer-implemented method of claim 1, wherein the gameplay data includes time, date, game title, and performance statistics the user has spent in the game. The method of claim 1, Reading a supported game list from the game list file while the game list file is based on the user profile and the game itself belongs to the supported game list; And And generating a new game object in association with the game based on the entry in the game list file. The method of claim 1, Managing user-initiated chat functions; These chat functions include joining group chats, initiating group chats, blocking second users, removing third users from subscribers, adding fourth users to subscribers, sending messages to fifth users, and receiving messages from sixth users. A computer implemented method, wherein each of the first to sixth users is another user other than the user of claim 1. Bus; A storage device containing computer use code; A communicator connected to the bus; User input; And A processor coupled to the bus; The processor executes the computer usage code to monitor game characteristics collected by the user game machine when the user starts the game and plays the game; Check the game state based on these game characteristics; Collect gameplay data when the game state changes; Game device, characterized in that for reporting the game play data. 12. The game device according to claim 11, wherein the processor checks the game characteristics based on user input or ruleset by executing computer use code. 12. The computer-readable medium of claim 11, wherein the processor executes computer usage code to accumulate game play data in a client game data file on a client side; When the threshold value is reached, the game device characterized in that sending the game play data to the server through the communication protocol. 12. The system of claim 11, wherein the processor executes computer usage code to update gameplay data to a database and receive dynamic data from the database, wherein the dynamic data includes streaming statistics, chat subscribers, chat buddy status, local user status, real time. A gaming device comprising performance statistics. 12. The system of claim 11, wherein the processor executes computer use code to read supported game lists from a game list file based on a user profile; And a new game object related to a game in the game list, based on the entry in the game list file. The method of claim 11, wherein the processor executes computer usage code to manage user-initiated chat functions, which chat group joins a group chat, initiates a group chat, blocks a second user, removes a third user from a subscriber, and a fourth. And adding a user to a subscriber, sending a message to a fifth user, and receiving a message of a sixth user, wherein each of the first to sixth users is another user other than the user of claim 11. In a computer program medium containing a computer use medium containing computer use program code executed in a gaming environment: The computer program code, Monitor game characteristics generated in the data processing apparatus when the user starts the game and plays the game; Check the game state based on these game characteristics; Collect gameplay data when the game state changes; And a computer program medium for reporting such gameplay data. 18. The computer program medium of claim 17, wherein the computer-used program code identifies game characteristics based on user input or ruleset. 18. The computer program product of claim 17, wherein the computer-enabled program code updates gameplay data in a database and receives dynamic data from the database, the dynamic data including streaming statistics, chat subscribers, chat buddy status, local user status, real-time performance statistics. And a computer program medium. 18. The method of claim 17, wherein the computer-enabled program code manages user initiated chat functions, the chat function joining a group chat, initiating a group chat, blocking a second user, removing a third user from a subscriber, and subscribing a fourth user. In addition to, sending a message to a fifth user, receiving a message of a sixth user, wherein each of said first to sixth users is a user other than the user of claim 17.

Images