DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
2. Claims 1-2, 5-13 and 16-35 are currently pending. Claims 1-2, 7 and 13 have been amended. Claims 20-35 have been added as new claims. Claims 3-4 and 14-15 have been canceled. Claims 1-2, 5-13 and 16-35 have been rejected.
Status of the Application
3. Claims 1-2, 5-13 and 16-35 are currently pending and have been examined in this application. This communication is the first action on the merits.
Response to Amendments
4. Applicant’s amendment filed on 06/12/2026 necessitated new grounds of rejection in this office action.
Foreign Priority
5. The Examiner has noted the Applicants claiming Priority from Provisional Application 63/176,198 filed on 04/16/2021, Provisional Application 63/282,507 filed on 11/23/2021, Provisional Application 63/299,710 filed on 01/14/2022, Provisional Application 63/302,013 filed on 01/21/2022, Continuation of PCT/US2022/025103 filed on 04/15/2022 and Continuation of PCT/US2022/025103 filed on 04/15/2022. Additionally, Examiner notes receipt is acknowledged of papers submitted under 35 U.S.C. § 119(a)-(d), which papers have been placed of record in the file. Therefore, the earliest effective filing date of this case for this application is 04/16/2021.
Continued Examination under 37 CFR 1.114
6. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06/12/2026 has been entered.
IDS Statements
7. The 1 Information Disclosure Statement (IDS) filed on 06/12/2025 complies with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 and are considered by the Examiner.
Response to Arguments
8. Applicant’s arguments, see page 10-13 of 18 filed on 06/12/2025, with respect to the previous 35 U.S.C. § 102 (a) (2) Rejections for Claims 1-5 and 19 have been fully considered and are found to be not persuasive. Applicant’s arguments with respect to Claims 1-2, 5-13 and 16-35 have been considered, but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
9. Applicant’s arguments, see page 13-16 of 18 filed on 06/12/2025, with respect to the previous 35 U.S.C. § 103 Rejections for the remainder of the claims have been fully considered and are found to be not persuasive. Applicant’s arguments with respect to Claims 1-2, 5-13 and 16-35 have been considered, but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
10. Additionally, due to Applicant’s proposed claim amendments, Examiner adds a 35 U.S.C. § 101 Rejections for Claims 1-2, 5-13 and 16-35. See the 35 U.S.C. § 101 Claim Rejections Section shown below.
Claim Rejections - 35 USC § 101
11. 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.
12. Claims 1-2, 5-13 and 16-35 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-2, 5-13 and 16-35 are each focused to a statutory category namely a “system” or an “apparatus” (Claims 1-2, 5-13 and 16-32) and a “method” or a “process” (Claim 33-35). We proceed onto analyzing the claims with respect to Step 2A Prong 1 shown below.
Step 2A Prong One: Independent Claims 1 and 33 recite limitations that set forth the abstract idea(s), namely (see in bold except via strikethrough):
“a set of digital products , and with product instructions, wherein the set of digital products includes a consumer product that is passed through a supply chain” (see Independent Claim 1);
“” (see Independent Claim 1);
“ product instructions to encode representing the set of digital products, wherein includes a value chain detect one or more supply chain disruptions, , in response to the consumer product experiencing a disruption while being passed through the supply chain” (see Independent Claim 1);
“identify at least one of the one or more supply chain disruptions using the value chain ” (see Independent Claim 1);
“update a subset to represent the identified at least one supply chain disruption by modifying one or more parameters” (see Independent Claim 1);
“determine a metric of the disruption based at least partially on the updated subset” (see Independent Claim 1);
“monitoring a consumer product being passed through a supply chain” (see Independent Claim 33);
“encoding representing a set of digital products including the consumer product” (see Independent Claim 33);
“detecting one or more supply chain disruption” (see Independent Claim 33);
“in response to the consumer product experiencing a disruption while being passed through the supply chain” (see Independent Claim 33);
“identifying at least one of the one or more supply chain disruptions” (see Independent Claim 33);
“updating a subset to represent the identified one or more supply chain disruptions by modifying one or more parameters” (see Independent Claim 33);
“determining a metric of the one or more supply chain disruptions based at least partially on the updated subset” (see Independent Claim 33).
Here, for Independent Claim 1, these claim limitation steps are directed to the abstract idea of the collection, analysis, and generation of information, rules for conducting a business, and the mathematical concept of calculating metrics.
For instance, the step of “identifying supply chain disruptions” recites the concept of monitoring, detecting, and identifying occurrences that delay or interrupt a process (mitigating risk). This falls under the Certain Methods of Organizing Human Activities (specifically, commercial or legal interactions and mitigating risk/fundamental economic principles). The step of “Updating a Subset of Digital Twins (Modifying Parameters)” recites the concept of generating, updating, and maintaining a data model or database representation based on new information. This falls under the Mental Processes Category of (handling information, performing calculations, or manipulating data in the human mind). Thirdly, the step of “determining a disruption metric” based on updated subset recites the concept of performing calculations, evaluating rules, and applying mathematical relationships to determine a value. This falls under the “Mathematical Concepts” category (mathematical relationships or calculations). Courts frequently reject claims involving computers that merely automate tasks historically performed by humans or organize business data. A digital supply chain twin system represents the virtual tracking and analysis of logistics data. When these processes describe abstractly evaluating risk, performing data manipulation, and applying computational metrics, they are categorized as abstract ideas.
Here, for Independent Claim 33, these claim limitation steps are directed to the abstract idea of collecting, analyzing, and digitally modeling information regarding a system's status.
For instance, the first step of “Monitoring, Detecting, and Identifying Disruptions” recites tracking the status of a physical object, evaluating data, and noticing changes against a standard (e.g., condition monitoring or observing logistical milestones). This falls under the Certain Methods of Organizing Human Activities (specifically managing a commercial or business process, tracking rules, or gathering information) category. Secondly, the step of “encoding digital twins and updating parameters” recites the concept of creating a virtual representation of a physical thing, and updating that virtual model's parameters when new information comes in. This falls under the Mental Processes (performing calculations, modeling, and data manipulation) category and Mathematical Concepts (using algorithms/formulas to update variables) category. Thirdly, the step of “determining a disruption metric” recites assessing data, generating a score, or calculating a value to measure the severity or impact of an event. This falls under the Mathematical Concepts (executing equations) category and Mental Processes (evaluating data or forming an observation) category.
Therefore, these abstract idea limitations (as identified above in bold), under their broadest reasonable interpretation of the claims as a whole, cover performance of their limitations as “Certain Methods of Organizing Human Activities” which pertains to (1) fundamental economic principles or practices (including mitigating risk) or (2) managing personal behavior (including teachings or following rules or instructions) and additionally or alternatively as “Mathematical Concepts” which pertains to (3) mathematical calculations.
Additionally, or alternatively, these abstract idea limitations (as identified above in bold), under the broadest reasonable interpretation of the claims as a whole, cover performance of their limitations as “Mental Processes” which pertains to (4) concepts performed in the human mind (including observations or evaluations or judgments) or (5) using pen and paper as a physical aid, in order to help perform these mental steps does not negate the mental nature of these limitations. The use of "physical aids" in implementing the abstract mental process, does not preclude these claims from reciting an abstract idea. See MPEP § 2106.04(a) III C.
That is, other than reciting the additional elements of (e.g., “product network interface” & “product memory” & “product processor” & “product network interface” & “product network control tower” & “digital twin system” & “value chain monitoring system” & “set of digital twins” & “control tower instructions” & “digital products”) nothing in the claim elements precludes the steps from being performed as “Certain Methods of Organizing Human Activities” which pertains to (1) fundamental economic principles or practices (including mitigating risk) or (2) managing personal behavior (including teachings or following rules or instructions) and additionally or alternatively as “Mathematical Concepts” which pertains to (3) mathematical calculations and additionally or alternatively as “Mental Processes” which pertains to (4) concepts performed in the human mind (including observations or evaluations or judgments) or (5) using pen and paper as a physical aid.
Therefore, at step 2a prong 1, Yes, Claims 1-2, 5-13 and 16-35 recite an abstract idea. We proceed onto analyzing the claims at step 2a prong 2.
Step 2A Prong Two: With respect to Step 2A Prong Two of the eligibility inquiry (as explained in MPEP § 2106.04(d)), the judicial exception is not integrated into a practical application. Independent Claim 1 recites additional elements directed to: (e.g., “product network interface” & “product memory” & “product processor” & “product network interface” & “product network control tower” & “digital twin system” & “value chain monitoring system” & “set of digital twins” & “control tower instructions” & “digital products”). Independent Claim 33 recites additional elements directed to: (e.g., “set of digital twins” & “digital twin parameters” & “digital products”). These additional elements have been considered individually and in combination, but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment. See MPEP § 2106.05(f) and MPEP § 2106.05(h).
Independent Claim 1 when considering the additional elements in view of the claim limitations both individually and as an ordered combination, the amended claim adds hardware elements: "product memory," "product network interface," "product processor," "control tower memory," "control tower network interface," and "control tower processor." Under USPTO guidance, merely appending generic, off-the-shelf computer components acting in their normal, expected manner to execute an abstract idea does not integrate that idea into a practical application. The claim does not improve the functionality of the computer components, processors, or network interfaces themselves. It does not speed up processing, optimize bandwidth, or secure data transmission. The hardware is simply used as a tool to run the digital twin software. The software elements ("product instructions," "control tower instructions," "value chain monitoring system") are defined purely by their functional results (what they do—detect, identify, update, determine) rather than a specific structural or algorithmic implementation (how they do it). The problem being solved (measuring supply chain disruptions) is an economic, business, and logistical hurdle, not a technical engineering challenge in computer hardware or network physics. Claim 1 does not integrate the abstract idea into a practical application.
Independent Claim 33 when considering the additional elements in view of the claim limitations both individually and as an ordered combination, the method fails to integrate the abstract idea into a practical application. The claim is written in purely functional, result-oriented prose without any structural hardware ties or specific algorithmic definitions. It describes a business problem (tracking and measuring supply chain disturbances) being solved by generic computer functions (encoding, updating, determining), which does not cross the threshold of a practical technical application. Claim 33 does not integrate the abstract idea into a practical application.
In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception. Therefore, at step 2a prong 2, Claims 1-2, 5-13 and 16-35 are directed to the abstract idea and do not recite additional elements that integrate into a practical application.
Step 2B: (As explained in MPEP § 2106.05), it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Independent Claim 1 recites additional elements directed to: (e.g., “product network interface” & “product memory” & “product processor” & “product network interface” & “product network control tower” & “digital twin system” & “value chain monitoring system” & “set of digital twins” & “control tower instructions” & “digital products”). Independent Claim 33 recites additional elements directed to: (e.g., “set of digital twins” & “digital twin parameters” & “digital products”). These elements have been considered individually and in combination, but fail to add significantly more to the claims because they amount to using computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (computing environment) and does not amount to significantly more than the abstract idea itself. See MPEP § 2106.05 (h) and See MPEP § 2106.05 (f). Notably, Applicant’s Specification suggests that the claimed invention relies on nothing more than a general-purpose computer executing the instructions to implement the invention (see at least Applicant’s Specification ¶ [1148]: “In general, the components of the chip 9100 may comprise one or more general-purpose processing chips that are configured using software instructions or other code, and/or may comprise special-purpose processing chips (e.g., ASICs) customized to perform the functions described herein.” and see at least Applicant’s Specification ¶ [1153]: “The processing core(s) 9106 may comprise general-purpose and/or special-purpose processors. In embodiments, the processing core(s) 9106 may use serial, parallel, and/or other processing techniques to accomplish the functions described herein.”)
Independent Claim 1 when considering the additional elements in view of the claim limitations both individually and as an ordered combination, the amended claim adds hardware elements such as Processors, memory, and network interfaces: These are standard, generic hardware components executing routine computing functions. The additional element of the Value chain monitoring system: Functionally performs the task of data collection and event detection. The additional element of the Digital twin system: Serves as a digital database or software model that updates records and computes data, which are routine data-processing tasks. The ordered combination of these elements follows a standard data-processing pipeline: hardware captures data and network transmit data and control tower processes data and database updates fields and processor outputs a metric. This represents the conventional automation of a manual business tracking process on a standard distributed computer network. It does not offer an unconventional technical architecture or a unique physical/software synergy. Ending the sequence by "determining a metric" is an analytical step that does not result in a physical transformation, an automated corrective action in the supply chain, or a non-abstract technical output. The claim elements, both individually and as an ordered combination, do not establish an inventive concept. The claim simply instructs the practitioner to apply the abstract idea of supply chain modeling on generic digital product network hardware, rendering Independent Claim 1 patent ineligible under 35 U.S.C. § 101.
Independent Claim 33 when considering the additional elements in view of the claim limitations both individually and as an ordered combination, lacks an inventive concept. Both individually and as an ordered combination, the steps describe a routine data acquisition and recording process (gather data → update file → compute metric). Because the claim concludes with the passive step of "determining a metric," it constitutes insignificant post-solution analytical activity. Independent Claim 33 is patent ineligible under 35 U.S.C. § 101.
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrates the abstract idea into a practical application. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that, as an ordered combination, amount to significantly more than the abstract idea itself.
Dependent Claims 2, 5-13, 16-32 and 34-35 recite additional elements directed to: (e.g., “hierarchical digital twins” (see Dependent Claim 2) & “set of composite digital twins” (see Dependent Claim 2) & “a set of discrete digital twins” (see Dependent Claim 2) & “set of digital products” (see Dependent Claim 2) & “moving elements” (see Dependent Claim 5) & “playback interface” (see Dependent Claim 6) & “adaptive user interface” (see Dependent Claim 7) & “self-expanding digital twin” (see Dependent Claim 9) & “APIs” (see Dependent Claim 17) & “twin store market system” (see Dependent Claim 18) & “automated analysis modules” (see Dependent Claim 20) & “risk analysis modules” (see Dependent Claim 20) & “safety analysis modules” (see Dependent Claim 20) & “control decision module” (see Dependent Claim 21) & “data acquisition circuit” (see Dependent Claim 24) & “pattern recognition circuit” (see Dependent Claim 24) & “analysis response circuit” (see Dependent Claim 24) & “database” (see Dependent Claim 25) & “an expert system” (see Dependent Claim 26) & “supervised learning system” (see Dependent Claim 26) & “deep learning system” (see Dependent Claim 26) & “marketplace interface circuit” (see Dependent Claim 27) & “digital twin I/o system” (see Dependent Claim 27) & “standardized APIs” (see Dependent Claim 27) & “distributed ledger” (see Dependent Claim 27) & “monitoring layer” (see Dependent Claim 32) & “automated analysis modules” (see Dependent Claim 35) & “risk analysis modules” (see Dependent Claim 35) & “safety analysis modules” (see Dependent Claim 35), etc…), and when considered individually and as an ordered combination (as a whole) with the limitations recite the same abstract idea(s) as shown in Independent Claims 1 and 33 along with further steps/details that could be performed as “Certain Methods of Organizing Human Activities” which pertains to (1) fundamental economic principles or practices (including mitigating risk) or (2) managing personal behavior (including teachings or following rules or instructions) and additionally or alternatively as “Mathematical Concepts” which pertains to (3) mathematical calculations and additionally or alternatively as “Mental Processes” which pertains to (4) concepts performed in the human mind (including observations or evaluations or judgments) or (5) using pen and paper as a physical aid.
The following dependent claims add further specific data parameters, interfaces, or business features to the abstract framework of Independent Claims 1 and 33. They are analyzed collectively below because they all share a common legal failure under § 101.
Claim 2: Claim 2 (Hierarchical/Composite Twins): Directed to the abstract idea of organizing data structures into hierarchies or groupings.
Claim 5: Claim 5 (Modeling Traffic): Directed to the abstract idea of a mathematical or computational simulation of traffic.
Claim 6: Claim 6 (Playback Interface): Directed to the abstract idea of collecting, storing, and displaying historical data visually.
Claim 7: Claim 7 (Adaptive UI based on Proximity): Directed to the abstract idea of tailoring information display based on a user's location or identity (a standard business practice).
Claim 8: Claim 8 (Managing Twin Interactions): Directed to managing data relationships/interactions within a database.
Claim 9: Claim 9 (Self-Expanding Twin): Directed to automated database growth and field updates.
Claim 10: Claim 10 (Aggregating Performance Data): Directed to collecting, indexing, and grouping data fields (Electric Power Group).
Claim 11: Claim 11 (Matching Owners in a Market): Directed to a fundamental economic practice or commercial match-making.
Claim 12: Claim 12 (Locking Twin upon Security Threat): Directed to the generic concept of restricting access to data fields upon an event.
Claims 13 and 18: Claim 13 & 18 (In-twin Marketplace / Twin Store): Directed to fundamental economic practices (buying, selling, or offering services and rights).
Claim 16: Claim 16 (Offering Components): Directed to commercial transactions and product marketing.
Claim 17: Claim 17 (APIs to Marketplaces): Directed to the generic concept of transferring data between commercial entities or software architectures.
Claim 19: Claim 19 (Vehicle/Appliance/Wearable Field of Use): Restricts the abstract idea to generic commercial consumer product categories.
None of these claims integrate the abstract idea into a practical application. They introduce purely generic data structures (composite records, playback logs, data structures), conventional software features (user interfaces, APIs, marketplaces), or nominal business concepts. They do not optimize internal computer memory performance, nor do they improve network physical layers. For example, Claim 19 merely acts as a field-of-use limitation (restricting the data tracking to a vehicle or wearable), which courts have explicitly ruled cannot save a claim under Prong 2. These claims add only conventional software features or commercial concepts, failing Step 2B. Implementing a playback loop (Claim 6), a marketplace (Claims 13/18), or an API connection (Claim 17) relies entirely on routine, conventional, and off-the-shelf software tools executing as expected. They represent insignificant post-solution administrative or data-display activities that do not transform the underlying abstract idea into a technical invention. Claims 2, 5–13, and 16–19 remain patent ineligible under § 101.
Claims 20-21: Claims 20 & 21 (Analysis & Governance Modules): Directed to the abstract ideas of risk/safety analysis and enforcing compliance/governance rules (methods of organizing human activity).
Claim 22: Claim 22 (Product Testing Capabilities): Directed to the abstract idea of gathering and analyzing product performance or compliance data.
Claim 23: Claim 23 (Monitoring Congestion/Failure Events): Directed to the abstract idea of collecting and tracking logistics information (delays, product failures). These claims fail to integrate the abstract ideas into a practical application. The added modules ("risk analysis module," "control decision module") are defined purely by their functional objectives (e.g., "determine governance standards," "generate control decisions"). They fail to provide any specific, non-abstract code structure or algorithmic sequence explaining how these decisions are computed. They remain high-level automated business processes. These limitations describe routine analytical steps and fail Step 2B. Automating risk analysis, safety checks, or compliance auditing on a computer network is standard practice in modern enterprise software. The claims lack an unconventional technical hardware structure or an inventive algorithmic implementation, offering nothing more than an instruction to "apply" compliance tracking to the system. Claims 20–23 remain patent ineligible under § 101.
Claim 24: Claim 24 does not integrate the abstract concept into a practical application. Claim 24 recites mere instructions to apply a judicial exception MPEP § 2106.05 (f) or a limited field of use in a technological environment under MPEP § 2106.05 (h)). The claim fails to integrate the abstract idea into a practical application. The claim merely instructs the implementation of these abstract concepts on generic computer components (circuits, hardware processors) without meaningfully limiting them. The physical elements (sensors, data acquisition circuits) act as mere data-gathering mechanisms. The analysis, twin-updating, and routing adjustments are performed purely via generic automation and computation. Because the steps do not physically transform a tangible item or improve computer functionality, the abstract idea is not integrated into a practical application. The claim recites standard hardware components such as a "data acquisition circuit," a "pattern recognition circuit," and an "analysis response circuit." Under Step 2B, reciting generic, off-the-shelf computer components to execute an abstract mathematical/business idea does not transform the claim into a patent-eligible invention. There are no additional elements that amount to an "inventive concept." The use of a trained neural network, updating a digital representation, and re-routing based on calculated metrics are all routine, well-understood, and conventional activities in the fields of machine learning and supply chain logistics. As a result, the claim provides no meaningful limitation that prevents preemption of the underlying abstract ideas.
Examiner points to the Federal Circuit’s ruling in Recentive Analytics, Inc. v. Fox Corp., 134 F.4th 1205, 1212 (Fed. Cir. 2025), and cited by PTAB Appeal 2025-003304: “The requirements that the machine learning model be ‘iteratively trained’ or dynamically adjusted based on real time changes do not represent a technological improvement” at least because they are “incident to the very nature of machine learning”.
These findings of the abstract computer aided operations are corroborated by Brandan Artley, Training a Neural Network by Hand, towardsdatascience webpages, Jun 23, 2022, incorporated herein, disclosing that the training of a neural network by hand to solve a regression problem where the model continually improves its predictions to arrive at a highly accurate model.
Claim 25: Claim 25 does not integrate the abstract concept into a practical application. Claim 25 recites mere instructions to apply a judicial exception MPEP § 2106.05 (f) or a limited field of use in a technological environment under MPEP § 2106.05 (h)). The claim fails to integrate the abstract idea into a practical application. These steps fail to integrate these concepts into a practical application because they do not alter, control, or limit the technology in the physical realm. The phrase "maintain a database" refers to generic data storage, and "correlate" refers to standard mathematical/statistical comparison. The steps merely use a computer as a tool to perform these mental and mathematical processes faster, rather than specifying how the computer is specially programmed to improve a specific technological process (such as dynamically altering network routing or modifying a specific machine's output). Stating that you are using a computer or a database to do this is not "significantly more." The Supreme Court in the Alice decision made it clear that adding the words "apply it with a computer" or requiring generic computer components to implement an abstract idea is insufficient to save a claim. The additional elements—maintaining a database, correlating data, and making recommendations—are purely conventional. The use of routine data-gathering and standard correlation algorithms does not add an inventive component to the steps. If these claims were allowed, they would effectively preempt (monopolize) the very concepts of comparing past supply chain disruptions to current ones and suggesting mitigations, regardless of the software or technology used. Because the claims do not limit the method to a particular, unconventional physical machine or specific technical implementation, they preempt the basic idea itself.
Claim 26: Claim 26 does not integrate the abstract concept into a practical application. Claim 26 recites mere instructions to apply a judicial exception MPEP § 2106.05 (f) or a limited field of use in a technological environment under MPEP § 2106.05 (h)). The claim fails to integrate the abstract idea into a practical application. Using broad terms like "analyze real-time sensor data" only identifies the technological environment. It acts merely as data-gathering or "extra-solution activity". The steps do not apply the analyzed information to solve a specific, real-world technical problem (such as physically controlling a specific apparatus or altering a mechanical process). Without linking the analysis to a specific architectural improvement in how the circuit operates, or detailing a specific, unconventional transformation of the sensor data, the steps amount to a mere mental process or abstract mathematical concept. Therefore, they fail to integrate the abstract idea into a practical application. The use of an "expert system," "supervised learning," or "deep learning" represents well-known, generic computational techniques for classifying and analyzing data. Merely stating "analyze the real-time sensor data" using these known, off-the-shelf AI/ML frameworks requires no more than a generic, conventional computer or circuit to perform math. The claims fail to recite an unconventional step or a specialized improvement to computer/circuit functionality. Because the claim broadly sweeps up any circuit running any deep learning system to process sensor data, it effectively preempts the mathematical concept or abstract idea itself, restricting all practical uses of these algorithms in the specified field. Consequently, the elements do not amount to "significantly more."
Claim 27: The claim fails to integrate the abstract idea into a practical application. Although the claim introduces technical-sounding terms ("marketplace interface circuit," "digital twin I/O system"), these modules are defined strictly by their high-level business functions (what they achieve: maintaining a marketplace, executing standard APIs, managing smart contracts, and utilizing distributed ledger technology). The claim does not improve the underlying physics or mechanics of distributed ledgers or network protocols; it merely uses generic blockchain/distributed ledger technology as a tool to automate a commercial marketplace. Claim 27 does not integrate the abstract idea into a practical application. The claim elements, both individually and as an ordered combination, lack an inventive concept. Courts have consistently held that appending standard, conventional blockchain elements (distributed ledger technology) and business automation logic (smart contracts) to a commercial platform represents routine, conventional activity in modern software engineering. It amounts to nothing more than an instruction to "apply" the abstract idea of commercial transaction management using generic, state-of-the-art software mechanisms. Claim 27 is patent ineligible under § 101.
Claim 28: The claim fails to integrate the abstract idea into a practical application. The added "security monitoring circuit" is described via purely functional language ("detect security threats," "lock access," "restrict marketplace transactions"). The claim lacks any technical explanation, network topology, or cryptographic algorithm detailing how the circuit technically locks or isolates data. It remains a high-level software business rule appended to an unpatentable marketplace system (Claim 27). Claim 28 does not integrate the abstract idea into a practical application. The claim fails to provide an inventive concept. Restricting access to data records or suspending a user's transaction capability when a security breach is detected is conventional, routine data-management activity. Because it uses conventional logic without an unconventional hardware structure or software breakthrough, it fails to provide "significantly more." Claim 28 is patent ineligible under § 101.
Claim 29: The claim fails to integrate the abstract idea into a practical application. The system simply concludes by "generating corresponding alerts." Generating a notification or a passive status alert is treated by courts as insignificant post-solution data display. It does not trigger an automated technological correction or improve the underlying computer hardware. The claim lacks an inventive concept. Using standard computer code to send an alert or flag an error state when data parameters change is a fundamental function of any software tracking application. The ordered combination provides no inventive engineering breakthrough.
Claim 30: The claim fails to integrate the abstract idea into a practical application. "Providing visualization" on a user interface is a classic example of passive data presentation. It merely allows human operators to observe business events without providing an automated, physical, or technical solution to an underlying technical challenge. Claim 30 does not integrate the abstract idea into a practical application. The claim elements, both individually and as an ordered combination, add nothing inventive. Using standard graphics APIs, user interfaces, or monitoring layers to display supply chain assets or demand charts is entirely conventional. It represents standard post-solution data-display activity. Claim 30 is patent ineligible under § 101.
Claim 31: The claim fails to integrate the abstract idea into a practical application. The claim relies entirely on generic, functional, and result-oriented language ("analyze one or more variances," "determine an acceptable range using artificial intelligence," "predict correlated pain points"). It fails to provide a specific, non-abstract algorithmic structure explaining how the AI is trained, engineered, or structurally bound to improve a technical process. The output remains a passive data prediction regarding logistical metrics (production rate, shipping measures, transport duration). Claim 31 does not integrate the abstract idea into a practical application. The claim lacks an inventive concept under Step 2B. Simply appending generic "artificial intelligence" to execute standard predictive analytics and forecasting on statistical data sets does not provide an inventive concept. The ordered combination amounts to nothing more than an instruction to "apply" standard predictive models to data fields. Claim 31 is patent ineligible under § 101.
Claim 32: The claim fails to integrate the abstract idea into a practical application. While predicting maintenance needs touches upon a physical concept (machine failure), the claim ends strictly at the point of "formulating predictions." It does not take an automated physical corrective action—such as automatically generating a machine repair order, halting a machine circuit, or modifying operational physical parameters to prevent the failure. It remains a passive data calculation. Claim 32 does not integrate the abstract idea into a practical application. The claim elements lack an inventive concept. The steps of collecting data from a generic "monitoring layer," applying generic "predictive analytics," and printing or outputting a prediction represent the conventional data-processing pipeline. It lacks an unconventional hardware setup or a unique physical/software integration. Claim 32 is patent ineligible under § 101.
Claim 34: The claim does not integrate the exception into a practical application. Limiting an abstract data-collection method to specific fields of data (e.g., traffic delays or failure logs) does not change the fact that the claim is fundamentally about collecting data. It provides no automated technical override or physical machine controls. Claim 34 does not integrate the abstract idea into a practical application. The claim elements, ordered or separate, lack an inventive concept. Monitoring traffic congestion or tracking when an engine or device fails are long-standing, conventional commercial tasks. Automating these data streams on a generic computer system does not inject an inventive concept. Claim 34 is patent ineligible under § 101.
Claim 35: The claim fails to integrate the abstract idea into a practical application. The method uses purely functional language to describe software modules ("risk analysis modules," "safety analysis modules") executing standard administrative tasks. It provides no unique underlying hardware or system architecture improvement. Claim 35 does not integrate the abstract idea into a practical application. The claim lacks an inventive concept under Step 2B. Evaluating an ongoing problem against governance parameters and outputting a compliance report ("generating analysis outputs characterizing the metric") is basic post-solution administrative activity. It utilizes entirely conventional computing mechanisms to automate a corporate compliance procedure. Claim 35 is patent ineligible under 35 U.S.C. § 101. Claims 24-35 remain patent ineligible under § 101.
Therefore, the ordered combination of elements in the Dependent Claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Accordingly, the subject matter encompassed by the dependent claims fails to amount to a practical application or significantly more than the abstract idea itself. Therefore, under Step 2B, Claims 1-2, 5-13 and 16-35 do not include additional elements that are sufficient to amount to significantly more than the recited judicial exceptions. Thus, Claims 1-2, 5-13 and 16-35 are ineligible with respect to the 35 U.S.C. § 101 analysis.
Claim Rejections - 35 USC § 102
13. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
14. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
15. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
16. Claims 1-2, 5-11, 13, 16-26 and 29-35 are rejected under 35 U.S.C. 102 (a) (2) as being anticipated by US PG Pub (US 2022/0156665 A1) hereinafter Karsten Beth, et. al.
Regarding Independent Claim 1, Karsten Beth digital twin enabled digital product network system teaches the following limitations comprising:
- a set of digital products each having a product memory (see at least Karsten Beth: Fig. 1 & Fig. 26 & ¶ [0179-0180].), a product network interface (see at least Karsten Beth: Figs. 7-24 & ¶ [0049].);
- a product processor programmed with product instructions (see at least Karsten Beth: Fig. 1 & Fig. 26 & ¶ [0050].), wherein the set of digital products includes a consumer product that is passed through a supply chain (see at least Karsten Beth: ¶ [0105-0107] & ¶ [0179]. Karsten Beth teaches that a shared maneuver may be a mission or task performed in a location where multiple agents are operating. The mission or task may be performed by two or more agents. Non-limiting examples of shared maneuvers include loading a cargo ship, unloading a cargo ship, transporting goods through a supply chain, cleaning a location, performing maintenance on equipment, and/or other types of missions or tasks described herein. In embodiments, the maneuver configuration circuit 2612 may include a task assignment microservice that can be deployed to one or more nodes/levels of the platform 100, 200, 300. See also Karsten Beth at ¶ [0107]: One or more of the microservices 2630, 2632, 2634 may perform one or more of the following: monitor fuel consumption for an agent, perform rerouting of an agent to account for planned and/or unplanned circumstances, e.g., bathroom breaks, supply chain delays, equipment malfunctions, weather events, etc. The agent coordination circuit 2616 may include one or more assignment microservices that assign optimal tasks to agents (identified for a mission) and create a data distribution service (DDS) network for the mission's agents to cooperatively work on and/or share information across. In embodiments, microservices may bid on tasks, akin to how agents may bid. In embodiments, a mission may have a variety of microservices for accomplishing the full mission end-to-end, wherein the microservices may be spun up on a same data distribution service (DDS) network.)
- a product network control tower having a control tower memory, a control tower network interface, and a control tower processor programmed with control tower instructions (see at least Karsten Beth: ¶ [0047-0048] & Figs. 2-3 & Fig. 23 & Fig. 28.);
- a digital twin system defined at least in part by at least one of the product instructions (see at least Karsten Beth: ¶ [0048] & Fig. 2 & Fig. 26.) or the control tower instructions to encode a set of digital twins representing the set of digital products (see at least Karsten Beth: ¶ [0048] & ¶ [0072] & ¶ [0090] & ¶ [0162]. Karsten Beth teaches that the platform 100 may output simulated mission data, e.g., instructing the digital twins to proceed to waypoints in a virtual simulation of the location, perform virtual inspections per the indicated workflow, collect simulated data, e.g., point clouds, images, etc., and return. This may provide for the platform 100 to operate as a simulator for mission planning, troubleshooting and optimization, prior to requiring the user to invest in vehicles, maps or models of the location(s), etc. See also Karsten Beth at ¶ [0048]: A translation layer 211 in device core 210 may interpret the mission tasks indicated in a workflow from the platform 200 to determine a specific instruction set for any particular vehicle or group of vehicles. See also Karsten Beth at ¶ [0109-0110] & Fig. 26: The apparatus 2600 may further include a replicate circuit 2640 structured to generate one or more digital twins 2642, 2644, 2646, as described herein. Each of the one or more digital twins 2642, 2644, and/or 2646 may correspond to a different agent of the plurality of agents.);
- wherein the digital twin system (see at least Karsten Beth: ¶ [0009] & ¶ [0047-0048] & Fig. 26.) includes a value chain monitoring system configured to detect one or more supply chain disruptions (see at least Karsten Beth: ¶ [0105-0107] & ¶ [0130] & ¶ [0141]. Karsten Beth teaches that the mission or task may be performed by two or more agents. Non-limiting examples of shared maneuvers include loading a cargo ship, unloading a cargo ship, transporting goods through a supply chain, cleaning a location, performing maintenance on equipment, and/or other types of missions or tasks described herein. The maneuver configuration circuit 2612 may include a task assignment microservice that can be deployed to one or more nodes/levels of the platform 100, 200, 300. See also Karsten Beth at ¶ [0107]: One or more of the microservices 2630, 2632, 2634 may perform one or more of the following: monitor fuel consumption for an agent, perform rerouting of an agent to account for planned and/or unplanned circumstances, e.g., bathroom breaks, supply chain delays, equipment malfunctions, weather events, etc. See also Karsten Beth at ¶ [0130]: At 3162, per stage and task DDS0_agents with quality of service (QOS) may be made reliable, e.g., the message configuration, quality of the service demanding receipt, and/or confirmation of the message. As will be understood, process 3162 may include the sentry node relaying one or more tasks in a secure manner to each agent of the workflow, such communication may occur over one or more secure channels, e.g., DDS, P2P, etc. See also Karsten Beth at ¶ [0141]: An acknowledgement message may require compliance with a distributed ledger sequence. While a message within a ledger may also be encrypted, a block chain distributed ledger may allow for secure validation of the message. See also Karsten Beth at ¶ [0178].), wherein the digital twin system (see at least Karsten Beth: ¶ [0009] & ¶ [0047-0048]. Karsten Beth notes that a digital twin of a given vehicle or asset may be provided such that it may be selected for inclusion in the mission irrespective of its current availability to an operator or user. As used herein, a “digital twin” is a computer model of a real-world asset or other item, e.g., a fuel truck, a dock crane, a shuttle craft, a human worker, etc., that mimics and/or tracks the behavior and/or properties of the real word asset. See also Karsten Beth at [0047-0048]: The device side digital twin layer 215 in device core 210 and cloud-side digital twin database 217 in platform 200 may provide for simulation and insights on digital assets. Accompanying digital twin files, e.g., data files corresponding to one or more digital twins, may reside, e.g., be stored on, one or more file systems, e.g., an InterPlanetary file system (“ipfs”) private to a fleet. Data relating to one or more digital twins may be segmented and/or linked to one or more coordinate systems, which may be in real-time data spaces and/or recorded in and/or verified via a blockchain. Non-limiting examples of coordinate systems include: absolute coordinates, e.g., Global Positioning System (GPS); relative coordinates, e.g., a coordinate system centered on a facility, a vehicle, and/or an arbitrary origin; etc. Data relating to digital twins may be protected via a distributed network.) is configured to, in response to the consumer product experiencing a disruption while being passed through the supply chain (see at least Karsten Beth: ¶ [0048] & ¶ [0061] & ¶ [0105-0107]. Karsten Beth teaches that a translation layer 211 in device core 210 may interpret the mission tasks indicated in a workflow from the platform 200 to determine a specific instruction set for any particular vehicle or group of vehicles. A tiered control layer 213 of device core 210 may provide for various types of control processes, such as coordinating requested workflow tasks with operation of the device's specific hardware capabilities. The device side digital twin layer 215 in device core 210 and cloud-side digital twin database 217 in platform 200 may provide for simulation and insights on digital assets. See also Karsten Beth at ¶ [0061]: For example, a simulation may be used to move the digital twins of vehicles 102, 106, and asset 114 about location A at a given time in order to ascertain the feasibility of the mission in terms of vehicle choice, routing, traffic deconfliction protocols, etc. See also Karsten Beth at ¶ [0178].);
- identify at least one of the one or more supply chain disruptions using the value chain monitoring system (see at least Karsten Beth: ¶ [0080] & ¶ [0105-0107] & ¶ [0155]. Karsten Beth teaches that at least one of the plurality of microservices corresponds to at least one of: traffic deconfliction for the plurality of agents; traffic prioritization for the plurality of agents; or execution of at least one of a mission or a task by one or more of the plurality of agents. In certain embodiments, the server further includes a replicate circuit structured to generate a digital twin corresponding to the first agent. The agent coordination circuit is further structured to generate the plurality of coordinated agent command values based at least in part on the digital twin. The mission or task may be performed by two or more agents. Non-limiting examples of shared maneuvers include loading a cargo ship, unloading a cargo ship, transporting goods through a supply chain, cleaning a location, performing maintenance on equipment, and/or other types of missions or tasks described herein. One or more of the microservices 2630, 2632, 2634 may perform one or more of the following: monitor fuel consumption for an agent, perform rerouting of an agent to account for planned and/or unplanned circumstances, e.g., bathroom breaks, supply chain delays, equipment malfunctions, weather events, etc. In embodiments, the agent coordination circuit 2616 may include one or more assignment microservices that assign optimal tasks to agents (identified for a mission) and create a data distribution service (DDS) network for the mission's agents to cooperatively work on and/or share information across. See also Karsten Beth at ¶ [0178].);
- update a subset of the set of digital twins to represent the identified at least one supply chain disruption by modifying one or more digital twin parameters (see at least Karsten Beth: ¶ [0105-0107] & ¶ [0118] & Figs. 26-27. See also Karsten Beth at ¶ [0109] wherein the apparatus 2600 may further include a replicate circuit 2640 structured to generate one or more digital twins 2642, 2644, 2646. Each of the one or more digital twins 2642, 2644, and/or 2646 may correspond to a different agent of the plurality of agents. platform may identify that vehicle 106 is collocated with a route 116 needed by vehicle 102 and, in response, adjust the route for the vehicle 102. See also Karsten Beth at ¶ [0080-0081]: Depending on a rule or rule set, e.g., that route 116 must be followed, the scheduling data for vehicle 102 may be changed by the platform 100, 200, 300 or otherwise, e.g., by device 102 and/or device 106, rather than the routing data, e.g., vehicle 102 may be delayed (or have a part or segment of its mission delayed or adjusted) or, if vehicle 102 is prioritized over vehicle 106 (or missions or assets associated therewith). Also missions or parts thereof may be adjusted based on vehicle or operator capabilities or expected actions, e g , manned and unmanned vehicles may be configured to adjust mission tasks or parameters thereof such as speed to accommodate a manned vehicle's acceptable or desirable operating parameters, an unmanned vehicle may be configured to update its map state to accommodate expected travel time, location and reaction for manned vehicles, etc. See also Karsten Beth at ¶ [0082]: A second, third or any number of additional profiles or parameters of a profile may also be associated with a vehicle or agent, e.g., based on context data such as goal (current, future or a combination thereof), time, location, payload, cargo, other proximate vehicles, route availability, etc. Thus, as will be appreciated, profile(s) associated with a vehicle may be abstracted at various layers and updated dynamically to include a hierarchy of information, for example ordered by importance or preference related to a mission type goal, such as efficient delivery, cargo type, fuel economy, safety, etc. See also Karsten Beth at Figs. 31A-31B. See also Karsten Beth at ¶ [0178].);
- determine a metric of the disruption based at least partially on the updated subset (see at least Karsten Beth: ¶ [0055] & ¶ [0105-0107] & Figs. 26-27. Karsten Beth notes that the shortest time to perform a particular action; monetary cost-efficiency, e.g., a least expensive way to perform a particular action; energy cost-efficiency, e.g., fuel and/or battery life; a prioritization-based efficiency; etc. Non-limiting examples of agent command values 2628 include route information, scheduled departure and arrival times, asset identification information, and/or other types of data for assisting the agent in performing the shared maneuver. See also Karsten Beth at Figs. 31A-31B noting “application updating twins’ ready status and task filters”. Examiner notes Karsten Beth product is a vehicle where it provides a metric of the disruption (e.g., delay in the supply chain or traffic congestion) and updating the virtual model (e.g., “digital simulation”) to mimic to conditions affected in the supply chain process. See also Karsten Beth at ¶ [0178].)
Regarding Independent Claim 33, Karsten Beth digital twin enabled digital product network method teaches the following limitations comprising:
- monitoring a consumer product being passed through a supply chain (see at least Karsten Beth: ¶ [0105-0107] & [0179-0180]. Karsten Beth teaches that a shared maneuver may be a mission or task performed in a location where multiple agents are operating. The mission or task may be performed by two or more agents. Non-limiting examples of shared maneuvers include loading a cargo ship, unloading a cargo ship, transporting goods through a supply chain, cleaning a location, performing maintenance on equipment, and/or other types of missions or tasks described herein. See also Karsten Beth at ¶ [0107]: One or more of the microservices 2630, 2632, 2634 may perform one or more of the following: monitor fuel consumption for an agent, perform rerouting of an agent to account for planned and/or unplanned circumstances, e.g., bathroom breaks, supply chain delays, equipment malfunctions, weather events, etc. The agent coordination circuit 2616 may include one or more assignment microservices that assign optimal tasks to agents (identified for a mission) and create a data distribution service (DDS) network for the mission's agents to cooperatively work on and/or share information across. See also Karsten Beth at ¶ [0179]: Transform physical and/or or intangible items from one state to another. The methods and systems described herein may also transform data representing physical and/or intangible items from one state to another.);
- encoding a set of digital twins representing a set of digital products including the consumer product (see at least Karsten Beth: ¶ [0048] & ¶ [0072] & Figs. 26-27. Karsten Beth teaches that a translation layer 211 in device core 210 may interpret the mission tasks indicated in a workflow from the platform 200 to determine a specific instruction set for any particular vehicle or group of vehicles. A tiered control layer 213 of device core 210 may provide for various types of control processes, such as coordinating requested workflow tasks with operation of the device's specific hardware capabilities. The device side digital twin layer 215 in device core 210 and cloud-side digital twin database 217 in platform 200 may provide for simulation and insights on digital assets. Accompanying digital twin files, e.g., data files corresponding to one or more digital twins, may reside, e.g., be stored on, one or more file systems, e.g., an InterPlanetary file system (“ipfs”) private to a fleet. See also Karsten Beth at ¶ [0072]: A simulated mission is indicated, as determined at 418, digital twins for each selected vehicle may be generated at 420, i.e., having the characteristics of the selected vehicles, for use in a simulation which is performed at 422. A non-limiting example of a simulated mission view for a powerline tower inspection is provided in FIG. 23. In certain aspects, the platform 100 may output simulated mission data, e.g., instructing the digital twins to proceed to waypoints in a virtual simulation of the location, perform virtual inspections per the indicated workflow, collect simulated data, e.g., point clouds, images, etc., and return. See also Karsten Beth at Figs. 31A-31B.);
- detecting one or more supply chain disruptions (see at least Karsten Beth: ¶ [0080-0081] & ¶ [0105-0107]. See also Karsten Beth at ¶ [0178].);
- in response to the consumer product experiencing a disruption while being passed through a supply chain (see at least Karsten Beth: ¶ [0080-0081] & ¶ [0105-0107]. See also Karsten Beth at ¶ [0178].)
- identifying at least one of the one or more supply chain disruptions (see at least Karsten Beth: ¶ [0080-0081] & ¶ [0105-0107]. See also Karsten Beth at ¶ [0178].);
- update a subset of the set of digital twins to represent the identified at least one supply chain disruption by modifying one or more digital twin parameters (see at least Karsten Beth: ¶ [0105-0107] & ¶ [0118] & Figs. 26-27. See also Karsten Beth at ¶ [0109] wherein the apparatus 2600 may further include a replicate circuit 2640 structured to generate one or more digital twins 2642, 2644, 2646. Each of the one or more digital twins 2642, 2644, and/or 2646 may correspond to a different agent of the plurality of agents. platform may identify that vehicle 106 is collocated with a route 116 needed by vehicle 102 and, in response, adjust the route for the vehicle 102. See also Karsten Beth at ¶ [0080-0081]: Depending on a rule or rule set, e.g., that route 116 must be followed, the scheduling data for vehicle 102 may be changed by the platform 100, 200, 300 or otherwise, e.g., by device 102 and/or device 106, rather than the routing data, e.g., vehicle 102 may be delayed (or have a part or segment of its mission delayed or adjusted) or, if vehicle 102 is prioritized over vehicle 106 (or missions or assets associated therewith). Also missions or parts thereof may be adjusted based on vehicle or operator capabilities or expected actions, e g , manned and unmanned vehicles may be configured to adjust mission tasks or parameters thereof such as speed to accommodate a manned vehicle's acceptable or desirable operating parameters, an unmanned vehicle may be configured to update its map state to accommodate expected travel time, location and reaction for manned vehicles, etc. See also Karsten Beth at ¶ [0082]: A second, third or any number of additional profiles or parameters of a profile may also be associated with a vehicle or agent, e.g., based on context data such as goal (current, future or a combination thereof), time, location, payload, cargo, other proximate vehicles, route availability, etc. Thus, as will be appreciated, profile(s) associated with a vehicle may be abstracted at various layers and updated dynamically to include a hierarchy of information, for example ordered by importance or preference related to a mission type goal, such as efficient delivery, cargo type, fuel economy, safety, etc. See also Karsten Beth at Figs. 31A-31B. See also Karsten Beth at ¶ [0178].);
- determine a metric of the disruption based at least partially on the updated subset (see at least Karsten Beth: ¶ [0055] & ¶ [0105-0107] & Figs. 26-27. Karsten Beth notes that the shortest time to perform a particular action; monetary cost-efficiency, e.g., a least expensive way to perform a particular action; energy cost-efficiency, e.g., fuel and/or battery life; a prioritization-based efficiency; etc. Non-limiting examples of agent command values 2628 include route information, scheduled departure and arrival times, asset identification information, and/or other types of data for assisting the agent in performing the shared maneuver. See also Karsten Beth at Figs. 31A-31B noting “application updating twins’ ready status and task filters”. Examiner notes Karsten Beth product is a vehicle where it provides a metric of the disruption (e.g., delay in the supply chain or traffic congestion) and updating the virtual model (e.g., “digital simulation”) to mimic to conditions affected in the supply chain process. See also Karsten Beth at ¶ [0178].)
Regarding Dependent Claim 2, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system is further defined to encode at least one of: hierarchical digital twins, a set of composite digital twins each made up of a set of discrete digital twins of the set of digital products, or a set of digital product digital twins representing a plurality of digital products of the set of digital products (see at least Karsten Beth: ¶ [0048] & ¶ [0080-0082] & Figs. 26-27. Karsten Beth teaches that the profile(s) associated with a vehicle may be abstracted at various layers and updated dynamically to include a hierarchy of information, for example ordered by importance or preference related to a mission type goal, such as efficient delivery, cargo type, fuel economy, safety, etc. See also Karsten Beth at ¶ [0009]: A “digital twin” is a computer model of a real-world asset or other item, e.g., a fuel truck, a dock crane, a shuttle craft, a human worker, etc., that mimics and/or tracks the behavior and/or properties of the real word asset. As will be appreciated, this allows the operator or user to test a vehicle's compatibility and capabilities in the context of a simulated mission prior to investing in the vehicle or including it in a particular mission. See also Karsten Beth at ¶ [0048]: A translation layer 211 in device core 210 may interpret the mission tasks indicated in a workflow from the platform 200 to determine a specific instruction set for any particular vehicle or group of vehicles. A tiered control layer 213 of device core 210 may provide for various types of control processes, such as coordinating requested workflow tasks with operation of the device's specific hardware capabilities. The device side digital twin layer 215 in device core 210 and cloud-side digital twin database 217 in platform 200 may provide for simulation and insights on digital assets. In embodiments, accompanying digital twin files, e.g., data files corresponding to one or more digital twins, may reside, e.g., be stored on, one or more file systems, e.g., an InterPlanetary file system (“ipfs”) private to a fleet. See also Karsten Beth at ¶ [0179]: The methods and systems described herein may transform physical and/or or intangible items from one state to another. The methods and systems described herein may also transform data representing physical and/or intangible items from one state to another. See also Karsten Beth at Figs. 31A-31B.).
Regarding Dependent Claim 5, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Figs. 26-27 & Figs. 31A-31B.) is further defined to model traffic of moving elements in the set of digital products (see at least Karsten Beth: ¶ [0056] & ¶ [0061-0063] & ¶ [0072] & ¶ [0107].)
Regarding Dependent Claim 6, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Figs. 26-27 & Figs. 31A-31B.) is further defined to have a playback interface for the set of digital twins wherein a user may replay data for a situation in the digital twin system and observe visual representations of events related to the situation (see at least Karsten Beth: ¶ [0070] & ¶ [0105-0109] & Figs. 26-27 & Figs. 31A-31B. See also Karsten Beth at ¶ [0155].)
Regarding Dependent Claim 7, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin is further defined to (see at least Karsten Beth: Figs. 26-27 & Figs. 31A-31B.);
- adapt for the adaptive user interface (see at least Karsten Beth: Figs. 1-3 & Figs. 26-27.) at least one of: available data, features, or visual representations based on at least one of a user’s association with or proximity to digital products of the set of digital products (see at least Karsten Beth: ¶ [0061] & ¶ [0072] & ¶ [0080-0082] & Fig. 4.)
Regarding Dependent Claim 8, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27 & Figs. 31A-31B.) is further defined to manage interactions among multiple digital product digital twins of the set of digital twins (see at least Karsten Beth: ¶ [0111] & ¶ [0183] & Fig. 4 & Figs. 26-27.)
Regarding Dependent Claim 9, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27.) is further defined to generate and update a self-expanding digital twin associated with the set of digital products (see at least Karsten Beth: ¶ [0055] & ¶ [0117] & Figs. 26-27.)
Regarding Dependent Claim 10, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27.) is further defined to:
- aggregate performance data from a plurality of digital twins of the set of digital twins about a common asset type represented in the plurality of digital twins (see at least Karsten Beth: ¶ [0121] & ¶ [0125] & ¶ [0160] & ¶ [0183]. See at least Karsten Beth: Fig. 4 & Figs. 26-27.)
Regarding Dependent Claim 11, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27.) is further defined to match owners of identical or similar products in a market for digital twin data (see at least Karsten Beth: ¶ [0075] & ¶ [0129] & ¶ [0150].)
Regarding Dependent Claim 13, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27.) is further defined to have an in-twin marketplace, and wherein the in-twin marketplace is configured to offer at least one of data or services (see at least Karsten Beth: Fig. 3 & ¶ [0047-0048] & ¶ [0095-0096] & ¶ [0102]. Karsten Beth teaches that the automated agents may be programmed to bid automatically on certain tasks or task types, at certain availability windows (statically programmed or dynamically determined, e.g., based on location, availability, economy, etc.), or a combination of end users and automated agents may participate in the bidding marketplace by an acceptable interface with the decentralized network 314. See also Karsten Beth noting at ¶ [0051]: “A local network infrastructure may be configured to offer one or more of the services of the platform 200. For example, the services offered by platform 200 may be incorporated locally into a server of a local network to control data and reduce or prevent certain data from leaving a local network.”).
Regarding Dependent Claim 16, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27.) is further defined to offer components (see at least Karsten Beth: ¶ [0051] & ¶ [0056] & ¶ [0074] & ¶ [0153].)
Regarding Dependent Claim 17, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27.) is further defined to include APIs (see at least Karsten Beth: ¶ [0046] & ¶ [0064] & ¶ [0159].) between the set of digital twins (see at least Karsten Beth: Fig. 4 & Figs. 26-27.) and marketplaces related to the set of digital products (see at least Karsten Beth: ¶ [0095-0096] & ¶ [0100-0102].)
Regarding Dependent Claim 18, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27.) is further defined to have a twin store market system for providing at least one of access or rights to at least one of the set of digital twins or data associated with the set of digital twins (see at least Karsten Beth: ¶ [0127] & Figs. 26-27 & Figs. 31A-31B.)
Regarding Dependent Claim 19, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the consumer product includes at least one of: a vehicle, a home appliance, or a wearable device (see at least Karsten Beth: ¶ [0006] & ¶ [0009] & ¶ [0179].)
Regarding Dependent Claim 20, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27.) further comprises: automated analysis modules including risk analysis modules and safety analysis modules (see at Karsten Beth: Figs. 1-3 & Fig. 26 & ¶ [0082-0083] & ¶ [0147].) configured to analyze the one or more supply chain disruptions (see at Karsten Beth: ¶ [0105-0107] & ¶ [0178].) and generate analysis outputs (see at Karsten Beth: ¶ [0062] & ¶ [0072] & ¶ [0078] & ¶ [0087] & Fig. 4.)
Regarding Dependent Claim 21, Karsten Beth digital twin enabled digital product network system teaches the limitations of Claims 1 and 20 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system further (see at least Karsten Beth: Fig. 4 & Figs. 26-27.)
comprises:
- a control decision module configured (see at Karsten Beth: Figs. 1-4.) to:
- determine governance standards applicable to the identified at least one of the one
or more supply chain disruptions (see at Karsten Beth: ¶ [0080] & ¶ [0105-0107] & ¶ [0178].)
- execute one or more analyses regarding the disruption based on the governance standards (see at Karsten Beth: ¶ [0063] & ¶ [0080] & ¶ [0159].)
- generate control decisions based on the one or more analyses (see at Karsten Beth: ¶ [0138] & ¶ [0183].).
Regarding Dependent Claim 22, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the value chain monitoring system further comprises product testing capabilities configured (see at least Karsten Beth: ¶ [0183] & Figs. 1-4.) to test at least one of: performance of the consumer product (see at least Karsten Beth: ¶ [0087] & ¶ [0121-0125] & ¶ [0160].), activation of capabilities and features, compliance with policy or regulations (see at least Karsten Beth: ¶ [0141].), or quality of service (see at least Karsten Beth: ¶ [0130].)
Regarding Dependent Claim 23, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system is configured (see at least Karsten Beth: Fig. 4 & Figs. 26-27.) to:
- monitor at least one of traffic congestion (see at least Karsten Beth: ¶ [0056] & ¶ [0063] & ¶ [0159].) or delay incidents in the supply chain (see at least Karsten Beth: ¶ [0080] & ¶ [0105-0107] & ¶ [0178].)
- detect at least one of product failure incidents or system performance incidents (see at least Karsten Beth: ¶ [0117-0119] & ¶ [0151].)
- update the subset of the set of digital twins (see at least Karsten Beth: ¶ [0080-0082] & Figs. 26-27 & Figs. 31A-31B.) based on at least one of: the monitored traffic congestion (see at least Karsten Beth: ¶ [0056] & ¶ [0063] & ¶ [0159].) or the delay incident (see at least Karsten Beth: ¶ [0080] & ¶ [0105-0107] & ¶ [0178].), or the detected product failure incident or the system performance incident (see at least Karsten Beth: ¶ [0117-0119] & ¶ [0151].)
Regarding Dependent Claim 24, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system further (see at least Karsten Beth: Fig. 4 & Figs. 26-27.) comprises:
- a data acquisition circuit (see at least Karsten Beth: ¶ [0011] & Figs. 1-4.) structured to collect real-time sensor data from the consumer product (see at least Karsten Beth: ¶ [0068] & ¶ [0090] & ¶ [0139-0140].);
- a pattern recognition circuit (see at least Karsten Beth: ¶ [0011] & Figs. 1-4.) structured to implement a trained neural network (see at least Karsten Beth: ¶ [0114] & ¶ [0118-0120].) to analyze the real-time sensor data (see at least Karsten Beth: ¶ [0068] & ¶ [0090] & ¶ [0139-0140].)
- an analysis response circuit (see at least Karsten Beth: ¶ [0011] & Figs. 1-4.) structured to detect a supply chain disruption (see at least Karsten Beth: ¶ [0080] & ¶ [0105-0107] & ¶ [0178].) affecting the consumer product based on the analyzed sensor data see at least Karsten Beth: ¶ [0068] & ¶ [0090] & ¶ [0139-0140].)
- wherein the analysis response circuit (see at least Karsten Beth: ¶ [0011] & Figs. 1-4.) is utilized to update the subset of the set of digital twins to represent the detected supply chain disruption (see at least Karsten Beth: ¶ [0105-0107] & ¶ [0118] & Figs. 26-27. See also Karsten Beth at ¶ [0109] wherein the apparatus 2600 may further include a replicate circuit 2640 structured to generate one or more digital twins 2642, 2644, 2646. Each of the one or more digital twins 2642, 2644, and/or 2646 may correspond to a different agent of the plurality of agents. platform may identify that vehicle 106 is collocated with a route 116 needed by vehicle 102 and, in response, adjust the route for the vehicle 102. See also Karsten Beth at ¶ [0080-0081]: Depending on a rule or rule set, e.g., that route 116 must be followed, the scheduling data for vehicle 102 may be changed by the platform 100, 200, 300 or otherwise, e.g., by device 102 and/or device 106, rather than the routing data, e.g., vehicle 102 may be delayed (or have a part or segment of its mission delayed or adjusted) or, if vehicle 102 is prioritized over vehicle 106 (or missions or assets associated therewith). Also missions or parts thereof may be adjusted based on vehicle or operator capabilities or expected actions, e g , manned and unmanned vehicles may be configured to adjust mission tasks or parameters thereof such as speed to accommodate a manned vehicle's acceptable or desirable operating parameters, an unmanned vehicle may be configured to update its map state to accommodate expected travel time, location and reaction for manned vehicles, etc. See also Karsten Beth at ¶ [0082]: A second, third or any number of additional profiles or parameters of a profile may also be associated with a vehicle or agent, e.g., based on context data such as goal (current, future or a combination thereof), time, location, payload, cargo, other proximate vehicles, route availability, etc. Thus, as will be appreciated, profile(s) associated with a vehicle may be abstracted at various layers and updated dynamically to include a hierarchy of information, for example ordered by importance or preference related to a mission type goal, such as efficient delivery, cargo type, fuel economy, safety, etc. See also Karsten Beth at Figs. 31A-31B. See also Karsten Beth at ¶ [0178].)
- wherein the analysis response circuit (see at least Karsten Beth: ¶ [0011] & Figs. 1-4.) is utilized to determine the metric of the supply chain disruption (see at least Karsten Beth: ¶ [0055] & ¶ [0105-0107] & Figs. 26-27. Karsten Beth notes that the shortest time to perform a particular action; monetary cost-efficiency, e.g., a least expensive way to perform a particular action; energy cost-efficiency, e.g., fuel and/or battery life; a prioritization-based efficiency; etc. Non-limiting examples of agent command values 2628 include route information, scheduled departure and arrival times, asset identification information, and/or other types of data for assisting the agent in performing the shared maneuver. See also Karsten Beth at Figs. 31A-31B noting “application updating twins’ ready status and task filters”. Examiner notes Karsten Beth product is a vehicle where it provides a metric of the disruption (e.g., delay in the supply chain or traffic congestion) and updating the virtual model (e.g., “digital simulation”) by analyzing historical disruption patterns using machine learning (see at least Karsten Beth: ¶ [0055] & ¶ [0105-0107] & ¶ [0178].)
- wherein the analysis response circuit (see at least Karsten Beth: ¶ [0011] & Figs. 1-4.) is utilized to automatically reconfigure supply chain routing (see at least Karsten Beth: ¶ [0055] & ¶ [0105-0107] & ¶ [0178].) based on the determined metric (see at least Karsten Beth: ¶ [0055] & ¶ [0105-0107] & Figs. 26-27. Karsten Beth notes that the shortest time to perform a particular action; monetary cost-efficiency, e.g., a least expensive way to perform a particular action; energy cost-efficiency, e.g., fuel and/or battery life; a prioritization-based efficiency; etc. Non-limiting examples of agent command values 2628 include route information, scheduled departure and arrival times, asset identification information, and/or other types of data for assisting the agent in performing the shared maneuver. See also Karsten Beth at Figs. 31A-31B noting “application updating twins’ ready status and task filters”. Examiner notes Karsten Beth product is a vehicle where it provides a metric of the disruption (e.g., delay in the supply chain or traffic congestion) and updating the virtual model (e.g., “digital simulation”) to mimic to conditions affected in the supply chain process. See also Karsten Beth at ¶ [0178].)
Regarding Dependent Claim 25, Karsten Beth digital twin enabled digital product network system teaches the limitations of Claims 1 and 24 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the analysis response circuit (see at least Karsten Beth: ¶ [0011] & Figs. 1-4.) is further structured to:
- maintain a database (see at least Karsten Beth: ¶ [0011] & Figs. 1-4.) of historical disruption events (see at least Karsten Beth: ¶ [0090] & ¶ [0107] & ¶ [0118] & ¶ [0123].) and corresponding mitigation actions (see at least Karsten Beth: ¶ [0102].)
- correlate the detected supply chain disruption of the historical disruption events with
similar historical disruption events (see at least Karsten Beth: ¶ [0080] & ¶ [0105-0107] & ¶ [0178].);
- generate predictive maintenance recommendations based on the correlation (see at least Karsten Beth: ¶ [0105] & ¶ [0121] & Fig. 28.)
Regarding Dependent Claim 26, Karsten Beth digital twin enabled digital product network system teaches the limitations of Claims 1 and 24 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the pattern recognition circuit (see at least Karsten Beth: ¶ [0011] & Figs. 1-4.) implements at least one of:
- an expert system; a supervised learning system; or a deep learning system (see at least Karsten Beth: ¶ [0055] & ¶ [0114] & ¶ [0118-0120].) to analyze the real-time sensor data (see at least Karsten Beth: ¶ [0068] & ¶ [0090] & ¶ [0139-0140].)
Regarding Dependent Claim 29, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27 & Figs. 31A-31B.) is further configured to, in response to the consumer product experiencing a disruption while being passed through the supply chain (see at least Karsten Beth: ¶ [0080-0081] & ¶ [0105-0107]. See also Karsten Beth at ¶ [0178].):
- update the subset of the set of digital twins to represent the disruption (see at least Karsten Beth: ¶ [0105-0107] & ¶ [0118] & Figs. 26-27. See also Karsten Beth at ¶ [0109] wherein the apparatus 2600 may further include a replicate circuit 2640 structured to generate one or more digital twins 2642, 2644, 2646. Each of the one or more digital twins 2642, 2644, and/or 2646 may correspond to a different agent of the plurality of agents. platform may identify that vehicle 106 is collocated with a route 116 needed by vehicle 102 and, in response, adjust the route for the vehicle 102. See also Karsten Beth at ¶ [0080-0081]: Depending on a rule or rule set, e.g., that route 116 must be followed, the scheduling data for vehicle 102 may be changed by the platform 100, 200, 300 or otherwise, e.g., by device 102 and/or device 106, rather than the routing data, e.g., vehicle 102 may be delayed (or have a part or segment of its mission delayed or adjusted) or, if vehicle 102 is prioritized over vehicle 106 (or missions or assets associated therewith). Also missions or parts thereof may be adjusted based on vehicle or operator capabilities or expected actions, e g , manned and unmanned vehicles may be configured to adjust mission tasks or parameters thereof such as speed to accommodate a manned vehicle's acceptable or desirable operating parameters, an unmanned vehicle may be configured to update its map state to accommodate expected travel time, location and reaction for manned vehicles, etc. See also Karsten Beth at ¶ [0082]: A second, third or any number of additional profiles or parameters of a profile may also be associated with a vehicle or agent, e.g., based on context data such as goal (current, future or a combination thereof), time, location, payload, cargo, other proximate vehicles, route availability, etc. Thus, as will be appreciated, profile(s) associated with a vehicle may be abstracted at various layers and updated dynamically to include a hierarchy of information, for example ordered by importance or preference related to a mission type goal, such as efficient delivery, cargo type, fuel economy, safety, etc. See also Karsten Beth at Figs. 31A-31B. See also Karsten Beth at ¶ [0178].);
- determine a metric of the disruption based at least partially on the updated subset (see at least Karsten Beth: ¶ [0055] & ¶ [0105-0107] & Figs. 26-27. Karsten Beth notes that the shortest time to perform a particular action; monetary cost-efficiency, e.g., a least expensive way to perform a particular action; energy cost-efficiency, e.g., fuel and/or battery life; a prioritization-based efficiency; etc. Non-limiting examples of agent command values 2628 include route information, scheduled departure and arrival times, asset identification information, and/or other types of data for assisting the agent in performing the shared maneuver. See also Karsten Beth at Figs. 31A-31B noting “application updating twins’ ready status and task filters”. Examiner notes Karsten Beth product is a vehicle where it provides a metric of the disruption (e.g., delay in the supply chain or traffic congestion) and updating the virtual model (e.g., “digital simulation”) to mimic to conditions affected in the supply chain process. See also Karsten Beth at ¶ [0178].)
- automatically identify problem states (see at least Karsten Beth: ¶ [0079-0081] & ¶ [0117-0119] & ¶ [0152].) associated with supply chain entities involved in the disruption (see at least Karsten Beth: [0097] & [0105-0107] & ¶ [0121] & ¶ [0178].) and generate corresponding alerts (see at least Karsten Beth: ¶ [0087].)
Regarding Dependent Claim 30, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27 & Figs. 31A-31B.) is further configured to:
- share status information about and between various supply chain entities to facilitate modeling and analytics (see at least Karsten Beth: ¶ [0087] & ¶ [0125] & ¶ [0129-0131] & Figs. 31A-31B.);
- provide a visualization of products moving through the supply chain (see at least Karsten Beth: ¶ [0080] & ¶ [0105-0107] & ¶ [0178].);
- wherein, in response to the consumer product experiencing a disruption while being passed through the supply chain (see at least Karsten Beth: ¶ [0080-0081] & ¶ [0105-0107]. See also Karsten Beth at ¶ [0178].);
- update the subset of the set of digital twins to represent the disruption (see at least Karsten Beth: ¶ [0105-0107] & ¶ [0118] & Figs. 26-27. See also Karsten Beth at ¶ [0109] wherein the apparatus 2600 may further include a replicate circuit 2640 structured to generate one or more digital twins 2642, 2644, 2646. Each of the one or more digital twins 2642, 2644, and/or 2646 may correspond to a different agent of the plurality of agents. platform may identify that vehicle 106 is collocated with a route 116 needed by vehicle 102 and, in response, adjust the route for the vehicle 102. See also Karsten Beth at ¶ [0080-0081]: Depending on a rule or rule set, e.g., that route 116 must be followed, the scheduling data for vehicle 102 may be changed by the platform 100, 200, 300 or otherwise, e.g., by device 102 and/or device 106, rather than the routing data, e.g., vehicle 102 may be delayed (or have a part or segment of its mission delayed or adjusted) or, if vehicle 102 is prioritized over vehicle 106 (or missions or assets associated therewith). Also missions or parts thereof may be adjusted based on vehicle or operator capabilities or expected actions, e g , manned and unmanned vehicles may be configured to adjust mission tasks or parameters thereof such as speed to accommodate a manned vehicle's acceptable or desirable operating parameters, an unmanned vehicle may be configured to update its map state to accommodate expected travel time, location and reaction for manned vehicles, etc. See also Karsten Beth at ¶ [0082]: A second, third or any number of additional profiles or parameters of a profile may also be associated with a vehicle or agent, e.g., based on context data such as goal (current, future or a combination thereof), time, location, payload, cargo, other proximate vehicles, route availability, etc. Thus, as will be appreciated, profile(s) associated with a vehicle may be abstracted at various layers and updated dynamically to include a hierarchy of information, for example ordered by importance or preference related to a mission type goal, such as efficient delivery, cargo type, fuel economy, safety, etc. See also Karsten Beth at Figs. 31A-31B. See also Karsten Beth at ¶ [0178].);
- determine a metric of the disruption based at least partially on the updated subset (see at least Karsten Beth: ¶ [0055] & ¶ [0105-0107] & Figs. 26-27. Karsten Beth notes that the shortest time to perform a particular action; monetary cost-efficiency, e.g., a least expensive way to perform a particular action; energy cost-efficiency, e.g., fuel and/or battery life; a prioritization-based efficiency; etc. Non-limiting examples of agent command values 2628 include route information, scheduled departure and arrival times, asset identification information, and/or other types of data for assisting the agent in performing the shared maneuver. See also Karsten Beth at Figs. 31A-31B noting “application updating twins’ ready status and task filters”. Examiner notes Karsten Beth product is a vehicle where it provides a metric of the disruption (e.g., delay in the supply chain or traffic congestion) and updating the virtual model (e.g., “digital simulation”) to mimic to conditions affected in the supply chain process. See also Karsten Beth at ¶ [0178].)
Regarding Dependent Claim 31, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27 & Figs. 31A-31B.) is further configured to:
- analyze one or more variances of measures of supply chain operations over time (see at least Karsten Beth: ¶ [0063] & ¶ [0078-0081] & ¶ [0152-0153].)
- determine an acceptable range (see at least Karsten Beth: ¶ [0067] & ¶ [0151].) of outcome variance using artificial intelligence (see at least Karsten Beth: ¶ [0104] & ¶ [0117] & ¶ [0125].)
- detect a problem state when at least one measure exceeds an artificial intelligence-determined problem state threshold (see at least Karsten Beth: ¶ [0117] & ¶ [0125] & ¶ [0153].)
- predict correlated pain points further along the supply chain based on the detected
problem state (see at least Karsten Beth: Figs. 12-13 & ¶ [0072-0075] & ¶ [0105-0107].)
- wherein the analysis of the one or more variances includes detecting one or more variances (see at least Karsten Beth: ¶ [0063] & ¶ [0078-0081] & ¶ [0152-0153].) in at least one of: production time, production quality, production rate, production start time, production resource availability, shipping supply chain entity measures, or transport mode transfer duration (see at least Karsten Beth: ¶ [0080] & ¶ [0105-0178] & ¶ [0178].)
Regarding Dependent Claim 32, Karsten Beth digital twin enabled digital product network system teaches the limitations of Independent Claim 1 above, and Karsten Beth further teaches the digital twin enabled digital product network system comprising:
- wherein the digital twin system (see at least Karsten Beth: Fig. 4 & Figs. 26-27 & Figs. 31A-31B.) is further configured to:
- collect events (see at least Karsten Beth: ¶ [0090] & ¶ [0107] & ¶ [0118] & ¶ [0123].) and state data about supply chain entities from a monitoring layer (see at least Karsten Beth: ¶ [0079-0081] & ¶ [0087] & Figs. 1-4.);
- apply predictive analytics to dissect the state data and search for correlations (see at least Karsten Beth: ¶ [0079-0081] & ¶ [0087] & ¶ [0177].);
- formulate predictions about maintenance needs (see at least Karsten Beth: ¶ [0105] & ¶ [0121] & ¶ [0177].) and remaining useful life of supply chain entities (see at least Karsten Beth: ¶ [0055] & ¶ [0060] & ¶ [0122].)
Regarding Dependent Claim 34, Karsten Beth digital twin enabled digital product network method teaches the limitations of Independent Claim 33 above, and Karsten Beth further teaches the digital twin enabled digital product network method comprising:
- detecting one or more supply chain disruptions (see at least Karsten Beth: ¶ [0080-0081] & ¶ [0105-0107]. See also Karsten Beth at ¶ [0178].) by:
- monitoring traffic congestion (see at least Karsten Beth: ¶ [0056] & ¶ [0063] & ¶ [0159].) or delay incidents in the supply chain (see at least Karsten Beth: ¶ [0080] & ¶ [0105-0107] & ¶ [0178].)
- detecting product failure incidents and system performance incidents (see at least Karsten Beth: ¶ [0117-0119] & ¶ [0151].);
- generating disruption detection outputs based on the monitored incidents (see at least Karsten Beth: ¶ [0117-0119] & ¶ [0151].)
- wherein updating the subset of the set of digital twins (see at least Karsten Beth: ¶ [0080-0082] & Figs. 26-27 & Figs. 31A-31B.) includes the modifying the one or more digital twin parameters based on the disruption detection outputs (see also Karsten Beth at Figs. 31A-31B. See also Karsten Beth at ¶ [0178]. Examiner notes “modifying the one or more digital twin parameters” based on at least one of: the monitored traffic congestion (see at least Karsten Beth: ¶ [0056] & ¶ [0063] & ¶ [0159].) or the delay incident (see at least Karsten Beth: ¶ [0080] & ¶ [0105-0107] & ¶ [0178].), or the detected product failure incident or the system performance incident (see at least Karsten Beth: ¶ [0117-0119] & ¶ [0151].)
Regarding Dependent Claim 35, Karsten Beth digital twin enabled digital product network method teaches the limitations of Claims 33-34 above, and Karsten Beth further teaches the digital twin enabled digital product network method comprising:
- wherein the determining the metric of the disruption (see at least Karsten Beth: ¶ [0055] & ¶ [0105-0107] & Figs. 26-27. Karsten Beth notes that the shortest time to perform a particular action; monetary cost-efficiency, e.g., a least expensive way to perform a particular action; energy cost-efficiency, e.g., fuel and/or battery life; a prioritization-based efficiency; etc. Non-limiting examples of agent command values 2628 include route information, scheduled departure and arrival times, asset identification information, and/or other types of data for assisting the agent in performing the shared maneuver. See also Karsten Beth at Figs. 31A-31B noting “application updating twins’ ready status and task filters”. Examiner notes Karsten Beth product is a vehicle where it provides a metric of the disruption (e.g., delay in the supply chain or traffic congestion) and updating the virtual model (e.g., “digital simulation”) to mimic to conditions affected in the supply chain process. See also Karsten Beth at ¶ [0178].) comprises:
- analyzing the one or more supply chain disruptions using automated analysis modules including risk analysis modules and safety analysis modules (see at Karsten Beth: Figs. 1-4 & Fig. 26 & ¶ [0082-0083] & ¶ [0147].)
- determining governance standards applicable to the one or more supply chain disruptions (see at least Karsten Beth: ¶ [0080] & ¶ [0105-0107] & ¶ [0178].);
- executing analyses regarding the one or more supply chain disruptions based on the
governance standards (see at Karsten Beth: ¶ [0105-0107] & ¶ [0178].);
- generating analysis outputs characterizing the metric (see at Karsten Beth: ¶ [0062] & ¶ [0072] & ¶ [0078] & ¶ [0087] & Fig. 4.) of the one or more supply chain disruptions (see at least Karsten Beth: ¶ [0080] & ¶ [0105-0107] & ¶ [0178].)
Claim Rejections - 35 USC § 103
17. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
18. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
19. 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.
20. Claim 12 and 27-28 are rejected under 35 U.S.C. 103 as being unpatentable over and in view of US PG Pub (US 2022/0156665 A1) hereinafter Karsten Beth, et. al., and in view of US PG Pub (US 2020/0250661 A1) hereinafter Padmanabhan, et. al.
Regarding Dependent Claim 12, Karsten Beth digital-twin-enabled digital product network system does not explicitly disclose, but Padmanabhan however in the analogous art for digital-twin-enabled digital product network system teaches the following:
- wherein the digital twin system is configured to lock the subset of the set of digital twins upon detection of a security threat in the consumer product (see at least Padmanabhan: ¶ [0110] & ¶ [0115-0117] & ¶ [0121] & Fig. 13.).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the teachings of Karsten Beth digital-twin enabled digital product network system with the aforementioned teachings of: wherein the digital twin system is configured to lock the subset of the set of digital twins upon detection of a security threat in the consumer product, and in view of Padmanabhan, whereby the apparatuses of Padmanabhan improves upon, modifying, and expanding upon blockchain and related distributed ledger technologies by providing means for implementing declarative smart actions for coins and assets transacted onto a blockchain using Distributed Ledger Technology (DLT) in conjunction and means for implementing certificates of authenticity of digital twins transacted onto a blockchain using distributed ledger technology with a cloud based computing environment (see at least Padmanabhan: ¶ [0010]). Moreover, Padmanabhan teaches that the confirmation period of a transfer between chains may be a duration for which a coin, token, or other exchanged value is locked on the parent blockchain before it may be successfully transferred to the sidechain. This confirmation period may allow for sufficient work to be created such that a denial-of-service attack in the next waiting period becomes more computationally difficult (see at least Padmanabhan: ¶ [0110]).
Further, the claimed invention is merely a combination of old elements in a similar field for a digital-twin enabled digital product network system, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Padmanabhan, the results of the combination were predictable.
Regarding Dependent Claim 27, Karsten Beth digital-twin-enabled digital product network system does not explicitly disclose, but Padmanabhan however in the analogous art for digital-twin-enabled digital product network system teaches the following:
- a marketplace interface circuit structured to maintain an in-twin marketplace for exchanging digital twin data (see at least Padmanabhan: ¶ [0009] & ¶ [0107-0110] & ¶ [0400]. Padmanabhan notes checking and confirming the authenticity of various goods sold into an open market place so as to combat the sale of counterfeit goods or the means by which such goods may be traced back to a source of origin, such as a manufacturer. See also Padmanabhan at ¶ [0400]: Such capabilities help to combat counterfeit goods in the market place because, at any time, the product manufacturer's digital signature may be verified using underlying Public Key Infrastructure (PKI) technology and the digital twin's certificate of authenticity may be check and validated via the public blockchain. See also Padmanabhan at Fig. 3C & Fig. 5.)
- a digital twin I/O system structured to (see at least Padmanabhan: Fig. 8 & Figs. 9A-9B & Fig. 10);
- implement standardized APIs for data exchange between marketplace participants (see at least Padmanabhan: ¶ [0204] & ¶ [0206].)
- manage smart contracts governing marketplace transactions (see at least Padmanabhan: ¶ [0280] & ¶ [0317] & ¶ [0327-0331]. Padmanabhan notes that the specified information for the newly declared smart action including any additional mandatory data fields and any custom smart contracts used for validation is then written into the blockchain and a new API is auto-generated via which the tenant org may then call the new smart action's custom function from other applications and code executing within the host organization's ecosphere of cloud-based services. In such a way, once an admin for the tenant organization declares the smart action, that tenant organization's code and application may then seamlessly transact with the blockchain utilizing the newly declared smart action via the auto-generated API. See also Padmanabhan notes at ¶ [0317]: Because blockchain utilizes a distributed ledger, creation and execution of smart contracts may be technically complex, especially for novice users. Consequently, a smart flow visual designer allows implementation of smart contracts with greater ease. The resulting smart flow contract has mathematically verifiable auto-generated code, as created by the blockchain translator 1130 freeing customers and users from having to worry about the programming language used in any given blockchain protocol.)
- validate marketplace participants using distributed ledger technology (see at least Padmanabhan: ¶ [0070] & ¶ [0221-0223] & ¶ [0400].)
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the teachings of Karsten Beth digital-twin enabled digital product network system with the aforementioned teachings of: wherein the digital twin system further comprises a marketplace interface circuit structured to maintain an in-twin marketplace for exchanging digital twin data & a digital twin I/O system structured to: implement standardized APIs for data exchange between marketplace participants; manage smart contracts governing marketplace transactions & validate marketplace participants using distributed ledger technology, and in view of Padmanabhan, whereby the apparatuses of Padmanabhan improves upon, modifying, and expanding upon blockchain and related distributed ledger technologies by providing means for implementing declarative smart actions for coins and assets transacted onto a blockchain using Distributed Ledger Technology (DLT) in conjunction and means for implementing certificates of authenticity of digital twins transacted onto a blockchain using distributed ledger technology with a cloud based computing environment (see at least Padmanabhan: ¶ [0010]). Moreover, Padmanabhan teaches that the confirmation period of a transfer between chains may be a duration for which a coin, token, or other exchanged value is locked on the parent blockchain before it may be successfully transferred to the sidechain. This confirmation period may allow for sufficient work to be created such that a denial-of-service attack in the next waiting period becomes more computationally difficult (see at least Padmanabhan: ¶ [0110]).
Further, the claimed invention is merely a combination of old elements in a similar field for a digital-twin enabled digital product network system, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Padmanabhan, the results of the combination were predictable.
Regarding Dependent Claim 28, Karsten Beth / Padmanabhan digital twin enabled digital product network system teaches the limitations of Claims 1 and 27 above, and Padmanabhan further teaches the digital twin enabled digital product network system comprising:
- further comprising a security monitoring circuit structured to (see at least Padmanabhan: ¶ [0124] & ¶ [0299] & Fig. 8 & Figs. 9A-9B & Fig. 10. Padmanabhan teaches that the security parameters of the particular sidechain's blockchain protocol implementation may thus be tuned to each particular sidechain's implementation. See also Padmanabhan at ¶ [0299]: As such, system 916 provides security mechanisms to keep each tenant's data separate unless the data is shared. If more than one MTS is used, they may be located in close proximity to one another (e.g., in a server farm located in a single building or campus), or they may be distributed at locations remote from one another (e.g., one or more servers located in city A and one or more servers located in city B). See at least Padmanabhan: Fig. 8 & Figs. 9A-9B & Fig. 10.);
- detect security threats affecting the consumer product (see at least Padmanabhan: ¶ [0110] & ¶ [0121] & ¶ [0222].)
- lock access to affected digital twins upon threat detection (see at least Padmanabhan: ¶ [0110] & ¶ [0115] & ¶ [0117]. The SPV proof may include a threshold level of work, and the generating may take place over a predetermined period of time, which may also be referred to as a wait out confirmation period 122. The confirmation period of a transfer between chains may be a duration for which a coin, token, or other exchanged value is locked on the parent blockchain 188 before it may be successfully transferred to the sidechain 189. This confirmation period may allow for sufficient work to be created such that a denial-of-service attack in the next waiting period becomes more computationally difficult. See also Padmanabhan at ¶ [0115]: The predetermined contest period is implemented to prevent any possibility for double-spending in the parent blockchain 188 by transferring previously-locked coins, tokens, value, or payload data during a reorganization. If at any point during this delay, a new SPV proof 184 (known as a “reorganization proof”) is published containing a chain with more aggregate work which does not include the block in which the lock output was created, the conversion is retroactively invalidated. If no reorganization proof is detected, the sidechain asset may be released. See also Padmanabhan at ¶ [0117]: While locked on the parent blockchain 188, the asset is freely transferable within the sidechain and without requiring any further interaction with the parent blockchain 188, thus permitting the sidechain 189 to again operate wholly independently.)
- restrict marketplace transactions involving compromised digital twins (see at least Padmanabhan: ¶ [0222] & ¶ [0374] & ¶ [0389-0393]. Padmanabhan teaches that these external parties, though part of the permissioned blockchain network 540, need not know the price at which the manufacturer supplies the products to various clients, with such information being controlled via an access control layer as restricted data or perhaps certain participants are prohibited from accessing restricted functions of a permissioned blockchain network pursuant to their role, such as adding a transaction to the permissioned blockchain or voting in a consensus mechanism for the permissioned blockchain. Use of permissioned blockchains allows such role-limited implementations. See also Padmanabhan at ¶ [0435].).
It would have been obvious for one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the teachings of Karsten Beth / Padmanabhan digital-twin enabled digital product network system with the aforementioned teachings of: comprising a security monitoring circuit structured to: detect security threats affecting the consumer product & lock access to affected digital twins upon threat detection and restrict marketplace transactions involving compromised digital twins, and in further view of Padmanabhan, whereby the apparatuses of Padmanabhan improves upon, modifying, and expanding upon blockchain and related distributed ledger technologies by providing means for implementing declarative smart actions for coins and assets transacted onto a blockchain using Distributed Ledger Technology (DLT) in conjunction and means for implementing certificates of authenticity of digital twins transacted onto a blockchain using distributed ledger technology with a cloud based computing environment (see at least Padmanabhan: ¶ [0010]). Moreover, Padmanabhan teaches that the confirmation period of a transfer between chains may be a duration for which a coin, token, or other exchanged value is locked on the parent blockchain before it may be successfully transferred to the sidechain. This confirmation period may allow for sufficient work to be created such that a denial-of-service attack in the next waiting period becomes more computationally difficult (see at least Padmanabhan: ¶ [0110]).
Further, the claimed invention is merely a combination of old elements in a similar field for a digital-twin enabled digital product network system, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Padmanabhan, the results of the combination were predictable.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DERICK HOLZMACHER whose telephone number is (571) 270-7853. The examiner can normally be reached on Monday-Friday 9:00 AM – 6:30 PM EST.
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, Brian Epstein can be reached on 571-270-5389. The fax phone number for the organization where this application or proceeding is assigned is 571-270-8853.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/DERICK J HOLZMACHER/ Patent Examiner, Art Unit 3625A
/SARA GRACE BROWN/Primary Examiner, Art Unit 3625
Prosecution Insights