US 10116738

Search Results Summary

I searched the USPTO and CAFC materials for the literal patent number 10116738.

• USPTO search: The only USPTO hit was an unrelated PTAB/BPAI appeal decision (Appeal 2018-006191, Application 15/167,238 — note this is a different number; do not confuse it with patent 10116738). No USPTO record for patent 10116738 itself was returned in the search snippets, but the bibliographic data below is corroborated by multiple independent sources.
• CAFC 2026 docket search: No results. I found no CAFC docket or litigation entry for patent 10116738 in the 2026 docket materials searched. I cannot confirm any pending CAFC case involving this patent.
• The authoritative full-text record was provided in your message (Google Patents, fetched 2026-08-26), and I rely on it as primary ground truth.

Patent Summary — US 10,116,738 B2 (US10116738B2)

Continuation chain: This patent is a continuation of US 11/932,162 (filed Oct. 31, 2007), which is a continuation of US 10/259,497 (filed Sep. 30, 2002; granted as US 7,822,871), which claims priority to Provisional 60/325,177 (Sep. 28, 2001). The family originated from the Savvis/Digital Island "Adaptive Traffic Control (ATC)" global DNS traffic-management system.

Abstract (verbatim):

"A method includes monitoring the operational status of at least some name servers in a name server network. Based on the monitoring, when an error or anomalous condition is detected at a particular name server, creating a policy to indicate the status of the particular name server. The policy is taken into account when resolving hostnames using the name server network."

Overview of the invention: The patent is drawn to an adaptive, policy-driven DNS (domain name service) traffic-management framework. Name servers in a network resolve hostnames to server IP addresses based on stored "ATC policies" (geo-political, load-share, failover, tiered-failover, shedding, regulatory, and CIDR-block policies). Servers are classified as static, monitored, managed, or overflow, and name-server/network monitoring mechanisms detect anomalies, update local policies (e.g., marking a server unavailable or adjusting load share), and feed event logs to an administrative master agent that consolidates traps, generates alerts, and broadcasts updated policies back to the name-server network. The specific claim focus of this continuation is detecting anomalous/error conditions at name servers themselves and creating policies reflecting that name-server status for use in hostname resolution.

Independent Claims — Plain-Language Overview (with caveat)

Important caveat: The Google Patents fetch you provided includes the abstract, description, and drawings listing but does not include the claims text, and my searches did not return the full claim language. I therefore cannot quote the independent claims verbatim with high confidence. Based on the abstract and specification, the independent claims are method-oriented and appear to cover, in substance:

1. Method claim (matching the abstract): A method of monitoring the operational status of at least some name servers in a name server network; upon detecting an error or anomalous condition at a particular name server (based on that monitoring), creating a policy that indicates the status of that particular name server; and then taking that policy into account when resolving hostnames using the name server network. In plain language: the DNS system watches its own name servers, and when one misbehaves, it writes a rule reflecting that server's bad state, and that rule influences which name server handles future hostname-resolution requests.

2. Likely additional independent claims: The family's prosecution style typically includes independent system and/or computer-readable-medium claims mirroring the method (a name-server network configured to perform the monitoring, policy creation, and policy-aware resolution). I cannot verify the exact number or wording of independent claims (e.g., whether there are 2 or 3) without the claim text.

Uncertainty statement: I have high confidence in the title, inventors, assignee history, filing/issue dates, priority chain, abstract, and legal status (all corroborated by the provided Google Patents record and search hits from golden.com, FreePatentsOnline, patentleaderboard.com, and uspto.report). I have low-to-moderate confidence in the specific independent claim set, because the claims section was not retrieved; the overview above is inferred from the abstract and specification and should be verified against the USPTO full-text or Patent Center record before being relied upon in any substantive analysis.

Key sources:

• https://patents.google.com/patent/US10116738/en (authoritative record provided in your message)
• https://uspto.report/patent/grant/10,116,738
• https://patents.google.com/patent/US20160255146 (pre-grant publication)
• https://wiki.golden.com/wiki/US_Patent_10116738_Detecting_anomalous_conditions_in_a_name_server_network-K3AWDNM

Based on my searches, here is what I can report regarding litigation involving US Patent 10116738 ("Detecting anomalous conditions in a name server network"):

Direct Litigation Search Results

I performed multiple targeted searches for the specific patent number 10116738 (and variations such as "10,116,738") in connection with litigation terms (litigation, lawsuit, complaint, defendant, Sandpiper). No case was found in which US 10116738 is explicitly identified as an asserted patent. Search results returned only:

• Patent database entries (Google Patents, USPTO.report, Justia, PatentLeaderboard, Golden wiki) confirming the patent's metadata.
• No PACER, CourtListener, Unified Patents, or CAFC docket entries that specifically name 10116738 as an asserted patent.

Potentially Related Case (Unverified Patent List)

One search result surfaced an active case brought by the patent's current assignee:

• Sandpiper CDN, LLC v. Microsoft Corporation
  • Jurisdiction: U.S. District Court, Eastern District of Texas (Marshall Division)
  • Case No.: 2:25-cv-00664-JRG-RSP
  • Amended Complaint filed: October 30, 2025
  • Plaintiff: Sandpiper CDN, LLC (the assignee of record for US 10116738 since April 26, 2024)
  • Defendant: Microsoft Corporation

Important caveat: The search snippet confirms this case involves CDN-related patents (the amended complaint discusses content delivery network technology and "Asserted Patents"), but I was unable to verify from the available snippet that US 10116738 is among the patents asserted in that case. The specific asserted patent list would need to be confirmed from the complaint itself on PACER/ECF or CourtListener. I cannot confirm this case involves 10116738 without that verification.

Relevant Patent Status Notes

• US 10116738 was filed November 30, 2015, and granted October 30, 2018.
• Google Patents lists its legal status as "Expired – Lifetime" with an anticipated expiration date of September 30, 2022 (consistent with a terminal disclaimer tying it to the 2001 priority family, since it is a continuation of US 7,822,871, which claims priority to September 28, 2001).
• Current assignee per the assignment record: Sandpiper CDN LLC (assigned from Level 3 Communications, LLC on April 26, 2024).

Conclusion

Based on the searches performed, no litigation specifically naming US 10116738 could be confirmed. The only potentially relevant litigation is the Sandpiper CDN v. Microsoft case in E.D. Tex. (2:25-cv-00664), but I could not verify from my search results whether 10116738 is one of the asserted patents in that case. To obtain a definitive answer, I would recommend:

1. Checking the PACER/ECF docket for 2:25-cv-00664 (and any related Sandpiper CDN cases) for the specific asserted patent lists;
2. Searching the Unified Patents litigation portal (portal.unifiedpatents.com/litigation/caselist) by the exact patent number 10116738; and
3. Checking RPX/DocketNavigator or the CAFC docket for appeals.

I cannot provide plaintiff/defendant/jurisdiction/case-number/status details for cases specifically involving this patent because none could be verified from the available information.

I'll verify the structured "no PTAB activity" baseline against public sources before writing the report.

