US 6873975

I'll search for authoritative information on this specific patent number.

Search results: US Patent 6,873,975

Note on scope of search

I searched for the literal string "6873975" and combinations with USPTO/CAFC 2026 docket terms. I found no CAFC (Federal Circuit) 2026 docket entry, appeal, or oral-argument listing for US 6,873,975, and no district-court or ITC litigation asserting this patent. The only hits for the bare number "6873975" outside patent databases were unrelated (a Nevada state criminal case transaction number and an Oracle Solaris bug ID), which I am explicitly not conflating with the patent. Treat "no litigation found" as an absence of evidence, not proof that none exists — my docket coverage is not exhaustive.

What follows is grounded in the authoritative full text of the patent (Google Patents, https://patents.google.com/patent/US6873975/en), corroborated by Justia and PatentLeaderboard listings.

---

Bibliographic data

The assignee is listed as Fujitsu Ltd, with the assignment recorded 2000-03-08 naming Hatakeyama, Miyazawa and Yoshioka as assignors.

Abstract (verbatim)

"A content usage control system comprises a copyright holder system, content server, license server and user system. The ACL setting section of the copyright holder system sets a license ACL expressed as a structure by a combination of logic sums and logic products of a plurality of partial licenses for the content, based on the user ID and a plurality of physical element IDs including media used in the user system, and stores the license ACL in an access control list. The license server controls the usage of the content by the user utilizing the access control list."

Technology context

This is a digital-rights-management (DRM) patent. It addresses the problem that in conventional systems the license was generated based only on a physical-element ID unique to the user's machine, so a matching device could decrypt content without any ability to limit read frequency, impose a time limit, or define charging conditions. The invention builds a license as a logical structure of AND/OR combinations ("logic products" and "logic sums") of multiple partial licenses, keyed to multiple physical-element IDs (CPU/processor serial number PSN, device DSN, media MSN, IC card certificates, biometric "bodyParts", time period, MAC address, geographic "location", user ID+password, and groupings) plus accounting conditions (maxCount / maxLength / maxTimeLen / maxDebt with corresponding usage-state counters). Encryption is nested/multiplied across the physical elements — e.g. {{{{{{<access information>}K5}K4}K3}K2}K1} for AND, XOR-combination where security levels are comparable, and OR-combinations of sublicenses — so that compromising a single physical element does not expose the content decode key Kc (risk distribution).

Plain-language overview of the independent claims

⚠️ Uncertainty flag: the fetched Google Patents text jumps from the detailed description directly to the classification/"Landscapes" section and does not reproduce the literal numbered claim set. The overview below is derived from the patent's "Summary of Invention" aspect paragraphs, which correspond to the independent claims (system, apparatus/server, method, and computer-readable recording medium). Claim numbering below is my mapping and should be verified against the USPTO PatentCenter claim text before being relied on.

1. Content usage control system — A system in which a setting unit builds a license for content as a structure of logic sums and logic products of multiple partial licenses, based on (a) ID information of physical elements of the user unit, including the media used in the user unit, and (b) ID information of the user; a usage control unit then controls the user's use of the content in accordance with that license. The point is versatile, multi-condition usage control rather than a single machine-ID check.

2. System of claim 1, with accounting conditions — The partial licenses include accounting conditions whose category changes with the usage state of the user unit and the user (e.g., max sessions, max read length, max execution time, credit/debt limits). This enables finer-grained, state-dependent control.

3. System with production unit + user unit — A production unit generates, at the content, license information encrypted from the license and the content decode key using the ID information of multiple physical elements of the user unit (including media); the user unit decrypts the license information sent in response to a content-usage request, using its physical-element ID information, and — if license conditions are satisfied — decrypts the encrypted content with the content decode key. This is the core cryptographic enforcement claim.

4. System of claim 3, with multiplied encryption — Where the interface between partial licenses is a logic product (AND), the encryption based on the ID information of the corresponding physical elements is multiplied, distributing the risk of content-decode-key theft in the event one physical element is successfully attacked.

5. System handling nested physical elements — Physical elements contained within another physical element are treated as a single physical element whose illegal use is not permitted, again distributing key-theft risk (see the "inclusion/hierarchical relation" of PCSUEs in FIG. 9).

6. System including a content server — A content server on the open network holds the content encrypted by the authorized information supplier unit and, on the user's distribution request, sends the encrypted content to the user unit — spreading traffic across the open network for faster acquisition (the "content cacheable" model).

7. Content management device (license-server side) — A setting unit stores, in a condition-storage unit of the usage control unit, the license conditions expressed as logic sums/products of partial licenses based on physical-element IDs (including media) and user ID, and holds the corresponding content decode key in a holding unit. An extraction unit receives the content-usage request from the user unit, extracts the matching license conditions and content decode key, and — based on the physical-element ID information sent by the user unit — produces and returns encrypted license information.

8. Content usage apparatus (user side) — A request unit transmits the apparatus's physical-element ID information and the user ID to the content management device on a content-usage request; it then decodes the returned license information based on its own physical-element ID information to determine the license conditions and content decode key, and, if permitted, decodes the content with the decode key. (Corresponds to the FIG. 11 user-system flow.)

9. Content usage method — The method counterpart of claim 8: send physical-element ID info and user ID to the managing device on a usage request; decode the returned license information based on the physical-element ID info to determine conditions and decode key; decode the content with the decode key if the conditions permit. (Two further "first step"-style method aspects in the Summary suggest additional method/medium claims — claim 10 and a computer-readable recording medium claim — whose exact wording I cannot confirm from the fetched text.)

Bottom line

US 6,873,975 is a Fujitsu DRM/licensing patent (1999 priority, granted 2005, now expired) that generalized earlier machine-ID-only content licensing into a boolean-structured license of partial licenses over multiple physical-element IDs plus usage/accounting conditions, with nested (multiplied) encryption of the content key across those elements. I found no CAFC 2026 activity for it, and the literal claim text was not present in the source I retrieved — the claim-summary above should be confirmed against the USPTO PatentCenter record before being cited as exact claim language.

I'll search for litigation involving US patent 6873975.

Let me run more targeted searches on litigation databases.

Litigation Search Results for U.S. Patent No. 6,873,975

Bottom line: I found no evidence of any litigation (district court, ITC, CAFC, or PTAB/AIA proceeding) involving U.S. Patent No. 6,873,975.

Search coverage

I searched for the patent number and associated terms across general web indexes, patent-litigation aggregators (Unified Patents, RPX Insight, Docket Alarm, CourtListener/Justia/UniCourt), CAFC-related sources, and PACER-adjacent dockets. Every hit returned for the numeric string "6873975" was an incidental, non-litigation match rather than an asserted patent. Specifically:

• Prior-art / citation listings – The number appears only as a cited reference in other patents' specification tables and prosecution "EAST search history" printouts (e.g., in the file history of US 8,886,954; in WO 2007/058292 as "JP 2000-293439 A … & US 6873975 B"). These are citations, not suits.
• Unrelated numeric collisions – The digits "6873975" also appear as an Oracle Solaris bug ID, a Nevada state-court transaction number, a Lithuanian business-registry notice number, and a SEC small-business-loan/Securities line item. None relate to the patent.
• Fujitsu litigation generally – I did find unrelated Fujitsu patent cases (e.g., Fujitsu Ltd. v. Belkin / D-Link / NETGEAR, N.D. Cal. No. 5:10-cv-03972; Competitive Technologies v. Fujitsu), but none of these assert U.S. 6,873,975. They involve different patents entirely.

Patent status (context)

U.S. 6,873,975 (Fujitsu Limited; inventors Hatakeyama, Yoshioka, Miyazawa; filed 2000-03-08; priority 1999-04-06; granted 2005-03-29) carries a Google Patents legal-status notation of "Expired – Fee Related," with an anticipated expiration of 2020-03-08. The absence of recorded litigation is consistent with the patent's age and expired/lapsed status.

Required qualifiers

• I cannot state as a certainty that zero suits were ever filed. Some older or sealed cases, cases terminated without a written opinion, or dockets not indexed by the aggregators I searched could omit a patent number. However, I found no affirmative record of any such case, and the burden is on the record to show one.
• No plaintiff, defendant, jurisdiction, case number, filing date, or outcome can be provided, because no case was located. I am not going to fabricate case identifiers to fill this gap.

If no litigation is known, say so: No litigation involving U.S. Patent No. 6,873,975 is known based on the sources searched as of April 26, 2026.

If you want me to push further, useful next steps would be a direct PACER docket query and a targeted search of the ITC EDIS system (Section 337 complaints), which are not fully captured by the open web indexes I used.

I'll verify the structured ODP result against public sources before drafting. Let me run several targeted searches.

No hits yet. Let me probe a few more angles — Unified Patents, CourtListener, and the patent's own litigation/PTAB tabs.

One search hit showed a Google Patents legal-events row pairing "IPR2022-00172" with a similar-document table row for US 6,873,975. That could be scrape bleed from a neighboring patent. Let me verify directly.

Proceedings overview

Zero AIA trial proceedings on file. The structured "PTAB proceedings on file" block — sourced from the USPTO Open Data Portal — returns 0 IPRs, 0 PGRs, and 0 CBM reviews naming US 6,873,975 as the challenged patent: 0 active, 0 claims-invalidated, 0 claims-sustained, 0 settled, 0 institution-denied. My independent web searches (Google Patents legal-events/PTAB tabs, PTAB docket aggregators, CourtListener, Federal Circuit material) surfaced no petition, institution decision, Final Written Decision, or appeal in which US 6,873,975 is the patent under review.

The bottom line for a defendant: this is "no PTAB activity" rather than "the patent is hardened by surviving IPRs." Those are different signals. The patent owner never had to defend 6,873,975 at the Board, so no claim of the patent has ever been tested for validity — there is no FWD to cite, no canceled claim to lean on, and no § 315(e)(2) estoppel to leverage. The defensive posture here comes from patent term and age, not from PTAB attrition (see Strategic summary).

---

No proceedings to report

There is nothing to list in the per-proceeding format. Instead, here are the two near-miss artifacts I found and why each is not a proceeding on this patent — flagged so you don't get burned citing them.

Artifact 1 — "IPR2022-00172" appearing adjacent to US 6,873,975 in a Google Patents crawl.
A search result rendering of the Google Patents page for US 8,489,895 B2 shows a "Similar Documents" table row for US 6,873,975 B1 (1999-04-06 / 2005-03-29 / Fujitsu Limited) sitting immediately above a scraped legal-event block reading IPR | Aia trial proceeding filed before the patent and appeal board: TRIAL NO: IPR2022-00172. This is scrape bleed between two separate tables on a third-party patent's page, not a docket entry for 6,873,975. The legal-event block belongs to the page's own legal-events list, not to the similar-document row. I attempted to resolve what patent IPR2022-00172 actually targets and was cut off by a tool-step limit before I could confirm it — so I am explicitly not asserting that IPR2022-00172 is a proceeding on 6,873,975, and I am not reporting it as one. Treat it as unverified and check PTAB E2E if it matters to your case.

Artifact 2 — "6873975" appearing inside a petitioner exhibit in IPR2024-00233.
A Docket Alarm exhibit (Exhibit 1002, file history of US 8,886,954, Google LLC) contains the string "6873975" as part of a transcript of a patent-office prior-art search run in a terminal emulator. That is a search-string capture inside an unrelated patent's file history — it is not a challenge to 6,873,975. IPR2024-00233 does not involve this patent.

Conclusion: no proceeding number, no petitioner, no panel, no institution date, and no FWD exists to report for US 6,873,975.

---

Strategic summary

Claim status: entirely UNTESTED. No claim of US 6,873,975 has been canceled, confirmed, or even construed by the PTAB, because no petition was ever filed. I do not have the issued claim set in the materials provided to me and will not guess at claim numbers or independent/dependent structure — the source text I was given contains the specification, abstract, and figures, but not the claims. Anyone needing the claim scope should pull them directly from the patent or USPTO PatentCenter. The practical point stands regardless: there is no narrowed surviving claim set and no dead claim, because there was no trial.

Estoppel landscape: empty. § 315(e)(2) estoppel only attaches to a petitioner that reaches a Final Written Decision. With zero IPRs, no party is estopped from anything, and there is no printed-publication/patent-art estoppel shadow constraining a defendant's invalidity case. That cuts both ways for you: you get a clean slate on prior art, but you also have none of the PTAB's work-product to borrow. A defendant would be building validity challenges from scratch, in district court, without the benefit of a Board construction.

Why the absence, and what it really signals. Three structural reasons explain the null PTAB record, and all three are useful to you:

1. The patent is expired. The ODP record shows filing 2000-03-08, priority 1999-04-06, and anticipated expiration 2020-03-08, with legal status "Expired - Fee Related." For a defendant, this collapses the assertion window: § 286 limits recovery to six years before filing, and the patent stopped issuing new infringement rights in March 2020. Any demand letter you receive is necessarily about past conduct in a narrow, closing window — a very different negotiating posture from a live patent with forward-looking injunctive leverage. (One caution: Google's "Expired - Fee Related" label is its generic bucket for patents past term and does not itself prove a maintenance-fee lapse. I did not independently verify the fee history, so don't argue lapse off that label alone.)
2. CBM is gone. Any covered-business-method theory would have been the natural fit for a 1999-priority content-rights-management patent, but the AIA § 18 CBM program sunset on 2020-09-16 — after this patent's expiration — and is unavailable now in any event.
3. No aggregator, no serial petitioner. I found no Unified Patents-style defensive aggregator in the chain and no repeat petitioner, because there is no petitioner at all. Conversely, the patent owner (Fujitsu Limited) has not pursued any PTAB appeal here, because there was nothing to appeal.

The honest read: for this patent, "no PTAB activity" is not evidence of a hardened patent. It is evidence of an old, expired, never-asserted-at-the-Board patent whose enforcement value is largely historical. That is a favorable fact pattern for a defendant — but it is a term-based defense, not an invalidity-adjudicated one.

---

Recommended next steps

• Do not cite a nonexistent FWD. There is no Final Written Decision for US 6,873,975 to link or quote. If opposing counsel or a demand letter implies the patent has been "upheld by the PTAB," that is false — it has never been before the PTAB. Ask them for the proceeding number.
• Verify the artifact, don't assume it. Before relying on my negative finding in a filing or opinion, run the patent number through PTAB E2E and the USPTO PTAB decisions page directly. I was unable to fully resolve whether IPR2022-00172 targets this patent or a different one, and I flag that as an open item rather than a conclusion. If it turns out to target 6,873,975, the entire analysis above changes and an institution decision or FWD may exist that the ODP has not indexed. This is the single highest-value check to run.
• Build the defense on expiration, not on PTAB estoppel. Confirm the actual maintenance-fee history and the effective expiration date via USPTO PatentCenter (the Google "Expired - Fee Related" tag is not proof of a lapse). Then map any asserted past conduct against the § 286 six-year lookback and the 2020-03-08 term expiry. If the demand letter targets post-expiration or out-of-window conduct, that is your dispositive threshold argument.
• If you need an invalidity case, start fresh. With zero PTAB estoppel, prior art is wide open — including the references this patent's own family cited (e.g., US 5,339,403; US 5,392,351; US 5,555,304; US 5,796,824; and JP 9-134311, all named in the specification's background) and the equivalent Japanese family member JP 3471654 B2. Pull the full prosecution history from PatentCenter before relying on any of them, since I have not reviewed the file wrapper.
• No trial-stage milestones apply. There is no institution-decision deadline, oral hearing, or statutory one-year FWD due date to track, because no trial was instituted. If E2E or PatentCenter reveals a live proceeding I could not confirm, the statutory § 316(a)(11) one-year clock runs from institution — re-run this analysis at that point.

