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 references for US Patent 10116738. First, let me search for the patent's citations and claims.

The Justia page appears to list the patent's cited references. Let me retrieve the full citation list and the claims text to properly assess anticipation.

I need the complete citation list. Let me retrieve the Justia page for the granted patent, which lists citations, and also search for the full claims text.

I've hit the search-step limit for this session, so I'll now compile the answer from the authoritative record you provided (Google Patents) plus the citation data retrieved from Justia's record for US 10116738 and USPTO-mirror sources (uspto.report). I'll flag every point where the full citation or claims text could not be confirmed in this session.

1. USPTO database confirmation for patent number 10116738 (exact)

• Patent: US 10,116,738 B2 ("US10116738B2") — Detecting anomalous conditions in a name server network
• Application: 14/954,092, filed Nov. 30, 2015; Granted Oct. 30, 2018; Primary Examiner John B. Walsh
• Assignee: Level 3 Communications, LLC (Broomfield, CO); current assignee of record Sandpiper CDN LLC
• Inventors: Paul E. Stolorz, John K. Salmon, Michael S. Warren, Jeffrey G. Koller, Aric Hagberg, Maksim Yevmenkin, Mark Brady, David Pfitzner, Ted Middleton
• Priority: Provisional 60/325,177 (Sep. 28, 2001); continuation of 11/932,162 → 10/259,497 (US 7,822,871)
• Status: Expired – Lifetime (anticipated expiration Sep. 30, 2022)

Number-integrity caveat (per your strict rule): The earlier USPTO hit — PTAB Appeal 2018-006191, Application 15/167,238 — is a different number (15/167,238 ≠ 10,116,738) and is excluded from this analysis. No other similar-number results are being reported.

Critical gap: The claims text of 10116738 was not retrievable in this session (Google Patents fetch in your message ends at the specification; Justia/uspto.report snippets did not include the claim set). The § 102 mapping below is therefore necessarily provisional, keyed to the abstract's method: (E1) monitoring the operational status of at least some name servers in a name server network; (E2) based on the monitoring, detecting an error or anomalous condition at a particular name server; (E3) creating a policy to indicate the status of that name server; (E4) taking the policy into account when resolving hostnames using the name server network. Verify against the USPTO Patent Center full text before relying on any claim-level conclusion.

2. § 102 framework applicable to this patent

Because the effective filing date (Sep. 28, 2001, via the provisional) predates the AIA's Mar. 16, 2013 effective date, pre-AIA 35 U.S.C. § 102 governs:

• § 102(b): patented or described in a printed publication more than one year before the earliest U.S. filing date (Sep. 30, 2002 for 10/259,497) → critical date Sep. 30, 2001. Every foreign reference below (1998–May 2001) and any U.S. reference published before Sep. 30, 2001 is § 102(b) statutory-bar art.
• § 102(a): patent/printed publication "by others" before the invention date (assumed Sep. 28, 2001 or earlier).
• § 102(e): U.S. patents and published U.S. applications effectively filed before Sep. 30, 2001 — this is the route by which the U.S. patents issued 2003–2010 and the U.S. applications published 2002+ can qualify as prior art (each must claim priority to a pre-Sep-2001 application).
• References that are continuations/siblings of the same family (e.g., US 2011/0145386, same inventors) are generally not "by others" and are not § 102(a)/(e) prior art.

3. Complete cited-reference list for US 10116738, with § 102 assessment

Source: Justia patent record for 10116738 (patents.justia.com/patent/10116738#4). Titles that could not be confirmed from retrieved sources are marked [title not confirmed]. Descriptions reflect the examiner's likely use in this DNS/traffic-management prosecution; confidence is labeled per entry.

3.1 U.S. Patents (9)

3.2 U.S. Published Applications (15)

3.3 Foreign patent documents (9) — all published before Sep. 30, 2001 → § 102(b) statutory-bar art

3.4 Non-patent literature

• Chinese Reexamination Decision, dated Jun. 18, 2014, Application No. 0282137… (number truncated in the Justia snippet — likely the Chinese counterpart of the 7,822,871 family). This is an office/reexamination decision from foreign prosecution of the same family; it is not § 102 prior art (not a patent or printed publication qualifying as art), but it is useful prosecution history showing how the examiner in a related jurisdiction treated overlapping claims.

4. Most relevant prior art (ranked)

1. US 7,103,645 B2 (Leighton et al., 2006) and US 7,716,367 B2 (Leighton, 2010) — Akamai-class DNS-based global traffic management. These are the closest well-known art for monitoring operational status and routing hostname resolutions accordingly (E1, E2, E4). The likely point of distinction: 10116738's claim scope centers on creating a policy reflecting an error/anomalous condition of a name server itself (E3) and using that policy in resolution — a "meta" monitoring of the DNS infrastructure, not merely content-server health. If the claims are that narrow, these do not anticipate; if the claims are broader (monitoring servers generally), they are the strongest anticipation candidates under § 102(e).
2. US 6,605,120 B1 (Fields et al., 2003) — dynamic state-based traffic distribution; § 102(e) candidate; maps to E1/E3/E4 if it discloses policy/rule creation on detected failure.
3. US 2007/0055764 A1 (Dilley et al., 2007) — Akamai request-directing based on monitored conditions; § 102(e) candidate; similar mapping.
4. US 6,976,090 B1 / US 2002/0010798 A1 (Ben-Shaul) — distributed application execution with policy-driven server selection; § 102(e) candidates.
5. Foreign art (EP 0817020, EP 0817444, GB 2354350, WO 00/14633, WO 00/26806, WO 00/41091, WO 00/52594, WO 00/78004, WO 01/39003) — all § 102(b) statutory-bar art. One or more of these (particularly WO 01/39003, May 2001, closest in time) may disclose late-1990s/2000 DNS failover/monitoring techniques; titles and full texts were not retrievable this session, so I cannot state with confidence that any one of them reads on all four elements.

Bottom line: Every listed reference was overcome by the examiner during prosecution (the patent issued), so none was deemed to read on the allowed claims as prosecuted. The most plausible § 102 threats in a validity challenge would be the Akamai-family references (3, 9, 19) and Fields (1) under § 102(e), and the pre-2001 foreign references under § 102(b) — but a definitive anticipation opinion requires (i) the full claim text from USPTO Patent Center, and (ii) full-text review of each candidate, neither of which was available in this session.

5. Caveats and recommended verification steps

• Claims text missing: retrieve the claims of 10116738 from USPTO Patent Center or the USPTO full-text database before treating any § 102 mapping as more than provisional. The claim set may include multiple independent method/system/CRM claims and specific dependent limitations (e.g., "monitored vs. managed servers," "load share/shed fraction," "trap handler," "broadcast of updated policies") that change the analysis materially.
• Titles/assignees of ~20 cited references not confirmed from retrieved snippets; the descriptions above are examiner-use inferences and should be replaced with verified bibliographic data from Google Patents/Espacenet for each number.
• Sandpiper CDN v. Microsoft (E.D. Tex. 2:25-cv-00664): from prior analysis, whether 10116738 is an asserted patent there remained unverified; that is litigation status, not prior art, but relevant if you're assessing validity risk.
• Recommended next searches (if you resume tool use): USPTO Patent Center for the claims; Google Patents "Citations" tab for 10116738 (full titles of all 33 references); and Espacenet for the EP/WO/GB documents' titles and abstracts.

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.