US 8261231

I'll verify the docket/litigation angle and check for any authoritative claim text, then summarize.

US Patent 8,261,231 — Analyst Summary

Search scope note up front: I searched for this exact identifier only. I found no CAFC 2026 docket, no PTAB proceeding, and no district-court case in which US 8,261,231 is the patent-in-suit. The only "8261231" hits in litigation-adjacent documents were (a) the patent appearing inside keyword-string search logs in prosecution-history exhibits filed in ironSource Ltd. v. Digital Turbine Inc., PGR2021-00096 (Docket Alarm exhibit PDFs) — where 8261231 is merely one of hundreds of numbers in an examiner's search string, not a challenged patent — and (b) it being cited as an "X" category prior-art reference in later EPO search reports (e.g., EP 2,929,412 A4; EP 3,342,145 A4). The 2026 CAFC opinions my search surfaced (Woodway/LifeCORE treadmill matter, Rare Breed/Partisan, Actelion v. Mylan) are unrelated to this patent number. The expiration status below also makes a 2026 appeal improbable.

1. Bibliographic data (from the authoritative Google Patents record supplied)

Source: https://patents.google.com/patent/US8261231/en

Assignee name caveat: one third-party account (a Patent StackExchange prior-art call) attributes the patent to a company called "appsbar." The record I was given lists the assignee of record as Media Direct, Inc. (assignment recorded 2012-02-14 from Hirsch, Pereymer, and Rajpal). "Appsbar" appears to be a product/brand reference, not the recorded assignee. Treat that attribution as unverified.

2. Abstract

