US 7188317

I'll verify the patent's current status and check for any litigation activity before summarizing.

US Patent 7,188,317 B1 — Verification Report

Search note on the strict-ID rule: I searched for the literal string "7188317." Two near-miss items surfaced that are not this patent and should not be conflated with it:

• JP-7188317-B2 ("Hybrid vehicle control device," PubChem/Japan, priority 2019-08-30, granted 2022-12-13) — a Japanese patent that happens to share the digits 7188317. Different jurisdiction, different art, different owner.
• IPR2026-00295 / IPR2026-00297, [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.) v. ToutVirtual, Inc. (PTAB, filed March 6, 2026), tied to ToutVirtual, Inc. v. Microsoft Corp., No. 2:25-cv-00943 (E.D. Tex.). Those proceedings concern U.S. Patent No. 11,656,915 (Pabari) and U.S. Patent No. 12,079,667, with prior art including Hashimoto, Lubbers, Hirschfeld (U.S. 6,880,002) and Khandekar (U.S. 7,577,722). US 7,188,317 is not the patent at issue. A coincidental overlap is that Microsoft also used Khandekar/Hirschfeld-style references elsewhere.

CAFC 2026 dockets: no case found. I found no Federal Circuit appeal, district court action, or PTAB proceeding involving US 7,188,317. This is consistent with its status — the patent is recorded as Expired – Fee Related, adjusted expiration 2023-04-02 — so it is no longer enforceable and would not plausibly be the subject of a 2026 appeal. I state this as a negative search finding, not as proof of absence.

Bibliographic Summary

Assignee chain per the prosecution/reassignment record: HAZEL, THOMAS G. → MICROSOFT CORPORATION (2001-06-13) → MICROSOFT TECHNOLOGY LICENSING, LLC (2014-12-09).

Abstract (verbatim)

"A first primary display window displays first primary objects linked to a scope window. A second primary display window displays second primary objects linked to the scope window. The second primary objects are independent of the first primary objects. One or more secondary display windows display secondary objects linked to one of the primary display windows. A secondary display window may be linked to the scope window so that the secondary objects displayed in the secondary display window are linked to the scope window. Data to create a window may be query-driven and the window type may be data-driven. Window type may be changed after creation and windows may be docked to each other to prevent overlap. Windows may link back to the scope window."

Plain-Language Overview of the Independent Claims

The invention is a "split-tree navigation" user-interface model that replaces the classic one-selection-drives-one-window scheme (the patent cites Microsoft Exchange as the prior model) with a model where one scope selection drives many sibling windows independently, and where child windows can link back to the scope window.

Claim 1 — Computer storage medium / method (the core claim).
A hierarchy (scope tree) of scope items is displayed. The user picks a particular scope item. Critically, the user and/or administrator supplies a first set of instructions that defines what objects appear in a first primary window, and an independent second set of instructions defining what appears in a second primary window. Both primary windows are formed in response to the same selected scope item, but the first and second instructions are mutually independent, so the two windows' contents are independent of each other. The scope window keeps displaying its scope items after both primary windows are created (i.e., the parent doesn't get replaced). The first and second primary objects are each linked to the scope window independently.

Claim 18 — Computer storage medium having a data structure.
Same core structure expressed as a stored data structure: a scope window with a hierarchical set of scope items and user-selectable items; a first primary window whose objects are dynamically linked to the selected scope item per a first user-specified instruction set; and a second primary window whose objects are dynamically linked to the same selected scope item per a second, independent user-specified instruction set. The scope window persists after both primary windows are formed.

Claim 21 — Method in a GUI environment.
Independent method claim (text truncated in the source I retrieved) reciting, in a computer system with a graphical user interface, a display, and a selection device: forming a scope window; retrieving scope items for display; and the subsequent steps of forming and populating the primary display windows from those retrieved items. Uncertainty flagged: my authoritative sources cut off in the middle of claim 21, so I can confirm its preamble and first steps but not its full body.

Claim 27 — Means-plus-function claim (inferred).
My source shows a claim ending just before claim 28 whose elements are "means for retrieving first primary objects linked to the scope window… means for displaying the retrieved first primary objects… means for retrieving second primary objects… such that linking the second primary objects… is independent of linking the first primary objects… and means for displaying the retrieved second primary objects…" Uncertainty flagged: I am inferring that this is claim 27 based on sequential position; I could not retrieve the claim number directly.

Claim 28 — Method of allowing a user/administrator to define windows.
Form a scope window showing a hierarchical scope tree per user/administrator instructions; let the user select a particular scope item; form a first primary window distinct from the scope window and dynamically link its objects to the selected scope item per a first instruction set (which changes the content of the selected scope item by defining what the first window displays); form a second primary window distinct from both the scope window and the first primary window, and dynamically link its objects to the same selected scope item per a second instruction set — where the second linking is independent of the first. The scope window persists after both are formed.

Claim 35 — Computer system with GUI (means-plus-function).
A system with means for displaying a scope window; permitting selection of a particular item; displaying first and second primary windows distinct from the scope window and from each other; receiving first and second user instruction sets that define the objects to be displayed in the respective primary windows; and independently linking the first-window objects and the second-window objects back to the scope window in response to the selected item and to the respective instruction sets. The scope window persists after both primary windows are displayed.

Claim 39 — Computer system with GUI (means-plus-function, "driving" variant).
Structurally parallel to claim 35, but framed as driving rather than linking: means for driving the first primary objects off the selected scope item based on the first instruction set, and means for driving the second primary objects off the same selected item based on the second instruction set, with the two driving means being independent of one another. The scope window persists.

Claim 42 — Computer storage medium / method (text truncated).
A further independent claim beginning "A computer storage medium having computer-executable instructions for performing a method comprising: forming a scope window displaying in…" Uncertainty flagged: the source truncates mid-claim, so I cannot state its full scope. Claims beyond 42 (up to 47) were also not retrievable.

Dependencies worth noting

Claim 3 (secondary windows off a selected primary object, with the second secondary window independent of the first), claim 5 (a secondary window that drives back to the scope window so a command/selection changes scope focus or content), claim 16 (user can convert a window from one type to another, e.g., right-click), and claim 17 (window type is determined by the type of query-driven data) capture the more distinctive downstream features. Claim 8 covers saving the workspace as a local view or a shared global database view.

Confidence and Gaps

• High confidence (from the authoritative full text and Google Patents record): title, inventor, application number, filing date, issue date, assignee chain, abstract, 47-claim count, and the full text of claims 1, 18, and 28.
• Medium confidence: the identity of claims 21, 27, 35, 39, and 42 as the independent claims; the claim numbering for 27 is inferred, and I could not verify whether any additional independent claims exist between 42 and 47.
• Explicit uncertainty: full text of claims 21 and 42 is truncated in my sources. I also could not access the USPTO PatentCenter/PAIR record or a Federal Circuit docket directly, so the assignee and legal-status fields are drawn from Google Patents and should be treated as the aggregator's representation rather than an official USPTO determination.

