US 9313101

Summary of U.S. Patent 9,313,101

Title: Method of controlling traffic by time-based policy

Assignee: Electronics and Telecommunications Research Institute

Inventors: Sang Wan KIM, Joon Kyung LEE, Dong Won KANG, Wang Bong Lee, Sang Kil Park, SangSik Yoon, Jong Dae Park

Filing Date: October 4, 2012

Issue Date: April 12, 2016

Abstract:
A method of controlling traffic, particularly, a method of setting and executing a traffic control policy in which a time condition is additionally combined is provided. At any specific step of a network that executes a time-based policy, an execution time point of the time-based policy can be determined. Further, a network service provider can provide various application services to a network user using a time-based policy.

---

Plain-Language Overview of Independent Claims:

Claim 1: This claim describes a method for a policy server to decide when to implement a time-based traffic control rule. The server continuously checks if it's the right time to activate a specific policy. Once the execution time arrives, the server sends the policy to a policy management system (PMS), which is connected to the equipment that will actually enforce the rule. This policy is created by combining information from network data packets (like source and destination addresses) with a time-based condition that is independent of the network traffic itself.

Claim 3: This claim outlines a method for a policy management system (PMS) to handle time-based traffic control policies. The PMS, which is connected to the equipment that enforces the policy, downloads and stores the policy. It then determines if the specific time for the policy to be executed has been reached. If it is not yet time, the system keeps checking. The policy itself is based on both network packet information and a time condition separate from the traffic.

Claim 6: This claim focuses on the final step of the process: the policy execution equipment (PEE). This piece of network hardware downloads the traffic control policy and is responsible for determining if the execution time has come. It continuously checks the time, and once the specified time is reached, it begins to enforce the policy. Similar to the other claims, the policy is based on a combination of data packet information and a time condition not derived from the traffic.

---

Litigation and Post-Grant Proceedings:

A search of the dockets for the Court of Appeals for the Federal Circuit (CAFC) for 2026 did not reveal any litigation related to US patent 9,313,101.

Information from the USPTO's Patent Trial and Appeal Board (PTAB) portal indicates that a post-grant proceeding, specifically an Inter Partes Review (IPR) designated as IPR2026-00272, involving this patent was pending as of March 30, 2026. However, further details about the status and substance of this proceeding are not available from the provided search results. Therefore, the existence of this proceeding is noted with uncertainty.

Litigation and Post-Grant Proceedings Update for U.S. Patent 9,313,101

As of April 30, 2026, U.S. Patent 9,313,101 is involved in at least two known legal proceedings. This information updates and supersedes the details noted in previously generated sections of this analysis.

District Court Litigation

A patent infringement lawsuit has been filed in the U.S. District Court for the Eastern District of Texas.

• Plaintiff: Optimnet LLC
• Defendant: Cisco Systems, Inc.
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:25-cv-00935
• Filing Date: September 4, 2025
• Status: The current status of this case is pending.

Post-Grant Proceedings

A post-grant challenge has been filed against the patent at the U.S. Patent and Trademark Office's Patent Trial and Appeal Board (PTAB).

• Proceeding Type: Inter Partes Review (IPR)
• Case Number: IPR2026-00321
• Petitioner: Cisco Systems, Inc.
• Patent Owner: Optimnet LLC
• Filing Date: March 30, 2026
• Status: Pending

This Inter Partes Review proceeding was initiated by Cisco Systems, Inc. to challenge the validity of one or more claims of the '101 patent. The filing of this IPR is subsequent to the district court litigation filed by Optimnet LLC and is a common defensive strategy in patent disputes.

Proceedings overview

There is one Inter Partes Review (IPR) proceeding on file for U.S. Patent 9,313,101, which is currently pending. This means the validity of the patent's claims has not yet been definitively determined by the PTAB. Therefore, the patent is neither hardened nor has it had claims canceled, leaving its defensive posture for a defendant uncertain regarding IPR challenges at this stage.

IPR2026-00321 — Cisco Systems, Inc. v. Optimnet LLC

• Type: Inter Partes Review
• Filed: 2026-03-30
• Status: Pending. The petition has been filed, and the PTAB is in the process of deciding whether to institute a review. The institution decision is due around September 30, 2026.
• Judge panel: Not yet public, as the institution decision has not been rendered.
• Petition grounds: The detailed petition grounds, including specific claims challenged, prior art cited, and statutory bases (§ 102 / § 103 / § 112), are not publicly available in the search results at this pending stage.
• Institution decision: Not yet issued. The Director of the USPTO now makes institution decisions, often through summary notices that may not provide extensive reasoning.
• Final Written Decision (if issued): Not issued.
• Settlement / termination: No settlement or termination recorded.
• Appeal: No appeal activity.
• Defensive value: As this IPR is in the pending stage, it does not yet provide any definitive defensive value. If the IPR is instituted, it indicates that the PTAB believes there is a reasonable likelihood that at least one challenged claim is unpatentable, opening a pathway to potentially invalidate claims. If institution is denied, it suggests the petition failed to meet the threshold for review, making future IPR attempts on the same grounds by the petitioner (or its privies) more difficult due to estoppel.

Strategic summary

Currently, the claims of U.S. Patent 9,313,101 are all UNTESTED by a final PTAB decision. The single IPR, IPR2026-00321, is in a preliminary, "Pending" status, meaning no claims have been canceled or sustained by the PTAB. Consequently, the patent has not been narrowed through IPR proceedings.

