US 6366912

I'll search for authoritative information on this patent number, including any 2026 CAFC docket activity.

Let me run additional targeted searches to confirm whether any 2026 litigation or CAFC docket activity exists for this specific patent.

One more check on litigation/PTAB history, then I'll summarize.

US Patent 6366912 — "Network Security Zones"

Source note / verification

I checked the patent-number-specific sources. The authoritative record I retrieved is the Google Patents full text you supplied (https://patents.google.com/patent/[US6366912](/patent/US6366912)/en), corroborated by uspto.report (https://uspto.report/patent/grant/6366912) and a Baidu Scholar entry (application no. US19980055772). One third-party aggregator (Unified Patents portal) lists the priority date as 1998-04-05; the USPTO-derived records list 1998-04-06. I am flagging this discrepancy rather than silently resolving it; the Google Patents/USPTO bibliographic data (1998-04-06) is the value I treat as controlling.

Important caveat on the CAFC request: My searches of public web/docket-indexed material did not surface any Court of Appeals for the Federal Circuit docket for 2026 (or any year) naming 6,366,912. I could not query the CAFC docket database or PACER directly with the tools available, so I cannot affirmatively certify a negative. What I can say with confidence: (a) the patent's legal status is "Expired – Lifetime," with anticipated expiration 2018-04-06 per the Google Patents record, so the asserted patent itself lapsed ~8 years before the date you asked about; and (b) no 2026 appellate activity tied to this number appeared in available indexed results. Treat any claim of a live 2026 CAFC appeal over this specific number as unverified.

Bibliographic summary

Abstract (as issued)

"A computer based system and method of providing security when receiving digital data at a client computer from one or more Web sites is disclosed. The method includes receiving security configuration information that specifies multiple security zones, each zone corresponding to a set of Web sites. The security configuration information also includes information specifying a set of security settings corresponding to each security zone. A security setting is a specification indicating an action to perform when a Web page from one of the security zones requests a protected operation to be performed. During a Web browsing session, the mechanism of the invention determines the security zone corresponding to the Web site currently being browsed. Prior to performing the protected operation, the mechanism of the invention determines the action to perform, based on the current Web site's security zone, the requested operation, and the security setting corresponding to the requested operation and the Web site's zone. Depending upon the security setting, the Web browser may perform the requested operation, prevent the requested operation from being performed, or prompt the user of whether to perform the requested operation. During the browsing of a Web site, the Web browser visually indicates the security zone corresponding to the current Web site."

Plain-language overview of the independent claims

The patent has six independent claims: 1, 7, 14, 15, 18, and 19. Claims 14 and 18 are computer-readable-medium claims that simply recite performance of the methods of claims 1 and 15 respectively (they carry independent form but no additional method matter). Claims 2–6 depend from claim 1; 8–13 depend from claim 7; 16–17 depend from claim 15.

Claim 1 — Core method (the base claim, and the one most of the family depends on).
A computer-based method for client-side security during a browsing session. The client receives a Web document for execution on the client that contains code in the actual content of the document requesting an operation pertaining to that document. In response, the client analyzes the code to determine whether the requested operation is a "protected operation" prior to executing the Web document; if a protected operation is to be performed, it determines a corresponding security setting; and it executes the Web document if performing the protected operation is allowed by that security setting. In plain terms: inspect the incoming page's own code first, look up the applicable setting, then execute only if permitted.

Claim 7 — Zone-based variant.
Takes the claim 1 method and adds the "zones" architecture: configure the browser with a specification of a plurality of zones, each zone containing at least one Web site and having a corresponding set of security settings; determine the zone corresponding to the Web site; and choose the security setting based on both the protected operation and the zone. (Dependent claims 10 and 11 add the firewall-relative zone split and the on-screen zone indicator.)

Claim 14 — Computer-readable medium.
A computer-readable medium with instructions for performing the method of claim 1. No added scope.

Claim 15 — User-configuration method.
A method centered on setup: the client receives from a user a specification of a security zone indicating at least one server computer in the zone; receives from the user a specification of a security level for that zone; and stores both specifications prior to receiving the Web document from the server in that zone. In plain terms: let the user define the zone and its security level up front, and persist that configuration in advance of the browsing event. (Dependent claims 16/17 distinguish whether the user is the local user or a remote administrator.)

Claim 18 — Computer-readable medium.
A computer-readable medium with instructions for performing the method of claim 15. No added scope.

Claim 19 — Multi-zone configuration method.
The broadest configuration claim: the client receives from a user specifications of a plurality of security zones, each indicating at least one Web site; receives, for each zone, a specification of a corresponding security level; subsequently receives a Web document from a Web site included in one of the zones; and stores the zone specifications and associated security levels at the client prior to receiving that Web document.

Key technical disclosure supporting the claims

• Four default zones: "local intranet," "trusted sites," "restricted sites," and "Internet," with default security levels of medium, low, high, and medium respectively. The Internet zone is the catch-all for unassigned sites.
• Zone determination by parsing URL: the Internet security manager parses the address (e.g., HTTP/FTP/FILE protocol plus top-level domain) to derive a zone ID. Notably, protocol + domain combinations can be split across zones (e.g., HTTP+www.microsoft.com in "trusted," FTP+www.microsoft.com in "Internet").
• Wildcard precedence: explicit specifications override general ones (e.g., "investor.msn.com" beats "*.msn.com").
• Per-operation settings with three-state semantics: enable (perform silently), prompt (ask the user; see FIG. 5 "security warning" dialog with an "always trust software" checkbox for signed software), and disable (block). The specification enumerates ~18 protected operations including ActiveX controls (signed/unsigned/safe-for-scripting), Java permissions, active scripting, file/font download, log-on behavior, non-encrypted form submission, IFRAME application launching, desktop item installation, and drag-and-drop/copy-paste.
• User/administrator configuration via "Internet Options," "Security settings," and "Web sites" dialog windows, persisted in the Windows system registry (or, alternatively, in internal data structures or files).
• Browser architecture (FIG. 2): MSHTML (rendering/scripting), SHDOCVW (UI), and JAVAVM (applets) components each consult an Internet security manager, which in turn reads configuration from the system registry.
• Optional logging of requested protected operations and the resulting action (claim 6 / step 920).

Assessment / uncertainty

• Highest confidence: bibliographic data, abstract, claim text, and legal status — all confirmed by the patent full text and corroborating records.
• Moderate confidence: the 1998-04-05 vs. 1998-04-06 priority-date discrepancy. The USPTO-derived record (1998-04-06) is preferred; the aggregator's 04-05 entry is unexplained.
• Not established: any 2026 CAFC docket activity. This patent expired in 2018 and I found no indexed 2026 appeal naming 6,366,912. If you need a definitive answer, the authoritative check is the CAFC docket (and the originating district court / PTAB docket), which I could not query directly here. If you have a specific CAFC appeal number in mind, give it to me and I will search it literally.

I'll research litigation involving US Patent 6366912.

Let me search additional litigation-specific sources.

Result: No litigation found involving US Patent 6,366,912

I searched for litigation specifically tied to US Patent 6,366,912 ("Network security zones," [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.), filed 1998‑04‑06, granted 2002‑04‑02, expired 2018‑04‑06). I could not identify any district court action, CAFC appeal, ITC investigation, or PTAB proceeding in which US 6,366,912 was asserted, challenged, or even named as a patent‑in‑suit.

Case table

What the searches actually returned (and why it is not litigation)

Grounds for concluding "no known litigation"

1. Ownership chain shows no NPE acquisition. Per the front page, the only assignments of record are (a) inventor→Microsoft Corp. (1998‑07‑13) and (b) Microsoft Corp.→Microsoft Technology Licensing, LLC (2014‑12‑09). The '912 patent was never severed into a monetization vehicle, which is the typical prerequisite for assertion campaigns involving a 1998‑priority browser-security patent.
2. Terminal disclaimer by expiration. Legal status is "Expired – Lifetime," with anticipated expiration 2018‑04‑06. Absent pre‑expiration assertion (which would almost certainly surface in docket aggregators), there is now no live cause of action.
3. Microsoft historically did not assert this family. The '912 patent is a browser‑configuration/internet‑security‑manager patent; it appears in the ecosystem overwhelmingly as prior art (cited by VirnetX‑family and Chang/Flexiworld‑family filings) rather than as an asserted patent.
4. Fail-safe note: I could not complete direct queries against RPX Insight (insight.rpxcorp.com), Docket Alarm litigation search, or the Unified Patents caselist for this specific number within the search budget available. I therefore cannot represent that these databases were exhaustively checked.

Caveats a diligence reviewer should carry forward

• Absence of evidence ≠ evidence of absence. The definitive negative check is a run against Lex Machina, Docket Navigator, RPX Insight, or Westlaw Litigation Analytics filtered on 6,366,912, plus a PACER/CAFC docket-name sweep. My conclusion rests on public web sources only.
• Do not conflate this patent with the many unrelated numbers that surfaced: Netlist '366 patent (U.S. 12,373,366), Netlist '912 patent (U.S. 7,619,912 — note this is a different '912 patent, in the Netlist v. Google/Micron/Samsung litigations), and VirnetX '135/'180 patents. Per the strict-interpretation rule, 7,619,912 is not 6,366,912.
• The '912 patent's claim 1 is directed to client-side analysis of code in the actual content of a Web document to determine whether a requested operation is protected — relevant context if a future reader assumes broad "security zone" assertions were made; no such assertion appears in the public record.

Bottom line: Based on the sources searched, there is no known litigation involving US Patent 6,366,912. It appears in the public record only as a prior-art citation and as an expired Microsoft/web-browser-security patent.

I'll verify the structured data with targeted searches before concluding.

Let me run a few more targeted checks on PTAB dockets and litigation history.

A couple more checks on litigation/enforcement history and any defensive-aggregator activity.

Proceedings overview

Zero (0) AIA trial proceedings are on file for US 6,366,912. The structured USPTO Open Data Portal block returns no IPR, PGR, or CBM petitions; the breakdown is therefore 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denials. Bottom line for a defendant: no claim of this patent has ever been tested at the PTAB, but that is not a "hardened patent" signal — it is an expired-patent signal. US 6,366,912 reached its anticipated expiration on 2018-04-06 and carries legal status "Expired - Lifetime." There is no live infringement exposure to defend against and no IPR to file.

No proceedings to detail — and that absence is independently verifiable

I checked the canonical source (the structured PTAB block: 0 AIA trials) and then ran targeted corroborating searches against Google Patents, the USPTO PTACTS/PATENTS End-to-End system, Docket Alarm's PTAB docket index, and general web indexes for the patent number paired with "IPR," "PGR," "CBM," "petition," and "inter partes review." No petition, institution decision, Final Written Decision, or appeal involving US 6,366,912 surfaced. I will not manufacture a proceeding number to fill this section.

Two search hits mention the string "6366912," but neither is a PTAB proceeding against it:

1. A CBM2015-00039 exhibit (PNC v. U.S. Pat. 7,631,191) contains a USPTO search-strategy transcript listing ("6366912").URPN. — that is a prior-art search query hitting the patent number, i.e., '912 was used as a search seed/reference, not challenged.
2. A PTACTS petition exhibit in a case involving U.S. Pat. 9,525,696 contains a Westlaw-style query string US-6363452-$.DID. OR US-6366912-$.DID. — again a database query artifact, not a proceeding identifier.

If you are pulling this patent from a docket-monitoring feed that flags "cited in PTAB filings," those two hits are the source of the false positive. Neither is a challenge to '912.

What the record does show (grounding for the strategic read)

This is a first-generation Microsoft Internet Explorer security-zones patent that describes the four-zone model (Local intranet / Trusted sites / Restricted sites / Internet) with per-zone Enable-Prompt-Disable settings for protected operations, plus the zone indicator in the browser chrome. It is squarely a defensive portfolio artifact from Redmond, not an NPE assertion vehicle. Note the irony in the citation trail: Microsoft's own later US 9,003,048 B2 ("Network zones," Shelest & Ward) and published application US 2004/0199648 A1 ("Network zones") both cite '912 as prior art — the '912 taught the follow-on, it did not get asserted.

Strategic summary

Claim status: all 19 claims are UNTESTED — none canceled, none sustained, none narrowed. Because there is no PTAB record, there is no claim-level invalidation history to hand a judge and no FWD holding to quote. Claims 1–19 stand or fall entirely on their original prosecution record, the statutory presumption of validity, and whatever district-court invalidity proofs a defendant can assemble from scratch. The practical significance of "untested" here is heavily discounted by one fact: the patent expired on 2018-04-06. With the six-year damages lookback under 35 U.S.C. § 286, any pre-expiration infringement swept within a lookback from today is nil. A demand letter citing US 6,366,912 in 2026 has no damages theory behind it, and no injunctive theory either — you cannot enjoin infringement of an expired claim.

Estoppel landscape: none exists, and that cuts in the defendant's favor. Section 315(e)(2) estoppel attaches only to a petitioner (and its privies/real parties in interest) whose IPR was instituted and resulted in a final written decision. No IPR was ever instituted against '912, so no party is estopped from raising any § 102 or § 103 ground in district court. The full universe of prior art — patents, printed publications, and (unlike in IPR) system art, public use, on-sale, and § 112 grounds — remains available to any defendant, subject only to the ordinary district-court rules. Conversely, because there is no institutional record and no FWD, a defendant also gets no benefit of a prior petitioner's work product, no IPR record estoppel to leverage, and no "the Board already killed these claims" argument. You would be litigating validity from a clean slate.

Pattern signals: absent. No repeat petitioner, because there is no petitioner at all. No patent-owner PTAB appeal practice, because there is no FWD to appeal — and I found no Federal Circuit decision involving '912 in the search results. No defensive aggregator in the chain: nothing ties Unified Patents, RPX, or any similar entity to this patent. And structurally, the modern challenge channels are closed or closing: PGR is unavailable (the patent's effective filing date of 1998-04-06 long predates the 2013-03-16 AIA cutoff), and CBM review is unavailable because the transitional CBM program sunset under AIA § 18 for petitions filed after 2020-09-16. That leaves IPR and ex parte reexamination as the only theoretical vehicles — and neither is worth filing over an expired patent with no damages.

Recommended next steps

• If you received a demand letter citing US 6,366,912: the strongest response is not a PTAB petition — it is a termination letter. Anchor it on the face of the patent record: anticipated expiration 2018-04-06; legal status "Expired - Lifetime" (https://patents.google.com/patent/US6366912/en). Under 35 U.S.C. § 286 there is no reachable damages period, and an expired patent carries no injunctive exposure. Ask the sender to identify any accused act occurring on or before 2018-04-06 and to state the license/release theory.
• If the sender claims a PTAB victory or a "validated" patent: that claim is false. There is no PTAB proceeding on this patent, no instituted IPR, no FWD, and no Federal Circuit appeal. Ask them to produce the proceeding number — they cannot.
• If, contrary to everything above, you still want a validity challenge on the merits (e.g., because a related later Microsoft "network zones" patent such as US 9,003,048 is what is actually being asserted): direct the challenge at that patent, not '912. For '912 specifically, the only theoretical vehicles are IPR under 35 U.S.C. §§ 311–319 or ex parte reexamination under §§ 301–307, since PGR and CBM are unavailable; and note that current USPTO practice disfavors instituting AIA review on long-expired, aged patents as a discretionary matter.
• Verify independently before relying on this: the authoritative checks are the USPTO Patent Center for the '912 application (https://patentcenter.uspto.gov, application 09/055,772), the PTAB End-to-End system at https://ptacts.uspto.gov, and CourtListener for any CAFC or district activity (https://www.courtlistener.com). I found no PTAB or appellate activity in any of them; if a newly-filed petition has not yet been ingested by the ODP, a direct PTACTS search on application 09/055,772 is the tiebreaker.

Confidence note: I am highly confident there are no issued decisions or instituted proceedings involving this patent, because both the ODP structured data and multiple independent public indexes return nothing. I cannot rule out a petition filed so recently that no public index has picked it up, but for a patent that expired in 2018, that risk is negligible.

I'll research the assignment record for US 6366912 across the USPTO Assignment Center, Google Patents legal events, and NPE/defensive-aggregator directories.

Let me dig for the specific reel/frame entries and correspondent of record.

I found the Microsoft→MTL reel/frame. Now let me pin down the original 1998 assignment and check for any litigation.

Assignment Reconstruction — US 6,366,912 B1 ("Network security zones")

Patent identifiers as recorded: US 6,366,912 B1 · Application 09/055,772 · Filed 1998‑04‑06 · Issued 2002‑04‑02 · Priority 1998‑04‑06 · Current assignee of record: Microsoft Technology Licensing, LLC · Status: Expired – Lifetime (anticipated expiration 2018‑04‑06).

Sources used: Google Patents legal events (https://patents.google.com/patent/US6366912/en), the sibling Microsoft→MTL transfer record surfaced via Espacenet INPADOC (reel/frame 034543/0001), and the mass Microsoft reassignments in the USPTO assignment index. I could not reach an interactive USPTO Assignment Center result page for this patent number within this session, so a small number of fields (noted below) are flagged as not surfaced rather than asserted.

Inventors

The five are named together as assignors in the 1998‑07‑13 record conveying rights to Microsoft Corporation, and the specification expressly describes Microsoft Internet Explorer as the embodied browser (US6366912, col. describing "Internet Explorer, available from Microsoft Corporation, of Redmond, Washington"). Three of the group are well‑known security practitioners (Kohnfelder, Geer, Dujari), consistent with the browser‑security subject matter.

Unusual patterns: None. I found no evidence of inventors departing the original assignee within 12 months of filing, no pre‑filing fire‑sale, and no inventor‑held reversion. This is an ordinary employee‑invention assignment to the operating employer.

Original assignee

Microsoft Corporation (Redmond, Washington) — named on the issued patent and listed as the original assignee in the USPTO record.

• Product embodying the claims: Yes. The patent claims a browser‑enforced "security zones" model (protected‑operation classification → security setting → enable/disable/prompt). This shipped as the Internet Options → Security tab in Microsoft Internet Explorer, with the four zones (Internet, Local intranet, Trusted sites, Restricted sites), default levels, and the per‑operation custom settings list recited in the spec. The claimed subject matter is therefore commercially practiced, not paper.
• Primary line of business: Operating software company (OS, productivity, browser).
• Current status: Operating. The relevant patent‑holding affiliate, Microsoft Technology Licensing, LLC, is a wholly owned Microsoft subsidiary (Delaware LLC, One Microsoft Way, Redmond, WA), created to hold and license Microsoft's patent portfolio.

Assignment timeline

Two recorded conveyances appear in the chain. The patent sat with the original assignee for ~16 years before the internal corporate transfer.

• 1998‑07‑13 (recorded) — Reel/frame not surfaced in the sources reachable this session

  • Conveyance: Assignment (Assignment of Assignors' Interest)
  • Assignor: Michael J. Wallent, Rajeev Dujari, Anand Ramakrishna, Loren M. Kohnfelder, Lewis Geer
  • Assignee: Microsoft Corporation, Redmond, Washington
  • Correspondent: Not surfaced. (Microsoft's filings of this vintage were handled by its own Law & Corporate Affairs department; I could not retrieve the recorded correspondent field, so I am not guessing a name.)
  • Context: Initial prosecution‑stage assignment — inventors convey their employee invention to the operating employer; recorded ~3 months after the 1998‑04‑06 filing.

• 2014‑10‑14 (executed/effective) / recorded 2014‑12‑09 — Reel 034543/0001

  • Conveyance: Assignment (portfolio‑wide corporate transfer)
  • Assignor: Microsoft Corporation
  • Assignee: Microsoft Technology Licensing, LLC, One Microsoft Way, Redmond, WA
  • Correspondent: Not surfaced for this specific reel; this was a Microsoft‑submitted bulk recordation (the same reel/effective date appears across large numbers of Microsoft patents, e.g. the sibling INPADOC record for US 2007/0182999 showing "ASSIGNOR: MICROSOFT CORPORATION; REEL/FRAME: 034543/0001" with effective date 2014‑10‑14). I flag the recurrence of reel 034543 across the Microsoft family, but I cannot independently confirm that this patent sits at frame 0001 of that reel — treat the frame as indicative, the reel and dates as the solid finding.
  • Context: Internal corporate reorg / transfer‑to‑IP‑holding‑subsidiary — a single‑date mass conveyance of the parent's portfolio to its wholly owned licensing affiliate; not a sale to a third party.

No further assignments recorded. Current assignee of record remains Microsoft Technology Licensing, LLC; the patent expired 2018‑04‑06.

Timeline diagram

timeline
    title Ownership of US 6366912
    1998 : Filed by Microsoft inventors
         : Assigned to Microsoft Corporation
    2002 : Patent issued
    2014 : Assigned to Microsoft Technology Licensing LLC
    2018 : Patent expired

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The only post‑issuance move is Microsoft Corporation → Microsoft Technology Licensing, LLC (reel 034543/0001, recorded 2014‑12‑09). Although MTL carries a "Licensing" suffix and is a Delaware LLC, it is a wholly owned Microsoft subsidiary at the parent's own address (One Microsoft Way, Redmond), not a registered‑agent service address, and the parent still ships a product (Internet Explorer) embodying the claims. The "Licensing" name alone is not a finding under the stated rubric.

2. Known asserter in the chain — not present. Neither assignee (Microsoft Corporation; Microsoft Technology Licensing, LLC) appears on the RPX / Unified Patents high‑frequency plainant lists in the prompt (Acacia, Marathon, IV, IPNav, Wi‑LAN, Conversant/Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities). Unified Patents' own patent page for US‑6366912 lists the assignee simply as "Microsoft Technology Licensing LLC" with no assertion history.

3. Repeat correspondent across the chain — unclear / not surfaced. I could not retrieve the recorded correspondent fields for either the 1998 or the 2014 record at the sources reachable here, so no recurrence can be established or excluded. On the evidence available, the one recurring filer pattern is Microsoft submitting its own portfolio assignments (not an outside agent running unrelated LLCs), which is the opposite of the tell this signal is designed to catch.

4. Cascading transfers — not present. Two recorded assignments across 16 years (1998 and 2014). No chained LLCs, no <24‑month sequence, no shared‑correspondent hop‑scotch.

5. Pre-litigation transfer — not present. No infringement suit naming this patent was surfaced, and the 2014 transfer predates expiry by ~3.5 years with no adjacent filing.

6. Bankruptcy fire‑sale — not present. No Chapter 7/11 event involving Microsoft or MTL; the 2014 record is a live corporate reorganization, not a distressed sale.

7. Privateering — not present. No transfer of this patent to a third‑party NPE asserting on Microsoft's behalf. The patent simply moved between Microsoft and its own affiliate.

8. Defensive aggregator (anti‑NPE) — not present. The chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN; it terminates at a vertically integrated operating company's subsidiary. (Inverse observation: the patent is nonetheless effectively neutralized now — it expired 2018‑04‑06 and cannot support new assertions.)

Verdict

Operating-company assertion.

The chain is a clean two‑link operating‑company record: inventors → Microsoft Corporation (recorded 1998‑07‑13) → Microsoft Technology Licensing, LLC (reel 034543/0001, effective 2014‑10‑14, recorded 2014‑12‑09). No signal on the NPE checklist is present on the documented evidence, and the claimed "security zones" functionality shipped in Microsoft Internet Explorer. One caveat: the "assertion" prong of this category is not independently evidenced — I found no infringement suit naming US 6,366,912, and MTL is a licensing affiliate rather than a product‑shipping operating entity, so if your rubric requires a documented assertion event the honest restatement is "operating‑company ownership, no NPE pattern, no assertion found." Either way this is not an NPE chain, and the patent is now expired.

Verify at the USPTO Assignment Center — search patent number 6366912: https://assignmentcenter.uspto.gov/ (mirror: https://assignment.uspto.gov/patent/index.html). Cross‑check legal events at https://patents.google.com/patent/US6366912/en.

Confidence notes (per operating rules): The dates, assignee names, reel 034543 and effective/recorded dates for the 2014 Microsoft→MTL transfer are grounded in the records cited above. The 1998 reel/frame, the 1998 correspondent, and the 2014 correspondent could not be retrieved in this session and are marked as not surfaced rather than reconstructed. The specific frame number (0001) on reel 034543 is drawn from a sibling Microsoft patent in the same bulk transfer and should be confirmed against the Assignment Center abstract for this patent before being relied on.

I'll start by verifying the patent and locating its prior-art citation record.

The authoritative text I was given includes the forward-citation list ("Cited By (183)") but omits the patent's own "References Cited" section. Let me locate that.

Let me try to retrieve the backward-citation ("References Cited") list from other databases.

1. Identity check — the document is confirmed

Working from the authoritative full text supplied to me (Google Patents, fetched 2026‑09‑29), the record for US 6,366,912 B1 is:

Two minor data conflicts I will flag rather than silently reconcile: an unrelated aggregator page (portal.unifiedpatents.com) lists a priority date of 1998‑04‑05 for "US‑6366912‑B1", and some mirrors render the priority as 1998‑04‑05/06. The authoritative text says 1998‑04‑06, and I use that. It is also worth noting the patent text contains an obvious typographical artifact, "perfonning" (FIG. 9 caption) — a rendering of "performing," not a separate term.

2. Critical caveat about "patent citations" — please read before the tables

The phrase "each patent citation for 6366912" is ambiguous, and the authoritative text I was given determines what I can actually answer:

• What IS in the record I was given: the forward citation table, "Cited By (183)" — i.e., 183 later documents that cite US 6,366,912 (plus the priority-application table, which contains only its own application US 09/055,772, so there is no continuation family).
• What is NOT in the record I was given: the patent's own front-page (56) "References Cited" / "Patent Citations" list — the backward citations to pre‑1998 art that the examiner and applicant cited. The Google Patents render supplied to me begins the document at the "Definitions" block and jumps from the "Cited By (183)" table straight to "Landscapes"/Abstract; the (56) section is absent.
• I will not fabricate a (56) list from memory. A fabricated citation list is worse than an acknowledged gap, and the examiner citations would need to be read literally off the face of the granted patent or its USPTO file wrapper.

There is a second, more important point:

Forward citations cannot anticipate US 6,366,912 under 35 U.S.C. § 102. A document that cites the '912 patent necessarily came later. Every entry in the "Cited By (183)" list that I can date was filed/published in 1999–2011 or later, i.e., after the '912 filing date of 1998‑04‑06. Under pre‑AIA § 102(a)/(b) they are not "prior art" to it at all, and under § 102(e) a US patent/application only qualifies with an earlier effective filing date than 1998‑04‑06.

So: I cannot name a § 102 anticipating reference for US 6,366,912 from the material supplied. What I can do — and do below — is (a) identify the one forward‑listed item with a pre‑1998 priority date that could theoretically double as § 102(e) art, (b) identify the documents that most closely track '912's claims (useful for scope/claim‑construction and infringement‑context analysis, not for anticipation), and (c) state exactly what a proper § 102 search must look for.

3. The one forward‑listed item whose date precedes the '912 filing

Every other forward citation is post‑1998 and is therefore § 103/§ 102‑irrelevant as to '912.

4. Most thematically relevant forward citations (ECHO '912's claims — they do not anticipate it)

These are the documents from the authoritative "Cited By" list that re‑implement or extend the '912 concepts. I give the '912 claim(s) they parallel in subject matter, with the express caveat that they are later documents and are not § 102 art against the '912 patent.

(Note: the supplied "Cited By" table is itself truncated mid‑entry in my fetch — it breaks off at "US 8,001,459 B2 … Enabling electronic documents for limited‑cap…". I therefore cannot enumerate all 183; I have not invented the missing ones.)

5. Where US 6,366,912 itself functions as prior art (the reverse direction)

This is often what analysts actually need:

• US 9,003,048 B2 (Shelest & Ward, Microsoft), filed 2003‑04‑01, granted 2015‑04‑07, lists in its (56) References Cited: 6,366,912 B1 * 4/2002 Wallent et al. ...... 707/9 — i.e., the '912 is cited with an examiner asterisk, against the later "Network Zones" patent. Source: https://patentimages.storage.googleapis.com/16/3a/68/d0a6fd7f7bb937/US9003048.pdf
• EP 2 579 496 B1 cites "US 6366912 B1 [0002]" in its "References cited in the description."
• USPTO/PTAB EAST search histories (e.g., the CBM2015‑00039 petitioner exhibit) show the '912 being searched as an "URPN"/"PN" reference during prosecution of later applications — confirming its role as a blocking/background reference for later zone‑based security patents, not as a target of them.

6. What a proper § 102 analysis of US 6,366,912 requires

Because the (56) list is missing from my source, here is the element checklist any anticipatory reference must meet, so the correct references can be pulled from the file wrapper and read against them:

Independent claim 1 requires all of:

1. client‑side method during a browsing session between client and server;
2. receiving a Web document for execution on the client;
3. the document containing code in the actual content of the document that requests the client to perform an operation pertaining to the document;
4. analyzing that code to determine whether the requested operation is a protected operation prior to executing the Web document;
5. if protected, determining a security setting corresponding to the protected operation;
6. executing the Web document if performing the protected operation is allowed based on that setting.

Independent‑ish claims 15 and 19 add: receiving from a user a specification of a security zone (≥1 server/Web site) and a security level, and storing both prior to receiving the document from that site.

Practical consequence: the search date line is 1998‑04‑06, and candidate art must be pre‑1998‑04‑06 (or a US filing with an earlier § 102(e) date). Thematically the search must cover content rating/filtering (e.g., PICS‑style schemes), browser plug‑in/ActiveX/Java sandboxing disclosures, signed‑object/JAR trust models, and proxy/firewall trust partitioning of 1994–1998 vintage. I am not naming specific pre‑1998 patents here, because I could not verify the '912 (56) list and will not substitute recollection for a citation.

7. Explicit statements of what I could not verify

1. I could not retrieve the face‑of‑patent (56) References Cited list for US 6,366,912 from the authoritative text provided or from the searches available to me. No § 102 anticipation conclusion can be responsibly drawn without it.
2. I could not enumerate all 183 "Cited By" entries; my source truncated the table.
3. The specific claims of '912 that a given later document "potentially anticipates" is, strictly speaking, a category error — those documents post‑date '912 and therefore cannot anticipate it under § 102. The claim numbers in § 4 are subject‑matter parallels only, offered to show claim scope, not legal anticipation.
4. I did not auto‑correct any identifier; US 6,366,912, application 09/055,772, and the cited US 9,003,048 B2 are reproduced exactly as they appear in the sources.

If you can supply the front page / (56) block or the USPTO PatentCenter "References Cited" tab for US 09/055,772, I will run the reference‑by‑reference § 102 mapping (claim 1, 7, 10, 11, 15, 19 in particular) against that verified list.

I'll start by pulling the page's prior-art-related content and cross-checking the citation data, since the supplied page text shows a "Prior art keywords/date" block and a "Cited By" list but no examiner-cited "Patent Citations" block.

The page text supplied shows a "Cited By (183)" (forward-citation) table but no examiner-cited "Patent Citations" block. Let me try to recover the actual § 102/§ 103 reference list from the patent's front page and bibliographic databases.

Let me try to recover the actual examiner-cited reference list (front-page (56) references) for US 6,366,912.

Obviousness Analysis — U.S. Patent 6,366,912 B1 ("Network Security Zones")

Patent: US 6,366,912 B1 (Appl. No. 09/055,772, filed 1998‑04‑06, granted 2002‑04‑02; inventors Wallent, Dujari, Ramakrishna, Kohnfelder, Geer; original assignee [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.); current assignee Microsoft Technology Licensing LLC; status: Expired – Lifetime, anticipated expiration 2018‑04‑06).
Governing law: Because the application was filed 1998‑04‑06, pre‑AIA 35 U.S.C. §§ 102/103 apply. No AIA §§ 102(a)(2)/102(d) "secret prior art" mechanics; pre‑AIA § 102(e) governs unpublished pre‑1999 U.S. applications.

1. Record-Integrity Findings (read this first)

1.1 What the supplied page actually contains as "prior art." The page contains (a) a machine‑generated keyword set — security, web, client computer, zone, computer — under "Prior art keywords," and (b) "Prior art date: 1998‑04‑06." It then contains "Cited By (183)", which is a forward‑citation table (later documents citing the '912 patent). The supplied text contains no examiner‑cited "(56) References Cited" block and no non‑patent‑citations block. I attempted to retrieve that list from the patent front page and bibliographic mirrors; the searches did not return it, so I will not invent reference numbers or quoted passages.

1.2 Date screening of the "Cited By" table. These are almost all post‑dating documents and therefore, standing alone, cannot be § 102/§ 103 prior art to a 1998‑04‑06 critical date. Screening: one item only has a pre‑critical‑date priority date.

Practical consequence: the "Cited By" table on this page is not an obviousness arsenal. It is evidence of follow‑on adoption of the claimed zone architecture (and, for Microsoft's own later filings, evidence of internal continuation) — potentially usable for framing secondary considerations and industry uptake, not for § 103 rejection.

1.3 Record discrepancy to note literally (no auto‑correction). Google Patents states the priority/filing date as 1998‑04‑06; a search result from a third‑party aggregator displayed "Priority Date: 1998‑04‑05" for US‑6366912‑B1. The one‑day variance is immaterial to any § 103 date, but it is recorded here as‑found rather than harmonized.

1.4 Google's "Definitions" list is an auto‑generated summary and is not the patent's legal text; the authoritative material is the Description and the 19 claims. Where the generated text is garbled (e.g., "local Internet zone" where the specification means "local intranet zone"), I follow the Description.

2. Framework Applied

1. Graham v. John Deere factors: scope/content of prior art; differences; PHOSITA level; secondary considerations.
2. KSR Int'l v. Teleflex (2007) rationales: known problem with an obvious solution; predictable variation; combination of known elements; design incentives/market forces.
3. MPEP 2129 — statements in the applicant's own specification (the "Background") are admissions of prior art and may be used as the primary reference.
4. Claim 1 is not limited to zones; it recites a client‑side pipeline: receive a Web document containing code → analyze that code to determine whether the requested operation is a protected operation, prior to executing the Web document → determine a security setting for the protected operation → execute the document if the setting allows. Zone‑based structure appears only in claims 7–11 and 15–19.

3. Grounded Obviousness Grounds Using This Page's Data

Ground 1 — Admitted prior art + ordinary skill ⇒ claims 1–6, 12–14

Basis (high confidence — quoted from the supplied Description):

• Browsers already "display a dialog window specifying the source of the ActiveX control and allowing the user to decide whether or not to install the specified control… prior to downloading a file, executing a program, or executing a script."
• "always trust software" checked content that is digitally signed is not a protected operation (FIG. 5 description).
• Files transferred by FTP may "include commands that perform malicious operations."

Mapping: pre‑operation, source‑aware, user‑approval gating of downloads/controls/scripts (claim 1 preamble, claims 4, 5, 12, 13); "enable/disable" outcomes (claims 1–2); logging (claim 6) is routine audit logging.

Motivation — supplied by the applicant itself: the Background states that per‑operation prompting "can result in a user repeatedly being presented with dialog windows… Faced with frequent interruptions, a user may respond hastily and improperly," and expressly desires "a mechanism that allows a user to specify desired security information in order to avoid repetitive and unnecessary queries." Replacing a per‑event query with a pre‑stored setting (prompt / enable / disable) is precisely a predictable variation of a known interaction, with a motivation stated in the reference itself. This is the single strongest § 103 attack on the broad claims.

Weak spot for the patent: claim 1's only arguably distinctive phrase is "analyzing the code [in the actual content of the Web document] … prior to executing the Web document." But every markup/script interpreter of that era (HTML parser + script engine + Java VM/ActiveX loader) scanned tags and control‑instantiation directives before executing them, so this is best characterized as a recitation of the browser's inherent load sequence rather than an inventive step — unless the prosecution history shows it was added to distinguish network‑/proxy‑layer filtering. A petitioner should obtain the file wrapper to confirm.

Ground 2 — US 6,708,203 B1 (the only date‑qualified cited reference) ⇒ insufficient alone; supplemental at best

US 6,708,203 is directed to filtering messages/events against a user profile via a client‑side filter/intercept module. If the relied‑upon disclosure is supported by its 1997‑10‑20 priority, it is pre‑AIA § 102(e) art.

• What it can arguably supply: client‑resident interception of incoming content plus user‑configurable policy data consulted before acting.
• What it does not supply (as titled/characterized here): the multi‑zone site taxonomy, the (site × operation) → setting mapping, the zone indicator, or the pre‑execution code analysis of a Web document.
• Motivation to combine with Ground 1: both are client‑side, profile‑driven content‑handling filters in the same field — a KSR‑sufficient reason (same problem: applying stored user preferences to incoming network content rather than querying the user each time). Confidence: low‑moderate, and I flag that I could not read its claims/specification through the available results, so treat it as a supplemental, not primary, reference.

Ground 3 — Zone claims 7–11, 15–19: what the combination must contain

I could not verify any specific (56) reference from this page, so I will not assign reference numbers. What a primary reference would have to teach, and why the combination would have been obvious, is nonetheless clear from the '912 record:

Net assessment: claims 1–6, 12–14 are the most vulnerable (a stated‑motivation improvement over admitted prompt‑based browser security). Claims 7–11 and 15–19 are only vulnerable if the searcher finds a pre‑1998 reference teaching categorization of network resources with per‑category client policy (URL/site‑category access‑control and firewalled‑network‑class art is the correct field; server‑ or proxy‑side filtering references are also useful because they can be combined with an admitted client‑side browser to yield the claimed client‑side enforcement).

4. Things I Could Not Verify (stated explicitly, per the no‑fabrication rule)

1. The '912 patent's actual (56) reference list. Not present in the supplied page; not recovered by search. Any analysis naming specific examiner‑cited patents would be speculation. Action: pull the front page PDF / file wrapper (USPTO Patent Public Search, PatentCenter) — the (56) block and any § 102(e)/§ 103 rejections are the ground truth.
2. US 6,708,203's specification, claims, and true § 102(e) date for the relied‑upon disclosure (its 2004 grant implies a possible continuation chain).
3. A third‑party litigation search history in my results listed patent numbers in the internet‑access‑control field (e.g., 5,678,041; 5,684,951; 5,696,898; 5,796,942; 5,828,893; 5,835,726; 5,919,247; 5,930,792; 5,940,843; 5,958,005; 5,958,051; 5,963,142; 5,987,611; 5,991,878; 6,154,751). I did not verify that any of these is cited in, or otherwise applied against, the '912 patent, nor did I verify each reference's filing date or content. I list them only as a research lead, not as a § 103 ground.
4. Pre‑AIA § 103(c) nuance worth checking: for applications filed before 1999‑11‑29 (the '912 patent qualifies), the common‑ownership disqualification of § 103(c) historically reached only § 102(f)/(g) art, not § 102(e) art. If correct, Microsoft‑owned § 102(e) art from other Microsoft inventors remains available against this patent. Verify against the statute version in force.

5. Bottom Line

• Claims 1–6, 12–14: obvious under § 103 over the applicant's own admitted prior art (browser pre‑operation dialogs identifying the source; FTP/ActiveX/script risk; signed‑software trust) in view of a stored per‑operation setting table. The specification's own problem statement supplies the motivation, satisfying KSR's "known problem → obvious solution" rationale.
• Claims 7–11, 15–19: not provable from this page's data. The zone‑and‑level configuration, admin distribution, and zone indicator require a pre‑1998 primary reference teaching resource categorization with per‑category client policy, combined with the Ground‑1 browser art. Obtain the (56) list and the file history before asserting a ground.
• Do not cite any member of the page's "Cited By (183)" table as prior art, with the sole exception of US 6,708,203 B1 — and that only after confirming its § 102(e) date and content. The remaining 182 entries post‑date the 1998‑04‑06 critical date and instead evidence the industry's adoption of the disclosed zone model (available for secondary‑consideration framing, subject to a demonstrated nexus).
• The patent is expired, so this analysis is retrospective — relevant to § 282 invalidity defenses for pre‑2018 conduct, portfolio valuation, and as prior art/background against later Microsoft and third‑party zone and browser‑security patents.