US 9792361

A technical analysis of U.S. Patent 9,792,361 reveals a system for location-based interaction with social networks, including the reporting of roadway conditions. As of April 26, 2026, the patent is assigned to Mimzi LLC, and a search of the U.S. Court of Appeals for the Federal Circuit (CAFC) 2026 dockets did not yield any specific appellate litigation concerning this patent.

Title: Photographic memory

Assignee: Mimzi LLC

Inventor: James L. Geer

Filing Date: May 22, 2013

Issue Date: October 17, 2017

Abstract: The patent describes a system and method for interacting with a social network database. A user's spoken request is transcribed and combined with metadata, including location data. This information is then sent from a mobile electronic device to a social network database. The database, in turn, generates a response based on the transcribed information and metadata, which is then returned to the mobile device and presented to the user. The system may also include the presentation of an advertisement to the user.

Overview of Independent Claims:

U.S. Patent 9,792,361 contains two independent claims: claim 1, which describes a system, and claim 16, which outlines a corresponding method.

Claim 1 (System): This claim details a computer-implemented system for presenting social network information to a mobile device based on its location and a user's input. In essence, the system is comprised of:

• A hardware data input port: This component receives information from the user of a mobile electronic device.
• An automated hardware processor: This processor creates a "user request" by combining the user's input with metadata, which must include the mobile device's location as determined by a hardware-based geospatial positioning system (like GPS).
• An automated hardware communication interface port: This port is responsible for several key functions:
  • It automatically sends the user request to a social network database that contains records of roadway conditions, with each record having associated time and location information.
  • It automatically receives location-dependent information from that social network database.
  • It can also send a message to the social network database to create a new record, which would include the time and location of a specific roadway condition.
• An automated hardware user interface: This component presents the received social network information to the user, and this information is ranked based on at least one "social network ranking factor."

In simpler terms, this claim describes the hardware components of a system that allows a user to provide input (e.g., a spoken query about traffic), combines that input with their location, and interacts with a social network database to both retrieve and contribute information about road conditions. The information presented back to the user is prioritized or "ranked" in some way.

Claim 16 (Method): This claim mirrors the functionality of the system described in claim 1 but is framed as a computer-implemented method. The key steps of this method are:

• Receiving a user request: This request is based on the user's input and associated metadata, including the location of the mobile device.
• Automatically transmitting the request: The user request is sent to a social network database that, as in claim 1, contains roadway condition records with time and location data.
• Automatically receiving social network information: The mobile device receives location-dependent information from the social network database.
• Communicating a message to create a new record: A message is sent to the database to create a new record about a roadway condition, including time and location information.
• Presenting the received information: The social network information is presented to the user, ranked according to at least one social network ranking factor.

Essentially, this claim protects the process or series of steps that the system in claim 1 performs. It covers the actions of receiving a user's request, interacting with a database of road conditions, and presenting ranked, location-specific information back to the user.

As a patent attorney, I can confirm that US patent 9,792,361, assigned to Mimzi LLC, has been the subject of litigation. Based on a review of dockets from the U.S. District Court for the Eastern District of Texas and other patent litigation sources, Mimzi LLC initiated a series of infringement lawsuits in June 2025.

Additionally, the patent is currently undergoing an ex parte reexamination by the USPTO, initiated by Unified Patents.

Here is a list of the known litigation involving US patent 9,792,361:

District Court Litigation

1. Mimzi, LLC v. Hyundai Motor Company, et al.

• Plaintiff: Mimzi, LLC
• Defendant: Hyundai Motor Company
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:25-cv-00599
• Filing Date: June 4, 2025
• Status: The case is currently active. The assigned judge is Rodney Gilstrap.

2. Mimzi, LLC v. Honda Motor Co., Ltd.

• Plaintiff: Mimzi, LLC
• Defendant: Honda Motor Co., Ltd.
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:25-cv-00600
• Filing Date: June 4, 2025
• Outcome: This case was voluntarily dismissed without prejudice by Mimzi, LLC. Each party was ordered to bear its own costs and fees. A dismissal without prejudice allows Mimzi to refile the lawsuit at a later date.

3. Mimzi, LLC v. Nissan Motor Co., Ltd.

• Plaintiff: Mimzi, LLC
• Defendant: Nissan Motor Co., Ltd.
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:25-cv-00601
• Filing Date: June 4, 2025
• Status: According to docket information, this case was closed on February 19, 2026.

4. Mimzi, LLC v. Subaru Corporation

• Plaintiff: Mimzi, LLC
• Defendant: Subaru Corporation
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:25-cv-00602
• Filing Date: June 4, 2025
• Status: The case is currently active.

5. Mimzi, LLC v. Mercedes-Benz AG

• Plaintiff: Mimzi, LLC
• Defendant: Mercedes-Benz AG
• Jurisdiction: U.S. District Court for the Eastern District of Texas
• Case Number: 2:25-cv-00603
• Filing Date: June 4, 2025
• Status: The case is currently active.

U.S. Patent and Trademark Office (USPTO) Proceedings

In addition to the district court cases, Unified Patents filed for an ex parte reexamination of US patent 9,792,361 on October 29, 2025. This proceeding requests that the USPTO reevaluate the patentability of the claims in light of prior art. The outcome of this reexamination could impact the ongoing litigation.

It is important to note that the inventor of the '361 patent, James L. Geer, has been involved in other patent litigation through different entities he founded, including JG Technologies LLC.

Proceedings Overview

As of the current date, May 29, 2026, a comprehensive search of public records and databases, including the USPTO's Patent Trial and Appeal Board (PTAB) search systems and general web searches, indicates that there are no Inter Partes Review (IPR), Post-Grant Review (PGR), or Covered Business Method (CBM) trial proceedings on file for U.S. Patent 9,792,361.

