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 § 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-7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. According to the specification, the invention relates to a game system allowing a player to engage in a parimutuel wagering game. Exemplary claims 1 and 7 include the following underlined claim elements:
1. A system for supporting a real-time baseball betting service comprising: a user terminal configured to, via a real-time baseball betting service platform, bet a specified amount of game money on a predicted outcome of a game event occurring during each inning of a live broadcast baseball match using a predetermined amount of game money which is paid per match; and a baseball game betting service server configured to directly or indirectly allow and/or prevent the user terminal from participating in a betting process according to a preset game betting rule, and pay a predetermined reward to the user terminal based on a cumulative sum of results of betting in which the user terminal participates in at least one of the game events occurring during each inning
7. A method for providing a real-time baseball betting service comprising: executing, by a user terminal, a real-time baseball game betting service platform and playing a desired baseball match video; displaying, by the user terminal, a result of a matchup between a pitcher and a batter for each inning and at least one game event about a defensive player; inputting, by the user terminal, preset betting points for at least one of game events related to a pitcher, batter, and defensive player for each inning under preset betting conditions; displaying, by the user terminal, betting results according to results of the game events related to the pitcher, the batter, and the defensive player; and when the game results are over, summing up betting points for the betting results of a user's bets on the pitcher and batter for each inning and then paying a prize or reward corresponding to summed points.
The underlined claim elements are directed in user interaction in a wagering game environment including applying game logic to user interactions which is the court enumerated abstract idea of certain methods of organizing human activities, following rules or instructions. The various dependent claims only further detail the abstract ideas or constitute insignificant extra solution activity and consequently are also considered abstract ideas.
This judicial exception is not integrated into a practical application because the claims do not recite additional elements that would integrate the abstract idea into a practical application. The recited “user terminal”, “game betting service platform” and “game betting service server” amount to implementing the abstract idea on a general purpose computer, and/or do no more than generally link the use of a judicial exception to a particular technological environment or field of use. There is no improvement made to computer technology since the claims are directed to a wagering game. This is not related to a long standing problem in computer technology. Additionally, there is no practical application as there is no particular machine that is used to implement the claim language and only generic computer components are used to perform the invention. Also, there is no transformation of the machine used in the application into a different state or thing. Lastly, the claims do not attempt to apply the abstract idea in a meaningful way beyond simply using a generic computer. The various dependent claims only further detail the abstract idea or are insignificant extra solution activity and also fail to rise significantly more than the abstract ideas.
The additional element(s) or combination of elements in the claim(s) other than the abstract idea(s) per se including one or more of an input device, output device: (i) mere instructions to implement the idea on a computer, and/or (ii) recitation of generic computer structures that serves to perform generic computer functions that are well-understood, routine, and conventional activities previously known to the pertinent industry per the applicant’s description (Applicant’s specification Paragraphs [0036], [0100], [0159] and [0162]). Viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself
Therefore, the claims are directed to an abstract idea that lacks significantly more and thus is not patent eligible.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1 and 4 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Simon (pub. no. 2003015797).
Regarding claim 1, Simon discloses a system for supporting a real-time baseball betting service comprising: a user terminal configured to, via a real-time baseball betting service platform, bet a specified amount of game money on a predicted outcome of a game event occurring during each inning of a live broadcast baseball match; using a predetermined amount of game money which is paid per match (“Accordingly, a PBG is provided for playing by a plurality of players, typically over the Internet. The parimutuel betting game is based on events unfolding during a live sporting event. A principle objective of the game is to acquire the largest number of betting tokens by the end of the sporting event. The players are in direct competition because payoffs are made in parimutuel style. Tokens are allocated to the players prior to commencement of the sporting event. A plurality of betting events are conducted during the sporting event. Each of the betting events is based on a bettable event occurring during the sporting event. Each step of conducting abetting event comprises selecting a betting event from the bettable events and administering at least one betting line for the betting event. Each step of administering a betting line comprises: opening a betting line for the betting event, the betting line based on a finite set of possible outcomes of the betting event; allowing the players an amount of time within which to selectively bet tokens on the possible outcomes of the betting event; freezing tokens bet on the open line such that the frozen tokens are not available for further betting until a payoff has been made on the betting event; closing the betting line after a selected interval such that no further tokens may be bet on the line; monitoring the sporting event until a termination event occurs with regard to the betting event; and terminating the betting event upon occurrence of the termination event for the betting event. Upon termination of the betting event, winners of each of the betting lines are paid off in parimutuel style. The process of selectively conducting betting events is repeated until the sporting event has concluded”, [0042];
“A simple way to play the PBG is to start each player 10 with a certain number of tokens 40 and declare the winner to be the player 10 with the most tokens 40 when the sporting event is over”, [0081];
“In order to play a PBG there must be some mechanism for opening 22, closing 24, and terminating 26 betting lines. The easiest way to do this is to have a human administrator 300 who watches the sporting event along with the players 10 (typically at some remote location) and has the responsibility of opening 22, closing 24 and terminating 26 betting lines 20”, [0095]);
and a baseball game betting service server configured to directly or indirectly allow and/or prevent the user terminal from participating in a betting process according to a preset game betting rule, and pay a predetermined reward to the user terminal based on a cumulative sum of results of betting in which the user terminal participates in at least one of the game events occurring during each inning (“In a preferred embodiment, the PBG is played in a computerized format, such as over the Internet, and is administered by an administrator. A host processor is provided, the host processor being programmed for analyzing and processing input data and outputting data and information relevant to the parimutuel betting game. A plurality of player processors are interactively connected to the host processor. The player processors are programmed for playing the PBG. Each player processor has a display means operatively associated therewith for displaying data received from the host processor and for entering data and sending data to the host processor. An administrative processor is interactively connected to the player processors via the host processor. The administrative processor is programmed for administering the parimutuel betting game. The administrative processor has a display means operatively associated therewith for displaying data received from the host processor and for entering data and sending data to the host processor. An administrator browser page is displayed on the display means of the administrative processor. A player browser page is displayed on the display means of each player processor. The processors are used to allocate betting tokens to each of the players prior to commencement of the sporting event. The administrator monitors the sporting event for situations giving rise to bettable events. The players and the administrator use the browser pages and the processors to conduct the plurality of betting events. The administrator selects the betting events. The administrator uses the administrative browser page to open a betting line for the betting event. When the administrator opens a new betting line, the administrative processor sends a betting line identifier and a bonus amount for the new line to the host processor. Upon receiving the betting line identifier for the new line, the host processor opens a new betting line. Betting event information for the open betting line is displayed on the display means of the player processors. The players are allowed an amount of time within which to use the player browser pages to selectively bet tokens on the possible outcomes of the betting event. For each bet placed by a player on a betting line, data concerning the bet is sent to the host computer for processing. The data includes a player identification, a betting line identification, a betting choice identification, and an amount bet. Tokens bet on the open betting line are frozen such that the frozen tokens are not available for further betting until a payoff has been made on the betting event. Updated betting information for each betting line is displayed on the player browser pages. After a selected interval, the administrator closes the betting line such that no further tokens may be bet on the line. When the administrator closes the line, the administrative processor sends the line identifier for the new line to the host processor. Upon receiving the betting line identifier, the host closes the new betting line such that no further bets can be placed on the line. The administrator monitors the sporting event until a termination event occurs with regard to the betting event. The administrator terminates the betting event upon occurrence of the termination event for the betting event. When the administrator terminates the betting event, the administrative processor sends the line identifier and a winning choice identification to the host processor for calculating the parimutuel payoff on the betting lines. Upon termination of the betting event, winners of each betting line in the betting event are paid off in parimutuel style, with the payoffs being determined and processed by the host processor. Updates are performed on a periodic basis wherein the host processor sends data to all the player processors and the administrative processor reflecting changes to the browser pages. The process of selectively conducting betting events is repeated until the conclusion of the sporting event”, [0043];
“Batter. The players 10 bet on the outcome of each batter's turn at bat. A line 20 opens 22 when the batter is about to step to the plate. A new line 20 can open 22 after each pitch, at which time the previous line closes 24. The basic choices are: (1) out and (2) not out. The choices could be elaborated (e.g., an out could be a strike out, fly out or ground out). The lines 20 terminate 26 when the player's at-bat is over. FIG. 8A is a block diagram representing a preferred embodiment of a hierarchical parimutuel style payoff structure for a betting event based on an at-bat in a baseball game.
Inning. The players 10 bet on the outcome of the half inning. A line 20 opens 22 at the end of the previous half inning, and subsequent lines 20 open 22 after the first and second outs are made. Lines 20 close 24 when the next line 20 opens 22. The basic choices are: (1) no runs; (2) one run; (3) two runs; and (4) more than two runs. Again, the choices could be elaborated significantly. The lines 20 terminate 26 at the end of the half inning. FIG. 8B is a block diagram representing a preferred embodiment of a hierarchical parimutuel style payoff structure for a betting event based on the outcome of an inning of a baseball game.
Winner. The players 10 bet on the winner of the game. A line 20 opens 22 at the beginning of the game and at the end of each half inning. Lines 20 close 24 when the next one opens 22. The basic choices are: (1) team 1 and (2) team 2. The choices could be elaborated (e.g., include the final score). The lines 20 terminate 26 when the game ends.
There are countless other betting events 18 for baseball, including: (1) next score; (2) winning pitcher; (3) losing pitcher; (4) winning margin; (5) number of home runs, and so on”, [0121] – [0125]).
Regarding claim 4, Simon discloses the baseball game betting service server is configured to sum up betting points of participants who failed to bet among betting points on result of a batter's attack and then distribute summed betting points evenly (“When the administrator terminates the betting event, the administrative processor sends the line identifier and a winning choice identification to the host processor for calculating the parimutuel payoff on the betting lines. Upon termination of the betting event, winners of each betting line in the betting event are paid off in parimutuel style, with the payoffs being determined and processed by the host processor”, [0042];
“In many of the betting events 18 described in the previous sections, the basic choices 80 could be divided into subchoices which would make interesting bets themselves. For example, the batter betting event in a baseball game has two primary outcomes 2001: SAFE and OUT. These two options branch into numerous possibilities 2002, and some of those possibilities can branch further 2003, as illustrated in FIG. 8A. Of course, if one player 10 places, for example, ten tokens on a particular choice 2001 and a second player 10 places 10 tokens on a subchoice 2002 of that choice 2001, the second player 10 should get a higher payoff than the first player 10 if they both win, since the second player 10 took a greater risk and made a more courageous bet. For example, the first player 10 might bet on "OUT" 2001 and the second player 10 on "GROUND OUT" 2002. If the batter strikes out, the first player 10 is a winner and the second player 10 is a loser. However, if the batter does ground out then both players 10 are winners, and the payoff scheme should reward the second player 10 for making a more courageous bet. This section describes a method for determining payoffs for hierarchical choice sets that retains the flavor of a parimutuel style.
To begin, we need to develop a notation for hierarchical choice sets. For a given betting event 18 we will number the choices from 1 to c. There is also a choice 0 that corresponds to the betting event 18 itself. The hierarchical structure is specified by a function P(l), l=1, 2, . . . , c, where P(l) is interpreted as the "parent" of choice l. In other words, if l1 is one of the subchoices of l2 then P(l1)=P(l2). If l is one of the "primary" choices (e.g. SAFE or OUT) then P(l)=0. The leaves 2010 of the tree 2000 are the choices that have no subchoices. A subtree of the betting line is a choice 2001 along with all its "descendants" 2002, 2003. For example, in FIG. 8A the choice HIT 2002 along with its subchoices SINGLE, DOUBLE, TRIPLE and HOME RUN 2003 constitutes a subtree. The subbets of choice l is the set of all "descendants" of l. For example, in FIG. 8A, the choice OUT has four subtrees, three of which are simply leaves 2010. Let Ll be the "level" of choice l defined to be the number of "generations" it is from choice 0. For example in FIG. 8A, L(SAFE)=1 and L(HOMERUN)=3. Each choice l that is not a leaf has a bonus bl>;0 associated with it. The tokens bet on the subtrees of l, plus the bonus bl, becomes the pot for choice l, which is split between the players 10 with bet(s) in the winning subtree of l (if there is one). Of course, if l is not a winning choice than all the players 10 betting on l or any of its descendants lose their bets. The question remains: How is the pot for choice l split between the players 10 when it is a winning choice?
The basic winning choice is the choice with the highest level among the winning choices. For example, in FIG. 8A, if a batter hits a home run then SAFE, HIT and HOME RUN are all winning choices, and HOME RUN is the basic winning choice. The basic winning choice is typically a leaf 2010, but does not have to be. For example, if a batter is "hit by a pitch" then SAFE would be the basic winning choice since the precise outcome does not appear in any of the subtrees. Any bets in the subtrees of SAFE would be losers. Clearly l is a winning choice if and only if it is the basic winning choice or is an "ancestor" of the basic winning choice. In other words, there is a unique path from the basic winning choice, "down the tree," to choice 0. The payoffs are calculated by climbing down the tree from the basic winning choice, one generation at a time, until choice 0 is reached, using the recursive algorithm described next”, [0136] – [0138]).
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.
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.
Claim(s) 2, 3 and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Simon (pub. no. 2003015797) in view of Steir et al. (pub. no. 20130184039).
Regarding claim 2, Simon discloses the baseball game betting service server is configured to support game betting on one or more baseball match broadcasts currently being played and on possible game events in each inning of each baseball match, for each pitcher, batter within a betting time, wherein the betting time for the pitcher is a time period from a time when a batter enters a batter's box to a time when the pitcher takes a set position to pitch (the pitcher places his axial foot facing the batter fully on or in front of a pitching plate, making contact with the pitching plate without separating from it, and then places his other foot in front of the pitching plate, holding a ball with both hands in front of his body, and completely stops moving for at least one second), and wherein the betting time of the batter and the defensive player is a time period from a time when a current batter strikes out or leaves the batter's box to a time when a next batter in order enters the batter's box (“Batter. The players 10 bet on the outcome of each batter's turn at bat. A line 20 opens 22 when the batter is about to step to the plate. A new line 20 can open 22 after each pitch, at which time the previous line closes 24. The basic choices are: (1) out and (2) not out. The choices could be elaborated (e.g., an out could be a strike out, fly out or ground out). The lines 20 terminate 26 when the player's at-bat is over. FIG. 8A is a block diagram representing a preferred embodiment of a hierarchical parimutuel style payoff structure for a betting event based on an at-bat in a baseball game”, [0122]).
Regarding claim 2, it is noted that Simon does not disclose a prediction with respect to a defensive player. Steir however, teaches a prediction with respect to a defensive player (“Game play can include various match-play construction decisions, such as defining the game play elements 802, and combining them into selection choices 804. In this match representation, the player at-bat is asked to only select the type of "hit" (as choices) when making a selection, whereas the player in the field is able to select either hits or outs as choices. These input elements are described in FIG. 20 as the potential prediction play outcomes of the live play (of the at-bat) 2002 or 2010 and to which fielder the ball may be hit 2004 or 2012. In the match, both players, depending on their team being at-bat or in the field, are asked to make their selections by combining one choice from each of these two independent elements. The At-bat outcome selection matrix 1806 shows prediction outcome choices available to a player who is predicting the outcome of the current batter when the player's team is at bat. The match-play game is designed to require that the At-bat player select both a type of hit 1802 and a location for the hit 1804. In this example, the player has predicted that the current batter will hit a ground ball single through the infield as the type of hit 1802. Hit direction matrix 1804 shows the choices that the player can make for where the ground ball could be hit. In the field outcome selection matrix 1808 shows outcome choices available to the opposing player who is predicting the outcome of the current batter when the player's team is in the field. The match is designed to require that this opposing player select either a type of hit or a type of out 1810 and a location of the hit or out 1812. In this example, the player has predicted that the current batter will make an out and the type of out will be a ground out to an infielder 1810. Based on this step in the prediction of the outcome, the player may now choose a location of this ground out 1812 by identifying one of the infielder”, [0128]).
Exemplary rationales that may support a conclusion of obviousness include combining prior art elements according to known methods to yield predictable results. Here both Simon and Steir are directed to games where players compete on predicting events in a live event. To modify the Simon invention to include the defensive player prediction as taught by Steir would be to combine prior art elements according to a known method to yield a predictable result. Therefore, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the invention to add the defensive predictions of Steir to the Simon invention. To do so would expand the number of betting lines available thereby increasing the perceived entertainment value of the system.
Regarding claim 3, Simon discloses the baseball game betting service server is configured to recognize a batter batting only when any one of five batting conditions input by the user terminal is satisfied, wherein the five batting conditions include (1) a case where it is ruled safe by umpires at first base, (2) a case where it is ruled safe by umpires at second base, (3) a case where it is ruled safe by umpires at third base, (4) a case where a safe call for home run is made by umpires at home, (5) a case where base is not advanced and umpires call a player out ([0122]).
Regarding claim 7, Simon discloses A method for providing a real-time baseball betting service comprising: executing, by a user terminal, a real-time baseball game betting service platform and playing a desired baseball match video; displaying, by the user terminal, a result of a matchup between a pitcher and a batter for each inning [and at least one game event about a defensive player]; inputting, by the user terminal, preset betting points for at least one of game events related to a pitcher, batter for each inning under preset betting conditions ([0042]; [0081] & [0095]);
displaying, by the user terminal, betting results according to results of the game events related to the pitcher, the batter, and the defensive player; and when the game results are over, summing up betting points for the betting results of a user's bets on the pitcher and batter for each inning and then paying a prize or reward corresponding to summed points ([0043]; [0121] – [0125]).
Regarding claim 7, it is noted that Simon does not disclose a prediction with respect to a defensive player. Steir however, teaches a prediction with respect to a defensive player ([0128]).
Exemplary rationales that may support a conclusion of obviousness include combining prior art elements according to known methods to yield predictable results. Here both Simon and Steir are directed to games where players compete on predicting events in a live event. To modify the Simon invention to include the defensive player prediction as taught by Steir would be to combine prior art elements according to a known method to yield a predictable result. Therefore, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the invention to add the defensive predictions of Steir to the Simon invention. To do so would expand the number of betting lines available thereby increasing the perceived entertainment value of the system.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Simon (pub. no. 2003015797) in view of Huke et al. (pub. no. 20220122408).
Regarding claim 5 it is noted that Simon does not disclose providing statistics regarding matchups. Huke however, teaches providing statistics regarding matchups (“Further, embodiments may include a ticker database 130 for storing ticker elements comprised of any game scores, team or player statistics, news events, etc. Game scores may include final game scores, the current score, and the game's status, which may include the period of the game, inning, time remaining, etc. Similarly, a ticker element may be a notification that a team or player has scored or achieved another notable action during the live event 102, such as an American football player achieving a total rushing yards run record or breaking the record for the longest field goal. Team or player statistics may include all-time statistics, career statistics, current season statistics, or current game or series statistics. Examples of team statistics including a team's win-loss record against their current opponent, a team's current ranking in the current season's standings, a team's average runs scored in a game, etc. Examples of player statistics may include a pitcher's win record, earned run average, number of saves, batter's batting average, on-base percentage, number of runs batted in, number of home runs, etc. In basketball, statistics include a player's field goal percentage, career points, the average number of assists per game. In football, statistics may include passing yards, rushing yards, points scored, etc. A ticker element may also comprise news events such as a player injury, the announcement of a player's trade from their current team to a new team, or a delay in gameplay due to rain. A ticker element may additionally include details about a wager, such as a new wager available to be placed, or changes to a wager such as improved odds or the results of a wager placed by the user. The ticker database 130 may additionally store a ticker priority score calculated by the ticker prioritization module 128, which may indicate the relevance of a ticker element to a user's preferences based on their wager history and the currently available wagers. The ticker database 130 may be populated by the administrator of a wagering network 114 and may additionally be updated by a third party, such as via a sports news or statistics database or service. The ticker database 130 may further be updated by the ticker prioritization module 128 and may be used by the base wagering module 124 and the ticker prioritization module 128”, [0076];
“The base wagering module 124 may display, at step 218, the ticker elements in a ticker feed on a wagering app 110 such that the ticker is visible to the user while the user is viewing the one or more available wagers. The ticker elements may be displayed such that the ticker element with the highest ticker priority score may be displayed first, and additional ticker elements may be displayed in the descending score order, with the last ticker element displayed having the lowest priority score. All the active ticker elements may be displayed, or a maximum number of ticker elements may be predetermined, such as no more than ten ticker elements. Alternatively, only ticker elements above a threshold priority score may be displayed, such as ticker elements with a score above 5. In some embodiments, both a priority score threshold and a maximum number of ticker elements may be defined to limit the number of ticker elements displayed. When all active ticker elements may be displayed to the user, the ticker elements may repeat, such that after the last ticker element is displayed, the first ticker element may be displayed again. The ticker elements may additionally be selectable by the user, such as by double-tapping the screen of the mobile device 108 on the ticker element or via a long press. In an embodiment, first displaying a ticker element comprising the 2021 season batting average for New York Yankees player, Aaron Judge, may be 0.282. His on-base percentage may be 0.375, which may have a ticker priority score of 11 and then display the ticker element comprising the score of a baseball game between the New York Yankees and the Boston Red Sox, with the Boston Red Sox leading with a score of 5 to 3 in the bottom of the 6th inning with a ticker priority score of 9. The base wagering module 124 may determine, at step 220, whether the user selected the displayed ticker element. The user may select the ticker element by double-tapping the screen of the mobile device 108 on the ticker element or via a long press”, [0077]).
Exemplary rationales that may support a conclusion of obviousness include use of a known technique to improve similar devices (methods, or products) in the same way. Here both Simon and Huke are directed to systems where players predict the outcome of live events. To include the ticker as taught by Huke to the Simon invention 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 Simon to use the ticker of Huke. To do so would better inform the player thereby increasing the perceived entertainment value of the system.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Simon (pub. no. 2003015797) in view of Huke et al. (pub. no. 20220122408) as applied to claim 5 above, and further in view of Steir et al. (pub. no. 20130184039).
Regarding claim 6, it is noted that Simon does not disclose a prediction with respect to a defensive player. Steir however, teaches a prediction with respect to a defensive player ([0128]).
Exemplary rationales that may support a conclusion of obviousness include combining prior art elements according to known methods to yield predictable results. Here both Simon and Steir are directed to games where players compete on predicting events in a live event. To modify the Simon invention to include the defensive player prediction as taught by Steir would be to combine prior art elements according to a known method to yield a predictable result. Therefore, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the invention to add the defensive predictions of Steir to the Simon invention. To do so would expand the number of betting lines available thereby increasing the perceived entertainment value of the system.
Conclusion
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
Prosecution Insights