US 8280819

I'll verify the patent's details against current sources and check for any litigation or CAFC 2026 activity.

Let me search more specifically for litigation and CAFC 2026 activity involving this exact patent number.

Verification status (read first)

I searched for the literal string "8280819" / "8,280,819" against USPTO PTAB records, district-court dockets, and Federal Circuit 2026 opinions/orders. No litigation, PTAB (IPR/PGR/CBM) proceeding, or 2026 CAFC appeal involving this exact patent number appeared in my search results. The only substantive hits were the patent's own Google Patents record, a third-party "cited-by/cited-in" listing, and a third-party valuation aggregator. I cannot certify the absence of such proceedings — my search coverage of PACER, the CAFC docket, and PTAB is not exhaustive, and the CAFC 2026 docket is a moving target. Treat "no 2026 CAFC activity found" as a search result, not a legal conclusion.

Everything below that is not flagged as unverified comes from the authoritative Google Patents full text of US 8,280,819 B2 (fetched 2026-09-30).

Bibliographic data

Note the unusually long pendency: filed July 2004, published January 2006, granted October 2012 — roughly eight years. The granted claim set is materially narrower and differently framed than one would expect from the 2004 disclosure, and in particular the granted independent claims recite a query-string-driven frame-sizing operation that corresponds to the FIG. 7 embodiment. I did not retrieve the prosecution-history file wrapper, so I cannot state with confidence which specific art or rejection drove that amendment — flagging as unverified.

Abstract (as issued)

"A method and apparatus for securely displaying and communicating trusted and untrusted internet content via a web browser is described. In a preferred embodiment, the invention is an electronic marketplace system in which auction-related content is displayed in one window of a customer's web browser while item-related content is displayed in a second window of the customer's web browser, such that the auction-related content and the item-related content are substantially prevented from substantially interacting. The invention further provides a method and apparatus for communicating predetermined information between multiple documents opened in multiple web browser windows, where the documents are served from multiple domains."

The underlying technology in one paragraph

The patent attacks the problem of seller-supplied HTML in an online marketplace listing page (eBay is the worked example) being able to script against, spoof, or exfiltrate the marketplace's own trusted content. Rather than filtering malicious markup, it architecturally isolates the two content classes on two different domains — the filing names ebay.com for trusted content and not-ebay.com for untrusted content — and relies on the browser's cross-frame/cross-domain security feature to block them from interacting when rendered in two separate browser views (an IFRAME in the preferred embodiment). Because the browser nonetheless permits "navigation" instructions across domains via URL, the patent adds a third, mediating view: a document on Domain2 builds a URL containing data (e.g., preferred frame size) as a query string, points the third view at Domain1, the Domain1 document parses or receives that query string, and — since it is same-domain with Doc1 — hands the value to Doc1 through the DOM. A symmetric path (Doc4 on Domain2) returns data to Doc2. HTML form POST/GET is disclosed as an alternative to query strings, and server-side parsing is disclosed as an alternative to client-side parsing.

Independent claims — plain language

The three independent claims (1, 8, 9) are substantively the same subject matter cast in the three statutory classes — non-transitory CRM (claim 1), method (claim 8), and system/means-plus-function (claim 9) — with near-identical wording. Reproduced in plain language using claim 1 as the model:

Claim 1 — One or more non-transitory computer readable media storing instructions that cause a processor to:

1. Store trusted content on a first server on a first domain.
2. Receive untrusted content from a user of a web site and store it on a second server on a second domain.
3. Receive, at a web server system and from a web browser, a request for a first set of trusted content and a second set of untrusted content.
4. Generate, at the second domain, a reference to the first domain that includes information inside a query string.
5. Transmit, from the second domain to the browser, a second document containing the untrusted content and that reference to the first domain.
6. Receive, at the first domain, the query string from a third browser view of the browser.
7. Determine a size of a second browser view based on the information in that query string.
8. Generate a single web page containing both the trusted and untrusted content, where generating it includes preventing the two content sets from interacting by putting the first document in a first browser view and the second document in the second browser view.

Claim 8 is the same eight-step sequence recited as a method ("A method comprising: storing… receiving… generating…").

Claim 9 is the same sequence recited as a system using "a means for…" language for every step — i.e., means-plus-function limitations that would be construed under 35 U.S.C. § 112(f) to cover only the corresponding disclosed structures (the listing server/management process, description server/management process, IFRAME views, query-string mechanism, Document Object Model access) and equivalents.

Observations on the claim language (analyst comment, not authoritative legal construction):

• The scope is much narrower than the specification's rhetoric. All three independent claims require both the cross-domain query-string mediation and the determination of a frame/view size from that query string. The broader "just put them in two frames" concept from the Summary section is not claimed.
• There is an apparent antecedent-basis gap: step 5 introduces "a second document," but step 8 refers to "the first document" and "the second document" although claim 1 never introduces "a first document" as such (only "a first set of trusted content"). This is a potential § 112(b) indefiniteness exposure. I am noting it as an observation; no court or PTAB decision confirming indefiniteness appeared in my searches.
• The claim also combines server-side acts (storing, receiving requests, generating a "single web page") with client-side state (query string "from a third browser view," view size), which raises divided-infringement/direct-infringement questions that are not resolved on the face of the claims.

Dependent claims (for completeness)

Downstream references worth noting (not litigation)

These documents cite 8,280,819 as prior art in the cross-domain-communication space, which is a useful signal of the patent's technological neighborhood:

