US 8370543

US Patent 8,370,543: Busy Detection Logic for Asynchronous Communication Port

Title: Busy detection logic for asynchronous communication port

Assignee: Induction Devices LLC

Inventors: Syed Babar Raza, Pradeep Bajpai

Filing Date: June 6, 2011

Issue Date: February 5, 2013

Abstract: An embodiment of the present invention is directed to a system for synchronizing independent time domain information. The synchronization of the device resource access information allows a memory access device to reliably access memory in a time domain independent of a device issuing requests. The system may synchronize device resource information for requests made by a processor to access (e.g., read/write) locations of a memory device. The present invention synchronizes the device access information without restricting pulse width of a read/write signal or requiring a high speed clock.

---

Plain-Language Overview of Independent Claims:

• Claim 1 (Circuit): This claim describes a circuit designed to synchronize communication between different time domains. It includes a "first logic" that receives incoming request signals from a first time domain and stores specific ones of these signals based on a "strobe signal." A "synchronizing logic" then takes these stored request signals and synchronizes them to a second, different time domain, producing synchronized request signals. Finally, "load logic" outputs these synchronized request signals according to a predefined priority.

• Claim 9 (Method): This claim outlines a method for communicating device resource access information between independent time domains. The method involves receiving various input signals, then capturing the state of certain selected input signals in response to a timing signal among those inputs. These captured states are then synchronously clocked along separate logic paths. Lastly, the captured states are outputted based on a predetermined priority.

• Claim 16 (System): This claim details a system comprising a "first device" (e.g., a processor) and a "second device" (e.g., a memory device) that has multiple resources accessible by the first device and operates in a first clock domain. The core of the invention lies in a "logic unit" situated between the two devices. This logic unit is configured to latch resource request signals from the first device when a timing signal within those requests is detected. It then synchronizes these latched resource request signals to the first clock domain of the second device.

---

CAFC 2026 Dockets:

As of April 26, 2026, the provided patent information from Google Patents indicates no specific cases filed in the Court of Appeals for the Federal Circuit (CAFC) in 2026 for US patent 8,370,543. However, the patent family has ongoing litigation with numerous US cases filed in the Texas Eastern District Court, including cases filed in 2025 and 2026. These district court cases are: 2:25-cv-00787, 2:25-cv-00788, 2:26-cv-00258, 2:26-cv-00249, 2:26-cv-00248, 2:26-cv-00247, 2:26-cv-00246, 2:26-cv-00197, 2:26-cv-00196, 2:26-cv-00195, 2:25-cv-00765, 2:25-cv-00766, 2:25-cv-00767, 2:25-cv-00768, 2:25-cv-00769, 2:25-cv-00775, 2:25-cv-00776, 2:25-cv-00777, 2:26-cv-00194, 2:25-cv-00778, 2:26-cv-00192, 2:25-cv-00789, 2:25-cv-00790, 2:25-cv-00791, 2:25-cv-00975, 2:25-cv-01006, 2:26-cv-00191, and 2:26-cv-00193.

As of April 26, 2026, known litigation involving US patent 8,370,543 includes numerous cases filed in the Texas Eastern District Court. The patent is owned and asserted by Induction Devices LLC. The defendants are generally described as 25+ banks and retailers, including entities such as Bank of America, JP Morgan Chase, Capital One, Costco, Lowes, Gap, and IKEA.

The specific district court cases identified are:

• Jurisdiction: Texas Eastern District Court
• Plaintiff(s): Induction Devices LLC (current assignee)
• Defendant(s): Various banks and retailers (specific defendant for each case number not detailed in search results)
• Case Numbers (2025 filings):
  • 2:25-cv-00787
  • 2:25-cv-00788
  • 2:25-cv-00765
  • 2:25-cv-00766
  • 2:25-cv-00767
  • 2:25-cv-00768
  • 2:25-cv-00769
  • 2:25-cv-00775
  • 2:25-cv-00776
  • 2:25-cv-00777
  • 2:25-cv-00778
  • 2:25-cv-00789
  • 2:25-cv-00790
  • 2:25-cv-00791
  • 2:25-cv-00975
  • 2:25-cv-01006
• Case Numbers (2026 filings):
  • 2:26-cv-00258
  • 2:26-cv-00249
  • 2:26-cv-00248
  • 2:26-cv-00247
  • 2:26-cv-00246
  • 2:26-cv-00197
  • 2:26-cv-00196
  • 2:26-cv-00195
  • 2:26-cv-00194
  • 2:26-cv-00192
  • 2:26-cv-00191
  • 2:26-cv-00193

Filing Dates and Outcome/Current Status: Specific filing dates and the current status or outcome for each individual case listed above are not available from the search results as of April 26, 2026. However, the litigation is described as "ongoing."

Proceedings overview

As of 2026-06-05, there is no PTAB activity on file for US Patent 8,370,543.

Strategic summary

Currently, all claims of US Patent 8,370,543 remain untested in AIA trial proceedings. This means that no claims have been canceled or sustained by the PTAB, and all claims are considered patentable as initially issued. Consequently, there is no estoppel landscape established by prior PTAB decisions. For a defendant facing assertion of this patent, all prior-art grounds remain available for potential challenges through PTAB proceedings, such as an Inter Partes Review (IPR). The absence of PTAB activity could indicate that the patent has not yet been aggressively challenged in this forum, or that prior art sufficient for an IPR has not yet been identified or leveraged.

Recommended next steps

Since there is no PTAB activity on file for US Patent 8,370,543, a defendant facing assertion of this patent should consider initiating an Inter Partes Review (IPR). This would involve:

• Conducting a thorough prior art search: Focus on identifying prior art that was not considered by the USPTO examiner during the original prosecution and could potentially invalidate the asserted claims under 35 U.S.C. §§ 102 or 103.
• Filing an IPR petition: If strong prior art is found, a petition should be drafted, clearly outlining the grounds for unpatentability for each challenged claim.
• Monitoring potential future PTAB filings: Given the ongoing district court litigation in the Eastern District of Texas, it is possible that other defendants might initiate PTAB proceedings in the future. Monitoring these could offer insights or opportunities for joinder.

Inventors

• Syed Babar Raza (Cypress Semiconductor Corp.)
• Pradeep Bajpai (Cypress Semiconductor Corp.)

Original assignee

The original assignee, Cypress Semiconductor Corp., was an American semiconductor design and manufacturing company. They offered various products including NOR flash memories, microcontrollers, PSoC solutions, capacitive touch-sensing controllers, and USB connectivity solutions. The company shipped products embodying the claims, specifically mentioning USB controllers and asynchronous SRAMs. Cypress Semiconductor Corp. was acquired by Infineon Technologies in April 2020 and is no longer an independent operating entity.

Assignment timeline

• 2012-02-13 (executed 2008-05-28) / recorded 2012-02-13 — Reel 027696/0109
  • Conveyance: Assignment
  • Assignor: BAJPAI, PRADEEP, RAZA, SYED BABAR
  • Assignee: CYPRESS SEMICONDUCTOR CORPORATION
  • Correspondent: BLAKELY SOKOLOFF TAYLOR & ZAFMAN LLP, 1279 OAKMEAD PARKWAY, SUNNYVALE, CALIFORNIA UNITED STATES 94085
  • Context: Original assignment from inventors to employer
• 2015-03-12 (executed 2015-03-12) / recorded 2015-03-21 — Reel 035240/0429
  • Conveyance: Security Interest
  • Assignor: CYPRESS SEMICONDUCTOR CORPORATION, SPANSION LLC
  • Assignee: MORGAN STANLEY SENIOR FUNDING, INC.
  • Correspondent: RICHARD S. PARNAS, 1585 BROADWAY, NEW YORK, NEW YORK UNITED STATES 10036
  • Context: Securitization of assets
• 2019-06-28 (executed 2019-06-28) / recorded 2019-07-10 — Reel 049717/0618
  • Conveyance: Assignment
  • Assignor: CYPRESS SEMICONDUCTOR CORPORATION
  • Assignee: MONTEREY RESEARCH, LLC
  • Correspondent: RICHARD S. PARNAS, 1585 BROADWAY, NEW YORK, NEW YORK UNITED STATES 10036. This correspondent recurs in this chain.
  • Context: Transfer of patent assets
• 2019-06-28 (executed 2019-06-28) / recorded 2019-08-07 — Reel 049989/0248
  • Conveyance: Release By Secured Party
  • Assignor: MORGAN STANLEY SENIOR FUNDING INC.,
  • Assignee: CYPRESS SEMICONDUCTOR CORPORATION
  • Correspondent: MORGAN STANLEY LEGAL DEPT., 1585 BROADWAY, NEW YORK, NEW YORK UNITED STATES 10036
  • Context: Release of security interest
• 2015-03-12 (executed 2015-03-12) / recorded 2020-11-03 — Reel 058002/0470
  • Conveyance: Corrective Assignment
  • Assignor: CYPRESS SEMICONDUCTOR CORPORATION, SPANSION LLC
  • Assignee: MORGAN STANLEY SENIOR FUNDING, INC.
  • Correspondent: RICHARD S. PARNAS, 1585 BROADWAY, NEW YORK, NEW YORK UNITED STATES 10036. This correspondent recurs in this chain.
  • Context: Corrective assignment to confirm security interest
• 2025-01-31 (executed 2025-01-31) / recorded 2025-05-16 — Reel 071299/0161
  • Conveyance: Assignment
  • Assignor: MONTEREY RESEARCH LLC
  • Assignee: SOUTHFORK IP HOLDINGS LLC
  • Correspondent: MEHRAN FAHIMI, 1800 DIABLO AVE, PETALUMA, CALIFORNIA UNITED STATES 94952
  • Context: Transfer of patent assets
• 2025-07-24 (executed 2025-07-24) / recorded 2025-07-28 — Reel 071853/0831
  • Conveyance: Assignment
  • Assignor: SOUTHFORK IP HOLDINGS LLC
  • Assignee: INDUCTION DEVICES LLC
  • Correspondent: MEHRAN FAHIMI, 1100 LARKSPUR LANDING CIRCLE, SUITE 245, LARKSPUR, CALIFORNIA UNITED STATES 94939. This correspondent recurs in this chain.
  • Context: Transfer to asserter

Timeline diagram

timeline
    title Ownership of US 8370543
    2012 : Assigned to Cypress Semiconductor
    2015 : Securitized to Morgan Stanley
    2019 : Assigned to Monterey Research LLC
         : Morgan Stanley released interest
    2020 : Corrective assignment to Morgan Stanley
    2025 : Assigned to Southfork IP Holdings LLC
         : Assigned to Induction Devices LLC

NPE / troll-pattern signals

