fetch
ChatGPTDeep Research compatible fetch — single string parameter. Returns {id, title, text, url, metadata} for the publication. Body uses the smart section (title + biblio + abstract + claim 1) to keep token cost low for multi-document Deep Research workflows. Not for normal conversations — there, use findip_get_patent_details (multiple patents × sections) or findip_get_patent_section.
fetch
ChatGPTDeep Research compatible fetch — single string parameter. Returns {id, title, text, url, metadata} for the publication. Body uses the smart section (title + biblio + abstract + claim 1) to keep token cost low for multi-document Deep Research workflows. Not for normal conversations — there, use findip_get_patent_details (multiple patents × sections) or findip_get_patent_section.
fetch
ChatGPTDeep Research compatible fetch — single string parameter. Returns {id, title, text, url, metadata} for the publication. Body uses the smart section (title + biblio + abstract + claim 1) to keep token cost low for multi-document Deep Research workflows. Not for normal conversations — there, use findip_get_patent_details (multiple patents × sections) or findip_get_patent_section.
findip_analyze_trends
ChatGPT특허 통계 집계 — 두 모드. CENSUS(정확 전수, query 생략) / TREND(시맨틱 추정, query 제공). Mode is decided by `query`: • CENSUS — OMIT `query`. Exact, exhaustive publication count of a metadata slice (applicant / IPC / inventor / date / country). No embedding, no min_score, no relevance ranking — every matching publication is counted. Use this whenever the user wants a number that must be complete and correct: "how many", "몇 건", "2026 공개/출원 현황", per-year or per-country totals for a company. Needs ≥1 of applicant_entity_ids / ipc_codes / inventor / date range. min_score·query_aux are ignored here. Fast (no GPU). ⚠️ Do NOT run a semantic query and present its estimate as if it were a complete count — for completeness, omit query. • TREND — PROVIDE `query`. Semantic retrieval + grouped counts. Counts are a min_score-tuned estimate of the topically-relevant population, NOT exhaustive. Use for "how is topic X evolving", relevance-ranked landscape, "which year did X take off". The min_score re-tuning guidance below applies to TREND mode ONLY. NOT for — best few patents to read (use findip_search_patents). Applicant — MANDATORY `findip_find_applicant` first (BOTH modes; same as findip_search_patents): resolve the company name → pass applicant_entity_ids=[…] as a list with all near-duplicate variants in ONE call. This applies equally to census ("how many patents does company X have"). Query breadth — read the `top_ipc` rows to judge focus (the results rows tagged row_type:'top_ipc'). Concentrated in one subclass family (e.g. all H01M*) = well-targeted. Scattered across unrelated subclasses with low counts (e.g. B29C + G06Q + G06F mixed) = broad / ambiguous query — the retriever latched onto a common term and drifted off-topic. For a broad query, DON'T just dump noisy results: read the distinct sub-fields from the top results' titles + top_ipc, then ASK the user which sub-field they mean — phrase the choices in plain technical language (e.g. "injection-molding machinery, or molding process-control software?"), never as IPC/CPC codes (users don't think in classification codes). Map the user's choice back to the matching top_ipc code INTERNALLY and re-run with ipc_codes (chosen FROM top_ipc, never invented from memory). Workflow — call with stats_group_by=['year','country','applicant','ipc'] for overview → identify slice → resolve leading applicant → drill in via findip_search_patents. Returns — {total_matched, score_distribution, page, page_size, total_pages, results[]}. All aggregations are delivered as individual rows inside `results[]` (NOT as a separate stats object), each tagged by row_type so every client surfaces them reliably: {row_type:'by_year', year, count}, {row_type:'by_country', country, count}, {row_type:'top_applicant', name, count}, {row_type:'top_ipc', code, count}. Aggregation rows come FIRST, followed by patent-preview rows (NO row_type; shape = findip_search_patents.results). Which aggregation row_types appear follows stats_group_by. To build a per-year / per-country / top-N table, read the matching row_type rows. CENSUS COMPANION (TREND mode only). When you run a TREND query that ALSO has applicant/IPC/inventor/date filters, the response prepends census_* rows — the EXACT exhaustive count of the same filter (no topic): {row_type:'census_total', count}, {row_type:'census_by_country', country, count}, {row_type:'census_by_year', year, count}, {row_type:'census_top_ipc', code, count}. These are the ground truth. total_matched/by_* are a topical estimate (and biased by query language). For "how many / 현황 / 몇 건", report census_*. NEVER say a country is "not indexed / coverage limit" when census_by_country lists it (e.g. KR may be 0 in the topical by_country but 130 in census_by_country — report 130). Rendering — single number / one-axis small buckets: inline. 2+ axes or >~10 buckets/axis: a recharts chart artifact/canvas (Claude=artifact, ChatGPT=canvas); markdown table elsewhere. Patent-preview…
findip_analyze_trends
ChatGPT특허 통계 집계 — 두 모드. CENSUS(정확 전수, query 생략) / TREND(시맨틱 추정, query 제공). Mode is decided by `query`: • CENSUS — OMIT `query`. Exact, exhaustive publication count of a metadata slice (applicant / IPC / inventor / date / country). No embedding, no min_score, no relevance ranking — every matching publication is counted. Use this whenever the user wants a number that must be complete and correct: "how many", "몇 건", "2026 공개/출원 현황", per-year or per-country totals for a company. Needs ≥1 of applicant_entity_ids / ipc_codes / inventor / date range. min_score·query_aux are ignored here. Fast (no GPU). ⚠️ Do NOT run a semantic query and present its estimate as if it were a complete count — for completeness, omit query. • TREND — PROVIDE `query`. Semantic retrieval + grouped counts. Counts are a min_score-tuned estimate of the topically-relevant population, NOT exhaustive. Use for "how is topic X evolving", relevance-ranked landscape, "which year did X take off". The min_score re-tuning guidance below applies to TREND mode ONLY. NOT for — best few patents to read (use findip_search_patents). Applicant — MANDATORY `findip_find_applicant` first (BOTH modes; same as findip_search_patents): resolve the company name → pass applicant_entity_ids=[…] as a list with all near-duplicate variants in ONE call. This applies equally to census ("how many patents does company X have"). Query breadth — read the `top_ipc` rows to judge focus (the results rows tagged row_type:'top_ipc'). Concentrated in one subclass family (e.g. all H01M*) = well-targeted. Scattered across unrelated subclasses with low counts (e.g. B29C + G06Q + G06F mixed) = broad / ambiguous query — the retriever latched onto a common term and drifted off-topic. For a broad query, DON'T just dump noisy results: read the distinct sub-fields from the top results' titles + top_ipc, then ASK the user which sub-field they mean — phrase the choices in plain technical language (e.g. "injection-molding machinery, or molding process-control software?"), never as IPC/CPC codes (users don't think in classification codes). Map the user's choice back to the matching top_ipc code INTERNALLY and re-run with ipc_codes (chosen FROM top_ipc, never invented from memory). Workflow — call with stats_group_by=['year','country','applicant','ipc'] for overview → identify slice → resolve leading applicant → drill in via findip_search_patents. Returns — {total_matched, score_distribution, page, page_size, total_pages, results[]}. All aggregations are delivered as individual rows inside `results[]` (NOT as a separate stats object), each tagged by row_type so every client surfaces them reliably: {row_type:'by_year', year, count}, {row_type:'by_country', country, count}, {row_type:'top_applicant', name, count}, {row_type:'top_ipc', code, count}. Aggregation rows come FIRST, followed by patent-preview rows (NO row_type; shape = findip_search_patents.results). Which aggregation row_types appear follows stats_group_by. To build a per-year / per-country / top-N table, read the matching row_type rows. CENSUS COMPANION (TREND mode only). When you run a TREND query that ALSO has applicant/IPC/inventor/date filters, the response prepends census_* rows — the EXACT exhaustive count of the same filter (no topic): {row_type:'census_total', count}, {row_type:'census_by_country', country, count}, {row_type:'census_by_year', year, count}, {row_type:'census_top_ipc', code, count}. These are the ground truth. total_matched/by_* are a topical estimate (and biased by query language). For "how many / 현황 / 몇 건", report census_*. NEVER say a country is "not indexed / coverage limit" when census_by_country lists it (e.g. KR may be 0 in the topical by_country but 130 in census_by_country — report 130). Rendering — single number / one-axis small buckets: inline. 2+ axes or >~10 buckets/axis: a recharts chart artifact/canvas (Claude=artifact, ChatGPT=canvas); markdown table elsewhere. Patent-preview…
findip_analyze_trends
ChatGPT특허 통계 집계 — 두 모드. CENSUS(정확 전수, query 생략) / TREND(시맨틱 추정, query 제공). Mode is decided by `query`: • CENSUS — OMIT `query`. Exact, exhaustive publication count of a metadata slice (applicant / IPC / inventor / date / country). No embedding, no min_score, no relevance ranking — every matching publication is counted. Use this whenever the user wants a number that must be complete and correct: "how many", "몇 건", "2026 공개/출원 현황", per-year or per-country totals for a company. Needs ≥1 of applicant_entity_ids / ipc_codes / inventor / date range. min_score·query_aux are ignored here. Fast (no GPU). ⚠️ Do NOT run a semantic query and present its estimate as if it were a complete count — for completeness, omit query. • TREND — PROVIDE `query`. Semantic retrieval + grouped counts. Counts are a min_score-tuned estimate of the topically-relevant population, NOT exhaustive. Use for "how is topic X evolving", relevance-ranked landscape, "which year did X take off". The min_score re-tuning guidance below applies to TREND mode ONLY. NOT for — best few patents to read (use findip_search_patents). Applicant — MANDATORY `findip_find_applicant` first (BOTH modes; same as findip_search_patents): resolve the company name → pass applicant_entity_ids=[…] as a list with all near-duplicate variants in ONE call. This applies equally to census ("how many patents does company X have"). Query breadth — read the `top_ipc` rows to judge focus (the results rows tagged row_type:'top_ipc'). Concentrated in one subclass family (e.g. all H01M*) = well-targeted. Scattered across unrelated subclasses with low counts (e.g. B29C + G06Q + G06F mixed) = broad / ambiguous query — the retriever latched onto a common term and drifted off-topic. For a broad query, DON'T just dump noisy results: read the distinct sub-fields from the top results' titles + top_ipc, then ASK the user which sub-field they mean — phrase the choices in plain technical language (e.g. "injection-molding machinery, or molding process-control software?"), never as IPC/CPC codes (users don't think in classification codes). Map the user's choice back to the matching top_ipc code INTERNALLY and re-run with ipc_codes (chosen FROM top_ipc, never invented from memory). Workflow — call with stats_group_by=['year','country','applicant','ipc'] for overview → identify slice → resolve leading applicant → drill in via findip_search_patents. Returns — {total_matched, score_distribution, page, page_size, total_pages, results[]}. All aggregations are delivered as individual rows inside `results[]` (NOT as a separate stats object), each tagged by row_type so every client surfaces them reliably: {row_type:'by_year', year, count}, {row_type:'by_country', country, count}, {row_type:'top_applicant', name, count}, {row_type:'top_ipc', code, count}. Aggregation rows come FIRST, followed by patent-preview rows (NO row_type; shape = findip_search_patents.results). Which aggregation row_types appear follows stats_group_by. To build a per-year / per-country / top-N table, read the matching row_type rows. CENSUS COMPANION (TREND mode only). When you run a TREND query that ALSO has applicant/IPC/inventor/date filters, the response prepends census_* rows — the EXACT exhaustive count of the same filter (no topic): {row_type:'census_total', count}, {row_type:'census_by_country', country, count}, {row_type:'census_by_year', year, count}, {row_type:'census_top_ipc', code, count}. These are the ground truth. total_matched/by_* are a topical estimate (and biased by query language). For "how many / 현황 / 몇 건", report census_*. NEVER say a country is "not indexed / coverage limit" when census_by_country lists it (e.g. KR may be 0 in the topical by_country but 130 in census_by_country — report 130). Rendering — single number / one-axis small buckets: inline. 2+ axes or >~10 buckets/axis: a recharts chart artifact/canvas (Claude=artifact, ChatGPT=canvas); markdown table elsewhere. Patent-preview…
findip_find_applicant
ChatGPT출원인 입력을 대표명(entity_id) 후보로 해석 — 5개국 통합 검색 전 단계 (MANDATORY). Purpose — Resolve a free-form applicant string (any of 5 languages) into canonical entity_id values for cross-country deduplicated retrieval. A single corporation has many surface forms (삼성전자주식회사, Samsung Electronics Co., Ltd., 三星电子株式会社, …); the raw applicant filter only matches one variant. This tool maps them to one harmonized name. Use whenever the user names a company in findip_search_patents / findip_analyze_trends. Returns — {candidates[]: {entity_id, pub_count, share}, top1_dominance, recommendation: 'auto'|'ask', total_pubs}. Decision - 'auto' → use candidates[0].entity_id. - 'ask' → use context (Samsung's display patents → SAMSUNG DISPLAY); group near-duplicates (삼성전자주식회사 + 삼성전자 주식회사) into one list silently; ask user only when truly distinct entities (Electronics vs SDI vs Display). - empty candidates[] → not indexed; tell the user (no fallback). Always pass entity_ids as a LIST in ONE call to findip_search_patents / findip_analyze_trends. Do NOT call multiple times for the same company. Known limit — single-space variants are split into separate entries; treat them as one entity. Examples - findip_find_applicant(q='華為') → HUAWEI TECH CO LTD - findip_find_applicant(q='Samsung', top_n=10) → ELECTRONICS, SDI, DISPLAY, ELECTRO-MECH, … (ask)
findip_find_applicant
ChatGPT출원인 입력을 대표명(entity_id) 후보로 해석 — 5개국 통합 검색 전 단계 (MANDATORY). Purpose — Resolve a free-form applicant string (any of 5 languages) into canonical entity_id values for cross-country deduplicated retrieval. A single corporation has many surface forms (삼성전자주식회사, Samsung Electronics Co., Ltd., 三星电子株式会社, …); the raw applicant filter only matches one variant. This tool maps them to one harmonized name. Use whenever the user names a company in findip_search_patents / findip_analyze_trends. Returns — {candidates[]: {entity_id, pub_count, share}, top1_dominance, recommendation: 'auto'|'ask', total_pubs}. Decision - 'auto' → use candidates[0].entity_id. - 'ask' → use context (Samsung's display patents → SAMSUNG DISPLAY); group near-duplicates (삼성전자주식회사 + 삼성전자 주식회사) into one list silently; ask user only when truly distinct entities (Electronics vs SDI vs Display). - empty candidates[] → not indexed; tell the user (no fallback). Always pass entity_ids as a LIST in ONE call to findip_search_patents / findip_analyze_trends. Do NOT call multiple times for the same company. Known limit — single-space variants are split into separate entries; treat them as one entity. Examples - findip_find_applicant(q='華為') → HUAWEI TECH CO LTD - findip_find_applicant(q='Samsung', top_n=10) → ELECTRONICS, SDI, DISPLAY, ELECTRO-MECH, … (ask)
findip_find_applicant
ChatGPT출원인 입력을 대표명(entity_id) 후보로 해석 — 5개국 통합 검색 전 단계 (MANDATORY). Purpose — Resolve a free-form applicant string (any of 5 languages) into canonical entity_id values for cross-country deduplicated retrieval. A single corporation has many surface forms (삼성전자주식회사, Samsung Electronics Co., Ltd., 三星电子株式会社, …); the raw applicant filter only matches one variant. This tool maps them to one harmonized name. Use whenever the user names a company in findip_search_patents / findip_analyze_trends. Returns — {candidates[]: {entity_id, pub_count, share}, top1_dominance, recommendation: 'auto'|'ask', total_pubs}. Decision - 'auto' → use candidates[0].entity_id. - 'ask' → use context (Samsung's display patents → SAMSUNG DISPLAY); group near-duplicates (삼성전자주식회사 + 삼성전자 주식회사) into one list silently; ask user only when truly distinct entities (Electronics vs SDI vs Display). - empty candidates[] → not indexed; tell the user (no fallback). Always pass entity_ids as a LIST in ONE call to findip_search_patents / findip_analyze_trends. Do NOT call multiple times for the same company. Known limit — single-space variants are split into separate entries; treat them as one entity. Examples - findip_find_applicant(q='華為') → HUAWEI TECH CO LTD - findip_find_applicant(q='Samsung', top_n=10) → ELECTRONICS, SDI, DISPLAY, ELECTRO-MECH, … (ask)
findip_get_coverage
ChatGPT데이터 커버리지 조회 — 5개국 색인 문서 수와 날짜 범위. Purpose — Avoid false negatives from out-of-range filters. Call before tightening filing_date_from / publication_date_from, or when the user asks about a specific year/country boundary. NOT for — repeated calls in one conversation; cache (stable per hour). Returns — {<country>: {count, from, to}} for KR/US/CN/JP/EP.
findip_get_coverage
ChatGPT데이터 커버리지 조회 — 5개국 색인 문서 수와 날짜 범위. Purpose — Avoid false negatives from out-of-range filters. Call before tightening filing_date_from / publication_date_from, or when the user asks about a specific year/country boundary. NOT for — repeated calls in one conversation; cache (stable per hour). Returns — {<country>: {count, from, to}} for KR/US/CN/JP/EP.
findip_get_coverage
ChatGPT데이터 커버리지 조회 — 5개국 색인 문서 수와 날짜 범위. Purpose — Avoid false negatives from out-of-range filters. Call before tightening filing_date_from / publication_date_from, or when the user asks about a specific year/country boundary. NOT for — repeated calls in one conversation; cache (stable per hour). Returns — {<country>: {count, from, to}} for KR/US/CN/JP/EP.
findip_get_patent_details
ChatGPT특허 상세 본문 조회 — 공개/등록번호(또는 출원번호) 기준 본문 마크다운 반환. Purpose — Deterministic body fetch by patent number, no ranking. Use after the user names a specific patent or as a follow-up to findip_search_patents / findip_analyze_trends. Number kind — patent_ids defaults to publication / registration numbers. If the user gives a Korean application number (출원번호, e.g. '10-2012-0151138'), you MUST set id_type='application' — application and publication numbers look identical and cannot be told apart by shape, so the kind must be stated. It resolves to the granted patent if one exists, else the publication. NOT for — topic-only search (use findip_search_patents). For a single section of one patent, findip_get_patent_section is more token-efficient. Sections kwarg — comma-separated subset of title,abstract,claims,description. Omit for full body. Restrict + batch 20–50 at a time to control response size. Returns — {patents[]} where each entry is {patent_id, metadata, content (markdown), representative_figure?} or {patent_id, error:'not_found'}. Rendering — For a FULL single-patent detail view ("자세히/상세히 보여줘"), do NOT fetch the body here — instead give the public detail page link https://findip.ai/p/{publication_id} inline (server rule 5). Use this tool only for a specific section or a multi-patent comparison: single short section (title/abstract) → inline; multi-patent comparison or body >~6 lines → HTML artifact/canvas (Claude=artifact, ChatGPT=canvas) per the global rendering policy (typography-led — no cards/boxes); inline elsewhere. Drawings: call findip_get_patent_drawing(pub, filename) separately so the client renders the figure natively (no token blow-up).
findip_get_patent_details
ChatGPT특허 상세 본문 조회 — 공개/등록번호(또는 출원번호) 기준 본문 마크다운 반환. Purpose — Deterministic body fetch by patent number, no ranking. Use after the user names a specific patent or as a follow-up to findip_search_patents / findip_analyze_trends. Number kind — patent_ids defaults to publication / registration numbers. If the user gives a Korean application number (출원번호, e.g. '10-2012-0151138'), you MUST set id_type='application' — application and publication numbers look identical and cannot be told apart by shape, so the kind must be stated. It resolves to the granted patent if one exists, else the publication. NOT for — topic-only search (use findip_search_patents). For a single section of one patent, findip_get_patent_section is more token-efficient. Sections kwarg — comma-separated subset of title,abstract,claims,description. Omit for full body. Restrict + batch 20–50 at a time to control response size. Returns — {patents[]} where each entry is {patent_id, metadata, content (markdown), representative_figure?} or {patent_id, error:'not_found'}. Rendering — For a FULL single-patent detail view ("자세히/상세히 보여줘"), do NOT fetch the body here — instead give the public detail page link https://findip.ai/p/{publication_id} inline (server rule 5). Use this tool only for a specific section or a multi-patent comparison: single short section (title/abstract) → inline; multi-patent comparison or body >~6 lines → HTML artifact/canvas (Claude=artifact, ChatGPT=canvas) per the global rendering policy (typography-led — no cards/boxes); inline elsewhere. Drawings: call findip_get_patent_drawing(pub, filename) separately so the client renders the figure natively (no token blow-up).
findip_get_patent_details
ChatGPT특허 상세 본문 조회 — 공개/등록번호(또는 출원번호) 기준 본문 마크다운 반환. Purpose — Deterministic body fetch by patent number, no ranking. Use after the user names a specific patent or as a follow-up to findip_search_patents / findip_analyze_trends. Number kind — patent_ids defaults to publication / registration numbers. If the user gives a Korean application number (출원번호, e.g. '10-2012-0151138'), you MUST set id_type='application' — application and publication numbers look identical and cannot be told apart by shape, so the kind must be stated. It resolves to the granted patent if one exists, else the publication. NOT for — topic-only search (use findip_search_patents). For a single section of one patent, findip_get_patent_section is more token-efficient. Sections kwarg — comma-separated subset of title,abstract,claims,description. Omit for full body. Restrict + batch 20–50 at a time to control response size. Returns — {patents[]} where each entry is {patent_id, metadata, content (markdown), representative_figure?} or {patent_id, error:'not_found'}. Rendering — For a FULL single-patent detail view ("자세히/상세히 보여줘"), do NOT fetch the body here — instead give the public detail page link https://findip.ai/p/{publication_id} inline (server rule 5). Use this tool only for a specific section or a multi-patent comparison: single short section (title/abstract) → inline; multi-patent comparison or body >~6 lines → HTML artifact/canvas (Claude=artifact, ChatGPT=canvas) per the global rendering policy (typography-led — no cards/boxes); inline elsewhere. Drawings: call findip_get_patent_drawing(pub, filename) separately so the client renders the figure natively (no token blow-up).
findip_get_patent_drawing
ChatGPT특허 도면 이미지 — 유일한 이미지 fetch 도구. Filename source: representative_figure (search/details) or findip_get_patent_section(pub,'drawings'). Never invent filenames. One figure inline → default format='base64' → ImageContent (image bytes skip your text tokens). A gallery (multiple figures / search results) → base64-embed into an HTML artifact/canvas (Claude=artifact, ChatGPT=canvas) WITH CODE. External image URLs are blocked in chat replies / artifact sandboxes, so do NOT put the URL in the HTML first and do NOT test whether it loads — go straight to: format='url' → download bytes to disk → encode → write the base64 into the file via script. NEVER paste base64 into your reply / artifact body / write-arg (output-token blowup), and never re-read the finished HTML whole. Pass a caption and restate it in your reply text (figures may render outside the main reply).
findip_get_patent_drawing
ChatGPT특허 도면 이미지 — 유일한 이미지 fetch 도구. Filename source: representative_figure (search/details) or findip_get_patent_section(pub,'drawings'). Never invent filenames. One figure inline → default format='base64' → ImageContent (image bytes skip your text tokens). A gallery (multiple figures / search results) → base64-embed into an HTML artifact/canvas (Claude=artifact, ChatGPT=canvas) WITH CODE. External image URLs are blocked in chat replies / artifact sandboxes, so do NOT put the URL in the HTML first and do NOT test whether it loads — go straight to: format='url' → download bytes to disk → encode → write the base64 into the file via script. NEVER paste base64 into your reply / artifact body / write-arg (output-token blowup), and never re-read the finished HTML whole. Pass a caption and restate it in your reply text (figures may render outside the main reply).
findip_get_patent_drawing
ChatGPT특허 도면 이미지 — 유일한 이미지 fetch 도구. Filename source: representative_figure (search/details) or findip_get_patent_section(pub,'drawings'). Never invent filenames. One figure inline → default format='base64' → ImageContent (image bytes skip your text tokens). A gallery (multiple figures / search results) → base64-embed into an HTML artifact/canvas (Claude=artifact, ChatGPT=canvas) WITH CODE. External image URLs are blocked in chat replies / artifact sandboxes, so do NOT put the URL in the HTML first and do NOT test whether it loads — go straight to: format='url' → download bytes to disk → encode → write the base64 into the file via script. NEVER paste base64 into your reply / artifact body / write-arg (output-token blowup), and never re-read the finished HTML whole. Pass a caption and restate it in your reply text (figures may render outside the main reply).
findip_get_patent_section
ChatGPT특허 본문의 한 섹션 정밀 조회 — findip_get_patent_details 보다 토큰 효율적. Purpose — Fetch one section of one patent. Avoids full-body cost when only claim 1 or description/15-20 is needed. Sections — title · abstract · biblio · smart (~500–1500 tokens: title+biblio+abstract+claim 1) · full · claims · description · background · drawings. `nums` selectors for claims / description: 1 | 1,3,5 | 1-5 | 1-3,5,7-9. KR [1] and US/JP [0001] both match the integer. nums is ignored for drawings. Matched paragraphs — pass section='description' + nums from search response's resources.description_matched URI to read only the hit passages. Returns — markdown str. For drawings returns a list of {filename, caption} entries; call `findip_get_patent_drawing(pub, filename, caption)` to fetch a specific image (image is not embedded here to avoid response bloat for patents with many figures). Examples - findip_get_patent_section('KR1020230012345A', 'smart') - findip_get_patent_section('KR…', 'claims', '1,3,5') - findip_get_patent_section('KR…', 'description', '15-20') - findip_get_patent_section('KR…', 'drawings') — list only; then findip_get_patent_drawing(pub, filename, caption) for the image
findip_get_patent_section
ChatGPT특허 본문의 한 섹션 정밀 조회 — findip_get_patent_details 보다 토큰 효율적. Purpose — Fetch one section of one patent. Avoids full-body cost when only claim 1 or description/15-20 is needed. Sections — title · abstract · biblio · smart (~500–1500 tokens: title+biblio+abstract+claim 1) · full · claims · description · background · drawings. `nums` selectors for claims / description: 1 | 1,3,5 | 1-5 | 1-3,5,7-9. KR [1] and US/JP [0001] both match the integer. nums is ignored for drawings. Matched paragraphs — pass section='description' + nums from search response's resources.description_matched URI to read only the hit passages. Returns — markdown str. For drawings returns a list of {filename, caption} entries; call `findip_get_patent_drawing(pub, filename, caption)` to fetch a specific image (image is not embedded here to avoid response bloat for patents with many figures). Examples - findip_get_patent_section('KR1020230012345A', 'smart') - findip_get_patent_section('KR…', 'claims', '1,3,5') - findip_get_patent_section('KR…', 'description', '15-20') - findip_get_patent_section('KR…', 'drawings') — list only; then findip_get_patent_drawing(pub, filename, caption) for the image
findip_get_patent_section
ChatGPT특허 본문의 한 섹션 정밀 조회 — findip_get_patent_details 보다 토큰 효율적. Purpose — Fetch one section of one patent. Avoids full-body cost when only claim 1 or description/15-20 is needed. Sections — title · abstract · biblio · smart (~500–1500 tokens: title+biblio+abstract+claim 1) · full · claims · description · background · drawings. `nums` selectors for claims / description: 1 | 1,3,5 | 1-5 | 1-3,5,7-9. KR [1] and US/JP [0001] both match the integer. nums is ignored for drawings. Matched paragraphs — pass section='description' + nums from search response's resources.description_matched URI to read only the hit passages. Returns — markdown str. For drawings returns a list of {filename, caption} entries; call `findip_get_patent_drawing(pub, filename, caption)` to fetch a specific image (image is not embedded here to avoid response bloat for patents with many figures). Examples - findip_get_patent_section('KR1020230012345A', 'smart') - findip_get_patent_section('KR…', 'claims', '1,3,5') - findip_get_patent_section('KR…', 'description', '15-20') - findip_get_patent_section('KR…', 'drawings') — list only; then findip_get_patent_drawing(pub, filename, caption) for the image
findip_search_patents
ChatGPT특허 시맨틱 검색 — 자연어 쿼리로 5개국(KR·US·CN·JP·EP) 관련 특허를 의미 기반 검색. Purpose — Multilingual embedding (Qwen3-0.6B) + BGE-v2-m3 reranker. Describe the technical concept in one sentence; keyword bags work poorly. Query language independent of result language. Use when — exploratory topic search, competitive landscaping, prior-art style retrieval. NOT for — known publication ID (use findip_get_patent_details), pure counts/trends (use findip_analyze_trends), image bytes (use findip_get_patent_drawing). Multi-country — pass all jurisdictions in ONE call (countries=["KR","US"]); per-country rank-percentile balancing kicks in. Splitting calls degrades quality. Applicant — MANDATORY `findip_find_applicant` first. If the user names a company (any language), call findip_find_applicant(q=name) → pass applicant_entity_ids=[…] (list, ONE call, include near-duplicates like 'SAMSUNG ELECTRONICS CO LTD' + '삼성전자주식회사' + '삼성전자 주식회사'). Empty candidates → not indexed (no fallback). Returns — {total, results[]} where each result has patent_id, title, country, kind_code, legal_status (GRANTED|PUBLISHED — dynamic post-grant status NOT reflected), applicants[], applicants_harmonized[], inventors[], inventors_harmonized[], application_number, family_id, filing_date, publication_date, grant_date, priority_date, ipc_codes[], similarity_score (loose), rerank_score (sort-only, never threshold), representative_figure (filename or null), chunks[] (matched passages ordered by rerank_score). Broad / multi-concept queries drift off-topic. A query mixing two concepts ("wireless-charging + IR temperature sensor") often latches onto the more common one and drops the other; a short broad term ("injection molding") scatters across unrelated fields. If results look off-topic or the ipc_codes across results are scattered/unrelated, narrow with the ipc_codes parameter — pick codes from what the results actually show (or call findip_analyze_trends for its top_ipc rows), NOT from memory. For a genuinely broad query, ask the user which sub-field they mean in plain technical language (not IPC codes), then re-search. Rendering — representative figures are shown by DEFAULT. When the client renders an HTML artifact/canvas (Claude=artifact, ChatGPT=canvas), build a gallery/table with each hit's figure base64-embedded; otherwise an inline markdown table (columns: patent_id · title · country · applicants_harmonized · filing_date · kind_code · legal_status · rerank_score) and still list every hit. Always prepend a 1–3 sentence plain-text summary. Link each `patent_id`/title to its public detail page https://findip.ai/p/{publication_id} (server rule 3); in HTML add target="_blank" rel="noopener" so it opens in a separate tab. Never link to third-party sites. For inline content use findip_get_patent_section / findip_get_patent_details. Drawings — always include each hit's representative_figure. Build the figures into the HTML result base64-embedded via code (see findip_get_patent_drawing). Never paste base64 yourself; let code write it to the file. Related — findip_find_applicant (before company filter), findip_get_patent_section / findip_get_patent_details (drill in), findip_analyze_trends (aggregates), findip_get_coverage (date sanity).
findip_search_patents
ChatGPT특허 시맨틱 검색 — 자연어 쿼리로 5개국(KR·US·CN·JP·EP) 관련 특허를 의미 기반 검색. Purpose — Multilingual embedding (Qwen3-0.6B) + BGE-v2-m3 reranker. Describe the technical concept in one sentence; keyword bags work poorly. Query language independent of result language. Use when — exploratory topic search, competitive landscaping, prior-art style retrieval. NOT for — known publication ID (use findip_get_patent_details), pure counts/trends (use findip_analyze_trends), image bytes (use findip_get_patent_drawing). Multi-country — pass all jurisdictions in ONE call (countries=["KR","US"]); per-country rank-percentile balancing kicks in. Splitting calls degrades quality. Applicant — MANDATORY `findip_find_applicant` first. If the user names a company (any language), call findip_find_applicant(q=name) → pass applicant_entity_ids=[…] (list, ONE call, include near-duplicates like 'SAMSUNG ELECTRONICS CO LTD' + '삼성전자주식회사' + '삼성전자 주식회사'). Empty candidates → not indexed (no fallback). Returns — {total, results[]} where each result has patent_id, title, country, kind_code, legal_status (GRANTED|PUBLISHED — dynamic post-grant status NOT reflected), applicants[], applicants_harmonized[], inventors[], inventors_harmonized[], application_number, family_id, filing_date, publication_date, grant_date, priority_date, ipc_codes[], similarity_score (loose), rerank_score (sort-only, never threshold), representative_figure (filename or null), chunks[] (matched passages ordered by rerank_score). Broad / multi-concept queries drift off-topic. A query mixing two concepts ("wireless-charging + IR temperature sensor") often latches onto the more common one and drops the other; a short broad term ("injection molding") scatters across unrelated fields. If results look off-topic or the ipc_codes across results are scattered/unrelated, narrow with the ipc_codes parameter — pick codes from what the results actually show (or call findip_analyze_trends for its top_ipc rows), NOT from memory. For a genuinely broad query, ask the user which sub-field they mean in plain technical language (not IPC codes), then re-search. Rendering — representative figures are shown by DEFAULT. When the client renders an HTML artifact/canvas (Claude=artifact, ChatGPT=canvas), build a gallery/table with each hit's figure base64-embedded; otherwise an inline markdown table (columns: patent_id · title · country · applicants_harmonized · filing_date · kind_code · legal_status · rerank_score) and still list every hit. Always prepend a 1–3 sentence plain-text summary. Link each `patent_id`/title to its public detail page https://findip.ai/p/{publication_id} (server rule 3); in HTML add target="_blank" rel="noopener" so it opens in a separate tab. Never link to third-party sites. For inline content use findip_get_patent_section / findip_get_patent_details. Drawings — always include each hit's representative_figure. Build the figures into the HTML result base64-embedded via code (see findip_get_patent_drawing). Never paste base64 yourself; let code write it to the file. Related — findip_find_applicant (before company filter), findip_get_patent_section / findip_get_patent_details (drill in), findip_analyze_trends (aggregates), findip_get_coverage (date sanity).
findip_search_patents
ChatGPT특허 시맨틱 검색 — 자연어 쿼리로 5개국(KR·US·CN·JP·EP) 관련 특허를 의미 기반 검색. Purpose — Multilingual embedding (Qwen3-0.6B) + BGE-v2-m3 reranker. Describe the technical concept in one sentence; keyword bags work poorly. Query language independent of result language. Use when — exploratory topic search, competitive landscaping, prior-art style retrieval. NOT for — known publication ID (use findip_get_patent_details), pure counts/trends (use findip_analyze_trends), image bytes (use findip_get_patent_drawing). Multi-country — pass all jurisdictions in ONE call (countries=["KR","US"]); per-country rank-percentile balancing kicks in. Splitting calls degrades quality. Applicant — MANDATORY `findip_find_applicant` first. If the user names a company (any language), call findip_find_applicant(q=name) → pass applicant_entity_ids=[…] (list, ONE call, include near-duplicates like 'SAMSUNG ELECTRONICS CO LTD' + '삼성전자주식회사' + '삼성전자 주식회사'). Empty candidates → not indexed (no fallback). Returns — {total, results[]} where each result has patent_id, title, country, kind_code, legal_status (GRANTED|PUBLISHED — dynamic post-grant status NOT reflected), applicants[], applicants_harmonized[], inventors[], inventors_harmonized[], application_number, family_id, filing_date, publication_date, grant_date, priority_date, ipc_codes[], similarity_score (loose), rerank_score (sort-only, never threshold), representative_figure (filename or null), chunks[] (matched passages ordered by rerank_score). Broad / multi-concept queries drift off-topic. A query mixing two concepts ("wireless-charging + IR temperature sensor") often latches onto the more common one and drops the other; a short broad term ("injection molding") scatters across unrelated fields. If results look off-topic or the ipc_codes across results are scattered/unrelated, narrow with the ipc_codes parameter — pick codes from what the results actually show (or call findip_analyze_trends for its top_ipc rows), NOT from memory. For a genuinely broad query, ask the user which sub-field they mean in plain technical language (not IPC codes), then re-search. Rendering — representative figures are shown by DEFAULT. When the client renders an HTML artifact/canvas (Claude=artifact, ChatGPT=canvas), build a gallery/table with each hit's figure base64-embedded; otherwise an inline markdown table (columns: patent_id · title · country · applicants_harmonized · filing_date · kind_code · legal_status · rerank_score) and still list every hit. Always prepend a 1–3 sentence plain-text summary. Link each `patent_id`/title to its public detail page https://findip.ai/p/{publication_id} (server rule 3); in HTML add target="_blank" rel="noopener" so it opens in a separate tab. Never link to third-party sites. For inline content use findip_get_patent_section / findip_get_patent_details. Drawings — always include each hit's representative_figure. Build the figures into the HTML result base64-embedded via code (see findip_get_patent_drawing). Never paste base64 yourself; let code write it to the file. Related — findip_find_applicant (before company filter), findip_get_patent_section / findip_get_patent_details (drill in), findip_analyze_trends (aggregates), findip_get_coverage (date sanity).
findip_search_sequences
ChatGPTFind patents containing a biological sequence similar to the query (homolog search). Purpose — Dense-vector k-NN over patent ST.26 sequence listings (DNA/RNA via Nucleotide Transformer, protein via ESM-2). Finds patents whose sequences are similar/related to the query — not exact BLAST alignment. When to use — The user supplies a nucleotide or amino-acid sequence and wants patents with similar sequences (e.g. "which patents have a sequence like this gene/peptide?"). Nucleic-acid vs protein is auto-detected. When NOT to use — Topic/keyword/problem search (use findip_search_patents). Exact variant-position alignment is out of scope (this is similarity retrieval). Returns — { seq_type, query_length, results[] }. Each result: publication_number, best_similarity (cosine 0–1), seq_count, matched_seqs[] (seq_id, seq_type, similarity, length, organism, sequence), biblio (title_text, applicant, ipc_codes, dates). Related — findip_get_patent_details (drill into a hit), findip_search_patents (topic search), findip_get_patent_section.
findip_search_sequences
ChatGPTFind patents containing a biological sequence similar to the query (homolog search). Purpose — Dense-vector k-NN over patent ST.26 sequence listings (DNA/RNA via Nucleotide Transformer, protein via ESM-2). Finds patents whose sequences are similar/related to the query — not exact BLAST alignment. When to use — The user supplies a nucleotide or amino-acid sequence and wants patents with similar sequences (e.g. "which patents have a sequence like this gene/peptide?"). Nucleic-acid vs protein is auto-detected. When NOT to use — Topic/keyword/problem search (use findip_search_patents). Exact variant-position alignment is out of scope (this is similarity retrieval). Returns — { seq_type, query_length, results[] }. Each result: publication_number, best_similarity (cosine 0–1), seq_count, matched_seqs[] (seq_id, seq_type, similarity, length, organism, sequence), biblio (title_text, applicant, ipc_codes, dates). Related — findip_get_patent_details (drill into a hit), findip_search_patents (topic search), findip_get_patent_section.
findip_search_sequences
ChatGPTFind patents containing a biological sequence similar to the query (homolog search). Purpose — Dense-vector k-NN over patent ST.26 sequence listings (DNA/RNA via Nucleotide Transformer, protein via ESM-2). Finds patents whose sequences are similar/related to the query — not exact BLAST alignment. When to use — The user supplies a nucleotide or amino-acid sequence and wants patents with similar sequences (e.g. "which patents have a sequence like this gene/peptide?"). Nucleic-acid vs protein is auto-detected. When NOT to use — Topic/keyword/problem search (use findip_search_patents). Exact variant-position alignment is out of scope (this is similarity retrieval). Returns — { seq_type, query_length, results[] }. Each result: publication_number, best_similarity (cosine 0–1), seq_count, matched_seqs[] (seq_id, seq_type, similarity, length, organism, sequence), biblio (title_text, applicant, ipc_codes, dates). Related — findip_get_patent_details (drill into a hit), findip_search_patents (topic search), findip_get_patent_section.
search
ChatGPTDeep Research compatible search — single string parameter. Used by ChatGPT Deep Research for multi-hop research. Returns {"results": [{id, title, url}, ...]} shape required by the OpenAI MCP search/fetch standard. Not for normal conversations — there, use findip_search_patents (country/date/IPC/applicant filters, full result fields).
search
ChatGPTDeep Research compatible search — single string parameter. Used by ChatGPT Deep Research for multi-hop research. Returns {"results": [{id, title, url}, ...]} shape required by the OpenAI MCP search/fetch standard. Not for normal conversations — there, use findip_search_patents (country/date/IPC/applicant filters, full result fields).
search
ChatGPTDeep Research compatible search — single string parameter. Used by ChatGPT Deep Research for multi-hop research. Returns {"results": [{id, title, url}, ...]} shape required by the OpenAI MCP search/fetch standard. Not for normal conversations — there, use findip_search_patents (country/date/IPC/applicant filters, full result fields).