• US RE45,139 E1 (Alibaba Group Holding Ltd.; reissue granted 2014-09-16) — "Method and apparatus for cross-domain communication using designated response processing page." This is close in subject matter to the patented third-frame mediation technique.
• US 9,215,096 B2 and US 10,044,660 B2 (Salesforce.com, Inc.) — cross-domain communication in a service cloud.
• US 2022/0092148 A1 (Content Directions, Inc. d/b/a Linkstorm, 2022) — "Methods and systems for cross-domain two-way communication by dynamic web content."

A third-party aggregator (patentleaderboard.com) lists US 8,280,819 with an "approximate value" figure; that number is a non-authoritative estimate by a private analytics site and should not be relied on.

Uncertainty / gaps

1. No litigation or 2026 CAFC activity found. My searches against the patent number returned no infringement suits, no PTAB proceedings, and no Federal Circuit 2026 appeals. I cannot exclude the existence of such proceedings.
2. Prosecution history not retrieved. I did not obtain the file wrapper, so the reasons for the eight-year pendency and for the specific claim amendments are unknown to me.
3. Assignment chain is as recorded, not as verified. Two assignments appear (eBay from the inventors, 2004; PayPal from eBay, 2015). Whether further transfers, security interests, or terminal disclaimers exist is not established by the data I retrieved.
4. Expiration date (2027-10-23) is the adjusted-expiration figure shown in the record and reflects PTA/terminal-disclaimer adjustments; it is stated here as recorded, not independently recomputed.

I'll search for litigation involving US patent 8280819 across patent litigation sources.

Initial searches didn't surface litigation. Let me check the dedicated litigation databases directly.

Let me verify whether any of these hits actually reference patent 8,280,819 specifically, and check the litigation portals directly.

Litigation Search Results for U.S. Patent No. 8,280,819

Bottom line: I found no litigation — no district court case, ITC investigation, or PTAB proceeding — specifically identifying U.S. Patent No. 8,280,819 ("Method and apparatus for securely displaying and communicating trusted and untrusted internet content").

Below is what I did, what I found, and important caveats.

Searches performed