Caveat on scope: my negative finding rests on the structured ODP block plus public web sources. I could not exhaustively query a subscription PTAB docketing service, and I was interrupted before resolving IPR2022-00172. Treat "no PTAB activity" as the well-supported default per the operating rules, not as a certified clean bill of health.

I'll research the assignment record for US 6873975.

Let me dig into the specific assignment records.

Let me look for the specific USPTO assignment record via dedicated sources.

Assignment & Ownership Analysis — U.S. Patent No. 6,873,975

Important methodological caveat up front: I was able to query only general web indexes, not the USPTO Patent Assignment Search backend directly. Google Patents' legal-events table for this patent does surface the assignment but renders it without the reel/frame number, and the Assignment Center pages themselves are not text-indexed by the search engines I could reach. I therefore could not retrieve reel/frame numbers, the recorded correspondent of record, or a recording date distinct from the execution/filing date. I will not invent those values. Where a field is unavailable I say so explicitly. Anyone needing the authoritative reel/frame should open Assignment Center directly (https://assignmentcenter.uspto.gov/) and search 6873975.

---

Inventors

All three are listed on the printed patent (75) with Kanagawa, JP addresses, and the (73) assignee is Fujitsu Limited — the classic Fujitsu in-house inventor pattern (inventors resident near the Kawasaki R&D campus).

