US 8156066

US Patent 8,156,066 B2 — Summary

Note on sourcing: The patent text you provided (from Google Patents, fetched 2026-08-26) is treated as authoritative. Search results from USPTO-adjacent aggregators (Google Patents, FreePatentsOnline, Unified Patents, Docket Alarm, CourtListener) were used to corroborate bibliographic and litigation facts. Where sources conflict, the Google Patents record prevails.

Bibliographic data

Minor caveat: The Unified Patents portal shows slightly different dates (priority/application dates of 2008-04-08/2009-04-08 and a "grant date" of 2009-10-14, which appears to be the application publication date). The Google Patents record and the patent text itself (provisional filed Apr. 9, 2008) support the dates in the table above.

Abstract

"An embodiment of a method includes receiving a content request including a first set of attribute values, using at least one of the attribute values from the first set of attribute values to determine a second set of attribute values, traversing a hierarchy of decision nodes, wherein each decision node implements business logic based on one of the attribute values from the first set of attribute values or the second set of attribute values, and generating a decision from a last node in the hierarchy, wherein the decision dictates how to respond to the content request."

Plain-language overview

The patent is directed to a content delivery network (CDN) architecture in which a content provider (a "customer" of the CDN) can define rules controlling how end-user requests for content are handled. A rule generator converts customer rule specifications into computer-executable business logic, implemented as a hierarchy of data-driven decision nodes (e.g., an XML-based decision tree), with default/exception paths at each node. A provisioning tool ingests geolocation-style IP-address attribute data and builds an IP-address attribute map. Both the business logic and the map are deployed to regional "request authorization servers" (RASs). At runtime, an edge-server agent extracts real-time attribute values from a content request (e.g., IP address, protocol, customer ID, file type, token), the RAS looks up semi-static attributes (country, city, ASN, etc.) from the IP map using the requester's IP address, optionally uses address-independent attributes (time/date/day-of-week), and traverses the decision hierarchy to yield a handling decision: allow (HTTP 200), deny (HTTP 4xx), or redirect (HTTP 3xx to alternate content). The customer-ID node at the top of the tree lets each customer's own rules govern downstream nodes.

Independent claims

Only claim 1 appears in the claim text provided (the Google Patents extract cuts off mid-claim-1 and lists 17 total claims). Accordingly, I can only authoritatively summarize claim 1; I flag the others as unverified.

• Claim 1 (computer program product — the only independent claim text available): A computer-readable medium storing instructions that cause a computing device to (a) receive a content request carrying a first set of attribute values; (b) use at least one of those attribute values to determine a second set of attribute values (i.e., derive semi-static attributes from the IP address via the map); (c) traverse a hierarchy of decision nodes, where each node applies business logic based on one attribute from either set; and (d) yield a decision from the last node in the hierarchy dictating how to respond to the request (allow/deny/redirect).

The specification's Summary describes three statutory embodiments — a computer-implemented method (receiving rules specifications; encoding them into rule-based business logic; generating an IP address map associating addresses with semi-static attribute values; deploying both to regional RASs; and, on request receipt, looking up semi-static values and applying the logic to render a handling decision), a computer program product (claim 1), and a system (edge server + administration server with agent and RAS executing rule-based business logic). It is highly likely claims 9 and 17 (or similar) are the other independent claims directed to the method and system, but I do not have authoritative text for claims 2–17 and will not speculate on their exact language.

Litigation / CAFC 2026 docket check

Searches of PTAB and court dockets show that Sandpiper CDN, LLC (the current assignee) has been litigating a portfolio of Level 3/Sandpiper CDN patents, including Sandpiper CDN, LLC v. Google LLC (C.D. Cal. 2:24-cv-03951), Sandpiper CDN, LLC v. Comcast (E.D. Tex. 2:24-cv-00886), and Sandpiper CDN, LLC v. [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.) (E.D. Tex. 2:25-cv-00664), with related PTAB IPRs (e.g., IPR2026-00095, IPR2025-00860, IPR2025-00969). However, those proceedings concern other patent numbers (e.g., 8,478,903; 10,924,573; 8,645,517; 9,021,112) — none of the search results I retrieved specifically names 8,156,066 in a CAFC 2026 docket or an IPR petition. I did not find any CAFC 2026 case specifically identifying 8156066. If you need definitive confirmation of whether 8156066 is asserted in any pending appeal, a direct search of the CAFC docket system (cafc.uscourts.gov) and USPTO Patent Center/PTAB would be the next step; I could not verify that from the searches available here.

I'll research litigation involving US Patent 8,156,066. Let me run several targeted searches.

The initial searches didn't surface specific cases. Let me run more targeted searches on litigation databases and the patent number in different formats.

The Sandpiper litigation appears in results but I need to verify whether patent 8,156,066 specifically is asserted. Let me dig deeper into the specific cases and IPR petitions.

I've reached the search limit for this session, so I'll consolidate the findings from the searches performed and from the prior analysis.

Answer: No confirmed litigation specifically naming US Patent 8,156,066 was found

Based on the searches available in this session (Docket Alarm, CourtListener, PacerMonitor, RPX, Unified Patents-related coverage), I did not find any district-court case, CAFC appeal, or PTAB proceeding that specifically names US Patent 8,156,066 B2 ("Rule-based content request handling") as an asserted or challenged patent.

What the searches did reveal (nearby, but not this patent)

The searches surfaced the active Sandpiper CDN, LLC enforcement campaign, which asserts a portfolio of Level 3 Communications-derived CDN patents. However, the patent numbers identified in those proceedings are siblings, not 8,156,066:

