US 6662235

I'll search for the specific patent number 6662235.

Let me search for litigation and CAFC docket information.

Summary of US Patent 6,662,235 (US6662235B1)

Important note on searches: I searched for the exact number "6662235" / "6,662,235." I found no results tying this patent to a CAFC 2026 docket, and no litigation in my available results. I cannot confirm any CAFC 2026 activity for this patent — I have no authoritative information on that, and I will not speculate. What follows is based on the patent text you supplied and on the search results retrieved.

Bibliographic data

Minor date discrepancy / uncertainty: Google Patents and the USPTO gazette give the filing/priority date as 2000-08-24 and the issue date as 2003-12-09. Unified Patents shows priority 2000-08-23, application date and grant date each one day earlier (2003-12-08), and expiration 2022-06-19. These one-day offsets appear to be database conventions/normalizations rather than substantive differences; I am reporting both rather than silently reconciling them.

Abstract (verbatim substance)

Embodiments of the invention include methods, systems and computer program products for a complex policy rule structured in a plurality of levels, where the rule selects an action based on a plurality of individual policy conditions. An event is received having an associated value defining a point in a space covered by the individual policy conditions. If the complex policy rule is a conjunctive normal form (CNF) rule, a plurality of summary conditions (one per level) are generated; the event's value is compared to a selected summary condition to determine if it is met; operations repeat for other summary and individual policy conditions until either a summary condition is not met or all individual policy conditions for one level are not met (allowing the rule to be skipped), or until at least one individual policy condition for each level is met. Disjunctive normal form (DNF) policy rule processing (using "collapsed" conditions) is also provided.

Plain-language overview of the independent claims

The patent is directed to speeding up evaluation of "If Condition then Action" policy rules (e.g., QoS/network policy rules per the IETF proposal) by pre-filtering conditions rather than evaluating every individual condition. Independent claims appear as a method claim, a system claim, and a computer-program-product (CPP) claim. Caveat: I have the full text of claim 1 and confirmation that claim 40 is a CPP claim, but I do not have authoritative claim text for the independent system claim. The three-independent-claim structure (method ≈ claim 1, system ≈ claim 20, CPP = claim 40) is a plausible reading of the 49-claim set but is not confirmed by my sources.