Departure pattern: No unusual pattern. Hatakeyama and Yoshioka recur as Fujitsu inventors on later, related content-protection filings — e.g. US 7,383,446 ("Recording device", Fujitsu/Hitachi/Sanyo joint) and AU 2002224119 ("Data terminal for managing ciphered content data and license acquired by software"). That continuity indicates the inventors stayed in Fujitsu's content-security/DRM R&D group well past the 12-month post-filing window, which is the opposite of the "all inventors bail before a fire-sale" tell.

---

Original assignee

Fujitsu Limited, Kawasaki-shi, Kanagawa, Japan (printed on the face of the patent as (73) Assignee).

• Line of business: Diversified ICT — computing, servers, telecom equipment, and enterprise middleware/services. Not a patent-holding shell.
• Product embodying the claims: The patent is directed to a DRM-style architecture (copyright-holder system → content server → license server with LDAP directory → user system holding ACLs as AND/OR trees of partial licenses). This maps to Fujitsu's content-rights-management / secure-content middleware work of that era rather than a single shrink-wrapped SKU. I cannot point to a specific commercial product by name with confidence.
• Current status: Operating. Fujitsu Limited remains an active global IT services and hardware company. It has never been in bankruptcy; there is no Chapter 7/11 event touching this portfolio. (Its consumer PC business was spun off/sold in the 2010s–2020s, but that does not affect this patent's chain.)
• Patent status: Google Patents records "Expired – Fee Related" with an anticipated expiration of 2020-03-08 — i.e. Fujitsu let the patent lapse for non-payment of a maintenance fee rather than keeping it alive to the full term. This is a meaningful ownership fact: the patent was abandoned by its owner, not sold.

---

Assignment timeline

Chronological record of every assignment surfaced:

• 2000-03-08 (executed, coincident with filing) / recorded not retrieved — Reel not retrieved / Frame not retrieved
  • Conveyance: Assignment ("ASSIGNMENT OF ASSIGNORS INTEREST", per the Google Patents legal-events entry)
  • Assignor: Takahisa Hatakeyama; Yuji Miyazawa; Makoto Yoshioka (all three inventors, jointly)
  • Assignee: FUJITSU LIMITED
  • Correspondent: Not retrieved. I could not obtain the recorded correspondent from any indexable source. Flagging honestly rather than guessing.
  • Context: Ordinary employer/inventor assignment executed as part of the original filing of US application 09/521,646 — not a sale, reorg, or securitization.

That is the only assignment in the chain. There is no post-issuance assignment, no transfer to an IP-holding subsidiary, no security interest, no merger conveyance, and no change-of-name record associated with this patent in the sources I could reach. Ownership therefore remained with Fujitsu Limited from filing until the patent lapsed.

(Recorded and execution dates may differ; the Patent Assignment database frequently records inventor assignments weeks or months after execution. Because I could not pull the reel/frame, I cannot state the actual recording date.)

---

Timeline diagram

timeline
    title Ownership of US 6873975
    1999 : Priority date JP filing
    2000 : Filed as US 09 521 646
         : Inventors assign to Fujitsu Limited
    2005 : Patent issued to Fujitsu Limited
    2020 : Patent lapses for non-payment

---

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. No assignment from Fujitsu to any "…IP / Patents / Licensing / Holdings / Ventures" entity appears anywhere in the record. The sole assignee is an operating company, Fujitsu Limited.

2. Known asserter in the chain — NOT PRESENT. Neither Fujitsu Limited nor any successor appears on the Acacia / Marathon / Intellectual Ventures / Wi-LAN / Conversant / Vringo / Pendrell / Round Rock / Spangenberg-type lists. No high-frequency-plaintiff entity touches this patent.

3. Repeat correspondent across the chain — UNCLEAR. This signal cannot be evaluated: with only one assignment in the chain, there is no second link against which recurrence could be measured, and I could not retrieve the recorded correspondent for even that one link. Marked unclear due to missing data, not due to evidence of absence.

4. Cascading transfers — NOT PRESENT. There are zero consecutive transfers, let alone chained LLC hops within 24 months.

5. Pre-litigation transfer — NOT PRESENT. There is no infringement suit naming this patent (consistent with the separately generated litigation summary), so there is no litigation to precede.

6. Bankruptcy fire-sale — NOT PRESENT. Fujitsu Limited has not filed for bankruptcy protection; no Kodak/Nortel/Polaroid-style IP auction involved this patent.

7. Privateering — NOT PRESENT. No operating-company-to-NPE transfer exists to trigger this signal, and no SEC disclosure or Patent Progress / EFF coverage ties this patent to proxy assertion.

8. Defensive aggregator (anti-NPE) — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. Note the inverse: the patent was effectively neutralized by lapse (abandonment), not by acquisition into a defensive pool.

---

Verdict

Insufficient data — specifically, the chain consists of nothing but the original inventor-to-Fujitsu assignment executed on 2000-03-08, with no post-issuance assignment of any kind on record. Every NPE signal except the un-evaluable correspondent test is affirmatively not present: the assignee is an operating multinational, no shell or known asserter ever held the patent, no litigation asserts it, and the patent expired fee-related on 2020-03-08. This is an ordinary large-company captive patent that was abandoned, not a monetization vehicle.

Verify at: https://assignmentcenter.uspto.gov/ (search 6873975) or https://assignment.uspto.gov/patent/index.html — these will surface the single inventor-assignment record with the reel/frame and correspondent that I was unable to retrieve through search.

---

Cross-reference note for the file

• The previously generated litigation summary concluded no litigation is known and used the date stamp "as of April 26, 2026." Today's date in this analysis is 2026-09-24; the earlier summary's as-of date appears to be a stale/incorrect stamp. This does not change its conclusion, but flag it so the two sections are not read as contemporaneous.
• The no-litigation finding and the no-post-issuance-assignment finding are mutually reinforcing: with no assertion event and no ownership transfer, there is no NPE story to tell for this patent.

I'll search for the patent's front-page citations and the prior art it discusses.

Let me get the full front-page citation list from other mirrors.

I found the front page of the issued patent. Let me pull the full "References Cited" list and the claim text.

Prior-Art Analysis — U.S. Patent No. 6,873,975

Method, sources, and two hard caveats (read first)

What I was able to retrieve (and how):

• The issued patent's front page (56) "References Cited" block — recovered from the OCR text of the printed patent PDF at patentimages.storage.googleapis.com/2a/f8/fa/e7b80819c2977a/US6873975.pdf. This is the authoritative citation list, but it is partially truncated in the retrieved text (the foreign list and "Other Publications" run off mid-entry).
• Google Patents' "Patent Citations" table for this number — recovered via a mirror of the Google Patents page (patents.google.com/patent/US6873975B1/en), which contributed the assignee-and-title metadata for several entries and established the total count as "Patent Citations (22)."
• The specification's own Background of the Invention — from the authoritative full text supplied in this file, which expressly names four U.S. patents and one Japanese publication.

Caveat 1 — I could not retrieve the literal issued claim set. The Google Patents text supplied in this file jumps from the detailed description to the classification/"Landscapes" block without reproducing the numbered claims, and my remaining searches were cut off by the tool-step limit. I have therefore mapped prior art to the claim aspects identified in the previously generated Patent summary (aspects 1–10), not to verified claim numbers. Treat every "claims" reference below as provisional and confirm against USPTO PatentCenter before relying on it in a filing. This is consistent with — and reinforces — the uncertainty flag already on file in the Patent summary.

Caveat 2 — every reference below is already on the face of the patent. A reference that appears in the (56) block is one the examiner considered during prosecution. That does not make a § 102 theory impossible (examiners do err, and the examiner here faced a claim set that had been amended), but it does mean any single-reference anticipation argument built on these documents must explain why the examiner's allowance was wrong. I am flagging that posture rather than pretending each reference below is a clean kill.

Caveat 3 — a numeric discrepancy in the source itself. The specification text supplied in this file says the FIG. 19 access-control model "is described in U.S. Pat. No. 5,339,403." The printed front page lists "5,329,403 A 8/1994 Parker … 395/425." These are different numbers. Per the operating rules I am not auto-correcting either one; I report both and flag the conflict as unresolved. Verify at PatentCenter which number is actually the intended citation.

---

A. U.S. patent documents cited (front page (56))

All dates are issue dates as printed on the face of US 6,873,975. "§ 102 subsection" assumes the pre-AIA statute (the application was filed 2000-03-08, priority 1999-04-06, so pre-AIA governs). A reference pre-dating 1999-03-08 (one year before the U.S. filing) is available under § 102(b); U.S. patents issuing later are available, if at all, only under § 102(e) by virtue of a pre-critical-date filing.

---

B. Foreign patent documents cited (front page (56)) — list is truncated

The retrieved OCR of the (56) foreign block reads (verbatim, including the duplicate entry):

JP 63-182758   7/1988
JP 3-68024     3/1991
JP 5257816     10/1993
JP 5-257816    10/1993
JP 7-319691    12/1995
JP 8-069419    3/1996
JP 8-289004    11/1996
JP 9-106376    4/1997
JP 9134311     5/1997
JP 9-190236    7/1997

…then the text runs off mid-entry. Google Patents records 22 total citations, so the foreign list may extend beyond what I recovered.

I can confidentially describe only two of these, both of which the Google Patents citation table ties to Fujitsu:

• JP 5-257816 (pub. 1993-10-08; JPH05257816A) — "Electronic data protection method" (Fujitsu). § 102(b). Maps to the physical-element/equipment-ID encryption aspects (aspects 1, 3).
• JP 8-289004 (pub. 1996-11-01; JPH08286904A) — "Software encryption/decryption method, software encryption system and software decryption system" (Fujitsu). § 102(b). Maps to aspect 3 (encrypt/decrypt of content under license).
• JP 9-134311 (pub. 1997-05-20; JPH09134311A) — "Security system" (Fujitsu). This one is expressly named in the specification's Background as disclosing "a technique for preventing the illegal use of content by checking the equipment of the users." § 102(b). Maps to aspects 1, 3.

For JP 63-182758, JP 3-68024, JP 7-319691, JP 8-069419, JP 9-106376, JP 9-190236 I cannot supply titles or descriptions from the sources retrieved, and I will not invent them. All are pre-1999 publications and are therefore § 102(a)/(b) printed publications as a matter of date. Their subject matter must be pulled from JPO/J-PlatPat.

---

C. "Other Publications" (front page (56)) — truncated to one fragment

The only fragment recovered is "… Its Billing and Utilizing Management;". This is a non-patent-literature citation about software billing/utilization management. I could not identify the full document, author, or date, and I am not going to reconstruct it. It would matter if it discusses usage-metering/billing (aspect 2), but that is speculation.

---

D. Related family (not "prior art" in the strict sense)

• JP 3471654 B2 and JP application 11-099482 (priority, filed 1999-04-06) — the Japanese family member corresponding to this patent. This is the priority document, not prior art; it is useful as a prosecution/claim-scope cross-reference.
• A JPO Decision of Refusal dated 2/8/Heisei 22 (2010) issued against a Fujitsu sibling application (JP appl. 1999-264616, "Content usage control device, content usage control system…") was surfaced. It concerns a different application and is not a citation against US 6,873,975 — flagged only so it is not misfiled as prior art.

---

E. Bottom line — the most relevant prior art

1. The single most relevant reference: U.S. 5,715,403 (Stefik, 2/1998). Its "usage rights grammar" — a formal expression of permissions plus conditions (fees, time, etc.) attached to a digital work — is the closest prior art to independent claim aspect 1's "license … expressed as a structure by a combination of logic sums and logic products of a plurality of partial licenses." A § 102 attack would turn on the gap between a grammar of usage rights and the patent's boolean tree of partial licenses each separately encrypted under a distinct physical-element ID.

2. The closest technical family: the Stefik/Xerox–ContentGuard "digital works" set (U.S. 5,530,235; 5,629,980; 5,634,012; 5,638,443; 5,715,403; and, via § 102(e), 6,233,684 / 6,236,971). U.S. 5,634,012 in particular is the closest art on the patent's accounting-condition feature (claim aspect 2).

3. The closest art on the physical-element-ID / media-ID gating: the Fujitsu Hasebe family (U.S. 5,392,351; 5,555,304; U.S. 5,796,824) plus JP 9-134311. These are the references the patent itself concedes disclose the "check the user's equipment" technique — i.e., the patent's own admitted starting point. They are strong on claim aspect 3's ID-encryption idea but silent on the boolean partial-license structure and on accounting conditions.

4. Watch the § 102(e)-only references (U.S. 6,233,684; 6,236,971; 6,253,193). All three issued in 2001 — after this application was filed — so they are worthless as § 102(a)/(b) art against a 1999 priority date and survive only if their underlying applications were filed before 1999-04-06. I did not verify those filing dates, so do not assert them as prior art without pulling their continuations/priority chains.

Net assessment: No single reference on the face of the patent appears to anticipate the full scope of the independent claims, which is exactly what one would expect — these are the references the examiner considered and allowed over. The patent's apparent point of novelty (a boolean-combined license of partial licenses, each multiplicatively encrypted under a different physical element's ID, combined with usage-state-driven accounting conditions) is not squarely met by any one of them. The realistic use of this list is as a § 103 starting set (Stefik usage-rights grammar + Hasebe equipment-ID gating + a fee-metering reference), and even then the § 103 case must reckon with the examiner's prior allowance.