Notably, one RPX article enumerating the six patents in the Google complaint lists "8,595,778; 8,645,517; 8,719,886; 9,021,112; 10,924,573" plus 8,478,903 — 8,156,066 is not among them. The Microsoft complaint analysis likewise discusses 8,478,903 and 8,924,466, not 8,156,066.

Cautions / limitations

1. Search scope limitation. I could not query PACER, the CAFC docket system (cafc.uscourts.gov), or the Unified Patents case list directly in this session, and the general web searches did not return a page associating 8,156,066 with any case. It is possible that 8,156,066 is asserted in a complaint whose patent list is buried in exhibits (as with the Microsoft case, where the asserted patents appear in docket entries rather than the main complaint text), or in a case filed after my search results were indexed.
2. Consistency with prior analysis. The previously generated summary of this patent reached the same conclusion: no CAFC 2026 docket or IPR petition specifically identifying 8,156,066 was found. The searches here are consistent with that.
3. Recommended next steps for definitive confirmation:
   • Search the Unified Patents litigation portal (portal.unifiedpatents.com) for "8,156,066" directly.
   • Run a PACER query across C.D. Cal., E.D. Tex., D. Del., and W.D. Tex. for Sandpiper CDN complaints and check their Exhibit A patent lists.
   • Check USPTO Patent Center / PTAB for IPR/PGR petitions listing 8,156,066 (the Microsoft IPR exhibits reference "Exemplary Search Results from ppubs.uspto.gov," indicating the parties themselves have been checking which patents are in suit).
   • Check the CAFC docket for any appeal from the Comcast case (the IPR2026-00190 record references an April 2, 2026 order in Sandpiper v. Comcast, ECF No. 132, which suggests active litigation, but the patent(s) at issue there were not identified in my snippets).

Bottom line: As of the information retrievable in this session (April 26, 2026), I cannot identify any litigation with US Patent 8,156,066 as a named patent. If you need certainty for a clearance or diligence purpose, the direct PACER/Unified Patents/PTAB checks above are the authoritative next steps.

The initial searches surface the broader Sandpiper CDN IPR campaign but nothing yet specific to 8,156,066. Let me dig deeper with targeted searches.

Proceedings overview

Total count: 0 AIA trial proceedings on file for US 8,156,066. The canonical USPTO Open Data Portal block reports no IPR, PGR, or CBM proceedings for this patent as of the most recent ingest, and independent web searching corroborates that — I found no petition, institution decision, or Final Written Decision naming 8,156,066. Breakdown by status: 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution-denied. Bottom line for a defendant: every claim (1–17) of 8,156,066 is untested at the PTAB — there is no estoppel bar against any challenger, no canceled claim to exploit, and no prior IPR record to cite; the patent is not "hardened" by PTAB victory, it is simply unchallenged — and the district court record shows it is now being actively asserted, so the IPR window may be open right now.

No PTAB proceedings exist for 8,156,066 — what the absence means

There are no proceedings to profile. Per the structured USPTO ODP block: "The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest." Web searches for "8,156,066" IPR, "8156066" PTAB, "Rule-based content request handling" IPR, and Sandpiper-specific queries returned zero PTAB cases directed at this patent. I will not invent proceeding numbers, panels, or FWDs.

What I did find (and why it matters to a defendant):

1. 8,156,066 is now asserted in district court. In Sandpiper CDN, LLC v. Microsoft Corporation, No. 2:26-cv-00681 (E.D. Tex.), the complaint's Exhibit G is U.S. Patent No. 8,156,066 (per PacerMonitor: https://cdn.pacermonitor.com/public/case/66191669/Sandpiper_CDN,_LLC_v_Microsoft_Corporation). Sandpiper CDN, LLC (assignee per the 2024-04-26 assignment from Level 3) is the plaintiff. This is the first direct confirmation I have that 8,156,066 is in active enforcement.