1. Shell-entity transfer — present

   • 2019-07-10 (Reel 049717/0618): Cypress Semiconductor Corporation to MONTEREY RESEARCH, LLC. Monterey Research, LLC is a known patent monetizing entity.
   • 2025-05-16 (Reel 071299/0161): MONTEREY RESEARCH LLC to SOUTHFORK IP HOLDINGS LLC. The name "IP Holdings" suggests a licensing-only entity.
   • 2025-07-28 (Reel 071853/0831): SOUTHFORK IP HOLDINGS LLC to INDUCTION DEVICES LLC. Induction Devices LLC is the current assignee and identified as the plaintiff in multiple infringement suits. Their primary business appears to be induction heating tools, which seems unrelated to asynchronous communication ports described in the patent.

2. Known asserter in the chain — present

   • 2019-07-10 (Reel 049717/0618): MONTEREY RESEARCH, LLC is a known NPE.
   • 2025-07-28 (Reel 071853/0831): INDUCTION DEVICES LLC is the current plaintiff in numerous infringement suits related to this patent.

3. Repeat correspondent across the chain — present

   • Richard S. Parnas (1585 Broadway, New York, New York United States 10036) appears as the correspondent for both the 2015-03-21 security interest filing (Reel 035240/0429) and the 2019-07-10 assignment (Reel 049717/0618), and the 2020-11-03 corrective assignment (Reel 058002/0470).
   • Mehran Fahimi (1800 DIABLO AVE, PETALUMA, CALIFORNIA UNITED STATES 94952 and 1100 LARKSPUR LANDING CIRCLE, SUITE 245, LARKSPUR, CALIFORNIA UNITED STATES 94939) appears as the correspondent for the 2025-05-16 assignment (Reel 071299/0161) and the 2025-07-28 assignment (Reel 071853/0831).

4. Cascading transfers — present

   • 2025-05-16 (Reel 071299/0161) and 2025-07-28 (Reel 071853/0831): Two assignments within approximately two months, transferring from Monterey Research LLC to Southfork IP Holdings LLC and then to Induction Devices LLC, with the same correspondent, Mehran Fahimi, involved.

5. Pre-litigation transfer — present

   • The assignment to Induction Devices LLC (Reel 071853/0831) was recorded on 2025-07-28. The earliest reported litigation filings are in 2025 (e.g., 2:25-cv-00787), indicating that this transfer occurred shortly before or concurrently with the initiation of legal actions.

6. Bankruptcy fire-sale — not present

7. Privateering — unclear

   • While the original assignee, Cypress Semiconductor, was acquired by Infineon, there is no direct evidence from the assignments or public records that Infineon transferred the patent to an NPE for assertion on its behalf.

8. Defensive aggregator (anti-NPE) — not present

Verdict

NPE — high confidence
The presence of multiple strong NPE signals, including transfers to known shell entities (Monterey Research LLC, Southfork IP Holdings LLC, Induction Devices LLC), a repeat correspondent attorney across several transfers, cascading transfers in a short timeframe, and pre-litigation transfers, strongly indicates NPE assertion. The current assignee, Induction Devices LLC, does not appear to manufacture products related to the patent's claims, further supporting this verdict. (See USPTO Assignment Center search for US8370543)

To identify the most relevant prior art for US patent 8,370,543, I will focus on the "Citations" section of the patent provided by Google Patents, as these are the references considered by the examiner and often represent the closest prior art. I will then briefly describe each cited patent and identify which claims it might potentially anticipate. The USPTO's Patent Public Search tool is a primary resource for this type of analysis.

Here's an analysis of the patent citations listed for US8370543, focusing on potential anticipation under 35 U.S.C. § 102. Anticipation means that every element of a patent claim is found, either explicitly or inherently, in a single prior art reference.

Most Relevant Prior Art for US Patent 8,370,543

Based on the provided patent text, here are some of the cited prior art documents and an initial assessment of their relevance:

1. US6055607A (Interface queue with bypassing capability for main storage unit)

• Full Citation: US6055607A, Unisys Corporation, filed Dec. 23, 1996, granted Apr. 25, 2000.
• Brief Description: This patent describes an interface queue system for a main storage unit that includes bypassing capabilities. It appears to deal with managing data flow, potentially in different timing scenarios.
• Potential Anticipation (35 U.S.C. § 102): The general concept of managing requests and data flow, especially with queuing mechanisms, could potentially anticipate elements of Claim 1 (circuit), particularly the "load logic coupled to output the synchronized request signals according to a predetermined priority," and Claim 9 (method), specifically "outputting the captured states according to a predetermined priority." The aspect of "bypassing capability" might also be relevant to the priority logic.

2. US4965794A (Telecommunications FIFO)

• Full Citation: US4965794A, Dallas Semiconductor Corporation, filed Oct. 5, 1987, granted Oct. 23, 1990.
• Brief Description: This patent describes a First-In, First-Out (FIFO) memory specifically for telecommunications applications. FIFOs are commonly used for synchronizing data between different clock domains.
• Potential Anticipation (35 U.S.C. § 102): A telecommunications FIFO inherently addresses synchronization between data streams, which is central to US8370543. Elements of this patent could potentially anticipate aspects of Claim 1 (circuit) regarding "synchronizing logic configured to synchronize the stored request signals to a second time domain," and Claim 9 (method) concerning "synchronously clocking the captured states along separate logic paths." Given the context of asynchronous communication ports, a FIFO is highly relevant.

3. US5444853A (System and method for transferring data between a plurality of virtual FIFO's and a peripheral via a hardware FIFO and selectively updating control information associated with the virtual FIFO's)

• Full Citation: US5444853A, Seiko Epson Corporation, filed Mar. 31, 1992, granted Aug. 22, 1995.
• Brief Description: This patent describes a system using both virtual and hardware FIFOs for data transfer to a peripheral, including updating control information. This implies handling multiple data streams and synchronization.
• Potential Anticipation (35 U.S.C. § 102): The use of multiple FIFOs and the concept of "selectively updating control information" are highly relevant to managing resource access and busy states. This could potentially anticipate aspects of Claim 1 (circuit) (e.g., "first logic... configured to store selected of the request signals," "synchronizing logic," and "load logic") and Claim 9 (method) (e.g., "capturing a state of selected input signals responsive to a timing signal," "synchronously clocking the captured states," and "outputting the captured states according to a predetermined priority"). It also relates to Claim 16 (system) regarding the "logic unit coupled between the first and second devices configured to latch resource request signals... and synchronize latched resource request signals."

4. US5898893A (Fifo memory system and method for controlling)

• Full Citation: US5898893A, Xilinx, Inc., filed Oct. 10, 1995, granted Apr. 27, 1999.
• Brief Description: This patent describes a FIFO memory system and method for controlling it. As with other FIFO patents, its relevance stems from its function in synchronizing data.
• Potential Anticipation (35 U.S.C. § 102): Similar to US4965794A, this patent's focus on FIFO memory systems and control methods directly relates to the core synchronization and data handling aspects of US8370543. It could potentially anticipate the "synchronizing logic" of Claim 1, the "synchronously clocking" step of Claim 9, and the "logic unit" of Claim 16 that latches and synchronizes signals.

5. US6269413B1 (System with multiple dynamically-sized logical FIFOs sharing single memory and with read/write pointers independently selectable and simultaneously responsive to respective read/write FIFO selections)

• Full Citation: US6269413B1, Hewlett Packard Company, filed Oct. 30, 1998, granted Jul. 31, 2001.
• Brief Description: This patent describes a system with multiple logical FIFOs sharing a single memory, allowing for independent and simultaneous read/write pointer control. This is highly relevant to managing multiple resource requests.
• Potential Anticipation (35 U.S.C. § 102): The ability to manage multiple, independently controlled FIFOs within a single memory, with dynamic sizing and independent read/write pointers, directly addresses resource allocation and busy detection in a multi-port scenario. This patent could potentially anticipate aspects of Claim 1 (circuit) (e.g., "first logic coupled to receive request signals," "synchronizing logic," and "load logic for ensuring that only one port is reported as busy at a time coupled to the synchronization logic"), Claim 9 (method) (e.g., "capturing a state of selected input signals," "synchronously clocking the captured states," and "outputting the captured states according to a predetermined priority"), and Claim 16 (system) (e.g., "a second device having a plurality of different resources accessible by the first device," and a "logic unit coupled between the first and second devices configured to latch resource request signals... and synchronize latched resource request signals"). The "one hot port busy setting" mentioned in the description of US8370543 for load logic 308 seems particularly vulnerable to this type of prior art.

This list provides a starting point for a more in-depth prior art analysis. A full analysis would involve a detailed comparison of each element of the claims of US8370543 against the disclosures of these and other cited prior art documents.

Obviousness Analysis of US Patent 8,370,543 under 35 U.S.C. § 103

This analysis identifies combinations of prior art references that would render the claims of US patent 8,370,543 obvious to a person having ordinary skill in the art (POSA). The problem addressed by US8370543 is synchronizing device resource access information between independent time domains without imposing pulse width restrictions on control signals or requiring high-speed clocks, while also efficiently managing multiple resource requests and ensuring singular access.

The conventional designs discussed in US8370543 (FIGS. 1A and 1B) highlight the prior art's limitations: pulse width restrictions with slow clocks (FIG. 1A) or increased complexity and power with fast clocks (FIG. 1B). The claimed invention aims to overcome these by using a read/write strobe signal as a clock to capture requests and then synchronizing them to the core clock domain with load logic that prioritizes access.

Combinations of Prior Art for Obviousness

A POSA would be motivated to combine elements from various prior art references to achieve the functionality described in US8370543, particularly given the known challenges of clock domain crossing and resource arbitration in asynchronous systems.

Combination 1: US6269413B1 in view of US4965794A (or US5898893A) and US6055607A

This combination addresses the core aspects of all independent claims (Claims 1, 9, and 16).

• US6269413B1 (System with multiple dynamically-sized logical FIFOs sharing single memory and with read/write pointers independently selectable and simultaneously responsive to respective read/write FIFO selections) provides a robust foundation for managing multiple resource requests and their states.

  • Basis for "first logic" / "capturing selected input signals" / "logic unit to latch resource request signals": This patent describes a system where "multiple dynamically-sized logical FIFOs" receive data, and their "read/write pointers [are] independently selectable and simultaneously responsive to respective read/write FIFO selections." This directly teaches a mechanism to receive and "capture" (latch/store) selected input signals (resource requests) via logical FIFOs in response to timing signals (read/write FIFO selections). The logical FIFOs effectively act as the "first logic" for storing selected request signals.
  • Basis for "outputting according to a predetermined priority" / "load logic": The "independently selectable and simultaneously responsive" nature of the read/write pointers in a system with "multiple logical FIFOs sharing single memory" implies a need for arbitration to manage access to the shared resource. A POSA would find it obvious to implement a priority scheme (e.g., a "one-hot" setting as described for load logic 308 in US8370543) for outputting these captured states (resource requests) to prevent conflicts and ensure orderly access, especially when a resource can only serve one request at a time. This would function as the "load logic."

