US 5938732

I'll search for the patent and any litigation/docket activity, then summarize.

Let me check for litigation, PTAB, or CAFC activity specifically involving this patent.

US Patent 5,938,732 — Summary

Important framing / scope of what I could verify. I searched for this patent number specifically (USPTO/Google Patents data and general web sources, plus queries aimed at CAFC 2026 dockets and PTAB). I found no CAFC 2026 docket and no PTAB proceeding involving patent 5,938,732. Searches for "5938732" + litigation/CAFC returned only unrelated matters (Amazon/DivX, InterDigital, PersonalWeb, etc.) and general CAFC/IPR commentary. Given the patent's legal status (expired), the absence of a 2026 appeal is expected, but I want to be explicit: I have no authoritative evidence of any 2026 Federal Circuit docket for this patent, and I did not query PACER directly. Below, bibliographic facts come from the patent's own text as provided.

Bibliographic data

Note on assignee: the "current assignee" line reflects a recorded assignment from Sun Microsystems to Amazon Technologies, Inc. in 2009. Google Patents cautions that assignee listings are not a legal conclusion; I did not independently verify the chain of title.

Abstract (as issued)

"A system and method for many-to-many failover and load balancing establishes a plurality of service groups for providing desired computing services. Each service group comprises a plurality of hosts, and each host within the service group is available to perform the computing services for which that group as a whole is responsible. Each host may belong to a plurality of service groups. Each operational host within a service group transmits periodic messages to each other host within the service group advising of the status of the transmitting host. A leader host evaluates the periodic messages and, where appropriate, dynamically reassigns responsibility for particular computing services to a host within the group. The reassignment can be due either to failover or load balancing."

Technical overview (from the specification)

The invention manages IP address ownership inside a "service group" of hosts, rather than using classic one-to-one/many-to-one primary-backup failover. Key mechanics:

• Each host has a host id (control address) and a preferred service address; the group shares a service group address (typically an IP multicast address + port) used for periodic UDP "control/info" (heartbeat) messages.
• A dynamically elected leader (lowest host id in the described embodiment) tries to keep the group at equilibrium: all service addresses served, each served by only one host, and each host serving its preferred address. It issues acquire/release messages to correct deviations.
• Failure detection is timeout-based (silent host = presumed dead); the leader reassigns orphaned addresses. Failed hosts can be removed and new hosts added without reconfiguring the rest.
• Orphaned addresses get a leader-maintained countdown timer; when it expires the address is invalidated, and since the DNS zone only advertises preferred addresses of available members, the orphaned address "fades away."
• Load balancing uses utilization = load ÷ capacity compared against operator-set high/low water marks, with DNS zone modification (and a floor on the minimum number of service addresses advertised) plus round-robin DNS rotation.
• Additional features: hot spares (no preferred address, receive only orphaned addresses), quiescing (host may release but not acquire; excluded from DNS but keeps serving), and detection of total host failure vs. service failure.
• Implementation is a multi-threaded Service Monitor per service (Transmit, Receive, Scripts, Control, DNS threads) within a RAIS daemon; the co-pending applications incorporated by reference include U.S. 08/763,234 ("Method and Apparatus for Client-Sensitive Name Resolution Using DNS") and U.S. 08/673,951 ("A Service for a Redundant Array of Internet Servers").

Plain-language overview of the independent claims

Claim 1 — Computer program product (the "peer messaging / acquire-release" claim).
A computer-usable medium carrying program code that causes a computer to: (1) transmit a message, addressed to a service group address, stating that computer's state; (2) receive at least one such message, addressed to the service group address, from at least one other computer; and (3) act on a received message by acquiring or releasing computer services. In plain terms: software that lets cluster members broadcast their status to a common group address and then take or give up services based on what they receive.

Claim 4 — Method for dynamically reassigning computing services (the core method claim).
Steps: (1) establish a service group per computing service, with a unique IP address assigned to each of a plurality of host computers, so the service stays available as long as any one host in the group is up; (2) assign responsibility for the service to a first host in the group; (3) periodically transmit messages among group hosts via a service group address, indicating the state of at least the first host; (4) receive messages via the service group address from the remaining hosts indicating their states; (5) evaluate the presence/absence and contents of those messages; and (6) reassign responsibility for the computing service to another host in the group in response to that evaluation. In plain terms: a many-to-many failover method where heartbeat messages to a shared group address drive who serves the service.

Claim 7 — Apparatus (the "at least three hosts + leader" claim).
A system with: (a) a service group of at least three hosts, each able to provide the desired computing service, each with its own unique IP address, such that the service is available as long as one host is available; (b) a message portion that provides data, via a service group address, about the state of each host; and (c) a leader portion that assigns responsibility, through the service group address, for each computing service to any host in the group in response to the message portion. In plain terms: the same scheme embodied as hardware/software apparatus, with the notable claim limits that the group is three or more hosts and that a leader entity does the assigning.

Dependent claims (brief, for context)

• 2–3 (depend from 1): the acquire/release messages result from failure of another host (2) or from load balancing (3).
• 5–6 (from 4): reassignment caused by lack of a message (5) or by load balancing (6).
• 8 (from 4): the first host assigns responsibility for particular services to the other hosts.
• 9–11 (from 4): load shedding above a preset max utilization (9); load "gaining" by adding a host back to the DNS zone below a preset min (10); DNS zone modification load balancing using a minimum-number-of-addresses configuration parameter (11).
• 12–13 (from 4): maintaining hosts as hot spares (12); maintaining a host in a quiesced state (13).
• 14–15 (from 4): failure detection for total host failure (14) and for service failure (15).
• 16 (from 4): the hosts are a redundant array of independent servers (RAIS).

