US 7502897

I'll search for authoritative records on this patent number, including litigation dockets, then summarize.

US Patent 7,502,897 — Verification Summary

Important disambiguation: I searched USPTO/Google Patents and Federal Circuit 2026 docket materials for the identifier "7502897." The only 2026 docket hit containing that digit string was an unrelated Seventh Circuit criminal appeal (USA v. Charles Carroll, No. 25‑3095), where "[7502897]" is a CM/ECF document/brief entry number, not a patent number. I found no Federal Circuit appeal, IPR appeal, or district court case in 2026 (or otherwise) involving U.S. Patent 7,502,897. I cannot rule out an unindexed or very recent filing, so treat "no litigation found" as a negative search result rather than an affirmative clearance statement.

Bibliographic Data (from the authoritative full text at patents.google.com/patent/US7502897/en)

Abstract (verbatim)

"Object-based conflict detection is described in the context of software transactional memory. In one example, a block of instructions is received for execution as an object in a software transactional memory transaction. The base of the object is computed, a lock is found for the object using the base of the object."

Plain-Language Overview of Each Independent Claim

Claim 1 — Method (the core concept).
A method with three steps: (1) receive a block of instructions to be executed as an object within a software transactional memory (STM) transaction; (2) compute the base address of that object; (3) use that base address to locate the lock for the object. The key idea is that conflict detection is done at object granularity by first deriving the object's starting address, then looking up its lock — rather than hashing the raw pointer into a global lock table.

Claim 10 — Machine-readable medium (software product claim).
A non-transitory-style medium storing instructions that cause a computer to: receive a pointer to a memory block holding an allocated object in STM; determine a header address for that block from the pointer (e.g., by masking low bits, so any interior pointer into a multi-object block resolves to the correct block); access the block header; determine the object's base using information stored in the header (such as object size); and use that base to find the object's lock. This claim captures the "interior pointer → block header → object base → lock" resolution chain that makes the approach work for C/C++ where pointers can point into the middle of an object or nested structure.

Claim 18 — Computer system (apparatus claim).
A system comprising an STM that stores instruction objects and corresponding locks, plus a processor coupled to the memory. The processor includes memory management logic that determines the locks for objects and stores those locks in memory, and that—when receiving an object—computes the object's base and finds the object's lock from that base. This recasts the method of claim 1 as a hardware/software system configuration.

Notable Dependent Claim Subject Matter

• Claim 2/3: computing the base uses the block header and the size of objects in the block.
• Claim 4: the base yields an index into a lookup table of locks.
• Claim 5: the lock is the first word following the object's header (the "inline lock" embodiment of FIG. 2).
• Claims 6–8: if the block is not within a reserved "small object" area, fall back to hashing-based conflict resolution; the test is expressed as interior_pointer − reserved_base_address < reserved_area_size, an unsigned comparison.
• Claim 9: the lock is written into the base by a memory manager (automatic lock provisioning, not programmer-managed).
• Claims 11–17 (dependent on 10): index-to-lock-table, object-size-based header/base determination, on-side locks (separate lock table per block, FIG. 1) vs. inline locks (reserved word adjacent to the object, FIG. 2), and use of the lock for conflict resolution.

Technical Contribution in One Paragraph

The patent addresses false conflicts in prior STM conflict-detection schemes, which were either cache-line granular (too coarse, producing false conflicts and blocking compiler CSE/redundancy elimination) or word/field granular (too much overhead). The claimed approach instead allocates one lock per object: an incoming interior pointer is range-checked against a reserved "small object space," resolved to its enclosing memory block header by bit-masking, and converted into an object base/index using uniform object size from the header, which then indexes a lock table (on-side) or yields a lock stored in memory reserved just before the object (inline). Objects outside the reserved area fall back to hashing.

Caveats / Uncertainty

• I have no authoritative confirmation of any 2026 litigation, IPR, or Federal Circuit docket for this patent number; this is a statement about search coverage, not a legal conclusion.
• The B1 vs. B2 kind-code discrepancy is noted deliberately and not auto-corrected; the granted document text supports B2.
• The 2010 assignment to Oracle International Corporation (from BEA Systems, Inc.) and the co-listing of Intel Corp as a current assignee in Google's automatically generated "Current Assignee" field are as recorded in the assignment/legal-events data; Google explicitly disclaims accuracy of that field.

I'll search litigation databases for US patent 7502897.

Let me search more targeted litigation databases.

Let me try a few more targeted searches on patent litigation databases.

Litigation Search Results — U.S. Patent No. 7,502,897

Bottom line: I found no litigation involving U.S. Patent No. 7,502,897.

