[ blog · comparison ]11 min read

API Google Patents jest martwe — 6 alternatyw do badania stanu techniki i swobody działania

Sarah Choy·Opublikowano 3 maja 2026·11 min czytania

Google Patents Public Datasets zostało wycofane bez udokumentowanego zastępnika, a USPTO w połowie 2026 roku przeniosło PEDS do nowego Open Data Portal, psując po drodze potoki danych. Oto co naprawdę działa w 2026 roku dla zadań związanych ze stanem techniki, FTO i badaniami własności intelektualnej — sześć alternatyw, obok siebie.

TL;DR

• •API Google Patents Public Datasets zostało wycofane; nie ma własnego zastępnika Google dla programowego wyszukiwania patentów.
• •USPTO zastąpiło stare PEDS przez Open Data Portal (ODP) — pełny tekst i metadane dla zgłoszeń amerykańskich, REST + JSON, za darmo.
• •EPO OPS jest najbardziej autorytatywne dla rodzin międzynarodowych, ale zwraca XML i ma ograniczenia szybkości.
• •PatentsView (finansowane przez USPTO) jest świetne do metadanych i ujednoznaczniania, ale brakuje mu pełnotekstowych zastrzeżeń.
• •API Pick Patent Search opakowuje wyszukiwanie semantyczne po USPTO + EPO + WIPO + JPO + KIPO + CNIPA w jednym punkcie końcowym POST, JSON na wejściu / JSON na wyjściu, 80 kredytów za wywołanie.

Co się zmieniło i dlaczego powstał ten artykuł

Dwie rzeczy zepsuły się w ekosystemie API do wyszukiwania patentów między 2024 a 2026 rokiem, i zepsuły się w tym samym czasie.

Po pierwsze, API wyszukiwania po słowach kluczowych Google Patents Public Datasets — de facto domyślny wybór niezależnych programistów zajmujących się stanem techniki i wywiadem konkurencyjnym — przestało być utrzymywane. Zbiór danych patents-public-data w BigQuery nadal tam jest na potrzeby analityki masowej, ale proste punkty końcowe https://patents.googleapis.com/..., które zasilały większość narzędzi patentowych z weekendowych projektów, zniknęły. Wyszukaj "Google Patents API alternative 2026", a znajdziesz sto pytań na Stack Overflow i zero odpowiedzi.

Po drugie, USPTO wycofało stary Patent Examination Data System (PEDS) pod koniec 2024 roku i migruje pozostałe masowe punkty końcowe do nowego Open Data Portal (ODP) do 29 maja 2026 roku. Potoki, które scrape'owały odpowiedzi XML z PEDS, zaczęły się psuć na początku 2025 roku; zespoły, które nie zmigrowały do I kwartału 2026 roku, są teraz po cichu zepsute.

Oba wydarzenia miały miejsce mniej więcej w tym samym czasie, gdy startupy z obszaru AI-dla-własności-intelektualnej (Solve Intelligence, Patlytics, NLPatent, IPRally, &AI) pozyskały poważne pieniądze — samo Solve Intelligence zamknęło rundę Series B o wartości $40M na wyszukiwanie i sporządzanie patentów z użyciem AI. Popyt nigdy nie był wyższy; strona podażowa właśnie zrobiła się bardziej chaotyczna.

Oto sześć API, które naprawdę działają w 2026 roku, w czym każde jest dobre i gdzie każde nie dociąga.

Sześć opcji

1. USPTO Open Data Portal (ODP)

Oficjalny amerykański zastępnik PEDS. REST + JSON, za darmo, pokrywa zgłoszenia patentowe, przyznane patenty i dane o cesjach z United States Patent and Trademark Office. Pełny tekst dostępny. Dokumentacja na developer.uspto.gov.

Mocne strony: autorytatywne, darmowe, pokrywa pełny tekst. Słabe strony: tylko USA (nadal będziesz potrzebować EPO OPS lub innych do zakresu międzynarodowego), zmiany schematu w oknie migracji zepsuły niektóre potoki, brak wyszukiwania semantycznego — tylko słowa kluczowe/Boolean.