Literal-reading caution: Claim 8 is drafted as "The method of claim 4…" despite appearing to describe a host action, and claim 7 is captioned "Apparatus…" — both are reproduced here as written, without correction.

Uncertainty flags

1. No CAFC 2026 docket located for 5,938,732. I cannot confirm or deny a 2026 Federal Circuit filing; my searches returned nothing on point, and direct PACER/CAFC docket access was not available. Given the 1996 priority date and 2016 expiration, active 2026 appellate activity would be unusual.
2. No PTAB/litigation record found for this patent. Search results referencing Amazon litigation concerned different patents.
3. Assignee history is taken from the patent page's recorded-assignment entries (Sun Microsystems → Amazon Technologies, 2009); not independently verified against USPTO assignment records.
4. One search hit cited the Chinese-language publication CN1508682A, which discusses US 5938732 as background art — that is a citation, not evidence of litigation over the patent.

If you need a docket-level confirmation, the reliable next step is a direct PACER search (US District Court dockets) and the CAFC's docket system, plus the USPTO Patent Center/Assignment database for the exact number 5,938,732.

I'll search for litigation involving US patent 5938732.

Let me search more targeted litigation databases.

Litigation Search Results for US Patent 5,938,732

Bottom line: I found no evidence of any litigation involving US Patent 5,938,732 in the sources I was able to search.

Patent identification (to confirm the correct target)

Per the authoritative patent text for this ID:

What the searches returned (and why they do not constitute litigation)

1. Google Patents page for US5938732 — the "Cited By" section lists forward citations (e.g., US6078960, US6327622, US6587866, etc.), which are later patents, not litigation. Nothing on that page indicates an infringement or declaratory-judgment suit.
2. Foreign prior-art citations — e.g., Chinese application CN1508682A cites US 5,938,732 as background art, and PCT publication WO2002059750A3 lists it in a search-report table. These are patent-office citations, not cases.
3. Patent Leaderboard entry — lists the patent under inventor Swee Boon Lim with an estimated value ("$55,617,000"). This is a valuation estimate, not a lawsuit.
4. Unrelated false positives — several results matching the bare digits "5938732" are business-registry filings (Slovenian Uradni list, a Lithuanian registry notice) belonging to a cargo/logistics company. These have no connection to the patent.

No court docket, complaint, CAFC opinion, PTAB proceeding, or Unified Patents litigation entry referencing this patent appeared in the results.

Important caveats on my search

• I could not complete queries directly against the specific litigation databases you named (Unified Patents litigation portal, PACER, Docket Navigator), and my final round of targeted queries was cut off. So this should be treated as "none found," not a definitive "none exists."
• The ~2016 expiration date makes it unlikely that this patent is currently being asserted, and it is plausible it was never litigated — but I cannot confirm that from the sources retrieved.
• A few of the results were heavily truncated (including the tail of the Google Patents page), so a dedicated docket search is still advisable.

Recommended next steps to definitively confirm

Since I can't verify this with high confidence, I'd suggest a direct check of:

• Unified Patents litigation portal: https://portal.unifiedpatents.com/litigation/caselist (search patent number 5938732)
• PACER / CourtListener RECAP and Docket Navigator for district-court dockets naming Sun Microsystems Inc. or Amazon Technologies, Inc. as owner
• PTAB proceedings (IPR/PGR/CBM) — note the patent predates IPR availability and expired in 2016, so post-grant challenges are unlikely

I want to be explicit rather than fabricate: based on the available search results, I have no litigation to list for US 5,938,732. I cannot confirm plaintiff, defendant, jurisdiction, case number, filing date, or outcome for any case, because no such case surfaced.

I'll verify the structured data against public sources before writing anything up.

One more targeted pass to make sure nothing is hiding in the PTAB end-to-end systems.

Let me also check for non-AIA validity challenges (reexam), since those can matter to a defendant even though they aren't AIA trials.

Proceedings overview

Total AIA trial proceedings on US 5,938,732: zero. The USPTO Open Data Portal (ODP) structured feed returns no IPR, PGR, or CBM proceedings for this patent — no active trials, no claims invalidated, no claims sustained, no institution denials, no settlements on file. The bottom-line defensive posture this gives a defendant is the strongest available in the PTAB dimension: there is no AIA trial record to work from and no adverse claim-cancellation to exploit, but also no litigation-tested narrowing — the claims stand exactly as they issued on 1999-08-17, and the reason no IPR exists is the patent's age, not its strength. Web verification confirmed the ODP result: searches across PTAB E2E/PTACTS material, Federal Circuit opinions, and third-party patent sources surfaced no petition, no institution decision, no Final Written Decision, and no CAFC appeal naming this patent. The absence is consistent with — and better explained by — the fact that the patent expired on 2016-12-09 (§ 286 lookback from a hypothetical 2026 assertion reaches nothing), rather than by any adjudged merit.

No proceedings to enumerate

The required per-proceeding fields (type, filing date, status, judge panel, grounds, institution decision, FWD claim-level verdict, settlement, appeal, defensive value) cannot be populated because no proceeding number exists to attach them to. Per the operating rules, I will not invent one. Listing a fictional IPR2017-xxxxx with fabricated APJ names and claim outcomes would be the single most damaging thing this memo could do — it would put invented representations in front of a court.

For completeness, here is what the canonical structured data says verbatim, and how I verified it:

Why no AIA trial exists — statutory unavailability, not vindication

This is the part a defendant should actually take away, because the reason for the empty docket determines what it's worth:

