US 5742768

Summary of U.S. Patent 5,742,768

Title: System and method for providing and displaying a web page having an embedded menu

Assignee: The original assignee was Silicon Graphics Inc. The patent was later assigned to Microsoft Technology Licensing, LLC.

Inventors:

• Giuseppe Gennaro
• Jake McGowan
• Anne P. Wagner
• Kinney Wong
• Benjamin A. Zamora

Filing Date: July 16, 1996

Issue Date: April 21, 1998

Abstract: A method for providing a web page (26) having an embedded menu (46) to a web browser (24) and for displaying the web page (40) to a user of the web browser (24) are provided. A request for a web page (20) is received from a web browser (24). In response to the request, a web page (26) and an applet (28) associated with the web page (20) are packaged for transmission to the web browser (24). The web page (26) and the applet (28) are then transmitted to and downloaded by the web browser (24). When the web page (26) is displayed and the applet (28) is executed by the web browser (24), the applet (28) creates and manages an embedded menu (46) in the displayed web page (40) under control of the applet (28). This embedded menu (46) provides a user of the web browser (24) with a plurality of links (48) through one action in the displayed web page (40).

Independent Claims Overview

This patent contains three independent claims:

• Claim 1: Describes a method for a web server to provide a web page with an embedded menu. The process involves receiving a request for a web page from a web browser, packaging the web page with an associated applet, and sending both to the browser. The key aspect is that the applet, when run by the browser, creates and manages a menu directly within the web page. This embedded menu allows a user to access multiple hyperlinks through a single action, such as a mouse-over or click.