Regarding the estoppel landscape, if IPR2026-00321 were to proceed to a Final Written Decision, § 315(e)(2) would bar Cisco Systems, Inc. (and its privies) from raising any ground they raised or reasonably could have raised in a later proceeding. However, since the proceeding is pending, no estoppel has yet attached. For a defendant currently being asserted against, this means that prior-art grounds, including those that might be raised in IPR2026-00321, are still available for an independent challenge, assuming the defendant is not a privy to Cisco Systems, Inc. The presence of Cisco Systems, Inc. as the petitioner is notable, indicating that a significant market player is challenging the patent's validity.

Recommended next steps

For IPR2026-00321, the key upcoming milestone is the institution decision, which is due around September 30, 2026. Monitoring the PTAB's Public Search for the institution decision, including any accompanying reasoning, would be crucial. If instituted, the trial will commence, typically leading to a Final Written Decision within one year of institution.

Inventors

• Sang Wan KIM (Electronics and Telecommunications Research Institute)
• Joon Kyung LEE (Electronics and Telecommunications Research Institute)
• Dong Won KANG (Electronics and Telecommunications Research Institute)
• Wang Bong Lee (Electronics and Telecommunications Research Institute)
• Sang Kil Park (Electronics and Telecommunications Research Institute)
• SangSik Yoon (Electronics and Telecommunications Research Institute)
• Jong Dae Park (Electronics and Telecommunications Research Institute)

All inventors were employed by the original assignee, Electronics and Telecommunications Research Institute (ETRI), at the time of filing.

Original assignee

Electronics and Telecommunications Research Institute (ETRI) is a non-profit, government-funded research institute based in Daejeon, South Korea. ETRI primarily focuses on research and development in information and communication technologies (ICT), including areas like artificial intelligence, 5G, and digital convergence. They have a history of commercializing their research, such as CDMA technology. ETRI operates as a technology incubator and licensor, fostering spin-offs and industry partnerships to commercialize its research breakthroughs. ETRI is currently operating.

Assignment timeline

• 2012-10-04 (executed) / recorded 2012-10-04 — Reel 029079/0176
  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: PARK, JONG DAE; PARK, SANG KIL; YOON, SANGSIK; KANG, DONG WON; KIM, SANG WAN; LEE, JOON KYUNG; LEE, WANG BONG (all individual inventors)
  • Assignee: ELECTRONICS AND TELECOMMUNICATIONS RESEARCH INSTITUTE
  • Correspondent: Not specified in available records for this initial assignment.
  • Context: Internal transfer from individual inventors to their employer, the original assignee, at the time of patent application filing. This is a standard practice where inventors assign their rights to the entity for which they developed the invention.

