US 7089581

I'll search for authoritative records on US 7,089,581 and any CAFC 2026 activity.

Now let me check for any CAFC 2026 docket activity and the USPTO assignment/legal status records.

Let me do a final targeted check for any district court/PTAB litigation or 2026 appellate activity tied to this patent.

US 7,089,581 — Verification Summary

Caveat on scope of search: I searched for USPTO records, judicial/appellate docket material, and general litigation references for the literal number 7089581 / US 7,089,581. I found no CAFC 2026 docket activity (no appeal, IPR appeal, or Federal Circuit proceeding) involving this patent. I cannot confirm the absence of any such docket with certainty — my searches covered public web sources, not a direct PACER/CAFC docket query, so treat "no 2026 CAFC activity found" as no results located, not as a verified negative.

I also note that the number string "7089581" appears in several unrelated PTAB exhibit prior-art lists (e.g., Palo Alto Networks v. Centripetal Networks, IPR2021-01152 and IPR2021-01521) where US 7,089,581 is cited as background art. Those are not proceedings involving this patent as the challenged/asserted patent.

Bibliographic Data

Uncertainty notes: The assignee is recorded as Hitachi, Ltd. in the patent and USPTO assignment records (assignment recorded 2000-11-22). I did not find a current-assignee transfer to another entity in my searches; some aggregator sites show "Hitachi Ltd" as current assignee. The "adjusted expiration 2023-01-07" reflects a patent term adjustment beyond the nominal 20-year term from the 2000-08-17 filing; I'm reporting it as Google Patents lists it rather than independently recomputing PTA.

Abstract (verbatim)

"A security system design supporting tool and method are disclosed, in which security requirements (PP) and security specifications (ST) used for designing a product or a system (TOE) based on CC requirements can be prepared efficiently and uniformly even by ordinary designers other than specialists. In a security system design supporting method, registered PPs and past PP/ST generation cases are so structured as to reuse and/or reference as templates, a draft is automatically generated, and the draft thus generated is additionally modified or corrected by partial automatic generation utilizing a database of past generation cases and partial case accumulated in the generation process thereof."

Plain-Language Overview of the Independent Claims

All three claims are method claims directed to computer-implemented support for drafting Common Criteria (CC)-based Protection Profiles (PP) and Security Targets (ST). Claims 1, 2, and 3 share a common backbone (the "providing / specifying / generating / rationale-matrix / verifying" sequence) and differ in added limitations.

Common backbone (all three claims):

• Providing a template case database in memory that stores internationally registered PPs, plus generated (non-registered) PPs or STs, organized in a class-tree structure based on inheritance relations between product/system types as the Target of Evaluation (TOE).
• Specifying the relevant PPs/STs by designating the TOE's constituent elements, type, and evaluation assurance level (EAL), and retrieving the relevant class-tree branch.
• Generating a PP/ST draft by integrally editing the definitions of the specified PPs/STs. The claims include a conditional fallback: if the retrieved PPs/STs match registered/local PPs, use them; if no match, retrieve higher-order ("parent") PPs/STs via the inheritance relation and partially add/correct.
• Generating a rationale matrix — a matrix table mapping each correspondence among security environments, security objectives, security requirements, and summary specification (i.e., the CC traceability matrix).
• Verifying whether any definition information lacks a correspondence, using that rationale matrix.

Claim 1 — The base method, ending with the rationale-matrix generation and lack-of-correspondence verification step.

Claim 2 — Adds a specific registration step: if the high-order (parent) PP among the generated PPs does not match, the generated PP draft is registered in a local PP/ST tree structured database. In other words, the unsuccessful-match draft is persisted as a new local case for future reuse. Rationale-matrix generation and verification are retained.

Claim 3 — Adds a graphical/"bill of materials" workflow: the PPs/STs in the template case database are displayed as icons identifying the constituting elements, type, and EAL; the relevant PPs/STs are specified from an inheritance tree of reference PP/ST cases; and a TOE structure diagram is produced using those icons as constituting elements (see the IC-card/EAL4 example in FIG. 5). Rationale-matrix generation and verification are retained.

Architecture Described in the Specification (supporting context)

• Registered side: registered PP/PP-family tree-structured DB and a CC (CEM)/PKG structured DB.
• Local side: local PP/ST tree-structured DB and an expanded CC/PKG structured DB.
• Corresponding knowhow DB: environment↔component mapping, environment↔objective mapping, objective↔CC-requirement mapping, CC-requirement↔implementation-scheme mapping, threat data (occurrence probability × loss), and protection-cost tables.
• Optimization feature (described in the spec but not recited in the granted independent claims): cost-minimization or protection-risk-maximization objective functions solved as a combinatorial optimization under constraints (risk acceptance, cost cap, residual-risk-to-cost ratio), with a worked numerical example yielding an optimal protection cost of 750,000 yen for objectives O-2, O-3, O-4, O-6.
• Deployment embodiments: stand-alone tool (FIG. 2), networked client-server (FIG. 10), horizontally distributed multi-organization DB (FIG. 11), vertically distributed international/domestic/private hierarchy for financial systems including an "information update monitor control unit" (FIG. 12), and portable media (floppy/CD-ROM) case delivery (FIG. 13).

Key Prior Art Cited on the Face of the Patent