I'll search for litigation involving US patent 7188317.

Let me search the litigation-specific databases directly.

Litigation Search Results for US Patent 7,188,317

Conclusion: I found no litigation involving US Patent 7,188,317. Based on the searches performed, there are no known infringement suits, declaratory judgment actions, or PTAB proceedings asserting or challenging this specific patent.

What was searched

• Google Patents litigation/assignee record for US 7,188,317 (source: https://patents.google.com/patent/US7188317/en)
• Unified Patents litigation portal (https://portal.unifiedpatents.com/litigation/caselist) and patent pages
• General docket searches (UniCourt, Docket Alarm, CourtListener, PACER-derived sources) for "7188317" and "7,188,317" combined with patent/litigation terms
• Microsoft-focused patent litigation searches

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

Several hits contained the digit string "7188317" or similar, but none reference US Patent 7,188,317 as a patent-in-suit. Applying the strict rule to interpret IDs literally:

Patent status context (from the authoritative text)

• Patent: US 7,188,317 B1 — "Dynamic multiple window display having independently linked windows"
• Inventor: Thomas G. Hazel
• Original assignee: Microsoft Corp.; current assignee: Microsoft Technology Licensing LLC
• Filed: June 13, 2001; granted: March 6, 2007
• Legal status: Expired – Fee Related, adjusted expiration 2023-04-02 (i.e., it lapsed for failure to pay maintenance fees)

The expired/lapsed status is consistent with the absence of litigation — a lapsed patent generally cannot be asserted and generates little litigation interest.

Important caveats

• I could not access PACER directly or run a complete, authoritative docket-level query (e.g., a full Docket Navigator or Lex Machina search by patent number). Public web results and aggregated dockets may not capture every historical case, particularly older settled or voluntarily dismissed suits.
• The only sources that returned the exact number 7,188,317 were patent databases and unrelated business registries — no court or litigation record.

Bottom line: If litigation exists, it was not surfaced by these searches. For a definitive, records-level confirmation, a Docket Navigator / Lex Machina / PACER "patent number" search (and a check of USPTO assignment and PTAB filings) should be run by the client.

Disclaimer: This is a research summary, not legal advice. Please verify against primary court records before relying on it.

I'll verify the structured "no proceedings" default against live sources before finalizing.

Proceedings overview

Total AIA trial proceedings on US 7,188,317: 0. No IPRs, no PGRs, no CBMs — active, instituted, settled, or denied. The canonical structured feed ("PTAB proceedings on file," USPTO Open Data Portal) returns no AIA trial records for this patent, and every web-source check I ran returned only patent-database and unrelated-number hits, with no PTAB case number. The defensive posture is therefore not "hardened by surviving IPRs" and not "claims already canceled." It is the third posture: never-challenged-at-the-Board — an untested patent, now expired, with the entire prior-art field still legally available to any defendant.

Proceeding entries

None. There are no proceeding numbers to report, and I will not manufacture any. The structured PTAB block is canonical and states, verbatim in substance, that the ODP API returns no AIA trial proceedings as of the most recent ingest; I was instructed to flag anything web search surfaced that the ODP had missed. Nothing was surfaced.

What I checked (and what the hits actually were):

Two caveats, stated plainly rather than glossed:

1. I could not execute a direct API/real-time query against the PTAB E2E or ODP endpoints from this environment. I am relying on the supplied canonical structured block plus web-source corroboration. For a records-level certification, run a PTAB E2E "patent number" search and a Docket Navigator / Lex Machina AIA-trial query.
2. Web indexes are unreliable for pre-2015 PTAB filings. The absence of hits is consistent with the structured feed, but the structured feed is the load-bearing evidence here — not the search results.

Strategic summary

Claim status: all 47 claims UNTESTED. Nothing has been canceled, confirmed, or amended at the Board. Claims 1 and 18 (the two independent claims visible in the claim set) stand exactly as granted on 2007-03-06, never having been construed by a PTAB panel. There is no FWD to quote, no certificate under 35 U.S.C. § 318(b) cancelling or confirming anything, and consequently no claim-level record to build either an infringement or an invalidity theory around. Any representation that claims of this patent have been invalidated — or have survived scrutiny — would be unsupported.

Estoppel landscape: empty in both directions. Because no IPR was ever instituted, 35 U.S.C. § 315(e)(2) estoppel never attached to anyone — not to a petitioner, not to a real party in interest, not to a privy. There is no prior PTAB record to freeze, and no ground that a defendant is barred from asserting in district court by virtue of a prior Board proceeding. Conversely, the patent owner has not had to defend its claims at the Board and has not narrowed or amended any claim, so it enters any future dispute with its original, broadest claim scope intact and no prosecution-history-before-the-Board admissions to exploit. Practically: a defendant today can raise § 102 and § 103 grounds on patents and printed publications in district court without worrying about IPR estoppel, and can still file a fresh IPR if the patent were assertable. The realistic limiting factors are timing and patent life, not estoppel.

Pattern signals: none, and the reasons are structural. No petitioner has filed even once against this patent, so there is no serial-petitioner pattern, no Unified Patents / defensive-aggregator footprint on this number, and no patent-owner appeal activity (there is nothing to appeal). Three structural reasons explain the silence better than "the patent is bulletproof":

• PGR was categorically unavailable. Post-grant review under 35 U.S.C. § 321 applies only to patents subject to the first-inventor-to-file provisions — i.e., effective filing dates on or after 2016-03-16 (AIA § 6(c)(2)(A), as implemented). This patent's application was filed 2001-06-13. PGR was never a legal option.
• CBM was a poor fit. Transitional CBM review (AIA § 18) reached patents issued before 2014-03-16, which this one satisfies, but only for patents claiming a "financial product or service" — Secure Access v. PNC framing. US 7,188,317 claims hierarchical scope windows driving multiple independent child display windows for systems-management/monitoring consoles (see the monitoring-software example in the specification, FIG. 3–4). Nothing in the claims is financial. CBM was never a credible vehicle.
• Only IPR was realistically available, and nobody needed it. The patent lapsed for failure to pay maintenance fees, with the record showing legal status "Expired – Fee Related," adjusted expiration 2023-04-02 (Google Patents, https://patents.google.com/patent/US7188317/en — the status entry is expressly an assumption of Google's, not a legal conclusion). An unasserted, fee-lapsed patent attracts no petitioners. That is the ordinary reason you see zero AIA trials, and it is the reason here. Note also that the absence of litigation (per the earlier section of this analysis) and the absence of PTAB activity are mutually reinforcing and share the same cause: the patent was never enforced and is now expired.

One caution for the reader: this patent sits squarely in the Microsoft console/GUI family (cf. the MMC / split-pane and list-control lineage) and is cited as prior art by later Microsoft filings (e.g., US 11,652,957 B1 cites US 7,188,317 B1 at https://patents.google.com/patent/[US11652957B1](/patent/US11652957B1)/en). Its citation footprint as prior art is real and worth knowing; that is not a PTAB proceeding and should not be confused with one.

Recommended next steps

For a defendant now receiving any communication citing US 7,188,317:

1. Do not accept the paper's framing. There is no FWD to link to and no certificate of cancellation. The honest statement in a responsive letter or invalidity contentions is: "No AIA trial proceeding has ever been instituted on US 7,188,317, and no claim of that patent has ever been canceled or confirmed by the PTAB." Support it with the Google Patents legal-status/prosecution record (https://patents.google.com/patent/US7188317/en) and a PTAB E2E case search (https://ptacts.uspto.gov) run by counsel.
2. Attack the term, not the claims. The dispositive defensive facts are likely temporal, not merits-based: filing date 2001-06-13, grant 2007-03-06, and recorded expiration 2023-04-02 for fee non-payment. If that status is confirmed at the USPTO Patent Center, no post-expiration infringement liability exists, and any past recovery is bounded by the 35 U.S.C. § 286 six-year lookback measured from complaint filing — which would reach back only to roughly 2020-09, i.e., into a window when, on the recorded status, the patent was in its final lapsed years. Confirm the maintenance-fee payment history directly at USPTO Patent Center rather than relying on aggregator status labels.
3. If the patent's enforceability period is somehow revived or disputed, IPR remains fully open. Zero prior petitions means zero § 315(e) estoppel, and PGR being unavailable is irrelevant because IPR grounds (§ 102/§ 103 on patents and printed publications) are the natural fit for a 2001-filed GUI patent. There is no Fintiv/discretionary-denial problem from a parallel PTAB record — though note the current institution landscape, where the Director now makes institution decisions and "settled expectations" (patent age) is being weighed against institution (see the 2025 Director memoranda and the KCT mandamus materials at https://patentlyo.com/media/2025/11/In-re-Kangxi-Mandamus-Petition.pdf). A 25-year-old patent is the paradigm case where that doctrine could cut against a petitioner, so an IPR filing would need to be justified on compelling merits.
4. Preserve the § 282 defenses. With no Board record, there is no estoppel restricting either side, so invalidity, unenforceability (check the fee-lapse / any inequitable-conduct angle), and § 287 marking/notice defenses all remain available without PTAB-imposed limits.

If the client's question is "has this patent been PTAB-tested?": the answer is no, and the more useful answer is that it never had a PTAB vehicle suited to it (no PGR, no CBM) and no economic incentive for IPR (unasserted and fee-lapsed). A filing is a negative-cost, high-confidence check: PTAB E2E patent-number search, Patent Center maintenance-fee history, and a Docket Navigator / Lex Machina AIA query — but I have no indication it will change the count of zero.

Disclaimer: research summary, not legal advice. The counts above rest on the supplied canonical ODP feed plus web corroboration; verify against primary USPTO records before relying on them.

I'll research the assignment/ownership record for this patent, then build the chain. Let me start with targeted searches.

Good leads. Let me pin down the specific reel/frame records for this patent.

Let me try to pull the patent-specific assignment records (INPADOC / uspto.report).

Inventors

• Single-inventor patent. There is no co-inventor group to analyze for divergence-of-employment patterns.
• Employer at time of filing is determinable and is the original assignee. The Google Patents reassignment record shows an assignment executed/recorded on the filing date 2001-06-13, assigning "HAZEL, THOMAS G. → MICROSOFT CORPORATION." This is the ordinary obligation-to-assign / employment conveyance made the same day the application was filed — i.e., the inventor was a Microsoft employee (or contractor under a written assignment obligation) at filing.
• No departure signal. The "all inventors leave the assignee within 12 months of filing" fire-sale precursor cannot be assessed here: the record has no employment-end data, and there is only one inventor. I found no evidence either way and state that as a negative finding, not a conclusion.
• I could not independently confirm Dr. Hazel's subsequent employment history from the assignment record; nothing in the recorded chain indicates he ever held rights after 2001.

Original assignee

Microsoft Corporation (Redmond, WA) — the entity named on the issued patent.

• Primary line of business: Operating company; software platforms (Windows, server/management tooling) and, at the relevant time, the enterprise systems-management / console product line. The specification's own framing corroborates this: it distinguishes the invention from "the typical model used for such applications as the Exchange software application by Microsoft Corporation," and its entire "Monitoring Software Example" describes a scope pane / result pane console with a splitter bar and hosted OCX list controls — the classic Microsoft Management Console (MMC) snap-in architecture, applied to monitoring software (the "hmdemo" host name and "alerts/events" panes are consistent with Microsoft's Operations Manager–era console work).
• Did it ship a product embodying the claims? The specification is written as an internal console/monitoring implementation (ActiveX split-pane control hosting two OCX list controls, upper "details pane" and lower "alert pane", data driven off scope-pane selection). That is strong evidence of an internal product embodiment, but the assignment record itself contains no product evidence — I flag product-embodiment as inferable from the specification, not proven by the chain of title.
• Current status: Operating. Microsoft Corporation remains a going concern and is the assignor of record on the 2014 transfer. Its patent-holding arm, Microsoft Technology Licensing, LLC, is the current recorded assignee. No bankruptcy, acquisition, or dissolution applies to either entity.

Assignment timeline

Source note / important limitation: The USPTO Assignment Center and its assignment.uspto.gov mirror present the abstract of title per application. I was not able to retrieve the patent-specific abstract-of-title page (and therefore the exact reel/frame and correspondent) for application 09/880,504 from the public web index. What is directly supported by the authoritative Google Patents legal-events record is the set of conveyances, the parties, and the dates below. I have flagged each field I could not verify rather than reconstructing it. Reel/frame values that appear below are block-level, corroborated from parallel Microsoft recordings, not from this patent's own record — treat them as candidate, not confirmed.

1. 2001-06-13 (executed) / recorded on or about 2001-06-13 — Reel /_ (not retrieved)

• Conveyance: Assignment of Assignors' Interest ("ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
• Assignor: HAZEL, THOMAS G.
• Assignee: MICROSOFT CORPORATION, One Microsoft Way, Redmond, WA 98052
• Correspondent of record: not retrievable from the sources available to me — I will not guess at the Microsoft in-house or outside attorney name. (For context only: Microsoft's in-house patent operations handled its 2001-era filings; no firm is named in the record I can cite.)
• Context: Employment/obligation assignment — the inventor's rights to his employer, executed contemporaneously with filing.

2. 2014-10-14 (executed) / recorded 2014-12-09 — Reel 034541/____ (block-level; frame for this patent not individually confirmed)

• Conveyance: Assignment of Assignors' Interest ("ASSIGNMENT OF ASSIGNORS INTEREST; ASSIGNOR: MICROSOFT CORPORATION")
• Assignor: MICROSOFT CORPORATION
• Assignee: MICROSOFT TECHNOLOGY LICENSING, LLC, One Microsoft Way, Redmond, WA 98052
• Correspondent of record: For the parallel Microsoft→MTL recordings in this same campaign, the correspondent is CPA GLOBAL LIMITED, Liberation House, Castle Street, St Helier, JE1 1BL, Jersey (channel-island recording agent). ⚠️ Flag: CPA Global recurs network-wide across the December 2014 Microsoft→MTL bulk recordings — but this is a high-volume corporate IP-recording agent, not an NPE/troll counsel, so its recurrence is a scheduling/administrative tell, not a troll tell. I could not confirm this correspondent is the one on this patent's recording.
• Context: Internal corporate reorganization — intra-group transfer of Microsoft's patent estate to its dedicated licensing subsidiary. This was a mass recording: the Executed-date/Recorded-date pair (2014-10-14 / 2014-12-09) and reel block 034541 (the block opens at frame 034541/0001) recur across thousands of Microsoft patents recorded that day (see e.g. the corroborating INPADOC/assignment entries for US 6,580,418, US 5,751,283, US 7,607,081, US 7,185,285).

No other recordings surfaced. I found no security agreement, license, release, correction, merger, or change-of-name record on this patent. There is no downstream NPE transfer.

Timeline diagram

timeline
    title Ownership of US 7188317
    2001 : Hazel assigns rights to Microsoft Corp
         : Application 09 880 504 filed
    2007 : Patent issued to Microsoft Corp
    2014 : Microsoft Corp assigns to MTL LLC
         : Recorded at reel block 034541
    2023 : Patent expires for fee non-payment

(Note: the 2023 expiry row is a USPTO legal-status event, not an assignment; included only for completeness of the ownership story.)

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT.
The only post-inventor transfer is Microsoft Corporation → Microsoft Technology Licensing, LLC (reel block 034541; executed 2014-10-14, recorded 2014-12-09). MTL is the wholly-owned patent-holding subsidiary of a publicly traded operating company, headquartered at One Microsoft Way, Redmond — not a registered-agent address, not a single-purpose Delaware/Texas LLC, and not a licensing-only entity divorced from a product business. The "IP/Holdings" suffix test is met on form only; the substantive shell indicators (no products, agent address, anonymous principals) are all absent.

2. Known asserter in the chain — NOT PRESENT.
Neither Microsoft Corporation nor Microsoft Technology Licensing, LLC appears on the standard NPE directories (Acacia, Marathon Patent Group, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities, or Unified/RPX high-frequency-plaintiff lists). MTL is an operating company's licensing affiliate, not an acquisitive assertion vehicle.

3. Repeat correspondent across the chain — UNCLEAR (evidence unavailable for this patent).
I could not retrieve the correspondent of record for either recording on application 09/880,504. The only recurrence I can evidence is CPA Global Limited (Jersey) appearing as the recording agent across the parallel December 2014 Microsoft→MTL recordings — a bulk corporate agent, which is the opposite of the "same plaintiff-side lawyer running a family of shell LLCs" pattern. No finding can be made on this signal for this patent.

4. Cascading transfers — NOT PRESENT.
Two recordings spanning ~13 years. No chained LLCs, no A → LLC1 → LLC2 → LLC3 sequence inside 24 months, and no shared correspondent address indicating a manufactured venue chain.

5. Pre-litigation transfer — NOT PRESENT.
The only post-issue transfer is dated 2014 (executed) — seven-plus years after issuance — and no infringement suit naming this patent was identified in the previously generated litigation section. There is no assignment within six months of any suit. (Cross-reference: the prior section's litigation search found no case involving US 7,188,317.)

6. Bankruptcy fire-sale — NOT PRESENT.
Microsoft Corporation has never filed Chapter 7/11. No docketed sale of this patent in any insolvency proceeding (contrast Kodak/Nortel/Polaroid).

7. Privateering — NOT PRESENT.
No evidence Microsoft transferred this patent to a third-party NPE to assert against competitors. The 2014 transfer stayed inside the Microsoft corporate family. (Note: Microsoft is a founding LOT Network member, whose by-laws auto-license Microsoft patents to all LOT members if they are ever transferred to an NPE — a structural anti-privateering commitment. No LOT transfer is recorded for this patent.)

8. Defensive aggregator (anti-NPE) — NOT PRESENT.
The chain does not terminate at RPX, AST, Unified Patents, OIN, or LOT Network. It terminates at Microsoft Technology Licensing, LLC. (The patent did lapse — see Verdict — but by fee non-payment, not by acquisition into a defensive pool.)

Verdict

Defensive / non-asserting.

⚠️ Taxonomy caveat, stated plainly: the closest-fit bucket here is "Defensive / non-asserting," but the enumerated definition for that bucket is "chain terminates at a defensive aggregator (RPX/AST/LOT/Unified/OIN)." That specific criterion is false — this chain terminates at Microsoft's own licensing subsidiary, not at an aggregator. I select this bucket because the substantive outcome matches: the patent passed from the original operating company to that same company's in-house licensing arm via a 2014-10-14 internal transfer (reel block 034541, recorded 2014-12-09), was never asserted, and lapsed for failure to pay maintenance fees effective 2023-04-02. It was never held by any independent NPE and never entered a defensive pool. (A stricter reading of the rubric would say no bucket fits exactly; I have not forced it to "Operating-company assertion," which would falsely imply litigation, nor to "Insufficient data," since the chain is in fact documented.)

Justification in brief: (i) the only two recorded links are Hazel → Microsoft (2001-06-13) and Microsoft → Microsoft Technology Licensing, LLC (executed 2014-10-14, recorded 2014-12-09, reel block 034541) — an ordinary employee-assignment followed, 13 years later, by an intra-corporate reorganization; (ii) neither assignee is a listed asserter, and the 2014 recording was a mass Microsoft estate-wide re-registration handled by the bulk agent CPA Global Limited (Jersey); (iii) no NPE-typical downstream transfer, securitization, or assertion exists, and the patent expired in 2023 — all consistent with a non-asserted, operating-company-owned patent rather than a troll asset.

Cross-reference to previously generated sections — no contradictions found. The prior patent summary recorded the same chain (Hazel → Microsoft Corp., 2001-06-13; → Microsoft Technology Licensing, LLC, recorded 2014-12-09) and the same Expired–Fee Related status, and the prior litigation section independently found no suit involving this patent. The two sections and this analysis are consistent. The only new uncertainty surfaced here is the missing patent-specific reel/frame and correspondent, which the earlier sections also did not have.

Verification links (for a records-level re-run):

• USPTO Assignment Center: https://assignmentcenter.uspto.gov/ (search by application 09/880,504 or patent 7,188,317)
• Assignment Search mirror: https://assignment.uspto.gov/patent/index.html
• Google Patents legal events (authoritative for the events above): https://patents.google.com/patent/US7188317/en
• USPTO Patent Center: https://patentcenter.uspto.gov/ (application 09/880,504)

Explicit residual uncertainty: I could not access the USPTO Assignment Center's per-application abstract of title for 09/880,504 during this run, so the exact reel/frame and the correspondent of record for each of the two conveyances remain unverified. The parties, conveyance types, and dates above are grounded; the block-level reel number (034541) is corroborated from parallel Microsoft recordings and is not confirmed for this patent specifically. Anyone relying on the reel/frame cites should re-pull the abstract of title directly.

This is a research summary, not legal advice.

I'll search the USPTO and patent databases for US 7,188,317's citation records.

Let me drill into the front-page references and citation tables for US 7,188,317 specifically.

I need the front-page "References Cited." Let me target the patent PDF and FreePatentsOnline record.

Prior-Art Analysis for US 7,188,317 B1

Search scope and a hard limitation, stated up front. I was able to confirm the USPTO/Google Patents record for the literal number 7,188,317 and to harvest a substantial set of forward citations (later patents that cite it). I was not able to retrieve the front page's "References Cited" (U.S. Patent Documents + Other Publications) block — i.e., the list of references the examiner actually cited against this patent during prosecution. That list lives on the issued patent's front page (items (56)) and in the USPTO file wrapper (PatentCenter, application 09/880,504). Without it, I can identify likely prior art and the § 102 framework, but I cannot responsibly give a claim-by-claim § 102 anticipation mapping for references I have not seen. I flag this rather than guess, per the strict-ID / no-fabrication rule.

(Minor discrepancy noted: the previously generated sections carry a fetch timestamp of 2026-09-20 and the current task header says April 26, 2026. Nothing in the analysis turns on this.)

1. USPTO-consistent confirmation of the number

Number-collision check (strict-ID rule applied). The following surfaced in connection with the digits 7188317 and are not US 7,188,317:

• JP 7188317 B2 — "Hybrid vehicle control device" (different jurisdiction and art; already flagged in the earlier summary).
• Various registry/numeric coincidences (Brazilian corporate registrations, unrelated docket numbers) — not patents.
• EP 2,333,556 B1 and US 9,141,349 both cite "US 7188317 B1" correctly — these are forward citations of the right patent, not confusions.
• Class-marking variation: Google Patents lists G06F 3/0481 / G06F 9/451, while aggregators (FreePatentsOnline, Radaris) show G06F 3/00 / 715/804. Same patent; differences are in the aggregators' classification display, not the identity.

2. The only prior art I can ground from the authoritative text: applicant-admitted art

The patent's own Background section constitutes an admission of the prior-art model:

"In typical multi-window navigation, a scope item selected in the scope (left side tree) window results in objects of the selected scope being displayed in the upper right display pane. When the user selects an object in the upper right display pane, details of the selected object appear in the lower right display pane. This is the typical model used for such applications as the Exchange software application by Microsoft Corporation. In other words, a single selection drives a single window."

• Citation: Microsoft Exchange (console/multi-pane navigation model), as described in US 7,188,317, col. 1 (Background).
• Date: admitted as "typical" prior art as of the 2001-06-13 filing.
• Description: A three-pane navigation UI — hierarchical scope tree (left), result list (upper right), detail pane (lower right) — in which each pane is driven by a single selection chain, with no independent sibling windows and no child-to-scope back-linkage.
• Potentially anticipatory under § 102(a)/(b) for: the preamble-level concept only — "forming a scope window displaying in a hierarchical structure a plurality of scope items" (claim 1), the corresponding data-structure element of claim 18, and the corresponding step of claim 28. It does not anticipate the independent limitations: two primary windows both driven off the same selected scope item by mutually independent instruction sets, and the persistence of the scope window after both are formed. Those independence/persistence limitations are the intended point of novelty (see the Summary: "Unlike the prior art, the creation, organization, and linkage between the windows … is not hardcoded"; "a single selection drives a single window" is expressly the deficiency being overcome).

Caveat: this is an applicant admission of a commercial product, not a printed publication in the record; its § 102 date and public-accessibility would have to be established independently.

3. Candidate prior art surfaced but NOT verified as cited-on-front-page

These two non-patent items appeared in a citation table adjacent to a US 7,188,317 entry in search results (in the citation list of US 9,141,349, "Visual development environment for implementing logic modules"). They may belong to US 9,141,349's own citation list rather than to 7,188,317's. I am flagging them as candidates requiring verification, not asserting they are the '317 references:

Because two of these three are 1995/1996 and one is 2006, and because the 2006 item is chronologically impossible as prior art to a 2001 filing, I infer the whole block is the other patent's citation list. Do not rely on this table without checking the '317 front page.

4. Forward citations (later patents citing '317) — context, NOT § 102 art

These are important for understanding the art family and the field, but a later patent is by definition not prior art to an earlier one. Several of these also use '317 as background art in the same UI/window-linking space:

5. § 102 mapping — what can and cannot be said

Can be said (with the admitted prior art): the Exchange-style "single selection drives a single window" model, as admitted at col. 1, is the closest thing to anticipatory art I can ground, and it reaches only the generic pane-formation recitations of claims 1, 18, and 28 (and the corresponding means in claims 27, 35, 39, if those are indeed the means-plus-function independents). Every asserted point of novelty — two or more primary windows on the same scope selection, independent instruction sets, independence of the two object sets, scope-window persistence after window formation — survives it.

Cannot be said: any claim-level § 102 rejection grounded in the actual examiner-cited patent references (the (56) block), because that block was not retrievable in this session. Producing such a mapping would require the front page of US 7,188,317 or the file wrapper.

6. To close the gap (recommended, authoritative steps)

1. USPTO PatentCenter, application 09/880,504 → "References Cited" / "Patent References by Examiner" and the full Image File Wrapper (IDS submissions + Form 892 PTO-1449).
2. Front page of the printed patent — the (56) "References Cited" block; obtainable from the patentimages PDF for US 7,188,317 or FreePatentsOnline/USPTO full-page images.
3. Google Patents "Citations" (backward) table for US7188317B1 — distinct from the "Cited By" table; only the former is prior art.
4. For any confirmed reference, run an element-by-element chart against claim 1 (the controlling independent claim) first, then propagate to claims 18/28 and the means-plus-function claims.

Bottom line: The literal number 7,188,317 is confirmed as US 7,188,317 B1 (Hazel/Microsoft). The only prior art I can ground from the authoritative text is the applicant-admitted Exchange single-selection model, which reaches only the generic pane-formation elements of claims 1/18/28. Two non-patent "dynamically linking windows" items (Beaudet 1995, Cundiff 1996) are thematically on point but are not verified as the '317 references, and one item in that same block (Seubert 2006) post-dates the priority date and therefore cannot be § 102 art to this patent. The examiner-cited (56) reference list was not retrievable here, and I have not fabricated one.

This is a research summary, not legal advice or a formal validity opinion.

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

Obviousness Analysis — U.S. Patent No. 7,188,317 B1

"Dynamic multiple window display having independently linked windows"

35 U.S.C. § 103 (pre‑AIA) | Effective filing date: June 13, 2001 | Expired – Fee Related (adjusted expiration 2023‑04‑02)

Status note: this is a technical invalidity analysis, not legal advice. The patent's expired status does not change the § 103 inquiry, which is assessed as of the effective filing date.

0. Source and scope note (read this first)

The task directs me to "use the results from the Prior Art section of this page." Two transparency points:

1. What the page's Prior Art section actually contains (as retrieved): the Google Patents record (https://patents.google.com/patent/[US7188317](/patent/US7188317)/en) exposes (a) prior-art keywords — display window, primary, window, scope, objects; (b) the Similar Documents list (e.g., US 2002/0186257 A1 (Cadiz, 2001‑06‑08); US 7,039,647 B2 (IBM, 2001‑05‑10); US 8,171,414 B2 (NetApp, 2001‑05‑22); US 7,334,196 B2 (Siemens, 2001‑06‑25); US 8,001,465 B2; US 2003/0084035 A1; US 7,251,776 B2); and (c) a Cited By list. It does not expose a clean front-page "References Cited" enumeration in the retrieved rendering.
2. I could not retrieve the examiner's own cited U.S. patent references from the patent's face. Accordingly, this memo builds the strongest available § 103 grounds from the technical prior art in this field, rather than purporting to reproduce the examiner's citation list. Where I rely on a reference whose own filing date I could not verify, I say so.

One cross-reference resolution: the earlier section flagged claim 27's number as inferred. The RPX/insight.rpxcorp rendering of the claims (https://insight.rpxcorp.com/patent/[US7188317B1](/patent/US7188317B1)) confirms the means-for-retrieving limitations as claim 27, and confirms independent claims 28, 35, 39. That resolves the earlier uncertainty; the earlier section's claim set (1, 18, 21, 27, 28, 35, 39, 42) is corroborated. Claims 21 and 42 remain text-truncated in every source I could reach.

1. Governing legal framework

Because the application was filed June 13, 2001, pre‑AIA § 103(a) governs. The analysis follows Graham v. John Deere Co., 383 U.S. 1 (1966) — scope and content of the prior art, differences between the prior art and the claims, level of ordinary skill, and objective indicia — as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007). Under KSR, the test is "whether the improvement is more than the predictable use of prior art elements according to their established functions," and the motivation to combine may flow from "the nature of the problem," "the ordinary creativity of a person of ordinary skill," or the "market demand" for the improvement — not solely from explicit teaching/suggestion/motivation in the references.

Critical dates:

• Effective filing / priority: 2001‑06‑13
• § 102(b) statutory bar cutoff: 2000‑06‑13 (one year earlier)
• § 102(a)/(e) art: anything before 2001‑06‑13

Pre‑AIA § 103(c) caveat: subject matter qualifying as prior art only under § 102(e)/(f)/(g) cannot be used in a § 103 combination if it was commonly owned with the claimed invention at the time of invention. This matters for the Microsoft‑originated secondary references discussed in § 4.4.

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

A POSITA at June 2001 in this art would be a software engineer or UI architect with ~2–4 years' experience building desktop console/management or data‑visualization applications on Microsoft Windows, familiar with: Win32/COM windowing; tree‑view + list‑view master‑detail UIs (Windows Explorer); the Microsoft Management Console (MMC) snap‑in architecture; MDI window management; ActiveX/OCX control hosting; and basic database‑query‑driven display. This is the same person who actually built the accused/claimed system — the patent names no non‑conventional hardware and the specification is, functionally, a design document for a monitoring console.

3. Claim construction of the terms that matter for § 103

Important admission in the specification. The Background (§ "BACKGROUND OF THE INVENTION") concedes the prior art: "In typical multi-window navigation, a scope item selected in the scope (left side tree) window results in objects… displayed in the upper right display pane. When the user selects an object in the upper right display pane, details of the selected object appear in the lower right display pane. This is the typical model used for such applications as the Exchange software application by Microsoft Corporation." That is an applicant admission that the tree + upper‑right list + lower‑right detail layout was known prior art. The only delta the applicant asserts is independence and link‑back.

4. The prior art

4.1 PA‑1 — Microsoft Management Console (MMC) — the primary reference

§ 102(b) status: strong. MMC was in public use and described in printed publications well over one year before 2001‑06‑13:

• MMC 1.0 — shipped in the Windows NT 4.0 Option Pack (1997/98)
• MMC 1.1 — shipped in SQL Server 7.0 and Systems Management Server 2.0 (1999)
• MMC 1.2 — shipped with Windows 2000 (Feb 2000)
• "Microsoft Management Console: Overview" white paper, Microsoft Corp., 1999 (59 pp.)
• "Microsoft Management Console Design and Development Kit," Microsoft Corp., 2000 (pp. i–829 + CD‑ROM) — cited as "OTHER PUBLICATIONS" in a later Microsoft patent (US 8,028,239 B1, https://patentimages.storage.googleapis.com/1c/f7/ea/fb83b9d0ff32ef/US8028239.pdf)
• MSDN "Result Panes" reference documentation (https://learn.microsoft.com/en-us/previous-versions/windows/desktop/mmc/result-panes)

What MMC discloses, mapped to the claims:

Where MMC alone is weakest: MMC's multiple result‑pane views for a single node are, in the stock UI, largely mutually exclusive (tab‑toggled) rather than simultaneously visible in two side‑by‑side result panes, and MMC's multiple MDI windows duplicate the scope pane in each window. MMC alone therefore most cleanly anticipates/renders obvious the "multiple driven windows off one scope selection, each independently authored and independently populated" concept, but the simultaneous two‑pane, one‑scope configuration benefits from a secondary reference. That is precisely where the multi‑view literature comes in.

4.2 PA‑2 — Multiple coordinated views / brushing‑and‑linking (NPL, all pre‑2001)

This is the "information visualization" body of work that invented the concept of several simultaneously visible views driven by one selection:

• Ward, "XmdvTool: Integrating Multiple Methods for Visualizing Multivariate Data," Proc. IEEE Visualization 1994, pp. 326–333 — a system that integrates multiple simultaneous displays and coordinates them.
• Fua, Ward & Rundensteiner, "Hierarchical Parallel Coordinates," Proc. IEEE InfoVis 1999, pp. 58–64 — hierarchical structure‑based brushing: "a structure‑based [technique] that allows the user to control the detailed global level of display and to brush records based on their proximity in the hierarchy." This is a hierarchical selection driving coordinated views — the closest NPL analogue to a "scope window driving primary windows."
• Buja, Cook & Swayne (XGobi), J. Computational & Graphical Statistics, 1996, pp. 78–99; Ahlberg & Shneiderman, CHI '94 — dynamic query + coordinated linked views; Spotfire (1996‑on) — commercially shipped multi‑view, brush‑and‑link data visualization, with rule‑based mapping of query results to visualization type and marking in one view driving what is presented in another (see the Spotfire AB patent family, e.g., https://patents.justia.com/assignee/spotfire-ab).

What PA‑2 supplies that MMC lacks: the explicit teaching that (i) two or more views of the same selected entity can be displayed at once, (ii) each view is independently configured (the user chooses axes/encodings/columns per view), and (iii) a mark/selection in one view is linked back to the master selection, which re‑drives the other views. Element (iii) is claim 5/13/20 in a nutshell.

4.3 PA‑3 — US 6,523,035 B1 ("System and method for integrating a plurality of disparate database utilities into a single graphical user interface")

Retrieved at https://patents.justia.com/patent/[6523035](/patent/6523035) and https://www.sumobrain.com/patents/us/System-method-integrating-plurality-disparate/6523035.html. It describes, in MMC terms, a console where a primary snap‑in (database browser) is extended by multiple independent extension snap‑ins, each exposing its own GUI wizard launched from the console; selecting a host in the scope pane triggers callback registration so the extension snap‑in is notified and drives its own UI; the console integrates disparate utilities into one GUI with multiple independently driven child windows.

Caveat flagged: US 6,523,035 issued 2003‑02‑18; I could not verify its U.S. filing date from the retrieved sources. Its disclosure and content suggest a filing in the 1999–2000 window, which would make it § 102(e) prior art against the 2001‑06‑13 filing. This needs verification. Its apparent assignee (the specification describes BMC PATROL/"BMC Space Management Task Pad" and "PATROL DB‑Reorg") is not Microsoft, so the pre‑AIA § 103(c) common‑ownership bar would not block its use in a § 103 combination. That makes it a strong secondary reference if the filing date checks out.

4.4 Other candidate secondary art (with status caveats)

The last row matters as a discipline point: several references on the Google Patents "Similar Documents" list are after this patent's filing date and cannot support a § 103 ground.

5. The § 103 grounds

Ground 1 — Claims 1, 18, 21, 27, 28, 35, 39 obvious over MMC in view of the coordinated‑multiple‑views art (PA‑1 + PA‑2)

Why every limitation is met. The scope window with a persisting, hierarchical scope tree is MMC's scope pane. Selecting a node drives the result pane (claim 1's "first primary display window"; claim 18's "dynamically linked to the particular selected scope item"). MMC's architecture lets two different snap‑ins author two different result views for the same node, each independent of the other — that is claim 1's "first set of instructions … independent of the second set of instructions" and claim 18's "second set of instructions … independent of the first." The administrator trigger is met by MMC's Author mode / Add‑Remove Snap‑in / Extensions tab / taskpad configuration. The "linking … independently" limitation is met because each result view is populated by its own handler against the scope context passed via IComponent/IConsole2; no view is chained to the other. The "scope window persists" limitation is trivially met — MMC never destroys the scope pane when a result pane is drawn.

Why a POSITA would have combined in the simultaneous two‑pane direction. The Background of the patent itself supplies the motivation: administrators needed to see the children/details of a selected node and the alerts/events for that node and its children at the same time — the patent's own Figures 3 and 4 show exactly this "details pane on top / alert pane on bottom" split. That need is documented in the MMC/console ecosystem: later, formally Microsoft‑owned, art describes the same "split pane control … upper result window … lower result window" design. A POSITA facing that need would have looked to the established coordinated‑views literature (PA‑2), which had been shipping for ~seven years and taught precisely that multiple independently configured views of one selection can be shown simultaneously and coordinated. Under KSR, the combination is "the predictable use of prior art elements according to their established functions."

Expectation of success: high. MMC already hosted multiple view types (list, taskpad, custom OCX, custom HTML) in one result pane, so hosting two — in a split pane — required no new technology. The patent's own "split pane control" is described as an ActiveX control hosting two OCX list controls — i.e., a trivial container built from then‑standard COM/OCX facilities.

The single‑selection‑drives‑single‑window distinction fails. The applicant's only asserted delta over the admitted Exchange model (Background) is independence + link‑back. MMC's MDI statement — "if a scope node is selected in more than one MDI window, the result list need not necessarily be the same" — already discloses two windows driven by the same scope selection with different, independent content.

Ground 2 — Claims 6, 7, 14, 15, 16, 17 obvious over MMC in view of PA‑3 (US 6,523,035) and/or US 7,039,647

• Claims 6/7 (developer‑ or user‑defined linkage passing parameters into a query that operates on a database): MMC's IComponent::QueryDataObject, cookies, and CCF_* clipboard formats pass node context into a data object that the snap‑in queries. US 6,523,035 extends this with an explicit callback‑registration model triggered by scope‑pane selection, and US 7,039,647 (IBM) teaches user‑built queries by drag‑and‑drop. Motivation: a console administrator's whole purpose is to make the displayed objects reflect the selected node.
• Claims 14/15 (window types: table, graph, list, list control, topological view, text window): MMC result‑pane views are list‑view, OCX (which hosts exactly the recited graph/table/topological controls), HTML, and taskpad. Literal correspondence.
• Claim 16 (user converts a window from one type to another, e.g., right‑click): MMC's toggle tabs (normal ↔ taskpad), the View menu (details/large icons/small icons/list), and the Add/Remove Snap‑in + Extensions tab all let a user/administrator change the window type of a pane; right‑click is an obvious input modality for that already‑known operation.
• Claim 17 (window type determined as a function of query‑driven data): MMC's virtual list (IResultOwnerData) has the snap‑in dynamically generating row content as the console asks for it — view content is driven on demand. The Data‑Driven → View‑Type mapping is squarely taught by the Spotfire line and by XmdvTool/InfoVis practice (rule/mapping‑based selection of visualization form from the data), and combining it with MMC would be an obvious design choice ("show a graph when the data is a time series, a table when it is tabular").

Ground 3 — Claims 3, 4, 11, 12, 19 (secondary windows) and 5, 13, 20 (link‑back) obvious over MMC + US 6,523,035 + PA‑2

• Secondary windows / two independent second‑level windows (claims 3, 4, 11, 12, 19): MMC's extension snap‑ins extend a result item, adding their own nodes/views/context‑menu actions for that item; a result item can therefore drive more than one extension‑authored presentation. US 6,523,035 makes this explicit: multiple extension snap‑ins, each with its own GUI wizard, all bound to the same selected object, each operating independently ("object‑to‑task" vs. "task‑to‑object"). That is the claims' "second secondary display window … independent of the first secondary display window."
• Link‑back to the scope window (claims 5, 13, 20): MMC exposes IConsole2::SelectScopeItem so a snap‑in can programmatically re‑select/redirect the scope‑tree node in response to a result‑pane action — literally "a command or selection in the … display window changes the focus or content of the scope window." This is also the ubiquitous Windows Explorer behavior (double‑click a folder in the right pane; the left tree follows), documented in Microsoft's own "Namespace Extensions (Windows Explorer and Controls)" material. PA‑2 supplies the why: brushing/linking from a detail view back to the master selection was a core, well‑understood idiom by 1999–2001. Motivation: the patent's own stated use case (double‑click an alert/subitem → re‑focus the scope tree and drill down) is a workflow improvement with obvious administrator value and essentially no technical risk.

Ground 4 — Claim 8 (workspace saved locally or as a shared global view) obvious over MMC

MMC natively saves configured consoles as .msc files, storable on a local drive or a network share, and MMC 1.2 "saves layout results for each user." Distributing a saved console to a team (or via policy) is the "global view in a database shared by multiple users" limitation realized with the era's standard administrative distribution mechanism. Even in 2001, "let me save my pane arrangement and share it with my colleagues" was a routine design objective, not an inventive one.

Ground 5 — The docked‑edge data‑structure claim(s) obvious over MMC + standard MDI/window‑docking art

The specification's docked‑edge aspect ("edges which are docked to each other so that there is no overlap … increasing the horizontal size of one window will necessarily decrease the horizontal size of the adjacent window") is the ordinary behavior of splitter bars and tiled MDI windows, both present in Windows/MMC (MDI Tile Horizontally/Vertically; draggable splitter bars; dockable toolbars). The patent's own monitoring‑software discussion concedes the implementation is a split pane control with a movable splitter bar — the single most conventional window construct of the era. Caveat: the claims 43–47 neighborhood includes a "docked edges" data‑structure claim whose exact number I could not verify (consistent with the earlier section's flagged gap).

6. Motivation to combine — consolidated

1. The applicant's own admission. The Background concedes the tree‑driven multi‑pane console was the prior art model (citing Microsoft Exchange). It also states the problem in the same breath: a single selection driving a single window "has limitations, particularly in more sophisticated software monitoring systems."
2. The problem was known and the solution was in the air. MMC (Windows 2000, Feb 2000) already delivered scope pane → result pane, multiple result‑pane views per node, extension snap‑ins, MDI multi‑window behavior with different result lists for the same node, console saving/sharing, and programmatic scope‑pane navigation. PA‑2 had, since 1994–1999, delivered simultaneous, independently configured, selection‑linked views, including over hierarchies.
3. Predictable combination, not a new architecture. Every claimed element is a documented, shipping, off‑the‑shelf MMC/windowing feature, combinable with a snaptop‑pane container built from standard ActiveX/OCX. KSR: "the improvement is [no] more than the predictable use of prior art elements according to their established functions."
4. Design incentives. System‑management consoles (BMC PATROL, Exchange, SMS, SQL Server, Computer Management) all had the same administrator pain — needing summary + event detail + performance graph at once — which is precisely what PA‑3/US 6,523,035 and the patent's Figures 3–4 show. Market/design demand is a recognized KSR motivation.
5. No teaching away, no criticality. Nothing in MMC or PA‑2 teaches away from showing two views at once; both trend toward more coordinated views. The patent claims no unexpected result and no measurement demonstrating superiority.

7. Anticipated rebuttals and their weaknesses

8. Conclusion and confidence

Bottom line. US 7,188,317's independent claims (1, 18, 21, 27, 28, 35, 39) are, on the retrieved record, more likely than not invalid as obvious under pre‑AIA § 103 in view of Microsoft Management Console (publicly used and publicly documented well before 2001‑06‑13) in view of the pre‑2001 coordinated‑multiple‑views/brushing‑and‑linking art, with US 6,523,035 and US 7,039,647 supplying the query‑linkage, multi‑extension‑snap‑in and user‑defined‑query limitations. Most dependent claims (2, 6–17, 19, 20, 29–34, 36–38, 40–41) fall with them as straightforward extensions of MMC's documented behavior; the docked‑edge claims fall over standard splitter/MDI tiling.

Confidence grading:

• High: MMC's scope pane/result pane architecture, multiple result‑pane view types, extension snap‑ins, MDI‑with‑different‑result‑lists, Author mode, .msc saving, and SelectScopeItem; the content of the coordinated‑views NPL; the applicant's background admission; claim 27's identity.
• Medium: that US 6,523,035 qualifies as § 102(e) art (its filing date is unverified); the strength of the claim 17 data‑driven‑window‑type ground; completeness of claim 21/42–47 analysis (their text remains truncated in my sources).
• Explicit uncertainty: I could not retrieve the patent's own front‑page "References Cited" list, so this memo does not claim to reproduce the examiner's cited art. If the client has the file wrapper, the strongest move is to re‑run this analysis against the examiner's actual citations and the confirmed filing date of US 6,523,035, using Docket Navigator / Lex Machina / PACER where the earlier research reported only negative public‑web findings.

Contradiction flag: none between this memo and the prior sections. This memo resolves the prior section's flagged uncertainty about claim 27's number (corroborated by https://insight.rpxcorp.com/patent/US7188317B1) and confirms the prior section's warning that the "7188317" digit string surfaces unrelated items (e.g., JP‑7188317‑B2, IPR2026‑00295/‑00297 re Pabari's US 11,656,915) that must not be conflated with US 7,188,317.