Prior art · defensive publication
This page is a defensive publication and product-category framing document. It records what address.bot acknowledges as established prior art, what address.bot does not claim, and the narrow combined architecture published here defensively: human-owned, agent-operated address infrastructure for policy-controlled, address-scoped physical-world evidence workflows. It is not a legal opinion on patentability, infringement, validity, or freedom to operate. The canonical text is timestamped through OpenTimestamps and, after Bitcoin block confirmation and an ots upgrade, anchored to Bitcoin; see section 7.
Bottom line
A postcard with a code or QR is not novel by itself. API-driven physical mail is not novel by itself. Photo or video capture is not novel by itself. Signed webhooks are not novel by themselves. Agent protocols are not novel by themselves. The differentiated architecture for address.bot is the combined interlock, narrowly stated: a human-owned account delegates bounded authority to an autonomous agent; the agent requests a physical address trigger and typed evidence contract; the platform validates policy, risk, review state, and spend constraints; a postal mailpiece reaches the mail stream for a physical street address; a non-account recipient redeems the request-scoped QR or printed code; the recipient submits typed evidence about the address, site, asset, condition, measurement, sample, observation, or requested media; the platform returns signed, machine-readable events to the initiating account or agent runtime; and validated state may unlock further bounded agent actions. address.bot does not identify the recipient, does not claim legal residency, does not perform KYC, and does not produce a sealed PDF evidence document.
The primitive is not merely address verification. The primitive is address-scoped physical-world tasking: an agent or business can ask for a specific observation, media artifact, measurement, sample, signature, third-party attestation, or other requested evidence tied to a physical address, and receive the result back as a machine-readable event for downstream agent, LLM, API, or human review action.
Defensive publication posture
0.1
This is a defensive publication and product-category framing document, not a claim that address.bot invented postcards, QR codes, postal OTP, address validation, KYC, signed webhooks, evidence capture, field inspection, cryptographic timestamps, or agent protocols.
0.2
The disclosed architecture is a human-owned, agent-operated workflow where a physical mailpiece or other physical address trigger opens a request-scoped evidence task about a street address, site, object, asset, condition, measurement, or requested observation — not a local identity investigation of the person who receives the mailpiece.
0.3
The recipient may complete the request without creating an address.bot account; custody, API delivery, policy controls, billing, logs, signed events, and downstream machine-readable state remain tied to the requesting business account and its delegated agent keys.
0.4
The publication is intentionally narrow: agent authority, human/business ownership, physical-world address trigger, non-account recipient evidence return, policy/spend gating, signed event custody, and escalation from physical address evidence triggers into site evidence, custom media requests, sample custody, fieldworker dispatch, or third-party attestation.
0.5
The public page should be date-stamped, versioned, canonicalized, archived, hashed, and timestamped. After any material edit, the canonical text file, SHA-256 digest, and OpenTimestamps proof should be regenerated.
Novelty thesis · what is different
The novelty theory is not “agent sends postcard.” The narrower thesis is delegated autonomous-agent initiation of policy-controlled physical address workflows and typed evidence collection from non-account recipients, with the output returned as signed events to the initiating account, webhook endpoint, LLM tool flow, or agent runtime.
Delegated physical-world action layer
The core disclosed architecture is a delegated physical-world action layer: a human or business owner authorizes one or more autonomous agents to initiate bounded physical address evidence triggers, collect address-tied evidence from non-account recipients, and receive machine-verifiable event updates under policy, risk, review, and spend controls. This is materially narrower and more specific than the generic idea that an AI agent can call a mailing API.
Address-scoped evidence object
The mailed token creates an address-scoped evidence object owned by the API initiator, not by the postcard recipient. Whoever has practical access to the mailpiece may complete the task, but the resulting state change is evidence about the address, site, asset, condition, or requested observation — not proof that a named person lives there or has been identified.
Arbitrary address-scoped evidence requests
The typed evidence contract is not limited to proof-of-address. It may request meter readings, serial-number capture, asset-tag photos, construction progress media, vacancy observations, custom videos, signatures, notes, document uploads, soil sample chain-of-custody, drone imagery, surveillance-footage requests, third-party observations, or other physical-world evidence. Completion of the request returns a structured event to the initiating account, webhook endpoint, LLM tool flow, or agent runtime.
Policy-based escalation
The system may start with a postal code or QR redemption and escalate, according to owner policy, risk score, asset type, address class, geography, agent confidence, prior workflow state, or manual review, into richer evidence requests such as photo, video, timestamped capture, geolocation, signature, document upload, fieldworker dispatch, drone imagery, soil sample, surveillance-footage request, or other typed evidence about the address.
Agent-safe real-world permissions
The address becomes a permissioned surface for agentic work. Autonomous agents can request physical-world actions at an address only when the request satisfies owner-defined rules, evidence requirements, geographic constraints, spend limits, abuse controls, workflow state, and review requirements.
Event custody, not PDF-pack claims
Signed event payloads, append-only timelines, media metadata, signed asset descriptors, and optional hash references may support custody and auditability, but address.bot does not claim a tamper-evident PDF pack, legal proof-of-address document, KYC artifact, or identity attestation as the invention. Those remain outside the claimed or defensively published surface.
Distinction from tamper-evident evidence-pack systems
address.bot does not claim, generate, rely on, or market a tamper-evident PDF evidence pack as the inventive surface. Hash-chained PDFs, sealed audit packets, immutable evidence bundles, cryptographic document timestamps, and auditor-ready evidence files are treated as adjacent prior art. address.bot's disclosed surface is different: a human-owned account delegates bounded authority to software agents; the agent initiates a postal-mail-gated physical address evidence task; a non-account recipient redeems a request-scoped QR or printed code; the recipient submits typed evidence about the address, site, asset, condition, observation, measurement, or requested task; and signed machine-readable events return to the initiating account or agent runtime under owner policy, spend, risk, and review controls.
The unit of trust is not a sealed PDF. The unit of trust is the address-scoped evidence workflow and the signed state transitions around that workflow.
More specific than “agent calls API”
Why This Has More Meat
The strongest invention story is not “agent calls API.” It is a delegated physical-world action layer where a human or business owner authorizes an autonomous agent to initiate bounded address-scoped challenges, collect evidence from a non-account recipient, and return machine-verifiable events under policy controls.
Patent-attorney review topics
The following are not asserted as granted claims. They are the specific invention concepts that this defensive publication preserves and that may merit further patent-attorney review, separate from the generic prior art of postcard verification, KYC, PDFs, hashing, field capture, and webhooks.
Vantage point
Express disclaimers · things not claimed
1.01
Mailing a postcard or letter containing a one-time code or QR code to confirm someone can receive mail at a postal address. Used by banks, telecoms, government agencies, and proof-of-address services for many years.
1.02
Combining email OTP, postal OTP, optional SMS, optional GPS, risk scoring, and identity-bound proof-of-address verification paths. Those patterns are established in public proof-of-address and regulated onboarding products. address.bot is expressly outside that category.
1.03
Tamper-evident PDF evidence packs of any kind, sealed by a SHA-256 hash chain or otherwise. Public proof-of-address and audit products may describe sealed evidence-pack approaches. address.bot does not produce, claim, rely on, or market sealed PDF evidence-pack systems.
1.04
SHA-256 hash chains, Merkle trees, content-addressed evidence bundles, detached cryptographic signatures, and cryptographic timestamping used to seal or time-prove a digital document or evidence collection.
1.05
HMAC-SHA256 signing of outbound webhook payloads with a timestamp, signing version, and signature header. Standard practice across Stripe, GitHub, Twilio, Lob, and many others.
1.06
API-driven postcard or letter printing and mailing with delivery, in-transit, returned-to-sender, and undeliverable status webhooks. Well-covered by direct-mail API providers.
1.07
Address normalization, CASS certification, DPV confirmation, geocoding, ZIP+4 enrichment, and parcel/address classification. Well-covered by postal authorities and address-validation vendors.
1.08
Identity verification, document OCR, liveness, selfie comparison, biometric matching, and KYC field workflows. Well-covered by identity verification providers. address.bot is expressly out of this category.
1.09
Risk scoring of recipient addresses and detection of disposable email, mail forwarding, ghost addresses, commercial mail receiving agencies, or suspicious onboarding behavior. Well-covered by risk vendors and proof-of-address providers.
1.10
Agent transport and discovery protocols themselves, including MCP, A2A, Hermes-style messaging, OpenClaw, or similar agent runtimes. address.bot consumes these as third-party protocol layers.
1.11
HTTP 402 Payment Required, x402-style machine payment proposals, hosted billing portals, sandbox-versus-live API key prefix discrimination such as sk_test_* and sk_live_*, and the Idempotency-Key header on POST endpoints. Prior art from RFCs, payment processors, the x402 community, and general HTTP practice.
1.12
Direct mail automation triggered by data events, schedules, CRM workflows, marketing workflows, or business rules. Widely available in marketing and direct-mail tooling.
1.13
Token-scoped one-time anonymous web sessions bound to a magic link or scanned code in general. Prior art from password-reset flows, magic-link authentication, event ticketing, and existing postal verification products.
1.14
Generic webhook-driven workflows that hand off events to AI agents, LLM runtimes, serverless workers, queues, or internal automation tools.
1.15
Photo or video field inspection apps, property condition reporting tools, construction progress documentation, field service management platforms, drone capture workflows, and remote inspection capture in general. address.bot consumes recipient-uploaded or third-party-submitted media but does not claim invention of remote inspection capture as a category.
1.16
The generic proposition that an autonomous agent may call a third-party API. address.bot's defensive publication is not that an agent calls an API; it is the owner-delegated, policy-gated, address-scoped physical-world evidence workflow that the API call initiates and governs.
1.17
The generic proposition that a verification result may unlock an action. address.bot's disclosed interlock is specific to a physical address trigger, a typed evidence contract, non-account recipient submission, signed event custody, and owner-controlled agent permissions.
Named adjacent prior art
Lob, PostGrid, Click2Mail, PCM Integrations, and direct-mail API providers
Programmable postcard and letter mailing with address helpers, templates, delivery events, returned-mail events, and API-driven fulfillment. address.bot treats mail production as an input layer, not as the novelty by itself.
USPS CASS / DPV, Smarty, Loqate, Melissa, Google Address Validation, and address-validation providers
Address parsing, normalization, deliverability, geocoding, enrichment, and classification. address.bot may consume or resemble these inputs, but the disclosed architecture concerns address-scoped evidence workflows after a request is created.
Identity verification and KYC platforms
Identity verification platforms collect person-bound evidence such as document images, selfies, liveness, biometrics, proof-of-address documents, sanctions checks, or AML onboarding artifacts. address.bot does not operate in that category and does not identify the recipient.
Payment processors and API infrastructure providers
Sandbox and live key separation, idempotency keys, hosted billing portals, HMAC webhook signing, billing confirmation, and machine-readable payment remediation are established API patterns. address.bot uses those patterns as ordinary infrastructure rather than claiming them in isolation.
Agent protocols and agent runtimes
Protocols and runtimes for software agents to exchange tool calls, context, messages, and structured outputs are third-party transport layers. address.bot may deliver events into these transports, but does not claim invention of the transport protocols themselves.
Event-driven agent inbox and communication products
Webhook delivery of inbound communication events into agent runtimes for autonomous handling is prior art. address.bot's distinction is the physical address trigger and typed address-scoped evidence contract feeding those event streams.
Government postal identity and address-proof artifacts
Government-issued postal identity cards, postal address proof cards, and residence/address artifacts are prior art. address.bot does not issue identity cards or proof-of-residence artifacts.
Property condition reporting and field inspection tools
Photo, video, timestamp, geolocation, and field evidence capture of physical premises by inspectors, workers, tenants, owners, or residents is a known category. address.bot's disclosed surface is the mail-gated, request-scoped, accountless recipient workflow and agent-callable event return, not field capture in the abstract.
iDenfy — WO2024261513A1 / EP4695708A1
Patent application directed to verifying the legal identity of a person by mailing a QR or short numeric code to a postal address and combining the recipient-side scan with downstream KYC, proof-of-address, identity-document capture, or biometric matching. address.bot is intentionally not in this category: it does not verify legal identity, does not collect identity documents, does not collect biometric data, does not produce a proof-of-residency artifact, and does not claim that any named person resides at the address. The recipient-side scan opens a request-scoped, accountless typed-evidence contract about the address, site, asset, condition, or requested observation — never an identity verification flow about the recipient.
United States Postal Service — US8214302B2
Granted patent directed to authenticating a physical address by mailing an electronic transaction verification document encoded with a unique verification ID and requiring the applicant to dispatch the document back through the postal system, comparing dispatch location and time against the submitted address as the authentication signal. address.bot has no return-mail leg, does not require the recipient to dispatch any physical item back, and does not use mail-processing-system metadata as the authentication signal. The mailpiece is a one-way physical capability grant; the recipient returns typed evidence about the address over the web through a one-time, accountless, token-scoped session.
Hushmesh — US11088837B2
Granted patent directed to a residence-based digital identity system in which a postal mailpiece carries a printed code addressed to a dedicated, always-on, cryptographically unique in-home device that scans the code and cryptographically confirms receipt to bind a residence to a digital identity for subsequent authentication. address.bot does not install, ship, distribute, sell, or assume any in-home cryptographic beacon device, does not bind a residence to a digital identity, does not issue residence-bound keys, and does not operate a residence-keyed authentication or single-sign-on system.
Civic — US20170317997A1
Published application directed to identity verification and attestation using a centralized or distributed ledger, including methods that may use a physical mailpiece or printed code as part of a validation protocol that ultimately writes a cryptographic identity attestation about a person to a ledger. address.bot does not publish identity attestations to any ledger, does not certify or sign user identities, does not act as an attestor in a verifiable-credential or decentralized-identifier framework, and does not create cryptographic identity records. The output is a signed event payload describing the state of a request mailed to an address, not an attestation about who the recipient is.
Location-based social network — CA2900042A1
Published application describing methods for organizing an online social network by geographical neighborhood and verifying address membership in a neighborhood by mailing a postcard with a verification code that the user enters to confirm membership. address.bot does not operate a social network, does not define neighborhoods, does not confirm community membership, and does not use postcard-code redemption to grant the recipient access to any address.bot service. The redemption opens only the request-scoped typed-evidence contract authored in advance by the requesting business; the recipient receives no account, no membership, and no continuing relationship with the platform.
707 Limited — US11924342B2
Granted patent directed to computer-implemented methods for evidencing the existence of a digital document, anonymously evidencing the existence of a digital document, and verifying its data integrity. The methods combine metadata, a cryptographic hash of the document, and a time stamp from an external time source into a stored evidence key produced at a remote evidence-key generator. address.bot does not produce evidence keys, further or compound evidence keys, identity hashes, or sealed cryptographic artifacts about a digital document; does not operate a remote evidence-key generator or tag-chain of such keys; and does not publish reference codes that grant third parties access to a sealed evidence record about a digital document. address.bot's outputs are signed event payloads describing the state of a request-scoped mailpiece-and-typed-evidence contract about a postal address — not proofs of the existence or integrity of a digital document.
Fatdoor / Abhyanker — US8738545B2
Granted patent directed to a map-based neighborhood social network operated by a privacy server, in which an address verification algorithm verifies that each user lives at a residential address and access to private neighborhood content is granted only to verified residents within a boundary. The patent enumerates multiple residence-verification methods, including postcard with unique alphanumeric access code. address.bot is not a neighborhood social network, does not define geofenced neighborhood boundaries, does not grant the recipient ongoing access to a private community of co-residents, and does not use postcard-code redemption to claim or prove that the recipient lives at the address. The postcard code in address.bot is a one-time physical capability grant for a single typed evidence task, not a credential for ongoing membership in a community.
General note on the named filings above
Several named filings operate on a similar surface ingredient — a code or QR mailed to a physical address — and extend that ingredient in directions address.bot expressly does not take: legal-identity verification, return-mail address authentication of an applicant, in-home cryptographic device binding to a digital identity, social-network neighborhood membership, or cryptographic evidence-key generation about digital documents. address.bot's narrow combination uses the mailed code as a one-way physical capability grant that opens a request-scoped, accountless, typed evidence contract about an address, consumed by an agent runtime under human-owner spend controls. Based on the public descriptions reviewed for this defensive publication, address.bot is intentionally framed away from identity verification, return-mail authentication, residence-bound cryptographic identity, neighborhood membership, and digital-document evidence-key generation. This is not a legal opinion on infringement, validity, or freedom to operate.
Judicial precedent — Secured Mail Solutions LLC v. Universal Wilde, Inc., No. 2016-1728 (Fed. Cir. Oct. 16, 2017)
Federal Circuit decision affirming district-court invalidation under 35 U.S.C. § 101 and the Alice/Mayo framework of seven patents directed to mailed-identifier verification. The surface ingredients held abstract included sender-assigned mail identifiers, barcodes, QR codes as identifier carriers, post-delivery communication about the mailpiece, and personalized-URL scanning to display recipient-side data. This entry is recorded as judicial precedent rather than as a patent filing. It is included because those surface ingredients overlap with ingredients address.bot does not claim as novel in isolation. The defensive surface here depends on the specific interlock among a postal-mail-gated one-way physical capability grant, a request-scoped accountless recipient session, an API-authored typed evidence contract about the address, signed agent-callable events, and human-owner-controlled spend caps — not on any individual surface ingredient. This is not a legal opinion and is not a prediction about how any future court would rule on the present subject matter.
Agentic workflow
Human owner delegates bounded authority to an agent key
↓
Software agent authors a typed evidence contract about one address
↓
Policy engine evaluates request type · spend cap · risk · review state
↓
POST /api/v1/preflight → priced estimate · 402-style remediation if not entitled
↓
Human owner approves live sending under per-request + monthly caps
↓
POST /api/v1/verifications (live request with matching preflight context)
↓
Postal mailpiece printed and mailed to a street address
↓
Whoever has access to the mailpiece scans QR or enters printed code
↓
Request-scoped session opens · no recipient account · no identity collection
↓
Recipient submits typed evidence about the address:
photo · video · code · note · signature · custom instructions
↓
address.bot validates evidence against the same typed contract
↓
Signed event (verification.submitted) emitted with request + evidence identifiers
↓
Event consumed by the customer's agent runtime via:
signed HTTPS webhook · MCP tool result · A2A message · Hermes envelope
OpenClaw worker · queue event · any chosen transport
↓
Agent decides and acts — keyed to the same address and the same evidence contract
↓
Optional escalation under policy:
photo · video · note · signature · follow-up mailing
or manual review / third-party follow-up outside the current APINarrow claim surface · the combination published defensively
None of the components below are claimed in isolation. The defensive surface is the specific interlock among them. Every property is asserted about a postal address and the typed evidence about that address, site, asset, condition, observation, measurement, sample, or requested task; none makes any assertion about the identity, residency, or legal status of any human recipient.
3.1 Mailpiece redemption as an agent-callable trigger about an address
A postal mailpiece that, when its recipient-side scanned code or printed code is presented back to the issuing platform, fires a request-scoped, signed, machine-readable event shaped to be directly consumable by a software agent runtime as a tool-call, webhook, A2A-style decision input, MCP result, or other agent-facing message. The mailpiece functions as a physical capability grant whose redemption opens an agent-callable decision point about a physical address, rather than functioning only as a step in a human-only KYC or identity-bound proof-of-address workflow.
3.2 Per-mailpiece typed evidence contract about the address
A typed evidence contract authored inline at request creation by an API caller — including a software agent — and persisted as a per-mailpiece obligation. The contract specifies the kinds of recipient evidence required, including printed code, photo, video, note, checkbox attestation, signature, document upload, meter reading, serial number, sample custody confirmation, custom media request, third-party observation, or other task-specific evidence. The recipient experience for that one mailpiece is bound to that specific contract, and the agent runtime consuming the post-completion event receives the same contract identifiers so it can route its decision against the fields it originally requested. The contract is about observable facts at the address, not about the identity of any person.
3.3 Owner-plus-agent split control over physical mailing
A control split between a verified human business owner and one or more software agents operating under that owner's account, in which: (a) software agents may create draft accounts, sandbox requests, preflight estimates, and configuration without a live mailing being committed; (b) a verified human owner must claim the account by email before any live postal mailing or live spend may occur; (c) the human owner sets a per-request spend cap and a monthly spend cap that bound autonomous agent operation; (d) the first live mailing of the account requires explicit owner approval recorded as an auditable event; (e) requests that match risk heuristics enter a manual review queue specifically gating physical mail or downstream physical-world action; and (f) all of the above are exposed to the agent over the same API surface so the agent may inspect policy state and proceed deterministically rather than guessing.
3.4 Anonymous, accountless, request-scoped recipient session
A request-scoped, accountless, anonymous recipient session bound to one mailpiece, one street address, one typed evidence contract, and one requesting business account, with no recipient-side registration on the platform, no identity collection from the recipient, no name verification, and no claim that the person at the address is any particular individual. All segmentation identifiers — including business id, mode, batch id, tranche id, tranche key, request id, request type, reference, free-form metadata, and QR template variant — are resolved server-side from the token rather than encoded into the recipient URL.
3.5 Preflight-and-confirm contract over mail plus typed evidence
A preflight quote and confirm contract that prices a postal mailing plus a typed evidence contract together as a single machine-readable estimate, returns a structured 402-style payment or approval challenge if the requester is not yet entitled to commit live spend, and only converts the preflight into live fulfillment after a separately recorded confirmation event that references the same preflight identifier. Preflight pricing is the same code path used by both human-driven dashboard confirmation and software-agent-driven confirmation.
3.6 The combined end-to-end interlock
A combined state machine wiring the above together end to end: (i) agent-authored draft, (ii) human-owner claim, (iii) preflight quote of mail plus typed evidence about the address, (iv) owner-approved confirmation under the live policy caps, (v) postal mailing of the physical trigger, (vi) anonymous recipient redemption of the mailpiece into the request-scoped session, (vii) typed evidence submission against the per-request contract, (viii) signed machine-readable event delivered into an agent runtime over a standard agent transport, and (ix) agent decision and downstream action keyed to the same address and the same evidence contract that originated the mailpiece.
3.7 Delegated physical-world action authority
A human or business owner delegates limited authority to one or more autonomous agents to initiate physical address evidence triggers. The agent's authority is bounded by account ownership, key scope, request type, spend limits, jurisdiction or geography, evidence policy, manual-review state, and abuse controls before the platform commits live postal fulfillment, emits downstream instructions, or accepts a downstream physical-world action.
3.8 Address-scoped evidence object owned by the initiator
A mailed code or QR creates an address-scoped evidence object tied to the initiating business account, the delegated agent or API key, the target address, the typed evidence contract, and the specific mailpiece. The recipient can complete the task without becoming the object owner, creating an account, or being identified; the output is an event and evidence state about the address, site, asset, condition, observation, measurement, or task for the initiating account.
3.9 Policy-based escalation of address-bound evidence
A request may escalate from basic postal code redemption into additional address-bound evidence requirements according to owner policy, risk score, address class, asset type, agent confidence, prior workflow state, geography, jurisdiction, or manual review. Escalations may include photo, video, timestamped capture, geolocation, signature, document upload, fieldworker dispatch, drone imagery, meter readings, serial-number capture, soil sample, surveillance-footage request, custom media capture, or other typed evidence about the address.
3.10 Agent-safe real-world permissions for addresses
The state of an address-scoped evidence object may gate subsequent agent actions, including payment release, contractor approval, site-access authorization, property-condition acceptance, follow-up mailings, third-party attestation, fieldworker dispatch, sample pickup, media request, robotics task, or other downstream workflows. Those actions remain bounded by the same human-owner policy, spend, risk, and review controls rather than by autonomous agent discretion alone.
Concrete agent-trigger embodiment
Example payload · typed evidence contract about an address
{
"request_type": "custom_media",
"recipient": {
"name": "Site Contact",
"line1": "123 Main St",
"city": "Austin",
"region": "TX",
"postal_code": "78701",
"country": "US"
},
"recipient_message": "Please scan this code and complete the requested site evidence tasks.",
"evidence": [
{
"kind": "code",
"label": "Printed postcard code",
"required": true
},
{
"kind": "photo",
"label": "Exterior photo",
"required": true,
"max_files": 3
},
{
"kind": "video",
"label": "Exterior walkthrough video",
"required": false,
"max_files": 1,
"max_size_mb": 250
},
{
"kind": "note",
"label": "Site note",
"required": true
},
{
"kind": "signature",
"label": "Optional recipient attestation",
"required": false
}
],
"reference": "site_check_123_main",
"metadata": {
"agent_initiated": true,
"requested_outcome": "address_scoped_evidence"
}
}The point of the request is not to send mail. It is to define a machine-readable typed evidence contract about a physical address that becomes completable only after the postal mailpiece is associated with a request-scoped QR or printed code, and whose completion fires an agent-callable event keyed to the same address and contract. No identity is asserted. No sealed evidence document is produced.
Out of scope
5.1
Generic postcard verification, generic postal proof-of-address, or generic mailed-OTP verification. Those remain prior art.
5.2
Tamper-evident hash-chained PDF evidence packs of any kind. address.bot does not publish, claim, rely on, or market sealed PDF evidence-pack systems. address.bot's media assets are stored as discrete files with metadata rows and signed event descriptors; they are not asserted to be a sealed evidence document.
5.3
Identity verification, KYC, proof-of-residency, document OCR, liveness, selfie matching, biometric matching, AML onboarding, or any binding of the recipient to a legal identity. address.bot is expressly outside this category.
5.4
Cryptographic identity protocols, decentralized identifiers, verifiable credentials, or blockchain-based identity proofs. Unrelated to this publication.
5.5
The internal designs of MCP, A2A, Hermes, OpenClaw, x402, Stripe, Lob, PostGrid, USPS, identity-verification providers, proof-of-address providers, or any third party. Each remains the property of its respective owner.
5.6
Broad claims that address.bot invented postcard verification, mail-based address confirmation, generic evidence capture, generic agent API calls, generic webhook automation, or generic cryptographic timestamping. This document deliberately avoids those broad statements.
5.7
Any assertion that the recipient is locally identified, that a named person resides at the address, or that the resulting output satisfies FCA, SRA, HMRC, AML, banking, leasing, or government proof-of-address requirements out of the box.
Comparative framing
| Capability | Prior art owners | address.bot framing |
|---|---|---|
| Normalize a postal address | USPS / Smarty / Loqate / Melissa / Google AV / address-validation providers | Input only; not claimed |
| Send a postcard via API with status hooks | Direct-mail API providers | Mail layer; consumed as a service |
| Mail a one-time code or QR for proof | Banks, KYC vendors, postal authorities, and proof-of-address products | One stage of a larger interlock; not claimed alone |
| Tamper-evident hash-chained evidence PDF | Public proof-of-address and evidence-pack products | Expressly disavowed; not used |
| Identity-bound proof-of-address or KYC | Identity verification and proof-of-address providers | Expressly disavowed; address.bot is not KYC |
| HMAC-SHA256 signed webhooks | Stripe / GitHub / Twilio / Lob / industry standard | Used as standard transport; not claimed |
| Photo or video evidence capture | Identity vendors / field inspection apps / property tools | Standard capture; bound to a per-address contract |
| Meter readings, serial captures, site observations, or sample custody | Field service, inspection, utility, construction, and chain-of-custody tools | Evidence types inside the address-scoped typed contract |
| Agent transport (MCP, A2A, Hermes, OpenClaw) | Third-party agent protocol and runtime providers | Consumed as transport; not claimed |
| HTTP 402 / x402 machine payment | RFC / Stripe / x402 community / payment processors | Used as a contract shape; not claimed |
| Sandbox vs live key separation | Stripe and other API platforms | Used as a convention; not claimed |
| Risk scoring of suspicious addresses or suspicious usage | Sift / Sardine / address-risk vendors / onboarding-risk vendors | Input to review queue and policy engine; not claimed alone |
| Delegated autonomous-agent initiation of policy-controlled physical address evidence collection | Generic agent API calls are prior art; no direct equivalent combined physical address evidence interlock is known to address.bot at publication date | Owner-delegated agent authority bounded by spend, risk, evidence, and review policy before physical-world action |
| Address-scoped evidence object owned by the API initiator | Mailed-code possession checks and KYC proof-of-address are prior art | Mailpiece creates a request-scoped address evidence object completed by a non-account recipient but owned by the initiating account |
| Policy escalation from postal-mail-gated evidence triggers to site evidence, sample custody, or third-party attestation | Field inspection, remote evidence capture, and chain-of-custody tools are prior art | Escalation is tied to the same address-scoped object and agent-owner policy rail rather than to a separate KYC or inspection product |
| Postal-mail-gated, anonymous-recipient, typed-evidence-about-an-address, agent-callable, owner-controlled-spend interlock | No direct equivalent combined interlock is known to address.bot at publication date | The narrow combination this document publishes defensively to place into the public record and make later attempts to claim the same combination easier to evaluate or challenge |
Cryptographic timestamp · OpenTimestamps with Bitcoin anchoring after confirmation
The canonical text of this publication is the file linked below. Its SHA-256 digest is recorded here, and an OpenTimestamps proof file (.ots) timestamping that digest is published alongside it. On first publication the .ots proof carries calendar attestations; once those calendars anchor the digest into a Bitcoin block and an ots upgrade is run, the calendar attestations are replaced with a Bitcoin block-header attestation. After upgrade, verification is independent of any calendar, of address.bot, and of OpenTimestamps itself.
The timestamp is not a legal threat and does not by itself decide patentability. Its purpose is to preserve the exact content and publication chronology of the disclosed architecture, place the narrow combination into the public record, and make later attempts to claim the same combination easier to evaluate or challenge.
# verify locally
curl -O https://address.bot/prior-art/2026-05-07.txt
curl -O https://address.bot/prior-art/2026-05-07.txt.ots
shasum -a 256 2026-05-07.txt
# expected: 3bfb4b3012492a9a95f1b656127dd72394debfa26aec57a47854d3d0207c5080
ots verify 2026-05-07.txt.ots
ots upgrade 2026-05-07.txt.otsStatement
address.bot publishes this document as a defensive disclosure. This publication is not a substitute for a patent filing and does not waive any rights address.bot may later seek to file, claim, license, or enforce. The broad ideas in postal verification, signed webhooks, evidence capture, address normalization, agent transport, machine payment rails, identity verification, field inspection, cryptographic timestamps, and tamper-evident evidence packs remain the prior art of their respective owners and publishers. The narrow combination described above — a delegated autonomous-agent, human-owner-controlled, postal-mail-gated, anonymous-recipient, address-scoped typed-evidence workflow with signed event custody, policy/spend controls, and optional escalation into address-bound site evidence, sample custody, custom media capture, fieldworker dispatch, or third-party attestation — is published here, timestamped through OpenTimestamps and, after Bitcoin block confirmation and an ots upgrade, anchored to Bitcoin per section 7. It is contributed to the public record to place this combination into the public record and make later attempts to claim the same combination easier to evaluate or challenge.
Published by address.bot · 2026-05-07