The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate preferred embodiments of the invention. Together with the description, the drawings serve to explain the principles of the invention. In the drawings:
is a block diagram showing the overall system architecture of the Decentralized Cryptographic Symbology Engine™ (D-CSE) System (10). The system boundary (10) encompasses three principal sub-system modules. The Encoder Module (100) comprises the Keccak-256 Hash Engine (102), which applies the SHA-3 cryptographic hash function to an input payload; the Procedural Glyph Generator (104), which produces a deterministic SVG visual symbol from the hash output; and the Compression Calculator (106), which computes the lossless compression ratio between the original payload and the 32-byte token. The Decentralized Ledger Interface (200) comprises the IPFS Content-Addressable Store (202), which stores the mapping between the GlyphHash and the original payload; the Polygon Blockchain Ledger (204), which records the GlyphHash and IPFS Content Identifier on-chain; and the Hash-to-Payload Index (206), which maintains the bidirectional lookup registry. The Decoder Module (300) comprises the Hash/IPFS URI Parser (302), which normalizes the query input; the CID Lookup Engine (304), which resolves the GlyphHash against the IPFS store; and the Lossless Fidelity Verifier (306), which confirms bit-perfect data integrity of the retrieved payload. External interfaces include the Client providing the Input Payload (400), the IPFS Network (500), the Polygon Blockchain Network (600), and the Client receiving the Restored Payload (700).
is a flowchart illustrating the method of encoding a natural language, code, or cultural narrative payload into a cryptographic symbology token, corresponding to Claims 1, 2, 3, and 5. The method begins at step S-202, wherein an arbitrary input payload of any byte length is received by the system. At step S-204, the Keccak-256 (SHA-3) cryptographic hash function is applied to the payload bytes, producing a deterministic fixed-length 32-byte Glyph Hash regardless of input size. At step S-206, hash bytes [0] through [31] are extracted as geometric seed parameters for glyph generation. At step S-208, the Glyph Generation Subroutine, further detailed in FIG. 4, is executed using the extracted seed parameters to produce the D-CSE Glyph. At step S-210, the mapping {GlyphHash → InputPayload} is stored in the IPFS Content-Addressable Store element (202 of FIG. 1). At step S-212, an IPFS Content Identifier (CID) is derived from the GlyphHash and associated with the stored payload. At step S-214, the GlyphHash and IPFS CID are broadcast to and recorded on the Polygon Blockchain Ledger element (204 of FIG. 1). At step S-216, the complete output set comprising the GlyphHash, the D-CSE Glyph SVG, the IPFS CID, and the CompressionRatio is returned to the client.
is a flowchart illustrating the method of decoding and losslessly retrieving an original data payload from a cryptographic symbology token, corresponding to Claims 4 and 6. The method begins at step S-302, wherein a query input comprising either a raw Keccak-256 GlyphHash or an IPFS URI is received. At step S-304, the input is parsed and the GlyphHash is normalized; where the input is an IPFS URI, the GlyphHash is extracted by stripping the URI prefix. At step S-306, the IPFS Content-Addressable Store element (202 of FIG. 1) is queried using the GlyphHash as the Content Identifier. At decision step S-308, the system determines whether the queried payload is present in the store. If the payload is not found, the method proceeds to step S-310, which returns an error condition of “Hash Not Found” and the method terminates on the error path. If the payload is found, the method continues to step S-312, which retrieves the original input payload in full from the IPFS store. At step S-314, a bit-perfect data integrity verification is performed by comparing the hash of the retrieved payload against the query GlyphHash, confirming lossless recovery. At step S-316, the original payload is returned together with a confirmed fidelity status of 100% Lossless Verified, completing the lossless retrieval cycle and proving the core utility claim of Lossless Cultural Compression.
is a reference diagram illustrating the Glyph Generation Subroutine, which is invoked at step S-208 of FIG. 2, showing the deterministic mapping of the 32-byte Keccak-256 GlyphHash input (400) to ten distinct visual glyph parameters within the Glyph Generation Engine (402), corresponding to Claim 3. The Shape Family Selector (404), seeded by hash byte H₀, determines the polygon vertex count in the range of three sides (triangle) to eight sides (octagon). The Outer Radius Calculator (406), seeded by byte H₁, sets the shape’s canvas coverage in the range of 30% to 70% of the viewBox dimensions. The Inner/Outer Radius Ratio (408), seeded by byte H₂, determines the size of the inner polygon as a ratio of 0.30 to 0.85 times the outer radius. The Base Rotation Angle (410), seeded by byte H₃, determines the base orientation of the glyph in the range of 0° to 360°, mapped linearly from the byte value 0x00–0xFF. The Primary Color Hue (412), seeded by byte H₄, selects the primary HSL color hue in the range of 0° to 360° across the full color wheel. The Accent Color Hue (414), seeded by bytes H₅ and H₆, generates a secondary color palette by offsetting from the primary hue by a factor of H₅ multiplied by 1.4. The Nested Layer Depth (416), seeded by bytes H₇ and H₈, sets the number of concentric nested shape layers in the range of two to five layers. Per-Layer Geometry Offsets (418), seeded by bytes H₉ through H₁₄, control the individual scaling, rotation delta, and opacity for each nested layer. Stroke Weight Parameters (420), seeded by bytes H₁₅ through H₁₉, set the per-element line thickness in the range of 0.5 to 4.0 SVG units. The Decorative Geometry Seed (422), seeded by bytes H₂₀ through H₃₁, controls embellishment element positions, inner dot array configurations, and accent shape placements. The combined output of all ten parameter mappings is the deterministic D-CSE Glyph Symbol (424), a unique SVG visual token that is cryptographically bound to the original input payload by virtue of the collision resistance of the Keccak-256 hash function.
| Numeral | Figure(s) | Element / Step Description |
|---|---|---|
| (10) | FIG. 1 | D-CSE System boundary |
| (100) | FIG. 1 | Encoder Module |
| (102) | FIG. 1 | Keccak-256 Hash Engine |
| (104) | FIG. 1 | Procedural Glyph Generator |
| (106) | FIG. 1 | Compression Calculator |
| (200) | FIG. 1 | Decentralized Ledger Interface |
| (202) | FIG. 1 | IPFS Content-Addressable Store (system element) |
| (204) | FIG. 1 | Polygon Blockchain Ledger (system element) |
| (206) | FIG. 1 | Hash-to-Payload Index |
| (300) | FIG. 1 | Decoder Module |
| (302) | FIG. 1 | Hash / IPFS URI Parser (system element) |
| (304) | FIG. 1 | CID Lookup Engine |
| (306) | FIG. 1 | Lossless Fidelity Verifier |
| (400) | FIG. 1 | Client / User — Input Payload (external entity) |
| (500) | FIG. 1 | IPFS Network (external decentralized infrastructure) |
| (600) | FIG. 1 | Polygon Blockchain Network (external) |
| (700) | FIG. 1 | Client / User — Restored Payload (external entity) |
| (S-202) | FIG. 2 | Step: Receive natural language / code input payload |
| (S-204) | FIG. 2 | Step: Apply Keccak-256; output 32-byte Glyph Hash |
| (S-206) | FIG. 2 | Step: Extract hash bytes [0..31] as geometric seed parameters |
| (S-208) | FIG. 2 | Step: Execute Glyph Generation Subroutine (ref. FIG. 4) |
| (S-210) | FIG. 2 | Step: Store {GlyphHash → InputPayload} in IPFS store |
| (S-212) | FIG. 2 | Step: Derive IPFS Content Identifier (CID) |
| (S-214) | FIG. 2 | Step: Broadcast {GlyphHash, IPFS CID} to Polygon Ledger |
| (S-216) | FIG. 2 | Step: Return {GlyphHash, D-CSE Glyph, IPFS CID, CompressionRatio} |
| (S-302) | FIG. 3 | Step: Receive query — Keccak-256 hash or IPFS URI |
| (S-304) | FIG. 3 | Step: Parse input; extract / normalize GlyphHash |
| (S-306) | FIG. 3 | Step: Query IPFS store using GlyphHash as CID |
| (S-308) | FIG. 3 | Decision: Payload found in IPFS store? |
| (S-310) | FIG. 3 | Step: Return error — Hash Not Found (error path) |
| (S-312) | FIG. 3 | Step: Retrieve original payload from IPFS store |
| (S-314) | FIG. 3 | Step: Perform bit-perfect data integrity verification |
| (S-316) | FIG. 3 | Step: Return {OriginalPayload, Fidelity: 100% Lossless Verified} |
| (400) | FIG. 4 | GlyphHash input [H₀…H₃₁] — 32-byte Keccak-256 digest |
| (402) | FIG. 4 | Glyph Generation Engine |
| (404) | FIG. 4 | Shape Family Selector — byte H₀ |
| (406) | FIG. 4 | Outer Radius Calculator — byte H₁ |
| (408) | FIG. 4 | Inner / Outer Radius Ratio — byte H₂ |
| (410) | FIG. 4 | Base Rotation Angle — byte H₃ |
| (412) | FIG. 4 | Primary Color Hue — byte H₄ |
| (414) | FIG. 4 | Accent Color Hue — bytes H₅–H₆ |
| (416) | FIG. 4 | Nested Layer Depth — bytes H₇–H₈ |
| (418) | FIG. 4 | Per-Layer Geometry Offsets — bytes H₉–H₁₄ |
| (420) | FIG. 4 | Stroke Weight Parameters — bytes H₁₅–H₁₉ |
| (422) | FIG. 4 | Decorative Geometry Seed — bytes H₂₀–H₃₁ |
| (424) | FIG. 4 | Output: D-CSE Glyph Symbol — Deterministic SVG Visual Token |