scan-emerging-ai-technologies-rd

Scan Emerging AI and Technology Signals

Purpose

This skill preserves the source package's three complete operating modules:

1. technology landscape analysis;
2. invention and patent mining;
3. current technology-intelligence briefing.

The modules solve different decisions and may be combined only when their scopes, evidence and outputs remain distinguishable.

The source uses semiconductor and tandem-OLED examples.

The localized skill supports those fields and emerging AI, computing, electronics, materials and other engineering domains.

Do not carry the source's OLED quantities, Samsung conclusions, patent numbers, dates, rankings, opportunity labels or forecasts into a new report.

Every factual result must come from the current search, a supplied dataset or a cited authoritative source.

Route the request

Landscape triggers

• technology or patent landscape;
• route evolution;
• competitor technology positioning;
• patent density or portfolio gaps;
• technology-tree or value-chain analysis;
• R&D prioritization based on a defined field.

Do not route a single-invention disclosure, claim drafting request or news digest to the landscape module.

Invention-mining triggers

• mine patentable concepts from an R&D project;
• extend a known technical concept;
• solve a measurable product or process problem;
• examine alternative technical routes around a patent obstacle;
• build structured material for an invention disclosure;
• identify system-integration or cross-domain concepts.

Do not promise patentability, freedom to operate, claim scope, infringement avoidance or grant.

Current-intelligence triggers

• monitor a company, technology or industry;
• summarize recent news, patents, papers, policy, standards and events;
• prepare a weekly, monthly, quarterly or custom-period briefing;
• identify corroborated emerging signals.

Do not route claim drafting, patentability analysis or project decomposition to this module.

Shared intake

Confirm or state assumptions for:

• the decision and audience;
• technology definition and excluded meanings;
• products, functions, mechanisms and applications;
• organizations of interest and known aliases;
• countries, languages and jurisdictions relevant to the decision;
• start/end dates, evidence cutoff and patent date field;
• patent publication/application/family counting unit;
• supplied confidential information and permitted use;
• report depth, output format and deadline.

Do not impose the source's fixed ten-year landscape, five-year patent scan, six-month action plan or six-to-twelve-month briefing window.

Use them only when appropriate and label the selection.

Evidence and MCP plan

User-supplied evidence requires no MCP.

When live research is requested and authorized, use only services actually exposed in the execution environment.

The source names a patent-technology-landscape server and individual trend/ranking/word-cloud/company tools.

Do not claim those tools exist unless their current connector, key and callable schema are verified at execution time.

When unavailable, derive supported analyses from complete or explicitly sampled search results and disclose the method.

Use official patent registers for material legal-status or term decisions.

Use primary company, government, regulator, standards-body, conference and scholarly sources for material non-patent facts.

Preserve exact returned global PatSnap record URLs.

Never construct a Zhihuiya or Eureka URL.

Shared evidence contract

Every material statement receives an evidence ID such as [S01].

For each source record:

• title and author/publisher;
• source type;
• publication, filing, priority, effective or event date as applicable;
• access date and evidence cutoff;
• URL, DOI, patent number or official identifier;
• relevant passage or structured fields;
• geography and scope;
• limitations and conflicts;
• source status: retrieved, user-supplied, or not retrieved;
• analyst confidence.

Never place “to be searched” records in a factual result table.

Put open research items in a clearly labeled evidence-gap register.

Patent counting and coverage

Record:

• exact query and translations;
• searched fields;
• filters and date semantics;
• tool/database and run timestamp;
• matched total and returned count;
• pagination and export limits;
• family consolidation rule;
• duplicate and entity-normalization method;
• incomplete jurisdictions/languages;
• whether charts use a complete corpus or a sample.

Use matched_total only as the provider-reported total for that exact query.

Do not add totals from overlapping queries.

Do not treat returned_count as the universe.

Do not estimate unseen distributions from a small top-ranked result set.

Module 1 — Technology landscape

Definition

Build a decision-ready view of a defined technology field for R&D, IP and strategy teams.

The technology tree is the coordinate system.

Time is a separate analytical axis.

The value chain and system interfaces provide context.

Competitor matrices compare evidence-defined capabilities.