I ran web searches targeting general patent-litigation coverage and patent-number-specific phrasing (e.g., "8280819 litigation," "8,280,819 infringement complaint," combined with the patent's subject matter and assignees eBay/PayPal). I attempted to reach the Unified Patents litigation portal (portal.unifiedpatents.com/litigation/caselist) and CourtListener/PTAB/PACER-style sources, but my tooling returned broad web-index results rather than direct docket lookups, and I was cut off before completing a definitive portal-by-portal check. I therefore cannot certify a negative result with 100% confidence, but nothing in the readily available sources tied this patent number to any case.

Important: false-positive hits I ruled out

Several search hits referenced an "'819 patent," but none of them are U.S. 8,280,819:

Per your instruction, I am flagging these explicitly so they are not mistaken for cases on 8,280,819.

Why litigation is unlikely (context, not proof)

• Current assignee: PayPal, Inc. (originally eBay, Inc.; reassigned 2015). This is an operating company's own patent, not an NPE-held asset, which makes it far less likely to appear in an assertion campaign.
• Related continuation abandoned: The child application US 13/620,003 (published US20130073683A1) is recorded as abandoned, with no enforcement activity visible.
• Status: Active; adjusted expiration listed as 2027-10-23, with 12th-year maintenance fee paid 2024-03-30 — i.e., still live, so future litigation cannot be ruled out.
• I found no IPR/PGR/CBM on this patent in the sources returned.

What I could not confirm

I could not positively confirm a clean bill of health from:

• Unified Patents District Court litigation portal — direct query did not complete.
• PACER / CourtListener docket-level search for 8,280,819.
• ITC EDIS / Section 337 investigations.
• CAFC appeal records.

Recommendation

To get a definitive answer, I recommend running the following (which I was unable to fully execute):

1. Unified Patents portal — search the exact string 8280819 in the District Court case list.
2. CourtListener / RECAP and PACER Party/Docket search on 8,280,819 (note the commas matter in some queries; search both 8280819 and 8,280,819).
3. USPTO Patent Center / Global Dossier litigation and assignment tabs for application 10/888,784.
4. ITC EDIS and CAFC docket search.

Conclusion: Based on the searches I was able to complete, there is no known litigation involving U.S. Patent No. 8,280,819. If you require a certified litigation-clear report, steps 1–4 above should be run directly, since my access to those specific dockets was incomplete.

I'll start by verifying the canonical list against public sources, since the structured block says the ODP index shows nothing.

The initial hits are false positives (different "'828" patents). Let me run targeted searches on the correct patent number and title.

Still nothing on-point. Let me check litigation/assertion history and defensive-aggregator activity, which often correlates with IPR filings.

I hit my search-step ceiling before I could complete a full litigation-history sweep, but the searches I did run returned nothing on this patent. Here is the honest picture.

Proceedings overview

Total AIA trial proceedings on file for US 8,280,819: zero (0). No IPRs, no PGRs, no CBM reviews — no institution decisions, no final written decisions, no appeals. The USPTO ODP-derived "PTAB proceedings on file" block returns an empty set, and my independent web searches (Google Patents US8280819B2 legal events, PTAB petition/decision text, CAFC-adjacent sources) surfaced only false positives on unrelated patents — e.g., pre-AIA medical-device '828 patents, IPR2025-01080 on U.S. 9,804,819, IPR2024-00241's citation to U.S. 8,670,819, and IPR2018-00277 on U.S. 8,543,819. None of those is this patent.

Bottom-line defensive posture for a defendant: the patent is completely untested at the PTAB. There is no canceled claim to point to and no FWD to quote. Unlike a patent that has "survived two IPRs and is hardened," this one has simply never been challenged in an AIA trial — which means (a) all prior-art grounds remain live and non-estopped for you, and (b) you would be the first petitioner, with no roadmap from a prior panel.

Because there are no proceedings, the per-proceeding template below has no entries to populate. I am not going to invent proceeding numbers, panels, or dispositions.

Patent-at-a-glance (the substrate a future petition would attack)

Two diligence notes, flagged as unverified:

• Eight-year pendency (2004-07-09 filing → 2012-10-02 grant) is long enough that some portion may have been an ex parte appeal to the Board. I could not confirm this, and I did not verify the content of any appeal or the pre-issuance claim amendments. If you are seriously considering a petition, pull the file wrapper (USPTO PatentCenter for US 10/888,784) and check for an appeal, an examiner's answer, and any argument-based narrowing — that history is the single richest source of prosecution-history estoppel against the owner.
• The 2004 filing date sits squarely on top of the prior-art of record. The Examiner-cited non-patent literature is all Microsoft Internet Explorer cross-frame/IFRAME documentation from 2001–2004, plus the CIAC HTML-tag vulnerability bulletin. That means the core "separate the untrusted content into a cross-domain frame" idea was already documented before the critical date — but it also means a § 325(d) Advanced Bionics discretionary-denial argument is a real risk if you reuse that same art. The 2012-era precedent on this exact issue (frames + cross-domain security) is precisely what the Board has been reluctant to institute on when the references were already before the Examiner.

Strategic summary

Claim status: all nine claims are UNTESTED. Claims 1, 8, and 9 (the three independents) have never been construed by the Board, never been the subject of an institution decision, and never been canceled. Claims 2–7 are equally untested. Contrast this with a patent that has been narrowed through IPR — here there is no surviving/amended claim set to analyze, no substitute claims, and no Certificate of Cancellation. The practical consequence: your invalidity case starts from zero on the administrative side, and any defense must be built from the prior art yourself rather than inherited from a prior petitioner's work product.

Estoppel landscape: essentially none, and that cuts in your favor. Because there is no IPR that reached a final written decision, § 315(e)(2) estoppel has never attached for anyone on any claim of this patent. Every § 102/§ 103 ground based on patents and printed publications remains available to a defendant. The only statutory gate is § 315(b): if you have been served with a complaint alleging infringement of the '819 patent, you have one year from service to file an IPR, and that clock is jurisdictional and unforgiving. Also worth noting — CBM review is gone. The transitional CBM program sunset on 2020-09-16. Even though this patent (electronic marketplace / listing + description content) looks like a plausible CBM candidate on its face, and even though eBay/PayPal itself has used CBMs aggressively (as petitioner against XPRT Ventures in CBM2017-00024 through -00029 on the '244, '528, '563, '856, '881, and '937 patents), that door is closed for anyone now. Likewise, PGR is unavailable because this is a 2004 pre-AIA filing. IPR is the only AIA vehicle left.

Pattern signals: the notable datum is the silence, and the ownership history. eBay/PayPal is a sophisticated, repeat PTAB player — it has both petitioned (the XPRT CBMs) and defended (PayPal, Inc. is the current assignee here). A 2004-filed software patent in the web-security space, held by a large operating company, that has gone 14 years post-grant and 22 years post-filing with zero PTAB challenges is unusual. Two readings, and you should test both: (i) the patent has rarely or never been asserted in a way that would trigger § 315(b) clocks or invite a defensive aggregator like Unified Patents to file — i.e., low assertion pressure; or (ii) it has been asserted but settled early, before any petition was filed. I could not verify the litigation history — my searches for an assertion record were cut off, and I found no confirmed district-court case. Do not assume either reading is correct; pull the docket first.

Recommended next steps

1. Treat "no PTAB activity" as the operative fact, verified twice. The ODP block is empty and independent searches corroborate it. The absence is itself a signal: well-asserted patents in the software/networking space eventually attract IPRs, and this one has not. Confirm the negative by checking PTAB E2E / the Patent Trial and Appeal Board's public search for both "8,280,819" and the application number 10/888,784 before you rely on it — and re-check at filing time, since proceedings can be filed the day you read this.

2. Search the litigation docket before anything else. Your § 315(b) one-year bar runs from service of a complaint, and your estoppel exposure and stay arguments depend on whether the owner has a litigation track record with this patent. Confirm whether the '819 patent has been asserted (and against whom) via PACER / CourtListener / the patent's Google Patents litigation tab, which I could not fully retrieve.

3. Pull the file wrapper (USPTO PatentCenter, application 10/888,784). The eight-year pendency is the highest-value unexplored item. Look specifically for (a) whether prosecution included an ex parte appeal to the Board, (b) the amendments that produced the issued claim 1 (which requires, among other things, "generating, at the second domain, a reference to the first domain comprising information within a query string," "receiving, at the first domain, the query string from a third browser view," and "determining … a size of a second browser view based on the information within the query string"), and (c) any § 112 or § 101 arguments the Examiner made. Argument-based narrowing on those three-view/query-string limitations is where a prosecution-history estoppel or a § 112 written-description attack will live.

4. Draft the IPR around art that was not the Examiner's. The § 325(d) / Advanced Bionics trap here is severe: the record already contains Microsoft's cross-frame and IFRAME documentation and the CIAC HTML-tag bulletin. A petition built on a browser-frame reference the Examiner already considered invites discretionary denial, and you would be fighting Fintiv-style arguments at the same time. Map new art to the "third browser view" mediation and the "size of the second browser view … based on … a query string" limitations — those are the narrowest, most recently-added-feeling elements and the likely point of novelty.

5. If no proceeding is ever filed, that is a legitimate defensive position too. With all nine claims untested and no estoppel, you retain full freedom to argue invalidity in district court on any ground (including § 101 and § 112, which IPR cannot reach) while preserving a later IPR as a stay-and-cost tool. Note, however, that a § 101 challenge is often attractive against claims of this vintage and subject matter — and unlike IPR, it is not subject to the one-year bar.

Verification caveat: I could not complete verification of the patent's litigation history or confirm the absence of a recently-filed (post-ODP-ingest) petition, because my search steps were exhausted. Nothing above should be treated as a substitute for checking PTAB E2E, the file wrapper, and the docket directly. No proceeding numbers, judge panels, or decisions are stated here because none exist on the record I could reach.

I'll research the assignment chain and any litigation/enforcement history for this patent.

Let me dig into the specific assignment records and any enforcement activity.

US 8,280,819 — Assignment & Ownership Chain Analysis

Patent: US 8,280,819 B2 — "Method and apparatus for securely displaying and communicating trusted and untrusted internet content"
Appl. No.: 10/888,784 · Filed: 2004-07-09 · Issued: 2012-10-02 · Priority: 2004-07-09
Current assignee of record: PayPal, Inc. (Palo Alto / San Jose, CA)
Sources used: Google Patents legal-events feed for US 8,280,819 (reel/frame citations below); USPTO Assignment Center indexing; Plainsite patent-assignment index; open-web litigation searches.

Methodological caveat up front. The USPTO Assignment Center (https://assignmentcenter.uspto.gov/) and its legacy mirror (https://assignment.uspto.gov/patent/index.html) were not directly reachable during this analysis — attempts to pull the patent-number-keyed assignment record returned no results. The reel/frame identifiers, execution and recording dates, and assignor/assignee names below are taken from the Google Patents legal-events record, which is itself populated from the USPTO assignment dataset. Correspondent-of-record data was not exposed by any source I could reach, so signal #3 could not be evaluated on evidence (see below). This is stated as a data gap, not as an absence of a correspondent.

Inventors

Pattern notes:

• All three inventors assigned to eBay Inc. within ~4 weeks of the 2004-07-09 filing date (signing dates 2004-07-26 through 2004-08-04). This is an ordinary, promptly-executed employee invention assignment — no departure pattern, no staggered/withheld execution, and no post-filing inventor-side activity is visible in the record.
• Low-confidence observation (flagged, not a finding): a third-party patent-analytics aggregator (patentleaderboard.com) indexes one "Evan Gilbert" under a Google inventor profile. I cannot confirm this is the same person as the eBay inventor, and I am not treating it as evidence of inventor departure. Recorded here only so a follow-up analyst can close the loop via the inventor's USPTO practitioner/inventor records.
• No inventor appears as an assignor on any later recording. There is no inventor-to-third-party transfer.

Original assignee

eBay Inc. (Delaware corporation; 2145 Hamilton Avenue, San Jose, CA), as recorded at Reel 015986/0792 on 2004-11-12.

• Primary line of business: online person-to-person marketplace / e-commerce operator. The patent is the archetypal eBay "safe item-description" invention — it is the mechanism by which eBay separated service-controlled listing chrome ("trusted content") from seller-supplied HTML item descriptions ("untrusted content") into sandboxed browser views so a malicious seller could not script against eBay's own page content, cookies, or logos.
• Product embodying the claims: Yes. eBay's item-listing pages in the mid-2000s rendered seller item descriptions inside a separate, cross-domain-sandboxed browser view precisely per the described IFRAME/DescriptionServerAddress arrangement. The specification itself describes the commercial deployment (FIGS. 4A–6, item description view 610 with its own scroll bar 520).
• Current status: Operating. eBay Inc. (NASDAQ: EBAY) remains a public, operating company. No bankruptcy, no wind-down, no dissolution, and no Chapter 7/11 proceeding is associated with eBay at any point in this chain.
• Note: the patent was not part of the original 2002 eBay↔PayPal acquisition inversions — the 2004 filing post-dates eBay's 2002 acquisition of PayPal and sits within eBay's core marketplace portfolio; the 2015 transfer is the reverse direction (eBay → spun-off PayPal).

Assignment timeline

Two recorded assignments exist for US 8,280,819. Both are accounted for below. Neither is an NPE transfer.

1. Inventors → eBay Inc. (initial assignment)

• 2004-07-26 to 2004-08-04 (executed; latest signing date 2004-08-04) / recorded 2004-11-12 — Reel 015986/0792
  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Jeremy Alan Davis; Evan Gilbert; Randall B. Spickler (individuals)
  • Assignee: eBay, Inc. (California)
  • Correspondent: Not available in the sources reachable. Google Patents' legal-events feed records only the reel/frame and free-format text (ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DAVIS, JEREMY ALAN;GILBERT, EVAN;SPICKLER, RANDALL B.;SIGNING DATES FROM 20040726 TO 20040804). Correspondent name/firm/address was not exposed. Cannot be flagged as recurring or non-recurring.
  • Context: Routine employee invention assignment to the operating employer — the original link in the chain, executed one to four weeks after filing.

2. eBay Inc. → PayPal, Inc. (corporate separation)

• 2015-07-17 (executed/effective) / recorded 2015-07-23 — Reel 036163/0469
  • Conveyance: Assignment
  • Assignor: eBay Inc.
  • Assignee: PayPal, Inc. (California; 2211 North First Street, San Jose, CA 95131)
  • Correspondent: Not available in the sources reachable. Free-format text is only ASSIGNMENT OF ASSIGNOR'S INTEREST;ASSIGNOR:EBAY INC.;REEL/FRAME:036163/0469, with Effective date: 20150717.
  • Context: Internal corporate reorganization / divestiture — not a sale to a third party. The effective date of 2015-07-17 is the exact completion date of the eBay–PayPal separation, when PayPal Holdings, Inc. was spun off from eBay Inc. as an independent NASDAQ-listed company and received the assets allocated to the PayPal business. The 6-day execution-to-recording gap is consistent with a bulk spin-off conveyance recorded in batch.

Related but unconfirmed record

• A separate eBay Inc. → PayPal, Inc. assignment, executed 2015-07-17 and recorded 2024-09-06 as Reel 68510/173, appears in the Plainsite assignment index. The indexed member asset is US Appl. 17/390,721 (Pub. 2021/0358003), not the '819 patent. This indicates that portions of the 2015 eBay→PayPal separation were re-recorded or swept up in a 2024 clean-up filing. I could not confirm that US 8,280,819 is a member of Reel 68510/173; the '819 patent's own 2015 record remains Reel 036163/0469. Treat this as a follow-up item for a full Assignment Center pull.

Non-assignment events (for completeness)

• 2011-12-08 — FEPP / Fee payment procedure / PAYOR NUMBER ASSIGNED … ENTITY STATUS OF PATENT OWNER: LARGE ENTITY — administrative, not a conveyance.
• 2012-09-14 — Continuation application US 13/620,003 filed (published US 2013/0073683 A1), an eBay-internal refiling; later abandoned. Not an assignment.
• 2016-03-16 / 2020-03-26 / 2024-03-30 — maintenance fees paid at the 4th, 8th, and 12th years, all as LARGE ENTITY. Ongoing fee payment by a large entity through 2024 is consistent with continuous ownership by PayPal, Inc. and with the patent not being abandoned into the public domain.
• Adjusted expiration: 2027-10-23, status Active.

No third recorded assignment exists. In particular, there is no assignment to any entity whose name contains "IP," "Patents," "Licensing," "Holdings," or "Ventures," and no assignment to any entity on the standard NPE lists.

Timeline diagram

timeline
    title Ownership of US 8280819
    2004 : Filed by eBay Inc
         : Inventors assign rights to eBay
    2012 : Patent issued to eBay
    2015 : Assigned to PayPal Inc
         : eBay PayPal separation completed
    2024 : 12th year maintenance fee paid

NPE / troll-pattern signals

1. Shell-entity transfer — not present.
The only post-original transfer is Reel 036163/0469 (executed 2015-07-17, recorded 2015-07-23), eBay Inc. → PayPal, Inc. Both are large public operating companies. No name-suffix LLC ("IP / Patents / Licensing / Holdings / Ventures"), no registered-agent-service address, no single-member Delaware/Texas shell. PayPal, Inc. at "2211 North First Street, San Jose, CA 95131" is PayPal's actual corporate headquarters campus, not a mail-drop.

2. Known asserter in the chain — not present.
Neither eBay Inc. nor PayPal, Inc. matches any entity on the reference lists (Acacia Research, Marathon Patent Group, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio IP Ventures, MPHJ Technology, Lumen View, Round Rock Research, Document Generation Corp, or Erich Spangenberg-affiliated entities). No entity surfaced by Unified Patents or RPX as a high-frequency plaintiff appears anywhere in this chain. The cited-by / citing-family data on Google Patents shows this patent's family being cited by operating companies (Microsoft, Google, Salesforce, Samsung, Alibaba, Oracle) and asserted-over by cross-domain-communication implementers — not by assertion vehicles.

3. Repeat correspondent across the chain — unclear (insufficient data).
This signal could not be evaluated. Neither the 2004 record (Reel 015986/0792) nor the 2015 record (Reel 036163/0469) exposed a correspondent, attorney, firm, or domestic representative in any source reachable during this analysis. Per the task's own guidance, a single appearance would not be a finding anyway — and here I have zero correspondent data points. I am explicitly not inferring anything from this gap. To close it, pull both reel/frame documents directly from the Assignment Center (search patent number 8280819) and read the "Correspondent" block on the face of each recorded cover sheet.

4. Cascading transfers — not present.
Two assignments over an eleven-year span (2004 and 2015), each a single-step conveyance. There is no chain of consecutive LLC-to-LLC transfers, no cluster inside any 24-month window beyond the single 2015 spin-off event, and no shared-principal or shared-address pattern observable.

5. Pre-litigation transfer — not present / no predicate.
I found no infringement action naming US 8,280,819 in any of the searches performed. The 2015 assignment is not proximate to any litigation against this patent; it is dated to a corporate separation. Note the searches did surface numerous unrelated patents also numbered x,8x9 (e.g., US 8,958,819, US 9,804,819, US 8,379,819, US 8,003,819) — those are different patents in different litigations and should not be conflated with US 8,280,819.

6. Bankruptcy fire-sale — not present.
Neither eBay Inc. nor PayPal, Inc. entered Chapter 7 or Chapter 11 at any relevant time; no court-supervised patent sale is implicated. This is not a Kodak/Nortel/Polaroid-style asset liquidation.

7. Privateering — not present.
The one non-original transfer ran from the operating parent to an operating spin-off that retained the business the patent supports. There is no transfer to an NPE that then asserts against the original assignee's competitors, and no SEC 10-K/8-K disclosure language of the "monetization via third-party licensing agent" type associated with privateering.

8. Defensive aggregator — not present.
The chain does not terminate at RPX, Allied Security Trust, LOT Network, Unified Patents, or the Open Invention Network. It terminates at PayPal, Inc., a practicing operating company.

Verdict

Operating-company assertion.

Justification: the entire recorded chain is two links long — inventors to eBay, Inc. at Reel 015986/0792 (recorded 2004-11-12) and eBay to PayPal, Inc. at Reel 036163/0469 (executed 2015-07-17, recorded 2015-07-23), the latter being the eBay–PayPal corporate separation rather than a sale to an assertion vehicle. No shell entity, no listed NPE, no cascading LLC chain, no bankruptcy, no defensive aggregator, and no located infringement suit naming this patent — so the "suing actual competitors" prong of the operating-company category is not proven; I select this verdict on the strength of the ownership profile (a practicing operating company, which itself embodies the claimed secure-content-separation architecture) and note that the accurate narrower finding is operating-company ownership with no NPE signals and no evidence of assertion. The two gaps that could change this call are (a) the unretrieved correspondent-of-record for Reels 015986/0792 and 036163/0469, and (b) the unverified question of whether US 8,280,819 is swept into the 2024 re-recording at Reel 68510/173 (eBay → PayPal, executed 2015-07-17, recorded 2024-09-06).

Verify at: https://assignmentcenter.uspto.gov/ (search patent number 8280819) · https://assignment.uspto.gov/patent/index.html · patent record: https://patents.google.com/patent/US8280819/en

I'll search for the specific patent and its cited references.

Let me gather details on the remaining cited references.

I'll ground this analysis in the actual prior-art references cited on the patent's face. Let me verify the key references.

Good grounding on four references. Let me verify the remaining two cited references and the key non-patent literature.

Obviousness Analysis — U.S. Patent No. 8,280,819 B2

Patent: US 8,280,819 B2, "Method and apparatus for securely displaying and communicating trusted and untrusted internet content"
App. No.: 10/888,784 | Filed: 2004-07-09 | Granted: 2012-10-02 | Priority: 2004-07-09 (pre-AIA)
Assignee: PayPal, Inc. (originally eBay Inc.)
Claims analyzed: 1–9 (9 total; 1 = CRM/Beauregard-style, 8 = method, 9 = means-plus-function system)
Source of record: https://patents.google.com/patent/US8280819/en
Analysis date: April 26, 2026

Scope note / caveat. This is a technical obviousness analysis, not a legal opinion or a validity conclusion. I rely primarily on the six U.S. patent references and eight non-patent citations listed on the face of US 8,280,819 ("the References"). I independently retrieved and verified the disclosures of US 6,732,161 B1, US 6,567,918 B1, US 2003/0135504 A1, US 2004/0015565 A1, and US 2005/0131992 A1. I was unable to independently retrieve (and therefore characterize only from the patent's own front page/Background, not from the primary document) the Teodora Stanev 2001 WebCast, the CIAC K-021 bulletin, and US 2005/0187895 A1. I flag those where used. Where my training data and the retrieved sources disagreed, I followed the retrieved sources; I found no such conflict here.

1. Legal framework applied

Under 35 U.S.C. § 103 as construed in KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), a claim is obvious where the differences between the claimed subject matter and the prior art are such that the subject matter as a whole would have been obvious to a person of ordinary skill in the art ("POSITA") at the effective filing date (2004-07-09). I consider: (a) the scope and content of the prior art; (b) the differences between the prior art and each claim; (c) the level of ordinary skill; and (d) objective indicia. KSR endorses combining references where the combination is "a predictable use of prior art elements according to their established functions," where there is a "design need or market pressure," or where the reference teaches "the identified, predictable solutions" to a known problem. The '819 Background itself frames the problem and the solution — a strong sign that the asserted advance was a known engineering fix rather than an inventive leap.

Level of ordinary skill: a software engineer/web developer with ~2–4 years of experience in HTML/browser-based client-server web application development, familiar with HTTP, HTML framesets/IFRAMEs, browser cross-frame/cross-domain security models, and server-side content templating.

2. The prior-art reference set (dates and § 102 status)

3. Claim 1 — element-by-element mapping

Claim 1 (CRM) recites, in substance: (a) storing trusted content on a first server/first domain; (b) receiving untrusted content from a user and storing it on a second server/second domain; (c) receiving, from a web browser, a request for the first (trusted) and second (untrusted) content; (d) generating, at the second domain, a reference to the first domain comprising information within a query string; (e) transmitting from the second domain a second document containing the untrusted content and that reference; (f) receiving, at the first domain, the query string from a third browser view; (g) determining a size of a second browser view based on the query-string information; and (h) generating a single web page with both content sets, where trusted and untrusted are prevented from interacting by rendering the first document in a first browser view and the second document in a second browser view.

Every element of claim 1 is disclosed or rendered obvious individually. The remaining question is whether the combination is obvious — and the answer is yes, for the reasons below.

4. Combinations rendering the claims obvious, with motivations

Combination A — Primary: '161 + Bednar '565 + Microsoft cross-frame/IFRAME NPLs

What is combined. '161 supplies the online-marketplace, seller-supplied-content, multi-server architecture, server-generated references and query-string URL technique, and the express teaching that the servers may be "multiple physical and/or logical devices." Bednar '565 supplies the recognition of, and architecture for, "the cross-frame or cross-domain security problem … where the company and the content server utilize different second-level domain names," and the use of a web-server filter/module acting as a content bridge to reconcile content served from different domains. The Microsoft NPLs (Stanev; "About Cross-Frame Scripting and Security"; FRAME/IFRAME object docs) supply the mechanism that makes the security guarantee work: cross-domain frames cannot read or modify one another, while cross-domain navigation by URL is still permitted — exactly the "prevented from interacting" + "query string to the first domain" duality '819 claims.

Why the POSITA would combine. The problem was known and named in the art: CIAC K-021 (Feb. 2000) warned that embedded scripts/tags "have the potential to be abused by an attacker… to alter the appearance of the page" — a warning '819 itself quotes. Bednar names the cross-domain variant of the problem and offers the domain-split architecture. The Microsoft Material on IFRAME/FRAME objects and cross-frame scripting security (2001–2004) provides a ready-made, documented mechanism to achieve isolation. Combining an online-marketplace listing system with a documented browser security model is a predictable use of known elements (IFRAMEs + the browser's own same-domain-origin restriction) according to their established functions — the paradigm of KSR. No new physical result is required; the components operate exactly as they were designed to.

Combination B — Add Microsoft '918 and/or Elvanoglu '504 for the "prevented from interacting" security premise

What is added. '918 states the cross-domain interaction rule verbatim in the browser context ("pages of an HTML frameset may only interact if the domain components of their URLs refer to the same domain") and explains security zones that grant, withhold, or restrict active content (JavaScript/VBScript/ActiveX) and cross-frame scripting by URL. Elvanoglu '504 specifies per-element (per-tag) security settings with a "negotiator" enforcing least privilege.

Motivation. Where the goal is "display untrusted HTML without letting it modify trusted content," a POSITA would look to the browser's own origin/zone/security-tag mechanisms — these references teach precisely that the domain of a URL is the operative security boundary and that scripts can be selectively disabled. This supplies claim 2 ("the web browser supports a cross-frame security feature") directly as a designed-for environment rather than an accidental one, and reinforces claim 1(h). Elvanoglu's "negotiator" (cannot exceed intended privileges) is logically the same policy '819 achieves structurally by domain separation.

Combination C — Add Goldstein '192 for the size-determination limitation (claim 1(d)/(g))

Claim 1(g) ("determining… a size of a second browser view based on the information within the query string") is the most specific limitation and the reference combination should address it explicitly. '192 discloses an independent, resizable browser window composed of HTML frames in which content items occupy "specific percentages of the height and width," the window can be resized, and "when the frame border is relocated, the browser application resizes both of the content items within the frames… proportionately." That is determining/setting view size from frame/content attributes. A POSITA combining '161 + Bednar with '192 has an express teaching to size a browser view to its content and would be motivated to do so here (a seller's HTML description of unknown length needs a correctly-sized view; '819 itself says the size information's purpose is "dynamically adjusting the size of view 706").

