US 10534820

Here's a concise summary of US Patent 10534820:

Title: Enhanced buyer-oriented search results

Assignee:

• Current Assignee: Querytron LLC (assigned 2025-10-10)
• Original Assignee: Individual (assigned 2006-07-28 to RICHARD A. HEGGEM from MYHANDSHAKE.COM, INC.)

Inventor: Richard A. Heggem

Filing Date: 2006-01-27

Issue Date (Publication Date): 2020-01-14

Abstract:
The patent discloses a system and architecture designed to enhance Internet search results by incorporating buyer-oriented information. This includes seller-specific details, which can be based on or comprise ratings associated with registered selling entities linked to a URL. This enhanced information is presented alongside the corresponding search result, enabling a user to better evaluate and select which search results to investigate further.

Plain-Language Overview of Independent Claims:

• Independent Claim 1: This claim describes a method for enhancing search results. It involves maintaining a database that associates URLs with registered selling entities and their ratings from registered buying entities. When an internet search engine generates a list of search results with associated URLs, the method determines if any of these URLs are registered in the database. For each registered URL, it generates and presents seller-specific information, derived from the associated selling entities' ratings, alongside the search result in the list. This allows the user to make a more informed decision about which results to explore.

• Independent Claim 12: This claim is directed to a computer system configured to enhance search results. The system includes a processor and memory, with instructions that, when executed, cause the system to perform steps similar to Claim 1. Specifically, it involves storing associations between URLs, selling entities, and buying entity ratings. Upon receiving search results from an internet search engine, it identifies registered URLs, generates seller-specific information based on associated ratings, and presents this information in proximity to the corresponding search results.

• Independent Claim 13: This claim focuses on a method for enhancing search results by presenting enhanced buyer-oriented information. This information is initially not part of the search results page. Instead, the original search results page includes a link (e.g., "B2B" or "MyHandshake") that, when activated by a user, causes a new search results page to load. This new page then displays the enhanced buyer-oriented information (such as seller entity ratings) in conjunction with the search results.

• Independent Claim 16: This claim describes a method for generating custom seller-specific information for a user. It involves maintaining a database with registered selling entities, URLs, and ratings from buying entities, as well as storing user attributes and filter criteria for registered buying entities. When a user (who is a registered buying entity) submits query terms to an internet search engine, and search results are generated, the method identifies registered URLs. For each such URL, it determines which associated selling entities satisfy the user's filter criteria and generates seller-specific information that reflects this, presenting it with the search result.

• Independent Claim 17: This claim is for a method that filters search results based on whether a selling entity associated with a URL satisfies a buying entity's criteria. It entails storing attributes of buying entities and criteria of selling entities in a database. When a registered buying entity (user) submits query terms, and search results are generated, for each search result's URL, it determines if any associated selling entities' criteria are satisfied by the user's attributes. Search results for which no associated selling entity's criteria are satisfied by the user's attributes are then omitted or removed from the displayed search results.

USPTO and CAFC 2026 Dockets:
As of April 26, 2026, US Patent 10534820B2 is involved in litigation. Despite its listed "Expired - Lifetime" status on Google Patents, a recent search result indicates ongoing legal activity. Querytron LLC is involved in a case against Poshmark, Inc. regarding patent 10,534,820 B2, which is directed at "enhanced buyer-oriented search results." This litigation includes references to Federal Circuit opinions and USPTO filings, with a case mentioned as dismissed on July 08, 2026. The presence of ongoing litigation suggests that the "Expired - Lifetime" status may be inaccurate or refer to a different aspect of the patent's lifecycle, as active litigation typically concerns valid or recently expired patents. Prioritizing search results, the patent is currently subject to legal proceedings.

US Patent 10534820B2 is involved in multiple litigation cases. Querytron LLC, the current assignee, is consistently identified as the plaintiff in these patent infringement actions. The status for some cases has progressed to dismissal, while others remain active.

Here is a list of known litigation involving US Patent 10534820B2:

• Querytron LLC v. Poshmark, Inc.

  • Plaintiff(s): Querytron LLC
  • Defendant(s): Poshmark, Inc.
  • Jurisdiction: District of Delaware
  • Case Number: 1:25-cv-00956
  • Filing Date: July 30, 2025
  • Outcome/Current Status: Dismissed on July 08, 2026.

• Querytron LLC v. eBay, Inc.

  • Plaintiff(s): Querytron LLC
  • Defendant(s): eBay, Inc.
  • Jurisdiction: U.S. District Court for the District of Delaware
  • Case Number: 1:25-cv-00950
  • Filing Date: July 29, 2025
  • Outcome/Current Status: Voluntary dismissal without prejudice on September 19, 2025.

• Querytron LLC v. Amazon.com, Inc.

  • Plaintiff(s): Querytron LLC
  • Defendant(s): Amazon.com, Inc.
  • Jurisdiction: Eastern District of Texas
  • Case Number: 2:26-cv-00118 (As listed on the Google Patents page and linked to Amazon in search results).
  • Filing Date: Not explicitly available from the provided search results, but the case number indicates a 2026 filing year.
  • Outcome/Current Status: No specific outcome or current status is explicitly available from the provided search results, though it is mentioned within a list of active retail patent litigation.

The Google Patents page for US10534820B2 also indicates additional litigation, for which specific defendant names, precise filing dates, and detailed outcomes are not immediately available from the conducted searches:

• Jurisdiction: New York Southern District Court

  • Case Number: 1:25-cv-04751
  • Plaintiff(s): Likely Querytron LLC (based on common litigation patterns for this patent).
  • Defendant(s): Not explicitly available.
  • Filing Date: The case number indicates a 2025 filing year.
  • Outcome/Current Status: Not explicitly available.

• Jurisdiction: Delaware District Court

  • Case Number: 1:25-cv-00955
  • Plaintiff(s): Likely Querytron LLC.
  • Defendant(s): Not explicitly available.
  • Filing Date: The case number indicates a 2025 filing year.
  • Outcome/Current Status: Not explicitly available.

• Jurisdiction: Delaware District Court

  • Case Number: 1:25-cv-00957
  • Plaintiff(s): Likely Querytron LLC.
  • Defendant(s): Not explicitly available.
  • Filing Date: The case number indicates a 2025 filing year.
  • Outcome/Current Status: Not explicitly available.

• Jurisdiction: New York Southern District Court

  • Case Number: 1:25-cv-04761
  • Plaintiff(s): Likely Querytron LLC.
  • Defendant(s): Not explicitly available.
  • Filing Date: The case number indicates a 2025 filing year.
  • Outcome/Current Status: Not explicitly available.

Proceedings overview

There are no AIA trial proceedings (Inter Partes Review, Post-Grant Review, or Covered Business Method) on file for US Patent 10534820 as of today's date, 2026-08-14. This means the patent's claims remain untested by PTAB challenges.

Strategic summary

As of the current date, all claims of US Patent 10534820 are UNTESTED by any AIA trial proceedings before the PTAB. There have been no IPRs, PGRs, or CBMs filed against this patent. Consequently, there is no estoppel landscape established through PTAB proceedings, meaning all prior art grounds (§ 102, § 103, § 112) remain available for a potential petitioner to raise in a new PTAB challenge. The absence of PTAB activity suggests that the patent owner has not yet faced a direct challenge to the validity of its claims through these mechanisms.

Recommended next steps

Since no PTAB activity exists for US Patent 10534820, a potential defendant facing assertion of this patent should:

• Conduct a thorough prior art search: Evaluate the claims of US10534820 against existing prior art to identify strong invalidity grounds under 35 U.S.C. §§ 102 and 103.
• Consider filing an IPR petition: If strong prior art is found, an Inter Partes Review (IPR) petition could be a viable strategy to challenge the patent's validity before the PTAB.
• Monitor for future PTAB filings: Keep an eye on the USPTO PTAB E2E system for any newly filed petitions against US10534820, as the existence of litigation often prompts such challenges.
• Analyze claims for patentability: Given the patent's filing date (2006-01-27) and publication date (2020-01-14), consider whether any claims are vulnerable under pre-AIA or AIA standards.

Inventors

The sole inventor named on US Patent 10534820 is Richard A. Heggem. At the time of filing (2006-01-27), the patent was associated with MYHANDSHAKE.COM, INC., which later assigned its interest to Richard A. Heggem in 2006. This suggests that Richard A. Heggem was likely affiliated with MYHANDSHAKE.COM, INC. at the time of the invention and filing.

Original assignee

The patent lists "Individual" as the original assignee on Google Patents, but an early assignment recorded on 2006-07-28 indicates MYHANDSHAKE.COM, INC. as the assignor. This suggests MYHANDSHAKE.COM, INC. was the initial corporate entity associated with the patent.

Based on the patent's description, MYHANDSHAKE.COM, INC. operated an "on-line business-to-business connectivity service" accessible through "www.myhandshake.com". This service facilitated buyer-seller interactions and implemented the enhanced search results described in the patent, indicating that MYHANDSHAKE.COM, INC. likely shipped a product embodying the claims. Their primary line of business was providing an online platform for B2B connections. The current status of MYHANDSHAKE.COM, INC. is unclear from the provided information, but its patent assets have since been transferred.

Assignment timeline

The following assignment record is derived from the "Legal status" section on Google Patents for US Patent 10534820B2. Due to the lack of access to live USPTO Assignment Center search results, specific reel/frame numbers and correspondent information are not available for this analysis.

• 2006-07-28 (assigned) — Recording details unavailable

  • Conveyance: Assignment
  • Assignor: MYHANDSHAKE.COM, INC.
  • Assignee: RICHARD A. HEGGEM
  • Correspondent: Information unavailable
  • Context: Transfer of assignor's interest, likely from the original operating company to the individual inventor.