• US 5,850,516 — Schneier (analyzing information systems using stored tree database structures)
• US 6,484,261 — Cisco (graphical network security policy management)
• US 6,405,364 — Accenture (development architecture framework)
• Non-patent: ISO/SC27 N2333 Guide for Production of Protection Profiles and Security Targets, v0.8 (July 1999); ISO/IEC 15408 seminar materials (Sept. 8, 1999).

Bottom line: US 7,089,581 is a 2006 Hitachi patent on semi-automated Common Criteria PP/ST authoring using an inheritance-tree template database, with three granted independent method claims centered on tree-based retrieval, draft generation with parent-PP fallback, and rationale-matrix traceability verification. I found no 2026 CAFC docket activity associated with it, and I cannot rule that out with full confidence given the limits of the sources searched.

I'll search litigation databases for US patent 7089581.

Let me run more targeted searches on litigation-specific databases.

Let me verify with a few more targeted searches before concluding.

Result: No litigation identified for U.S. Patent No. 7,089,581

I searched for litigation specifically involving U.S. Patent No. 7,089,581 ("US7089581" / "US7089581B1"), including patent-litigation aggregators (Unified Patents Portal, Docket Alarm, Justia dockets, CourtListener, UniCourt, PACER Monitor), the CAFC opinions/orders site, and general web sources. I found no district court case, no Federal Circuit appeal, and no PTAB proceeding (IPR/PGR/CBM) in which U.S. Patent No. 7,089,581 was asserted, challenged, or otherwise at issue.

Because the request requires each case to have plaintiff, defendant, jurisdiction, case number, filing date, and status, I cannot populate that table — there are zero cases to report.

Why this appears to be a true negative (not just a failed search)

• Patent data pages only. Justia, FreePatentsOnline, Google Patents, Golden Wiki, and Patent Leaderboard each show the patent bibliographically (Hitachi, Ltd.; inventors Nagai, Fujiyama, Arai, Tsunoda, Yamada; filed Aug. 17, 2000; granted Aug. 8, 2006; app. 09/640,016; priority JP33930499, 1999-11-30). None of these pages display a litigation or PTAB tab with cases.
• Unified Patents Portal shows an entry for "US-7089581-B1 – Security System Design Supporting Method – Hitachi Ltd – 1999-11-29," but it appears in a related/citation listing context, not in the portal's district-court or PTAB case lists.
• Docket Alarm hits were citation strings. The occurrences of "7089581" I retrieved were inside long bracketed strings of patent numbers in PTAB exhibits (e.g., an IPR2021-01152 exhibit and a reexamination document) — i.e., prior-art/citation lists, not case captions.

Important caution — do not conflate similar numbers

Many search results referenced different patents whose numbers merely end in "958" or resemble the number. These are not U.S. 7,089,581 and should not be attributed to it:

• U.S. 6,452,958 — Agere Systems v. Sony / LSI v. Funai & Realtek (digital modulation, van Nee) — a different patent.
• U.S. 7,627,708 — USB multi-host device (IPR2017-00861) — a different patent.
• The '958 patents appearing in Texas and other Markman orders (contact-hole/semiconductor) are unrelated.

Patent status relevant to your question

• Assignee: Hitachi, Ltd. (Tokyo, Japan)
• Legal status listed: Expired – Fee Related, adjusted expiration 2023-01-07
• Technology: security system design support using Common Criteria (CC) Protection Profiles (PP) / Security Targets (ST)

Confidence and limitations

I have moderate-to-high confidence that no U.S. litigation has been filed on 7,089,581, given its subject matter (an internal Hitachi CC design-support tooling method), its expiration, and the absence of any case caption in the aggregators checked. However, I could not directly query PACER dockets or run every possible plaintiff/defendant name pair, and my searches were stopped at a tool-usage limit. If you need a litigation-grade clearance, the authoritative step would be a direct PACER docket search for "7,089,581" and a check of the patent's full file history/assignment record, which I was unable to complete here.

Bottom line: No known litigation involving U.S. Patent No. 7,089,581.

PTAB proceedings on file — US 7,089,581 ("Security system design supporting method")

Canonical source: The structured "PTAB proceedings on file" block (USPTO Open Data Portal) in this prompt is the authoritative list. It returns no AIA trial proceedings for US 7,089,581 as of the most recent ODP ingest.