Combination D — Add US 2005/0187895 A1 for dynamic UI aggregation

US 2005/0187895 A1 ("Dynamically customizing a user interface for the aggregation of content," Microsoft, filed 2004-02-23) is § 102(e) art and, as its title indicates, is directed to dynamically customizing a UI that aggregates content — squarely the "generating a single web page comprising the first set … and second set" concept and the dynamic-customization aspect of claim 1(g). I verified only its title/identity from the '819 front page, so I state this more cautiously than Combinations A–C, but on its face it is corroborating art for the aggregation/customization elements.

5. Dependent claims 2–7

• Claim 2 (cross-frame security feature): disclosed by '918 (cross-domain frameset interaction rule) and the Microsoft cross-frame scripting NPLs, and is intrinsic to the IFRAME mechanism '161/Bednar-based systems would use. Obvious as the designed operating environment.
• Claim 3 (single page lists an item/service in an electronic marketplace): '161 (online marketplace/auction item presentation). Directly disclosed.
• Claim 4 (trusted content provided by the marketplace service): '161 (service-generated Gallery/listing templates and auction metadata alongside the seller description). Directly disclosed.
• Claim 5 (trusted content in a format other than HTML by the user): '161 teaches the seller may supply the description in text or HTML, and that the service supplies the listing chrome/interface; the registration form collects constrained, non-HTML fields (predefined categories, payment methods, shipping terms — compare '819's own Fig. 4A/4B reasoning). Obvious.
• Claim 6 (untrusted content in HTML by the user): '161 — "detailed description of the item in text or HTML format." Directly disclosed.
• Claim 7 (untrusted content is a description of an item/service): '161 — the seller's item description. Directly disclosed.

