US 7743111

I'll search for authoritative information on US 7,743,111, including any 2026 CAFC docket activity.

US Patent 7,743,111 — Analyst Summary

Sourcing note: The authoritative text I was given is the Google Patents record at https://patents.google.com/patent/US7743111/en (fetched 2026-09-21). I also ran web searches against Google Patents, FreePatentsOnline, Justia Patents, and general docket/news queries. Where the search record and the supplied text agree, I treat them as confirmed; where a claim was truncated in the supplied text, I flag it explicitly.

1. Bibliographic data

Family note: The specification states this is a continuation of 09/045,340 (now US 6,697,846). The Google Patents "priority to" event also shows a later continuation, US 12/779,075, which issued as US 8,533,295. Related Soltis/DataPlow patents surfaced in the citations include US 7,165,096 and US 7,552,197 ("Storage Area Network File System").

2. Abstract (as issued)

"A shared storage distributed file system is presented that provides users and applications with transparent access to shared data stored on network attached storage devices by utilizing layering techniques to inherit file management functionality from existing file systems. The present invention stores meta-data for the shared data as real-data in a standard, non-modified, client-server distributed file system, such as NFS. In effect, the standard client-server file system acts as a meta-data server. The name space consisting of inode files stored as real-data on the meta-data server acts as the name space for the shared data. Similarly, file attributes of the inode files are utilized as the file attributes of the shared data… A method for communicating with network attached storage devices over layered file systems is also presented."

3. Plain-language overview

The patent calls its invention the Shared File System (SFS). The central trick: rather than build a new distributed file system from scratch, you layer it on top of an off-the-shelf, unmodified network file system such as NFS (or SMB/DFS), which the patent calls the Meta-data File System (MFS).

• Real-data (the user's actual bytes) lives on network attached storage (NAS) devices on a storage area network (SAN) — Fibre Channel, HiPPI, IPI-2, SCSI-2, etc. Clients read/write that data directly, bypassing the server for the bulk data path.
• Meta-data (inodes/extent lists, free-block bitmaps, superfile, segment files) is stored as ordinary regular files inside the NFS server's own file tree. The NFS server therefore becomes the SFS "meta-data server" without any modification.
• The NFS directory tree doubles as the SFS namespace, and NFS's per-file attributes (owner, permissions, times, size) double as the SFS file attributes. NFS's built-in read-locks/write-locks provide meta-data consistency; NFS's caching and recovery are inherited for free.
• Because meta-data is just another file, clients retrieve, analyze, and modify it themselves directly (not the server), and they sequence updates so a crash can only produce repairable inconsistencies (e.g., segment allocation tables updated before inodes on allocation; inodes updated before segment files on de-allocation, with an on-line repair utility that reconstructs segment files by scanning all inode files).

4. Independent claims — plain-language overview

Claim 1 — Distributed file system (apparatus). A file system spread across multiple computers, with a namespace defining a directory structure of files plus metadata containing pointers to real-data. It requires:

• (a) at least one server computer running server software that manages the namespace;
• (b) a network;
• (c) at least one client computer separate from the server, communicating over the network, whose client software (i) sends the server namespace requests over the network — each request being a filename plus an operation encoded in a protocol the server understands, and limited to the group of add a filename, remove a filename, and search the namespace for a filename — and (ii) directly retrieves, analyzes, and alters the metadata itself.

The inventive core is the split: the server handles only namespace operations, while the client owns metadata manipulation.

Claim 10 — Network of computing devices (shared-storage distributed file system). A network comprising:

• (a) a network storage device on the network;
• (b) a server computer that manages the namespace by retrieving and modifying directory files in response to namespace requests, including adding and removing filenames;
• (c) a client computer in network communication with both, which (i) issues namespace requests to the server, (ii) reads and writes real-data directly from the network storage device, and (iii) creates, retrieves, and modifies the metadata.

This is the "SAN data path vs. LAN control path" claim. Its dependents add detail: LAN for server traffic / SAN for real-data (claims 11–13), attribute requests forwarded to the server (14–15), acquiring a lock before modifying metadata (16), namespace searches with server-enforced permissions (17–18), and metadata stored by the server in a real-data file, including on a locally attached server storage device distinct from the network storage device (19–23).

Claim 24 — "An improved file system operating as part of a client computer comprising: a) a digital communication path to a storage device; b) …" — ⚠️ Uncertainty flag. The authoritative text I was supplied breaks off in the middle of element (b). I can confirm literally only the preamble and element (a). I cannot authoritatively state the full scope of claim 24, nor rule out that other independent claims exist among the un-supplied claims 25–52.

Claim 53 — Method for handling file requests by a file system. The steps, as visible in the record: b) requesting at the client computer namespace data relating to the file request from a server computer that manages the namespace and is located separately from the client; c) analyzing and altering metadata at the client computer, the metadata relating to allocation information of storage on a storage device; and d) saving on the storage device the allocation information metadata altered by the client computer. Dependent claim 54 specifies the allocation information consists of bitmap tables; claim 55 requires a lock acquired before and released after the analyze/alter-and-save sequence. ⚠️ Step (a) (which precedes the visible text) is not reproduced in my authoritative excerpt; based on the parallel claim 56 it most likely recites receiving the file request at a client computer, but I cannot confirm the literal wording.

Claim 56 — Computer product. A non-transitory computer readable medium carrying program code to implement a file-request method: a) receiving the file request at a client computer; b) requesting at the client computer that a server computer which manages a namespace perform a namespace search for the requested file, the server being located separately from the client; c) analyzing and altering metadata relating to the location of real-data of the file request at the client computer; and d) saving the metadata altered by the client computer.