Web-search verification: I ran searches aimed at IPR/PGR/CBM dockets, PTAB petition PDFs, litigation complaints naming the patent, and Federal Circuit activity. Results surfaced no proceeding naming US 7,089,581. Hits that came back were false positives on other patents with similar numbers (e.g., IPR2017-00861 on U.S. 7,627,708; IPR2024-00823 on U.S. 7,502,958; Samsung's IPR on U.S. 8,791,581). No proceeding number for US 7,089,581 was found, so none is reported here. I did not invent one.

Proceedings overview

Total AIA trial proceedings on file: 0. Breakdown by status: 0 active, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denials. The bottom-line defensive posture is therefore not "the patent survived IPRs and is hardened" and not "claims have been canceled by the Board." The correct posture is: the Board has never construed a single claim of this patent, and no AIA estoppel exists for or against anyone. That cuts both ways — a defendant gains no free "claim 1 is dead" argument, but also faces no Madstad/Fintiv fight and no petitioner estoppel blocking its own validity case.

A material practical overlay, from the patent record rather than from any proceeding: Google Patents shows the legal status as "Expired – Fee Related, expires 2023-01-07" (adjusted expiration 2023-01-07; filing 2000-08-17; priority 1999-11-30; granted 2006-08-08). Confirm the maintenance-fee history in USPTO Patent Center before relying on this — but if the patent lapsed for non-payment of a maintenance fee, the enforceable term ended well before the nominal 2023-01-07 date. Sources: Google Patents — US7089581B1, USPTO Patent Center, uspto.report record.

Per-proceeding detail

None to report. Rather than fabricate four proceeding write-ups, here is what the empty docket does and does not tell you, expressed in the format the analysis calls for:

(no proceeding) — No petitioner v. Hitachi, Ltd.

• Type: n/a — no IPR, no PGR, no CBM has ever been instituted or even filed on this patent per the ODP record and my searches.
• Filed: n/a
• Status: n/a
• Judge panel: n/a — no APJ panel has ever touched this patent.
• Petition grounds: n/a
• Institution decision: n/a
• Final Written Decision: n/a — no claim of this patent has ever been canceled, confirmed, or even construed by the PTAB. Claims 1, 2, and 3 (the entire claim set) are UNTESTED at the Board.
• Settlement / termination: n/a
• Appeal: none found at the Federal Circuit. CourtListener and the CAFC docket surfaced nothing tying 7,089,581 to an appeal.
• Defensive value: Zero IPR-based leverage available, and zero IPR-based risk. More importantly, the CBM door is closed — CBM review sunset under AIA § 18 on 2020-09-16, so no new CBM petition can be filed even if this G06Q-classified patent arguably claims a "covered business method" for financial/administrative data processing (see classification G06Q 99/00 in the record). Any invalidity attack today belongs in district court, in a reexam, or in the ITC — not in an AIA trial.

Strategic summary

Claims CANCELED vs. SUSTAINED vs. UNTESTED. All three claims — 1, 2, and 3 — are UNTESTED. There is no IPR Certificate cancelling anything, so there is no "claims 1–5 are dead, the demand letter is empty" defense to hand a client. Conversely, Hitachi never had to defend a single claim, so there is also no body of Board claim construction (no Phillips-based narrowing, no patent-owner disclaimers in an IPR record, no adverse FWD findings to cherry-pick for a § 112 or § 103 attack).

Estoppel landscape. § 315(e)(2) estoppel is a non-issue in both directions: no party has ever been a petitioner, so no party and no privy is estopped from raising § 102/§ 103 art in the district court. Equally, a defendant cannot cite an FWD as issue-preclusive. The practical consequence: the full universe of prior art is available, subject only to the ordinary district-court rules (KSR, secondary considerations) and any prosecution-history disclaimer. Note the record's own cited art (e.g., U.S. 5,588,056 Ganesan; U.S. 5,850,516 Schneier; U.S. 6,405,364 Bowman-Amuah; U.S. 6,484,261) — art of this vintage alongside 1999-era common-criteria PP/ST literature (ISO/SC27 N2333, ISO/IEC 15408 seminar materials) is the natural starting point for a § 103 challenge.

Pattern signals. No pattern exists to read: same petitioner filed no multiple IPRs (there are none), the patent owner (Hitachi, Ltd.) has not pursued PTAB appeals on this patent, and there is no defensive aggregator (Unified Patents or similar) in the chain — nothing in the searched record shows Unified or any other aggregator petitioning on 7,089,581.

Why the silence matters. The absence of PTAB activity is itself a signal that this patent was never a high-value assertion target. Patents that get asserted against deep-pocketed defendants reliably attract IPRs; a 27-year-old (priority 1999) design-tool patent with three mostly process-oriented method claims and a lapsed fee status has not. That inference is circumstantial, not proof — I state it as a practitioner reading, not a record fact.

Recommended next steps

1. Verify the term before anything else. Pull the maintenance-fee history in USPTO Patent Center for 7,089,581. If it lapsed for fee non-payment, determine the lapse date and whether the § 41(c) surcharge/acceptance window has closed. A demand letter asserting an expired patent is a very different problem-solving exercise (and may itself be actionable).
2. Because no IPR is available or needed, shift the defense to Article III/reexam channels. Options: (a) district-court § 101 (§ 101 is not an AIA-trial ground anyway) and § 103 motions; (b) ex parte reexamination under 35 U.S.C. § 302 / Reexam Control No. 90/xxx,xxx — note the record already reflects an ex parte reexamination touching a different patent in the same family ("incomplete ex parte reexamination of the '958 patent" appears in related litigation), so check the 7,089,581 reexam history file wrapper directly.
3. Attack the claims on their face. The claim set (1–3) is drafted as a "security system design supporting method" — a design/authoring workflow with database-structuring and matrix-verification steps. These are prime Alice step-two candidates (computer-implemented design support, arguably conventional), and claim 3's icon/tree-diagram limitations are the only concrete structural hook. That is my analysis of the claim text, not a Board or court holding — no tribunal has ever ruled on these claims.
4. If you nonetheless want an AIA-trial posture mapped: confirm in PTAB E2E and via the ODP "PTAB proceedings on file" feed at the time of your filing that no petition has since been lodged (the ODP ingest lags; my searches are current to 2026-09-20 and found nothing). If any petition appears naming this patent, the § 315(b) one-year clock from your own service of a complaint controls — but with CBM closed and the patent apparently lapsed, the realistic answer remains: no PTAB activity exists, and none is likely.

Confidence statement: High confidence that no AIA trial proceeding names US 7,089,581, based on the canonical ODP block plus searches current to 2026-09-20. Medium confidence on the expired/lapsed-fee status, which is taken from Google Patents' legal-status field and should be confirmed in Patent Center. I could not locate any Federal Circuit appeal, settlement, or panel — because, on this record, none exists.

I'll research the assignment record for US 7,089,581.

Let me dig into the assignment-specific record sources.

Let me try the assignment-record aggregators directly.

Assignment & Ownership Reconstruction — US 7,089,581

Data-quality caveat up front: I was unable to retrieve a single reel/frame number, recorded execution date, or named recording correspondent from the USPTO Assignment Center or its mirrors (PlainSite, uspto.report, Espacenet/INPADOC) within this session. Every assignment citation below is therefore attributed to the source that carries it rather than to a reel/frame I could not personally confirm. No reel/frame identifiers are fabricated in this report. The only assignment event text I could substantiate is the one Google Patents carries on its legal-events tab, which quotes the USPTO assignment abstract verbatim.

Verification entry points:

• https://assignmentcenter.uspto.gov/ (search by patent number 7089581)
• https://assignment.uspto.gov/patent/index.html
• https://patents.google.com/patent/US7089581/en#legalEvents

Inventors

Five named inventors, all with Japanese residence cities listed on the face of the patent:

Employer determination: All five are recorded as assignors to Hitachi, Ltd. in the USPTO assignment abstract — "ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ARAI, MASATO, FUJIYAMA, TATSUYA, NAGAI, YASUHIKO, TSUNODA, MITSUHIRO, YAMADA, TOMOAKI" (as carried on the Google Patents legal-events record, recorded 2000-11-22). A single joint employment assignment of this form is the standard corporate practice for a wholly in-house team and is the strongest available evidence that all five were Hitachi employees at filing. Corroboration: Patent Leaderboard lists Fujiyama as an inventor on 6 US patents "while listed as an inventor at Hitachi," which is consistent but not independent proof for the other four.

Unusual-pattern check — no signal. There is no evidence of any inventor departing Hitachi within 12 months of the 2000-08-17 filing. I did not locate departure data, reissue, or co-inventor re-assignment activity. I am explicitly not calling this a clean bill of health — it is an absence of located evidence, not a verified negative. The inventors' subsequent patent output (Fujiyama's later grants through November 2006, per Patent Leaderboard) is at least consistent with continued Hitachi employment, but I did not verify the assignee on those later grants.