• US4965794A (Telecommunications FIFO) or US5898893A (Fifo memory system and method for controlling) provide explicit teachings on synchronization between different clock domains.

  • Basis for "synchronizing logic" / "synchronously clocking" / "synchronize latched resource request signals to the first clock domain": FIFOs are a standard and well-known solution for reliably transferring data and control signals between asynchronous clock domains. US4965794A explicitly describes a FIFO for telecommunications, inherently dealing with such synchronization, and US5898893A details a FIFO memory system and its control. A POSA, faced with the need to synchronize latched resource requests from a first time domain to a second (core) time domain (as described in US8370543 for synchronization logic 306), would naturally look to known FIFO architectures for this purpose. The internal mechanisms of these FIFO references would provide the specific "synchronizing logic" and "synchronously clocking" capabilities required.

• US6055607A (Interface queue with bypassing capability for main storage unit) further reinforces the concept of prioritized handling of requests.

  • Motivation for "predetermined priority": While US6269413B1 provides a framework for managing multiple requests, US6055607A's "interface queue with bypassing capability" explicitly teaches mechanisms for prioritizing data flow and handling requests out of sequential order if needed. A POSA would be motivated to integrate such a bypassing or explicit priority mechanism into the "load logic" (or arbitration scheme) of the multi-FIFO system described in US6269413B1 to ensure that critical requests are serviced first, thereby achieving a "predetermined priority" output as claimed in US8370543.

Motivation for Combining:

A POSA encountering the problem of synchronizing resource access between independent time domains, especially where traditional pulse width restrictions or high-speed clocks are undesirable (as highlighted in the background of US8370543), would be motivated to combine these references for the following reasons:

1. Standard Solutions for Asynchronous Communication: FIFOs are the established and obvious choice for transferring data across asynchronous clock domains to prevent metastability and ensure data integrity. Therefore, incorporating the synchronization mechanisms from US4965794A or US5898893A into any system requiring clock domain crossing, such as the multi-resource access system of US6269413B1, would be a matter of routine engineering design.
2. Efficient Resource Management: When multiple requests are vying for a shared resource, as enabled by US6269413B1's multiple logical FIFOs accessing a single memory, an arbitration scheme is essential. Implementing a "predetermined priority" (as found in US6055607A and also a common design principle in resource arbiters) for outputting these requests would be a logical and desirable design choice to optimize performance, prevent deadlocks, and ensure quality of service for critical operations.
3. No Unforeseen Results: Combining these known elements in this manner would yield predictable results: a system that can receive and latch asynchronous requests, synchronize them to a target clock domain, and then dispatch them to a shared resource based on a defined priority, without requiring stringent pulse width controls or excessively fast clocks. This directly addresses the stated problems in the background of US8370543 with conventional synchronization designs.

Conclusion

Therefore, a person having ordinary skill in the art, seeking to synchronize device resource access information between independent time domains and manage resource requests efficiently, would have been motivated to combine the teachings of US6269413B1 (for managing multiple requests and providing a framework for outputting them), US4965794A or US5898893A (for explicit clock domain synchronization), and US6055607A (for implementing a predetermined priority scheme). This combination would render the independent claims (Claims 1, 9, and 16) of US patent 8,370,543 obvious.

To determine the details regarding US patent 8,370,543, including patent term adjustments (PTA), patent term extensions (PTE), continuation/divisional applications, related family members, and the projected expiration date, direct access to the USPTO database (Patent Center or Patent Public Search) is required. The USPTO does not calculate expiration dates for patents but provides a calculator and guidance for the public to estimate them.

Based on the information available and general patent law:

• Patent Term: For applications filed on or after June 8, 1995, the term of a U.S. utility patent is generally 20 years from the earliest effective filing date of the application.
• Patent Term Adjustment (PTA): PTA is added to the 20-year term to compensate for certain administrative delays by the USPTO during prosecution. This information is typically provided in the issue notification or on the patent front page.
• Patent Term Extension (PTE): PTEs are typically related to delays in regulatory review, such as by the FDA, and are limited to five years.

For US Patent 8,370,543:

• Filing Date: June 6, 2011.
• Issue Date: February 5, 2013.
• Priority Date: March 9, 2007. This patent claims priority to U.S. Provisional Application No. 60/906,042, filed March 9, 2007, and U.S. Provisional Application No. 60/934,664, filed June 14, 2007. It is also a continuation of U.S. application Ser. No. 12/044,831, filed March 7, 2008, now U.S. Pat. No. 8,145,809.
  • The earliest priority date from a non-provisional application is March 7, 2008 (for U.S. application Ser. No. 12/044,831). The earliest overall priority date, however, is March 9, 2007, from the provisional application. For patents filed after June 8, 1995, the 20-year term is calculated from the filing date of the earliest non-provisional application, or the actual filing date if no earlier non-provisional application is claimed. However, provisional applications are generally not used to calculate the 20-year term for utility patents. Therefore, the earliest non-provisional filing date in the chain is March 7, 2008.

Based on the available information:

• Continuation Applications / Divisional Applications / Related Family Members:

  • This application is a continuation of U.S. application Ser. No. 12/044,831, filed March 7, 2008, which issued as U.S. Pat. No. 8,145,809.
  • It claims the benefit of and priority to U.S. Provisional Application No. 60/906,042, filed March 9, 2007, and U.S. Provisional Application No. 60/934,664, filed June 14, 2007.
  • U.S. Pat. No. 8,145,809 (from application Ser. No. 12/044,831) is an active family member, expiring on 2029-01-06.

• Patent Term Adjustments (PTA): The Google Patents page indicates "Adjusted expiration: 2028-05-10". This suggests that Patent Term Adjustment (PTA) has been applied to extend the patent term beyond the standard 20 years from the earliest non-provisional filing date. The USPTO calculates PTA to account for delays in prosecution. Without direct access to the USPTO's Patent Center for this specific patent, the exact calculation of PTA cannot be provided, but the adjusted expiration date reflects its inclusion.

• Patent Term Extensions (PTE): There is no indication of Patent Term Extensions (PTE) in the provided data. PTEs are typically granted for delays in regulatory review (e.g., FDA approval) and are explicitly noted.

• Projected Expiration Date: The Google Patents record indicates an adjusted expiration date of 2028-05-10. This date incorporates any Patent Term Adjustment (PTA) applied.

The following "Defensive Disclosure" document aims to broaden the scope of prior art related to US Patent 8,370,543, "Busy detection logic for asynchronous communication port." By detailing derivative variations across several technological axes, this disclosure intends to render future incremental improvements in this domain obvious or non-novel, thereby limiting the patentability of such advancements.

---

Defensive Disclosure for US Patent 8,370,543

I. Derivative Variations of Independent Claim 1 (Circuit)

Claim 1: A circuit, comprising first logic coupled to receive request signals generated in a first time domain, and configured to store selected of the request signals responsive to a strobe signal of the request signals; synchronizing logic configured to synchronize the stored request signals to a second time domain to generate synchronized request signals; and load logic coupled to output the synchronized request signals according to a predetermined priority.

---

Derivative 1.1: Material & Component Substitution (Quantum Computing Context)

• Enabling Description: The "first logic" comprises a network of superconducting transmon qubits configured to store request signal states, where each qubit's state (e.g., |0> or |1>) represents a bit of the request. The "strobe signal" is a precisely timed microwave pulse that induces a controlled-NOT (CNOT) gate operation between a control qubit (representing the strobe) and target qubits (representing the request data), effectively "latching" the request state. The "synchronizing logic" utilizes quantum annealing processes, where the coupled qubit states are allowed to evolve in a shared quantum bath, gradually aligning their phases and frequencies to the quantum clock domain of the "second time domain" (e.g., a cryogenically cooled quantum processor). The "load logic" is implemented using a quantum comparator circuit that determines the priority of entangled qubit states by measuring their collective energy levels, with lower energy states having higher priority, and then applying targeted microwave pulses to extract the highest priority synchronized request.
• Mermaid Diagram:

  graph TD
      A[First Time Domain Request Signals] --> B(Superconducting Transmon Qubits - First Logic);
      C[Strobe Microwave Pulse] --> B;
      B -- Latch Request State via CNOT --> D{Stored Qubit States};
      D --> E(Quantum Annealing Processor - Synchronizing Logic);
      F[Quantum Clock Domain] --> E;
      E -- Align Qubit States --> G{Synchronized Qubit States};
      G --> H(Quantum Comparator Circuit - Load Logic);
      H -- Measure Energy Levels --> I[Predetermined Priority Output];
  

---

Derivative 1.2: Operational Parameter Expansion (Extreme High-Frequency, Optical Domain)

• Enabling Description: The "first logic" comprises an array of ultrafast electro-optic modulators (EOMs) receiving request signals as amplitude-modulated optical pulses in the terahertz (THz) domain. The "strobe signal" is a picosecond-duration optical pump pulse that gates the EOMs, allowing selected optical request pulses to pass into an optical delay line, which acts as the storage. The "synchronizing logic" consists of a cascaded series of all-optical regenerators and wavelength converters operating in the petahertz (PHz) range, employing four-wave mixing in highly nonlinear fibers. These regenerators reshape and re-time the optical request pulses to align with a PHz optical clock in the "second time domain." The "load logic" is implemented with a photonic integrated circuit featuring an array of Mach-Zehnder interferometer (MZI) based priority encoders. Each MZI is tuned to a specific priority level, and an optical switch directs the highest priority synchronized optical pulse to the output port.
• Mermaid Diagram:

  graph TD
      A[THz Optical Request Pulses (First Time Domain)] --> B(Array of Electro-Optic Modulators - First Logic);
      C[Picosecond Optical Pump Pulse (Strobe)] --> B;
      B -- Gated Optical Pulses --> D(Optical Delay Line - Storage);
      D --> E(Cascaded Optical Regenerators/Wavelength Converters - Synchronizing Logic);
      F[PHz Optical Clock (Second Time Domain)] --> E;
      E -- Reshape & Retime Pulses --> G(Synchronized Optical Pulses);
      G --> H(Photonic Integrated Circuit with MZI Priority Encoders - Load Logic);
      H -- Optical Switch --> I[Highest Priority Optical Output];
  

---

Derivative 1.3: Cross-Domain Application (Medical Imaging - MRI Data Acquisition)

