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 .
Claim Rejections - 35 USC § 103
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.
Claims 1-2, 5, 8, 12-14 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2013/0116022 A1 to Davison et al. in view of US 2021/0394060 A1 to Yilmazcoban et al.
Re claim 1, Davison teaches: A method for generating assistive content,
The Abstract describes Davison as being directed to, “techniques to automatically provide assistance for electronic games … a game strategy application arranged to receive as input game telemetry … The game strategy application may process the game telemetry … to determine whether a player … needs assistance, and if so, automatically retrieve appropriate game strategy information from a local or remote datastore.”
the method comprising: receiving user information over a communication network from a user device, the user information regarding one or more interactions in a virtual environment during a current session of an interactive content title;
Refer again to the Abstract
[0019]-[0020] and [0025]describes that “… a game strategy application [is] arranged to receive as input game telemetry information representing gameplay of an electronic video game on a first client device. An example of the first client device may comprise a game system. The game strategy application may process the game telemetry information to determine whether a player of the electronic video game potentially needs assistance”
[0026] defines input game telemetry information as including “player information, client device information owned or operated by a player, input/output (I/O) device information used with a client device of a player” and so on.
Fig. 1 diagrams and [0026] describes Game Strategy System 100 as being in bidirectional communication with game telemetry information 110. Fig. 2 provides detail on the types of inputs received through telemetry including a player identifier 210-1, game identifier 210-2, game events 210-3, and game event times 210-4.
identifying that one or more of the interactions correspond to a progress level in relation to one or more objectives associated with the interactive content title;
[0036]-[0037] describes that a game monitor 122-2 monitors game telemetry parameters 210 of game telemetry information received from a game strategy application 120. “The game monitor component 122-1 may determine whether a player of an electronic video game needs assistance for a game event during gameplay of the electronic video game based on the one or more game telemetry parameters 210-b. The game monitor component 122-1 may generate a game assist indicator 220 when a player needs assistance.”
[0040] describes that game event parameters 210 comprise unique game events such as “a game challenge, a game puzzle … a game mission, a game objective, a game obstacle”.
[0056], “a game event parameter 210-3 may identify a specific game event, and the game strategy component 122-2 may retrieve or generate a set of game assist files 410-f customized for that specific game event.”
selecting an in-game action from among a plurality of different action options to take next within the virtual environment during the current session based on the progress level, wherein the selected in-game action is predicted to result in an outcome that advances the progress level toward at least one of the objectives;
[0055] describes that game assist files 410 pertinent to certain game events 218 can be retrieved or generated. The game assist files “may comprise discrete portions of game strategy information 130” including “multimedia help files, frequently asked question (FAQ) files, question and answer (Q&A) files, developer game secret files, cheats, cheat files, cheat codes, hints, strategies, advice, walkthroughs, and other similar types of information.”
Game strategy information including developer secrets, hints, tips, and cheats by definition are game actions predicted to advance a player in a game with respect to objectives (see definitions of objectives in [0040].)
generating custom assistive content based on the selected in-game action, wherein at least one video file of the video files is associated with the predicted outcome;
[0056], “The game strategy component 122-2 may retrieve or generate a set of game assist files 410-f customized for a specific game assist event 218-e. A game event parameter 210-3 may identify a specific game event, and the game strategy component 122-2 may retrieve or generate a set of game assist files 410-f customized for that specific game event. … a game assist parameter 210-5 may identify a specific type of assistance, such as a game event walkthrough, and the game strategy component 122-2 may retrieve or generate a set of text files 410-3 with the game event walkthrough.”
and providing the custom assistive content over the communication network to the user device for presentation during the current session.
[0056], “The game strategy component 122-2 may retrieve or generate a set of game assist files 410-f customized for a specific game assist event 218-e.”
and [0057], “The game strategy component 122-2 may send the one or more game assist files 410-f as game strategy information 130 to a client device. … the game strategy component 122-2 may send the one or more game assist files 410-f as a pass-through service without any pre-processing or post-processing operations, where the game assist files 410-f are sent to a client device as stored in the database 124.” or in another embodiment, “game strategy component 122-2 may process the game assist files 410-f to further customize game strategy information 130 for a given player, system or device.”
Although Davison teaches substantially the same inventive concept, Davison lacks wherein generating custom assistive video content comprises combining video files.
Yilmazcoban is an analogous prior art reference that occupies the same art of generating and providing game-related video clips and statistics to inform players of information, including hints, in real-time (Abstract, [0045]). Yilmazcoban teaches that it was known to generate such video clips by combining a plurality of individual video files associated with a certain in-game event topic. Yilmazcoban terms this activity “clustering” and describes in [0045] that “Video highlights generator 116 further comprises a clustering module 306 for clustering individual video clips from video editing library 304 for each topic, before being merged into a full video. Clustering is done such that the full videos are created both for professional players and enthusiasts to help educate the gamers and the community at large with best practices such as, by providing directly relevant hints to improve the game play.”
It would have been obvious to one having ordinary skill in the art before the effective filing date of the invention that Davison’s generated hint videos could comprise merged individual videos relevant to a given topic as taught by Yilmazcoban without causing any unexpected results. An expected advantage would be to provide multiple views and/or multiple examples of a certain teaching to ensure players have sufficient information to learn the hint being taught.
Re claim 2, Davison in [0040] describes that game event parameters 210 comprise unique game events such as “a game challenge, a game puzzle … a game mission, a game objective, a game obstacle”. As the claim does not provide any definition of “player-defined objectives” or outline any additional method steps needed to achieve this feature, any distinct objective that in any way relates to a player’s performance or progress in a game can be interpreted as a player-defined objective. The scenario in [0041] wherein a player of first-person shooter game has to release hostages from a guarded location wherein there is a measurable “amount of time a player has spent trying to accomplish the rescue mission” is a player-centric and thus player-defined objective.
Re claim 5, [0055] of Davison additionally describes providing haptic feedback such as tactile feedback as part of a sensory help file for conveying help information to a player. Haptic feedback meets the intended-use limitation of “presentation parameter for synchronizing … to the identified point of action”.
Re claim 8, Davison teaches, see [0042], [0044], [0051], in addition to analyzing game events, a player identifier 210 and player profile 214 may be evaluated when retrieving or generating game assistance. [0045] notes that a player assist parameter 215 may “provide further granularity to indicate global assist preferences, game specific assist preferences, game system specific assist preferences, game event specific preferences, game account specific preferences, and so forth.”
Re claim 12, Davison teaches selecting assistive information from a database, which meets a limitation of filtering, based on game telemetry data, see [0030], [0034], [0055].
Re claim 13, [0027], [0055]-[0056] of Davison describes that video assistive information can comprise walkthroughs, which by definition depict completing certain objectives (of the objectives noted in [0040]). And this content can be user-generated, see “walk-throughs” in Davison [0055].)
Re claim 14, the receipt of user input in telemetry, see Davison [0042], meets the limitation of a queried user input, as this claim does not define in what manner, such as by what specific method steps, querying it to be carried out. Inputs invoked by player-observed game progress meet this limitation. Additionally, [0043]-[0045] describes that a player may operate a management component interface to answer whether the player does or does not wish to receive gameplay assistance as well as indicated preferences related thereto.
Re claims 18 and 20, refer to the rejection of claim 1.
Re claim 19, see Davison [0055], “The game strategy component 122-2 may retrieve one or more game assist files 410-f for the game assist events 218-e. The game assist files 410-f may comprise discrete portions of game strategy information 130. Examples of game assist files 410-f may include without limitation multimedia help files … the game strategy component 122-2 may retrieve or generate one or more videos files 410-1”.
Claims 3-4, 6-7, 9-10 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US 2013/0116022 A1 to Davison et al. in view of US 2021/0394060 A1 to Yilmazcoban et al. and US 2021/0402292 A1 to Chow.
Re claims 3-4, Although Davison as modified by Yilmazcoban teaches substantially the same inventive concept including evaluating based on game telemetry data whether a player needs customized assistance to be able to achieve certain goals, Davison-Yilmazcoban lacks selecting a suggested in game action based on a current trajectory comprising one or more portions associated with different action options.
Chow is an analogous prior art automated video game assistant that teaches, see Fig. 5A, a current trajectory along path A comprising sequential segments, and action options including changing that trajectory, for example, to path C, starting from a certain segment along path A.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the invention that Davison-Yilmazcoban could have considered game actions with respect to a trajectory as taught by Chow without causing any unexpected results. The advantage expected would be to consider game story arcs and not just a single data point with respect to player performance.
Re claims 6-7, Chow additionally teaches that it was known in the art to generate updated custom assistive content based on whether objectives have been met or not, see [0006], “… the system may also identify an interactive task .. that the user missed interacting with or that requires an action from the user. The interactive task that the user missed or requires action may be identified by correlating content of the game scenario with context of actions performed by the user in the game scenario.”
[0040], “… players may miss certain interactive tasks … present in the game scenario of the game [that] may be needed by the player … in accumulating certain game points or rewards or tools, etc., that may be needed to progress in the video game.”
[0054], “…determine if the player is getting distracted or is losing focus or is having a hard time keeping pace with the game play or is missing interacting with interactive tasks within the game scenario, etc., which prevents the player from achieving game objective of the game play.”
Re claim 9, refer to Chow’s extensive teachings of a learning engine that uses machine learning logic to dynamically train from game inputs and game progression data in [0014], [0041]. And [0054] notes that the haptic learning model is further trained by “additional information collected from ongoing game inputs of the player”. Refer additionally to [0064]-[0065], [0070] “The attributes of the player and the game play features are also provided to the haptic learning engine 403 for generating and training a haptic learning model”, and notably [0071], actions a player missed when interacting in game scenarios are provided as input to the haptic learning engine 403.
It would have been obvious to one having ordinary skill in the art that Davison’s admittedly player-profile sensitive customized game play assistance could have applied a machine learning model trained to identify actions towards advancement as taught by Chow without causing any unexpected results. The application of machine learning has become ubiquitous in software applications, especially those that provide personalized functionality for users.
Re claim 10, Chow in [0053] further teaches game state data that is transmitted to and stored at a data center comprises metadata.
Re claim 15, Chow additionally teaches, see [0039], [0040], [0065], and note especially [0074], determining from a player’s progress that they have failed to complete or perform a task required to advance the game and generating updated assistive haptic content associated with the past failure aimed at completing an object.
Claims 11 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over US 2013/0116022 A1 to Davison et al. in view of US 2021/0394060 A1 to Yilmazcoban et al. and US 2021/0402292 A1 to Chow in view of US 2018/0243656 A1 to Aghdaie et al.
Re claim 11, Although Davison and Yilmazcoban as modified by Chow teaches incorporating machine learning based on past user’s game play sessions into customized player assistance generation, Chow is silent as to whether machine learning can additionally be performed on bot sessions.
Aghdaie is an analogous prior art video game dynamic difficulty reference that teaches, see [0049], “prediction models may be generated by analyzing data from a plurality of users or automated routines (“bots”…) The user or bot data may correspond to any type of user interaction information and/or bot information, such as length/frequency of user play sessions, user/bot scores, user/bot gameplay interactions, and/or the like. Relationships between different types of user and/or bot data can be identified to determine which types of user and/or bot data can be used to predict an expected value or occurrence.”
It would have been obvious to one having ordinary skill in the art before the effective filing date of the instant invention that the machine learning taught by Chow could have learned gameplay interactions from bots in addition to players as taught by Aghdaie without causing any unexpected results. The advantage would be that bot gameplay is still valid gameplay that can benefit machine learning.
Re claims 16-17, Aghdaie additionally teaches receiving user tags in association with user gaming information (equivalent to the claimed “annotation information”) for labeling user information accordingly so that a machine learning model can better interpret what might otherwise be anomalous data, see [0056].
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 STEVEN J HYLINSKI whose telephone number is (571)270-1995. The examiner can normally be reached Mon-Fri 10-530.
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, Dmitry Suhol can be reached at (571) 272-4430. 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.
/STEVEN J HYLINSKI/Primary Examiner, Art Unit 3715
Prosecution Insights