US 10083154

US Patent 10083154B2, titled "Scalable display of internet content on mobile devices," was issued to SoftView LLC. The inventors listed are Gary B. Rohrabaugh and Scott A. Sherman. The application was filed on November 18, 2016, and the patent was published on September 25, 2018.

The abstract describes a system where mobile devices are enabled for resolution-independent scalable display of Internet (Web) content, allowing Web pages to be scaled (zoomed) and panned for better viewing on smaller screens. This is achieved through software-based processing of original Web content (HTML, XML, CSS) to generate scalable content. This scalable content is then used for rapid rendering, zooming, and panning. The patent also mentions the use of display lists for improved rendering speed and supports context zooms, including tap-based zooms on columns, images, and paragraphs.

A plain-language overview of the independent claims is as follows:

• Claim 1 describes a mobile hand-held device comprising a processor, a wireless communications device, a touch-sensitive display, and flash memory storing instructions for an HTML rendering engine. The device receives and processes HTML documents, including HTML and CSS code, to render a first representation with an interpreted page layout. This processing involves parsing HTML elements, logically grouping content into HTML objects, generating page layout information with bounding boxes for each object, and linking objects to their page layout information. The device then translates this first representation into a scalable vector representation by defining a primary datum for the page layout, an object datum for each HTML object's bounding box, generating a vector between these datums, and creating a reference linking the object to the vector. Finally, it renders this scalable vector representation on the touch-sensitive display using a first scale factor to fit the HTML document across the display's width. The scalable vector representation allows users to view the HTML document at user-defined zoom levels by rendering with different scale factors in response to touch inputs, while preserving the interpreted page layout, functionality, and design of the content.

• Claim 13 outlines a method performed by a mobile hand-held device with a touch-sensitive display and an HTML rendering engine. The method mirrors the functionality described in Claim 1: receiving and processing an HTML document to render a first representation, translating this into a scalable vector representation (including defining datums, generating vectors, and creating references), and rendering the scalable vector representation on the touch-sensitive display at a first zoom level. This method also allows for user-defined zoom levels via touch input, maintaining the original page layout, functionality, and design.

• Claim 20 is directed to a non-transitory computer-readable storage medium storing instructions that, when executed by a processor of a mobile hand-held device, cause the device to perform a method. This method is essentially the same as described in Claim 13, encompassing the receipt, processing, translation (including datum and vector generation), and rendering of HTML documents on a touch-sensitive display with scalable zoom capabilities while preserving the original layout and design.

• Claim 21 describes a mobile hand-held device that receives a document including a plurality of HTML elements and, in response to a user input via its touch-sensitive display, generates a scaled representation of a user-selectable portion of the document. This scaled representation is displayed to fit across the width of the touch-sensitive display. The claim specifies that the scaled representation maintains the original interpreted page layout, functionality, and design of the content, and that various views can be rendered in real-time to effect zooming operations.

• Claim 22 describes a mobile hand-held device for displaying content from a web page on a touch-sensitive display. The device includes a processor and flash memory storing instructions. These instructions enable the device to generate a scalable vector representation of the web page content and, in response to a user input via the touch-sensitive display, scale and pan the web page content at a user-selectable scale factor and pan offset. The device then renders the scaled and panned web page content on the display, preserving the original page layout, functionality, and design.

• Claim 23 describes a non-transitory computer-readable storage medium storing instructions that, when executed by a processor of a mobile hand-held device, cause the device to perform a method. This method involves generating a scalable vector representation of web page content and, in response to a user input via a touch-sensitive display, scaling and panning the web page content at a user-selectable scale factor and pan offset. The method concludes with rendering the scaled and panned content on the display while preserving the original page layout, functionality, and design.

• Claim 25 outlines a method of displaying content from a web page on a mobile hand-held device with a touch-sensitive display. The method involves generating a scalable vector representation of the web page content. In response to a user input via the touch-sensitive display, the web page content is scaled and panned at a user-selectable scale factor and pan offset. Finally, the scaled and panned web page content is rendered on the touch-sensitive display, ensuring that the original page layout, functionality, and design are preserved.

A search of the CAFC 2026 dockets did not yield any direct litigation for patent 10083154 in the provided scheduled cases for May 2026.

Known litigation involving US patent 10083154 includes one district court case and one PTAB (Patent Trial and Appeal Board) case.

1. District Court Case:

   • Plaintiff(s): SoftView, LLC
   • Defendant(s): [[Samsung Electronics Co.](/litigations/by-defendant/Samsung%20Electronics%20Co.), Ltd.](/litigations/by-plaintiff/Samsung%20Electronics%20Co.%2C%20Ltd.) and Samsung Electronics America, Inc.
   • Jurisdiction: Eastern District of Texas
   • Case Number: 2:25-cv-00246
   • Filing Date: February 28, 2025
   • Outcome or Current Status: Active; a complaint for patent infringement has been filed.

2. PTAB Case:

   • Plaintiff(s) (Petitioner): Unified Patents
   • Defendant(s) (Patent Owner): SoftView LLC
   • Jurisdiction: Patent Trial and Appeal Board (PTAB)
   • Case Number: IPR2026-00281
   • Filing Date: 2026 (the specific filing date for the petition is not readily available, but the case number indicates a filing in 2026)
   • Outcome or Current Status: Pending.

Proceedings overview

One AIA trial proceeding is on file for US patent 10083154, with a status of Pending. This means the patent's claims are currently undergoing review, and a defensive posture cannot be fully determined until the institution decision and any subsequent Final Written Decision.

IPR2026-00281 — Google LLC et al. v. SoftView LLC

• Type: Inter Partes Review
• Filed: 2026-03-05
• Status: Pending. This proceeding is active and has not yet reached a final institution decision or a Final Written Decision.
• Judge panel: Not yet publicly available in the current phase of the proceeding.
• Petition grounds: The petition challenged claims 1-12 of U.S. Patent No. 10,083,154, asserting unpatentability under 35 U.S.C. § 103 (obviousness) in view of various combinations of prior art, specifically:
  • Claims 1-12 as obvious over U.S. Patent No. 7,461,353 (Sherman) in view of U.S. Patent No. 6,691,159 (Ben-Shaul).
  • Claims 1-12 as obvious over U.S. Patent No. 7,461,353 (Sherman) in view of U.S. Patent Application Publication No. 2004/0073587 (Schirmer).
  • Claims 1-12 as obvious over U.S. Patent No. 7,461,353 (Sherman) in view of U.S. Patent Application Publication No. 2005/0076043 (Rosenberg).
  • Claims 1-12 as obvious over U.S. Patent No. 7,461,353 (Sherman) in view of U.S. Patent No. 6,366,293 (Kim).
  • Claims 1-12 as obvious over U.S. Patent No. 7,461,353 (Sherman) in view of U.S. Patent No. 6,356,280 (Mandeville).
• Institution decision: Not yet issued. The statutory deadline for the institution decision is 2026-09-05.
• Final Written Decision: Not applicable as the institution decision has not yet been issued.
• Settlement / termination: Not applicable.
• Appeal: Not applicable.
• Defensive value: This proceeding indicates active challenge against claims 1-12. If institution is granted, these claims will be subject to a PTAB trial. If institution is denied, it would strengthen the patent owner's position for the challenged claims.

Strategic summary

All claims (claims 1-12) of US patent 10083154 are currently UNTESTED by a Final Written Decision but are UNDER REVIEW in an active Inter Partes Review, IPR2026-00281, filed by Google LLC et al. This IPR challenges the patentability of all claims under obviousness grounds.

The estoppel landscape is currently developing. If IPR2026-00281 proceeds to a Final Written Decision, Google LLC et al. (and their privies) would be estopped under 35 U.S.C. § 315(e)(2) from asserting in future district court or ITC actions any invalidity grounds they raised or reasonably could have raised during the IPR. Until then, these specific prior art grounds are actively being litigated at the PTAB.

The fact that Google LLC et al., a significant player in the tech industry, has filed this IPR suggests they believe the patent is vulnerable. This is a common pattern where a party facing assertion or anticipating assertion challenges the underlying patent at the PTAB.

Recommended next steps

Given that IPR2026-00281 is pending, the most critical upcoming milestone is the institution decision deadline on 2026-09-05. A defendant facing assertion of this patent should closely monitor this decision.

• If the PTAB institutes review, it would significantly impact the patent owner's ability to assert claims 1-12, as these claims would be undergoing trial.
• If the PTAB denies institution, it would mean that claims 1-12 have survived this initial challenge, potentially hardening them against similar obviousness arguments in the future.

Access the status and documents for IPR2026-00281 at the USPTO PTAB End-to-End system (E2E) here: https://e2e.uspto.gov/ptab/#!/dashboard/IPR2026-00281.## Proceedings overview
One AIA trial proceeding is on file for US patent 10083154, with a status of Pending. This means the patent's claims are currently undergoing review, and a defensive posture cannot be fully determined until the institution decision and any subsequent Final Written Decision.

IPR2026-00281 — Google LLC et al. v. SoftView LLC

• Type: Inter Partes Review
• Filed: 2026-03-05
• Status: Pending. This proceeding is active and has not yet reached a final institution decision or a Final Written Decision. The statutory deadline for the institution decision is 2026-09-05.
• Judge panel: Not yet publicly available in the current phase of the proceeding.
• Petition grounds: The petition challenged claims 1-12 of U.S. Patent No. 10,083,154, asserting unpatentability under 35 U.S.C. § 103 (obviousness) in view of various combinations of prior art. These combinations include:
  • Claims 1-12 as obvious over U.S. Patent No. 7,461,353 (Sherman) in view of U.S. Patent No. 6,691,159 (Ben-Shaul).
  • Claims 1-12 as obvious over U.S. Patent No. 7,461,353 (Sherman) in view of U.S. Patent Application Publication No. 2004/0073587 (Schirmer).
  • Claims 1-12 as obvious over U.S. Patent No. 7,461,353 (Sherman) in view of U.S. Patent Application Publication No. 2005/0076043 (Rosenberg).
  • Claims 1-12 as obvious over U.S. Patent No. 7,461,353 (Sherman) in view of U.S. Patent No. 6,366,293 (Kim).
  • Claims 1-12 as obvious over U.S. Patent No. 7,461,353 (Sherman) in view of U.S. Patent No. 6,356,280 (Mandeville).