1. PGR was never available. Post-grant review under § 321 applies only to patents with an effective filing date on or after 2013-03-16. This patent's effective filing date is 1996-12-09. PGR is categorically off the table — for anyone, forever.
2. CBM was never available. Under AIA § 18(d)(1), covered-business-method review required claims for "performing data processing or other operations used in the practice, administration, or management of a financial product or service." US 5,938,732 claims cluster service-address management, leader election, DNS zone modification, and load-shedding (claims 1–16) — it is a distributed-systems/cluster patent, not a financial-services patent. The CBM program also sunset for new petitions on 2020-09-16. Doubly unavailable.
3. IPR was available from 2012-09-16 to 2016-12-09 and nobody filed. IPR is available against pre-AIA patents, so a window existed. It was never used — plausibly because no assertion was ever made against it (see the litigation summary: no case found), so no defendant ever had the § 315(a)/(b) incentive or the litigation cost justification to petition. The 1996–1999 vintage also means the realistic prior-art universe is deep and largely accessible (e.g., the 1995 "One-IP" work by Damani et al. cited against the later Sun/EP family member EP 1 094 645), which cuts both ways: easy art to find, but no reason to pay to find it absent a demand letter.
4. Settled expectations now cut against any future challenge. Under the USPTO's 2025 interim discretionary-denial processes, a patent in force for many years creates settled expectations favoring denial, and a patent that has been expired for a decade weighs even more heavily. Any 2026-vintage petition would face a Director discretionary-denial regime stacked against it, on top of a merits posture where cancellation would yield the petitioner nothing.
5. Ex parte reexamination — non-AIA, but a defendant's other validity vehicle — likewise shows no trace. Searches for a reexamination certificate or proceeding control number tied to 5,938,732 returned nothing. (Caveat: the Sun/NetApp-era reexaminations that surface in search results — e.g., the Network Appliance Inc. v. Sun Microsystems Inc. stays in N.D. Cal. 2008 — concerned U.S. Patents '001, '211, and '292, which are different patents. Do not conflate those.) I could not complete a direct FOIA-style pull of every 90/xxxxxx control number, so treat this as "none found," not a certified negative.

Strategic summary

Claim status. All 16 claims of US 5,938,732 — claims 1–3 (computer program product, with 2–3 depending on 1), claims 4–6 (method with failover- and load-balancing-triggered reassignment), claims 7 (apparatus with a "service group including a plurality of at least three hosts," a message portion, and a leader portion), claims 8–15 (dependent method claims covering leader assignment, high/low water-mark load shedding and load gaining, DNS zone minimum-address parameters, hot spares, quiescing, and total-host/service failure detection), and claim 16 (dependent on the hosts being a redundant array of independent servers) — are UNTESTED. None is canceled. None has been adjudicated. There is no claim sheet to hand a court, and no SAS-style institution record, because no petition was ever filed. A defendant cannot say "the PTAB already killed claim 1" — because it didn't; nobody ever asked it to.

Estoppel landscape. 35 U.S.C. § 315(e)(2) estoppel arises only against a petitioner that obtained a Final Written Decision. No FWD exists, therefore no estoppel attaches to anyone. This is a genuine asymmetry that favors the challenger: there is no privity chain, no real-party-in-interest trap, no ground that was "raised or reasonably could have been raised" that is now closed off. Every prior-art ground — § 102 anticipation, § 103 obviousness, and even the § 112 written-description/enablement theories that the specification's pseudocode-heavy disclosure (the control-database nested loops and the DNS-thread pseudocode in FIGS. 6B–6C) might invite — remains fully available. The corollary is that a defendant also gets zero benefit from a prior petitioner's work product: no IPR record, no admitted art, no Board claim constructions to leverage.

Pattern signals. No repeat petitioner (there is no first petitioner). No Patent Owner § 141(c) appeal activity, because there was no adverse decision to appeal. No defensive aggregator in the chain — Unified Patents or any similar entity would leave a public docket trace, and none appears. The 2009-06-05 assignment from Sun Microsystems to Amazon Technologies, Inc. is a corporate portfolio transfer, not a litigation signal. The only "activity" the patent shows is forward citation volume (138 citing documents per the Google Patents page, e.g., US 6,078,960, US 6,327,622, US 6,587,866), which is evidence of technical influence in the cluster-load-balancing art — a real consideration if you are assessing invalidity risk from the family lineage — but is not evidence of enforcement.

Recommended next steps