• Enabling Description: In an MRI system, the "first logic" is a custom FPGA gate array within the RF coil controller, receiving raw k-space data acquisition requests (e.g., sequence parameters, gradient timings) from the pulse sequence generator (first time domain). The "strobe signal" is a "sequence-start" trigger from the pulse sequence controller. This logic is configured to store specific k-space trajectory requests (selected request signals) in a high-speed buffer. The "synchronizing logic" is a dedicated DSP (Digital Signal Processor) operating in the MRI scanner's master clock domain (second time domain). It applies non-uniform Fast Fourier Transform (NUFFT) pre-processing and synchronization algorithms to align the acquired k-space data requests with the image reconstruction pipeline's timing. The "load logic" is an embedded controller that outputs these synchronized k-space data requests to the main image processor based on a predetermined priority (e.g., urgent clinical scans, real-time functional MRI, or routine anatomical scans).
• Mermaid Diagram:

  graph TD
      A[K-Space Acquisition Requests (Pulse Seq. Generator)] --> B(FPGA Gate Array - First Logic);
      C[Sequence-Start Trigger (Strobe)] --> B;
      B -- Store Selected Trajectories --> D(High-Speed Buffer);
      D --> E(Dedicated DSP - Synchronizing Logic);
      F[MRI Scanner Master Clock Domain] --> E;
      E -- NUFFT & Synchronization --> G(Synchronized K-Space Requests);
      G --> H(Embedded Controller - Load Logic);
      H -- Priority (Urgent/Real-time/Routine) --> I[Image Processor Input];
  

---

Derivative 1.4: Cross-Domain Application (Smart Grid Management - Distributed Energy Resources)

• Enabling Description: For smart grid management, the "first logic" is a micro-controller unit (MCU) within a Grid-Edge Control device, receiving distributed energy resource (DER) control requests (e.g., solar inverter output adjustments, battery charge/discharge commands) from various independent DER systems (first time domain). The "strobe signal" is a "grid event" trigger (e.g., frequency deviation, voltage fluctuation) broadcast across the local grid segment. This MCU stores selected DER control requests. The "synchronizing logic" is a Field Programmable Gate Array (FPGA) within a Substation Automation System, operating in the substation's synchronized phasor measurement unit (PMU) clock domain (second time domain). It converts and time-aligns the DER control requests with the grid's operational timeline using precise time stamping protocols (e.g., IEEE 1588 PTP). The "load logic" is an advanced Distribution Management System (DMS) module that outputs these synchronized DER control requests to grid actuators (e.g., smart circuit breakers, transformer tap changers) based on a predetermined priority (e.g., grid stability, economic dispatch, demand response).
• Mermaid Diagram:

  graph TD
      A[DER Control Requests (First Time Domain)] --> B(Grid-Edge MCU - First Logic);
      C[Grid Event Trigger (Strobe)] --> B;
      B -- Store Selected Requests --> D(MCU Internal Buffer);
      D --> E(Substation FPGA - Synchronizing Logic);
      F[PMU Clock Domain (Second Time Domain)] --> E;
      E -- PTP Time Alignment --> G(Synchronized DER Requests);
      G --> H(Advanced DMS Module - Load Logic);
      H -- Priority (Stability/Economic/DR) --> I[Grid Actuator Commands];
  

---

Derivative 1.5: Cross-Domain Application (Robotics - Swarm Coordination)

• Enabling Description: In a robotic swarm, the "first logic" is a dedicated processing core on each robot, receiving localized task requests (e.g., move to target, pick up item) from neighboring robots or an ad-hoc mesh network (first time domain). The "strobe signal" is a "broadcast sync" packet from a designated swarm leader or a consensus-based timestamp. This logic stores selected task requests in a local memory. The "synchronizing logic" is a hardware-accelerated clock synchronization module (e.g., using a Network Time Protocol (NTP) or Precision Time Protocol (PTP) implementation) operating in the global swarm time-synchronous clock domain (second time domain), aligning received task requests to the common swarm timeline. The "load logic" is an on-board task scheduler that outputs these synchronized task requests to the robot's motor controllers and manipulators based on a predetermined priority (e.g., collision avoidance, mission-critical tasks, resource gathering).
• Mermaid Diagram:

  graph TD
      A[Localized Task Requests (Neighboring Robots)] --> B(Robot Processing Core - First Logic);
      C[Broadcast Sync Packet (Strobe)] --> B;
      B -- Store Selected Tasks --> D(Local Robot Memory);
      D --> E(HW-Accelerated Clock Sync Module - Synchronizing Logic);
      F[Global Swarm Clock Domain] --> E;
      E -- NTP/PTP Time Alignment --> G(Synchronized Task Requests);
      G --> H(On-Board Task Scheduler - Load Logic);
      H -- Priority (Collision/Critical/Resource) --> I[Motor/Manipulator Commands];
  

---

Derivative 1.6: Integration with Emerging Tech (AI-driven Optimization)

• Enabling Description: The "first logic" is a configurable hardware module (e.g., an eFPGA block) that receives dynamic request signals from various system agents. The "strobe signal" remains a conventional read/write or enable pulse. The module stores these requests, and an integrated, lightweight Neural Network (NN) inference engine immediately tags each request with a preliminary priority score based on learned patterns from historical system usage and real-time sensor data. The "synchronizing logic" is a multi-stage clock domain crossing (CDC) synchronizer, as described in the patent, which also feeds its intermediate states to a Reinforcement Learning (RL) agent. The RL agent, operating in the second time domain, continuously optimizes the synchronization pipeline parameters (e.g., number of flip-flop stages, metastable recovery time) to minimize latency and maximize throughput. The "load logic" is an AI-optimized arbiter: a deep Q-network (DQN) trained to make dynamic priority decisions for outputting synchronized requests. This DQN uses real-time system state (e.g., buffer fullness, resource contention, external QoS metrics) as input, refining the preliminary priority scores and adaptively adjusting the "predetermined priority" to achieve global system performance objectives, rather than a fixed priority.
• Mermaid Diagram:

  graph TD
      A[Request Signals (First Time Domain)] --> B(Configurable HW Module w/ NN Inference - First Logic);
      C[Strobe Signal] --> B;
      B -- Store & Preliminary Priority Tag --> D(Tagged Requests);
      D --> E(Multi-Stage CDC Synchronizer w/ RL Agent - Synchronizing Logic);
      F[Second Time Domain Clock] --> E;
      G[Real-time System State] --> I(Deep Q-Network Arbiter - Load Logic);
      E -- Synchronized Tagged Requests --> I;
      I -- Optimized Output Priority --> J[Output Synchronized Requests];
      E -- Intermediate States --> K(RL Agent for Pipeline Optimization);
      K -- Feedback --> E;
  

---

Derivative 1.7: Integration with Emerging Tech (IoT Sensors for Real-time Monitoring)

• Enabling Description: The "first logic" incorporates a low-power microcontroller with integrated radio (e.g., LoRaWAN) that receives request signals originating from a dense network of IoT environmental sensors (first time domain). These requests could be "data upload" triggers or "sensor recalibration" commands. The "strobe signal" is a scheduled transmission event from the sensor network. Selected requests are stored in the MCU's flash memory. The "synchronizing logic" consists of a dedicated network synchronization chip (e.g., a GPS-disciplined oscillator or a PTP slave) that time-aligns the received sensor requests to a central IoT hub's real-time clock (second time domain). Concurrently, metadata from each sensor (e.g., battery level, signal strength, environmental context) is streamed alongside the request. The "load logic" is a cloud-connected edge gateway device running a fuzzy logic controller. This controller leverages the synchronized sensor requests and their real-time IoT metadata to dynamically adjust the "predetermined priority" for forwarding requests to a backend processing platform. For instance, requests from low-battery sensors in critical zones might receive boosted priority.
• Mermaid Diagram:

  graph TD
      A[IoT Sensor Request Signals (First Time Domain)] --> B(Low-Power MCU w/ Radio - First Logic);
      C[Scheduled Tx Event (Strobe)] --> B;
      B -- Store Selected Requests & Metadata --> D(Flash Memory);
      D -- Stream Data --> E(Dedicated Network Sync Chip - Synchronizing Logic);
      F[Central IoT Hub Real-time Clock (Second Time Domain)] --> E;
      G[IoT Metadata Stream] --> H(Edge Gateway w/ Fuzzy Logic - Load Logic);
      E -- Synchronized Sensor Requests --> H;
      H -- Dynamically Adjusted Priority --> I[Backend Processing Platform];
  

---

Derivative 1.8: Integration with Emerging Tech (Blockchain for Supply Chain Verification)

• Enabling Description: The "first logic" is an embedded system within a manufacturing plant's quality control station, receiving "product inspection complete" signals from various asynchronous inspection machines (first time domain). The "strobe signal" is a "batch verified" signal from a local production line controller. This logic stores selected inspection complete signals (with associated product IDs and quality metrics). The "synchronizing logic" is a secure hardware module with a trusted execution environment (TEE), operating on the plant's enterprise resource planning (ERP) system's clock domain (second time domain). It cryptographically signs and time-stamps the stored inspection signals, synchronizing them with the ERP's transaction ledger. The "load logic" is a blockchain node client integrated into the ERP system. It outputs these synchronized, cryptographically signed product inspection records to a private blockchain network (e.g., Hyperledger Fabric) according to a "predetermined priority" that ensures critical compliance milestones (e.g., raw material verification, final product release) are immutably recorded before less critical updates. The blockchain itself provides verification and audit trails.
• Mermaid Diagram:

  graph TD
      A[Product Inspection Complete Signals (First Time Domain)] --> B(Embedded QC System - First Logic);
      C[Batch Verified Signal (Strobe)] --> B;
      B -- Store Selected Signals + Product Data --> D(Local Storage);
      D --> E(Secure HW Module w/ TEE - Synchronizing Logic);
      F[ERP System Clock Domain (Second Time Domain)] --> E;
      E -- Cryptographic Signing & Timestamping --> G(Signed/Timestamped Records);
      G --> H(Blockchain Node Client - Load Logic);
      H -- Priority (Compliance Milestones) --> I[Private Blockchain Network];
  

---

Derivative 1.9: The "Inverse" or Failure Mode (Low-Power, Limited Functionality Safety Mode)