Original assignee

Hitachi, Ltd. (Tokyo, Japan) — original and, per Google Patents' "Current Assignee" field, still the assignee of record.

• Entity type / primary line of business: Global diversified industrial and information-technology conglomerate — information and telecommunication systems, power and industrial systems, rail, automotive systems, digital media, construction machinery, and materials. This is not an IP-holding vehicle; it is a very large operating company.
• Did they ship a product embodying the claims? Unclear / no evidence located. The claimed subject matter is a method for semi-automatically authoring Common Criteria Protection Profiles and Security Targets. Hitachi was, in the relevant era, an active CC evaluation participant (the patent's own FIG. 5 worked example is an IC-card system at EAL4, with an IC card PP and an IC card reader/writer PP). That makes it highly plausible the method was used internally as a design aid for Hitachi smart-card and terminal products, but I found no commercial product, datasheet, or marketing material evidencing that Hitachi sold a "security system design supporting tool." I would not assert internal-use-only as a finding on this record.
• Current status: Operating. Hitachi, Ltd. remains an active global corporation; it did not enter bankruptcy, and no Hitachi Chapter 7/11 proceeding is implicated in this patent's chain. Note that Hitachi has undergone substantial portfolio restructuring (e.g. divestiture of the storage business to Western Digital in 2012), so the absence of any recorded transfer of this patent is itself mildly informative — it suggests this asset was not swept into any of those carve-outs.

Assignment timeline

Only one assignment is recorded for this patent. On the USPTO Assignment Center and Google Patents legal events, the chain consists of the original inventor-to-corporate assignment and nothing else — no post-issuance transfers, no security interests, no name changes, no mergers, no releases.

• 1999-11-30 (JP priority date, JP 33930499) — not an assignment; flagged for chronology.
• Executed 1999/2000 (exact execution date not captured) / recorded 2000-11-22 — Reel/frame: not retrieved; not fabricated.
  • Conveyance: Assignment of assignors' interest
  • Assignor: Nagai, Yasuhiko; Fujiyama, Tatsuya; Arai, Masato; Tsunoda, Mitsuhiro; Yamada, Tomoaki (all five, jointly)
  • Assignee: Hitachi, Ltd.
  • Correspondent: Not captured from the assignment record. The attorney of record on the face of the granted patent is Mattingly, Stanger, Malur & Brundidge, P.C. (a Virginia firm). I flag this only as the prosecution attorney of record per Justia; I did not verify that this firm was the recording correspondent on the assignment, and the two roles are not necessarily the same. No recurrence finding can be made — there is only one link in the chain, and I have no correspondent name attached to it.
  • Context: Ordinary employment/ownership assignment from the inventor team to the corporate employer. Not a fire-sale, not a reorg, not a transfer-to-asserter.
• 2006-08-08 — Application granted; patent issued. Not an assignment event.
• 2023-01-07 — Google Patents lists an adjusted expiration of 2023-01-07, with legal status "Expired – Fee Related."

Flagged inconsistency (do not resolve by assumption): The two dates above are in tension. A 20-year term from the 2000-08-17 filing would end 2020-08-17; reaching 2023-01-07 would require roughly 873 days of patent term adjustment, which is plausible for a 2000 filing that took six years to issue. But if the patent is truly "Expired – Fee Related," the lapse date normally equals a maintenance-fee window (the 11.5-year fee would have been due on or about 2018-02-08, with a grace period to on or about 2018-08-08). I could not reconcile these two data points from available sources. I am reporting both as Google Patents lists them rather than recomputing PTA or asserting a lapse date. This matters for the NPE analysis only insofar as an expired/lapsed patent has no assertion value — see the verdict.

Timeline diagram

timeline
    title Ownership of US 7089581
    1999 : JP priority application filed
    2000 : US application filed Aug 17
         : Inventors assign to Hitachi Ltd
    2006 : Patent issued Aug 8
    2023 : Adjusted expiration Jan 7
         : Status expired fee related

NPE / troll-pattern signals

Identifier-confusion warning (literal number discipline)

Two near-miss numbers circulate in Hitachi-related litigation material and should not be merged into this chain:

• US 7,089,342 — "Method Enabling Display Unit To Bi-Directionally Communicate With Video Source," also issued 2006-08-08 (the same issue date, coincidentally). This patent appears in a complaint involving Hitachi entities and in a standing dispute over whether Hitachi, Ltd. as corporate parent is an equitable title holder relative to subsidiaries (HCE, HAD). One search result surfaced this docket material alongside the string "7,089,581." These are different patents. Do not attribute the Hitachi enforcement campaign to US 7,089,581.
• US 6,484,261 / US-B1-6484261 — recited as cited prior art on the face of this patent and independently appearing in the Palo Alto Networks v. Centripetal Networks PTAB exhibits (IPR2021-01152, IPR2021-01521). US 7,089,581 likewise appears in Centripetal exhibit prior-art lists. That is third-party use of this patent as background art by unrelated parties — it is not Hitachi assertion activity and not a Hitachi-to-NPE transfer. (This is consistent with the earlier-generated section of this analysis, which reached the same conclusion.)

No contradiction was found between this section and the previously generated summary; the earlier "no 2026 CAFC docket activity located" finding is consistent with an unreassigned, non-asserted, fee-expired patent.

Verdict

Insufficient data — the chain consists of only the original assignment.

Justification: The USPTO record for US 7,089,581 shows exactly one conveyance: the five-inventor team's assignment of their interests to Hitachi, Ltd., recorded 2000-11-22, with no reel/frame, execution date, or recording correspondent that I was able to verify directly from the Assignment Center in this session. There are no post-issuance assignments of any kind — no shell-entity transfer, no asserter in the chain, no cascading LLC hops, no bankruptcy sale, no defensive-aggregator termination. The current assignee field still reads Hitachi, Ltd. That is exactly the situation the rubric classifies as "only the original assignment," and it means the original operating-company assignee still owns the patent. On top of that, the patent is listed as Expired – Fee Related with an adjusted expiration of 2023-01-07, which — if the lapse is genuine — removes any practical assertion value and further undercuts an NPE reading. This is a non-asserted, non-transferred corporate asset, not a troll pattern; and per the stated constraints, I decline to upgrade a suggestive corporate pedigree into an NPE finding absent a reel/frame.

Residual uncertainty: Because I could not open the Assignment Center record directly, I cannot rule out an unindexed or recently recorded transfer. Anyone relying on this should run the patent number at https://assignmentcenter.uspto.gov/ and confirm the reel/frame, execution date, and correspondent name before treating the single-assignment characterization as final.

I'll research the prior-art citations for US 7,089,581. Let me verify the front-page references and gather citation data.

I have the front-page citation set. Let me verify the two remaining references (US 5,588,056 and EP 1 065 861) and check for any additional cited art.

Prior-Art Analysis — US 7,089,581 (confirming earlier bibliographic work)

Building on the previously generated verification summary (Hitachi, Ltd.; app. US 09/640,016; filed 2000‑08‑17; priority JP 33930499, 1999‑11‑30; granted 2006‑08‑08; 3 independent method claims). I will not repeat that bibliographic block. Two things I must flag up front:

⚠️ Discrepancy with the earlier section. The prior summary listed only three US patent references on the face of the patent (US 5,850,516; US 6,484,261; US 6,405,364). A direct read of the granted front page shows five patent citations — the three above plus US 5,588,056 and EP 1 065 861 A1. The earlier list was incomplete. I use the full five below.

Framework note. Because the application was filed 2000‑08‑17 (pre‑AIA), the applicable statute is pre‑AIA 35 U.S.C. §102. The critical date is the 1999‑11‑30 priority date (JP 33930499) for §102(a)/(b), and the 2000‑08‑17 filing date for §102(e) (with benefit to 1999‑11‑30). Timing therefore matters a great deal for three of these references.

Front-Page Patent Citations (5) — per reference

1. US 5,850,516 — Schneier, "Method and apparatus for analyzing information systems using stored tree database structures"

• Full citation: U.S. Patent No. 5,850,516 B1; inventor Bruce Schneier; assignee individual (later Bt Americas Inc./British Telecom family per Unified Patents); App. No. 08/772,413. Filed 1996‑12‑23; granted 1998‑12‑15.
• §102 status: Available as §102(b) printed publication/patent (granted >1 yr before 1999‑11‑30 priority).
• Brief description: Computer-implemented attack trees. The system is modeled as a logical tree with leaf nodes = attacks, intermediate nodes = logical combinations of attacks, root node = overall system security, with node values that can be Boolean or continuous (cost, time, probability), and can represent both attacks and defenses. Discloses quantifying security, comparing systems, evaluating modifications, subsystem analysis, and "allocating a security budget," and plugging subsystem trees into an overall system tree.
• Claim-mapping: This is the most structurally relevant reference to the "class-tree structure"/tree-retrieval core (element A/B of the claims) and to the quantitative risk/cost concepts in the specification. However, it contains no Protection Profile/Security Target, no EAL, no environment→objective mapping, no "integrally edit a PP/ST draft," and no rationale matrix.
• §102 anticipation assessment: Does not anticipate claims 1, 2, or 3 — it lacks the PP/ST template database, the EAL designation, and the rationale-matrix/verification limitations. Best characterized as a §103 primary reference (tree-structured security modeling) rather than an anticipatory reference.

2. US 6,484,261 — Wiegel (Cisco Technology, Inc.), "Graphical network security policy management"

• Full citation: U.S. Patent No. 6,484,261 B1; inventor Scott L. Wiegel; assignee Cisco Technology, Inc.; App. No. 09/210,143, filed 1998‑12‑11, claiming benefit of provisional 60/074,945 filed 1998‑02‑17; granted 2002‑11‑19.
• §102 status: Because it was filed in the U.S. before 1999‑11‑30 and granted, it is available as §102(e) prior art as of its 1998‑12‑11 filing date (and 1998‑02‑17 provisional date), notwithstanding its post-priority grant date.
• Brief description: Establishing an abstract network security policy as a decision tree of graphical symbols; a user manipulates icons/property sheets to build a logical policy; the policy can be applied to network devices by moving an icon over a device icon; "Policies, network objects, and network services are stored in the form of trees." Includes dynamic validation of edit commands against syntactic rules.
• Claim-mapping: Directly relevant to claim 3's graphical limitations — PP/ST icons identifying constituting elements, specification from an inheritance tree, and producing a TOE structure diagram using icons as constituting elements (cf. Wiegel's icon-over-device-application and tree storage). Also touches the icon/element selection of claim 1/2's specifying step.
• §102 anticipation assessment: Does not anticipate claim 1 or 2 (no PP/ST, EAL, or rationale matrix). It is the closest art to claim 3's icon/tree/diagram elements but still lacks CC/PP/ST semantics, so claim 3 is not cleanly anticipated; it is a strong §103 combination reference against claim 3.

