DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Applicant’s submission of a response on 9/17/25 has been received and considered. In the response, Applicant amended claims 1 and 11 and canceled claims 2 and 12. Therefore, claims 1, 3-11 and 13-20 are pending.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 3-11 and 13-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dorn et al. (pub. no. 20210402304) in view of Rudi et al. (pub. no. 2022011297).
Regarding claim 1, Dorn discloses a method for detecting negative gameplay behavior and gameplay control (“A common problem in multi-player gameplay concerns how to address inappropriate or abusive actions by a given player. Such actions can include gameplay contrary to the spirit and principles of the video game, as well as activity that harasses or is inappropriate towards other players. Accordingly, implementations of the present disclosure provide methods and systems for detecting and addressing abusive gameplay. Such methods and systems can be useful in influencing correction of inappropriate behavior, so as to promote better gameplay experiences for players collectively.
In some implementations, abusive players are detected through player flagging, wherein players in a video game can flag abusive behavior for follow-up by the system. In some implementations, a machine learning model is trained to recognize abusive behavior, and further may suggest to the players when seemingly abusive behavior is recognized, to give the players the option to flag such behavior.
In some implementations, abusive players are automatically separated from a given multiplayer session or server of a video game. For example, an abusive player can be migrated to a different session or server in response to detecting abusive behavior on the part of the abusive player. Such migration of the abusive player can be managed in a manner so as to be seamless, or cause minimal interruption, to the abusive player and the other players in the video game. In some implementations, abusers are allowed to play games, but for those games, the abusers are focused to play together, separate from regular players that obey or work with the game mechanics to advance in the game. It is possible to switch abusive players to different servers, or different game instances or worlds, and such reassignment can be done in the background and not completely evident to the abusive player”, [0042] - [0044]),
the method comprising: receiving, by a device, gameplay data for a plurality of players for a game, wherein the gameplay data includes player input controls for the plurality of players (“The execution of the multi-player session generates a server game state 200 that is continually updated, using inputs from the user applied to the game engine to drive the gameplay. In order to detect events occurring during gameplay, game state data 202 (and/or game telemetry data) from the server game state 200 is obtained and analyzed using an event detection process 204 to identify when qualifying transitional events occur. In some implementations, game state data 202 may further include game state data and/or game telemetry data from any of the local sessions of the players”, [0065]);
detecting, by the device, at least one negative game behavior for at least one player of the plurality of players, wherein the at least one negative game behavior is detected based player input controls for a first player (“As has been noted, a problem in multiplayer gaming is that certain players can engage in abusive or inappropriate behavior. The actions of an abusive player degrade the gameplay experience for the other players of the video game. Hence, it is important to detect and address abusive behavior in multiplayer video games. To this end, the gaming service 100 further includes a player behavior system 114 that is configured to detect abusive behavior and address the abusive behavior through various mechanisms. The player behavior system 114 includes a behavior detection unit 116, which is configured to determine when abusive behavior by a given player occurs. In some implementations, the behavior detection unit 116 detects abusive behavior, at least in part, based on receiving flags or reports from players of a given session of the video game. In some implementations, the behavior detection unit 116 detects abusive behavior, at least in part, by using a machine learning model”, [0049];
“In some implementations, the behavior detection unit 116 can automatically report or flag a player for bad behavior. For example, the machine learning model 602 can be trained to recognize abusive behavior, and then be applied to run on current multiplayer gaming sessions and flag bad behavior. In some implementations, the alleged abusive behavior flagged by the machine learning model is verified by the verification logic 604, such as by presenting the flagged behavior (e.g. presenting video) to the alleged player's teammates and asking them for their judgement regarding whether they think the flagged behavior was actually abusive or not.
It will be appreciated that video and/or game state capture can be performed for behavior flagged by the machine learning model, and stored to the abusive behavior data storage 614. Captured data for identified abusive behavior (whether identified by a player or identified by the machine learning model), and especially verified abusive behavior, can be used to further train the machine learning model, so that over time the machine learning model improves its recognition of abusive behavior, both in terms of scope and accuracy”, [0095] & [0096]);
determining, by the device, at least one game function response of the game to limit outcome of the at least one player input control for the game; and controlling, by the device, output of the game using the at least one game function response (“In the illustrated implementation, the player 126 has been identified as an abusive player that has performed abusive/inappropriate actions in the multi-player session 104 of the video game, these being detected by the behavior detection unit 116. In response, the player behavior system 114 may perform various actions, such as warning the player 126 that the abusive actions have been detected, advising them to stop such behavior, and notifying them of penalties that may be levied against them. In the present disclosure, various types of penalties are discussed, including migration as discussed below, which can be imposed in response to detecting and verifying abusive behavior. It will be appreciated that in some implementations, such penalties may be imposed after abusive behavior is repeated at least once (detected more than once), or after the player has received at least one warning”, [0051];
“In some implementations, the server 106 to which the abusive player 126 is migrated, is selected or configured so as not to further enable the abusive behavior by the player 126. Such configuration can take various forms depending upon the abusive behavior that has been performed by the player 126. For example, in some implementations it may be desirable to limit contact of the abusive player with other players so as to limit the capacity of the abusive player to perform inappropriate actions towards another player. Thus, the server to which the abusive player is migrated can be selected or configured as a server having significantly fewer players, or scarce numbers of players, or players that are widely dispersed, or even no other players, such that it becomes less likely that the abusive player will come in contact with other players, and thereby reducing the opportunities for the abusive player to perform inappropriate actions affecting other players”, [0053];
“ In some implementations, when abusive behavior is detected, then a corrective action is implemented by a corrective action unit 610, the corrective action being configured to prevent the abusive behavior from reoccurring or motivate the abusive player not to engage in the abusive behavior. In some implementations, the abusive player can be notified that they have been reported for bad behavior (e.g. if the behavior has been verified as bad by the machine learning model). In some implementations, the abusive player is informed of what it was they were determined to have been doing wrong. This can be configured to allow them to learn from their mistakes or else be banned (e.g. temporarily or permanently)”, [0098];
“It will be appreciated that in various implementations, various corrective actions can be performed in response to detecting and/or verifying abusive behavior. For example, in some implementations, some functionality of an abusive player is reduced, disabled or turned off, e.g. text/keyboard chat, voice/mic chat, camera, microphone, etc. In some implementations, such functionality is disabled for a predefined period of time, until a significant event occurs, or until the session ends. In some implementations, such functionality is disabled specifically in relation to a given player that is a victim of or reports the abusive behavior, e.g. not allowing the abusive player to engage in keyboard chat or voice chat with the victim/reporting player”, [0101]).
Regarding claim 1, it is noted that Dorn does not disclose the player input controls comprise at least two of game controller input, voice command, audio input, text input, player in-game movement, or player position in game and that negative behavior is detected based on at least tow input controls. Rudi however, teaches player input controls comprise at least two of game controller input, voice command, audio input, text input, player in-game movement, or player position in game and that negative behavior is detected based on at least two input controls (“Examples of the classifications include instances of abusive behavior, such as abusive acts or negative acts, and instances of praiseworthy behavior, such as praiseworthy acts or positive acts, identified from the weighted factors, the input data 312, the correspondences between game states of the input data 312 and the chats or comments, or a combination thereof”, [0092]).
Exemplary rationales that may support a conclusion of obviousness include use of known technique to improve similar devices (methods, or products) in the same way. Here both Dorn and Rudi are directed to systems to flag bad behavior in a video game. To modify Dorn to use combination of chat or comments and game state of input to flag negative behavior would be to use a known technique to improve a similar device in the same way. Therefore, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the claimed invention to modify Dorn to incorporate the combination of factors as taught by Rudi to determine negative behavior. To do so would increase the accuracy of detection thereby increasing the perceived value of the system.
Regarding claim 3, Dorn discloses the negative game behavior is an in-game action of the first player for at least one of harming and disrupting a second player of the game (“Broadly speaking, abusive behavior can include any type of inappropriate gameplay, or gameplay activity in bad faith, or inappropriate behavior occurring during gameplay by a given player. Examples of abusive behavior include, without limitation, the following: failing to engage in gameplay or being “AFK” (away from keyboard), playing in a manner damaging or detrimental to one's own team or to a fellow member of the team, playing in bad faith or inconsistent with the mechanics of the game, “griefing” or deliberately using aspects of the game in unintended ways to irritate/harass/annoy/harm other players, text/voice chat harassment (e.g. using harassing or explicit language or images), spamming text or voice chat channels, etc”, [0050]).
Regarding claim 4, Dorn discloses the negative game behavior is a communication from the first player to at least one second player of the game ([0050]).
Regarding claim 5, Dorn discloses the negative game behavior is detected using a model and model training on parameters for at least one of text, speech, player in-game movement, player position in-game, and game state ([0049]; [0050];
“In some implementations, the machine learning model can be trained from prior gameplays so as to understand the proper mechanics for given scenarios of a video game. Thus, the machine learning model is enabled to recognize when player behavior deviates from the proper mechanics, which may constitute bad or abusive behavior”, [0129]).
Regarding claim 6, Dorn discloses determining a warning message for output to the first player ([0051]).
Regarding claim 7, Dorn discloses determining at least one control for blocking in-game output of the player input control ([0101]).
Regarding claim 8, Dorn discloses at least one of blocking and limiting input controls of the first player for a period of time ([0101]).
Regarding claim 9, Dorn discloses at least one of slowing and modifying game player characteristics of the first player for a period of time (“In some implementations, an abusive player is masked or otherwise socially removed from another player (victim or reporting player). In some implementations, the abusive player is made invisible or transparent so that the other player no longer sees the abusive player in the game. In some implementations, the other player is made invisible to the abusive player so that the abusive player can no longer see the other player.
In some implementations, the abusive player is socially removed by moving them to another location in the game world.
In some implementations, the appearance of an abusive player is changed, such as by coloring or changing their avatar's appearance in some way, which may provide an indicator of bad reputation.
In some implementations, respawning of an abusive player is slowed or subject to a time delay. In some implementations, prior to respawning, a tutorial is presented to the abusive player explaining why they've been penalized.
In some implementations, an abusive player is deprioritized in the queues for the game, such by delaying, slowing, or withholding them joining multiplayer matchmaking queues. In some implementations, the abusive player is prevented or withheld from joining sessions having characteristics or players that the abusive player has previously abused”, [0102] – [0106]).
Regarding claim 10, Dorn discloses removing the first player from a game session for a period of time ([0053]).
Claims 11 and 13-20 are directed to devices that implement the methods of claim 1 and 3-10 respectively and are rejected for the same reasons as claims 1 and 3-10 respectively.
Response to Arguments
Applicant’s arguments filed on September 17, 2025 have been fully considered but they are not entirely persuasive.
On page 6, Applicant argues that the amended claims overcome the prior art of record because Dorn does not disclose negative behavior is detected based on at least two player input controls. Examiner agrees. However, it would have been obvious to do so given the teachings of Rudi as detailed above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE STEFAN GALKA whose telephone number is (571)270-1386. The examiner can normally be reached M-F 6-9 & 12-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, David Lewis can be reached at 571-272-7673. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/LAWRENCE S GALKA/Primary Examiner, Art Unit 3715