• Enabling Description: In a safety-critical system (e.g., industrial robotics), the "first logic" is implemented using ultra-low-power, event-driven asynchronous logic gates (e.g., self-timed circuits) that receive "system health status" request signals (e.g., temperature, current, motor feedback) from various sensors. The "strobe signal" is a "health update" event. In normal operation, these requests are handled conventionally. However, upon detection of a system fault (e.g., power supply brown-out, overheating), the system enters a "limited functionality" mode. In this mode, the "first logic" automatically filters out all but safety-critical requests (e.g., "emergency stop," "shutdown sequence initiation"). The "synchronizing logic" switches to a single, barebones flip-flop synchronizer clocked by a minimal, battery-backed watchdog timer (second time domain). Its primary function is to simply pass the "emergency stop" signal to the safety controller, foregoing complex synchronization for speed. The "load logic" defaults to a hardwired, fixed priority scheme where the "emergency stop" signal has absolute highest priority, bypassing all other pending requests and directly activating the fail-safe mechanism, ensuring safe shutdown even with degraded power. All other requests are dropped or queued indefinitely until normal operation resumes.
• Mermaid Diagram:

  stateDiagram-v2
      state NormalOperation {
          NormalRequests --> FirstLogicNormal : System Health
          FirstLogicNormal --> SyncLogicNormal : Strobe
          SyncLogicNormal --> LoadLogicNormal : Synced Req
          LoadLogicNormal --> OutputNormal : Priority Output
      }
      state LimitedFunctionality {
          HealthUpdateEvent --> FirstLogicLowPower : System Health
          FirstLogicLowPower --> FilterSafetyCritical : Filter
          FilterSafetyCritical --> SingleFFSync : Emergency Stop
          SingleFFSync --> HardwiredPriority : Synchronize
          HardwiredPriority --> OutputFailSafe : Fail-Safe Output
      }
      NormalOperation --> LimitedFunctionality : FaultDetected
      LimitedFunctionality --> NormalOperation : FaultCleared
      
      direction LR
      FirstLogicNormal : Ultra-low-power event-driven logic
      FirstLogicLowPower : Ultra-low-power event-driven logic (filtered)
      SingleFFSync : Barebones Flip-Flop Synchronizer
      HardwiredPriority : Hardwired Emergency Stop Priority
  

---

Derivative 1.10: The "Inverse" or Failure Mode (Decentralized Redundancy for High Availability)

• Enabling Description: In a high-availability server cluster, the "first logic" on each server node receives client request signals (e.g., database queries) from its local network interface. The "strobe signal" is an incoming packet arrival interrupt. Selected requests are stored in a local queue. The "synchronizing logic" is a distributed consensus algorithm (e.g., Paxos or Raft) running across multiple nodes in the cluster, synchronizing client requests across nodes to a globally consistent logical clock (second time domain). The "load logic" is dynamically managed by a cluster orchestrator. If a primary node fails, its "load logic" enters a "degraded mode," ceasing to output requests, and a secondary node's "load logic" automatically takes over and outputs synchronized requests from its queue based on a pre-established failover priority. This ensures continuous service, as the failure of one "load logic" simply shifts the responsibility, and the "predetermined priority" is then applied by the new active node. The cluster continues to operate, albeit with potentially reduced throughput.
• Mermaid Diagram:

  sequenceDiagram
      participant Client
      participant ServerNodeA
      participant ServerNodeB
      participant ClusterOrchestrator
  
      Client ->> ServerNodeA: Request Signal (First TD)
      ServerNodeA ->> ServerNodeA: First Logic (Latch)
      ServerNodeA ->> ServerNodeB: Synchronizing Logic (Consensus Algorithm)
      ServerNodeB ->> ServerNodeA: Synchronizing Logic (Consensus Algorithm)
      ServerNodeA -->> ClusterOrchestrator: Node A Health Check
  
      alt Primary Node Fails
          ServerNodeA ->> ClusterOrchestrator: Node A Failure
          ClusterOrchestrator ->> ServerNodeB: Activate Load Logic (Failover Priority)
          ServerNodeB ->> Client: Synchronized Request Output
      else Normal Operation
          ServerNodeA ->> ServerNodeA: Load Logic (Predetermined Priority)
          ServerNodeA ->> Client: Synchronized Request Output
      end
  

---

II. Derivative Variations of Independent Claim 9 (Method)

Claim 9: A method, comprising: receiving a plurality of input signals; capturing a state of selected input signals responsive to a timing signal of the plurality of input signals; synchronously clocking the captured states along separate logic paths; and outputting the captured states according to a predetermined priority.

---

Derivative 9.1: Material & Component Substitution (Bio-molecular Computing)

• Enabling Description: The method involves receiving a plurality of input signals encoded as specific DNA oligonucleotide sequences, representing molecular states. Capturing a state of selected input signals is achieved by DNA hybridization reactions with immobilized capture probes, responsive to a "timing signal" consisting of a controlled temperature fluctuation or enzyme activation. The hybridized DNA sequences, representing captured states, are then synchronously clocked along separate logic paths using a DNA strand displacement cascade, where each step of the cascade is triggered by a global molecular clock (e.g., cyclical addition of a catalyst) that dictates the timing of displacement events. Outputting the captured states according to a predetermined priority is performed by a competitive reaction system: DNA aptamers with varying binding affinities to a fluorescent reporter molecule, where aptamers representing higher-priority captured states outcompete lower-priority ones, resulting in a measurable fluorescent output sequence indicative of the highest priority state.
• Mermaid Diagram:

  graph TD
      A[DNA Oligonucleotide Input Signals] --> B(DNA Hybridization with Capture Probes);
      C[Temperature/Enzyme Activation (Timing Signal)] --> B;
      B -- Selected Hybridized DNA --> D(DNA Strand Displacement Cascade - Logic Paths);
      E[Global Molecular Clock] --> D;
      D -- Synchronously Clocked DNA --> F(Competitive Aptamer Reaction System);
      F -- Varying Binding Affinities --> G[Fluorescent Output (Predetermined Priority)];
  

---

Derivative 9.2: Operational Parameter Expansion (Underwater Acoustic Communication)

• Enabling Description: This method applies to underwater acoustic communication, where receiving a plurality of input signals involves hydrophones detecting a sequence of modulated acoustic pulses (e.g., frequency-shift keying, phase-shift keying) from various autonomous underwater vehicles (AUVs) in a noisy, multipath environment. Capturing a state of selected input signals is performed by a software-defined sonar array, which beamforms and filters specific AUV signals, responsive to a "timing signal" derived from a detected preamble or synchronization sequence within the acoustic data packet. The captured states (e.g., AUV ID, requested action) are then synchronously clocked along separate logic paths within a robust acoustic modem's digital signal processor (DSP), where each path incorporates adaptive equalization and forward error correction algorithms running on a stable internal clock. Outputting the captured states according to a predetermined priority is achieved by a mission control scheduler integrated into the modem, which prioritizes AUV commands based on predefined criteria (e.g., emergency surface requests, collision avoidance maneuvers, data collection uploads).
• Mermaid Diagram:

  graph TD
      A[Modulated Acoustic Pulses (Hydrophones)] --> B(Software-Defined Sonar Array);
      C[Preamble/Sync Sequence (Timing Signal)] --> B;
      B -- Beamformed/Filtered AUV Signals --> D(DSP with Adaptive Equalization/FEC - Logic Paths);
      E[Internal Modem Clock] --> D;
      D -- Synchronously Clocked States --> F(Mission Control Scheduler);
      F -- Predefined Priority (Emergency/Collision/Data) --> G[AUV Command Output];
  

---

Derivative 9.3: Cross-Domain Application (Precision Agriculture - Autonomous Robot Fleet)

• Enabling Description: For managing an autonomous agricultural robot fleet, the method involves receiving a plurality of input signals from individual robots, comprising sensor data (e.g., soil moisture, crop health, pest detection) and operational status (e.g., battery level, task completion). Capturing a state of selected input signals occurs at a central farm management server, responsive to a "timing signal" which is a periodic "fleet status broadcast" from the robots. The captured states (e.g., "Field X needs watering," "Robot Y needs recharge," "Pest detected at Z") are synchronously clocked along separate logic paths within a cloud-based agronomy platform. Each path handles a specific data type or robot, ensuring consistent processing. Outputting the captured states according to a predetermined priority is performed by an expert system within the platform, which generates actionable commands (e.g., "Dispatch irrigation drone," "Route Robot Y to charging station," "Deploy biological control") based on factors like immediate crop threat, robot availability, and resource allocation efficiency.
• Mermaid Diagram:

  graph TD
      A[Robot Sensor Data & Status (Individual Robots)] --> B(Central Farm Management Server);
      C[Fleet Status Broadcast (Timing Signal)] --> B;
      B -- Captured States (e.g., Field X, Robot Y) --> D(Cloud-based Agronomy Platform - Logic Paths);
      E[Platform Internal Clock] --> D;
      D -- Synchronously Clocked States --> F(Expert System);
      F -- Priority (Crop Threat/Robot Avail.) --> G[Actionable Commands (e.g., Irrigate, Recharge, Deploy)];
  

---

Derivative 9.4: Cross-Domain Application (Spacecraft Formation Flying - Relative State Updates)

• Enabling Description: In spacecraft formation flying, the method involves receiving a plurality of input signals from multiple distributed satellites, including relative position, velocity, and attitude measurements from inter-satellite communication links. Capturing a state of selected input signals occurs at a lead spacecraft's onboard computer, responsive to a "timing signal" which is a periodic "relative state beacon" transmitted by each satellite. The captured states (e.g., "Satellite A at [X,Y,Z] relative to B") are synchronously clocked along separate logic paths within a dedicated Guidance, Navigation, and Control (GNC) processor, where each path is designed for a specific orbital mechanics calculation or Kalman filter update. Outputting the captured states according to a predetermined priority is managed by the GNC system's autonomy engine, which generates formation-keeping maneuvers or collision avoidance commands based on real-time threat assessments and mission objectives (e.g., maintain station-keeping, execute rendezvous, avoid space debris).
• Mermaid Diagram:

  graph TD
      A[Relative State Measurements (Distributed Satellites)] --> B(Lead Spacecraft Onboard Computer);
      C[Relative State Beacon (Timing Signal)] --> B;
      B -- Captured States (e.g., Sat A at X,Y,Z) --> D(Dedicated GNC Processor - Logic Paths);
      E[GNC Internal Clock] --> D;
      D -- Synchronously Clocked States --> F(GNC Autonomy Engine);
      F -- Priority (Collision Avoidance/Formation Keeping) --> G[Maneuver Commands];
  

---

Derivative 9.5: Cross-Domain Application (Financial Trading - High-Frequency Order Matching)

