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 § 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(a) as being unpatentable over White (US 2021/0129017), in view of Mitkar (US 2017/0262520).
Claim 1, White teaches “causing a launch of a session associated with a gaming application”
“receiving video data corresponding to a gameplay session for a player of a game …”(White, para [0057]), “determining, during the session … that one or more portions of one or more files of the gaming application have been changed”, White does not disclose detecting changes to underlying application files or portions thereof; however, Mitkar discloses detecting changed portions of stored data using a maintained change bitmap: “the filter driver may maintain a change bitmap that indicates one or more blocks in the primary data that have changed since the most recent query” (Mitkar, paras [00305]–[00306]), “generating … a data package that includes data representative of the one or more portions of the one or more files”, White does not generate or store data packages representing changed file portions, however, Mitkar teaches aggregating changed portions into an intermediate staging area: “storing copies of the one or more blocks indicated by the change bitmap in an intermediate staging area” (Mitkar, paras [00326]–[00327]), “storing … the data package in one or more memories”, Mitkar further teaches storing accumulated changed data: “the cumulative block-level changes are stored in the intermediate staging area” (Mitkar, paras [00328]–[00329]), therefore, it would have been obvious to a person having ordinary skill in the art would have been motivated to incorporate Mitkar’s incremental change-tracking and staging mechanism into White’s session-based gaming system in order to efficiently persist changes to application data occurring during execution. Incremental tracking of changed data portions was a well-known technique to reduce storage overhead and avoid full snapshots in long-running application sessions, and its application to White’s gaming session environment represents a predictable use of prior art elements according to their established functions.
Claim 2, “determining one or more types of changes … deletion, addition, or modification”, White does not classify types of file changes, however, Mitkar distinguishes block updates and replacements: “some of the block changes may be redundant (e.g., modifying a single block more than once)”, (Mitkar, paras [00314]–[00315]), this disclosure inherently distinguishes modification and replacement, “generating the data package to further include … types of changes”, Mitkar stores change metadata associated with changed blocks: “update the block change to reflect the additional change”, (Mitkar, para [00307]), thus it would have been obvious to ordinary skilled artisan.
Claim 3, “determining one or more offsets within the one or more files”, White does not disclose offsets, Mitkar operates at block-level granularity, which inherently corresponds to offsets within a file: “the change bitmap indicates … blocks in the primary data that have changed”(Mitkar, paras [00305]–[00306]), “generating the data package to include … offsets”, Mitkar stores block-identified data in staging: “storing copies of the one or more blocks indicated by the change bitmap”, (Mitkar, paras [00326]–[00327]), White does not identify offsets or locations within files corresponding to changed portions. Mitkar tracks changes at block-level granularity, which inherently corresponds to offsets or locations within stored data, thus, a person of ordinary skill in the art would have been motivated to include offset information in the data package when adapting Mitkar’s block-based change tracking to White’s file-based gaming application, as identifying where within a file a change occurred is necessary to correctly apply incremental updates. This represents a predictable and necessary implementation detail.
Claim 4, “determining that one or more second files … have not been changed during a threshold period of time”, White does not disclose temporal change monitoring, Mitkar discloses querying change state at discrete times: “the data agent may query the filter driver at each of t0–t3”(Mitkar, para [00314]), Non-changed blocks during the interval are implicitly determined, “generating the data package is based at least on the determining”, Mitkar conditions storage on detected changes: “store any block changes in the staging area” (Mitkar, para [00314]); White does not disclose determining that certain files have not changed during a defined time period. Mitkar discloses querying a change bitmap at discrete time intervals and storing only those blocks that are indicated as changed, thus, a person of ordinary skill in the art would have been motivated to infer unchanged files or portions based on the absence of entries in Mitkar’s change bitmap during a given interval and to base generation of a data package on that determination. Using time-based thresholds to control change capture is a routine design choice in incremental backup and replication systems.
Claim 5 , “after storing the data package … determining … second portions … have been changed; generating a second data package … and storing … in association”
White does not disclose generating multiple sequential data packages corresponding to later changes, Mitkar discloses repeated querying of the change bitmap and accumulation of additional changes over time: “the data agent may query the filter driver at each of t0–t3 and store any block changes in the staging area”(Mitkar, para [00314]), therefore, it would have been obvious to a person of ordinary skill in the art would have been motivated to generate multiple data packages corresponding to successive changes during a session, as Mitkar teaches repeated incremental capture of changed portions over time. Applying this technique to White’s session-based execution allows incremental persistence of application state and represents a routine extension of known change-tracking systems.
Claim 6, “associating a first indicator … and a second indicator indicating that a loading of the second data package occurs after”
White does not disclose ordering or sequencing of data packages, however, Mitkar teaches that later changes may overwrite or replace earlier ones: “some of the block changes may be redundant (e.g., modifying a single block more than once)” (Mitkar, paras [00314]–[00315]), therefore, it would have been obvious to a person of ordinary skill in the art would have recognized that incremental change packages must be applied in sequence to correctly restore state. Incorporating ordering indicators into White’s system is a predictable and necessary implementation detail when using Mitkar’s staged change sets.
Claim 7, “determining that an event has occurred that caused the session … to terminate … applying … changes”, White discloses session-based execution but does not disclose restoration of file state, Mitkar discloses applying accumulated change data during subsequent operations:
“transmitting second change data … including cumulative block-level changes stored in the intermediate staging area”(Mitkar, paras [00330]–[00331]), thus, a person of ordinary skill in the art would have been motivated to apply stored incremental changes after session termination in order to restore application state, as Mitkar teaches use of staged changes for recovery and White discloses session relaunch in a computing environment.
Claim 8, “determining … during the second session … changes”, Mitkar discloses continued monitoring after prior operations: “query the filter driver … since the most recent query”(Mitkar, paras [00324]–[00326]), “generating and storing a second data package”, Mitkar discloses additional staged change data: “store any block changes in the staging area”(Mitkar, para [00314]); thus, would have been obvious within the ordinary skilled artisan; White does not disclose continued change tracking during a subsequent session. Mitkar discloses repeated and ongoing change detection across multiple intervals and operations, thus, a person of ordinary skill in the art would have found it obvious to continue detecting and packaging additional file changes during a second session after restoration, as Mitkar’s change tracking is not limited to a single execution period. Extending this behavior to White’s restarted gaming session is a predictable use of Mitkar’s techniques.
Claim 9, “storing … a state associated with the gaming application”, White discloses storing gameplay-related session data: “hardware and software components … memory … to perform the operations” (White, paras [0067]–[0095]), “causing a deletion of the data package”, Mitkar discloses replacement and update of staged data: “update the block change … without creating a new entry”, (Mitkar, para [00307]); White does not disclose deleting intermediate change data packages after storing a final application state; Mitkar discloses updating and replacing stored change data rather than indefinitely retaining all intermediate data, thus a person of ordinary skill in the art would have been motivated to delete incremental change packages once a final application state has been stored at session completion in order to conserve memory and storage resources. Such lifecycle management of change data is routine in data-tracking systems.
Claim 10, “determining … based on analyzing … a journal that indicates changes”
White does not disclose a file-change journal, however, Mitkar explicitly teaches maintaining a change bitmap: “the filter driver may maintain a change bitmap that indicates the block-level changes” (Mitkar, paras [00305]–[00306]), thus a person of ordinary skill in the art would have recognized that using a journal or bitmap to detect data changes is more efficient than scanning full files and would have applied Mitkar’s bitmap-based approach to White’s system.
Claim 11, “causing … a spool of a virtual machine (VM) and allocation of resources”
White discloses computing systems allocating processing and memory resources: “processors, memory, and other resources required to perform the operations”(White, paras [0067]–[0095]), “updating … a state … based on user data corresponding to a previous session”, White discloses session-based data processing across gameplay: “receiving video data corresponding to a gameplay session”(White, para [0057]); “storing the data package in association with the user data”
Mitkar stores change data associated with primary data sets: “storing copies of the … blocks … in the intermediate staging area”, (Mitkar, paras [00326]–[00327]); White discloses allocating computing resources for session execution but does not disclose associating incremental file changes with user data across sessions. Mitkar discloses storing incremental changes associated with a primary data set, thus a person of ordinary skill in the art would have been motivated to associate incremental file-change data with user data and VM-based sessions in White in order to preserve user-specific application state across sessions. This combination uses each reference according to its intended purpose.
Claim 12, “removing the first file from the first data package when the same file appears in the second” White does not disclose eliminating redundant data across stored packages, Mitkar teaches updating previously stored changes rather than duplicating them: “update the block change to reflect the additional change … without creating a new entry” (Mitkar, para [00307]), thus a person of ordinary skill in the art would have been motivated to eliminate redundancy between data packages to conserve storage and ensure correctness, as explicitly taught by Mitkar.
Claims 13–14, “Identifiers and ordering”, Mitkar identifies blocks and maintains update order: “the change bitmap indicates … blocks”, (Mitkar, paras [00305]–[00306]), “update the block change”, (Mitkar, para [00307]); White does not disclose using identifiers to correlate files across data packages. Mitkar inherently identifies blocks and tracks updates to specific data locations, thus a person of ordinary skill in the art would have found it obvious to use identifiers to determine when files in different data packages correspond to one another, as identification of data elements is necessary to perform updates and de-duplication. This represents a routine implementation detail.
Claim 15, “threshold period of time elapsing before generating data packages”
White does not disclose time-based thresholds, however, Mitkar teaches collecting changes at defined time intervals: “repeat … at each of t0–t3” (Mitkar, para [00314]), applying time-based thresholds to White’s system represents a routine design choice for controlling when incremental data is persisted; White does not disclose time-based thresholds for generating data packages. Mitkar discloses querying and capturing changes at defined time intervals, thus,a person of ordinary skill in the art would have found it obvious to use time-based thresholds in White’s gaming system to control when data packages are generated, as this balances performance and storage overhead. Time-based triggering is a well-known design choice.
Claim 16, “generating data packages based on resource usage amounts”, Mitkar explicitly teaches resource-usage-based triggering: “determine that an amount of computing resources … is less than a threshold amount” (Mitkar, paras [00330]–[00335]); Thus, a person of ordinary skill in the art would have recognized that triggering change capture based on resource usage improves system performance and predictably integrates with White’s resource-managed execution environment; White does not disclose generating data packages based on resource usage. Mitkar discloses triggering change capture based on computing resource conditions, thus, a person of ordinary skill in the art would have been motivated to generate data packages based on resource usage in White’s environment in order to optimize performance and resource allocation. Applying Mitkar’s resource-based triggers to White’s system yields predictable results.
Claim 17, “apply first and second data packages during a second session”, Mitkar teaches applying cumulative and subsequent change data during later operations: “second change data including (i) cumulative block-level changes … and (ii) changes since the most recent query”, (Mitkar, para [00330]–[00331]); White discloses allocating resources for new sessions but does not disclose applying multiple stored change sets during a second session. Mitkar discloses applying cumulative and subsequent change data during later operations, thus, a person of ordinary skill in the art would have been motivated to apply multiple stored data packages during a second gaming session in order to restore different portions of application files. This is a predictable extension of Mitkar’s incremental restore techniques when used in White’s session framework.
Claims 18–20, System environment breadth, White discloses execution in computing environments with processors and memory: “hardware and software components … processors, memory” (White, paras [0067]–[0095]),these disclosures support the enumerated system environments.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MASUD AHMED whose telephone number is (571)270-1315. The examiner can normally be reached M-F 9:00-8:30 PM PST with IFP.
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, Abby Lin can be reached at 571 270 3976. 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.
MASUD . AHMED
Primary Examiner
Art Unit 3657A
/MASUD AHMED/Primary Examiner, Art Unit 3657