Practical reading: Claims 1, 10, 24, 53, and 56 (the five independent claims I can identify) all cover the same architectural idea from different statutory angles — apparatus/network/method/computer-product — with the recurring limitations being (i) a separate server that manages only the namespace, and (ii) the client directly reading/writing and modifying the metadata (including real-data allocation metadata).

5. Litigation / CAFC 2026 docket search — result: no relevant activity found

I searched for US 7,743,111 in connection with Federal Circuit / 2026 docket activity, including queries pairing "7743111" with "CAFC 2026," "appeal," "docket," and the assignee/inventor names.

• I found no evidence of any 2026 CAFC docket, appeal, IPR, or district-court matter involving US 7,743,111. I state this as a negative finding from my searches, not as a certified clearance search.
• Consistent with that, the patent is recorded as Expired – Lifetime with an adjusted expiration of 2022-04-27, which makes current enforcement activity unlikely.
• Caution on identifier collisions: a bare search for "7743111" (without the "US patent" qualifier) returns a Czech public-contracts registry entry (ID smlouvy 7743111, a 2019 real-estate purchase agreement) that has nothing to do with this patent. Likewise, a snippet about a patent lapsing "for failure to pay maintenance fees, effective 2014-11-30" appears on a Google Patents page for US 7,844,596 (an IBM patent) that merely cites US 7,743,111 — that maintenance-fee lapse does not refer to US 7,743,111. I flag this because it is an easy mis-attribution.
• I do not have high-confidence information about any historical District Court litigation asserting US 7,743,111 (as distinct from the related DataPlow patents), so I make no claim about one.

6. Confidence and caveats

• High confidence: title, inventor, assignee, application number, filing date, issue date, priority date, family/continuation relationship, abstract, and the full text of claims 1–23 plus claims 54–56.
• Moderate confidence: the identity of claim 24 as an independent client-side file-system claim (preamble confirmed; body not fully supplied).
• Low confidence / unverified: the full text of claims 24–52, the literal step (a) of claims 53 and 56, and the exact count/identity of independent claims. I have not assumed that claims 1, 10, 24, 53, and 56 are the only independent claims.
• Negative finding, not certification: no CAFC 2026 (or other) docket activity for US 7,743,111 was located. If you need a definitive litigation history, a PACER/Docket Navigator and USPTO PatentCenter assignment-history pull on application 10/738,371 would be required.

I'll search for litigation involving US patent 7743111 across patent litigation resources.

Let me search more specifically on litigation databases and for the patent owner (DataPlow).

Let me run more targeted searches on litigation databases and the patent owner's assertion history.

Litigation Search Results — U.S. Patent No. 7,743,111

Bottom line: I was unable to identify any litigation involving U.S. Patent No. 7,743,111 in the searches I was able to run. I cannot report cases I did not find, and I will not fabricate plaintiff/defendant pairings, case numbers, or outcomes. Below is a transparent account of what I did and did not find, plus the patent-identification facts needed for a proper docket search.

What I searched

• General web searches for "7743111" combined with litigation terms, and for the patent owner ("DataPlow") combined with infringement/lawsuit terms.
• Attempts to reach Unified Patents' litigation portal and search-engine results referencing CAFC/PACER materials.