The authoritative text I was given begins at the "Definitions" section and reproduces the specification, but the abstract block itself was not included in the fetched text. The abstract as indexed by third-party sources reads substantially as follows (and is consistent with the specification's summary):

Systems and methods for developing, customizing, and deploying mobile device applications are provided through a mobile application development and deployment platform. Preferably, these systems and methods are implemented in an Internet based environment that allows non-technical users to build sophisticated, highly-customizable cross-platform mobile applications. The platform allows users to select, input, create, customize, and combine various content, design characteristics, and application components, such as modules, some of which utilize features and functionality associated with various mobile devices and mobile operating systems. In certain embodiments, the platform allows users to compile, and generate a configuration file for, the mobile application that can be distributed to end users for execution on various mobile devices and mobile operating systems. When the mobile application is installed on, or executed by, the mobile device, the configuration file may enable the retrieval of various data associated with the mobile application.

(Composite from the specification's own summary paragraphs and a mirror of the abstract at https://wiki.golden.com/wiki/US_Patent_8261231_Systems_and_methods_for_a_mobile_application_development_and_development_platform-99ENVPK — flagged because I could not verify it against the front page in the text provided to me.)

3. Plain-language overview of the disclosure

The patent describes a web-based "app builder" for non-programmers: a user picks an app-type (e.g., appRestaurant, appRealtor, appBook, appMagazine, appBlog, appDoctor, appMuseum, appLawyer, appAccountant), which limits the set of available modules (contacts, feeds, forms, HTML, links, photos/videos, soundboard, stickers, menu/list with eCommerce, coupons, discography, quiz, talking friend, e-books/interactive books, events, etc.), plus design elements (themes, layouts) and content elements (text, images, audio, video). Selections are stored relationally (Apps, AppTypes, AppModules, ModuleType, Layouts, AppType‑ModuleType, AppTheme, AppCategory, AppDevices, AppUpdate/Launch tables). The platform then compiles a shell/"empty" app for selected target device sets using the mobile OS vendor's native build tools, embedding a configuration file with an app identifier, and submits it to digital distribution platforms (App Store, Android Market/Google Play, App Catalog) automatically or manually. On install/launch, the identifier is used to pull the actual application data (components, layouts, content) from a remote store — enabling on-the-fly construction, automatic updates without going back through the store, and offline use via caching. Supplementary content (ads, notifications) and social sharing features are also described.

4. Independent claims — important uncertainty flag

The full text I was furnished was truncated mid-specification (it stops in the FIG. 19 description at "…whether the developer wants to add a field to the form. If so") and does not contain the claims. Accordingly I cannot give you verbatim, authoritative claim language, and I will not fabricate it.

• An EPO search report citing US 8,261,231 lists the relevance as "claims 1‑20," which indicates the patent issued with 20 claims (this is an inference from a search-report citation, not from the patent's own claims page). Source example: EP 3,342,145 A4 search report PDF (patentimages.storage.googleapis.com).
• The only claim text I can retrieve is claim 1, reproduced in a third-party prior-art call (Patent StackExchange revision pages, mirroring Techdirt's 2012 coverage). It is consistent with the specification's FIG. 3/FIG. 4 workflow, but it is secondary-source text.

Plain-language reading of claim 1 (system claim), based on that source:

Claim 1 — System for cross-platform mobile app development. A computing device with physical memory storing instructions that cause it to: (1) provide the mobile app development platform; (2) receive a user request to develop an app; (3) receive an application property selection indicating an application category; (4) determine the customizable components based on that category, the components spanning functionality, design, and content; (5) present those components to the user; (6) receive the user's component selections; (7) associate and store application data comprising at least one application component (user-defined functionality), at least one design element (user-defined design characteristic for on-device presentation), and at least one content element (user-defined content accessed through the app); (8) determine at least one set of target mobile devices; (9) generate compiled data using build tools associated with the mobile operating system of that target device set; and (10) generate a configuration file containing an app identifier adapted for transmission to and execution on a target mobile device — wherein the identifier enables the mobile device to retrieve at least a portion of the compiled data from a remote storage location when the app is installed or executed.

That last "wherein" clause — the thin client/shell compiled package that pulls real application data remotely by identifier — is the practical heart of the claim, and it is the same concept the specification stresses at FIGS. 3 and 5 (step 70 reference data; steps 420–460 retrieval, build and display, caching, device-specific function calls).

Other independent claims: Given a 20-claim set and the disclosure's structure, one would expect at least one independent method claim and likely a computer-readable-medium or additional system claim, but I do not have authoritative text for them and cannot confirm their number or scope. Do not rely on a reconstructed claim set from me.

5. Practical notes

• The "Expired – Fee Related" status means, per Google Patents, maintenance fees were not paid; if accurate, the claims are unenforceable, which explains the absence of 2026 appellate activity and makes further asset-level diligence on this patent number largely academic.
• The patent's disclosure is unusually broad for its era and has been cited as "X" art against later mobile-app-development applications, and it is the subject of an informal prior-art collection effort (the StackExchange thread names AppBreeder, GENWI, MobileAppLoader, Yapper, and the defunct Whoop as candidate prior art). Those are third-party assertions, not adjudicated findings.

If you need the verbatim claim set, the authoritative source is the granted patent PDF/Google Patents "Claims" section (https://patents.google.com/patent/US8261231/en) or USPTO PatentCenter for application 13/396,368 — the excerpt I was given did not include it.

I'll search for litigation involving US patent 8261231.

Let me search more specifically for litigation databases and the patent owner.

Litigation Search Results for US Patent 8,261,231

Summary: I did not find any litigation (district court, Federal Circuit, ITC, or PTAB) specifically involving US Patent 8,261,231.

What I searched

• General web search for US patent 8261231 litigation
• "8261231" patent lawsuit
• "8,261,231" patent infringement defendant complaint
• Searches keyed to the assignee/inventors (Media Direct, Inc.; Hirsch et al.)
• Searches aimed at litigation aggregators (Unified Patents, Docket Alarm, PACER/CAFC references)

What the searches actually returned (and why each is not litigation on the '231 patent)

1. Prior-art citations to US 8,261,231 — not litigation.

   • EP 3,342,145 A4 search report cites US 8261231 B1 (HIRSCH SCOTT [US] ET AL) as an X-category reference.
   • EP 2,929,412 A4 cites US 8261231 B1 as an [Xi] reference.
   • A Russian patent (RU 2,778,379, Yandex) lists US 8261231 B1, 04.09.2012 in its search report.
     These are examiner/third-party prior-art citations, not assertions of the patent.

2. A PTAB proceeding that mentions the number — not about this patent.

   • PGR2021-00096, ironSource Ltd. v. Digital Turbine Inc. — the string "8261231" appears only as one entry in a long list of patent/publication numbers in a prior-art search-query log (Exhibits 1002 / 2001). The proceeding itself does not concern, and does not challenge, US 8,261,231.

3. Patent-family / assignee pages — not litigation.

   • FreePatentsOnline and Justia pages for 8261231 show assignee Media Direct, Inc., inventors Scott Hirsch, Arsen Pereymer, Sunny Rajpal, and priority date 2011-04-06 (provisional 61/472,609). These are bibliographic pages, with no litigation entries.
   • The Google Patents record for US 8,261,231 lists legal status "Expired – Fee Related" and shows no litigation/"Patently" or "Litigation" section entries. The only post-grant events listed are foreign family filings (AU, CA, EP, JP, KR, PCT/WO) — prosecution, not litigation.

Conclusion

Based on the available search results, no known litigation is asserted against or by US Patent 8,261,231. The patent appears to have lapsed (Expired – Fee Related, with anticipated expiration noted at 2032-02-14). Its only documented appearances in the record are as a cited prior-art reference and in an unrelated PTAB proceeding's prior-art search logs.

Important limitations / caveats

• I was unable to run additional, more targeted queries (e.g., direct Docket Alarm / Unified Patents database lookups, PACER docket report retrieval, or Federal Circuit docket searches) before exhausting my search budget. My searches did not constitute an exhaustive, authoritative clearance search of every district court docket and every PTAB proceeding.
• The '231 patent has many US siblings/applications in the same family (e.g., the numbers 8,768,063; 8,875,095; 8,893,629; 8,876,091; 8,892,701; 9,026,673; 9,075,595; 9,223,899; 9,334,373; and others appearing in the search logs). Litigation is sometimes asserted on sibling/continuation patents rather than on the exact patent number. If you need a definitive answer, I recommend a dedicated search of that family in PACER, Docket Navigator, and Unified Patents' litigation portal.
• Per your standing instruction, I have interpreted all identifiers literally and have not auto-corrected any patent or case numbers.

If you'd like, I can attempt follow-up searches specifically on the sibling patents in this family (e.g., by assignee "Media Direct, Inc." or by plaintiff/vendor name) to check whether the same subject matter has been litigated under a different patent number.

PTAB Proceedings — US 8,261,231 ("Systems and methods for a mobile application development and development platform")

Assignee of record: Media Direct, Inc. (Appsbar) · Inventors: Hirsch, Pereymer, Rajpal · Granted: 2012-09-04 · Priority: 2011-04-06 (provisional 61/472,609) · Legal status per Google Patents: "Expired – Fee Related"

Proceedings overview

Total AIA trial proceedings on file: 0 — no IPR, PGR, or CBM petition has ever been instituted, denied, or terminated against US 8,261,231; the structured USPTO ODP block reports no AIA proceedings, and independent web searching surfaced no proceeding number, FWD, or PTAB E2E docket naming this patent. Because there is no PTAB activity at all, there is no claim to call "invalidated" and no claim to call "hardened": for a defendant, the bottom line is that § 315(e)(2) estoppel is a blank slate — no petitioner, and no petitioner's privies, are barred from running an IPR on any ground — but it also means the claims are wholly untested at the Board, and the assertion risk you face turns on the patent's expiration status, not on any prior PTAB loss.

Canonical source note (per the "PTAB proceedings on file" block): the USPTO Open Data Portal API returns no AIA trial proceedings for this patent as of the most recent ingest. That is the authoritative list for this report. Everything below is either (a) verification searching, or (b) flagged as not this patent.

No proceedings to report

There is no proceeding-number section to populate. I searched for IPR/PGR/CBM activity on 8,261,231 by patent number, by "Appsbar," and by "Media Direct," and found no AIA trial.

False positives you should not confuse with this patent (these are the only "'231" PTAB hits that surfaced, and they involve different patents):

• IPR2020-00603 — U.S. Patent No. 6,232,231 (semiconductor damascene metallization, not 8,261,231); instituted on all challenged claims and grounds; grounds included claims 1–4, 8 under § 103(a) over Jaso + Stine1998. Source: PTAB E2E petition documents (PATENTSCOPE/PTAB E2E mirrors). This is a different patent and a different patent owner.
• U.S. Patent No. 6,232,231 also appears in a denial-of-institution filing (AMT v. patent owner, petition filed ~2021-12-01) referencing "Ground 4 … Ito." Again unrelated.
• EP prosecution citations of US 8,261,231 as prior art (EP 3,342,145 A4; EP 2,929,412 A4) — these are this patent, but as a cited reference in third parties' European prosecutions, not as a PTAB subject. Useful prior-art notoriety context only. (EP3342145A4, EP2929412A4)

⚠️ Flag before anything else: verify the maintenance-fee lapse

Google Patents' legal-status field for this patent reads "Expired – Fee Related" with an anticipated expiration date of 2032-02-14 (US8261231B1). Google expressly disclaims that this is a legal conclusion, and I did not independently verify a lapse window via USPTO maintenance-fee records. Verify this first in USPTO Patent Center before spending a dollar on validity work. If the patent lapsed for non-payment (3.5-year fee due ~2016-03, 7.5-year fee due ~2020-03, 11.5-year fee due ~2024-03), that fact is materially more important to a defendant than anything the PTAB did or didn't do. If it lapsed, only past damages within the § 286 six-year lookback remain live, and there is no injunctive exposure. An expired patent can still be challenged in IPR (expired claims are construed under Phillips per the Board's practice in Idle Free Systems v. Bergstrom, IPR2012-00027, and cannot be amended), so expiration doesn't foreclose PTAB relief — it just changes the cost/benefit calculus.

Strategic summary

Claim status. UNTESTED — all of them. No claim of 8,261,231 has ever been canceled, confirmed, or even institution-tested by the PTAB. There is no surviving-claims list to give you because there was never a narrowing. If a demand letter asserts claim 1 (or any of claims 1–20), the letter is not citing a claim that has been invalidated anywhere; it is citing a claim that has simply never been attacked at the Board. The only public signals of vulnerability are non-adjudicative: the 2012 Techdirt coverage of Appsbar's stated intent to "strictly enforc[e]" the patent (Techdirt, 2012-11-16), the crowdsourced prior-art call on Patent Stack Exchange (Whoop, PhoneGap, Illumination Software Creator, GLBasic, and similar pre-2011 graphical cross-platform code generators), and the fact that two European examiners treated this patent as X-category prior art against third-party claims — which cuts both ways: it shows the disclosure is broad enough to anticipate others, and it shows the art space was crowded as of 2011.

Estoppel landscape. None attaches. § 315(e)(2) estoppel runs only against a petitioner that obtained an FWD; with zero proceedings, no party and no privy is barred. Grounds that were raised or reasonably could have been raised in a hypothetical IPR remain fully available to you. Also note two availability limits on the AIA-trial side: PGR is unavailable — this patent's claims all carry pre-2013-03-16 effective filing dates, so § 321 post-grant review never applied; and the CBM transitional program is closed to new petitions (it sunset 2020-09-16), so CBM will not be an option either. Practically, IPR is your only AIA trial vehicle, alongside ex parte reexamination, which is attractive here precisely because it carries no § 315(b) one-year bar, no estoppel, and no real-party-in-interest fight — at the cost of being ex parte and slower. Watch the § 315(b) clock: if you've been served with a complaint alleging infringement, you have one year from service to file; and if you filed a declaratory-judgment action challenging validity first, § 315(a)(1) bars an IPR outright.

Pattern signals. No petitioner has ever filed on this patent, so there is no serial-petitioner or joined-petitioner pattern to read. The patent owner has never had a PTAB appeal to pursue (no Arthrex-era or Director-review activity exists for it). There is no evidence of any defensive aggregator (Unified Patents, RPX, AST, LOT) in the chain — and the fact that this is exactly the profile of patent Unified would normally target (broad software platform claims, aggressive enforcement rhetoric, publicly criticized) is itself telling: well-asserted patents eventually attract IPRs, and this one attracted none, which suggests either that it was never assertively litigated in a way that produced a motivated, funded petitioner, or that the enforcement campaign never materialized past the 2012 press release. I found no confirmed district court docket asserting 8,261,231 — I could not verify any litigation in my searches, so treat "this patent has been litigated" as unverified and check CourtListener and Docket Alarm directly.

Recommended next steps

1. Pull the maintenance-fee status first at USPTO Patent Center for application 13/396,368. If the patent is lapsed, price a laches/§ 286 defense and consider whether a validity challenge is worth funding at all.
2. Confirm the null PTAB result independently at PTAB E2E (search by patent number 8261231 and by party "Media Direct") and at the PTAB Decisions page. The ODP ingest may lag recently filed petitions; note that any petition filed in the last ~60–90 days would not yet appear in a stale ODP pull.
3. Check for litigation and any past assertion campaign via CourtListener and Docket Alarm (patent number and "Media Direct"/"Appsbar" as party). A prior litigation with a § 315(b)-triggering service date is the single fact that could change your filing strategy overnight.
4. Because no FWD exists, there is no disposition to quote and no opinion link to give you — do not let anyone hand you a 6,232,231 or other "'231" FWD as if it belonged to this patent. Verify the patent number on the face of any decision before using it.
5. If you do proceed, budget an IPR on the strongest § 103 combination drawn from the pre-2011 graphical cross-platform code-generation art (Whoop, PhoneGap-era toolchains, GLBasic, Illumination Software Creator) plus the app-type/module/layout configuration architecture disclosed in the specification — the claims' novelty lies in the remote-data-with-shell-clients configuration-file mechanic (see the FIG. 4 data model and the FIG. 5 execute/retrieve/cache flow), so that limitation is where your obviousness theory should concentrate.

Bottom line: the PTAB has never touched this patent. Your PTAB posture is therefore offensive and unconstrained, not defensive — but confirm the fee lapse and confirm the absence of a § 315(b) service date before you commit.

I'll research the assignment record and litigation history for US 8261231.

Let me search for more specific ownership and litigation information.

Let me dig into the Appsbar connection and the litigation history.

Assignment & Ownership Analysis — US 8261231 B1

Scope note / data limitation (read first): I was not able to open the USPTO Assignment Center (assignmentcenter.uspto.gov) as a live session, and my retrievals from Google Patents' legal-events block and third-party indexes did not expose reel/frame numbers or the recording correspondent for this patent. Per your constraints I will not fabricate reel/frame identifiers. Everything below is grounded in the records I could actually retrieve, and I flag each place where a field was unavailable. This is itself part of the finding: the only ownership event of record for US 8261231 is the original inventor→company assignment; no post-issuance transfer is documented in any source I retrieved.

Inventors

Source: the PCT publication for the sibling case (WO2013121301A3) lists applicant MEDIA DIRECT, INC., 260 SW Natura Avenue, Deerfield Beach, FL 33441, with the three inventors at the addresses above; the issued US 8,898,629 front page names the same three inventors and the same assignee. The Google Patents legal-events block for US 8261231 records the inventors conveying to Media Direct, Inc. on the filing date.

Pattern notes:

• All three inventors were the founders/principals of the assignee, not rank-and-file engineers. This is a founder-owned startup fact pattern, not the "inventors depart before fire-sale" pattern.
• No evidence of any inventor leaving the assignee within 12 months of the 2012-02-14 filing. The same three inventors continue to appear as inventors on the entire Media Direct continuation family filed in March 2013 (US 8,875,095; US 8,898,629; US 8,978,006; US 2014/0109046). Continuity of the inventor group across the family cuts against the "abandoned by its inventors" signal.
• Arsen Pereymer carries an earlier, unrelated software lineage: US 2003/0197746, "Data Collection Technology Useful For Form Manipulation," filed 2002 out of Brooklyn, NY (with Elvis Pereymer). This is a web-forms tool, not mobile — background color, not an NPE indicator.

Original assignee

Media Direct, Inc. — a Florida corporation, 260 SW Natura Avenue, Deerfield Beach, FL 33441.

• Named on the issued patent: Yes. Patents-Review and FreePatentsOnline both show assignee "Media Direct, Inc. (Deerfield Beach, FL)" for US 8,261,231 and its siblings.
• Product embodying the claims: The patent claims a hosted, cross-platform mobile-app builder that compiles against native OS build tools and ships a configuration file that pulls app content from a remote server. Media Direct's commercial embodiment is Appsbar, a free web-based cross-platform mobile app builder. Contemporary coverage (Techdirt, Nov. 16, 2012) describes the patent as belonging to "Appsbar," and an Ask Patents prior-art call from late 2012 refers to the '231 patent as "a company named Appsbar['s] … utility patent on code generation as used for creating cross-platform apps for mobile devices." I could not corroborate the exact corporate relationship between the Appsbar brand and Media Direct, Inc., but the product description matches the claimed architecture closely (remote configuration file → retrievable app data).
• Primary line of business: Hosted do-it-yourself mobile application development (a "no-coding" app builder for SMBs, restaurants, musicians, etc.).
• Current status (as of this analysis): The patent itself is Expired – Fee Related on Google Patents, with anticipated expiration 2032-02-14 (i.e., the 20-year term was cut short by non-payment of maintenance fees). I found no 10-K/8-K, no bankruptcy docket, and no acquisition announcement for Media Direct, Inc. Status = operating-at-filing, now effectively dormant/abandoned as to this asset; unable to confirm current corporate status. No public-company ownership change is documented.

Also note the family's filing posture: the parent application was filed under the USPTO Track One expedited program (the cross-reference in US 8,898,629 references a concurrently filed "track1" docket), which explains grant in under seven months (filed 2012-02-14, issued 2012-09-04). Fast-track grant is a portfolio-building tell, but it is equally consistent with a startup racing to protect its product.

Assignment timeline

Every source I could reach (Google Patents legal events; the USPTO assignment data as indexed by Google Patents; the sibling-family prosecution records) shows exactly one recorded conveyance:

• 2012-02-14 (executed) / recorded 2012-02-14 — Reel/Frame: not exposed in the sources retrieved
  • Conveyance: Assignment ("ASSIGNMENT OF ASSIGNORS INTEREST")
  • Assignor: Hirsch, Scott; Pereymer, Arsen; Rajpal, Sunny (individually)
  • Assignee: Media Direct, Inc. (Deerfield Beach, FL)
  • Correspondent: Not available from the sources retrieved. The family's prosecution agent of record is Bryan Cave LLP (per the published-application file data for US 2012/0260232 / US 8,898,629). Prosecution counsel is often, but not always, the assignment recording correspondent — I will not assert that Bryan Cave recorded this assignment without seeing the cover sheet.
  • Context: Founder-to-company assignment at formation/filing — the standard "each inventor hereby assigns to the company" instrument that perfects the company's chain of title the day the application is filed.

No security agreements. No mergers. No changes of name. No license recordations. No releases. No corrections. No transfers to any IP-holding or licensing entity. I found no assignment naming an NPE, no assignment to a defensive aggregator, and no litigation in which US 8,261,231 is the asserted patent.

If the Assignment Center in fact shows additional reels beyond this single inventor assignment, they were not surfaced by any indexed copy I could reach; flag that for manual confirmation.

Timeline diagram

timeline
    title Ownership of US 8261231
    2011 : Provisional 61472609 filed
    2012 : Nonprovisional 13396368 filed
         : Inventors assign to Media Direct Inc
         : Patent US8261231 issues
         : Appsbar platform reported as product
    2013 : Continuation family filed by Media Direct
    2026 : Expired fee related no assignments found

(Event text kept punctuation-free; the final entry marks the observed Expired – Fee Related status rather than a specific abandonment date, which no source gave me precisely.)

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT.
No assignment to any entity bearing an "IP / Patents / Licensing / Holdings / Ventures" suffix, no registered-agent address, no single-purpose LLC anywhere in the record. The sole recorded assignee is the operating company that shipped the platform (Media Direct, Inc.). The family patents (US 8,875,095; US 8,898,629; US 8,978,006; US D681,654) all remain in Media Direct's name in the sources retrieved.

2. Known asserter in the chain — NOT PRESENT.
Media Direct, Inc. does not appear on any NPE list I could check (Acacia, Marathon, IV, IPNav, Wi-LAN, Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities). No Unified Patents or RPX high-frequency-plaintiff directory listing surfaced for Media Direct. Where US 8,261,231 does appear in litigation-adjacent documents, it is as prior art or a citation — e.g., cited as an "X" reference in the EP supplementary search report for EP 3,342,145, and listed in exhibit tables in PGR2021-00096 (ironSource v. Digital Turbine). Cited-by ≠ asserted-by.

3. Repeat correspondent across the chain — UNCLEAR / no finding.
There is only one link in the chain, so the "recurrence" test cannot be met. I could not retrieve the recording correspondent for that one link (see data limitation above). Bryan Cave LLP appears as prosecution agent for the family, but I have no evidence it recorded the assignment. Do not treat this as a finding either way.

4. Cascading transfers — NOT PRESENT.
No consecutive assignments at all, let alone chained LLCs within 24 months. The chain is one link long and stable since 2012.

5. Pre-litigation transfer — NOT PRESENT.
No infringement suit naming US 8,261,231 was found. There is therefore no pre-suit transfer window to measure. (The 2012-11-16 Techdirt piece and the contemporaneous Ask Patents "call for prior art to get this patent re-examined or otherwise invalidated" signal public controversy over patent quality, not assertion activity — no case ever followed.)

6. Bankruptcy fire-sale — NOT PRESENT / no evidence.
No Chapter 7 or 11 docket, no 363 sale, no SEC disclosure surfaced for Media Direct, Inc. The patent's Expired – Fee Related status indicates the owner stopped paying maintenance fees, which is the opposite of a monetization-driven asset — but I found no evidence of a formal insolvency proceeding. Call this not present, with the caveat that a small private Florida company could have dissolved without a retrievable public record.

7. Privateering — NOT PRESENT.
No operating company is transferring to an NPE to assert on its behalf. There is no NPE in the chain at all.

8. Defensive aggregator — NOT PRESENT.
The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. The patent was not "neutralized" by acquisition — it simply lapsed.

Verdict

Insufficient data (only the original assignment is recorded).

The entire documented chain of title is a single founder→company instrument dated 2012-02-14, conveying US 8,261,231 from Hirsch, Pereymer, and Rajpal to Media Direct, Inc. of Deerfield Beach, FL — the operating company behind the Appsbar cross-platform app builder, whose claimed architecture (hosted build platform + remotely retrieved configuration data) the company's product embodies. No NPE, no licensing entity, no defensive aggregator, no litigation, and no post-issuance transfer of any kind appears in the record I could retrieve; the patent has since gone Expired – Fee Related, which is the profile of a lapsed operating-company asset rather than a monetized NPE portfolio. This is a clean trail-to-the-operator result — the appropriate call is Insufficient data / non-asserting, not "NPE," precisely because there is no second link in the chain to analyze.

Verify manually at: https://assignmentcenter.uspto.gov/ (search patent number 8261231) — request the cover sheet for the single 2012-02-14 conveyance to capture reel/frame and correspondent, which are the two fields I could not retrieve and the only ones that could change the read above.

I'll search for the patent's front-page references and the prior art cited during prosecution.

Let me target the front-page "References Cited" section of the patent itself.

I need the front-pageReferences Cited list. Let me query more specifically.

I've hit the tool-call limit, so I'll report what is verifiable and be explicit about what I could not confirm rather than fill gaps with invented numbers.

0. Important scope note before the reference list

The authoritative full text you supplied for US 8,261,231 B1 is truncated. The fetched copy runs continuously from the Definitions section through the FIGS. 1–19 narrative and stops mid-sentence at the forms-module flow ("a determination is then made as to whether the developer wants to add a field to the form. If so"). It does not contain the front-page "References Cited"/"Patent Citations" block, the "Other References," or the claims column. Consequently I cannot transcribe the patent's own cited prior art from the authoritative source, and I will not reconstruct it from memory — per your strict rule, inventing patent numbers would be worse than reporting a gap.

What follows therefore distinguishes three different things that get conflated in "prior art for '231":

• (A) references the '231 patent cites (front-page "References Cited") — not available in my sources;
• (B) references that cite the '231 patent as prior art against other applications — I found several, but these run the wrong direction and are not § 102 art against '231;
• (C) third-party-submitted prior art candidates — these exist in the public record and are the only substantive § 102 analysis I can actually support.

1. Bibliographic control facts (verified against the Google Patents record you supplied)

Legal-standard note that governs the whole § 102 exercise: because the application was filed 2012-02-14, before the AIA's 2013-03-16 change, pre-AIA 35 U.S.C. § 102(a)/(b)/(e) and pre-AIA § 103(a) control. Any § 102 analysis should be run under the pre-AIA framework (with the 2011-04-06 priority date as the critical date), not AIA § 102(a)(1)/(a)(2).

2. The '231 patent's own front-page references — NOT RETRIEVABLE

I could not obtain the "References Cited" list for US 8,261,231 B1 from the authoritative text or from the search results. None of my searches returned the patent's own citation block. I am not able to supply "full citation / date / description / § 102 mapping" for that list without fabricating it.

If a definitive list is needed, it must be pulled directly from:

• the USPTO Patent Center / Patent Public Search (App. 13/396,368) front page, or
• the Google Patents "Patent Citations" and "Cited By" tabs for US8261231B1,
• the printed patent PDF front page (the "U.S. PATENT DOCUMENTS" and "OTHER PUBLICATIONS" columns).

I was unable to complete that retrieval before exhausting the search budget.

3. References that cite the '231 patent (wrong direction — flagged for completeness)

These are frequently mistaken for "prior art for '231." They are the opposite: examiners elsewhere used '231 as art. None is § 102 art against '231, and none shares the '231 inventors' priority.

Conclusion: these confirm the '231 patent is used as prior art by others; they are not the art to be analyzed against it.

4. Third-party-submitted prior art candidates — the only § 102 analysis I can support

These come from the public Patents Stack Exchange challenge thread on US 8,261,231 (a third-party submission effort, not an examiner citation record). Dates and product facts below are as reported by that thread and were not independently re-verified by me. Treat them as leads requiring primary-source confirmation (archived product pages, Wayback Machine captures, product literature).

Claim 1 (as reproduced in that thread) — the target for any § 102 mapping:

1. A system for allowing users to develop mobile applications that are capable of being compiled to run on a plurality of mobile operating systems associated with various mobile devices, the system comprising: a computing device having physical memory storing instructions that cause the computing device to: provide a mobile application development platform ...; receive from a user a request to develop a mobile application ...; receive from the user an application property selection comprising an indicator of an application category ...; determine a plurality of customizable components based, at least in part, on the received application property selection ...; send information causing the plurality of customizable components to be presented to the user; receive from the user a plurality of customizable component selections ... [application component / design element / content element] ...; determine at least one set of target mobile devices ...; generate compiled data for the mobile application based on the application data using build tools associated with a mobile operating system ...; generate a configuration file comprising an identifier for the mobile application, the configuration file being adapted for transmission to, and execution on, a mobile device ...; wherein the identifier enables the retrieval of at least a portion of the compiled data by the mobile device from a remote storage location in response to the mobile application being installed on or executed by the mobile device.

§ 102 analysis caveats for Section 4. (i) Each candidate is analyzed only against claim 1; I do not have the full claim set of '231 from the authoritative text, so I cannot map dependent claims. (ii) Anticipation requires every element of the claim in a single reference — the "generate a configuration file comprising an identifier … wherein the identifier enables retrieval of at least a portion of the compiled data … from a remote storage location" limitation is the most likely element to be missing from C1–C6 and is the key gap a challenger would need to close. (iii) These are product/website disclosures; establishing § 102(a)/(b) dates requires archived captures, not memory. (iv) I have not confirmed that any of C1–C6 was cited on, or considered during prosecution of, the '231 patent.

5. What I could not verify (stated explicitly, per your instruction)

1. The patent's own front-page "References Cited" list — not present in the supplied authoritative text and not returned by search. This is the single most important missing piece for your request.
2. Whether any specific reference was cited or applied by the examiner against App. 13/396,368 — no Office action or examiner citation was retrieved.
3. The exact publication/filing dates for C1–C6 — reported, not independently confirmed.
4. The complete claim set of '231 (only claim 1 is in hand via the third-party thread) — so no dependent-claim § 102 mapping is offered.

6. Recommended next step

To answer your question authoritatively, retrieve the front page of US 8,261,231 B1 (or the file wrapper for 13/396,368) and paste the "U.S. PATENT DOCUMENTS," "FOREIGN PATENT DOCUMENTS," and "OTHER PUBLICATIONS" columns. With those in hand I can produce the complete per-reference table you asked for — full citation, date, description, and § 102(a)/(b)/(e) claim mapping for each — under the pre-AIA framework that governs this patent.

I'll gather the prior-art references associated with this patent (and its family) before running the §103 analysis.

Now let me pull the substance of the front-page references so I can map them to the claims.

Obviousness Analysis — US 8,261,231 under 35 U.S.C. § 103

Scope note. The task asks me to use "the results from the Prior Art section of this page." The fetched page text I was given is truncated in the specification and does not contain the "References Cited" section, the claims, or the prosecution history. I therefore reconstructed the prior-art set from (a) the front-page reference list for this patent as mirrored at FreePatentsOnline (freepatentsonline.com/8261231.html), and (b) the IDS/NPL list of the same family (US 8,978,006). I hit the tool-call cap before I could retrieve abstracts for several of those references, so items marked [title-level] are characterized from their titles only. Treat the following as an analyst's framework, not as an invalidity opinion, and verify against the certified record before relying on it.

1. Governing law and framing

• Statute: The application (13/396,368) was filed 2012-02-14 with earliest claimed benefit to provisional 61/472,609 (2011-04-06) — both before 2013-03-16. Pre-AIA § 103(a) governs. A reference is available if it is § 102(a)/(b)/(e) art as of its own effective date.
• Framework: Graham v. John Deere, 383 U.S. 1 (1966) (scope/content, differences, PHOSITA level, secondary considerations); KSR Int'l v. Teleflex, 550 U.S. 398 (2007) (predictable combinations, design incentives, "obvious to try," design choice).
• Subject matter character: This is a client–server software configuration/workflow claim. Under KSR, where the art is predictable and the components are known, a combination is obvious if there is (i) an articulated reason to combine, (ii) a reasonable expectation of success, and (iii) no unexpected result. The specification itself supplies the business rationales (cross-platform portability, no programming, on-the-fly updates) that a PHOSITA would have recognized as the known objectives of the field.

PHOSITA (proposed): A team of ordinary skill circa April 2011: a software engineer with a bachelor's in CS/EE and 2–4 years' experience building web-delivered, multi-tier applications (server-side content management plus browser/device clients), working with someone having 1–2 years of mobile SDK experience (iOS/Android/BlackBerry). This is a low-to-moderate level of skill; the techniques at issue (templates, wizards, code generation, HTTP retrieval, caching, installers) were conventional.

Claim text caveat (carried forward and updated): The earlier sections flagged that the claim text I have is secondary-source. I have now found a second, independent reproduction of claim 1 — the Ask Patents question body (CommonsWare, Nov. 2012), which reproduces claim 1 verbatim and separately states the patent "was filed for on Feb. 14, 2012" — and it matches the first reproduction word-for-word. That raises confidence that the claim-1 text is accurate, but it remains non-authoritative; the 20-claim count remains an inference from the EPO search-report citation ("claims 1-20"). I still do not have dependent-claim text and will not fabricate it.

2. The prior-art set on the face of the '231

Family IDS/NPL (from US 8,978,006's reference list — useful as leads, unusable in part): App Inventor (Dec. 30, 2010); AppsGeyser (Mar. 24, 2011); Balagtas-Fernandez, "Mobia Modeler" (IUI 2010); Abrahamsson, "Mobile-D" (OOPSLA 2004). Post-dating the 2011-04-06 priority date and therefore not § 102 art against the '231 absent a priority failure: Anubavam (Oct. 12, 2011); Churchill/iBuildApp (Jun. 13, 2011); Apps Builder (Feb. 10, 2012); Appy Pie (2013). Third-party (unverified) candidates from the Ask Patents prior-art call: Whoop, AppBreeder (Jan. 2010 per that thread), Yapper (May 2010), Illumination Software Creator (May 12, 2010), GENWI and MobileAppLoader (Jun. 2011 — post-date), PhoneGap (Mar. 2009). Only the pre-April-2011 ones are usable, and each needs corroboration (archive captures, product literature, source code).

3. Element-by-element mapping and the grounds

Ground 1 — Eteminan alone: anticipated in substantial part, and obvious over Eteminan

Eteminan discloses a web-browser-delivered ecosystem in which a user composes an application from existing components, the system builds the application natively for each target mobile brand/OS group, and distributes it through a brand-agnostic store. That reaches:

• Preamble / E1 — system of cooperating elements implemented as a web-based service (Pub. ¶¶[0010]–[0013]).
• E2, E3 — a browser-accessible "Mobile Application Composition Studio" for creating applications (¶[0012]).
• E5, E6, E7 — component library + explicit teaching of "new applications … created through attribute customization of existing applications, incorporation of various existing application components" (¶[0009]).
• E8 — application data comprising components plus data/interfaces (¶[0012], "logic, interfaces, and data").
• E9, E10 — "Mobile Application Build Engine" producing builds native to each device brand or brand group (¶[0010]).
• E11 — the store/distribution subsystems deliver an installable application construct.

Probable gap: explicit disclosure of (i) an "application property selection" that drives the set of offered components, and (ii) the "wherein" clause (config file with identifier → device pulls compiled data from remote storage at install/launch). Eteminan's emphasis on native builds (and its stated desire "to avoid … a separate common runtime or virtual machine") cuts against a thin shell. That is the honest weakness in a single-reference attack.

Ground 2 (strongest two-reference combination) — Eteminan + O'Farrell (US 2010/0251230), optionally + Kirsch (7,962,762)

O'Farrell is titled and directed to context-sensitive mobile data and software update — i.e., a mobile device that contacts a server and obtains application data/software updates based on its context/version. Kirsch teaches a user module whose data is stored server-side and accessed from the mobile device. Either supplies E12.

Motivation to combine (articulated):

1. Same field, same problem, complementary teachings. Both references address delivering and maintaining mobile application content on heterogeneous devices over wireless links. Eteminan's grievance is per-brand build/store friction; O'Farrell's is stale on-device data/software. Combining them solves both with no change in principle of operation.
2. The patent's own stated advantage is the motivation. The '231 touts (specification, "FIG. 5" discussion) that updates "may be realized immediately by end users without requiring them to manually download updates and/or connect to a digital distribution platform." That commercial/technical desideratum — avoid the store approval/re-download cycle — is the classic reason a PHOSITA would replace full-payload builds with an identifier-bearing shell that fetches live data. Eteminan's own approval/verification bottleneck (its central complaint) supplies the same incentive.
3. Reasonable expectation of success / predictability. Both systems are HTTP client–server architectures; the "shell + fetch + cache" pattern was the standard web-application pattern of the era. No new hardware, no unpredictable physics.
4. KSR "design choice." Whether to ship all application data or an identifier plus a subset is a deployment-payload tradeoff routinely made based on over-the-air bandwidth, storage, and update-freshness — an ordinary engineering choice with predictable results.

Ground 3 — Eteminan + Brisebois (+ Jain / Loos) for E2–E8

Brisebois ("customizing a mobile application using a web-based interface") supplies expressly and unambiguously the web-mediated, non-programmer selection of application attributes. Jain and Loos supply commercial-grade mobile-app development/delivery flows. Motivation: same field; Eteminan's own aim is "used intuitively by all people, including children and adults who are not skilled software developers," which is precisely Brisebois's stated purpose — a textbook KSR "same problem, obvious to try the other's approach" rationale.

Ground 4 — + Knight (US 2008/0222621) and/or Nigam (US 2010/0017812) and/or Balathandapani (7,890,926) for E9–E10

Knight discloses automatically building a customized software application for a specific type of wireless computing device — i.e., the target-device-set → generated-build step. Nigam discloses a framework for deploying the same application across heterogeneous mobile environments. Motivation: Eteminan already recites per-brand native building; Knight/Nigam confirm this was the conventional implementation and supply the "build tools associated with the mobile operating system of the target set" teaching that the claim recites generically.

Ground 5 — Dependent-claim exposure (mapping only; claim numbers are my extrapolation and must be verified)

Given the 20-claim set and the disclosure's module-by-module structure (FIGS. 9–43C), the dependents almost certainly recite things like: specific module types (contacts, feeds, forms, HTML, links, photos/videos, soundboard, stickers, menu/list+eCommerce, coupons, discography, quiz, talking friend, e-books/interactive books, events); themes/layouts; the relational data model (Apps/AppTypes/AppModules/Layouts/AppTheme/AppCategory/AppDevices tables); submission to and approval by a digital distribution platform; device-specific feature calls; caching/offline operation; advertisements and notifications; digital signature/unique identifier; and social/developer-network features.

Ground 6 — Analogy art for the "configuration file + identifier → fetch at launch" limitation (E12)

Even if a tribunal credits Eteminan with a "full-payload native build" architecture, E12 is a well-known deployment pattern in the art: descriptor/manifest files that are small, carry an identifier or URL, and cause the real payload to be retrieved at launch — e.g., Java Web Start/JNLP (from 2001) and ClickOnce manifests (from 2005), and client-side widget/gadget containers that instantiate remote content by identifier. Flag: these are my knowledge-based analogies, not references I verified on the face of the '231 or in the family IDS. They are most useful as "the pattern was old" evidence to rebut a "specific shell architecture" non-obviousness argument. The references actually in the record that best capture this point are Neil 7,913,234 (execution of textually-defined instructions delivered to the device), O'Farrell, Kirsch, and Bosworth.

4. Rebutting the likely patent-owner responses

1. "The examiner allowed over Eteminan." Eteminan appears at the top of the references-cited list, so it was before the examiner. I do not have the file history and cannot say what the distinguishment was — but the most likely candidates are the E12 shell/fetch clause or the category-driven component determination. A challenger must obtain the applicant's remarks and the Examiner's Reasons for Allowance and then show either (a) the distinguishing feature is taught/suggested by O'Farrell, Kirsch, Brisebois, or Neil, or (b) the distinguishment rested on a non-limiting preamble or an over-narrow reading.
2. "The prior art builds complete applications; the '231 builds an empty shell." This is the strongest defense. Counters: (i) the claim says "generate compiled data" and requires retrieval of "at least a portion of the compiled data" — it does not require an empty shell; (ii) the spec itself says the compilation "may not contain the complete collection of data … but instead may include … a settings or configurations file and/or a subset of the application data" — a subset, not emptiness; (iii) O'Farrell/Kirsch/Neil expressly teach the split architecture.
3. "Non-obvious because it must work across multiple operating systems." Multivariate build targets are explicitly the problem both Eteminan and Nigam solve; KSR forecloses "obvious to try all known options."
4. Priority-date attack surface (double-edged). The '231's pre-April-2011 date depends on provisional 61/472,609 supporting claim 1. If it does not, the effective date moves toward Feb. 14, 2012, and the Jun. 2011–Feb. 2012 art becomes available — iBuildApp (Jun. 13, 2011), Anubavam (Oct. 12, 2011), Apps Builder (Feb. 10, 2012), GENWI and MobileAppLoader (Jun. 2011), plus US 2013/0205276 A1 (Media Direct's own later publication) as a possible § 102(b) self-publication. Conversely, the same family IDS cites appsbar's own 2011 marketing ("About Us," 2011; Van Buskirk, Sep. 12, 2011) — if the applicant's system was publicly available before Feb. 14, 2011, a § 102(b) public-use/on-sale theory arises, which is a separate (and riskier, fact-intensive) invalidity theory, not § 103.
5. Secondary considerations (Graham factor 4). No evidence of nexus, unexpected results, copying, industry praise, or long-felt-but-unsolved need is apparent. The strongest objective indicator in the record points the other way: Google Patents lists the patent "Expired – Fee Related," with no litigation or PTAB activity (per the earlier Litigation section) — consistent with limited commercial significance rather than a valuable, unexpected advance. Flag: non-payment of maintenance fees is not legally probative of obviousness; it is only a practical signal.
6. Parallel § 101 exposure (outside § 103, but material to any validity assessment). Claim 1 as reproduced recites generic computing hardware executing a content-configuration and distribution workflow with no asserted technical improvement in computer functioning. Under Alice/Mayo step two, the ordered combination is arguably conventional; the specification's own touted benefits are business/administrative (no programming skill, faster updates, no store re-submission). I raise this only as a risk indicator, since I was not asked to brief § 101 and the record here contains no eligibility analysis.

5. Bottom line and required verification

Assessment: On the record as reconstructed, claim 1 is highly vulnerable to a § 103 challenge, with US 2011/0161912 (Eteminan) as the primary reference and US 2010/0251230 (O'Farrell) and/or US 7,962,762 (Kirsch) supplying the identifier-driven remote-retrieval clause — optionally reinforced by Brisebois, Nigam, Knight, Jain, Loos, Balathandapani, or Neil. The motivation to combine is strong and arises from the references themselves (same field, same non-programmer/cross-platform objective, complementary update-delivery problems) and from KSR design-choice reasoning. Eteminan alone is arguably anticipatory in substantial part; the honest single-reference gap is the shell-plus-identifier runtime fetch.

What must be verified before this becomes an opinion:

1. Certified claim set (all 20 claims) from USPTO PatentCenter/PAIR for 13/396,368 or the granted PDF — I have only secondary-source claim 1.
2. Prosecution history: the applicant's remarks and the Examiner's Reasons for Allowance re Eteminan US 2011/0161912, and whether the same art was applied against 13/396,392 (→ US 8,978,006) and 13/831,155.
3. Eteminan's exact US filing date and application number (I have only its publication date, 2011-06-30, and assignment signing dates of 2009-12-31→2010-02-02, from which I inferred a ~Dec. 2009 filing).
4. Support in provisional 61/472,609 for claim 1 (determines the effective date and whether the Jun. 2011–Feb. 2012 art is available).
5. Abstracts/text of the [title-level] references — Ross 7,716,634, Nigam 2010/0017812, Brisebois 2010/0174974, and the various Neil references — which I could identify from the front page but could not retrieve within the search budget.
6. Corroboration (archive captures, product literature, source code) for the third-party NPL candidates (Whoop, AppBreeder, Yapper, Illumination Software Creator) before using them.

Sources relied on: the authoritative Google Patents record supplied (https://patents.google.com/patent/US8261231/en); FreePatentsOnline front-page reference list (https://www.freepatentsonline.com/8261231.html); Eteminan publication (https://patents.google.com/patent/US20110161912, https://www.freepatentsonline.com/8719776.html); US 8,978,006 IDS/NPL list (https://patents.justia.com/patent/8978006); the Ask Patents claim-1 reproduction (https://patents.stackexchange.com/questions/1942/any-prior-art-on-mobile-app-code-generators); EPO search reports citing the '231 (https://patentimages.storage.googleapis.com/fb/6d/cb/e6a9a8bf34e07d/EP3342145A4.pdf).