2. EPO OPS (Open Patent Services)

API dla programistów European Patent Office. Pokrywa EP, WO i wiele zgłoszeń krajowych za pośrednictwem bazy danych INPADOC. Autorytatywne dla wyszukiwania rodzin międzynarodowych i danych PCT.

Mocne strony: najlepszy zasięg międzynarodowy, zawiera status prawny i informacje o rodzinie. Słabe strony: zwraca XML (ciężkie parsowanie), poziom darmowy ograniczony do 500 MB/tydzień, osobny punkt końcowy fulltext, przepływ OAuth dla wyższych poziomów. Stroma krzywa uczenia się dla integratorów po raz pierwszy.

3. PatentsView

Narzędzie badawcze finansowane przez USPTO. Silne w metadanych: ujednoznacznianie uprawnionych, profile wynalazców, sieci cytowań, finansowanie z interesu rządowego. Za darmo.

Mocne strony: czyste, ujednoznacznione encje, łatwe REST + JSON. Słabe strony: brak pełnotekstowej treści zastrzeżeń, ukierunkowane na USA, opóźnienie względem zgłoszeń w czasie rzeczywistym, nieoptymalizowane pod wyszukiwanie podobieństwa semantycznego.

4. Lens.org

Agregator obejmujący ponad 95 mln patentów z ponad 100 jurysdykcji oraz prace naukowe. Używany przez analityków własności intelektualnej i badaczy akademickich. Darmowy poziom akademicki; poziom komercyjny fakturowany.

Mocne strony: najszerszy zasięg jurysdykcji, łączy patenty z literaturą naukową, dobry interfejs do dalszej pracy człowieka. Słabe strony: nieprzejrzysta wycena komercyjna, wyszukiwanie semantyczne jest wspomagane słowami kluczowymi, a nie natywnie oparte na osadzeniach.

5. PQAI (Project PQAI)

Projekt wyszukiwania patentów o otwartym kodzie prowadzony przez zespół własności intelektualnej AT&T. Za darmo, podobieństwo semantyczne po USPTO + EPO. Popularny w społeczności niezależnej / r/LocalLLaMA — zobacz wpis na DEV.to "I posted my patent search AI to Reddit and got 65 upvotes", który wydobył ten zakątek ekosystemu na światło dzienne.

Mocne strony: darmowe, semantyka na pierwszym miejscu, brak klucza API potrzebnego przy umiarkowanym wolumenie. Słabe strony: dostępność na zasadzie najlepszych starań, brak SLA, mniejszy zasięg jurysdykcyjny, brak wsparcia komercyjnego.

6. API Pick Patent Search

Wyszukiwanie semantyczne po USPTO + EPO + WIPO + JPO + KIPO + CNIPA w pojedynczym wywołaniu REST. JSON na wejściu / JSON na wyjściu, 80 kredytów za wywołanie (~$0,08 przy $5 / 5000 kredytów), rozliczenie tylko przy sukcesie. Zwraca tytuł, streszczenie, fragment, URL, jurysdykcję i uprawnionego dla każdego trafienia.

Mocne strony: jeden punkt końcowy pokrywający wszystkie główne urzędy, uszeregowane wyniki semantyczne wstępnie sformatowane pod konsumpcję przez LLM, przewidywalna cena za wywołanie. Słabe strony: mniej konfigurowalne niż bezpośrednie EPO OPS w brzegowych przypadkach statusu prawnego; jeśli potrzebujesz masowej analityki zbiorów danych, BigQuery nadal jest lepsze niż API rozliczane za wywołanie.

Obok siebie

Działający kod: to samo zapytanie o stan techniki, na sześć sposobów

Przykładowe zapytanie: "wireless charging coil with embedded ferrite for under-display sensors." Prawdziwe pytanie w kształcie FTO.

USPTO ODP

import requests

# Open Data Portal — keyword/Boolean
r = requests.get(
    "https://api.uspto.gov/api/v1/patent/applications/search",
    params={
        "query": "wireless charging coil ferrite under-display",
        "fields": "applicationNumber,inventionTitle,filingDate,abstractText",
        "limit": 25,
    },
)
print(r.json()["results"][:3])