3. US 6,405,364 — Bowman‑Amuah (Accenture LLP), "Building techniques in a development architecture framework"

• Full citation: U.S. Patent No. 6,405,364 B1; inventor Michel K. Bowman‑Amuah; assignee Accenture LLP; App. No. 09/387,651 filed 1999‑08‑31 (PCT/US00/23893); granted 2002‑06‑11.
• §102 status: §102(e) prior art as of its 1999‑08‑31 U.S. filing date (before the 1999‑11‑30 priority date).
• Brief description: A software development architecture framework covering requirements specification and implementation strategy, build/test/QA, reuse‑support tools, object modeling, component modeling, repositories, and security requirement definition and auditing of projects. Broadly about structuring and reusing software-development artifacts.
• Claim-mapping: Touches only generic elements — "specify requirements," "reuse," repository-driven development. It discloses nothing regarding CC, PP/ST, EAL, inheritance class-trees of PPs, rationale matrices, or lack-of-correspondence verification.
• §102 anticipation assessment: Does not anticipate any of claims 1, 2, or 3. At most a §103 secondary reference for the general "reuse existing artifacts when specifying new-system requirements" motivation.

4. US 5,588,056 — Ganesan (Bell Atlantic Network Services), "Method and system for generating pronounceable security passwords"

• Full citation: U.S. Patent No. 5,588,056; inventor Ravi Ganesan; assignee Bell Atlantic Network Services, Inc.; App. No. 08/328,476. Filed 1994‑10‑25; granted 1996‑12‑24.
• §102 status: §102(b) art (well before priority).
• Brief description: Generates pronounceable passwords from first/second word-segment portions selected with substantially equal probability, using transition numbers (Markov-model derived) to build an 8+ character pronounceable password usable to encrypt/decrypt or as part of a private key.
• Claim-mapping: No overlap with any claim limitation (no tree database, no PP/ST, no rationale matrix, no optimization).
• §102 anticipation assessment: Anticipates none of claims 1, 2, or 3. It appears to have been cited only as general security-technology background (both it and the companion US 5,850,448 relate to the "APG/FIPS PUB 181" password theme in the NPL list). Treat as non-invalidating background art.