White space is a hypothesis requiring evidence and feasibility review.

Landscape Stage 1 — Boundary and technology tree

Define:

• root technology and alternatives;
• first-level physical, functional, architectural or lifecycle branches;
• second-level technical routes;
• interfaces, dependencies and excluded adjacent fields;
• terminology in relevant languages;
• each node's search concepts, classifications and validation records.

Use three to six first-level branches only when the technology supports that structure.

Do not force the source's OLED tree onto another domain.

For emerging AI, possible first-level branches may include model architecture, data, training/optimization, inference/serving, hardware/system integration, evaluation/safety and applications.

These are candidates, not a fixed taxonomy.

Landscape Stage 2 — Search design

Use complementary routes:

1. semantic/function/problem search;
2. keywords, synonyms and technical phrases;
3. classifications with plain-English meanings;
4. applicant/assignee searches;
5. citation/family/related-record exploration;
6. scientific and standards evidence.

Validate queries against known relevant and irrelevant records.

Classifications may appear in the methods/search appendix.

Use engineering language in executive sections.

Landscape Stage 3 — Global situation scan

Analyze only where data support it:

• application and priority trends;
• publication lag and partial years;
• normalized applicants/owners;
• jurisdictions or priority origins;
• family reach;
• legal-status context;
• technical-node distribution;
• citation indicators with observation date;
• value indicators with their provider definition;
• emerging terminology and route transitions.

Do not equate patent volume, citation count or provider value score with technical leadership.

Landscape Stage 4 — Route evolution

Identify milestones through:

• priority chronology;
• claim/description relevance;
• independently documented technical milestones;
• parameter or architecture discontinuities;
• scientific-to-patent-to-product translation evidence;
• changes in applicant mix and filing behavior.

Do not label a record foundational solely because it is highly cited.

Do not invent phases around convenient dates.

Each phase needs start/end rationale, supporting records, counterevidence and uncertainty.

Landscape Stage 5 — Actor segmentation

Build the actor universe from evidence.

Possible groups:

• established product/platform companies;
• specialist technology suppliers;
• emerging companies;
• universities and public research institutions;
• standards or consortia participants;
• upstream/downstream partners.

Do not use arbitrary Top 5/Top 10 cutoffs as the only selection rule.

Normalize subsidiaries, acquisitions, former names, transliterations and joint applicants.

Landscape Stage 6 — Competitor matrix

Compare actors by disclosed dimensions such as:

• relevant family depth;
• claim/function coverage;
• route breadth and concentration;
• recent momentum with publication-lag caveat;
• geographic reach;
• evidence-backed product/deployment signals;
• standards participation;
• research-to-product translation;
• complementary assets and dependencies.

Every score needs a rubric, evidence IDs, date and “not assessed” option.

Missing data is not a zero score.

Landscape Stage 7 — Opportunity hypotheses

Retain the source's five opportunity types:

1. low-density technical space;
2. weak competitor coverage aligned with user capability;
3. route-transition window;
4. extension into a new application;
5. upstream or downstream extension.

For every opportunity include:

• exact technical problem and route;
• evidence of low/fragmented coverage;
• known blocking records and counterevidence;
• user capability fit;
• technical feasibility and maturity;
• validation experiment;
• business relevance;
• IP question, not a legal conclusion;
• confidence and monitoring signal.

Low patent density alone is not opportunity.

It may indicate low value, poor feasibility, terminology mismatch or search failure.

Landscape report structure

1. scope, definitions, cutoff and decision;
2. executive findings and confidence;
3. methods, queries, counting and coverage;
4. technology tree;
5. overall patent/research situation;
6. route evolution and milestones;
7. representative evidence records;
8. actor and competitor matrix;
9. opportunity hypotheses and counterevidence;
10. implications, validation plan, limitations and source register.

Module 2 — Invention mining

Definition

Structure technical ideas for engineering and patent-professional review.

The workflow finds testable invention concepts; it does not draft claims or determine patentability, infringement or FTO.

Mining scenario routing

Initial mining response

State:

• focal organization or project perspective;
• selected mining situation;
• likely technical/communication/evidence bottleneck;
• applicable method;
• one or two essential missing inputs;
• what can proceed provisionally.