EPO OPS

import requests
from base64 import b64encode

# OAuth: token from Consumer Key + Secret
auth = b64encode(b"YOUR_KEY:YOUR_SECRET").decode()
token = requests.post(
    "https://ops.epo.org/3.2/auth/accesstoken",
    headers={"Authorization": f"Basic {auth}"},
    data={"grant_type": "client_credentials"},
).json()["access_token"]

# Then search
r = requests.get(
    "https://ops.epo.org/3.2/rest-services/published-data/search",
    params={"q": 'ti="wireless charging coil ferrite"'},
    headers={"Authorization": f"Bearer {token}", "Accept": "application/xml"},
)
# Returns XML — you'll need lxml or xmltodict
print(r.text[:500])

PatentsView

import requests

r = requests.post(
    "https://search.patentsview.org/api/v1/patent/",
    headers={"X-Api-Key": "YOUR_KEY"},
    json={
        "q": {"_text_phrase": {"patent_title": "wireless charging coil"}},
        "f": ["patent_id", "patent_title", "patent_date", "assignees"],
        "o": {"size": 25},
    },
)
print(r.json()["patents"][:3])

Lens.org

import requests

# Lens uses Lucene-style queries; commercial endpoints require paid token
r = requests.post(
    "https://api.lens.org/patent/search",
    headers={"Authorization": "Bearer YOUR_TOKEN"},
    json={
        "query": {
            "match": {
                "full_text": "wireless charging coil ferrite under-display sensor"
            }
        },
        "size": 25,
    },
)
print(r.json()["data"][:3])

PQAI

import requests

r = requests.get(
    "https://api.projectpq.ai/patents/",
    params={
        "q": "wireless charging coil with embedded ferrite for under-display sensors",
        "n": 10,
    },
)
print(r.json()["results"][:3])

API Pick Patent Search

import requests

r = requests.post(
    "https://www.apipick.com/api/search/patents",
    headers={"x-api-key": "pk_yourkey"},
    json={
        "query": "wireless charging coil with embedded ferrite for under-display sensors",
    },
)
print(r.json()["results"][:3])
# Each result: { title, abstract, snippet, url, jurisdiction, assignee }
# Ranked by semantic similarity. 80 credits, only on HTTP 200.

Jak wybrać, według przypadku użycia

Dokąd to zmierza

AI-dla-własności-intelektualnej to obecnie jedna z najszybciej rozwijających się wertykali oprogramowania. W ciągu 18 miesięcy założenie, że "wyszukiwanie patentów = wpisanie zapytania Boolean w interfejsie", będzie wyglądać równie staromodnie jak "wyszukiwanie kodu = wpisanie wyrażenia regularnego w grep". Zespoły, które dziś dostarczają działające produkty, to te, które w 2025 roku zapłaciły podatek migracyjny — ustawiły odporny dostęp programowy, nałożyły warstwę wyszukiwania semantycznego i zbudowały potok czyszczący na nieuniknioną zmienność schematów ze źródeł publicznych.

W przypadku większości agentów AI w produkcji nie musisz wybierać jednego API — potrzebujesz rozsądnego domyślnego wyboru z przewidywalną ceną i możliwości zejścia do źródła niższego poziomu w przypadkach brzegowych. Dlatego zbudowaliśmy API Pick Patent Search jako pojedynczy punkt końcowy semantyczny obejmujący główne urzędy: pokrywa 95% obciążeń agentów, a pozostałe 5% może wywołać EPO OPS lub USPTO ODP bezpośrednio. Towarzyszące URL Extract podejmuje pałeczkę tam, gdzie którekolwiek z tych narzędzi ją odkłada — pobierając pełny tekst konkretnego zgłoszenia do dogłębnej analizy zastrzeżeń.

Autor

Sarah Choy

CEO, API Pick

Sarah Choy jest CEO API Pick. Pisze o budowaniu produkcyjnych API dla agentów AI i przepływów pracy z LLM.