1. Claim 1 – independent method claim (CNF processing). Steps:

   • Determine whether the complex policy rule is a CNF policy rule.
   • Receive an event having an associated value that defines a point in the condition space.
   • If the rule is CNF: generate a plurality of summary conditions, one per level (a summary condition is the union/"superset OR" of the individual conditions at a level — its range runs from the lowest start value to the highest end value of that level's conditions).
   • Compare the event's value to a selected summary condition to see if it is met.
   • If that summary condition is not met, determine the rule may be skipped (a broad range failing guarantees every individual condition at that level fails).
   • Repeat the comparison across other summary and individual policy conditions until: a summary condition is not met, or all individual policy conditions for one level are not met, or at least one individual condition per level is met.
   • Skip the rule if a summary condition is not met or all conditions at one level fail.

   In short: use per-level "union" ranges as a fast, cheap gate; if the gate fails, discard the rule immediately without checking every underlying condition.

2. Independent system claim (number not confirmed). Directed to a data-processing system (processor plus memory containing rule-execution, CNF-test, and DNF-test logic) configured to carry out the same "determine CNF → generate summary conditions → compare → repeat/skip" operations described in claim 1. I could not retrieve the verbatim preamble/element text, so treat its exact scope as unconfirmed.

3. Independent computer program product claim (claim 40). A computer program product/computing device with computer-readable program code that (a) determines whether the complex policy rule is a CNF rule, (b) responsive to a CNF determination, generates summary conditions per level and compares the event's value to a selected summary condition, and (c) controls repetition of the comparisons until a summary condition is not met, all individual policy conditions for one level are not met, or at least one individual condition per level is met. Dependent claims (e.g., claims 43–44) add features such as selecting the summary condition most likely not to be met first, and executing the rule's action when at least one individual condition per level is met. A separate dependent claim adds the DNF analogue: if the rule is DNF, generate "collapsed" conditions (the intersection/AND of same-group ranges at a level) and execute the action if any one collapsed condition is met.

Supporting concepts that may appear in dependent claims (from the specification, not necessarily claimed independently): collapsed conditions may be declared invalid where same-group ranges do not intersect; an "all-inclusive" range is used as a summary when one condition imposes no limit on a group, or when two conditions each specify a different single (unitary) value for a group; condition groups include source/destination IP address range, inbound/outbound interface ID range, source/destination port range, protocol ID range, application name, and application data classification; and ordering comparisons by likelihood (largest/most-likely-met first for DNF; smallest/most-likely-to-fail first for CNF) to enable early exit.

Uncertainties to flag

• CAFC 2026 dockets: No results. I cannot confirm any 2026 Federal Circuit appeal involving US 6,662,235. The patent's stated legal status is Expired – Lifetime (expiration 2022-06-20), which makes current appellate activity unlikely, but I am not asserting that as fact.
• Exact independent-claim set: Claim 1 (method) and claim 40 (CPP) are confirmed; the independent system claim's number and text are not confirmed from my sources.
• Third-party "value" figures (e.g., a cited ~$6.52M estimated value on patentleaderboard.com) are third-party estimates, not authoritative USPTO data, and should not be relied upon.
• Assignee history shows an original assignment to IBM with a later recorded transfer to Trend Micro (2010-05-19); whether further transfers occurred is not established by my sources.

I'll research litigation involving US Patent 6,662,235. Let me search multiple sources.

Let me search more specifically for this patent in litigation contexts.

Let me search the litigation portals and CourtListener directly.

Litigation Involving U.S. Patent No. 6,662,235

Finding: No litigation involving U.S. Patent No. 6,662,235 could be identified in the sources searched.

What I searched

I queried the Unified Patents litigation portal (portal.unifiedpatents.com), Google Patents, CourtListener, and general web sources for the specific number 6,662,235 and for related case documents. To avoid conflating this patent with similarly numbered patents, I treated the number literally: the only patent matching 6,662,235 is US 6,662,235 B1, "Methods, Systems and Computer Program Products for Processing Complex Policy Rules Based on Rule Form Type" (Application No. 09/645,147; filed August 24, 2000; granted December 9, 2003).

Results

• Unified Patents portal (https://portal.unifiedpatents.com/patents/patent/US-6662235-B1): The patent's record page displays bibliographic data (inventors, assignees, priority/grant/expiration dates, valuation metrics) but did not return any associated litigation (case list) entries for this patent. The page shows "Family Members (0)" and no case links.
• CourtListener / general web: No docket, complaint, or decision referencing patent 6,662,235 was returned. Results for other numbers (e.g., the '235 patent at issue in Bacus Laboratories v. Aperio Technologies is U.S. 6,272,235 — a different patent) were excluded per your instruction not to substitute similar numbers.
• No ANDA/pharmaceutical-style 6,362,178 case, no Lone Star v. Asus ('435 patent), and no other hit relates to 6,662,235.

Context that may explain the absence of litigation

• Ownership: Originally assigned to International Business Machines Corp. (2002), then reassigned to Trend Micro Incorporated (recorded May 19, 2010; currently listed as Trend Micro Inc.).
• Status: The patent is recorded as Expired – Lifetime, with an adjusted expiration of June 20, 2022. Even if it had been asserted, its term has now lapsed, and the ~22-year-old priority date (2000) places it well before the modern NPE assertion wave for this technology area.

Important limitations / caveats

• I could not independently verify against PACER or the CAFC docket directly (those require authenticated access and were not reachable within the searches performed). It is possible a suit exists that is not indexed by the free portals searched.
• Because the patent is not in a class that commonly appears in Unified Patents' NPE-tracking case list, a litigation record may simply never have been created on that platform.

Conclusion: Based on the sources searched, I have no evidence of any lawsuit, ITC action, or PTAB proceeding involving U.S. Patent No. 6,662,235. If you require a definitive negative, I recommend verifying directly on PACER (search "6,662,235" as a patent-in-suit across all district courts) and on the CAFC docket, since a paid/authenticated search could confirm the absence with certainty. I did not find any case to report for the requested categories (plaintiff, defendant, jurisdiction, case number, filing date, status).

I'll verify against the canonical structured data and then search for any PTAB activity on this patent.

Let me run additional targeted checks before concluding.

One more verification pass on litigation/PTAB databases.

Cross-reference note (contradiction flagged)

Before the PTAB analysis, one correction to the previously generated "Patent summary" section. That section guessed the independent-claim structure as "method ≈ claim 1, system ≈ claim 20, CPP = claim 40" and flagged the system claim as unconfirmed. Search results retrieved for this task show the actual independent claims more likely to be:

• Claim 1 — independent method (CNF)
• Claim 24 — independent method (referenced by claim 25 as "the method of claim 24 wherein the step of generating a plurality of summary conditions…")
• Claim 29 — independent method (DNF: "A method for processing a complex policy rule… generating a plurality of collapsed conditions…")
• Claim 30 — independent system claim, means-plus-function ("means for determining… means for receiving… means for generating a plurality of summary conditions…")
• Claim 40 — independent computer program product

So the prior "system ≈ claim 20" guess is contradicted; the system claim appears to be claim 30. Treat the independent-claim set as still not fully verified (I have snippets, not the full claim set), but do not rely on claim 20 as the system claim.

Proceedings overview

Zero (0) AIA trial proceedings — 0 IPR, 0 PGR, 0 CBM — have ever been filed against US 6,662,235. The USPTO Open Data Portal structured block supplied with this task reports no AIA trial proceedings on file as of the most recent ingest, and my independent web searches for PTAB activity on this patent number (queries covering "6662235"/"6,662,235" combined with IPR, PTAB, CBM, petitioner, and Trend Micro) returned no petition, institution decision, Final Written Decision, or appeal — the functional breakdown is therefore active 0 / invalidated 0 / sustained 0 / settled 0 / institution-denied 0.

Bottom-line defensive posture for a defendant: the patent has never been tested at the PTAB, so all 49 claims remain presumptively valid and entirely un-narrowed — there is no FWD to hide behind and no § 315(e) estoppel to leverage; the only real defenses are that the patent expired on 2022-06-20 (Google Patents) and that any damages theory is now confined to a shrinking pre-expiration window.

No proceedings to report

There is no proceeding number to give you, and I will not manufacture one. The structured "PTAB proceedings on file" block is the canonical source here, and it is empty; my web searches did not surface older or recently-filed proceedings the ODP might have missed, nor any Unified Patents-style defensive filing, nor any Federal Circuit appeal arising from a PTAB FWD on this patent. This is consistent with the earlier-generated section of this analysis, which likewise found no CAFC 2026 docket and no litigation tying this number to an appeal.

Two practical caveats, stated plainly rather than papered over:

• Absence of evidence vs. evidence of absence. I cannot prove a negative from web search alone. The authoritative statement is the ODP result (none); my searches are corroborating, not conclusive, for anything filed in the last few weeks.
• Ex parte reexamination would not appear in an AIA-trial list. If any ex parte reexam request was filed, it would not be captured by the structured block. I did not find one, but I am not asserting that none exists.

Strategic summary

Claim status: 1–49 are UNTESTED, not canceled, not sustained. No claim of US 6,662,235 has ever been canceled through an AIA trial, and none has been adjudicated patentable in one either. For a defendant, that cuts both ways: you inherit no free kill (no canceled independent claim to point at), but you also face no inter partes estoppel and no hardened claim set that already survived a merits challenge. The prior-art universe is fully open to you.

Estoppel landscape is empty. Because no IPR/PGR/CBM was ever instituted, 35 U.S.C. § 315(e)(2) estoppel is not triggered by anyone on this patent. No petitioner, and no privy of any petitioner, is barred from raising any § 102/§ 103 ground in district court. Conversely, if you file an IPR and reach an FWD, you will then be estopped as to grounds you raised or reasonably could have raised — the normal asymmetry applies fresh.

Pattern signals: no serial-petition pattern (there is no petition), no patent-owner PTAB appeal pattern, and no defensive aggregator appears in the chain. The ownership chain runs IBM (original assignee) → Trend Micro Incorporated (assignment recorded 2010-05-19). Trend Micro is itself a frequent petitioner at the PTAB — but I found no evidence it has ever been a patent owner defending this patent in an AIA trial.

The expiration clock dominates the analysis. Google Patents states Expired – Lifetime, adjusted expiration 2022-06-20; Unified Patents shows 2022-06-19. The patent is not in force, so any assertion today is a past-damages-only claim. Under 35 U.S.C. § 286 the damages lookback is six years from the date suit is filed, which means a complaint filed in, say, 2027 can reach back only to 2021 — a narrow pre-expiration slice. Practically, the actionable tail runs until roughly mid-2028, six years after expiration. That is the real risk window, not a live injunction threat. It is also the main reason the absence of IPRs is unsurprising: for most defendants, the cost of an IPR exceeds the value of knocking out a patent that can no longer be infringed.

Recommended next steps

• Do not plan around a canceled claim. There is no FWD to cite and no canceled claim 1, 24, 29, 30, or 40 to hand a plaintiff. Any argument that "the PTAB killed this patent" is false as of today.
• Verify the canonical list yourself before relying on this. Run the patent number through USPTO Patent Trial and Appeal Board (PTAB) E2E (https://developer.uspto.gov/ptab-web/) and the USPTO Open Data Portal trial-proceedings endpoint, and cross-check CourtListener (https://www.courtlistener.com/) for any FWD or Rule 36/Rule 35 appeal mentioning 6,662,235. My searches corroborate the ODP "none," but the primary source should control.
• If you are a defendant facing a demand letter: the strongest structural defenses are (i) expiration on 2022-06-20 and the corresponding § 286 six-year damages cutoff, and (ii) invalidity under § 101 given the patent's age and abstract-idea framing (rule-condition pre-filtering) — note the Federal Circuit's Intellectual Ventures v. Symantec/Trend Micro line applied § 101 to network-rule patents. Neither route has been pre-empted by any PTAB ruling on this patent.
• If an IPR is nonetheless worth filing (e.g., a large pre-expiration damages exposure or an indemnity position): the runway is short and shrinking. There is no institution decision, no oral hearing, and no FWD due date to track because no trial exists — you would be starting from a clean slate with the § 316(a)(11) one-year-from-institution clock applying only after your own petition is instituted.
• Confirm the independent-claim map (claims 1, 24, 29, 30, 40 per the snippet evidence above) against the issued patent at https://patents.google.com/patent/US6662235/en before drafting any claim-chart or invalidity contention.

Uncertainties I will not paper over: I could not verify the complete independent-claim set (snippet-level evidence only); I cannot rule out a very recent filing or an ex parte reexam not captured by the ODP ingest; and the 2022-06-19 vs. 2022-06-20 expiration discrepancy noted in the prior section remains unreconciled — both dates are reported, neither silently adopted.

I'll research the assignment record for US 6,662,235 across the USPTO Assignment Center and related sources.

Let me search for the specific reel/frame and correspondent data.

I hit the research step limit before I could pull the Assignment Center record directly, so I'm reporting what is recoverable and flagging exactly what could not be confirmed. No reel/frame numbers or correspondent-of-record data could be retrieved from any source I reached (Google Patents legal events, Unified Patents, general web). I will not invent those fields.

Inventors

All six inventors are listed on the issued patent (Google Patents bibliographic record; also Unified Patents page for US-6662235-B1):

Employer determination: The residences all cluster in the Raleigh–Durham–Chapel Hill corridor, home to IBM's Research Triangle Park facility. Confirmed by the recorded assignment in which these six inventors conveyed their rights to International Business Machines Corporation (Google Patents legal event, recorded 2002-05-24, assignors: FRANKS, JON KEVIN; SHANNON, DIANE IUPE; YANG, DAVID YU PIN; CALLIS, GREGORY M.; HUYNH, LAP THIET; NGUYEN, LOAN).

Unusual-pattern check: The "all inventors departed within 12 months of filing" tell could not be assessed — I found no employment-tenure or departure data for any inventor. No finding either way. (Note: an inventor→employer assignment recorded ~21 months after the August 2000 filing is mildly late for a same-day RTP filing, but this is a recordation-timing observation, not evidence of any problem.)

Original assignee

International Business Machines Corporation, Armonk, NY — the entity named on the issued patent (issued 2003-12-09 as US 6,662,235 B1) and the original assignee per Google Patents and Unified Patents.

• Primary line of business: diversified enterprise IT — hardware, software, and services; in 2000 it was also a networking-equipment and network-management vendor, which is the natural commercialization home for a QoS/policy-based networking (IETF policy core schema) patent.
• Did it ship a product embodying the claims? Unclear / not determinable from my sources. The patent is directed to software logic for evaluating IETF-style policy rules (CNF/DNF forms) — the specification expressly frames it as deployable in "routers 120," bridge/switches, servers, or clients. I could not tie it to a specific shipping IBM product (e.g., a named Nways/policy-management release). Do not treat "IBM shipped it" as established.
• Current status: IBM is an operating, publicly traded company (NYSE: IBM) — not dissolved, acquired, or in bankruptcy. It is no longer the owner of this patent.

Assignment timeline

Important caveat: The USPTO Assignment Center / assignment.uspto.gov record for this patent returned no accessible results in my searches, so I cannot supply reel/frame numbers or the correspondent-of-record for either link. The two links below are reconstructed from Google Patents "legal events / reassignment" entries, which mirror recordation events but omit reel/frame and correspondent fields. Treat reel/frame and correspondent as unretrieved, not as non-existent.

1. [execution date not shown] / recorded 2002-05-24 — Reel not retrieved / Frame not retrieved

   • Conveyance: Assignment of assignors' interest ("ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
   • Assignor: Callis, Gregory M.; Franks, Jon Kevin; Huynh, Lap Thiet; Nguyen, Loan; Shannon, Diane Iupe; Yang, David Yu Pin (all six named inventors)
   • Assignee: International Business Machines Corporation, Armonk, NY
   • Correspondent: Not retrieved — cannot confirm IBM's IP Law Dept. (Somers, NY) or any outside counsel; cannot assess recurrence.
   • Context: Standard employee/inventor→employer assignment perfecting IBM's title during prosecution (patent issued 2003-12-09). Not a sale.

2. [execution date not shown] / recorded 2010-05-19 — Reel not retrieved / Frame not retrieved

   • Conveyance: Assignment of assignors' interest ("ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
   • Assignor: International Business Machines Corporation
   • Assignee: Trend Micro Incorporated
   • Correspondent: Not retrieved — cannot confirm which firm/attorney recorded the IBM→Trend Micro conveyance. This is the single most important missing field for the correspondent-recurrence test.
   • Context: Corporate portfolio divestiture — IBM sold/transferred a batch of patents to Trend Micro (an operating security-software vendor), not a transfer to an anonymous licensing LLC. (The prior "Patent summary" section already established this 2010-05-19 reassignment; no contradiction.)

No further assignments appear after 2010-05-19. The chain terminates at Trend Micro. (Google Patents shows the 2022-06-20 entry as an adjusted expiration legal-status event, not an assignment.)

Timeline diagram

timeline
    title Ownership of US 6662235
    2000 : Application filed
    2002 : Inventors assigned rights to IBM
    2003 : Patent issued to IBM
    2010 : Assigned to Trend Micro Incorporated
    2022 : Patent expired

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The only post-issuance transfer is IBM → Trend Micro Incorporated (recorded 2010-05-19). Trend Micro is a large, publicly traded security-software operating company (Tokyo Stock Exchange: 4704), not an "IP/Holdings/Licensing/Ventures" LLC. No registered-agent address, no single-member-LLC indicia in the record I retrieved.

2. Known asserter in the chain — Not present. Neither IBM nor Trend Micro appears on the supplied NPE list (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities). Both are operating companies.

3. Repeat correspondent across the chain — Unclear / not assessable. No correspondent-of-record was retrievable for either the 2002-05-24 or 2010-05-19 recorded event. Without reel/frame and correspondent data I cannot run the recurrence test — this is a data gap, not a negative finding.

4. Cascading transfers — Not present. Only one post-issuance transfer exists in the record, and it occurred ~10 years after filing and ~6.5 years after issuance — no chained LLCs, no <24-month cascade.

5. Pre-litigation transfer — Not present. The prior "Litigation summary" section found no lawsuit, ITC action, or PTAB proceeding involving US 6,662,235. There is therefore no first-suit date against which the 2010-05-19 transfer could fall within six months.

6. Bankruptcy fire-sale — Not present. No Chapter 7/11 proceeding is associated with either IBM or Trend Micro in my sources. The 2010 transfer is a corporate sale, not a court-supervised asset liquidation.

7. Privateering — Unclear (no evidence either way). No SEC filing, Patent Progress, or EFF coverage in my results shows IBM transferring this patent to an NPE to assert on IBM's behalf. Trend Micro is a direct operating competitor-type acquirer, not an IBM proxy asserter. I found nothing to support privateering, but I also could not rule it out with an SEC-filing review.

8. Defensive aggregator (anti-NPE) — Not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN; it terminates at Trend Micro, an operating company.

Verdict

Insufficient data.

Reasoning: The recoverable chain — inventor assignment to IBM recorded 2002-05-24, then a single corporate transfer to Trend Micro Incorporated recorded 2010-05-19 — shows no NPE signals (no shell LLC, no known asserter, no cascade, no pre-litigation timing, no bankruptcy, no defensive aggregator), and no litigation involving this patent exists in the prior section's research. However, the USPTO Assignment Center record (reel/frame and correspondent-of-record) could not be retrieved for either link, so the two required evidentiary anchors for an NPE call — the recorded document identifiers and the correspondent-recurrence test — are unverified. Under the supplied taxonomy this does not qualify as "Defensive / non-asserting" (Trend Micro is not a defensive aggregator) and there is no "Operating-company assertion" (no suit found); accordingly I record Insufficient data, with the substantive note that on the retrievable record the ownership chain looks like a normal operating-company portfolio sale, not an NPE arrangement.

Verify at: https://assignmentcenter.uspto.gov/ (search patent number 6662235) and https://assignment.uspto.gov/patent/index.html — both should surface the two recorded events above with their reel/frame, execution date, and correspondent, which are the fields I could not confirm.

Flagged contradiction / gap vs. prior sections: None substantively — the 2002-05-24 inventor assignment and 2010-05-19 Trend Micro reassignment are consistent with the earlier "Patent summary" and "Litigation summary." The one-day date offsets noted earlier (Unified Patents showing 2000-08-23 / 2003-12-08 / 2022-06-19) persist and remain a database-normalization artifact, not a title dispute.

I'll research the prior art citations for US 6,662,235. Let me run several targeted searches.

I have the patent's front-page citation list from the Indiana virtual disk library. Let me pull the full "References Cited" section and the citing/cited references.

The front-page citation list isn't surfacing directly. Let me try FreePatentsOnline, Patentscope, and the patent PDF front page.

Retrieval limitation — state this up front

I was asked to work through each patent citation on US 6,662,235. I was not able to retrieve the patent's front-page "References Cited" list (the examiner-/applicant-cited U.S. Patent Documents, foreign documents, and other publications). My searches returned:

• the Google Patents description page for US6662235B1 (claim/spec text only — no citation table rendered),
• the USPTO Gazette abstract/claim text at the Indiana virtual disk library, and
• forward citations (patents that cite 6,662,235, e.g. US 9,130,921 and US 2007/0288430), which are not prior art to this patent.

I therefore cannot enumerate the examiner-cited patent references by number, and I will not invent them. Below is what I can substantiate, plus an explicit list of what remains unverified.

1. Reference confirmed from the patent itself (non-patent literature)

"Policy Core LDAP Schema," Internet Draft, draft-ietf-policy-core-schema-07.txt, July 14, 2000 (IETF).

• Citation as used in the patent: the spec calls this the "IETF proposal" and identifies it as the source of the policy-rule schema the invention builds on.
• Date: July 14, 2000 — roughly six weeks before the Aug. 24, 2000 filing date.
• Brief description: An IETF object-oriented policy schema defining three policy classes —policyRule, policyAction, and policyCondition — with the semantics "If Condition then Action." Conditions represent criteria used to identify groupings (host, routing, application, etc.), and the schema contemplates multiple levels of policy conditions to be evaluated before an action executes. The application-condition group includes an attribute identifying the content of application data (for Web requests, the URI portion of the URL).
• Earlier related version found: draft-ietf-policy-core-schema-00, dated November 1998 (https://dt-main.dev.ietf.org/doc/html/draft-ietf-policy-core-schema-00) — an even earlier publication of the same schema family, i.e., potentially stronger §102 art on the conceptual subject matter than the -07 draft the patent cites.

Mapping to claims. The IETF proposal supplies the background claim elements — the notion of a policy rule, of individual policy conditions, of conditions organized into levels, and of condition "groups" (source/destination IP, ports, interface IDs, application name/data classification). It does not, on the face of the specification's own description, teach the characterizing steps of claim 1: generating a plurality of "summary" conditions (the per-level superset/union range) and using a failed summary condition to skip the rule. So:

• §102 anticipation: I found no basis to say the IETF draft anticipates claim 1 (or its system/CPP counterparts) — the summary-condition gating step is absent. It is best characterized as §102/§103 background art for the rule/condition/level framework, not as an anticipatory reference for the independent claims.
• §103: it is the natural primary reference against which a "determine whether the rule is CNF vs. DNF + structure the condition evaluation" limitation would be obviousness-mapped.

The independently-published earlier -00 draft (Nov. 1998) should be checked as an alternative, earlier-dated version of the same disclosure.

2. Adjacent reference identified incidentally (not confirmed as cited on the face)

US 6,820,121 B1 — patentimages PDF, https://patentimages.storage.googleapis.com/18/95/42/1cf8a266be25b0/US6820121.pdf. Its background reproduces the identical IETF "Policy Core LDAP Schema," draft-ietf-policy-core-schema-07.txt, Jul. 14, 2000 passage found in US 6,662,235. This indicates a shared art cluster (IBM policy-rule/QoS work) but I could not confirm US 6,820,121 is itself listed in 6,662,235's citation table, and its publication date would need to be checked against the 2000 priority date before it could be §102 art.

3. What I could not verify (and why it matters)

The tool searches I ran were exhausted before I could reach a page that renders the citation table (Google Patents' "References Cited" section, FreePatentsOnline's "Patent References Cited / Other References," or the patentimages PDF cover page). Fabricating plausible-looking 6,xxx,xxx numbers for this space (there are many superficially similar policy/QoS/rule-evaluation patents) would be exactly the error the operating rules forbid.

4. Recommended next retrieval steps (to complete the task)

1. Open the cover page of the granted PDF at https://patentimages.storage.googleapis.com/d6/65/31/435b956f2307e0/US6662235.pdf (page 1) — this lists every "References Cited" entry with number, date, and assignee.
2. FreePatentsOnline: https://www.freepatentsonline.com/6662235.html → "Patent References Cited" and "Other References" sections.
3. Patentscope / Espacenet record for US6662235B1 → "Cited documents."
4. For each retrieved patent citation, compare its publication or filing date to 2000-08-24 to classify it as §102(a)/(e) vs. §102(b), then map its disclosure against claim 1 (method), the system claim, and claim 40 (CPP) — paying particular attention to whether any reference discloses the "summary condition" / per-level union range and the "skip on failed summary" logic, since that is the apparent point of novelty.

Bottom line: on the sources I could reach, the only prior-art citation I can state with confidence is the IETF "Policy Core LDAP Schema" Internet Draft (draft-ietf-policy-core-schema-07.txt, Jul. 14, 2000; earlier -00 version, Nov. 1998). It is strong background/§103 art for the policy-rule-and-levels framework but does not appear to anticipate the independent claims. The full examiner-cited patent list remains unretrieved, and I am flagging that rather than guessing at it.

I'll research the prior art landscape for this patent before building the obviousness analysis.

Let me pull the specific cited references from the patent's front page.

Let me find the specific front-page references cited against this patent.

Obviousness Analysis — U.S. Patent No. 6,662,235 under 35 U.S.C. § 103

0. Sources used and a threshold caveat

This analysis is built on the prior-art materials associated with the patent page:

• The patent's own Background section, which expressly cites and characterizes the IETF "Policy Core LDAP Schema," draft-ietf-policy-core-schema-07.txt, July 14, 2000 ("IETF proposal") — source: https://patents.google.com/patent/[US6662235](/patent/US6662235)/en
• The "Prior art keywords" indexed for this patent: conditions, met, policy, collapsed, levels (same URL) — these keywords tell us the examiner's own framing of the closest art: policy-condition evaluation, per-level conditions, and "collapsed" conditions.
• The Unified Patents record, which shows the examiner-cited art as Patent Art (5) and Non-Patent Literature (4), with Referenced By (151) — source: https://portal.unifiedpatents.com/patents/patent/US-6662235-B1

Important limitation (flagged, not papered over): the fetched Google Patents text did not include the verbatim "References Cited" table, and my follow-up searches for the five cited patent references and four NPL items returned no list. I therefore cannot name the specific front-page references verbatim, and I will not fabricate patent numbers. What I can do reliably is (a) analyze against the art the patent itself admits, and (b) test the claims against the categories of art a person having ordinary skill in the art ("POSITA") demonstrably possessed as of the August 24, 2000 priority date. Where I rely on my own knowledge of a reference rather than on a retrieved document, I label my confidence.

This builds on — and does not repeat — the earlier-generated Patent Summary and Litigation Summary. Two cross-references are load-bearing here: the earlier section's unconfirmed status of the independent system claim (method ≈ claim 1, system ≈ claim 20, CPP = claim 40), and its finding of no identified litigation. I carry both caveats forward; nothing below depends on the system claim being exactly claim 20.

1. Legal framework

Under Graham v. John Deere Co. v. Graham, 383 U.S. 1 (1966), obviousness is assessed against four factors: (1) the scope and content of the prior art; (2) the differences between the prior art and the claims; (3) the level of ordinary skill; and (4) objective indicia (secondary considerations). Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), a combination is obvious where the improvement is a "predictable use of prior art elements according to their established functions," where a "design incentive" or "market pressure" drove the combination, or where a "known technique" was applied to a "known structure" — the motivation need not be found in the references themselves.

Effective filing date / applicable prior art. The application was filed August 24, 2000; priority is the same date (Unified Patents shows a one-day-shifted 2000-08-23 normalization, flagged in the earlier summary). This is pre-AIA art. Qualifying art is therefore (i) printed publications or public use/knowledge before the invention date under § 102(a); (ii) publications more than one year before filing under § 102(b); or (iii) U.S. patents/applications with an earlier effective filing date under § 102(e).

2. Level of ordinary skill in the art (POSITA)

A POSITA here would be a network/software engineer with a bachelor's degree in computer science or electrical engineering and roughly 2–4 years of experience in policy-based networking, IP routing/QoS, or packet classification, comfortable with Boolean algebra (CNF/DNF normal forms, short-circuit evaluation) and with interval/range arithmetic. This is a modest skill level: the invention is an algorithmic optimization within an existing standards framework, not a new science.

3. The claimed subject matter, distilled

Consistent with the earlier Patent Summary (claim 1 = method; claim 40 = CPP; system claim unconfirmed):

Claim 1 (CNF method). Determine whether a multi-level rule is CNF; receive an event whose value is a point in the condition space; if CNF, generate one summary condition per level — the union / superset-OR of that level's individual range conditions (lowest start → highest end); compare the event to a selected summary condition; skip the rule if it fails (a failed union guarantees every individual condition at that level fails); repeat across summary and individual conditions until (i) a summary fails, (ii) all individual conditions for a level fail, or (iii) at least one individual condition per level is met.

DNF-dependent claims. For DNF rules, generate collapsed conditions = the intersection / AND of same-group ranges at each level; if any collapsed condition is met, execute the action.

Other dependents. Ordering the "most likely not to be met" summary first (CNF) / "most likely to be met" collapsed first (DNF); "all-inclusive" range handling; declaring a rule invalid where same-group ranges do not intersect; enumerated condition groups (source/dest IP range, inbound/outbound interface ID, source/dest port, protocol ID, application name, data classification).

The entire claimed advance is therefore: use a cheap, sound (never-false-negative) pre-filter derived from the rule's normal form to short-circuit evaluation of the expensive individual conditions.

4. Scope and content of the prior art

Difference from the claims. R1–R6 teach the framework (multi-level, range-valued policy conditions, event/flow evaluation, multi-field classification) and the general optimization technique (fail-fast predicate ordering; coarse-then-fine classification). None of the retrieved/known general references, standing alone, teaches generating a per-level union "summary condition" for a CNF rule as a gate or a per-level intersection "collapsed condition" for a DNF rule. That is the point of novelty — and, as shown below, the point on which obviousness turns, because it is a direct and predictable application of Boolean normal-form algebra to an admitted framework.

5. Combination A (primary): R1/R2/R3 + R4/R5 → Claim 1

Proposed combination. Combine the IETF policy framework (R1) — with its multi-level, range-valued policy conditions — with the packet-classification / predicate-ordering art (R4, R5).

Element mapping.

• "complex policy rule structured in a plurality of levels … individual policy conditions … expressed as ranges and associated with one of the levels." → Fully disclosed by R1, which the applicant itself describes as "reference[ing] multiple levels of policy conditions to be evaluated," with host/routing/application condition groups and range attributes. This element is not merely obvious; it is substantively anticipated by the applicant's own admitted art.
• "receiving an event … defining a point in a space covered by the individual policy conditions." → R2/R3 (a flow/packet with a multi-field tuple evaluated against the rule) and R5 (a packet as a point in a multi-dimensional field space).
• "determining if the complex policy rule is a CNF policy rule." → R1's schema permits AND/OR combinations of referenced conditions; reading a rule's grouping/flag to obtain its normal form is a definitional step, squarely within R7.
• "generating a plurality of summary conditions, each associated with one of the levels" (the union/superset). → This follows mechanically from the CNF structure: a level in a CNF rule is an OR of its individual conditions, and the satisfying set of an OR of ranges over a common field is, by definition, their union — representable as the interval from the minimum lower bound to the maximum upper bound. R5's aggregation/precomputation teaches computing coarse envelope structures over rule fields; R7 teaches the union operation. Neither is a leap.
• "comparing … to a selected summary condition … skip if not met" and "repeat … until one summary is not met, all individual conditions of a level are not met, or at least one condition per level is met." → This is precisely short-circuit evaluation of (C1.1 OR C1.2 OR C1.3) AND (C2.1 OR C2.2) (R7) and the coarse-filter-then-precise-match strategy of R5. If the OR-level gate (the union) is false, no member of the OR can be true, so the whole AND fails — the "sound pre-filter" property is a theorem, not an invention.

Motivation to combine (KSR). The patent's own Background supplies the motivation verbatim: implementation "in time sensitive environments, such as a high speed network environment, can place time critical demands on processing capabilities," and "fast methodologies for processing communication requests … for assignment of appropriate QoS based on policy rules is desirable." A POSITA facing that express performance pressure would predictably reach for the well-known evaluate-the-cheapest-determinative-test-first technique (R4, R7) and the coarse-filter/packet-classification technique (R5) and apply them to the admitted IETF rule structure (R1). The result — fewer condition comparisons per rule and earlier rule rejection — is exactly the predictable result the techniques were known to produce. Under KSR, "a known technique applied to a known structure to yield a predictable result" is obvious.

6. Combination A′ (targeting the DNF claims): R1/R2 + R5/R6 + R7

Proposed combination. For the DNF dependent claims (generate collapsed conditions = intersection/AND of same-group ranges per level; execute if any collapsed condition is met; declare invalid where ranges don't intersect):

• A DNF rule is an OR of ANDs; the satisfying set of each ANDed clause is the intersection of its member ranges (R7: interval intersection).
• R5 teaches computing the satisfying region of a conjunctive clause and indexing/ordering by it; R6 teaches exactly the operation of computing whether rule field-ranges intersect and identifying rules whose ranges conflict / do not intersect — which maps onto the claim's "invalid rule where ranges do not intersect" and the "collapsed condition is not met if any one of its ranges is not met" (AND semantics).
• Motivation: if any one clause region "covers" the event, the whole DNF is true, so evaluating per-clause intersections first and stopping on the first hit is the direct analogue of the CNF optimization and is dictated by DNF semantics plus the same performance pressure. Same predictable result.

7. Dependent-claim-specific combinations

• "Select the summary condition most likely not to be met first" / "collapsed condition most likely to be met first." → R4 (Selinger selectivity ordering) directly teaches ordering predicate tests by probability/cost to minimize expected work. Applying selectivity ordering to the summary/collapsed tests is a textbook optimization; the patent's own text concedes the ordering "may be determined based upon range values or other known characteristics of the operating environment" — i.e., routine heuristics.
• "All-inclusive range" when a condition imposes no limit on a group. → An unconstrained predicate is the universal set; treating an omitted group term as "all-inclusive" is trivial set theory (R7). "All-inclusive when two conditions specify different unitary values" → the union of two distinct points, if forced into a single contiguous interval, is the convex hull spanning both; this is a straightforward interval-arithmetic convention (R7), and is the weakest candidate for a non-obviousness foothold.
• "Rule declared invalid if collapsed ranges don't intersect." → R6 (firewall rule intersection/conflict detection).
• Enumerated condition groups (IP/port/interface/protocol/application). → Fully conventional network-tuple fields (R1, R2, R5); the patent expressly disclaims any limitation to them ("provided solely by way of example").

8. The system and CPP claims (claims ≈ 20 and 40)

Assuming the earlier section's structure (independent system claim unconfirmed; CPP = claim 40), these claims recite the same algorithm carried out by a processor/memory or by program code. Implementing a known algorithm as software on a general-purpose data-processing system is not a patentable distinction — KSR ("programming a general-purpose computer" is not inventive per se) and the long line of "software implementation of a known method" cases. The DNF/CNF test circuits and rule-execution circuit described in the specification are conventional components executing the same logic; no new hardware or unexpected result is claimed.

9. Anticipated rebuttals and secondary considerations

• "The references don't teach per-level union/intersection pre-filters." The strongest non-obviousness argument. It is answered by (i) the fact that the operation is definitional Boolean algebra (R7), and (ii) the express performance motivation in the patent's own Background — a classic KSR "predictable result" combination.
• "The IETF draft post-dates the invention." A subtlety worth flagging: the IETF draft is dated July 14, 2000, only ~6 weeks before the August 24, 2000 filing, so § 102(b) does not reach it and its § 102(a) status depends on the actual invention date. However, because the applicant affirmatively adopted and characterized it in the specification as the prior art framework, it is usable as an applicant admission of what a POSITA knew, independent of its § 102 date. R2/R3 (both well before filing) supply the framework content without this wrinkle.
• Secondary considerations (objective indicia). There is no evidence in the record I reviewed of commercial success, licensing, copying, or industry praise with a nexus to the claimed summary/collapsed-condition technique. Separate from the earlier section's finding, the absence of any identified litigation over ~22 years of ownership (IBM → Trend Micro) and the patent's Expired – Lifetime status (adjusted expiration 2022-06-20) undercut arguments of industry recognition or asserted value. The third-party ~$6.52M "approximate value" figure the earlier section flagged is not authoritative and carries no nexus to non-obviousness. Caveat: the earlier section's litigation finding is a negative based on free portals and is not a PACER-verified certainty, so I do not treat it as dispositive — only as the absence of countervailing objective evidence.

10. Conclusion

On the record available, claims 1 (method), the mirror system claim, and claim 40 (CPP) are prima facie obvious under § 103 over the combination of the IETF policy framework (R1, admitted in the patent) and/or RFC 2753 / Verma (R2/R3), in view of predicate-ordering (R4) and packet-classification/coarse-filtering (R5), and Boolean normal-form/short-circuit evaluation (R7). The DNF dependent claims are prima facie obvious over the same framework art in view of firewall rule-intersection analysis (R6) and interval arithmetic (R7). The "order by likelihood" dependents are squarely met by R4 (selectivity ordering).

The single strongest possible non-obviousness point is the specific recitation of a per-level union "summary condition" (CNF) / per-level intersection "collapsed condition" (DNF) as a pre-computation — but its correctness and its performance benefit follow necessarily from the algebra of the admitted rule structure, and the motivation to reduce real-time condition evaluations is stated in the patent itself. That makes the claims vulnerable to a KSR-style "predictable application of a known technique to a known structure" rejection.

Verification flags. (1) I could not retrieve the examiner's five cited patent references or four NPL items from the page's References/Cited-By data, so I have not matched the claims against the actual citation list; the examiner's art almost certainly overlaps R1–R7 but I cannot confirm which items it contains. (2) The exact text and number of the independent system claim remain unconfirmed per the earlier summary; this analysis assumes it mirrors claim 1's operations. (3) R2–R6 are stated from my own knowledge with confidence levels noted; before filing any § 103 challenge or IPR, they should be pulled as authenticated copies and their dates verified against the August 24, 2000 priority date.