Claims 3, 4, 6, 7 are essentially '161's own subject matter, making them the strongest single-reference § 103 (indeed § 102-flavored) targets.

6. Claims 8 and 9

• Claim 8 is the method counterpart of claim 1, with the same limitations; the same combinations apply.
• Claim 9 is a "means for" system claim. Under Williamson v. Citrix Online (Fed. Cir. 2015) (and, at the 2004 priority date, the Halliburton line), the "means for" recitations are presumed § 112(f) means-plus-function limitations whose corresponding structure is the servers/management processes/browser views described in the '819 specification. Because the corresponding structures are exactly the generic server/browser/management-process elements again disclosed by '161 + Bednar '565 + '918 + '192, claim 9 rises and falls with claim 1 and presents no additional technical content.

7. Motivation to combine, expressly

A POSITA would have combined the references because:

1. The problem was known, named, and published. CIAC K-021 (Feb. 2, 2000) — cited by the applicant's own specification — articulated the malicious-embedded-content problem, and Bednar '565 named the cross-domain security variant and the "different second-level domain names" architecture. Design need is established by the art itself.
2. The solution used the browser's existing, documented mechanism. The same-origin/cross-frame restriction and the IFRAME element were documented in Microsoft's own materials (2001–2004). Using the browser's native domain boundary to isolate untrusted HTML is a predictable application of a known technique to a known problem (KSR).
3. The building blocks were all in the same field of endeavor and reasonably pertinent (browser-based web content delivery and security). '161 and '192' are web content presentation; '918, Elvanoglu, Bednar, and the Microsoft NPLs* are browser security/domain-reconciliation — all directly pertinent to serving mixed-origin content.
4. Reasonable expectation of success. '819 admits (via its own reliance on Internet Explorer 4.0+ behavior) that the cross-domain restriction and "permission denied" behavior already worked; the only remaining work was routine wiring (an IFRAME whose SRC carries a query string; a server-side parser). No unpredictable result is claimed.
5. Design flexibility / "obvious to try." '819's own spec concedes that the two domains can be two servers or one server with two domain addresses, and that the parsing can be client-side or server-side — hallmarks of a KSR-type "finite number of identified, predictable solutions."

