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 § 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-5, 9, 10, 12-14, 19 and 20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Gordon et al. (pub. no. 20150141120).
Regarding claim 1, Gordon discloses a method comprising: providing access to a plurality of versions of a particular video game application over a network (“A previously purchased product (hereinafter "PPP") is defined herein as an executable product designed to be locally rendered, processed, and presented by a particular platform. The PPP may have its own SKU and cannot be locally rendered, processed, and presented by another platform. That other platform may require a separate PPP in order to locally render, process, and present that product.
The cross platform access to the PPP can be accomplished by using a datacenter capable of locally rendering content of the PPP and distributing the rendered content for consumption by a platform other than the platform for which the PPP was designed. This advantageously enables end users to use other platforms and experience the PPP in a manner that emulates or substantially replicates the same experience the user enjoys when interacting with the PPP on its designated platform.
For example, the datacenter enhances the gaming experience for users without cannibalizing publisher sales of those games. This can be accomplished by allowing a previously purchased video game designed for use with a first platform (e.g., a personal computer) to be rendered locally at the datacenter for distribution to and consumption on a second platform, or to any other suitable number of different platforms, in return for a fee paid to the publisher or other entity. This way, the publisher collects its fee for the original intended purpose of the video game (e.g., to play the game on a personal computer) as well as for subsequent uses of that game (e.g., to play the game on a tablet, smartphone, or other platform)“, [0023] – [0025];
“FIG. 2 shows an illustrative diagram of system 200 according to an embodiment. System 200 can include datacenter 210, thin clients 212, servers 220 and 222, thick clients 224 and 226, and network 230. It is understood that the number of components shown are merely illustrative and that any suitable number of such components may comprise system 200. As shown, datacenter 210 may communicate with platforms 212, servers 220 and 222, and platforms 224 and 226 via network 230. Server 220 may communicate with thick clients 224 via network 224, and server 222 may communicate with thick clients 226. Platforms 212 may be operative to receive rendered content from database 210 and may function solely as thin clients. Platforms 224 and 226 may function as thick clients or thin clients depending on how they are presenting an product. For example, when platform 224 is receiving rendered product content from database 210, it may function as a thin client, when platform 224 is locally rendering product content, it may function as a thick client”, [0048];
“Datacenter 210 can provide several services according to various embodiments. In one embodiment, datacenter 210 can render content of products, including previously purchased products, and distribute the rendered content to one or more of platforms 212, 224, and 226 via network 230. That is, datacenter 210 may serve as the content rendering engine for any product that a user interacts with using, for example, one of platforms 212. In this context, a user may view and interact with an product (e.g., a video game) using one of platforms 212, but the computational rendering of content presented on platform 212 is performed remote to platform 212”, [0050]);
receiving a request to launch the particular video game application from a particular client device; obtaining context information relating to the request to launch the particular video game application; accessing game version information for the plurality of versions of the particular video game application (“Referring now to FIG. 3, a more detailed illustrative schematic of datacenter 210 is shown according to an embodiment. As shown, datacenter 210 can include rendering module 302, network monitoring module 304, product library 310, third party update service 315, product session module 320, translation library 330, translation module 340, and optional database 350. Each of the components can be implemented as part of one or more servers.
Rendering module 302 may be operative to render product content for distribution as rendered product content 303 based on product code 311 and translated inputs 341. As shown, rendered product content 303 is provided to network 230 for distribution to a platform (not shown) operating as a thin client. Although not specifically shown in FIG. 3, rendering module 302 may be provided with all necessary components of any product. Product code 311 and other components (not shown) can be provided by product library 310. In some embodiments, product code 311 can embody the same binary code of a PPP. Product library 310 may maintain component equivalents (e.g., including binary codes and assets) of all purchasable products, as shown by product codes 1 through N. The product codes can include different platform specific product codes for the same title. For example, product code 1 may embody the binary code of an product designed to be locally rendered on a first platform, and product code 2 may embody the binary code of an product designed to be locally rendered on a second platform, and so on”, [0053] & [0054]);
based at least on the context information and the game version information, choosing a selected version of the particular video game application to launch in response to the received request; and initiating a current streaming session of the selected version of the particular video game application, the current streaming session involving remote execution of the selected version of the particular video game application (“Rendering module 302 can render product code 311 in the same manner a platform would render the PPP. For example, if the PPP is designed to be locally generated on a first platform, rendering module 302 can render the product code as if it were the first platform. In some embodiments, rendering module 302 may be the functional equivalent to the platform for which the PPP's components were designed “, [0056];
“Translation module 340 may be operative to map received inputs 305 to translated inputs 341. Received inputs 305 may be inputs generated by and transmitted by a platform receiving rendered product content 303. Received inputs 305 can be input commands input by the user when interacting with rendered product content 303 using his platform. Because the platform being used to generate received inputs 305 may be different than the platform for which product code 311 was originally designed for, translation module 340 may be needed to map the received inputs to a format that can be recognized and used by rendering module 302. Translation module 340 may access the appropriate translation map in translation library 330 to perform the appropriate mapping.
Translation library 330 may include any suitable number of translation maps necessary to produce the appropriate translated inputs 341 for rendering module 302. In some embodiments, several translation maps may be associated with each product, where each map is able to appropriately translate the received input command from any platform to the platform designated by the product. For example, assume product 1 designates or was designed to be locally rendered on a first platform. The translation maps associated with product can map inputs from any other platform to first platform inputs”, [0058] & [0059]).
Regarding claim 2, Gordon discloses the plurality of versions including two or more of a console version of the particular video game application, a personal computer version of the particular video game application, and a mobile version of the particular video game application (There may be many instances of one particular platform, each of which is capable of locally rendering a first product, but instances of all other platforms cannot locally render that first product. For example, personal computers and laptop computers running a first operating system may represent a first platform and personal and laptop computers running a second operating system may represent a second platform. A portable device such as a tablet running a third operating system may represent a third platform, and a portable device such as a smartphone may represent a fourth platform.
Each of these four different platforms may require components (e.g., program code) specifically designed for its platform in order to locally render the product, including product having the same title. Although products/product can have the same title, each of their respective components (e.g., program code or binary code) are different. That is, their respective components are designed to work on one particular platform and no others. Product publishers address this issue by providing multiple skus of the same titled product. Product publishers address this issue by providing multiple SKUs of the same titled product. Thus, if a user wishes to play the same titled product, for example, on a first platform (e.g., personal computer) and a second platform (e.g., smartphone), that user would have to procure a first product for the first platform and procure a second product for the second platform. Procurement of products can include installing a computer readable medium (e.g., CD) that contains the program code or downloading the program code from the Internet”, [0043] & [0044]).
Regarding claim 3, Gordon discloses the context information includes client device information indicating input device capabilities of the client device ([0058] & [0059]).
Regarding claim 5, Gordon discloses the game version information conveying to support by the plurality of versions of the particular video game application for different input devices ([0058] & [0059]).
Regarding claim 9, Gordon discloses the context information includes user history information relating to previous streaming sessions by a particular user of the particular client device (“Product session module 320 may be operative to monitor, save, and/or report the state of an product session. An product session can refer to a user's start and end time of interacting with an product, and can represent all attributes of the user's advancement within an product. In some embodiments, module 320 can keep track of user's progress within an product. This is sometimes referred to as a save feature. The save data may be stored in database 350 or it may be provided to a database remote to datacenter 210, such as a database associated with server 220. In other embodiments, product session module 320 can enable a user to resume a game in a different platform. Thus, if a user ceases playing a game on a first platform, and begins playing the same game on another platform, product session module 320 can ensure that the user resumes play where he left off”, [0057]).
Regarding claim 10, Gordon discloses the user history information identifies a specific version of the video game that the user played in an immediately preceding streaming session that has completed, and the specific version is selected as the selected version for the current streaming session ([0057]).
Regarding claim 12, Gordon discloses the user history information identifies a previously-saved streaming session that the user is requesting to re-initiate in the current streaming session and a specific version of the video game that the user was playing during the previously-saved streaming session, and the specific version is selected as the selected version for the current streaming session ([0057]).
Regarding claim 13, Gordon discloses the user history information identifies a previously-saved streaming session that the user is requesting to re-initiate in the current streaming session and a specific version of the video game that the user was playing during the previously-saved streaming session, and a different version is selected as the selected version for the current streaming session in an instance when the game version information indicates that the particular video game application supports resuming the previously-saved streaming session with the different version ([0057]).
Claim 14 is directed to a system that implements the method of claim 1 and is rejected for the same reasons as claim 1.
Regarding claim 19, Gordon discloses the processing resources implement a plurality of different gaming platforms corresponding to the plurality of versions of the particular video game application ([0054]).
Claim 20 is directed to an article of manufacture that contains code that implements the method of claim 1 and is rejected for the same reasons as claim 1.
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) 6-9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gordon et al. (pub. no. 20150141120) in view of Perlman et al. (pub. no. 20090118019).
Regarding claim 6, it is noted that Gordon does not explicitly disclose context information indicating client display capabilities. Perlman however, teaches context information indicating client display capabilities (“Under the HDMI standard, the display capabilities (e.g. supported resolutions, frame rates) 464 are communicated from the display device 468, and this information is then passed back through the Internet connection 462 back to the hosting service 210 so it can stream compressed video in a format suitable for the display device”, [0121]).
Exemplary rationales that may support a conclusion of obviousness include combining prior art elements according to known methods to yield predictable results. Here both Gordon and Perlman are directed to systems that provide remote gaming. To modify Gordon to consider the display capabilities of a client device as taught by Perlman would be to combine a prior art element 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 claimed invention to incorporate the display context as taught by Perlman into the Gordon invention. To do so would allow the server to adjust resolution of the streamed content thereby maximizing bandwidth efficiency.
Regarding claim 7, Gordon discloses the game version information conveying graphical user interface characteristics of the plurality of versions of the particular video game application ([0056], [0058], [0059]).
Regarding claim 8, the combination of Gordon Perlman discloses the client device information conveys a display size of the client device (Perlman: [0121]).
Allowable Subject Matter
Claims 11 and 15-18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The Applicant is directed to the attached “Notice of References Cited” for additional relevant prior art. The Examiner respectfully requests the Applicant to fully review each reference as potentially teaching all or part of the claimed invention.
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