• 2025-10-10 (assigned) — Recording details unavailable

  • Conveyance: Assignment
  • Assignor: HEGGEM, RICHARD A.
  • Assignee: QUERYTRON LLC
  • Correspondent: Information unavailable
  • Context: Transfer of assignor's interest from the individual inventor to a new entity, Querytron LLC.

Timeline diagram

timeline
    title Ownership of US 10534820
    2006-01-27 : Filed
    2006-07-28 : Myhandshake Inc to Heggem
    2020-01-14 : Issued
    2025-07-29 : First suit filed by Querytron
    2025-10-10 : Heggem to Querytron LLC
    2026-07-08 : Poshmark case dismissed

NPE / troll-pattern signals

1. Shell-entity transfer — Present. The assignment from Richard A. Heggem to Querytron LLC (assigned 2025-10-10) involves an entity, Querytron LLC, that is identified as a plaintiff in multiple patent infringement lawsuits. The name "Querytron LLC" is generic and does not immediately suggest product development, which is common for licensing-only entities. This transfer indicates a shift from individual ownership to an entity primarily engaged in assertion.
2. Known asserter in the chain — Present. Querytron LLC, the current assignee (assigned 2025-10-10), is actively asserting this patent in multiple litigations against companies like Amazon.com, Inc., eBay, Inc., and Poshmark, Inc.. This consistent identification as a plaintiff in patent infringement suits aligns with the definition of a patent asserter or NPE.
3. Repeat correspondent across the chain — Unclear. Correspondent information (attorney name, firm, address) for the recorded assignments is not available from the provided data, preventing an assessment of this signal.
4. Cascading transfers — Not present. There are only two recorded assignments, spanning a significant period, not multiple consecutive transfers within a short timeframe.
5. Pre-litigation transfer — Present. The assignment to Querytron LLC occurred on 2025-10-10. However, Querytron LLC was already listed as the plaintiff in patent infringement lawsuits against eBay, Inc. (filed 2025-07-29) and Poshmark, Inc. (filed 2025-07-30). While the assignment date is after these initial filings, the transfer of ownership to an actively litigating entity is closely timed with the litigation, suggesting the ownership structure was formalized to support assertion, even if the recording post-dated initial filings.
6. Bankruptcy fire-sale — Not present. There is no indication in the provided information that Myhandshake.com, Inc. or Richard A. Heggem filed for bankruptcy or that the patent was sold in bankruptcy proceedings.
7. Privateering — Unclear. There is no explicit evidence in the provided information to suggest that Querytron LLC is asserting this patent on behalf of an operating company competitor.
8. Defensive aggregator (anti-NPE) — Not present. The current assignee, Querytron LLC, is an asserting entity, not a defensive aggregator.

Verdict

NPE — high confidence

The analysis shows a strong pattern indicative of an NPE. Querytron LLC, the current assignee (assigned 2025-10-10), is identified as the plaintiff in multiple patent infringement lawsuits against operating companies, with some of these lawsuits having been filed before the formal assignment to Querytron LLC. This combination of a generic-named assignee (Querytron LLC) and active, multi-party litigation strongly supports a high-confidence NPE verdict.

Verification search: USPTO Assignment Search for US10534820

To identify the most relevant prior art for US Patent 10534820, I will rely on the "Cited by" and "References" sections typically found in patent documents, which list prior art considered by the examiner and applicant. Since I cannot directly access the USPTO database in an interactive way to perform a live search and extract citations, I will analyze the publicly available information on Google Patents for US10534820B2 to identify its citations.

The "Prior art keywords" listed on the Google Patents page are: "seller", "search results", "specific information", "selling", "entities". These indicate the general technical areas the patent relates to.

Based on the provided patent text, US10534820B2 itself explicitly references two prior art applications in its "RELATED APPLICATIONS" section and within the detailed description:

• U.S. patent application Ser. No. 10/752,163
• U.S. patent application Ser. No. 11/153,929

Both are titled "CONNECTING BUSINESS-TO-BUSINESS BUYERS AND SELLERS," were filed by Richard A. Heggem, and are incorporated by reference in their entirety. Since these are directly cited within the patent and are applications by the same inventor, they are critical to understanding the claimed invention's novelty and non-obviousness under 35 U.S.C. § 102 and § 103. Prior art under 35 U.S.C. § 102 includes anything publicly known or available before the effective filing date of the claimed invention, such as previously patented inventions or descriptions in printed publications.

To determine which specific claims these prior art references potentially anticipate, a detailed claim-by-claim analysis against the full disclosure of each reference would be necessary. However, based on the patent's own description of these applications, they cover the underlying business-to-business connectivity service, the rating system, and the "ongoing relationship" concept that forms the foundation for the enhanced search results.

Here's an analysis of the explicitly mentioned prior art:

1. U.S. patent application Ser. No. 10/752,163

• Full Citation: U.S. patent application Ser. No. 10/752,163, titled "CONNECTING BUSINESS-TO-BUSINESS BUYERS AND SELLERS", filed on January 5, 2004.
• Publication/Filing Date: January 5, 2004 (Filing Date).
• Brief Description: This application describes a business-to-business connectivity system that allows buying entities to rate selling entities. The system associates these ratings with the selling entities. It also discusses the ability for buying and selling entities to specify attributes and criteria to filter each other, and to engage in a multi-phase "pipeline" relationship.
• Potential Anticipation (35 U.S.C. § 102):
  • Claim 1 & 12 (Method & System for enhancing search results): This prior art describes the core mechanism for buyers rating sellers and storing these associations. This foundational element, particularly the association of ratings with selling entities and the use of a B2B database, could anticipate parts of the "maintaining a database" and "generating seller-specific information based on said ratings" steps of Claim 1 and elements of the system in Claim 12.
  • Claim 16 (Generating custom seller-specific information): The concept of storing user attributes and filter criteria for registered buying entities, and using these to tailor information, is explicitly mentioned as being described in this application. This directly relates to the customization aspect of Claim 16.
  • Claim 17 (Filtering search results based on criteria): The idea of buying and selling entities ranking and filtering each other based on attributes and criteria, and preventing certain search results from being seen by unqualified buying entities, is disclosed. This directly impacts the novelty of the filtering mechanism in Claim 17.

2. U.S. patent application Ser. No. 11/153,929

• Full Citation: U.S. patent application Ser. No. 11/153,929, titled "CONNECTING BUSINESS-TO-BUSINESS BUYERS AND SELLERS", filed on June 15, 2005 (priority to US11/340,905 filed 2006-01-27). Note: The patent states this application is related to US10/752,163 and also describes the business-to-business connectivity service. The priority date for US10534820B2 is 2006-01-27, which is after the filing date of both referenced applications.
• Publication/Filing Date: The Google Patents page for US10534820B2 lists a priority date to US11/340,905 on 2006-01-27, and US11/153,929 is also mentioned as a related application. Searching for US11/153,929 reveals it was filed on June 15, 2005.
• Brief Description: Similar to U.S. patent application Ser. No. 10/752,163, this application describes the on-line business-to-business connectivity service, the mechanism for buying entities to rate selling entities, the concept of a "trusted buyer network," and the multi-phase "pipeline" relationship including the "ongoing relationship" phase.
• Potential Anticipation (35 U.S.C. § 102):
  • Claim 1 & 12 (Method & System for enhancing search results): Like the '163 application, this reference describes the core service for collecting and associating ratings with selling entities linked to URLs, which forms the basis for the enhanced search results.
  • Claim 16 (Generating custom seller-specific information): The patent explicitly states that user preferences and criteria for tailoring selling entity information are described in this application.
  • Claim 17 (Filtering search results based on criteria): This application also describes the mechanisms for buying and selling entities to rank and filter each other, and for omitting search results based on whether a buying entity satisfies a selling entity's criteria.
  • Implicitly related to aspects of other claims: Any specific features related to the details of ratings, such as composite ratings or breakdowns of ratings, or the "ongoing relationship" phase, would also find their basis in these foundational applications as described within US10534820B2.

These two patent applications are crucial prior art because US10534820B2 builds upon the systems and methods described within them. The novelty of US10534820B2 would, therefore, primarily lie in the integration of this existing B2B connectivity and rating system with Internet search engine results in a novel way, rather than the underlying rating or filtering mechanisms themselves.

Obviousness Analysis of US Patent 10534820 Under 35 U.S.C. § 103

To assess the obviousness of US Patent 10534820, we consider whether a person having ordinary skill in the art (PHOSITA) at the time of the invention (priority date 2006-01-27) would have been motivated to combine existing prior art references to arrive at the claimed invention. The PHOSITA in this context would be familiar with Internet search technologies, online business-to-business (B2B) platforms, and methods for presenting user-generated content or ratings.

The primary prior art references explicitly cited within US10534820B2 itself are U.S. patent application Ser. No. 10/752,163 (the '163 application) and U.S. patent application Ser. No. 11/153,929 (the '929 application), both titled "CONNECTING BUSINESS-TO-BUSINESS BUYERS AND SELLERS" and by the same inventor, Richard A. Heggem. These applications describe the foundational B2B connectivity service, including buyer/seller registration, attribute specification, rating mechanisms, and filtering capabilities.

The core inventive concept of US10534820B2 lies in integrating seller-specific, buyer-oriented information, derived from a B2B rating and relationship management system, directly into standard Internet search results. The background section of US10534820B2 highlights the problem that traditional Internet search results are "seller-oriented" and lack information about seller quality or trustworthiness, making it difficult for buyers to find "high-quality sellers."