Do not require a patent number or DOI as a prerequisite.

Accept natural-language descriptions and retrieve public evidence when requested.

Do not impose a per-block confirmation pause unless the user asks for checkpoints or a decision is genuinely required.

Four blocks and ten steps

Block 1 — Decompose the technology

Step 1: Evidence scan

Search the defined field, relevant actors, known approaches and neighboring mechanisms.

Record dense and sparse regions only within the documented corpus.

Step 2: Technical decomposition

Decompose by relevant dimensions:

• components and interfaces;
• functions and control logic;
• materials and physical mechanisms;
• manufacturing and assembly;
• measurement, calibration and testing;
• operating states and failure modes;
• applications and lifecycle stages.

Each candidate unit states current state, proposed change, mechanism, expected effect and dependencies.

Checkpoint 1

• search elements and coverage recorded;
• relevant actors and approaches identified;
• dense/sparse statements evidence-bounded;
• technical tree uses engineering terms;
• at least one meaningful problem or gap identified;
• missing evidence visible.

Do not force three problems when evidence supports fewer.

Block 2 — Form invention concepts

Step 3: Define problems

Prioritize measurable problems, constraints, contradictions, failure modes and unmet functions.

Use P0/P1/P2 only with a defined decision rubric.

Step 4: Generate solution hypotheses

Use first principles, TRIZ, morphology, functional effects, analogies, architecture alternatives and experiments as appropriate.

Each concept includes:

• problem and baseline;
• changed feature or relationship;
• mechanism;
• expected technical effect and metric;
• boundary conditions;
• variants and alternatives;
• feasibility risks;
• discriminating validation.

Checkpoint 2

• prioritized problems link to tree nodes;
• each priority problem has at least one technical hypothesis or an explicit no-concept result;
• effects are measurable where possible;
• assumptions and validation are visible.

Block 3 — Evaluate concepts

Step 5: Establish relevant prior art

Search features in combination and separately.

Retrieve claim and description context for material records.

Step 6: Patentability questions

Prepare evidence for qualified counsel on novelty, inventive step/non-obviousness, enablement/support and utility/industrial applicability as jurisdictionally relevant.

Do not assign “optimistic/average/poor” without a transparent evidence rubric.

Step 7: Claim-coverage or infringement questions when triggered

Map technical elements to relevant claims, jurisdiction, status, ownership and date.

This is issue spotting, not a legal opinion.

Step 8: Technical alternatives when triggered

Explore removal, substitution, recombination, separation, sequencing, control, geometry, materials, process and system-boundary alternatives.

Evaluate technical equivalence, performance, safety, cost and validation.

Do not claim an alternative avoids infringement.

Step 9: Define invention concepts

Rate technical contribution, evidence support, feasibility, differentiation, business relevance and validation readiness separately.

The source mentions “technology/legal/market/VSD three-dimensional assessment”; treat VSD only if defined for the team.

Checkpoint 3

• concept list complete for the selected scope;
• prior-art evidence and search gaps labeled;
• unsupported records excluded from factual tables;
• legal questions routed to qualified professionals;
• validation and counterevidence recorded.

Block 4 — Advance actions

Step 10: Decide next action

Possible routes:

• prepare an invention disclosure;
• perform further experiments;
• refine the concept;
• monitor or incubate;
• consider trade-secret treatment under policy;
• stop or change route.

For each concept record owner, decision date, next evidence, success/failure criterion and dependency.

Use a six-month roadmap only when the project horizon supports it.

Checkpoint 4

• every concept has a disposition or explicit unresolved state;
• owners/timing are realistic and user-approved;
• milestones produce evidence or decisions;
• confidentiality/public-disclosure risks are addressed.

Mining scenario extensions

For R&D projects, examine structure, function, application, test and production.

For known innovations, extend horizontally, upstream and downstream.

For competitor obstacles, examine upstream, downstream, engineering implementation, components and performance mechanisms.

For technical alternatives, examine removal, substitution, combination and decomposition plus other mechanism-specific routes.

These are prompts, not mandatory quotas.

Mining report structure

