US 5227771

I'll search for this specific patent to check for any litigation/docket records, then summarize from the authoritative text.

Let me try one more targeted search for litigation or docket records.

US Patent 5,227,771 — Summary

Source of record: Full patent text from Google Patents (https://patents.google.com/patent/[US5227771](/patent/US5227771)/en), corroborated by EveryPatent (http://www.everypatent.com/comp/pat5227771.html), uspto.report (https://uspto.report/patent/grant/5,227,771), and the UK IPO record for the EP family member EP0537097 (https://www.search-for-intellectual-property.service.gov.uk/EP0537097).

Bibliographic data

Minor discrepancy flagged: one aggregator (Unified Patents portal) lists the priority/effective date as "1991-07-09." The authoritative patent record and all other sources give 1991-07-10. I treat 1991-07-10 as correct.

Abstract (verbatim)

"A window displayed on a user interface can be incrementally enlarged or reduced by selecting an appropriate sizing icon. There are provided an enlarge icon and a reduce icon in the window title bar. To resize the window, the user selects the appropriate icon with the cursor. The window will change its border size according to a predetermined incremental value. The data that is displayed inside of the newly sized window is determined and then displayed. By continuously selecting one of the sizing icons, the window will be continuously sized in an incremental manner until the user terminates the selection or until the maximum or minimum window limits are reached. As the window is resized, the cursor remains attached to the selected icon. During resizing of the window, one border corner is fixed in position on the interface while the opposite border corner is moved."

Cited prior art (of record)

US 4,574,364 (Tabata, Hitachi); US 4,692,757 (Tsuhara, Hitachi); US 4,831,556 (Oono, Toshiba); US 4,890,098 (Dawes, IBM); US 4,896,148 (Kurita, Minolta). Also a non-patent citation: Microsoft Windows User's Guide, version 2.0, Microsoft Corp., 1987, pp. 6–7, 32–41, 54–55, 66–75 & 96–103. The patent has an unusually large forward-citation footprint (269 "cited by" entries in the Google Patents family listing, 144 in the shorter table), covering later IBM, Apple, Microsoft, Sun and Intel window-management art.

Independent claims in plain language

There are five independent claims: 1, 6, 10, 12 and 13. Claims 2–5, 14 and 15 depend from claim 1; claims 7–9 from claim 6; claim 11 from claim 10; claim 16 from claim 12; claim 17 from claim 13.

Claim 1 — Two-level icon semantics (method). Display a window with data in it, plus an enlarge icon and a reduce icon. Detect a user selection that may be a first or second selection of the enlarge icon, or a first or second selection of the reduce icon. Identify which of those four it is, then size the window accordingly: a first selection enlarges/reduces by a predetermined increment; a second selection enlarges/reduces directly to a predetermined maximum or minimum size. Determine the new content for the resized window and display the new window with that content. (Operationally this maps to single-click = step increment; double-click = jump to max/min.)

Claim 6 — Continuous/repeating incremental sizing (method). Display window + enlarge and reduce icons; detect selection of either icon. Compute a new window size per a predetermined incremental value, where that increment is chosen such that plural repeated increments reach a predetermined maximum or minimum. Determine and display the new content. Then test whether the user input is continuous; if so, repeat the sizing/display steps until the input terminates or the max/min size is reached. (This captures the press-and-hold behavior.)

Claim 10 — Cursor re-attachment after resizing (method). Display window + enlarge and reduce icons; detect a selection made by a cursor on one of the icons. Compute the new window size (enlarged or reduced) per a predetermined increment, where the new window has newly positioned enlarge and reduce icons; determine the new content; attach the cursor to the selected, newly positioned icon; and display the new window, new content and newly positioned cursor. (This is the "pointer stays glued to the sizing icon" feature, so the user need not re-acquire the icon across multiple increments.)

Claim 12 — Data processing system, two-level icon semantics (apparatus). A system claim mirroring claim 1 in means-plus-function form: interface means for display; means for displaying a window with data plus enlarge and reduce icons; means for detecting input comprising first/second selections of each icon; means for identifying which selection occurred; and means for determining a new window size — increment-responsive for first selections, max/min-responsive for second selections — with the increment predetermined so plural increments reach the max or min. The determining means is coupled to the detecting and displaying means so the newly sized window is displayed.

Claim 13 — Data processing system, cursor re-attachment (apparatus). Interface means; means for displaying window/data plus enlarge and reduce icons; means for detecting a cursor-based selection of either icon; and means for determining a new window size per a predetermined increment (enlarged or reduced per the input), which determining means also computes new icon positions and a new cursor position so the cursor is attached to the selected, newly positioned icon. Coupled to the detecting and displaying means so the new window is displayed.

Features carried only in dependent claims

• Fixed-corner/border resizing (claims 2, 3, 7, 8): hold at least one border segment fixed while the remaining segments move; and if a moving border segment hits an interface limit, reposition the fixed segment so the entire new window remains viewable (i.e., the "slide the window back onto the screen as it approaches the edge" behavior).
• User-selectable increment (claim 5): permit the user to choose the predetermined incremental value.
• Increment-customization dialog (claim 9): on user request, display a sizing window; detect an incremental-value input; compute and display a new sizing window — this corresponds to the "INCREMENTS" pop-up (FIG. 10) with a miniature preview of the current window, push buttons and prompts, plus vertical/horizontal increment read-outs in pels with dimension lines, live-updated as the user types values.
• Continuous mode added to the two-level claims (claims 14, 11) and cursor re-attachment added to the two-level claims (claim 15): claim 14 grafts claim 6's continuous-input loop onto claim 1's structure; claim 15 grafts claim 10's cursor-attachment feature onto claim 1. Claims 16 and 17 add the cursor/icon-repositioning function to the system claims 12 and 13 respectively.

Prosecution/drafting artifacts worth noting

The granted text contains apparent typographical defects that a careful analyst should not silently "correct": claim 1(c) and claim 6(c) both end with a stray "interface;" fragment; claim 12 recites "a second secretion of said enlarge icon" and "aid information"; claim 6(g)'s closing alternative reads "said predetermined maximum size or said predetermined maximum size" (the second should read "minimum"); and claim 11 recites "predetermine minimum size." These are literal-text defects in the printed patent.

Docket / litigation check — honest limitation

I ran targeted searches for US 5,227,771 / "5227771" in connection with CAFC 2026 dockets and district court litigation. My search tooling surfaced no litigation, PTAB proceeding, or Federal Circuit appeal involving this specific patent. The only IBM-related 2026 docket material returned concerned unrelated matters (e.g., KPM Analytics v. Blue Sun Scientific in the First Circuit, and Xinuos v. IBM, which is a copyright dispute over Project Monterey/AIX). Because I do not have direct PACER, CourtListener docket-query, or Lexis/Westlaw access here, I cannot certify that no such proceeding exists — absence of results in a general web search is not proof of absence. Treat the "no litigation found" statement as a search result, not as an authoritative negative finding.

One further caveat: the patent expired (anticipated expiration 1991-07-10 + 20 years = 2011-07-10, consistent with the "Expired – Lifetime" status), so any 2026 CAFC activity would necessarily involve expired-patent issues such as past damages or license/standing questions rather than injunctive relief.

I'll research litigation involving US patent 5227771.

Initial results were mostly noise. Let me search more targeted litigation sources.

The searches are returning unrelated IBM cases. Let me refine with more specific litigation-focused queries.

Summary of Findings

Based on my searches, I found no litigation in which US Patent No. 5,227,771 was asserted as a patent‑in‑suit.

I attempted multiple queries against litigation-covering sources (Google Patents' litigation/citation data, general web searches referencing the Unified Patents litigation portal, PACER-adjacent aggregators such as Docket Alarm / Justia Dockets / PacerMonitor, and USPTO PTAB filings). Every hit that contained the string "5227771" or "5,227,771" was one of the following non-litigation matches:

I also surfaced several genuine IBM patent suits (e.g., VirtaMove Corp. v. International Business Machines Corp., E.D. Tex. 2:24‑cv‑00093 / 2:25‑cv‑00619; Neon v. IBM; TecSec v. IBM; ExactoJoin LLC v. IBM, W.D. Tex. 7:26‑cv‑00105), but none of these plead US 5,227,771 — they involve different patents entirely, and they appeared only because my query contained the word "IBM." I have deliberately excluded them rather than misattribute them to this patent.

Litigation Table

No cases found. Accordingly, I cannot provide a plaintiff/defendant/jurisdiction/case‑number/filing‑date/status row for any case, because no such case was identified.

Important Caveats (please read before relying on this)

1. My search run was truncated. I hit a tool-call/time limit before I could exhaustively query the sources you named directly (the Unified Patents portal case list, PACER/CM-ECF, and Docket Alarm). A negative result from an incomplete sweep is not proof of a true negative.
2. I did not retrieve a single Unified Patents portal record for this patent — the portal search did not return a usable case list for 5227771. So I cannot say the portal was "checked and confirmed empty"; I can only say I did not obtain a hit.
3. Practical context favoring a genuine "no litigation" conclusion (this is my analysis, not a sourced fact): the patent is a 1991 IBM window‑sizing patent that reached its anticipated expiration on 2011‑07‑10 (per the Google Patents legal-status record, "Expired – Lifetime"). A patent that expired ~15 years ago has essentially no remaining enforceability window and is an unlikely candidate for modern assertion. This is consistent with — but does not itself prove — the absence of litigation.
4. Note on scope: you asked specifically not to return results for similar numbers. I have followed that. Some search engines would have conflated 5,227,771 with neighbors such as 5,227,770 or 5,227,772; I discarded those.

Recommendation

To get a definitive answer, the following should be checked directly (I was unable to complete these):

• Unified Patents litigation portal: https://portal.unifiedpatents.com/litigation/caselist — search the exact patent number.
• USPTO Patent Center / Patent Assignment / PTAB: https://patents.google.com/patent/US5227771/en shows only 5 examiner citations (US 4,574,364; US 4,692,757; US 4,831,556; US 4,890,098; US 4,896,148) and 2 non-patent citations, with no "Litigation" section populated — which on Google Patents is itself an indication of no known asserted cases.
• PACER / CourtListener RECAP docket search on the exact string 5,227,771.

If you'd like, I can run a further, more targeted pass against any one of those specific sources.

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

AIA Trial Proceedings — US 5,227,771

Verification note: The canonical structured "PTAB proceedings on file" block supplied with this task states that the USPTO Open Data Portal returns no AIA trial proceedings for this patent as of the most recent ingest. I ran targeted web searches to try to surface anything the ODP has not indexed (searches on the patent number combined with "IPR," "inter partes review," "post-grant review," "PTAB," "litigation," and the inventor/assignee pair Kerr/Torres/IBM). No IPR, PGR, or CBM petition, institution decision, FWD, or appeal involving US 5,227,771 surfaced. The default therefore controls: there is no PTAB activity on file.

Proceedings overview

Total AIA trial proceedings on file: 0 (0 active, 0 with claims invalidated, 0 with claims sustained, 0 settled, 0 with institution denied).

The bottom-line defensive posture is unusual for this patent and does not depend on PTAB outcomes at all: US 5,227,771 issued on 1993-07-13 with a 1991-07-10 priority date, and Google Patents records its anticipated expiration as 2011-07-10, with the legal status listed verbatim as "Expired - Lifetime." There is no live patent here to defend against — no IPR was ever needed, and none was filed. If you are receiving a demand letter citing this patent, the first question is not "how do I invalidate it," it is "how is this patent being asserted at all, given that it lapsed more than fifteen years ago?"

No proceedings to report

Because the structured list is empty and my searches corroborated that, I am not going to construct placeholder entries. Inventing a proceeding number, a petitioner, or an FWD disposition would be the single most damaging error in this analysis — a defendant who relies on a nonexistent "claims canceled" FWD would build a defense on sand. So: there is no ### IPR20XX-XXXXX entry to write.

Strategic summary

Claim status: all 17 claims UNTESTED before the PTAB — and all 17 are expired. No claim of US 5,227,771 has been canceled, confirmed, or even challenged in an AIA trial. Claims 1–17 (the method claims 1–11 and 14–15, and the data processing system claims 12–13 and 16–17) therefore stand in the same posture they had at issuance: never administratively reviewed, never judicially construed as far as my searches revealed, and now unenforceable by reason of the patent term having run. The claim set includes the incremental-sizing-and-icon-attachment features (claims 4, 10, 15, 16, 17) and the border-fixing/limit-repositioning features (claims 2, 3, 7, 8) that make this patent a frequently cited foundational reference — Google Patents lists it in the citations of a very large number of later window-management and GUI patents (144 "cited by" entries in the excerpt supplied).

Estoppel landscape: § 315(e)(2) is a non-issue here, because there was never a petitioner. No party is estopped, because no party filed. That cuts in an unexpected direction: if a defendant today faced a live assertion (and I found no evidence of one), the entire universe of prior art — including the five references the examiner cited and the Microsoft Windows 2.0 User's Guide non-patent literature identified in the file — would remain available in district court, with no IPR-driven narrowing and no claim-construction record. But again, the more fundamental point is that the patent's term has expired, so the prior-art question is academic unless someone is asserting it improperly or in a manner that mischaracterizes its status.

Pattern signals: absent. There is no repeat-petitioner pattern because there is no petitioner. There is no PTAB appeal history because there is no Board decision to appeal. I searched for a defensive aggregator (e.g., Unified Patents) in the chain and found nothing connecting such an entity to this patent — which is unsurprising, because Unified and similar entities target currently asserted patents, and this one expired in 2011. The original assignee, International Business Machines Corporation, appears only as the patent owner; IBM's later, well-documented PTAB and district court activity (for example the IBM v. Zillow line of § 101 cases cited in unrelated search results) involves different, much later patents and has no bearing on the '771 patent.

Recommended next steps

• Treat the absence of PTAB activity as a signal about the patent's age and status, not about its strength. Well-asserted patents with live terms attract IPRs; this patent did not, most plausibly because its anticipated expiration date of 2011-07-10 preceded the effective date of the AIA's IPR provisions (2012-09-16) and the CBM transitional program (which ran from 2012-09-16 through 2020-09-16). A CBM petition could only be brought by a party sued for or charged with infringement, and the window for such a challenge to a patent whose term ended in 2011 was effectively nil.
• If you have received a demand or a complaint citing US 5,227,771, verify the patent's status directly and immediately. Pull the current USPTO Patent Center record and confirm the expiration and the maintenance-fee history rather than relying on any search result, including this one. If the patent is in fact expired and unenforceable, that is your defense, and it is dispositive in a way that no IPR could be — it defeats the assertion outright rather than merely canceling claims. Document the source of the expiration determination and the date on which the assertion was made.
• Do not represent to a court or an adversary that claims of this patent "have been canceled" or "survived IPRs." Neither is true. All 17 claims are untested at the PTAB; the patent's term has simply run. If you need an authoritative negative statement, cite the USPTO Open Data Portal record showing no AIA proceedings, plus the Patent Center legal-status record showing expiration.
• If it turns out there is a live assertion — for example, a pre-2011 or post-expiration damages theory, or an assertion against activity that predates expiration — then and only then does validity analysis matter. In that scenario, the key prior art on the face of the patent is US 4,574,364 (Hitachi), US 4,692,757 (Hitachi), US 4,831,556 (Toshiba), US 4,890,098 (IBM), US 4,896,148 (Minolta), plus the Microsoft Windows User's Guide, version 2.0 (1987) non-patent literature. Because no IPR was ever filed, none of these are subject to any § 315(e)(2) estoppel and all remain fully available. I could not locate a district court or Federal Circuit decision construing this patent, so I have no claim-construction record to point you to; state that limitation candidly rather than implying the patent has been litigated and lost.

Confidence and limitations: I have high confidence that no AIA trial proceeding on US 5,227,771 is on file, based on the ODP-derived structured block plus multiple corroborating searches. I have lower confidence about the complete absence of district court litigation involving this patent, because my searches were not an exhaustive litigation-database query (no PACER or Docket Navigator run) and pre-2011 complaints involving IBM are not well indexed in general web search. I would not represent the non-litigation finding as definitive without a dedicated docket search.

I'll verify the assignment record before writing anything, since the provided patent text shows only one assignment event (with no reel/frame) and no post-issuance transfers.

Let me try to locate the recorded assignment document itself and check for any post-issuance transfers.

Assignment Record Reconstruction — US 5,227,771

Important sourcing caveat up front. I was not able to run a live query against USPTO Assignment Center (assignmentcenter.uspto.gov) in this session, and no third-party mirror I could reach surfaced a reel/frame for this patent. Everything below is grounded in the Google Patents legal-events record for US5227771A (https://patents.google.com/patent/US5227771A/en), which I treat as authoritative per my operating rules, plus the front-page bibliographic data. Where a reel/frame or correspondent is not in that record, I say so rather than guess. Verify against Assignment Center before relying on the "no post-issuance transfers" conclusion.

---

Inventors

The assignment record lists Assignors: Kerr, Linda L.; Torres, Robert J. conveying to International Business Machines Corporation, a corp. of NY. IBM's standard practice — confirmed by the boilerplate IBM inventor-assignment forms visible in the USPTO legacy assignment corpus — is a same-day, all-inventors conveyance to IBM, which is exactly the pattern here.

Unusual-pattern check: Unclear / not determinable from the record. The premise you flagged — all inventors departing the original assignee within 12 months of filing as a fire-sale precursor — cannot be tested here, because there is no inventor-side data in the patent or assignment record (no re-assignment back to the inventors, no subsequent inventor-to-third-party conveyance). The chain never left IBM, so there is no departure event to detect. Note only that both inventors were IBM-located (the specification targets the IBM Personal System/2 and languages "such as BASIC, PASCAL or C," consistent with IBM Boca Raton / Armonk-area work on OS/2 Presentation Manager).

---

Original assignee

International Business Machines Corporation (Armonk, New York), assignee of record from filing. The issue-date assignee shown on Google Patents is likewise International Business Machines Corporation.

• Product embodying the claims: Yes — this is a GUI window-management invention. The specification's flow charts are written for "a computer such as the IBM Personal System/2 (PS/2) family of computers," i.e. the OS/2 Presentation Manager window environment. The claimed subject matter (title-bar enlarge/reduce sizing icons, incremental resize, cursor clinging to the selected icon) is a window-chrome feature, and OS/2 shipped exactly this style of title-bar sizing control. This is operating-company software, not a paper asset at issue.
• Primary line of business: Computer hardware, system software, and IT services.
• Current status: Operating. IBM remains an active NYSE-listed enterprise; no dissolution, bankruptcy, or acquisition of IBM is implicated. (No IBM Chapter 7/11 event relevant to this patent exists.)

---

Assignment timeline

Finding: this patent has only ONE recorded assignment in the sources reviewed — the original inventor→IBM conveyance. No post-issuance assignment appears. The original assignee therefore still owns the patent.

• 1991-07-10 (executed / filed) / recorded 1991-07-10 — Reel/Frame: NOT DISCLOSED in the Google Patents legal-events record; not retrievable via third-party mirrors consulted

  • Conveyance: Assignment of assignors' interest ("ASSIGNMENT OF ASSIGNORS INTEREST")
  • Assignor: Kerr, Linda L.; Torres, Robert J.
  • Assignee: International Business Machines Corporation, a corporation of New York ("A CORP. OF NY")
  • Correspondent: Not disclosed in the record available to me. IBM self-files its inventor assignments through in-house IP operations (the legacy corpus shows IBM's own "IBM Corporation" correspondent block, e.g. Rochester MN dept. 917 for PS/2-era filings), so an in-house IBM correspondent is the likely-but-unconfirmed entry. Do not treat this as a finding — the correspondent field was not obtained.
  • Context: Ordinary employment/obligation assignment at filing — every-inventor-to-employer, the routine opening link of a corporate chain of title, not an acquisition or fire-sale.

• (No further records.) No merger, change-of-name, security agreement, corrective assignment, release, or licensing-only LLC transfer appears for this patent. The Google Patents "Reassignments" events list contains only the 1991 inventor→IBM entry, and the "Current Assignee" field remains International Business Machines Corp — there is no "current assignee (may be inaccurate)" divergence from the original assignee, which is the tell Google Patents typically shows when a later transfer went unrecorded.

Terminus: Patent expired 2011-07-10 (anticipated expiration, "Expired – Lifetime"). That date is 20 years from the 1991-07-10 filing date, so this is natural end-of-term expiration, not abandonment for non-payment and not a sale into a monetization chain. The asset was never in play before it lapsed.

---

Timeline diagram

timeline
    title Ownership of US 5227771
    1991 : Filed 1991-07-10
         : Kerr and Torres assign to IBM
    1993 : Patent issued 1993-07-13
    2011 : Term expires 2011-07-10
         : No further recorded transfers

(Only one assignment exists, so the diagram is a straight line: invent → assign to IBM → issue → natural expiration. No branching or cascading transfers.)

---

NPE / troll-pattern signals

Note on the citation volume as a (non-)signal. US 5,227,771 carries roughly 269 forward citations ("Cited By (269)") and is a foundational reference in window-resizing art. High forward-citation count is frequently mistaken for NPE salience; here it indicates the opposite — the patent was influential prior art owned by an operating company that let it run to full term, not a monetization vehicle.

---

Verdict

Insufficient data — and, on the record obtained, affirmatively not an NPE chain.

The only recorded transfer is the routine 1991-07-10 inventor→International Business Machines Corporation employment assignment (Kerr and Torres as assignors), with no post-issuance assignment, no change of assignee, and no litigation naming the patent. IBM is the assignee of record from filing to the patent's 2011-07-10 natural expiration, so the chain terminates at an operating company that shipped the claimed window-management functionality in OS/2 — not at a licensing LLC. Per the rubric this maps to Insufficient data (only the original assignment), with the caveat that the underlying source was Google Patents legal events rather than a first-party Assignment Center query, so I could not capture reel/frame or correspondent.

Verify here: USPTO Assignment Center, search by patent number — https://assignmentcenter.uspto.gov/ (mirror: https://assignment.uspto.gov/patent/index.html). Confirm (a) that exactly one assignment is indexed for 5,227,771, and (b) the reel/frame and correspondent on that single record.

---

Analyst's bottom line

This is the cleanest possible ownership picture: one link, employer to employee-inventors, never sold, expired on schedule. There is no shell entity, no repeat-player NPE correspondent, no cascading LLC chain, and no pre-litigation transfer — because there is no transfer after 1991 at all. If a later record does exist in Assignment Center that Google Patents missed, the highest-value fields to pull would be the correspondent name and address on the 1991 record (to establish the baseline IBM in-house filer) and any record dated 2011 or later (which would necessarily post-date expiration and be of near-zero monetization value).

I'll research US patent 5227771 and its prior art references. Let me start with targeted searches.

Let me research the remaining prior art references.

Prior Art Analysis — US Patent 5,227,771

1. The Patent Under Review

Independent claims: 1, 6, 10 (methods), 12, 13 (data‑processing systems).
Dependent claims: 2–5, 7–9, 11, 14–17.

Core inventive concept: window resizing by selecting enlarge/reduce icons (rather than dragging a border) so the window changes size by a predetermined increment; a corner is held fixed while the opposite borders move; the cursor remains attached to the selected icon as the window resizes; continuous selection produces repeated increments; and the increment size is user‑customizable via a dialog.

---

2. Methodology and a Key Caveat

The five references below are the patent citations listed on the face of US 5,227,771 (i.e., cited by the examiner), plus one non‑patent citation. This means they were considered during prosecution and did not defeat patentability as filed — which is important context for the §102 question you asked.

⚠️ Important limitation: In a strict §102 anticipation analysis, a reference must disclose every element of a claim arranged as in the claim. None of the five references, on their face, discloses the combination recited in independent claims 1, 6, 10, 12, or 13 (in particular the enlarge/reduce icon pair used for incremental sizing, the second-selection‑to‑maximize/minimize behavior, and the cursor‑attachment feature). These references are therefore best characterized as §103 (obviousness) art and as anticipatory only with respect to certain narrower claim elements, not the independent claims as a whole. I flag specific points of uncertainty below rather than overstate an anticipation theory.

All five references predate the 1991‑07‑10 filing/priority date and are therefore valid prior art under §102(a)/(b) (pre‑AIA).

---

3. Reference‑by‑Reference Analysis

Reference A — US 4,574,364 A

Description. A window‑management system for a raster display. It maintains a window management table (position, size, level/overlap) and executes commands including a SCALE command that changes the size (lateral/longitudinal dimensions) of a designated window, updating the window management table and refresh memory. It discloses creating, deleting, moving, scaling and re‑layering windows, and uses a transfer controller to "quarry" the correct portion of image data into the refresh memory.

Claim mapping (potential §102 / §103 relevance):

• Elements of claim 1 / claim 12: anticipates/makes obvious the general steps of displaying a window with data therein and determining a new window size and displaying it (the SCALE command with new w/H values).
• Weakness for anticipation: No enlarge icon / reduce icon selection, no fixed corner with moving opposite borders, no cursor‑attachment, and no continuous/incremental resizing. The size is explicitly input as parameters (keyboard), not via icons.
• Best used for: §103 in combination with an icon‑based interface reference to show window‑resizing to a computed new size with recomputed content was known.

---

Reference B — US 4,692,757 A

Description. A multimedia (text/graph/image) windowing display that writes window content directly into a bit‑map refresh memory (avoiding a large page‑sized image memory). It maintains a window management table defining each window's position and size, and supports commands including:

Claim mapping:

• Relevant to claim 1/6/12 generally: discloses window resizing commands (GROW/SHRINK) and recomputation of window size and displayed content — i.e., the concepts of determining a new window size and determining new data to display.
• Distinguishing features absent: commands are keyboard‑entered with parameters; no enlarge/reduce icons, no cursor attached to a sizing icon, no incremental-by-predetermined-value with continuous repeat, no fixed‑corner / moving‑border re‑positioning step for repair of the fixed corner.
• Best used for: §103 — "GROW" and "SHRINK" are conceptually close to the claimed enlarge/reduce actions; the novelty of '771 lies in the icon‑driven incremental mechanism, not in resizing per se.

---

Reference C — US 4,831,556 A ⭐ (closest of the cited art)

Description. A document‑processing device with multi‑window display. A "frame icon" surrounds each window and carries several icons, including:

• left/right/up/down arrow icons that move the window by an increment (Δx/Δy, sized to one character), and
• a "slanted arrow icon" / "size arrow icon" 51 at the lower‑right corner used to expand or contract the window display region.
• The frame icon expands or contracts with the window and stays on the window's periphery; the scroll indicia regions resize while the icon sizes remain fixed.

The user positions the mouse cursor on an icon and presses and holds the button to move/scroll, or moves the cursor while pressing to resize; content is updated accordingly. Movement is by fixed increments Δx, Δy.

Claim mapping — strongest prior art in this set:

• Claim 4 (cursor/icon attachment analog): The frame icon (with its size‑arrow icon) is repositioned as the window changes size while remaining on the periphery. This is closely related to '771's "cursor attached to selected icon as window changes size." However, Toshiba repositions the icon, not the cursor onto the icon automatically; the distinction matters and is likely why this did not anticipate claim 4.
• Claims 1/6/12 general steps: window displayed with data; icons displayed; user input selecting an icon; window resized; content re‑displayed — all present.
• Claim 2/7 (fixed border segment, moving remaining segments): Toshiba resizes about an anchor while the frame follows the periphery — arguably related, but Toshiba does not expressly recite the fixed‑corner/moving‑opposite‑border scheme or the reposition‑fixed‑corner‑at‑screen‑limit step (claims 3/8).
• Gaps: The enlargement via icon 51 is a drag‑resize, not a discrete predetermined increment driven by a single click; there is no second‑selection‑to‑maximize/minimize; no user‑customizable increment.
• Best used for: primary §103 reference against claims 1, 4, 6, 10, 12, 13 and their dependents; a strong secondary reference against the "icon moves with the resizing window" and "hold button to repeat" concepts.

---

Reference D — US 4,890,098 A

Description. A window manager that lets a user mark an area on the display to define the dimensions and contents of a resized window. The user selects a window, positions a cursor at an axis location, presses a button, and a transparent "sizing window" appears at the top of the stack. "…as the user moves the cursor around the screen, the transparent sizing window stretches and shrinks, like a rubber‑band… to enclose the newly sized window." On completion, all non‑hidden text/attributes within the enclosed area are incorporated into the newly resized window (checking for windows below, hidden vs. visible, default/background fill, etc.).

Claim mapping:

• Relevant to "determining new data to be located in the new window" (claim 1(f), 6(e), 10(e), 12, 13): Directly addresses computing the content for a resized window — and goes further (multi‑window content incorporation, hidden/visible checks). This is strong §103 art for the "determine new data" step.
• Relevant to "user input for changing the size of the window": cursor‑driven sizing input is disclosed.
• Distinguishing features absent: No enlarge/reduce icon pair; no fixed‑corner with opposite borders moving; no predetermined incremental value; no max/min second‑click behavior; no cursor‑attachment to a sizing icon. The resizing is a free‑form rubber‑band drag, which is precisely the prior‑art approach '771 characterizes as "clumsy."
• Best used for: §103 against the "determine/display new data in the resized window" limitations and to show that cursor‑driven resizing with content recomputation was well known.

---

Reference E — US 4,896,148 A

Description. A display apparatus cited by the examiner. On the information available to me, this is a general display‑apparatus reference relating to display of information/indicators on a screen.

⚠️ Explicit uncertainty: My searches returned only bibliographic confirmation of this citation (priority 1986‑09‑08, grant 1990‑01‑23, Minolta Camera). I do not have a verified detailed disclosure record for US 4,896,148 and will not fabricate claim‑by‑claim mapping for it. Based on its title, assignee and era, it appears to have been cited as general background art (a peripheral/"A"-type reference) rather than as an anticipation reference. To analyze it rigorously you should pull the full text (USPTO PatentCenter / Google Patents) and inspect its description and drawings.

Preliminary view (low confidence): unlikely to independently anticipate any claim of '771; likely relevant only to the general environment of computer‑controlled displays.

---

Reference F (Non‑Patent Literature) — Microsoft Windows User's Guide ("Windows 2.0")

Description. The user's guide for Microsoft Windows 2.0 — a bona fide GUI operating environment manual. It documents window management conventions of the era, including maximize/minimize controls, window sizing, resizing by manipulating window borders, and application switching.

Claim mapping:

• Relevant to claim 1(e) / 12(e) — the "second selection … to a predetermined maximum or minimum size": Windows 2.0 provided maximize and minimize controls to drive a window to maximum (full screen) or minimum (icon state). This is material prior art for the max/min aspect.
• Relevant to window‑resize by border manipulation — the very practice '771 identifies as the clumsy prior art it improves upon.
• Distinguishing features absent: Windows 2.0's documented paradigm uses maximize/minimize buttons plus border‑drag sizing — it does not disclose an enlarge/reduce icon pair used for discrete incremental sizing, nor the cursor‑attachment or fixed‑corner features.
• Best used for: §103 — establishes that "first action = resize; second action = maximize/minimize" style control and full‑screen/icon states were conventional, which narrows the scope of '771's max/min claims.

---

4. Summary Ranking of Relevance

---

5. Bottom Line

• Most relevant single reference: US 4,831,556 A (Toshiba), because it is the only cited reference that combines dedicated icons on the window frame, icon‑based resize/expand‑contract control, a frame that repositions itself as the window resizes, and press‑and‑hold repeat behavior — i.e., the features on which '771's alleged novelty (icons instead of border‑drag; cursor/icon tracking) most directly builds.
• Most relevant for the "determine new data in the new window" limitation: US 4,890,098 A (IBM/Dawes‑Henson).
• Most relevant for the maximize/minimize "second selection" limitation: Microsoft Windows User's Guide v2.0 (1987).
• No single cited reference appears to anticipate any independent claim (1, 6, 10, 12, 13) under §102 as a matter of strict "every element arranged as claimed" analysis — chiefly because none discloses the conjunction of (i) enlarge/reduce icon selection, (ii) predetermined incremental sizing, (iii) cursor attached to the resized icon, and (iv) fixed‑corner/moving‑border with corner repositioning at display limits. These references are therefore appropriately treated as §103 art — which is consistent with the patent having issued over them.

Recommendations for a rigorous follow‑up: (1) retrieve and read the full disclosure of US 4,896,148 A (Minolta), which I could not verify; (2) confirm the exact page range of the Windows 2.0 User's Guide excerpt as cited on the patent face (pp. 6–7, 32–41, 54–55, 66–75, 96–103); and (3) review the EP 0537097 B1 / JP H0820939 B2 prosecution histories, which may contain examiner reasoning mapping these references to specific claims.

Note on identifiers: All patent numbers are reported exactly as they appear in the US 5,227,771 record; I have not normalized or "corrected" any of them. Where a source (e.g., a Unified Patents page) appeared to associate US 4,574,364 with a different title or a 2001 priority date, that is a data‑aggregator error and I have relied on the authoritative Google Patents/patent‑face data (Hitachi, Ltd.; priority 1982‑11‑23; grant 1986‑03‑04) instead.

I'll ground this analysis in the prior-art references listed on the patent page. Let me pull details on each cited reference.

Good detail so far. Let me gather the remaining references and the non-patent literature.

Obviousness Analysis — US 5,227,771 A

Patent: "Method and system for incrementally changing window size on a display" (IBM; inventors Linda L. Kerr and Robert J. Torres; filed 1991‑07‑10; granted 1993‑07‑13; expired 2011‑07‑10).
Source of record: https://patents.google.com/patent/[US5227771A](/patent/US5227771A)/en

Because the application's effective filing date is July 10, 1991, pre‑AIA 35 U.S.C. § 103(a) governs, and the Graham v. John Deere factors plus the KSR Int'l v. Teleflex rationales set the test. All five examiner‑cited U.S. patents and the Microsoft non‑patent literature predate the filing date and are available as § 102(b)/102(a) art.

---

1. The prior art of record (as listed on the patent page)

The patent's own Background expressly concedes the state of the art: maximize/minimize icons exist, and intermediate sizes require locating the cursor on a border "and then mov[ing] the cursor to the selected location while dragging the border along."

---

2. Mapping claims to elements

---

3. Combinations that would support a § 103 rejection

Combination A — Windows 2.0 User's Guide + US4831556 (primary).
Both are GUI window‑sizing arts. Windows 2.0 supplies the claimed two‑icon metaphor in the title bar (maximize/minimize boxes selected by pointer) and the mundane double‑click gesture as a distinct command. US4831556 supplies the missing piece: sizing in fixed increments from an on‑window icon rather than by dragging a border, with the icons repositioning on the window perimeter and the data inside the window being re‑rendered. A PHOSITA asked to eliminate the "clumsy" border‑drag tolerated by the Windows guide would predictably move the resize gesture onto the icon set already occupying the title/perimeter region — a substitution of one known input gesture for another to perform the same function (MPEP 2144.04 / KSR, "simple substitution of one known element for another"). The motivation is articulated by the inventor herself: eliminating pointer travel and making sizing "user friendly."

Combination B — US4831556 + US4574364 (+ Windows U.G.).
US4574364 shows that a window's width/height are stored as table values and can be changed by a designated amount and re‑displayed. Combining that data‑structure/redraw teaching with US4831556's icon‑initiated resize yields claim 1's steps (a)‑(g) except the "first vs. second selection" gesture mapping, which the Windows guide and common GUI practice supply. Post‑KSR, this is a "known technique applied to a known device ready for improvement" with a finite number of predictable implementations.

Combination C — US4831556 (or Windows U.G.) + US5001697 for claims 6, 10, 11, 13, 15‑17.
US5001697 already teaches the "press and hold to resize continuously" loop, re‑computing window size on the fly, checking that data fits, and restoring the pointer to its original relative location. Adding US4831556's icon‑anchored cursor and icon repositioning makes the "cursor remains attached to the selected icon" limitation a mere automation of pointer tracking — the reference literally performs the equivalent step ("Call REPLACE POINTER program"). Combination C is the strongest case for claims 10/13's dependents.

Combination D — US4890098 + US4574364 for the "new data" step.
Both teach determining and carrying forward the content that will occupy the resized window, which answers claim 1(f)/6(e)/10(e). Neither is needed to supply any distinct inventive concept — content re‑layout on resize was routine (also US5001697, "Shrink Data").

---

4. Motivation to combine (why a PHOSITA would do it)

1. Same field, same problem. All references address on‑screen window display/sizing (G06F 3/048 subclasses). KSR permits combination where the references are from the same field and address the same need.
2. Articulated design incentive. The patent's Background states the known drag method is "not very user friendly … somewhat clumsy" and that "there is no icon for incremental sizing" — the problem itself supplies the motivation and even names the solution (an icon).
3. Ergonomic / pointer‑travel incentive. Both US5001697 and US4831556 are about keeping the operator's hand on one control; eliminating repeated drags was a well‑known GUI design pressure.
4. Predictable result. Each reference already produces a different, known window state (incremental change vs. maximum icon state); juxtaposing the two on the same window produced nothing more than the expected combination of their known functions (KSR; MPEP 2144.04, "predictable variation").
5. Infrastructure already in place. US4574364's window table and US5001697's display buffers show the platform supported storing arbitrary window dimensions and re‑painting — no new hardware was required.

---

5. Where the obviousness case is genuinely weak (candor check)

Two limitations resisted the art of record, which is consistent with the claims having been allowed and with counterparts granting in EP (EP0537097B1), JP (JPH0820939B2) and DE (DE69226744T2):

• Claim 1 / claim 12 — "second selection of said enlarge icon … to a predetermined maximum size." No cited reference shows the same sizing icon accepting a second (e.g., double‑click) selection to jump to maximum/minimum while a first selection increments. The Windows guide shows maximize/minimize boxes with a single action; US4831556 shows icon‑initiated incremental resizing. Bridging these requires importing the single‑vs‑double‑click convention as a matter of common knowledge — a reasonable but not airtight obviousness argument, since the counter‑argument is that the guide already provided dedicated maximize/minimize boxes and therefore taught against burdening the new incremental icons with a dual role (i.e., no reason to duplicate a function that already had its own button).
• Claim 9 — sizing dialog with a miniature version of the window that previews the effect of entered increments. US4890098 and US4831556 teach rubber‑band/dotted‑outline previews of the window on the desktop, and US4574364 teaches keyboard entry of a size, but none combines a configuration dialog with a live miniature window. This is the best non‑obviousness argument for the patentee; it would likely be attacked as a mere design choice / predictable use of a known preview technique, but that attack is the least certain in this analysis.

Also note the claims contain apparent typographical defects that must be read literally per the identifiers as published: claim 12 recites a "second secretion of said enlarge icon," and claim 6 ends "…until said new window reaches said predetermined maximum size or said predetermined maximum size" (the second term appears intended as "minimum," but I have not auto‑corrected it).

---

6. Caveats on verified content

• I confirmed the disclosures of US4831556A, US4890098A, US4574364A and US5001697A from the sources retrieved (https://patents.google.com/patent/US4831556 ; https://patentimages.storage.googleapis.com/74/8b/38/8f777451adb541/US4890098.pdf ; https://uspto.report/patent/grant/[4,574,364](/patent/4574364) ; https://www.freepatentsonline.com/[5001697](/patent/5001697).html).
• I could not verify the specification content of US4896148A (Minolta) or US4692757A (Hitachi) in this session; my searches were cut off. I therefore do not rely on either for any essential limitation. Any assertion about them should be re‑checked before filing.
• US5001697A lists Robert J. Torres — a co‑inventor of US5227771 — as an inventor. It appears on the page under "Family Cites Families," not as an examiner citation. Under pre‑AIA § 102(e)/103(c), a reference whose inventive entity is not "another" (or that is commonly owned) may be disqualified or excepted; asserting it as prior art against US5227771 therefore carries a legal risk that should be flagged before use in a rejection. Likewise JPH01250129A is family‑cited rather than examiner‑cited.
• The Microsoft Windows User's Guide, v. 2.0 (1987) is listed on the patent page only as a citation (pp. 6‑7, 32‑41, 54‑55, 66‑75, 96‑103); I did not independently obtain the pages, so specific page‑level pin cites (e.g., for the maximize/minimize boxes) should be verified against the printed guide.

Bottom line: Claims 2‑8, 10, 11 and 13‑17 are, on this record, vulnerable to a § 103 rejection built on Windows 2.0 + US4831556, with US4890098/US4574364 supplying the "new data in the new window" and user‑selectable‑dimension elements and US5001697 supplying continuous "press‑and‑hold" resizing with pointer tracking. Independent claims 1 and 12 turn on the dual‑gesture (first vs. second selection) mapping to incremental vs. maximum size, and claim 9 on the miniature‑window increment dialog; those are the limitations for which the strongest non‑obviousness arguments exist.