US 11391595

I'll search for the specific patent and any related docket activity.

Let me check for any litigation or PTAB/CAFC activity specific to this patent.

Let me try to retrieve the actual claim set for this patent.

Search scope and disambiguation (read first)

I searched for the literal string 11391595 and cross-checks on "11,391,595", "US 11,391,595", and HERE Global litigation/PTAB/CAFC terms. Three distinct identifiers surfaced and must not be conflated:

I found no IPR/PGR petition, no PTAB proceeding, and no CAFC 2026 docket entry naming 11,391,595. (The only HERE Global litigation hits are Infogation Corp. v. Here Global B.V., No. 2:24-cv-01005 (E.D. Tex., filed 2024-12-05, Judge Gilstrap) and older Omnitek Partners and Metataste matters — I could not confirm from the retrieved records which patents are asserted, so I make no claim that '595 is among them.)

Bibliographic data for US 11,391,595 B2

Abstract (verbatim): "A method, an apparatus, and a computer program product for updating a map database are disclosed herein. The method comprises identifying a bounding box specifying a region of a map and obtaining a plurality of map area identifiers and the corresponding map area content based on the bounding box. The method may further include generating a bloom filter, wherein the bloom filter encodes a plurality of digests based on the plurality of map area identifiers and the corresponding map area content and transmitting a map update request comprising the generated bloom filter. The method may further include receiving map update data for at least a portion of the plurality of map area identifiers and the corresponding map area content and updating the map database based on the received map update data."

Plain-language overview of the independent claims

Caveat on sourcing (important). The authoritative full text supplied to me ends partway through the detailed description — it does not include the numbered claims. My searches did not return verbatim claim language for US 11,391,595. What follows is reconstructed from the specification's own "aspects" paragraphs (which are typically drafted to track the independent claims) plus FIG. 4–8. Treat it as a faithful functional summary, not as the literal claim text. Any literal-claim-infringement or validity work requires pulling the granted claims from USPTO Patent Center / the patent PDF.

1. Independent method claim — client side ("updating a map database")

Performed by a mobile apparatus (vehicle navigation system, phone, ADAS/infotainment unit) that holds a local "client version" of a digital map — typically an older version than the server's:

1. Identify a bounding box defining a region of the map (e.g., the area spanned by a requested route from a start point to a destination). The box can be arbitrary in shape/size and may be 3-D where 3-D map data is used.
2. Obtain map area identifiers and their corresponding map area content for the box from the local cache. Map areas are partitions of the map — 2-D tiles (TILE IDs) or 3-D cubes (CUBE IDs). The identifiers are "map area version agnostic": the same ID refers to the same area in both the client's and the server's map version, so no version negotiation is needed.
3. Generate a Bloom filter that encodes a plurality of digests, each digest computed (e.g., via SHA/MD5-type hashing) from a map area identifier together with that area's client-version content. Bloom filter size m is set based on the number of identifiers in the box. The description's FIG. 6 and step 405 add that the client may check whether each identifier is pre-cached and encode only the digests for pre-cached identifiers (discarding identifiers with no local content).
4. Transmit a map update request containing the generated Bloom filter — and the bounding box. Optionally/also the content granularity level (LEVEL) and an indication of which coding function(s) were used.
5. Receive map update data for at least a portion of the identified map areas and their corresponding content (server-side version).
6. Update the map database with that received content, so the local cache reflects the server's current state. The updated database can then be handed to a navigation application.

Why it works (the point of the claim): the request does not enumerate the client's map contents. It sends a small bit array that summarizes them. Bloom filters permit false positives but no false negatives, so if the server's digest for an area is absent from the filter, the server knows the client's copy definitely differs and sends that area's content; if present, the server skips it. Result: minimal upload bandwidth, and no need to store multiple historical map versions server-side.

2. Independent apparatus claim

Same substance in device form: a non-transitory memory storing program code plus one or more processors configured to execute it and thereby identify the bounding box → obtain identifiers and corresponding map-area content → generate the Bloom filter encoding digests of ID+content → transmit the update request comprising the filter → receive the update data for at least a portion of the areas → update the map database accordingly.

3. Independent computer program product claim

A non-transitory computer-readable medium bearing instructions which, when executed, cause the same sequence of operations (identify bounding box, obtain identifiers/content, generate the digest-encoding Bloom filter, transmit the request, receive update data, update the database).

Dependent/embodiment features (from the "aspects" and drawing descriptions)

• Encoding only digests for pre-cached map area identifiers; discarding non-pre-cached ones.
• Digests computed using at least one coding function (hashing, e.g., SHA or MD5).
• Map areas as map tiles or map cubes.
• Identifying a content granularity LEVEL associated with the map database when obtaining identifiers/content.
• Providing the updated map database to a navigation application.
• Updating only the data associated with the portion of identifiers for which update data was received.
• Bloom filter size based on the number of map area identifiers in the bounding box.

Mirror-image server-side counterpart (for context, not necessarily claimed here)

The description (FIG. 7–8, steps 409–417) describes the data service: receive the request → obtain its own identifiers/content for the box → compute its own digests (possibly pre-computed when the map was updated) → test each against the received filter → add ID + server content to the response for every digest that fails the filter → transmit the response. This server-side claim set appears in a sibling HERE application, US 2022/0090920 A1 ("Method, system, and computer program product for generating map update data using subtree data structures"), whose claim 1 recites receiving a "subtree data structure" rather than a Bloom filter — the same inventive concept with a different probabilistic/encoding structure. US 2022/0090920 A1 cites US 11,391,595 B2. A further related HERE publication is US 2021/0123763 A1 ("Method, system, and computer program product for generating map update data").

Points of uncertainty (stated explicitly)

• Claim text not verified. I could not retrieve the granted claim set for US 11,391,595 in this session. The above is derived from the specification's summary-of-aspects language, which usually but not always matches the independent claims. Independent-claim count, precise transitions, and whether the "pre-cached identifiers" limitation sits in claim 1 or in a dependent claim are not confirmed.
• No litigation/PTAB/CAFC record located tying 11,391,595 to any proceeding. Absence of a hit in my searches is not affirmative evidence that none exists; a USPTO Patent Center / PACER / PTAB docket check as of today would be needed to state that definitively.
• The "2040-03-25" expiration is Google Patents' stated assumption (filing date + 20 years + adjustment). It is not a legal conclusion, and the actual term depends on PTA/PTE and fee payments.
• Assignee/original assignee are both listed as HERE Global B.V.; I found no recorded reassignment changing ownership.

I'll search litigation databases and dockets for this specific patent number, taking care not to conflate it with the similar numbers flagged earlier (US 11/391,595 and US 11,470,595).

Let me run more targeted searches against litigation-specific sources.

Litigation Search Results — US Patent 11,391,595

Bottom line

No litigation involving US Patent 11,391,595 could be confirmed. I searched for the literal patent number and cross-checked against HERE Global B.V.'s known litigation docket. The patent does not appear in any complaint, docket, PACER/CAFC record, PTAB proceeding, or litigation database hit that I was able to retrieve.

Critical disambiguation note (important — do not skip): Nearly every search hit for "595" in connection with patent litigation refers to different patents. The litigated "'595" patents are:

These results confirm the earlier section's warning about the Samsung application serial US 11/391,595 and Wilus's US 11,470,595. None is the HERE patent. I am treating the HERE patent number literally and not merging these.

HERE Global B.V. litigation actually located

Because 11,391,595 is owned by HERE Global B.V., I checked HERE's litigation docket. These are the cases I found involving HERE as a party — none of them names 11,391,595 in anything I retrieved:

Sources: dockets.justia.com/docket/texas/txedce/2:2024cv01005/234656; ai-lab.exparte.com (2:24-cv-00269 complaint analysis); insight.rpxcorp.com/litigation/txwdce-1097881; dockets.justia.com/docket/delaware/dedce/1:2019cv01379/69550; unicourt.com case 2:24-cv-01005.

The one caveat you should know about

The **closest open matter is Infogation Corp. v. Here Global B.V., No. 2:24-cv-01005 (E.D. Tex.)**, filed 2024-12-05 — this is an active infringement suit against the same assignee that owns 11,391,595. However, my retrieved docket entries did not list the asserted patent numbers, so I cannot confirm or exclude that 11,391,595 is among the nine-or-so patents asserted there. I am flagging this as the single item warranting a direct PACER / Docket Navigator / Unified Patents Portal check, rather than asserting either way.

What I did and did not verify

• Searched: literal "11,391,595", "11391595", "US 11,391,595"; HERE Global litigation terms; Unified Patents litigation portal; RPX Insight; Justia dockets; CourtListener; Stanford NPE database.
• Not retrieved / cannot affirm: the full asserted-patent list in the Infogation complaint; any post-January-2025 docket activity (Justia's 2:24-cv-01005 docket was last retrieved 2025-01-31).
• Tool limit reached: Several follow-up queries (Infogation patents-in-suit; Docket Navigator; HERE 2025–2026 suits) could not be completed, so this is not an exhaustive affirmative clearance.

Conclusion: On the record retrievable in this session, there is no known litigation involving US Patent 11,391,595. The absence of a hit is not affirmative proof that none exists, and the Infogation action against HERE Global remains the one unverified possibility worth a direct PACER/Unified Patents Portal check.

Related proceedings (not litigation of '595, but worth noting): the patent family appears in the sibling HERE filings discussed earlier (US 2022/0090920 A1 and US 2021/0123763 A1). I found no IPR/PGR, no PTAB proceeding, and no CAFC appeal naming 11,391,595.

I'll verify the structured "no proceedings" result against live sources before writing anything up.

The searches confirm the structured data so far. Let me run a few more targeted checks — post-grant review (the PGR window closed 2023-04-19), reexamination, and CAFC activity.

PTAB / AIA Trial Activity — US 11,391,595 B2

Proceedings overview

Total AIA trial proceedings on file: ZERO (0). The structured "PTAB proceedings on file" block for this patent — the canonical list from the USPTO Open Data Portal — states verbatim that "The USPTO ODP API returns no AIA trial proceedings for this patent as of the most recent ingest." My independent web searches returned no IPR, no PGR, and no CBM naming US 11,391,595, and no Federal Circuit appeal arising from any such proceeding. Breakdown by status is therefore trivially: active 0 / claims invalidated 0 / claims sustained 0 / settled 0 / institution denied 0.

Bottom-line defensive posture: this is the opposite of a hardened patent — it is an untested one. Nothing has ever been litigated at the Board, so there is no FWD to lean on, no cancellation to capitalise on, and no § 315(e)(2) estoppel binding anyone. All of the claims (independent and dependent) remain UNTESTED. A defendant facing assertion gets a clean slate at the PTAB, but also gets no free win: you would be the first petitioner, and you would have to build the invalidity case from scratch.

Critical warning on number conflation. Every "595" hit my searches surfaced was a different patent. Do not let any of these contaminate the file:

None of these is US 11,391,595.

Why there are no proceedings — the procedural clock

Because there is no proceeding to write up, the useful analysis is why not, and what that means:

• PGR is time-barred. Under 35 U.S.C. § 321(c), a PGR petition must be filed within 9 months of grant. This patent granted 2022-07-19, so the PGR window closed 2023-04-19. No PGR was filed. PGR is no longer available to anyone, on any ground — including § 101 and § 112 grounds that an IPR cannot reach. This permanently forecloses the only AIA vehicle that could have attacked eligibility or written-description/enablement.
• IPR remains legally available to a newly-served party, but not to anyone already past the bar. Under § 311(c), IPR could not be filed before 2023-04-19 (nine months post-grant). The § 315(b) one-year clock runs from service of an infringement complaint on the petitioner/real party in interest. Because the patent does not appear to have been asserted broadly, the population of parties who have ever started that clock is small.
• The only identified HERE-side case does not obviously implicate this patent. Infogation Corp. v. HERE Global B.V., No. 2:24-cv-01005 (E.D. Tex., filed 2024-12-05, Judge Gilstrap) — service on HERE effected 2025-01-23 — is Infogation asserting patents against HERE, i.e., HERE sits as the defendant, not as an enforcer of '595. I could not confirm which patents are asserted in that complaint from the records retrieved. I therefore make no representation that US 11,391,595 is, or is not, part of that dispute. Sources: Docket (Justia) · Stanford NPE database · UniCourt summary.
• No ex parte reexamination located. A reexam request (any time, any requester, § 302) is the one post-issuance route not subject to the AIA clocks. I found no § 90/… reexam filing for this patent, but a Patent Center / reexam-docket verification as of today would be needed to state that definitively.

Family context (relevant to any attack, not to PTAB history)

The patent is one of a HERE Global cluster by the same inventors, Raul Cajias and Daniel Rolf, all built on the "map-version-agnostic Bloom filter" concept. This matters because it tells you the art and the claim-drafting patterns HERE used, and because prior art against one is likely relevant to the others:

• US 2021/0123762 A1 — the pre-grant publication of this patent (published 2021-04-29).
• US 2021/0123763 A1 — "Method, system, and computer program product for generating map update data" (server-side counterpart).
• US 2022/0090920 A1 — "…generating map update data using subtree data structures" — cites US 11,391,595 B2, and its claim 1 recites a "subtree data structure" rather than a Bloom filter: same inventive concept, different probabilistic/encoding structure.
• US 2020/0370908 A1 — "Decoding routes to POIs in proximity searches using Bloom filters," Cajias & Rolf, filed 2019-05-22 (app. 16/419,610) — the earliest Bloom-filter map patent in the family (PDF).

Practically: if you are building an invalidity case against '595, the family's own earlier filings and the shared Bloom-filter disclosure are the first place to look, and any IPR you file on '595 should be coordinated with any parallel attack on the siblings to avoid inconsistent claim constructions.

Strategic summary

Claim status: every claim of US 11,391,595 is UNTESTED. No claim has been canceled, disclaimed, amended, or confirmed in any AIA trial. There is no certificate of cancellation, no substitute claim, and no Board construction on the record. Note the sourcing caveat carried forward from the earlier sections: the authoritative text supplied to me does not include the numbered granted claims, and I could not retrieve verbatim claim language — so I cannot enumerate "claims 1–N" as surviving or at risk. Any statement about specific claim numbers should be verified against the granted claims in USPTO Patent Center before it is used in a brief or a demand letter.

Estoppel landscape: completely open. Because no IPR ever reached a final written decision under § 318(a), § 315(e)(2) estoppel does not attach to anyone. No petitioner, real party in interest, or privy is barred from raising any § 102/§ 103 ground in a civil action. There is likewise no § 325(e) PGR estoppel. For a defendant today, this means the entire universe of patents-and-printed-publications prior art remains fully available at the PTAB and in district court, with no "reasonably could have raised" trap. It also means the patent owner has not had to defend its claims against a focused invalidity challenge — a mixed signal: the claims may be vulnerable (never stress-tested), or they may simply never have attracted a well-funded challenger.

Pattern signals: none. No petitioner has filed anything, so there is no serial-filer pattern, no joinder, no second bite at the apple. HERE Global has not been an active PTAB appellant on this patent. There is no defensive aggregator (Unified Patents or similar) in the chain — I found no filing by any such entity. The HERE docket that does show activity is all prosecution-side (roughly 33 pending office actions, per third-party prosecution analytics), not trial-side. The absence of any IPR over ~3.5 years of enforceability is itself informative: well-asserted, commercially significant patents reliably attract IPR petitions, so either this patent has not been asserted in a way that triggered the § 315(b) clock for anyone, or it has been asserted against parties who chose district-court invalidity instead.

Recommended next steps

1. Confirm the baseline on the primary sources before relying on this memo. Verify "no proceedings" directly at PTAB E2E / PTAB Center (https://ptacts.uspto.gov/) and the USPTO Patent Center prosecution and reexamination tabs for US 16/664,372. Absence from an ODP API ingest is strong but not conclusive.
2. Pull the actual granted claims. The prior sections flag that the claim set was not retrievable in this session. For any defendant, obtain the granted claims (and the file wrapper) from Patent Center before mapping an invalidity theory — the independent-claim count and whether "pre-cached identifiers" sits in claim 1 are still unverified.
3. Check for a live § 315(b) window. If your client — or a co-defendant with whom you are not in privity — was served with an infringement complaint asserting '595, calendar the one-year deadline from that service date. Do not assume the Infogation service date (2025-01-23) governs you. If no one has been served, no clock is running and you have the luxury of preparing a petition on your own timeline.
4. Since no FWD exists, there is nothing to link. I cannot quote a disposition, because there is none. If you need a citable record of the negative finding, capture a dated screenshot of the PTAB E2E "Patent No. 11391595" search result and the Patent Center "Post-Grant Review / Inter Partes Review" tab.
5. Consider the non-AIA routes. With PGR time-barred, the residual options are ex parte reexamination under § 302 (any requester, any time, patents/printed publications only) and district-court invalidity. Reexam is a realistic low-cost first move precisely because the patent has never been tested and there is no estoppel to worry about.
6. Coordinate across the HERE Bloom-filter family. US 2022/0090920 A1 cites this patent; US 2020/0370908 A1 shares the inventors and the core disclosure. Any prior-art position you take on '595 should be checked for consistency against those siblings.

Honest limitation: my search coverage was bounded, and absence of a hit is not affirmative proof that no proceeding exists. The structured ODP block is the authoritative statement here, and it says none. Treat the negative as well-supported but verify at PTAB E2E as of today before filing anything that depends on it.

I'll research the assignment chain for US 11,391,595, prioritizing USPTO Assignment Center records and cross-referencing public datasets.

Let me dig into the recorded assignment for the application and cross-reference litigation and NPE directories.

Let me try to directly access the assignment records and check for any post-issuance transfers.

Ownership Chain Analysis — US 11,391,595 B2

Source limitation (read first). My in-session queries returned no live Assignment Center payload for this patent — the direct USPTO Assignment Search query did not surface records I can quote, and I hit the search-step ceiling before a full reel/frame-level pull. What I can state with confidence comes from the patent's own Google Patents legal-events record (which mirrors the assignment events) and cross-referenced public datasets. I therefore report the assignment chain structurally and flag unverified fields (reel/frame, correspondent) rather than invent them. For a prosecution-grade record, the reel/frame must be pulled at https://assignmentcenter.uspto.gov/ (search by patent number 11391595 / application 16/664,372).

Inventors

Pattern notes:

• Both inventors executed the assignment to the operating company at the time of filing/recording (2019-10-28) — the normal employee-invention-assignment pattern, not a late or fire-sale transfer.
• Both inventors stayed with HERE and filed a family of related applications: the sibling publications US 2021/0123763 A1 (map update data generation) and US 2022/0090920 A1 (map update data via subtree data structures) share the Cajias/Rolf inventorship, and a further ROLF/Cajias HERE filing appears at EP 3,696,500 (generating correspondence between map versions, priority 2019-09-03). This is affirmative evidence against the "all inventors departed within 12 months → fire-sale" signal. I found no evidence of either inventor leaving HERE inside 12 months of the 2019-10-25 filing.
• No unusual inventorship pattern (no non-employee inventors, no mixed assignor set) is visible.

Original assignee

HERE Global B.V. (Kennedyplein 222, 5611 ZT Eindhoven, Netherlands; formerly a HERE/Nokia NAVTEQ-lineage entity). Also listed as original assignee; assignment recorded 2019-10-28.

• Primary line of business: digital mapping, location, navigation and automotive-grade map/HD-map platforms and data services. HERE is the mapping/connected-services joint venture spun out of Nokia (successor to NAVTEQ), owned by a consortium of automotive OEMs (Audi, BMW, and Daimler/Mercedes-Benz).
• Ships a product embodying the claims? Yes, in the ordinary sense applicable here — the patent is directed to updating a client map cache against a server map in a version-agnostic way, which maps directly onto HERE's commercial map-update/navigation-data delivery stack (the patent itself names "HERE Venues," "HERE Tracking," "HERE Indoor Positioning" as accused products in unrelated third-party suits, confirming active product lines). The claims are method/apparatus/CPP claims reading on map-data-update pipelines, and HERE operates exactly such pipelines.
• Current status: Operating. No bankruptcy, dissolution, or acquisition of HERE Global B.V. is evident. No recorded reassignment out of HERE Global B.V. appears in the legal-events record.
• Litigation posture (important nuance): HERE appears in public litigation datasets predominantly as the alleged infringer / defendant, not the asserter — e.g., Infogation Corp. v. Here Global B.V., No. 2:24-cv-01005 (E.D. Tex., filed 2024-12-05, Judge Gilstrap); Facet Technology Corp. v. Here Global B.V., No. 2:24-cv-00269 (E.D. Tex.); Route Guidance Systems LLC v. Here Global B.V., 1:22-cv-02274 (N.D. Ill.) (NPE); Omnitek Partners LLC v. Here Global B.V., 6:20-cv-00438 (W.D. Tex.). None of these are HERE asserting '595. I did not confirm that '595 is among the patents asserted in Infogation (the complaint's identified patents were not retrievable in-session), so I make no claim either way.

Assignment timeline

Only one assignment event is visible in the record for this patent:

• 2019-10-28 (recorded; execution date not exposed in the retrieved text) — Reel/Frame: not retrieved in session (unverified)
  • Conveyance: Assignment (Assignment of Assignors' Interest)
  • Assignor: CAJIAS, RAUL; ROLF, DANIEL (the named inventors)
  • Assignee: HERE GLOBAL B.V.
  • Correspondent: not exposed in the retrieved record ("SEE DOCUMENT FOR DETAILS" per Google Patents' event text). Recorded-address/attorney field must be read from the Assignment Center entry for patent 11391595. Cannot assess recurrence without that field.
  • Context: Ordinary employee invention assignment at the operating company — inventors signing over rights to their employer. Not an acquisition, fire-sale, reorg, securitization, or transfer-to-asserter.

No post-issuance (post-2022-07-19) assignment, license, security agreement, merger, or release is recorded. That absence is itself the finding: title remains with the original operating-company assignee, HERE Global B.V.

Cross-reference caution (carried from the prior section): do not conflate this with US application 11/391,595 (Samsung Electronics, "Apparatus and Method for Measuring Speed of a Moving Object," filed 2006-03-27). That is a pre-AIA application serial number, unrelated to this patent. Likewise US 11,470,595 B2 (Wilus Institute) is unrelated.

Timeline diagram

timeline
    title Ownership of US 11391595
    2019 : Filed by HERE Global BV
         : Inventor assignment recorded to HERE
    2021 : Pre-grant publication US20210123762A1
    2022 : Patent granted US11391595B2
         : Title still held by HERE Global BV
    2024 : HERE sued as defendant by NPEs
         : No assignment out of HERE

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. No transfer to any "IP / Patents / Licensing / Holdings / Ventures" LLC. Current assignee remains HERE Global B.V. (an operating map/navigation company); there is no recorded transfer to a single-purpose vehicle.

2. Known asserter in the chain — Not present. Neither assignor (Cajias, Rolf) nor assignee (HERE Global B.V.) matches the named NPE list (Acacia, Marathon, IV, Wi-LAN/Conversant, Vringo, Pendrell, Round Rock, etc.). HERE appears in litigation records as an alleged infringer, not an asserter. The NPEs that do surround HERE (Route Guidance Systems LLC — asserted against HERE per Unified Patents, 1:22-cv-02274; Omnitek Partners LLC) are plaintiffs against HERE, not assignees in HERE's chain.

3. Repeat correspondent across the chain — Unclear / not assessable. Only one link exists, and the correspondent field was not exposed in my retrieved record. A single appearance would not be a finding in any event; I flag it as unverified pending the Assignment Center pull.

4. Cascading transfers — Not present. There is exactly one recorded assignment (the 2019 employee assignment); no chained LLC transfers within 24 months.

5. Pre-litigation transfer — Not present. No assignment transaction precedes any suit, because no transfer at all post-dates issuance. HERE has not asserted '595.

6. Bankruptcy fire-sale — Not present. HERE Global B.V. is an operating JV; no Chapter 7/11 sale of this patent is on record.

7. Privateering — Not present. No operating-company→NPE transfer. HERE retains title; there is no third-party asserter acting on HERE's behalf for this patent.

8. Defensive aggregator (anti-NPE) — Not present. Chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN.

Summary: zero NPE signals present; one field-level signal (correspondent) unverified.

Verdict

Insufficient data (only the original assignment).

Per the verdict definitions, this patent has no records beyond the original assignment — a single 2019-10-28 employee-invention assignment of inventors Cajias and Rolf to HERE Global B.V., with no post-issuance transfer recorded. That absence is itself the substantive result: an operating company (HERE Global B.V.) retains clean, unbroken title, and none of the eight NPE-pattern signals is present in the chain. I therefore do not classify this as an NPE matter; the only reason the verdict is not a stronger "operating-company / non-asserting" call is that (a) I was unable to retrieve reel/frame and correspondent fields, and (b) the record shows HERE as a target of NPE suits rather than an asserter, so there is no affirmative assertion activity by the owner to characterize.

Verification links:

• USPTO Assignment Center — search patent number 11391595 / application 16/664,372: https://assignmentcenter.uspto.gov/
• Mirror index: https://assignment.uspto.gov/patent/index.html
• Google Patents legal events (source of the single 2019-10-28 assignment entry): https://patents.google.com/patent/US11391595/en
• NPE/asserter context: https://npe.law.stanford.edu/party/here-global-bv and https://www.unifiedpatents.com/insights/2025/8/8/route-guidance-systems-vehicle-guidance-patent-confirmed-invalid-by-[ptab](/ptab)

If a later session can pull the reel/frame + correspondent from Assignment Center, the one open item (repeat-correspondent analysis) can be closed; everything else already points to a normal operating-company ownership with no troll-pattern footprint.

I'll research the prior-art citations for US 11,391,595. Let me run several searches.

I found the patent's own "References Cited" list. Let me retrieve the complete citation list from the patent PDF and cross-references.

Scope note before the analysis

I ran the searches against live web sources. My search tool reaches the USPTO-hosted patent full-text PDF (via patentimages.storage.googleapis.com) and the Google Patents / Justia records for US 11,391,595, but I did not get a direct Patent Center / PatFT "References Cited" query result. So the list below comes from the (56) block printed on the face of the granted patent (US11391595.pdf), which is the authoritative citation list. I flag below exactly what I could and could not verify.

Nothing in this retrieval contradicts the previously generated sections; the earlier caveat that the granted claim text is not in hand still stands and materially limits any §102 conclusion.

The patent is confirmed as US 11,391,595 B2, application 16/664,372, filed/priority 2019-10-25, granted 2022-07-19, HERE Global B.V., inventors Cajias and Rolf. No similar number is being substituted.

1. The (56) "References Cited" list on the face of US 11,391,595

Verification caveat. The abstract snippet I could retrieve showed this block marked "(Continued)," meaning the printed list continues onto the next column. Therefore the list below is partial — I could see the U.S. patent documents and U.S. application publications, but foreign patent documents and any further entries were not retrievable. Do not treat this as the complete citation list.

1a. U.S. Patent Documents

1b. U.S. Patent Application Publications

On the asterisk (*): many patents use an asterisk in the (56) list to flag examiner-cited vs. applicant-cited references. I am not certain of the extraction convention used in this PDF, so I am not asserting which references were examiner- vs. applicant-cited. Treat the asterisks as printed but of unverified meaning.

1c. Non-Patent Literature (the most on-point reference)

• Jonnich et al., "Dynamic Map Update Protocol for Highly Automated Driving Vehicles," Proceedings of the 3rd International Conference on Vehicle Technology and Intelligent Transport Systems (VEHITS 2017), pp. 68–78.
  • This is, by title and context, the most conceptually relevant reference on the face of '595 — it addresses dynamic map-update protocols for automated driving, i.e., client↔server map-update exchange where the client and server hold different map versions. It is a natural candidate for the §102(a)(1)/§102(b) "prior art" discussion for claim 1's "map update request / map update data" steps — but whether it discloses a Bloom filter encoding digests of map-area-ID + content (the actual point of novelty) must be confirmed by reading the paper, which I have not retrieved in full.
• Murray, "Map Visualization Developer's Guide," Oracle — retrieved Oct. 25, 2019 (Oracle Database docs). This is a technical-background/§102(b) printed publication reference; likely cited to characterize map-tile/grid partitioning and bounding boxes, not for the Bloom-filter novelty.

2. Forward citations ("Cited By") — NOT prior art, but flagged for a §102(a)(2) trap

The Google Patents record shows '595 is cited by a large block of HERE Global sibling patents/applications, including:

• US 10,794,717 B1; US 10,809,074 B1; US 10,861,333 B1 (priority 2019-06-04)
• EP 3742122 A1; EP 3742123 A1; US 2020/0370911 A1; US 2020/0370917 A1; US 2020/0370918 A1; US 2020/0370908 A1; US 2020/0386556 A1 (priority 2019-05-22)
• US 2021/0123747 A1; US 2021/0123759 A1; US 2021/0123761 A1; US 2021/0123763 A1; US 11499838 B2 (priority 2019-10-25, same day)

These are forward citations and are not "prior art cited in" '595. However, the 2019-05-22 HERE applications (Cajias/Rolf, e.g., "Bloom filter route encoding" US 2020/0370903, "Decoding routes to POIs … using bloom filters" US 2020/0370908) have an effective filing date earlier than '595's 2019-10-25 date and published 2020-11-26. If the examiner or a litigant treats them as §102(a)(2) art, note the §102(b)(2)(C) common-ownership exception (all HERE Global B.V.) — this is a flag for validity analysis, not a conclusion.

3. Honest bottom line on the §102 question

To answer "which claim(s) it potentially anticipates under 35 U.S.C. § 102" rigorously, I need two things I do not have:

1. The granted claim text. Still unavailable this session. The claim set is reconstructed from the specification's "aspects" paragraphs, which usually but not always mirror the independent claims (method, apparatus, computer-program-product). Any statement that a reference "anticipates claim 1" is therefore provisional.
2. The full reference texts, especially the Jonnich VEHITS-2017 paper — I have only the citation, not its disclosure.

With those limits stated, my grounded reading is:

• No reference on the visible (56) list appears, on its face, to disclose the specific combination that is the point of novelty of '595: (i) a bounding box, (ii) a Bloom filter encoding digests computed from map-area-identifier + that area's content, (iii) transmitted as the map update request, and (iv) updating the local map database with only the areas whose digests fail the filter. The face citations read as a mix of navigation/map-display background (Rasmussen, Brackett, Becker, Brachet), display/compression/telemetry art (Opala, Sirion, Addepalli), and one on-point NPL reference (Jonnich et al.).
• Therefore, on the record I retrieved, the citations support §103 obviousness-type reasoning (each element found across references), not a clean single-reference §102 anticipation. The one candidate for a §102 argument would be Jonnich et al. (VEHITS 2017) — and only if its text actually discloses a Bloom-filter/digest-based partial map update. Unverified.

4. What I recommend to close the gaps

1. Pull the complete (56) block (including the "Continued" column and any foreign patent documents) from the USPTO full-text PDF at https://patentimages.storage.googleapis.com/34/33/09/a1a15cb5782ae2/US11391595.pdf — I could only retrieve a fragment.
2. Pull the granted claims from USPTO Patent Center (application 16/664,372) so the §102 mapping is to literal claim language.
3. Retrieve the Jonnich et al. VEHITS 2017 paper full text — it is the single most decision-relevant prior-art item.
4. For any Inter Partes review / litigation posture, confirm whether the 2019-05-22 HERE sibling applications create §102(a)(2) exposure and whether §102(b)(2)(C) common ownership neutralizes it.

Search limitation (stated explicitly): I reached the patent's face citations via the patent PDF and Google Patents/Justia; I did not obtain the complete citation list or any foreign citations, and I found no PTAB/CAFC record naming 11,391,595 this session. Absence of a found record is not evidence that none exists.

I'll gather the actual prior-art record for this patent before analyzing.

Let me pull details on the specific references cited on the face of '595 and the closest non-patent literature.

Update to previously generated sections (important)

Two items from my earlier "Points of uncertainty" are now resolved — and one is a correction I should flag explicitly:

1. Claim text now partially verified. The granted claim 1 of US 11,391,595 B2 has been located in the patent PDF (https://patentimages.storage.googleapis.com/34/33/09/a1a15cb5782ae2/US11391595.pdf), as has claim 2. My earlier statement that claim language was "not verified" is superseded. Claim 1 reads (verbatim, formatting normalized):

   "1. A method for updating a map database, the method comprising: identifying a bounding box specifying a region of a map to be updated; obtaining a plurality of map area identifiers and the corresponding map area content based on the bounding box; generating a bloom filter, wherein the bloom filter encodes a plurality of digests based on the plurality of map area identifiers and the corresponding map area content; transmitting, over a network, a map update request comprising the generated bloom filter to an update server; receiving map update data for at least a portion of the plurality of map area identifiers and the corresponding map area content; and updating, by one or more processors, the map database based on the received map update data."

   "2. The method of claim 1, wherein the plurality of map area identifiers and the corresponding map area content represent data corresponding to one of map tiles or map cubes."

   Note two things my earlier functional summary got slightly wrong: claim 1 does not require the bounding box to be transmitted in the request (only the Bloom filter), and it does not contain the "pre-cached identifiers" limitation (that is a specification/FIG. 6 feature and, per my earlier note, likely a dependent claim). This matters for §103 — it broadens the independent claim.

2. The prior-art record (56) references are now identified from the printed patent and Google Patents, and are listed below. My earlier statement that the prior art was unknown is superseded.

Obviousness analysis of US 11,391,595 B2 under 35 U.S.C. § 103

1. Legal framework applied

Under Graham v. John Deere, 383 U.S. 1 (1966), I assess (a) the scope and content of the prior art, (b) the differences between the prior art and the claims, (c) the level of ordinary skill, and (d) objective indicia. Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), a claim is obvious where (i) a known technique is applied to a known structure to yield predictable results, (ii) a finite number of identified, predictable solutions yields the claimed result ("obvious to try"), or (iii) a design need or market pressure prompts a known variation. The motivation to combine need not be found in the references themselves — it may come from the "background knowledge, creativity, and common sense of the person of ordinary skill" (KSR; In re Bozak).

Level of ordinary skill (my proposed construct): a person with a bachelor's degree in computer science, computer/electrical engineering, or geographic information systems, plus ~2–4 years' experience in navigation/mapping systems, network protocols, and data structures — including familiarity with hash functions, checksums, and probabilistic data structures such as Bloom filters. The art is highly predictable.

2. The prior art of record (scope and content)

2a. References cited on the face of '595 (from the printed patent's "(56) References Cited")

2b. Relevant field knowledge and additional art the analysis must draw on

• US 2014/0101096 A1, "Method and apparatus for providing incremental database updates based on delta pages" (Nokia) — frames the identical problem statement to '595: preloaded geographic databases on embedded devices "face significant technical challenges to ensuring that the databases are up-to-date and consistent between server side components and the client devices," and "the databases can be frequently updated." Its solution: compute a difference patch between a new page of the server DB and the corresponding reference page of the client DB, and send only the patch. (https://patentimages.storage.googleapis.com/22/3b/c3/b12f8be3f6a810/US20140101096A1.pdf)
• Bloom filters (B. Bloom, Space/Time Trade-offs in Hash Coding with Allowable Errors, CACM 13(7):422–426 (1970)) — a bit array of m bits with k hash functions encoding set membership; false positives possible, false negatives not. This is exactly the structure '595 recites, verbatim in its spec.
• Bloom filters applied to cache summarization and inter-node content exchange — the canonical example being L. Fan, P. Cao, J. Almeida & A. Broder, "Summary Cache: A Scalable Wide-Area Web Cache Sharing Protocol," IEEE/ACM Trans. Networking 8(3) (2000), and the Squid "Cache Digests" scheme, both of which transmit a bit array summarizing a cache's contents so a peer can determine what the other node has and transfer only the missing objects. This is the identical functional architecture as '595, in a different content domain (web objects vs. map tiles).
• The tile-ID scheme itself. Map partitioning into a grid where the identifier encodes LEVEL/row/column (with 2^L × 2^L cells at level L) is the industry-standard "slippy map"/XYZ tiling convention and is also the NDS scheme the '595 spec itself names (see '595 ¶ re "NDS (Navigation Data Standard)" and the description of TILE ID). These "map version agnostic" IDs are ubiquitous and pre-date 2019.

Caution: I could not, in this session, retrieve the full text of the Jonnich VEHITS 2017 paper, nor confirm the subject matter of US 8,369,264 / 7,962,281 / 8,243,080 / 9,026,615 / 9,654,937 / 2015/0264554 / 2008/0176583 beyond their CPC codes and titles as listed. I therefore treat Jonnich as "a cited art-recognized map-update protocol" and do not attribute specific teachings to it beyond its title/venue. Any assertion in an IPR or office action about Jonnich's precise disclosure must be verified against the paper itself.

3. Element-by-element mapping of claim 1

Net: every limitation is individually in the art; the only question is whether the combination (content-derived digests → bloom filter → client→server request → selective return → local DB update) is non-obvious.

4. Proposed § 103 combinations

Combination 1 (primary): Jonnich + Bloom-filter cache summarization (Summary Cache / Cache Digests) + conventional map tiling

• Jonnich (VEHITS 2017) supplies the client↔server dynamic map update protocol for a vehicle whose local map may differ in version from the backend's.
• The Bloom-filter cache-summarization art supplies the technique of encoding a cache's contents into a bit array and transmitting that array to a peer so the peer can determine what the sender already has and send only the remainder. The '595 spec's own recitation of the Bloom filter (empty filter = m bits of 0; k coding functions; "possibly in set"/"definitely not in set") is the textbook Bloom-filter description, unchanged.
• Conventional tiling supplies the "map area identifier … level, column and row" that is version-agnostic by construction.

Motivation: Both references address the same technical problem — exchanging content efficiently across a bandwidth-limited network when the two endpoints hold different, independently-updating copies of a data set. A POSITA optimizing Jonnich's map-update protocol, and knowing that Bloom filters had already been used to summarize cache state to avoid transmitting redundant content, would predictably reach for the Bloom-filter summarization technique. Result: fewer bytes on the wire, no need to keep N historical map versions server-side. That is a predictable improvement of a known process.

Combination 2: US 2014/0101096 (delta pages) + US 9,851,209 / US 8,880,589 (hash signatures of map tiles) + Bloom filter encoding

• US 2014/0101096 supplies the map-version-divergence problem statement and the "send only the difference" solution for preloaded geographic databases.
• The signature-based-map-caching family supplies the hash-a-map-tile-property-set (including level/column/row) to produce a signature/digest idea, and even uses MD5.
• The Bloom-filter art supplies the packing of a set of such digests into one small bit array for transmission.

Motivation: US 2014/0101096 expressly seeks to minimize transmitted data; it computes differences between server and client pages. A POSITA seeking to reduce the request-side traffic further would recognize that instead of enumerating which pages the client has, the client can send a compact probabilistic summary. Encoding the client's per-tile hash signatures into a bloom filter is the natural, known way to do that. This is a classic KSR "combination of familiar elements according to known methods yields predictable results."

Combination 3: Jonnich + US 9,851,209/US 8,880,589 + US 2014/0101096 + Bloom-filter technique (the full stack)

If the examiner requires all elements anchored in map-specific references, the stack above covers (i) the map-update protocol (Jonnich), (ii) hashing tile identifiers/properties into digests (signature-based caching family — note both US 8,880,589 B2 and US 9,851,209 B2 are on the face of '595), (iii) sending only differences for map content (delta pages), and (iv) the Bloom filter as the encoding/transport vehicle (well-known art, restated by the spec itself).

5. Why a POSITA would have combined — the KSR motivations spelled out

1. Same field, same problem. Every reference is in navigation/mapping or network content distribution, and each independently recites (or responds to) the identical problem: a client holds an outdated copy of a frequently-updated data set, and updating it is bandwidth- and storage-constrained. '595's own Background concedes that "maintaining multiple versions of the digital map" server-side "is not viable."
2. Known technique, applied to a known structure. The Federal Circuit and KSR treat applying a known data-structure technique to a new but analogous data set as obvious. Bloom-filter summarization of a cache to reduce inter-node traffic (Summary Cache; Cache Digests) is precisely that technique, and "cache" is what a client-side map database is.
3. Finite number of predictable solutions. Facing the "how do I tell the server what I already have without enumerating it?" problem, a POSITA has a small, well-characterized menu: (i) send a version number/ETag per tile, (ii) send a list of tile IDs + versions, (iii) send a hash/checksum per tile, or (iv) send a compact probabilistic summary of a set of hashes. Option (iv) is the claimed approach and was a known, off-the-shelf option with a reasonable expectation of success.
4. Desirability / market pressure. Mobile/vehicle links are bandwidth- and cost-limited and the app must work offline (the spec says so; US 2014/0101096 says so). The incentive to shrink the request is strong and recited by the references themselves.
5. Accepted trade-off. The Bloom filter's false positives (which can cause a needed update to be skipped) are a known, bounded, acceptable cost that the '595 spec itself acknowledges ("False positive matches are possible, but false negatives are not"). No reference teaches away; the trade-off is the price of the bandwidth win.

6. Dependent claims / alternative embodiments — also likely obvious

• Claim 2 (map tiles or map cubes). Tiles are ubiquitous; cube (3-D) partitions are the 3-D analogue the '595 description itself says "may be a … map cube (i.e. a three dimensional partition)." Routine, and squarely within the ordinary artisan's skill.
• "Pre-cached identifiers only" (FIG. 6; likely a dependent claim). Encoding only identifiers for which local content exists is a trivial optimization — a Bloom filter's membership semantics require an element to exist to be hashed in; skipping absent elements is inherent.
• Digests computed with "at least one coding function" / SHA / MD5. MD5 hashing of map properties is literally claimed in US 8,880,589 B2 claim 8 and in US 9,851,209 B2. Obvious over the signature-based-caching family alone.
• "Content granularity level (LEVEL) associated with the map database." LEVEL-encoded tile IDs are the standard tiling scheme (and disclosed in US 9,851,209 B2's "level, column and row" description).
• "Size of the bloom filter is based on a number of map area identifiers in the bounding box." Sizing a Bloom filter as a function of expected element count is the standard, textbook Bloom-filter design rule (m = −n·ln p / (ln 2)²). Obvious.
• "Providing the updated map database to a navigation application." Mere intended use / field-of-use of a conventional DB update.

7. The strongest non-obviousness positions the patent owner would (and could) assert

I state these because a fair § 103 analysis must confront them — not to endorse them:

1. "Bloom filter as a content-equality oracle, not a membership oracle." Standard Bloom-filter applications ask "is element X in set S?" The '595 asks something subtly different: the client packs hashes of (ID, client-content) pairs, and the server tests hashes of (ID, server-content) pairs — using Bloom-filter membership as a proxy for "my content equals yours." A patent owner will argue the prior art used Bloom filters to summarize which objects are cached (by object identity), not to test whether two independently-versioned copies of the same object are identical by folding content into the hash.
   • Rebuttal: US 9,851,209/US 8,880,589 already hash map properties (which are exactly the parameters that distinguish one map artifact from another) to form the comparison key, and content-fingerprinting with hashes is routine; folding the content into the hash is the predictable way to make the digest change when content changes. The '595 spec supplies no algorithm for the digest beyond "hash the TILE ID and the content," which is the definitional SHA/MD5 use.
2. "Bloom filters are the wrong tool here because false positives cause missed updates." The owner could argue a POSITA would not choose a structure with retention-risk false positives for a correctness-critical map-update task, i.e., a teaching away.
   • Rebuttal: no reference disparages Bloom filters for this use; the trade-off is a routine bandwidth/accuracy engineering choice, and the spec itself comfortably accepts it. Mere "the tool has a known downside" is not a teaching away absent a statement that the combination is unsatisfactory (In re Fulton).
3. Objective indicia. None currently in evidence before me. The existence of the Infogation Corp. v. HERE Global B.V., No. 2:24-cv-01005 (E.D. Tex., filed 2024-12-05) suit and the family of HERE Bloom-filter sibling applications (e.g., US 2020/0370903 A1, US 2021/0123763 A1, US 2022/0090920 A1, US 11,353,331, US 11,499,838) shows the assignee's own active investment in this space, that the area was commercially important to HERE.
   • Caveat: objective indicia require a nexus between the evidence and the claimed subject matter; and sibling HERE applications, if commonly owned, are not § 102/103 prior art against '595 at all (35 U.S.C. § 102(b)(2)(C)). I flag this so the sibling applications are not mistakenly cited against '595.

8. Conclusion

• No single reference of record appears to anticipate claim 1 — the specific Bloom-filter-encoding-of-content-derived-digests is not shown in the map-update art in a single reference. § 102 is not the primary attack.
• Claim 1 is, in my assessment, vulnerable to a strong § 103 challenge built on: Jonnich (VEHITS 2017) + the Bloom-filter cache-summarization art (Bloom 1970; Summary Cache / Cache Digests) + conventional map tiling, with US 2014/0101096 (delta pages) and US 8,880,589 B2 / US 9,851,209 B2 ("Signature based map caching," both cited on the face of '595) supplying the map-specific hashing/digest and "send only the difference" teachings. The motivation is supplied by the shared problem, the small closed set of predictable solutions, and the bandwidth/pressure incentives that the references themselves recite.
• The dependents add little. Claim 2 (tiles/cubes), MD5/SHA hashing, LEVEL granularity, and Bloom-filter sizing as a function of element count are each individually obvious over the cited art.
• The one genuinely non-trivial conceptual step — using a Bloom filter as a content-equality test (hashing the map area's content together with its version-agnostic ID, rather than merely hashing object identities) — is the most defensible non-obviousness position, and any IPR petition should meet it head-on with a content-fingerprinting/hashing-over-data reference rather than relying on the identity-based cache-summarization art alone.

9. Explicit uncertainties

• I could not retrieve the full text of the Jonnich et al. VEHITS 2017 paper in this session; its precise disclosure (beyond being a dynamic map-update protocol for automated driving) is unverified, and the combinations above are constructed on the patchwork of references, not on Jonnich alone.
• I could not confirm the subject matter of US 8,369,264; US 7,962,281; US 8,243,080; US 9,026,615; US 9,654,937; US 2015/0264554; US 2008/0176583 beyond their titles/CPC codes as printed in the patent's (56) list. Treat any teaching attributed to these as provisional.
• Claims 3 and beyond were not retrieved (the PDF snippet truncated at "3. The…"). The dependent-claim analysis above draws on claim 2 (verified) plus the specification's enumerated "aspects"; if claim 3+ contains an unexpected limitation, it may narrow the viable rejection.
• The Bloom-filter prior-art citations (Bloom 1970; Fan et al. Summary Cache 2000; Squid Cache Digests) are well-established general-knowledge references I am citing as art-recognized background; I have not re-verified their bibliographic details by live retrieval in this session beyond general knowledge, and an office action would need them formally authenticated as printed publications with pre-2019 dates.
• My analysis assumes a 2019-10-25 effective filing priority for '595; if any earlier priority is later established, some of the mapping references would need re-dating.

Primary sources: https://patents.google.com/patent/US11391595/en; claim 1/2 text from https://patentimages.storage.googleapis.com/34/33/09/a1a15cb5782ae2/US11391595.pdf; https://patents.google.com/patent/US9851209B2/en; https://patents.justia.com/patent/9851209; http://patentimages.storage.googleapis.com/5d/7e/dc/474a87c0cf3e84/US8880589.pdf; https://patentimages.storage.googleapis.com/e2/27/a3/3f1bcf15256550/US20120173606A1.pdf; https://patentimages.storage.googleapis.com/22/3b/c3/b12f8be3f6a810/US20140101096A1.pdf.