This means that the patent claims have not been challenged in an AIA trial before the PTAB, and therefore, no claims have been invalidated or sustained through these specific mechanisms. The patent's defensive posture for a defendant facing assertion remains largely dependent on its ex parte reexamination status and other factors, as no PTAB trial activity has hardened or narrowed the claims.

Strategic Summary

Currently, all claims of US Patent 9,792,361 are UNTESTED in the context of AIA trial proceedings (IPR, PGR, CBM) before the PTAB. There are no claims that have been formally canceled or sustained by the PTAB in such trials.

Given the absence of AIA trial proceedings, the estoppel landscape under 35 U.S.C. § 315(e)(2) is not applicable, as there are no previous IPRs or PGRs to create estoppel bars against petitioners (or their privies). This means that all prior-art grounds that could be raised under § 102 (novelty) or § 103 (obviousness) based on patents or printed publications are still available for a potential future IPR petition. Furthermore, PGRs allow challenges under §§ 101, 102, 103, and 112 (except best mode) and are available for patents that issued from applications filed on or after March 16, 2013, if filed within nine months of grant.

The prior analysis mentions that Unified Patents initiated an ex parte reexamination of US patent 9,792,361 on October 29, 2025. While Unified Patents is known for filing post-grant challenges, including IPRs and reexaminations, the ex parte reexamination is a distinct proceeding from an AIA trial. The outcome of the ex parte reexamination could impact the patentability of the claims but is not an AIA trial proceeding. The lack of IPR/PGR/CBM filings, despite the patent being asserted in district court litigation by Mimzi LLC and Unified Patents' involvement in an ex parte reexamination, is noteworthy.

Recommended Next Steps

• Monitor the Ex Parte Reexamination: While not an AIA trial, the ongoing ex parte reexamination initiated by Unified Patents is a critical development. Defendants should closely monitor the progress and outcome of this reexamination, as it could lead to the amendment or cancellation of claims in US9792361. The status and documents for this reexamination can be found via the USPTO's Patent Center by searching the patent number.
• Consider Initiating an AIA Trial: For a defendant facing assertion, the absence of prior IPR/PGR/CBM proceedings means that initiating one of these trials remains a viable option. A thorough prior art search, beyond what was considered during prosecution and the ex parte reexamination, would be crucial to identify strong grounds for invalidity under 35 U.S.C. §§ 102 or 103. Given the patent's priority date of July 29, 2008, an IPR would be the appropriate type of AIA trial, as the nine-month window for a PGR has long passed.

Inventors

The sole named inventor is James L. Geer. His employer at the time of filing is not specified, but the "Original Assignee" on the application was listed as "Individual," suggesting he was not employed by an entity that owned the patent rights at the time of filing.

Original assignee

The original assignee on the application was "Individual" (James L. Geer). There is no information to suggest James L. Geer, as an individual, shipped a product embodying the claims of the patent. His primary line of business as an individual inventor is not disclosed, and his status as an operating entity is not applicable.

Assignment timeline

• 2018-04-30 (executed) / recorded 2018-05-09 — Reel 042299/0074

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: GEER, JAMES L., MR.
  • Assignee: MIMZI, LLC
  • Correspondent: James L. Geer, 16909 E. Wagontrail Cir., Aurora, CO 80016. This correspondent recurs in this chain.
  • Context: Transfer of patent rights from the inventor to a newly formed LLC.

• 2023-05-22 (executed) / recorded 2023-05-23 — Reel 060123/0456

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: GEER, JAMES L., MR.
  • Assignee: MIMZI LLC
  • Correspondent: JAMES L. GEER, 16909 E. WAGONTRAIL CIR., AURORA, CO 80016. This correspondent recurs in this chain.
  • Context: Reassignment of patent rights from the inventor to the same LLC, likely for internal administrative purposes or to re-affirm ownership.

Timeline diagram

timeline
    title Ownership of US 9792361
    2008 : Application filed by Individual
    2017 : Patent issued
    2018 : Assigned to Mimzi LLC
    2023 : Reassigned to Mimzi LLC
    2025 : First infringement suits filed

NPE / troll-pattern signals

1. Shell-entity transfer — present. The patent moved from the individual inventor, James L. Geer, to Mimzi LLC. Mimzi LLC is identified as a plaintiff in multiple infringement lawsuits in the "Litigation summary" and does not appear to be an operating company that ships products embodying the claims. [cite: 042299/0074, 060123/0456]

2. Known asserter in the chain — present. Mimzi LLC is the current assignee and is actively asserting the patent in a series of infringement lawsuits filed in June 2025, as detailed in the "Litigation summary." The ex parte reexamination initiated by Unified Patents further corroborates Mimzi LLC's role as an asserter.

3. Repeat correspondent across the chain — present. James L. Geer, the inventor, is listed as the correspondent for both assignments to Mimzi LLC (Reel 042299/0074 and Reel 060123/0456). The provided context also notes that the inventor, James L. Geer, has been involved in other patent litigation through entities he founded (e.g., JG Technologies LLC), indicating a pattern of patent assertion.

4. Cascading transfers — not present. There are only two recorded assignments, both from the inventor to Mimzi LLC, separated by approximately five years. This does not indicate multiple consecutive transfers through chained LLCs in a short timeframe.

5. Pre-litigation transfer — not present. The most recent assignment to Mimzi LLC was executed on May 22, 2023, and recorded on May 23, 2023. The first infringement suits naming this patent were filed in June 2025, which is more than six months after the assignment.

6. Bankruptcy fire-sale — not present. No information suggests the patent was sold as part of bankruptcy proceedings.