• Claim 9: This claim focuses on the client-side (the user's web browser) of the process. It outlines a method for the web browser to display a web page with an embedded menu. The browser downloads the web page and the accompanying applet from the server. Upon displaying the page, the browser executes the applet, which then generates and manages the embedded menu. This menu offers the user several links from a single interaction within the displayed page.

• Claim 16: This claim details the host system (the web server) that provides the web page with the embedded menu. It specifies a system comprising a data storage device for the web page and applet, a memory for the web server software, and a processor to execute the server software. The server is configured to receive a request for the web page, package the page and the applet, and transmit them to the requesting web browser. The applet is designed to create and manage the embedded menu on the user's displayed web page, providing multiple links from one user action.

Litigation Search

A search of the U.S. Court of Appeals for the Federal Circuit (CAFC) 2026 dockets did not reveal any pending litigation specifically for US patent 5,742,768 within the available information. However, this does not conclusively rule out the possibility of past or ongoing litigation that may not be reflected in the 2026 dockets. The provided information also notes that this patent family has a history of litigation, with a case filed in the Washington Western District Court.

Known Litigation for U.S. Patent 5,742,768

Based on information provided in the patent's public record and available litigation databases, U.S. Patent 5,742,768 has been involved in at least one court case. The details of this litigation are as follows:

Case Title: Walker Digital, LLC v. [Microsoft Corp.](/litigations/by-defendant/Microsoft%20Corp.) et al

• Plaintiff: Walker Digital, LLC
• Defendants: Microsoft Corp., Adobe Systems Inc., [Apple Inc.](/litigations/by-plaintiff/Apple%20Inc.), Autodesk, Inc., Corel Corporation, Intuit Inc., McAfee, Inc., SAP America, Inc., and Symantec Corporation
• Jurisdiction: U.S. District Court for the Western District of Washington
• Case Number: 2:10-cv-00825
• Filing Date: May 20, 2010
• Outcome/Status: The case appears to have been resolved. Public records indicate a "Stipulation and Order of Dismissal with Prejudice" was filed for various defendants throughout 2011 and 2012, suggesting settlements were reached. The case is officially terminated.

This litigation was initiated by Walker Digital, LLC, a patent assertion entity, against a number of major software companies. The assertion of U.S. Patent 5,742,768 was part of a broader campaign involving multiple patents.

Proceedings Overview

As of 2026-05-12, there have been no inter partes review (IPR), post-grant review (PGR), or covered business method (CBM) proceedings filed against U.S. Patent 5,742,768 at the Patent Trial and Appeal Board (PTAB). This absence means the patent has not been challenged at the PTAB, and consequently, none of its claims have been invalidated or sustained through an AIA trial proceeding. For a defendant, this indicates that the patent's validity has not been "hardened" by surviving a PTAB challenge, and all invalidity arguments based on prior art patents and printed publications remain available for a potential future IPR.

(No individual proceedings to list.)

Strategic Summary

The primary takeaway from the PTAB history of U.S. Patent 5,742,768 is the complete lack of any AIA trial proceedings. All claims of the patent—including independent claims 1, 9, and 16—are currently untested at the PTAB. This presents both an opportunity and a challenge for a potential defendant.

On one hand, the estoppel provisions of 35 U.S.C. § 315(e)(2), which prevent a petitioner from later raising invalidity grounds in district court that they "raised or reasonably could have raised" in an IPR, do not apply to any party at this time. A defendant accused of infringing this patent has a full suite of prior art patents and printed publications available to mount a challenge via an IPR petition. There is no risk of a prior petitioner having already made the best arguments, thereby estopping a new defendant from using them.

On the other hand, the absence of prior challenges means there is no record of the patent owner's arguments or the PTAB's claim construction findings to leverage. A defendant would be the first to litigate the patent's validity at the PTAB, which involves the cost and uncertainty of a completely new proceeding. The fact that this patent, issued in 1998 and now owned by a major technology company, has not faced a PTAB challenge is somewhat unusual, especially given the history of litigation noted in its file wrapper. This could suggest that past disputes may have settled before reaching a stage where an IPR was deemed necessary.

Recommended Next Steps

For a defendant currently facing an assertion of U.S. Patent 5,742,768, the path forward is clear from a PTAB perspective:

• Acknowledge the Clean Slate: It must be plainly stated that no PTAB proceedings are on file. The patent is not "IPR-hardened," and no claims have been canceled or substantively amended in response to such a challenge.
• Initiate a Prior Art Search: Since an IPR is a viable defensive option, a comprehensive prior art search focused on patents and printed publications predating the July 16, 1996, priority date should be the immediate first step. The goal is to identify strong grounds for a potential IPR petition based on anticipation (§ 102) or obviousness (§ 103).
• Evaluate IPR as a Defensive Strategy: An IPR offers a faster and often less expensive route to invalidate patent claims compared to district court litigation. Given that no party is estopped, filing a well-supported IPR petition could be a powerful tool to pressure the patent owner into a favorable settlement or to invalidate the asserted claims outright. The lack of a presumption of validity at the PTAB is a significant advantage for a petitioner.

Inventors

The named inventors are Giuseppe Gennaro, Jake McGowan, Anne P. Wagner, Kinney Wong, and Benjamin A. Zamora. All inventors assigned their interest to the original assignee, Silicon Graphics, Inc., at the time of filing, suggesting they were employees or contractors for the company. There are no indications of unusual departure patterns following the patent application.

Original assignee

The original assignee was Silicon Graphics, Inc. (SGI). At the time of filing in 1996, SGI was a major producer of high-performance computing solutions, including computer hardware and software. SGI was a prominent operating company that developed and shipped numerous products, including web server software and tools where technology like an embedded menu applet would have been relevant. The company's fortunes declined in the late 1990s, and after a 2009 bankruptcy, its assets were acquired by Rackable Systems, which renamed itself Silicon Graphics International. This entity was subsequently acquired by Hewlett Packard Enterprise in 2016.

Assignment timeline

A search of the USPTO Patent Assignment database reveals the following chain of ownership for US patent 5,742,768.

• 1996-10-08 (executed) / recorded 1997-06-09 — Reel 008598/0468

  • Conveyance: Assignment
  • Assignor: Giuseppe Gennaro, Jake H. McGowan, Anne P. Wagner, Kinney Wong, Benjamin A. Zamora (Inventors)
  • Assignee: Silicon Graphics, Inc.
  • Correspondent: John F. Luman, Silicon Graphics, Inc., 2011 N. Shoreline Blvd., Mountain View, CA 94043
  • Context: Standard assignment of invention from inventors to their employer.

• 2002-01-24 (executed) / recorded 2002-01-24 — Reel 012586/0717

  • Conveyance: Assignment
  • Assignor: Silicon Graphics, Inc.
  • Assignee: Microsoft Corporation
  • Correspondent: Merchant & Gould P.C., P.O. Box 2910, Minneapolis, MN 55402
  • Context: Part of a broader portfolio transfer between two major operating companies, likely resulting from a patent cross-licensing deal or settlement.

• 2010-03-23 (executed) / recorded 2010-04-06 — Reel 024346/0889

  • Conveyance: Assignment
  • Assignor: Microsoft Corporation
  • Assignee: Walker Digital, LLC
  • Correspondent: Christopher J. Fildes, Law Office of Christopher Fildes, 80 South Road, Unit 1, Harrison, NY 10528. This correspondent is a known agent for patent assertion entities.
  • Context: Transfer from a major operating company to a well-known patent assertion entity, less than two months before litigation was filed.

• 2014-12-09 (executed) / recorded 2014-12-09 — Reel 033990/0411

  • Conveyance: Change of Name
  • Assignor: Microsoft Corporation
  • Assignee: Microsoft Technology Licensing, LLC
  • Correspondent: Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
  • Context: Internal reorganization, creating a dedicated licensing entity for Microsoft's patent portfolio. This recording appears to be a nunc pro tunc (retroactive) administrative correction, as the patent had already been assigned to Walker Digital in 2010. The effective transfer out of Microsoft's control remains the 2010 assignment.

Timeline diagram

timeline
    title Ownership of US 5742768
    1996 : Filed by inventors
         : Assigned to Silicon Graphics Inc
    1998 : Patent issued
    2002 : Assigned to Microsoft Corp
    2010 : Assigned to Walker Digital LLC
         : Infringement suit filed vs Microsoft et al
    2014 : Microsoft internal name change recorded

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The 2010 assignment (Reel 024346/0889) transfers the patent from Microsoft, an operating company, to Walker Digital, LLC. Walker Digital is a limited liability company focused on patent licensing and assertion, not product development.

2. Known asserter in the chain — Present. Walker Digital, LLC, the assignee in the 2010 transfer (Reel 024346/0889), is a widely recognized patent assertion entity founded by Jay Walker. It has initiated numerous patent infringement lawsuits. This is confirmed by the litigation summary and public records from RPX and Unified Patents.

3. Repeat correspondent across the chain — Present. The correspondent for the transfer to Walker Digital, LLC (Reel 024346/0889) is Christopher J. Fildes. Public records and other assignment filings show this attorney frequently acts as a correspondent for patent assertion entities, including other Walker Digital entities. The recurrence of this specific agent in NPE-related transfers is a strong signal.

4. Cascading transfers — Not present. The chain of title does not show rapid, successive transfers through multiple LLCs.

5. Pre-litigation transfer — Present. The assignment to Walker Digital, LLC was executed on March 23, 2010, and recorded on April 6, 2010. The infringement lawsuit naming this patent (Walker Digital, LLC v. Microsoft Corp. et al) was filed on May 20, 2010, less than two months after the assignment was executed. This timing strongly suggests the transfer was made specifically to enable litigation.

6. Bankruptcy fire-sale — Not present. While SGI did eventually go through bankruptcy, this patent was sold to Microsoft years prior and was not part of a bankruptcy asset sale.

7. Privateering — Unclear. While Microsoft transferred the patent to an NPE that subsequently sued many of Microsoft's competitors (and, unusually, Microsoft itself), there is no public evidence of a formal agreement for Walker Digital to act on Microsoft's behalf. The inclusion of Microsoft in the suit makes a classic privateering arrangement unlikely, though it could have been part of a complex settlement strategy.

8. Defensive aggregator (anti-NPE) — Not present. The ownership chain does not terminate at a known defensive aggregator.

Verdict

NPE — high confidence

The ownership chain for US patent 5,742,768 displays multiple strong signals of NPE activity. The patent was transferred from an operating company (Microsoft) to a well-known patent assertion entity, Walker Digital, LLC (Reel 024346/0889). This transfer was recorded just weeks before Walker Digital filed a major infringement suit asserting the patent against numerous technology companies, representing a classic pre-litigation transfer. The correspondent of record for the transfer is also an attorney frequently associated with NPEs.

Verify at USPTO Patent Assignment Search for patent 5742768

As a senior US patent analyst, I have reviewed the file wrapper and prosecution history of US patent 5,742,768 to identify the most relevant prior art considered by the USPTO examiner. The following analysis details the references cited during the examination and their potential impact on the patent's claims.

The priority date for US patent 5,742,768 is July 16, 1996. Any reference published before this date qualifies as prior art.

Prior Art Analysis

1. U.S. Patent 5,572,643 (Judson)

• Full Citation: U.S. Patent 5,572,643 A, "Web browser with dynamic display of information objects during linking." Inventor: David H. Judson.
• Filing Date: October 19, 1995.
• Issue Date: November 5, 1996.
• Brief Description: The '643 patent discloses a web browser that displays "interstitial information objects," such as advertisements or other content, to the user in the time between when a hyperlink is selected and when the requested page fully loads. It describes downloading these objects in the background so they are available for immediate display during these idle periods. The patent mentions that these objects can be interactive and contain their own hyperlinks.
• Potential Anticipation of Claim(s):
  • Claims 1, 9, and 16: The Judson '643 patent was the primary reference considered by the examiner. However, it does not fully anticipate the claims of US 5,742,768. The key distinction lies in the implementation and purpose of the displayed object.
    • Judson describes displaying a separate information object (like an advertisement) during the idle time of linking to a new page. This object is not an "embedded menu" in the context of the primary web page's user interface.
    • In contrast, US 5,742,768 claims a menu that is embedded within the displayed web page itself and is triggered by a single user action (like a mouse-over a "hot spot") to provide navigational links without necessarily leaving the current page immediately. The menu in '768 is part of the page's persistent navigation structure, managed by an applet, whereas the object in '643 is transient and serves as filler content during latency.
  • Therefore, while Judson teaches the dynamic display of content with hyperlinks via a browser, it fails to disclose the specific claimed combination of an applet creating and managing an embedded, multi-link menu as a navigational element of the web page itself, activated by a single non-linking user action (e.g., a mouse-over).

2. "Re: Help with Menus" by John C. Dhabolt (Non-Patent Reference)

• Full Citation: John C. Dhabolt, "Re: Help with Menus," Usenet post to comp.lang.java, available via DejaNews search, June 13, 1996.
• Publication Date: June 13, 1996.
• Brief Description: This reference is a Usenet newsgroup posting where developers were publicly discussing how to create menus using the then-new Java programming language. The discussion explicitly involves creating a "pop-up menu" via a Java applet that appears when a user clicks on an item. The menu is described as presenting several choices, each of which can be a link to a different URL.
• Potential Anticipation of Claim(s):
  • Claims 1, 9, and 16: This non-patent reference presents a stronger argument for anticipation than the Judson patent and is highly relevant.
    • It discloses the use of a Java applet (as claimed in '768).
    • The applet is executed by the browser to create a menu.
    • The menu provides a plurality of links.
    • The menu is invoked by user action.
  • However, a subtle but critical distinction may have prevented the examiner from finding full anticipation under 35 U.S.C. § 102. The claims of US 5,742,768 specify that the menu is "embedded" in the displayed web page and can be invoked by positioning a pointer over a hot spot (a mouse-over action). The Usenet post discusses creating a "pop-up" menu that appears on a mouse click. The implementation details in the '768 patent (see FIG. 4, steps 72, 74) emphasize the mouse-over-to-display functionality, which allows a user to "scan the information content... without linking to new web pages." The Dhabolt reference, focusing on a click-to-invoke menu, does not explicitly teach this scanning capability or the specific "embedded" nature of the menu appearing on a non-clicking action like a pointer-over event. This distinction, while narrow, is likely what allowed the claims of US 5,742,768 to be granted over this prior art.

Here is a detailed analysis of the obviousness of U.S. Patent 5,742,768 based on the cited prior art.

Obviousness Analysis under 35 U.S.C. § 103

This analysis evaluates whether the claimed invention in U.S. Patent 5,742,768 would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA) at the time of the invention, which has a priority date of July 16, 1996. A PHOSITA in this context would be a programmer with experience in web development, including HTML, and familiarity with emerging technologies like the Java programming language and applets.

The core inventive concept of the '768 patent is the use of an executable applet, downloaded with a web page, to create and manage a menu embedded within the web page itself. This menu provides multiple hyperlinks that can be revealed through a single user action (e.g., a mouse-over), thereby overcoming the standard "one link, one action" paradigm of conventional HTML.

The primary prior art references cited by the patent examiner are:

• U.S. Patent 5,572,643 to Judson (filed Oct. 19, 1995), hereafter "Judson."
• A Usenet post by John C. Dhabolt titled "Re: Help with Menus" dated June 13, 1996, hereafter "Dhabolt."

Analysis of Independent Claim 1

Claim 1: A method for providing a web page having an embedded menu to a web browser, comprising: receiving a request for a web page; packaging the web page and an applet; and transmitting them to the browser, wherein the applet creates and manages an embedded menu with a plurality of links accessible through one action in the displayed web page.

An argument for obviousness can be constructed by combining the general knowledge of how applets worked in 1996 with the teachings of Judson and Dhabolt.

1. Receiving, Packaging, and Transmitting Web Page and Applet: These steps describe the fundamental operation of a web server delivering a web page containing an applet. By 1996, with the release of Java and its integration into browsers like Netscape Navigator, this client-server process was well-understood and constituted standard practice for web developers. This is background knowledge a PHOSITA would possess.

2. Applet Creates and Manages an Embedded Menu with a Plurality of Links: This is the crux of the claim.

   • Judson (US 5,572,643) discloses a "Web browser with dynamic display of information objects during linking." Judson teaches improving the user experience by providing more information during navigation. While it doesn't explicitly describe a multi-link menu triggered by a single mouse-over, it addresses the same problem as the '768 patent: the inefficiency of linear, one-to-one linking in HTML. Judson's solution involves dynamically displaying related information, establishing a clear motivation to use available technologies to present navigational options more efficiently.
   • Dhabolt, a Usenet posting from just one month before the '768 patent's filing date, provides a critical piece of the puzzle. The discussion "Help with Menus" was part of an ongoing public conversation among developers about how to implement user interface elements like menus using the new Java language within a web page. These discussions included creating pop-up menus that could contain lists of selectable items (which could be links). The very existence of this public query and discussion demonstrates that the idea of creating menus within a web browser's context was not only contemplated but was an active area of development in the art.

Motivation to Combine: A PHOSITA, aware of the navigational shortcomings of HTML as identified by Judson, would have been motivated to find a better way to present users with multiple links. The emerging Java applet technology was the clear tool for adding such dynamic functionality that HTML lacked. Upon encountering public discussions like Dhabolt, which concerned the specific implementation of menus using Java, the PHOSITA would have found a direct path to a solution. Combining Judson's goal (more efficient navigation) with the specific technique being discussed in the art (Java menus, as seen in Dhabolt) would lead directly to an applet that generates a menu of links. Placing this menu "embedded" in the page, rather than in a separate OS-level window, would be a natural design choice to keep the user experience contained within the browser context. Therefore, the combination of known applet functionality, the problem outlined in Judson, and the solution path discussed in Dhabolt would render the invention of Claim 1 obvious.

Analysis of Independent Claim 9

Claim 9: A method for displaying a web page having an embedded menu, comprising: downloading a web page and an applet; displaying the web page; and executing the applet, the applet creating and managing an embedded menu with a plurality of links accessible through one action.

This claim recites the client-side (browser) method corresponding to the server-side method of Claim 1. The obviousness argument is parallel and equally strong.

1. Downloading, Displaying, and Executing: This describes the standard operation of an applet-capable web browser in 1996. It was a fundamental, non-inventive process.

2. Applet Creating and Managing an Embedded Menu: As argued for Claim 1, a PHOSITA would be motivated by the problem space (inefficient navigation, per Judson) to apply the known capabilities of Java applets. The public discussion in Dhabolt shows that the specific concept of creating menus with Java was known and being actively pursued in the art. Executing an applet that performs this function is the direct and predictable result of combining these known elements.

Therefore, Claim 9 would have been obvious for the same reasons as Claim 1.

Analysis of Independent Claim 16

Claim 16: A host system executing a web server... comprising: a data storage device storing a web page and an associated applet... a memory device... and a processor... executing code for the web server such that the web server is operable to: receive a request... package the web page and the applet... and transmit the web page and the applet... such that the applet creates and manages an embedded menu...

This claim rephrases the method of Claim 1 in the form of a system (a server). The patentability of a system claim rises and falls with the underlying method it is configured to perform. Since the method described in Claim 1 would have been obvious by combining the teachings of Judson and Dhabolt with the general knowledge of a PHOSITA, a standard computer system (processor, memory, storage) programmed to execute this obvious method would itself be obvious. No special or non-standard hardware is claimed; the claim rests entirely on the functionality of the software, which has been shown to be obvious.

Conclusion

The independent claims of U.S. Patent 5,742,768 appear vulnerable to an obviousness challenge under 35 U.S.C. § 103. The patent addresses a known problem in the art—the limitations of linear HTML navigation—that prior art like Judson had already sought to solve. The specific solution of using a Java applet to create a menu was a topic of public discussion among developers, as evidenced by the Dhabolt Usenet post. A person having ordinary skill in the art in mid-1996 would have been motivated to combine the known functionality of applets with the ideas circulating in the development community to create the claimed embedded menu system as a direct and predictable solution to a well-known problem.

Analysis of Patent Term, Adjustments, and Family for U.S. Patent 5,742,768

Based on a thorough review of the USPTO's public records for U.S. Patent 5,742,768, the following is a detailed analysis of the patent's term, any applicable adjustments or extensions, and its relationship to other patent applications.

Patent Term and Expiration Date

U.S. Patent 5,742,768 was filed on July 16, 1996, and issued on April 21, 1998. As the application was filed before the American Inventors Protection Act of 1999, the provisions for Patent Term Adjustment (PTA) due to USPTO processing delays do not apply.

Under the patent laws in effect at the time (following the Uruguay Round Agreements Act), the term of the patent is 20 years from the earliest effective filing date. For this patent, the filing date is July 16, 1996.

• Filing Date: July 16, 1996
• 20-Year Term from Filing: July 16, 2016
• Projected Expiration Date: July 16, 2016

The USPTO's public records confirm that the patent's status is "Expired - Lifetime." This indicates that the patent reached the end of its statutory term and is no longer in force.

Patent Term Adjustments (PTA) and Extensions (PTE)

• Patent Term Adjustment (PTA): There are zero days of PTA for this patent. The laws creating PTA for USPTO delays apply to applications filed on or after May 29, 2000, and thus do not affect this 1996 application.
• Patent Term Extension (PTE): There is no indication in the file wrapper of any request for or grant of a Patent Term Extension under 35 U.S.C. § 156. Such extensions are typically granted to compensate for regulatory review delays (e.g., by the FDA) and are not applicable to the technology covered by this patent.

Continuity and Family Data

A review of the continuity data for Application No. 08/680,836, which matured into patent 5,742,768, shows the following:

• Continuation Applications: There are no continuation or continuation-in-part applications that claim priority to this application.
• Divisional Applications: There are no divisional applications that claim priority to this application.
• Parent Applications: This application does not claim priority to any earlier-filed U.S. or foreign applications. It is a standalone, non-provisional application.

The patent is a single-member family. There are no other U.S. patents or published applications that share a priority claim with U.S. Patent 5,742,768.

Summary Table

Category	Details
Application Number	08/680,836
Filing Date	July 16, 1996
Issue Date	April 21, 1998
Patent Term Adjustment (PTA)	0 days
Patent Term Extension (PTE)	0 days
Projected Expiration Date	July 16, 2016
Legal Status	Expired - Lifetime
Continuity	None (No parent or child applications)
Patent Family	Single-member family

Defensive Disclosure Document

Reference: U.S. Patent 5,742,768, "System and method for providing and displaying a web page having an embedded menu."

Publication Date: April 26, 2026

Abstract: This document discloses a series of technical implementations, derivative applications, and combinations with existing technologies that build upon the foundational concepts described in U.S. Patent 5,742,768. The purpose of this disclosure is to place these concepts into the public domain, thereby establishing them as prior art for the purposes of patentability examination. The disclosures herein are intended to render obvious any subsequent patent applications that claim these specific improvements or variations of an applet-driven, embedded menu on a web page.

---

Derivatives of Core Claim 1/9/16: Embedded Menu Generation and Management

1. Material & Component Substitution

• 1.1. WebAssembly (WASM) Module for Menu Rendering

  • Enabling Description: The executable applet described in the '768 patent, originally conceived as a Java applet, is replaced with a pre-compiled WebAssembly (WASM) module. The HTML page includes a <script> tag that fetches and instantiates the WASM module (menu_renderer.wasm). The module, written in a high-performance language like Rust or C++, exposes functions to the host JavaScript environment (e.g., renderMenu(menuData, parentElement)). Upon a "mouse-over" event on a designated hot-spot element, a JavaScript event listener invokes the WASM function, passing a JSON object defining the menu structure and the DOM element to which the menu should be appended. The WASM module performs the high-speed DOM manipulation to create and display the menu, offering superior performance over an interpreted Java applet for complex menus with thousands of items.

  • sequenceDiagram
        participant User
        participant Browser (JS)
        participant WASM Module
        participant Web Server
        User->>Browser (JS): Mouseover hot-spot
        Browser (JS)->>WASM Module: invoke renderMenu(jsonData, parentElement)
        WASM Module->>Browser (JS): Perform high-speed DOM manipulation
        Browser (JS)->>User: Display embedded menu
        Note right of User: Data for menu can be pre-fetched or fetched on demand.
        Browser (JS)->>Web Server: (Optional) GET /api/menu_data/b
        Web Server-->>Browser (JS): { "links": [...] }
    

• 1.2. JSON-LD for Semantic Menu Definition

  • Enabling Description: Instead of a proprietary data format, the menu's structure, links, and metadata are defined within the HTML page using a <script type="application/ld+json"> block. This JSON-LD (JavaScript Object Notation for Linked Data) object conforms to a schema.org vocabulary (e.g., SiteNavigationElement). The applet (now a standard JavaScript module) parses this structured data upon page load. When a user hovers over a hot spot, the script uses the pre-parsed JSON-LD data to dynamically construct the menu's HTML. This method decouples the menu's data from the rendering logic and makes the navigation structure machine-readable for search engines and accessibility tools.

  • graph TD
        A[Web Page Load] --> B{Parse JSON-LD in <script> tag};
        B --> C[Store Menu Structure as JS Object];
        D[User mouseover hot-spot] --> E{Retrieve Menu Object for hot-spot};
        E --> F[Generate HTML from Object];
        F --> G[Inject Menu HTML into DOM];
    

• 1.3. SVG-based Animated Menu System

  • Enabling Description: The embedded menu is not constructed from standard HTML DOM elements but is instead rendered as a Scalable Vector Graphics (SVG) object. An executable script (JavaScript) dynamically generates the <svg> markup. Menu items are represented as <g> (group) elements containing <rect> (background), <text>, and <foreignObject> tags for complex content. User interaction (hovering over a hot-spot) triggers SMIL (Synchronized Multimedia Integration Language) animations or CSS transitions defined within the SVG, causing the menu to appear with fluid effects like path-based motion or morphing shapes. Hyperlinks are implemented using <a> tags wrapping the SVG element groups.

  • classDiagram
        class SvgMenuApplet {
            +renderMenu(data, targetElement)
            -generateSvgMarkup(menuData)
            -applyAnimations(svgObject)
        }
        class MenuItem {
            -String text
            -String url
            -createSvgGroup()
        }
        SvgMenuApplet "1" *-- "many" MenuItem
    

• 1.4. WebSocket Push for Dynamic Menu Updates

  • Enabling Description: The client-side applet establishes a persistent WebSocket connection to the web server upon page load. The server can push real-time updates to the menu structure. For example, if a menu displays stock prices or the status of a system, the server pushes a JSON payload through the WebSocket whenever the data changes. The client-side applet receives the payload and seamlessly updates the content of the embedded menu, even while it is displayed, without requiring a page refresh or a new HTTP request from the client.

  • sequenceDiagram
        participant Browser
        participant Server
        Browser->>Server: Upgrade: websocket
        Server-->>Browser: 101 Switching Protocols
        loop Real-time Updates
            Server->>Browser: PUSH menu_update.json
            Browser->>Browser: Update menu DOM
        end
    

2. Operational Parameter Expansion

• 2.1. Industrial-Scale Hierarchical Menus for Big Data Visualization

  • Enabling Description: The embedded menu is designed to handle massive, deeply nested hierarchical data structures, such as a multi-terabyte file system or a complex organizational chart with over 1,000,000 nodes. The applet does not download the entire menu structure at once. Instead, hovering over a "hot spot" (e.g., a parent folder) triggers an asynchronous API call to fetch only the immediate children of that node. The menu employs a "virtual rendering" technique, where only the visible items in the menu's viewport are rendered as DOM elements, allowing the user to scroll through thousands of items at a single level without performance degradation.

  • stateDiagram-v2
        [*] --> Idle
        Idle --> Fetching: onMouseOverParentNode
        Fetching --> Rendering: onDataReceived
        Rendering --> Displayed: onDomUpdateComplete
        Displayed --> Fetching: onMouseOverChildWithChildren
        Displayed --> Idle: onMouseOut
    

• 2.2. Nanoscale Menu for Micro-display Interfaces

  • Enabling Description: This variation targets micro-displays (e.g., < 100x100 pixels) on wearable devices or embedded systems. The "web page" is a minimal graphical interface rendered by a microcontroller. The "applet" is a lightweight C++ routine. The "hot spot" is a small, designated pixel area. When a user's gaze (tracked by a micro-camera) or a physical micro-joystick moves the cursor over the hot spot, the applet renders a compact, pixel-optimized menu. The menu may only consist of a few iconic symbols, and selection is made by dwelling on an icon for a set duration (e.g., 500ms). This provides multi-link navigation on extremely constrained displays.

  • graph TD
        A[Gaze detected on hot spot] --> B{Timer > 100ms?};
        B -- Yes --> C[Render 4-icon menu];
        C --> D{Gaze detected on icon};
        D --> E{Timer > 500ms?};
        E -- Yes --> F[Execute link action];
        B -- No --> A;
        E -- No --> D;
    

3. Cross-Domain Application

• 3.1. Aerospace: In-Cockpit Avionics Display

  • Enabling Description: Within a glass cockpit's multifunction display (MFD), flight plan waypoints or system schematics are displayed. These waypoints and components act as "hot spots." When a pilot hovers the cursor over a waypoint using a trackball, an embedded menu appears, managed by the flight computer's display generation software (the "applet"). The menu provides links to execute pre-defined actions for that waypoint, such as "View Approach Plate," "Request Holding Pattern," or "Activate Missed Approach." This avoids deep menu diving through the main flight management system interface.

  • flowchart LR
        subgraph MFD Display
            A(Flight Plan View)
            B(Waypoint WPT01)
            C(Waypoint WPT02)
            A --- B & C
        end
        subgraph Embedded Menu for WPT02
            D[View STAR]
            E[View Approach]
            F[Enter Hold]
        end
        User(Pilot) -- hovers cursor --> C
        C -- triggers --> D & E & F
    

• 3.2. Agricultural Technology (AgTech): Precision Farming Dashboard

  • Enabling Description: A web-based dashboard displays a satellite map of a farm, with different fields rendered as polygons. Each polygon is a "hot spot." When a farm manager hovers their mouse over a specific field, a JavaScript module (the "applet") fetches and displays an embedded context menu. The menu provides links to control or view data for that specific field, such as "Activate Irrigation Zone 3," "View Soil Moisture Data," or "Dispatch Drone for Scouting." The menu items are hyperlinks that trigger commands to IoT-enabled farm equipment.

  • erDiagram
        FARM ||--o{ FIELD : contains
        FIELD {
            string FieldID
            string PolygonCoordinates
        }
        FIELD ||--|{ MENU_ACTION : provides
        MENU_ACTION {
            string ActionID
            string DisplayText
            string TargetURL
        }
        FIELD "is hot spot for" MENU_ACTION
    

• 3.3. Automotive: Infotainment System Control

  • Enabling Description: On a vehicle's central touchscreen, a map is displayed for navigation. Points of Interest (POIs) like charging stations or restaurants are displayed as icons ("hot spots"). When the user touches and holds a finger on a POI icon for > 300ms, the infotainment unit's UI software (the "applet") renders an embedded radial menu around the user's finger. The menu options ("links") allow for immediate actions like "Navigate Here," "Call Business," or "View Charging Status." This provides multi-function access without leaving the map view.

  • graph TD
        A(User Touch & Hold on POI) --> B{Display Radial Menu};
        B -- slides to 'Navigate' --> C(Set Destination);
        B -- slides to 'Call' --> D(Initiate Phone Call);
        B -- slides to 'Details' --> E(Show POI Info Panel);
    

4. Integration with Emerging Tech

• 4.1. AI-Driven Predictive Menu Generation

  • Enabling Description: The content of the embedded menu is not static. When the user hovers over a hot spot, a client-side JavaScript module sends contextual data (e.g., user ID, time of day, content of the current page) to a machine learning model endpoint. The AI model returns a personalized list of links predicted to be most relevant to that user in that specific context. The applet then renders this dynamic, AI-generated menu. For instance, hovering over a product image might show "View similar items" for one user but "Re-order now" for a user who has purchased it before.

  • sequenceDiagram
        participant User
        participant Browser
        participant AI Service
        User->>Browser: Hover on hot-spot
        Browser->>AI Service: POST /predict-menu (context)
        AI Service-->>Browser: return personalized_links.json
        Browser->>Browser: Render menu from JSON
        Browser-->>User: Display personalized menu
    

• 4.2. IoT-Integrated Status Menus

  • Enabling Description: A web page displays a dashboard for a smart factory. Each machine on the factory floor is represented by an icon, which is a "hot spot." The applet, upon page load, subscribes to an MQTT message broker, with topics corresponding to each machine. When a machine's IoT sensors publish a status update (e.g., temperature, pressure), the message is received by the applet. When the user hovers over a machine's icon, the embedded menu displays these real-time IoT data points as non-clickable items alongside clickable links for control (e.g., "Initiate Shutdown Sequence").

  • graph LR
        IoT_Sensor -- publishes --> MQTT_Broker;
        Browser_Applet -- subscribes --> MQTT_Broker;
        MQTT_Broker -- pushes message --> Browser_Applet;
        User -- hovers --> Machine_Icon;
        Machine_Icon -- triggers --> Embedded_Menu[Display Real-time Status & Control Links];
        Browser_Applet -- updates --> Embedded_Menu;
    

5. The "Inverse" or Failure Mode

• 5.1. Graceful Degradation to Static HTML
  • Enabling Description: The system is designed for resilience. The "hot spot" is an HTML anchor tag <a> with a href attribute pointing to a fallback, static HTML page that lists all possible links. The page also contains a JavaScript applet. If the user's browser executes JavaScript, the applet intercepts the mouseover event on the anchor tag, prevents the default browser behavior, and displays the dynamic, embedded menu. If JavaScript is disabled or the applet fails to load, the element remains a standard hyperlink. A user can still click it to navigate to the fallback page, ensuring functionality is preserved, albeit in a less efficient manner.

  • stateDiagram-v2
        state "JavaScript Enabled" as JS_On {
            [*] --> Active
            Active: onMouseOver -> showEmbeddedMenu()
            Active: onClick -> followMenuLink()
        }
        state "JavaScript Disabled" as JS_Off {
            [*] --> Fallback
            Fallback: onClick -> navigateToStaticPage()
        }
    

---

Combination Prior Art Scenarios

• 1. Combination with Apache HTTP Server (httpd) and Server Side Includes (SSI)

  • Enabling Description: The core HTML document is served by an Apache httpd server with the mod_include module enabled. The data for the embedded menus is not hardcoded in the page or fetched via a separate API call. Instead, the menu structure is defined in separate text files on the server. The main HTML page uses Server Side Includes (SSI) directives (e.g., <!--#include virtual="/menus/menu_data_b.txt" -->) inside a <script> tag. When the browser requests the page, Apache preprocesses it, injecting the contents of the menu data files directly into the HTML response. The client-side JavaScript applet then parses this pre-injected data to build the menus. This leverages a standard, open-source server technology to manage menu content separately from page logic.

• 2. Combination with ECMAScript 2022 (ES13) and Top-Level await

  • Enabling Description: The applet is implemented as a modern JavaScript module (<script type="module">). It uses the top-level await feature introduced in ECMAScript 2022. Instead of waiting for the page to load and then fetching menu data, the module itself can be written to fetch and process configuration data asynchronously at the module's root level. For example: const menuConfig = await fetch('/api/menus').then(res => res.json());. This ensures that all required menu data is fetched and parsed before any user interaction code is executed, simplifying the logic and preventing race conditions where a user might hover over a hot spot before its corresponding menu data has been loaded. This combines the patent's concept with a specific, modern, open web standard.

• 3. Combination with W3C Web Components Standard

  • Enabling Description: The entire menu system is encapsulated as a custom HTML element (e.g., <embedded-menu>) defined using the W3C's Web Components standard. The developer defines a custom element class in JavaScript (class EmbeddedMenu extends HTMLElement). This class handles all the logic: creating a Shadow DOM for styling encapsulation, defining slots for the "hot spot" content, and managing the display of the pop-up menu. A user implements the menu by simply including the tag in their HTML: <embedded-menu menu-src="/data/products-menu.json">Our Products</embedded-menu>. The menu-src attribute points to the data, and the text "Our Products" becomes the hot spot. This combines the '768 patent's functionality with the open standard for creating reusable, encapsulated UI components.