---

F. Items to verify before relying on this

1. Pull the literal claim set from USPTO PatentCenter for application 09/521,646 and re-map every row above to real claim numbers. My mapping is to invention aspects, not claims.
2. Resolve the 5,329,403 vs. 5,339,403 discrepancy (Caveat 3) — confirm which number the specification and the (56) block actually carry.
3. Recover the untruncated foreign list and the full "Other Publications" entry — my source text cut off. Google Patents' count of 22 citations suggests I may be missing one or more entries.
4. Confirm the § 102(e) filing dates for U.S. 6,233,684; 6,236,971; and 6,253,193 before treating any of them as prior art.

Cross-reference note: the previously generated Litigation summary carried an as-of stamp of "April 26, 2026" while the patent-text fetch was dated 2026-09-24; the same date inconsistency is present in this task header. It does not affect the prior-art conclusions above, but the file's dates should be reconciled. Also consistent with the earlier sections: no litigation, no PTAB proceeding, and no post-issuance assignment exists to change how this prior-art set should be read — these are purely prosecution-era references.

I'll gather grounding on the prior-art references this patent itself identifies, since the task points me to the Prior Art section.

Obviousness Analysis — U.S. Patent No. 6,873,975 under 35 U.S.C. § 103

Prepared: 2026-09-30 (task stamp says April 26, 2026 — see the stale-date flag carried forward from the earlier sections)
Patent: US 6,873,975 B1, Fujitsu Limited — priority 1999-04-06 (JP), filed 2000-03-08, issued 2005-03-29.