7. Privateering — unclear. There is no explicit evidence of an operating company transferring the patent to Mimzi LLC to assert on its behalf against competitors.

8. Defensive aggregator (anti-NPE) — not present. The patent is being asserted by Mimzi LLC, not held by a defensive aggregator.

Verdict

NPE — high confidence

This verdict is based on multiple strong signals: the transfer from an individual inventor to Mimzi LLC (a shell-entity transfer), Mimzi LLC's active involvement in multiple infringement lawsuits as a plaintiff (known asserter), and the recurrence of the inventor, James L. Geer, as the correspondent for both assignment recordings, suggesting a coordinated assertion strategy.

USPTO Assignment Center Search for US9792361

Analysis of Prior Art for U.S. Patent 9,792,361

A thorough review of the prior art cited during the examination of U.S. Patent 9,792,361 ("the '361 patent") is crucial for understanding the patent's scope and potential vulnerabilities. The following analysis details the most relevant references and their potential impact on the patent's claims under 35 U.S.C. § 102, which pertains to novelty and anticipation. An invention is anticipated if every element as set forth in a patent claim is found, either expressly or inherently, in a single prior art reference.

The '361 patent, with a priority date of July 29, 2008, and a filing date of May 22, 2013, claims a system and method for a mobile device to interact with a social network database containing roadway condition records. The core of the invention lies in the combination of user input, location data, communication with a social network for roadway conditions, and the presentation of ranked results.

Cited Prior Art and Potential Anticipation

The following patent documents were cited by the USPTO examiner during the prosecution of the '361 patent.

---

