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 – 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Step 1: It must be determined whether the invention falls in one of the four statutory categories of invention. Claims 1 – 6 and 13 – 17 are directed towards a method, (process), and claims 7 – 12 and 18 -20 are directed towards a system, (machine), which are statutory categories of invention.
Step 2a:
Prong 1: It must be determined whether the invention is directed to judicially recognized exception. Claim 1 is analyzed below with limitations indicating recitations of an abstract idea.
A method of managing a change in an active object in a game space of a multi-player video game based on an interaction of a player with the active object, wherein the multi-player video game is hosted by at least one server and is configured to be at least partially executed on a client device controlled by the player, wherein the at least one server is configured to execute a server-side module, and wherein the client device is configured to execute a client-side module, the method comprising: acquiring, by the server-side module, data indicative of the player’s interaction with the active object during a gameplay session of the multi-player video game; determining, by the server-side module, data indicative of a first state of the active object and data indicative of a first attribute associated with the first state; determining, by the server-side module, altered state data indicative of a second state of the active object, wherein a second attribute is associated with the second state; sending, by the server-side module, said altered state data to the player’s client device; determining, concurrently and independently by both the server-side module and the client-side module, evolved object data indicative of a change from the first attribute to the second attribute; and rendering, by the client-side module, the active object in the second state and the second attribute using said evolved object data.
The abstract idea is defined by the underlined portions exemplary claim 1, with substantially similar features found in claims 7, 13, and 18. Dependent claims 2 – 6, 8 – 11, 14 – 17, 19, and 20 further define the abstract idea or relate to the implementation of the abstract idea. The abstract idea is defined in at least the following grouping below:
Mental processes (observation, evaluation, judgment)
The claims are directed towards an abstract idea of rules for conducting a game which falls into the category of mental processes, (See MPEP 2106.04(a)(2)(III)). More specifically, the claimed invention recites a gaming system that executes a multiplayer video game where players manages an object of the game in order to progress through the game. The claimed invention can be practically performed as mental process by a human managing game objects in a multiplayer game. A human make control the game object and make game determinations in their mind.
The claims are also directed towards a series of steps which can practically be performed by one or more human, which fall into the category of mental processes, (See MPEP 2106.04(a)(2)(III)). More specifically, the claimed invention recites a multiplayer video game, wherein the claims disclose acquiring and determining data with respect to a player’s interaction with a game object, wherein the claims further disclose that the server and the client determine the evolved object data. The claims recite instructions for controlling a game with these features. Here, a human can observe an interaction with a game object, the state of the game object, an attribute of the game object, and an altered state of the game object. A human can then determine that the state and attribute data of the game object will be changed based on the altering of the game object, wherein a human can then make a game determination of a next step to further progress that is favorably for the player.
Prong 2: Does the Claim recite additional elements that integrate the exception in to a practical application of the exception?
The claims recite a generic server along with instructions that hosts and present a multiplayer game to a player and determine a state of a game object, which is viewed as no more than instructions to implement a judicial exception.
These additional limitations do not represent an improvement to the functioning of a computer, or to any other technology or technical field, (MPEP 2106.05(a)). Nor do they apply the exception using a particular machine, (MPEP 2106.05(b)). Furthermore, they do not effect a transformation. (MPEP 2106.05(c)). Rather, these additional limitations amount to an instruction to “apply” the judicial exception using a computer as a tool to perform the abstract idea.
Step 2b: It must be determined whether the claimed invention recites additional elements that amount to significantly more than the judicial exception.
The claim language does recite a server, a client device, and a game object associated with a player however, viewed as a whole, these additional elements are indistinguishable from conventional computing elements known in the art, (See Xie 2014/0141876 regarding a client server system processing data generated by interactions between objects as being conventional). Therefore, the additional elements fail to supply additional elements that yield significantly more than the underlying abstract idea. Viewing the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 – 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 - 16 of U.S. Patent No. 12,097,430.
Although the claims at issue are not identical, they are not patentably distinct from each other because the current claims are drawn towards the system and method claim versions of the parent 12,097,430, except the current claims manage an active object, while the parent claims manage a scriptable object and generating a seed, wherein the seed is randomly generated vector. Therefore the current claims are a broader version of the parent claims regarding this feature, as shown in table below. Independent claim 7, 13, and 18 includes similar language to that of independent claim 1, wherein dependent claims 2 – 6, 8 – 11, 14 – 17, 19, and 20 include identical language as the dependent claims in the parent 12,097,430. Therefore the claims are not patentably distinct.
Pending Claim 1:
Patented Claim 1:
1. A method of managing a change in an active object in a game space of a multi-player video game based on an interaction of a player with the active object, wherein the multi-player video game is hosted by at least one server and is configured to be at least partially executed on a client device controlled by the player, wherein the at least one server is configured to execute a server-side module, and wherein the client device is configured to execute a client-side module, the method comprising: acquiring, by the server-side module, data indicative of the player’s interaction with the active object during a gameplay session of the multi-player video game; determining, by the server-side module, data indicative of a first state of the active object and data indicative of a first attribute associated with the first state; determining, by the server-side module, altered state data indicative of a second state of the active object, wherein a second attribute is associated with the second state; sending, by the server-side module, said altered state data to the player’s client device; determining, concurrently and independently by both the server-side module and the client-side module, evolved object data indicative of a change from the first attribute to the second attribute; and rendering, by the client-side module, the active object in the second state and the second attribute using said evolved object data.
1. A method of managing a scriptable object in a game space of a multi- player video game based on interactions of a player with the scriptable object via a client-side device, wherein the multi-player video game is hosted by at least one server, wherein the at least one server is configured to execute a server-side module and wherein the client-side device is configured to execute a client-side module, the method comprising: generating, in the server-side module, a seed and transmitting the seed to the client-side module, wherein the seed is a randomly generated alphanumeric vector of 'n' bits and wherein the scriptable object is spawned in the multi-player video game based on said seed; acquiring, by the server-side module and by the client-side module, data indicative of the player's interaction with the scriptable object during a game session of the multi-player video game, wherein the scriptable object comprises a first portion tracked by the server-side module and a second portion tracked by the client-side module; determining, by the server-side module, data indicative of an initial state of the first portion and, by the client-side module, data indicative of an initial state of the second portion; determining, by the server-side module, first altered state data indicative of a next state of the first portion and, by the client-side module, second altered state data indicative of a next state of the second portion; determining, by the server-side module, first evolved object data of the first portion and, by the client-side module, second evolved object data of the second portion; and rendering, by the client-side module, an updated scriptable object based on the first evolved object data and the second evolved object data.
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.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Karashima (U.S. 2018/0214775) in view of Justice et al. (U.S. 2014/0267429).
Regarding claims 1, 7, 13, and 18, Karashima discloses a method and system of managing a change in an active object in a game space of a video game based on an interaction of a player with the active object, (“One or more embodiments of the present invention provide a game execution component that controls the progress of the game by referring to the attribute values of characters, a first evolution component that changes the attribute value of a first character”, par. 0007, wherein the Examiner views the first character as being equivalent to an active object and changing the attribute level of the first character as being equivalent to managing a change in an active object). Karashima further discloses that managing the change is based on an interaction of a player with the active object, (“One or more embodiments of the present invention enhance the strategy of a game by leaving it up to the player to select how game characters will evolve”, wherein the Examiner views a player selecting how the game character will evolve as being equivalent managing a change based off the active object based on an interaction between the player and the active object). Karashima further discloses that the video game is hosted by at least one server and is configured to be at least partially executed on a client device controlled by the player, (“The game server 102 provides the game to each of the game terminals”, par. 0028 and fig. 2, parts 102 and 104, wherein the client device is configured to execute a client-side module, (“The game terminals 104 each include a user interface”, par. 0033 and fig.2, part 104, and “the player selects up to four execution characters from among his characters displayed on the screen of the game terminal 104”, wherein the Examiner views the player game terminal to select game characters displayed on the screen of the game terminal as being equivalent to a client device executing a client side module). Karashima further discloses acquiring, by the server side module, data indicative of the player’s interaction with the active object during a gameplay session of the video game, (“The user interface 122 also detects various inputs made by the player, and the data processor 126 sends the game server 102 the inputted information via the communication component 124. The data processor 107, and particularly the game execution component 112, controls the progress of the game according to this inputted information”, par. 0034 and “the player fosters the character 130 while increasing the level of the basic skill 132 and at the same time deciding whether to prioritize the unlocking of optional skills 134 or to prioritize increasing the level of the already-unlocked optional skills 134. In other words, the player not only selects between fusion evolution and evolution over time, but also selects whether the basic skill 132 or the optional skills 134 will be what evolves”, par. 0039, wherein the Examiner views the user interface detecting inputs made by the player that is then sent to the game server and the player selecting which skills of the of the player are to be evolved as being equivalent a server acquiring a player’s interaction with the active object during a gameplay session). Karashima further discloses determining, by the server side module, data indicative of a first state of the active object and data indicative of a first attribute associated with the first state, (“In the initial state, the level of the basic skill 132 is set to 1”, par. 0037), determining, by the server side module, altered state data indicative of a second state of the active object, wherein a second attribute is associated with the second state, (“the player designates either the basic skill 132 or the unlocked optional skills 134 as what is to evolve. When the basic skill 132 of level 1 is designated and the evolution is successful, the level of the basic skill 132 is increased from 1 to 2”, par. 0038), sending, by the server side module, (“The communication component 124 acquires various kinds of game information from the game server 102”, par. 034,), said altered state data to the player’s client device, (“the data storage component 108 manages the players with player IDs, and stores information indicating the play state of the players. For example, information about which characters each player owns is also stored in the data storage component 108 as play state information”, par. 0031 and “In fusion evolution or evolution over time, the player designates either the basic skill 132 or the unlocked optional skills 134 as what is to evolve. When the basic skill 132 of level 1 is designated and the evolution is successful, the level of the basic skill 132 is increased from 1 to 2”, par. 0038, wherein the Examiner views the basic skill being increased from 1 to 2 as being equivalent to altered state data and Karashima’s teaching that the data storage component of the game server, (parts 102 and 108 of fig. 2), stores play state information, is viewed by the Examiner as altered state data being stored in a data storage component of the game server, along with, as cited above, the communication component receiving game information from the game server, (parts 102, 110, and 124 of fig. 2), as being equivalent to a server side, (part 102), module sending data to a player’s client device, (part 104), altered state data to the player’s client device).
Karashima discloses, as cited above, a video game and displaying the active object in the second state and the second attribute, (fig. 3, parts 130, 132, and 134), however, Karashima is silent on disclosing a multiplayer video game, rendering game objects, and server and client devices concurrently and independently determining changed object data. In a related art, Justice discloses a method of managing active objects in a game space based on an interaction of a player with the active object, (“Games may have a virtual world in which the players' avatars or characters interact”, par. 0024), in a multiplayer video game, (“In a remote multiplayer setting where other players are connected via a network”, par. 0079), wherein Justice further discloses rendering game objects, (“The client-rendering component 624 generates a client-rendered video game image that is different than the server-rendered video game image generated based on the same or similar signals. Generally, the client rendering component 624 generates images of a particular game feature related to a player's interactions with a game object”, par. 0110, wherein the Examiner views Justice’s rendering teachings combined with Karashima as meeting at least the claim limitation of rendering the active object in the second state and the second attribute using evolved data). Justice also discloses determining, concurrently and independently, by both the server and client modules, evolved object data, (“Additionally, the game code and game state may be managed and manipulated on the server. However, portions of the final image shown to the user may be rendered on the client. For example, various targeting functions may be rendered on the client and composited with the server rendered image to generate a final image that is shown to the user. Thus, portions of the game code may be executed on a client and some images may be rendered on the client and combined with images rendered by the server”, par. 0130, wherein the Examiner views the targeting functions being rendered on the client and composited with the server rendered image to generate a final image, as being equivalent to determining, concurrently and independently, by both the server and client modules, evolved object data, combined with Karashima as meeting the claim limitation of Justice also discloses determining, concurrently and independently, by both the server and client modules, evolved object data indicative of a change from a first attribute to a second attribute).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to combine the multiplayer and rendering teachings of Justice into the art disclosed by Karashima in order to boost social connection, competitiveness, and player retention, (multiplayer), to create emotional connections and to immerse players into the virtual world, (rendering), and to hide network delay which gives players a smooth, real-time gaming experience, (concurrent and independent processing of game data).
Regarding claims 2 and 8, Karashima discloses comprising associating, by the server-side module, a plurality of states with the active object, wherein each of said plurality of states comprises at least one attribute, (“When the basic skill 132 of level 1 is designated and the evolution is successful, the level of the basic skill 132 is increased from 1 to 2. When the level of the basic skill 132 goes from 2 to 3”, par. 0038, wherein the Examiner views the basic skill going from 1 to 2 then to 3 as being equivalent to a plurality of states).
Regarding claims 3, 9, and 15, Karashima discloses determining the altered state data based on the player’s interaction with the active object, (“When the level of the basic skill 132 goes from 2 to 3”, par. 0038).
Regarding claims 4, 10, and 16, Karashima discloses wherein the evolved object data is representative of a change in at least one of a behavioral, visual or functional characteristic of the active object, (“When the level of the basic skill 132 goes from 2 to 3, the tool skill is unlocked”, par. 0038, wherein the Examiner views basic skill 3 unlocking the tool skill as being equivalent to a functional characteristic).
Regarding claims 5 and 11, Karashima, as cited above, discloses sending, by the server-side module, the altered state data to a client-side module of a client device, (“the data storage component 108 manages the players with player IDs, and stores information indicating the play state of the players. For example, information about which characters each player owns is also stored in the data storage component 108 as play state information”, par. 0031 and “In fusion evolution or evolution over time, the player designates either the basic skill 132 or the unlocked optional skills 134 as what is to evolve. When the basic skill 132 of level 1 is designated and the evolution is successful, the level of the basic skill 132 is increased from 1 to 2”, par. 0038, wherein the Examiner views the basic skill being increased from 1 to 2 as being equivalent to altered state data and Karashima’s teaching that the data storage component of the game server, (parts 102 and 108 of fig. 2), stores play state information, is viewed by the Examiner as altered state data being stored in a data storage component of the game server, along with, as cited above, the communication component receiving game information from the game server, (parts 102, 110, and 124 of fig. 2), as being equivalent to a server side, (part 102), module sending data to a player’s client device, (part 104), altered state data to the player’s client device), however, as stated above, Karashima is silent on disclosing a multiplayer game and rendering objects, however, Justice discloses a multiplayer game and rendering game objects, (“The client-rendering component 624 generates a client-rendered video game image that is different than the server-rendered video game image generated based on the same or similar signals. Generally, the client rendering component 624 generates images of a particular game feature related to a player's interactions with a game object”, par. 0110, wherein the Examiner views Justice’s rendering teachings combined with Karashima as meeting at least the claim limitation of rendering the active object in the second state and the second attribute using evolved data), wherein in combination with Karashima, discloses the limitation of sending, by the server-side module, the altered state data to a client-side module of a client device controlled by a second player; determining, by the client-side module on the second player’s client device, said evolved object data; and rendering, by the client-side module on the second player’s client device, the active object on the second player’s client device using said evolved object data.
Therefore, it would have been obvious to one of ordinary skill to combine the multiplayer and rendering teachings of Justice in order to boost social connection, competitiveness, and player retention and to create emotional connections and to immerse players into the virtual world.
Regarding claims 6 and 12, Karashima, as stated above, is silent on disclosing a multiplayer video game, however, Justice discloses a location of a virtual character controlled by the second player is proximal to a location of the active object within the game space, (“Where multiple players are located in view of the control input device, multiple avatars or game features directly linked to the multiple players may be client rendered”, par. 0040).
Therefore, it would have been obvious to one would be motivated to combine the multiplayer teachings of Justice in order to boost social connection competitiveness, and player retention.
Regarding claims 14 and 19, Karashima, as stated above, is silent on rendering, however, Justice discloses rendering the active object only if the one of the one or more players is located proximate to the active object in the game space, (“For example, an avatar that moves in response to user actions captured in the three-dimensional image data may be rendered on the client while the rest of the video game image is rendered on the server”, par. 0040).
Therefore, it would have been to one of ordinary skill to combine the rendering teachings of Justice in order to create emotional connections and to immerse players into the virtual world.
Regarding claims 17 and 20, Karashima discloses wherein the first state of the active object and second state of the active object are controlled by the client-side module, (“One or more embodiments of the present invention enhance the strategy of a game by leaving it up to the player to select how game characters will evolve”, par. 0010).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC M THOMAS whose telephone number is (571)272-1699. The examiner can normally be reached 9:00am - 5:00pm.
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.
/E.M.T/ Examiner, Art Unit 3715
/JUSTIN L MYHR/ Primary Examiner, Art Unit 3715
Prosecution Insights