I ran multiple targeted searches (patent number in both 7,502,897 and 7502897 formats, combined with "litigation," "lawsuit," "infringement," "complaint," "district court," and the patent's title) across publicly indexed litigation sources, including Justia Dockets, CourtListener/RECAP, Docket Alarm, PACER Monitor, and the Google Patents litigation/"Cited By" section for this patent. No district court case, ITC investigation, PTAB proceeding, or CAFC appeal asserting or challenging this patent was identified.

Requested case table

Because no case exists in the sources searched, the remaining requested fields cannot be populated. I will not fabricate entries to fill them.

What I did find (and why these are not the patent)

Several false-positive hits contain the digit string "7502897," and per your instruction I confirmed each is a different identifier, not this patent:

• JP7502897T — a Japanese national-phase patent publication number, not the U.S. patent.
• FR7502897A — a French application number (FR2260184A1).
• US 7,502,897 listed in "Back stretcher – USD398399S" — this is a Google Patents render of the design patent's application number US29/075,028, not U.S. 7,502,897.
• [7502897] in USA v. Charles Carroll (7th Cir. 25-3095) — a CA7 docket entry number, not a patent.
• 10.1109/NOMS.7502897 — an IEEE DOI suffix.
• Brazilian legislation citation E=692987 e N=7502897 — a legislative point number.

None of these reference the patent at issue.

Patent context (from the authoritative full text)

• U.S. Patent No. 7,502,897 B2, "Object based conflict detection in a software transactional memory."
• Application 11/477,339; filed June 28, 2006; granted March 10, 2009.
• Inventors: Ben Hertzberg, Bratin Saha, Ali-Reza Adl-Tabatabai; original assignee Intel Corp; current assignee listed as Oracle International Corp (recorded assignment from BEA Systems, Inc., effective 2010‑10‑08).
• Continuation: US 7,802,059 B2 (from application 12/270,710, filed 2008‑11‑13) — same family, same title.
• Legal status: Expired – Fee Related; maintenance fees lapsed and the patent expired 2021‑03‑10; adjusted/googled expiration listed as 2026‑12‑11.

No litigation is recorded against the patent or its continuation in the public indexes reviewed.

Caveats and recommended verification steps

I want to be explicit about the limits of this negative finding, rather than overstate confidence:

1. Database coverage. My searches ran against publicly crawlable sources. Unified Patents' litigation caselist, Docket Navigator, and Lex Machina sit behind subscriptions or require interactive queries, and I could not execute a full end-to-end PACER party/patent-number query in this session.
2. Indexing gaps. Patent numbers are sometimes absent from complaint captions or docket text, so a case could exist without surfacing on a plain-text number search. A case would also be hard to find if pleadings are sealed or the docket is not in RECAP.
3. Practical likelihood. Given the patent issued in 2009, was assigned into the Oracle portfolio, and expired for non‑payment of maintenance fees in 2021, the absence of litigation is consistent with the record — an expired, fee-lapsed patent is an unlikely assertion vehicle.

Suggested next steps to confirm definitively: search the Unified Patents Patent Litigation Docket (https://portal.unifiedpatents.com/litigation/caselist) by patent number, run a patent-number search in Docket Navigator or Lex Machina, and run a PACER "party/patent" query on the '897 and '059 numbers against both Intel and Oracle International Corp.

If you have a specific case caption, court, or party in mind, provide it and I will verify it directly against the '897 patent rather than relying on number-string matches.

I'll verify the structured no-activity finding against public sources before writing up.

Proceedings overview

Zero (0) AIA trial proceedings have ever been filed against US 7,502,897 — 0 active, 0 with claims invalidated, 0 with claims sustained, 0 settled, 0 institution-denied — so a defendant today does not face "hardened" claims that survived an IPR nor "dead" claims canceled in one; it faces a patent whose validity has never been tested by the Board and whose family expired for failure to pay maintenance fees on 2021-03-10.

Proceedings (0) — I am not going to generate proceeding headings for proceedings that do not exist

The structured "PTAB proceedings on file" block (USPTO Open Data Portal) returned no AIA trial proceedings for this patent, and my independent searching did not surface any. Because the canonical list is empty, there is no ### IPR####-##### — Petitioner v. Patent Owner entry to write, and I will not invent a proceeding number, panel, or FWD to fill the template. What I can give a defendant is the verification trail and the strategic consequence.

Sources checked for AIA trial activity (search run 2026-09-27):

Confirmed false positives (number-string matches only — none is this patent):

One data point worth flagging without relying on it: during searching, an IPR exhibit record (a Colwell declaration) surfaced for US 8,898,395, a transactional-memory patent concerned with cache-line marking bits. I did not verify the petitioner, patent owner, or outcome, so I draw no conclusion from it other than that mid-2000s STM patents were in the IPR crosshairs in that era — which makes the total absence of challenges to the '897 patent a real signal, not just a default.

Strategic summary

Claim status — all 20 claims are UNTESTED. Independent claims 1, 10 and 18, and every dependent claim (2–9, 11–17, 19–20), stand exactly as they issued on 2009-03-10. Nothing has been canceled, nothing has been confirmed, nothing has been narrowed by amendment or certificate (the only post-grant paper in the legal events is a certificate of correction recorded 2010-04-06). There is therefore no Final Written Decision to quote, no claim-level disposition to borrow, and no PTAB claim construction for a defendant to work from. The only prior art the examiner is recorded as having considered was a single reference — US 6,850,938 B1 (Cisco, "Method and apparatus providing optimistic locking of shared computer resources") — plus a non-patent citation (Microsoft Computer Dictionary, 5th Ed., 2002, p. 465). That is a thin prosecution record, which cuts in favor of a challenger on the merits but gives you nothing in the way of a ready-made invalidity narrative.

Estoppel landscape — there is none, but the more important point is that the AIA trial vehicle is largely academic. No petition was ever filed, so § 315(e)(2) estoppel has never attached to anyone, and no § 315(b) one-year clock has ever started for any party. Every prior-art ground is theoretically still available. Two structural notes: (i) this is a pre-AIA patent (filed 2006-06-28), so PGR was never available; and (ii) a software transactional memory patent is not a "covered business method patent" directed to a financial product or service, so CBM was never available either — and the CBM window closed on 2020-09-16 regardless. IPR was the only AIA trial path ever open against this patent, and even that is now of limited practical use: the patent expired on 2021-03-10 for failure to pay maintenance fees, so a defendant sued on pre-expiration conduct could still file an IPR within one year of service, but the patent owner would have no live claims to amend and the relief would be aimed at back-damages exposure, not at stopping ongoing sales.

Pattern signals — absence across the board, and a fee-lapsed family. No petitioner has filed once, let alone repeatedly; no defensive aggregator (Unified Patents or similar) appears anywhere in the chain; the patent owner has never had occasion to defend a Board appeal, so there is no Federal Circuit docket for this patent or its continuation. The assignment history (Intel → effectively Oracle International Corporation via BEA Systems, recorded 2010-10-15) put the patent in a portfolio, but the family's own metadata shows it was never asserted and never monetized: Google Patents lists both US 7,502,897 and its continuation US 7,802,059 B2 (app. 12/270,710, issued 2010-09-21, adjusted expiration listed as 2028-11-13) as "Expired – Fee Related." In other words, the owner let a continuation with roughly two more years of nominal term die for non-payment too. That is the behavior of a patent nobody intended to enforce. The 58 forward citations — concentrated in Intel and Microsoft transactional-memory filings — show the disclosure matters to the art; they do not show anyone needed to kill it.

Recommended next steps

If you are a defendant, there is nothing to petition against right now, and nothing to copy from a Board decision. State the position plainly:

1. Run the expiration math first. The '897 patent expired 2021-03-10 ("Patent expired for failure to pay maintenance fees," recorded 2021-04-12). No accused conduct after that date can infringe. Under 35 U.S.C. § 286, a complaint filed today (2026-09-27) reaches back only six years, to 2020-09-27 — leaving a theoretical back-damages window of roughly 2020-09-27 to 2021-03-10. Verify the exact lapse date and any intervening-rights or revival issues; a petition under 37 C.F.R. § 1.378 to revive for unintentional delay is theoretically available to a patent owner, and I found no evidence of any such petition on the record — but I did not search the PTO's petition-decision records, so treat that as an unverified negative.
2. Do not budget for an IPR as a first-line defense. With no prior institution decision, no FWD, and no Board claim constructions, an IPR would be built from scratch, and its only payoff is against a narrow pre-2021 damages claim. If you are served, calendar the § 315(b) one-year bar immediately, because that is the only deadline that could force the issue.
3. Screenshot and preserve the expiration record (Google Patents legal events, and the USPTO PatentCenter maintenance-fee page for both the '897 and '059 patents) for the demand-letter response — it is the single most efficient defense you have.
4. If a demand letter cites claims 1–5, 10, or 18, the response is not "those claims are invalid under an FWD" (there is none). It is: the patent is expired and unenforceable for prospective conduct, the recoverable window is measured in months, and the patent issued over a single prior-art reference with its own specification admitting that cache-line and hashing schemes were the prior approach.
5. Confirm the absence independently before relying on it: search https://ptab.uspto.gov/ (PTAB E2E) by application 11/477,339 and by patent numbers 7,502,897 and 7,802,059; check the USPTO PTAB decisions page (https://www.uspto.gov/patents/ptab/decisions) and CourtListener (https://www.courtlistener.com/) for any appeal; and, because patent numbers are sometimes omitted from captions, run the same query against the Unified Patents litigation caselist (https://portal.unifiedpatents.com/litigation/caselist) and Docket Alarm.

One cross-reference flag for the record: the earlier litigation section in this analysis reached the same negative result for court proceedings, so the litigation and PTAB pictures are consistent — a fee-lapsed patent that was never sued on was also never IPR'd. Separately, I noticed that the continuation US 7,802,059 appears to carry a different claim set from the '897 patent (directed to determining whether a pointer is in "small object space," masking lower bits to obtain a block header, and determining object size from the header, rather than to computing a base and finding a lock from it). I saw this in published-application and aggregator text, not in a verified granted-claims document, so I flag it as an apparent discrepancy to verify rather than as a finding — but if accurate, it means a challenger would need a separate petition per patent, not one petition covering the family.

I'll verify the assignment record details and try to surface the correspondent of record, which is not in the Google Patents legal-events data.

Let me try to fill the two gaps: (a) the correspondent of record, and (b) how BEA Systems came to be the assignor in 2010 for an Intel-originated patent.

The reel/frame I found is important — 025192/0244 is the blanket BEA→Oracle merger-cleanup assignment used across the entire BEA portfolio (Espacenet INPADOC shows the same reel/frame on US 7,028,030, a different BEA patent). Let me check for the missing Intel→BEA link.

Assignment / Ownership Reconstruction — US 7,502,897 B2

Scope and source caveat (read first). Everything below is built from (a) the assignment and legal-events records reproduced on the authoritative full text at https://patents.google.com/patent/US7502897/en, and (b) corroborating records I could retrieve for the cited reel/frames. Two data elements you specifically asked for are not exposed in any source I could reach:

• Correspondent of record (the attorney/firm that filed each recording). Neither Google Patents' legal-events block nor the corroborating records I retrieved publish the correspondent. I will not guess a name or firm. Note also that the 2006-2008 Intel record (020343/0650) predates USPTO's modern correspondent-capture practice for many bulk filings, so it may be blank even in the Assignment Center.
• The intervening conveyance from Intel Corporation to BEA Systems, Inc. The chain as recorded has a gap that I flag explicitly in the timeline section.

To pull correspondents directly, run the patent-number query at https://assignmentcenter.uspto.gov/ (mirror: https://assignment.uspto.gov/patent/index.html) and expand each record's "Correspondent" field; also run an assignor query on BEA Systems across the same date range to see whether a separate Intel→BEA reel exists but is not linked to this patent's page.

Inventors

Employer determination. The three inventors' employer is established by the executed assignment itself (Reel 020343/0650, assignors "HERTZBERG, BEN; SAHA, BRATIN; ADL-TABATABAI, ALI-REZA" → Intel Corporation) and corroborated by the contemporaneous Intel paper "Implementing a High Performance Software Transactional Memory for a Multi-core Runtime" (Saha, Adl-Tabatabai, Hudson, Minh, Hertzberg, PPoPP 2006), which surfaced in my search results as a non-patent citation to a sibling Intel patent (US 9,304,769).

Unusual patterns — assessed:

• Execution dates lag the filing date. Signing dates are 2006-09-15 to 2006-11-16, i.e., roughly 3–5 months after the 2006-06-28 filing. This is the ordinary "file first, paper the assignment later" employment practice; it is not a fire-sale tell.
• No mass inventor departure. Saha and Adl-Tabatabai continue appearing as Intel inventors/assignors on later Intel STM filings (e.g., the 2006-12-28 and 2007-04-09 family members listed in this patent's "Cited By"). There is no evidence in the record of the entire inventive team leaving Intel within 12 months of filing. Not present.
• One caveat I cannot resolve: I found no authoritative record of Ben Hertzberg's subsequent employment (he appears on Intel filings into 2007, but I have no reliable post-2008 employment data). I flag this as unknown, not as a finding.

Original assignee

Intel Corporation, Santa Clara, CA (named on the face of the granted patent).

• Line of business: semiconductor design and manufacturing — microprocessors, chipsets, platforms, and the compilers/runtimes that accompany them.
• Product embodying the claims: Unclear / no confirmed product. The claims cover an STM conflict-detection mechanism (object-base resolution → per-object lock), implemented as a software transactional memory library or as compiler routines. Intel's STM work was research-grade; Intel's shipping transactional-memory feature (TSX) arrived years later on Haswell (2013) and is hardware transactional memory, not the claimed object-based STM locking scheme. I found no evidence that Intel ever shipped a commercial product practicing claims 1/10/18. Treat "no product" as a negative search result, not proof of absence.
• Current status: Operating. Intel remains a going concern and is not in bankruptcy. Google Patents' automatically generated "Current Assignee" field lists both Intel Corp and Oracle International Corp; Google expressly disclaims the accuracy of that field, and the recorded chain (below) shows Oracle as the terminal assignee.

Assignment timeline

Two conveyances are recorded, plus one non-conveyance legal event. Then a gap.

1. 2006-09-15 / 2006-11-16 (executed — two signing dates across the three inventors) / recorded 2008-01-09 — Reel 020343/0650

• Conveyance: Assignment (recorded as "ASSIGNMENT OF ASSIGNORS INTEREST")
• Assignor: Ben Hertzberg; Bratin Saha; Ali-Reza Adl-Tabatabai (individually)
• Assignee: Intel Corporation, Santa Clara, CA
• Correspondent: Not retrievable from the sources available. I cannot state the filing attorney/firm. No basis to flag recurrence.
• Context: Routine employee-inventor assignment to employer.

2. 2010-10-08 (effective) / recorded 2010-10-15 — Reel 025192/0244

• Conveyance: Assignment
• Assignor: BEA Systems, Inc.
• Assignee: Oracle International Corporation, Redwood Shores, CA
• Correspondent: Not retrievable. However, I can report a strong corroborating fact about the reel itself: reel/frame 025192/0244 is a bulk, portfolio-wide record. Espacenet's INPADOC legal status for an unrelated BEA-origin patent, US 7,028,030 B2 ("Cluster caching with concurrency checking"), shows the identical entry — assignee "ORACLE INTERNATIONAL CORPORATION, CALIFORNIA," effective date 20101008, "ASSIGNOR: BEA SYSTEMS, INC.; REEL/FRAME:025192/0244." That is the signature of a single blanket merger-cleanup instrument recorded against the whole BEA portfolio on one day, not a patent-specific negotiation. The recurrence here is of a reel, not of an attorney, so it does not satisfy your repeat-correspondent test.
• Context: Internal reorg / post-merger transfer. Oracle acquired BEA Systems in its fiscal 2008 (Oracle's own corporate reporting lists "BEA Systems, Inc. in fiscal 2008" among its acquisitions); the 2010 recording is the delayed papering of that merger — hence the ~2.5-year lag between deal close and recordation.

3. Non-conveyance legal event — recorded 2010-04-06 — Certificate of Correction. Not an assignment; it changes no ownership. Listed only because it appears in the legal-events block and could be mistaken for a chain link.

4. ⚠️ DOCUMENTATION GAP — no recorded Intel → BEA Systems conveyance found. The recorded chain jumps from Intel (owner via Reel 020343/0650, 2008) to BEA Systems as assignor (Reel 025192/0244, 2010) with no intervening recorded assignment in the indexed data. One of the following is true, and I cannot determine which from available sources:

• (a) An Intel→BEA (or Intel→Oracle) assignment was executed and recorded on a reel that is simply not hyperlinked on this patent's Google Patents page; or
• (b) The reel 025192/0244 record enumerates patents by portfolio schedule and this patent's inclusion reflects an instrument whose Intel-side link is separately indexed under a different patent number; or
• (c) A data artifact in the aggregation layer.

Recommended verification: query the Assignment Center by patent number 11/477,339 and separately by assignor BEA Systems, Inc. with a 2007–2010 date window, and pull the full property list attached to reel 025192/0244.

Timeline diagram

timeline
    title Ownership of US 7502897
    2006 : Filed by Intel Corp
         : Inventors sign assignment
    2008 : Assignment recorded to Intel
         : Continuation 12270710 filed
    2009 : Patent issues as US 7502897 B2
    2010 : Certificate of correction
         : Recorded transfer to Oracle via BEA
    2012 : Maintenance fee year 4 paid
    2016 : Maintenance fee year 8 paid
    2021 : Expires for unpaid maintenance fees

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT.
No LLC or naming-suffix entity appears anywhere in the chain. Both recorded assignees are century-scale operating corporations: Intel Corporation (Reel 020343/0650) and Oracle International Corporation (Reel 025192/0244). No registered-agent service address, no single-member LLC.

2. Known asserter in the chain — NOT PRESENT.
Neither Intel nor Oracle International Corporation appears on the NPE rolls you cited (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities) or in my Unified Patents / RPX review. Oracle is a prolific commercial litigant and a frequent patent defendant/plaintiff, but it is an operating company, not an NPE.

3. Repeat correspondent across the chain — UNCLEAR / NOT ASSESSABLE.
The correspondent field is not published in any source I could reach for either reel (020343/0650 or 025192/0244), so I can neither confirm nor rule out that a single attorney/firm handled both. I explicitly decline to substitute a guess. One adjacent fact, offered without over-reading it: reel 025192/0244 is demonstrably a bulk instrument recurring across the BEA portfolio (see US 7,028,030, Espacenet INPADOC) — that is evidence of a corporate record-keeping event, not of a repeat NPE attorney.

4. Cascading transfers — NOT PRESENT.
Two recorded links, ~4.5 years apart (2008-01-09 and 2010-10-15). No chained LLCs, no transfers within <24 months, no shared correspondent address evidence.

5. Pre-litigation transfer — NOT PRESENT.
The prior analysis found no litigation involving this patent. There is therefore no suit to measure a 6-month window against. For completeness: the last transfer (effective 2010-10-08) would precede the present date by ~16 years, which is the opposite of a set-up-to-sue timing.

6. Bankruptcy fire-sale — NOT PRESENT.
No Chapter 7/11 sale, no stalking-horse or §363 sale. The 2010 event is the papering of Oracle's acquisition of BEA (a solvent merger), and Intel — the original assignee — never filed for bankruptcy.

7. Privateering — NOT PRESENT / UNCLEAR.
No operating company transferred this patent to an NPE to assert against competitors. The transfer is Intel → BEA (unrecorded link) → Oracle, i.e., operating company to operating company. I found no SEC disclosure, Patent Progress, or EFF coverage tying this patent to a privateering arrangement.

8. Defensive aggregator — NOT PRESENT.
The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN.

Additional signal worth recording (not in your list): lapse/abandonment. The chain terminates in abandonment: fee year 4 paid 2012-09-05, fee year 8 paid 2016-08-25, then "MAINTENANCE FEE REMINDER MAILED" (2020-10-26), "LAPSE FOR FAILURE TO PAY MAINTENANCE FEES" (recorded 2021-04-12, effective 2021-03-10), and "PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362." An NPE keeps its ammunition in force; an operating company letting a 2009 patent lapse is consistent with a portfolio it never asserted.

Verdict

Insufficient data — with the substantive finding stated plainly: no NPE pattern is present.

Reasoning: (i) the two recorded conveyances are Reel 020343/0650 (2006-09-15/2006-11-16 executed; 2008-01-09 recorded; inventors → Intel) and Reel 025192/0244 (2010-10-08 effective; 2010-10-15 recorded; BEA Systems → Oracle International, a portfolio-wide merger-cleanup instrument corroborated on US 7,028,030), both between large operating corporations, with zero shell, asserter, cascade, pre-litigation, bankruptcy, privateering, or defensive-aggregator signals, and the patent was abandoned in 2021; and (ii) I nonetheless cannot award a clean "operating-company" verdict because the record has an unresolved gap — no Intel → BEA conveyance is indexed — and the correspondent of record for both reels is unavailable, which is precisely the field that would let me detect a repeat-player attorney hiding behind an anonymous intermediary. That combination is "insufficient data" in the sense of incomplete record, not absent record: had an intervening NPE link existed, it would most plausibly sit in exactly that gap.

Verify at: https://assignmentcenter.uspto.gov/ (mirror https://assignment.uspto.gov/patent/index.html) — query patent 11/477,339 for both reel/frame entries and their Correspondent fields, and query assignor BEA Systems, Inc. over 2007–2010 to locate the missing Intel-side link.

I'll verify the cited prior art against authoritative sources. Let me run targeted searches.

Prior-Art Analysis — U.S. Patent No. 7,502,897

1. USPTO record confirmation (exact-number lookup, no substitutes)

The record matching the exact identifier 7502897 is:

Authoritative source: https://patents.google.com/patent/US7502897/en (full text supplied in the authoritative extract) and the grant PDF at https://patentimages.storage.googleapis.com/e1/ff/ca/a6ac9cae1943e6/US7502897.pdf

Per the operating rule, I did not fold in near-number hits. The distractors already identified in the litigation section (JP7502897T, FR7502897A, US design application 29/075,028 in Back stretcher – USD398399S, CA7 docket entry [7502897], DOI suffix 10.1109/NOMS.7502897) are different identifiers and are excluded here as well.

2. The complete examiner-cited prior-art set

Building on the bibliographic table already produced, the "Patent Citations," "Non-Patent Citations," and "Citations" fields of the '897 record contain exactly the following two references. There are no other prior-art citations in the USPTO/Google Patents record for this patent. Every citation is analyzed below.

⚠️ Explicit flag — an anomaly in the Google Patents rendering

The Google Patents page for US7502897 also prints a section headed "Family Cites Families (25)" containing 25 entries that are completely unrelated to transactional memory: rubber/polymer preservatives (Very Important Products, 1974), Dow Corning silicone brake fluid, Goodyear tire sidewall coatings, Michelin tyre casings, Ecolab molded detergent compositions, tire-dressing applicators, etc.

These cannot be prior art to the '897. They are a data-association error in Google Patents' automated family-citation rendering (a rubber/tire patent family's cited-art list has been mismatched onto this family). I am reporting this literally rather than silently dropping it, and I do not treat any of those 25 entries as prior art to US 7,502,897. Note also that the same page reports forward-citation counts inconsistently ("Cited By (25)" in one block, "Cited By (58)" in another) — a further sign that those automated fields should not be relied on without checking the face of the patent.

3. Reference 1 — US 6,850,938 B1

3.1 Full citation

Sources: https://patents.google.com/patent/[US6850938B1](/patent/US6850938B1) ; grant PDF https://patentimages.storage.googleapis.com/0c/1d/66/8b46de8372349b/US6850938.pdf ; family member https://www.patents-review.com/a/20050138375-method-apparatus-providing-optimistic-locking-shared.html

3.2 Brief description

The '938 disclosure is in the database concurrency-control field. A lock manager process generates and maintains a lock data structure ("lock") for a particular resource object — explicitly "a database object in a database," and more generally "any item that can be separately accessed by a reference," including "variables, buffers, registers, data structures, methods, and groupings of data and methods." The lock data structure carries: (i) a resource object identification, (ii) a lock type (shared / exclusive / optimistic), and (iii) a version number related to the number of changes to the object since the lock structure was generated. A requesting process requests a lock type; the lock manager grants or denies it based on the requested type vs. the lock type in the structure. At commit, the optimistic lock is converted to an exclusive lock, the version number is checked against the object's current version, and if they differ the transaction is rejected and restarted. The stated advance is that placing the version number in the lock structure (managed by the lock manager) rather than in the database record allows optimistic locking to be introduced into a legacy database without altering the table schema.

Critically for this analysis, the '938 retrieves its lock by object identification / a lock-manager table keyed on resource ID, in a client/server database setting. It does not deal with software transactional memory transactions, memory blocks containing uniformly sized allocated objects, interior pointers, bit-masking a pointer to recover a block header, or computing an object's base address from block/object size and then deriving the lock from that base.

3.3 Anticipation analysis under 35 U.S.C. § 102

Because 11/477,339 was filed 2006‑06‑28 (before the 2013‑03‑16 AIA first-inventor-to-file change), pre‑AIA § 102 governs. '938 is "by another" (Sadjadi/Cisco), and under pre‑AIA § 102(e) its prior-art date is its filing date, 2001‑02‑08 — well before the '897's filing and any invention date of record. It is therefore unquestionably available as prior art. The question is whether it anticipates.

To anticipate, a single reference must disclose every element arranged as claimed. Applying that standard claim-group by claim-group:

Conclusion on Reference 1: US 6,850,938 B1 does not anticipate any claim of US 7,502,897 under § 102. Its relevance is as a § 103 "secondary teaching" reference establishing the general background of object-level optimistic locking and lock-structures-carried-in-a-lock-table (useful against the broadest element of claims 1/10/18, i.e., "finding a lock for an object"), while the novel element of the '897 — computing the object's base from the enclosing memory block and using that base (or its index) to reach the lock — is absent. It also explains why the '897's Background frames the invention against cache-line and hashing schemes: the examiner needed only to show that object-associated locking was known, leaving the address-resolution mechanism as the point of novelty.

4. Reference 2 — Microsoft Computer Dictionary, 5th Edition (p. 465)

4.1 Full citation

Verification of the edition's identity and ISBN: the title/copyright page as filed in a USPTO PTAB exhibit — https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1557577](/patent/1557577)/download-documents?artifactId=8Tu6ldkpU_2ZWNGKdrvlLu67ASdHX7VPxV2i7lOKL5Sq3_b6TeUlEQY (shows "Fifth Edition … Copyright © 2002 by Microsoft Corporation … ISBN 0‑7356‑1495‑4").

4.2 Brief description

The Fifth Edition is a general computing dictionary (approximately 10,000+ entries) defining hardware, software, networking, programming, and standards terminology. The examiner cited a single page (p. 465) — standard USPTO practice when a claim term needs an ordinary-meaning reference.

Disclosure limitation (stated honestly): I could not verify which specific entry appears on page 465 of the print edition from the publicly indexed sources in this session. Search hits reproduce the dictionary's front matter and other pages (e.g., p. 269 entries "indexed address," "indexed search," "Indexed sequential access method" as reproduced in a district-court exhibit at https://storage.courtlistener.com/recap/gov.uscourts.cand.[195854](/patent/195854).84.3.pdf), but not p. 465. I will not guess the headword. Given the '897's terminology, the page most plausibly supplies the ordinary meaning of a term such as "object," "lock," "pointer," "transaction," or "hash," but that is inference, not verified fact.

4.3 Anticipation analysis under 35 U.S.C. § 102

5. References that are not prior art to the '897 (avoiding double-counting)

• US 7,802,059 B2 / US 2009/0077339 A1 (application 12/270,710, filed 2008‑11‑13) — the continuation in the same family (family ID 38972717). It shares the same priority date (2006‑06‑28), published after the '897's filing date, and is not "by another." It is not prior art against the '897; it has the same specification and a parallel claim set.
• The "Cited By" lists (the 25/58 forward citations to the '897, e.g., Intel's US 7,809,903; Microsoft's US 8,226,907; IBM's US 8,096,750) — these are later documents citing the '897. They are not prior art to it.
• The 25 rubber/tire entries under "Family Cites Families" — excluded for the data-error reason given in § 2.

6. Bottom line on anticipation

1. US 6,850,938 B1 — the only patent cited against US 7,502,897 — does not anticipate any of claims 1–20 under § 102. It is database optimistic-locking art (lock-by-resource-ID, version numbers carried in a lock data structure), missing the '897's core limitations: STM transaction context, memory-block header recovery from a pointer, and computing the object's base and obtaining the lock from that base.
2. Microsoft Computer Dictionary, 5th Ed. (2002), p. 465 — qualifies as § 102(b) prior art but is a definitional reference; it anticipates no claim.
3. The examiner's citation set is remarkably thin (one patent, one dictionary page). Consequently the '897's patentability, as reflected by the record, rests on the specificity of the base-address → block header → object base → lock resolution chain and its on-side/inline lock variants (FIGS. 1–3, claims 2–5, 9, 11–16), none of which appear in the cited references.
4. Consistent with the earlier-generated litigation section, no PTAB proceeding was found; if an IPR ever had been filed, US 6,850,938 B1 would be an unlikely lone basis given the gaps in § 3.3.

Confidence and caveats. High confidence on the citation identities, numbers, dates, and the § 102 element-by-element comparison (grounded in the authoritative full text and the '938 grant PDF/Google Patents record). Lower confidence on the content of dictionary page 465, which I could not verify and have flagged rather than guessed. As before, "no other prior art cited" is a statement about the face of the '897 and its Google/USPTO record, not an affirmation that no other art exists.

I'll ground the obviousness analysis in the record before writing. Let me pull the cited prior art and related material.

Strong lead: the inventors' own March 2006 McRT-STM paper appears to disclose object-based conflict detection with size-segregated 16KB allocation blocks. Let me verify that and the other candidate references.

Obviousness Analysis — U.S. Patent No. 7,502,897 B2 under 35 U.S.C. § 103

Patent: US 7,502,897 B2, "Object based conflict detection in a software transactional memory"
Inventors: Hertzberg, Saha, Adl-Tabatabai · Original assignee: Intel Corp. · Filed/priority: 2006‑06‑28 · Granted: 2009‑03‑10
Continuation in family: US 7,802,059 B2 (app. 12/270,710)
Governing law: Pre‑AIA § 103(a) (filed before 2013‑03‑16), applied per Graham v. John Deere and KSR Int'l v. Teleflex.

0. Scope note and a flagged inconsistency

The instant page's "Prior Art" record is thin: the Patent Citations table contains exactly one reference — US 6,850,938 B1 (Sadjadi / Cisco Technology, "Method and apparatus providing optimistic locking of shared computer resources," filed 2001‑02‑08, granted 2005‑02‑01) — and Non‑Patent Citations contain exactly one item: Microsoft Computer Dictionary, 5th ed. (Microsoft Press, 2002), ISBN 0‑7356‑1495‑4, p. 465.

Flag: My strongest § 103 build does not rest on those two items alone. It rests primarily on the McRT‑STM paper (PPoPP '06, published 2006‑03‑29), whose author list includes two of the three named inventors (Saha, Adl‑Tabatabai) and a third (Hertzberg). That reference is not in the "Prior Art" table. I treat it as supplemental art because your instruction was to identify combinations of prior art references, and because omitting it would understate the invalidity risk. I flag the divergence explicitly rather than silently re-labeling it as "cited art."

Second flag: I could not retrieve the content of Microsoft Computer Dictionary p. 465 in this session. I therefore do not assert what term it defines. Dictionary citations of this type are conventionally used to construe a claim term (e.g., "lock," "pointer," "object"), not to supply a missing limitation; a dictionary alone cannot carry a § 103 rejection of claims 1/10/18.

1. Level of ordinary skill (PHOSITA)

A person having ordinary skill at the June 2006 critical date: a B.S. in CS/EE plus ~2–4 years of systems/compiler experience, or an M.S./Ph.D. with research in concurrent runtime systems. Such a person would know: (a) STM design tradeoffs, (b) explicit memory management in C/C++ (malloc/free, slab/size‑segregated pools, power‑of‑two alignment, block headers), (c) cache‑coherent multiprocessor synchronization, and (d) optimistic concurrency control from the database literature.

This matters because claim 1 is extremely broad — three functional steps with no structural detail:

"receiving a block of instructions for execution as an object in a software transactional memory transaction; computing a base of the object; finding a lock for the object using the base of the object."

Nothing in claim 1 requires: a header lookup, bit‑masking, size‑segregated pools, a specific lock representation, an STM library, or even a non‑dictionary allocation scheme. Claim 1 is effectively a functional result ("find the lock from the object's base"). Under KSR, "a patent composed of several elements is not proved obvious merely by demonstrating that each element was independently known," but where the claimed combination is a predictable application of known techniques to a known problem, the claim fails.

2. The problem the patent itself admits (admitted prior art)

The specification's Background is binding on the patentee as an admission:

• "To resolve conflicts in a STM, a cache line‑based conflict detection, or some form of hashing scheme is currently used to detect conflicts between transactions."
• "This creates false conflicts between transactions and is less intuitive for the programmer, since the programmer is programming in terms of objects."

The patent thus concedes the state of the art, the problem (false conflicts; object‑unintuitive granularity), and — critically — that the goal was to move conflict granularity to the object. A specification that states the problem supplies the motivation prong of the § 103 inquiry almost by itself.

3. Ground 1 (primary): McRT‑STM PPoPP '06, alone or in view of US 6,850,938 and McRT‑Malloc

Reference A: Saha, Adl‑Tabatabai, Hudson, C. C. Minh, Hertzberg, "McRT‑STM: A High Performance Software Transactional Memory System for a Multi‑Core Runtime," PPoPP '06 (ACM, publication history 2006‑03‑29), pp. 187–197 — https://dl.acm.org/doi/abs/10.1145/[1122971](/patent/1122971).[1123001](/patent/1123001)
Reference A′ (companion slide deck, same content): http://cobweb.ecn.purdue.edu/~smidkiff/ppopp/presentations/saha_adl-tabatabai.pdf

Disclosures I verified in the retrieved text:

Reference B (secondary, for the literal "lock" vocabulary and per‑object lock structure): US 6,850,938 B1 — https://patents.google.com/patent/[US6850938B1](/patent/US6850938B1)
The Cisco reference teaches "generating a lock data structure for a particular resource object," the lock data structure carrying a "resource object identification, a lock type, and a version number," managed by a lock manager, with the request being "for a requested lock type for access to the particular resource object." Its definition of "object" is deliberately broad: "an object is any item that can be separately accessed by a reference… variables, buffers, registers, data structures, methods, and groupings of data and methods." It also discloses the version‑number/optimistic‑lock mechanism that is the functional analogue of an STM conflict‑detection record.

Analysis. McRT‑STM alone discloses claims 1, 2, 3, 4, 5, 18, 19, 20 nearly element‑for‑element (base derived from a 16K‑aligned block with size in block metadata; TxR per object; on‑line/off‑line TxR placement). That is a § 102 anticipation posture, with § 103 as the fallback. US 6,850,938 supplies the express "lock for an object, keyed by object identity" teaching and the versioning semantics, so that even if McRT‑STM's "TxR" were argued to be something other than a "lock," the combination meets the claim.

Motivation to combine (KSR rationales 1, 3, 4, 6).

1. Same field, same problem, same actors. McRT‑STM and US 6,850,938 both address concurrent access to shared objects; STM is expressly described as replacing lock‑based synchronization.
2. Design incentive stated in the references. McRT‑STM explicitly frames the design space as "cache line based versus object based conflict detection" and quantifies the tradeoff — i.e., it teaches the skilled artisan that object granularity is a selectable, beneficial design point. The patent's own Background concedes the same tradeoff.
3. Predictable result. Substituting object granularity for cache‑line/hash granularity is a change in granularity of a known mechanism, producing the predictable elimination of aliasing/false conflicts (the very benefit the patent asserts).
4. Known technique. Deriving an object's base from a pointer via a power‑of‑two‑aligned block header is elementary allocator practice (see Ground 3).

Antedating caveat (important, and adverse to the challenger). PPoPP '06 published 2006‑03‑29, which is less than one year before the 2006‑06‑28 filing. It is therefore § 102(a) art, not § 102(b) statutory bar art, and because it is the inventors' own prior publication, the applicants could in principle swear behind it under 37 CFR 1.131 (or argue the object‑based detection was added to the paper after the invention date). Practically, however, (i) the paper was submitted/accepted well before March 2006, and (ii) a Rule 131 declaration requires corroborated facts, not attorney argument. This is the single most consequential factual battleground for this patent.

4. Ground 2: McRT‑Malloc ISMM '06 in view of McRT‑STM / US 6,850,938

Reference C: Hudson, Saha, Adl‑Tabatabai, Hertzberg, "McRT‑Malloc: A Scalable Transaction Aware Memory Allocator," ISMM 2006 — listed as ref. [16] in the Intel Technology Journal survey of McRT, Intel Technology Journal, vol. 11, no. 3 (2007), p. 211 ff. (http://download.intel.com/technology/itj/2007/v11i3/4-environment/vol11-i3-art04.pdf).

Flag: I verified the existence, title, venue, authors, and the McRT‑Malloc ↔ object‑based‑TxR linkage from the Intel TJ reference list and the PPoPP slide deck, but I did not independently confirm the exact ISMM 2006 publication date in this session. If the paper appeared at ISMM 2006 (early June 2006), it predates the June 28, 2006 filing and is § 102(a)/(b)‑eligible art; if it appeared later, it is not. Treat the date as an open verification item.

Combination mapping (chiefly aimed at claims 10, 12, 13, 18):

Motivation. The references themselves state the linkage: the slide deck literally says object‑based TxR for C/C++ "leverages McRT's memory allocator," where "allocation blocks [are] aligned on 16K boundaries" and "block metadata includes size." That is a teaching of the exact pointer → block → size → base → TxR/lock chain recited in claim 10. Where a reference expressly directs the artisan to leverage allocator metadata to locate per‑object transactional metadata, the motivation inquiry is satisfied. Claim 16's fallback to hashing is separately motivated by the patent's own admission that hashing was the existing scheme — retaining a known scheme for the residual case (non‑allocator objects, stack/globals) is the epitome of an obvious design choice / obvious‑to‑try limitation, and the reference calls out the "both object‑based and cache‑line based" coexistence.

Claim 8's interior_pointer − reserved_base_address < reserved_area_size unsigned comparison is a routine range check; the claim recites no algorithm and no unexpected result.

5. Ground 3: Ananian & Rinard (SCOOL '05) + US 6,850,938 + allocator art

Reference D: C. S. Ananian and M. Rinard, "Efficient Object‑Based Software Transactions," SCOOL '05 (OOPSLA Workshop), San Diego, 2005‑10‑16, pp. 65–74 — https://flex.cscott.net/Publications/ and http://cscott.net/Publications/SCOOL05/SCOOL05.pdf

This reference is independently titled and directed to the same subject matter as claim 1's preamble: object‑based software transactions, with "an efficient object‑based implementation of non‑blocking software transactions" that "allows compiler optimizations to provide better performance." It is more than one year before filing → § 102(b) art, and not the inventors' own work, so it is not susceptible to a Rule 131 antedating problem. Its own slide deck describes an "object representation" containing a pointer to object contents and per‑object state (prior state / result of operation) manipulated via compare‑and‑swap — i.e., per‑object transactional metadata located via the object's base.

Combination: D (object‑based software transactions, per‑object metadata, object representation) + B (a lock data structure per resource object, keyed by object identification) + C / ordinary allocator knowledge (base computation from an aligned block header). Motivation: D pursues the identical efficiency goal for object‑based transactions; B supplies the lock object and its identification key; C supplies the trivial address arithmetic.

Why this ground is strategically important: it is not the inventors' own publication, so it removes the Rule 131 escape hatch that threatens Ground 1. Its weakness is that the retrieved content is a workshop presentation emphasizing functional arrays and the "large object problem," and I have not verified that it discloses the specific base‑computation‑from‑pointer/header step. Ground 3 therefore depends materially on Ground 2 (or ordinary skill) to supply claims 10/12/13.

6. Ground 4: Admitted prior art + Harris/Fraser + Herlihy/Moss + US 6,850,938

Reference E: T. Harris and K. Fraser, "Language support for lightweight transactions," OOPSLA 2003, pp. 388–402 — word‑based STM with per‑word versioned ownership records (the "word‑based conflict detection" the patent's Background disparages as "too much overhead," and which the McRT slide deck notes "Other STMs (Harris et al.) use the same algorithm").
Reference F: M. Herlihy and J. E. B. Moss, "Transactional memory: architectural support for lock‑free data structures," ISCA '93, pp. 289–300 — the foundational per‑data‑item ownership/version conflict detection.

The argument: the only thing separating the claims from E/F is granularity. E/F locate conflict metadata per word/cache line; the claims locate it per object, keyed by the object's base address. The patent's Background concedes both the cache‑line/hash approach and the word‑based approach were known, and frames the invention as a middle ground ("Object‑level conflict detection represents a balance between cache line‑based detection and word‑based detection"). Under KSR, a "structure [that] is a combination of familiar elements according to known methods" yielding "predictable results" is obvious; and where the prior art identifies the very problem to be solved (false conflicts from coarse granularity; overhead from fine granularity), the motivation is supplied. US 6,850,938 then supplies the per‑object lock data structure that bridges word granularity and object granularity.

7. Claim‑by‑claim vulnerability ranking

The weakest link for the patentee is claim 1; the strongest defense for the patentee is claim 9 (memory‑manager‑written lock), which depends on the McRT‑Malloc reference's date and content.

8. Anticipated patentee rebuttals, and how they fare

1. "Different field — US 6,850,938 is a database patent." Weak. The reference's own definition of "object" ("any item that can be separately accessed by a reference… data structures") and its optimistic/versioned locking are reasonably pertinent to STM conflict detection. KSR disfavors rigid field‑of‑invention limits where the references address the same problem.
2. "Rule 131 antedating of McRT‑STM / PLDI '06." The patentee's best argument. It neutralizes Ground 1 and the PLDI '06 reference (Adl‑Tabatabai, Lewis, Menon, Murphy, Saha, Shpeisman, "Compiler and runtime support for efficient software transactional memory," PLDI '06) but not Ground 3 (Ananian/Rinard) or Ground 4.
3. "No motivation to combine, because a database lock manager is architecturally remote from an STM." Undermined by the McRT references, which themselves state the object‑granularity objective and the allocator linkage.
4. "Unexpected results / commercial success (secondary considerations)." No evidence of nexus is present in the record; the spec asserts only expected benefits (fewer false conflicts, compiler CSE enabled). Also, the patent's own Background concedes the benefit was foreseeable, which undercuts nexus.

9. Related non‑§ 103 exposure (flagged, not analyzed here)

• Obviousness‑type double patenting against US 7,802,059 B2 (same family, same title, same inventors, continuation filed 2008‑11‑13). The two specifications are substantially identical; only a terminal disclaimer likely separates them.
• § 112(b) exposure on claim 1: "computing a base of the object" and "finding a lock… using the base" are result‑oriented; the specification's only enabling disclosure of how is the mask/index arithmetic in the "Determining Object Metadata Locations from an Interior Pointer" section. This is a validity vulnerability independent of § 103 and worth noting because claim 1 does not recite that arithmetic.

10. Uncertainty statement

• I have not confirmed the exact publication date or page content of ISMM 2006 McRT‑Malloc in this session; I verified its existence and subject matter only via the Intel Technology Journal reference list and the PPoPP slide deck. Do not treat Ground 2's date predicate as established.
• I have not verified what term Microsoft Computer Dictionary, 5th ed., p. 465 defines. It cannot, standing alone, supply the missing limitations of claims 1/10/18.
• I have not reviewed the file history, any Rule 131 declaration, or any terminal disclaimer for the '897/'059 family. A Rule 131 declaration, if present and effective, materially weakens Ground 1.
• Consistent with the prior sections of this analysis, I found no litigation, IPR, or Federal Circuit proceeding involving US 7,502,897; the obviousness conclusions above are analytical and are not an assertion that any tribunal has so held. The patent is expired (maintenance‑fee lapse, effective 2021‑03‑10), so any invalidity challenge today would arise only defensively or as to past damages — the practical exposure is limited, which is itself consistent with the absence of litigation.
• I have not auto‑corrected any identifier. Where the record's "Prior Art" table and the broader literature diverge (one patent + one dictionary citation vs. the McRT/Ananian/Harris body of art), I have preserved both and labeled which is which.