The returned results were the patent document itself (Google Patents, FreePatentsOnline, Justia) and unrelated matters (e.g., a PTAB IPR about a different patent, U.S. Patent No. 10,334,311 — not the '111 patent at issue here; a Czech government contract also bearing numeric ID 7743111). None of these involved U.S. Patent No. 7,743,111.

Literal patent identification (for docket verification)

Per the authoritative patent text provided:

Note: The '111 patent expired in 2022, so any enforcement activity necessarily predates that date. Its parent, U.S. 6,697,846, shares the same specification and owner and would be the more likely vehicle for any enforcement campaign — but I found no confirmed case names or numbers for either patent in these searches.

Important caveats

1. My search tool did not return records from PACER, Docket Navigator, Unified Patents' case list, or CourtListener directly. Those are precisely the sources that would confirm or refute enforcement activity. I could not open the Unified Patents litigation caselist or any PACER docket within the constraints of this session.
2. Absence of evidence is not evidence of absence. DataPlow, Inc. is a small assignee, and any suits it filed may be indexed only in paywalled docket databases or in historical court records not surfaced by these general searches.
3. I do not have high-confidence knowledge of any specific case involving the '111 patent, and I am expressly declining to guess at party names, jurisdictions, case numbers, filing dates, or outcomes.

Recommended verification steps (where a definitive answer would come from)

• PACER / CourtListener (RECAP): search "DataPlow" as party and "7,743,111" as patent number across all district courts.
• Unified Patents Litigation Portal (portal.unifiedpatents.com/litigation) and Docket Navigator / Lex Machina: query by patent number 7743111 and by assignee "Data Plow, Inc."
• USPTO Patent Trial and Appeal Board (PTAB): search for IPR/PGR/CBM challenges naming the '111 patent (no such proceeding appeared in my searches, but PTAB is the authoritative check).
• CAFC: search by the same patent number and by "DataPlow" for any appeals.

If you can supply access to a docket database or confirm a specific case caption, I can analyze the complaint, asserted claims, and outcome in detail. As of this search, the accurate answer is: no litigation involving U.S. 7,743,111 was identified.

I'll start by verifying the structured data against public sources.

The first searches surfaced a different patent (10,334,311). Let me search specifically for this patent's owner and litigation/PTAB history.

No PTAB hits yet for this patent. Let me check litigation history and whether any reexamination exists.

Proceedings overview

There are zero AIA trial proceedings on file for US 7,743,111. The structured USPTO Open Data Portal block supplied with this task states: "The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest," and my independent web searches for PTAB activity naming this patent (and its owner, DataPlow, Inc. / inventor Steven Soltis) surfaced no IPR, PGR, or CBM petition, institution decision, Final Written Decision, or appeal. Breakdown by status is therefore 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denied — I have no proceeding numbers to report, and I will not manufacture any.

Bottom line for a defendant: this is not a "hardened patent" story and not a "claims canceled" story — it is an untested-at-the-PTAB, already-expired patent. There is no FWD to lean on, but there is also no live patent right to infringe going forward. Any demand letter asserting US 7,743,111 today is asserting a patent whose Google Patents legal-status entry reads "Expired - Lifetime, expires 2022-04-27" (a status the same page expressly labels an assumption, not a legal conclusion — verify against USPTO Patent Center before relying on it). If that expiration date holds, the only exposure is a past-damages theory capped by the six-year limitation of 35 U.S.C. § 286, i.e., conduct on or after roughly 2020-09-21 — and none of that has ever been tested at the Board.

⚠️ False-positive alert. Searching for this patent repeatedly returns U.S. Patent No. 10,334,311 ("the '311 Patent") from IPR2023-00238 — a completely different patent (display-device/input-icon art, different owner, different petition). Do not let a case-management or docketing system conflate "7743111" with "10,334,311." No petition I found challenges US 7,743,111.

Proceeding-by-proceeding detail

None to report. Because the required output format is proceeding-driven, I'm giving the format-relevant facts that would attach, rather than inventing an entry:

Methodological caveat (stated plainly rather than papered over): I confirmed the absence via the ODP block and targeted web searches (PTAB petition documents, DataPlow/Soltis IPR queries, CBM-eligibility queries). I did not exhaustively docket-search district court litigation or run a full Patent Center transaction-history pull, so I cannot affirmatively represent that this patent has never been litigated or never been the subject of a reissue or ex parte reexamination (which are not AIA trials and would not appear in the ODP AIA-trial list). Treat "no PTAB activity" as high-confidence; treat "no other post-grant activity whatsoever" as unverified.

Strategic summary

Claim-by-claim posture. No claim of US 7,743,111 is CANCELED and no claim is SUSTAINED — the correct label for every one of the 56 claims is UNTESTED. There is no narrowing to exploit and no surviving-claim list to recite, because the patent has never been through an IPR. The claims break into at least these families as printed: independent system/distributed-file-system claims (e.g., claim 1, with dependent claims 2–9), a network-of-computing-devices claim family starting at claim 10 (dependents 11–23), and an improved-file-system claim family beginning at claim 24. (The full text supplied to me truncates mid-claim 24; I have not verified the claim set beyond the printed count of 56.) The real narrowing story for this family, if there is one, lives in the sibling patents, not here — the '111 patent is a continuation of US 6,697,846, and DataPlow's related assets in the same lineage include US 7,552,197 (storage area network file system) and US 8,533,295 (which the Google Patents page lists as taking priority from US 12/779,075), plus published applications such as US 2011/0125835 and US 2012/0278450. Family members, not the '111 patent, are where a live right might sit.

Estoppel landscape. Because no IPR reached a § 318(a) Final Written Decision, § 315(e)(2) estoppel does not exist against anyone — no petitioner, real party in interest, or privy is barred from raising any prior-art ground in district court or the ITC. That cuts both ways for you: you inherit no one else's foreclosed art (you can run any § 102/§ 103 ground you can find), but you also get no benefit from a prior petitioner's work product. Conversely, there is no § 315(a)(1) bar against you for filing an IPR unless you first filed a civil action challenging validity, and the § 315(b) one-year clock has not started against you unless you were served with a complaint alleging infringement of this patent — check your service date, because that clock is the single most important date on your calendar if you intend to petition. Practically, though, on an expired patent an IPR is usually a poor investment: there is no prospective infringement to enjoin, the Board has no claims to amend around, and appellate standing to defend a favorable FWD on an expired patent is a real (and litigated) risk.

Pattern signals. No petitioner has filed on this patent — not once, not twice — so there is no serial-petitioner pattern, no joinder, and no defensive-aggregator trail. I found no evidence of Unified Patents or any other defensive aggregator in the chain for US 7,743,111; the name appears in results only via Unified's public patent-data portal, which indexes patents generally and is not evidence of a challenge. There is likewise no evidence the patent owner has pursued PTAB appeals, for the simple reason that it has never had an FWD to appeal. Note the tension worth flagging to a client: the absence of IPR activity is often read as "not worth asserting," but here it correlates with the patent's expiry, which would also explain why nobody bothered.

Recommended next steps

1. Verify the expiration date first — everything else follows from it. The Google Patents status ("Expired - Lifetime, expires 2022-04-27") is expressly an assumption. Pull the USPTO Patent Center record and the ODP grant/PTA data for US 10/738,371 and confirm the terminal date (20 years from 1998-03-20 + any patent term adjustment). If the patent is expired, the practical demand-letter response is that post-expiration conduct is non-infringing and damages are limited by 35 U.S.C. § 286 to six years before filing — i.e., no earlier than approximately 2020-09-21.

2. Pull the full transaction history and confirm there is no sibling activity. If you are being asserted against this patent, run the family (US 6,697,846, US 7,552,197, US 8,533,295, and any live continuations) through USPTO Patent Center and the PTAB's own docket (https://ptab.uspto.gov/; AIA-trial documents at https://ptacts.uspto.gov/ptabweb). A demand letter may be asserting the '111 patent while a live family member is the actual leverage point; you want to know which one is enforceable before you negotiate.

3. If you were recently served and the patent is not expired, calendar the § 315(b) one-year bar immediately and treat it as the governing deadline. Institution decisions issue within three months of the preliminary response or its due date (§ 314(b)), and the Board must reach an FWD within one year of institution, extendable up to six months for good cause (§ 316(a)(11)). Given the pre-AIA status, scope your petition to § 102/§ 103 patents and printed publications only — no § 112 ground will be heard in an IPR.

4. If the patent is expired, the fight is about past damages and validity-in-the-alternative, not about an IPR. In a DJ or defense posture, the untested 1998-era file-system claims are fair game for § 101 (abstract idea / generic-computer implementation), § 112 (enablement/written description of the extent-and-hole inode schemes), and § 102/§ 103 art from the NFS/AFS/xFS/Global File System/spin literature that the specification itself cites (e.g., Sandberg et al., "Design and Implementation of the Sun Network File System"; Anderson et al., "Serverless Network File System"; Soltis's own 1997 Minnesota thesis). None of that art has ever been tested by the Board, which means it is fully available to you.

5. Because there is no PTAB activity, say so plainly and in writing to the client. There is no FWD to quote and no disposition to link — the per-proceeding template above is empty by design, not by omission. The signal to convey is: the patent is expired and has never been PTAB-tested; the demand letter's leverage depends entirely on the expiration verification in step 1 and on any live family member.

Sources consulted: US 7,743,111 full text and legal status, https://patents.google.com/patent/US7743111/en · USPTO PTAB docket entry point, https://ptab.uspto.gov/ · USPTO PTAB decisions, https://www.uspto.gov/patents/patent-trial-and-appeal-board/ptab-decisions · CAFC opinions via CourtListener, https://www.courtlistener.com/ (no 7,743,111 appeal found) · the IPR2023-00238 petition papers located in search, which concern U.S. Patent No. 10,334,311 and are not relevant to this patent.

Confidence: high that no AIA trial proceeding exists on US 7,743,111; unverified as to district court litigation history and non-AIA post-grant activity (reissue, ex parte reexamination).

I'll search for the assignment record for US 7,743,111 and the DataPlow ownership chain.

Let me search more specifically for DataPlow's corporate history and any assignment/legal events data.

Let me try to locate the specific assignment reel/frame and any DataPlow corporate/enforcement history.

Assignment & Ownership Analysis — US 7,743,111 ("Shared file system")

Data-access caveat up front: I was unable to open the USPTO Assignment Center (assignmentcenter.uspto.gov / assignment.uspto.gov) directly in this session — the search tool returned no records from that system. What follows is reconstructed from (a) the authoritative patent text and Google Patents legal-events tab you supplied, which mirror the underlying USPTO assignment/reassignment data; and (b) corroborating corporate records. I could not verify reel/frame numbers or the correspondent-of-record, and I will not invent them. Where a field is blank, treat it as not retrieved, not as not existing.

Inventors

Unusual-pattern check: None detected. There is a single inventor, so the "all inventors depart the original assignee" fire-sale precursor cannot apply. Note a related, separate patent — U.S. 6,493,804, "Global file system and data storage device locks" — lists Soltis among a team of Minnesota inventors and is assigned to the Regents of the University of Minnesota, indicating Soltis moved between University of Minnesota research and his company around this period. That is a lineage observation, not an ownership transfer of the '111 patent.

Original assignee

Data Plow, Inc. / Dataplow, Inc., Rochester, Minnesota (privately held; founded 1997; ~11–50 employees; est. revenue low-seven figures per third-party business directories).

• Line of business: Operating software vendor — develops and distributes SAN/cluster file-system software (marketed as DataFlow SFS; copyright notices "© 1997–2006 DataFlow, Inc." appear in the product documentation). Marketing claims 300,000+ licenses sold.
• Did it ship a product embodying the claims? Yes — DataFlow SFS is the commercial embodiment of the layered shared-file-system architecture described in the specification. This is an operating-company assignee, not a licensing shell.
• Current status: No evidence of dissolution, acquisition, or bankruptcy found. It appears to remain a small, privately held Minnesota company. I could not confirm current operating status with high confidence.

Assignment timeline

I retrieved one recorded assignment link from the patent's legal-events/reassignment data. Reel/frame and correspondent were not retrievable in this session.

• 2003-12-16 (executed) / recorded 2003-12-16 — Reel [not retrieved — verify at Assignment Center]
  • Conveyance: Assignment of Assignors' Interest ("ASSIGNMENT OF ASSIGNORS' INTEREST — SEE DOCUMENT FOR DETAILS")
  • Assignor: Steven R. Soltis
  • Assignee: DATAPLOW, INC. (also rendered "Data Plow, Inc."), Rochester, MN
  • Correspondent: Not retrieved. (The prior section notes Beck & Tysver, P.L.L.C., Minneapolis as prosecuting counsel; that is a prosecution fact, not a confirmed assignment correspondent — do not conflate the two.)
  • Context: Internal/inventor-to-employer assignment accompanying the filing of continuation application 10/738,371 (filed the same day); routine housekeeping, not an acquisition or fire-sale.

Additional/unconfirmed entry — flag for verification: Google Patents lists the current assignee under two name variants: "Data Plow Inc" and "Dataplow Inc." This is consistent with either (i) a simple change-of-name record ("Data Plow, Inc." → "Dataplow, Inc.") or (ii) nothing more than inconsistent data entry. I could not confirm a recorded Change of Name conveyance, so I am not asserting one. Verify at the Assignment Center.

No post-issuance third-party assignments were found. There is no recorded transfer to any licensing entity, holding company, or aggregator. The chain appears to terminate at the original operating assignee.

Timeline diagram

timeline
    title Ownership of US 7743111
    1997 : DataPlow founded in Rochester MN
    1998 : Parent app 09/045340 filed
    2003 : Continuation 10/738371 filed
         : Soltis assigns interest to DataPlow
    2004 : Parent US 6697846 issues
    2010 : US 7743111 issues
    2022 : Patent expires

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. The only recorded conveyance is inventor-to-original-assignee (2003-12-16). No transfer to any "IP / Holdings / Licensing / Ventures" entity, no registered-agent-service address, no single-member LLC. Current assignee is the operating vendor.

2. Known asserter in the chain — Not present. DataPlow / Data Plow, Inc. matches none of the listed NPEs (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Round Rock, etc.). DataPlow is a product company selling DataFlow SFS.

3. Repeat correspondent across the chain — Unclear / not assessable. No correspondent data retrieved. With only one link in the chain, the "recurrence" test cannot be run. Do not treat a single appearance by Beck & Tysver as a finding — it is prosecution counsel, and the rule-of-thumb in the brief is that recurrence, not a single appearance, is the signal.

4. Cascading transfers — Not present. No chained LLC assignments; only one recorded link.

5. Pre-litigation transfer — Not present / not applicable. No transfer within 6 months of any suit; the prior litigation section identified no suit at all.

6. Bankruptcy fire-sale — Not present. No Chapter 7/11 activity by DataPlow found.

7. Privateering — Not present. No operating-company-to-NPE transfer; the operating company retained the patent.

8. Defensive aggregator — Not present. Chain does not end at RPX, AST, LOT, Unified Patents, or OIN.

Verdict

Insufficient data (only the original assignment).

Justification: The record contains a single conveyance — Soltis → DATAPLOW, INC., executed/recorded 2003-12-16 — which is an ordinary inventor-to-original-assignee assignment, not a transfer to any third party. The assignee is a small but genuine operating company that shipped a product (DataFlow SFS) embodying the claims, and no downstream shell, known asserter, cascading transfers, or bankruptcy sale appears in the chain. Because the chain terminates at the original operating assignee and I could retrieve no reel/frame or correspondent data, the honest classification is insufficient data for an NPE finding — and the evidence that is present points toward an operating-company owner, not a troll structure.

Verification links:

• USPTO Assignment Center (search "7,743,111" / "DataPlow"): https://assignmentcenter.uspto.gov/
• Google Patents legal events (source of the 2003-12-16 reassignment entry): https://patents.google.com/patent/US7743111/en
• PatentsView / USPTO Patent Public Search (assignee history): https://ppubs.uspto.gov/

Open items to close this out: (1) pull the actual reel/frame for the 2003-12-16 assignment and capture the correspondent of record; (2) confirm whether the "Data Plow Inc" → "Dataplow Inc" variant reflects a recorded Change of Name; (3) run Reel/Frame + assignee "Dataplow" across sibling patents (US 6,697,846, US 7,165,096, US 7,552,197, US 8,533,295) to see whether any bulk transfer family exists.

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

Let me get the complete "References Cited" list for this patent from multiple sources.

I have the cited-references list. Now let me verify the titles and dates of each cited U.S. patent reference.

Note on tool availability: I hit the session's step limit mid-verification. I'm reporting what I actually retrieved and clearly flagging what I could not confirm. I did not fabricate any title, date, or claim mapping.

Prior-Art Analysis — US 7,743,111 B2 ("Shared file system," Soltis / Data Plow, Inc.)

A. Sourcing and scope caveats (read first)

1. Source. My searches returned the patent record via Google Patents, Justia Patents, FreePatentsOnline, and SumoBrain rather than a direct USPTO PatentCenter/PAIR page-hits view. The "References Cited" data below is the front-page citation list as reproduced on those mirrors. I could not independently pull the original USPTO file wrapper (Office actions listing the examiner's actual § 102 rejections), so what follows is my candidate prior-art analysis, not the examiner's reasons for allowance or rejection.
2. Literal-identifier caution. A bare search on 7743111 again returned an unrelated Czech public-contracts entry (ID smlouvy 7743111, a 2019 real-estate purchase agreement at smlouvy.gov.cz). It has nothing to do with this patent. Likewise, do not confuse the '111 patent with US 10,334,311, a PTAB matter that surfaced in searches.
3. Since the task says "do not auto-correct IDs": every number below is reproduced exactly as it appears in the citation list.
4. Which § 102 applies. Application 10/738,371 was filed 2003-12-16 but is a continuation claiming priority to 1998-03-20. Pre-AIA 35 U.S.C. § 102 therefore governs. This matters a great deal: references published after 1998-03-20 cannot be § 102(a)/(b) art unless their own filing date precedes the priority date (§ 102(e)). Several cited references (Hitz 2001, Pothapragada 2002, Philbrick 2001, Kazar 2002) are in that category and are, on their face, weak anticipatory art.
5. Anticipation vs. obviousness. The task asks about anticipation (§ 102), which requires a single reference disclosing every element of a claim as arranged. Almost none of the cited references alone does that for the independent claims — the citations are more plausibly § 103 combinations. I flag where a reference maps to only a portion of a claim.

B. Cited U.S. patent documents (front-page "References Cited")

The retrieved list contains 20 U.S. patent documents. Dates are the issue/publication dates as listed.

Foreign patent documents: none appeared in the retrieved excerpt of the "References Cited" list. I cannot confirm that none exist in the original front page.

C. Cited non-patent literature ("Other References")

This list is arguably the most dangerous prior art for this patent, because it includes the inventor's own dissertation and the CMU network-attached-secure-disks work:

D. My § 102 mapping — where anticipation is actually plausible

Applying the "single reference must disclose every element" rule to the independent claims I can read (1, 10, 24, 53, 56):

E. Explicit non-findings and limits on this answer

• I could not verify the titles of items 1, 3–16, 18, 19 (marked ?/~). I deliberately did not guess at titles for them; only Henson US 5,202,971, Kazar US 2002/0112022, and the NPL entries were independently confirmed in this session.
• I could not confirm whether the retrieved "References Cited" list is the complete front-page list (e.g., whether foreign patent documents or additional NPL were omitted by the mirror), nor whether the file wrapper contains examiner-attached art not appearing on the front page.
• I could not retrieve the examiner's actual rejections, so I cannot tell you which of these references the examiner actually applied under § 102 versus merely cited as background.
• Items published 2001–2002 (Hitz, Pothapragada, Philbrick, Kazar) are, given the 1998-03-20 priority date, at best § 102(e) art and cannot be § 102(b) art — a materially important point if you are evaluating validity.

To close the gap definitively, the authoritative sources would be: USPTO PatentCenter for application 10/738,371 (full file wrapper, all Office actions and PTO-1449 forms), the printed front page of US 7,743,111 (foreign patent documents section), and the parent US 6,697,846 file wrapper.

I'll research the prior art that was cited against and around US 7,743,111 before doing the §103 analysis.

Let me retrieve the specific US patent citations listed on the '111 patent and check a few key references.

Let me pull the complete citation list and check for any validity challenges that discussed prior art.

Obviousness Analysis — U.S. Patent No. 7,743,111 ("Shared file system") under 35 U.S.C. § 103

Grounds reminder and sourcing. This analysis uses the prior art of record on the face of the patent (as surfaced in the Google Patents / FreePatentsOnline / SumoBrain records for US 7,743,111), the applicant's own background discussion, and the related-family record. Where I could not verify something, I say so. Two references that appear in the "Patent Citations" list — US 2002/0112022 A1 (Kazar et al.) and US 2001/0037406 A1 (Philbrick et al.) — are dated such that they are not prior art to the 1998 priority date except under restricted theories (§102(e)); see §3.3. My search session did not retrieve the full 15-item U.S. citation list, a prosecution history, or any IPR/PGR record, so I treat that list as partial (two of fifteen items confirmed).

1. Priority / critical date — this drives everything

Consequence: The operative prior-art window is anything publicly available before 1998-03-20, with §102(b) bars reaching back to 1997-03-20. This is why essentially the entire citation list consists of 1985–1997 academic and industrial work. It also means the Kazar and Philbrick publications (published 2002 and 2001 respectively) can only be used if the 1998 priority is broken for the claims at issue, or via §102(e) as of their U.S. filing dates — which for Kazar (2000-12-18) is still after the priority date and therefore of no use at all against claims entitled to 1998-03-20.

2. The prior art of record (as retrieved)

2.1 U.S. patent documents (partial list — 2 of 15 confirmed)

2.2 Non-patent literature (the substantive prior art of record)

Also expressly admitted as prior art in the '111 specification itself (background section): the Cray Research Shared File System, the Digital VAXcluster, the Global File System (GFS) from the University of Minnesota, Andrew File System, Sprite, Coda, xFS, and the HPSS/SIOF project at Lawrence Livermore. Statements in the specification describing the state of the art are usable as applicant admissions (e.g., In re Fout, and the MPEP line that arguments/admissions in the spec can supply missing claim elements of the prior art).

3. What the claims actually add over the art

Stripping '111's independent claims to their distinguishing features (claim texts as verified in the supplied record; claim 24 flagged):

1. The server does namespace only — add/remove/search filenames encoded in a protocol the server understands (claim 1(c)(i)); retrieve/modify directory files (claim 10(b)); namespace search (claims 17, 56(b)).
2. The client owns the metadata — directly retrieving, analyzing and altering metadata that includes pointers to real-data (claim 1(c)(ii)); create/retrieve/modify metadata (claim 10(c)(iii)); analyze and alter allocation information metadata and save it (claims 53(c)–(d), 56(c)–(d)).
3. The real-data path bypasses the server — client reads/writes the network storage device directly (claim 10(c)(ii); claim 9).
4. Ancillary: locks before metadata modification (claims 16, 55); server-enforced permissions (claims 7, 18); attributes forwarded to server (claims 14–15); metadata stored as a real-data file by the server (claims 19–21); LAN/SAN split (claims 11–13); bitmap allocation tables (claim 54).
5. No claim expressly requires "unmodified/off-the-shelf client-server DFS as the metadata store," "holes in an inode file to encode file size," "segment files," "superfile," or "inode files stored as regular files on the MFS." Those are embodiments, not limitations.

That mismatch is decisive: the claims are materially broader than the described invention's cleverest parts, which makes them substantially easier to invalidate.

4. Level of ordinary skill and the legal standard

A PHOSITA here is a systems-software engineer with ~2–5 years' experience in operating-system kernel/file-system design (VFS/vnode internals, NFS or an equivalent RPC-DFS) plus exposure to shared-disk/network-attached storage. That is precisely the audience of every reference above.

Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007): (i) a combination is obvious when the improvement is a predictable use of prior-art elements according to their established functions; (ii) where there is a design need or market pressure and a finite number of identified, predictable solutions, following the lead is not innovation; (iii) the "obvious to try" standard is met when the field presents a small set of candidate solutions; and (iv) an express teaching, suggestion, or motivation is not required. Under pre-AIA §103(a), the relevant question is whether the claimed subject matter as a whole would have been obvious — the de facto scope of the prior art here is the entire literature on distributed and shared-storage file systems published 1985–1997, which is remarkably broad.

5. Combination analysis

I give five combinations. Combinations A and B alone are, in my view, sufficient to render claims 1, 2, 4–7, 9–23, and most of 53–56 obvious to a preponderance.

Combination A — Principal: GFS/private-file-manager shared-storage art + NFS (Sandberg 1985; Pawlowski 1994) + Vnodes/VFS (Kleiman 1986; Rosenthal 1990)

This is the strongest and most economical: it uses the applicant's own admitted prior art as the primary reference.

Motivation. Two independent, express motivations exist:

• Data-path optimization. The '111 specification itself states the server in the data path "adds overheads caused by server workload and overheads relating to storage device interface to network interface protocol translations," and that shared-storage designs "have a short data-path between clients and devices." A reference in the same record — Gibson et al., "File Server Scaling with Network-Attached Secure Disks" — is devoted to the proposition that the central file server is the scaling bottleneck and that clients should address storage directly. Matthews (1995) and Wiltzius & Minuzzo (1995) supply the shared-channel implementation.
• Code reuse. Heidemann & Popek (1994) and Rosenthal (1990) expressly teach that new file systems should be built by stacking on existing ones to inherit namespace, attribute, and consistency machinery. Khalidi & Nelson (1993) show it in a shipping OS. That is exactly the "layering" the '111 specification identifies as its second founding technology — and the specification admits it as prior art ("file system layering … include adding quota support … compressing or encrypting files … without such support").

Predictability / reasonable expectation of success. NFS's namespace semantics and attribute handling were stable and public (Sandberg; NFSv3). Layering was already demonstrated. Client-side handling of shared-disk metadata was already demonstrated in GFS and in NASD. The combination is a rearrangement of known components each doing what it already did.

Combination B — Secondary: Anderson et al. (xFS, 1995) + NFS + VFS/vnodes

xFS is the closest academic teaching of the full architecture:

• xFS is shared-storage (its data path bypasses a data server) — satisfies claim 10(c)(ii) and claim 9.
• xFS distributes metadata management to cooperating clients with a global consistency mechanism instead of a monolithic metadata server — satisfies claim 1(c)(ii), claim 10(c)(iii), and claims 53/56's client-side analyze-and-alter of allocation metadata.
• NFS supplies the single, centralized, mature namespace with permissions, which is what claim 1(c)(i) and claims 5–7/17–18 recite.
• Kleiman/Rosenthal supply the VFS/vnode plumbing that makes the client able to treat "metadata as a file" and "real-data as a block device" through one interface.

Motivation. Combining xFS-style metadata handling with NFS-style namespace/attribute handling is the predictable, identified solution to the problem the field had articulated for a decade: get the server out of the bulk-data path (Gibson, Anderson, Matthews, Wiltzius) while preserving the namespace/attribute semantics users already had and the DFSs already implemented (Sandberg, Pawlowski). Under KSR's "finite number of identified, predictable solutions" prong, that is the essence of obviousness. Devarakonda et al. (1995), "Evaluation of Design Alternatives for a Cluster File System," is itself a roadmap reference: a paper whose entire purpose is to enumerate and compare the design alternatives (central metadata server vs. distributed client metadata, locking, data path) — evidence that the design space was small and being systematically explored before the priority date.

Combination C — NASD (Gibson 1997, both papers) + NFS/vnodes — targets claims 53–56 specifically

Claims 53(c)–(d) and 56(c)–(d) require the client to analyze and alter allocation-information metadata and to save it. NASD is directly on point: its file system places responsibility for allocation and permission metadata on clients talking to secure network-attached disks, with cryptographic capability keys standing in for a server-mediated file handle. Combine with NFS for the namespace request/response and the "separate server that manages the namespace" element.

Motivation. Gibson's NASD papers expressly state the design motivation — remove the file server as a scaling and bandwidth bottleneck by letting clients manipulate allocation metadata and address disks directly. That is the motivation required for the claimed client-side alteration of allocation metadata, stated in the prior art itself.

Combination D — HPSS/SIOF NAP (Wiltzius & Minuzzo 1995) + NFS — targets claims 10, 19–23

HPSS/SIOF's network-attached peripherals deliver data directly to clients while a control/management path remains centralized — claim 10's two-path architecture. NFS layered on an existing local file system supplies claim 19–21 ("server computer stores the metadata within a real-data file"/"operating as the server of a client-server file system") and claim 22–23 (server storage device distinct from the network storage device), because NFS is by construction a DFS that stores everything as ordinary files on a server-attached device.

Motivation. "Reuse the mature, already-installed central file service for the low-bandwidth control/metadata traffic; use the new fast direct path for the bulk traffic" is the express rationale of the NAP paper and the admitted state of the art.

Combination E — Sprite (1988) / Coda / Devarakonda (1995) + NFS locking — targets claims 16 and 55

Claims 16 and 55 require a lock acquired before metadata modification (and released after). Sprite and Coda are 1988–1990 systems with client-side caching and server-mediated consistency protocols; NFS v3 included a companion locking protocol; Devarakonda compares locking designs for cluster file systems. And the '111 specification admits the need ("Meta-data consistency is … vital to file system integrity. Corruption of meta-data may result in the complete destruction of the file system"). A lock-before-modify discipline is the textbook, predictable answer to a known shared-mutable-state problem. This is a classic KSR "predictable variation of the prior art."

6. Claim-by-claim disposition summary

Practical conclusion: Claims 1, 10, and (subject to verification) 24 are obvious over Combination A alone; claims 53–56 are obvious over Combination C with NFS; claims 16 and 55 over Combination E. The dependent claims add only conventional, admitted, or expressly-taught subject matter.

7. Why a PHOSITA would have been motivated — consolidated

1. Express motivation in the art. Gibson et al. (NASD, 1997) and Anderson et al. (xFS, 1995) are about removing the file server from the data path; Heidemann & Popek (1994) is about building file systems by stacking layers on existing ones. Together they state the two motivations the '111 specification names as its own foundation.
2. Applicant admissions. The '111 background itself recites the catalogue of prior-art designs (Cray, VAXcluster, GFS, xFS, HPSS/SIOF) and their trade-offs, i.e., "private file managers have primitive caching and hard recovery" vs. "shared file manager designs are complex and brittle." A PHOSITA reading that catalogue is handed the problem statement and two known partial solutions. KSR teaches that such a roadmap plus predictable recombination defeats §103.
3. Market/design pressure. Server cost and scalability ("Server computers designed to support large workloads are very expensive" — admitted in '111) plus the availability of Fibre Channel as a combined channel/network interface (admitted in '111) supply the classic KSR "design need and market pressure" prong.
4. Finite, identified, predictable solutions. Devarakonda et al. (1995) had already enumerated the design alternatives for cluster file systems. Where the field has enumerated the options, selecting one is not invention (KSR; Perfect Web Techs. v. InfoUSA).
5. Reasonable expectation of success. All the components — NFS namespace/attributes, vnode layering, direct shared-storage access, client-managed allocation bitmaps, lock-based consistency — had each been built and published. The claimed result is their predictable union.
6. "Prior art of record" does not immunize. The fact that several of these references appear on the face of the patent only establishes that the examiner considered them; §103 is judged afresh on the merits, and Google/third-party citation lists frequently include references the examiner did not apply.

8. Counterarguments a challenger must overcome (and the rebuttals)

9. Explicit caveats and unverified items

1. Claims 24–52 are not in my authoritative excerpt. Claim 24's element (b) is truncated; I cannot chart it, and I cannot rule out additional independent claims. The analysis above covers the claims I could verify (1–23 as excerpted, plus 53–56). Do not treat my claim mapping as complete.
2. Claim 53 step (a) and claim 56 step (a) are partially outside my excerpt; I inferred (a) ≈ "receiving the file request at the client computer" from the parallel structure, but I flag this as inference, not verified text.
3. Claim 53(d)/56(d) scope is ambiguous ("saving on the storage device the allocation information metadata"). Read literally it may require the allocation metadata to be persisted on the shared storage device — which maps onto the specification's alternative embodiment ("Segment Bitmaps on Network Attached Storage Devices," NAS drive-hosted allocation tables) rather than the main MFS-hosted embodiment. If that reading is correct, Combination C (NASD) becomes the primary attack and is even stronger.
4. The U.S. patent citation list is partial. I confirmed only US 2001/0037406 A1 and US 2002/0112022 A1 out of the 15 listed. A fuller picture could reveal additional §102(e) art — though any such art postdating 1998-03-20 is unusable against claims with the 1998 priority.
5. No prosecution history, no IPR/PGR, no litigation record was retrieved. I therefore cannot report what art was actually applied versus merely cited, nor any examiner reasoning or patentee remarks that would affect the §103 analysis. My earlier searches (in the sections above) likewise found no 2026 CAFC activity and no identified litigation for US 7,743,111.
6. Practical stakes. The patent is recorded Expired – Lifetime, adjusted expiration 2022-04-27, consistent with a terminal disclaimer tying it to the parent US 6,697,846. Enforceable life has run out; any §103 challenge today would matter only for past damages, for the related family members (US 6,697,846; US 7,165,096; US 7,552,197; US 8,533,295), or for defensive/precedential purposes.

10. Bottom line

US 7,743,111 claims a two-path distributed file system in which a server manages only the namespace and a separate client directly manipulates the metadata that points to real-data on shared network storage, with the bulk-data path bypassing the server. By 1998-03-20 that architecture was the predictable convergence of at least four independently published lines of work that the applicant's own specification cites: NFS-style namespace/attribute service (Sandberg 1985; Pawlowski 1994), vnode/stackable-layer extensibility (Kleiman 1986; Rosenthal 1990; Heidemann & Popek 1994), client-managed shared-storage file systems (the admitted GFS/Cray/VAXcluster designs; Anderson's xFS 1995; Matthews 1995), and client-managed allocation metadata for network-attached disks (Gibson's NASD papers, mid-1997). The motivation to combine was express, the solution space was small and already catalogued (Devarakonda 1995), and the result was the predictable union of elements performing their known functions — the KSR paradigm of obviousness.

I therefore assess claims 1–23 and 53–56 (as I can read them) as more likely than not invalid under §103(a) over GFS/xFS/NFS/vnodes (claims 1–23) and NASD+NFS (claims 53–56), with claims 16/55 additionally obvious over Sprite/Coda/NFS locking art. The features that would most plausibly have survived challenge — the inode-hole file-size encoding, the segment-file/superfile organization, the crash-repair update ordering, and the "unmodified client-server DFS as metadata store" layering — appear to be unclaimed embodiments of '111, which is the single most important finding of this analysis. Claims 24–52 remain uncharted and would need to be retrieved before any final validity opinion.