5. EP 1 065 861 A1 — Alcatel, "Method to provide authorization, a certifying authority, a terminal, a service provider and a certificate realizing such a method"

• Full citation: European Patent Application EP 1 065 861 A1 (Alcatel). Filed 1999‑06‑28; published 2001‑01‑03.
• §102 status: Questionable as §102 art — flag this. §102(e) is limited to U.S. applications/patents (and PCT applications designating the U.S.); a foreign (EPO) published application is not §102(e) art. Its publication date (2001‑01‑03) is after the 1999‑11‑30 priority date, and its foreign filing date does not create §102(a)/(b) art. Unless a U.S. counterpart filed before 1999‑11‑30 exists and is relied upon, this reference is not available for §102 against these claims.
• Brief description (subject matter): Authorization/certification scheme involving a certifying authority, terminal, service provider and certificate.
• §102 anticipation assessment: Anticipates none of claims 1, 2, or 3, and is likely not prior art at all on the dates given. Its citation on the front page is likely incidental (security authorization/certificate context).

Front-Page Non-Patent Citations (13) — most relevant

The granted front page lists 13 NPL items. Grouped by §102 relevance:

Pre‑priority (potential §102(b) art):

• ISO/SC27 N2333, "Guide for Production of Protection Profiles and Security Targets," Version 0.8 (July 1999) — the single most relevant NPL reference. Defines the PP/ST chapter structure and content the claims operate on. Relevant to the "contents of a definition of the specified PPs/STs" and the environment/objective/requirement chapter mapping — but it is a draft guide describing format/content, not an automated inheritance-tree tool with rationale-matrix verification, so it does not anticipate claims 1–3; it is important §103 context.
• "Information Technology security evaluation standards," pp. 26–33, ISO/IEC 15408 Seminar Materials (Sept. 8, 1999) — §102(b); CC background (EALs, functional/assurance requirements).
• "Common Criteria for Information Technology Security Evaluation User Guide," Oct. 1999, pp. 1–41 — §102(b) (published before 1999‑11‑30).
• "Common Criteria: An Introduction," pp. 1–19 — CC primer; date not fully specified in the record.
• "Common Evaluation Methodology for Information Technology Security, Part 1, Introduction and General Model," Jan. 11, 1997, pp. 1–24 — §102(b); CEM evaluation methodology (relates to the "PP/ST simple evaluation" concept in the specification, though that feature is not recited in the granted claims).
• Richard Baskerville, "Information System Security Design Methods: Implementation for Information Systems Development," ACM Computing Surveys, vol. 25, No. 4, pp. 375–414, Dec. 1993 — §102(b); security-design methodology survey.
• Automated Password Generator (APG), FIPS PUB 181, Oct. 5, 1993 — §102(b); password-generation standard (pairs with US 5,588,056). Not relevant to the claims.

