Prosecution Insights
Last updated: April 19, 2026
Application No. 18/670,940

SYSTEMS AND METHODS FOR DESCRIBING, SIMULATING AND OPTIMIZING SPACEBORNE SYSTEMS AND MISSIONS

Non-Final OA §103
Filed
May 22, 2024
Examiner
MAPAR, BIJAN
Art Unit
2189
Tech Center
2100 — Computer Architecture & Software
Assignee
Loft Orbital Technologies S A S
OA Round
7 (Non-Final)
67%
Grant Probability
Favorable
7-8
OA Rounds
3y 6m
To Grant
96%
With Interview

Examiner Intelligence

Grants 67% — above average
67%
Career Allow Rate
317 granted / 470 resolved
+12.4% vs TC avg
Strong +29% interview lift
Without
With
+29.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 6m
Avg Prosecution
23 currently pending
Career history
493
Total Applications
across all art units

Statute-Specific Performance

§101
31.1%
-8.9% vs TC avg
§103
39.8%
-0.2% vs TC avg
§102
10.4%
-29.6% vs TC avg
§112
11.7%
-28.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 470 resolved cases

Office Action

§103
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 . Continued Examination Under 37 CFR 1.114 A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/24/2026 has been entered. Response to Arguments Applicant’s amendments have overcome the prior grounds of rejection. As noted by applicant, the aggregate resource features now claimed are not explicitly disclosed by the cited references. They are, however, rendered obvious by the newly cited Jian (Jian, L., & Cheng, W. (2008, June). Resource planning and scheduling of payload for satellite with genetic particles swarm optimization. In 2008 IEEE congress on evolutionary computation (IEEE world congress on computational intelligence) (pp. 199-203). IEEE.) reference, when taken in combination with the prior cited references. The new grounds of rejection are presented in full below. 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. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Rutschman (US 20180239948 A1) in view of Araguz (Araguz, C., Marí, M., Bou-Balust, E., Alarcon, E., & Selva, D. (2018). Design guidelines for general-purpose payload-oriented nanosatellite software architectures. Journal of aerospace information systems, 15(3), 107-119.), Gadepalli (Gadepalli, P. K., Peach, G., Parmer, G., Espy, J., & Day, Z. (2019, April). Chaos: a system for criticality-aware, multi-core coordination. In 2019 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS) (pp. 77-89). IEEE.), and Jian (Jian, L., & Cheng, W. (2008, June). Resource planning and scheduling of payload for satellite with genetic particles swarm optimization. In 2008 IEEE congress on evolutionary computation (IEEE world congress on computational intelligence) (pp. 199-203). IEEE.). Regarding Claim 1: Rutschman teaches: a satellite bus; (¶28 The satellite imaging system 100 is mounted to at least one satellite bus 106.) one or more satellite systems communicatively coupled to the satellite bus, each configured to perform one or more satellite functionalities; (¶175 Note that the satellite bus of satellite 500 can include subsystems including command and data handling, communications system, electrical power, propulsion, thermal control, altitude control, guidance navigation and control, or related subsystems.) one or more software satellite payloads, each configured to perform one or more payload missions; and (¶69 The vision platform hardware pipeline of the image processors 504 and 504N can include ISP to convert camera bit depth, exposure, and white balance; ¶69 Software frameworks utilized by the image processors 504 can include any of OPENGL, OPEN CL, FASTCV, OPENCV, OPENVX, and/or TENSORFLOW. The image processors 504 and 504N can be tightly coupled and/or in close proximity to the respective image sensors 508N and/or the hub processor 502 for high speed data communication connections; ¶172 Interfaces of the TT&C 1706 include one or more of ... payload) an interface hub communicatively coupled between the satellite bus and the one or more software satellite payloads, the interface hub comprising a hardware processor and a non-transitory computer-readable storage medium storing executable instructions that, when executed by the hardware processor, cause the interface hub to: provide an interface to the one or more software satellite payloads (¶32 The satellite imaging system 100 can capture hundreds of gigabytes per second of image data (e.g., using an array of sensors each capturing approximately twenty megapixels of imagery at twenty frames per second). The image data is processed onboard the satellete imaging system 100 through use of up to forty, fifty, sixty, or more processors.) receive one or more commands from a hardware satellite payload to control operation of a set of the satellite hardware systems, (¶132 Updated tracking information from the image processor 504N can be provided as ongoing feedback to the image processor 504N1 to control movement of the third imaging unit 104 and the spot field of view 408.; ¶137 he hub processing unit 502 can provide actuation signals directly or indirectly to the gimbal 110 of the third imaging unit 104 to control alignment of the field of view 408. Alternatively, the hub processing unit 502 can provide varying levels of instruction to a control unit of the gimbal 110 (or an independent actuation control unit) to direct alignment of the field of view 408.) and cause the set of satellite hardware systems to perform one or more functionalities of the set of satellite hardware systems based on the one or more commands. (¶132 Hub processor 502 can then control image processor 504N1 to hone the third imaging unit 104 and the spot field of view 408 on the ballistic missile.; ¶143 can be controlled to track the particular cityscape as it moves beyond the field of view; ¶215 The processor 504N can further render weather predictions based on one or more models local to the satellite 500 and transmit any of the determined information, weather predictions, or portions of the infrared or visible imagery to one or more recipients) Rutschman does not teach in particular, but Araguz teaches: and a standardized command set that can be used to control each of the software satellite payloads; (p.112, Robust communications: Exchanging information between two entities is often critical. Processes and modules may communicate to send system commands and their responses, system variables, or sensitive data (e.g., subsystem configuration parameters) ... In order to prevent unreliable delivery of digital data, the communication protocols should implement error detection and correction (EDAC) techniques.; p.113, Although the adoption of industrial standards is always the preferred alternative, their complexity and lack of knowledge can be an obstacle to many educational nanosatellite programs. Nonetheless, simpler alternatives like the ones suggested by NASA Jet Propulsion Laboratory for Reliable Software in [34] can be applied with less effort and are highly recommended.; p.117, System Data Bus ... set of commands) provide an application programming interface (API) for each of the set of satellite systems to the one or more hardware satellite payloads; (p.114, design intermodule interfaces that are insensitive to the anticipated changes, preventing the changeable aspects to be revealed by the interface.; p.114, The interface is defined as a set of functions that can be invoked by other modules in the architecture and that modify the internal state of the component (Fig.5). Four basic functions are defined, namely, check(), init(), run(), and halt(). Their implementations should account for the functionality described in Table 1. This basic API, which has some resemblance with Linux drivers management, allows the system to start and stop modules in a controlled manner.; p.114, With this minimal, generic interface encapsulating routines that are close to the payload and subsystem hardware, changeable modules can be integrated seamlessly in an architecture. Provided that the interface is kept the same, replacing low-level components should be transparent to higher-level components and should provide the required flexibility in future nanosatellite generations.; p.117, connected is the System Data Bus(SDB). This layer acts as a command forwarder, delivering requests and replies from any module connected to it) restrict access to one or more of the set of satellite systems based on permissions assigned to a tenant associated with the software satellite payload, (p.117, the SDB protocol defines restricted commands that are only available to some modules (e.g., low-level modules cannot request dc/dc converters to be enabled because this action is strictly solely restricted for the procman, but all modules can request sensor measurements).) route the received one or more commands to the set of satellite systems via the corresponding APIs for the satellite systems, (p.114, design intermodule interfaces that are insensitive to the anticipated changes, preventing the changeable aspects to be revealed by the interface.; p.114, The interface is defined as a set of functions that can be invoked by other modules in the architecture and that modify the internal state of the component (Fig.5). Four basic functions are defined, namely, check(), init(), run(), and halt(). Their implementations should account for the functionality described in Table 1. This basic API, which has some resemblance with Linux drivers management, allows the system to start and stop modules in a controlled manner.; p.114, With this minimal, generic interface encapsulating routines that are close to the payload and subsystem hardware, changeable modules can be integrated seamlessly in an architecture. Provided that the interface is kept the same, replacing low-level components should be transparent to higher-level components and should provide the required flexibility in future nanosatellite generations.) It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the interface features of Araguz to the satellite system of Rutschman, in order to allow changeable modules to be integrated seamlessly in the system architecture (Araguz p.114). Rutschman in view of Araguz does not teach in particular, but Gadepalli teaches: validate that an execution of the first received command by a first satellite system will not consume satellite resources that constrains an execution of a second received command by a second satellite system, (Abstract, This paper presents the Chaos system that uses devirtualization to extract high-criticality tasks from shared software environments, thus alleviating interference, and runs them in a minimal runtime; Section II.B., Chaos enables the devirtualization of tasks of criticalities that are not compatible with the assurance levels of the subsystems they are dependent on. ... These proxies insulate the high-criticality tasks from shared memory and IPI overheads within the low-assurance subsystem while routing requests for functionality to that subsystem. The safety controller sees the same functionality as it did in cFS, but avoids low-assurance subsystem interference. cFS subsystem sees the proxy as the safety controller.; Section IV.A., A capability is an unforgeable token that conveys access to a system resource, ownership of which provides the ability to perform specific operations on that resource ... All system resources are protected and referenced via capability-based access control [34] – which enables strong isolation via confinement) validate that a configuration of the one or more satellite systems can continue to operate within defined constraints as additional software satellite payloads are added, (The above described features enforce operation within constraints (e.g. by "insulat[ing] the high criticality tasks from shared memory") in the combination of references, and therefore render the claim language obvious as described below. See Gadepalli Section IV.A., "Capability-based isolation, and a fine-grained system decomposition enable the strict isolation required by the constraints in §III." which shows that the isolation of the system ensures that it meets the section III constraints. See also Gadepalli's section at the end of p.80 and the note in ¶1 of p.81, "Chaos requires that the underlying kernel that provides the virtualization and execution contexts not, itself, suffer from the shared memory and IPI interference problems demonstrated in §II." Gadepalli validates that it can operate within constraints by insulating high criticality tasks from these problems - the validation is accomplished by the architecture's implementation. Taken in combination with the following feature of Araguz detailed on p.114, the system resulting from the combination of references ensures operation within the constraints of Gadepalli as discussed above when changeable modules of Araguz are integrated, i.e. added (Araguz p.114, "With this minimal, generic interface encapsulating routines that are close to the payload and subsystem hardware, changeable modules can be integrated seamlessly in an architecture. Provided that the interface is kept the same, replacing low-level components should be transparent to higher-level components and should provide the required flexibility in future nanosatellite generations."). The validation is accomplished by the above cited requirement that the kernel not suffer from the shared memory and IPI interference problems (fulfilled by the system insulating it from shared memory). As a final note, see also Gadepalli section V., on p.85, "the ability of ChaosRT to provide strong predictability guarantees to high-criticality safety controller and the real-time cFS subsystem in the presense of IPI interference from a low-assurance subsystem." - the ability to provide the mentioned "predictability guarantee" is equivalent to a validation that the system can meet timing constraints.) It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the criticality aware, multi-core controller of Gadepalli to the satellite software of Rutschman as modified by Araguz, in order to provide high resources utilization (Gadepalli, section I) while maintaining the verification guarantees of the system (Gadepalli, section II.A.). Rutschman in view of Araguz and Gadepalli does not teach in particular, but Jian teaches: validate ... by simulating, prior to instantiating the additional software satellite payloads, an aggregate resource usage of the one or more satellite systems and the additional software satellite payloads and determining that the simulated aggregate resource usage remains below satellite system constraints; and (Section III.B., GPSO and PSO with 30 particles and 400 iteration steps have been implemented to a simulative earth observing satellite equipped with 6 payloads ... The planning and scheduling period is divided into 3 state intervals, in which the satellite will cover the 1st area, the 2nd area and the 1starea in turn. In the second interval, the satellite will send data to the ground station with costing some power. In the 3rd interval, the downlink will release the power, and the available memory will increase because of the data transmission in the former interval.; Tables I-II.; Section III.B. payload 1 is active in all the intervals at the same time payload 2 is inactive, which means payload 1 will collect redundant data from the 1st area but payload 2 will collect no data from any area, while in the cases with the worth adjust function, payload 1 and payload 2 will collect the data from the 1st area once and only once. ... payload 3 and payload 6 are inactive because of the shortness of power ... payload 6 is inactive to satisfy the of satellite pose constraint) It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply validation simulation and resource allocation handling of Jian to the satellite software of Rutschman as modified by Araguz and Gadepalli, in order to provide a proactive planning and scheduling strategy based on the availability of consumable and replenishable resources (Jian, Abstract). Regarding Claim 2, Rutschman teaches: satellite hardware provided by a manufacturer or owner of the satellite system. (See Fig. 1 illustrating the satellite including satellite hardware that one of ordinary skill in the art would recognize as provided by the manufacturer/owner of the satellite; ¶72 The wireless communication interface 506 can include a satellite radio communication link ) Regarding Claim 3, Rutschman teaches: a hardware payload provided by either an owner of the satellite system or a third party. (¶69 The vision platform hardware pipeline of the image processors 504 and 504N can include ISP to convert camera bit depth, exposure, and white balance; DSP for image pyramid generation, background subtraction, and object segmentation; GPU for optical flow) Regarding Claim 4, Rutschman teaches: a communication hardware system. (¶72 The wireless communication interface 506 can include a satellite radio communication link ) Regarding Claim 5, Rutschman teaches: wherein the one or more commands from the software satellite payload configure the communication hardware system to send one or more communications via the communication hardware system. (¶74 hosting local applications for analyzing and reporting on pre or non-transmitted high resolution imagery; ¶121 obtaining image data responsive to the request, generating binary or text data responsive to the request, initiating responsive processes or actions based on image or binary or text data, and/or transmitting communication data responsive to the request) Regarding Claim 6, Rutschman teaches: a satellite movement hardware system. (¶172 satellite bus of satellite 500 can include subsystems including command and data handling, communications system, electrical power, propulsion, thermal control, altitude control, guidance navigation and control,) Regarding Claim 7, Rutschman teaches: configure the satellite movement hardware system to change an orientation, rotation, or position of the satellite system. (¶172 satellite bus of satellite 500 can include subsystems including command and data handling, communications system, electrical power, propulsion, thermal control, altitude control, guidance navigation and control; examiner notes that altitude control is position change) Regarding Claim 8, Rutschman teaches: wherein the one or more satellite systems includes a propulsion system. (¶172 satellite bus of satellite 500 can include subsystems including … propulsion) Regarding Claim 9, Rutschman teaches: configure the propulsion system to change an orbit, altitude, or location of the satellite system. (¶172 satellite bus of satellite 500 can include subsystems including command and data handling, communications system, electrical power, propulsion, thermal control, altitude control, guidance navigation and control,) Regarding Claim 10, Rutschman teaches: a computing system or one or more hardware processors. (¶4 at least one computer processor) Regarding Claim 11, Rutschman teaches: configure the computing system or one or more hardware processors to perform one or more operations and (¶4 at least one computer processor configured by the one or more program instructions to perform operations including at least: obtaining imagery using the at least one imager of the satellite;) to provide a result of the one or more operations to the software satellite payload. (¶61 a hub processing unit 502 linked to each of array of image processors 504 and 504N; and a wireless communication interface 506 linked to the hub processor 502; ¶121 satisfy one or more incoming requests received via the communication interface or gateway 506.) Regarding Claim 12, Rutschman teaches: a computing system or one or more sensor systems. (¶127 a visible image sensor 316; and an infrared image sensor 318) Regarding Claim 13, Rutschman teaches: configure the one or more sensor systems to be repositioned or reconfigured. (¶127 The dimensions of the steerable spot imager 104; ¶52 The gimbal 110 can be arranged with and pivot close to or at the center of gravity of the steerable spot imager 104 to reduce negative effects of slewing; ¶100 image content within one subfield of the field of view 404 can trigger actions, such as movement of a steerable spot imaging unit 104 to track the content through different subfields.) Regarding Claim 14, Rutschman teaches: wherein the one or more sensor systems comprise one or more cameras. (¶127 a visible image sensor 316; and an infrared image sensor 318) Regarding Claim 15, Rutschman teaches: configure the one or more cameras to capture an image and communication the image via a hardware communication system of the satellite system after the satellite system has been moved into a new orientation, location, position, or altitude. (¶74 obtaining a request, identifying which image processors correspond to a portion of the request, and transmitting sub request to the appropriate image processors … process high resolution raw image data prior to transmission … enable independent focus, zoom, and steering by multiple simultaneous clients ... identify and track important objects or events; ¶118 high resolution imagery can still be be transmitted over the wireless communication interface 506 despite its constraints) Regarding Claim 16, Rutschman teaches: wherein the one or more commands from the software satellite payload modify an aperture, shutter, or filter of the one or more cameras. (¶74 obtaining a request, identifying which image processors correspond to a portion of the request, and transmitting sub request to the appropriate image processors; ¶89 first imaging unit configured to capture and process imagery of a first field of view includes ... aperture 18.4 mm; ¶110 second imaging unit configured to capture and process imagery of a second field of view that is proximate to and that is larger than a size of the first field of view includes … aperture f/2.5) Regarding Claim 17, Rutschman teaches: wherein the one or more sensor systems comprise a radio frequency sensor. (¶72 include a satellite radio communication link) Regarding Claim 18, Rutschman teaches: wherein the one or more sensor systems comprise a weather monitoring instrument or a climate monitor instrument. (¶104 may monitor for low pressure and weather systems) Regarding Claim 19, Rutschman teaches: wherein the one or more sensor systems comprise one or more power sources. (¶172 Interfaces of the TT&C 1706 include one or more of a satellite operations system, an altitude determination and control, command and data handling, electrical power; ¶175 Note that the satellite bus of satellite 500 can include subsystems including command and data handling, communications system, electrical power) Regarding Claim 20, Rutschman teaches: wherein the one or more sensor systems comprise one or more of an astronics system, an avionics system, a horizon sensor, and a transceiver system. (¶72 The wireless communication interface 506 can include a satellite radio communication link) Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIJAN MAPAR whose telephone number is (571)270-3674. The examiner can normally be reached Monday - Thursday, 11:00-8:30. 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, Rehana Perveen can be reached at 571-272-3676. 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. /BIJAN MAPAR/ Primary Examiner, Art Unit 2189
Read full office action