The USPTO Assignment Center (https://assignmentcenter.uspto.gov/) shows no other recorded assignments for US 9313101 after this initial assignment from the inventors to ETRI.

Timeline diagram

timeline
    title Ownership of US 9313101
    2012 : Filed by ETRI inventors
         : Assigned to ETRI
    2016 : Issued
    2025 : First infringement suit filed by Optimnet LLC
    2026 : IPR filed against patent by Cisco

NPE / troll-pattern signals

1. Shell-entity transfer — unclear. While Optimnet LLC, the current asserter, is typically associated with patent assertion, there is no recorded assignment of this patent to Optimnet LLC in the USPTO Assignment Center. Therefore, the transfer itself is not documented.

2. Known asserter in the chain — present. Optimnet LLC is the current plaintiff in district court litigation and the patent owner in the IPR proceeding. Optimnet LLC is known as a high-frequency plaintiff and patent assertion entity.

3. Repeat correspondent across the chain — not present. Only one assignment from the inventors to ETRI is recorded, and the correspondent for that specific transaction is not specified in the available records.

4. Cascading transfers — not present. No assignments are recorded beyond the initial inventor-to-assignee transfer.

5. Pre-litigation transfer — unclear. Although litigation by Optimnet LLC was filed in September 2025, no assignment to Optimnet LLC is recorded in the USPTO Assignment Center. Without a recorded transfer, it is impossible to determine if a pre-litigation transfer occurred for this specific patent.

6. Bankruptcy fire-sale — not present. There is no indication that Electronics and Telecommunications Research Institute has filed for bankruptcy.

7. Privateering — unclear. While Optimnet LLC is asserting the patent, there is no public record or SEC filing indicating a specific privateering arrangement with the original assignee or another operating company.

8. Defensive aggregator (anti-NPE) — not present. The patent is currently being asserted by Optimnet LLC.

Verdict

NPE — high confidence

The primary signal supporting this verdict is that the current patent owner and plaintiff, Optimnet LLC, is a known patent assertion entity. This is confirmed by the ongoing district court litigation (Case 2:25-cv-00935) and the Inter Partes Review (IPR2026-00321) where Optimnet LLC is identified as the Patent Owner. The lack of recorded assignments to Optimnet LLC in the USPTO Assignment Center suggests that the transfer might have occurred through means not typically recorded in the public assignment database for this specific patent, or is part of a larger portfolio transfer. However, Optimnet LLC's established pattern as a patent asserter strongly indicates an NPE role.

Verification: https://assignmentcenter.uspto.gov/

Analysis of Prior Art for U.S. Patent 9,313,101

This analysis details the most relevant prior art cited against U.S. Patent 9,313,101, focusing on references considered by the USPTO examiner during prosecution. Each reference is evaluated for its potential to anticipate the independent claims of the '101 patent under 35 U.S.C. § 102.

The core invention of U.S. Patent 9,313,101 lies in combining traditional network traffic rules (based on packet "tuple information") with a time-based condition (e.g., time of day, specific date range) and specifying three distinct architectural locations for determining when this time condition is met: the Policy Server (PS), the Policy Management System (PMS), or the Policy Execution Equipment (PEE).

---

Examiner-Cited Prior Art

These references were cited by the USPTO patent examiner as relevant to the examination of the patent application.

1. U.S. Patent 6,859,841 B2

• Full Citation: US 6,859,841 B2, "Programmable system for processing a partitioned network infrastructure"
• Assignee: Intel Corporation
• Publication Date: February 22, 2005 (Filed: June 15, 1998)
• Description: This patent describes a system with a policy server that provides rules to distributed "policy targets" for enforcement. The patent explicitly states that policy rules can be defined with attributes including a "rule lifetime including start date and time and end date and time" (Column 13, lines 35-36 of US 6,859,841 B2). The policy server manages these rules and provides them to the network elements that will enforce them.
• Potential Anticipation: This reference is highly relevant as it discloses the combination of policy rules with specific time-based validity periods.
  • Claim 1: This claim is potentially anticipated. US '841 discloses a policy server that manages rules based on a "lifetime" defined by a start and end time. The server providing these rules to policy targets implies that the server is determining whether the rule is active ("execution time point arrives") before making it available for enforcement. This aligns closely with the process described in claim 1, where the policy server determines the execution time and then transmits the policy.
  • Claims 3 & 6: This reference is also relevant to claims 3 and 6. The "policy target" in the '841 patent could be analogous to the PMS or PEE. If the policy target receives rules with their start/end times and is responsible for checking the current time before enforcement, then it would anticipate the methods described in claims 3 and 6.

2. U.S. Patent Application Publication 2008/0316922 A1

• Full Citation: US 2008/0316922 A1, "Data and Control Plane Architecture Including Server-Side Triggered Flow Policy Mechanism"
• Assignee: Packeteer, Inc.
• Publication Date: December 25, 2008 (Filed: June 21, 2007)
• Description: This application details a policy server that communicates policy rules to a policy client for enforcement. The application explicitly discloses that a policy rule can have one or more "triggers," which are conditions that must be met for enforcement. A stated example of a trigger is "a time-of-day or a day-of-week" (Abstract). The application further clarifies that "The policy client evaluates the trigger condition" before enforcing the rule (Paragraph).
• Potential Anticipation: This reference strongly teaches time-based triggers for network policies.
  • Claim 1: This reference likely does not anticipate claim 1. The '101 patent's claim 1 requires the policy server to wait for the execution time and then transmit the policy. In contrast, the '922 application describes the policy being sent to the client with the time-based trigger, and the client is responsible for evaluating that trigger.
  • Claims 3 & 6: These claims are potentially anticipated. The "policy client" in the '922 application is analogous to the PMS (of claim 3) or the PEE (of claim 6). The client downloads the policy and its time-based trigger, and is explicitly responsible for "determin[ing] whether an execution time point of the policy arrives." This matches the methods of claims 3 and 6 directly.

3. U.S. Patent Application Publication 2013/0117847 A1

• Full Citation: US 2013/0117847 A1, "Streaming Method and System for Processing Network Metadata"
• Assignee: William G. Friedman
• Publication Date: May 9, 2013 (Filed: November 7, 2011)
• Description: This application describes a system for processing streams of network data by applying a set of rules. The application states that these rules can have "a time-based component (e.g., to only apply on weekdays between 9 am and 5 pm)" (Paragraph).
• Potential Anticipation: This reference provides another clear disclosure of combining network rules with time-based conditions.
  • Claim 1: Similar to the '922 application, this reference does not appear to describe the server-side time check required by claim 1.
  • Claims 3 & 6: The "rules engine" described in this application, which applies the time-based rules, is analogous to the PMS or PEE. The engine must check the current time to see if the rule is active, which aligns with the core steps of claims 3 and 6.

---

Other Cited Prior Art

The following references were also cited on the face of the '101 patent and are relevant.

1. Korean Patent Application Publication KR 2003-0003593 A

• Full Citation: KR 2003-0003593 A, "Network Security System and Method for applying Security Rule for Restricted Condition"
• Assignee: HackersLab Inc.
• Publication Date: January 10, 2003
• Description: An English-language abstract indicates this reference discloses a policy server that generates a security rule with a "time limit condition" and sends it to a "security agent." The agent applies the rule only when the current time is within the defined time limit.
• Potential Anticipation: This reference strongly anticipates claims 3 and 6 for the same reasons as US 2008/0316922 A1. The "security agent" performs the role of the PMS or PEE by downloading a policy and being responsible for checking the time condition before execution. It does not appear to anticipate claim 1.

2. U.S. Patent Application Publication 2008/0225708 A1

• Full Citation: US 2008/0225708 A1, "Application-aware policy enforcement"
• Assignee: Lange Andrew S
• Publication Date: September 18, 2008 (Filed: March 13, 2007)
• Description: This application describes policies being provisioned from a policy server to a policy enforcement point. It explicitly states, "The policy rule can define conditions when it is applicable, such as time of day, day of week, or other time-based criteria" (Paragraph).
• Potential Anticipation: This reference anticipates claims 3 and 6. The "policy enforcement point" is responsible for applying the rules, which includes checking the time-based criteria. This is directly analogous to the PEE (claim 6) or PMS (claim 3) determining the execution time. The reference does not appear to describe the specific server-side determination method of claim 1.

Obviousness Analysis of U.S. Patent 9,313,101 under 35 U.S.C. § 103

This analysis evaluates whether the independent claims of U.S. Patent 9,313,101 would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time of the invention, based on the prior art references detailed in the preceding section. An invention is considered obvious if the differences between the claimed invention and the prior art are such that the subject matter as a whole would have been obvious to a PHOSITA.

The central concept of the '101 patent is a network policy system where traffic rules are based on a combination of packet data (tuple information) and a time-based condition. The patent's claims are distinguished by the specific architectural component responsible for determining when the time condition is met: the Policy Server (PS) in claim 1, the Policy Management System (PMS) in claim 3, or the Policy Execution Equipment (PEE) in claim 6.

---

Analysis of Independent Claim 1

Claim 1: A method where a Policy Server (PS) determines if a policy's execution time has arrived and, if so, transmits the policy to a Policy Management System (PMS).

Obviousness Combination: U.S. Patent 6,859,841 B2 ('841) in view of engineering principles and knowledge common to a PHOSITA.

Reasoning:

1. Base Teachings of '841: U.S. Patent 6,859,841 B2 discloses a comprehensive policy management system. Crucially, it teaches a policy server that manages rules which can be defined with a "rule lifetime including start date and time and end date and time." This directly teaches the creation of time-based policies that combine network rules with a time condition, as required by claim 1. The '841 patent's server provides these rules to distributed "policy targets" for enforcement.

2. The Missing Element: Claim 1 requires a specific implementation detail: the PS must determine that the start time has arrived before transmitting the policy. The '841 patent describes a server managing time-based rules but does not explicitly forbid sending the policy to the target before its start time (i.e., sending the policy along with its "lifetime" metadata for the target to handle).

3. Motivation to Modify '841: A PHOSITA, when designing a system based on '841, would have been presented with a finite and predictable set of implementation choices for handling the "rule lifetime."

   • Option A: Send the policy and its lifetime metadata to the policy target and let the target manage the activation time.
   • Option B: Have the central policy server manage the activation time and only push the policy to the target when it is time for it to be active.

   Choosing Option B, which is the method of claim 1, would have been an obvious design choice for several compelling reasons:

   • Centralized Control: Managing policy activation at the server simplifies the logic required at the potentially numerous and less-powerful policy targets (the PEEs).
   • Resource Management: It prevents the network and the policy targets from being burdened with policies that are not yet active. The server only sends what is necessary at the time it is needed.
   • Simplified Auditing: A central server that logs exactly when it pushes each policy provides a simpler and more reliable audit trail for policy activation.

Therefore, modifying the system of '841 to have the server determine the execution time and transmit the policy only upon that time arriving is not an inventive step, but rather a predictable design choice to enhance centralization and efficiency. This would have been obvious to a PHOSITA.

---

Analysis of Independent Claims 3 and 6

Claim 3: A method where a Policy Management System (PMS) downloads a policy, determines if its execution time has arrived, and then transmits it to the Policy Execution Equipment (PEE).

Claim 6: A method where the Policy Execution Equipment (PEE) downloads a policy and determines for itself whether the execution time has arrived before enforcing it.

Obviousness Combination: U.S. Patent Application 2008/0316922 A1 ('922) alone or in view of the known functions of network management systems. The same argument can be made using KR 2003-0003593 A or US 2008/0225708 A1 as the primary reference.

Reasoning:

1. Base Teachings of '922: US 2008/0316922 A1 explicitly discloses the core of claims 3 and 6. It teaches a system where a policy rule has a "trigger," which can be a "time-of-day or a day-of-week." The application unequivocally states, "The policy client evaluates the trigger condition" before enforcing the rule.

2. Obviousness of Claim 6: The "policy client" of the '922 application is functionally identical to the "policy execution equipment" (PEE) of claim 6. Both are network devices that download a policy containing a time-based condition and are responsible for checking the current time to determine if the policy should be active. The method described in claim 6 is therefore directly taught by and would have been obvious in light of the '922 application.

3. Obviousness of Claim 3: Claim 3 introduces the intermediate Policy Management System (PMS) as the component that performs the time check. The three-tier PS-PMS-PEE architecture is a well-understood model for scalable network management. A PMS serves as a middle-management layer, aggregating policies from a central server and distributing them, often in a parsed or vendor-specific format, to numerous enforcement points.

   A PHOSITA, tasked with implementing the system of '922 in a large-scale network, would have found it obvious to instantiate the "policy client" function on a PMS. The motivation for this is clear:

   • Scalability: Having a PMS perform the time check for a whole group of PEEs is more efficient than requiring every single PEE to perform this check independently.
   • Abstraction: The PMS can abstract the policy logic from the PEEs. The PMS determines when a policy is active and then pushes a simple "execute now" command to the PEE, which might not need to be time-aware itself, thereby simplifying PEE hardware and software requirements.

   Therefore, applying the client-side time-check taught by '922 to the well-known PMS layer of a standard three-tier policy architecture would have been an obvious combination for a PHOSITA seeking to build a scalable and efficient policy enforcement system.

Analysis of Patent Term, Adjustments, and Family for U.S. Patent 9,313,101

Date of Analysis: April 26, 2026

This analysis details the term, continuity data, and international family of U.S. Patent 9,313,101. The information is based on the authoritative patent text and public records from the U.S. Patent and Trademark Office (USPTO).

Patent Term and Expiration

• Filing Date: October 4, 2012
• Issue Date: April 12, 2016
• Standard Term: 20 years from the filing date.
• Calculated Standard Expiration Date: October 4, 2032
• Projected Expiration Date: February 8, 2033

The projected expiration date includes adjustments granted by the USPTO.

Patent Term Adjustment (PTA)

Patent Term Adjustment (PTA) is a process by which the USPTO extends the term of a U.S. patent to compensate for certain administrative delays during prosecution.

For U.S. Patent 9,313,101, the USPTO has granted a Patent Term Adjustment of 127 days. This adjustment extends the patent's term beyond the standard 20 years from its filing date. The adjustment accounts for delays in examination by the USPTO, resulting in the adjusted expiration date of February 8, 2033.

Patent Term Extension (PTE)

There is no record of any Patent Term Extension (PTE) for this patent. PTE is typically granted to compensate for regulatory review delays (e.g., by the FDA) and is not applicable here.

Continuity Data

A review of the patent's prosecution history indicates that U.S. Patent 9,313,101, which issued from application number 13/645,090, has no related U.S. continuation or divisional applications. It is a standalone application in the United States.

Patent Family

This patent claims priority to and is part of a patent family that includes applications filed in South Korea.

• Priority Application: The U.S. application claims priority to Korean Patent Application No. 10-2012-0040556, which was filed on April 18, 2012. This earlier filing date is the priority date for the invention.

• Family Member Publications:

  • KR102007732B1: This appears to be the granted Korean patent corresponding to the priority application.
  • KR20130126791A: This is the publication of the Korean patent application.
  • US20130281075A1: This is the U.S. patent application publication for the '101 patent.

Defensive Disclosure and Prior Art Generation for U.S. Patent 9,313,101

Publication Date: April 26, 2026
Reference ID: DDPUB-2026-0426-ETRI1
Title: System and Method for Distributed, Time-Variant Policy Enforcement Across Heterogeneous Architectures and Emergent Technologies

This document discloses a series of derivative works, extensions, and combinations related to the core teachings of U.S. Patent 9,313,101 ("Method of controlling traffic by time-based policy"). The purpose of this disclosure is to place these extensions into the public domain, thereby establishing them as prior art for any future patent applications in this domain.

---

Derivatives Based on Independent Claim 1: Server-Side Time Determination

Claim 1 describes a Policy Server (PS) determining the execution time point of a policy and transmitting it to a Policy Management System (PMS) only when that time arrives. The following are derivative implementations.

1. Material & Component Substitution: Hardware-Accelerated Policy Server

• Enabling Description: The Policy Server (PS) is implemented not as a general-purpose CPU running software, but as a dedicated network appliance utilizing a Field-Programmable Gate Array (FPGA) or Application-Specific Integrated Circuit (ASIC). The time-determination logic (whether an execution time point of the policy arrives) is synthesized into hardware logic blocks. This provides deterministic, nanosecond-level precision for time checks, which is critical for applications like high-frequency trading or industrial control systems. The PS uses a temperature-compensated crystal oscillator (TCXO) or an oven-controlled crystal oscillator (OCXO) as its time source for high stability, and synchronizes via a hardware implementation of the Precision Time Protocol (PTP, IEEE 1588). Upon a successful time-check in the hardware logic, the policy is passed to a network interface controller (NIC) for transmission to the PMS.
• Mermaid Diagram:

  graph TD
      subgraph FPGA-based Policy Server (PS)
          A[PTP Hardware Clock] --> B{Time-Check Logic Block};
          C[Policy Storage on BRAM] --> B;
          B -- Time Match True --> D[DMA Engine];
          D --> E[Integrated NIC];
      end
      E -- Policy Transmission --> F[Policy Management System (PMS)];
  

2. Operational Parameter Expansion: Policies in Relativistic Time-Frames

• Enabling Description: The system is applied to manage communications between a ground station (PS) and multiple low-earth orbit (LEO) or deep-space satellites (PEEs). The PS must pre-calculate the policy execution time points by factoring in relativistic effects, including time dilation due to velocity (Special Relativity) and gravitational potential (General Relativity), as well as signal propagation delay. The PS determines that a policy's execution time point has arrived on the ground when the calculated transmission time plus propagation delay will cause the policy to arrive at the satellite precisely at the satellite's relativistically-adjusted target time. This method uses the SPICE toolkit from NASA for orbital mechanics and time-frame calculations.
• Mermaid Diagram:

  sequenceDiagram
      participant GroundStation_PS as PS (Ground Time)
      participant Satellite_PEE as PEE (Satellite Time)
      GroundStation_PS ->> GroundStation_PS: 1. Calculate T_exec_sat (target exec time on PEE)
      GroundStation_PS ->> GroundStation_PS: 2. Calculate T_prop (propagation delay)
      GroundStation_PS ->> GroundStation_PS: 3. Calculate T_rel_delta (relativistic time offset)
      GroundStation_PS ->> GroundStation_PS: 4. Determine T_tx_ground = T_exec_sat - T_prop - T_rel_delta
      loop Check Ground Time
          GroundStation_PS ->> GroundStation_PS: Is current_time >= T_tx_ground?
      end
      Note right of GroundStation_PS: Execution time point arrives
      GroundStation_PS ->> Satellite_PEE: 5. Transmit Policy
      Satellite_PEE -->> GroundStation_PS: (Policy arrives at T_exec_sat in PEE frame)
  

3. Cross-Domain Application: Agricultural Technology (AgTech)

• Enabling Description: A central AgTech cloud platform (PS) manages irrigation and fertilization policies for thousands of distributed farms. To conserve battery life and bandwidth for in-field IoT controllers (PEEs), the PS holds all weekly policies. It runs a daily cron job that determines which policies are active for the next 24-hour period (e.g., "Irrigate Zone A from 04:00-05:00"). Only at 00:01 local time each day does the PS transmit this subset of active policies to the regional farm hub (PMS), which then distributes them to the field controllers.
• Mermaid Diagram:

  graph TD
      A[AgTech Cloud PS] --> B{Time Check: T == 00:01};
      B -- True --> C[Select Active Policies for Next 24h];
      C --> D[Transmit Policy Subset];
      D --> E[Farm Hub PMS];
      E --> F[Field Irrigation Controller PEE];
      E --> G[Fertilizer Drone PEE];
  

4. Integration with Emerging Tech: AI-Predicted Policy Generation

• Enabling Description: The PS integrates a machine learning model (e.g., a recurrent neural network - RNN) that continuously analyzes network traffic metadata. The model predicts future congestion hotspots or security threats. When a future event is predicted with high confidence (e.g., a DDoS attack is likely at 3:00 PM), the PS pre-generates a mitigation policy. It then sets the execution time point for that policy to T-5 minutes (2:55 PM). The PS holds this policy and only transmits it to the PMS at the designated time, allowing for proactive, automated network defense.
• Mermaid Diagram:

  sequenceDiagram
      participant Monitor as Network Monitor
      participant AI_Model as Predictive AI
      participant PS as Policy Server
      participant PMS as Policy Management System
  
      Monitor->>AI_Model: Real-time traffic data
      AI_Model->>PS: Prediction: DDoS likely at 15:00
      PS->>PS: Generate mitigation policy
      PS->>PS: Set Execution Time = 14:55
      loop Until 14:55
          PS->>PS: Hold policy, check time
      end
      PS->>PMS: Transmit mitigation policy
  

5. Inverse/Failure Mode: "Heartbeat" Policy Transmission

• Enabling Description: The PS is designed for high-reliability networks where the health of the downstream PMS/PEE is unknown. Instead of a single transmission, the PS determines the policy's execution time window (start and end). Once the start time arrives, it begins transmitting the active policy to the PMS repeatedly at a configurable interval (e.g., every 60 seconds). This acts as both a policy enforcement mechanism and a heartbeat signal. If the PMS fails to receive the policy for N consecutive intervals, it triggers an alarm. The PS stops transmitting when the policy's end time arrives.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Inactive
      Inactive --> Active: Execution start time arrives
      Active --> Active: Transmit policy to PMS (every 60s)
      Active --> Inactive: Execution end time arrives
      Active --> Alarm: PMS fails to ack after N intervals
      Alarm --> Inactive: Manual Reset
  

---

Derivatives Based on Independent Claim 3: PMS-Side Time Determination

Claim 3 describes a PMS downloading a policy, storing it, and determining the execution time point before transmitting it to a PEE.

1. Material & Component Substitution: Distributed Consensus-Based PMS

• Enabling Description: The PMS is not a single server but a distributed cluster of nodes running a consensus algorithm like Raft or Paxos. A policy from the PS is downloaded and replicated across all nodes in the PMS cluster. The "determining whether an execution time point arrives" step requires a quorum of PMS nodes to independently agree on the current time (sourced from their local, synchronized clocks) and the validity of the policy. Only after consensus is reached does the leader node of the cluster parse and transmit the policy to the relevant PEEs. This prevents a single, compromised, or time-drifted PMS node from incorrectly activating a policy.
• Mermaid Diagram:

  graph TD
      subgraph Distributed PMS Cluster
          A[Node 1] -- Time & Policy Hash --> B{Raft Leader};
          C[Node 2] -- Time & Policy Hash --> B;
          D[Node 3] -- Time & Policy Hash --> B;
          B -- Quorum Achieved --> E[Parse & Transmit Policy];
      end
      PS -- Download Policy --> A;
      PS --> C;
      PS --> D;
      E --> PEE;
  

2. Cross-Domain Application: Smart Grid Energy Management

• Enabling Description: In an electrical smart grid, a Regional Operations Center acts as the PMS. It downloads various demand-response policies from the national grid operator (PS), such as "Reduce load by 10% from 17:00-20:00". The regional PMS stores these policies and monitors grid conditions and its local, high-precision clock. At 17:00, it determines the execution time has arrived. It then parses this high-level policy into specific commands for different types of PEEs: "Increase thermostat set-point by 2 degrees" for smart thermostats, and "Temporarily halt charging cycle" for electric vehicle charging stations.
• Mermaid Diagram:

  sequenceDiagram
      participant GridOperator_PS as PS
      participant RegionalCenter_PMS as PMS
      participant Thermostat_PEE as PEE-1
      participant EV_Charger_PEE as PEE-2
  
      GridOperator_PS->>RegionalCenter_PMS: Download Policy: ReduceLoad(10%, 17:00-20:00)
      activate RegionalCenter_PMS
      loop Until 17:00
          RegionalCenter_PMS->>RegionalCenter_PMS: Check time
      end
      RegionalCenter_PMS->>RegionalCenter_PMS: Time Match! Parse Policy.
      RegionalCenter_PMS->>Thermostat_PEE: Command: SetTemp(current+2)
      RegionalCenter_PMS->>EV_Charger_PEE: Command: PauseCharging()
      deactivate RegionalCenter_PMS
  

3. Integration with Emerging Tech: Blockchain-Verified Policy Auditing

• Enabling Description: The PMS includes a blockchain client. When the PMS downloads a policy from the PS, it stores the policy hash in its local database. When the PMS determines the execution time point has arrived, it performs two actions: 1) it transmits the policy to the PEE, and 2) it writes a transaction to a private, permissioned blockchain. This transaction contains the policy hash, the timestamp of the execution decision, and the ID of the target PEE. This creates an immutable, tamper-proof audit trail for compliance, verifying exactly when a policy was deemed active and to whom it was sent.
• Mermaid Diagram:

  flowchart LR
      subgraph PMS
          A[Download Policy] --> B[Store in DB];
          B --> C{Determine Execution Time};
          C -- Yes --> D[Transmit to PEE];
          C -- Yes --> E[Create Transaction: {PolicyID, Timestamp, PEE_ID}];
          E --> F[Write to Blockchain Ledger];
      end
      PS --> A;
      D --> PEE;
  

4. Operational Parameter Expansion: Geo-Temporal Policy Activation in CDNs

• Enabling Description: A Content Delivery Network (CDN) provider uses a globally distributed PMS layer. The PMS downloads a single policy from the central PS with a "local time" condition, e.g., "Serve video at lower bitrate from 08:00-11:00 AM local time." Each PMS node, located in a different geography (e.g., Tokyo, Frankfurt, Ashburn), is responsible for determining when 08:00 AM arrives in its own timezone. Upon reaching this local execution time, it pushes the bitrate-limiting policy to all PEEs (caching servers) under its regional control.
• Mermaid Diagram:

  graph TD
      PS -- Policy: LimitVideo(08:00-11:00 Local) --> PMS_Tokyo;
      PS --> PMS_Frankfurt;
      PS --> PMS_Ashburn;
  
      subgraph Tokyo
          PMS_Tokyo --> T_Check{Time == 08:00 JST?};
          T_Check -- Yes --> PEE_Japan;
      end
  
      subgraph Frankfurt
          PMS_Frankfurt --> F_Check{Time == 08:00 CET?};
          F_Check -- Yes --> PEE_Germany;
      end
  
      subgraph Ashburn
          PMS_Ashburn --> A_Check{Time == 08:00 EST?};
          A_Check -- Yes --> PEE_Virginia;
      end
  

5. Inverse/Failure Mode: "Stale Policy" Graceful Degradation

• Enabling Description: The PMS is designed to maintain operation if it loses its connection to the PS. The PMS stores all downloaded policies with their last-known validity window. If the connection is lost, the PMS enters a "fail-static" mode. It continues to determine execution time points for the policies it already has stored. However, once a policy's end-time passes, it is purged and not replaced. The system's functionality gracefully degrades as policies expire, rather than failing completely. A special, permanent "fail-safe" policy (e.g., "block all new connections") is activated if the connection to the PS is down for more than a specified TTL (e.g., 24 hours).
• Mermaid Diagram:

  stateDiagram-v2
      state "Connected" as C
      state "Disconnected" as D
  
      [*] --> C
      C --> D : Connection to PS Lost
      D --> C : Connection Restored
  
      state "Normal Operation" as C_Normal
      C: state C_Normal {
          [*] --> Download
          Download --> Store
          Store --> Determine_Time
          Determine_Time --> Transmit_to_PEE
          Transmit_to_PEE --> Store
      }
  
      state "Fail-Static Mode" as D_FailStatic
      D: state D_FailStatic {
          [*] --> Determine_Time
          Determine_Time --> Transmit_to_PEE : If policy is valid & active
          Determine_Time --> Purge_Policy : If policy has expired
      }
      D_FailStatic --> Activate_FailSafe : TTL Exceeded
  

---

Derivatives Based on Independent Claim 6: PEE-Side Time Determination

Claim 6 describes the Policy Execution Equipment (PEE) itself downloading the policy and determining the execution time point before executing it.

1. Material & Component Substitution: TPM-Secured Time Source

• Enabling Description: The PEE is a hardware device that includes a Trusted Platform Module (TPM) with a secure, monotonic counter and a hardware-backed real-time clock (RTC). Policies are downloaded from the PMS and stored in encrypted memory. For the PEE to "determine whether an execution time point arrives," it must receive a time signal from its TPM-secured RTC. The TPM signs the timestamp, preventing local software-based attacks from spoofing the time to prematurely activate or disable a policy. Execution only proceeds if the policy's time condition is met by a validly signed timestamp from the TPM.
• Mermaid Diagram:

  flowchart LR
      subgraph PEE
          A[PMS] -- Encrypted Policy --> B(Encrypted Storage);
          C[TPM] -- Signed Timestamp --> D{Time Check Logic};
          B -- Decrypt w/ TPM Key --> D;
          D -- Time Match & Valid Signature --> E[Execute Policy];
      end
  

2. Cross-Domain Application: Automotive Over-the-Air (OTA) Updates

• Enabling Description: A vehicle's Telematics Control Unit (TCU) acts as the PEE. The manufacturer (PS/PMS) pushes an OTA update package containing new software and a set of activation policies. One policy might be: "Apply powertrain update only when (vehicle_speed == 0) AND (local_time is between 02:00-04:00)." The TCU downloads this package and continuously monitors its own internal clock and vehicle CAN bus data. When it sees that the vehicle is parked and its clock is within the specified window, it self-determines that the execution time point has arrived and initiates the software flash.
• Mermaid Diagram:

  graph TD
      A[OTA Server] -- Update Package & Policy --> B[Vehicle TCU (PEE)];
      subgraph B
          C[Internal RTC] --> D{Time Check (02:00-04:00?)};
          E[CAN Bus Sensor] -- Speed=0 --> D;
          D -- All Conditions Met --> F[Initiate Powertrain Update];
      end
  

3. Integration with Emerging Tech: IoT Sensor-Triggered Time Windows

• Enabling Description: The PEE is an edge computing device controlling factory machinery. It downloads a policy: "Activate high-power diagnostic mode for 10 minutes." This policy is dormant until triggered. An attached IoT acoustic sensor, running a local ML model, detects an anomalous machine vibration. This sensor event triggers the start of the 10-minute time window. The PEE determines the "execution time point" has arrived upon receiving the trigger from the IoT sensor and then executes the policy, self-disabling it after the 10-minute duration has elapsed according to its internal clock. This combines an external event with an internal, time-based execution.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Idle
      Idle --> Executing : IoT sensor detects anomaly
      Executing --> Idle : 10-minute timer expires
  
      Executing: On Entry: Activate diagnostic policy
      Executing: On Exit: Deactivate diagnostic policy
  

4. Operational Parameter Expansion: Cryogenic Computing Environment

• Enabling Description: The PEE is a control module for a quantum computer, operating at cryogenic temperatures near absolute zero. It downloads experimental control sequences (policies) from a room-temperature PMS. Each policy is tagged with a valid execution window defined in terms of the number of clock cycles elapsed on a master cryogenic reference clock. The PEE determines the execution time point has arrived by comparing the cycle count from the reference clock to the policy's valid cycle window. This is necessary because standard RTCs do not function at such low temperatures and time must be tracked as discrete, high-frequency cycles.
• Mermaid Diagram:

  sequenceDiagram
      participant PMS as Room-Temp PMS
      participant PEE as Cryo-Control PEE
      participant RefClock as Cryo Reference Clock
  
      PMS->>PEE: Download Policy (Valid: Cycles 1M to 1.1M)
      loop
          RefClock->>PEE: Current Cycle Count
          PEE->>PEE: Is Count >= 1,000,000?
          alt Yes
              PEE->>PEE: Execute Policy
          end
      end
  

5. Inverse/Failure Mode: "Time-Drift Failsafe" Execution

• Enabling Description: The PEE is a low-cost IoT device with an imprecise internal clock. It periodically synchronizes with an NTP server. The PEE is programmed with a "maximum allowable time drift" parameter (e.g., 5 seconds). Before determining a policy's execution time, it first checks the time elapsed since its last successful NTP sync. If this duration exceeds a threshold, or if its calculated drift is greater than the parameter, it refuses to execute any time-based policies. Instead, it enters a limited-functionality mode and executes a static, pre-defined default policy until it can successfully re-synchronize its clock, preventing erratic behavior from time inaccuracy.
• Mermaid Diagram:

  flowchart TD
      A[Start Time Check for Policy X] --> B{Time since last NTP sync < Threshold?};
      B -- No --> C{Calculated Drift < Max Drift?};
      B -- Yes --> D{Is current time within Policy X window?};
      C -- No --> E[Enter Failsafe Mode: Execute Default Policy];
      C -- Yes --> D;
      D -- Yes --> F[Execute Policy X];
      D -- No --> G[Continue Monitoring];
  

---

Combination Prior Art Scenarios with Open-Source Standards

1. Combination with Kubernetes NetworkPolicy API: The PS-PMS-PEE architecture is mapped directly onto a Kubernetes cluster. A custom Kubernetes controller (acting as the PS) watches for NetworkPolicy objects that have a new, non-standard spec.timeCondition field (e.g., timeCondition: {tz: "UTC", startTime: "22:00", endTime: "06:00"}). This controller does not apply the policy directly. Instead, a DaemonSet running on each node (acting as the PMS) receives all NetworkPolicy objects. The PMS on each node determines, based on the node's local clock, if the timeCondition is met. If so, it translates the Kubernetes policy into rules for the underlying CNI plugin (e.g., Calico, Cilium), which acts as the PEE.

2. Combination with Prometheus and Alertmanager: An Alertmanager instance acts as the PS. A time-based policy is defined as an alert rule in Prometheus (e.g., ALERT TimePolicyActive IF hour() >= 9 AND hour() < 17). When this alert becomes Firing, Alertmanager (PS) sends a webhook containing the policy details to a generic policy orchestrator (PMS). The PMS parses the webhook and transmits the appropriate configuration to a network device (PEE). In this model, the "determination of the execution time" is performed by the Prometheus query engine, and the "transmission" is the Alertmanager webhook action.

3. Combination with IETF QUIC and BGP: A time-based policy is used to control BGP route advertisements for a QUIC-enabled service. A central BGP controller (PS) holds two potential route advertisements for a service prefix: a high-performance path and a low-cost, high-latency path. The PS determines, based on time-of-day, which policy is active. During peak business hours (09:00-17:00), it "transmits" the high-performance route to its BGP peers (PMS/PEE). During off-peak hours, it withdraws that route and transmits the low-cost route. This uses time-based policy logic to influence routing decisions for a specific application protocol (QUIC) at the network infrastructure layer (BGP).