• Enabling Description: In high-frequency financial trading, the method involves receiving a plurality of input signals, comprising market data updates (e.g., bid/ask quotes, trade executions) from various exchanges and incoming order requests (e.g., buy/sell X shares at price Y) from multiple algorithmic trading desks. Capturing a state of selected input signals occurs at a co-located low-latency FPGA-based matching engine, responsive to a "timing signal" which is the arrival of a new tick (market data update) or an order message. The captured states (e.g., "New Bid for XYZ at $100," "Sell Order for ABC," "Market price update") are synchronously clocked along separate, optimized logic paths within the FPGA, where each path is tailored for specific order book operations (e.g., limit order insertion, market order execution, quote update processing). Outputting the captured states according to a predetermined priority is handled by the FPGA's hardware arbiter, which enforces specific market rules (e.g., price-time priority, pro-rata allocation) for matching buy and sell orders, ensuring fairness and compliance while processing thousands of transactions per second.
• Mermaid Diagram:

  graph TD
      A[Market Data & Order Requests (Exchanges/Trading Desks)] --> B(FPGA-based Matching Engine);
      C[New Tick/Order Message (Timing Signal)] --> B;
      B -- Captured States (e.g., New Bid, Sell Order) --> D(Optimized FPGA Logic Paths);
      E[FPGA Internal Clock] --> D;
      D -- Synchronously Clocked States --> F(Hardware Arbiter);
      F -- Market Rule Priority (Price-Time/Pro-Rata) --> G[Matched Trades/Order Updates];
  

---

Derivative 9.6: Integration with Emerging Tech (AI-driven Optimization for Network Traffic Management)

• Enabling Description: The method receives input signals as network packets from various traffic flows (e.g., video streaming, voice calls, sensor data). Capturing selected input signals occurs at an intelligent network interface card (NIC), responsive to a "timing signal" from the packet arrival. The NIC includes a custom ASIC with embedded AI accelerators. The captured states (e.g., source/destination IP, payload size, QoS tags) are processed by an on-board TinyML model which dynamically assigns a 'traffic urgency score' to each packet. These scored packet states are synchronously clocked along separate logic paths within the NIC's data plane, aligned to the network processor's clock. The logic paths use hardware-based flow tables. Outputting the captured states (packets) according to a "predetermined priority" is managed by an AI-optimized packet scheduler on the NIC. This scheduler, informed by the TinyML urgency score and real-time network congestion metrics, adaptively adjusts queuing disciplines (e.g., Weighted Fair Queuing, priority queuing) to optimize network throughput, minimize latency for critical applications (e.g., real-time control), and prevent buffer overflows. The 'predetermined priority' is not static but dynamically derived by the TinyML model and scheduler.
• Mermaid Diagram:

  graph TD
      A[Network Packets (Input Signals)] --> B(Intelligent NIC w/ TinyML ASIC);
      C[Packet Arrival (Timing Signal)] --> B;
      B -- Capture & Assign Urgency Score --> D(Scored Packet States);
      D --> E(NIC Data Plane Logic Paths);
      F[Network Processor Clock] --> E;
      G[Real-time Network Congestion] --> H(AI-Optimized Packet Scheduler);
      E -- Synchronously Clocked Packets --> H;
      H -- Adaptive Queuing Discipline --> I[Output Network Packets];
  

---

Derivative 9.7: Integration with Emerging Tech (IoT Sensors for Real-time Industrial Process Control)

• Enabling Description: This method focuses on industrial control, receiving input signals from heterogeneous IoT sensors (e.g., temperature, pressure, vibration, chemical composition) distributed across a manufacturing plant. Capturing the state of selected input signals occurs at local edge gateways, responsive to a "timing signal" which is a periodic "sensor polling" request initiated by the gateway. The captured sensor readings and event flags are augmented with metadata (e.g., sensor ID, location, timestamp). These augmented states are synchronously clocked along separate logic paths within the edge gateway, where each path includes data validation and anomaly detection filters. Outputting the captured states according to a predetermined priority is managed by a publish/subscribe broker (e.g., MQTT) running on the gateway. The "predetermined priority" is dynamically assigned based on the severity of the anomaly detected, the criticality of the sensor's location, and the subscription levels of various supervisory control and data acquisition (SCADA) systems or maintenance alerts. Critical alerts are published immediately, while routine telemetry is batched.
• Mermaid Diagram:

  graph TD
      A[IoT Sensor Readings/Events (Input Signals)] --> B(Local Edge Gateway);
      C[Periodic Sensor Polling (Timing Signal)] --> B;
      B -- Capture & Augment with Metadata --> D(Augmented Sensor States);
      D --> E(Data Validation/Anomaly Detection Logic Paths);
      F[Edge Gateway Internal Clock] --> E;
      G[SCADA/Maintenance Subscriptions] --> H(MQTT Publish/Subscribe Broker);
      E -- Synchronously Clocked States --> H;
      H -- Dynamic Priority (Severity/Criticality) --> I[SCADA/Alerts Output];
  

---

Derivative 9.8: Integration with Emerging Tech (Blockchain for Authenticated Log Processing)

• Enabling Description: This method involves receiving a plurality of input signals as security event logs (e.g., login attempts, access violations, system configuration changes) from various servers and network devices within an enterprise, each operating asynchronously. Capturing a state of selected input signals is performed by a specialized log aggregator, responsive to a "timing signal" from the log entry timestamp. The captured log entries are then cryptographically hashed and grouped. These hashed log groups are synchronously clocked along separate logic paths within a tamper-proof hardware security module (HSM), where each path performs cryptographic signing and noncing, aligning them to a global network time protocol (NTP) synchronized clock. Outputting the captured states (signed and nonced log groups) according to a predetermined priority involves broadcasting them to a permissioned blockchain (e.g., using a Proof-of-Authority consensus) where critical security events (e.g., successful unauthorized access) are given higher transaction priority to ensure their rapid and immutable recording on the distributed ledger, enabling real-time forensic analysis and auditability.
• Mermaid Diagram:

  graph TD
      A[Security Event Logs (Input Signals)] --> B(Log Aggregator);
      C[Log Entry Timestamp (Timing Signal)] --> B;
      B -- Capture, Hash & Group Logs --> D(Hashed Log Groups);
      D --> E(Tamper-Proof HSM w/ Signing/Noncing Logic Paths);
      F[Global NTP Synchronized Clock] --> E;
      E -- Cryptographically Signed Log Groups --> G(Permissioned Blockchain Network);
      G -- Transaction Priority (Critical Events) --> H[Immutable Log Record on Blockchain];
  

---

Derivative 9.9: The "Inverse" or Failure Mode (Graceful Degradation for Data Logging)

• Enabling Description: In a data logging system for remote environmental sensors, the method receives input signals (e.g., temperature, humidity, light) from the sensors. Capturing selected input signals occurs at a data logger, responsive to a periodic "sampling interval" timing signal. In a normal operational mode, these captured states are processed with high fidelity. However, upon detection of a low-battery condition or unstable communication link (failure mode), the system transitions to "graceful degradation." In this mode, the method continues to receive input signals but the "capturing" step implements a selective downsampling algorithm, capturing only a fraction of the raw sensor data (e.g., every 10th reading instead of every 1st) to conserve power. The "synchronously clocking" step along separate logic paths then prioritizes essential metadata (e.g., timestamp, sensor ID) for logging, using robust, low-power synchronization circuits. The "outputting" step according to a "predetermined priority" now prioritizes transmitting critical aggregated data (e.g., daily averages, max/min values) to a central server via a low-bandwidth channel, while raw, less critical data is discarded or stored locally for potential later retrieval.
• Mermaid Diagram:

  stateDiagram-v2
      state NormalLogging {
          SensorData --> DataLoggerNormal : High Fidelity Capture
          DataLoggerNormal --> ProcessFullData : Sync Clocking
          ProcessFullData --> TransmitFullData : Output Priority
      }
      state GracefulDegradation {
          SensorData --> DataLoggerDegraded : Selective Downsampling
          DataLoggerDegraded --> PrioritizeMetadata : Low-Power Sync
          PrioritizeMetadata --> TransmitAggregatedData : Output Priority (Critical)
      }
      NormalLogging --> GracefulDegradation : LowBatteryOrLinkLoss
      GracefulDegradation --> NormalLogging : BatteryRestoredOrLinkStable
      
      direction LR
      DataLoggerNormal : Full Data Capture
      DataLoggerDegraded : Downsampled Data Capture
      ProcessFullData : High-fidelity processing
      PrioritizeMetadata : Essential metadata processing
      TransmitFullData : Raw data transmission
      TransmitAggregatedData : Aggregated data transmission
  

---

Derivative 9.10: The "Inverse" or Failure Mode (Cyber-Physical System Isolation Mode)

• Enabling Description: In a cyber-physical system (e.g., industrial control system), the method receives input signals as control commands from a supervisory control system and operational feedback from physical actuators. Capturing a state of selected input signals occurs at a safety-critical controller, responsive to a "timing signal" from a deterministic control loop. In a detected cyber-attack scenario (failure mode), the system enters an "isolation mode." In this mode, the "receiving" step immediately ceases accepting commands from the supervisory system, and the "capturing" step only captures input signals directly from local, trusted physical sensors (e.g., hardwired emergency buttons, limit switches). The "synchronously clocking" step along separate logic paths within the safety controller now runs on an isolated, non-networked clock, ensuring that actuator commands are generated solely based on local physical state and pre-programmed safety parameters. The "outputting" step according to a "predetermined priority" is overridden: all non-safety critical outputs are suppressed, and only emergency shutdown or safe-state commands are generated with absolute highest priority, directly driving actuators to a known safe configuration, irrespective of any external requests.
• Mermaid Diagram:

  flowchart TD
      A[Control Commands (Supervisory System)] --> B{Receiving Input Signals};
      P[Operational Feedback (Physical Actuators)] --> B;
      B --> C{Detect Cyber Attack?};
      C -- No --> D[Normal Operation];
      C -- Yes --> E[Isolation Mode];
      
      subgraph Normal Operation
          D --> F[Capture Selected Signals (Control Loop Timing)];
          F --> G[Synchronously Clocking (Full Functionality)];
          G --> H[Output Based on Predetermined Priority];
      end
      
      subgraph Isolation Mode
          E --> I[Receive ONLY from Trusted Physical Sensors];
          I --> J[Capture ONLY Safety-Critical Inputs];
          K[Isolated, Non-Networked Clock] --> L[Synchronously Clocking (Safety Parameters Only)];
          L --> M[Output ONLY Emergency Shutdown/Safe-State Commands (Absolute Priority)];
      end
  

---

III. Derivative Variations of Independent Claim 16 (System)

Claim 16: A system, comprising: a first device; a second device having a plurality of different resources accessible by the first device, and operating in a first clock domain; and a logic unit coupled between the first and second devices configured to latch resource request signals from the first device in response to a timing signal of the resource request signals, and synchronize latched resource request signals to the first clock domain.

---

Derivative 16.1: Material & Component Substitution (Photonic Integrated Circuit for High-Performance Computing)

