US 6594348

I'll search for the specific patent number in USPTO and CAFC contexts.

Let me run a couple more targeted searches to confirm litigation/docket status and current ownership.

US Patent 6,594,348 B1 — Summary

Searches run: (1) USPTO/Google Patents record for US 6,594,348 B1; (2) CAFC 2026 docket/appeal search for the number; (3) litigation/docket and reassignment searches. I did not find any CAFC 2026 docket entry, appeal, IPR, or district-court case naming US 6,594,348. I am flagging that as an absence-of-evidence result rather than a confirmed negative — I do not have authoritative access to a live PACER/CAFC docket feed, so I cannot rule out a case I simply could not retrieve.

Bibliographic data

Sources: https://patents.google.com/patent/US6594348/en ; https://portal.unifiedpatents.com/patents/patent/US-6594348-B1 ; https://patents.justia.com/patent/6594348

Abstract (as granted)

The invention relates to a voice browser (110) arranged at a server (120) connected to the Internet (130) and responsive to DTMF tones received from a telecommunications network (150). The voice browser responds to different sets of predetermined DTMF tones — one set dedicated to voice-browser functions, another dedicated to HTML application functions — and synchronises the DTMF tones that can be accepted for a given browsed part of an HTML page.

Claim 1 — plain-language overview (independent, apparatus)

A voice browser hosted on an Internet-connected server that responds to DTMF tones arriving from a telephone network, comprising:

• An object model built from the elements of a retrieved HTML page, which defines navigation positions (nodes) within that page;
• Audio means for playing an audio stream derived from an HTML-page element;
• A voice browser controller that controls browser operation;
• A dialogue state structure — multiple states with transitions — storing the text and audio objects to be output to the audio means;
• A dialogue controller that runs the dialogue against that state structure and, on receiving an interpreted DTMF tone, sends an event to the voice browser controller.

The two-set split is the core: if the event carries a DTMF tone from a first predetermined set, the controller performs the associated browser function and decides which state (in the same dialogue state structure, or in a second one tied to a second retrieved HTML page) the dialogue resumes from after the function executes. If the event carries a tone from a second predetermined set, the controller passes the tone through to the HTML application itself (the "access key" concept). Each state is tied to a corresponding position in the object model, and the browser includes synchronisation means that keep the dialogue state structure, relative to its current state, aligned with a new position in the object model after the function is carried out.

Claim 18 — plain-language overview (independent, method)

The method counterpart, performed at such a voice browser:

1. Retrieve an HTML page in response to a DTMF tone interpretation;
2. Create an object model of the page's elements;
3. Derive states, each holding a reference to an object-model position plus at least one input and/or output;
4. Build a dialogue state structure incorporating those states and inter-state transitions;
5. Run the dialogue against that structure;
6. On an interpreted DTMF tone in a state, raise an event to the voice browser controller;
7. If the tone is from a first predetermined set — control the associated browser function and determine which state (of this structure or of a second structure for a second HTML page) the dialogue resumes from;
8. If the tone is from a second predetermined set — direct the interpreted tone to the HTML application; and
9. Synchronise the dialogue state structure, relative to its current state, with a new position in the object model.