A PHOSITA, aware of both the deficiencies of generic Internet search engines for B2B transactions and the existence of B2B platforms like MyHandshake.com (as described in the '163 and '929 applications) that provide trust and quality information, would have been motivated to combine these two areas. The motivation would be to enhance the utility of widely used Internet search engines by making the valuable seller-specific data (e.g., ratings, filter compatibility, trusted connections) immediately accessible to prospective buyers at the initial point of their search, thereby streamlining the process of finding trustworthy sellers.

Obviousness of Independent Claims

Claims 1 and 12 (Method and System for Enhancing Search Results)

• Claim Elements: These claims describe a method and system for enhancing Internet search results by maintaining a database associating URLs with registered selling entities and their ratings from registered buying entities. When an Internet search engine generates a list of search results with associated URLs, the method determines if any are registered, generates seller-specific information based on the associated ratings, and presents this information alongside the corresponding search result.
• Prior Art Teaching: The '163 and '929 applications extensively teach:
  • Maintaining a database associating registered selling entities with URLs they provide.
  • Establishing accounts for registered buying and selling entities.
  • Buying entities doing business with and providing ratings for selling entities, with these ratings being associated with the selling entities' accounts and stored in a "B2B" database.
• Motivation for Combination: The '163 and '929 applications describe a system for building trust and providing ratings within a dedicated B2B environment. However, they do not explicitly teach integrating this information into general Internet search results. A PHOSITA would recognize that users often begin their product/service search using general Internet search engines (like Google or Yahoo!, which were commonplace by 2006). The motivation to combine the B2B rating system with Internet search engines would be to bridge the gap between initial discovery and trust validation. By embedding seller-specific ratings directly into search results, the PHOSITA would enable buyers to quickly identify reputable sellers without having to navigate away to a separate B2B platform and perform a secondary search. This directly addresses the stated problem of generic search results offering "very little information... that will assist him in finding a high-quality seller." Whether implemented by the search engine directly or via a "toolbar" application, the technical steps of identifying URLs in search results and querying a database for associated ratings were well-known integration techniques in web development.

Claim 13 (Method for Accessing Enhanced Buyer-Oriented Information)

• Claim Elements: This claim describes a method where an original, un-enhanced search results page is displayed, which also comprises a link (e.g., "B2B," "Business-to-Business," or "MyHandshake"). Activating this link causes the user's Internet browser to load a new search results page that does contain enhanced buyer-oriented information, such as seller entity ratings.
• Prior Art Teaching: The '163 and '929 applications describe the underlying B2B system and the detailed buyer-oriented information it collects, including seller ratings. Standard Internet search engines provide un-enhanced search results.
• Motivation for Combination: Assuming, arguendo, that direct integration (as in Claim 1) was not initially feasible or desired (e.g., due to lack of cooperation from search engine providers, or to offer user choice), a PHOSITA would find it obvious to provide an option for users to view enhanced results. Presenting a link on an initial page to access a "more detailed" or "enhanced" view of related information on a separate page is a common and obvious user interface design pattern in web applications. The specific label for the link (e.g., "B2B" or "MyHandshake") would simply inform the user about the source or nature of the enhanced information, directly referencing the B2B service already described in the '163 and '929 applications.

Claim 16 (Generating Custom Seller-Specific Information)

• Claim Elements: This claim describes a method that, for a registered buying entity (user), uses the user's specified preferences and filter criteria (stored in the B2B database) to generate and present customized seller-specific information alongside search results.
• Prior Art Teaching: The '163 and '929 applications explicitly teach:
  • Registered buying entities specifying "attributes and characteristics" and "preferences and criteria" to the on-line B2B service.
  • Storing these attributes and criteria in association with the buyer's account.
  • The service providing "selling entity information that is tailored based specifically on the buying entity's specified preferences and filter criteria."
• Motivation for Combination: The '163 and '929 applications already disclose the capability to tailor selling entity information based on a buying entity's specified preferences and filter criteria within the B2B service. When extending the B2B service's functionality to enhance Internet search results (as motivated for Claim 1), it would be an obvious and desirable step for a PHOSITA to apply this existing customization. The purpose of "enhanced buyer-oriented search results" is inherently to make the results more relevant to the individual buyer. Therefore, leveraging pre-existing buyer profiles and filter criteria to personalize the displayed seller-specific information within the search results page would be a natural and obvious extension, improving the relevance and value proposition for the registered user.

Claim 17 (Filtering Search Results Based on Criteria)

• Claim Elements: This claim describes a method where, for a registered buying entity, if none of the selling entities associated with a search result's URL satisfy the buying entity's attributes (based on criteria specified by the selling entity), then that search result is omitted or removed from the displayed results.
• Prior Art Teaching: The '163 and '929 applications explicitly teach:
  • Buying entities specifying attributes and selling entities specifying criteria that a buying entity must satisfy to be of interest to the selling entity (reciprocal filtering).
  • Buying and selling entities being able to "rank and filter each other based on the extent to which they satisfy each other's criteria."
  • The patent itself describes the motivation for this, stating, "By preventing certain search results from being seen by unqualified buying entities, the selling entity is spared the burden of dealing with a buying entity in which the selling entity is clearly not interested."
• Motivation for Combination: The '163 and '929 applications establish a system for mutual filtering between buying and selling entities within the B2B platform. When applying the B2B system's intelligence to Internet search results, a PHOSITA would be motivated to extend this reciprocal filtering capability to the search results display. The explicit benefit noted in US10534820B2—sparing sellers from "clicks" by unqualified buyers and sparing buyers from engaging with disinterested sellers—provides a strong business rationale for implementing this filtering at the search results stage. This would reduce wasted effort for both parties, making the search more efficient and relevant, and is therefore an obvious application of the existing filtering logic to the new context of enhancing Internet search results.

In conclusion, the independent claims of US Patent 10534820B2 appear obvious in light of the '163 and '929 patent applications. These prior art references, by the same inventor, describe the core B2B connectivity, rating, and filtering systems. A PHOSITA, seeking to improve the utility and relevance of general Internet search results for B2B transactions, would have been motivated to combine the known functions of the B2B platform with a standard Internet search engine to present buyer-oriented information, customize that information based on user profiles, and filter results based on mutual criteria. Such combinations would have been logical extensions to address a known problem with readily available tools and techniques at the time of the invention.

As a patent analyst, I need to consult the official USPTO databases directly to provide accurate information on patent term adjustments (PTA), patent term extensions (PTE), continuation/divisional applications, related family members, and the projected expiration date for US Patent 10534820. While Google Patents offers some details, the authoritative source for this specific information is the USPTO. I do not have live, interactive access to the USPTO database, such as Patent Center or Public Search, to retrieve the full prosecution history, which would contain precise PTA calculations and details of related applications.

Therefore, I cannot provide definitive figures for Patent Term Adjustment (PTA) or confirm any Patent Term Extensions (PTE) without direct access to the USPTO's official records for US 10534820.

However, I can provide general information about these concepts:

• Patent Term Adjustment (PTA): This extends the term of a patent to compensate for certain delays caused by the USPTO during the examination process. It is calculated based on specific types of delays (A-delays, B-delays, and C-delays) less any applicant delays. The final PTA is added to the standard 20-year patent term, which typically begins from the earliest effective filing date. The USPTO provides this calculation at the time of patent issuance.
• Patent Term Extension (PTE): This is a separate provision that extends the patent term for patents on certain products, primarily human drugs, food or color additives, medical devices, animal drugs, and veterinary biological products, to restore time lost during regulatory review by agencies like the FDA. This patent, concerning enhanced search results, does not appear to fall into the categories eligible for PTE.
• Continuation Applications: A continuation application is filed by an applicant to pursue additional claims to an invention disclosed in an earlier, still-pending application (the "parent"). It uses the same specification and claims the priority date of the parent, but no new subject matter can be added. These are useful for seeking broader or different claims or to respond to competitor products.
• Divisional Applications: A divisional application is a separate application claiming a distinct invention disclosed but not claimed in a parent application. They are typically filed in response to a USPTO restriction requirement, which states that the original application claims more than one distinct invention. Divisional applications retain the priority date of the parent.
• Related Family Members: A patent family includes a group of related patent applications that cover the same invention and have at least one common inventor. These relationships are identified by priority claims. The original patent text for US10534820 explicitly references two U.S. patent applications as "RELATED APPLICATIONS": U.S. patent application Ser. No. 10/752,163 and U.S. patent application Ser. No. 11/153,929. Both are titled "CONNECTING BUSINESS-TO-BUSINESS BUYERS AND SELLERS" and are by the same inventor, Richard A. Heggem.
• Projected Expiration Date: The standard term for a U.S. utility patent is 20 years from the earliest effective filing date of the application. This date can be adjusted by PTA or PTE, and may be capped by terminal disclaimers. The filing date for US10534820 is January 27, 2006. Without any adjustments, the patent would expire on January 27, 2026. However, the Google Patents page currently lists the status as "Expired - Lifetime" and "Anticipated expiration 2026-01-27." Given the ongoing litigation, this "Expired - Lifetime" status may be inaccurate or refer to a different aspect of the patent's lifecycle. Since the issue date was January 14, 2020, and the filing date was January 27, 2006, the 20-year term from the filing date would indeed be January 27, 2026. Any PTA would extend this date.

To obtain the precise PTA, PTE details (if any), full family history, and definitive expiration date, direct access to the USPTO's public search tools (e.g., Patent Center) and a review of the patent's prosecution history (file wrapper) would be required.