• Enabling Description: The "first device" is a general-purpose processor array (e.g., CPU/GPU cores). The "second device" is a silicon photonic memory array (e.g., a bank of optical RAM modules), having a plurality of different optical memory resources (e.g., specific wavelength channels, spatial modes) accessible by the processor array, and operating in an optical clock domain (first clock domain) using a continuous-wave laser. The "logic unit" is a photonic integrated circuit (PIC) coupled between the processor array and the memory array. This PIC is configured to latch optical resource request signals (e.g., memory address encoded as wavelength shifts or pulse timings) from the processor array in response to an optical timing signal (e.g., a fast optical clock pulse) multiplexed with the request signals. The PIC then synchronizes these latched optical resource request signals to the optical clock domain of the silicon photonic memory array using all-optical clock recovery and re-timing circuits (e.g., based on four-wave mixing or saturable absorbers).
• Mermaid Diagram:

  classDiagram
      class ProcessorArray {
          +sendOpticalRequests()
      }
      class OpticalMemoryArray {
          +OpticalRAMModules
          +WavelengthChannels
          +SpatialModes
          +OpticalClockDomain
      }
      class PhotonicIntegratedCircuit {
          +latchOpticalRequests()
          +synchronizeOpticalRequests()
          -OpticalTimingSignal
          -AllOpticalClockRecovery
          -ReTimingCircuits
      }
  
      ProcessorArray "1" -- "1" PhotonicIntegratedCircuit : coupled to
      PhotonicIntegratedCircuit "1" -- "1" OpticalMemoryArray : coupled to
      OpticalMemoryArray <|-- "1..*" OpticalRAMModules : has
      OpticalMemoryArray : operates in first clock domain
      PhotonicIntegratedCircuit : latches & synchronizes requests
  

---

Derivative 16.2: Operational Parameter Expansion (Deep Space Communication - Time-Varying Delays)

• Enabling Description: The "first device" is an interplanetary probe. The "second device" is an onboard science instrument suite (e.g., spectrometer, imager) with various data acquisition modes (resources), operating in the probe's internal clock domain (first clock domain). The "logic unit" is a specialized deep-space communication synchronizer embedded within the probe's command and data handling system. This unit is configured to latch resource request signals (e.g., "start imaging," "take spectrum") from the ground control station (via the interplanetary probe, which acts as a relay for the "first device" concept here, with very long and variable propagation delays) in response to a timing signal that is heavily compensated for relativistic and gravitational time dilation effects and dynamic propagation delays. The logic unit then employs an adaptive Phase-Locked Loop (PLL) with neural network-based prediction algorithms to synchronize these latched resource request signals to the probe's internal clock domain, continuously adjusting for drift and jitter introduced by the vast distances and gravitational influences.
• Mermaid Diagram:

  flowchart TD
      A[Ground Control Station] --> B(Interplanetary Probe - First Device Concept);
      B -- Resource Request Signals --> C(Deep-Space Comm Synchronizer - Logic Unit);
      D[Timing Signal (Relativistic/Gravitational Compensated)] --> C;
      E[Probe Internal Clock Domain (First Clock Domain)] --> F(Science Instrument Suite - Second Device);
      C -- Latch & Synchronize --> F;
      C : + Adaptive PLL
      C : + Neural Network Prediction
      F : + Various Data Acquisition Modes
  

---

Derivative 16.3: Cross-Domain Application (Smart City Infrastructure - Traffic Light Control)

• Enabling Description: The "first device" is a centralized Urban Traffic Management System (UTMS). The "second device" is a smart traffic intersection controller, having a plurality of different signal phases and pedestrian crossings (resources) accessible by the UTMS, and operating in a local intersection clock domain (first clock domain). The "logic unit" is an embedded controller at each intersection, connected to the UTMS via a low-latency communication link. This embedded controller is configured to latch traffic flow optimization request signals (e.g., "extend green light for N-S direction," "activate pedestrian walk signal") from the UTMS in response to a timing signal that is a dynamic "phase change trigger" from the UTMS. The logic unit then synchronizes these latched requests to the local intersection clock domain using a hardware-accelerated time-stamping unit and a local NTP client, ensuring that phase changes are enacted precisely and without conflicts with local sensor readings or safety interlocks.
• Mermaid Diagram:

  graph TD
      A[Urban Traffic Management System (First Device)] --> B(Embedded Controller - Logic Unit);
      C[Traffic Flow Optimization Request Signals] --> B;
      D[Dynamic Phase Change Trigger (Timing Signal)] --> B;
      B -- Latch Requests --> E(Latched Requests);
      E --> F(Hardware-Accelerated Time-Stamping + NTP Client);
      G[Local Intersection Clock Domain (First Clock Domain)] --> F;
      F -- Synchronize Requests --> H(Smart Traffic Intersection Controller - Second Device);
      H --> I[Traffic Signal Phases / Pedestrian Crossings];
  

---

Derivative 16.4: Cross-Domain Application (Manufacturing - Robotic Arm Tool Changer)

• Enabling Description: In a flexible manufacturing cell, the "first device" is a central factory automation controller. The "second device" is a robotic arm, having a plurality of different end-effectors or tools (resources) accessible by the automation controller (e.g., gripper, welder, paint sprayer), and operating in the robotic arm's internal motion control clock domain (first clock domain). The "logic unit" is an intelligent tool interface module mounted on the robotic arm. This module is configured to latch tool change request signals (e.g., "attach gripper," "select welder") from the factory automation controller in response to a "tool change complete" feedback signal from the robotic arm (timing signal). The logic unit then synchronizes these latched resource request signals to the robotic arm's internal motion control clock domain using a high-speed fieldbus communication protocol (e.g., EtherCAT) with built-in distributed clock synchronization, ensuring precise and safe tool changes during dynamic operations.
• Mermaid Diagram:

  graph TD
      A[Factory Automation Controller (First Device)] --> B(Intelligent Tool Interface Module - Logic Unit);
      C[Tool Change Request Signals] --> B;
      D[Tool Change Complete Feedback (Timing Signal)] --> B;
      B -- Latch Requests --> E(Latched Requests);
      E --> F(High-Speed Fieldbus Protocol w/ Distributed Clock Sync);
      G[Robotic Arm Internal Motion Control Clock Domain (First Clock Domain)] --> F;
      F -- Synchronize Requests --> H(Robotic Arm - Second Device);
      H --> I[End-Effectors / Tools];
  

---

Derivative 16.5: Cross-Domain Application (Entertainment - Multi-User Virtual Reality Rendering)

• Enabling Description: In a multi-user virtual reality (VR) system, the "first device" is a user's VR headset. The "second device" is a high-performance graphics rendering server, having a plurality of different rendering pipelines or texture units (resources) accessible by multiple VR headsets, and operating in the server's GPU clock domain (first clock domain). The "logic unit" is a dedicated hardware rendering request aggregator and synchronizer on the server's front-end network interface. This unit is configured to latch render request signals (e.g., "render scene fragment X," "load texture Y") from individual VR headsets in response to a "frame sync pulse" from the server's master VR compositor (timing signal). The logic unit then synchronizes these latched resource request signals to the GPU clock domain using a low-latency, real-time operating system (RTOS) kernel and hardware timestamping units, ensuring that render commands from different users are precisely interleaved and executed by the GPU to maintain smooth, consistent frame rates for all participants.
• Mermaid Diagram:

  graph TD
      A[VR Headset (First Device)] --> B(HW Rendering Request Aggregator - Logic Unit);
      C[Render Request Signals] --> B;
      D[Frame Sync Pulse (Timing Signal)] --> B;
      B -- Latch Requests --> E(Latched Requests);
      E --> F(Low-Latency RTOS Kernel + HW Timestamping);
      G[Server GPU Clock Domain (First Clock Domain)] --> F;
      F -- Synchronize Requests --> H(Graphics Rendering Server - Second Device);
      H --> I[Rendering Pipelines / Texture Units];
  

---

Derivative 16.6: Integration with Emerging Tech (AI-driven Optimization for Data Center Resource Scheduling)

• Enabling Description: The "first device" is a virtual machine (VM) orchestrator in a cloud data center. The "second device" is a heterogeneous computing node (e.g., CPU, GPU, FPGA, specialized ASIC) with a plurality of different accelerators and memory banks (resources), operating in the node's internal high-speed fabric clock domain (first clock domain). The "logic unit" is an intelligent resource arbitration module implemented in a SmartNIC (Network Interface Card) within each computing node. This module is configured to latch virtual resource request signals (e.g., "allocate 200MB GPU memory," "schedule task on FPGA X") from the VM orchestrator in response to an "orchestration heartbeat" signal (timing signal). An on-board Machine Learning (ML) inference engine within the SmartNIC analyzes the latched requests, predicting optimal resource allocation based on current node utilization, application performance profiles, and energy efficiency metrics. The SmartNIC then synchronizes these ML-optimized resource requests to the node's internal fabric clock domain using an adaptive clock domain crossing (CDC) unit whose parameters are continuously tuned by a Reinforcement Learning agent. This agent learns from actual resource contention and latency feedback, dynamically adjusting the synchronization logic to minimize inter-device communication overhead and optimize overall data center throughput.
• Mermaid Diagram:

  graph TD
      A[VM Orchestrator (First Device)] --> B(SmartNIC w/ ML Inference - Logic Unit);
      C[Virtual Resource Request Signals] --> B;
      D[Orchestration Heartbeat (Timing Signal)] --> B;
      B -- Latch & ML-Optimize Requests --> E(ML-Optimized Latched Requests);
      E --> F(Adaptive CDC Unit w/ RL Agent);
      G[Node Internal Fabric Clock Domain (First Clock Domain)] --> F;
      H[Utilization/Performance Feedback] --> F;
      F -- Synchronized Requests --> I[Heterogeneous Computing Node (Second Device)];
      I --> J[Accelerators / Memory Banks];
  

---

Derivative 16.7: Integration with Emerging Tech (IoT Sensors for Predictive Maintenance in Industrial Machinery)

• Enabling Description: The "first device" is a local analytics engine on an industrial machinery asset (e.g., a turbine). The "second device" is a predictive maintenance sensor hub, having a plurality of different sensor acquisition channels (resources) (e.g., vibration, temperature, acoustic) and associated data buffers, operating in the sensor hub's low-power sampling clock domain (first clock domain). The "logic unit" is an embedded event-driven micro-controller within the sensor hub. This micro-controller is configured to latch high-frequency data acquisition request signals (e.g., "trigger burst vibration sampling," "record acoustic signature") from the local analytics engine in response to a "maintenance alert threshold exceeded" signal (timing signal) detected by the analytics engine. The logic unit then synchronizes these latched resource request signals to the sensor hub's low-power sampling clock domain using a time-domain multiplexing (TDM) scheduler that ensures non-blocking access to sensor channels and efficient power management. It also integrates a blockchain module to immutably log when requests were made and serviced.
• Mermaid Diagram:

  graph TD
      A[Local Analytics Engine (First Device)] --> B(Embedded Event-Driven MCU - Logic Unit);
      C[High-Freq Data Acquisition Request Signals] --> B;
      D[Maintenance Alert Threshold Exceeded (Timing Signal)] --> B;
      B -- Latch Requests --> E(Latched Requests);
      E --> F(TDM Scheduler + Blockchain Module);
      G[Sensor Hub Low-Power Sampling Clock Domain (First Clock Domain)] --> F;
      F -- Synchronize Requests + Log Tx --> H[Predictive Maintenance Sensor Hub (Second Device)];
      H --> I[Sensor Acquisition Channels / Data Buffers];
  

