Cycle Walking Tokenization Engine for Variable-Length String Conversion

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing tokenization systems face challenges in efficiently converting plaintext data to tokens and vice versa when the string length is less than the lookup size of the token/plaintext lookup table, leading to inefficiencies in memory usage and conversion latency.

Innovation Solution

The cycle walking tokenization engine employs string padding and multiple table lookups to match the string length to the lookup size, using leading or trailing zeros to pad the input string, and iteratively refining the lookup until the correct token or plaintext is retrieved, allowing for efficient conversions using the token/plaintext lookup table.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If the input string length is less than the lookup size of the token/plaintext lookup table, then the conversion process becomes inefficient, but using standard lookup tables requires larger memory allocation to handle all possible string lengths

Engineering Contradiction:
Improveconversion efficiencyVSAvoidmemory footprint
Core Design Contradiction:
ProductivityVSQuantity of substance

Solution Approach 1:

The patent segments the tokenization process into multiple iterative lookup operations. Instead of requiring a single large lookup table that can handle all string lengths, the system performs multiple smaller lookups on progressively refined strings, where each lookup operates on the lookup table's native size. This segmentation allows efficient processing of variable-length strings without requiring the lookup table to be oversized.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies preliminary actions by performing padding or truncation of the input string before the lookup operation to ensure the string length matches the lookup table's expected size. This preprocessing step prepares the data in advance, allowing the main lookup operation to proceed efficiently without requiring the table to accommodate all possible string lengths.

Inventive Principle:
Principle #10Preliminary action

2Measurement precision

If multiple table lookups are performed to handle strings of varying lengths, then conversion accuracy improves, but conversion latency increases

Engineering Contradiction:
Improveconversion accuracyVSAvoidconversion latency
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent implements a dynamic tokenization approach where the number of lookup iterations and the string transformation operations adapt based on the input string length. For strings that already match the lookup size, a single lookup suffices. For strings of different lengths, the system dynamically applies padding or truncation followed by iterative lookups, optimizing the balance between accuracy and latency for each specific case rather than using a fixed multi-step process for all inputs.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent maintains continuous useful action by ensuring that each iterative lookup builds upon the previous result, with the output of one lookup becoming the input for the next. This continuous refinement process efficiently converges to the correct token or plaintext, minimizing unnecessary iterations while ensuring conversion accuracy. The process maintains momentum by continuously transforming the string toward its final form rather than performing discrete, disconnected operations.

Inventive Principle:
Principle #20Continuity of useful action

Data Source

PatentUS10956610B2Cycle walking-based tokenization
Publication Date: 2021.03.23 MICRO FOCUS LLC
  • US10956610B2 patent drawing
  • US10956610B2 patent drawing
  • US10956610B2 patent drawing

AI summary

A technique includes accessing data representing plaintext. The plaintext has a first string size. The technique includes using a table to retrieve data representing a token that corresponds to the plaintext. The table has an associated string lookup size smaller than the first string size.