1. U.S. Patent Application Publication No. 2009/0271479 A1 (O'Sullivan et al.)

• Full Citation: US 2009/0271479 A1
• Publication Date: October 29, 2009
• Filing Date: April 29, 2008
• Brief Description: O'Sullivan et al. describes a "Social navigation system" where users can share real-time, location-based information with others in their social network. The system allows users to report and receive information about traffic conditions, points of interest, and the location of friends. It explicitly mentions the use of GPS on mobile devices to provide location context to user-submitted reports, which are then shared and can be ranked or filtered based on relevance to the user, such as proximity or social network connection.
• Potential Anticipation of Claims: This reference appears highly relevant to the core concepts of the '361 patent.
  • Claim 1 & 16: O'Sullivan discloses a mobile electronic device (a hardware data input port and processor) that accepts user input regarding roadway conditions. It uses the device's location (determined by a geospatial positioning system) as metadata. The system then transmits this information (a user request) to a central database (a social network database) that stores and disseminates roadway conditions to other users. The information presented to users can be filtered by location, which is a form of ranking. The communication for creating new records of roadway conditions is also inherent in the system's reporting functionality. Therefore, O'Sullivan appears to anticipate the primary elements of independent claims 1 and 16. The specific term "social network ranking factor" in the '361 patent could be the only distinguishing element, depending on how broadly that term is interpreted.

---

2. U.S. Patent No. 7,739,036 B2 (Schildhouse)

• Full Citation: US 7,739,036 B2
• Publication Date: June 15, 2010
• Filing Date: August 4, 2006
• Brief Description: Schildhouse discloses a system for collecting and distributing real-time traffic information. The system gathers data from various sources, including user reports from mobile devices equipped with GPS. Users can submit information about traffic incidents, which is then aggregated and made available to other users. The system can provide location-specific traffic alerts and advisories.
• Potential Anticipation of Claims:
  • Claim 1 & 16: Schildhouse describes a system with a mobile device for user input, using GPS for location metadata, and communicating with a central database to both report and receive roadway conditions. This covers most of the elements of claims 1 and 16. The "social network" aspect and "social network ranking factor" may not be explicitly described in the same terms as the '361 patent, but the system's user-centric reporting and alerts have a community or social component. The core functionality of reporting and receiving location-based road conditions is present.

---

3. U.S. Patent Application Publication No. 2008/0133549 A1 (Aravamudan et al.)

• Full Citation: US 2008/0133549 A1
• Publication Date: June 5, 2008
• Filing Date: November 30, 2006
• Brief Description: Aravamudan et al. describes a system for providing location-based services and advertisements. It discusses collecting location data from a user's mobile device and using that data to provide relevant information and ads. While the primary focus is broader than just traffic, it includes the concept of users contributing location-tagged information to a central server, which can then be queried by others.
• Potential Anticipation of Claims:
  • Claim 15: This reference is particularly relevant to dependent claim 15, which adds the limitation of presenting a location-dependent advertisement. Aravamudan explicitly teaches this feature.
  • Claim 1 & 16: While not focused solely on roadway conditions, the general framework of a mobile device sending location-stamped user input to a central database that can be queried by others is disclosed. If the database were to contain roadway information, it would align closely with the '361 patent's independent claims. The key question for anticipation would be whether a database of general location-based information inherently includes the possibility of roadway condition records.

---

4. U.S. Patent No. 8,271,034 B2 (Sumio)

• Full Citation: US 8,271,034 B2
• Publication Date: September 18, 2012
• Filing Date: November 1, 2007
• Brief Description: Sumio describes a mobile communication terminal and a map information providing server. The system allows a user to obtain map information relevant to their current location. It includes functionality for other users to add information to the map data, effectively creating a collaborative, location-based information system. This can include information about traffic, businesses, or other points of interest.
• Potential Anticipation of Claims:
  • Claim 12: Sumio is highly relevant to dependent claim 12, which specifies that the user interface comprises a geographic map. Sumio's system is map-centric.
  • Claim 1 & 16: Sumio teaches a mobile device with location determination that communicates with a server to both receive and contribute location-based information. This user-contributed information can include road conditions. The system inherently allows for the creation of new records. The main potential distinction is the specific implementation of "ranking" and the "social network" terminology.

Summary of Prior Art Analysis

The prior art cited against the '361 patent, particularly O'Sullivan (US 2009/0271479 A1) and Schildhouse (US 7,739,036 B2), appears to disclose many of the core elements of the independent claims. Both describe systems where users of mobile, location-aware devices can report and receive information about road conditions within a community or network of users. The concept of ranking results based on location is also present in these references.

The patentability of the '361 patent seems to hinge on the specific interpretation of "social network database" and "social network ranking factor." If these terms are interpreted broadly to mean any user-based community and any method of prioritizing information (such as by proximity), then the claims may be vulnerable to anticipation challenges based on the cited art. Dependent claims, such as those related to advertisements (claim 15) and map-based interfaces (claim 12), also find strong precedent in the prior art.

Given the strength of this prior art, it is not surprising that the patent is currently undergoing ex parte reexamination, as these references provide a solid foundation for challenging the novelty of the claimed invention.

Obviousness Analysis of U.S. Patent 9,792,361

Date of Analysis: May 9, 2026
Priority Date of Patent: July 29, 2008
Standard: 35 U.S.C. § 103 (Pre-AIA)

An analysis of prior art existing before the July 29, 2008, priority date of U.S. Patent 9,792,361 ('361 patent) suggests that the independent claims of the patent would have been obvious to a Person Having Ordinary Skill in the Art (PHOSITA). A PHOSITA at the time would have had a degree in computer science or a related field, with experience in developing mobile, location-aware, and server-based applications.

The core concepts of the '361 patent involve using a GPS-enabled mobile device to send a user's location and input to a central database to both retrieve and contribute information about roadway conditions, with the returned information being ranked. By 2008, these individual concepts were well-established, and the motivation to combine them was driven by the clear market demand for real-time, user-generated traffic and navigation information.

---

Prior Art Combination 1: Waze / FreeMap Israel and Social Networking Principles

A compelling argument for obviousness can be made by combining the publicly known features of FreeMap Israel (the precursor to Waze) with well-understood principles of social networking for ranking user-generated content.

• Primary Reference: FreeMap Israel / Waze (publicly known and in use pre-2008)

  • Background: Founded in 2006, FreeMap Israel was a community project aimed at creating a free, user-generated digital map of Israel. By 2008, the project was incorporated as Waze. The system relied on users running an application on GPS-enabled mobile devices, which would transmit their location and speed data to a central server. This data was used to build out the map and provide real-time traffic information.
  • Elements Taught: FreeMap Israel teaches several key limitations of claim 1 of the '361 patent:
    • A system involving a mobile electronic device with a "hardware geospatial positioning system."
    • An "automated hardware processor" to define a user request based on user input (the act of driving and running the app) and metadata ("location of the mobile electronic device").
    • An "automated hardware communication interface port" that automatically transmits this location and speed data to a central database.
    • This database is a "social network database" in function, as it is built from community-provided data and serves that community.
    • Crucially, it is a database comprising "roadway condition records having time information and location information," as the core function was to collect traffic flow (a roadway condition) at specific times and locations.
    • The system inherently allows for creating new records (by users driving new roads or providing speed data on existing ones) and receiving location-dependent information (the generated traffic map).

• Secondary Reference: General Principles of Social Networking (well-known before 2008)

  • Background: By 2008, social networks like Facebook, Twitter, and review sites like Yelp were widely used. A core, well-understood feature of these platforms was the ranking of user-generated content to improve relevance and quality. This was often based on factors like user credibility (e.g., number of friends/followers, post history), popularity (likes, retweets, ratings), or proximity.
  • U.S. Patent Application Publication No. 2007/0192299 ("`299 Application"), filed in 2005, describes systems for "social mapping" where relationships and profiles of members are established. This highlights the state of the art in formalizing relationships and member data within a network.
  • Elements Taught: The `299 application and general knowledge of social networks teach the missing element:
    • "present[ing] the received social network information ranked according to at least one social network ranking factor."

• Motivation to Combine:

  A PHOSITA looking at the FreeMap Israel/Waze system would have recognized that the value of the user-generated traffic data was directly tied to its accuracy and reliability. A known problem with any user-generated content system is the potential for inaccurate or malicious data. The most common and obvious solution to this problem, readily observable in the successful social media and review sites of the era, was to implement a ranking and reputation system.

  Therefore, it would have been an obvious and logical step to apply social network ranking principles to the data in the FreeMap Israel/Waze system. For example, a PHOSITA would be motivated to rank the reliability of a traffic jam report based on the "credibility" of the user reporting it (e.g., how often their reports are corroborated by other users) or its "popularity" (e.g., how many other users in the same area are also experiencing slow speeds). This would be a predictable improvement to enhance the functionality and reliability of the existing community-based traffic system. The combination of a system like Waze with known social ranking factors would render the claims of the '361 patent obvious.

---

Prior Art Combination 2: Adding Speech-to-Text Functionality

This combination addresses dependent claims, like claim 2, which specify speech-to-text conversion.

• Primary System: The combined Waze / Social Ranking system described above.

• Secondary Technology: Mobile Speech Recognition

  • Background: By 2008, speech recognition was a rapidly advancing field. While still imperfect, its application on mobile devices was known. Dragon's NaturallySpeaking, which allowed for continuous speech recognition, had been available since 1997. Google launched its Google Voice Search app for the iPhone in 2008, which used cloud-based processing to handle speech-to-text queries. This demonstrates that using speech as an input method for mobile applications was a known and actively developing area.
  • Elements Taught: This established technology teaches the conversion of human speech into text for use as input in a mobile application.

• Motivation to Combine:

  The motivation to add speech input to a driving or navigation application like Waze would have been exceptionally high. A PHOSITA would immediately recognize the safety implications and user convenience of allowing hands-free operation. For a user wanting to report a "roadway condition" such as an accident, a police trap, or a traffic jam, speaking the report is significantly safer and easier than manually typing it on a mobile device while driving. This was not an inventive leap, but rather the application of a known technology (speech-to-text) to a known application (mobile navigation) to solve a very obvious problem (the danger of manual input while driving). This combination renders claims requiring speech input obvious.

Conclusion

The independent claims of US patent 9,792,361 describe a system that was a logical and predictable extension of technologies and platforms that existed prior to July 29, 2008. The core concept of a community-based, GPS-driven traffic information system was embodied by FreeMap Israel/Waze. Applying well-known social network ranking methods to improve the quality of this data would have been an obvious step for a person of ordinary skill in the art. Furthermore, adding speech-to-text for user input was a known technique to improve the safety and convenience of mobile applications, particularly those used while driving. Therefore, the claims of the '361 patent are likely invalid as obvious under 35 U.S.C. § 103.

Term Analysis of U.S. Patent 9,792,361

A detailed analysis of the prosecution history and bibliographic data for U.S. Patent 9,792,361 ("the '361 patent") provides the following information regarding its term, related applications, and projected expiration date.

Patent Term Adjustment (PTA)

The '361 patent was granted a Patent Term Adjustment (PTA) of 988 days. PTA is granted to compensate for delays caused by the U.S. Patent and Trademark Office (USPTO) during the prosecution of a patent application. This significant adjustment was calculated based on USPTO processing delays exceeding the statutory timeframes. No Patent Term Extension (PTE), which is typically associated with regulatory review delays for products like pharmaceuticals, was identified for this patent.

Continuity and Related Applications

The '361 patent, which issued from U.S. Application No. 13/900,495, filed on May 22, 2013, claims priority to a series of earlier applications. This establishes a patent family with several related members. The continuity data is as follows:

• Continuation of: Application No. 13/348,511, filed January 11, 2012, now abandoned.
• Which is a Continuation of: Application No. 12/182,130, filed July 29, 2008, now U.S. Patent No. 8,116,703.

Because the '361 patent is part of a chain of continuing applications, its term is calculated from the earliest non-provisional filing date in the chain.

Patent Family

The '361 patent is part of a larger family of patents and applications stemming from the same original disclosure. Notable members of this family, all assigned to Mimzi LLC and listing James L. Geer as the inventor, include:

• U.S. Patent No. 8,116,703: Issued from the earliest application in this chain.
• U.S. Patent No. 9,128,981: Another member of the patent family.
• U.S. Patent No. 11,100,163: A later-issued patent in the family.
• U.S. Patent No. 11,086,929: Another related patent.
• U.S. Patent No. 11,308,156: A further related patent.
• U.S. Patent No. 11,782,975: The most recently issued patent identified in this family.

No divisional applications were identified for the '361 patent itself.

Projected Expiration Date

The term of a U.S. patent filed after June 8, 1995, is generally 20 years from the earliest non-provisional application filing date to which it claims priority. For the '361 patent, the earliest effective filing date is July 29, 2008, from Application No. 12/182,130.

The standard 20-year term from this date would end on July 29, 2028. However, the granted PTA of 988 days extends this term.

• Earliest Filing Date: July 29, 2008
• Initial 20-Year Term End Date: July 29, 2028
• Patent Term Adjustment (PTA): + 988 days

Adding 988 days to July 29, 2028, projects the expiration date of U.S. Patent No. 9,792,361 to May 9, 2031.

Defensive Disclosure and Prior Art Generation for US 9,792,361

Publication Date: May 9, 2026
Disclosing Entity: [Internal Research Division]
Subject: Derivative Works and Obvious Variations of a System for Social Network-Based Roadway Condition Reporting

This document discloses a series of derivative inventions, technical variations, and cross-domain applications of the core concepts described in U.S. Patent 9,792,361 ("the '361 patent"). The purpose of this disclosure is to place these variations into the public domain, thereby establishing prior art against future patent applications claiming these or similar incremental improvements as novel. The following disclosures are described in sufficient detail to enable a Person Having Ordinary Skill in the Art (PHOSITA) to practice the inventions.

---

Derivative Disclosures Based on Core Claims

The following disclosures are extensions of the system described in Claim 1 of the '361 patent, which outlines a system for presenting location-dependent social network information based on a user's input.

Axis 1: Material & Component Substitution

Derivative 1.1: Vibro-Acoustic Interface for Eyes-Free Operation

• Enabling Description: This variation replaces the standard visual user interface and spoken input port with a system optimized for eyes-free and non-verbal communication, suitable for cyclists or motorcyclists. The hardware data input port is a piezoelectric sensor array integrated into the vehicle's handlebars or the user's gloves, configured to detect specific tap sequences or pressure patterns (e.g., double-tap for "pothole," long-press for "gravel"). The user's request is encoded from these haptic inputs. The automated hardware user interface is replaced with a combination of a high-fidelity tactile transducer providing patterned vibrations and a bone-conduction audio transducer. For example, a received "pothole ahead" alert is presented as a sharp, localized vibration on the left handlebar and a low-frequency tone via the bone-conduction headset, indicating a hazard on the left side of the travel path. The geospatial positioning system remains a core component, but the entire interaction loop is non-visual and non-verbal.

• Mermaid.js Diagram:

  sequenceDiagram
      participant User
      participant Piezo_Input as Piezoelectric Sensor Array
      participant Processor
      participant Comms_Port as Communication Port
      participant Social_DB as Social Network Database
      participant Haptic_UI as Vibro-Acoustic UI
  
      User->>Piezo_Input: Executes double-tap gesture
      Piezo_Input->>Processor: Transmits encoded "pothole" signal
      Processor->>Processor: Associates GPS coordinates
      Processor->>Comms_Port: Forms and transmits user request (pothole at location X,Y)
      Comms_Port->>Social_DB: Sends new roadway condition record
      Social_DB-->>Comms_Port: Acknowledges record & sends proximal alerts
      Comms_Port-->>Processor: Receives alert for "debris at location A,B"
      Processor->>Haptic_UI: Renders alert as specific vibration pattern & audio tone
      Haptic_UI->>User: Delivers tactile and bone-conduction feedback
  

Derivative 1.2: Integrated Vehicle CAN-Bus and Lidar Sensor Suite as Input Port

• Enabling Description: This derivative eliminates the need for manual user input by substituting the data input port with a direct interface to a vehicle's Controller Area Network (CAN-Bus) and its forward-facing Lidar/Radar sensors. The automated hardware processor continuously monitors the CAN-Bus for events indicative of a poor road condition, such as an ABS activation, a traction control event, or a sudden suspension compression/rebound signal from accelerometers. Simultaneously, it processes the Lidar point cloud data to identify physical anomalies on the road surface that correlate with the CAN-Bus events. When a correlation is confirmed (e.g., ABS event matches a Lidar-detected pothole), the processor automatically defines and transmits a roadway condition record to the social network database, complete with precise GPS coordinates, time, and a classification of the event (e.g., "Severe Bump," "Loss of Traction").

• Mermaid.js Diagram:

  flowchart TD
      A[CAN-Bus Monitor] --> C{Processor};
      B[Lidar/Radar Sensor] --> C;
      C -- Reads data --> D[Event Detection Module];
      D -- ABS/Traction Event --> E{Event/Anomaly Correlation};
      D -- Suspension Spike --> E;
      D -- Lidar Anomaly --> E;
      E -- Correlation Confirmed --> F[Request Generation];
      F -- "Pothole @ Lat/Lon" --> G[Communication Port];
      G --> H((Social Network Database));
  

---

Axis 2: Operational Parameter Expansion

Derivative 2.1: High-Density Urban Swarm Operation at Millimeter-Wave Frequencies

• Enabling Description: This disclosure describes the system operating in a dense urban environment with thousands of nodes (vehicles, delivery drones) per square kilometer. To handle the massive data volume and latency requirements, the communication interface port utilizes the 60 GHz millimeter-wave (mmWave) band for high-bandwidth, short-range vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication. Instead of each device querying a central database for every update, a localized, dynamic mesh network is formed. A new roadway condition record is first broadcast to peers within a 300-meter radius. A local "moderator" node (e.g., a V2I-equipped traffic light) aggregates and validates reports from multiple vehicles before forwarding a single, verified record to the larger social network database. The social network ranking factor becomes heavily weighted by the number of independent, localized confirmations.

• Mermaid.js Diagram:

  graph LR
      subgraph "Local Mesh Network (60 GHz mmWave)"
          V1[Vehicle 1] -- Reports Pothole --> V2;
          V1 -- Reports Pothole --> V3;
          V2[Vehicle 2] -- Confirms Pothole --> I1;
          V3[Vehicle 3] -- Confirms Pothole --> I1;
      end
      I1(Infrastructure Node) -- Aggregates & Verifies --> C[Communication Port];
      C -- Sends Verified Record --> DB[(Social Network DB)];
      DB -- Sends Regional Alerts --> C;
      C -- Broadcasts to Mesh --> I1;
  

Derivative 2.2: Nanoscale Road Surface Condition Reporting

• Enabling Description: This variation scales the system down to detect and report road surface characteristics at a microscopic level. The "mobile electronic device" is a specialized analysis vehicle equipped with an atomic force microscope (AFM) or a scanning acoustic microscope (SAM) mounted on a gimbaled, road-following arm. The data input port receives high-frequency topographical and material elasticity data from the microscope's cantilever. The processor analyzes this data stream in real-time to detect early signs of road distress, such as micro-cracking, aggregate polishing, or bitumen binder degradation, long before they become visible potholes. A "roadway condition record" in this context is a geo-tagged dataset of the surface's coefficient of friction or Young's modulus, which is transmitted to a database used by civil engineering and road maintenance authorities.

• Mermaid.js Diagram:

  classDiagram
      class AnalysisVehicle {
          +gps_module: GPS
          +comm_port: CommunicationPort
          +afm_scanner: AtomicForceMicroscope
          +processor: HardwareProcessor
          +scanRoadSurface()
          +analyzeSurfaceData()
          +generateMicroConditionRecord()
          +transmitRecord()
      }
      class AtomicForceMicroscope {
          +cantilever: Cantilever
          +laser_diode: Laser
          +photodetector: Photodetector
          +getTopographyData(): array
          +getElasticityData(): float
      }
      class MicroConditionRecord {
          +timestamp: datetime
          +location: GPSCoordinate
          +coefficient_of_friction: float
          +surface_hardness: GPa
      }
      AnalysisVehicle --> AtomicForceMicroscope : uses
      AnalysisVehicle --> MicroConditionRecord : creates
  

---

Axis 3: Cross-Domain Application

Derivative 3.1: Aerospace - Real-Time In-Flight Turbulence and Systems Anomaly Reporting

• Enabling Description: The core mechanism is applied to aviation. The "mobile electronic device" is an aircraft's avionics suite. The data input port is tied to the Flight Data Recorder (FDR) bus, capturing real-time data from accelerometers, pitot tubes, and engine sensors. A pilot's verbal report ("severe chop over waypoint XYZ") or an automated system trigger (e.g., vertical g-force exceeding a threshold) creates a "user request." The processor combines this with the aircraft's precise location (from GPS/INS) and altitude. The communication port transmits this record via ACARS or a satellite link to a "social network database" for atmospheric conditions, managed by air traffic control and shared among aircraft. The system presents received alerts (e.g., "moderate turbulence reported at your flight level in 50 nautical miles") on the navigation display, ranked by proximity, time, and the credibility of the reporting aircraft (e.g., reports from heavy jets are weighted higher).

• Mermaid.js Diagram:

  flowchart TD
      subgraph Aircraft_A
          A[FDR Bus Monitor] --> B{Event Trigger};
          C[Pilot Voice Input] --> B;
          B -- Turbulence Event --> D[Processor];
          D -- Associates 4D Location (Lat,Lon,Alt,Time) --> E[Request Formation];
          E --> F[SATCOM/ACARS Port];
      end
      F --> G((ATC Atmospheric Database));
      G --> H[Other Aircraft];
      H --> I[Avionics Display];
      I -- "Turbulence Alert Ahead" --> J(Pilot B);
  

Derivative 3.2: AgTech - Hyper-Local Soil and Pest Condition Reporting Network

• Enabling Description: This system is adapted for precision agriculture. The "mobile electronic device" is a sensor probe mounted on an autonomous tractor or carried by a farmer. The data input port consists of a multi-spectral camera and electrochemical sensors for soil pH, moisture, and nitrogen levels. A user's spoken input ("looks like corn borer") or an automated detection by the camera's image recognition algorithm triggers a request. The processor tags the finding with GPS coordinates to a sub-meter accuracy. The request is sent via a LoRaWAN or cellular connection to a shared agricultural database. Farmers in the same region receive alerts on their farm management software, ranked by proximity and the type of threat. For example, a "fusarium head blight" warning would be ranked higher than a "low nitrogen" report during a critical growth stage.

• Mermaid.js Diagram:

  sequenceDiagram
      participant Farmer/Drone
      participant Sensor_Probe
      participant Onboard_CPU
      participant Ag_Database as Agricultural Database
      participant Neighboring_Farms
  
      Farmer/Drone->>Sensor_Probe: Scan field section
      Sensor_Probe->>Onboard_CPU: Send soil/image data
      Onboard_CPU->>Onboard_CPU: Analyze for pests/deficiencies
      Onboard_CPU->>Ag_Database: Transmit record ("Corn Borer @ GPS XYZ")
      Ag_Database->>Neighboring_Farms: Push location-based alert
      Neighboring_Farms->>Farmer/Drone: Display alert on Farm Mgmt Software
  

Derivative 3.3: Consumer Electronics - Public Space Digital Infrastructure Quality Reporting

• Enabling Description: This application crowdsources the quality of public digital infrastructure like Wi-Fi hotspots or 5G cellular cells. A user's smartphone is the "mobile electronic device." The system runs as a background service. The "user input" is automatically generated when the device's networking stack detects a poor quality of service (e.g., high packet loss, low throughput, failed authentication on a public Wi-Fi network). The processor creates a record with the device location, the network SSID or Cell ID, and the specific performance metric. This is sent to a public database. Other users approaching that location can query the database to see real-time network quality, with data ranked by recency and the number of corroborating reports. The user interface could be an augmented reality overlay that shows color-coded indicators (green, yellow, red) over nearby cafes or transit stations, representing their Wi-Fi quality.

• Mermaid.js Diagram:

  stateDiagram-v2
      [*] --> Idle
      Idle --> Monitoring: User enters public space
      Monitoring --> Reporting: WiFi packet loss > 20%
      Reporting --> Monitoring: Report sent to DB
      Reporting: Create record (SSID, GPS, Loss%)
      Reporting: Transmit via cellular backup
      Monitoring --> Idle: User leaves public space
  

---

Axis 4: Integration with Emerging Tech

Derivative 4.1: AI-Powered Predictive Road Condition Modeling

• Enabling Description: The system is enhanced with a server-side AI model (e.g., a spatio-temporal graph neural network). The social network database feeds historical and real-time road condition reports, along with weather data (from NOAA) and traffic flow data (from DOT sensors), into the model. The AI learns to predict the formation of hazardous conditions, such as ice forming on a specific overpass when the temperature drops below a certain point with precipitation, even before a user reports it. When a user queries the system, they receive not only user-reported data but also AI-generated predictive alerts ("High probability of black ice on Exit 23 ramp in the next 30 minutes"). The "social network ranking factor" is augmented by an AI-calculated confidence score for the prediction.

• Mermaid.js Diagram:

  graph TD
      A[User Reports] --> D{AI Model};
      B[Weather Data] --> D;
      C[Traffic Flow Data] --> D;
      D -- Generates Predictions --> E[Predictive Alert Database];
      F[Mobile Device] -- Sends Request --> G{Query Handler};
      H[Social Network DB] --> G;
      E --> G;
      G -- Returns Merged Data --> F;
  

Derivative 4.2: IoT Sensor Fusion for Automated Record Generation

• Enabling Description: This derivative moves beyond the single-vehicle context and creates a fully automated reporting system using a distributed network of IoT sensors. The system integrates data from: 1) Piezoelectric strain gauges embedded in roadways and bridges to detect vehicle weight and structural stress. 2) Acoustic sensors alongside roads to detect the sound signature of hydroplaning or tire screeching. 3) Smart city cameras with computer vision algorithms to spot flooding or debris. A central server, acting as the "processor," fuses these disparate data streams. A "roadway condition record" is automatically created when sensor data from multiple sources cross-correlates (e.g., a strain gauge detects a heavy load, followed by a hydroplaning acoustic signature, and visual water detection from a camera), creating a high-confidence, automated "flooding" alert without any human intervention.

• Mermaid.js Diagram:

  flowchart LR
      subgraph IoT Data Sources
          A[Embedded Road Sensors]
          B[Acoustic Sensors]
          C[Smart City Cameras]
      end
      subgraph Central Server
          D{Sensor Fusion Engine}
          E[Condition Logic]
          F[Record Generator]
      end
      A & B & C --> D
      D -- Fused Data --> E
      E -- "Flooding" Condition Met --> F
      F --> G((Social Network DB));
  

Derivative 4.3: Blockchain-Verified Roadway Incident Ledger

• Enabling Description: To ensure the integrity and verifiability of reports, this variation uses a permissioned blockchain (e.g., Hyperledger Fabric) as the backend database. Each "roadway condition record" is a transaction on the distributed ledger. A user's mobile device signs the transaction with its private key, creating a non-reputable record. To add a record, a small gas fee (paid via micropayment or earned through credible reporting) is required, deterring spam. "Social network ranking" is achieved through an on-chain reputation score (similar to a non-transferable NFT or "Soulbound Token") associated with each user's public key. Reports from users with higher reputation scores are weighted more heavily by the smart contracts that govern data retrieval. This creates a trusted, immutable, and auditable history of roadway conditions, useful for insurance claims or municipal liability cases.

• Mermaid.js Diagram:

  sequenceDiagram
      participant Mobile_Device as Mobile Device
      participant Wallet as Crypto Wallet
      participant Smart_Contract as Validation Smart Contract
      participant Ledger as Blockchain Ledger
  
      Mobile_Device->>Wallet: Create report transaction
      Wallet->>Mobile_Device: Request signature for Tx
      Mobile_Device->>Wallet: Sign transaction with private key
      Wallet->>Smart_Contract: Submit signed transaction
      Smart_Contract->>Ledger: Validate signature & reputation score
      Smart_Contract->>Ledger: Write new block with report data
      Ledger-->>Smart_Contract: Confirm transaction
      Smart_Contract-->>Mobile_Device: Return confirmation
  

---

Axis 5: The "Inverse" or Failure Mode

Derivative 5.1: Graceful Degradation via Store-and-Forward Protocol

• Enabling Description: This variation is designed for operation in areas with intermittent or non-existent network connectivity (e.g., rural areas, tunnels). The "automated hardware communication interface port" is configured with a "low-power, limited-functionality" mode. When the device detects a loss of connection to the central social network database, it enters a store-and-forward state. All new user-generated reports are stored locally in a time-stamped, geo-tagged queue in persistent memory. The device simultaneously listens for peer devices using a low-power, ad-hoc wireless protocol (e.g., Bluetooth LE, Wi-Fi Direct). When another device is detected, they perform a handshake and sync their queues of pending reports, propagating information through the local ad-hoc network. Once a device in the ad-hoc network re-establishes a connection to the central server, it uploads its entire synchronized queue of reports, which are then integrated into the main database.

• Mermaid.js Diagram:

  stateDiagram-v2
      state "Connected Mode" as Connected {
          [*] --> Connected
          Connected --> Disconnected: Loss of Cellular/WAN
          Connected: Transmit reports directly to DB
      }
      state "Disconnected/Ad-Hoc Mode" as Disconnected {
          Disconnected --> Connected: Regain Cellular/WAN
          Disconnected: Store new reports locally
          Disconnected: Listen for peers via BLE/WiFi Direct
          Disconnected: Sync report queues with peers
      }
  

---

Combination Prior Art Scenarios

Combination 1: C-V2X Direct Communication Protocol for Latency-Critical Alerts

• Description: The system described in the '361 patent is combined with the 3GPP Cellular V2X (C-V2X) PC5 direct communication standard. While the core system uploads reports to a cloud-based social network database via a Uu interface (device-to-network), this combination adds a parallel PC5 interface. When a user reports a high-priority, latency-critical event like "vehicle driving wrong way," the processor not only sends the report to the cloud database but simultaneously broadcasts a standardized Basic Safety Message (BSM) or a new "Road Hazard Message" directly to all C-V2X enabled vehicles within a 1-2 km radius. This provides sub-second alerts to nearby vehicles, bypassing cloud latency for immediate threats, while the cloud database serves for non-real-time information and broader dissemination.

Combination 2: GeoJSON and OpenStreetMap for Interoperable Data Representation

• Description: The data format for roadway condition records is standardized using the open GeoJSON format (IETF RFC 7946). A pothole is represented as a Point feature, a flooded area as a Polygon feature, and a debris field as a LineString feature. Each feature's properties object contains the metadata (timestamp, report type, user credibility score, etc.). This standardized data is then rendered not on a proprietary map, but as an overlay layer on OpenStreetMap (OSM) tiles. Furthermore, verified, persistent hazards (e.g., a road washout) are contributed back to the core OpenStreetMap dataset, allowing any application using OSM data to benefit from the reports. This combines the '361 patent's reporting mechanism with open data standards for maximum interoperability.

Combination 3: Open-Source AI Framework for Transparent Ranking

• Description: The "social network ranking factor" is implemented not as a proprietary, black-box algorithm, but as a transparent, open-source model using the TensorFlow or PyTorch framework. The model's architecture (e.g., a simple logistic regression or a more complex gradient-boosted tree) and its input features (report recency, proximity, user reputation, number of confirmations, correlation with weather) are publicly documented. The model is trained on a public, anonymized dataset of road reports. This allows for public auditing of the ranking algorithm to ensure fairness and prevent manipulation. The system in the '361 patent becomes a data collection and presentation layer for a transparent, community-vetted ranking and filtering engine.