Claimed key assignments (from the specification's table, referenced by dependent claims)

• Keys 1–6: reserved for the HTML application (Access Key binding) — the "second set" (claim 26)
• 7: Back (claims 8–12); 8: Pause (claim 15); 9: Forward (claims 13–14)
• 0: Go to user start page (claim 17); *: Go to voice browser system menu (claims 6–7); #: Select active element (claim 16)

Notes and uncertainties

• No CAFC 2026 activity found. My searches returned no Federal Circuit 2026 appeal, panel decision, or docket referencing 6,594,348. Given the patent expired for non-payment of maintenance fees on/around 2020-02-22, active enforcement litigation is unlikely, but I cannot positively exclude a case based on the searches performed.
• Do not confuse with adjacent numbers. The prior art and citing-document lists include US 6,594,484 (Hitchings, "Automated access by mobile device…") and US 6,594,384-type neighbors; those are different patents. I did not substitute them for 6,594,348.
• Cited prior art in the patent itself includes WO 1997/032427 and US 5,953,392 (both Netphonic Communications), US 5,884,262 (Bell Atlantic), US 5,761,280 (8×8, Inc.), GB 2,317,070 (IBM), EP 0 847 179 A2 (AT&T), and US 6,430,624 (Air2Web) — relevant if you are assessing validity or freedom-to-operate.
• Everything above is drawn from the granted US text and its public bibliographic record; the "Expired – Fee Related" status and 2004 HP reassignment come from the Google Patents/Unified Patents records and should be verified against USPTO Patent Center (https://patentcenter.uspto.gov) for any legal conclusion.

I'll research litigation involving US patent 6594348. Let me search multiple sources.

Let me check the Unified Patents portal and other litigation sources.

Let me check Docket Alarm, CourtListener, and Google Patents litigation tabs specifically.

Summary of Findings: US Patent No. 6,594,348

Patent identity (confirmed, literal):

• US 6,594,348 B1 — "Voice browser and a method at a voice browser"
• Application No. 09/914,234; PCT/SE2000/000319; priority 1999-02-24; filed 2000-02-22; granted 2003-07-15; expired 2020-02-22 (Expired – Fee Related)
• Inventors: Hans Bjurstrom, Christer Granberg, Jesper Hogberg, Berndt Johannsen, Scott Mcglashan
• Original assignee: Pipebeach AB; current assignee: Hewlett-Packard Development Co. LP (HP acquired PipeBeach AB in 2003)
• 26 claims; CPC H04M3/4938 (voice browser / VoiceXML); 8 cited patent references; ~124 citing documents

Litigation: I found NO evidence of any litigation involving US 6,594,348.

The sources I was able to reach before hitting my search limit showed:

1. Google Patents (the authoritative full-text source provided) — the record contains no litigation section and no litigation events for this patent. Google Patents populates a "Litigation" block when district-court or PTAB cases are associated with a patent; none appears.

2. Unified Patents Portal entry for US-6594348-B1 — the captured record lists only bibliographic data, assignees, and cited-by references. It reports PVIX: 0 and RNIX: 0 (Unified's own Patent Value / litigation-related index scores), which is consistent with no litigation activity, and shows no case list. It also notes lifetime renewal fees: $0, consistent with the patent lapsing without enforcement activity.

3. No district-court or Federal Circuit case referencing 6,594,348 surfaced. Important caution: several search hits mentioning a "'434 patent" refer to an unrelated patent — the Purcell '434 (bus/carry-save-stage technology, asserted in Advanced Micro Devices, Inc. v. [Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.), No. CV-08-0986-SI, N.D. Cal.). That is a different patent number and must not be conflated with US 6,594,348.

Caveats / limitations:

• My live searches were cut off before I could directly query PACER, CourtListener/RECAP, and the Unified Patents litigation caselist (https://portal.unifiedpatents.com/litigation/caselist) for this specific number. If a definitive negative is required, those should be run directly.
• The patent expired in 2020, was never a subject of a reported suit in the accessible records, and its owner (HP) is a large operating company rather than a litigation-frequent NPE — all of which is consistent with the absence of litigation.
• I did not find any PTAB proceeding (IPR/PGR) or ITC action involving this number either.

Bottom line: Based on the available evidence, there is no known litigation involving US 6,594,348. I cannot state this with absolute certainty because I was unable to complete direct PACER/CourtListener and Unified litigation-caselist queries; if absolute confirmation is needed, those databases should be checked by exact patent number (6,594,348 / 6594348), and results for other "'434" patents should be excluded.

I'll verify the structured-data baseline with targeted searches before writing anything.

No proceedings surfaced. Let me run a couple more targeted checks to be confident this isn't a search-coverage gap.

One more check specific to litigation/appeal dockets, since those often surface a PTAB link.

PTAB Proceedings Analysis — US Patent 6,594,348

Verification basis: USPTO ODP AIA trial feed (structured "PTAB proceedings on file" block) = zero records. Corroborated by targeted web searches across PTAB case numbers, the patent number, the assignee (Pipebeach AB / Hewlett-Packard Development Co. L.P.), and third-party litigation trackers. No AIA trial proceeding — IPR, PGR, or CBM — was identified on any independent source.

Proceedings overview

Total AIA trial proceedings: 0 — no IPRs, no PGRs, no CBMs, no derivation proceedings, and no Federal Circuit appeals arising from a Board trial. Breakdown by status is therefore N/A across the board (0 active, 0 invalidated, 0 sustained, 0 settled, 0 institution-denied).

The defensive posture this gives a defendant is not the usual "survived N IPRs" story. It is a mootness story: the patent is expired. Per the Google Patents record, priority date 1999-02-24, filing date 2000-02-22 (national phase of PCT/SE00/00319, US app. 09/914,234), granted 2003-07-15, anticipated expiration 2020-02-22, legal status "Expired - Fee Related." The patent owner never needed to defend these claims at the Board because the enforcement window closed first.

Bottom line for a defendant: US 6,594,348 expired on 2020-02-22 and has never been tested at the PTAB. There is no FWD to quote, no canceled claim to hide behind, and no IPR estoppel to worry about — because there is no IPR. Your defense is not "the claims are invalid"; it is "the patent is dead and the § 286 damages lookback reaches no act of infringement." If a demand letter cites this patent today, the sender is either using the number as filler or has not done a term calculation.

Proceeding-by-proceeding detail

No proceedings to report. I am not going to manufacture case numbers, panels, or dispositions for proceedings that do not exist.

• Type: N/A
• Filed: N/A
• Status: N/A
• Judge panel: N/A
• Petition grounds: N/A
• Institution decision: N/A
• Final Written Decision: N/A
• Settlement / termination: N/A
• Appeal: N/A
• Defensive value: N/A

Why the zero is structural, not accidental

Three features of this patent explain why no AIA vehicle was ever a realistic fit:

1. It is a pre-AIA patent. Filed 2000-02-22 with an effective filing date of 1999-02-24, it predates the AIA's 2013-03-16 cutoff. Post-Grant Review (§ 321) is categorically unavailable — PGR reaches only patents with an effective filing date on or after 2013-03-16.
2. CBM was a poor fit and is now sunset. The claims (see below) are directed to a voice browser converting HTML to audio over a telecom network — an interactive-voice-response/telecom networking invention, not a "financial product or service" under AIA § 18(d)(1). CBM review also sunset on 2020-09-16, months after this patent expired.
3. IPR was legally available but commercially pointless. An expired patent remains technically reviewable, but the patent owner cannot amend claims in an expired patent, and with the infringement window closing there was no accused product to defend. No rational petitioner spends IPR fees on a patent whose damages tail has run out.

Even the accused-infringer track is empty. The patent was assigned to Hewlett-Packard Development Company, L.P. on 2004-12-06 following HP's July 2003 acquisition of Pipebeach AB, and the public record shows it used as prior art (pervasively — see below) rather than as an assertion vehicle. Its forward-citation footprint is large (41 "cited by" entries in the primary list, expanding to 124 in the extended family view, spanning Parus Holdings, Phoenix Solutions/Nuance, Kirusa, Accenture, and others), which is the profile of a foundational reference, not a litigated patent.

Strategic summary

Claim status across all 26 claims: UNTESTED — and now unreachable. Claims 1–17 are apparatus claims to the voice browser; claims 18–26 are the corresponding method claims. Claim 1 requires, among other things, an object model over a retrieved HTML page, a dialogue state structure, a dialogue controller issuing events to a voice browser controller, a first predetermined set of DTMF tones mapped to browser functions and a second predetermined set mapped to the HTML application (the "access key" split), and synchronisation means tying the current dialogue state to a position in the object model. Claim 3 adds the look-up table; claims 18–26 parallel the method. None of these claims has ever been construed by the PTAB, canceled, or sustained — there is no claim-level record to report, and I will not invent one.

Estoppel landscape: clean, because there is nothing to be estopped by. § 315(e)(2) estoppel is triggered only by a petitioner's own IPR that reaches a final written decision. Here no petitioner exists, so no party — and no privy of any party — carries IPR estoppel on this patent. In the abstract, every prior-art ground that a defendant could raise is still available. In practice, the more important point is that the patent expired 2020-02-22, so the § 286 six-year damages lookback (which would reach back only to 2026-09-28 — a date after expiry) captures no period of infringement at all. There is no past-damages exposure to defend, and no injunction is available against an expired patent.

Pattern signals: a flat line. No petitioner filed once, let alone multiple times. No patent owner appeal to the Federal Circuit exists because there is no FWD to appeal. Unified Patents did not file a challenge — it maintains a passive profile page for the patent at https://portal.unifiedpatents.com/patents/patent/US-6594348-B1 but shows no proceeding, consistent with the patent's age and expiry. The only "chain" here is the corporate one: Pipebeach AB → Hewlett-Packard Development Company, L.P. (2004-12-06). The patent's real significance today is as § 102/§ 103 art against later voice-browser and multi-modal patents — which is exactly how the citing families (Parus, Phoenix/Nuance, Kirusa, Accenture, Gula) treat it.

Recommended next steps

If you are a defendant being asserted against: the analysis does not depend on any FWD, because none exists. Establish the dates and you are done:

• Expiry: 2020-02-22 (20 years from the 2000-02-22 filing date). Confirm the term adjustment calculation on the face of the patent and in Patent Center — if a § 154(b) adjustment is asserted, it cannot extend the term meaningfully here.
• § 286 lookback: any complaint filed today (2026-09-28) reaches back only to 2020-09-28. The patent was already expired. No compensable infringement period exists.
• No AIA trial record to rely on or rebut: there is no FWD, so no issue-preclusion or § 315(e)(2) estoppel argument is in play in either direction. If opposing counsel represents otherwise, ask them for the proceeding number.
• Verify independently before responding to a demand: USPTO PTAB E2E (https://ptacts.uspto.gov/ptabweb) and Patent Center (https://patentcenter.uspto.gov) for the application number 09/914,234; Google Patents legal-status tab at https://patents.google.com/patent/US6594348/en.

If active proceedings are alleged: they are not. There is no institution deadline, no oral hearing date, and no statutory FWD due date to calendar, because no petition was filed. Treat any such claim as a factual error by the sender.

The absence as signal: I'll note this carefully, because the framing in the task prompt ("well-asserted patents eventually attract IPRs") does not cleanly apply here. The zero is not evidence that the patent was too strong to challenge — it is evidence the patent was never seriously asserted, and that by the time the AIA trial regime matured (2012 onward), the patent had roughly eight years of term left and no products worth defending. A defendant should not read the empty PTAB docket as "hardened patent." Read it as "abandoned patent."

Caveats and confidence

• High confidence, no PTAB activity. The ODP structured feed is empty and four independent search passes found nothing. I found no FWD, no institution decision, no termination, and no CAFC appeal to cite — and I have deliberately cited none rather than fabricate a proceeding number or panel.
• Coverage gap I cannot fully close. The ODP AIA feed covers trial proceedings. Ex parte reexamination (which is not an AIA trial and does not appear in that feed) and any pre-AIA interference history would live in separate PTO systems. My searches surfaced no reexamination certificate, but absence of search hits is weaker evidence than an empty ODP feed. If that distinction matters for your matter, pull the full file history via Patent Center for app. 09/914,234.
• One minor record discrepancy worth noting: the Unified Patents portal lists an "Application Date" of 2001-08-24 (the § 371 national-phase entry date), while Google Patents shows the 2000-02-22 PCT international filing date and the ODP record shows filing date 2000-02-22. For term and § 286 purposes, the controlling date is the 2000-02-22 international filing date, giving expiry 2020-02-22 — which is what the record states. I flag this only so it isn't misread as an extension of term.

I'll reconstruct the assignment chain for US 6,594,348 by querying the USPTO Assignment Center records and cross-referencing ownership events.

Let me search for the specific recorded assignment details and any downstream transfers.

Assignment & Ownership Analysis — US 6,594,348 B1

Data-retrieval caveat (read first): I reached my search-step limit before I could open the USPTO Assignment Center abstract-of-title page for this patent and capture the reel/frame numbers, execution dates, and correspondent-of-record for each conveyance. The two conveyance events below are confirmed by the Google Patents "Legal Events"/reassignment record contained in the authoritative full text, but the reel/frame and correspondent fields are not retrieved — I am labeling them as such rather than inventing them. Verify at the Assignment Center search page: https://assignmentcenter.uspto.gov/ (search by patent number 6594348).

Inventors

Basis: all five are named as assignors on the inventor→PipeBeach reassignment of record (Google Patents legal events, recorded 2001-09-25), which is the standard evidence that the inventors were the Swedish company's employees and that the invention was a company work product. PipeBeach AB was founded by Katja Bergman (not a listed inventor). McGlashan's CTO role is corroborated by contemporaneous press reporting of the HP acquisition (https://www.infoworld.com/article/[2231133](/patent/2231133)/hp-buys-swedish-voicexml-company.html).

Unusual-pattern check — not present. There is no exit-within-12-months pattern. Inventors were still with the company (as employees) until the 2003 HP acquisition, >4 years after the 1999 priority filing; press reports state all Stockholm staff agreed to join HP at that time. This is a normal corporate work-product chain, not a pre-fire-sale inventor exodus.

Original assignee

PipeBeach AB (Stockholm, Sweden). A venture-backed software company founded in the late 1990s that built VoiceXML-based voice-browser / interactive-voice products — SpeechWeb and SpeechWeb Portal — which are the products embodying the claimed voice-browser-with-DTMF sets. Primary line of business: speech/telephony application-platform software for telecom operators. It shipped product (SpeechWeb platform) and, per HP, was assessed as roughly two years ahead of HP's own in-house development.

• Current status: acquired / dissolved as a standalone entity. HP announced the acquisition on 2003-07-23 and integrated PipeBeach's VoiceXML products and staff into the HP OpenCall telecommunications software suite (https://www.lightreading.com/business-management/hp-acquires-pipebeach ; https://www.cnet.com/tech/tech-industry/hp-grabs-maker-of-voice-portal-software/). The patent's US title later passed to Hewlett-Packard Development Company, L.P. (recorded 2004-12-06). No bankruptcy, no wind-down sale of the portfolio is evidenced.

Assignment timeline

Two post-filing conveyances are of record in the retrieved sources.

• Execution date not retrieved / recorded 2001-09-25 — Reel not retrieved / frame not retrieved

  • Conveyance: Assignment of assignors' interest (inventor→company)
  • Assignor: Hans Bjurström; Christer Granberg; Jesper Högberg; Berndt Johannsen; Scott McGlashan
  • Assignee: PipeBeach AB
  • Correspondent: not retrieved
  • Context: Routine employee invention assignment, recorded on entry of the PCT case into the US national phase (US 09/914,234, § 371 national-stage entry 2001-08-24), not a third-party transfer. No recurrence flag — correspondent data unavailable.

• Execution date not retrieved (HP deal announced 2003-07-23) / recorded 2004-12-06 — Reel not retrieved / frame not retrieved

  • Conveyance: Assignment
  • Assignor: PipeBeach AB
  • Assignee: Hewlett-Packard Development Company, L.P.
  • Correspondent: not retrieved
  • Context: Acquisition — an operating company (HP) absorbing an operating company (PipeBeach) and its IP as part of an announced M&A transaction; not a transfer to an asserter or shell entity.

Chain terminates at HP. No further assignment, security interest, license, merger, or name-change record appears in the Google Patents legal-events block or the Unified Patents record (https://portal.unifiedpatents.com/patents/patent/US-6594348-B1), which still lists Hewlett-Packard Development Co. LP (parent HP Inc.) as current assignee. If the Assignment Center shows any post-2004 entry for this patent, that would be new information not reflected in the sources I could reach.

Bibliographic discrepancy to flag: Google Patents lists the US filing date as 2000-02-22 (PCT filing date), while Unified Patents records an application date of 2001-08-24. This is the normal § 371 national-phase artifact (PCT filing date vs. US national-stage entry date), not a contradiction in ownership.

Timeline diagram

timeline
    title Ownership of US 6594348
    1999 : Inventors file the application
    2001 : Inventors assign to PipeBeach AB
    2003 : US patent granted
         : HP acquires PipeBeach AB
    2004 : PipeBeach AB assigns to HP
    2020 : Patent expires for fee non-payment

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The only transfer is PipeBeach AB → Hewlett-Packard Development Company, L.P. (recorded 2004-12-06). The assignee is a large operating corporation, not an "IP/Licensing/Holdings/Ventures" LLC. No Delaware/Texas single-purpose vehicle appears.

2. Known asserter in the chain — not present. Neither PipeBeach AB nor HP matches any listed NPE (Acacia, Marathon, IV, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, etc.). Unified Patents' record for this number shows no case list and no litigation index activity.

3. Repeat correspondent across the chain — unclear / not retrieved. I could not retrieve the correspondent-of-record for either recording, so recurrence cannot be assessed. This is a retrieval gap, not a negative finding.

4. Cascading transfers — not present. Only two records, spanning 2001-09-25 → 2004-12-06 (~39 months), and they are unidirectional inventor→company→acquirer. No chained LLC hops, no shared-correspondent cluster.

5. Pre-litigation transfer — not present. There is no infringement suit naming this patent in the accessible records (consistent with the prior litigation section), so there is no pre-suit assignment to time against. The final assignment (2004) precedes any hypothetical assertion by ~16 years.

6. Bankruptcy fire-sale — not present. PipeBeach was an acquired going concern (2003 HP deal), not a Chapter 7/11 debtor. No court-supervised portfolio sale.

7. Privateering — not present. This is a genuine upstream acquisition (HP bought the company and integrated its product into HP OpenCall), not an operating company parking patents with an NPE to assert against rivals. No SEC 8-K/10-K disclosure of NPE-directed assertion surfaced.

8. Defensive aggregator — not present. The chain does not terminate at RPX, AST, LOT, Unified, or OIN.

Verdict

Defensive / non-asserting — nearest available label, with a taxonomy caveat flagged below.

The recorded chain is a plain operating-company ownership path: inventors → PipeBeach AB (recorded 2001-09-25) → Hewlett-Packard Development Company, L.P. (recorded 2004-12-06), with no shell entity, no known asserter, no cascading LLC hops, no bankruptcy sale, and no litigation anywhere in the record. HP held the patent to anticipated expiry on 2020-02-22 and ultimately lapsed it for non-payment of maintenance fees (Unified: lifetime renewal fees $0), which is the practical signature of a patent that was never monetized by assertion.

Caveat / contradiction to flag: the requested verdict taxonomy has no clean slot for "owned by an operating company, embodied in a shipping product, and never asserted." "Operating-company assertion" requires actual suits against competitors (none exist), and "Defensive / non-asserting" is defined by termination at a defensive aggregator (not the case). I selected Defensive / non-asserting because the operative fact — the patent was held by an operating company and never used to sue — is the substantive match, but the label is imperfect. If the reviewer prefers strict definitions, the honest classification is that this patent shows no NPE pattern at all.

Verification link: https://assignmentcenter.uspto.gov/ (search patent number 6594348). Recommend pulling the reel/frame and correspondent for both conveyances to close the one open field in this analysis.

I'll verify the USPTO record and each cited reference before building the § 102 analysis.

Now let me verify the remaining four cited references and the USPTO record.

I completed searches for the USPTO record and five of the eight cited references before hitting my tool-call limit. Below I separate (a) what the authoritative patent text and search results establish, from (b) what I could not directly verify. Per your strict rule, all identifiers are reproduced literally.

1. US 6,594,348 B1 — record confirmation (literal ID: 6594348)

Confirmed sources: Google Patents (https://patents.google.com/patent/US6594348/en), Unified Patents portal (https://portal.unifiedpatents.com/patents/patent/US-6594348-B1), RPX Insight (https://insight.rpxcorp.com/patent/[US6594348B1](/patent/US6594348B1)), uspto.report (https://uspto.report/patent/grant/6594348).

Literal-reading flag (no correction applied): granted independent claim 1 recites "each of said states is associated with a corresponding position in said object mode" (not "object model"). I am reproducing the term as printed and not auto-correcting it.

Do-not-confuse list: the record is dense with near-numbers that are different patents — US 6,594,484, US 5,953,392, US 5,884,262, US 5,761,280, US 6,230,173, US 6,430,624, and the unrelated "'434" patent (bus/carry-save stage, AMD v. Samsung, N.D. Cal.). None is substituted for 6594348.

2. What a § 102 reference would have to disclose

Because the priority date (1999-02-24) predates the AIA, pre-AIA § 102 governs. For US 6,594,348 the critical dates are:

• § 102(b) bar date ≈ 1999-02-22 (one year before the 2000-02-22 U.S./international filing date; foreign priority cannot be used to swear behind a § 102(b) bar).
• § 102(a) invention date = presumptively 1999-02-24 (SE priority).
• § 102(e) = a granted U.S. patent whose application was filed before 1999-02-24.

All references dated 1996–1998 below are § 102(b) art (all are >1 year before 1999-02-22), and several are also § 102(e) art.

To anticipate claim 1 or claim 18, a single reference must disclose all of:

1. a voice browser at an Internet-connected server, DTMF-responsive;
2. an object model of HTML-page elements defining navigation positions;
3. a dialogue state structure (finite-state machine) with states + transitions, each state referencing an object-model position;
4. a dialogue controller emitting an event carrying an interpreted DTMF tone;
5. a first predetermined set of DTMF tones → browser functions + control of where the dialogue resumes;
6. a second predetermined set of DTMF tones → passed through to the HTML application ("access keys"); and
7. synchronisation means aligning the current state with a new object-model position.

My assessment (flagged as analytical, not an examiner's rejection): none of the eight cited references is known to me to disclose all seven elements, so none is a clean § 102 anticipation of claims 1/18. The strongest § 102 pressure points are US 5,884,262 and US 5,953,392 / WO 97/32427, described below.

3. The eight cited references (§ 102 analysis)

3.1 US 5,884,262 A — strongest § 102(b) candidate

• Full citation: Wise, L.H.; Mavrotheris, E.; Curry, J.E., "Computer network audio access and conversion system," US 5,884,262 A, Appl. No. 08/623,103; assignee Bell Atlantic Network Services, Inc.
• Dates: filed 1996-03-28; granted 1999-03-16.
• Description: Telephone user calls in and requests documents via DTMF or voice. A Parser 230 "dynamically analyzes the structure and contents of the downloaded file" — determines title, finds tables, marks occurrences of hyper-text links, distinguishes images, finds lists, detects audio/video — then routes segments (text-to-speech, audio player) to the user. Crucially, the disclosure states the system has "a native command capability which allows the system to act independently of the accessed document contents to replay a document or carry out functions similar to those available in conventional web browsers." (https://patents.google.com/patent/[US5884262A](/patent/US5884262A)/en)
• § 102 mapping: Potentially anticipates the structural-analysis + dual command-source concepts: claim 1 (object model built by parsing HTML; audio means; browser controller with native commands vs. document-content commands), claim 3-type structural mapping, claims 8/9 (replay/back of a document = "revert the playing"), claim 13, claim 16 ("press 1 to indicate the selection of a hyper-text link"), claims 18, 22, 24, 26. It is the closest single reference to the two-set idea (browser-native commands "independent of the document contents" vs. document/link commands).
• Gap for the patentee: US 5,884,262 does not, on the passages retrieved, describe a finite-state dialogue structure with states each referencing an object-model position, nor a specific first/second predetermined DTMF key-set split with resume-state control. So it likely supports § 103 rather than clean § 102.

3.2 WO 97/32427 A1 and 3.3 US 5,953,392 A — the Netphonic family

• Full citations: (a) WO 97/32427 A1, Int'l App. PCT/US97/03329, Int'l filing 1997 (published 1997-09-04); (b) US 5,953,392 A, Rhie, K.H.; Kwan, R.J.; Olsen, L.E.; Hahn, J.S., "Method and apparatus for telephonically accessing and navigating the internet," Appl. No. 08/609,699; assignee Netphonic Communications, Inc.
• Dates: US filed 1996-03-01; granted 1999-09-14. (Flag: Unified Patents lists the US-5,953,392-A priority date as 1996-02-29; Google Patents lists 1996-03-01. Minor discrepancy — both are § 102(b) art.)
• Description: The WO abstract/spec: "a method for accessing and browsing the internet through the use of a telephone and the associated DTMF signals … converts the information content of a web page from text to speech … signals the hyperlink selections of a web page in an audio manner … allows selection of the hyperlinks through the use of DTMF signals as generated from a telephone keypad." The reference also describes an "HTree Generator/Web browser" producing a tree of the page.
• § 102 mapping: The HTree hierarchy is arguably the "object model." Maps to broad elements of claims 1 and 18 (DTMF voice browser; text-to-speech; DTMF hyperlink selection) and to claim 26 (keypad selection of links). Weak/absent on: dialogue state structure with per-state object-model references, the first-set/second-set split, and synchronisation means.
• Note: WO 97/32427 and US 5,953,392 are the same disclosure; citing both is a family pair, not two independent teachings.

3.4 US 5,761,280 A — 8×8

• Full citation: Noonen, M.; Deierling, K.; Barraclough, K.; Martin, B.R.; Sing, Y.; Parkinson, J.L., "Telephone web browser arrangement and method," US 5,761,280 A, Appl. No. 08/706,486; assignee 8×8, Inc.
• Dates: filed 1996-09-04; granted 1998-06-02.
• Description: An interface (memory + processor) connected to a telephone and a display: receives a first DTMF code to load a Web browser, receives a second DTMF code and converts it into a Web browser command using an "interpretation protocol," then executes the command. Figs. 2–3 show keypad maps (1–9 → menus; *,0,# → menu/select/protocol change).
• § 102 mapping: Potential anticipation of the DTMF-to-browser-command conversion concept underlying claims 1 and 18, and of the keypad-command layout in claims 6, 7, 16, 22–24, 26. Significant gap: the 8×8 system is a local appliance with a display (PSTN-side), not a voice browser at an Internet-connected server converting HTML to audio; and it has no object model / dialogue state structure / synchronisation means. Anticipation of claims 1/18 is therefore unlikely.
• Family (for accuracy, not prior art): continuations US 6,133,940 and US 6,282,272.

3.5 GB 2 317 070 A — IBM

• Full citation: "Voice processing/internet system," GB 2 317 070 A; applicant International Business Machines Corporation.
• Dates: filed 1996-09-07; published 1998-03-11.
• Description: A voice-processing system that interfaces a voice-processing platform with the Internet (telephony channel + voice resources such as speech recognition/response). Confirmed as a citation to US 6,594,348 via Google Patents' reverse-citation listing (e.g., EP0878948B1 cites "GB2317070A … Voice processing/internet system").
• § 102 mapping: Relevant to the environment elements of claims 1 and 18 (voice processing on a telecommunications network with Internet access). Weak on anticipation: I could not retrieve the specification text, and nothing in the available abstract-level material shows the object model, dialogue state structure, the two DTMF sets, or synchronisation means. Treat as § 103 background, not § 102 anticipation.

3.6 EP 0 847 179 A2 — AT&T

• Full citation: "System and method for voiced interface with hyperlinked information," EP 0 847 179 A2; applicant AT&T Corp.
• Dates: filed 1996-12-04; published 1998-06-10.
• Description: A voiced (speech/telephone) interface for navigating hyperlinked information — i.e., an HTML/hypertext-to-voice browser. (I could retrieve the bibliographic entry from the patent's own citation table but not the EP specification text.)
• § 102 mapping: Relevant to the broad "voice browser for HTML/hyperlinked content" elements of claims 1 and 18; background for claims 25/17 (start page / navigation). On the available record I cannot map it to the object model, dialogue state structure, two-set DTMF split, or synchronisation means — § 103 background, not § 102 anticipation.

3.7 US 6,230,173 B1 — Microsoft

• Full citation: "Method for creating structured documents in a publishing system," US 6,230,173 B1; assignee Microsoft Corporation.
• Dates: filed 1995-07-17; granted 2001-05-08.
• Description: Structured-document authoring/publishing (document structure, elements, hierarchy). It is a likely § 102(e) reference (application filed 1995-07-17, well before 1999-02-24).
• § 102 mapping: Potentially relevant only to the "object model comprising elements defined in a … page" and document-structure elements of claims 1, 4, 18. It contains nothing on DTMF, telephony, voice browsers, dialogue state structures, or browsers — so it cannot anticipate claims 1 or 18. Best characterized as a § 103 supporting reference for the object-model concept (or an IDS citation).

3.8 US 6,430,624 B1 — Air2Web — ⚠️ does not qualify as § 102 prior art on its face

• Full citation: "Intelligent harvesting and navigation system and method," US 6,430,624 B1; assignee Air2Web, Inc.
• Dates: filed 1999-10-21; granted 2002-08-06.
• ⚠️ Critical flag: the filing date (1999-10-21) is after the 1999-02-24 priority/invention date. On the face of the record it is therefore not § 102(a), § 102(b), or § 102(e) prior art against US 6,594,348 (it could only qualify if it claims an earlier provisional/priority benefit that I could not verify — my search for its specification was cut off). Its appearance in the citation list is most consistent with a background/IDS citation, not an anticipation reference. Do not treat it as § 102 art without first checking its priority chain on the face of the patent.

4. Bottom line

• US 6,594,348 B1 is confirmed present in the USPTO/Google Patents record (App. 09/914,234; 26 claims; Pipebeach AB → HP).
• Eight patent references are cited against it: US 5,884,262; US 5,953,392; WO 97/32427; US 5,761,280; GB 2 317 070 A; EP 0 847 179 A2; US 6,230,173; and US 6,430,624.
• The two most substantive § 102(b) candidates are US 5,884,262 (Bell Atlantic — parser-based structural analysis of HTML plus an explicit native browser-command capability independent of document contents, the nearest single-reference showing of the two-command-source idea) and US 5,953,392 / WO 97/32427 (Netphonic — DTMF voice browser with an HTree of the page and audio hyperlink selection).
• US 5,761,280 (8×8) and US 6,230,173 (Microsoft) are best viewed as § 103 supporting references (DTMF-to-browser-command conversion; structured document element model) rather than anticipations.
• GB 2 317 070 A and EP 0 847 179 A2 are § 103 background on the retrieved record.
• US 6,430,624 appears to post-date the priority date and therefore not be § 102 prior art at all — the most important single caveat here.
• No single cited reference is known to me to disclose all of the object model, the state-per-position dialogue structure, the two-set DTMF split with resume control, and the synchronisation means; my working conclusion is that the cited art supports § 103 obviousness attacks more than § 102 anticipation of independent claims 1 and 18.

Unverified items I want to flag explicitly: I did not retrieve the full specifications of US 6,230,173, EP 0 847 179 A2, GB 2 317 070 A, or US 6,430,624, nor did I retrieve the USPTO file wrapper / examiner's citations-on-face distinctions, before my search budget ended. Any of the § 102/§ 103 mappings in §§ 3.5–3.8 above should be re-checked directly against those documents and against the patent's front-page "References Cited" and Form PTO-892 at USPTO Patent Center (https://patentcenter.uspto.gov) before being relied upon for a validity opinion.

I'll ground the analysis in the actual prior-art references of record before building the combinations.

Good — I now have the Netphonic and Bell Atlantic references grounded. Let me pull the remaining cited references.

Obviousness Analysis — US 6,594,348 B1 under 35 U.S.C. § 103

Patent: US 6,594,348 B1, "Voice browser and a method at a voice browser" (app. 09/914,234; PCT/SE2000/000319; priority SE 9900652, 1999‑02‑24; granted 2003‑07‑15; expired 2020‑02‑22).
Source of record: https://patents.google.com/patent/US6594348/en

Contradiction flag (per instructions). The "Definitions" block on the Google Patents page describes the synchronisation element as "synchronising said dialogue, with respect to a current state, with a position in said object model," whereas the granted claim 1 reads "synchronising said dialogue state structure, with respect to a current state, with a new position in said object model." The granted claim text governs. This matters because the broader "synchronising said dialogue" phrasing would map even more readily onto the menu-driven art below.

1. The person of ordinary skill (POSITA)

A POSITA at the 1999‑02‑24 priority date would be a software/telecom engineer with a B.S. in EE/CS (or equivalent) plus roughly 2–3 years of experience in interactive voice response (IVR), telephony application development, and HTTP/HTML client-server programming, and would be familiar with: DTMF signalling, text-to-speech (TTS), HTML parsing and hyperlink handling, and finite-state/scripted dialogue modeling. That framing is not contested by the specification — the '348 background itself treats voice browsers, HTML, TTS, IVR menus, and HTML "access keys" as known art.

2. Prior-art references of record and their § 102 footing

All references below are listed on the face of the '348 patent as cited prior art (except where noted), so they were before the examiner.

Reference that is NOT prior art — flag. The '348 record also lists US 6,430,624 (Air2Web). Its cited priority/filing date is 1999‑10‑21, which is after the '348 priority date of 1999‑02‑24. It therefore cannot be used in a § 103 combination. Any analysis that leans on Air2Web for the '348 patent is invalid on its face.

Applicant-admitted prior art. The '348 specification itself concedes: "Such direct access to keys on a keyboard sometimes in the literature referred to as 'access keys'. With the notation of an access key in HTML, an application could assign a key to be directly attached to the application." It also concedes "Tabindex" page elements and "go to a start page" as known. The W3C HTML 4.0 Recommendation (17‑Dec‑1997) defines both ACCESSKEY and TABINDEX. These are admissions against interest that directly support the "second predetermined set of DTMF tones" (access-key passthrough) limitation and claims 6–7, 16, 17, 26.

3. Primary combination: Netphonic (WO 97/32427 / US 5,953,392) + Bell Atlantic (US 5,884,262), optionally + 8×8 (US 5,761,280)

3.1 Claim 1 (apparatus) — element mapping

Conclusion: every element of claim 1 is disclosed or rendered obvious by Netphonic in view of Bell Atlantic.

3.2 Why the combination is motivated (KSR factors)

1. Same field, same problem, same solution family. Both are telephone-access systems that convert HTML to audio and navigate with DTMF over a telecom link. KSR makes combination of references "in the same field of endeavor" addressing the same need obvious.
2. Bell Atlantic supplies the missing functional block with a stated purpose. Bell Atlantic expressly frames its native command capability as letting the system "act independently of the accessed document contents … like conventional web browsers" — which is exactly the claimed first set. Its content/link sub-mode (press 1 to select a hyperlink, content-based navigation) is the claimed second set. Combining a document-content navigation mode with an independent-system-command mode in the same set-top voice browser is not a change in principle of operation; it is the addition of a known subsystem performing its known function.
3. The 12-key keypad constraint is a stated, well-known motivation. The '348 specification itself says "the number of keys of a telephone keypad generally is limited to 12 keys." 8×8 resolves the same problem by partitioning keys: 1–9 to Web-browser pull-down menus, and 0/*/# to "additional menus" and to change the protocol. A POSITA facing collision between browser commands and content selections on 12 keys would partition the keypad into two sets — the claimed architecture — as a predictable design choice.
4. Design incentive to keep the offered keys consistent with the read-aloud fragment. Bell Atlantic's "menus read with an opportunity to select following the speaking of each entry" and its "effect any action possible at that location" supply both the problem and the mechanism that make the claimed synchronisation an obvious engineering goal, not an inventive leap. The '348 specification characterizes synchronisation as a design problem ("how to design a voice browser …"), which is a classic "designer's design choice" under KSR.
5. The prior art supplies the implementation vehicle. Netphonic's HTree cache keyed by URL, and its per-URL HTree entries in the URL list, are a ready-made structure for a node→state index. Claim 3's look-up table is a routine data-structure choice.

3.3 Claim 18 (method)

Claim 18 is the method counterpart and tracks claim 1 step-for-step: retrieve HTML in response to a DTMF interpretation (Netphonic/Bell Atlantic); create an object model (Netphonic's H-tree conversion; Bell Atlantic's parser); derive states each with an object-model reference and input/output (Netphonic CMSI registers + Selection/Goto/Play); build a dialogue structure with transitions; run the dialogue; raise an event on an interpreted DTMF tone; branch by set (Bell Atlantic native commands vs. content actions); synchronise to a new position (Netphonic traversal + URL/HTree index). Same conclusion.

4. Dependent claims

Design-choice overlay: claims 6, 7, 8, 9, 13, 14, 15, 16, 17, 22–26 largely fix which key triggers which already-known function. Under KSR and In re Kuhle-type reasoning, assigning a function to a particular key on a 12-key pad produces no new technical result and would be an obvious design choice; the specification offers no evidence of any unexpected result from the specific assignments.

5. Alternative and back-up combinations

• Combination B — Bell Atlantic (primary) + Netphonic (secondary) + AT&T EP 0 847 179 A2. Bell Atlantic supplies the two command classes ("native command capability" vs. content navigation) and content-based navigation. Netphonic supplies the HTML→tree construction and DTMF hyperlink selection. AT&T supplies the reserved command vocabulary concept ("reserved action words (e.g., commands)") alongside hyperlink words — a direct teaching of maintaining a distinct system-command set while the content vocabulary varies with the page, i.e., the synchronisation goal.
• Combination C — 8×8 (primary) + Bell Atlantic. 8×8 supplies DTMF→browser-command interpretation with keys partitioned between browser menus and "additional menus," but it uses a display and a local interface; Bell Atlantic supplies the server-side HTML→audio rendering, parser, and independent browser-command capability. Motivation: 8×8 explicitly notes the need for "an inexpensive and convenient apparatus and method" to browse without a PC — the same need Bell Atlantic serves — so a POSITA would combine the DTMF-command protocol of 8×8 with the server-side HTML-to-voice architecture of Bell Atlantic.
• Combination D — any of the above + GB 2 317 070 A for hyperlinked voice-menu navigation over the Internet. Caveat: I did not independently verify GB 2 317 070's disclosure; it is offered as a corroborating reference only.
• Not available: US 6,430,624 (Air2Web) — post-dates the priority date; do not use.

6. Where the § 103 case is weakest (candid assessment)

1. The "event" architecture is described at a level of abstraction no reference literally states. Netphonic's CMSI and Bell Atlantic's call manager both function as disclosed, but neither describes a discrete "event with a DTMF interpretation, an object-model reference, a timestamp, and a next-state reference" passed from a dialogue process to a browser process. This is the strongest § 103 rebuttal available to a patent owner, and it turns on (a) how broadly "event" is construed (it is a generic computing term) and (b) whether the combination's ordinary-programming-implementation argument is accepted. It is a foreseeable-architecture argument, and the '348 claims recite no algorithm for it.
2. No single reference discloses a dialogue state structure whose states each hold a pointer into an HTML-derived parse tree, plus a reverse table from nodes to states. This is why the case must be a three-reference combination rather than a two-reference one, and why a patent owner would argue the combination is only "obvious to try" rather than "obvious." The counter is Bell Atlantic's "effect any action possible at that location" plus Netphonic's per-URL HTree index — the functional requirement, if not the vocabulary, is present.
3. File history unknown. The examiner allowed over these exact references. I do not have the '348 file history / reasons for allowance, so I cannot say whether the examiner found a specific teaching lacking — or simply did not perceive the Netphonic + Bell Atlantic + 8×8 combination. Any reexamination/validity opinion should obtain the file wrapper first.

7. Secondary considerations

No evidence of unexpected results, commercial success with nexus, long-felt need, or industry praise appears in the record reviewed. Neutral-to-negative facts: the patent expired for failure to pay maintenance fees (2020‑02‑22); the "previously generated" sections of this analysis found no litigation, PTAB, ITC, or Federal Circuit activity involving 6,594,348; the assignee (HP) is an operating company; and the field (voice/IVR browsing) was evolving rapidly around 1996–1999, with multiple independent teams (Netphonic, Bell Atlantic, 8×8, AT&T, IBM, Air2Web) converging on the same architecture — objective evidence of the predictable, industry-wide nature of the solution.

8. Bottom line

• Claim 1 and claim 18 would have been obvious under § 103 over Netphonic (WO 97/32427 / US 5,953,392) in view of Bell Atlantic (US 5,884,262), with 8×8 (US 5,761,280) supplying the express DTMF key-partitioning motivation, and with the specification's own admissions (HTML "access keys," start pages, 12-key keypad limit) filling the remaining gaps.
• Dependent claims 2–5, 8–17, 19–21 are obvious for the same reasons; claims 8–12, 13–15 rest substantially on conventional audio-stream transport control plus Bell Atlantic's back/forward traversal.
• Claims 6, 7, 16, 17, 22–26 are obvious as design choices over known keypad protocols (8×8) and known IVR/web-browser functions, reinforced by the applicant's own admission of HTML access keys and by Bell Atlantic's "press 1 … to select a hyper-text link" and AIN-designated user home page.
• Do not use US 6,430,624 — it post-dates the priority date and is not § 102/§ 103 art against this patent.

Sources: https://patents.google.com/patent/US6594348/en · https://patents.google.com/patent/[US5953392A](/patent/US5953392A)/en · https://patents.google.com/patent/US5884262A/en · https://patents.google.com/patent/US5761280 · https://patentimages.storage.googleapis.com/06/0c/61/32ed2eb84eebb6/US6133940.pdf · https://patents.google.com/patent/EP0847179A2/en · https://patentimages.storage.googleapis.com/f0/ac/2b/7903321ef2632b/WO1997032427A1.pdf

Caveats: I did not retrieve the '348 file wrapper or the full text of GB 2 317 070 A, US 6,230,173, or US 6,430,624. Claim-construction positions (especially the breadth of "event," "object model," and the § 112(f) "synchronisation means") should be settled before relying on any of this for a validity or FTO opinion.