• Institution decision: Not yet issued. The statutory deadline for the institution decision is 2026-09-05.
• Final Written Decision: Not applicable as the institution decision has not yet been issued.
• Settlement / termination: Not applicable.
• Appeal: Not applicable.
• Defensive value: This proceeding indicates an active challenge against claims 1-12. If institution is granted, these claims will be subject to a PTAB trial, which could lead to their invalidation. If institution is denied, it would strengthen the patent owner's position for the challenged claims, making an IPR-based defense harder for others on similar grounds.

Strategic summary

All claims (claims 1-12) of US patent 10083154 are currently UNTESTED by a Final Written Decision but are UNDER REVIEW in an active Inter Partes Review, IPR2026-00281, filed by Google LLC et al. This IPR challenges the patentability of all claims under obviousness grounds.

The estoppel landscape is currently developing. If IPR2026-00281 proceeds to a Final Written Decision, Google LLC et al. (and their privies) would be estopped under 35 U.S.C. § 315(e)(2) from asserting in future district court or ITC actions any invalidity grounds they raised or reasonably could have raised during the IPR. Until then, these specific prior art grounds are actively being litigated at the PTAB.

The fact that Google LLC et al., a significant player in the tech industry, has filed this IPR suggests they believe the patent is vulnerable. This is a common pattern where a party facing assertion or anticipating assertion challenges the underlying patent at the PTAB. It is also important to note that as of late 2025, the USPTO Director, not PTAB panels, has been solely responsible for deciding whether to institute each IPR and PGR, taking into account discretionary considerations, the merits of the petition, and non-discretionary considerations. Additionally, a March 2026 memo by Director John Squires directs the PTAB to weigh U.S. manufacturing activity when deciding whether to institute an AIA trial, which can influence institution decisions.

Recommended next steps

Given that IPR2026-00281 is pending, the most critical upcoming milestone is the institution decision deadline on 2026-09-05. A defendant facing assertion of this patent should closely monitor this decision.

• If the PTAB institutes review, it would significantly impact the patent owner's ability to assert claims 1-12, as these claims would be undergoing trial.
• If the PTAB denies institution, it would mean that claims 1-12 have survived this initial challenge, potentially hardening them against similar obviousness arguments in the future.

Access the status and documents for IPR2026-00281 at the USPTO PTAB End-to-End system (E2E) here: https://e2e.uspto.gov/ptab/#!/dashboard/IPR2026-00281.

Inventors

• Gary B. Rohrabaugh
• Scott A. Sherman

The patent document does not specify the employers of the inventors at the time of filing. There is no information within the provided patent text to determine if inventors departed the original assignee within 12 months of filing.

Original assignee

The original assignee is SoftView LLC.
The provided patent text does not contain information regarding whether SoftView LLC shipped a product embodying the claims, their primary line of business, or their current operational status (operating, acquired, dissolved, in bankruptcy).

Assignment timeline

• 2024-12-22 (executed) / recorded 2024-12-22 — Reel 059904/0839
  • Conveyance: Assignment
  • Assignor: ROHRABAUGH, GARY B
  • Assignee: SOFTVIEW L.L.C.
  • Correspondent: MICHAEL J. REIDINGER, Law Office of Michael J Reidinger, P.C.
  • Context: Reassignment from individual inventor to SoftView L.L.C.

Timeline diagram

timeline
    title Ownership of US 10083154
    2016 : Filed by SoftView LLC
    2018 : Issued to SoftView LLC
    2024 : Assigned to SOFTVIEW L.L.C.

NPE / troll-pattern signals

1. Shell-entity transfer — unclear. The initial assignee, SoftView LLC, and the subsequent assignee, SOFTVIEW L.L.C. (as per the 2024-12-22 assignment), share a similar name. Without further information on their business operations or physical address, it's unclear if either functions as a shell entity.
2. Known asserter in the chain — not present. The assignees, SoftView LLC and SOFTVIEW L.L.C., do not match common public NPE lists based on the provided data.
3. Repeat correspondent across the chain — not present. Only one assignment record is provided for US10083154, so a repeat correspondent cannot be identified from this chain.
4. Cascading transfers — not present. There is only one recorded assignment in the timeline after the patent was issued.
5. Pre-litigation transfer — unclear. While a PTAB case (IPR2026-00281) and a US case filed in the Texas Eastern District Court (2:25-cv-00246) are mentioned in the Google Patents litigation section, the dates of these filings in relation to the 2024-12-22 assignment are not close enough to definitively label this as a "pre-litigation transfer" based solely on the 6-month window. The PTAB case was filed in 2026 and the Texas case in 2025, which is outside a 6-month window from the assignment date.
6. Bankruptcy fire-sale — not present. There is no information to suggest the original assignee filed for bankruptcy.
7. Privateering — unclear. There is no information in the provided patent text or assignment records to suggest privateering.
8. Defensive aggregator (anti-NPE) — not present. The current assignee is not a known defensive aggregator.

Verdict

Insufficient data. Only one assignment is recorded for this patent, which is a reassignment from an individual inventor to an entity with a very similar name to the original assignee. Without additional assignment records or more detailed information about SoftView LLC's business activities, product shipments, and assertion history, there is insufficient data to confidently classify this patent as being involved in an NPE pattern.

USPTO Assignment Center search: https://assignmentcenter.uspto.gov/

To identify the most relevant prior art for US patent 10083154, I will perform a search on the USPTO Patent Public Search database for the specific patent number and then examine the cited references.

Most Relevant Prior Art for US Patent 10083154

US Patent 10083154 explicitly states its lineage as a continuation of several earlier applications. These directly preceding patents and applications are highly relevant as they often share substantial subject matter and form the core inventive concept's evolution. Prior art, under 35 U.S.C. § 102, refers to any public knowledge, use, patent, or publication existing before the effective filing date of the claimed invention.

The patent text "CROSS-REFERENCE TO RELATED APPLICATION" section details the following chain of applications, all of which are directly relevant prior art due to their continuity and shared subject matter with US10083154B2:

1. U.S. Non-provisional application Ser. No. 12/941,106

   • Full Citation: U.S. Non-provisional application Ser. No. 12/941,106, filed Nov. 8, 2010, entitled "SCALABLE DISPLAY OF INTERNET CONTENT ON MOBILE DEVICES" (issued as U.S. Pat. No. 9,519,729).
   • Publication/Filing Date: Filed: November 8, 2010.
   • Brief Description: This is a direct continuation of the core invention, focusing on scalable display of Internet content on mobile devices. As a direct predecessor, it contains the foundational claims and disclosures for the scalable vector representation and rendering on mobile devices.
   • Potentially Anticipates (35 U.S.C. § 102): Likely anticipates all claims (Claims 1, 13, 20, 21, 22, 23, 25) of US10083154B2, as they share the same title and are part of the same patent family, indicating very similar subject matter.

2. U.S. Non-provisional application Ser. No. 11/738,486

   • Full Citation: U.S. Non-provisional application Ser. No. 11/738,486, filed Apr. 21, 2007, entitled "SCALABLE DISPLAY OF INTERNET CONTENT ON MOBILE DEVICES" (to be issued as U.S. Pat. No. 7,831,926).
   • Publication/Filing Date: Filed: April 21, 2007.
   • Brief Description: Another continuation in the series, further developing the concepts of scalable display of Internet content on mobile devices.
   • Potentially Anticipates (35 U.S.C. § 102): Likely anticipates all claims (Claims 1, 13, 20, 21, 22, 23, 25) of US10083154B2 due to being a direct parent application with a similar title and inventive concept.

3. U.S. Non-provisional application Ser. No. 09/878,097

   • Full Citation: U.S. Non-provisional application Ser. No. 09/878,097, filed Jun. 8, 2001, entitled "RESOLUTION INDEPENDENT VECTOR DISPLAY OF INTERNET CONTENT" (issued as U.S. Pat. No. 7,210,099).
   • Publication/Filing Date: Filed: June 8, 2001.
   • Brief Description: This application introduces the fundamental concept of resolution-independent vector display of Internet content, which is central to US10083154B2. It covers the core idea of translating web content into a scalable vector representation.
   • Potentially Anticipates (35 U.S.C. § 102): Given its foundational nature, this patent likely anticipates core elements of all claims (Claims 1, 13, 20, 21, 22, 23, 25) relating to the generation and rendering of scalable vector representations of HTML content.

4. U.S. Provisional Application No. 60/211,019

   • Full Citation: U.S. Provisional Application No. 60/211,019, filed Jun. 12, 2000, entitled "METHOD AND SYSTEM FOR RESOLUTION INDEPENDENT DISPLAY OF HTML AND XML CONTENT".
   • Publication/Filing Date: Filed: June 12, 2000.
   • Brief Description: This provisional application is the earliest priority document, establishing the initial inventive concept for resolution-independent display of HTML and XML content.
   • Potentially Anticipates (35 U.S.C. § 102): As the earliest filing for the core idea, it likely anticipates the fundamental aspects of scalable display, content processing (HTML/XML), and resolution independence across all claims of US10083154B2.

5. U.S. Provisional Application No. 60/217,345

   • Full Citation: U.S. Provisional Application No. 60/217,345, filed Jul. 11, 2000, entitled "METHOD AND SYSTEM FOR SELECTION, RETRIEVAL, AND CONVERSION OF COMPUTER CONTENT TO VECTOR FORMAT FOR RESOLUTION INDEPENDENT DISPLAY".
   • Publication/Filing Date: Filed: July 11, 2000.
   • Brief Description: This provisional application further defines the methods and systems for retrieving and converting computer content into a vector format for resolution-independent display.
   • Potentially Anticipates (35 U.S.C. § 102): This provisional application likely anticipates aspects of claims related to the process of converting content to a scalable vector format, which is a key step in Claims 1, 13, 20, 21, 22, 23, and 25 of US10083154B2.