As a Senior Patent Strategist and Research Engineer specializing in Defensive Publishing, my objective is to generate a comprehensive "Defensive Disclosure" document for US Patent 10534820. This document aims to create "Prior Art" that renders future incremental improvements by competitors "obvious" or "non-novel" by outlining derivative variations of the core claims across several technical axes.

---

Defensive Disclosure for US Patent 10534820

This disclosure describes various technical derivatives of the core independent claims of US Patent 10534820, aimed at pre-empting future patent claims by demonstrating prior art across multiple dimensions.

Derivatives of Independent Claim 1: Method for Enhancing Search Results

Claim 1: A method for enhancing search results, the method comprising: maintaining, in one or more databases, a plurality of associations, each association in the plurality of associations associating a uniform resource locator (URL) in a set of one or more URLs with a separate set of one or more registered selling entities, each of the one or more registered selling entities in the separate set of one or more registered selling entities being associated with one or more ratings from one or more registered buying entities that have done business with that selling entity; receiving, from an Internet search engine, a list of search results generated by the Internet search engine based on one or more query terms submitted by a user, the list of search results comprising one or more search results that are associated with one or more of the URLs in the set of one or more URLs; determining, for each search result in at least a subset of the one or more search results in the list of search results, whether that search result's associated URL is associated with one or more registered selling entities in the plurality of associations; generating, for each search result that is associated with one or more registered selling entities, seller-specific information that is based on the one or more ratings that are associated with the one or more registered selling entities that are associated with that search result's associated URL; and presenting, to the user who submitted the one or more query terms, the seller-specific information in association with that search result in the list of search results.

---

1.1 Derivative: Distributed Ledger for Immutable Ratings

• Axis: Material & Component Substitution
• Enabling Description: The "one or more databases" for maintaining URL-to-selling entity associations and buying entity ratings are replaced by a distributed, permissioned blockchain ledger. Each rating provided by a registered buying entity for a selling entity is recorded as a cryptographically signed transaction on the ledger, including the selling entity ID, buying entity ID, rating value, and timestamp. The URL association for each selling entity is also immutably stored on this ledger. When "determining" and "generating" seller-specific information, a blockchain node or a distributed application (DApp) directly queries the ledger state to retrieve verifiable, tamper-proof ratings and associations, which are then aggregated (e.g., using secure multi-party computation) and presented. This architecture ensures transparency and auditability of the underlying rating data, eliminating a single point of data manipulation.

flowchart TD
    UserQuery[User submits Query] --> SearchEngine[Internet Search Engine]
    SearchEngine --> SearchResults[Search Results List (URLs)]
    SearchResults --> B[URL Processor]
    B -- Registered URLs --> C{Blockchain Node / DApp}
    C -- Query Immutable Ledger --> D[Permissioned Blockchain Ledger]
    D -- Verifiable Ratings & Associations --> C
    C -- Aggregated Seller Info --> E[Seller Info Generator]
    E --> UserDisplay[Enhanced Search Results Display]

1.2 Derivative: Real-time, High-Frequency Trading Platform Enhancement

• Axis: Operational Parameter Expansion
• Enabling Description: The method is applied to real-time financial market data search results. Specifically, for algorithmic traders or institutional investors searching for specific financial instruments or trading strategies, the search results (e.g., for a particular stock, option contract, or trading algorithm provider) are enhanced. The "seller-specific information" becomes "broker/provider-specific performance metrics," including real-time execution latency statistics, slippage rates, order fill ratios, and historical uptime reliability scores for brokers or trading platform providers. These metrics are dynamically updated at sub-millisecond frequencies from direct market access (DMA) feeds and presented in association with search results on a high-refresh-rate financial terminal. The "ratings" could originate from quantitative performance benchmarks and audited trading logs.

sequenceDiagram
    participant U as User (Trader)
    participant FT as Financial Terminal
    participant SE as Market Data Search Engine
    participant BM as Broker Metrics Aggregator
    participant DMS as DMA/Market Data Stream
    U->>FT: Search Query (e.g., "AAPL stock, low latency brokers")
    FT->>SE: Submit Query
    SE->>FT: Raw Market Search Results (URLs/Broker IDs)
    FT->>BM: Request Real-time Broker Performance
    BM->>DMS: Continuously Ingest Market Data & Broker Logs
    BM-->>FT: Real-time Performance Metrics (Latency, Slippage, Uptime)
    FT->>U: Display Enhanced Search Results with Live Metrics

1.3 Derivative: Art & Collectibles Provenance Verification

• Axis: Cross-Domain Application
• Enabling Description: In the art and collectibles market, when a user searches for specific artworks, antiques, or rare items (e.g., "Andy Warhol silkscreen," "18th-century French armoire"), the search results (from specialized art databases or general web searches) are enhanced. The "seller-specific information" comprises "provenance scores" or "authenticity ratings" associated with galleries, auction houses, art dealers, or even individual sellers linked to the artwork's URL. These ratings are derived from verified transaction histories, expert appraisals, forensic analysis reports, and community trust networks (registered buying entities could be collectors, museums, or art historians). The information could indicate the number of times a piece has been authenticated, the reliability of past owners, or ratings for the seller's due diligence process, providing critical trust signals to prospective buyers in a market prone to counterfeits.

graph TD
    A[User Search: "Art Piece X"] --> B(Art Search Engine / Database)
    B --> C{Search Results (URLs of Sellers/Galleries)}
    C --> D[Provenance Data Aggregator]
    D -- Query Blockchain/Expert DB --> E(Immutable Provenance Ledger / Expert Registry)
    E --> D
    D -- Authenticity Scores & Seller Ratings --> F[Enhanced Display]
    F --> G[Collector/User]

1.4 Derivative: AI-Driven Intent-Based Rating Weighting

• Axis: Integration with Emerging Tech
• Enabling Description: An AI-driven optimization module, utilizing Natural Language Processing (NLP) and machine learning, dynamically analyzes the user's query terms, prior search history, and implicit behavioral patterns to infer their purchasing intent and priority criteria (e.g., "cost-sensitive," "quality-focused," "fast delivery essential"). Based on this inferred intent, the module dynamically adjusts the weighting applied to different components of the "one or more ratings" (e.g., product quality ratings, seller responsiveness, price competitiveness) when "generating" the composite seller-specific information. For instance, a "budget-friendly" query might prioritize cost-related positive ratings, while a "mission-critical" query emphasizes reliability scores. This real-time, personalized weighting optimizes the relevance of the presented seller-specific information without requiring explicit filter settings from the user.

sequenceDiagram
    participant U as User
    participant Q as Query Interface
    participant SE as Search Engine
    participant AI as AI Intent/Weighting Module
    participant BDB as B2B Database (Ratings, Attributes)
    participant EGI as Enhanced Info Generator
    participant DP as Display Processor
    U->>Q: Submits Query "affordable widgets fast"
    Q->>SE: Query
    SE->>AI: Raw Search Results (URLs)
    AI->>AI: Analyze Query/User Context (Infer "affordable", "fast")
    AI->>BDB: Request Seller Ratings & Attributes
    BDB-->>AI: Raw Ratings, Performance Metrics
    AI->>EGI: Dynamically Weighted Ratings (e.g., "delivery speed" weighted higher)
    EGI->>DP: Generate Seller-Specific Info
    DP->>U: Display Enhanced Results

1.5 Derivative: "Rating Decay" and "Performance Variance" Display

• Axis: The "Inverse" or Failure Mode
• Enabling Description: The "generating" of seller-specific information incorporates a temporal decay function for ratings and explicitly includes "performance variance" metrics. Individual "one or more ratings" are assigned a half-life, meaning older ratings (e.g., more than 12 months) contribute proportionally less to a composite score, ensuring the displayed information reflects recent seller performance. Additionally, the seller-specific information explicitly includes a statistical variance metric (e.g., standard deviation) or a "rating volatility index" alongside the average rating, indicating the consistency of the seller's performance over time. A highly variable rating suggests inconsistent service, even if the average is high. In a "low-functionality" mode, only the current 3-month average and variance are shown, omitting granular historical data to save bandwidth or processing power.

stateDiagram
    state "Search Result Display Flow" as SRDF
    SRDF --> QuerySubmitted: User Input
    QuerySubmitted --> RawResultsReceived: Search Engine Response
    RawResultsReceived --> RatingAggregation: Filter & Match URLs
    
    state "Rating Aggregation" as RA {
        [*] --> CollectHistoricalRatings: For Matched URLs
        CollectHistoricalRatings --> ApplyDecayFunction: Weighting by Recency
        ApplyDecayFunction --> CalculateVariance: Measure Consistency
        CalculateVariance --> GenerateCompositeRating: Weighted Average
        GenerateCompositeRating --> DisplayEnhancedInfo: Incorporate Variance
    }
    
    RatingAggregation --> DisplayEnhancedInfo
    DisplayEnhancedInfo --> UserViewed: Presentation
    UserViewed --> [*]

---

Derivatives of Independent Claim 12: Computer System for Enhancing Search Results

Claim 12: A computer system for enhancing search results, the computer system comprising: a processor; and a memory coupled to the processor and storing instructions which, when executed by the processor, cause the computer system to perform a method, the method comprising: maintaining, in one or more databases, a plurality of associations, each association in the plurality of associations associating a uniform resource locator (URL) in a set of one or more URLs with a separate set of one or more registered selling entities, each of the one or more registered selling entities in the separate set of one or more registered selling entities being associated with one or more ratings from one or more registered buying entities that have done business with that selling entity; receiving, from an Internet search engine, a list of search results generated by the Internet search engine based on one or more query terms submitted by a user, the list of search results comprising one or more search results that are associated with one or more of the URLs in the set of one or more URLs; determining, for each search result in at least a subset of the one or more search results in the list of search results, whether that search result's associated URL is associated with one or more registered selling entities in the plurality of associations; generating, for each search result that is associated with one or more registered selling entities, seller-specific information that is based on the one or more ratings that are associated with the one or more registered selling entities that are associated with that search result's associated URL; and presenting, to the user who submitted the one or more query terms, the seller-specific information in association with that search result in the list of search results.

