DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Responsive to the communication dated 04/28/2023
Claims 1-4 are presented for examination
Drawings
The subject matter of this application omits of illustration by a drawing to facilitate understanding of the invention. Applicant is required to furnish a drawing under 37 CFR 1.81(c). No new matter may be introduced in the required drawing. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d).
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Abstract
The abstract dated 04/08/2023 has been reviewed. It has 128 words, and contains no legal phraseology. It is accepted.
Claim Objections
Claims 2-4 are objected to because of the following informalities:
Claim 2 recites “various modularized components … the various modularized components comprise … each of the various modularized components… geometric and physical parameters of the various modularized components” To improve readability and better distinguish this set of modularized components from the modularized components described in claim 1, it is recommended to amend the claims to replace the word “various” with either “a set of” or “a first set of”
Claim 2 recites “the various modularized components comprise at least one item selected from…” As these are later collectively referred to as ‘modules’ (i.e. inter-module connection, module material, module weight) it is recommended to replace the word “item” with “module” when referring to these elements.
Claim 3 recites the limitation “forming the task text data set by all text and the label of the corresponding text;’ Firstly, to improve readability, it is recommend to replace “forming the task text data set by…” with “forming the task text data set from…” Further, to avoid potential issues with antecedent basis it is recommended to replace “all text” with a listing the specific text elements to be included in the task text data, e.g. the previously recited piece of text.
Claim 4 recites “an output of the deep neural network model is three-dimensional model data of a target spacecraft assembled by the modularized component;” Firstly, the modularized components were only introduced previously in a plural sense, and it is clear that this plurality of modularized components is still intended in claim 4. Therefore, to improve readability and avoid potential issues with antecedent basis, it is recommended to amend this limitation to instead read “the modularized components”.
Secondly, it is clear that these modularized components are the building blocks used to construct the spacecraft and not a mechanism for assembling the spacecraft itself. With this in mind, it is recommended to amend the claim to instead read “… assembled using the modularized components”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3 and 4 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 3, the phrase "related operation of text vectorization" is interpreted as a misspelling of “related operations of text vectorization,” i.e. other related operations for text vectorization beyond the Chinese word segmentation and removing stop words already listed, and therefore renders the claim(s) indefinite because the claim(s) include(s) elements not actually disclosed (those encompassed by "related operations"), thereby rendering the scope of the claim(s) unascertainable. See MPEP § 2173.05(d).
Claim 3 recites the limitation “each executed spacecraft manufacturing task…” There is insufficient antecedent basis for this limitation in the claim. Particularly, it is no spaceship manufacturing tasks, let alone the execution of such tasks, was previously presented.
Claim 4 recites the limitation " N is a total quantity of modularized components comprised in the data set;" There is insufficient antecedent basis for this limitation in the claim. Particularly, it is not entirely clear whether this is referring to the previously introduced component data set or a separate data set.
Claim 4 recites the limitation "three-dimensional model data of a target spacecraft assembled by the modularized component;" There is insufficient antecedent basis for this limitation in the claim. Particularly, it is not entirely clear whether this is referring to the target spacecraft introduced in claim 1, or if this target spacecraft assembled by the modularized component is a different, separate spacecraft.
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.
(1) Claims 1-2 are rejected under 35 U.S.C. 103 as being unpatentable over Vaujour (US 11651466 B2) in view of Jiang (CN 101901287 A)
Claim 1. Vaujour teaches An intelligent modularized reconstruction system for a spacecraft based on analysis of a task text, ([Abstract] “Systems and methods for describing, simulating and/or optimizing spaceborne systems and missions. Configurations for spaceborne systems are generated and validated based on simulation output.” [Figure 6A] shows the task definition screen, which clearly includes text input and/or selection. The data entered therein is used for the generation of a spacecraft configuration) comprising a modularized spacecraft component library, ([Col 6 line 21-26] “In variants, the repository 120 stores data for one or more of: a payload model 121, spacecraft platform model 122, a payload hub model 123, a system configuration 124, mission requirements 126, a simulation 125, artefacts 127, ground station model 128, and orbital parameters 129, as shown in FIG. 4A.” [Col 13 line 23-34] “Accessing system data S210 can include updating system data (e.g., stored in the repository 120). Data can be added to the repository 120 in response to a request for adding a new customer-specific sub-mission to a payload rideshare mission, in response to addition of a new payload that can be used for rideshare missions, and in response to addition of a new spacecraft platform that can be used for rideshare missions. For example, as new payloads and spacecraft platforms are purchased or developed, corresponding models can be added to the repository 120, so that they can be selected for use in a system configuration that will be evaluated.”) a modularized spacecraft component recommendation subsystem, ([Col 16 line 1-8] “In variants, generating system configuration S220 includes identifying a set of payloads (e.g., at S222) that satisfy the mission requirements (e.g., 126) for at least one sub-mission. For example, if a sub-mission requires a methane sensor, then a methane sensor payload is selected. Once a first set of payloads needed to satisfy all requirements have been selected (at S222), the evaluation system 110 validates (at S223) the selection of payloads…”) a spacecraft generation subsystem, and ([Col 13 line 35-61] “Data accessed at S210 can be used to generate at least one system configuration at S220. System configuration can be generated automatically or in response to user input. In a first example, system configuration can be automatically generated based on one or more requests for space missions (e.g., a rideshare mission, or a sub-mission to be included in a rideshare mission). In a second example, system configuration can be generated based on a request to update an existing rideshare mission system configuration to include support an additional sub-mission. In a third example, the system configuration can be explicitly configured by a user of a user device (e.g., 160). For example, an operator can request evaluation of a specific system configuration (e.g., regardless of whether the system configuration is suitable for a particular rideshare mission). In variations, the evaluation system 110 (or a component of the evaluation system, e.g., the configuration generator ill) generates system configuration at S220. However, any suitable component of the system 100 can generate the system configuration at S220. Generating system configuration S220 can include selecting at least one payload for a rideshare mission (S222). … In variants, generating system configuration S220 can include selecting a spacecraft platform (e.g., a satellite bus) from a plurality of available spacecraft platforms (S221).”) a [Col 4 line 49 – Col 5 line 47] “In some implementations, the evaluation system 110 functions to validate one or more system configurations. In variants, system configurations include spacecraft configurations. In some implementations, spacecraft configurations include one or more of a payload, a payload hub, and a spacecraft platform (e.g., a satellite bus bus). For example, the evaluation system 110 can allow a spacecraft operator, manufacturer or service provider to assess the viability of various system configurations. The evaluation system 110 can generate system configurations (e.g., by combining potential payloads with a minimally modified ‘off the shelf’ satellite bus designs) and then assess and validate these system configurations using modelling and simulation (e.g., to provide automated trade studies). In an example, the various system configurations (e.g., combinations of payloads and satellite bus), and their performance in a simulated mission, are compared to analyze the use of spacecraft resources over the mission lifetime. The evaluation system 110 can run an evaluation process continuously and automatically to provide an ongoing visualization of the performance of validated system configurations as more potential system configurations (e.g., configurations of bus and payload candidates) are added or updated to a data repository (e.g., 120 shown in FIGS. 1A-C). The operational simulation of the ultimately selected payload configuration can then then be used as an initial Concept of Operations (CONOPS) for a spacecraft system. In variants, the evaluation system 110 functions to facilitate the development of payload rideshare missions using minimally modified off-the-shelf spacecraft systems (e.g., satellite buses). In some variations, the evaluation system 110 identifies system configurations (e.g., spacecraft configurations) that satisfy requirements for a payload rideshare mission. System configurations can be validated based on requirements of a rideshare mission by analyzing a range of performance aspects for one or more system configurations. … In some implementations, the evaluation system 110 can use information for each spacecraft platform stored in a system data repository 120, and identify the performance metrics and available resources of a candidate spacecraft platform. Such performance metrics and resources can include: volume, mass, maximum payload volume, maximum payload mass, communications bandwidth, peak and average power and thermal management available to payloads as well as the pointing accuracy, lifetime, electromagnetic compatibility of the spacecraft platform, slew rate, data storage capacity, power available, battery maximal depth of discharge, pointing budget available, and any other suitable metric or resource. However, the evaluation system 110 can identify any suitable performance metric or resource. In variants, the evaluation system 110 considers the requirements of the individual payloads, including their need for spacecraft platform real estate, resources and operational performance, in addition to any constraints the payload spacecraft platform may have. The evaluation system 110 can continuously generate a complete set of payloads from a library of candidates, given one or several available platforms or if an agreement has already been made to host a specific payload, the evaluation system 110 can analyze what payloads could be used to fill remaining spacecraft platforms capacity and reduce the cost to all customers.”) the modularized spacecraft component library comprises three-dimensional models and geometric and physical parameters of modularized components; ([Col 6 line 21-26] “In variants, the repository 120 stores data for one or more of: a payload model 121, spacecraft platform model 122, a payload hub model 123, a system configuration 124, mission requirements 126, a simulation 125, artefacts 127, ground station model 128, and orbital parameters 129, as shown in FIG. 4A.” [Col 13 line 23-34] “Accessing system data S210 can include updating system data (e.g., stored in the repository 120). Data can be added to the repository 120 in response to a request for adding a new customer-specific sub-mission to a payload rideshare mission, in response to addition of a new payload that can be used for rideshare missions, and in response to addition of a new spacecraft platform that can be used for rideshare missions. For example, as new payloads and spacecraft platforms are purchased or developed, corresponding models can be added to the repository 120, so that they can be selected for use in a system configuration that will be evaluated.” [Col 12 line 54-62] “In variants, each model identifies one or more parameters. In some implementations, payload models, spacecraft platform models, and payload hub models each identify one or more of: power requirements, data communication requirements, thermal constraints (e.g., as shown in FIG. 4B). In some implementations, a model of a physical device identifies at least one of: a mass of the modeled device, a volume of the device, dimensions of the device, a shape of the device (e.g., in a computer aided design format).”) the modularized spacecraft component recommendation subsystem is configured to recommend a type and a quantity of required modularized components from the modularized spacecraft component library for the task text; ([Col 13 line 35-61] “Data accessed at S210 can be used to generate at least one system configuration at S220. System configuration can be generated automatically or in response to user input. In a first example, system configuration can be automatically generated based on one or more requests for space missions (e.g., a rideshare mission, or a sub-mission to be included in a rideshare mission). In a second example, system configuration can be generated based on a request to update an existing rideshare mission system configuration to include support an additional sub-mission. In a third example, the system configuration can be explicitly configured by a user of a user device (e.g., 160). For example, an operator can request evaluation of a specific system configuration (e.g., regardless of whether the system configuration is suitable for a particular rideshare mission). In variations, the evaluation system 110 (or a component of the evaluation system, e.g., the configuration generator ill) generates system configuration at S220. However, any suitable component of the system 100 can generate the system configuration at S220. Generating system configuration S220 can include selecting at least one payload for a rideshare mission (S222). In variants, a single spacecraft platform is used for all rideshare missions. Alternatively, a selection of various spacecraft platforms can be used. In variants, generating system configuration S220 can include selecting a spacecraft platform (e.g., a satellite bus) from a plurality of available spacecraft platforms (S221).” [Col 16 line 1-8] “In variants, generating system configuration S220 includes identifying a set of payloads (e.g., at S222) that satisfy the mission requirements (e.g., 126) for at least one sub-mission. For example, if a sub-mission requires a methane sensor, then a methane sensor payload is selected. Once a first set of payloads needed to satisfy all requirements have been selected (at S222), the evaluation system 110 validates (at S223) the selection of payloads…”[Col 6 line 21-26] “In variants, the repository 120 stores data for one or more of: a payload model 121, spacecraft platform model 122, a payload hub model 123, a system configuration 124, mission requirements 126, a simulation 125, artefacts 127, ground station model 128, and orbital parameters 129, as shown in FIG. 4A.” [Col 13 line 23-34] “Accessing system data S210 can include updating system data (e.g., stored in the repository 120). Data can be added to the repository 120 in response to a request for adding a new customer-specific sub-mission to a payload rideshare mission, in response to addition of a new payload that can be used for rideshare missions, and in response to addition of a new spacecraft platform that can be used for rideshare missions. For example, as new payloads and spacecraft platforms are purchased or developed, corresponding models can be added to the repository 120, so that they can be selected for use in a system configuration that will be evaluated.”) the spacecraft generation subsystem is configured to reconstruct and assemble the required modularized components recommended by the modularized spacecraft component recommendation subsystem to generate ([Col 16 line 1-8] “In variants, generating system configuration S220 includes identifying a set of payloads (e.g., at S222) that satisfy the mission requirements (e.g., 126) for at least one sub-mission. For example, if a sub-mission requires a methane sensor, then a methane sensor payload is selected. Once a first set of payloads needed to satisfy all requirements have been selected (at S222), the evaluation system 110 validates (at S223) the selection of payloads…” [Col 17 line 42- 58] “In variants, a set of payloads (selected at S222, S222b) is evaluated based on one or more constraints (e.g., at S223), and at least one validated set of payloads that satisfies all constraints is selected. The various constraints (e.g., fixed constraints imposed by the design of the spacecraft platform selected at S221) can be evaluated in any suitable order. (102) In some implementations, validating payload selection S223 includes determining whether a system configuration that includes the selected spacecraft platform and the selected first set of payloads satisfies one or more of: mass constraints (e.g., at S310 shown in FIG. 3), volume constraints (e.g., at S320), power constraints (e.g., at S330), data constraints (e.g., at S340), dimensional constraints (e.g., at S350), and thermal constraints (e.g., at S360). However, any suitable set of constraints can be used to validate payload selection. In variants, the evaluation system 110 determines whether constraints are satisfied at S223.” [Col 18 line 41-67] “Validating a set of payloads based on dimensional constraints S350 includes: computing dimensional requirements for all payloads in the set of payloads being validated (as identified by the data accessed at S210), and determining whether the dimensional requirements are satisfied by the dimensions for the spacecraft platform (e.g., as identified by a spacecraft platform model 122 for the selected spacecraft platform). If the dimensional requirements are satisfied by the dimensions for the spacecraft platform, then the set of payloads is validated. In variants, validating a set of payloads based on dimensional constraints S350 includes performing physical modeling using Computer Aided Design to generate a digital representation of a physical arrangement of the set of payloads that satisfies the dimensional requirements of the spacecraft platform. In variations, digital representation of the physical arrangement includes a physical representation of the payload hub selected for the system configuration at S220. In variations, the dimensional constraints include dimensional constraints of the payload hub selected for the system configuration at S220. In variations, validating a set of payloads based on dimensional constraints functions to determine whether the set of payloads is physically compatible with the selected spacecraft platform (and optionally the payload hub), meaning that all payloads can fit in the spacecraft in a manner that allows them to fulfill their intended functions.” [Col 12 line 54-62] “In variants, each model identifies one or more parameters. In some implementations, payload models, spacecraft platform models, and payload hub models each identify one or more of: power requirements, data communication requirements, thermal constraints (e.g., as shown in FIG. 4B). In some implementations, a model of a physical device identifies at least one of: a mass of the modeled device, a volume of the device, dimensions of the device, a shape of the device (e.g., in a computer aided design format).”) ([Col 20 line 49- Col 21 line 10] “Validating a system configuration (e.g., 510, 520) based on simulation output S240 can include comparing the simulated values generated for the system configuration (for one or more system parameters) with a set of constraints. In variants, constraints are defined (e.g., in data stored in the repository 120) for one or more simulated system parameters. The system configuration is validated by comparing the simulated values for a parameter with the corresponding parameter constraints. The results of the comparison can identify whether the system configuration is feasible for the mission being simulated. In variants, parameter constraints include one or more of threshold values, ranges, rules, and the like. Comparing simulated values with constraints can include verifying that the simulated values satisfy the constraints. Constraints can include constraints defined by the mission requirements 126, or performance requirements. Performance requirements can include requirements that the system does not run out of power, run out of data storage, drop data packets due to insufficient bandwidth, or otherwise fail to perform in any aspect. In variants, the configuration validator validates the system configuration based on the simulation output. In an example, validating based on simulation output includes ensuring that a spacecraft system with a given payload arrangement and mission configuration can withstand and deliver certain a level of performance, by simulating performance levels and potential conflicts of the payloads operating on the spacecraft system.” [Col 22 line 53-62] “Evaluating validated system configurations S260 can include one or more of: accessing data for one or more system configurations from the repository 120, displaying data for one or more system configurations, and selecting at least one system configuration. Configurations can be selected automatically based on selection criteria (such as threshold values, rules, optimization criteria etc.), or selected in response to user input received via one or more of an API, a user interface, and a network interface. In variants, selection criteria includes optimization criteria.” [Col 4 line 49- Col 5 line 8] “In some implementations, the evaluation system 110 functions to validate one or more system configurations. In variants, system configurations include spacecraft configurations. In some implementations, spacecraft configurations include one or more of a payload, a payload hub, and a spacecraft platform (e.g., a satellite bus bus). For example, the evaluation system 110 can allow a spacecraft operator, manufacturer or service provider to assess the viability of various system configurations. The evaluation system 110 can generate system configurations (e.g., by combining potential payloads with a minimally modified ‘off the shelf’ satellite bus designs) and then assess and validate these system configurations using modelling and simulation (e.g., to provide automated trade studies). In an example, the various system configurations (e.g., combinations of payloads and satellite bus), and their performance in a simulated mission, are compared to analyze the use of spacecraft resources over the mission lifetime. The evaluation system 110 can run an evaluation process continuously and automatically to provide an ongoing visualization of the performance of validated system configurations as more potential system configurations (e.g., configurations of bus and payload candidates) are added or updated to a data repository (e.g., 120 shown in FIGS. 1A-C). The operational simulation of the ultimately selected payload configuration can then then be used as an initial Concept of Operations (CONOPS) for a spacecraft system.” [Col 23 line 1-4] “[Col 20 line 49- Col 21 line 10] “Validating a system configuration (e.g., 510, 520) based on simulation output S240 can include comparing the simulated values generated for the system configuration (for one or more system parameters) with a set of constraints. In variants, constraints are defined (e.g., in data stored in the repository 120) for one or more simulated system parameters. The system configuration is validated by comparing the simulated values for a parameter with the corresponding parameter constraints. The results of the comparison can identify whether the system configuration is feasible for the mission being simulated. In variants, parameter constraints include one or more of threshold values, ranges, rules, and the like. Comparing simulated values with constraints can include verifying that the simulated values satisfy the constraints. Constraints can include constraints defined by the mission requirements 126, or performance requirements. Performance requirements can include requirements that the system does not run out of power, run out of data storage, drop data packets due to insufficient bandwidth, or otherwise fail to perform in any aspect. In variants, the configuration validator validates the system configuration based on the simulation output. In an example, validating based on simulation output includes ensuring that a spacecraft system with a given payload arrangement and mission configuration can withstand and deliver certain a level of performance, by simulating performance levels and potential conflicts of the payloads operating on the spacecraft system.” [Col 12line 54-62] “ In variants, each model identifies one or more parameters. In some implementations, payload models, spacecraft platform models, and payload hub models each identify one or more of: power requirements, data communication requirements, thermal constraints (e.g., as shown in FIG. 4B). In some implementations, a model of a physical device identifies at least one of: a mass of the modeled device, a volume of the device, dimensions of the device, a shape of the device (e.g., in a computer aided design format)”) the intelligent modularized reconstruction system is configured to perform a spacecraft reconstruction task comprising following steps: ([Abstract] “Systems and methods for describing, simulating and/or optimizing spaceborne systems and missions. Configurations for spaceborne systems are generated and validated based on simulation output.” [Figure 6A] shows the task definition screen, which clearly includes text input and/or selection. The data entered therein is used for the generation of a spacecraft configuration) step 1: describing the spacecraft reconstruction task in text to form the task text, wherein the task text comprises at least a task purpose, a motility requirement, an energy supply, a space size, and a load requirement; ([Figure 6A] shows the task definition screen which includes a purpose (objective) [Col 14 line 63 – Col 15 line 29] “In some implementations, a mission definition includes a payload description for each payload, and optionally a number of payloads to be used for the mission. In some implementations payload description for a payload includes one or more of: a payload name, a payload type, and a current technology readiness, mass, length, width, height, and desired placement (e.g., nadir facing, placement not important, etc.). In some implementations, the mission definition defines one or more operating modes (e.g., imaging mode, processing mode, standby mode, etc.). In some implementations, an operating mode definition for an operating mode identifies one or more of: name, mean power, duty cycle (e.g., average % of orbit), spacecraft pointing desired, maneuvering desired, and area of interest (AOI) (e.g., North America, Polar regions, not important, etc.). In some implementations, the mission definition defines attitude determination and control system (ADCS) information. In some implementations, ADCS information identifies one or more of: pointing accuracy, pointing knowledge, pointing stability, and maximum pointing angle off nadir. In some implementations, the mission definition defines data information. In some implementations, data information identifies one or more of: data volume per orbit, maximum data latency from collection, on-board data processing resources desired, and on-board data storage desired. In some implementations, the mission definition defines orbit information. In some implementations, orbit information identifies one or more of: orbit type, altitude range, inclination, and LTAN (Local Time of Ascending Node). In some implementations, the mission definition defines schedule information. In some implementations, schedule information identifies one or more of: planned flight model readiness, desired launch date, desired mission duration, and payload design life.”) step 2: inputting the task text into the modularized spacecraft component recommendation subsystem, and recommending the type and the quantity of the required modularized components for the task text ([Col 13 line 35-61] “Data accessed at S210 can be used to generate at least one system configuration at S220. System configuration can be generated automatically or in response to user input. In a first example, system configuration can be automatically generated based on one or more requests for space missions (e.g., a rideshare mission, or a sub-mission to be included in a rideshare mission). In a second example, system configuration can be generated based on a request to update an existing rideshare mission system configuration to include support an additional sub-mission. In a third example, the system configuration can be explicitly configured by a user of a user device (e.g., 160). For example, an operator can request evaluation of a specific system configuration (e.g., regardless of whether the system configuration is suitable for a particular rideshare mission). In variations, the evaluation system 110 (or a component of the evaluation system, e.g., the configuration generator ill) generates system configuration at S220. However, any suitable component of the system 100 can generate the system configuration at S220. Generating system configuration S220 can include selecting at least one payload for a rideshare mission (S222). In variants, a single spacecraft platform is used for all rideshare missions. Alternatively, a selection of various spacecraft platforms can be used. In variants, generating system configuration S220 can include selecting a spacecraft platform (e.g., a satellite bus) from a plurality of available spacecraft platforms (S221).” [Col 16 line 1-8] “In variants, generating system configuration S220 includes identifying a set of payloads (e.g., at S222) that satisfy the mission requirements (e.g., 126) for at least one sub-mission. For example, if a sub-mission requires a methane sensor, then a methane sensor payload is selected. Once a first set of payloads needed to satisfy all requirements have been selected (at S222), the evaluation system 110 validates (at S223) the selection of payloads…”) from the modularized spacecraft component library; ([Col 6 line 21-26] “In variants, the repository 120 stores data for one or more of: a payload model 121, spacecraft platform model 122, a payload hub model 123, a system configuration 124, mission requirements 126, a simulation 125, artefacts 127, ground station model 128, and orbital parameters 129, as shown in FIG. 4A.” [Col 13 line 23-34] “Accessing system data S210 can include updating system data (e.g., stored in the repository 120). Data can be added to the repository 120 in response to a request for adding a new customer-specific sub-mission to a payload rideshare mission, in response to addition of a new payload that can be used for rideshare missions, and in response to addition of a new spacecraft platform that can be used for rideshare missions. For example, as new payloads and spacecraft platforms are purchased or developed, corresponding models can be added to the repository 120, so that they can be selected for use in a system configuration that will be evaluated.”) step 3: ([Col 4 line 49- Col 5 line 8] “In variants, system configurations include spacecraft configurations. In some implementations, spacecraft configurations include one or more of a payload, a payload hub, and a spacecraft platform (e.g., a satellite bus bus).” [Col 13 line 30-34] “For example, as new payloads and spacecraft platforms are purchased or developed, corresponding models can be added to the repository 120, so that they can be selected for use in a system configuration that will be evaluated.” [Col 12 line 54-62] “In variants, each model identifies one or more parameters. In some implementations, payload models, spacecraft platform models, and payload hub models each identify one or more of: power requirements, data communication requirements, thermal constraints (e.g., as shown in FIG. 4B). In some implementations, a model of a physical device identifies at least one of: a mass of the modeled device, a volume of the device, dimensions of the device, a shape of the device (e.g., in a computer aided design format).”) and step 4: inputting the component data set into the spacecraft generation subsystem to perform reconstruction and assembly, generating ([Col 16 line 1-8] “In variants, generating system configuration S220 includes identifying a set of payloads (e.g., at S222) that satisfy the mission requirements (e.g., 126) for at least one sub-mission. For example, if a sub-mission requires a methane sensor, then a methane sensor payload is selected. Once a first set of payloads needed to satisfy all requirements have been selected (at S222), the evaluation system 110 validates (at S223) the selection of payloads…” [Col 17 line 42- 58] “In variants, a set of payloads (selected at S222, S222b) is evaluated based on one or more constraints (e.g., at S223), and at least one validated set of payloads that satisfies all constraints is selected. The various constraints (e.g., fixed constraints imposed by the design of the spacecraft platform selected at S221) can be evaluated in any suitable order. (102) In some implementations, validating payload selection S223 includes determining whether a system configuration that includes the selected spacecraft platform and the selected first set of payloads satisfies one or more of: mass constraints (e.g., at S310 shown in FIG. 3), volume constraints (e.g., at S320), power constraints (e.g., at S330), data constraints (e.g., at S340), dimensional constraints (e.g., at S350), and thermal constraints (e.g., at S360). However, any suitable set of constraints can be used to validate payload selection. In variants, the evaluation system 110 determines whether constraints are satisfied at S223.” [Col 18 line 41-67] “Validating a set of payloads based on dimensional constraints S350 includes: computing dimensional requirements for all payloads in the set of payloads being validated (as identified by the data accessed at S210), and determining whether the dimensional requirements are satisfied by the dimensions for the spacecraft platform (e.g., as identified by a spacecraft platform model 122 for the selected spacecraft platform). If the dimensional requirements are satisfied by the dimensions for the spacecraft platform, then the set of payloads is validated. In variants, validating a set of payloads based on dimensional constraints S350 includes performing physical modeling using Computer Aided Design to generate a digital representation of a physical arrangement of the set of payloads that satisfies the dimensional requirements of the spacecraft platform. In variations, digital representation of the physical arrangement includes a physical representation of the payload hub selected for the system configuration at S220. In variations, the dimensional constraints include dimensional constraints of the payload hub selected for the system configuration at S220. In variations, validating a set of payloads based on dimensional constraints functions to determine whether the set of payloads is physically compatible with the selected spacecraft platform (and optionally the payload hub), meaning that all payloads can fit in the spacecraft in a manner that allows them to fulfill their intended functions.” [Col 12 line 54-62] “In variants, each model identifies one or more parameters. In some implementations, payload models, spacecraft platform models, and payload hub models each identify one or more of: power requirements, data communication requirements, thermal constraints (e.g., as shown in FIG. 4B). In some implementations, a model of a physical device identifies at least one of: a mass of the modeled device, a volume of the device, dimensions of the device, a shape of the device (e.g., in a computer aided design format).”) importing the ([Col 20 line 49- Col 21 line 10] “Validating a system configuration (e.g., 510, 520) based on simulation output S240 can include comparing the simulated values generated for the system configuration (for one or more system parameters) with a set of constraints. In variants, constraints are defined (e.g., in data stored in the repository 120) for one or more simulated system parameters. The system configuration is validated by comparing the simulated values for a parameter with the corresponding parameter constraints. The results of the comparison can identify whether the system configuration is feasible for the mission being simulated. In variants, parameter constraints include one or more of threshold values, ranges, rules, and the like. Comparing simulated values with constraints can include verifying that the simulated values satisfy the constraints. Constraints can include constraints defined by the mission requirements 126, or performance requirements. Performance requirements can include requirements that the system does not run out of power, run out of data storage, drop data packets due to insufficient bandwidth, or otherwise fail to perform in any aspect. In variants, the configuration validator validates the system configuration based on the simulation output. In an example, validating based on simulation output includes ensuring that a spacecraft system with a given payload arrangement and mission configuration can withstand and deliver certain a level of performance, by simulating performance levels and potential conflicts of the payloads operating on the spacecraft system.” [Col 22 line 53-62] “Evaluating validated system configurations S260 can include one or more of: accessing data for one or more system configurations from the repository 120, displaying data for one or more system configurations, and selecting at least one system configuration. Configurations can be selected automatically based on selection criteria (such as threshold values, rules, optimization criteria etc.), or selected in response to user input received via one or more of an API, a user interface, and a network interface. In variants, selection criteria includes optimization criteria.” [Col 4 line 49- Col 5 line 8] “In some implementations, the evaluation system 110 functions to validate one or more system configurations. In variants, system configurations include spacecraft configurations. In some implementations, spacecraft configurations include one or more of a payload, a payload hub, and a spacecraft platform (e.g., a satellite bus bus). For example, the evaluation system 110 can allow a spacecraft operator, manufacturer or service provider to assess the viability of various system configurations. The evaluation system 110 can generate system configurations (e.g., by combining potential payloads with a minimally modified ‘off the shelf’ satellite bus designs) and then assess and validate these system configurations using modelling and simulation (e.g., to provide automated trade studies). In an example, the various system configurations (e.g., combinations of payloads and satellite bus), and their performance in a simulated mission, are compared to analyze the use of spacecraft resources over the mission lifetime. The evaluation system 110 can run an evaluation process continuously and automatically to provide an ongoing visualization of the performance of validated system configurations as more potential system configurations (e.g., configurations of bus and payload candidates) are added or updated to a data repository (e.g., 120 shown in FIGS. 1A-C). The operational simulation of the ultimately selected payload configuration can then then be used as an initial Concept of Operations (CONOPS) for a spacecraft system.” [Col 23 line 1-4] “[Col 20 line 49- Col 21 line 10] “Validating a system configuration (e.g., 510, 520) based on simulation output S240 can include comparing the simulated values generated for the system configuration (for one or more system parameters) with a set of constraints. In variants, constraints are defined (e.g., in data stored in the repository 120) for one or more simulated system parameters. The system configuration is validated by comparing the simulated values for a parameter with the corresponding parameter constraints. The results of the comparison can identify whether the system configuration is feasible for the mission being simulated. In variants, parameter constraints include one or more of threshold values, ranges, rules, and the like. Comparing simulated values with constraints can include verifying that the simulated values satisfy the constraints. Constraints can include constraints defined by the mission requirements 126, or performance requirements. Performance requirements can include requirements that the system does not run out of power, run out of data storage, drop data packets due to insufficient bandwidth, or otherwise fail to perform in any aspect. In variants, the configuration validator validates the system configuration based on the simulation output. In an example, validating based on simulation output includes ensuring that a spacecraft system with a given payload arrangement and mission configuration can withstand and deliver certain a level of performance, by simulating performance levels and potential conflicts of the payloads operating on the spacecraft system.”)
Vaujour does not explicitly teach a three-dimensional simulation environment; generate three-dimensional model data of a target spacecraft; the three-dimensional simulation environment is configured to display and analyze three-dimensional models of the components and three-dimensional models of the target spacecraft as a whole; displaying the components in the three-dimensional simulation environment; obtaining geometric information of the components in the three-dimensional simulation; generating three-dimensional model data of the target spacecraft and presenting the three-dimensional model data of the target spacecraft in the three-dimensional simulation environment;
Jiang makes obvious a three-dimensional simulation environment; generate three-dimensional model data of a target spacecraft; the three-dimensional simulation environment is configured to display three-dimensional models of the components and three-dimensional models of the target spacecraft as a whole; displaying the components in the three-dimensional simulation environment; obtaining geometric information of the components in the three-dimensional simulation; generating three-dimensional model data of the target spacecraft and presenting the three-dimensional model data of the target spacecraft in the three-dimensional simulation environment; ([Figs. 3-6] Clearly show the designed spacecraft, and their constituent components, in a 3D simulation environment [Page 3 Par 15-18] “Figure 3 is the 3D geometry and behavior modeling rendering of my country's "Shenzhou 5" spacecraft; Figure 4 French SPOT-5 satellite modeling renderings; Figure 5 Modeling renderings of the International Space Station; Fig. 6 Geometry and behavioral modeling renderings of Long March 2;” [Page 13 Par 4] “As shown in Figure 3, it is the 3D geometry and behavior modeling rendering of my country's "Shenzhou 5" spacecraft. This figure shows the behaviors of the spacecraft model, such as the stretching of the solar panels, the ignition of the main engine, and the work of the attitude adjustment engine. implemented under the control of parameters.”) [Page 2 Par 12-16] “In order to achieve the above object, the steps of the three-dimensional modeling method for the integration of geometry and behavior of the spacecraft of the present invention are as follows: (1) Establish the primitive library of the geometric model of the spacecraft, which includes basic geometric primitives and reference primitives; each basic geometric primitive is a single model with a single geometric structure and set by parameters; (2) Construct the model components of each part of the spacecraft from the primitive and its transformation combination; (3) According to the spacecraft entity structure, use the tree data structure to connect the model components of each spacecraft component. The model component of each component is an independent node in the model, and each node of the model is connected by a tree structure. The hierarchical structure is connected together, the root node represents the whole model, and each connected node forms relative child nodes and parent nodes according to the distance from the root node, and the transformation of the child node relative to the parent node is set with parameters; (4) Set the motion parameters of the spacecraft component nodes that need to be moved, and complete the integrated 3D modeling of the spacecraft geometry and behavior” )
PNG
media_image1.png
759
530
media_image1.png
Greyscale
PNG
media_image2.png
360
472
media_image2.png
Greyscale
PNG
media_image3.png
594
383
media_image3.png
Greyscale
Jiang is analogous art because it is within the field of spacecraft modelling and simulation. It would have been obvious to one of ordinary skill in the art to combine it with Vaujour before the effective filing date. One of ordinary skill in the art would have been motivated to make this combination in order to better integrate with existing tools and therefore make spacecraft development more streamlined. Jiang notes that while integration with common 3D modelling tools and formats has been explored within the field of spacecraft modelling, important design features are often lost in the process due to poor integrate mechanisms between the modelling tools and simulation software ([Page 2 Par 8-9] “The traditional spacecraft product modeling has achieved considerable research results, but it mainly focuses on the geometric information modeling of the product, the completeness of product information description is not enough, the standardization and normalization of product definition is not good, and there is a lack of an integrated , a complete and consistent effective method, especially for complex aerospace products that are difficult to express uniformly at the system level, and cannot effectively support the integrated development process of the entire life cycle of spacecraft products. At present, the 3D exchange model data structure (such as 3DS format and DXF format) output by widely used commercial 3D modeling tools (such as 3DSMax, AutoCAD, etc.) in the world adopts the boundary representation method based on the triangle surface fitting solid surface. Although the structure of the data organization is simple, it can only describe the model as a combination of several polygonal surfaces, which is not suitable for the three-dimensional expression of objects with complex internal structures (such as spacecraft); the boundary representation is not good for the geometric description of the model. It has parameter features, and cannot express the size, position, direction, offset, etc. of model components; the 3D entity described in 3DS format also has action features. This method adopts the frame animation implementation method, which specifies the start and The frame state is terminated, and the animation in the middle process is interpolated through time control, so the user is not allowed to control the model behavior parameters.”) To this end, Jiang presents a system that can more effectively integrate the simulation system with typical 3D modelling systems, making up for the shortcomings present when importing common model types such as boundary-representation models ([Page 3 Par 1] “The modeling method of the present invention adopts the tree-like data structure to manage the internal components of the model, which has obvious hierarchy and can well make up for the shortcomings of the model boundary representation method, so that the model components can be easily transplanted and reused, and are easy to expand; Components are expressed parametrically. Under the control of parameters, the movement (such as translation, rotation, scaling, etc.) of a node in the model component tree is transmitted to the model components on each child node under the node, so as to realize the three-dimensional control of spacecraft parameters An expression of an entity's behavioral characteristics.”) Overall, one of ordinary skill in the art would have recognized that combining Jiang with Vaujour would allow the system to integrate more easily with existing modelling tools and pipelines, ultimately streamlining the entire craft development process.
Claim 2. Vaujour teaches wherein: the modularized spacecraft component library is an extensible database comprising at least three-dimensional models and geometric and physical parameters of various modularized components; ([Col 6 line 21-26] “In variants, the repository 120 stores data for one or more of: a payload model 121, spacecraft platform model 122, a payload hub model 123, a system configuration 124, mission requirements 126, a simulation 125, artefacts 127, ground station model 128, and orbital parameters 129, as shown in FIG. 4A.” [Col 13 line 23-34] “Accessing system data S210 can include updating system data (e.g., stored in the repository 120). Data can be added to the repository 120 in response to a request for adding a new customer-specific sub-mission to a payload rideshare mission, in response to addition of a new payload that can be used for rideshare missions, and in response to addition of a new spacecraft platform that can be used for rideshare missions. For example, as new payloads and spacecraft platforms are purchased or developed, corresponding models can be added to the repository 120, so that they can be selected for use in a system configuration that will be evaluated.” [Col 12 line 54-62] “In variants, each model identifies one or more parameters. In some implementations, payload models, spacecraft platform models, and payload hub models each identify one or more of: power requirements, data communication requirements, thermal constraints (e.g., as shown in FIG. 4B). In some implementations, a model of a physical device identifies at least one of: a mass of the modeled device, a volume of the device, dimensions of the device, a shape of the device (e.g., in a computer aided design format).”) the various modularized components comprise at least one item selected from the group consisting of a propulsion module, an energy module, a storage module, a communication module, an observation module, ([Col 7 line 54 – Col 8 line 2] “Some examples of payloads can include one or more sensors. The sensors preferably include imaging sensors (e.g., cameras, synthetic-aperture radar sensors, etc.), but can additionally or alternatively include any other suitable sensors. The payload can optionally include actuators configured to aim and/or otherwise adjust operation of the sensor (e.g., reposition the sensor, adjust elements of the sensor such as apertures, shutters, filters such as spectral filters and/or polarization filters, etc.), and/or can include any other suitable elements configured to control sensor operation and/or state. One or more payloads can additionally or alternatively include propulsion elements. One or more payloads can additionally or alternatively include experimental elements, such as electronic elements (e.g., experimental flight computer, experimental circuitry, control electronics for conducting experiments, etc.).”) and a connection module; each of the various modularized components comprises a standard docking interface; the standard docking interface is configured to establish at least one item selected from the group consisting of an inter-module connection, an electrothermal transmission, and a data communication; and ([Col 9 line 5-55] “In a second variation, the payload hub includes an interface module (or multiple interface modules) that function to interface one or more payloads with a spacecraft platform (e.g., by coupling a payload to a power system or communication system of the spacecraft platform). In the second variation, in which the payload hub includes an interface module, the interface module preferably functions as an interface (e.g., communication interface, mechanical interface, and/or electrical interface, etc.) between other elements of the spacecraft platform (e.g., between the bus and one or more of the payloads); and/or preferably functions as an interface (e.g., communication interface) between the spacecraft platform and/or other payloads, and optionally other elements, such as ground control elements, other spacecraft, etc. In such variations, the interface module can function to facilitate use of arbitrary payloads, buses, and/or payload-bus combinations in a spacecraft. In examples in which the interface module is engineered to interface with both the bus and the payloads, the bus does not need to be engineered based on specific characteristics of the payloads and/or of the interface module. In examples in which the interface module is further engineered to interface with the ground control elements (e.g., wherein the interface module is configured to communicate with the ground control elements in a standardized manner), preferably such that any communication between ground control elements and other elements of the spacecraft system is intermediated via the interface element, the other spacecraft elements (e.g., bus, payloads) on the one hand and the ground control elements on the other hand do not need to be engineered based on specific characteristics of each other. In variants, the hub (e.g., the interface module) is connected to each payload, more preferably mechanically, communicatively, and electrically connected, but can alternatively have any other suitable arrangement and/or configuration with respect to the payloads. In variants, the hub (e.g., the bus and/or the interface module) includes one or more power sources, attitude and/or trajectory control modules, astrionics modules (e.g., attitude determination sensors, command modules, telemetry modules, health sensors, etc.), avionics modules, communication modules, computation modules, sensors, and/or any other suitable elements. In some examples, the spacecraft platform includes one or more power sources, attitude and/or trajectory control modules, and astrionics modules (e.g., attitude determination sensors, command modules, telemetry modules, health sensors, etc.), and the interface module includes one or more communication modules and computation modules included in the spacecraft platform. However, the elements of the hub can additionally or alternatively be distributed in any other suitable manner.”) geometric and physical parameters of the various modularized components comprise at least one item selected from the group consisting of module material, module weight, space size, centroid, and rotational inertia. ([Col 12 line 54-65] “n variants, each model identifies one or more parameters. In some implementations, payload models, spacecraft platform models, and payload hub models each identify one or more of: power requirements, data communication requirements, thermal constraints (e.g., as shown in FIG. 4B). In some implementations, a model of a physical device identifies at least one of: a mass of the modeled device, a volume of the device, dimensions of the device, a shape of the device (e.g., in a computer aided design format).”)
Allowable Subject Matter
Additionally, Claims 3 and 4 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 in a way that overcomes the previously outlined objections and rejections under 35 U.S.C. 112.
Claim 3 would be allowed under 35 U.S.C. 103 over prior art. The following is a statement of reasons for the indication of allowable subject matter: prior art representative of the claim, in particular prior art that described decomposing text describing spacecraft tasks into vectors and using these vectors to train a machine learning model to select appropriate spacecraft components that would have been obvious to one of ordinary skill in the art to combine with the other references could not be found.
Claim 4 would be allowed under 35 U.S.C. 103 over prior art. The following is a statement of reasons for the indication of allowable subject matter: prior art representative of the claim, in particular prior art that described generating a spacecraft design using the particular component-based machine learning method as claimed could not be found.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Michael P Mirabito whose telephone number is (703)756-1494. The examiner can normally be reached M-F 10:30 am - 6:30 pm.
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, Emerson Puente can be reached at (571) 272-3652. 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.
/M.P.M./Examiner, Art Unit 2187
/EMERSON C PUENTE/Supervisory Patent Examiner, Art Unit 2187
Prosecution Insights