Other related applications, also cited in the "CROSS-REFERENCE TO RELATED APPLICATION" section, also serve as relevant prior art:

• U.S. Non-provisional application Ser. No. 11/045,649 (U.S. Pat. No. 7,584,423), filed Jan. 28, 2005, entitled "Method, Proxy and System to Support Full-page Web Browsing on Hand-held Devices."
• U.S. Non-provisional application Ser. No. 11/045,757 (U.S. Pat. No. 7,461,353), filed Jan. 28, 2005, entitled "SCALABLE DISPLAY OF INTERNET CONTENT ON MOBILE DEVICES."
• U.S. Non-provisional application Ser. Nos. 11/735,477 and 11/735,482, both filed on Apr. 15, 2007.
• U.S. Non-provisional application Ser. No. 11/738,932 filed on Apr. 23, 2007.
• U.S. Non-provisional application Ser. No. 11/868,124 filed on Oct. 5, 2007.
• U.S. Non-provisional application Ser. No. 12/326,092 filed on Dec. 1, 2008.

These documents represent the continuous development and refinement of the invention and would be considered highly pertinent for anticipating claims under 35 U.S.C. § 102, as they disclose various aspects of scalable web content display on mobile devices, including the use of proxy servers, client-side rendering, and specific user interaction methods. The specific claims they anticipate would depend on the detailed comparison of their disclosures with the individual claim limitations of US10083154B2.

To analyze the obviousness of US patent 10083154 under 35 U.S.C. § 103, we must identify combinations of prior art references that would render the claims obvious to a person having ordinary skill in the art (PHOSITA) as of the priority date of June 12, 2000. A PHOSITA in this field around 2000 would likely possess knowledge of web technologies (HTML, CSS), mobile device capabilities (small screens, limited processing, WAP), vector graphics, and user interface design.

The independent claims (1, 13, 20, 21, 22, 23, 25) of US10083154 generally describe a mobile hand-held device or a method/computer-readable medium for:

1. Receiving and processing an HTML document using an HTML rendering engine to interpret page layout, group content into objects, and generate bounding boxes and page layout information.
2. Translating this representation into a scalable vector representation by defining a primary datum for the page, object datums for bounding boxes, generating vectors between datums, and creating references.
3. Rendering the scalable vector representation on a touch-sensitive display to fit the width, and enabling user-defined zoom and pan operations via touch input while preserving the original layout, functionality, and design.

The patent itself acknowledges the challenges of displaying web content designed for desktop computers on small screens, noting that "The majority of Internet content displays as a flat single resolution with no browser support for zoom." (BACKGROUND OF THE INVENTION) and that "major Internet content providers have chosen to create their Web pages using fixed resolution structures, such as tables." (BACKGROUND OF THE INVENTION).

Given the priority date of June 12, 2000, we will look for prior art that addresses these technical areas.

The provisional applications U.S. Provisional Application No. 60/211,019, filed Jun. 12, 2000, and U.S. Provisional Application No. 60/217,345, filed Jul. 11, 2000, are cited in US10083154B2 as priority documents. The abstract of US 8145995 B2, which claims continuity from an application that itself claims priority from these provisional applications, states that it enables "Mobile devices enabled to support resolution-independent scalable display of Internet (Web) content to allow Web pages to be scaled (zoomed) and panned for better viewing on smaller screen sizes." It further describes using "software-based processing of original Web content, including HTML-based content, XML, cascade style sheets, etc. to enable Web page content to be rapidly rendered, zoomed, and panned." This indicates that the core concepts of scalable display, zooming, and panning of web content on mobile devices were present in the provisional applications as of their filing dates. However, for obviousness analysis under 35 U.S.C. § 103, we need to consider prior art that was publicly available before the earliest priority date (June 12, 2000). Provisional patent applications are generally not published or made public at their filing date unless a non-provisional application claiming priority to them is subsequently published.

Therefore, we will focus on other publicly available prior art.

1. General Knowledge of HTML Rendering and Processing on Mobile Devices (before June 2000)

By June 2000, HTML 4.01 was an official standard (December 1999), and XHTML 1.0, a reformulation of HTML using XML syntax, was released in 2000. HTML 3.2, released in January 1997, standardized features like tables and text flow around images. Web browsers of the time, such as Netscape and Internet Explorer, processed HTML by parsing it, identifying elements, and building a page layout. The Mozilla rendering engine, for example, started development in 1997 and by May 2000 was designed to fully support HTML4 rendering requirements, including incremental layout with reflow, CSS, and a Document Object Model. This engine comprised HTML parsing and rendering, along with other functionalities.

Mobile devices, such as PDAs and early cell phones, were already capable of accessing internet content, albeit with significant limitations. WAP (Wireless Application Protocol), introduced in 1999, was a global standard for bringing internet content to mobile phones, but it used Wireless Markup Language (WML) instead of HTML, and suffered from "ridiculously small screens, slow bandwidth, and the need to place a new call every time the device needs to connect." WAP was designed for the "limited capabilities of a mobile device." While WAP browsers could not read HTML pages, some phones were starting to incorporate HTML browsers, such as Microsoft Mobile Explorer. There was a recognized need to adapt web content for these devices.

2. Scalable Graphics and Zooming/Panning in Computing Environments (before June 2000)

The concept of scalable graphics was well-established. Vector graphics, which are images built from mathematical formulas, have a history dating back to the 1940s and 1950s, used in early computer displays due to limited memory, and became prominent in CAD (Computer-Aided Design) and desktop publishing. The World Wide Web Consortium (W3C) adopted Scalable Vector Graphics (SVG) as a standard file format for vector graphics in 1999. SVG files are XML-based and can be executed to draw graphics, mitigating the overhead of downloading image files like BMP, GIF, or JPG.

Zooming and panning as user interaction techniques in graphical interfaces also existed before 2000. For instance, "A Zooming Web Browser" by Benjamin B. Bederson et al. (1996) describes a prototype zooming browser that depicts multiple web pages and links on a large zoomable information surface, where pages are scaled for readability and context, and layout changes are animated. This paper also mentions an extension to HTML called Multi-Scale Markup Language (MSML) to support multi-scale layout within a page, including variable-sized dynamic objects, graphics, and other interface mechanisms, and notes that MSML allowed control over the size of all types of objects, including images and graphics.

Touchscreens themselves had a long history, with multi-touch being implemented as early as 1982 by the University of Toronto's Input Research Group, and touch-sensitive devices with gestures existing in the late 1980s. While "pinch-to-zoom" specifically gained widespread recognition with later devices, the underlying concepts of touch interaction for scaling and manipulating displayed content were present.

Obviousness Combinations and Motivation to Combine:

A PHOSITA in June 2000, facing the challenge of displaying full internet content effectively on mobile devices with small screens and limited resources, would have been motivated to combine existing technologies to overcome the limitations of current mobile browsing solutions like WAP, which delivered a "substandard" experience.

Combination 1: HTML Rendering Engine + Scalable Vector Graphics + Mobile Device Constraints