1. executive decision summary;
2. technical/problem tree;
3. evidence and prior-art situation;
4. focal capability/current position;
5. relevant competitor approaches;
6. invention concepts and alternatives;
7. evidence, patent and validation questions;
8. action roadmap;
9. reference patent/evidence index.

Module 3 — Current technology-intelligence briefing

Definition

Monitor a defined technology or actor set across five dimensions:

1. news and company disclosures;
2. patent activity;
3. scientific literature;
4. regulation, policy and standards;
5. industry events, transactions and collaborations.

Dimension 1 — News

Cover relevant:

• corporate strategy and financial disclosures;
• product and technical announcements;
• capacity and manufacturing changes;
• market and supply-chain developments;
• documented leadership/organization changes when material and lawful.

Prefer original company filings/releases and corroborated reporting.

Dimension 2 — Patents

Cover relevant:

• newly published applications;
• grants and material legal events;
• assignments or licenses with reliable evidence;
• litigation or licensing developments from official/court/credible legal sources;
• changes in applicant route concentration.

Do not call a patent high value solely because it was granted or cited.

Dimension 3 — Scientific literature

Cover relevant:

• peer-reviewed papers;
• conference papers and proceedings;
• preprints, clearly labeled;
• datasets, benchmarks and reproducibility artifacts;
• institution/company translation signals.

DOIs are preferred when available, but absence of a DOI does not invalidate a legitimate conference paper, standard or preprint.

Dimension 4 — Regulation, policy and standards

Use the jurisdictions relevant to the user and technology.

Cover:

• regulations and effective dates;
• export controls and sanctions where relevant;
• investment screening and funding programs;
• standards development and revisions;
• implementation guidance and enforcement signals.

Use official sources and distinguish proposal, adoption, entry into force and enforcement.

Dimension 5 — Industry events

Cover relevant:

• financing, M&A and public-market events;
• capacity construction, commissioning or shutdown;
• partnerships, joint ventures and consortia;
• conferences, exhibitions and demonstrations;
• supply agreements and ecosystem changes.

An exhibition announcement is a visibility signal, not proof of performance or deployment.

Confidence model

Do not use source type alone as confidence.

Assess:

• authority;
• directness;
• independence;
• methodological transparency;
• corroboration;
• recency;
• applicability to the scoped claim.

Suggested labels:

• A — direct authoritative evidence for the claim;
• B — strong evidence with independent corroboration or limited caveats;
• C — single credible but uncorroborated source or indirect evidence;
• D — unverified lead, rumor or material conflict; exclude from factual findings.

An official company claim may still need independent validation for performance.

Priority model

Define priorities relative to the user's decision:

• P0 — time-sensitive signal with potentially material decision impact;
• P1 — material signal requiring planned review;
• P2 — contextual signal worth tracking;
• Not prioritized — insufficient relevance/evidence.

Priority is not confidence.

A high-confidence routine event can be P2; an uncertain potentially material lead can be P0 for verification but not for factual conclusion.

Cross-validation

Corroborate material claims where independent evidence is reasonably available.

Do not require two dimensions mechanically.

Some facts are authoritatively established by one official record.

Conversely, multiple reports copying one anonymous source are not independent corroboration.

Briefing report structure

1. scope, monitoring window, cutoff and key changes;
2. method, coverage and source-quality legend;
3. news/company signals;
4. patent signals;
5. scientific signals;
6. regulatory/policy/standards signals;
7. industry events;
8. integrated timeline and cross-signals;
9. implications, watch items and verification actions;
10. limitations and evidence register.

HTML report system

Use references/reference_ui_template.html as the exact package reference.

It is a neutral English template, not a source of factual content.

Replace all {{...}} placeholders and repeated data-template rows with reviewed data.

Do not leave source-case OLED/Samsung facts, invented patent numbers, fixed chart arrays, estimated values or future events.

Scientific/editorial visual language

• white or very light neutral page;
• dark navy/charcoal text;
• one restrained blue accent plus semantic status colors;
• no gradient hero, decorative floating cards or motion required for comprehension;
• readable typography and generous spacing;
• tables and charts designed for evidence comparison;
• color never the only carrier of meaning;
• keyboard-accessible navigation;
• responsive and print-ready layouts;
• charts include data tables or text alternatives;
• no mandatory third-party CDN.