Post‑priority (NOT §102 art):

• Common Criteria Part 1/2/3 and Common Methodology, Aug. 2005 versions, and NIAP "Protection Profiles" / "The Common Criteria: Evaluation and Validation Scheme Validated Protection Profiles," Jan. 4, 2006. These postdate both the 1999‑11‑30 priority and the 2000‑08‑17 filing (and postdate even the 2006‑08‑08 grant for the NIAP items). They cannot be §102 prior art and appear to be later-submitted/current-version documents. I flag this because treating the "Aug. 2005" CC documents as prior art against a 1999 priority would be an error.

Bottom line — ranking of most relevant prior art

No single front-page reference discloses every limitation of claims 1, 2, or 3. Each claim requires the combination of (A) a template case database of registered and non-registered PPs/STs in an inheritance class-tree, (B) specification by designating elements, type, and EAL, (C) draft generation by integral editing (with parent-PP fallback; plus local registration in claim 2, plus icons/tree/TOE diagram in claim 3), and (D)/(E) rationale-matrix generation and lack-of-correspondence verification. Schneier and Wiegel supply the tree/graphical pieces; the ISO/CC NPL supplies the PP/ST semantics; none supplies the automated inheritance-tree retrieval and rationale-matrix verification together. Accordingly, the realistic invalidity theory is a §103 combination, with Schneier or Wiegel as primary and CC/N2333 as the PP/ST-defining teaching.

Confidence/limitations: Citation lists were read from Google Patents' and Justia's renderings of the granted front page and matched across sources; the two-source agreement on the five patent citations is strong. I did not independently verify the EP reference's U.S. family or the exact publication dates of every NPL item, and the ISO/CC NPL dates are reported as listed. If you need a binding §102 date-status determination for EP 1 065 861 A1 (i.e., whether a pre‑1999‑11‑30 U.S. counterpart exists), that requires a family/priority lookup I have not completed.

I'll verify the filing dates of two of the cited references, since their § 102 qualification turns on dates rather than issue dates.

Obviousness Analysis — US 7,089,581 B1 under 35 U.S.C. § 103

Building on the prior summary (bibliographic data, claim backbone, and reference list). This section does not re-summarize the claims; it maps them against the cited art and articulates motivations to combine.

A. Legal frame

Pre-AIA § 103(a) governs. Application 09/640,016 was filed 2000-08-17, before the AIA first-to-file effective date (2013-03-16). The inquiry is therefore whether the differences between the claimed subject matter and the prior art would have been obvious at the time the invention was made to a person of ordinary skill in the art (PHOSITA), judged on the Graham v. John Deere factors. The Federal Circuit's KSR Int'l v. Teleflex (2007) guidance applies: motivation may be found in the references themselves, in the ordinary knowledge of the artisan, or in the nature of the problem; predictable combinations of known elements are obvious, and the artisan is presumed to have ordinary creativity, not merely to be a "automaton."