---

0. Evidence caveats you must read before using this section

Three limitations carried over from the earlier-generated sections bind this analysis:

1. The literal claim set was never in my source. The fetched Google Patents text jumps from the detailed description to the "Landscapes"/classification block and does not reproduce the numbered claims. Every claim-element mapping below is therefore built from the patent's "Summary of Invention" aspect paragraphs (which conventionally track the independent claims) and from the specification's own structural description (equations (1)–(3), FIG. 10 steps S430–S452, FIG. 3 ACL string). Verify each mapping against the USPTO PatentCenter claim text before relying on it in a filing.
2. I am interpreting "the Prior Art section of this page" literally. On the Google Patents rendering, that is the block containing Prior art keywords (content, license, information, physical elements, usage) and Prior art date 1999-04-06, plus the references the specification itself names. The patent's specification names exactly five prior-art items: US 5,339,403; JP 9-134311; US 5,392,351; US 5,555,304; US 5,796,824 (see the Background section: "A specific example of the access control model in the distributed system environment shown in FIG. 19 is described in U.S. Pat. No. 5,339,403. Japanese Unexamined Patent Publication No. 9-134311 and U.S. Pat. Nos. 5,392,351, 5,555,304 and 5,796,824 disclose a technique for preventing the illegal use of content by checking the equipment of the users."). I build the grounds on those, supplemented by contemporaneous art I could verify, and I label which references I could retrieve and which I could not.
3. No file wrapper, no IDS, no "References Cited" face-page list was retrieved. I cannot tell you what the examiner actually cited. That matters: the strongest § 103 arguments here are not about the examiner's art but about applicant-admitted prior art (below).