---

2.1 Derivative: Hardware-Accelerated Rating Lookup and Aggregation System

• Axis: Material & Component Substitution
• Enabling Description: The "computer system" comprises a general-purpose host processor and specialized hardware acceleration units, such as Field-Programmable Gate Arrays (FPGAs) or Application-Specific Integrated Circuits (ASICs), dedicated to the "determining" and "generating" steps. The "one or more databases" storing URL associations and ratings are implemented using ultra-low-latency in-memory databases (e.g., Redis, Aerospike) accessible directly by the FPGA/ASIC via high-speed interfaces (e.g., PCIe). The FPGA/ASIC is pre-programmed with logic gates optimized for parallel URL matching, hash table lookups of selling entity IDs, and arithmetic operations for composite rating generation (e.g., weighted averages, standard deviations). This offloads computationally intensive tasks from the main processor, achieving sub-microsecond response times for enhancing search results, critical for high-volume or real-time applications.

flowchart LR
    A[User Query] --> B(Internet Search Engine)
    B --> C[Raw Search Results (URLs)]
    C --> D[Host CPU]
    D -- Send URLs for Enhancement --> E[PCIe Bus]
    E --> F[FPGA/ASIC Accelerator]
    F -- Query In-Memory DB (High Speed) --> G[Ratings & URL Associations DB]
    G -- Return Data --> F
    F -- Generate Seller Info (Parallel Logic) --> E
    E --> D
    D -- Integrate Enhanced Info --> H[User Display]

2.2 Derivative: Geo-Distributed Serverless Microservices Architecture

• Axis: Operational Parameter Expansion
• Enabling Description: The "computer system" is implemented as a geo-distributed serverless microservices architecture, spanning multiple cloud regions globally. The "maintaining" of associations and ratings is handled by a globally replicated, eventually consistent NoSQL database (e.g., DynamoDB Global Tables, Cosmos DB). The "receiving," "determining," and "generating" steps are executed as ephemeral serverless functions (e.g., AWS Lambda, Google Cloud Functions) triggered by incoming search result requests. These functions are deployed at edge locations or closest to the user's geographical region, leveraging Content Delivery Networks (CDNs) for static asset distribution. This architecture enables massive horizontal scalability to handle billions of search result enhancement requests per day with minimal latency, automatically adjusting resource allocation based on demand without persistent server management.

graph LR
    User --> EdgeNetwork(CDN/Edge Network)
    EdgeNetwork --> LambdaGateway(API Gateway/Lambda Proxy)
    LambdaGateway --> DetermineURLFunction[Serverless Function: Determine URL Association]
    DetermineURLFunction --> GenerateInfoFunction[Serverless Function: Generate Seller Info]
    GenerateInfoFunction --> GlobalNoSQLDB[Globally Replicated NoSQL DB]
    GlobalNoSQLDB --> DetermineURLFunction
    GenerateInfoFunction --> LambdaGateway
    LambdaGateway --> EdgeNetwork
    EdgeNetwork --> UserDisplay(Enhanced Search Result Display)

2.3 Derivative: Infrastructure Planning Enhancement System

• Axis: Cross-Domain Application
• Enabling Description: The computer system is designed for urban and regional infrastructure planning. When urban planners or government officials search for proposed infrastructure projects (e.g., "new bridge construction," "water pipeline upgrades") or contractors in public procurement databases, the "search results" are enhanced. The "seller-specific information" represents "contractor/project performance ratings," derived from historical data on project completion rates, budget adherence, regulatory compliance, environmental impact scores, and public satisfaction surveys. The "registered selling entities" are construction companies, engineering firms, or urban development consortiums, and "registered buying entities" are government agencies, civic organizations, or auditing bodies. The system presents these verifiable performance metrics to facilitate more reliable and transparent infrastructure development decisions.

classDiagram
    class User {
        +SearchQuery()
    }
    class InfraSearchEngine {
        +GetProjectResults()
    }
    class ProjectURL {
        +URL: string
        +AssociatedContractors: list<Contractor>
    }
    class Contractor {
        +ID: string
        +HistoricalRatings: list<Rating>
        +ComplianceScores: float
        +BudgetAdherence: float
    }
    class Rating {
        +Source: BuyingEntity
        +Value: float
        +Metric: string
    }
    class BuyingEntity {
        +ID: string
        +Type: string (e.g., GovernmentAgency, CivicOrg)
    }
    class EnhancementSystem {
        -DB: InfrastructureDB
        +ProcessQuery(query): list<EnhancedResult>
        +GeneratePerformanceInfo(contractor): dict
    }
    class InfrastructureDB {
        +GetAssociations(URL): list<Contractor>
        +GetRatings(ContractorID): list<Rating>
    }
    class EnhancedResult {
        +OriginalResult: ProjectURL
        +PerformanceInfo: dict
    }
    User --> InfraSearchEngine
    InfraSearchEngine --> EnhancementSystem
    EnhancementSystem --> InfrastructureDB
    InfrastructureDB --> Contractor
    InfrastructureDB --> BuyingEntity
    EnhancementSystem --> EnhancedResult
    EnhancedResult --> User

2.4 Derivative: Quantum-Resistant Encrypted Rating Storage

• Axis: Integration with Emerging Tech
• Enabling Description: The "one or more databases" storing the URL associations and ratings implement quantum-resistant cryptographic algorithms for all data at rest and in transit. Specifically, all "one or more ratings" from "registered buying entities" and their associated metadata are encrypted using lattice-based cryptography (e.g., Kyber for key encapsulation, Dilithium for digital signatures) before storage. The "computer system" includes specialized hardware security modules (HSMs) or trusted execution environments (TEEs) that perform the decryption and "generating" of seller-specific information in a secure, isolated manner. This ensures that even with the advent of large-scale quantum computers, the sensitive rating data and entity associations remain confidential and tamper-proof. The presentation layer receives cryptographically signed (quantum-resistant) aggregated results, which are verified on the client side.

flowchart TD
    User[Buying Entity Rating] --> Encrypt[Quantum-Resistant Encryption (Lattice-based)]
    Encrypt --> Storage[Encrypted Ratings DB]
    Storage --> Decrypt[Secure Enclave / HSM (Q-R Decryption)]
    Decrypt --> Generator[Seller Info Generator]
    Generator --> Sign[Q-R Digital Signature]
    Sign --> Presentation[Enhanced Search Results]
    Presentation --> UserDisplay[User Display]

2.5 Derivative: "Fallback Read-Only" Disaster Recovery System

• Axis: The "Inverse" or Failure Mode
• Enabling Description: The computer system incorporates a "fallback read-only" disaster recovery mode. In normal operation, the system utilizes active-active database clusters for the "one or more databases." However, in the event of a catastrophic failure (e.g., primary data center outage, major database corruption), a monitoring system automatically triggers a switch-over to a pre-provisioned, geo-redundant static data store (e.g., AWS S3, Google Cloud Storage) containing periodically snapshotted, highly aggregated "seller-specific information." In this mode, the "generating" step is bypassed. Instead, the system retrieves only the most essential, pre-computed seller metrics (e.g., overall average rating, number of reviews) from the static store. The "presenting" component then renders these cached, limited data points, ensuring that basic buyer-oriented information is still available, albeit in a reduced functionality, read-only state, minimizing downtime and data loss exposure.

graph TD
    A[Primary DB Cluster] -- Active Replication --> B[Secondary DB Cluster]
    C[Monitor & Health Check] -- Detects Failure --> D{Recovery Orchestrator}
    D -- Switchover Trigger --> E[Static Fallback Storage (Aggregated Data)]
    E --> F[Limited Functionality Generator]
    F --> G[Enhanced Search Results (Basic)]
    C -- Normal Operation --> H[Full Functionality Generator]
    H --> I[Enhanced Search Results (Full)]
    G --> User[User]
    I --> User

---

Derivatives of Independent Claim 13: Method for Accessing Enhanced Buyer-Oriented Information

Claim 13: A method for enhancing search results by presenting enhanced buyer-oriented information, the method comprising: receiving, from an Internet search engine, a search results page that contains one or more search results but that does not contain the enhanced buyer-oriented information; and presenting, on the search results page, a link which, when activated by a user, causes the user's Internet browser to load a second search results page that contains the enhanced buyer-oriented information in association with the one or more search results contained in the first-mentioned search results page.

---

3.1 Derivative: Custom URI Scheme for Native Application Display