Required metadata

Every report displays:

• title and module;
• decision/audience;
• scope and exclusions;
• search/evidence dates;
• cutoff date;
• counting unit;
• corpus/sample coverage;
• source IDs;
• limitations;
• reviewer status.

Chart rules

Each chart states:

• measure and unit;
• date field and range;
• population/counting unit;
• complete versus sampled data;
• missing/unknown values;
• source IDs;
• interpretation limits.

Do not show a chart when the data are unavailable.

Use an explicit empty state instead.

Patent links

Use exact returned global PatSnap record links when available.

Otherwise link to an appropriate official public record or show the identifier without a fabricated URL.

Material legal decisions require official-register verification.

Quality rules

Data integrity

• never fabricate patent numbers, applicants, classifications, papers, DOIs, policy identifiers, company events or metrics;
• distinguish retrieved, user-supplied, calculated and inferred values;
• never use “pending search” as evidence;
• maintain source IDs and coverage;
• do not estimate unseen corpus distributions from returned samples;
• reconcile totals across charts and tables;
• retain original-language evidence and label translations where material.

Analytical integrity

• do not call a route feasible/infeasible without technical evidence and conditions;
• do not call low density white space without query and coverage validation;
• do not call a competitor weak because data are missing;
• do not infer strategy from one filing;
• do not infer causality from temporal coincidence;
• preserve counterevidence and alternative explanations;
• state confidence and validation action.

IP/legal integrity

• patentability, validity, infringement, FTO, enforceability, term and SEP conclusions require qualified legal analysis;
• compare relevant claims, jurisdictions, dates and status for material questions;
• do not promise that a design avoids a patent;
• do not provide claim language as legal advice;
• protect confidential invention information and avoid premature disclosure.

Communication integrity

• use technical and business language appropriate to the audience;
• classifications may appear in methods when useful and explained;
• do not ban classifications from all report text when they materially support reproducibility;
• define acronyms at first use;
• avoid emojis as status labels in formal reports;
• label provisional findings and empty states plainly;
• do not provide investment recommendations or use nonpublic material.

Source references retained from the original package

The source cites Chinese-language patent analysis, patent mining, invention analysis and patent-practice books, semiconductor device-physics texts, and IEEE/JEDEC material.

Retain them only when the team can verify the exact edition, translation and relevance.

For a global report, supplement with current jurisdiction-appropriate patent-office guidance, WIPO materials, relevant standards and peer-reviewed technical sources.

Do not treat any general handbook as evidence for a specific technical or legal conclusion.

Final quality gate

• Correct module or clearly separated multi-module output.
• Decision, scope, cutoff and audience visible.
• Every material fact has a source ID.
• Search queries, counts, pagination and counting unit recorded.
• Patent family/publication/application counts are not mixed.
• Partial years and publication lag are handled.
• Technology tree is evidence-validated.
• Actor normalization and selection logic are disclosed.
• Route phases and opportunity hypotheses include counterevidence.
• Mining concepts include mechanism, effect, conditions and tests.
• Legal questions are not presented as conclusions.
• Intelligence confidence and priority are separate.
• Rumor is excluded from factual conclusions.
• HTML contains no source-case facts or invented placeholders.
• Charts reconcile with tables and provide accessible alternatives.
• Global PatSnap links are exact and current.
• Report is responsive, printable and review-labeled.

Appendix A — Landscape field contract

Technology-tree node

Each node contains:

• stable node ID;
• parent node ID;
• engineering name;
• definition;
• included concepts;
• excluded concepts;
• synonyms and translations;
• search-query IDs;
• relevant classification seeds with meanings;
• representative evidence IDs;
• corpus count and counting unit;
• complete/sample flag;
• known overlaps;
• confidence;
• reviewer note.

Route record

Each route contains:

• route ID and technology-tree node;
• problem/function addressed;
• mechanism or architecture;
• required inputs/interfaces;
• claimed or measured performance;
• maturity evidence;
• manufacturing/deployment constraints;
• milestone evidence and dates;
• relevant actors;
• patent-family evidence;
• scientific/standards evidence;
• counterevidence;
• unresolved questions;
• confidence and validation action.