---

1. Governing law and the correct analytical frame

• Pre-AIA § 103 applies. The application was filed 2000-03-08, before the March 16, 2013 AIA change. Do not apply AIA § 102/103 or the "reasonable certainty" formulation. The frame is Graham v. John Deere, 383 U.S. 1 (1966): scope/content of the claims, differences over prior art, level of ordinary skill, and secondary considerations.
• KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007) controls the combination question. The four applicable rationales here are: (a) combining prior-art elements according to known methods to yield predictable results; (b) simple substitution of one known element for another to obtain predictable results; (c) use of a known technique to improve similar devices in the same way; and (d) "obvious to try" — a finite number of identified, predictable solutions.
• Critical threshold point: much of what claim 1 recites is admitted prior art in the specification itself. The Background states the conventional model works by "a device coincident with the physical element ID unique to the user system can basically decode the confidential content and use the content," and describes the "content cacheable model" (content server caching encrypted content in the open area, license obtained separately) as an existing distribution option. That admission is dispositive leverage for a § 103 attack on the broadest claims: the applicant conceded the architecture, and the asserted invention is only the structure of the license and the manner of its encryption.

---

2. Hypothetical claim set and element decomposition

(Using the earlier section's Summary-derived mapping; element letters are mine.)

Element-level note on 1a/4a: the specification itself, in FIG. 10 (steps S430–S452), reduces "logic sums and logic products of partial licenses" to a recursive descent parser over an ACL string: OR → {(AC, hash)Kp, returnvalue} (step S443), AND → {returnvalue, AC, hash}Kp (step S452). The claim is therefore directed to boolean expression parsing plus nested keyed encryption — a combination of two old software techniques, not a new machine or a new cryptographic primitive.

---

3. Level of ordinary skill in the art (POSITA), as of April 1999

A POSITA would have a bachelor's degree in computer science or electrical engineering (or equivalent), plus 2–3 years of experience in one or more of: cryptographic key management, operating-system/access-control design, or secure content distribution. This is a low-to-moderate skill level; the field in 1999 was crowded with well-documented prior art (the patent's own Background concedes the currency/copy-control problem was "long known"). The low skill level cuts against patentability: a POSITA would have read the Stefik and Ginter disclosures as cookbooks.

---

4. Prior-art inventory (verification status tagged)

References named in the patent's specification (the "Prior Art" section):

Contemporaneous art I verified (not named by applicant, but squarely in the field):

Not verified / flagged: I could not open the literal text of US 5,392,351, US 5,555,304, or JP 9-134311. Do not quote them as though I had.

---

5. Grounds of rejection — combination-by-combination

I present these as § 103 grounds. Primary reference in bold.