8. Anticipated counter-arguments and objective indicia

Likely rebuttals to consider (not resolved here):

• "Bednar teaches away." Bednar streams remote content through the local server so it appears to come from the same domain — arguably the opposite of '819's "keep them on different domains" approach. A patentee could argue that Bednar's domain-unifying bridge teaches away from the domain-separating architecture. Rebuttal: Bednar nonetheless teaches the problem (cross-domain security with different second-level domain names) and one alternative solution; teaching away requires that the reference discourage the claimed approach, which Bednar does not (Bednar also teaches other approaches, and '819's architecture is a known alternative for the same need).
• Specific limitation (g) size determination. This is the most vulnerable point for the primary combination; it is why Combination C ('192) and Combination D ('895) are needed to supply "determining a size of a second browser view based on the query-string information." Whether that limitation is fully met should be verified against the primary text of '192 (verified in part here) and '895 (not independently verified here).
• Prosecution history. '819 issued in 2012 (8 years after filing) on claims that appear narrowed relative to the original disclosure (the 2012 child application, US 2013/0073683, was abandoned). The claim-1 limitations "generating, at the second domain, a reference to the first domain comprising information within a query string" and "determining… a size of a second browser view" appear to be amendment-driven — meaning the examiner may have considered and distinguished some art. The full prosecution history has not been reviewed here and should be, since statements therein could limit claim scope or evidence unexpected results.