• If you received a demand letter citing US 5,938,732, the correct PTAB-side response is not "file an IPR" — it is a standing/damages challenge. The patent expired 2016-12-09. Under 35 U.S.C. § 286, no damages are recoverable for infringement more than six years before the complaint is filed, so a suit filed today (2026-09-28) reaches no period of infringement at all. Confirm the expiration date against the USPTO Patent Center record for US 5,938,732 (https://patents.google.com/patent/US5938732/en and https://patentcenter.uspto.gov) and check for any terminal disclaimer, PTA/PTE, or maintenance-fee lapse that could shift the date — the authoritative text shows "Anticipated expiration 2016-12-09" and no fee-related lapse, but verify the certificate of the last maintenance fee payment independently.
• If the patent is somehow still being pressed despite expiration, an IPR remains legally possible but is very likely to be discretionarily denied under the USPTO's 2025 interim processes (settled expectations of a decades-old, long-expired patent). Do not budget for an IPR as your primary defense; budget for a Rule 12 motion.
• Because no proceeding exists, there is no FWD to link to and no Board disposition to quote. The accurate citation for the negative is the USPTO's PTAB proceeding search (https://developer.uspto.gov/ptab-web/#/search/decisions and PTAB E2E via https://ptacts.uspto.gov/ptacts/) plus the ODP structured record. Flag this absence expressly in any invalidity contentions so opposing counsel cannot later characterize the empty docket as an oversight.
• Re-verify before filing. I could not query PTACTS or PACER directly, and one search returned truncated docket material. Two things would change this memo materially and must be re-checked once more at filing time: (a) any petition filed near the 2016 expiration that ODP has not ingested, and (b) any ex parte reexamination (90/xxxxxx) request that would have left a certificate altering claim scope. Neither surfaced in my searches; both should be confirmed against the official records rather than assumed.

I'll research the assignment record for US 5,938,732, starting with the authoritative legal events I already have and then verifying reel/frame details.

Let me dig deeper on the specific assignment records and the Sun→Amazon transfer.

Let me search for the specific Amazon assignment record and the inventors' backgrounds.

I've hit my search budget. Here is my reconstruction, grounded in the authoritative patent text and Google Patents legal-events data I have, with explicit gaps flagged rather than filled by inference.

Assignment Record Reconstruction — US 5,938,732

Confidence note up front: The authoritative patent text provides three Google Patents "legal events" for this patent, one of which cites a reel/frame (8464/0013). I could not retrieve the full USPTO Assignment Center abstract-of-title page, so the correspondent of record and the executed dates are not in hand for any link, and the reel/frame for the 2009 Amazon recording is unknown. I state those as gaps rather than guess.

Inventors

Pattern observations:

• All three inventors assigned to the employer of record (Sun Microsystems) via a recorded assignment dated/recorded 1997-04-21, i.e., this is a standard employee-invention assignment to the employer, not a founder-to-startup chain.
• The application was filed as part of a same-day cluster of at least nine related Sun applications (all dated Dec 9, 1996 per the "Related Applications" section: Ser. Nos. 08/763,234; 08/762,393; 08/762,402; 08/763,068; 08/762,212; 08/762,709; 08/762,933; 08/762,705; 08/673,951). This is a large-operating-company portfolio-construction pattern (RAIS = "Redundant Array of Independent Servers"), which is the opposite of the "all inventors depart within 12 months / fire-sale" tell.
• Departure timing: not determinable from available sources. I found no evidence in the retrieved material about whether any inventor left Sun within 12 months of filing, and I will not assert it.

Original assignee

• Entity on the issued patent: Sun Microsystems, Inc. (Delaware; Mountain View, CA).
• Line of business: Enterprise computer hardware, workstations/servers, Solaris, Java. The claimed subject matter (load balancing and failover of network services across a group of hosts) was a core commercial product line — Sun's clustered/HA server offerings.
• Did Sun ship a product embodying the claims? Yes, in substance. The patent describes the "RAIS daemon" (FIG. 1A) as software running on Sun hosts; the specification expressly frames the invention as operating on a "Redundant Array of Independent Servers, or RAIS," and the companion application Ser. No. 08/673,951 is titled "A Service for a Redundant Array of Internet Servers." This is product-facing architecture, not a paper patent.
• Current status: No longer independent. Oracle announced its acquisition of Sun on 2009-04-20 and completed it 2010-01-27. Sun did not file bankruptcy (it was acquired as a going concern), so the "bankruptcy fire-sale" archetype does not apply to Sun here.

Assignment timeline

Chronological. All dates below are recording dates as exposed by the patent's legal-events data unless stated otherwise.

• Recorded 1997-04-21 — Reel 8464/0013 (this reel/frame is referenced by the later corrective entry; I could not independently view the record itself)

  • Conveyance: Assignment (assignment of interest)
  • Assignor: LIM, SWEE BOON; RADIA, SANJAY R.; SINGHAI, ASHISH
  • Assignee: SUN MICROSYSTEMS, INC.
  • Correspondent: not retrieved (the fetched record does not include the correspondent block for this entry). Cannot state whether this correspondent recurs elsewhere in the chain.
  • Context: Original employee-invention assignment to the employer — routine, pre-product-launch, no NPE characteristics.

• Recorded 1997-06-30 — Reel/frame: correction to the entry previously recorded at Reel 8464/0013 (the new reel/frame is not given in the fetched data)

  • Conveyance: Correction / re-record (a re-recording of the same assignment)
  • Assignor: LIM, SWEE BOON; SINGHAI, ASHISH; RADIA, SANJAY R.
  • Assignee: SUN MICROSYSTEMS, INC.
  • Correspondent: not retrieved.
  • Context: Administrative correction only — per the record, it re-records to "correct the filing receipt date from 12-11-96 to 12-09-96." This is a housekeeping fix, not a change in ownership. Flag: it is a same-assignee/same-assignee re-record ~10 weeks after the original, so it is not a cascading transfer.

• Recorded 2009-06-05 — Reel/frame NOT RETRIEVED

  • Conveyance: Assignment ("reassignment" in Google Patents' labeling)
  • Assignor: SUN MICROSYSTEMS, INC.
  • Assignee: AMAZON TECHNOLOGIES, INC.
  • Correspondent: not retrieved. Cannot state, and will not infer, who filed this recording.
  • Context: Transfer to an operating company's IP-holding subsidiary. Not a transfer to a licensing-only shell on the face of the record.

Anomaly I want to flag rather than paper over: the Amazon recording is dated 2009-06-05, which falls after Oracle's acquisition of Sun was announced (2009-04-20) but before it closed (2010-01-27). A transfer of a Sun patent to Amazon in that window is not the standard Sun→Oracle flow, and I could not confirm the mechanism (independent pre-closing sale, a carve-out, a cross-license-related recordation, or a recording artifact). Per my operating rules I am reporting the record literally and not auto-correcting or theorizing it into a merger transfer.

If the Assignment Center returns no additional records beyond the above, that does not change the analysis — the chain is short and terminates at Amazon Technologies.

Timeline diagram

timeline
    title Ownership of US 5938732
    1996 : Application filed by Sun Microsystems
    1997 : Assignment recorded to Sun Microsystems
         : Correction refiled to fix filing date
    1999 : Patent issued to Sun Microsystems
    2009 : Assigned to Amazon Technologies
    2016 : Patent expired

NPE / troll-pattern signals

Verdict

Insufficient data — and specifically, no evidence of an NPE pattern.

Justification: The entire recorded ownership chain is operating-company to operating-company: inventors → Sun Microsystems (reel 8464/0013, recorded 1997-04-21; corrected 1997-06-30) → Amazon Technologies, Inc. (recorded 2009-06-05). Signals 1, 2, 4, 6, 7, and 8 are affirmatively not present, and signal 3 is simply unretrieved, not adverse. I decline to enter "Operating-company assertion" because that category requires an active suit against competitors and none is documented; I decline "Defensive / non-asserting" because the chain does not terminate at a defensive aggregator; and I decline any NPE category because there is no shell transfer and no known asserter on the record. The controlling defect in my dataset is the missing Assignment Center abstract-of-title page (correspondent and executed dates, plus the 2009 reel/frame), which is why the call is "insufficient data" rather than a clean "not an NPE."

Verification link (USPTO Assignment Center): https://assignmentcenter.uspto.gov/ — search patent number 5938732 (alternate index: https://assignment.uspto.gov/patent/index.html). To close the remaining gap, pull the abstract of title for reel 8464/0013 and the 2009-06-05 Amazon recording, and capture the correspondent of record for both.

Two things a follow-up should nail down:

1. The correspondent on the 2009-06-05 Amazon recording — the single most diagnostic field still missing.
2. The executed (not just recorded) date of the Sun→Amazon transfer, to test whether the 2009-06-05 recording sits inside the Oracle pre-closing window as a standalone sale.

I'll search for the USPTO record and the prior-art references cited against US 5,938,732.

The full text I was given omits the front-page "References Cited" list, so let me locate the examiner-cited prior art directly.

Let me try dedicated patent databases that expose the front-page citation list.

Scope note — what I could and could not verify

I attempted to pull the USPTO/Google Patents front-page "References Cited" (U.S. Patent Documents) list for US 5,938,732 directly. I could not retrieve that specific examiner-cited list in this session. Two concrete reasons:

1. The authoritative full text you supplied for US5938732A omits the front-page citation block entirely — it runs Abstract → Description → Cited By, with no "References Cited" section. (The Google Patents page for this record renders no "Patent Citations" table in the text captured.)
2. My searches for "US5938732" + References Cited, freepatentsonline 5938732 references cited, and justia 5938732 returned either (a) forward citations ("Cited By"), which are not prior art, or (b) citations belonging to other patents (e.g., the "Patent Citations (25)" block I saw belongs to US6735206, not to 5938732).

I will not fabricate the front-page list. What follows separates (A) prior art I can ground in retrieved documents, (B) the patent's own incorporated references, and (C) what is not prior art.

1. Confirmed identification (from the authoritative text)

Because this is a pre-AIA patent (filed 1996), pre-AIA 35 U.S.C. § 102 applies. The critical § 102(b) bar date is 1995-12-09.

2. Prior art grounded in retrieved documents

A. References cited in the European family member (EP 0 978 184 B1) — the closest grounded proxy

EP0978184B1 is the same invention (same priority, same family). Its background/description expressly discusses specific prior documents. These are the references the family itself treated as relevant art (albeit in an EPC Article 54(3)/background context, not a US examiner's § 102 rejection). I retrieved these from the EP0978184B1 PDF:

A1. EP-A-817020 — name service for a redundant array of Internet servers

• Citation: EP 0 817 020 A ("co-pending application relevant only under Article 54(3) EPC"); the US counterpart is US 08/673,951, filed 1996-07-01 ("A Service for a Redundant Array of Internet Servers," Swee Boon Lim).
• Date: US filing 1996-07-01; EP publication 1998-01-21.
• Description: "The workload is distributed among the available servers in the system. A service monitor for each host system periodically broadcasts information about available servers and the workload of the host. The information is received by a name service and used to assist with load balancing."
• Potential § 102 mapping: § 102(e) (U.S. application filed by another before the applicant's date of invention — here filed 1996-07-01, ~5 months before 08/763,289). Also potentially § 102(a)/(g). Maps to claim 1 (periodic broadcast message re: state of a host), claim 4 (periodic messages; reassignment; load balancing), claim 7 (message portion + assignment), and the load-balancing dependents claims 3, 6, 9, 10, 11. Caveat: same-inventor / commonly-owned subject matter can trigger the pre-AIA § 103(c) carve-out (affecting obviousness combinations, not 102 novelty).

A2. EP-A-384339 — broker for computer network selection

• Date: published 1990-08-29.
• Description: "The broker mechanism allocates a plurality of servers, each having an available resource capacity, to a plurality of clients… The broker operates by monitoring a subset of all available servers capable of delivering the requested service… and based on a network policy and the available resource capability suggests one of the servers."
• Potential § 102 mapping: § 102(b) (published >1 year before 1996-12-09). Maps to claim 7 ("leader portion … assign responsibility … for each of the computing services"), claim 8, and load/capacity-based dependents claims 6, 9. This is the strongest single-document candidate for the leader/broker-assigns-service-by-capacity concept.

B. Non-patent literature cited in the EP family background

B1. Ji Hua Xie Li, "A Distributed Computing Model Based on Multiserver," Operating Systems Review (SIGOPS), v.30, n.4, Oct. 1996, pp. 3–11.

• Description: "A distributed system in which many resources coexist in the network. A multiserver system… needs to be transparent and fault tolerant. A service manager is used to provide dynamic binding between clients and servers."
• Potential § 102 mapping: § 102(a) (printed publication before the applicant's invention; not old enough for § 102(b), which would require pre-1995-12-09). Maps to claim 1 and claim 4 (plural hosts, fault-tolerant service, message-driven binding).

B2. R. Adler, "Distributed Coordination Models for Client/Server Computing," Computer, v.28, n.4, Apr. 1995, pp. 14–22.

• Description: coordination model for a distributed system; "a request broker… mediate[s] interactions between client applications and server applications. There may be multiple servers for a given service, for example to increase availability."
• Potential § 102 mapping: § 102(b) (published Apr. 1995, >1 year pre-filing). Maps to claim 4 and claim 7 (multiple hosts per service for availability).

B3. "Local Area Network Server Replacement Procedure," IBM Technical Disclosure Bulletin, v.38, n.1, Jan. 1995, pp. 235–236.

• Description: "a series of LAN client machines can dynamically switch from one LAN server to another (e.g. when the original LAN server is taken down for maintenance)."
• Potential § 102 mapping: § 102(b). Maps to the failover subject matter of claims 2, 5, 14 (reassignment due to a host going down).

C. Specifications expressly cited inside US5938732 itself

The patent's own description states: "Domain Name Zones are also discussed at length on the Internet RFC pages 1034 and 1035."

• Citation: P. Mockapetris, RFC 1034 ("Domain Names — Concepts and Facilities") and RFC 1035 ("Domain Names — Implementation and Specification"), Nov. 1987.
• Potential § 102 mapping: § 102(b) (1987, long pre-bar). Relevant to the DNS-zone-dependent claims 10 (adding host to DNS zone) and 11 (minimum number of service addresses in a DNS zone) — these RFCs disclose DNS zone structure, though not load-balancing use of it.

3. The patent's own "Related Applications" — status under § 102

US5938732 lists nine applications filed the same day (1996-12-09) (08/763,234; 08/762,393; 08/762,402; 08/763,068; 08/762,212; 08/762,709; 08/762,933; 08/762,705) plus 08/673,951, filed 1996-07-01.

• The same-day filings are not § 102(a) prior art (a reference cannot be "by another … before the invention thereof" if filed the same day). They are at most § 102(e) candidates only if they qualify as "by another," which commonly-owned same-day filings typically do not.
• 08/673,951 (filed 1996-07-01) is the one genuinely pre-dating item and is the U.S. counterpart of EP-A-817020 discussed in § A1 above — treat it as a § 102(e) reference.

4. What is NOT prior art (important disambiguation)

The "Cited By (138)" list on the patent record (US6078960, US6327622, US6587866, US6092178, etc.) consists of later patents that cite US5938732 — forward citations. They post-date 1999 and therefore cannot anticipate or render obvious US5938732. Do not treat them as § 102 art.

Likewise, the foreign documents I found (e.g., CN1508682A citing US5938732 as background; PCT/SE01/02877 and PCT/US03/37839 search reports listing it) are citations to the patent, not prior art against it.

5. Confidence and recommended next steps

• High confidence: bibliographic data, claim set, and the EP0978184B1-cited references (A1–B3) — all grounded in retrieved documents and the authoritative text.
• Low/insufficient confidence: the exact examiner-cited U.S. Patent Documents printed on the US5938732 front page (§ 102 references such as specific US patents from IBM/Oracle/etc.). I could not retrieve that list, and the authoritative text you supplied omits it. I am not asserting any US patent number as a front-page citation of 5938732, because I could not verify one.

To close that gap definitively, the reliable sources are:

1. USPTO Patent Center / Patent Public Search — the full-text "References Cited" for 5,938,732 (and the IFW "List of References Cited by Examiner").
2. The granted patent PDF front page (US5938732A PDF), which prints the U.S. Patent Documents / Foreign Patent Documents / Other Publications blocks.
3. Espacenet / Global Dossier for the EP0978184B1 search report and its US-family equivalents.

If you can supply the PDF front page or permit a direct fetch of the USPTO full-text page, I will produce the complete per-reference table (citation, date, description, and claim-by-claim § 102 mapping) for the actual examiner-cited art, rather than the EP-family proxy above.

I'll start by trying to retrieve the actual prior-art references of record for this patent, since the text provided to me includes a "Cited By" (forward-citation) list but not a "References Cited" list.

The prior-art list on the Google Patents page wasn't in the provided text. Let me try to pull the actual "References Cited" record.

Let me try to locate the family's search-report prior art (EP/WO counterpart often lists the references of record).

Obviousness Analysis — US 5,938,732 Under 35 U.S.C. § 103

0. Scope and a required correction about the "Prior Art section"

Before the analysis, one factual correction that materially affects how I can ground it:

The patent page supplied to me contains three things that could loosely be called "prior art," and they are not equivalent:

The authoritative text I was given is cut off inside the "Cited By" table (US6807580B2 … 2000‑05‑08 2004‑), and no "References Cited" (backward-citation) listing for US 5,938,732 appears in it. I also attempted to retrieve that list from Google Patents, Espacenet/EPO Global Patent Index, and the WO/EP family search reports; I could not obtain the examiner's cited references for US 5,938,732 itself. I will therefore not invent one.

What I can ground the analysis on is the following, all of which is in the record before me:

1. Admitted prior art in the specification's own Background (one-to-one failover, symmetric one-to-one failover, many-to-one failover) — an applicant's own characterization of the prior art is a binding admission.
2. Art cited on the face of the specification: Internet RFCs 1034 and 1035 (Domain Name concepts).
3. References with pre‑1996‑12‑09 priority that appear in the page's own "Cited By" table — chiefly US 6,101,542 A (priority 1996‑07‑19) and US 6,178,444 B1 (priority 1996‑03‑11).
4. Generally known contemporaneous art, which I flag as reconstruction/judgment rather than record evidence.

Everything below carries an explicit confidence marker.

1. Governing law, effective date, and the POSITA

Effective date. Application 08/763,289 was filed 1996‑12‑09 with no earlier priority claim (PCT/US1997/022117 and EP 97952269 claim priority from it). So the critical date is 9 December 1996, and pre‑AIA § 103(a) applies: the inquiry is whether the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art. (Today's application would still be judged under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), whose "predictable variations / known-technique" logic is what I apply below. Note also that the patent expired 2016‑12‑09, so this is a retrospective/hypothetical validity analysis — consistent with the prior sections, which found no litigation and no PTAB proceeding.)

POSITA (high confidence this is the right level). As of December 1996: a person with a bachelor's degree in computer science or electrical engineering and roughly 3–5 years of experience in distributed systems and TCP/IP network server administration, familiar with: UNIX daemons and sockets, UDP/IP multicast, DNS (RFCs 1034/1035), server "farms," keep‑alive/heartbeat failure detection, group communication and leader-election concepts from the distributed-systems literature, and basic load-balancing techniques.

The claim set (literal, as issued). 16 claims; independents are claim 1 (computer program product), claim 4 (method), and claim 7 (apparatus). I reproduce the key limitations exactly and do not correct the drafting anomalies in claims 7 and 8 (claim 7 is captioned "Apparatus" yet begins "Apparatus for providing…"; claim 8 is captioned "The method of claim 4…" but recites an action of the first host).

2. Prior-art inventory (with provenance and confidence)

Caution on § 102(e) status. US 6,101,542 and US 6,178,444 qualify as prior art only if their U.S. filing date (or qualifying international filing date) pre-dates 9 Dec 1996. Foreign priority alone does not establish a § 102(e) date for a pre-AIA reference. The page gives me priority dates, not filing receipts. Treat these as "apparent § 102(e) art pending verification."

Co-pending applications are NOT prior art. The nine applications incorporated by reference (Ser. Nos. 08/763,234; 08/762,393; 08/762,402; 08/763,068; 08/762,212; 08/762,709; 08/762,933; 08/762,705, all filed 1996‑12‑09; and 08/673,951, filed 1996‑07‑01) are same-day or commonly-owned filings. The 1996‑07‑01 filing could in principle be § 102(e) art, but pre‑AIA § 103(c) commonly-owned-subject-matter disqualification and the joint-research-agreement exception would need to be worked through. I flag this as a known interaction I have not resolved.

3. Independent claim 4 — element-by-element mapping

Claim 4 is the analytical center of gravity; claims 1 and 7 largely restate it in other statutory categories plus the "leader" and "at least three hosts" constraints.

Assessment for claim 4. Every limitation is met by admitted art A or C with the ordinary cluster/multicast/heartbeat toolkit. The only genuine delta over the admitted art is degree: A/B/C tolerate one failure; claim 4 tolerates failure of any host so long as one remains (N‑of‑M). That is a predictable extension of symmetric one-to-one failover (admitted art B) to N hosts, not a new mechanism.

4. Combination grounds

Ground 1 — Admitted art B/C + group-address heartbeat messaging + RFC 1034/1035 → claims 1, 4, 5, 7, 14

Combination: many-to-one (or symmetric one-to-one) failover in view of a periodic group-addressed status/heartbeat message with timeout-based membership, and in view of DNS zone management for addressing services.

Motivation:

• The specification itself supplies the motivation: it states the admitted schemes are "limited in that the networks are reliable only as long as only one system fails" and that prior art "do[es] not allow for good failover scaleability because the secondary system typically must be identified at initial configuration and cannot thereafter be changed." A known deficiency in the art, stated by the applicant, is itself the strongest motivation to improve it.
• Symmetric one-to-one (admitted art B) already generalizes to "each host can serve the other's services"; extending pairwise symmetry to an N-member group is arithmetic, not inventive.
• Group-addressed periodic status messages were the standard building block for exactly this problem (membership + failure detection); selecting a single multicast group address per service group is a routine addressing design choice.
• Expectation of success: high — each ingredient was independently proven; their combination yields no unpredictable result.

Ground 2 — US 5,774,660 (Resonate) + US 5,991,809 (Clearway) + RFC 1794/1034 → claims 3, 6, 9, 10, 11

Combination: a multi-node web-serving system that distributes client requests across nodes (US 5,774,660; US 5,991,809) in view of DNS-based load distribution (RFC 1794; RFC 1034/1035) in view of the admitted failover art, the failover art supplying the "reassign on host loss" leg.

Motivation:

• Both references are squarely in the December-1996 "scale the web server horizontally" problem space; combining load distribution with failover is the archetypal design goal (the sole purpose of the combination is to keep the service up and spread).
• DNS round-robin/rotation is the cheapest possible load-distribution mechanism and was known; using a min-floor on published address records (claim 11) is a routine guard against removing all records.

Ground 3 — US 6,178,444 (ordered messaging) and/or US 6,101,542 (service management) + Ground 1 → claims 1, 4, 14, 15

Combination: reliable/ordered state messaging (US 6,178,444) or service-keyed network management (US 6,101,542) in view of the admitted failover schemes.

Motivation: if one relies on period messages to decide who owns a service (Ground 1), a POSITA would obviously reach for known techniques to keep those messages coherent/ordered and to key state to service identity — a predictable improvement, no new result.

Ground 4 — Ground 1 + leader/coordinator election (e.g., Garcia-Molina 1982) → claim 7

Combination: the Ground 1 system, with one member elected to assign service ownership ("leader portion").

Motivation: the specification itself identifies the problem the leader solves — avoiding two hosts serving the same service address ("that each service address is assigned to only one host"). Duplicate ownership is a classic split-brain problem with a classic known solution (elect a single coordinator). The claim's "leader portion configured to assign responsibility through a service group address" is a mere implementation choice of the known leader pattern. "At least three hosts" adds no technical significance — three is the minimum size at which a group can survive a loss with two remaining, i.e., an obvious sizing of the admitted schemes.

5. Dependent-claim analysis

6. Where an infringement/validity challenger should expect pushback

Being candid about the weak points of the obviousness case matters more than maximizing the number of grounds:

1. Claims 11 and 15 are the survivors. Claim 11's "minimum number of available service addresses that must be present in the DNS zone" is a specific, non-generic configuration parameter, and I have no verified reference disclosing it. Claim 15's service-level (as opposed to host-level) failure detection with voluntary release is a meaningful distinction from mere heartbeat timeouts. If someone is attacking this patent, these are the claims to expect to persist (or to need a targeted secondary reference for).
2. The unclaimed mechanisms cannot save the patent. The most technically distinctive parts of the disclosure — orphaned-address countdown-timer invalidation, weighted utilization with a Δ hysteresis band, and the DNS "minimum addresses" floor logic in the DNS thread pseudocode — are largely not claimed. Under § 103 the analysis is confined to the claims. Practitioners should not expect the orphan-aging mechanism to rescue, e.g., claim 4.
3. "Teaching away" is the applicant's best, but weak, argument. The specification's own statement that the prior art "is limited in that the networks are reliable only as long as only one system fails" could be recast as a teaching away from many-to-many. It is not: a statement of a limitation is not a teaching away; that limitation supplies the motivation to combine (see KSR, 550 U.S. at 421, on design incentives arising from known needs).
4. The "service group address" is the most arguable claim element. Claim 1/4/7 all hinge on messages "through a service group address." One could argue that using a single address for both group control and service addressing is a specific design choice. It does not withstand scrutiny well — IP multicast group addressing was standard for this purpose — but it is the limitation to brief if a response is needed.
5. Drafting anomalies matter for literal infringement, not for validity. Claim 7's "Apparatus…" caption with "configured to" language and claim 8's odd "The method of claim 4…" recitation are reproduced as written; I have not corrected them. They don't change the § 103 analysis but they do affect how a court would construe the claims.

7. Secondary considerations

I have no evidence of record on secondary considerations (long-felt need, unexpected results, commercial success, failure of others, licensing). Two observations:

• The patent is expired (2016‑12‑09) and, per the prior sections of this analysis, not the subject of any identified litigation or PTAB proceeding, so no real-world validity record exists to cite.
• The one valuation datapoint I encountered (Patent Leaderboard's ~$55.6M estimate for this patent) is a modeling output, not evidence of nexus between any commercial product and the claims, and would be irrelevant to § 103 absent a proven nexus to a specific product practicing the claimed subject matter.

8. Bottom line

High confidence. On the material available to me, independent claims 1, 4, and 7 — and dependent claims 2, 3, 5, 6, 8, 9, 10, 12, 13, 14, 16 — would more likely than not be held obvious under pre-AIA § 103 over the combination of (i) the failover schemes the applicant itself admits in the Background, (ii) group-addressed periodic heartbeat messaging with timeout-based failure detection, and (iii) known DNS/load-distribution techniques (RFC 1034/1035; and, if verified, RFC 1794 and the 1996-era load-balancing references such as US 5,774,660 and US 5,991,809). The motivation to combine is supplied by the applicant's own recitation of the prior art's shortcomings and by the then-prevailing market need for horizontally scalable, highly available web serving.

Moderate confidence, and where the case is weakest. Claims 11 and 15 are the specific limitations most likely to survive: I have no verified reference disclosing (a) a DNS-zone configuration parameter imposing a minimum number of published service addresses, or (b) service-level (as distinct from host-level) failure detection triggering voluntary address release. Anyone advancing this obviousness theory should obtain secondary art aimed directly at those two limitations.

Uncertainty flags (please do not treat the above as a defect record):

1. I could not retrieve the actual "References Cited" list for US 5,938,732. My analysis is built on the specification's admitted prior art, on the specification's own RFC citations, and on the pre‑1996‑12‑09 subset of the page's "Cited By" table. The genuine examiner-cited art may be broader or narrower than what I used.
2. US 6,101,542 and US 6,178,444 are "apparent" § 102(e) art only. I have their priority dates from the page's table, not their U.S. filing dates or disclosure content. Both need verification before being relied upon.
3. US 5,774,660 and US 5,991,809 appear in Google Patents citation tables for a different Sun patent (US 6,327,622), not demonstrably on US 5,938,732's own face; treat them as candidate art, not as part of this patent's record.
4. RFC 1794 and Garcia-Molina (1982) are cited from my own knowledge of the literature, not from the supplied page. Existence and dates are, I believe, correct; verify before filing.
5. Identifiers reproduced literally: US 5,938,732; US5938732A; 08/763,289; PCT/US1997/022117; WO1998026553A1; EP0978184B1; JP4087903B2; DE69738257D1. Where the supplied page rendered a family title garbled ("LASTEUS COMPENSATION AND TRANSFER OF NETWORK SERVICES"), I have not corrected it.
6. No contradiction with the prior sections. The earlier summary and litigation sections found no litigation and no PTAB activity; nothing I found in this pass contradicts that.