The searches surfaced an important development (a 2026 Sandpiper v. Microsoft case listing 10116738 as an exhibit), so let me verify that case and check specifically for any IPR against this patent.

Proceedings overview

Zero AIA trial proceedings exist on US 10,116,738. The USPTO Open Data Portal (the canonical structured source for this prompt) reports no IPR/PGR/CBM filings for this patent, and my web searches corroborate that — no PTAB proceeding number anywhere is tied to 10,116,738. Status breakdown: 0 active, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denied. The bottom line: the patent has never been tested at the PTAB — every claim is untested — and because it expired 2022-09-30 and is only now being asserted (E.D. Tex. 2:26-cv-00681), any defendant's exposure is limited to a narrow pre-expiration damages window, with a completely open prior-art field and no IPR estoppel baggage.

There are therefore no proceedings for which I can report a panel, grounds, institution decision, or Final Written Decision — and I will not fabricate any. What the searches did surface is significant and directly relevant: the same plaintiff (Sandpiper CDN, LLC) is now asserting 10,116,738 against Microsoft in a second E.D. Tex. case, and Microsoft and Google have built an IPR campaign against Sandpiper's sibling CDN patents — which tells you what is likely coming for this patent and what defenses are available today.

---

AIA trial proceedings on US 10,116,738 — none on file

• Type: N/A (no IPR, PGR, or CBM has ever been filed against this patent)
• Filed: N/A
• Status: No proceedings — per the USPTO ODP structured data in this prompt ("no AIA trial proceedings ... as of the most recent ingest"), confirmed by web search (no hit for "10,116,738" / "10116738" in any PTAB index, RPX Insight, Docket Alarm, or PTAB docket aggregator).
• Petition grounds: N/A
• Institution decision: N/A
• Final Written Decision: N/A — do not rely on any representation that any claim of this patent has been held patentable or unpatentable at the PTAB.
• Settlement / termination: N/A
• Appeal: N/A
• Defensive value: This is a clean-slate patent from the defendant's perspective. No IPR estoppel (§ 315(e)) attaches to anyone on this patent, and because it is a pre-AIA patent (priority chain back to a Sept. 28, 2001 provisional / Sept. 30, 2002 non-provisional), PGR and CBM are unavailable — the only AIA vehicle is IPR on § 102/§ 103 grounds over patents and printed publications. The absence of any IPR in the 2018–2022 period, despite the patent being in force until Sept. 30, 2022, is itself telling: it was not meaningfully asserted during its life, and the PTAB was never asked to look at it.

Verification caveat: The claims text of 10,116,738 was not available in the record I was given (the Google Patents fetch includes abstract, specification, and drawings but not the claims), so I cannot enumerate the claims that would be at risk in any future IPR. The abstract points to a single method of (i) monitoring operational status of name servers, (ii) creating a policy on detecting an error/anomalous condition at a particular name server, and (iii) applying that policy in hostname resolution.

---

Context: PTAB activity on Sandpiper/Level 3 sibling CDN patents (NOT 10,116,738)

These are not proceedings on this patent, but they are the single best predictor of what a defendant will face next, and they show both sides' playbooks. All numbers below are verified from search results; none involve 10,116,738.

Sources: RPX Insight – IPR2026-00174; Docket Alarm – IPR2026-00095; ipverse/greyb – IPR2026-00190. Microsoft sought to join Google's IPRs in an "understudy role" (email exchange of 2025-11-03, EX1019 in IPR2026-00095).

And the litigation that matters for this patent: Sandpiper CDN, LLC v. Microsoft Corporation, E.D. Tex., No. 2:26-cv-00681, complaint on file with "Exhibit F – Patent No. 10,116,738" (PacerMonitor docket; case status "Open," patent-infringement cause of action). The earlier case, 2:25-cv-00664 (amended complaint 2025-10-30), asserted six other patents (8,478,903; 8,924,466; 9,456,053; 9,228,883; 9,762,692; 10,701,173) — 10,116,738 was not among them. So 10,116,738 first appears in the 2026 complaint. This updates and partially contradicts the earlier litigation summary in this file, which said no litigation naming 10116738 could be confirmed; the PacerMonitor docket for 2:26-cv-00681 now confirms it is asserted there. (PacerMonitor case page; CourtListener docket for 2:25-cv-00664)

---

Strategic summary

Claim status: ALL claims of 10,116,738 are UNTESTED — none canceled, none sustained. No PTAB tribunal has ever reviewed any claim of this patent. That cuts both ways: there is no FWD to lean on, but there is also no estoppel and no "hardened by IPR" story the patent owner can tell. The patent's substantive vulnerability has simply never been litigated at the Board. (I cannot give you a claim-by-claim inventory because the claims text was not in the record I was given — verify against USPTO Patent Center before any claim-level analysis.)

Estoppel landscape — a clean slate, but with a clock. Because no IPR has ever been filed on 10,116,738, no one is estopped under § 315(e)(2) from raising any § 102/§ 103 ground in district court or in a future IPR. For a defendant being sued today in 2:26-cv-00681: every prior-art ground (any patent or printed publication predating the 2001–2002 priority date) remains available, in court and at the PTAB. The practical constraint is the one-year bar (35 U.S.C. § 315(b)): an IPR must be filed within one year of service of the complaint alleging infringement of this patent. If Sandpiper's 2026 complaint is the first time 10,116,738 was asserted against Microsoft, Microsoft's IPR window runs into roughly mid-2027. Note also: because this is a pre-AIA patent, only IPR is available (no PGR; the CBM program has expired), so § 101/§ 112 challenges must be made in district court, not at the Board.

