Obviousness

Obviousness Analysis of US Patent 10691579 Under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the claims of US patent 10691579B2 obvious to a person having ordinary skill in the art (POSITA), along with the motivation for combining them. The analysis relies on the prior art identified within the provided patent text, specifically the familial prior art reference US 7,813,910 B1, as indicated by the "Priority claimed from US11/449,958" in the Google Patents page and the "RELATED APPLICATIONS" section of US10691579B2. The prior art date for relevant subject matter is June 10, 2005.

Primary Prior Art Reference

US 7,813,910 B1 (Poulin): This patent is a direct antecedent in the family chain of US10691579B2, with US10691579B2 being a divisional of US 14/084,321, which is a divisional of US 12/705,913, which is a continuation-in-part (CIP) of US 11/449,958 (which matured into US 7,813,910 B1). The titles are identical: "Systems including device and network simulation for mobile application development." Given this relationship, it is highly probable that US 7,813,910 B1 (hereinafter '910 patent) discloses much of the core subject matter of US10691579B2. For the purpose of this obviousness analysis, we assume the '910 patent discloses the foundational elements present in the common description of the '579 patent, up to the point where novel features might have been introduced in the CIP or subsequent applications.

Analysis of Claim 1 of US10691579B2

Claim 1 of US10691579B2 reads:
"1. A computer-implemented system for developing a frame-based application, comprising:
a non-transitory computer-readable medium having instructions stored thereon that, when executed by a processor, cause the processor to:
receive a frame-based application from an application development tool, the frame-based application for playing on a mobile device that includes an application player;
generate a mobile device model based upon characteristics of the mobile device, the characteristics defining performance of the mobile device;
play the frame-based application within the mobile device model to emulate playing of the frame-based application on the mobile device;
monitor playing of the frame-based application within the mobile device model to determine resource utilization of the frame-based application for the mobile device; and
generate a profile data display window to display the determined resource utilization of the frame-based application for the mobile device, wherein the profile data display window displays per-frame resource utilization of the frame-based application, thereby facilitating assessment of stresses applied to the mobile device when playing the frame-based application."

Elements likely disclosed by US 7,813,910 B1:

Based on the descriptive content of US10691579B2 (which largely carries over from its parent applications, including the '910 patent), the '910 patent would likely disclose the following elements of Claim 1:

1. A computer-implemented system with a non-transitory computer-readable medium and processor: This is a fundamental aspect of any software development environment.
2. Receiving a frame-based application from an application development tool for playing on a mobile device with an application player: The background of US10691579B2 explicitly discusses Flash Player applications and development tools like FlashMX. It notes that these applications are "typically developed on a personal computer (PC) or workstation and target one or more types of mobile device that include a Flash Player." [cite: "Applications for mobile devices are typically developed on a personal computer (PC) or workstation and target one or more types of mobile device that include a Flash Player."] These applications are also inherently "frame-based." [cite: "Flash applications are based upon a timeline of frames that may include graphical information and action scripts, FS Commands, network protocols, selected frame rate, etc."]
3. Generating a mobile device model based on characteristics defining performance: The '579 patent describes an "emulator 101" that "generates a mobile device model 102, based upon characteristics 115 of mobile device 114." [cite: "Emulator 101 generates a mobile device model 102 , based upon characteristics 115 of mobile device 114 ."] It further details these characteristics (e.g., processor type, speed, RAM size, availability) in Table 1. [cite: "TABLE 1 Mobile Device Characteristics', shows exemplary characteristics that may be used to specify hardware attributes and performance of model 102 to emulate mobile device 114 ."]
4. Playing the frame-based application within the mobile device model to emulate playing on the mobile device: This is a core function of the system, where the "model 102 emulates mobile device 114 to play frame-based application 104." [cite: "Model 102 emulates mobile device 114 to play frame-based application 104 ."]
5. Monitoring playing within the model to determine resource utilization: A "profiler 106 monitors playing of frame-based application 104 within model 102 to estimate resource usage of application 104." [cite: "Profiler 106 monitors playing of frame-based application 104 within model 102 to estimate resource usage of application 104 ."] The patent describes various profile modules for processor, memory, and graphic utilization. [cite: "Processor profile module 202 may, for example, estimate processor utilization of application 104 within model 102 .", "Memory profile module 204 may, for example, estimate memory utilization by application 104 within model 102 .", "Graphic profile module 206 may, for example, estimate utilization of 30 fill rate and 30 polygon count of application 104 within model 102 ."]
6. Generating a profile data display window to display the determined resource utilization: "Profiler 106... generates a profile data display window 110." [cite: "Profiler 106 monitors playing of frame-based application 104 within model 102 to estimate resource usage of application 104 and generates a profile data display window 110 ."]

Obviousness of "per-frame resource utilization"

The distinguishing feature of Claim 1, beyond the general emulation and profiling, is "wherein the profile data display window displays per-frame resource utilization of the frame-based application, thereby facilitating assessment of stresses applied to the mobile device when playing the frame-based application."

Even if the '910 patent did not explicitly use the term "per-frame" in its claims or summary, the detailed description of US10691579B2 strongly suggests this was a natural and obvious implementation for debugging frame-based applications.

Motivation to Combine/Modify US 7,813,910 B1:

A Person Having Ordinary Skill in the Art (POSITA) in mobile application development and debugging, familiar with the '910 patent (or its underlying application), would have been motivated to modify the general resource utilization display to show "per-frame resource utilization" for the following reasons:

1. Nature of Frame-Based Applications: Mobile applications, particularly those utilizing platforms like Flash Lite, are explicitly described as "based upon a timeline of frames that may include graphical information and action scripts." [cite: "Flash applications are based upon a timeline of frames that may include graphical information and action scripts, FS Commands, network protocols, selected frame rate, etc."] Resource demands in such applications often vary significantly from one frame to the next due to complex animations, data loading, or script execution within specific frames. [cite: "each frame of frames 223 includes multiple graphic elements and/or action scripts that involve image manipulation (e.g., retrieving data from non-volatile storage, avatar manipulations, animations, etc.), each frame may require differing resources in order to display correctly."].
2. Problem to be Solved: The background section highlights the significant problem of identifying and correcting system resource problems, which often requires "transfer[ring] and play[ing] the application hundreds of times... before identifying and correcting all system resource problems." [cite: "During development of an application for a mobile device, an application author may transfer and play the application hundreds of times (development life cycles) on the targeted mobile device before identifying and correcting all system resource problems within the application."]. A general display of resource utilization without frame correlation would make this diagnostic process much harder.
3. Enhancing Diagnostic Utility: Presenting resource utilization data per-frame directly addresses the problem of pinpointing resource bottlenecks. A POSITA would readily understand that correlating resource consumption directly with the corresponding frames on a timeline (as shown in FIG. 3 with "time line 302" and "each bar 304 indicates processor resource utilization for each of certain frames 223" [cite: "FIG. 3 shows one exemplary profile data display window 110 showing a frame-based display of profiled data 152 , FIG. 1B , determined by processor profile module 202 .", "profile window 110 is shown with a time line 302 that represents timeline 222 of application 104 .", "each bar 304 indicates processor resource utilization for each of certain frames 223 of application 104 ."]) provides invaluable, granular feedback for developers. This allows them to precisely identify which frames are causing over-utilization and potential application crashes, leading to efficient debugging and optimization.
4. Predictable Result: Modifying a display of profiled data for a frame-based application to show per-frame usage is a logical and predictable design choice aimed at improving the clarity and actionability of the diagnostic information. It is a straightforward application of profiling techniques to the inherent structure of the application being analyzed.

Therefore, a POSITA, seeking to create a more effective debugging tool for frame-based mobile applications building upon the general emulation and profiling system described in the '910 patent, would have been motivated to display resource utilization on a per-frame basis to better diagnose and resolve performance issues. This modification would have been obvious in light of the '910 patent and the common general knowledge in the field of software development and debugging for mobile platforms.