Competitor record

Each actor contains:

• normalized name;
• aliases/subsidiaries included;
• corporate event cutoff;
• role in the value chain;
• technology nodes evidenced;
• relevant patent families/publications;
• recent activity with partial-year caveat;
• products/deployments and source type;
• research/standards signals;
• strengths supported by evidence;
• limitations or missing data;
• comparison rubric values;
• evidence IDs and review date.

Opportunity record

Each opportunity contains:

• opportunity ID and type;
• technical node and user problem;
• observed evidence gap;
• search coverage supporting the gap;
• known nearby patents/solutions;
• counterevidence and alternative explanation;
• user capability fit;
• technical feasibility assumptions;
• maturity and dependency;
• market/business relevance source;
• proposed experiment;
• success and failure criteria;
• IP question for counsel;
• monitoring indicators;
• confidence and owner.

Appendix B — Invention-mining field contract

Problem record

• problem ID;
• linked tree node;
• baseline and current state;
• target response and unit;
• operating/boundary conditions;
• measurement method and uncertainty;
• constraint or contradiction;
• business/engineering relevance;
• evidence IDs;
• priority rubric and result.

Concept record

• concept ID;
• linked problem;
• proposed changed feature/relationship;
• mechanism;
• expected technical effect;
• measurable prediction;
• required components/materials/data;
• variants and alternatives;
• dependencies and interfaces;
• feasibility risks;
• safety/regulatory risks;
• prior-art search IDs;
• closest relevant records;
• differentiating questions;
• counterevidence;
• experiment and acceptance criterion;
• confidentiality/public-disclosure status;
• reviewer and disposition.

Prior-art record

• evidence ID;
• publication number and exact source URL;
• family/member used;
• priority/publication dates;
• applicant/inventor as published;
• relevant claims or passages;
• mapped concept features;
• similarities;
• differences;
• status observation and source;
• jurisdiction;
• translation status;
• analyst limitation.

Action record

• concept ID;
• disposition;
• owner;
• decision authority;
• next evidence required;
• experiment or search task;
• start and due dates;
• dependency;
• success/failure criterion;
• disclosure/control requirement;
• next review gate.

Appendix C — Intelligence-item contract

Each item contains:

• stable item ID;
• dimension and subcategory;
• factual headline;
• event/effective/publication date;
• discovery and access date;
• organizations and technologies;
• geography;
• primary source ID;
• corroborating source IDs;
• whether sources are independent;
• source-quality dimensions;
• confidence label and rationale;
• priority label and decision rationale;
• fact versus inference fields;
• counterevidence;
• implications;
• verification action;
• owner and review date.

Timeline event

• event ID;
• exact or approximate date;
• date type;
• linked intelligence items;
• linked patent/paper/policy records;
• route/actor mapping;
• observed change;
• interpretation;
• alternative explanation;
• confidence.

Cross-signal record

• signal ID;
• proposition being tested;
• evidence from each dimension;
• independence assessment;
• chronological order;
• supporting evidence;
• contradictory evidence;
• missing evidence;
• conclusion strength;
• next observable indicator.

Appendix D — Report production checks

Before authoring:

• freeze the data package;
• validate required fields;
• reconcile IDs;
• remove duplicate sources;
• verify link schemes;
• identify empty sections;
• compute chart series from the same reviewed tables;
• define accessibility labels;
• mark reviewer status.

During authoring:

• escape untrusted text;
• avoid injecting raw user HTML;
• keep source text and translation distinguishable;
• show units in labels;
• show unknown values as unknown;
• prevent division by zero or misleading percentages;
• keep color legends textual;
• avoid motion-only disclosure;
• preserve print page breaks.

After authoring:

• validate HTML structure;
• inspect at desktop and mobile widths;
• print to PDF or print preview;
• test keyboard navigation;
• verify chart/table equality;
• verify every evidence link;
• scan for domestic links and source-case facts;
• scan for credentials and personal paths;
• obtain technical and IP review as appropriate;
• record release decision and unresolved risks.