Objective indicia: none were identified in the record available to me. The '819 claims recite a specific structural arrangement; no non-obvious performance result (e.g., measured security improvement) is claimed, which weakens any "unexpected results" position. Long-felt need is argued in the specification, but the need was already articulated in the prior art (CIAC K-021, 2000; Bednar, 2002), which weighs against long-felt-need as a nexus-bearing secondary consideration.

9. Bottom line

On the record of the six patent citations and eight non-patent citations on the face of US 8,280,819:

• Claims 3, 4, 6, 7 are the most straightforwardly obvious — largely disclosed by US 6,732,161 B1 alone, since they recite the marketplace listing/item-description subject matter of that reference.
• Claims 1, 2, 8, 9 are obvious over the combination of US 6,732,161 B1 (Hess/Wilson, eBay) + US 2004/0015565 A1 (Bednar) + the Microsoft cross-frame/IFRAME NPLs (Stanev; "About Cross-Frame Scripting and Security"; "FRAME/IFRAME Element" docs), optionally + US 6,567,918 B1 and/or US 2003/0135504 A1 (Elvanoglu) for the "prevented from interacting" cross-frame security feature (claim 2), and + US 2005/0131992 A1 (Goldstein) and/or US 2005/0187895 A1 (Microsoft) to supply "determining a size of a second browser view based on the information within the query string."
• The motivation to combine is well supported: the problem was named in the art ('819's own Background quotes CIAC K-021), Bednar names the cross-domain variant and architecture, and the Microsoft NPLs document the exact browser mechanism used. The combination is a predictable use of known elements for their established functions, with a reasonable expectation of success — the KSR standard.
• Claim 5 is obvious over '161 (seller-supplied text vs. HTML; service-supplied constrained fields).

Primary open risks to be resolved with the untouched sources: (i) the primary text of US 2005/0187895 A1 (not independently retrieved here), and (ii) the full prosecution history, given the apparent 2012 claim amendments and the abandoned 2012 child (US 2013/0073683). If a formal validity challenge were contemplated, I would obtain and read both in full before finalizing.