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 12/29/2022
Claims 1-10 are presented for examination
Drawings
The drawings dated 12/29/2022 have been reviewed. They are accepted.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Abstract
The abstract dated 12/29/2022 has been reviewed. It has 99 words, and contains no legal phraseology. It is accepted.
Claim Objections
Claims 1-10 objected to because of the following informalities:
The claims have numerous issues with antecedent basis. The Examiner suggests amending the claims such that the first recitation of each distinct element uses articles such as “a”/”an”, later recitations referring back to the same distinct element uses articles such as “the”/”said”, to use disambiguating modifiers (e.g., first, second, etc.) when there are multiple distinct elements with the same base term, and that the use of modifiers for each distinct element is kept consistent. Below is a non-exhaustive list of examples of these issues:
Claim 1 recites “…the result of attribute modeling of simulation entity, thus obtaining simulation entity model;” There are numerous missing articles in this limitation. This should read “…the result of the attribute modeling of the simulation entity, thus obtaining a simulation entity model;”
Claim 2 recites “physical attribute modeling of simulation entity, behavior attribute modeling of simulation entity” There are missing articles in this limitation. This should read “physical attribute modeling of the simulation entity, behavior attribute modeling of the simulation entity
Claim 3 recites “the compound type comprises entity type, enumeration type and user-defined type;” There are missing articles in this limitation. This should read “the compound type comprises an entity type, an enumeration type and a user-defined type;”
Claim 4 recites “constructing an event model for behavior to interact among entities with an event mechanism.” This limitation is not clearly written. It is recommended to amend it to read something along the lines of “constructing an event model for ion behavior among entities with an event mechanism”
Claim 5 recites “modeling a reliability of equipment task execution through a reliability block diagram algorithm, and generating entity model task reliability module.” No “equipment task” was previously introduced.
Claim 6 recites the limitation "equipment physical model.” No equipment physical model was previously introduced.
Claim 8 recites the limitation “…obtaining a result of attribute modeling of a simulation entity of a module to be tested…” There are missing articles in this limitation. This should read “…obtaining a result of the attribute modeling of a simulation entity of a module to be tested…”
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 8-10 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 claims 3 and 8, the phrase “used for” renders the claim indefinite because it is unclear whether the limitation(s) following the phrase are part of the claimed invention. Particularly, it is unclear whether or not the limitations following the phrase are meant to be limiting structural elements. For example, claim 3 recites “the entity type comprises an entity primary key, used for indicating an inter-entity relationship among entities…” Is the use of this key to indicate inter-entity relationships meant to limit the scope of the claim to only cover keys used for defining such relationships, or is this merely an intended use of this key, with its existence as part of the entity type being the only intended limit to the claim scope. See MPEP § 2173.05(d), § 2111.02, and 2173.02. With this in mind, for the purposes of this examination, the limitations following the phrase “used for” are treated as simply statements of intended use or purpose and therefore non-limiting.
The term “commonly used” in claim 3 is a relative term which renders the claim indefinite. The term “commonly used” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Is it unclear what is frequent enough to be considered “commonly.” Is a list accessed once every 2 seconds “commonly” used? Every month? Every 10,000 years? With this indefinite scope in mind, any element that is in any way accessed or accessible is consider is considered to be “commonly used.”
The term “convenient” in claim 3 is a relative term which renders the claim indefinite. The term “convenient” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. What is considered “convenient” is a subjective opinion that differs from person to person.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-10 are rejected under 35 U.S.C. 101 because they are directed to an abstract idea without significantly more.
Claim 1 (Statutory Category – Process)
Step 2A – Prong 1: Judicial Exception Recited?
Yes, the claim recites a mental process, specifically:
MPEP 2106.04(a)(2)(Ill): “Accordingly, the "mental processes" abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, Judgments, and opinions.”
Further, the MPEP recites “The courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation.”
A method for modularized modeling of equipment entities in simulation field based on meta-model, comprising: … performing data pre-processing using the data to be tested, then obtaining metadata;
Performing generic “pre-processing” of data is a mental process equivalent to performing any kind of operation on a data element, for example multiplying numeric data by a scaling factor, collecting data into a collection/container, etc.
Obtaining metadata about this data is also a mental process, equivalent to considering the original data and describing it with other data. For example, a person could generate “metadata” about a photograph by writing out when it was taken, what people are in the photo, etc. This new information could be written out using a pencil and paper.
performing attribute modeling using the metadata, and obtaining a result of attribute modeling of a simulation entity of a module to be tested;
Performing this attribute modeling is a mental process equivalent to creating a model of some aspect of the system reflected in the metadata. For example, if the metadata describes aspects of a model of a conveyor belt, such as the speed of the belt, performing this attribute modeling would be equivalent to modeling what this speed would be in the future. A person could reasonably do this by observing the past metadata and predicting its future state based on this history. For example, if a conveyor belt has its target speed set to 10 mph, and the belt’s actual speed has been at 10 mph for the past hour, a person could reasonably conclude that the belt will likely still be at 10 mph in the next second.
performing simulation entity model binding processing based on the result of attribute modeling of simulation entity, thus obtaining simulation entity model;
Performing this “binding” is merely the act of associating the various model components with each other. For example, associating a base conveyor belt model entity with a physical simulation of its movement and a behavioral simulation of its operating state. These kinds of associations can be made simply by indicating them as by drawing/writing such indications with a pencil and paper. For example, a drawn diagram element representing a “base conveyor belt” entity may have an arrow that points to another “conveyor belt physical simulation” diagram element. These kinds of diagrammatic system representations are commonly created by system designers, such as by drawing UML models.
and instantiating the simulation entity model to obtain a simulation result.
Instantiating an element is merely the act of creating a copy of it. For example, if a drawn diagram contains a “base conveyor belt” entity, instantiating this entity would simply consist of drawing a copy of that entity in the diagram.
Indicating the result of the simulation merely amounts to writing out a representation of that result. For example, writing out the predicted future speed of the modeled conveyor belt would be an example of obtaining this simulation result.
Should it be found that this is not a mental process, it is also an example of mere instructions to apply.
Step 2A – Prong 2: Integrated into a Practical Solution?
Insignificant Extra-Solution Activity (MPEP 2106.05(g)) has found mere data gathering and
post solution activity to be insignificant extra-solution activity.
Data gathering:
collecting data to be tested;
Without specifying how this collection is actually performed, collecting this data amounts to no more than mere data gathering.
Mere Instructions to Apply (MPEP 2106.05(f)) has found that merely applying a judicial exception such as an abstract idea, as by performing it on a computer, does not integrate the claim into a practical solution.
Mere Instructions to Apply:
instantiating the simulation entity model to obtain a simulation result.
Applying a computer to perform a generic simulation at a high level of generality is simply the act of instructing a computer to perform generic functions to perform that simulation, which is merely an instruction to apply a computer to the judicial exception. The claim only recites the idea of a solution or outcome, i.e. that the model is “instantiated” and a simulation result is “obtained” without reciting how this simulation is actually accomplished. Further, the computer elements claimed are cited as merely generic tools to perform the operations.
Step 2B: Claim provides an Inventive Concept?
No, as discussed with respect to Step 2A, the additional limitations are Insignificant Extra-Solution Activity and do not impose any meaningful limits on practicing the abstract idea and therefore the claim does not provide an inventive concept in Step 2B.
Insignificant Extra-Solution Activity (MPEP 2106.05(g)) has found mere data gathering and
post solution activity to be insignificant extra-solution activity.
Data gathering:
collecting data to be tested;
Without specifying how this collection is actually performed, collecting this data amounts to no more than mere data gathering.
A claim element that amounts to merely gathering data is not indicative of integration into a practical solution nor evidence that the claim provides an inventive concept or significantly more, as exemplified by ((MPEP 2106.05)(g)(Mere Data Gathering) i. Performing clinical tests on individuals to obtain input for an equation, In re Grams, 888 F.2d 835, 839-40; 12 USPQ2d 1824, 1827-28 (Fed. Cir. 1989); iv. Obtaining information about transactions using the Internet to verify credit card transactions, CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011);
Mere Instructions to Apply (MPEP 2106.05(f)) has found that merely applying a judicial exception such as an abstract idea, as by performing it on a computer, does not integrate the claim into a practical solution.
Mere Instructions to Apply:
instantiating the simulation entity model to obtain a simulation result.
Applying a computer to perform a generic simulation at a high level of generality is simply the act of instructing a computer to perform generic functions to perform that simulation, which is merely an instruction to apply a computer to the judicial exception. The claim only recites the idea of a solution or outcome, i.e. that the model is “instantiated” and a simulation result is “obtained” without reciting how this simulation is actually accomplished. Further, the computer elements claimed are cited as merely generic tools to perform the operations.
The additional elements have been considered both individually and as an ordered combination in the consideration of whether they constitute significantly more, and have been determined not to constitute such.
The claim is ineligible.
Claim 8 The elements of claim 8 are substantially the same as those of claim 1. Therefore, the elements of claim 8 are rejected due to the same reasons as outlined above for claim 1.
Moreover, Mere Instructions To Apply An Exception (MPEP 2106.05(f)) has found that simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. In light of this, the additional generic computer component elements of “A system for modularized modeling of equipment entities in simulation field based on meta- model, comprising…” are not sufficient to integrate a judicial exception into a practical application nor provide evidence of an inventive concept.
The additional elements have been considered both individually and as an ordered combination in the consideration of whether they constitute significantly more, and have been determined not to constitute such.
The claim is ineligible.
Claim 2 recites “wherein the attribute modeling comprises: physical attribute modeling of simulation entity, behavior attribute modeling of simulation entity, and task reliability modeling.”
Modelling the physical attributes of an entity is a mental process equivalent to drawing and/or writing, with a pencil and paper, a representation of those physical attributes. For example, modelling the physical attributes of a conveyor belt might consist of writing out the dimensions of the belt, or indicating the speed of the belt and predicting what its future speed will be.
Modelling the behavioral attributes of an entity is a mental process equivalent to creating a representation of the behavior of that entity, i.e. by drawing or writing out such a representation. For example, the behavior of light bulb might be modelled using a state model indicating that the bulb transitions from the “on” state to the “off” state when a switch is flipped.
Modelling the task reliability of an entity is a mental process equivalent to predicting the chances of failure for a certain task. For example, given a plane with no wings, a person could reasonably conclude that a task of crossing the Atlantic would have a very low chance of success. Such task reliability modelling is also commonly performed through techniques such as the use of reliability block diagrams, which can be drawn and evaluated by hand.
Claim 9 The elements of claim 9 are substantially the same as those of claim 2. Therefore, the elements of claim 9 are rejected due to the same reasons as outlined above for claim 2.
Claim 3 recites “wherein the physical attribute modeling of simulation entity comprises attribute types of basic type and compound type; the compound type comprises entity type, enumeration type and user-defined type; the entity type comprises an entity primary key, used for indicating an inter-entity relationship among entities, comprising a mounted entity, an assembled entity to a present entity, or an entity that the present entity is affiliated to, then a corresponding entity is available in an entity instance manager through the entity primary key; the enumeration type comprises optional attribute value list and attribute value, used for representing order enumeration type, equipment state enumeration type, and equipment working unit enumeration type; and the user-defined type comprises an attribute list, the attribute list is commonly used by users and is convenient for attribute reuse.”
This merely clarifies the structure of how the system is organized and which components contain which sub-components and what data. Therefore, this is merely an extension of the mental process.
Claim 4 recites “wherein a method of the behavior attribute modeling of simulation entity comprises: modeling entity behavior through a behavior tree, generating behavior modules, and constructing an event model for behavior to interact among entities with an event mechanism.”
Constructing a behavior tree and modeling the behavior between entities is a mental process equivalent to drawing such a behavior tree for each entity that includes this interaction behavior. For example, the tree for a first entity might have a “send broadcast” node, while the second entity has a sequence node with the children “heard broadcast?” and “acknowledge.” This creates an interaction where the first entity sends out a broadcast and the second entity acknowledges the broadcast if it is received.
Claim 10 The elements of claim 10 are substantially the same as those of claim 4. Therefore, the elements of claim 10 are rejected due to the same reasons as outlined above for claim 4.
Claim 5 recites “wherein a method of the task reliability modeling comprises: modeling a reliability of equipment task execution through a reliability block diagram algorithm, and generating entity model task reliability module.”
Creating and using a reliability block diagram is merely the mental process of drawing such a diagram and evaluating it.
Creating such a module is a mental process equivalent to creating a diagrammatic representation that encapsulates the task reliability evaluation, as by drawing it with a pencil and paper.
Claim 6 recites “wherein a method of the simulation entity model binding processing comprises: binding equipment physical module and the behavior modules corresponding to a task being performed as well as task reliability modules, and the binding is achieved through an association model globally unique identifier (GUID).”
Binding these elements together by associating them with GUIDs is a mental process equivalent to including these GUIDs in the system diagram. For example, “binding” the equipment physical module to the behavior module might consist of assigning a GUID to each as well as a reference to the other module’s GUID. The diagram element representative of the physical module might, for example, include a box that lists its GUID as 0, while the element representative of the behavior module might include a box that lists its GUID as 1. To “bind” the physical module to the behavior module, the physical module representation might also include an “external reference” box that lists 1, the GUID of the behavior module, and vice versa for the behavior module referencing the physical module.
Claim 7 recites “wherein a method of instantiating the simulation entity model comprises: inputting the simulation entity model into an instantiation factory, outputting an entity instance by a cloning method, and managing the entity instance with an instance manager to complete a modeling process, then loading the entity instance onto a simulation engine, and running to output simulation results.”
This operation consists of the mental process of creating a duplicate of the simulation entity, for example by drawing another copy of it in the system diagram, then performing a generic simulation based on that instance.
Managing the entity instance is a mental process equivalent to making decisions about the content of that instance, i.e. whether to change or keep aspects of it.
Applying a computer to perform a generic simulation at a high level of generality is simply the act of instructing a computer to perform generic functions to perform that simulation, which is merely an instruction to apply a computer to the judicial exception. The claim only recites the idea of a solution or outcome, i.e. that the instance is “loaded” into the simulation engine and “running” the simulation without reciting how this simulation is actually accomplished. Further, the computer elements claimed are cited as merely generic tools to perform the operations;
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 and 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Grefen (US 11562112 B2) in view of Wang (CN 114201885 A)
Claim 1. Grefen teaches A method for modularized modeling of equipment entities in simulation field based on meta-model, comprising: ([Abstract] “Modelling of distributed event-discrete systems using digital twins. In more detail, the present disclosure relates to the field of modeling distributed event-discrete systems using digital twins for subsequent use of the models during real time control of distributed even-discrete systems. Heretofore, there are provided a computer implemented meta model, modeling methods using the computer implemented meta model, and related modeling engine and service engine. In the computer implemented meta model at least one state in the at least one state model is represented by a set of partial states using different levels of data abstraction according to a meta description, a range of values characterizing a target for a considered state, and a range of values representing an actual constellation of a considered state.”)collecting data to be tested; performing data pre-processing using the data to be tested, then obtaining metadata; ([Fig. 3] Shows the metadata associated with meta objects relating to a conveyor and sensor. As can be seen from the “State:” section of the figure, the metadata representation utilizes actual collected data, such as the speed of a particular conveyor [Col 6 line 20-27] “As shown in FIG. 3, yet another important aspect of the present invention is a meta representation of states on different levels of abstraction. As shown in FIG. 3, such an abstracted state representation for the meta object conveyer would be, e.g. a meta state signal analyzed, a specification of a target feature to a target velocity, and a specific representation of an actual feature showing the actual speed of the conveyer during run time”[Col 14 line 30-33] “As shown in FIG. 11, initially, in a step S10 executed by the modeling engine 12, there is generated at least one meta object type in line with the pre-configured static data model to be explained in the following with respect to FIG. 12.” [Col 18 line 6-9] “As shown in FIG. 11, initially, in a step S10 executed by the modeling engine 12, there is generated at least one meta object type in line with the pre-configured static data model to be explained in the following with respect to FIG. 12.” [Col 15 line 40-54] “As shown in FIG. 12, the static meta model of the computer implemented meta model comprises an input vector entity 26 representing a first input to the functional model Φ(ex,in)i•at as at least one state vector Θ(ex,in),i•at,l summarizing at least one tuple of an identification of a subsystem and a state in which the identified subsystem prevails. Further, the input vector entity 26 represents a second input to the functional model Φ(ex,in),i•at as a vector summarizing at least one condition Δ(ex,in),i•at that must be met prior to a state transition from a source state zi•a to a target state zi•t. Further, the input vector entity 26 represents the at least one condition as data reflecting at least one target feature and/or at least one actual feature.”) performing attribute modeling using the metadata, and obtaining a result of attribute modeling of a simulation entity of a module to be tested([Col 17 line 37-45] “As shown in FIG. 13, the modeling engine 12 executes a step S24, by running the function use module 32, to model a state transition in the at least one state model Σi• from a source state zi•a to a target state zi•t by a functional model representing a data flow model according to meta features, target feature, and/or actual features as explained above. Here, the data flow model describes a control flow operating on meta data and a data flow operating on data reflecting target or actual features.”) ([Col 17 line 37-45] “As shown in FIG. 13, the modeling engine 12 executes a step S24, by running the function use module 32, to model a state transition in the at least one state model Σi• from a source state zi•a to a target state zi•t by a functional model representing a data flow model according to meta features, target feature, and/or actual features as explained above. Here, the data flow model describes a control flow operating on meta data and a data flow operating on data reflecting target or actual features.”) thus obtaining simulation entity model; and instantiating the simulation entity model to obtain a simulation result. ([Col 26 line 42-45] “Then for each dedicated use of a specific meta model there is instantiated at least one digital twin as digital counter part of a process object in the real world.” [Col 14 line 41-46] “As shown in FIG. 11, then follows a step S16 executed by the virtual twin engine to run the generated model in real-time. Here, the virtual twin engine 16 will allocate at least one twin object per meta object type use(s) and also use different levels of abstraction with respect to data representation” [Fig. 11] Shows an overview of the system. Note that the state transition modelling described in Col 17 happens within the modelling engine, S10 in the figure, while this running of the generated model described in Col 14 happens within the virtual twin engine, S16 in the figure.)
Grefen does not explicitly teach performing simulation entity model binding processing based on data
Wang makes obvious performing simulation entity model binding processing based on data ([Page 12 Par 4] “b) the behaviour model manager is responsible for registering the behaviour tree model, wherein the behaviour tree node and the pre-set condition are generated to the corresponding behaviour tree node type plant and the pre-condition type plant to realize, and binding the behaviour tree model to the corresponding entity model;”)
Wang is analogous art because it is within the field of metamodeling. It would have been obvious to one of ordinary skill in the art to combine it with Grefen before the effective filing date. One of ordinary skill in the art would have been motivated to make this combination in order to make model configurations more flexible and easier to adapt and optimize. As noted by Wang, many existing equipment simulation systems struggle from inflexible configuration methods ([Page 2 Par 7] “the existing military entity behaviour simulation modeling method uses the simulation behavior module of the existing simulation platform, configuring the simulation behavior model parameter of the military entity, so as to realize the purpose of the simulation modeling of the military entity behavior, but has been in the military entity behavior simulation modeling method, there is a simulation platform/engine behavior modeling bottom technology details invisible, model parameter configuration is not flexible and so on”) Logically, such an inflexible system would be harder to use and would be suboptimal for many situations where complex configuration is needed. To this end, Wang presents a metamodeling system featuring extensive modularity, making configuration of the system easier and allowing for greater flexibility that enables the system to be even better suited to any given use case. ([Page 2 Par 6- 8] “behavior tree as a better expansibility, stronger modular capability, high reusability of behavior representation method, the game artificial intelligence, computer simulation, human behaviour modeling field is widely developed. … Aiming at the above problem, the method of the invention claims a behavior simulation element modeling idea, making behavior element model xml description specification, and as the standard of constructing the military entity behavior simulation element model, simulation behavior element model comprises behavior parameter list, behavior tree model, behavior management, behavior simulation operation and so on; based on the improved behaviour tree to construct the simulation action main body frame, comprising a behaviour tree control node and leaf action node and node tree structure relation, for realizing the construction of the behaviour tree model, at the same time, developing model analyzer in the simulation behaviour frame, realizing xml analysis of the behaviour model, so as to generate simulation behaviour tree model and computer program of example; according to the behavior decision, using the combination behavior tree control node and setting behavior tree node prepositive condition represents behavior decision rule; using the algorithm configuration mode based on the directed graph, constructing the action node of the action device model; by combining the action decision rule and the action device sequence, finally realizing the military entity behaviour simulation modeling. The method realizes the simulation engine behaviour simulation modeling key core technology autonomously controllable, model parameter configuration is flexible, supporting military, game, logistics, physical behaviour simulation modeling of multi-simulation application field of traffic and so on.”) While Wang presents military logistics simulation as an example use of the system, it would have been obvious to one of ordinary skill in the art that the enhanced flexibility granted by the system would be useful in any number of simulation contexts, and that combining Wang with Grefen would ultimately result in a system that is significantly easier to use and customize for particular needs, making the combined system more useful in a wider variety of potential use cases.
Claim 7. Grefen teaches wherein a method of instantiating the simulation entity model comprises: inputting the simulation entity model into an instantiation factory, outputting an entity instance
and running to output simulation results. ([Col 26 line 42-45] “Then for each dedicated use of a specific meta model there is instantiated at least one digital twin as digital counter part of a process object in the real world.” [Col 14 line 41-46] “As shown in FIG. 11, then follows a step S16 executed by the virtual twin engine to run the generated model in real-time. Here, the virtual twin engine 16 will allocate at least one twin object per meta object type use(s) and also use different levels of abstraction with respect to data representation” [Col 12 line 36-41] “Here, every context models a potential relation between two twin objects representing digital instantiations of meta object types MO•, or in other words a potential relation between instantiations of components of the distributed event-discrete system on a twin level as will be explained in more detail below.” [Fig. 11] Shows an overview of the system. [Examiner’s note: an “instantiation factory” is interpreted as any system that generates new instances of model elements])
Wang makes obvious generating an instance by a cloning method, managing with an instance manager ([Page 12 Page 5] “behaviour factory using clone method according to the registered behaviour model to create corresponding behaviour instance, and binding entity instance, and the behaviour instance manager using behaviour set class to manage;”)
Claim 8. The elements of claim 8 are substantially the same as those of claim 1. Therefore, the elements of claim 8 are rejected due to the same reasons as outlined above for claim 1. Further, Grefen makes obvious the additional elements of A system for modularized modeling of equipment entities in simulation field based on meta- model, comprising: ([Abstract] “Modelling of distributed event-discrete systems using digital twins. In more detail, the present disclosure relates to the field of modeling distributed event-discrete systems using digital twins for subsequent use of the models during real time control of distributed even-discrete systems. Heretofore, there are provided a computer implemented meta model, modeling methods using the computer implemented meta model, and related modeling engine and service engine. In the computer implemented meta model at least one state in the at least one state model is represented by a set of partial states using different levels of data abstraction according to a meta description, a range of values characterizing a target for a considered state, and a range of values representing an actual constellation of a considered state.” a metadata acquisition module, ([Fig. 3] Shows the metadata associated with meta objects relating to a conveyor and sensor. As can be seen from the “State:” section of the figure, the metadata representation utilizes actual collected data, such as the speed of a particular conveyor [Col 6 line 20-27] “As shown in FIG. 3, yet another important aspect of the present invention is a meta representation of states on different levels of abstraction. As shown in FIG. 3, such an abstracted state representation for the meta object conveyer would be, e.g. a meta state signal analyzed, a specification of a target feature to a target velocity, and a specific representation of an actual feature showing the actual speed of the conveyer during run time”) a simulation entity attribute modeling module, ([Col 17 line 37-45] “As shown in FIG. 13, the modeling engine 12 executes a step S24, by running the function use module 32, to model a state transition in the at least one state model Σi• from a source state zi•a to a target state zi•t by a functional model representing a data flow model according to meta features, target feature, and/or actual features as explained above. Here, the data flow model describes a control flow operating on meta data and a data flow operating on data reflecting target or actual features.”) ([Col 26 line 42-45] “Then for each dedicated use of a specific meta model there is instantiated at least one digital twin as digital counter part of a process object in the real world.” [Col 14 line 41-46] “As shown in FIG. 11, then follows a step S16 executed by the virtual twin engine to run the generated model in real-time. Here, the virtual twin engine 16 will allocate at least one twin object per meta object type use(s) and also use different levels of abstraction with respect to data representation”)
While Wang makes obvious a simulation entity model binding processing module ([Page 12 Par 4] “b) the behaviour model manager is responsible for registering the behaviour tree model, wherein the behaviour tree node and the pre-set condition are generated to the corresponding behaviour tree node type plant and the pre-condition type plant to realize, and binding the behaviour tree model to the corresponding entity model;”)
Wang is analogous art because it is within the field of metamodeling. It would have been obvious to one of ordinary skill in the art to combine it with Grefen before the effective filing date. One of ordinary skill in the art would have been motivated to make this combination in order to make model configurations more flexible and easier to adapt and optimize. As noted by Wang, many existing equipment simulation systems struggle from inflexible configuration methods ([Page 2 Par 7] “the existing military entity behaviour simulation modeling method uses the simulation behavior module of the existing simulation platform, configuring the simulation behavior model parameter of the military entity, so as to realize the purpose of the simulation modeling of the military entity behavior, but has been in the military entity behavior simulation modeling method, there is a simulation platform/engine behavior modeling bottom technology details invisible, model parameter configuration is not flexible and so on”) Logically, such an inflexible system would be harder to use and would be suboptimal for many situations where complex configuration is needed. To this end, Wang presents a metamodeling system featuring extensive modularity, making configuration of the system easier and allowing for greater flexibility that enables the system to be even better suited to any given use case. ([Page 2 Par 6- 8] “behavior tree as a better expansibility, stronger modular capability, high reusability of behavior representation method, the game artificial intelligence, computer simulation, human behaviour modeling field is widely developed. … Aiming at the above problem, the method of the invention claims a behavior simulation element modeling idea, making behavior element model xml description specification, and as the standard of constructing the military entity behavior simulation element model, simulation behavior element model comprises behavior parameter list, behavior tree model, behavior management, behavior simulation operation and so on; based on the improved behaviour tree to construct the simulation action main body frame, comprising a behaviour tree control node and leaf action node and node tree structure relation, for realizing the construction of the behaviour tree model, at the same time, developing model analyzer in the simulation behaviour frame, realizing xml analysis of the behaviour model, so as to generate simulation behaviour tree model and computer program of example; according to the behavior decision, using the combination behavior tree control node and setting behavior tree node prepositive condition represents behavior decision rule; using the algorithm configuration mode based on the directed graph, constructing the action node of the action device model; by combining the action decision rule and the action device sequence, finally realizing the military entity behaviour simulation modeling. The method realizes the simulation engine behaviour simulation modeling key core technology autonomously controllable, model parameter configuration is flexible, supporting military, game, logistics, physical behaviour simulation modeling of multi-simulation application field of traffic and so on.”) While Wang presents military logistics simulation as an example use of the system, it would have been obvious to one of ordinary skill in the art the enhanced flexibility granted by the system would be useful in any number of simulation contexts, and that combining Wang with Grefen would ultimately result in a system that is significantly easier to use and customize for particular needs, making the combined system more useful in a wider variety of potential use cases.
(2) Claims 2, 4-6, and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Grefen (US 11562112 B2) in view of Wang (CN 114201885 A) in further view of Plawecki (US 12296978 B1)
Claim 2. Grefen teaches wherein the attribute modeling comprises: physical attribute modeling of simulation entity, ([Col 8 line 35-45] “These different types of abstraction for state representation according to the present invention allow for a significant reduction of complexity in the handling of the process control of the distributed event-discrete system. The reason for this is that while, e.g. the target of a sub system used to specify a control behavior might be in the real-time domain and thus be of infinite number of values. Nevertheless, on abstraction of a way of such a real range into meta level types of, e.g. low speed, medium speed, high speed, will then lead to a reduction of complexity in the handling of, e.g. a conveyer line as described above.”) behavior attribute modeling of simulation entity, and ([Col 17 line 37-45] “As shown in FIG. 13, the modeling engine 12 executes a step S24, by running the function use module 32, to model a state transition in the at least one state model Σi• from a source state zi•a to a target state zi•t by a functional model representing a data flow model according to meta features, target feature, and/or actual features as explained above. Here, the data flow model describes a control flow operating on meta data and a data flow operating on data reflecting target or actual features.”)
Plawecki makes obvious task reliability modeling. ([Abstract] “In some examples, a dynamic reliability model of dynamic reliability models can be updated based on at least component reliability data indicative of a reliability of a component of the aerial vehicle of aerial vehicles. Each dynamic reliability model can characterize a reliability of one of the aerial vehicles. Each dynamic reliability model can be executed to compute an indication of vehicle reliability for each aerial vehicle.”)
Plawecki is analogous art because it is within the field of equipment modelling. It would have been obvious to combine it with Grefen and Wang before the effective filing date. One of ordinary skill in the art would have been motivated to make this combination in order to better predict potential failures in the operation of systems and therefore enable better decision-making based on these predicted outcomes. As noted by Plawecki, current method for modelling and predicting the reliability performance of equipment executing certain tasks/missions, particularly within a military context, suffer from an inability to alter and update the model as events unfold, e.g. if a component of an aircraft is suddenly damaged, being able to account for this damage in the prediction of further damage and ultimate task/mission success. ([Col 3 line 12-61] “The present disclosure relates to systems and methods for aerial vehicle mission and maintenance planning. Complex modeling of reliability can be used to determine a probability of mission success or loss of a platform, such as aerial vehicles (e.g., manned or unmanned aerial vehicles). Existing complex modeling approaches provide a quantitative methodology for understanding how likely an aerial vehicle will be able to complete a mission, and thus establish or define an acceptable level of mission or safety risk. However, existing modeling techniques are only used in development that is in early stages and provide a static reliability model. During a sustainment phase of the aerial vehicle, the static reliability models remain unchanged and are not updated to reflect new information realized during use and/or deployment of the aerial vehicle. In some instances, technical performance measures (TPMs) such as Mean Time Between Failure (MTBF), Mission Critical Rate, and Availability metrics are available. These TPMs are derived from field recorded maintenance actions and are published for customer consumption based on a predetermined frequency defined by the program. TPMs are a snapshot in time restricting operations to a more reactive than a proactive construct. However, reported TPMs do not provide a user real time platform specific reliability, remaining useful life, and influences from mission type, exposure time, and other external factors. Reliability modeling can use an exponential distribution that factors in latency, detectability, and duty cycle throughout a mission profile. However, the established reliability assumes a system or component of the aerial vehicle is new with no regard to degradation over time. Reliability Centered Maintenance (RCM) and Condition Based Maintenance Plus (CBM+) can be used to improve the life cycle of platforms; however, these approaches are limited to individual systems, and do not allow for complete vehicle reliability evaluation. Systems are becoming more complex with the incorporation of integrated vehicle health management (IVHM) constructs to provide real time diagnostics and prognostics in an effort to improve operational availability. Such technologies provide opportunities for deriving real time and meaningful health of the system during the entire life cycle through a dynamic reliability construct. Dynamic reliability can be utilized in modeling factors using conditional probability based on the remaining useful life of equipment, degradation of redundant system paths, and the ability of the equipment to complete a specified mission. There are opportunities to account for the reliability growth of the platform and leverage Failure Reporting and Corrective Action System (FRACAS) to influence mission modeling.”) To this end, Plawecki presents a method for more accurate equipment modelling by integrating real-time reliability modelling. ([Col 3 line 62- Col 4 line 11] “Reliability Centered Maintenance (RCM) and Condition Based Maintenance Plus (CBM+) can be used to improve the life cycle of platforms; however, these approaches are limited to individual systems, and do not allow for complete vehicle reliability evaluation. Systems are becoming more complex with the incorporation of integrated vehicle health management (IVHM) constructs to provide real time diagnostics and prognostics in an effort to improve operational availability. Such technologies provide opportunities for deriving real time and meaningful health of the system during the entire life cycle through a dynamic reliability construct. Dynamic reliability can be utilized in modeling factors using conditional probability based on the remaining useful life of equipment, degradation of redundant system paths, and the ability of the equipment to complete a specified mission. There are opportunities to account for the reliability growth of the platform and leverage Failure Reporting and Corrective Action System (FRACAS) to influence mission modeling.”) Ultimately, one of ordinary skill in the art would have recognized that combining Plawecki with Grefen and Wang, particularly the more accurate dynamic reliability modeling disclosed therein, would result in an overall more accurate and fully-featured equipment modelling system
Claim 9. The elements of claim 9 are substantially the same as those of claim 2. Therefore, the elements of claim 9 are rejected due to the same reasons as outlined above for claim 2.
Claim 4. Grefen teaches wherein a method of the behavior attribute modeling of simulation entity comprises: ([Col 17 line 37-45] “As shown in FIG. 13, the modeling engine 12 executes a step S24, by running the function use module 32, to model a state transition in the at least one state model Σi• from a source state zi•a to a target state zi•t by a functional model representing a data flow model according to meta features, target feature, and/or actual features as explained above. Here, the data flow model describes a control flow operating on meta data and a data flow operating on data reflecting target or actual features.”) ([Abstract] “Modelling of distributed event-discrete systems using digital twins. In more detail, the present disclosure relates to the field of modeling distributed event-discrete systems using digital twins for subsequent use of the models during real time control of distributed even-discrete systems.” [Col 11 line 51-56] “Here, the functional model Φex,i•at represents a meta model of a state transition triggered by at least one external event relevant for a specific meta object type MO•. Further, it describes a data flow model according to different levels of data abstraction, i.e. with respect to meta features, target feature, and/or actual features.” [Col 5 line 11-26] “In view of the above, events are classified into three classes: A first class relates to internal events occurring within a subsystem of the distributed event-discrete system without external transmission of messages. A second class relates to sending events occurring within a subsystem triggering the sending of messages from the subsystem to different subsystems of the distributed event-discrete system. From a global perspective they precede corresponding receiving events in different subsystems to which the messages are addressed. A third class relates to receiving events occurring within subsystems upon receipt of messages from different subsystems of the distributed event-discrete system. From a global perspective they succeed corresponding sending events in different subsystems from which the messages are sent.”)
Wang makes obvious modeling entity behavior through a behavior tree, ([Page 3 Par 2-4] “In order to achieve the above object, the present invention provides a military entity behavior simulation meta modeling method based on improved behavior tree, comprising the following steps: establishing a behaviour tree model xml description specification, according to the behaviour tree model xml description specification, establishing simulation behaviour model modelling tool; improving the behaviour tree, constructing a simulation behaviour tree framework; the simulation behaviour tree framework comprises a multi-tree structure relationship between the behaviour tree node and the behaviour tree node”) generating behavior modules, ([Page 14 Par 13] “S502, the xml of the behavioural simulation model is parsed and the simulation program is generated. using the simulation behavior module of the simulation engine based on the simulation behavior frame of the improved behavior tree, loading the behavior model xml file, analyzing the behavior model and generating the corresponding simulation program, executing the simulation program to realize the behavior simulation and operation.”)
Claim 10. The elements of claim 10 are substantially the same as those of claim 4. Therefore, the elements of claim 10 are rejected due to the same reasons as outlined above for claim 4.
Claim 5. Plawecki teaches wherein a method of the task reliability modeling comprises: modeling a reliability of equipment task execution through a reliability block diagram algorithm, and generating entity model task reliability module. ([Col 1 line 19-21] “A reliability block diagram (RBD) is a diagrammatic method for showing how component reliability contributes to a success or failure.” [Col 10 line 38- 45] “The reliability calculator 206 can include a dynamic reliability model 208 for each aerial vehicle that can provide a different level of abstractness of the aerial vehicle. In some examples, the dynamic reliability model 208 can include one or more predefined models (e.g., constructed at a reliability modeling stage), such as RBDs, FTAs, functional models, or a combination thereof that can be updated as disclosed herein to provide for dynamic reliability modeling.” [Col 19 line 43 – Col 20 line 21] “FIG. 4 is an example of a dynamic reliability model 400. The dynamic reliability model 400 can be generated for a system of an aerial vehicle. By way of example, the dynamic reliability model 400 can be a dynamic RBD model. The dynamic reliability model 400 can model reliability of components of the system. Each component can be represented in the dynamic reliability model 400 as a block diagram 402-418 and in some examples can be referred to as a node. Each node 402-418 can include a node reliability value representing an availability of a respective component of the system. Thus, each node 402-418 can represent an availability (e.g., a success or failure rate) of the respective component of the system. By way of example (referred to herein as the given example), at 406, the node reliability value can be a conditional node reliability value. In the given example, at remaining block diagrams 402-404 and 408-418, respective node reliability values can also be conditional reliability values for respective systems. In some examples, the dynamic reliability model 400 can be updated via the model adjustment engine 210, as disclosed herein. For example, the model adjustment engine 210 can be configured to update a respective node reliability value of a corresponding block diagram 402-418 based on the component reliability and biasing data 212 and 214 provided by the machine learning library 216, as shown in FIG. 2. By way of example, the model adjustment engine 210 can be configured to update the block diagram 404 to “0.50.” In some examples, the dynamic reliability model 400 can be updated following each mission of the aerial vehicle by the model adjustment engine 210 based on the component reliability and biasing data 212 and 214 provided by the machine learning library 216. Thus, the dynamic reliability model 400 can be updated continuously for the aerial vehicle. In some examples, the reliability calculator 206 can be configured to execute the dynamic reliability model 400 to compute a system reliability for the system of the aerial vehicle. The system reliability can be representative of an availability or a probability that the system of the aerial vehicle will not fail during the user-specified mission. In the present example of FIG. 4, the system reliability for the system of the aerial vehicle is 0.47. As disclosed herein, the reliability calculator 206 can be programmed to determine a vehicle reliability indicative of an availability or a probability that the aerial vehicle will not fail during the mission based on the system reliability for each system of the aerial vehicle.”)
Claim 6. Grefen teaches ([Col 8 line 35-45] “These different types of abstraction for state representation according to the present invention allow for a significant reduction of complexity in the handling of the process control of the distributed event-discrete system. The reason for this is that while, e.g. the target of a sub system used to specify a control behavior might be in the real-time domain and thus be of infinite number of values. Nevertheless, on abstraction of a way of such a real range into meta level types of, e.g. low speed, medium speed, high speed, will then lead to a reduction of complexity in the handling of, e.g. a conveyer line as described above.”) and the behavior modules ([Col 17 line 37-45] “As shown in FIG. 13, the modeling engine 12 executes a step S24, by running the function use module 32, to model a state transition in the at least one state model Σi• from a source state zi•a to a target state zi•t by a functional model representing a data flow model according to meta features, target feature, and/or actual features as explained above. Here, the data flow model describes a control flow operating on meta data and a data flow operating on data reflecting target or actual features.”)
Wang makes obvious wherein a method of the simulation entity model binding processing comprises: binding elements corresponding to a task being performed and the binding is achieved through an association model globally unique identifier (GUID). ([Page 12 Par 4] “b) the behaviour model manager is responsible for registering the behaviour tree model, wherein the behaviour tree node and the pre-set condition are generated to the corresponding behaviour tree node type plant and the pre-condition type plant to realize, and binding the behaviour tree model to the corresponding entity model;” [Page 9 Par 4 – Page 10 Par 1] “
<BehaviourNodeID= "20" Name= "Processing small repair start event control node" Description = " parallel control nodes of the behavioural tree, The control node "Type=" BehavNodeB"FinishedCondition= "k_PFC-AND" >
<BehaviourNodeID= "21" Name= "Processing small repair start event action" Description = "Leaf node of behavior tree, Processing Off-modification Start Incident Action" Type= "PropertyChangeAction" > >
<Preconditions>
<Presence tionType= "StringCompare" Operation= "EQUAL" LProperty= "EventType" RProperty = "Little Re-start Event" Source = "EventType" RProperty = "EventType" Source = "EventType" Source = "EventType" Source = "EventType" Source = "EventType" RProperty = "EventType" Source = "EventType" Source = </Precondition> Event "
<Presence tionType= "StringCompare" Operation= "EQUAL" LProperty = "Equipment State" RProperty= "Waiting" Source= "Entity" </Precondition>
<Precondition Type= "PropertyCompare" Operation= "EQUAL" LProperty= "EntityId" RProperty= "Id" Source = " Current Event-Entity</Precondition>
</Preconditions>
<ActionType= "PropertyChange" Name = "Processing small repair start event action, setting equipment state is small repair, actual small repair interval is set zero" > >
<InputParamList>
</InputParamList>
<OutputParamList>
<ParamName = "Equipment state" Type= "STRING" Value= "MinorRepair" ></Param>
<ParamName = "actual minor repair interval" Type= "INT" Value = "0" ></Param>
</OutputParamList>
<Actuator>
<Actuator Model
GUID= " 1F2504E0-4F59-11D3-9A0C-0305E82C3301
Type= "PropertyChange" Name = " Processing Oudix Start Event Action
"</ActuatorModel>
</Actuator>
</Action>
</BehaviourNode>
<BehaviourNodeID= "22" Name= "generating small repair ending event action" Description = "behavior tree leaf node, generating small repair ending event action" Type= "EventProduceAction" >
<Preconditions>
<Presence tionType= "StringCompare" Operation= "EQUAL" LProperty= "EventType" RProperty = "Little Re-start Event" Source = "EventType" RProperty = "EventType" Source = "EventType" Source = "EventType" Source = "EventType" Source = "EventType" RProperty = "EventType" Source = "EventType" Source = </Precondition> Event "
<Presence tionType= "StringCompare" Operation= "EQUAL" LProperty = "Equipment State" RProperty= "MinorRepair" Source = "EQUAL". Entity "</Precondition>
<Precondition Type= "PropertyCompare" Operation= "EQUAL" LProperty= "EntityId" RProperty= "Id" Source = " Current Event-Entity</Precondition>
</Preconditions>
<ActionType= "EventProduce" Name = "The Action of the End Event of the Small Repair" > >
<InputParamList>
<ParamName = "Event trigger time delay" Type="INT "Value=" 15 "Unit=" Tie"</Param>
</InputParamList>
<OutputParamList>
<ParamName = "Event Name" Type= "STRING" Value = "Little Sending Event" ></Param>
</OutputParamList>
<Actuator>
<Actuator Model
GUID= " 1F2504E0-4F59-11D3-9A0C-0305E82C3301
Type= "EventProduce" Name = " The Action of the Event of Little Fitting
"</ActuatorModel>
</Actuator>
</Action>
</BehaviourNode>
</BehaviourNode>
[Examiner’s note: the above code shows behavior elements associated with model entities using GUIDs])
Plawecki makes obvious associating elements corresponding to a task being performed as well as task reliability modules ([Col 20 line 53- Col 21 line 12] “By way of example, each dynamic reliability model 502-506 can be a dynamic RBD model. Each dynamic reliability model 502-506 can model a reliability of a respective aerial vehicle. Each dynamic reliability model 502-506 can include block diagrams also known as nodes representative of systems of the aerial vehicle. For example, each system can be represented in the dynamic reliability model 400 as a corresponding node that can include multiple system components, labeled “System A,” “System B,” “System C,” and “System D” in FIG. 5. In other examples, at least some of the dynamic reliability models 502-506 can include more or fewer systems as shown in the example of FIG. 5. In some examples, at least one of the systems of a corresponding dynamic reliability model 502-506 can correspond to the system disclosed herein with respect to FIG. 4. Each node of FIG. 5 of each dynamic reliability model 502-506 can include or be associated with a node reliability value representing an availability (e.g., probability) for a respective system of the aerial vehicle. By way of example, the node reliability value can correspond to a conditional reliability value for the respective system. In some examples, the reliability calculator 206 can be configured to execute each dynamic reliability model 502-506 to compute a vehicle reliability value for each aerial vehicle. The vehicle reliability value for each aerial vehicle can be representative of an availability (e.g., probability) of the respective aerial vehicle during the mission.”)
(3) Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Grefen (US 11562112 B2) in view of Wang (CN 114201885 A) in further view of Plawecki (US 12296978 B1) in addition to Murty (US 20090259683 A1)
Claim 3. Grefen teaches wherein the physical attribute modeling of simulation entity ([Col 8 line 35-45] “These different types of abstraction for state representation according to the present invention allow for a significant reduction of complexity in the handling of the process control of the distributed event-discrete system. The reason for this is that while, e.g. the target of a sub system used to specify a control behavior might be in the real-time domain and thus be of infinite number of values. Nevertheless, on abstraction of a way of such a real range into meta level types of, e.g. low speed, medium speed, high speed, will then lead to a reduction of complexity in the handling of, e.g. a conveyer line as described above.”)
Wang makes obvious ([Page 8 Par 15] “attribute explanation value type constraint or value domain Category Model Category enumeration (Behaviour, Entity) GUID behaviour model unique identifier GUID 16-ary digital symbol string Type behavioural model type enumeration (BehaviourTree, BaseBehaviour) Name behaviour model name Character string string is 4 character coding” [Examiner’s note: this passage is a translation of the table at [0055] on Page 7 of the original application. (Behaviour, Entity) and (BehaviourTree, BaseBehaviour) are enumeration type attribute values) ([Page 12 Page 5] “behaviour factory using clone method according to the registered behaviour model to create corresponding behaviour instance, and binding entity instance, and the behaviour instance manager using behaviour set class to manage;”) ([Page 8 Par 15] “attribute explanation value type constraint or value domain Category Model Category enumeration (Behaviour, Entity) GUID behaviour model unique identifier GUID 16-ary digital symbol string Type behavioural model type enumeration (BehaviourTree, BaseBehaviour) Name behaviour model name Character string string is 4 character coding” [Examiner’s note: this passage is a translation of the table at [0055] on Page 7 of the original application (Page 24 of the supplied combined translation+original document). (Behaviour, Entity) and (BehaviourTree, BaseBehaviour) are enumeration type attribute values)
The combination of Grefen, Wang, and Plawecki does not explicitly teach wherein the system comprises attribute types of basic type and compound type; the compound type comprises entity type, and user-defined type; the entity type comprises an entity primary key, used for indicating an inter-entity relationship among entities, comprising a mounted entity, an assembled entity to a present entity, or an entity that the present entity is affiliated to, then a corresponding entity is available through the entity primary key; and the user-defined type comprises an attribute list, the attribute list is commonly used by users and is convenient for attribute reuse.
Murty makes obvious wherein the system comprises attribute types of basic type and compound type; ([Par 55] “An object-relational mapping system also can model attributes of an entity to information regarding a record in a relational data table. These attributes are known in the art as either a "fundamental" type attribute or a "composite" type attribute.”) the compound type comprises entity type, ([Par 59- 60] “A "composite" object type is represented as a class in the object environment. For example, com.example.util.Address is a collection of three attributes of fundamental type. For example, as shown in the object code 301 in FIG. 3, the object property address has three attributes, city, street, and zipcode. Such attributes of composite types are mapped to multiple columns. The xml code snippet
TABLE-US-00005 <component name="address" class="com.example.util.Address" > <property name="street" type="string" column=" ADD_STREET"/> <property name="city" type="string" column.sup.=" ADD_CITY" /> <property name="zipcode" type="string" column=" ADD_ZIPCODE" /> </component>
creates the mapping between the columns ADD_STREET, ADD_CITY, and ADD_ZIPCODE in the relational data table and the object property address.
"Entities" are persistent types that represent first-class business objects. In other words, there may be some types (or classes) that are more important then others, and those types of objects may be known as "first-class" business objects. For example, the object com.example.entities. User is a first-class business object that has an associated table USER in the database. There also are value types such as java.lang.String and com.example.util.Address that do not have an associated table. Thus, two users having the same address will refer to two different instances of com.example.util.Address, and modifying Joe's zipcode does not change the zipcode for Jane.” and user-defined type; ([Par 62] “In addition to having simple attributes, an entity can have attributes having a collection of values. For example a user can have multiple nicknames or multiple secondary addresses or multiple secondary nationalities. Such attributes are usually modeled as a collection in the object environment and a secondary table in a database. For example, the software code snippet 1001 in FIG. 10 depicts an attribute nicknames whose values comprise a list of fundamental type <string>. See also FIG. 11, which depicts USER table 1101 and USER_NICKNAMES table 1102, and Hibernate XML code snippet 1201 in FIG. 12, which models the object nicknames on the data in the relational tables 1101 and 1102 shown in FIG. 11. As seen in FIG. 11, the entry for "William", which corresponds to ID 44 in USER table 1101, has multiple values, i.e., a collection or list of values in USER_NICKNAMES table 1102. The Hibernate XML code snippet shown in FIG. 12 also reflects that the values for the attribute nicknames for entity com.example.entities.User comprise a list, i.e., multiple values.”) the entity type comprises an entity primary key, used for indicating an inter-entity relationship among entities, comprising a mounted entity, an assembled entity to a present entity, or an entity that the present entity is affiliated to, then a corresponding entity is available through the entity primary key; ([Fig. 32] Shows the code view of the User and Configuration entities. Note that both contain key elements. These keys are used to uniquely identify the entities for referencing [Par 108-109] “The fields of ATTRIBUTE table 1401 shown in FIG. 14 include: ID 1401a: An identifier for the attribute (a primary key). The ID field is used in attribute value tables like EXT_USER where the values of the attributes for com.example.entities.User are stored.”) and the user-defined type comprises an attribute list, the attribute list is commonly used by users and is convenient for attribute reuse. ([Par 62] “In addition to having simple attributes, an entity can have attributes having a collection of values. For example a user can have multiple nicknames or multiple secondary addresses or multiple secondary nationalities. Such attributes are usually modeled as a collection in the object environment and a secondary table in a database. For example, the software code snippet 1001 in FIG. 10 depicts an attribute nicknames whose values comprise a list of fundamental type <string>. See also FIG. 11, which depicts USER table 1101 and USER_NICKNAMES table 1102, and Hibernate XML code snippet 1201 in FIG. 12, which models the object nicknames on the data in the relational tables 1101 and 1102 shown in FIG. 11. As seen in FIG. 11, the entry for "William", which corresponds to ID 44 in USER table 1101, has multiple values, i.e., a collection or list of values in USER_NICKNAMES table 1102. The Hibernate XML code snippet shown in FIG. 12 also reflects that the values for the attribute nicknames for entity com.example.entities.User comprise a list, i.e., multiple values.”)
Murty is analogous art because it is within the field of system modelling. It would have been obvious to one of ordinary skill in the art to combine it with Grefen, Wang, and Plawecki before the effective filing date. One of ordinary skill in the art would have been motivated to make this combination in order to make the modelling system more easily extensible. As noted by Murty, relational modeling systems, such as the one described in Grefen, can suffer from difficultly adapting and extending the features of entities and elements after the initial setup of the system ([Par 2-7] “In today's information-driven economy, the ability of an enterprise to efficiently store, update, and use information can be critical to the enterprise's ability to serve its customers and compete in the economy. … An entity such as a business enterprise can model a concept of an entity relating to that enterprise and use such modeling information to maintain and use information relating to that entity. Some examples are of entities that can be modeled by an enterprise include user, bill of materials etc. An enterprise can maintain and model data relating to these entities in either a relational programming environment or in an object-oriented environment such as the commonly used Java environment. In a relational system, data is maintained in one or more data tables, where each row refers to an instance of the entity. In an object system, an entity concept is modeled using classes, where each instance of the class--called an object--refers to an instance of the entity, with characteristics of those objects being known as "attributes" of that object. In order to bridge the two systems, object-relational modeling (ORM) techniques are used to enable an enterprise to use data maintained in relational databases in an object-oriented environment … The ability to work with data in both a relational and object-oriented system can be very important to an enterprise's business. For example, a provider of software as a service ("SaaS provider") may have to install an enterprise system and provide service to multiple customers, where each customer is an enterprise in its own right. In such an environment, the system should be able to let each customer define their own extensions to the model, add their own business logic and define their own rules for attribute value computations. Ideally, the system should let each customer manage the extensions and business logic on their own, without affecting other customers in functionality and performance. To this end, an enterprise may make a large investment in an enterprise data management system that meet almost all its objectives except a few. To meet the last mile of its objectives may require a small extension to the data model, like having an additional attribute for an entity with some additional business logic. The usual solution is for the enterprise to continue with the deficient product or request the creator of the product to add additional attributes to the entity as part of the next release. Such requests may not be appropriate in a general setting, i.e. the request is very specific to the internal running of the requesting enterprise. In many cases, the enterprise data management system has to work along with other systems that are already installed and in use. For a new enterprise system to efficiently blend into an existing enterprise ecosystem, the two systems must be integrated. Such integration often is accomplished by using daily or hourly computer synchronization tasks, which, however, represent costly and inefficient use of the enterprise's computing resources.”) This lack of easy extensibility can make it difficult to add new features to such a system, for example adding a new type of equipment that requires specialized features when modeling it. To this end, Murty presents a method that allows for the easy extensibility of model entities ([Par 9] “Aspects herein relate to a system and method to permit an enterprise to define one or more additional "extension" attributes of an its entities in addition to the core attributes already defined in the enterprise's database and to use object-relational mapping (ORM) techniques to determine the value of such extension attributes. Other aspects relate to a system and method to permit the enterprise to develop one set of business logic to access and use both the core and extension attributes without having to distinguish between the two”) Overall, one of ordinary skill in the art would have recognized that combining Murty with Grefen, Wang, and Plawecki would allow for easier, deeper customization of the modelling system for any given use case.
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
/JOHN E JOHANSEN/Examiner, Art Unit 2187