2. The portfolio around it is under heavy PTAB fire — but not this patent (yet). Sandpiper/Level 3 sibling patents are the targets of a coordinated IPR campaign:

   • Google LLC v. Sandpiper CDN, LLC, IPR2025-00826 (U.S. 9,021,112) — trial instituted 2025-11-07 (greyb: https://ipverse.greyb.com/ptab-web/cases/case-details/IPR2025-00826).
   • Google LLC v. Sandpiper CDN, LLC, IPR2025-00860 / -00969 / -01010 (U.S. 10,924,573 and related) — filed 2025-05-01 (ai-lab.exparte.com).
   • Microsoft Corporation v. Sandpiper CDN, LLC, IPR2026-00095 — filed 2025-11-03, trial instituted 2026-04-22, panel of APJs Weatherly, McShane, Cygan (Docket Alarm: https://www.docketalarm.com/cases/PTAB/IPR2026-00095/).
   • Microsoft Corporation v. Sandpiper CDN, LLC, IPR2026-00174 (U.S. 9,762,692) — filed 2025-12-17 (RPX Insight).
   • Microsoft Corporation v. Sandpiper CDN, LLC, IPR2026-00190 (U.S. 9,456,053) — filed 2025-12-29, discretionary denial 2026-05-15 (greyb).

   None of these petitions name 8,156,066. They attack sibling patents in the same CDN family (e.g., 9,021,112; 10,924,573; 9,762,692; 9,456,053).

3. A defensive aggregator is circling the portfolio. Unified Patents published an investigation notice titled "Sandpiper CDN patents being investigated" (2026-08-11), stating it is using its Pearl tool to chart prior art against Sandpiper CDN LLC, "an NPE" (https://www.unifiedpatents.com/insights/2026/8/11/sandpiper-cdn-patents-being-investigated). Unified Patents historically files or sponsors IPRs — a signal that a petition against 8,156,066 (or another portfolio patent) may be in preparation.

Strategic summary

Claim-level status of 8,156,066: All 17 claims are UNTESTED at the PTAB — none canceled, none sustained in an FWD, none even challenged. "Sustained" would be the wrong word; the correct characterization is virgin. The only independent claim text publicly available (claim 1, the computer-program-product claim directed to traversing a hierarchy of decision nodes) has never been through an AIA trial. So a defendant cannot point to any PTAB cancellation, and the patent owner cannot point to any PTAB validation — both sides start from a blank PTAB record.

Estoppel landscape: Because no IPR has ever been filed against 8,156,066, there is no § 315(e)(2) estoppel binding anyone. Every § 102 / § 103 / § 112 ground that could have been raised is still available to any defendant. The only timing constraint is the one-year bar under § 315(b): a defendant served with a complaint asserting 8,156,066 must file its IPR petition within one year of service. Given that the 2:26-cv-00681 Microsoft case is a 2026 filing, the window for that defendant is likely still open — but it is finite and should be treated as urgent. Note also the district court docket shows the parties litigating related Sandpiper patents already have developed prior-art records (e.g., Microsoft's IPR2026-00095 exhibits reference the Sandpiper v. Google/Comcast/Microsoft complaints), so art that works against the siblings — e.g., the Dilley/Pai/Wang and Newton-471-type CDN references being used against 10,924,573 — should be screened against 8,156,066's rule-based decision-tree claims immediately.

Pattern signals: This is a coordinated, multi-petitioner campaign (Google, Microsoft, Comcast-related defendants) against the Sandpiper/Level 3 CDN portfolio, with Unified Patents publicly investigating the portfolio — but 8,156,066 has so far escaped scrutiny. That is unusual for a patent that is being asserted: well-asserted patents in this portfolio attract IPRs within months of the complaint. The most plausible explanations are (a) the patent was only recently added to a complaint (the 2:26-cv-00681 filing), so challengers' one-year clocks are still running; or (b) challengers are prioritizing higher-value claims in the portfolio first. Either way, the absence of PTAB activity on 8,156,066 should be treated as a temporary state, not a durable one.

Recommended next steps

• *If you are the defendant in Sandpiper CDN, LLC v. Microsoft Corp., 2:26-cv-00681 (E.D. Tex.)* (or any other case where 8,156,066 is asserted): do not assume the PTAB is irrelevant because no IPR exists. Confirm the service date and calendar the § 315(b) one-year deadline. Run a prior-art search against claim 1 and its dependents now — focusing on 1990s–2000s CDN/geolocation/access-control art (the same art pool Google and Microsoft are using against 9,021,112 and 10,924,573). If the art is strong, file an IPR; there is no estoppel obstacle because the PTAB record is blank.
• There is no FWD to link — do not cite any PTAB decision as if it involved 8,156,066. The only authoritative source for "no proceedings" is the USPTO ODP block in this prompt; the corroborating litigation context is the PacerMonitor docket (Exhibit G = 8,156,066) and the Unified Patents investigation notice linked above.
• Re-verify directly before the IPR window closes: the ODP ingest may lag, and petitions filed in late 2025 / H1 2026 (e.g., IPR2026-xxxxx series) may not be indexed. Check USPTO Patent Center / PTAB E2E for any petition naming 8,156,066, and monitor the Unified Patents investigation (2026-08-11 notice) for a sponsored petition.
• If no proceeding exists by the time you act, say so plainly — the absence is itself the actionable signal: a patent that has survived multiple portfolio IPRs by not being challenged is not hardened; it is the next target.

I've hit the search-step limit, but I have enough corroborated material to reconstruct the record. Important transparency note up front: I could not open the USPTO Assignment Center directly from this environment. The reel/frame data below comes from a PTAB exhibit listing (IPR2026-00190) and Google Patents legal events, corroborated by RPX reporting and the Sandpiper complaints. Correspondents of record are not verifiable from the sources I could reach, and I flag that rather than guess.

Inventors

Pattern check: All four inventors executed assignments to Level 3 Communications, LLC (recorded 2009-07-31), consistent with in-house employees of Level 3's CDN group at filing (provisional Apr. 9, 2008; non-provisional Apr. 9, 2009). I found no evidence of the inventors departing Level 3 en masse within 12 months of filing, and no inventor-departure anomaly. Unlike the older Sandpiper Networks patents in this family (e.g., 8,478,903 with Farber/Swart), this patent originated at Level 3, not at Sandpiper Networks/Digital Island/Savvis.

Original assignee

Level 3 Communications, LLC (named assignee on the issued patent; original assignee of record).

• Product embodying claims: Yes. The patent describes Level 3's own CDN request-authorization architecture (edge-server agents, regional request-authorization servers, IP-attribute maps, rule-based decision hierarchies). Level 3 operated one of the largest CDNs in the U.S. and the patent's specification is written around that production architecture.
• Line of business: Tier-1 telecom / content delivery network operator.
• Current status: Still a legal entity, now a wholly owned subsidiary of Lumen Technologies (formerly CenturyLink, which acquired Level 3 in 2017). Per the Sandpiper v. Google complaint (2:24-cv-03951), Level 3 "decided to exit the CDN market in 2023 and began selling off its CDN assets"; it sold the asserted patents to Sandpiper CDN in early 2024. Not bankrupt — this was a strategic divestiture, not a bankruptcy liquidation.

Assignment timeline

Assignment Center records exist for this patent (two recorded conveyances). Reel/frame for the 2009 entry is not independently verified; the 2024 entry's reel/frame comes from the IPR2026-00190 exhibit list.

• 2009-07-31 (recorded; execution date not separately verified) — Reel/frame not verified (Google Patents legal event only; USPTO Assignment Center not directly accessible)

  • Conveyance: Assignment (inventors → employer)
  • Assignor: Jin-Gen Wang; Bill Hopkins; David Reisfeld; Steven P. Higgins
  • Assignee: Level 3 Communications, LLC
  • Correspondent: Not available from sources searched — do not have the attorney of record for this filing.
  • Context: Routine inventor-to-employer assignment coincident with prosecution of the application.

• 2024-04-24 (executed, per RPX) / recorded 2024-04-26 — Reel 068256 / Frames 0091–0115 (per IPR2026-00190, Petitioner Exhibit 1036, "Patent Assignment Cover Sheet from Level 3 Communications, LLC to Sandpiper CDN, LLC")

  • Conveyance: Assignment (bulk portfolio transfer — 80+ U.S. patents per RPX)
  • Assignor: Level 3 Communications, LLC
  • Assignee: Sandpiper CDN, LLC
  • Correspondent: Not verified from available sources. Litigation counsel for Sandpiper's first suit was Shook, Hardy & Bacon L.L.P. (filed the Google complaint, per RPX), but I cannot confirm they were the assignment correspondent of record — flagging as unknown rather than inferring.
  • Context: Transfer-to-asserter. Sandpiper CDN, LLC was formed in Delaware on March 21, 2024 (RPX), received the Level 3 portfolio, and filed its first infringement suit ~2 weeks after the recording date (May 10, 2024, against Google). The complaint states the sale was agreed March 29, 2024.

No other recorded assignments found. Notably, there is no recorded intermediate chain (no Savvis/Digital Island/Sandpiper Networks conveyances for this patent — it did not exist until 2009) and no security agreements, mergers, or releases on the records I could verify.

Timeline diagram

timeline
    title Ownership of US 8156066
    2008 : Provisional filed
    2009 : Filed by Level 3 Communications
         : Inventors assign to Level 3
    2012 : Patent issued
    2024 : Level 3 assigns to Sandpiper CDN LLC
         : Sandpiper sues Google
         : Sandpiper sues Comcast
    2025 : Sandpiper sues Microsoft
    2026 : 8156066 asserted vs Microsoft

NPE / troll-pattern signals

1. Shell-entity transfer — present. Sandpiper CDN, LLC was formed in Delaware on 2024-03-21 (RPX), received 80+ patents from Level 3 (Reel 068256 / Frames 0091–0115, recorded 2024-04-26), and does not operate a CDN. Its own USPTO PTACTS filing describes the entity as managing the portfolio and lists a "Manager, IP Licensing" (Jim Amend); its public contact line solicits "partnership and licensing opportunities." It is co-owned by Andrew Swart, former Sandpiper Networks CEO — i.e., a portfolio-management/assertion vehicle, not an operating company.

2. Known asserter in the chain — present. Sandpiper CDN, LLC is a high-frequency plaintiff surfaced by RPX (RPX Insight coverage of the Google, Comcast, and Microsoft suits). It is not on the classic enumerated list (Acacia, Marathon, IV, etc.), but it matches the "entity surfaced by RPX as a high-frequency plaintiff" prong: suits against Google (2:24-cv-03951, C.D. Cal., 2024-05-10), Comcast (2:24-cv-00886, E.D. Tex., 2024-11-01), and Microsoft (2:25-cv-00664 and 2:26-cv-00681, E.D. Tex., 2025–2026). 8,156,066 is specifically asserted in 2:26-cv-00681 (Exhibit G = Patent No. 8,156,066 per PacerMonitor).

3. Repeat correspondent across the chain — unclear. I could not retrieve the correspondents of record for either recorded assignment (Reel 068256 and the 2009 filing). Shook, Hardy & Bacon L.L.P. filed Sandpiper's first complaint (RPX), but a single litigation appearance is not a recurrence finding. This is the one signal I could not test with available sources — verify on assignmentcenter.uspto.gov.

4. Cascading transfers — not present. Only two recorded conveyances for this patent (inventors→Level 3 in 2009; Level 3→Sandpiper in 2024). No chained LLCs, no <24-month multiple-hop pattern for this specific patent.

5. Pre-litigation transfer — present (portfolio-level, with a caveat). The Level 3→Sandpiper assignment was recorded 2024-04-26 (Reel 068256/0091–0115), and Sandpiper filed its first suit (Google) on 2024-05-10 — ~2 weeks later. Strictly, 8,156,066 was not in the Google suit; the first suit naming this patent is the Microsoft case 2:26-cv-00681 (2026), which is >6 months after the transfer. But the transfer-to-assert pattern for the portfolio is unambiguous: assignment recorded, entity formed ~5 weeks prior, first complaint filed 2 weeks after recording.

6. Bankruptcy fire-sale — not present. Level 3 was acquired by CenturyLink/Lumen in 2017 (corporate acquisition, not bankruptcy). The 2023–2024 CDN divestiture was a strategic exit ("rampant infringement … depressed its revenue and profit" per Sandpiper's own complaint), not a Chapter 7/11 proceeding.

7. Privateering — present. Level 3 (an operating CDN that shipped the claimed architecture) exited the CDN market and transferred 80+ patents to a newly formed Delaware assertion LLC that immediately sued Level 3's CDN competitors (Google, Microsoft, Comcast). RPX explicitly notes this "is not Level 3's first transfer to an NPE" — from April 2017 Level 3 moved ~110 patent assets to Optic153 LLC, a subsidiary of Equitable IP Corporation. The pattern (operating company → assertion vehicle → competitor suits) is the classic privateering structure, though I found no SEC filing expressly confirming a revenue share or license-back to Lumen.

8. Defensive aggregator (anti-NPE) — not present. The chain terminates at Sandpiper CDN, LLC, an asserting entity. There is no RPX, AST, LOT, Unified Patents, or OIN endpoint.

Verdict

NPE — high confidence.

Multiple strong signals converge: (1) the patent moved from an operating company to a Delaware LLC formed five weeks before the transfer was recorded (2024-03-21 formation; Reel 068256/Frames 0091–0115 recorded 2024-04-26); (2) that LLC filed its first infringement suit two weeks after recording (Sandpiper CDN v. Google, 2:24-cv-03951, 2024-05-10) and has since sued Comcast and Microsoft, with 8,156,066 expressly asserted in Sandpiper CDN v. Microsoft (2:26-cv-00681, Ex. G); and (3) the assignor, Level 3/Lumen, had previously used the same privateering playbook via Optic153/Equitable IP (RPX). This is a transfer-to-asserter chain, not an operating-company assertion — Sandpiper CDN ships no CDN product and markets licensing, not services.

Verification: USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search patent number 8156066; confirm Reel 068256/Frames 0091–0115 and pull the correspondents of record, which I could not retrieve). Corroborating: Google Patents legal events (https://patents.google.com/patent/[US8156066](/patent/US8156066)/en), RPX Insight (https://insight.rpxcorp.com/news/details?searchq=ents%3A%2813488673%29), Docket Alarm IPR2026-00190 exhibit list (https://www.docketalarm.com/cases/PTAB/IPR2026-00190/Microsoft_Corporation_v._Sandpiper_CDN_LLC/), and the Sandpiper CDN v. Microsoft docket (2:26-cv-00681, https://cdn.pacermonitor.com/public/case/66191669/Sandpiper_CDN,_LLC_v_Microsoft_Corporation).

The searches surfaced the patent record but not the full citation list. Let me dig into the cited references (the Unified Patents portal indicated 19 patent references) and the Google Patents citation pages.

Let me try to access the actual citation list from Google Patents and the PCT family member (WO2009126829A2) which would share citations.

I've hit the tool-call limit for this session, so I'll consolidate what is verifiable from the searches I did run and clearly flag what could not be retrieved. Per the operating rules, I will not fabricate the prosecution citation list — the exact 19-reference list could not be pulled from the USPTO/Google Patents citation tabs in this session, and I'll say so explicitly rather than guess at numbers.

Prior Art Analysis — US 8,156,066 B2 ("Rule-based content request handling")

1. What the searches confirmed about the citation record

• The application publication US-2009-0259611-A1 (same disclosure as 8,156,066) is indexed by the Unified Patents portal as having "Patent Art (19)" (i.e., 19 U.S. patent documents cited during prosecution), "Non-Patent Literature (0)", and "Referenced By (27)" (27 later patents citing it). See https://portal.unifiedpatents.com/patents/patent/US-20090259611-A1.
• The patent is cited by later patents/applications found in the searches, including US 8,601,526 B2, EP 2,352,312 A2, US 2019/0124003 A1, and US 11,843,682 B2 — these are citing references (post-dating 8,156,066), not prior art, so they are excluded from the §102 analysis.
• The family member WO 2009/126829 A2 (PCT/US2009/040107) and EP 2,263,159 B1 share the disclosure; the PCT publication's International Search Report would normally list the same X/Y references, but I could not retrieve that ISR's reference list from the searches performed.
• Critical caveat: I could not retrieve the actual 19-item "Patent Citations" list for 8,156,066 from the Google Patents citation tab (the authoritative source is https://patents.google.com/patent/[US8156066B2](/patent/US8156066B2)/en → "Citations"). The analysis below therefore distinguishes (A) confirmed facts from (B) candidate prior art identified from the technical field and from citations commonly associated with this Level 3/Sandpiper CDN family. The candidate list should be treated as a hypothesis to verify against the prosecution file history (PAIR/Patent Center) and the Google Patents citation tab.

2. The claim set being analyzed

Only claim 1 text is authoritative in the materials provided (claims 2–17 are counted in the Google Patents header but their text was cut off). Claim 1 requires, in substance:

1. receiving a content request including a first set of attribute values;
2. using at least one of the attribute values from the first set to determine a second set of attribute values (specifically: IP address → semi-static attribute lookup);
3. traversing a hierarchy of decision nodes, each node implementing business logic based on one attribute value from the first or second set; and
4. yielding a decision from a last node in the hierarchy dictating how to respond to the request.

Because claims 2–17 are unavailable, claim-mapping below is limited to claim 1, with observations on the method/system embodiments recited in the specification's Summary (which likely correspond to the other independent claims).

3. Candidate most-relevant prior art (pre-AIA § 102 analysis)

The invention combines four technical strands: (i) CDN request routing/delivery, (ii) IP-address-to-geographic/network-attribute mapping, (iii) rule/decision-tree business logic, and (iv) token/URI-based request authorization. The most relevant prior art falls in those strands. All references below predate the effective filing date of April 9, 2008 (and all but the last also predate the April 9, 2008 provisional priority date), so they are available under § 102(a)/(b) (and, where applicable, § 102(e) if earlier-filed). Caveat: these are candidates, not confirmed citations.

(a) Foundational CDN content-delivery and routing patents

(b) IP-address → attribute mapping (the "second set of attribute values")

(c) Rule-based access control / decision trees

(d) Token/URI-based authorization

4. Direct § 102 assessment for claim 1

On the available record, no single confirmed prior-art reference cleanly anticipates all four elements of claim 1. The reason is structural: claim 1's combination of (a) receiving a request with a first attribute set, (b) deriving a second attribute set from one of the first-set values (the IP address), (c) traversing a hierarchy of decision nodes, and (d) yielding an allow/deny/redirect decision from the last node is a compound of CDN routing, geolocation, and rule-engine concepts that, on the candidate list above, are spread across separate references:

• (b) is best covered by the Quova-type geolocation art (e.g., 6,684,250) and CDN art (6,185,598 — which derives routing attributes from the requester's network position).
• (c) is best covered by rule-based CDN access-control art (e.g., 7,240,106, if verified) and general policy-decision-tree art.
• (d) (explicit allow/deny/redirect decision vocabulary with HTTP 200/3xx/4xx codes) appears in various content-protection and redirect references (e.g., 6,754,699).

Accordingly, the realistic invalidity theory for claim 1 is obviousness under 35 U.S.C. § 103 (e.g., Quova-type IP-attribute mapping combined with a CDN rule-based handler), rather than § 102 anticipation by any single reference. For the method and system embodiments in the specification's Summary (likely independent claims 9 and 17), the same candidate art applies, with the system claim additionally requiring the edge-server/agent/administration-server/RAS architecture — a combination most likely addressed by the CDN routing references (6,185,598; 7,133,905) plus the geolocation art.

5. Verified next steps to obtain the authoritative citation list

The 19 cited patent references are viewable at:

• Google Patents citation tab: https://patents.google.com/patent/US8156066B2/en (click "Citations") — this was not fully retrievable through the search tool in this session.
• USPTO Patent Center / Global Dossier: application 12/421,084 — the IDS and examiner's cited references are in the file wrapper.
• Unified Patents portal (confirmed it indexes "Patent Art (19)"): https://portal.unifiedpatents.com/patents/patent/US-20090259611-A1.

6. Confidence statement

• High confidence: bibliographic data; Unified Patents' count of 19 cited patent references and 27 citing patents; the candidate prior-art categories.
• Medium confidence: the specific citation numbers in tables (a)–(c). US 6,185,598, US 6,754,699, US 7,133,905, US 6,996,616, and US 6,684,250 are well-known, verifiable patents I'm confident exist with the dates given; US 7,240,106 and US 6,757,740 and the token-authorization category are flagged for verification and should not be cited in a filing without confirmation.
• Not retrieved: the exact 19-item prosecution citation list; claims 2–17 text. I will not speculate on the language of claims 2–17, and any § 102 mapping to those claims would be premature until their text is obtained.

Two of the three flagged references are now confirmed (6,757,740 and 6,684,250), but the search for "7,240,106" surfaced a publication (US20030174648A1, "Content delivery network by-pass system," Mea Wang/Edgix) rather than the issued patent. Let me verify the exact number and content of the "by-pass system" reference and confirm the foundational CDN references.

I have hit the search-step limit, but the searches I completed materially upgraded the prior-art record. Three important verification outcomes before the analysis:

1. US 6,757,740 B1 is confirmed — Parekh et al., Digital Envoy, "Systems and methods for determining, collecting, and using geographic locations of internet users," filed Mar. 31, 2000, granted June 29, 2004. Its abstract expressly teaches that with IP-derived geographic data, "web sites can target content, advertising, or route traffic depending upon the geographic locations of their visitors." It is also confirmed as active IPR ammunition (Exhibit 1061 in Google's IPR2025-00124).
2. US 6,684,250 B2 is confirmed — Anderson et al., Quova, "Method and apparatus for estimating a geographic location of a networked entity," filed Apr. 3, 2001, granted Jan. 27, 2004.
3. The "Content delivery network by-pass system" reference is now verified under its publication number US 2003/0174648 A1 (Mea Wang, Edgix, filed Oct. 17, 2001, published Sep. 18, 2003) — not as "US 7,240,106" (Cochran). Per the operating rules, I treat the live search result as ground truth: the earlier "US 7,240,106 / Cochran" attribution was wrong or unverifiable, and I flag it as such. US 6,185,598 B1 (Farber, Digital Island) is also confirmed via multiple sources.

Obviousness Analysis under 35 U.S.C. § 103 — US 8,156,066 B2 ("Rule-Based Content Request Handling")

I. Scope and limits of this analysis

Only claim 1 text is authoritative in the available record; claims 2–17 exist (per the Google Patents header) but their text was not retrievable. This analysis therefore maps combinations to claim 1's four elements, and addresses dependent-claim themes (token/time-constraint attributes) only conditionally. The specification's Summary describes method and system embodiments (likely independent claims 9 and 17) that recite the same rule-generation/IP-map/deployment architecture; the combinations below apply to those with the additional edge-server/agent/RAS structural limitations supplied by the CDN references.

Claim 1 (parsed):

• [1a] receiving a content request including a first set of attribute values;
• [1b] using at least one of the attribute values from the first set to determine a second set of attribute values (per the spec: IP address → semi-static attributes via an IP map);
• [1c] traversing a hierarchy of decision nodes, each node implementing business logic based on one attribute value from the first or second set;
• [1d] yielding a decision from a last node in the hierarchy dictating how to respond to the content request.

II. Legal framework

Under Graham v. John Deere Co., 383 U.S. 1 (1966), obviousness turns on (1) the scope and content of the prior art, (2) differences between the prior art and the claims, (3) the level of ordinary skill, and (4) secondary considerations. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), eliminated any rigid "teaching-suggestion-motivation" test and instructs that a combination of known elements "according to known methods" that "yields predictable results," or is driven by "a design need or market pressure to solve a problem," is obvious — and that a PHOSITA is "a person of ordinary creativity, not an automaton." The combination analysis below applies KSR's framework.

III. Person of ordinary skill in the art (PHOSITA)

A PHOSITA as of the April 9, 2008 priority date would have: a B.S. (or equivalent) in computer science/engineering; roughly 2–4 years of experience in content delivery networks, HTTP/RTMP streaming protocols, IP networking, server-side access control, and IP geolocation services; working familiarity with the CDN art (Akamai, Digital Island, Edgix/Speedera) and geolocation vendors (Quova, Digital Envoy); and routine familiarity with rule engines / decision trees for request filtering and policy enforcement. Such a person would regard IP-address-to-geography mapping as a commodity service — by 2007, per a contemporaneous industry article, ~35% of U.S. online merchants used geolocation tools (CircleID, Feb. 5, 2007), and the same article documents that content providers were already being pressured to use IP filtering to comply with regional laws (citing the Yahoo! case and MLB.TV blackouts).

IV. Combination A — Farber '598 + Anderson '250 (and/or Parekh '740): the CDN request-handling framework with IP-derived attribute lookup

Element coverage

Motivation to combine — KSR rationale

• Same field, complementary disclosures. Both references operate in Internet content delivery/request handling. Farber provides the CDN-side decision point; Anderson/Parekh provide the attribute-derivation layer. The '066 spec itself concedes the two strands were mature: it names Quova™ as the source of its raw IP attribute data and describes the CDN infrastructure in which its RASs sit.
• Express teaching of the combination. Parekh '740's abstract does not merely permit the combination — it recommends it: geographic location of visitors is obtained so web sites can "target content, advertising, or route traffic depending upon the geographic locations of their visitors." That is a direct, pre-2004 articulation of claim 1's [1b]→[1d] flow (derive location from IP; use it to decide how to handle the request).
• Design need / market pressure (KSR). By 2007 the industry was publicly wrestling with geographic licensing compliance (sports blackouts, the Yahoo! case); the CircleID article documents that content providers were using Quova/Digital Envoy data precisely to gate content by region. A PHOSITA implementing Farber-style request handling for a content provider with licensing constraints would have had every reason to feed the requester's IP address into the Quova/Digital Envoy map and use the returned country/city/ASN attributes in the handling decision. This is "a design need ... known in the field of endeavor" pushing toward the combination.
• Predictable result. Substituting a richer attribute lookup (geographic/network attributes) for Farber's cost-group lookup, at the same decision point, yields the predictable result of policy-aware handling. No re-architecture is required.

What Combination A does not cover

Farber's decision logic is a routing selection, not an explicit multi-node decision hierarchy with per-node default paths ([1c]). Anderson/Parekh disclose a lookup service, not a decision tree. Combination A alone therefore does not cleanly satisfy [1c].

V. Combination B — Combination A + Wang US 2003/0174648 A1 ("Content delivery network by-pass system"): add the rule-based decision hierarchy

The reference (verified)

US 2003/0174648 A1 (Mea Wang, Edgix; filed Oct. 17, 2001; published Sep. 18, 2003) discloses a CDN edge platform in which content requests are handled according to classes/rules — including deciding whether to serve through or "bypass" the CDN — and discusses request handling for HTTP, SSL, and FTP, plus authentication options (cookie-based, querystring-based, and HTTP authentication, per its description of Digital Island's FootprintSecure). The earlier draft's "US 7,240,106 / Cochran" citation is not confirmed; the verified document is the Wang publication.

Element coverage

Motivation to combine — KSR rationale

• Known problem, known solution. The '066 patent solves: "content providers typically have limited control in how, or to whom, the content is distributed." Wang shows a CDN edge making rule-based handling decisions; Farber shows a CDN edge making redirect decisions; Anderson/Parekh show how to learn who the requester is (geographically/network-wise). Assembling these three is combining known elements "according to known methods" to "yield predictable results" — the core KSR formulation.
• Interchangeable components in a single system. A PHOSITA building a CDN authorization layer would take the decision logic from the rule-based art (Wang), feed it the attribute set from the geolocation art (Anderson/Parekh), and place the decision point in the request path from the CDN art (Farber). All three are in the same field; each reference's disclosure presupposes the others' existence (Wang's background discusses Digital Island, the assignee of Farber).
• The decision hierarchy is a standard construct. The '066 spec's own tree (customer-ID node → country node → protocol node → allow/deny/redirect leaf nodes, with default paths at every node) is a textbook exception-based decision tree as used in firewall rule tables, policy engines, and HTTP access control — the "default path at every node" is the standard catch-all rule. Under KSR, the PHOSITA is presumed to have ordinary creativity to arrange such known nodes hierarchically.
• No teaching away. Nothing in Farber, Anderson/Parekh, or Wang discourages combining geolocation-derived attributes with rule-based CDN request handling. To the contrary, Parekh '740 affirmatively teaches routing traffic based on visitor geography.

Element coverage summary for Combination B

• [1a]: Farber (request receipt at CDN edge; request carries IP + resource attributes). Also Wang (request handling at edge).
• [1b]: Anderson '250 / Parekh '740 (IP → country/city/ASN/connection-speed attribute lookup). Farber partially (cost-group derivation).
• [1c]: Wang (rule/class-based request handling) + routine decision-tree implementation.
• [1d]: Farber (serve/redirect), Wang (serve/bypass), and the allow/deny/redirect vocabulary of HTTP access control (3xx/4xx codes were standard long before 2008).

VI. Alternative and substitute anchors (all pre-2008)

VII. Graham factor analysis

1. Scope and content of the prior art. Mature by 2008: CDN request routing/redirection (Farber '598; Swildens '699; Dilley '905), IP geolocation as a commercial service with patents expressly teaching traffic routing based on visitor location (Anderson '250; Parekh '740), and rule/class-based CDN request handling (Wang '4648). The '066 specification itself acknowledges the Quova™ data source and the CDN context, confirming both strands were in the field's toolkit.
2. Differences between prior art and claim 1. The principal differences are (a) the explicit recitation of a "hierarchy of decision nodes" with per-node attribute-based switching, and (b) the explicit allow/deny/redirect decision vocabulary. Neither is a patentable advance: (a) is the standard structure of every rule/policy engine and firewall access-control list, and (b) is the standard HTTP 2xx/3xx/4xx response vocabulary. No limitation of claim 1 recites a new technical mechanism, data structure, or protocol; the "IP address map" is the Quova/Digital Envoy lookup, and the "hierarchy" is a conventional decision tree.
3. Level of ordinary skill. Moderate — as defined in § III; such a person routinely integrates geolocation APIs into CDN/access-control products (the 2007 industry data shows this was mainstream).
4. Secondary considerations. No evidence found of long-felt need, commercial success attributable to the claimed features, unexpected results, copying, or industry skepticism. The PTAB record is blank (no IPR/PGR has ever been filed on 8,156,066), so there is no FWD praising the claims' validity, and no objective indicia anywhere in the record reviewed. Absence of objective indicia supports, rather than rebuts, obviousness.

VIII. Why a PHOSITA would have been motivated — consolidated rationale

1. Same field, complementary components. All combination references address handling content requests in distributed networks; each solves a piece the others presuppose (CDN decision point + attribute derivation + rule logic).
2. Express roadmap in the art. Parekh '740 literally instructs routing traffic based on IP-derived visitor geography — the heart of the '066 invention.
3. Known problem with commercial urgency. Geographic licensing restrictions (sports blackouts, regional broadcast rights) were widely publicized by 2007 and drove the very existence of the Quova/Digital Envoy services; implementing a geographic access rule at a CDN edge was the natural, market-pressured solution.
4. Predictable combination of known elements. Decision trees with default branches, IP-address lookup tables, and HTTP allow/deny/redirect responses were all individually conventional; KSR holds that the combination is obvious when it yields only the predictable sum of those parts.
5. No teaching away and no unexpected interaction. The references are compatible; nothing in them suggests the combination would fail or degrade performance.

IX. Counterarguments and responses (the patent owner's likely case)

• "No single reference teaches the full hierarchy with per-node attribute switching." True — which is why this is a § 103 combination case, not § 102. The hierarchy is the PHOSITA's routine arrangement of rule-engine nodes; KSR forecloses treating "the art was not combined before" as proof of non-obviousness.
• "The customer-ID-rooted multi-tenant tree is a specific, advantageous design." It is a design choice — rooting a rule tree at a tenant identifier is how every multi-tenant policy system partitions rules. Routine.
• "The second attribute set is derived from the IP address specifically." Anderson '250 and Parekh '740 are IP-address-lookup patents; Farber derives routing attributes from client network position. The claim adds nothing beyond pointing the lookup at the request's IP address — the exact use those patents teach.
• "Token/time-constraint features are distinctive." Possible for some dependent claims, but time-limited URL tokens were standard pre-2008 streaming/CDN security (querystring/cookie auth is even noted in Wang '4648). The dependent-claim text must be obtained before this can be assessed fairly.

X. Recommended primary grounds (if drafting an IPR/invalidity contention)

XI. Confidence statement and verification caveats

• High confidence: Farber '598, Anderson '250, Parekh '740, and Wang '4648 are verified as existing with the dates above; the geolocation→content-routing motivation is verified by Parekh '740's abstract and the 2007 industry literature; the PTAB record for 8,156,066 is blank (no estoppel, no FWD).
• Medium confidence: US 6,754,699 (Swildens) and US 7,133,905 (Dilley) — well-known but not re-verified this session; verify numbers/dates before filing.
• Flagged correction: "US 7,240,106 B2 (Cochran)" from the prior prior-art section was not confirmed; the verified "content delivery network by-pass system" document is US 2003/0174648 A1 (Mea Wang, Edgix). Do not cite 7,240,106 without confirmation.
• Not available: claims 2–17 text; the exact 19-reference prosecution citation list. The analysis of claim 1 is authoritative; dependent-claim analysis must await their text.

Bottom line: Claim 1 of US 8,156,066 is a straightforward, KSR-style aggregation of three mature, pre-2004 components — CDN request handling (Farber '598), IP-address attribute mapping expressly used to route traffic (Parekh '740 / Anderson '250), and rule/class-based edge request handling (Wang '4648). The strongest § 103 ground is Farber '598 + Parekh '740 + Wang '4648, with a strong motivation record drawn from Parekh's own abstract and the documented 2004–2007 industry practice of geolocation-based content gating. Secondary considerations are absent from the record, and the blank PTAB history means the § 315(b) one-year window is the only timing obstacle for a defendant.