Critical date: earliest priority is 1999-11-30 (JP 33930499). Everything below turns on that date.

B. Prior-art qualification — a refinement of the earlier section

The earlier section listed these references with issue dates only. Issue dates are the wrong operative dates for pre-AIA § 102(e) art, and two of the three US references issued after the priority date but were filed before it. I verified the filing dates; the result materially improves the prior-art position:

This is a refinement, not a contradiction, of the earlier section — that section simply did not assert dates of prior-art effect.

Caveat: the § 102(e) dates assume the JP priority date is also the earliest invention date. If the inventors' actual conception/diligence date predates 1999-08-31, the Accenture reference would drop out and the Cisco date (1998-12-11) would still hold. The Accenture margin is narrow (three months), so this is the one reference whose status is worth confirming against the JP file.

Note also that US 6,484,261's Google Patents family entries surface both "1998-02-17" (via an EP family listing) and "Dec. 11, 1998" (the front page (22) Filed of the patent itself). Either way both precede 1999-11-30; the 1998-02-17 date may reflect an earlier related application.

C. PHOSITA

Two defensible formulations, either of which supports the analysis:

1. A security/systems engineer with a bachelor's degree in computer science or electrical engineering and 2–4 years' experience in information-security engineering, including familiarity with ISO/IEC 15408 (CC) PP/ST structure, relational/object-oriented database design, and GUI-based engineering tools; or
2. A software architect/developer with the same education and 2–4 years in requirements-engineering and development-architecture frameworks, working in a team that includes a CC specialist.

The inventor list (five inventors spanning security, architecture, and UI) itself suggests the invention practiced by a team; the claims are drafted to a system-building methodology, not a cryptographic algorithm, so a broader skill range is appropriate.

D. Element-by-element mapping

Claim 1

Claim 2 (adds: register the unmatched draft in a local PP/ST tree DB)

Claim 3 (adds: icons + inheritance-tree display + TOE structure diagram)

E. The obviousness combinations and why the artisan would combine

Combination 1 (primary): ISO/CC materials + Schneier + Accenture.

• Common field / analogous art: all three address computer-assisted security or software-system analysis and design. Schneier's stated problem — "the knowledge that these people have is very specialized" — is verbatim the problem the patent identifies ("the person in charge of preparation is required to be equipped with the special knowledge of CC…").
• Motivation from the CC side: the applicant's own Background concedes that the PP "should inherently be reused and shared by product/system designs of the same type," and that certification "becomes an essential condition." A regulatory/market pull toward a reusable, standardized repository is itself a documented motivation.
• Motivation from the tool side: Schneier supplies the tree-and-reuse architecture ("Applying attack trees to two related systems …", pluggable sub-system trees); Accenture supplies the inheritance/override reuse mechanism and framework methodology. Combining a known hierarchical reuse structure with a known design-methodology framework to build a PP/ST authoring tool is the application of known techniques to a known problem, yielding predictable results.

Combination 2: Combination 1 + Cisco. Cisco contributes the GUI/icon layer directly corresponding to Claim 3, and the automated validation corresponding to Claim 1's "verifying" step.

Combination 3 (expansion): all four references fanned against all claims. Schneier's cost/probability node values (US 5,850,516 cls. 43, 46–47: "cost associated with said security attribute," "probability of occurrence") are notably aligned with the specification's threat-risk/protection-cost engine, although that engine is not recited in the granted claims and is therefore not needed for the § 103 case.

Overarching motivations (any one of which suffices under KSR):

1. Same problem, same field. All references target reducing the expertise barrier to security-system specification.
2. Regulatory pressure. CC certification as a purchase/network-connection precondition (patent Background) creates a demand for efficient PP/ST authoring.
3. Predictable combination. Each element (tree DB; OO inheritance; icon GUI; validation) was independently known; their aggregation produces no unexpected behavior.
4. Design choice. Representing the repository as a class tree, expressing the rationale as a matrix, and rendering the tree as icons are each conventional choices among known alternatives.

F. Anticipated counterarguments

G. Conclusion and confidence

The one genuinely contestable link is Claim 1's requirement that the template repository be a class-tree based on inheritance between TOE types. The references collectively supply class inheritance (Accenture), tree-structured security databases (Schneier), and the same-type-reuse mandate for PPs (CC) — which is sufficient to render the limitation obvious, but it is the limitation on which a patent owner would most plausibly resist.

Confidence: My mapping rests on the reference descriptions surfaced above plus the patent's own text. I did not read the cited references column-by-column; before relying on this, the specific passages (especially Cisco's icon/property-sheet passages and Accenture's inheritance/reuse passages) should be verified against the originals, and the Accenture § 102(e) date should be confirmed against the JP priority document. I also flag that I could not verify the two non-patent ISO documents' exact content beyond the titles/dates given in the patent's "References Cited" — their substantive teaching of PP/ST structure is my inference from the CC framework itself, and should be spot-checked.

This is a technical prior-art analysis, not legal advice; claim construction, validity determinations, and infringement are outside its scope.