• Axis: Material & Component Substitution
• Enabling Description: Instead of a standard HTML <a> tag, the "link" presented on the initial search results page is a custom Uniform Resource Identifier (URI) scheme (e.g., b2benhancer://viewenhanced?url=encoded_original_url&query=encoded_query). When this custom URI is activated, the user's operating system (desktop or mobile) intercepts it and launches a pre-installed native application (e.g., a dedicated B2B Enhancer desktop app or mobile app). This native application then parses the URI parameters, retrieves the "enhanced buyer-oriented information" (e.g., via a secure API call to the B2B service), and renders it within its own rich user interface, separate from the web browser. This allows for a more controlled, potentially offline-capable, and feature-rich display of the enhanced information compared to a web page.

sequenceDiagram
    participant U as User
    participant WB as Web Browser
    participant OS as Operating System
    participant NA as Native B2B App
    participant B2BS as B2B Service API
    U->>WB: Receives Search Results Page (no enhanced info)
    WB->>U: Displays Custom URI Link (e.g., b2benhancer://...)
    U->>WB: Activates Link
    WB->>OS: Passes Custom URI Scheme
    OS->>NA: Launches Native App with URI
    NA->>B2BS: API Call (e.g., /getEnhancedInfo?url=...)
    B2BS-->>NA: Enhanced Buyer-Oriented Data
    NA->>U: Displays Rich Enhanced Information (in native UI)

3.2 Derivative: Multimodal Output for Accessibility

• Axis: Operational Parameter Expansion
• Enabling Description: The "presenting" of the link and the "loading" of the second search results page are augmented for multimodal accessibility, specifically for users with severe visual impairments. When the initial search results page is received, an assistive technology agent (e.g., a screen reader) detects the presence of the hidden semantic "link" (e.g., ARIA attributes for accessibility). Upon activation (e.g., via a keyboard shortcut or voice command), instead of visually loading a "second search results page," the system triggers an audio synthesis module to verbalize the key "enhanced buyer-oriented information" for each search result (e.g., "Seller X, 4.5 stars, 20 trusted connections, compatible with your filters"). For devices with haptic feedback, a subtle vibration pattern might indicate a highly-rated seller, providing a non-visual cue.

graph TD
    A[User with Visual Impairment] --> B(Assistive Technology / Screen Reader)
    C[Search Results Page (Raw HTML + ARIA)] -- Parsed by --> B
    B --> D{Detects Semantic "Enhanced" Link}
    D -- User Activation (Voice/Keyboard) --> E(Multimodal Output Engine)
    E -- Triggers Audio Synthesis --> F[Verbalize Enhanced Info]
    E -- Triggers Haptic Feedback (Optional) --> G[Tactile Cues]
    F --> A
    G --> A

3.3 Derivative: Healthcare Provider Ratings for Patient Choice

• Axis: Cross-Domain Application
• Enabling Description: In the healthcare domain, a user searches for medical practitioners or facilities (e.g., "dermatologist near me," "pediatric hospital with good reviews"). The initial search results page (from a health directory or general search engine) displays basic information such as names, addresses, and specialties. A "link" (e.g., "View Patient Experience Scores" or "See Verified Quality Metrics") is presented next to each provider. Activating this link causes the user's browser to load a "second search results page" from a regulated health information portal. This page contains detailed "enhanced buyer-oriented information," such as verified patient satisfaction ratings (overall experience, wait times, communication), anonymized treatment outcome statistics (e.g., success rates for specific procedures), insurance network compatibility, and certifications from accredited bodies. This assists patients (buying entities) in making informed choices about healthcare providers (selling entities).

flowchart TD
    A[Patient Search: "Specialist Type"] --> B(Health Search Engine)
    B --> C{Basic Provider Results (Name, Location)}
    C --> D[Provider Card with "View Details" Link]
    D -- Click Link --> E(Health Info Portal)
    E --> F[Dynamic Page Generation]
    F -- Retrieve Verified Ratings/Outcomes --> G(Regulated Health DB)
    G --> F
    F --> H[Enhanced Provider Page (Ratings, Outcomes)]
    H --> A

3.4 Derivative: Augmented Reality Overlay for Product/Service Ratings

• Axis: Integration with Emerging Tech
• Enabling Description: The "link" mechanism is integrated with Augmented Reality (AR) technology. When a user conducts a search for physical products or local services (e.g., "coffee maker," "plumber") and views the results through an AR-enabled device (e.g., smartphone camera, AR glasses), the "link" is represented as an interactive AR marker or a detected physical object. Upon activation (e.g., by gazing at the marker, performing a specific hand gesture, or tapping on the object in AR view), instead of loading a separate web page, the "enhanced buyer-oriented information" is dynamically rendered as a holographic overlay directly onto the real-world view of the product (if present) or associated with the physical location of the service provider. For instance, hovering over a coffee maker in a store might display its average star rating, number of reviews, and a "trusted buyer" indicator as a virtual label in the AR viewport.

sequenceDiagram
    participant U as User
    participant ARD as AR Device (e.g., phone, glasses)
    participant SE as Internet Search Engine
    participant EIS as Enhanced Info Service (API)
    U->>SE: Searches for "Product X"
    SE->>ARD: Raw Search Results (textual, images)
    ARD->>ARD: User enables AR View / points camera
    ARD->>ARD: Detects Product X in physical space / displays virtual markers
    U->>ARD: Activates virtual "Enhanced Info" marker/gesture
    ARD->>EIS: Requests Enhanced Buyer-Oriented Info for Product X (via URL/ID)
    EIS-->>ARD: Detailed Ratings, Reviews
    ARD->>U: Displays Holographic Overlay of Info onto Product X in real-time view

3.5 Derivative: "Sandbox Preview" Mode for Untrusted Sources

• Axis: The "Inverse" or Failure Mode
• Enabling Description: When the "link" to the "second search results page" is activated, particularly if the source of the "enhanced buyer-oriented information" is from a third-party or potentially untrusted domain, the user's Internet browser loads this second page within an isolated, sandboxed iframe or a secure virtualized browser environment (e.g., WebContainer). This sandbox prevents the content of the enhanced page from accessing or manipulating the primary browsing session's cookies, local storage, or other sensitive resources. This "limited-functionality" mode ensures that even if the enhanced content contains malicious scripts or trackers, the user's security and privacy on the main search results page remain uncompromised. The sandbox explicitly disables features like arbitrary script execution or cross-origin requests, operating as a secure preview rather than a full navigation.

graph TD
    A[User Activates Link] --> B(Browser Security Module)
    B --> C{Enhanced Info Page Origin Trusted?}
    C -- Yes --> D[Load Page Directly]
    C -- No --> E[Load Page in Sandboxed Iframe/VM]
    E -- Restricted Access --> F(Isolated Execution Environment)
    F -- Secure Content Display --> G[User View]
    D --> G

---

Derivatives of Independent Claim 16: Method for Generating Custom Seller-Specific Information

Claim 16: A method for generating custom seller-specific information for a user, the method comprising: maintaining, in one or more databases, a plurality of associations, each association in the plurality of associations associating a uniform resource locator (URL) in a set of one or more URLs with a separate set of one or more registered selling entities, each of the one or more registered selling entities in the separate set of one or more registered selling entities being associated with one or more ratings from one or more registered buying entities that have done business with that selling entity; maintaining, in one or more databases, one or more user attributes and one or more filter criteria for each of a plurality of registered buying entities; receiving, from an Internet search engine, a list of search results generated by the Internet search engine based on one or more query terms submitted by a user who is a registered buying entity, the list of search results comprising one or more search results that are associated with one or more of the URLs in the set of one or more URLs; determining, for each search result in at least a subset of the one or more search results in the list of search results, whether that search result's associated URL is associated with one or more registered selling entities in the plurality of associations; determining, for each of the one or more registered selling entities associated with a search result's associated URL, whether that registered selling entity satisfies at least a portion of the one or more filter criteria associated with the user; generating, for each search result that is associated with one or more registered selling entities, seller-specific information that is based at least in part on (a) the one or more ratings that are associated with the one or more registered selling entities that are associated with that search result's associated URL and (b) whether the one or more registered selling entities satisfy the at least a portion of the one or more filter criteria associated with the user; and presenting, to the user, the custom seller-specific information in association with that search result in the list of search results.

---

4.1 Derivative: Homomorphic Encryption for Private Filter Matching

• Axis: Material & Component Substitution
• Enabling Description: The "determining" step, which assesses whether a "registered selling entity satisfies at least a portion of the one or more filter criteria associated with the user," is performed using homomorphic encryption. The user's "one or more filter criteria" are encrypted on the client side using a partially homomorphic encryption scheme (e.g., Paillier or BFV/CKKS for more complex operations). These encrypted criteria are transmitted to the server where the "one or more attributes" of the selling entities (also encrypted or securely transformed) reside. The server then performs the matching operation directly on the encrypted data without ever decrypting either the user's criteria or the seller's attributes. The result of the comparison (a match score or boolean) is also encrypted and sent back to the client for decryption and presentation. This guarantees privacy by ensuring that the server never learns the specifics of the user's private filter criteria or the exact seller attributes during the matching process.

sequenceDiagram
    participant U as User (Buying Entity)
    participant CS as Client-Side System
    participant SS as Server-Side System
    participant BDB as B2B Database (Encrypted)
    U->>CS: Define Filter Criteria (FC)
    CS->>CS: Encrypt FC (E_FC) Homomorphically
    CS->>SS: Send Query + E_FC
    SS->>SS: Receive Raw Search Results (URLs)
    SS->>BDB: Retrieve Encrypted Seller Attributes (E_SA)
    BDB-->>SS: E_SA
    SS->>SS: Perform Homomorphic Match(E_FC, E_SA)
    SS-->>CS: Send Encrypted Match Result (E_MR)
    CS->>CS: Decrypt E_MR
    CS->>U: Display Custom Seller Info based on MR

4.2 Derivative: Dynamic Multi-Jurisdictional Compliance Filtering

• Axis: Operational Parameter Expansion
• Enabling Description: The "generating" of custom seller-specific information and the "determining" of filter satisfaction dynamically adapt to the user's detected geographical jurisdiction and local regulatory landscape. For each "registered buying entity," an associated compliance profile is maintained, detailing required data privacy standards (e.g., GDPR, CCPA, PIPL) and industry-specific certifications. When "generating" information, a geo-compliance module checks the user's location and adjusts the display of seller attributes and ratings based on local legal disclosure requirements. For instance, certain data points (e.g., seller's specific historical pricing) might be omitted or aggregated if the user's jurisdiction restricts such direct competitive information, while other certifications might be prioritized for display based on local industry mandates. This ensures legal compliance of personalized content delivery on a global scale.

graph TD
    A[User Query + Location] --> B(Search Result Processor)
    B -- Identify User Geolocation --> C{Geo-Compliance Module}
    C -- Fetch Regulatory Rules --> D[Jurisdictional Policy DB]
    D --> C
    C -- Adjust Filter Criteria / Info Disclosure --> E(Custom Info Generator)
    E -- Retrieve Seller Data & Ratings --> F(B2B Database)
    F --> E
    E --> G[Present Custom Seller Info (Geo-Compliant)]
    G --> A

4.3 Derivative: Investment Portfolio Fit Scoring

• Axis: Cross-Domain Application
• Enabling Description: In financial services, specifically for individual investors, the "custom seller-specific information" is "investment portfolio fit scores" presented alongside search results for financial assets (stocks, bonds, mutual funds, ETFs). The "user attributes and filter criteria" comprise the investor's risk tolerance (e.g., conservative, moderate, aggressive), investment horizon, ESG (Environmental, Social, and Governance) preferences, diversification requirements, and current portfolio holdings. When an investor searches for an asset (the "URL" could be a ticker symbol or fund ID), the system "determines" how well that asset's characteristics (e.g., sector, market cap, historical volatility, ESG rating from a third party) satisfy the investor's criteria. The "seller-specific information" then quantifies this as a "Portfolio Fit Score" (e.g., 1-100) and highlights specific matches or mismatches (e.g., "High ESG Alignment," "Increases portfolio risk by X%"). This empowers investors to quickly identify assets that align with their personalized financial goals.

classDiagram
    class Investor {
        +RiskTolerance: enum
        +InvestmentHorizon: int
        +ESG_Preferences: list<string>
        +CurrentPortfolio: list<Asset>
        +SearchForAsset(query: string)
    }
    class AssetSearchEngine {
        +Search(query: string): list<AssetURL>
    }
    class AssetURL {
        +Identifier: string (e.g., Ticker)
        +Attributes: dict (e.g., Sector, Volatility, ESG Rating)
    }
    class PortfolioAnalyzer {
        -InvestorProfileDB: InvestorProfileDB
        +CalculateFitScore(investor: Investor, asset: AssetURL): FitScore
        +IdentifyMatches(investor: Investor, asset: AssetURL): list<string>
    }
    class InvestorProfileDB {
        +GetInvestorProfile(userID: string): Investor
    }
    class FitScore {
        +Value: float
        +Justification: list<string>
    }
    Investor --> AssetSearchEngine
    AssetSearchEngine --> PortfolioAnalyzer
    PortfolioAnalyzer --> InvestorProfileDB
    AssetURL --> PortfolioAnalyzer
    PortfolioAnalyzer --> FitScore
    FitScore --> Investor: Presented

4.4 Derivative: Explainable AI (XAI) for Filter Satisfaction Justification

• Axis: Integration with Emerging Tech
• Enabling Description: When "generating" custom seller-specific information, the system integrates an Explainable AI (XAI) module. This module not only determines whether a "registered selling entity satisfies at least a portion of the one or more filter criteria" but also generates a concise, human-readable justification for why that determination was made. For instance, if a user's filter criteria require a seller with "ISO 9001 certification" and "local presence," the XAI output might be "Seller X meets your criteria: 'ISO 9001 certified (verified 2024)' and 'Operates in your designated region: Greater Seattle Area'." Conversely, for a non-satisfying seller, it might state, "Seller Y does not meet 'minimum 5-year operating history' (only 3 years)." This transparent justification builds user trust and helps refine their filter criteria or understanding of seller profiles.

flowchart TD
    A[User Query] --> B(Search Results)
    B --> C{URL Matcher}
    C --> D[Retrieve Seller Attributes (SA) & Ratings]
    C --> E[Retrieve User Filter Criteria (FC)]
    D --> F(Filter Satisfaction Determiner)
    E --> F
    F --> G{XAI Explanation Generator}
    G -- "Why X, Why Not Y" --> H[Custom Seller Info + Justification]
    H --> I[User Display]

4.5 Derivative: "Filter Fatigue" Detection and Suggestion Mode

• Axis: The "Inverse" or Failure Mode
• Enabling Description: The method includes a "filter fatigue" detection and suggestion mode as a "limited-functionality" or "failure mitigation" feature. An analytics component continuously monitors the search session for instances where "determining" filter satisfaction consistently results in zero or very few matching selling entities across multiple queries. Upon detecting "filter fatigue" (e.g., less than 5% of results satisfy filters for 3 consecutive searches), the "generating" step is modified. Instead of strictly presenting only matching results, the system offers dynamically generated "soft suggestions" for modifying the user's "filter criteria." This might include "loosening" a stringent parameter (e.g., suggesting expanding a geographical radius), prioritizing a "soft filter" over a "hard filter," or identifying "alternative criteria" from similar successful user profiles. This aims to prevent user frustration from overly restrictive filtering by making the system more adaptive.

stateDiagram
    state "Search Flow" as SearchFlow
    SearchFlow --> QuerySubmission: User Enters Query
    QuerySubmission --> ResultProcessing: Get Raw Results
    ResultProcessing --> FilterMatching: Apply User Criteria
    FilterMatching --> NoMatchDetected: Few/No Sellers Satisfy Filters
    NoMatchDetected --> IncrementFilterFatigueCounter: Record Low Match Rate
    IncrementFilterFatigueCounter --> CheckFilterFatigueThreshold: Is Counter > N?
    
    CheckFilterFatigueThreshold --> SuggestFilterAdjustment: Yes, Trigger Suggestion Mode
    SuggestFilterAdjustment --> PresentSuggestedFilters: Display Options to User
    PresentSuggestedFilters --> UserModifiesFilters: User Interaction
    UserModifiesFilters --> ResetFilterFatigueCounter: New Search w/ Modified Filters
    
    CheckFilterFatigueThreshold --> PresentLimitedResults: No, Continue with Limited Matches
    PresentLimitedResults --> SearchFlow
    
    FilterMatching --> ResultsSatisfy: Some/Many Sellers Satisfy Filters
    ResultsSatisfy --> PresentCustomInfo: Display Enhanced Results
    PresentCustomInfo --> SearchFlow

---

Derivatives of Independent Claim 17: Method for Filtering Search Results Based on Seller Criteria

Claim 17: A method for filtering search results based on whether a selling entity associated with a URL satisfies a buying entity's criteria, the method comprising: maintaining, in one or more databases, a plurality of associations, each association in the plurality of associations associating a uniform resource locator (URL) in a set of one or more URLs with a separate set of one or more registered selling entities, each of the one or more registered selling entities in the separate set of one or more registered selling entities being associated with one or more criteria; maintaining, in one or more databases, one or more attributes for each of a plurality of registered buying entities; receiving, from an Internet search engine, a list of search results generated by the Internet search engine based on one or more query terms submitted by a user who is a registered buying entity, the list of search results comprising one or more search results that are associated with one or more of the URLs in the set of one or more URLs; determining, for each search result in at least a subset of the one or more search results in the list of search results, whether that search result's associated URL is associated with one or more registered selling entities in the plurality of associations; determining, for each of the one or more registered selling entities associated with a search result's associated URL, whether the one or more attributes associated with the user satisfy the one or more criteria associated with that registered selling entity; and omitting or removing, from the list of search results, each search result for which the one or more attributes associated with the user do not satisfy the one or more criteria associated with any of the one or more registered selling entities associated with that search result's associated URL before the list of search results is presented to the user.

---

5.1 Derivative: Fuzzy Logic Inference for Attribute-Criteria Matching

• Axis: Material & Component Substitution
• Enabling Description: The "determining" step, which assesses whether "one or more attributes associated with the user satisfy the one or more criteria associated with that registered selling entity," is performed by a fuzzy logic inference engine. Instead of binary (yes/no) satisfaction, buyer attributes and seller criteria are represented as fuzzy sets (e.g., "small company budget" is a fuzzy set with membership functions defining 'small', 'medium', 'large'). The fuzzy inference engine calculates a "degree of satisfaction" (e.g., a score from 0.0 to 1.0) for each selling entity based on the linguistic rules defined by the criteria. Search results are then omitted or moved to a "less relevant" section if their highest fuzzy satisfaction score falls below a dynamically adjustable threshold (e.g., 0.7), allowing for more nuanced filtering than strict boolean matching.

flowchart TD
    A[User Attributes] --> B(Fuzzy Logic Inference Engine)
    C[Seller Criteria (Fuzzy Sets/Rules)] --> B
    B --> D[Degree of Satisfaction (0-1.0)]
    D --> E{Threshold Check}
    E -- Below Threshold --> F[Omit/Deprioritize Search Result]
    E -- Above Threshold --> G[Keep Search Result]
    F --> H[Filtered Search Results List]
    G --> H

5.2 Derivative: Dynamic Real-time Seller Availability Criteria

• Axis: Operational Parameter Expansion
• Enabling Description: The "one or more criteria associated with that registered selling entity" are dynamically updated in real-time, reflecting current operational parameters such as inventory levels, staffing availability, current project load, or geographical reach based on logistics data. For example, a selling entity's criterion for a "buying entity" might be "available for new projects in Q3" or "requires minimum order quantity of 1000 units." These criteria are continuously streamed from the seller's internal ERP or CRM systems into the "one or more databases." The "determining" step then performs a real-time match against these ephemeral criteria. Search results are immediately "omitted or removed" if the seller's real-time criteria are not met by the user's current attributes, ensuring that displayed results only show sellers who are actively capable and interested in doing business with the user at that exact moment.

graph TD
    A[Selling Entity Internal Systems (ERP/CRM)] --> B(Real-time Criteria Update Service)
    B --> C[Seller Criteria Database]
    D[User Query + Attributes] --> E(Search Result Processing)
    E -- Fetch Seller Criteria (Real-time) --> C
    C --> E
    E --> F{Attribute-Criteria Matcher}
    F -- No Match --> G[Omit/Remove Search Result]
    F -- Match --> H[Keep Search Result]
    G --> I[Filtered Search Results]
    H --> I
    I --> User[User Display]

5.3 Derivative: Government Procurement Compliance Filtering

• Axis: Cross-Domain Application
• Enabling Description: The method is applied to government procurement portals. When a government agency (the "registered buying entity" with "one or more attributes" like "department budget," "required certifications," "local content preference") searches for potential contractors or suppliers for bids (the "search results"), the results are filtered. The "one or more criteria associated with that registered selling entity" are compliance metrics, certifications, small business status, diversity classifications, and historical performance required for government contracts. The "determining" step checks if a contractor's attributes satisfy mandatory regulatory compliance (e.g., CMMC for cybersecurity, FAR/DFARS compliance), specific licenses, or set-aside program requirements. Any search result for a contractor that does not satisfy all mandatory criteria for the requesting agency is "omitted or removed" before presentation, streamlining the often complex and compliance-heavy government bidding process.

classDiagram
    class GovernmentAgency {
        +Budget: float
        +CertificationsRequired: list<string>
        +LocalContentPreference: float
        +SearchForContractor(query: string)
    }
    class ProcurementSearchEngine {
        +Search(query: string): list<ContractorURL>
    }
    class ContractorURL {
        +ID: string
        +ComplianceAttributes: dict (e.g., CMMC Level, Licenses, SmallBizStatus)
        +PastPerformanceRatings: dict
    }
    class ComplianceFilterEngine {
        -AgencyCriteriaDB: AgencyCriteriaDB
        +FilterResults(agency: GovernmentAgency, results: list<ContractorURL>): list<ContractorURL>
        +CheckCompliance(agency: GovernmentAgency, contractor: ContractorURL): bool
    }
    class AgencyCriteriaDB {
        +GetAgencyCriteria(agencyID: string): dict
    }
    GovernmentAgency --> ProcurementSearchEngine
    ProcurementSearchEngine --> ComplianceFilterEngine
    ComplianceFilterEngine --> AgencyCriteriaDB
    ContractorURL --> ComplianceFilterEngine
    ComplianceFilterEngine --> GovernmentAgency: Filtered Results

5.4 Derivative: Self-Sovereign Identity (SSI) for User Attributes and Criteria Matching

• Axis: Integration with Emerging Tech
• Enabling Description: Buyer "attributes" and seller "criteria" are managed using Self-Sovereign Identity (SSI) principles and verifiable credentials (VCs). A "registered buying entity" maintains their "one or more attributes" as VCs issued by trusted authorities (e.g., employment history VC from an HR system, industry certification VC from a professional body) in a digital wallet. A "registered selling entity" publishes its "one or more criteria" (e.g., "requires buyer with 'Enterprise Architect' title," "minimum purchase authority of $1M") also as VCs. When a user submits a query, during the "determining" step, the user's client-side agent selectively presents only the necessary VCs containing relevant attributes to the matching service. The matching service cryptographically verifies these VCs against the seller's VC-based criteria without learning the full set of user attributes or storing them centrally, ensuring maximal user privacy and verifiable claims during the filtering process. Only the boolean result of the match is communicated back to the search result presentation layer.

sequenceDiagram
    participant U as User (Buying Entity)
    participant UC as User Client
    participant SSIW as SSI Wallet
    participant MS as Matching Service
    participant SCDB as Seller Criteria DB (VCs)
    participant SE as Search Engine
    U->>UC: Initiate Search + Authorize Attribute Disclosure
    UC->>SSIW: Select Verifiable Credentials (VCs) (e.g., job title, budget)
    SSIW->>UC: Present Selected VCs
    UC->>SE: Submit Query
    SE->>MS: Send Raw Search Results (URLs) + Selected VCs
    MS->>SCDB: Retrieve Seller Criteria VCs for Matched URLs
    SCDB-->>MS: Seller Criteria VCs
    MS->>MS: Cryptographically Verify User VCs against Seller VCs
    MS-->>SE: Boolean Match Result (Omit/Keep) for each URL
    SE->>U: Display Filtered Search Results

5.5 Derivative: "Explain Why Omitted" Feedback Mode

• Axis: The "Inverse" or Failure Mode
• Enabling Description: When a search result is "omitted or removed" due to a mismatch between user attributes and seller criteria, the method incorporates an "Explain Why Omitted" feedback mechanism. Instead of simply hiding the result, a subtle placeholder or an optional "See Omitted Results" link is presented. If the user activates this, a "limited-functionality" pop-up or dedicated section appears. This section provides a concise, human-readable explanation of which specific seller criteria were not met by the user's attributes (e.g., "Seller X requires 'Enterprise-level budget (>$500k)', your profile indicates 'SMB budget (<$50k)'" or "Seller Y requires 'US-based clients only', your profile indicates 'EU region'"). This provides valuable feedback to the user, allowing them to understand the filtering logic, potentially adjust their own profile, or refine future search queries, transforming omission into an educational experience rather than a black box.

flowchart TD
    A[Search Results Processing] --> B{Determine Match (User Attributes vs. Seller Criteria)}
    B -- No Match --> C[Mark Result as Omitted]
    C --> D[Present Filtered List + Omitted Indicator]
    D -- User Clicks "Why Omitted?" --> E(Explanation Module)
    E -- Generates Specific Reason --> F[Display Reason to User]
    B -- Match --> G[Present Result]

---

Combination Prior Art Scenarios

Here are at least three scenarios combining US Patent 10534820 with existing open-source standards to demonstrate prior art for future incremental improvements.

1. Integration with Schema.org & JSON-LD for Direct Web-Based Ratings

• Scenario: A web-based system that uses Schema.org vocabulary and JSON-LD markup embedded directly into seller websites to provide buyer-oriented information. Sellers, as "registered selling entities," use these open standards to structure and publish their "one or more ratings" (e.g., AggregateRating, Review) and "attributes" (e.g., Organization properties like industry, location, services offered). Internet search engines (or dedicated crawlers acting as the "receiving" component in Claim 1) are configured to parse this structured data during their indexing process. The "determining" and "generating" steps then directly leverage this natively published, standardized data to create "seller-specific information" for presentation alongside search results. This eliminates the sole reliance on a proprietary "B2B database" for initial data acquisition, making the web itself the primary "database" of enhanced information.
• Relevance to Patent: This makes the core mechanism of associating URLs with seller ratings (Claim 1, 12) directly discoverable and consumable via widely adopted open web standards, rather than requiring a separate, private B2B database interaction for initial data discovery. Any subsequent patent claims around novel methods for integrating seller-specific information would face this as prior art.

2. Integration with OpenStreetMap (OSM) & GeoJSON for Location-Based Filtering

• Scenario: An enhancement system that leverages OpenStreetMap (OSM) data and GeoJSON standards to filter and customize search results based on geographic proximity or service areas. "Registered selling entities" (e.g., local service providers, regional distributors) declare their service territories using GeoJSON polygons or points in the "one or more databases" (Claim 17). When a "user who is a registered buying entity" submits a geographically sensitive query (e.g., "IT support in Manhattan") along with their own precise location (GeoJSON point), the "determining" step of Claim 17 utilizes an open-source geospatial library (e.g., PostGIS, Turf.js) to perform spatial intersection analysis. Search results for sellers whose declared service area (from GeoJSON data) does not spatially overlap with the buyer's location or specified region are "omitted or removed." The customized seller-specific information (Claim 16) could also include a "distance to nearest service point" derived from OSM routing data.
• Relevance to Patent: This demonstrates an obvious application of the filtering mechanism (Claim 17) and customization (Claim 16) using widely available open geographic data standards. Extending the concept of "criteria" to include geographic zones and "attributes" to include location, then performing a spatial match for filtering, would be considered obvious given the existence of OSM and GeoJSON.

3. Integration with ActivityPub for Decentralized, Federated Ratings

• Scenario: A system that collects "one or more ratings from one or more registered buying entities" (Claim 1) from a decentralized, federated network utilizing the ActivityPub protocol. Instead of ratings being submitted to a single "on-line business-to-business connectivity service," buying entities publish their ratings for selling entities as ActivityPub "Note" or "Review" activities on their own federated social network instances. The "one or more databases" in Claim 1 is replaced by a "rating aggregation service" that subscribes to relevant ActivityPub feeds, ingests these signed, distributed ratings, and aggregates them. This service verifies the authenticity of the ratings (e.g., via cryptographic signatures and reputation of the publishing instance) and then makes them available for "generating" "seller-specific information" for search results. This establishes a community-driven, censorship-resistant rating infrastructure that feeds into the enhanced search display.
• Relevance to Patent: This provides a decentralized and open-standard alternative for the fundamental data collection and storage mechanism (the "maintaining, in one or more databases, a plurality of associations... with one or more ratings") of the patent's claims. Any claims related to novel methods for collecting or storing ratings would need to distinguish from this federated, ActivityPub-based approach.