---

Derivative 16.8: Integration with Emerging Tech (Blockchain for Supply Chain Asset Tracking)

• Enabling Description: The "first device" is an asset tracking gateway in a logistics warehouse. The "second device" is a smart pallet, having a plurality of different environmental sensors (resources) (e.g., temperature, humidity, shock) and a tamper-detection unit, operating in the smart pallet's internal low-frequency sensor clock domain (first clock domain). The "logic unit" is a secure microcontroller with a cryptographic accelerator embedded within the smart pallet. This microcontroller is configured to latch "environmental data query" request signals from the asset tracking gateway in response to a "pallet movement detected" signal (timing signal) from the pallet's accelerometer. The logic unit then synchronizes these latched resource request signals to the smart pallet's internal sensor clock domain using a secure one-way hash chain for timestamping and an energy-harvesting-powered clock synchronization circuit. Upon synchronization, the requested sensor data, along with a cryptographic hash, is immutably recorded as a transaction on a private blockchain ledger, accessible for supply chain verification.
• Mermaid Diagram:

  graph TD
      A[Asset Tracking Gateway (First Device)] --> B(Secure Microcontroller w/ Crypto Accel - Logic Unit);
      C[Environmental Data Query Request Signals] --> B;
      D[Pallet Movement Detected (Timing Signal)] --> B;
      B -- Latch Requests --> E(Latched Requests);
      E --> F(Secure Hash Chain + Energy-Harvesting Clock Sync);
      G[Smart Pallet Low-Frequency Sensor Clock Domain (First Clock Domain)] --> F;
      F -- Synchronize Requests & Hash --> H[Smart Pallet (Second Device)];
      H --> I[Environmental Sensors / Tamper Detection Unit];
      I -- Output to Blockchain --> J[Private Blockchain Ledger];
  

---

Derivative 16.9: The "Inverse" or Failure Mode (Limited Functionality Sensor Network)

• Enabling Description: The "first device" is a central monitoring station for a remote environmental sensor network. The "second device" is an individual sensor node, having a plurality of different sensor modalities (resources) (e.g., air quality, water quality, seismic activity), operating in the sensor node's low-power clock domain (first clock domain). The "logic unit" is a minimal hardware interface on the sensor node. In a "limited functionality" mode (triggered by low battery or extreme environmental conditions), this logic unit is configured to only latch "critical alert" request signals (e.g., "high radiation detected," "imminent landslide") from the central monitoring station. All other routine data request signals are ignored. The "timing signal" for these critical alerts is a specific, robustly encoded burst transmission from the monitoring station. The logic unit then synchronizes these latched critical alert requests to the sensor node's low-power clock domain using a simplified, single-stage flip-flop synchronizer, designed for absolute minimal power consumption and maximum reliability for critical signal passage, even at the cost of higher latency for non-critical signals (which are now ignored). The sensor node responds by activating only its most essential safety features (e.g., an alarm, or a very low-power, single-sample transmission of critical data).
• Mermaid Diagram:

  stateDiagram-v2
      state NormalMode {
          RoutineDataRequests --> HWInterfaceNormal : Full Feature Latch
          HWInterfaceNormal --> FullSyncLogic : Complex Sync
          FullSyncLogic --> SensorNodeFull : Access All Modalities
      }
      state LimitedFunctionalityMode {
          CriticalAlertRequests --> HWInterfaceLimited : Only Critical Latch
          HWInterfaceLimited --> SimplifiedFFSync : Minimal Power Sync
          SimplifiedFFSync --> SensorNodeLimited : Activate Essential Safety Features
      }
      NormalMode --> LimitedFunctionalityMode : LowBatteryOrExtremeEnv
      LimitedFunctionalityMode --> NormalMode : ConditionsNormalize
      
      direction LR
      HWInterfaceNormal : Full feature hardware interface
      HWInterfaceLimited : Minimal hardware interface
      SimplifiedFFSync : Single-stage flip-flop synchronizer
      SensorNodeFull : Access all sensor modalities
      SensorNodeLimited : Activate essential safety features
  

---

Derivative 16.10: The "Inverse" or Failure Mode (Distributed Ledger Node with Reduced Consensus)

• Enabling Description: The "first device" is a user application submitting transactions to a decentralized application (DApp). The "second device" is a peer-to-peer (P2P) network of distributed ledger technology (DLT) nodes, where each node has a plurality of different state-changing functions (resources) (e.g., execute smart contract A, update ledger entry B), operating in its local node clock domain (first clock domain). The "logic unit" is a transaction pre-processor embedded within each DLT node. This pre-processor is configured to latch transaction request signals from user applications. The "timing signal" is a "block proposal" from a validator node. In a detected network partition or denial-of-service attack (failure mode), the DLT system enters a "reduced consensus mode." In this mode, the logic unit's synchronization mechanism shifts from a full Byzantine Fault Tolerant (BFT) consensus algorithm to a simpler, less robust Proof-of-Work (PoW) or Proof-of-Authority (PoA) mechanism, requiring fewer nodes to agree. This prioritizes transaction processing speed over strict decentralization and security guarantees for non-critical transactions. The latched resource request signals are synchronized to the local node clock domain with this reduced consensus requirement, allowing the network to continue operating and process a subset of transactions, maintaining basic functionality until full consensus can be restored.
• Mermaid Diagram:

  flowchart TD
      A[User Application (First Device)] --> B(Transaction Pre-processor - Logic Unit);
      C[Transaction Request Signals] --> B;
      D[Block Proposal (Timing Signal)] --> B;
      B -- Latch Requests --> E{Detected Network Attack?};
      E -- No --> F[Normal Consensus (e.g., BFT)];
      E -- Yes --> G[Reduced Consensus Mode (e.g., PoW/PoA)];
      
      subgraph Normal Consensus Mode
          F --> H[Full BFT Synchronization to Local Node Clock];
          H --> I[Execute All DLT Node Resources];
      end
      
      subgraph Reduced Consensus Mode
          G --> J[Reduced PoW/PoA Sync to Local Node Clock];
          J --> K[Execute Subset of DLT Node Resources (Prioritized)];
      end
  

---

IV. Combination Prior Art Scenarios with Open-Source Standards

The following combinations demonstrate the obvious integration of the concepts within US Patent 8,370,543 with existing open-source standards, thereby expanding the prior art landscape.

---

1. US8370543 (Busy Detection Logic) + AMBA AXI (Advanced Microcontroller Bus Architecture eXtensible Interface) Standard

• Description: A person having ordinary skill in the art, when designing an advanced System-on-Chip (SoC) utilizing the open-standard AMBA AXI protocol, would find it obvious to apply the busy detection and synchronization logic of US8370543 to manage asynchronous AXI transactions. Specifically, the "first logic" and "synchronizing logic" would be implemented within an AXI-compliant slave interface to handle asynchronous AXI request signals (e.g., AXI read/write addresses, control signals) originating from an AXI master operating in a different clock domain. The "strobe signal" would be derived from the AXI valid signals (e.g., AWVALID for write address valid, ARVALID for read address valid). The "synchronizing logic" would leverage well-known AXI clock domain crossing (CDC) mechanisms, such as asynchronous FIFOs or multi-flop synchronizers with handshaking logic, to safely transfer the latched AXI requests to the slave's clock domain. The "load logic" would then arbitrate access to shared resources within the AXI slave (e.g., different memory banks, peripheral registers) based on AXI transaction priorities (e.g., AWPROT, ARPROT bits) or user-defined Quality of Service (QoS) requirements, feeding back AXI ready/valid signals (e.g., AWREADY, ARREADY, RREADY, BREADY) to the master. This integration addresses resource contention and ensures coherent data transfer across clock domains within a standard SoC architecture.

---

2. US8370543 (Busy Detection Logic) + FreeRTOS (Real-Time Operating System) Task Scheduling

• Description: A person having ordinary skill in the art designing an embedded system managed by the open-source FreeRTOS real-time operating system would find it obvious to integrate the busy detection logic of US8370543 for managing asynchronous hardware events and their corresponding software task priorities. The "first logic" would capture asynchronous hardware interrupt requests (e.g., a "data ready" signal from a sensor, a "peripheral complete" signal from a DMA controller) from various hardware modules. The "strobe signal" would be the interrupt pulse itself or a derived hardware event signal. The "synchronizing logic" would be used to safely transfer these asynchronous hardware events into the FreeRTOS system tick clock domain (the "second time domain"). The "load logic" would then interact directly with the FreeRTOS task scheduler. The "predetermined priority" for outputting synchronized requests would map directly to FreeRTOS task priorities, where synchronized hardware events trigger or unblock specific FreeRTOS tasks. For example, a high-priority hardware event (e.g., an emergency shutdown trigger) would unblock a high-priority FreeRTOS task responsible for handling the emergency, ensuring immediate software response even if the hardware event originated asynchronously. This combination provides a robust mechanism for deterministic real-time event handling in embedded systems using an open-source RTOS.

---

3. US8370543 (Busy Detection Logic) + MQTT (Message Queuing Telemetry Transport) Protocol

• Description: A person having ordinary skill in the art developing an Internet of Things (IoT) gateway or edge device would find it obvious to apply the busy detection and synchronization logic of US8370543 to efficiently handle asynchronous message traffic using the open-source MQTT protocol. The "first logic" would be configured within the IoT gateway to receive asynchronous sensor data packets or control command messages (request signals) from various IoT devices connected via diverse low-power radio protocols (e.g., LoRaWAN, Zigbee, Bluetooth Low Energy). The "strobe signal" would be the event of successful packet reception or message parsing. The "synchronizing logic" would time-align these asynchronously received messages to the gateway's internal system clock (the "second time domain"), ensuring consistent temporal context for all incoming data. The "load logic" would then function as an MQTT client within the gateway, publishing these synchronized data points or commands to an MQTT broker. The "predetermined priority" for outputting messages would be dynamically assigned based on factors such as message criticality (e.g., environmental anomaly alert vs. routine telemetry), QoS requirements, or subscriber urgency, and could be directly mapped to MQTT Quality of Service (QoS) levels (e.g., QoS 0 for best-effort, QoS 1 for at-least-once, QoS 2 for exactly-once delivery) to ensure reliable and prioritized message delivery from asynchronous edge devices to a centralized or cloud-based IoT platform.