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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “the game” (line 3). There is insufficient antecedent basis for this limitation in the claim. Independent claims 11 and 20 recite similar claim language and are similarly rejected. Dependent claims 2-10 and 12-19 inherit this discrepancy by nature of their dependencies. Appropriate correction is required.
Claim 15 recites “The non-transitory computer readable medium” (line 1). There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
Claim 20 recites “the matchmaking system” (line 16). There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
Claim 20 recites “A system for matchmaking” (line 1) and “the matchmaking system” (line 16). Consistent usage of the same terms is much preferred over creatively describing the same elements using different language. Using similar, yet slightly different claim language creates confusion. It is unclear whether each term is intended to refer to the same claim element or whether each term refers to a different claim element. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claimed invention is directed to non-statutory subject matter because the claims as a whole, considering all claim elements both individually and in combination, do not amount to significantly more than an abstract idea. Each of claims 1-20 has been analyzed to determine whether it is directed to any judicial exceptions.
The determination of subject matter eligibility under 35 USC 101, relies on the Mayo/Alice two-step analysis.
In step 1 of the analysis, the claims are evaluated to determine whether they fall within one of the four statutory categories (i.e., process, machine, manufacture, or composition of matter). In the present case, claims 1-10 are directed to a method (i.e., a process), claims 10-19 are directed to a non-transitory computer readable medium (i.e., a manufacture), and claim 20 is directed to a system (i.e., a machine). The claims are, therefore directed to one of the four statutory categories.
Under prong 1 of step 2A, the examiner is directed to determine whether the claim recites a judicial exception. The claims are compared to groupings of subject matter that have been found by courts as abstract ideas. These groupings include
(a) Mathematical concepts—mathematical relationships, mathematical formulas or equations, mathematical calculations;
(b) Certain methods of organizing human activity—fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions); and
(c) Mental processes—concepts performed in the human mind (including an observation, evaluation, judgment, opinion).
Claim 1 is considered representative and recite (the abstract idea is underlined) a method for matchmaking of game players, comprising:
receiving player data associated with a user account;
receiving match state data associated with a match of the game;
based on the player data and the match state data, extracting a plurality of engagement prediction features;
providing, as an input to an engagement prediction model, the plurality of engagement prediction features;
receiving, as an output from the engagement prediction model, a predicted engagement metric, the predicted engagement metric being based on the plurality of engagement prediction features;
providing the predicted engagement metric as an input to a matchmaking system; and
receiving from the matchmaking system a decision whether to match the user account to the match of the game for gameplay.
The present claims are directed to a method of matchmaking. These steps fall under the category of certain methods of organizing human activity. Specifically, they are directed to the sub-category of managing personal behavior or relationships or interactions between people. Accordingly, the claim recites an abstract idea.
Under prong 2 of Step 2A, the examiner considers whether additional elements integrate the abstract idea into a practical application. To do so, the examiner looks to the following exemplary considerations, looking at the elements individually and in combination:
• an additional element reflects an improvement in the functioning of a computer, or an improvement to other technology or technical field;
• an additional element that applies or uses a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition (not considered relevant to the present claims);
• an additional element implements a judicial exception with, or uses a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim;
• an additional element effects a transformation or reduction of a particular article to a different state or thing; and
• an additional element applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception.
The additional elements in the present claims are a computer, a processor, and a non-transitory computer readable medium. The additional elements do no integrate the judicial exception into a practical application. In particular, the additional elements do not reflect an improvement in the functioning of a computer, or an improvement to other technology or technical field. The additional elements do not implement a judicial exception with, or uses a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim. The additional elements do not effect a transformation or reduction of a particular article to a different state or thing. The additional elements do not apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they does not impose any meaningful limits on practicing the abstract idea.
Under step 2B, the examiner evaluates whether the additional elements amount to significantly more than the judicial exception itself. The examiner considers if the additional elements:
• add a specific limitation or combination of limitations that are not well-understood, routine, conventional activity in the field, which is indicative that an inventive concept may be present; or
• simply appends well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, which is indicative that an inventive concept may not be present.
The present claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The additional elements are well-understood, routine, or conventional, as shown:
a computer, a processor, and a non-transitory computer readable medium (Vagner, US 2015/0302482 A1, a general computer can include a memory, a processor, input/out components, and other components that are common for general computers, all of which are well known in the art [0099]).
Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
As a result, the claims are not directed to patent eligible subject matter.
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.
Claims 1-7, 9-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over AMER et al., US 2021/0275908 A1 (hereinafter Amer) in view of Xue et al., US 2018/0111051 A1 (hereinafter Xue).
Regarding Claim 1: Amer discloses a method for matchmaking of game players, comprising:
receiving player data associated with a user account (Amer, one or more of player activity data indicative of levels of engagement associated with a player's voice, presence manual inputs, or body language [0018]);
receiving match state data associated with a match of the game (Amer, gameplay status data indicative of a game state of a game being streamed by the player or of the player being engaged in a side task [0018]);
based on the player data and the match state data, extracting a plurality of engagement prediction features (Amer, the engagement data 114 includes one or more of player activity data indicative of levels of engagement associated with a player's voice, presence manual inputs, or body language, ... gameplay status data indicative of a game state of a game being streamed by the player or of the player being engaged in a side task [0018]);
providing, as an input to an engagement prediction model, the plurality of engagement prediction features (Amer, the engagement analytics engine 114 includes player activity data, color anomaly data, gameplay status data, UI element data 408, motion characterization data 410, audio source data 412, and aggregate engagement data 414 [0042] and [Fig. 4]);
receiving, as an output from the engagement prediction model, a predicted engagement metric, the predicted engagement metric being based on the plurality of engagement prediction features (Amer, the engagement analytics engine 112 generates the player engagement score 452 based on one or both of the player activity data 402 and the gameplay status data 406 [0061]);
Amer fails to explicitly disclose
providing the predicted engagement metric as an input to a matchmaking system; and
receiving from the matchmaking system a decision whether to match the user account to the match of the game for gameplay.
Xue teaches
providing the predicted engagement metric as an input to a matchmaking system (Xue, matchmaking may be applied to a pool of users or players, P={p.sub.1, . . . , p.sub.N}, who are waiting to start or play 1-vs-1 matches; one such example of a pool of users P is illustrated in FIG. 3 as the pool of users 302; agraph G can be constructed to model the set of players waiting to play the multiplayer video game; one such example of the graph G is illustrated in FIG. 3 as the graph 304; each player p.sub.i may be represented by a vertex or a node of the graph, which has a current player state s.sub.i.; the player state s.sub.i may represent any data specific to the user and the user's interaction with the video game 112; the edge between two players p.sub.i and p.sub.i may be associated with the expected sum objective or engagement metric (for example, sum churn risk) if the users are paired; this metric relies on both users' states and may be denoted as a function f(s.sub.i, s.sub.j) [0062]); and
receiving from the matchmaking system a decision whether to match the user account to the match of the game for gameplay (Xue, a list of user or player tuples, M={(p.sub.i, p.sub.j)}, may be used to denote a matchmaking result, or a pair assignment, in which all players in P are paired and are only paired once [0062]).
Amer discloses an engagement analytics engine of a computing device analyzes one or more of scene representations, player inputs, or player meta information and generates corresponding engagement data indicative of a level of engagement corresponding to the represented scene (Amer [Abstract]). The engagement analytics engine generates encoding parameters based on the engagement data to cause scenes or regions within scenes to be encoded with a level of quality based on the indicated level of engagement (Amer [Abstract]). In some examples, the engagement analytics engine generates rendering parameters based on the engagement data to cause scenes to be rendered with a frame rate or quality parameters based on the indicated level of engagement (Amer [Abstract]). In some examples, the engagement analytics engine causes a load balancer to shift workloads associated with one or more scenes to higher or lower performance servers based on the engagement data (Amer [Abstract]).
Xue teaches identifying users to play a multiplayer video game together using a mapping system and machine learning algorithms to create sets of matchmaking plans for the multiplayer video game that increases player or user retention (Xue [Abstract]). Embodiments of systems presented herein can determine the predicted churn rate, or conversely retention rate, of a user waiting to play a video game if the user is matched with one or more additional users in a multiplayer instance of the video game (Xue [Abstract]). Software developers typically desire for their software to engage users for as long as possible (Xue [0002]). The longer a user is engaged with the software, the more likely that the software will be successful (Xue [0002]). The relationship between the length of engagement of the user and the success of the software is particularly true with respect to video games (Xue [0002]). The longer a user plays a particular video game, the more likely that the user enjoys the game and thus, the more likely the user will continue to play the game (Xue [0002]). The principle of engagement is not limited to single player games and can also be applied to multiplayer video games (Xue [0003]).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the engagement analytics engine as disclosed by Amer with the matchmaking system as taught by Xue in order to ensure users enjoy the game.
Regarding Claim 2: Amer further discloses wherein the match state data comprises at least one of a game map, a match capacity of the game, a number of players currently playing the game, current scores in the game, progress of the game, and number of objectives completed in the game (Amer, the engagement analytics engine 112 generates the game state data 430 based on at least one of analysis of rendered scenes associated with the game application 120, analysis of player command inputs 134, or analysis of game state information received from the game application 120 [0051]).
Regarding Claim 3: Amer further discloses wherein the player data comprises gameplay history data, player engagement history data, and player-specific attribute data (Amer, a prediction model can be used to determine an expected churn rate or a probability that a user will cease playing the video game 112 based on one or more inputs to the prediction model, such as, for example, historical user interaction information for a user [0032]; the player activity data includes player voice data 416, player visual presence data 418, player manual input data 420, and player body language data 422 [0043]).
Regarding Claim 4: Xue further teaches wherein the player-specific attribute data comprises at least one of player preferences, skill, playstyle, toxicity level, average kills and deaths in a session, winning streak, hours played in current session, hours played total, joining as a group, playing as a group, and friend connections (Xue, these play characteristics may include characteristics relating to skill level, play style (for example, a user who plays defensively, plays offensively, plays a support role, prefers stealth attacks, prefers to use magic abilities, or prefers to use melee abilities, and the like), and/or sportsmanship (for example, a user who is a gracious winner or loser, is or is not gregarious, or does not insult other users, and the like) [0027]).
Regarding Claim 5: Xue further teaches wherein the player preferences comprise at least one of game map preferences, weapon preferences, vehicle preferences, and character class preferences (Xue, the data may include in-game character selection preferences, role preferences, and other information [0057]).
Regarding Claim 6: Xue further teaches wherein the user account is matched to a match of the game that includes one or more other matched accounts (Xue, matchmaking may be applied to a pool of users or players, P={p.sub.1, . . . , p.sub.N}, who are waiting to start or play 1-vs-1 matches [0062]).
Regarding Claim 7: Xue further teaches wherein the predicted engagement comprises an engagement score that represents a likelihood that the user account will engage in a match defined by the match state data (Xue, multiplayer games with poor matchmaking algorithms can result in lower engagement by users; in other words, poorly matched opponents and/or teammates may result in users ceasing to play a video game or playing the video game less often than if the multiplayer game has better matchmaking algorithms [0019]).
Regarding Claim 8: Amer in view of Xue discloses the invention as recited above. Amer in view of Xue fails to explicitly disclose wherein the engagement score is a value between zero and one, inclusive, with a minimum value of zero representing a first prediction that the user account will not engage, and a maximum value of one representing a second prediction that the user account will engage.
Amer discloses wherein aggregate engagement data includes a temporal importance score, high engagement regions, low engagement regions, a player engagement score, and an aggregate engagement score (Amer [0058]).
Xue teaches finding an optimal pair assignment M*, which maximizes the overall player engagement by using an equation (i.e., M*=arg max.sub.M Σ.sub.(p.sub.i.sub.,p.sub.j)ϵMf(s.sub.i, s.sub.j)) (Xue [0058]).
In both instances, it is clear that engagement is a value that is used in an equation. Engagement has a range of no engagement to full engagement and could be described by any range of values. The ultimate decision to select the numerical range of engagement is a matter of obvious design choice that would work equally well.
Therefore, it would have been prima facie obvious to modify Amer to define engagement as ranging from zero to one because such a modification would have been considered a mere design consideration which fails to patentably distinguish over the prior art of Amer.
Regarding Claim 9: Xue further teaches wherein providing the predicted engagement as an input to a matchmaking system is based on a determination that the engagement score is greater than a pre-defined engagement threshold associated with the match state data, wherein proposed matches with engagement scores below the pre-defined engagement threshold are not provided to the matchmaking system (Xue, the prediction model 160 may be use to confirm whether a particular match plan satisfies a set of conditions, such as, for example, a particular threshold retention rate [0049]).
Regarding Claim 10: Amer further discloses
providing the match state data as a further input to the matchmaking system.
(Amer, the engagement data 114 includes one or more of player activity data indicative of levels of engagement associated with a player's voice, presence manual inputs, or body language, ... gameplay status data indicative of a game state of a game being streamed by the player or of the player being engaged in a side task [0018])
Regarding Claim 11: Amer discloses a non-transitory computer readable medium storing a program for matchmaking of game players, which when executed by a computer, configures the computer to:
receive player data associated with a user account (Amer, one or more of player activity data indicative of levels of engagement associated with a player's voice, presence manual inputs, or body language [0018]);
receive match state data associated with a match of the game (Amer, gameplay status data indicative of a game state of a game being streamed by the player or of the player being engaged in a side task [0018]);
based on the player data and the match state data, extract a plurality of engagement prediction features (Amer, the engagement data 114 includes one or more of player activity data indicative of levels of engagement associated with a player's voice, presence manual inputs, or body language, ... gameplay status data indicative of a game state of a game being streamed by the player or of the player being engaged in a side task [0018]);
provide, as an input to an engagement prediction model, the plurality of engagement prediction features (Amer, the engagement analytics engine 114 includes player activity data, color anomaly data, gameplay status data, UI element data 408, motion characterization data 410, audio source data 412, and aggregate engagement data 414 [0042] and [Fig. 4]);
receive, as an output from the engagement prediction model, a predicted engagement metric, the predicted engagement metric being based on the plurality of engagement prediction features (Amer, the engagement analytics engine 112 generates the player engagement score 452 based on one or both of the player activity data 402 and the gameplay status data 406 [0061]);
wherein the player data comprises gameplay history data, player engagement history data, and player-specific attribute data (Amer, a prediction model can be used to determine an expected churn rate or a probability that a user will cease playing the video game 112 based on one or more inputs to the prediction model, such as, for example, historical user interaction information for a user [0032]; the player activity data includes player voice data 416, player visual presence data 418, player manual input data 420, and player body language data 422 [0043]).
Amer fails to explicitly disclose
provide the predicted engagement metric as an input to a matchmaking system; and
receive from the matchmaking system a decision whether to match the user account to the match of the game for gameplay,
Xue teaches
provide the predicted engagement metric as an input to a matchmaking system (Xue, matchmaking may be applied to a pool of users or players, P={p.sub.1, . . . , p.sub.N}, who are waiting to start or play 1-vs-1 matches; one such example of a pool of users P is illustrated in FIG. 3 as the pool of users 302; agraph G can be constructed to model the set of players waiting to play the multiplayer video game; one such example of the graph G is illustrated in FIG. 3 as the graph 304; each player p.sub.i may be represented by a vertex or a node of the graph, which has a current player state s.sub.i.; the player state s.sub.i may represent any data specific to the user and the user's interaction with the video game 112; the edge between two players p.sub.i and p.sub.i may be associated with the expected sum objective or engagement metric (for example, sum churn risk) if the users are paired; this metric relies on both users' states and may be denoted as a function f(s.sub.i, s.sub.j) [0062]); and
receive from the matchmaking system a decision whether to match the user account to the match of the game for gameplay (Xue, a list of user or player tuples, M={(p.sub.i, p.sub.j)}, may be used to denote a matchmaking result, or a pair assignment, in which all players in P are paired and are only paired once [0062]).
As stated with respect to claim 1, it would have been obvious to one of ordinary skill in the art before the effective filing date to combine the engagement analytics engine as disclosed by Amer with the matchmaking system as taught by Xue in order to ensure users enjoy the game.
Regarding Claim 12: Amer further discloses wherein the match state data comprises at least one of a game map, a match capacity of the game, a number of players currently playing the game, a number of artificial intelligence bots playing the game, current scores in the game, progress of the game, and number of objectives completed in the game (Amer, the engagement analytics engine 112 generates the game state data 430 based on at least one of analysis of rendered scenes associated with the game application 120, analysis of player command inputs 134, or analysis of game state information received from the game application 120 [0051]).
Regarding Claim 13: Xue further teaches wherein the player-specific attribute data comprises at least one of player preferences, skill, playstyle, toxicity level, average kills and deaths in a session, winning streak, hours played in current session, hours played total, joining as a group, playing as a group, and friend connections (Xue, these play characteristics may include characteristics relating to skill level, play style (for example, a user who plays defensively, plays offensively, plays a support role, prefers stealth attacks, prefers to use magic abilities, or prefers to use melee abilities, and the like), and/or sportsmanship (for example, a user who is a gracious winner or loser, is or is not gregarious, or does not insult other users, and the like) [0027]).
Regarding Claim 14: Xue further teaches wherein the player preferences comprise at least one of game map preferences, weapon preferences, vehicle preferences, and character class preferences (Xue, the data may include in-game character selection preferences, role preferences, and other information [0057]).
Regarding Claim 15: Xue further teaches wherein the user account is matched to a match of the game that includes one or more other matched accounts (Xue, matchmaking may be applied to a pool of users or players, P={p.sub.1, . . . , p.sub.N}, who are waiting to start or play 1-vs-1 matches [0062]).
Regarding Claim 16: Xue further teaches wherein the predicted engagement comprises an engagement score that represents a likelihood that the user account will engage in a match defined by the match state data (Xue, multiplayer games with poor matchmaking algorithms can result in lower engagement by users; in other words, poorly matched opponents and/or teammates may result in users ceasing to play a video game or playing the video game less often than if the multiplayer game has better matchmaking algorithms [0019]).
Regarding Claim 17: Amer in view of Xue discloses the invention as recited above. Amer in view of Xue fails to explicitly disclose wherein the engagement score is a value between zero and one, inclusive, with a minimum value of zero representing a first prediction that the user account will not engage, and a maximum value of one representing a second prediction that the user account will engage.
Amer discloses wherein aggregate engagement data includes a temporal importance score, high engagement regions, low engagement regions, a player engagement score, and an aggregate engagement score (Amer [0058]).
Xue teaches finding an optimal pair assignment M*, which maximizes the overall player engagement by using an equation (i.e., M*=arg max.sub.M Σ.sub.(p.sub.i.sub.,p.sub.j)ϵMf(s.sub.i, s.sub.j)) (Xue [0058]).
In both instances, it is clear that engagement is a value that is used in an equation. Engagement has a range of no engagement to full engagement and could be described by any range of values. The ultimate decision to select the numerical range of engagement is a matter of obvious design choice that would work equally well.
Therefore, it would have been prima facie obvious to modify Amer to define engagement as ranging from zero to one because such a modification would have been considered a mere design consideration which fails to patentably distinguish over the prior art of Amer.
Regarding Claim 18: Xue further teaches wherein providing the predicted engagement as an input to a matchmaking system is based on a determination that the engagement score is greater than a pre-defined engagement threshold associated with the match state data, wherein proposed matches with engagement scores below the pre-defined engagement threshold are not provided to the matchmaking system (Xue, the prediction model 160 may be use to confirm whether a particular match plan satisfies a set of conditions, such as, for example, a particular threshold retention rate [0049]).
Regarding Claim 19: Amer further discloses wherein the program, when executed by the computer, further configures the computer to provide the match state data as a further input to the matchmaking system (Amer, the engagement data 114 includes one or more of player activity data indicative of levels of engagement associated with a player's voice, presence manual inputs, or body language, ... gameplay status data indicative of a game state of a game being streamed by the player or of the player being engaged in a side task [0018]).
Regarding Claim 20: Amer discloses a system for matchmaking of game players, comprising:
a processor (Amer, a hardware processor [0006]); and
a non-transitory computer readable medium storing a set of instructions (Amer, a hardware processor in communication with the electronic data store [0006]), which when executed by the processor, configure the processor to:
receive player data associated with a user account (Amer, one or more of player activity data indicative of levels of engagement associated with a player's voice, presence manual inputs, or body language [0018]);
receive match state data associated with a match of the game (Amer, gameplay status data indicative of a game state of a game being streamed by the player or of the player being engaged in a side task [0018]);
based on the player data and the match state data, extract a plurality of engagement prediction features (Amer, the engagement data 114 includes one or more of player activity data indicative of levels of engagement associated with a player's voice, presence manual inputs, or body language, ... gameplay status data indicative of a game state of a game being streamed by the player or of the player being engaged in a side task [0018]);
provide, as an input to an engagement prediction model, the plurality of engagement prediction features (Amer, the engagement analytics engine 114 includes player activity data, color anomaly data, gameplay status data, UI element data 408, motion characterization data 410, audio source data 412, and aggregate engagement data 414 [0042] and [Fig. 4]);
receive, as an output from the engagement prediction model, a predicted engagement metric, the predicted engagement metric being based on the plurality of engagement prediction features (Amer, the engagement analytics engine 112 generates the player engagement score 452 based on one or both of the player activity data 402 and the gameplay status data 406 [0061]).
Amer fails to explicitly disclose
provide the predicted engagement metric as an input to a matchmaking system; and
receive from the matchmaking system a decision whether to match the user account to the match of the game for gameplay.
Xue teaches
provide the predicted engagement metric as an input to a matchmaking system (Xue, matchmaking may be applied to a pool of users or players, P={p.sub.1, . . . , p.sub.N}, who are waiting to start or play 1-vs-1 matches; one such example of a pool of users P is illustrated in FIG. 3 as the pool of users 302; agraph G can be constructed to model the set of players waiting to play the multiplayer video game; one such example of the graph G is illustrated in FIG. 3 as the graph 304; each player p.sub.i may be represented by a vertex or a node of the graph, which has a current player state s.sub.i.; the player state s.sub.i may represent any data specific to the user and the user's interaction with the video game 112; the edge between two players p.sub.i and p.sub.i may be associated with the expected sum objective or engagement metric (for example, sum churn risk) if the users are paired; this metric relies on both users' states and may be denoted as a function f(s.sub.i, s.sub.j) [0062]); and
receive from the matchmaking system a decision whether to match the user account to the match of the game for gameplay (Xue, a list of user or player tuples, M={(p.sub.i, p.sub.j)}, may be used to denote a matchmaking result, or a pair assignment, in which all players in P are paired and are only paired once [0062]).
As stated with respect to claim 1, it would have been obvious to one of ordinary skill in the art before the effective filing date to combine the engagement analytics engine as disclosed by Amer with the matchmaking system as taught by Xue in order to ensure users enjoy the game.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WERNER G GARNER whose telephone number is (571)270-7147. The examiner can normally be reached M-F 7:30-15:30 EST.
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.
/WERNER G GARNER/Primary Examiner, Art Unit 3715