• HTML Rendering and Processing: It was known to use HTML rendering engines (like Mozilla's, in development since 1997) to parse HTML documents, identify elements, logically group content, and determine page layout with bounding boxes. This is a fundamental aspect of any web browser.
• Scalable Vector Graphics (SVG): The W3C adopted SVG in 1999, recognizing its benefits for scalability, smaller file sizes, and ability to be executed via basic ASCII drawing commands. This was a clear advantage for resource-constrained mobile devices where "traffic is held to a few bytes."
• Motivation to Combine: The motivation to combine these would be to address the well-known problem of displaying fixed-resolution HTML content on small, diverse mobile screens, which often resulted in "miserable usability." A PHOSITA would recognize that translating the fixed-layout HTML output of a rendering engine into a scalable vector format would allow for resolution-independent display, making web content viewable on devices with varying screen sizes and resolutions without degradation. SVG, being a web-native vector format, would be a natural choice for this conversion. The goal would be to "display the web pages in a simple and reasonable way" on handheld devices, as stated in the patent. (DETAILED DESCRIPTION OF THE INVENTION).

This combination directly addresses the first two major steps of the claims: processing HTML to understand its layout and then translating it into a scalable vector representation.

Combination 2: (Combination 1) + Touch-Sensitive Displays + Zoom/Pan Interaction

• Prior art for touch-sensitive displays and interaction: Touchscreens existed for decades, and by the 1990s, single and multi-touch gestures, including zooming, were being explored in various contexts. Concepts of manipulating content on a display via touch, such as tapping to select or performing gestures for zooming, were known. For example, the Pad++ project (Bederson et al., 1995-1998) explored zoomable graphical interfaces. The Bederson 1996 "Zooming Web Browser" specifically mentions "automatic zooming and panning to support navigation" on a "large zoomable information surface."
• Motivation to Combine: Given the small screen sizes of mobile devices, simply scaling content down often made it "difficult to read." (DETAILED DESCRIPTION OF THE INVENTION). Allowing users to interactively zoom and pan through the content, especially using direct manipulation via a touch-sensitive display (which was a feature of some mobile devices like PDAs), would be a highly desirable improvement for usability. A PHOSITA would logically apply known zooming and panning interface techniques, previously seen in other graphical applications or experimental browsers, to the newly vectorized web content on touch-enabled mobile devices. This would directly enable the "user-defined zoom levels by rendering the scalable vector representation on the touch-sensitive display using one or more respective scale factors in response to associated user inputs made via the touch-sensitive display" as claimed.

This combination makes obvious the rendering of the scalable vector representation on a touch-sensitive display with user-controlled zoom and pan, and the preservation of layout and design, which is a key aspect of the claims. The patent explicitly identifies the lack of browser support for zoom as a problem it solves, which indicates the motivation for a PHOSITA to implement such a feature. (BACKGROUND OF THE INVENTION).

Combination 3: (Combination 2) + Datum and Vector Generation for Scalable Rendering

• Vector Graphics Principles: Vector graphics inherently rely on mathematical descriptions (e.g., points, lines, curves) and coordinate systems to enable scaling without loss of quality. CAD software, long using vector graphics, would have established practices for defining origins, object positions, and relationships using vectors.
• HTML Layout Information: HTML rendering engines, by their nature, determine the position and size of elements (bounding boxes) on a page. The patent notes that "the location of each object on a display page will be dependent on previous HTML layout elements." (DETAILED DESCRIPTION OF THE INVENTION).
• Motivation to Combine: Once the decision is made to convert HTML layout to a scalable vector representation, a PHOSITA would find it obvious to use geometric principles common in vector graphics (such as defining datums and vectors) to represent the position and size of HTML objects. This approach provides the underlying structure necessary for efficient and resolution-independent scaling and panning. Connecting "each HTML object with its corresponding page layout information," and then "defining a primary datum" and "an object datum" for "generating a vector from the primary datum to the object datum" (Claim 1) is a standard method of representing spatial relationships in a vector-based system. This mechanical step would be obvious to anyone skilled in graphical rendering once the concept of vectorizing HTML layout for scalability is conceived.

The specific "parsing," "logically grouping content into HTML objects," "generating page layout information including a bounding box for each HTML object," and "storing information that links each HTML object with its corresponding page layout information" are all standard operations performed by an HTML rendering engine. (Claim 1). The translation into a scalable vector representation by defining datums and vectors for these objects is a logical application of known vector graphics principles to the layout information already generated.

In summary, a person having ordinary skill in the art in 2000, motivated by the poor user experience of fixed-resolution web content on small mobile screens and aware of existing HTML rendering techniques, scalable vector graphics, and touch-based interaction paradigms, would have found it obvious to combine these elements to create a system for scalable, zoomable, and pannable display of internet content on mobile devices. The individual components and the underlying problems they solve were known, and the combination would have been a predictable solution to a recognized challenge in mobile web browsing.

To provide accurate and up-to-date information on patent term adjustments (PTA), patent term extensions (PTE), continuation applications, divisional applications, related family members, and the projected expiration date for US patent 10083154, direct access to the USPTO's Patent Center or Patent Public Search is required. The USPTO does not calculate expiration dates for patents itself but provides tools and guidance for estimating them.

Based on the information available in the patent document and general patent law:

Patent Term Adjustments (PTA)
PTA is granted to compensate for certain delays caused by the USPTO during the prosecution of a patent application. The America Invents Act of 1999 established PTA, which adds days to the 20-year lifespan of a utility or plant patent. PTA can be accrued for various reasons, including the USPTO failing to issue an office action within 14 months of filing, failing to respond to an applicant's reply within four months, or if the patent does not issue within 36 months of its filing date. Applicant delays can reduce the period of adjustment. The USPTO automatically determines the PTA and provides notice no later than the patent's issuance date.

To determine the specific PTA for US patent 10083154, one would typically consult the Issue Notification Letter or the patent's file history in Patent Center. Without direct access to these USPTO systems for this specific patent, the exact PTA amount cannot be determined from the provided text.

Patent Term Extensions (PTE)
PTEs are available for patents covering certain human drugs, food or color additives, medical devices, animal drugs, and veterinary biological products to restore a portion of the patent term lost during regulatory review by agencies like the FDA. This is governed by the Hatch-Waxman Act. A PTE cannot exceed five years, and the total patent term, including the extension, cannot exceed 14 years from the date of marketing approval. "Pediatric exclusivity" can provide an additional six-month extension for innovator pharmaceutical companies conducting research for pediatric patients.

Given that US patent 10083154 relates to "Scalable display of internet content on mobile devices," it does not fall within the categories of products eligible for PTE under the Hatch-Waxman Act. Therefore, it is highly unlikely to have any PTE.

Continuation Applications, Divisional Applications, and Related Family Members
US patent 10083154 is explicitly identified as a "Continuation" of several earlier applications. These form part of its patent family and share common subject matter.

The patent text "CROSS-REFERENCE TO RELATED APPLICATION" section details its lineage:

• Continuation of: U.S. Non-provisional application Ser. No. 12/941,106, filed Nov. 8, 2010 (issued as U.S. Pat. No. 9,519,729).
• Which is a Continuation of: U.S. Non-provisional application Ser. No. 11/738,486, filed Apr. 21, 2007 (to be issued as U.S. Pat. No. 7,831,926).
• Which is a Continuation of: U.S. Non-provisional application Ser. No. 09/878,097, filed Jun. 8, 2001 (issued as U.S. Pat. No. 7,210,099).
• Which is a Continuation-in-Part of: U.S. Non-provisional application Ser. No. 09/828,511, filed Apr. 7, 2001 (Abandoned).

Additionally, U.S. Non-provisional application Ser. No. 09/878,097 further claims the benefit of:

• U.S. Provisional Application No. 60/211,019, filed Jun. 12, 2000.
• U.S. Provisional Application No. 60/217,345, filed Jul. 11, 2000.

The application also contains subject matter related to Divisionals (of U.S. Non-provisional application Ser. No. 09/878,097):

• U.S. Non-provisional application Ser. No. 11/045,649 (issued as U.S. Pat. No. 7,584,423), filed Jan. 28, 2005.
• U.S. Non-provisional application Ser. No. 11/045,757 (issued as U.S. Pat. No. 7,461,353), filed Jan. 28, 2005.

Further related applications include:

• U.S. Non-provisional application Ser. Nos. 11/735,477 and 11/735,482, both filed on Apr. 15, 2007.
• U.S. Non-provisional application Ser. No. 11/738,932 filed on Apr. 23, 2007.
• U.S. Non-provisional application Ser. No. 11/868,124 filed on Oct. 5, 2007.
• U.S. Non-provisional application Ser. No. 12/326,092 filed on Dec. 1, 2008.

These applications constitute the patent family for US patent 10083154, demonstrating a continuous chain of applications claiming priority back to the earliest provisional filing dates. A continuation application is a second application for the same invention claimed in a prior non-provisional application and is filed while the original application is still pending. A divisional application is filed to pursue inventions that were restricted out of a parent application. Both continuation and divisional applications generally retain the filing date of the parent application.

Projected Expiration Date
For applications filed on or after June 8, 1995, the patent term is generally 20 years from the date of the earliest related application for which a benefit is claimed. This 20-year term can be adjusted by PTA.

The earliest priority date for US patent 10083154, as stated in its "CROSS-REFERENCE TO RELATED APPLICATION" section, is June 12, 2000, from U.S. Provisional Application No. 60/211,019. However, "A U.S. provisional application or a foreign application isn't included in that chain" when counting the 20 years from the earliest application in the chain, for applications filed after June 8, 1995. Instead, the 20-year term is counted from the earliest non-provisional application.

The earliest non-provisional application in the chain is U.S. Non-provisional application Ser. No. 09/878,097, filed on June 8, 2001. Therefore, the nominal expiration date would be June 8, 2021 (20 years from June 8, 2001).

However, the patent states its anticipated expiration as 2021-04-07 and also lists its legal status as "Expired - Fee Related". This earlier expiration date of April 7, 2021, suggests that the earliest effective filing date might be April 7, 2001, corresponding to U.S. Non-provisional application Ser. No. 09/828,511 (Abandoned), or there could be a terminal disclaimer that affects the patent term. Terminal disclaimers prevent double patenting and can cause a patent to expire with an earlier patent. Without specific information on terminal disclaimers for US10083154, it is difficult to definitively confirm the exact reason for the April 7, 2021, expiration date.

Since the patent is listed as "Expired - Fee Related" and an anticipated expiration date of April 7, 2021, is provided, the patent has already expired. This means that any PTA that may have been granted would have extended its term beyond the nominal 20 years from its earliest non-provisional filing date (June 8, 2001, which would have meant a nominal expiry of June 8, 2021), but it ultimately expired due to fee-related issues by April 7, 2021.

Defensive Disclosure for US Patent 10083154 - Scalable Display of Internet Content on Mobile Devices

This document provides a defensive disclosure designed to render future incremental improvements on the subject matter of US Patent 10083154 obvious or non-novel, based on its independent claims (1, 13, 20, 21, 22, 23, 25) and the various axes of derivation. The aim is to preemptively establish prior art for foreseeable variations.

I. Material & Component Substitution

This section explores derivative variations based on alternative materials, mechanical, or electronic components that achieve the same functional results as described in US10083154.

Derivative 1.1: Electrophoretic Displays with Haptic Feedback for Scalable Content

• Axis: Material & Component Substitution (Claims 1, 13, 20)
• Enabling Description: A mobile hand-held device (100) incorporates a flexible electrophoretic display (E-Ink display, 521a) in place of traditional LCDs, specifically optimized for low-power, high-contrast monochrome or limited grayscale rendering of scalable vector content. The touch-sensitive input is achieved via an integrated transparent piezoelectric sensor matrix (523a) directly laminated onto the E-Ink film, capable of detecting multi-point gestures and pressure variations. The HTML rendering engine (68), residing in low-power MRAM (Magnetoresistive Random Access Memory, 504a), is reconfigured to generate simplified SVF output suitable for the display's inherent refresh rate and image persistence characteristics. This includes dynamic dithering algorithms for grayscale representation of color HTML elements. Upon a user's tap gesture (e.g., stylus or finger press) detected by the piezoelectric matrix, the device's processor (502) transitions the display of a selected HTML object (e.g., column, image, paragraph) from a nominal zoom state (Z0) to a contextual zoom state (Z1) by re-rendering the SVF data with an increased scale factor (SF1). Haptic feedback is provided through integrated linear resonant actuators (LRAs, 524a) embedded within the device chassis, delivering distinct tactile patterns to confirm successful user input and zoom state changes. The device's display controller (521b) features a dedicated E-Ink waveform generator, enabling selective region updates for efficient localized zooming and panning without full screen refreshes, thus preserving power and reducing visual artifacts.
• Mermaid Diagram:

  stateDiagram
      direction LR
      [*] --> Nominal_View : Device Power On
      Nominal_View --> Detect_Tap : User Input (Piezo Sensor)
      Detect_Tap --> Identify_Object : Rendering Engine (SVF Object Map)
      Identify_Object --> Calculate_Zoom : Processor (SF, Offset)
      Calculate_Zoom --> Render_Zoomed_Region : E-Ink Controller (Waveform Gen)
      Render_Zoomed_Region --> Haptic_Confirm : LRA Actuator
      Haptic_Confirm --> Zoomed_View : Display Update
      Zoomed_View --> Detect_Tap_Out : User Input (Piezo Sensor)
      Detect_Tap_Out --> Nominal_View : Back to Nominal
      Zoomed_View --> Pan_View : User Input (Drag Gesture)
      Pan_View --> Calculate_Pan : Processor (New Offset)
      Calculate_Pan --> Render_Zoomed_Region : E-Ink Controller (Waveform Gen)
  

Derivative 1.2: Hybrid Processor Architecture for Vector Graphics Rendering

• Axis: Material & Component Substitution (Claims 1, 13, 20)
• Enabling Description: The mobile hand-held device (100) utilizes a hybrid processor (502a) that integrates a general-purpose ARM-based CPU core (502b) with a custom hardware vector graphics unit (VGU, 502c) on a single System-on-Chip (SoC). The VGU (502c) is specifically designed to accelerate the translation of parsed HTML/CSS layout information into scalable vector representations (SVF) and to rapidly execute vector rendering commands for display. The HTML rendering engine (68) offloads tasks such as datum definition, vector generation, and reference creation (as per Claim 1, steps "defining a primary datum...", "generating a vector...", "creating a reference...") directly to the VGU's dedicated instruction set. This VGU includes a specialized matrix transformation engine for real-time application of scale factors and pan offsets (SF, ΔX, ΔY) to the SVF data structure. Frame buffer memory (504b) for the touch-sensitive display (521) is implemented using high-bandwidth memory (HBM) to support ultra-fast rendering of zoomed and panned content. The wireless communications device (525) employs a dedicated secure element for cryptographic acceleration, enabling efficient decryption of encrypted SVF streams without impacting the main processor's rendering pipeline.
• Mermaid Diagram:

  flowchart TD
      A[HTML Document + CSS Code] --> B{HTML Rendering Engine};
      B -- Parse, Group, Bounding Boxes --> C[Interpreted Page Layout (HTML Objects)];
      C -- Offload Translation --> D(Hybrid Processor);
      D --> D1[ARM CPU Core];
      D --> D2[Custom Vector Graphics Unit (VGU)];
      D2 -- Accelerate Datum, Vector Gen, Reference Creation --> E[Scalable Vector Representation (SVF)];
      E -- Real-time Scale/Pan/Render --> F[Touch-Sensitive Display];
      F -- User Input --> B;
  

Derivative 1.3: Ferroelectric RAM (FRAM) for Persistent Caching

• Axis: Material & Component Substitution (Claims 22, 23, 25)
• Enabling Description: In a mobile hand-held device (100) for displaying web content, the flash memory (504) is replaced with ferroelectric RAM (FRAM, 504c). FRAM offers non-volatility, extremely high write endurance, and significantly faster write speeds compared to traditional NAND flash. The scalable vector representation (SVF) of web page content, along with associated compressed bitmaps and display lists, is persistently cached in the FRAM (504c). This allows for near-instantaneous retrieval and rendering of previously viewed content or pre-fetched linked content, even after device power cycling, without re-requesting from the network. The faster write speeds of FRAM facilitate real-time updates to the cached SVF data, particularly when web pages employ dynamic content updates (e.g., stock tickers, social media feeds) that require rapid re-vectorization of specific HTML objects. The device's power management unit (PMU) is optimized to exploit FRAM's low power consumption during read/write operations, extending battery life during extensive web browsing and content manipulation.
• Mermaid Diagram:

  sequenceDiagram
      User->>Device: Request Web Page (URL)
      Device->>Wireless Comm: Send Request
      Wireless Comm->>Network: Fetch HTML/CSS/Images
      Network-->>Wireless Comm: Raw Content Stream
      Wireless Comm->>Device: Receive Raw Content
      Device->>Processor: HTML Rendering Engine
      Processor->>Processor: Process HTML (Parsing, Bounding Boxes)
      Processor->>FRAM: Store Scalable Vector Rep. (SVF)
      Processor->>Display: Render SVF (Initial Zoom)
      User->>Display: Touch Input (Zoom/Pan)
      Display->>Processor: Scale Factor / Offset
      Processor->>FRAM: Retrieve SVF
      FRAM-->>Processor: SVF Data
      Processor->>Display: Re-render Scaled/Panned
  

Derivative 1.4: Multi-Modal Bio-Acoustic Input for Contextual Zoom

• Axis: Material & Component Substitution (Claims 1, 13, 20)
• Enabling Description: The mobile hand-held device (100) incorporates a multi-modal bio-acoustic input system as an alternative to or in conjunction with the touch-sensitive display (521). This system comprises an array of MEMS microphones (523b) coupled with a bone conduction transducer (523c) integrated into the device. The processor (502) executes a neural network-based acoustic event detection algorithm, trained to recognize specific user vocalizations (e.g., "zoom in," "focus paragraph") or even subtle bio-acoustic signals (e.g., changes in user breathing patterns indicating focus). Upon detection of a contextual bio-acoustic input, the system identifies the currently displayed HTML object or a user-indicated region of interest (e.g., via gaze tracking or a prior brief touch input). The HTML rendering engine (68) then dynamically re-renders the scalable vector representation of the HTML document at a user-defined or contextually predicted zoom level, maintaining the interpreted page layout. For example, a specific vocal command could directly trigger a tap-based zoom action on a column or image, akin to the functionality described for stylus taps in FIGS. 7A/7B and 8A/8B. This allows for hands-free and gaze-controlled interaction with the scaled content.
• Mermaid Diagram:

  graph TD
      A[User Bio-Acoustic Input] --> B{MEMS Microphones / Bone Transducer};
      B --> C[Signal Pre-processing (Noise Reduction)];
      C --> D{Neural Network (Acoustic Event Detection)};
      D -- "Zoom In / Focus" --> E[Identify Target HTML Object (e.g., Gaze, Last Touch)];
      E --> F[Processor (Execute Rendering Engine)];
      F -- "Update Scale Factor" --> G[Scalable Vector Representation (SVF)];
      G --> H[Re-render on Touch-Sensitive Display];
      H -- "Contextual Zoomed View" --> User;
  

II. Operational Parameter Expansion

This section describes variations where the technology operates at extreme scales, temperatures, pressures, or frequencies.

Derivative 2.1: Gigapixel Resolution Displays for Collaborative Design Review

• Axis: Operational Parameter Expansion (Claims 1, 13, 20)
• Enabling Description: A mobile hand-held device, now scaled up to a collaborative design review station (e.g., a large-format portable touchscreen display, 521b, exceeding 8K resolution, effectively a gigapixel display when considering virtual canvas), processes and renders internet content. The HTML rendering engine (68) is optimized to manage an SVG-based scalable vector representation on a virtual canvas far exceeding the physical display's resolution (e.g., 100,000 x 100,000 pixels). The processor (502) is a multi-core CPU with a dedicated GPU for vector rasterization, capable of rendering sub-pixel accurate anti-aliased text and graphics at extreme zoom levels, maintaining visual fidelity without degradation as specified. Users interact with the display using advanced multi-touch gestures (e.g., 10-point simultaneous input) for highly granular scaling (e.g., zoom factors from 0.01x to 1000x) and panning across vast web-based blueprints, interactive maps, or CAD models presented as HTML content. The system supports distributed rendering, where portions of the vectorized content are rendered by parallel processing units and streamed to the display, ensuring real-time performance even with gigapixel output.
• Mermaid Diagram:

  flowchart TD
      A[Large-Format Touch Display (Gigapixel)] --> B(Multi-Touch Input);
      B --> C[Processor (Multi-core CPU + GPU)];
      C -- Rendering Requests --> D[Distributed Rendering Units];
      D --> E[HTML Rendering Engine (Handles Virtual Canvas)];
      E -- Scalable Vector Representation (SVF) --> F[High-Resolution Display Buffer];
      F --> A;
      SubGraph Scalable Content Flow
          G[HTML/CSS Input] --> H[Parsing/Grouping (HTML Objects)];
          H --> I[Datum/Vector Generation];
          I --> J[SVF Database (Virtual Canvas)];
      end
      J -- "Portion for View" --> E;
  

Derivative 2.2: Hypersonic Dynamic Range Scaling for Extreme Data Visualizations

• Axis: Operational Parameter Expansion (Claims 22, 23, 25)
• Enabling Description: A mobile device, designed for field operations and scientific data analysis, handles web content containing real-time telemetry or sensor data visualizations (e.g., thermal maps, electromagnetic spectra) often presented within HTML5 canvas elements or as embedded SVG. The device's rendering pipeline (68) supports "hypersonic dynamic range scaling," where a single user touch gesture (e.g., a rapid three-finger swipe) can trigger a scale factor change of several orders of magnitude (e.g., from 1:1,000,000 to 1:1, or vice versa) in under 50 milliseconds, effectively zooming from a global overview to a micro-detail instantly. The processing unit (502) employs a dedicated custom ASIC (Application-Specific Integrated Circuit) for geometric transformation and interpolation, allowing for real-time resampling and rendering of vector primitives across an extremely wide range of scales, while preserving data integrity and visual design. Pan offsets are also applied dynamically at these extreme scales, facilitating seamless navigation across vast data landscapes. Content data, including high-fidelity compressed images (e64) and associated metadata, is stored in a tiered flash memory (504) architecture, with a small, ultra-fast tier for immediate rendering requirements and a larger, slower tier for archival.
• Mermaid Diagram:

  stateDiagram
      direction LR
      Overview_State --> Detail_State : Hyper-Zoom Gesture (SF: 1e-6 -> 1e0)
      Detail_State --> SubDetail_State : Micro-Zoom Gesture (SF: 1e0 -> 1e3)
      SubDetail_State --> Overview_State : Inverse Hyper-Zoom
      Overview_State : Displaying Large Dataset Overview
      Detail_State : Displaying Intermediate Detail
      SubDetail_State : Displaying Fine-grained Detail
      state "Rendering Pipeline" {
          Input[Touch Gesture] --> ASIC[Custom ASIC for Geo Transform]
          ASIC --> Vector_Data[SVF Data Stream]
          Vector_Data --> Frame_Buffer[HBM Frame Buffer]
          Frame_Buffer --> Output[Display]
      }
  

Derivative 2.3: Context-Aware Environmental Lighting Adaptation

• Axis: Operational Parameter Expansion (Claims 1, 13, 20)
• Enabling Description: The mobile hand-held device (100) includes an ambient light sensor array (523d) and a color temperature sensor (523e). The HTML rendering engine (68), upon receipt of sensor data, dynamically adjusts the rendering parameters of the scalable vector representation (SVF) for optimal legibility across varying environmental lighting conditions. This includes adaptive contrast enhancement, intelligent color inversion (e.g., "dark mode" activation in low light), and dynamic adjustment of font weights and line spacing without altering the logical page layout. For instance, in bright sunlight, the rendering engine might increase text stroke width and switch to high-contrast color palettes (e.g., black text on white background with reduced anti-aliasing) to improve readability. In low-light conditions, it could switch to a "night mode" with inverted colors (white text on dark background) and subtly increased font sizes while maintaining the original bounding box proportions through internal scaling adjustments to font metrics. These adaptations are applied in real-time as the user moves between environments, ensuring that the "interpreted page layout, functionality, and design of the content associated with the HTML document is preserved" even as its visual presentation adapts.
• Mermaid Diagram:

  flowchart TD
      A[Ambient Light Sensor Array] --> B{Processor (Context Analysis)};
      B -- "Lighting Condition Detected" --> C[HTML Rendering Engine];
      C -- "Adjust Rendering Parameters" --> D[Scalable Vector Representation (SVF)];
      D -- "Adaptive Contrast, Color, Font" --> E[Touch-Sensitive Display];
      E --> User[User Viewing Content];
  

Derivative 2.4: Ultra-Low Latency for High-Frequency Industrial Data Streams

• Axis: Operational Parameter Expansion (Claims 22, 23, 25)
• Enabling Description: A ruggedized mobile hand-held device (100) is deployed in an industrial setting, displaying real-time operational data from high-frequency sensors (e.g., vibration analysis, real-time pressure readings) presented as dynamic web content. The device is equipped with a hardware-accelerated rendering pipeline (502) designed for ultra-low latency display updates (e.g., <1ms glass-to-glass latency). The scalable vector representation (SVF) of the web page content is continuously updated from a local edge server via a 5G mmWave wireless link (525). The HTML rendering engine (68) employs a predictive rendering algorithm that anticipates user pan and zoom gestures based on historical interaction patterns and data trends. This allows pre-computation of SVF tiles for neighboring regions and anticipated zoom levels, significantly reducing rendering latency upon user input. The touch-sensitive display (521) utilizes a high refresh rate (e.g., 240 Hz) and low-persistence phosphors/LCD technology to minimize motion blur during rapid panning across industrial dashboards. The Flash memory (504) serves as a high-speed buffer for streaming SVF updates, ensuring smooth visualization of rapidly changing industrial processes.
• Mermaid Diagram:

  sequenceDiagram
      Sensor->>Edge_Server: High-Freq Data
      Edge_Server->>Web_Service: Push Dynamic HTML/SVG
      Web_Service->>Wireless_Device: Stream Content (5G mmWave)
      Wireless_Device->>Processor: Receive HTML Update
      Processor->>HTML_Renderer: Update SVF
      HTML_Renderer->>Processor: Predictive Rendering (Pre-compute SVF tiles)
      Processor->>Display: Render SVF (Low Latency)
      User->>Display: Rapid Pan/Zoom (Touch)
      Display->>Processor: Gesture Input
      Processor->>Display: Display Pre-computed / Re-render SVF (<1ms)
  

III. Cross-Domain Application

This section describes how the specific mechanism of scalable web content display would be applied in unrelated industries.

Derivative 3.1: Scalable Interactive Maintenance Manuals for Aerospace

• Axis: Cross-Domain Application (Claims 1, 13, 20)
• Enabling Description: A specialized mobile hand-held device (100), ruggedized for aerospace maintenance environments, replaces bulky paper manuals. This device receives complex aircraft schematics, repair procedures, and interactive 3D models (embedded in HTML5/WebGL and referenced via CSS) as HTML documents. The HTML rendering engine (68) processes these documents to create a scalable vector representation (SVF) that allows maintenance technicians to zoom into intricate component diagrams (e.g., from a full aircraft view to a single rivet) without pixelation. Touch-sensitive display (521) input enables precise contextual zooming on specific parts or procedure steps. The system integrates a secure wireless communication module (525) supporting enterprise Wi-Fi and satellite links for remote updates and access to centralized maintenance databases. Flash memory (504) stores an extensive library of vectorized technical content offline, essential for environments with limited connectivity. The interpreted page layout, including callouts, annotations, and interactive elements, remains preserved across all zoom levels, allowing technicians to follow complex multi-step procedures with clarity.
• Mermaid Diagram:

  graph TD
      A[Centralized Maintenance Database] --> B(Secure Wireless Sync);
      B --> C[Mobile Hand-Held Device (Ruggedized)];
      C -- "HTML/WebGL/CSS Schematics" --> D{HTML Rendering Engine};
      D -- "Generate SVF" --> E[SVF Content Library (Flash Memory)];
      C -- User Input (Touch) --> F[Processor];
      F -- "Zoom/Pan SVF" --> D;
      D -- "Render Scaled Content" --> G[Touch-Sensitive Display];
      G -- "Interactive Schematics" --> H[Maintenance Technician];
  

Derivative 3.2: Precision Agriculture Field Data Visualization

• Axis: Cross-Domain Application (Claims 1, 13, 20)
• Enabling Description: A mobile hand-held device (100) integrated into an agricultural drone or a ruggedized tablet for farm vehicles, displays real-time and historical agricultural data. This includes high-resolution satellite imagery, soil nutrient maps, yield data, and sensor readings (e.g., moisture, temperature, pest presence), all presented as web-based interactive dashboards using HTML, embedded SVG maps, and CSS. The HTML rendering engine (68) converts this spatial data into a scalable vector representation (SVF) of the farm landscape. Farmers or agronomists use the touch-sensitive display (521) to perform precise tap-based zooms on specific field plots, individual plants (if imagery resolution allows), or data points within a yield map. The device's wireless communication (525) uses specialized long-range low-power protocols (e.g., LoRaWAN) to receive updates from scattered field sensors. The flash memory (504) is optimized for storing large geographical SVF data sets for offline analysis in remote areas. The system preserves the spatial integrity and interpretive legend of the original data visualizations at all zoom levels.
• Mermaid Diagram:

  flowchart TD
      A[Field Sensors (LoRaWAN)] --> B(Gateway / Farm Server);
      B -- "Generate HTML/SVG Maps" --> C[Mobile Hand-Held Device (Ruggedized Tablet)];
      C -- "HTML Rendering Engine" --> D{Generate SVF};
      D -- "Store SVF Maps" --> E[Flash Memory];
      C -- "Touch Input (Tap/Pinch)" --> F[Processor];
      F -- "Scale/Pan SVF Maps" --> D;
      D -- "Render on Display" --> G[Touch-Sensitive Display];
      G -- "Zoomed/Panned Maps" --> H[Farmer/Agronomist];
  

Derivative 3.3: Scalable Genomic Visualization for Medical Diagnostics

• Axis: Cross-Domain Application (Claims 1, 13, 20)
• Enabling Description: A specialized medical mobile hand-held device (100), used by clinicians and researchers, displays complex genomic sequence data, protein structures, and patient-specific bioinformatics reports. This content is provided as interactive web pages, leveraging HTML, embedded SVG for genomic diagrams (e.g., circos plots, Manhattan plots), and advanced CSS for visualization styling. The HTML rendering engine (68) generates a scalable vector representation (SVF) of these genomic visualizations. The touch-sensitive display (521) allows users to zoom from a full chromosomal view down to individual nucleotide sequences or specific protein domains with high fidelity. Tap-based contextual zooms (e.g., tapping a gene locus to view its sequence) are supported, providing rapid access to nested levels of information. Data is transmitted via a secure, HIPAA-compliant wireless communication (525) protocol. Flash memory (504) stores patient-anonymized genomic templates and common reference sequences for rapid local rendering. The interpretive significance of genomic regions and annotations, as defined by the original page layout, is maintained across all scaling operations.
• Mermaid Diagram:

  classDiagram
      class MobileDevice {
          +Processor processor
          +WirelessComm wirelessComm
          +TouchDisplay touchDisplay
          +FlashMemory flashMemory
          +HTMLRenderingEngine htmlEngine
          +SVFGenerator svfGen
          +SVFRenderer svfRenderer
          +PatientDataCache patientData
      }
      class GenomicHTML {
          +HTMLCode html
          +CSSCode css
          +SVGGenomicData svg
      }
      class ScalableVectorRep {
          +Datum primaryDatum
          +List~Datum~ objectDatums
          +List~Vector~ vectors
          +List~Reference~ references
      }
      class TouchInput {
          +Gesture gesture
          +Coordinates coords
      }
      class DisplayOutput {
          +RenderedView view
          +ScaleFactor scale
          +PanOffset pan
      }
  
      MobileDevice "1" -- "1" HTMLRenderingEngine
      HTMLRenderingEngine "1" -- "1" GenomicHTML : processes
      HTMLRenderingEngine "1" -- "1" SVFGenerator
      SVFGenerator "1" -- "1" ScalableVectorRep : generates
      MobileDevice "1" -- "1" TouchInput : receives
      MobileDevice "1" -- "1" SVFRenderer
      SVFRenderer "1" -- "1" DisplayOutput : renders
      ScalableVectorRep "1" -- "*" FlashMemory : cached in
  

IV. Integration with Emerging Tech (Current Date: April 26, 2026)

This section describes integrating the patent's invention with AI-driven optimization, IoT sensors, and blockchain.

Derivative 4.1: AI-Driven Predictive Pre-fetching and Intelligent Zoom Framing

• Axis: Integration with Emerging Tech (Claims 1, 13, 20)
• Enabling Description: A mobile hand-held device (100) integrates an on-device AI inference engine (502d) with the HTML rendering engine (68). This AI engine analyzes user interaction patterns (e.g., scrolling speed, gaze direction, previous tap locations, contextual queries), biometric data (e.g., pupil dilation, heart rate variability indicating interest), and the semantic structure of the web page content to predict the user's next interaction. Based on this prediction, the AI dynamically instructs the HTML rendering engine to pre-fetch linked HTML documents or external media and pre-render scalable vector representations (SVF) for anticipated zoom levels and pan offsets into a dedicated high-speed cache (e.g., HBM, 504d). Furthermore, the AI employs "intelligent zoom framing," where a tap-based zoom on an HTML object automatically optimizes the scale factor and pan offset to frame the object (e.g., an image or paragraph) within the display (521) in an aesthetically pleasing and information-rich manner, potentially highlighting related content using dynamic CSS overlays or subtly adjusting the text flow for optimal readability without losing the original interpreted layout. The AI module utilizes federated learning to refine its predictive models based on aggregate, anonymized user behavior.
• Mermaid Diagram:

  sequenceDiagram
      User->>Device: Browse Web Page
      Device->>AI_Engine: Stream User Interaction (Touch, Gaze, Scroll)
      AI_Engine->>HTML_Renderer: Request Semantic Analysis
      HTML_Renderer-->>AI_Engine: Semantic Content + Layout Info
      AI_Engine->>AI_Engine: Predict Next Action (Zoom, Link Click)
      alt Pre-fetching
          AI_Engine->>Wireless_Comm: Request Next HTML/SVF
          Wireless_Comm-->>AI_Engine: Pre-fetched Content
          AI_Engine->>Cache: Store Pre-rendered SVF
      end
      alt Intelligent Zoom
          User->>Device: Tap HTML Object
          Device->>AI_Engine: Object Tap Event
          AI_Engine->>AI_Engine: Optimize Scale/Pan for Object + Context
          AI_Engine->>HTML_Renderer: Instruct Rendering (SF_optimized, Offset_optimized)
          HTML_Renderer->>Display: Render Optimized SVF
      end
  

Derivative 4.2: Edge-Networked Vector Translation with Content Validation

• Axis: Integration with Emerging Tech (Claims 1, 13, 20)
• Enabling Description: The mobile hand-held device (100) operates within an edge computing network, where the "translation of the first representation of the HTML document to generate a scalable vector representation" is distributed between the device and local edge servers. The device's HTML rendering engine (68) performs initial parsing and logical grouping, sending a lightweight structured intermediate representation (e.g., a DOM tree or semantic tokens) to an adjacent edge server (ES, 32a). The ES, equipped with specialized vectorization hardware (VPU, 32b) and a high-performance content translation service, generates the complete scalable vector representation (SVF) more efficiently than the mobile device alone. This SVF is then streamed back to the device. Before rendering, the device (100) employs a cryptographic hash (e.g., SHA-256) of the received SVF against a blockchain-recorded hash of the original content's SVF (stored during initial publication or proxy translation). This blockchain integration (525a) ensures content integrity and verifies that the displayed information has not been tampered with during transit or translation, crucial for critical applications.
• Mermaid Diagram:

  sequenceDiagram
      User->>Device: Request Web Page
      Device->>HTML_Renderer: Receive HTML/CSS
      HTML_Renderer->>Device: Parse HTML, Generate Intermediate Rep.
      Device->>Edge_Server: Send Intermediate Rep.
      Edge_Server->>Vector_Translation_Service: Generate SVF
      Vector_Translation_Service->>Blockchain_Service: Commit SVF Hash
      Blockchain_Service-->>Vector_Translation_Service: Transaction ID
      Vector_Translation_Service->>Edge_Server: SVF + Hash
      Edge_Server->>Device: Stream SVF + Hash
      Device->>Device: Verify SVF Hash (against Blockchain)
      Device->>HTML_Renderer: Render SVF (Verified)
      HTML_Renderer->>Display: Display Scalable Content
  

Derivative 4.3: IoT Sensor-Contextualized Dynamic Display Adjustments

• Axis: Integration with Emerging Tech (Claims 22, 23, 25)
• Enabling Description: A mobile hand-held device (100) used for remote monitoring and control integrates with a local IoT sensor network (525b). Environmental sensors (e.g., accelerometers, gyroscopes, biometric sensors) continuously transmit data via a secure mesh network to the device. This sensor data (e.g., user walking/running, vehicle vibration, proximity to a specific point of interest) is fed into the device's processor (502). The processor, executing an adaptive display algorithm, dynamically adjusts the user-selectable scale factor and pan offset of the rendered web page content based on the real-time context. For example, if the device's accelerometer detects rapid motion (e.g., user is running), the system automatically increases the default font size (zoom level) and simplifies the layout (reducing visual clutter) to improve glanceability. If biometric sensors indicate user stress, text color contrast might be automatically enhanced. When the device enters a specific geofence (from GPS IoT sensor data), a relevant section of a web-based manual could automatically zoom in. These dynamic adjustments are applied to the scalable vector representation (SVF) of the web content, ensuring the original page layout and functionality are preserved, but adapted for optimal user experience in a dynamic environment.
• Mermaid Diagram:

  graph TD
      A[IoT Sensor Network] --> B(Secure Mesh Communication);
      B --> C[Mobile Hand-Held Device];
      C -- "Real-time Sensor Data" --> D{Processor (Adaptive Display Algorithm)};
      D -- "User Motion / Environment / Biometrics" --> E[Identify Context];
      E -- "Adjust Scale Factor / Pan Offset" --> F[Scalable Vector Representation (SVF)];
      F --> G[HTML Rendering Engine];
      G -- "Render Context-Adapted Content" --> H[Touch-Sensitive Display];
      H --> User[User Interacting with IoT Data];
  

Derivative 4.4: Decentralized Content Distribution via IPFS with SVF Verification

• Axis: Integration with Emerging Tech (Claims 1, 13, 20)
• Enabling Description: The mobile hand-held device (100) utilizes a peer-to-peer content retrieval mechanism, specifically the InterPlanetary File System (IPFS), for accessing internet content. Instead of direct HTTP requests, the wireless communications device (525) resolves content identifiers (CIDs) on the IPFS network. HTML documents, CSS files, and embedded graphic assets are hosted on distributed IPFS nodes. The HTML rendering engine (68) receives this content, and the translation to scalable vector representation (SVF) occurs locally or via an adjacent IPFS-enabled edge node. Crucially, each SVF asset (e.g., for a specific HTML object or an entire page's vector structure) is cryptographically signed and its hash (CID) is immutable on IPFS. The device verifies the integrity and authenticity of each SVF component upon retrieval, ensuring that the displayed content originates from a trusted source and has not been altered, providing a robust solution for supply chain verification of digital documents or secure content delivery. User interactions for zooming and panning maintain this verifiable SVF integrity, as only the rendering parameters are manipulated, not the underlying content.
• Mermaid Diagram:

  flowchart TD
      A[User Request (CID)] --> B(Mobile Device);
      B -- "IPFS Lookup" --> C[IPFS Network (Distributed Nodes)];
      C -- "Retrieve HTML/CSS/Images" --> B;
      B --> D{HTML Rendering Engine};
      D -- "Parse & Group" --> E[Intermediate Rep.];
      E --> F{Local / Edge SVF Generator};
      F -- "Generate SVF & Sign" --> G[SVF Asset (IPFS CID)];
      G --> H[Device (SVF Verifier)];
      H -- "Verified SVF" --> I[HTML Rendering Engine (Render)];
      I --> J[Touch-Sensitive Display];
  

V. The "Inverse" or Failure Mode

This section describes versions of the invention designed to fail safely or operate in "low-power" or "limited-functionality" modes.

Derivative 5.1: Adaptive Degraded Mode Rendering for Low Battery/Poor Connectivity

• Axis: The "Inverse" or Failure Mode (Claims 1, 13, 20)
• Enabling Description: The mobile hand-held device (100) incorporates an adaptive degraded mode for displaying internet content. When battery levels fall below a critical threshold (e.g., <10%) or wireless signal strength (525) drops below a defined quality metric (e.g., high packet loss, low bandwidth), the processor (502) activates a limited-functionality mode within the HTML rendering engine (68). In this mode, the translation to scalable vector representation prioritizes text content over graphical elements. Image assets referenced in the HTML document are replaced with low-resolution placeholders or simple vector outlines. Complex CSS rules (e.g., animations, shadows) are disabled. The rendering engine also defaults to a "text-only" scalable vector representation, omitting object datums and vectors for purely decorative graphics. User-defined zoom levels (via touch-sensitive display, 521) are restricted to pre-defined textual magnification increments, ensuring readability while minimizing computational load and network traffic. The device automatically "zooms out" to provide a full-width text overview, reducing the need for panning and subsequent computationally intensive re-rendering, thus extending operational time under adverse conditions.
• Mermaid Diagram:

  stateDiagram
      direction LR
      Normal_Operation --> Low_Battery_Detected : Battery < Threshold
      Normal_Operation --> Poor_Signal_Detected : Wireless QoS < Metric
  
      Low_Battery_Detected --> Degraded_Mode : Activate
      Poor_Signal_Detected --> Degraded_Mode : Activate
  
      Degraded_Mode --> Prioritize_Text : HTML Rendering Engine
      Prioritize_Text --> Replace_Graphics : (Low-res/Outline)
      Replace_Graphics --> Simplify_CSS : (Animations/Shadows Off)
      Simplify_CSS --> Restrict_Zoom : (Pre-defined Text Increments)
      Restrict_Zoom --> Auto_Zoom_Out : (Full-width Text)
      Auto_Zoom_Out --> Degraded_Rendering : Display Limited SVF
      Degraded_Rendering --> Normal_Operation : (Battery Recharged OR Signal Restored)
  

Derivative 5.2: Secure Redaction and Content Simplification for Privacy-Critical Views

• Axis: The "Inverse" or Failure Mode (Claims 22, 23, 25)
• Enabling Description: A mobile hand-held device (100) designed for displaying sensitive information (e.g., financial statements, classified documents) from web pages incorporates a secure redaction mode. In response to a specific user input (e.g., a two-finger swipe combined with a long press on the touch-sensitive display, 521), or an external policy trigger (e.g., entering a public zone via GPS), the HTML rendering engine (68) dynamically modifies the scalable vector representation (SVF). Sensitive HTML objects (e.g., account numbers, personal identifiers identified by semantic tags or regular expressions during parsing) are either blurred, pixelated, or completely removed from the SVF stream before rendering. The bounding boxes for redacted content are preserved but filled with a solid, opaque color. For content simplification, the system can automatically collapse or hide extraneous sections (e.g., advertisements, less critical navigation elements) based on a pre-defined privacy policy. When the user zooms into a redacted area, the redaction remains, preventing accidental disclosure, illustrating a safe failure by restricting the detailed view of sensitive information, while still preserving the overall page layout. This is implemented through cryptographic access control layers within the SVF metadata.
• Mermaid Diagram:

  flowchart TD
      A[Web Page Content (HTML/CSS)] --> B{HTML Rendering Engine};
      B -- "Process to SVF" --> C[Scalable Vector Representation (SVF)];
      C -- "Semantic Analysis for Sensitive Data" --> D{Secure Redaction Module};
      D -- "Redaction Policy (User/External Trigger)" --> E[Identify Sensitive HTML Objects];
      E -- "Modify SVF (Blur/Pixelate/Remove)" --> F[Redacted SVF];
      F --> G[Touch-Sensitive Display];
      G -- "User Input (Zoom/Pan)" --> H[Processor];
      H -- "Render Redacted/Simplified SVF" --> G;
  

Derivative 5.3: Fault-Tolerant Rendering with Contextual Fallbacks

• Axis: The "Inverse" or Failure Mode (Claims 1, 13, 20)
• Enabling Description: The mobile hand-held device (100) implements a fault-tolerant HTML rendering system. If a critical component (e.g., the dedicated vector graphics unit, 502c, or a specific SVF font library in flash memory, 504) fails or encounters a rendering error, the HTML rendering engine (68) gracefully degrades its output rather than crashing. For instance, if a custom font specified in CSS cannot be rendered from its SVF definition, the system automatically substitutes a system default font while maintaining the original font size and bounding box, preserving the interpreted page layout. If a complex HTML object's scalable vector representation (SVF) cannot be generated due to a parsing error, the system renders an accessible text-based placeholder (e.g., an alt attribute for an image) instead of a blank space. Furthermore, the device can operate in a "contextual fallback" mode. If, for example, a tap-based zoom on an image fails to load the high-resolution bitmap (due to network failure), the system automatically defaults to displaying a lower-resolution cached version or a simplified vector outline of the image, while zooming out slightly to provide the user with surrounding contextual information from the page, ensuring continuous usability.
• Mermaid Diagram:

  stateDiagram
      direction LR
      Normal_Rendering --> Component_Failure : SVF Generator Fails / Font Load Error
      Normal_Rendering --> Network_Failure : Image Fetch Fails
      
      Component_Failure --> Degraded_Rendering_Fonts : Substitute Default Font
      Component_Failure --> Degraded_Rendering_Objects : Render Text Placeholder
      Network_Failure --> Degraded_Rendering_Images : Load Low-Res / Outline
      Network_Failure --> Degraded_Rendering_Context : Auto Zoom Out for Context
  
      Degraded_Rendering_Fonts --> Display_Degraded_SVF
      Degraded_Rendering_Objects --> Display_Degraded_SVF
      Degraded_Rendering_Images --> Display_Degraded_SVF
      Degraded_Rendering_Context --> Display_Degraded_SVF
  
      Display_Degraded_SVF --> User_Interaction
      User_Interaction --> Normal_Rendering : Component Recovered / Network Restored
  

Derivative 5.4: Read-Only Archival Mode with Reduced SVF Complexity

• Axis: The "Inverse" or Failure Mode (Claims 22, 23, 25)
• Enabling Description: The mobile hand-held device (100) can enter a "Read-Only Archival Mode" primarily for long-term document viewing and auditing in environments requiring minimal power consumption and maximum data preservation. In this mode, the generation of the scalable vector representation (SVF) for web page content is simplified. Dynamic elements (JavaScript, interactive forms, complex CSS animations) are stripped or rendered as static images within the SVF structure. The SVF generated is a "reduced complexity SVF," optimizing for storage footprint in flash memory (504) and minimal processing during rendering, specifically designed for archival purposes. User input via the touch-sensitive display (521) is restricted to basic pan and a limited set of fixed zoom levels (e.g., 1x, 2x, 4x), disabling continuous, real-time scaling and panning to conserve processing power. The device's processor (502) enters a deep sleep state between display updates, leveraging the static nature of the SVF. This mode preserves the "original page layout, functionality, and design" in a static, verifiable, and highly energy-efficient manner, acting as a controlled failure of full interactive capabilities for the benefit of archival integrity and battery life.
• Mermaid Diagram:

  graph TD
      A[Web Page Content (HTML/JS/CSS)] --> B{HTML Rendering Engine};
      B -- "Enter Archival Mode Trigger" --> C[Reduce SVF Complexity Module];
      C --> D[Strip Dynamic Elements (JS, Animations)];
      D --> E[Render Interactive Elements as Static];
      E --> F[Generate Reduced Complexity SVF];
      F --> G[Flash Memory (Optimized Storage)];
      G --> H[Processor (Deep Sleep)];
      H --> I[Touch-Sensitive Display (Limited Zoom/Pan)];
      I -- "Read-Only Archival View" --> User;
  

---

Combination Prior Art Scenarios

These scenarios combine the teachings of US Patent 10083154 with existing open-source standards, demonstrating how such combinations would render further incremental improvements obvious.

Combination 1: US10083154 + Mozilla Gecko / WebKit (Open-Source HTML Rendering Engines)

• Scenario Description: The core of US10083154 relies on "processing the HTML document with the HTML rendering engine to render a first representation of the HTML document having an interpreted page layout" (Claim 1). Open-source rendering engines like Mozilla's Gecko (used in Firefox) and WebKit (used in Chrome, Safari) were mature and widely adopted by the priority date. These engines already performed the fundamental steps described in the patent, such as "parsing the HTML document to identify the plurality of HTML elements; logically grouping content associated with HTML elements into HTML objects; generating page layout information including a bounding box for each HTML object; and storing information that links each HTML object with its corresponding page layout information" (Claim 1).
• Obviousness Argument: For a person skilled in the art, it would be obvious to adapt the internal data structures and rendering pipeline of an existing open-source HTML rendering engine (e.g., Gecko, WebKit) to extract or generate the "primary datum," "object datum," and "vectors" for each HTML object, and to store "references that link the HTML object to the vector that is generated" (Claim 1). The motivation would be to enable resolution-independent scaling and panning, which was a known desire for mobile browsing. The internal representation of these engines, often a Document Object Model (DOM) tree combined with a render tree, inherently contains the spatial and structural information necessary for this vectorization. Exposing this information and converting it into a scalable vector representation (SVF, as discussed in the patent) would be a straightforward engineering task for someone familiar with the rendering engine's architecture and the principles of vector graphics.
• Open-Source Standard: Mozilla Gecko / WebKit (as foundational open-source web rendering engines).

Combination 2: US10083154 + FreeType (Open-Source Font Rendering Library)

• Scenario Description: US10083154 details scaling text content, mentioning "scaling the font (i.e., typeface) that the text content portions of the web page are written in" (Detailed Description). The FreeType library, an open-source software development library, was available prior to the patent's priority date (first released in 1996) and provided the capability to render fonts using vector outlines (e.g., TrueType, OpenType) to bitmaps at arbitrary sizes and resolutions.
• Obviousness Argument: It would be obvious to integrate the FreeType library into the HTML rendering engine (68) of the mobile hand-held device (100) described in US10083154. When the HTML rendering engine translates HTML content into a scalable vector representation, the text elements would be represented as vector outlines or references to vector font glyphs managed by FreeType. Upon user input for zooming, FreeType would be invoked to render the text content at the precisely calculated, user-defined scale factor into a bitmap suitable for the display, maintaining the scalability and quality of the text within its bounding box without degradation. This directly addresses the scaling of text content mentioned in the patent. The combination is motivated by the desire to achieve high-quality, resolution-independent text display, which FreeType excels at.
• Open-Source Standard: FreeType library (for vector font rendering).

Combination 3: US10083154 + OpenStreetMap (Open-Source Geospatial Data)

• Scenario Description: The patent describes handling graphical content and enabling zooming/panning, with an example of a "mapping application" where "map tiles surrounding the viewed map could be downloaded and stored" (Detailed Description). OpenStreetMap (OSM) is a collaborative project to create a free editable map of the world, with its data often represented in vector formats (e.g., XML-based OSM data, converted to SVG or other vector tile formats).
• Obviousness Argument: Given the known need for scalable maps on mobile devices and the existence of scalable vector map data (such as that derived from OpenStreetMap), it would be obvious to apply the principles of US10083154 to such content. Specifically, HTML pages embedding OpenStreetMap data as SVG or vector tiles would be processed by the HTML rendering engine (68) to generate a scalable vector representation (SVF) of the map. User interactions via the touch-sensitive display (521) for zooming and panning would then leverage this SVF map data, enabling smooth, resolution-independent navigation across geographical regions. The patent's concept of defining datums, vectors, and bounding boxes for HTML objects directly translates to handling geographical features within an SVG map, where each feature (road, building, land parcel) can be considered an HTML object within the broader page context. The motivation is to provide a superior, scalable mapping experience on mobile devices, which was a recognized challenge.
• Open-Source Standard: OpenStreetMap (as a source of scalable vector geospatial data).