Pattern signals. (1) Same-owner, multi-front war: Sandpiper has sued Google (2:24-cv-03951, C.D. Cal.), Comcast (2:24-cv-00886, E.D. Tex.), and Microsoft (2:25-cv-00664 and now 2:26-cv-00681) on this CDN portfolio — this is a classic post-expiry monetization campaign. (2) Petitioners are organized: Microsoft and Google are coordinating (Microsoft sought to join Google's IPRs in an understudy role), and Microsoft's petitions are being handled by Perkins Coie with Google represented by Finnegan — meaning any IPR on 10,116,738 would likely be part of a coordinated, well-resourced campaign, not a solo shot. (3) Patent owner has won one round: the Director denied institution on discretionary grounds in IPR2026-00190 (Microsoft's IPR on the '053 patent) — Sandpiper successfully invoked discretionary-denial practice there, so expect Sandpiper to deploy Fintiv/Sotera-style and § 325(d) arguments against any future IPR on 10,116,738, particularly while the parallel district case is young. (4) No defensive aggregator is in the chain for this patent — Sandpiper is a monetization entity (assigned from Level 3 in 2024), and Microsoft is an RPX member per the POPR record in IPR2026-00095, which cuts toward a coordinated defense.

---

Recommended next steps

1. If you are a defendant (or prospective defendant) facing 10,116,738 today: the single most important fact is that the patent expired 2022-09-30. There is no injunction risk and no ongoing royalty; recoverable damages are confined to pre-expiration infringement and, under 35 U.S.C. § 286, to the six years before the complaint — which, for a 2026 filing against a patent that died in September 2022, likely caps exposure to roughly the 2020-09-30 → 2022-09-30 window (verify the exact complaint filing date in 2:26-cv-00681 and watch for tolling/equitable arguments — Sandpiper's own pleadings in the sibling cases show willfulness theories built on 2017-era citations and press coverage, which should be tested against § 286).
2. PTAB options: Because no IPR exists, you are free to file one without § 325(d) or estoppel complications from prior proceedings on this patent — but expect Sandpiper to oppose institution on discretionary grounds (it succeeded in IPR2026-00190) and to argue the parallel district case weighs against institution. If you are Microsoft, note that the one-year IPR clock runs from service of the 2:26-cv-00681 complaint. If you file: statutory milestones are an institution decision within ~3 months of the POPR and a Final Written Decision within 12 months of institution (subject to the Director's 6-month extension, as happened in the sibling litigation).
3. Verify the record before relying on any claim-level statement: pull the full claims text of 10,116,738 from USPTO Patent Center (application 14/954,092) — the record in this analysis never contained the claims, and no PTAB document addresses them. Confirm the assignment chain (Level 3 → Sandpiper CDN, recorded 2024-04-26) for standing and for who must be named in any petition.
4. Monitor: watch PTAB E2E (ptab.uspto.gov) and RPX Insight for any new IPR petition bearing patent number 10,116,738 — given Microsoft's demonstrated pattern of filing against this exact portfolio (four IPRs in two months, Dec. 2025–Jan. 2026, on sibling patents), an IPR on this patent within the one-year window is a realistic near-term event.

Bottom line: There is no PTAB history on 10,116,738 — zero proceedings, zero FWDs, zero claim rulings. That is not because the patent is strong; it is because it was never asserted until after it expired. The absence of PTAB activity, combined with the expired status, narrow damages window, and the open prior-art field, gives a defendant the strongest possible starting posture: no estoppel, no injunction risk, minimal damages exposure, and a blank canvas for prior-art challenges in both forums.

I've reached the limit of my available search steps. Below is the ownership-chain reconstruction based on the authoritative Google Patents record (provided in your message), corroborated by RPX, DocketAlarm, PTAB/PTACTS, and CourtListener materials surfaced in my searches. I flag clearly where the USPTO Assignment Center's reel/frame and correspondent fields could not be retrieved from my searches.

---

Inventors

All eight named inventors were, at the time of the underlying invention (2001) and the original non-provisional filing (Sep. 30, 2002), employees of Digital Island, Inc. (San Francisco) and/or its immediate successor Cable & Wireless Internet Services, Inc. after Cable & Wireless acquired Digital Island in October 2001. The inventors' assignment (recorded 2015-12-20) runs from the inventors to Digital Island, Inc.:

Pattern note: The entire inventing team was dispersed within a few years of filing — consistent with the 2001 Cable & Wireless acquisition and the 2006 divestiture of the CDN business (see below). This is an employee-dispersal pattern typical of a technology line that changed corporate hands twice, not itself an NPE tell.

---

Original assignee

• Entity named on the issued patent (US 10116738B2): Level 3 Communications, LLC (per Google Patents "Original Assignee"; the patent issued Oct. 30, 2018, by which time the chain had consolidated at Level 3).
• Product embodiment: Yes — the claims concern policy-driven DNS/name-server anomaly detection and traffic control, which is the core technology of the Adaptive Traffic Control (ATC) / Sandpiper/Footprint CDN that Level 3 operated commercially (the original Sandpiper Networks CDN, acquired via Savvis in Dec. 2006 for $135M per the Microsoft complaint, ¶47).
• Line of business: Tier-1 telecommunications / content delivery network operator.
• Current status: Level 3 was acquired by CenturyLink in 2017 and rebranded Lumen Technologies; Lumen exited the CDN business in 2023–2024 (CDN contracts sold to Akamai; CDN technology/IP spun out). Level 3 Communications, LLC remains the recorded transferor of record to Sandpiper CDN, LLC.

---

Assignment timeline

Important caveat: My searches did not return the USPTO Assignment Center reel/frame numbers or correspondent-of-record fields for these recordings. The events below are taken from the Google Patents legal-events record (authoritative for parties, conveyance types, and USPTO recordation dates). The 2015-12-20 / 2015-12-22 dates are USPTO recordation dates — the entire historical chain was recorded en masse by Level 3 in a single title-cleanup filing in December 2015, weeks after the continuation application US 14/954,092 was filed (2015-11-30). Execution dates and reel/frame/correspondent data must be verified on assignmentcenter.uspto.gov before reliance.

Recorded assignments (chronological by recordation):

1. Executed ~2001–2002 / recorded 2015-12-20 — Reel/frame: not retrieved

   • Conveyance: Assignment of Assignors' Interest
   • Assignor: John K. Salmon, Aric Hagberg, Mark Brady, Jeffrey Koller, David Pfitzner, Paul E. Stolorz, Michael S. Warren, Maksim Yevmenkin (inventors)
   • Assignee: Digital Island, Inc.
   • Correspondent: not retrieved
   • Context: Original inventors' assignment to the original assignee (recorded 13+ years later in the 2015 chain cleanup).

2. Recorded 2015-12-20 — Reel/frame: not retrieved

   • Conveyance: Change of Name
   • Assignor: Digital Island, Inc.
   • Assignee: Cable & Wireless Internet Services, Inc.
   • Context: Name change following Cable & Wireless's October 2001 acquisition of Digital Island.

3. Recorded 2015-12-20 — Reel/frame: not retrieved

   • Conveyance: Assignment of Assignors' Interest
   • Assignor: Cable & Wireless Internet Services, Inc.
   • Assignee: Savvis Asset Holdings, Inc.
   • Context: Transfer of the CDN patent assets out of C&W (prelude to the 2006 sale to Level 3).

4. Recorded 2015-12-20 — Reel/frame: not retrieved

   • Conveyance: Change of Name
   • Assignor: Savvis Asset Holdings, Inc.
   • Assignee: Savvis, Inc.
   • Context: Internal reorg / name change within Savvis.

5. Recorded 2015-12-20 — Reel/frame: not retrieved

   • Conveyance: Merger
   • Assignor: Savvis, Inc.
   • Assignee: Savvis Communications Corporation
   • Context: Internal reorg (merger into the listed parent).

6. Recorded 2015-12-20 — Reel/frame: not retrieved

   • Conveyance: Security Agreement
   • Assignor: Savvis Communications Corporation
   • Assignee: Wells Fargo Foothill, Inc., as Administrative Agent
   • Context: Debt-financing security interest under Savvis's credit facility — an operating-company financing event, not a transfer of title.

7. Recorded 2015-12-20 — Reel/frame: not retrieved

   • Conveyance: Assignment of Assignors' Interest
   • Assignor: Savvis Communications Corporation
   • Assignee: Mount Shasta Acquisition LLC
   • Context: Sale of the Savvis CDN business to Level 3 (announced Dec. 2006, $135M); "Mount Shasta" was the Level 3 acquisition vehicle.

8. Recorded 2015-12-20 — Reel/frame: not retrieved

   • Conveyance: Merger
   • Assignor: Mount Shasta Acquisition LLC
   • Assignee: Level 3 Communications, LLC
   • Context: Merger of the acquisition vehicle into Level 3 — consolidating title in the operating company.

9. Executed ~2002 / recorded 2015-12-22 — Reel/frame: not retrieved

   • Conveyance: Assignment of Assignors' Interest
   • Assignor: Ted Middleton (inventor)
   • Assignee: Level 3 Communications, LLC
   • Context: Ninth inventor's assignment recorded separately two days after the bulk filing — a stray-record cleanup item.

10. Recorded 2024-04-26 — Reel/frame: not retrieved

    • Conveyance: Assignment of Assignors' Interest
    • Assignor: Level 3 Communications, LLC
    • Assignee: Sandpiper CDN, LLC
    • Context: Transfer-to-asserter — Level 3/Lumen spun the CDN patent portfolio out to Sandpiper CDN, LLC in late 2023/early 2024; this is the event that put the patent in the hands of the entity now suing Google, Microsoft, and Comcast. (Corroborated by PTAB IPR2026-00095 Exhibit 1021, "Assignment from Level 3 Communications to Sandpiper CDN, LLC.")

If the Assignment Center shows additional items (e.g., a release of the Wells Fargo Foothill security interest, or earlier individual recordings from 2002–2007 that Google Patents did not surface), those would appear under the patent's full record; I could not retrieve reel/frame data to confirm or deny them.

---

Timeline diagram

timeline
    title Ownership of US 10116738
    2001 : Provisional filed
    2002 : Utility filed at Digital Island
    2006 : Level 3 buys Savvis CDN business
    2007 : Continuation filed
    2010 : Parent patent 7822871 issues
    2015 : Continuation 14954092 filed
         : Chain of title recorded at USPTO
    2018 : US 10116738 issues
    2022 : Patent expires
    2024 : Transferred to Sandpiper CDN LLC
         : Google suit filed by Sandpiper
    2025 : Microsoft and Comcast suits

---

NPE / troll-pattern signals

1. Shell-entity transfer — present (portfolio-level). The patent moved from operating company Level 3 Communications, LLC to Sandpiper CDN, LLC, a recently formed Delaware LLC (RPX: "Recently formed Delaware plaintiff Sandpiper CDN, LLC"). Sandpiper's own PTACTS filing emphasizes "partnership and licensing opportunities" and does not describe an operating CDN network with customers. Counter-nuance: Sandpiper publicly identifies as the successor to Sandpiper Networks and is co-owned by former Sandpiper CEO Andrew Swart — it is not an anonymous registered-agent shell. Transfer recorded 2024-04-26 (Level 3 → Sandpiper CDN, per Google Patents and IPR2026-00095 EX1021).

2. Known asserter in the chain — present. Sandpiper CDN, LLC is tracked by RPX (entity ID 13488673 per RPX News) as a high-frequency plaintiff: Sandpiper CDN v. Google/Alphabet (C.D. Cal., 2:24-cv-03951, filed June 2024), Sandpiper CDN v. Comcast (E.D. Tex., 2:24-cv-00886), Sandpiper CDN v. Microsoft (E.D. Tex., 2:25-cv-00664, amended complaint Oct. 30, 2025). Microsoft has responded with IPR2026-00095. Sandpiper is not on the classic Acacia/Marathon/IV list but matches the RPX/Unified "high-frequency plaintiff" profile. Caveat: I could not confirm that US 10116738 specifically is on any asserted-patent list; the Google suit asserts six CDN patents and the IPR targets U.S. 8,478,903.

3. Repeat correspondent across the chain — unclear / not retrievable. The USPTO Assignment Center correspondent fields were not returned by my searches. No correspondent names can be cited. This signal is unverified, not absent.

4. Cascading transfers — present in form, weak as an NPE signal. Nine recordings were filed in a two-day window (2015-12-20 and 2015-12-22). This is a same-day bulk chain-of-title cleanup by Level 3 (weeks after the 2015-11-30 continuation filing), not a 24-month cascade through chained LLCs. The genuine cascade (Digital Island → C&W → Savvis → Mount Shasta → Level 3) spans 2001–2007 and reflects real M&A, not shell churn.

5. Pre-litigation transfer — present (timing, portfolio-level); unverified for this patent. The Level 3 → Sandpiper CDN transfer was recorded 2024-04-26; Sandpiper's first suit (Google) followed in June 2024 — inside the 6-month window. However, US 10116738 expired 2022-09-30 (20 years from the 2002-09-30 filing of US 10/259,497), ~18 months before the transfer. An expired patent cannot support prospective damages, so this patent is most plausibly a portfolio-filler in the transfer, and I could not verify it is asserted anywhere.

6. Bankruptcy fire-sale — not present. No bankruptcy in the chain. The 2006 Savvis CDN sale was a strategic divestiture (multiple bidders, per the Microsoft complaint); Lumen's 2023–2024 exit was an orderly market withdrawal (CDN contracts to Akamai; IP to Sandpiper).

7. Privateering — present. Operating company Level 3/Lumen transferred CDN patents to Sandpiper CDN, which asserts them against CDN competitors (Google CDN, Microsoft Azure CDN, Comcast). The Google complaint itself frames Google CDN as "a direct competitor to the CDN services offered by the Plaintiff's predecessor, Level 3," and RPX notes the patents "were received from Level 3 Communications." This fits the classic privateering pattern, albeit from a company that had exited the CDN business rather than one still competing.

8. Defensive aggregator (anti-NPE) — not present. The chain terminates at Sandpiper CDN, an assertive entity. No RPX/AST/LOT/OIN ownership.

---

Verdict

NPE — high confidence.

The chain terminates at Sandpiper CDN, LLC (recorded transfer from Level 3 Communications, LLC on 2024-04-26), a recently formed Delaware LLC with no operating CDN product that is a tracked RPX plaintiff (Google 2:24-cv-03951, Comcast 2:24-cv-00886, Microsoft 2:25-cv-00664, and IPR2026-00095 defense) — a transfer-to-asserter / privateering pattern with litigation filed within two months of the recording. Two caveats keep this from being a textbook case: (1) US 10116738 itself expired 2022-09-30, before the transfer and all litigation, so I could not verify it is individually asserted (it functions as portfolio inventory); and (2) the assignment reel/frame and correspondent data could not be retrieved in my searches and should be pulled from the USPTO Assignment Center to confirm no additional recordings (e.g., release of the Wells Fargo Foothill security interest) and to identify the repeat correspondent.

Verify at: https://assignmentcenter.uspto.gov/ (Patent Assignment Search → patent number 10116738) and the PTAB record for IPR2026-00095 (Exhibit 1021).

I'll research the cited prior art for US 10,116,738, starting with the USPTO/Google Patents citation records and then verifying each reference.

Now let me try to obtain the actual claim text (critical for a § 102 analysis) and verify the individual references.

The IPR2025-00806 petition references sibling-patent claim language. Let me now try to pin down the actual claims of 10,116,738 and verify the key references' dates and content.

Prior Art Analysis — US 10,116,738 B2 ("Detecting anomalous conditions in a name server network")

0. Search scope, and what I did not return

I searched for the literal number 10116738 / 10,116,738. Per your instruction I excluded results for near-miss numbers that surfaced in the search index:

Critical limitation on this report: the claims text of 10,116,738 was not retrievable in the record available to me (the authoritative Google Patents fetch contains the abstract, specification and drawing list but not the claims; Justia likewise returned the reference list and bibliographic data but not the claim set). Every reference below is therefore mapped to the claim architecture supported by the abstract, not to verified claim numbers. I flag this again at §5. Do not cite claim numbers from this report without pulling the grant from USPTO Patent Center.

---

1. The reference list of record (the patent's own "References Cited")

Source verified this session: Justia, https://patents.justia.com/patent/10116738 (References Cited). The Google Patents record and FreePatentsOnline mirror agree.

1(a) U.S. patents cited

1(b) U.S. publications cited

1(c) Foreign patent documents

1(d) Non-patent literature (as listed)

• Chinese Reexamination Decision, Jun. 18, 2014, App. No. 02821371.8, filed Sep. 30, 2002
• Chinese Reexamination Notification, Jul. 5, 2012
• Chinese Reexamination Notification, Sep. 13, 2012
• Chinese Reexamination Notification, Jan. 10, 2014, App. No. 02821371.8 (12 pp.)
• Decision on Petition, Nov. 13, 2013, in U.S. Appl. No. 12/978,537
• Berners-Lee et al., RFC 1738 (Dec. 1994) — cited in the specification body, not in the IDS

---

2. The single most important legal gate: which references are even prior art

The claims of 10,116,738 carry an effective filing date of Sep. 28, 2001 (provisional 60/325,177) / Sep. 30, 2002 (Ser. No. 10/259,497) if the 2015 continuation claims are fully supported by that disclosure. Because the specification is the same ATC disclosure, that entitlement is likely solid for most claims — but it is contestable claim-by-claim, and the consequence is severe: if a claim is not entitled to the 2001/2002 date, its effective date is Nov. 30, 2015, and roughly a decade of additional art becomes available.

Applying the pre-AIA §§ 102(a)/(b)/(e) framework (this is a pre-AIA patent — the family never contained a claim with an effective filing date on or after Mar. 16, 2013):

This gate matters more than the substance of any single reference: a defendant's best § 102 argument is often not "reference X discloses the claim" but "this claim is not entitled to the 2001 priority date, so reference X (post-2001) is § 102(e)/(a)(2) art."

---

3. Reference-by-reference analysis

Framing caveat repeated: each of the references below was cited in the IDS and considered by the examiner (Primary Examiner John B Walsh, per Justia), and the application issued with claims. That means no reference of record was found to anticipate. Under § 102, anticipation requires a single reference disclosing every element arranged as in the claim. None of the references of record satisfies that on the face of the record. Their real force is in § 103 combinations (analyzed in the prior section of this file) and, for the post-2001 references, in the priority-date attack described above. I therefore report, for each reference, the element it supplies and the claim(s) it would potentially reach if either (a) the claim is broader than the abstract suggests, or (b) the priority date is lost.

---

3.1 US 6,976,090 — Ben-Shaul (Dec. 13, 2005) — ★ the most dangerous reference

• Full citation: US 6,976,090 B1, Ben-Shaul. Issued Dec. 13, 2005.
• Companion: US 2002/0010798 A1 (Ben-Shaul), published Jan. 24, 2002 — the pre-grant publication of the same workstream, cited separately on the face.
• Dates that matter: the issue date is irrelevant to § 102; the U.S. filing date governs, and it is pre-2002 on the family's own cited-art theory. Verify the filing date on USPTO Patent Center — I could not confirm it in this session, and the entire § 102(e) argument rises or falls on it.
• Brief description: A DNS-based content-delivery/request-routing system in which an administrative/origination component ("administrative agent") associated with the origin server creates and deploys "directives" — i.e., policies — that govern how name resolution is performed, and which receives reports back from the distributed delivery tier. In the IPR record discussed at §4 below, the Petitioner quotes Ben-Shaul at [0345] for "an origination component 116 (administrative agent) that 'resides in the origin web server,'" and states that the origination component "is responsible for creating and deploying the directives."
• § 102 reach — which claims it potentially anticipates: the independent method claim (the claim corresponding to the abstract), because Ben-Shaul supplies in one reference: (i) a network of name servers/request directors, (ii) an administrative agent that creates a policy, and (iii) resolution of hostnames by reference to that policy. If the granted independent claim recites an administrative agent that creates the policy on the basis of monitoring information, Ben-Shaul is the closest single-reference disclosure. Its identified gap for § 102 purposes is element (a)/(b) of the abstract — monitoring the name servers themselves and detecting an error/anomalous condition at a name server — because Ben-Shaul's monitoring reports concern the delivery/origin tier, not the DNS-routing tier.
• Why it is the most dangerous: it is the reference Google is currently using against the family. In IPR2025-00806 (Ex. 1005 in that record) the Petitioner maps Ben-Shaul — alone or in view of Hasan — against independent claims of US 8,645,517, a sibling continuation from the same ATC specification, including the limitation "the name server network comprising at least one domain name server … constructed and adapted to provide adaptive policy-based domain name service." See §4.

3.2 US 7,103,645 — Leighton et al. (Sep. 5, 2006) — Akamai "Global hosting system"

• Full citation: US 7,103,645 B2 (Leighton et al.), issued Sep. 5, 2006; continuation US 7,716,367 B2 (Leighton), issued May 11, 2010, also cited.
• Dates: U.S. filing dates are pre-2001 (Akamai's DNS-based content routing was commercial from 1999); verify on Patent Center.
• Brief description: A distributed, DNS-based global hosting/content-routing system: a set of content servers and a name-server layer that answers hostname queries by selecting a server according to monitored conditions, with detection of failed or congested servers and re-routing DNS answers around them.
• § 102 reach: the independent method claim — it discloses elements (b) and (d) of the abstract (detecting a bad condition; letting that condition influence hostname resolution) and much of (a). Its § 102 gap is the object of the monitoring: Leighton monitors the content servers, while the abstract of 10,116,738 says the monitoring is of "at least some name servers in a name server network." That distinction is the whole case on § 102, and it is thin enough that it is more honestly characterized as a § 103 problem (as the prior section concluded).

3.3 US 6,605,120 — Fields et al. (Aug. 12, 2003)

• Full citation: US 6,605,120 B1 (Fields et al.), issued Aug. 12, 2003.
• Dates: filing date not verified this session; the reference is characterized in the record as a network-management/alarm/policy system.
• Brief description: Network/internetwork management: collection of status information from network elements, detection of faults or anomalous conditions, generation of alarms, and application of management policies in response.
• § 102 reach: the independent claim — supplies element (b) (error/anomaly detection) and (c) (creating a policy indicating status) in a generic network-management setting, and (a) in the sense of monitoring network elements. Its § 102 gap is d: Fields does not resolve hostnames. It is a § 103 partner, not an anticipatory reference, for any claim that requires DNS resolution.

3.4 US 2002/0145975 — MeLampy et al. (Oct. 10, 2002)

• Full citation: US 2002/0145975 A1 (MeLampy et al.), published Oct. 10, 2002.
• Dates: published after the Sep. 28, 2001 priority date — so it is prior art only under § 102(e), and only to the extent its U.S. filing date precedes the priority date. This is a verification-critical reference.
• Brief description: Network traffic management using DNS, with monitoring of server availability/load driving the returned answer.
• § 102 reach: the independent claim — potentially supplies (a)–(d) if its filing date is pre-2001, because it links monitored availability directly to DNS answer selection. If and only if the priority date is lost (see §2), it becomes § 102(e) art on the whole disclosure.

3.5 US 2002/0087684 — Foth (Jul. 4, 2002)

• Full citation: US 2002/0087684 A1 (Foth), published Jul. 4, 2002.
• Dates: published after the priority date; § 102(e) only.
• Brief description: Automatic data routing via DNS responsive to server load/availability.
• § 102 reach: the independent claim, via (b)/(c)/(d): monitored server state is converted into routing state consulted at resolution time. Same monitoring-object gap as Leighton (content servers, not name servers).

3.6 US 6,976,090's sibling publication US 2002/0010798 — Ben-Shaul (Jan. 24, 2002)

• Full citation: US 2002/0010798 A1 (Ben-Shaul), published Jan. 24, 2002.
• Dates: published after the priority date; § 102(e) only.
• § 102 reach: same as §3.1. If the examiner cited the publication and the patent separately, they are the same disclosure and should be treated as one reference for anticipation purposes (no double-counting).

3.7 US 7,577,754 — Garcia-Luna-Aceves et al. (Aug. 18, 2009)

• Brief description: Measurement and reporting of network quality/performance between nodes; quality information fed back to a routing/selection decision.
• § 102 reach: (b) — measuring the network to detect degraded/anomalous conditions. A § 103 partner for the "anomalous condition" element; not an anticipator of a DNS-resolution claim.

3.8 US 2002/0143914 — Cihula (Oct. 3, 2002); US 2002/0116444 — Chaudhri et al. (Aug. 22, 2002)

• Both published after the priority date → § 102(e) only.
• § 102 reach: (c)/(d) — using monitored load/availability to alter what the name service returns. Both are § 103 partners.

3.9 US 7,185,052 / US 7,219,153 — Day (Feb. 27, 2007 / May 15, 2007); US 7,188,317 — Hazel (Mar. 6, 2007); US 7,373,644 — Aborn (May 13, 2008)

• Brief description (per the record's characterization): content-delivery-oriented DNS routing (Day); network/server measurement and quality reporting (Hazel, Aborn).
• § 102 reach: (d) and (a) respectively. All are § 103 partners. I could not verify abstracts individually in this session — treat the characterizations as provisional.

3.10 US 2007/0055764 — Dilley et al. (Mar. 8, 2007) — Akamai global load balancing

• Brief description: Continuous measurement of server health and load, feeding a DNS-based global load-balancing decision across mirrored server sites.
• § 102 reach: (a)–(d) in substance — health/load monitoring → routing state → DNS answer. Strong § 103 partner. Because it post-dates 2001 by six years, it is § 102(e)/(a)(2) art only if its underlying U.S. filing date precedes Sep. 28, 2001 — which is doubtful. Verify.

3.11 US 2009/0254661 and US 2010/0332595 — Fullagar et al.; US 2010/0169772 — Stallings et al.; US 2010/0312861 — Kolhi et al.; US 2004/0010588 — Slater et al.; US 2004/0064832 — Tsukidate et al.; US 2005/0060493 — Krissell et al.; US 2005/0240966 — Hindle et al.

• § 102 reach: None as anticipatory art. Every one of these post-dates the Sep. 28, 2001 priority date by 2–9 years. They are § 102(e)/(a)(2) candidates only to the extent of pre-2001 U.S. filing dates (verify individually), and otherwise they are simply not prior art to the claims if the 2001 date holds. Their inclusion on the face of the patent is a signal that the examiner cast a wide net, not that they are close art.

3.12 Foreign references

3.13 Non-patent literature

• Chinese Reexamination Decision, Jun. 18, 2014, App. No. 02821371.8 and the three Reexamination Notifications (2012-07-05; 2012-09-13; 2014-01-10). These are not prior art — they are the prosecution/re-examination record of the Chinese counterpart of the 2002 parent. Their evidentiary value is the opposite of anticipation: the family's claims survived a full Chinese reexamination over whatever art was cited there. Expect the patent owner to use this defensively; expect a defendant to dig into the Chinese file to see whether the surviving claim scope was narrowed relative to the U.S. claims (an obviousness-type scope-inconsistency argument).
• Decision on Petition, Nov. 13, 2013, U.S. Appl. No. 12/978,537 — a petition decision in another family member, not prior art.

---

4. New, material finding this session: the family is already being attacked

This is not prior art against 10,116,738, but it directly governs how the § 102 argument will be run:

• IPR2025-00806 (Google's 2025 filing on the Sandpiper/Level 3 portfolio) is an IPR against US 8,645,517 — a sibling continuation drawn from the same ATC specification as 10,116,738 (the petition quotes the shared "policy database 124" and the shared decision-tree passage at 9:1-12).
• The petition seeks cancellation of claims 1–20 of the '517 patent, characterizing it as "a graphical user interface (GUI) for setting DNS polices in a decision tree structure."
• Ben-Shaul is the Petitioner's primary reference, mapped limitation-by-limitation — including the "name server network comprising at least one domain name server … constructed and adapted to provide adaptive policy-based domain name service" preamble and the policy-creation/provision elements.
• That means the same Ben-Shaul reference cited on the face of 10,116,738 is the reference currently aimed at the family's policy-creation claims. The only thing 10,116,738 adds to the family's claim vocabulary is the name-server-anomaly-detection hook in the abstract — so the defensible § 102 theory for a defendant is not Ben-Shaul alone; it is Ben-Shaul (policy creation by an administrative agent) plus a name-server-monitoring reference (WO 2000/52594 / the UltraDNS line) to close the "monitoring the name servers themselves" element.

Also newly confirmed this session: the patent's own family includes US 10,911,531 ("Multi-tiered server network," filed Oct. 29, 2018), which claims priority to application 14/954,092 — so 10,116,738's application is itself the parent of a further continuation. That matters for claim-scope comparison across the family.

---

5. Bottom-line answers to your three questions

Which reference is the most relevant?
US 6,976,090 (Ben-Shaul) / US 2002/0010798 (Ben-Shaul) — cited twice on the face of 10,116,738, and the reference actually being asserted against the sibling patent in IPR2025-00806. Second: US 7,103,645 + US 7,716,367 (Leighton/Akamai). Third: WO 2000/52594 (name-server-tier monitoring), which is the only cited reference that reads on the abstract's literal "monitoring the operational status of … name servers."

Which claims does each potentially anticipate under § 102?
Stated honestly: on the face of the record, none of them anticipates anything, because each was considered and each independent claim issued over the whole list. Reference-by-reference, the closest § 102 theories are:

• Ben-Shaul → the independent method claim (policy creation + policy-based hostname resolution), with a gap on "error/anomalous condition at a name server";
• Leighton ('645/'367) and Foth / MeLampy / Cihula / Dilley → the independent method claim, with the same monitoring-object gap;
• Fields → the independent claim only for the anomaly-detection/policy-creation half; does not resolve hostnames;
• WO 2000/52594 + WO 2000/14633/26806/41091 + EP 0817020/0817444 → element (a) as literally claimed ("name server network" monitoring); these are § 102(b) art and immune to the priority-date fix;
• Post-2002 U.S. publications (Fullagar, Stallings, Kolhi, Krissell, Hindle, Slater, Tsukidate) → no claim, because they are not prior art if the Sep. 28, 2001 priority date holds.
• US 2011/0145386 (Stolorz et al.) → no claim; it is the family's own publication and cannot be § 102 art against it.

The claim numbers. I could not supply them. The abstract-supported claim architecture is a single independent method claim plus dependents. Verify the grant at USPTO Patent Center, application 14/954,092 before using any claim number in a pleading.

Strategic note for whoever is facing this patent today (consistent with the earlier sections of this file): the patent expired Sep. 30, 2022, and is now asserted against Microsoft in E.D. Tex. 2:26-cv-00681 (Exhibit F — Patent No. 10,116,738). The § 102 story is weak on the face of the record, but it improves sharply if any asserted claim is denied the 2001/2002 priority date — at which point Foth, MeLampy, Cihula, Dilley, Fullagar, Stallings, Kolhi, Krissell, Hindle, Slater and Tsukidate all convert from "not prior art" into § 102(e) references. The priority-date challenge is the highest-leverage § 102 argument available, and the claim text I could not retrieve is what determines whether it is available.

Obviousness Analysis of US 10,116,738 B2 Under 35 U.S.C. § 103

Preliminary caveat on the claim set

The authoritative Google Patents record provided includes the abstract, specification, and drawings list but not the claims text, and my searches did not retrieve the verbatim claims. The analysis below therefore treats the claimed invention at the level supported by the abstract ("A method includes monitoring the operational status of at least some name servers in a name server network. Based on the monitoring, when an error or anomalous condition is detected at a particular name server, creating a policy to indicate the status of the particular name server. The policy is taken into account when resolving hostnames using the name server network.") and the specification's description of the monitoring/trap/policy-creation architecture (Figs. 5–7; Figs. 8(c)–8(e)). If the granted claims are narrower (e.g., requiring a specific "trap," an administrative master agent, or a specific policy type), the combination analysis should be re-run against the actual claim language from USPTO Patent Center before reliance. The "Prior Art section" referenced in the task corresponds to the References Cited list on the Google Patents/Justia records for US10116738, which I reproduce and use below.

---

1. The claimed invention in plain terms

Reading the abstract and specification together (name servers 118 with monitoring mechanism 130, database manager 132, ATC network monitoring mechanism 150 with trap handler 176/event consolidation 180/alert generation 184), the invention can be broken into four substantive elements:

The specification expressly contemplates the failover scenario at the name-server layer: "if the North America name server agent is not functioning properly, the Europe name server agent may be temporarily assigned to handle the DNS requests from North America."

---

2. Prior art of record (the "Prior Art section" of the patent)

The References Cited for US10116738 (per the Justia record) includes, inter alia:

U.S. patents / publications:

• US 6,605,120 (Fields et al., Aug. 12, 2003) — network/intelligent network management, monitoring, alarms, policies
• US 6,976,090 (Ben-Shaul, Dec. 13, 2005) and US 2002/0010798 (Ben-Shaul, Jan. 24, 2002) — DNS-based network service delivery, hierarchy of name servers, server monitoring
• US 7,103,645 (Leighton et al., Sep. 5, 2006) — Akamai "Global hosting system" — DNS-based content routing, network monitoring, failure-aware routing
• US 7,185,052 (Day) and US 7,219,153 (Day) — content-delivery-related DNS routing
• US 7,188,317 (Hazel); US 7,373,644 (Aborn); US 7,577,754 (Garcia-Luna-Aceves et al.) — network/server measurement, monitoring, and quality reporting
• US 7,716,367 (Leighton) — continuation of the Akamai global hosting system
• US 2002/0087684 (Foth, Jul. 4, 2002) — automatic data routing via DNS responsive to server load/availability
• US 2002/0116444 (Chaudhri et al.); US 2002/0143914 (Cihula); US 2002/0145975 (MeLampy et al., Oct. 10, 2002) — network traffic management via DNS with monitoring of availability/load
• US 2004/0010588 (Slater et al.); US 2004/0064832 (Tsukidate et al.) — load balancing with monitoring
• US 2005/0060493 (Krissell et al.); US 2005/0240966 (Hindle et al.)
• US 2007/0055764 (Dilley et al., Mar. 8, 2007) — Akamai global load balancing across mirrored servers (health/load monitoring driving DNS responses)
• US 2009/0254661 (Fullagar et al.); US 2010/0169772 (Stallings et al.); US 2010/0312861 (Kolhi et al.); US 2010/0332595 (Fullagar et al.)
• US 2011/0145386 (Stolorz et al.) — same inventive family (publication of the parent application); not prior art under § 102/103 by virtue of common ownership/continuity, but confirms the specification was published years earlier

Foreign:

• EP 0817020 (Jan. 1998) and EP 0817444 (Jan. 1998) — DNS-based server selection (Cisco DistributedDirector lineage)
• GB 2354350 (Mar. 2001)
• WO 2000/14633; WO 2000/26806; WO 2000/41091; WO 2000/52594 (Sep. 2000, Matra Nortel, "Scalable and efficient domain name resolution" — distributed directory/name servers); WO 2000/78004; WO 2001/39003 (May 2001, integrated point-of-presence server network)

NPL: Chinese Reexamination Decision dated Jun. 18, 2014, Application No. 0282137… (reexamination of the family's Chinese counterpart — evidence that the family's scope was contested abroad, not a substantive U.S. prior-art teaching).

---

3. Legal framework and PHOSITA

Graham factors: (1) scope/content of prior art; (2) differences between prior art and claims; (3) level of ordinary skill; (4) secondary considerations.

Person having ordinary skill in the art (PHOSITA), circa September 2001: an engineer with a B.S./M.S. in computer science or networking and 2–5 years' experience in Internet infrastructure, DNS (RFC 1034/1035), load balancing, and network/server monitoring. Such a person would be familiar with: BIND, DNS delegation (NS/CNAME), round-robin DNS, Cisco DistributedDirector, Akamai's DNS-based content routing (commercial from 1999), SNMP/RMON monitoring, and policy-based network management.

---

4. Element-by-element coverage by the primary references

---

5. Combinations and motivation to combine

Combination A (strongest): Akamai DNS-based routing + name-server/network monitoring

References: US 7,103,645 (Leighton et al., "Global hosting system") or US 7,716,367, combined with WO 2000/52594 (Matra Nortel, distributed directory/name servers) and/or US 6,605,120 (Fields, network management with alarms/policies).

Teaching of the combination. Leighton et al. already discloses: a DNS-based global routing system with a hierarchy of name servers; monitoring of network/server conditions; detection of failed or congested servers; and modifying DNS answers (hostname resolution) to route around failures — i.e., elements (b) and (d) and part of (a). What Leighton monitors is primarily the content-serving infrastructure. WO 2000/52594 discloses a distributed system of directory/name servers whose own operational status is monitored and managed — i.e., element (a) as applied to the name-server tier. Fields discloses network fault detection with alarm generation and policy-based responses — i.e., elements (b)/(c) in generic form.

Motivation. The entire point of DNS-based traffic management is fault tolerance of the routing layer: RFC 1034/1035 already required redundant name servers, and the patent's own specification admits name-server agents "may also serve as a back up name server agent for other name server agents." A PHOSITA building a DNS-based traffic director would have a self-evident reason to monitor the name servers themselves (the single point of failure for the whole routing scheme) using known name-server/network monitoring tools, and to encode the detected failure as a routing policy so that hostname resolution avoids the failed name server. This is the routine application of an existing monitoring/alarm/policy system (Fields; WO 2000/52594) to the infrastructure already being monitored in Leighton — a textbook "known technique, known problem, obvious solution" case (KSR). No inventive leap is required to monitor the DNS tier rather than only the content tier, especially where the spec itself treats name-server redundancy as conventional.

Combination B: DNS-based server selection + health/load-feedback routing

References: EP 0817020 / EP 0817444 (DistributedDirector lineage) or US 2002/0087684 (Foth), combined with US 2007/0055764 (Dilley et al., global load balancing across mirrored servers) and/or US 2002/0145975 (MeLampy et al.).

Teaching of the combination. DistributedDirector/Foth disclose DNS responses that are dynamically computed from measured network and server conditions — elements (b)/(d). Dilley discloses continuously measuring server health/load and feeding those measurements into a DNS-based global load-balancing decision — elements (a)–(d) in substance, albeit again aimed primarily at content servers. MeLampy discloses network traffic management via DNS with availability/load monitoring.

Motivation. The Dilley/Foth/McLampy systems all respond to a detected server anomaly by changing what the DNS layer returns. Extending the same health-feedback loop to the name servers is an obvious design choice: the name-server tier is just another set of network elements whose health can be probed with the identical mechanisms (heartbeats, SNMP traps, load reports) already used for the content servers. The motivation is reliability: if a name server fails or behaves anomalously, DNS queries it would have handled must be redirected to a healthy name server, and the natural implementation is a status policy consulted at resolution time. A PHOSITA combining Dilley (health-feedback routing) with DistributedDirector (metric-based DNS selection) would arrive at element (c) — a status record/policy for the anomalous name server consulted during hostname resolution — without any unexpected result.

Combination C: Policy-based network management + DNS failover

References: US 6,605,120 (Fields, intelligent network management with policies and alarms) combined with US 6,976,090 / US 2002/0010798 (Ben-Shaul, DNS-based network service with name-server hierarchy and failover) and/or GB 2354350 / WO 2001/39003 (point-of-presence server networks).

Teaching of the combination. Fields discloses monitoring network elements, detecting anomalies, and applying management policies/alerts — elements (a)/(b)/(c) in a generic network-management context. Ben-Shaul discloses a hierarchy of DNS name servers that route requests to the best server and handle failures — elements (b)/(d). Combining them teaches exactly the claimed method: use Fields-style monitoring on the Ben-Shaul name servers, generate a status policy upon detection of an anomaly, and have the Ben-Shaul resolution logic honor that policy.

Motivation. The known problem of "the DNS router itself goes down" was squarely within the domain of both policy-based network management (Fields) and DNS-based traffic directors (Ben-Shaul). The motivation to combine is the recognized desirability of self-monitoring, self-healing routing infrastructure; the combination is the union of two references addressing complementary halves of the same system, with predictable results.

---

6. Differences the claims might still present (and why they are likely not enough)

If the granted claims require specific details beyond the abstract — e.g., the "policy" is stored in a per-name-server policy database managed by a database manager; the anomaly is detected via trapped events consolidated by an administrative master agent; or the policy marks a name server "unavailable" so that a backup name server handles its region — each of these is individually well-known:

• Traps/event consolidation and alert generation to a network operations center: standard SNMP trap architecture (Fields; generic network management; the spec cites its own NOC alerting as routine).
• Local policy databases updated upon detected unavailability: disclosed in substance by Foth, Dilley, and Ben-Shaul (routing state updated from monitored health), and by policy-based network management generally.
• Backup name servers taking over for failed ones: conventional DNS redundancy (RFC 1034/1035), expressly acknowledged in the specification itself.

None of these details rises to an "unexpected result" or a new technical effect over the combination of a DNS traffic director with a name-server/network monitoring system.

---

7. Secondary considerations

• Long-felt need / commercial success: The record before me contains no evidence of long-felt need or unexpected results attributable to the name-server-status-policy feature specifically. The commercial success of Akamai and DistributedDirector-style products predates the invention and is explained by the prior art, not by this claim.
• Skepticism/teaching away: None identified in the record.
• Copying: No evidence.
• Prosecution history caveat: This continuation was filed in 2015 and granted in 2018, and the family underwent a Chinese reexamination (NPL of record, 2014). That suggests the claims were narrowed during prosecution; the actual granted claim limitations may be materially narrower than the abstract, and the analysis above should be re-run against the USPTO full-text claims and file wrapper before it is used in litigation.

---

8. Conclusion

Under 35 U.S.C. § 103, the abstract-supported claim scope of US 10116738 — monitoring name servers in a name server network, detecting an error/anomalous condition at a particular name server, creating a policy indicating that name server's status, and consulting that policy in hostname resolution — would very likely have been obvious to a PHOSITA as of the September 2001 priority date.

The strongest combination is US 7,103,645 (Leighton/Akamai) + WO 2000/52594 (Matra Nortel) + US 6,605,120 (Fields): the first supplies DNS-based, failure-aware hostname resolution; the second supplies monitoring of the distributed name-server tier itself; the third supplies anomaly detection, alerting, and policy-based management. The motivation — ensuring the fault tolerance of the DNS routing infrastructure, which is the single point of failure of the entire traffic-management system — is explicit in the conventional DNS redundancy practice acknowledged in the patent's own specification. Alternative combinations (DistributedDirector/Foth + Dilley; Fields + Ben-Shaul) are equally available and independently motivated.

Caveat on confidence: High confidence in the prior-art list (it is the patent's own References Cited) and in the § 103 framework; moderate confidence in the element-level mapping because the verbatim claims were not available in the record. Verify the granted claims (USPTO Patent Center / Google Patents claims tab) before relying on this analysis in any substantive proceeding.