Ground 1 — [PA-6 Stefik '980/'012/'403] + [PA-5 US 5,796,824] + [PA-9 US 5,138,712] ⇒ claims 1, 2, 6, 7

• 1a (logic sums/products of partial licenses): Stefik's usage rights grammar is expressly structured as rights, each with nested conditions to exercising the right (copy-count, security class, access conditions, time, fee). Boolean combination of access conditions was, independently, the standard formalism of ACLs and X.509-style attribute certificates (PA-1 is itself a certificate-based boolean access model). Parsing a boolean license expression into a license tree (FIG. 10) is ordinary parser/compiler work.
• 1b (physical elements incl. media): US 5,796,824 claim 1 is nearly a verbatim disclosure — encrypted data on a medium, medium personal number unique to each storage medium written un-rewritably, used to generate a decryption key. Media is thus an already-established "physical element."
• 1c (user ID): ubiquitous; PA-4/PA-8 both authenticate the user.
• 1d (usage control unit): Stefik's repositories enforce the rights; PA-1's PUM validates; PA-7's VDE enforces.
• 2a (accounting conditions): Stefik '403 discloses exactly the categories of claim 2 — copy-count, time specification, fee specification, security class. PA-4 (Saito) discloses limiting the number of repetitions of copying/transferring. PA-7 discloses a "descending count of permitted use" and "expiration date."
• 6a (content server on open network): the specification admits the "content cacheable model" is prior art; Stefik's distributed repositories and PA-7's distributors confirm caching/server distribution.
• 7a–7d (management device with condition storage + key holding + extraction unit): US 5,138,712 (Orwin) and GB 2 236 604 both disclose a license server holding license records in a database, finding the matching token, and transmitting it on request — that is claim 7 almost element-for-element (substituting "license conditions + Kc" for "license token").

Motivation (KSR (a)+(c)): Both families target the identical problem — enforcing the copyright owner's conditions on digital content after it leaves the owner's control. Stefik teaches a condition grammar but binds enforcement to repositories/security classes; '824 teaches binding decryption to physical media. Combining them — putting a media/device physical-element credential into the condition set of the rights grammar — is the use of a known technique (media-bound keys) to improve a similar device (a rights-enforcement engine) in the same way, with a predictable result (the license can no longer be replayed on other media). Nothing in the art taught away; the references are complementary, not conflicting.

Predicted result: the license is now (i) expressed as a boolean tree of conditions and (ii) cryptographically tied to a media serial. Both results were expected in 1999. KSR, 550 U.S. at 417 ("combination of familiar elements according to known methods is likely to be obvious… when it does no more than yield predictable results").

---

Ground 2 — [PA-3 US 5,392,351] + [PA-4 US 5,555,304] + [PA-5 US 5,796,824] (the applicant's own cited trio), optionally + [PA-7 VDE] ⇒ claims 1, 3, 7, 8

This ground is deliberately built from the references the applicant itself cited as teaching "preventing the illegal use of content by checking the equipment of the users." Under § 103, a reference cited and characterized by the applicant is an admission that the reference is prior art and of what it teaches.

• 3a (production unit encrypts license + Kc using a plurality of physical-element IDs): PA-5 encrypts content and generates the decryption key from the medium personal number; PA-4 keys content to a permit key tied to the requested form of use; PA-3 is characterized by the applicant as checking user equipment. The claimed plurality is the ordinary aggregation of these: bind to media (PA-5) + bind to equipment (PA-3) + bind to a permitted-use credential (PA-4).
• 3b/3c (user decodes the license from its own IDs, checks conditions, then decodes content): This is precisely the request/challenge/decrypt loop of PA-8 (England) and the token-decode loop of PA-10 (GB 2 236 604), and it is the ordinary reverse of the encryption steps.
• 7/8 (server-side storage/extraction and client-side request unit): PA-9/PA-10 supply the server; PA-5/PA-4 supply the client-side key derivation from device/medium identity.

Motivation: The applicant conceded the problem ("the versatile control of the content usage has been impossible" because the license was produced "based only on the physical element ID"). If the only defect in the prior art is that it used one physical element instead of several, the fix is a simple substitution of a known element (a second/third device or media ID) for a known element (a single device ID) — KSR rationale (b) — with the predictable benefit of tighter binding. That is the definition of obviousness.

---

Ground 3 — [PA-6 Stefik '980 / '012 + PA-7 Ginter VDE] + [PA-1 US 5,339,403] ⇒ claims 1, 2, 3, 6, 7

• Boolean/logical combination of conditions (1a, 4a's precondition): Stefik's grammar permits a work to "have different versions of a right attached thereto… the conditions (and typically the fees) would be different." PA-1 discloses access rights embodied in an encrypted certificate validated by a shared validation unit. Combining a condition grammar with certificate-based validation yields a license that is both structurally boolean and cryptographically verifiable — the two halves of claim 1.
• Accounting conditions (2a): PA-7's "descending count of permitted use," "expiration date," and metering/budget structures are the same species as the patent's maxCount/totalLen/totalTimeLen/maxDebt.
• Content server (6a): PA-7's distributors + the specification's admitted "content cacheable model."
• Management device (7a–7d): PA-1's validation unit shared between a plurality of applications + PA-9/PA-10's license-token database.

Motivation: All three sit in the same distributed-rights-management field, address the same adversary (an untrusted client), and are architecturally compatible (a shared server holding rights + a client presenting a credential). Reasonable expectation of success is high — the interoperability of these exact pieces (a rights server issuing a certificate that a client validates and uses to unlock a key) was the well-understood template of the era. W3C's own retrospective records that ContentGuard asserted US 5,715,403 covers "any REL" (rights expression language) — i.e., the industry regarded the boolean rights grammar over conditions as the general prior-art template, not as this applicant's invention (https://www.w3.org/2012/09/odrl/archive/odrl.net/workshop2005/program/prez-guth-iannella.pdf).

---

Ground 4 — [PA-8 England (US 6,327,652 / 6,330,670)] + [PA-5 US 5,796,824] ⇒ claims 3, 8, 9 (+ medium claim 10)

• 8a (send physical-element ID + user ID on request): England's DRMOS, on requesting content, responds to the provider's challenge message asking for the identity of the CPU, the DRMOS, and the application. That is claim 8a almost verbatim.
• 8b (decode returned license information using own physical-element ID): England's rights manager certificate / access predicate comparison, plus the "license that specifies limitations on the use of the content"; PA-5's medium-personal-number key derivation.
• 8c (decode content with the decode key when permitted): England's control block releases the cryptographic key to the stream controller on satisfaction of the rule.
• 3a (encrypt license AND content decode key with the physical-element IDs): the complement of 8b; PA-5 teaches the key-generation-from-identifier half; England teaches the challenge/identity half.
• Method claim 9 / medium claim 10: England is a method/system disclosure; a POSITA implements it as stored program instructions — a computer-readable recording medium claim adds nothing patentable over a disclosed method implemented in software (routine implementation choice).

Motivation: England and '824 are directed to the identical goal (limiting content use to an authorized machine) and are combinable without modification because England already collects machine identity and '824 already derives decryption keys from a machine/media identifier. Simple substitution of England's CPU-identity challenge with a media-serial-based key generator (or the mere addition of the media element) yields a predictable system.

---

Ground 5 — any of Grounds 1–4 + the general knowledge of superencryption / multiple-key combination ⇒ claim 4 (multiplied encryption)

Claim 4 recites that where the interface between partial licenses is a logic product (AND), the encryption "based on the ID information of the physical elements corresponding to the partial licenses is multiplied," distributing the risk of Kc theft.

• The specification itself shows multiplication is mere nesting: {{{{{{<access information>}K5}K4}K3}K2}K1} (equation (1)) — i.e., encrypt with K5, then K4, then K3… That is superencryption / cascaded encryption, a technique at least as old as multistage cipher machines and standard in key-management literature. Where the elements have comparable security, the patent itself falls back on exclusive-OR of the keys (equation (2)) — an even older combining operation.
• Motivation is express: distribute the risk that one compromised element exposes Kc. Under KSR rationale (d), requiring n independent secrets to recover a key is a finite, identified, predictable solution to the single-point-of-failure problem, and its result (attacker needs all n keys) is exactly what a POSITA would expect — no more than the predictable sum of the known parts.
• PA-5 already establishes the "encrypt content key under a medium identifier" step; multiplying that step by n identifiers is arithmetic, not invention.

Note on equation (3) (OR-combination: {<access information>}K5 + {…}K4 + …): the specification itself frames this as producing "sublicenses" combined "by simple OR operation," and states "AND, XOR and OR operations are combined in nest relation to generate a license." A POSITA writing a recursive generator over a boolean expression string would arrive at exactly this — which is the point of FIG. 10.

---

Ground 6 — claim 5 (contained physical elements handled as one) — weakest ground; flag it

Claim 5 (contained elements treated as a single element, per FIG. 9's OS-kernel/device-layer containment tree) is the element for which I have the least verified prior art. Candidate support:

• PA-1 US 5,339,403 — a distributed system in which a user's rights are represented through nested system/application structure validated centrally.
• General OS device-model knowledge: device trees, parent/child driver containment, and treating a composite device (e.g., an MO drive + loaded MO disc) as a single logical unit were ordinary in 1999 OS design. The specification itself notes "a single physical device such as an MO device can function as the content storage device and the usage environment specifying element at the same time."
• Assessment: I would rate claim 5 obvious over the architecture references combined with ordinary skill, but with lower confidence than claims 1–4 and 6–9, because it depends on a specific device-model convention that I have not grounded in a verified reference. Do not lead with claim 5.

---

6. The single strongest § 103 posture: applicant-admitted prior art

Independent of which references you cite, the specification concedes the following as old:

1. Storing encrypted content on a content server in the open area and caching it there ("content cacheable model").
2. Decrypting content in a confidential protection area using a content decode key Kc tied to a physical-element ID, where "a device coincident with the physical element ID unique to the user system can basically decode the confidential content and use the content."
3. The problematic consequence: because the license "is produced based only on the physical element ID," one cannot add read-frequency limits, time limits, or charging conditions — "the versatile control of the content usage has been impossible."
4. Distributing the license and content separately (license server vs. content server), with delegation of the access-control right from the copyright holder to the license server.

Once those are admitted, the entire delta of the invention is: (i) make the license a boolean structure; (ii) use several physical elements instead of one; (iii) add accounting conditions to the condition set; (iv) nest the encryption across the elements. Each delta is a known technique applied to an admitted, known base — the textbook KSR fact pattern.

---

7. Anticipated non-obviousness arguments, and why they fail

---

8. Conclusion

Ranked obviousness assessment (pre-AIA § 103), with confidence:

Bottom line: US 6,873,975 is highly vulnerable to a § 103 challenge built from (a) the applicant's own admitted prior-art architecture, (b) the ContentGuard/Stefik usage-rights-grammar family (conditions incl. count, time, and fee) and InterTrust/Ginter VDE family (metering, descending counts, expiration, secure containers with decryption info), (c) the machine/media-identity art the applicant itself cited — US 5,392,351, US 5,555,304, US 5,796,824 — and (d) the license-server token art (US 5,138,712; GB 2 236 604). Every separate feature the patent claims as its contribution — boolean-structured license, multi-element binding, accounting conditions, multiplied encryption — was independently known; their aggregation yields only the predictable result of a more tightly bound, more finely conditionable license. That is the core KSR fact pattern.

Practical caveats before you rely on this:

• Pull the literal claims from PatentCenter. My element decomposition is a Summary-derived proxy; if the issued claims contain an unexpected limitation (e.g., a specific data structure, a specific ordering of decryption, or a negative limitation), the strongest grounds may need to be re-aimed. This is the single highest-value verification step.
• Do not quote US 5,392,351, US 5,555,304, or JP 9-134311 as though I verified their text. I did not. Retrieve them (and the JP family member JP 3471654 B2) before citing them.
• Confirm the Stefik and Ginter citations. I verified their teachings through secondary sources (W3C deck, EP 1 329 794 B1, PTAB petition excerpts) and verified US 5,796,824's claim 1 and US 5,339,403's abstract/claim 1 directly. The Stefik/Ginter patent documents themselves should be pulled and pinpoint-cited.
• Stale-date flag (repeated from the earlier sections): the litigation summary carried an "as of April 26, 2026" stamp; today's analysis date is 2026-09-30 (the task header says April 26, 2026). This does not change the obviousness conclusions, but the sections should not be read as contemporaneous.