Prosecution Timeline

May 22, 2024
Application Filed
Dec 14, 2024
Non-Final Rejection — §103
Dec 30, 2024
Response Filed
Mar 08, 2025
Final Rejection — §103
Apr 04, 2025
Request for Continued Examination
Apr 14, 2025
Response after Non-Final Action
Apr 19, 2025
Non-Final Rejection — §103
Jul 09, 2025
Response Filed
Jul 26, 2025
Final Rejection — §103
Aug 27, 2025
Request for Continued Examination
Sep 05, 2025
Response after Non-Final Action
Sep 06, 2025
Non-Final Rejection — §103
Dec 21, 2025
Response Filed
Jan 24, 2026
Final Rejection — §103
Feb 24, 2026
Request for Continued Examination
Mar 07, 2026
Response after Non-Final Action
Mar 21, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602521
COMPUTER-IMPLEMENTED METHOD, DATA PROCESSING SYSTEM FOR PRODUCING A TARGET DESIGN AND COMPUTER PROGRAM, STORAGE MEDIUM HAVING INSTRUCTIONS FOR PRODUCING A TARGET DESIGN, METHOD FOR PROVIDING A SPECTACLE LENS, STORAGE MEDIUM HAVING A NUMERICAL REPRESENTATION OF A SPECTACLE LENS AND METHOD FOR MANUFACTURING A SPECTACLE LENS
2y 5m to grant Granted Apr 14, 2026
Patent 12602037
METHODS AND APPARATUS TO GENERATE A PREDICTIVE ASSET HEALTH QUANTIFIER OF A TURBINE ENGINE
2y 5m to grant Granted Apr 14, 2026
Patent 12596856
ASSET EVALUATION SYSTEM FOR AUTONOMOUS VEHICLE SIMULATIONS
2y 5m to grant Granted Apr 07, 2026
Patent 12596860
SYSTEMS AND METHODS FOR HARDWARE ACCELERATION OF MASKING AND NORMALIZING DATA WITH A TRIANGULAR INPUT MASK
2y 5m to grant Granted Apr 07, 2026
Patent 12589553
EVALUATION OF 3D PRINTED OBJECTS
2y 5m to grant Granted Mar 31, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

7-8
Expected OA Rounds
67%
Grant Probability
96%
With Interview (+29.0%)
3y 6m
Median Time to Grant
High
PTA Risk
Based on 470 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month