Application programming interface use support system

Abstract

The present invention relates to an API usage support system that cooperates with an API of an AI system and supports utilization of a AI model through construction of a visual dataflow.SOLUTION: Technical Field The present invention relates to an API usage support system that supports utilization of a AI model in cooperation with an API of an AI system. This system is provided with a chest flow configuration GUI processor which operates on a computer system provided with a processor and a memory and can visually construct a data flow through a graphical user interface (GUI) while supporting the use of an API, a database for storing configuration information, and a chest flow execution controller for controlling the data flow and the chest.SELECTED DRAWING: Figure 1

Description

Priority claim

[0001] This application claims priority to Provisional Patent Application No. 63 / 668,301, filed July 8, 2024, and Provisional Patent Application No. 63 / 686,167, filed August 23, 2024. [Technical Field]

[0002] The present invention relates to a computer system technically configured to efficiently support the use of an application programming interface (API), and more particularly to an API usage support system that generates and executes a structured data flow that affects the operation or output of an API in a manner that allows trial and error at any time, based on input to a plurality of objects displayed via a graphical user interface (GUI).

[0003] In recent years, artificial intelligence (AI) systems have become available as open-access computing services over the Internet, making them accessible to the general public. Various AI models have been developed, including the "GPT" series for natural language processing, "DALL-E" for image generation, and "Whisper" for speech recognition. Various platform services are also available for utilizing these AI models. For example, an API platform is provided that enables programmatic access to the models. A conversational AI system called "ChatGPT" is also available, which is used to interact with language models. Furthermore, the various AI models mentioned above are made publicly available and available on open platforms such as Hugging Face. Cloud services such as Amazon Web Services (AWS), Google Cloud, and Microsoft Azure also provide environments and tools that enable the integration and execution of API calls to these AI models.

[0004] When incorporating an external AI model into their own application programs or services, computer program developers can use the API (application programming interface) provided by the AI ​​model. They can also customize the behavior of the AI ​​model as needed. For example, by adjusting parameters such as "temperature" and "token count," it is possible to control the nature and length of the response (the number of tokens refers to the number of linguistic units into which a sentence is divided). On the other hand, when general users without specialized programming knowledge use the AI ​​model, they typically enter a single inquiry (query or prompt), check the returned response, and try to obtain the desired result through trial and error.

[0005] From the perspective of average users, even if developers provide user-friendly AI models and build platforms for using them, there may be concerns that using the platform will lead to users adopting the developer's preferences and design philosophy. Because human thought processes, conceptual frameworks, and assumptions vary from person to person, platforms that allow and support users' own trial and error tend to be more readily accepted than platforms that reflect the developer's biases. Furthermore, even if trial and error requires a certain amount of effort, users tend to prefer platforms that allow users to visually understand the process and reach a conclusion that they are satisfied with.

[0006] LangSmith, provided by LangChain, is a platform that supports the debugging and evaluation of applications that incorporate large-scale language models (LLMs). The platform is said to have the ability to visually represent the processing process from input queries to output responses in the form of a directed graph and present it to users. [Prior art documents] [Non-patent literature]

[0007] [Non-Patent Document 1] LangChain's LLM application development support tool "LangSmith" (accessed April 11, 2025) Summary of the Invention [Problem to be solved by the invention]

[0008] Previously, tools supporting LLM application development, such as LangSmith, and API-based AI frameworks, were useful in providing tracing, visualization, and debugging capabilities for LLM behavior. However, these tools primarily rely on iterative evaluation of test datasets and prompt histories to improve and adjust output, lacking mechanisms for directly and intuitively manipulating user topics of interest and intent. Furthermore, these conventional technologies have technical limitations: the output adjustment process is developer-driven, making it visually and operationally unintuitive for average users. They also lack visualization of causal relationships and structural backgrounds for the output, explaining why a particular result was achieved. Furthermore, output improvements are often influenced by the design constraints, API specifications, and rigid structure of the tools and models, hindering users' free expression of intent.

[0009] To elaborate on the previous issues, first, in conventional AI service integration, users had to understand the different API specifications for each service and implement them individually, resulting in extremely high development and maintenance costs. API authentication, log management, and usage restrictions were also handled individually, resulting in a significant lack of effort and consistency in security management. The dependency on a single service made it difficult to flexibly integrate and switch between multiple AI models, hindering versatility and scalability. Furthermore, model building and data processing operations were not visualized, making them extremely difficult to use for non-engineers.

[0010] In such environments, monolithic server configurations were the norm, making function-based scaling and load balancing difficult, significantly limiting system availability and scalability. The architecture also had unclear boundaries between the front-end data flow configuration unit, chest flow execution controller, and database, resulting in a lack of role separation, leaving issues with system maintainability. The user interface and data flow design were also unintuitive, and users were forced to perform complex operations without explicit data dependencies, resulting in a heavy operational burden.

[0011] Context management using LLM also relied on internal logic, making it difficult to control with arbitrary operations. The real-time display mechanism and UX design were also insufficient, leaving users with few ways to immediately grasp the current processing status. Furthermore, message processing and integration with external APIs were tightly coupled, making expansion and reuse difficult, and adding APIs required individual manual implementation. Tag management and pre- and post-processing code were distributed, making it difficult to achieve both flexibility and scalability, and independence between modules was not maintained.

[0012] Due to insufficient visualization of the process flow and structure, the entire flow was not encapsulated, and dependencies between chests (processing nodes) were statically defined. Processing registration and execution were performed in separate processes, requiring checks each time to maintain consistency, resulting in frequent rework. There was also a lack of coordination between the UI and execution results, and editing operations and tag settings were not immediately reflected, creating major issues with usability.

[0013] Global / local tag mapping was not integrated, making data inheritance and centralized management difficult. In addition, there were issues with recovering from operational errors and maintaining data consistency during state transitions. Chest generation, execution, and property editing were also intermittent, requiring multiple steps before execution, hindering rapid construction. There was also no unified mechanism for map / yield processing or sequence registration, resulting in a lack of flexibility.

[0014] Furthermore, message structures were not standardized, and plain text and structured data were managed together, making subsequent processing and tracking difficult. The type validation mechanism was insufficient, creating issues with the reliability of error detection and prevention. Injecting file data and linking it with function definitions and message structures was complicated, preventing structured management. There was also no standardization for the REST API, LLM integration, or input / output specifications for various queries, which increased development time.

[0015] Even in response extraction processing, branching for each condition was separated into modules, creating problems with maintenance and reusability. Furthermore, there was poor consistency between argument processing and notebook definitions, preventing flexible data integration across the two. Setting properties and structures was cumbersome, and definition updates were sometimes not reflected immediately. There was also no inheritance of previous processing results or bidirectional data mapping functionality, resulting in poor overall integration.

[0016] In light of these challenges, the present invention overcomes these issues one by one and provides a processing mechanism that receives user input for multiple objects (topic nodes, output elements, etc.) visually presented via a GUI, and sequentially constructs and optimizes output results based on sequential and trial operations such as selecting, editing, and reconfiguring the objects. This invention realizes a user-oriented output improvement system that allows users to visually operate on a topic-by-topic basis according to their own interests and questions, and allows them to freely adjust and develop output content without being bound by the constraints of a predefined API structure or system design. Furthermore, adjustments can be made without being affected by factors beyond the user's control, such as external model design or specification changes, and there is a visible feedback loop that shows which operations affected which outputs, making it easy to interpret the meaning of trial and error. [Means for solving the problem]

[0017] In order to solve the above problems, a representative configuration of the API usage support system according to the present invention is a computer-implemented API usage support system that operates on a computer system equipped with multiple processors and memory and supports complex data processing in cooperation with the application programming interface (API) of an external artificial intelligence (AI) system, and includes: a dataflow construction processor that provides a graphical interface (GUI) that supports touch or pointing device input, allowing multiple data processing nodes (chests) to be visually created, connected, and selected on a canvas, generating a flow structure that defines the data flow between the chests, and allowing the processing order and dependencies for each chest to be defined; a database unit that stores multiple tables including at least account information, project information, chest detail information, connection relationship information between chests, message processing support helper information, AI model information, uploaded data file information, script data, and dataflow identification information; Based on sequential operation requests from the GUI, the system performs input and output with the database unit, creates, deletes, places, and updates chests, controls data flow, and saves and updates dependencies. When placing a new chest, an existing chest can be graphically selected to construct a data flow. The system sequentially executes the processing steps associated with the chest, and also constructs and sends messages to be sent to the API of an external AI system, obtains corresponding responses, associates them with the chest, and processes them. The data flow constructor, database unit, and chest flow execution controller are linked via a network, making it possible to construct and execute complex processing flows, including interactions with external AI systems, based on visual and sequential input from the user.

[0018] In the API usage support system of the present invention, the chest flow execution control body can be equipped with a notebook executor that safely and virtually executes scripts or structured queries associated between the chests and saves and outputs the execution results in a format that can be used for subsequent processing within the system, and a file storage that stores and manages the data files uploaded by users and files generated by the system.

[0019] In the API usage support system of the present invention, the chest flow execution control body may further include a calculation processing support module that sends the script associated with the chest and corresponding input data to an API of an external artificial intelligence (AI) system, obtains a response from the API, analyzes and formats the response as a processing result, and then passes the response to the chest or subsequent processing.

[0020] In the API usage support system of the present invention, the chest flow execution control body can include a text preprocessing unit that analyzes unstructured or semi-structured text data and extracts structured data formatted in a format that can be processed by the API of an external artificial intelligence (AI) system.

[0021] In the API usage support system of the present invention, the chest flow execution control unit controls the execution order and dependencies of data processing across multiple chests based on the construction information of the data flow defined by the data flow configuration processing unit, generates and sends queries from each chest to the API of the external artificial intelligence (AI) system in a consistent message format according to the definition of that chest, stores the obtained API responses as messages corresponding to each chest, and sequentially propagates and processes the messages in subsequent chests while converting their contents, thereby dynamically updating the entire processing flow in real time and enabling feedback control of output throughout the entire system.

[0022] In the API usage support system of the present invention, the chest functions as the basic unit of the data processing, and has at least one or more different operating modes: a map-type chest that applies the same processing in parallel to multiple target data sets; a yield-type chest that repeats the same processing sequentially; a reduce-type chest that integrates multiple input data; and a split-type chest that divides input data and applies different processing to it.These chests are visually displayed as objects in a field on the user interface of the data flow configuration processing body, and a user can construct the entire data flow by setting visual flow objects between multiple chests in that field.

[0023] In the API usage support system of the present invention, the chest flow execution control body includes a partial execution unit that selectively executes only a portion of the chests selected by the user from among the multiple chests included in the data flow, and the partial execution unit generates a shot data structure that records the input and output states of the target chest group as snapshots based on the user's specifications, and is capable of controlling the selective execution of the portion of the chests while checking and comparing the states of the portion of the chests with other chests based on the shot data structure.

[0024] In the API usage support system of the present invention, the chest flow execution control body further includes a recalculation unit that performs recalculation processing based on dependencies and re-executes related flows for multiple chests included in the data flow, and the recalculation unit enables the configuration of a selected group of chests to be re-edited in response to a range specification input by the user on a graphical interface (GUI), and can automatically verify and resolve consistency with dependent chests based on the editing results, and then perform recalculation processing for the relevant range.

[0025] In the API usage support system of the present invention, the chest flow execution control body is provided with a message helper unit that describes the processing logic related to the generation, conversion, formatting, or transmission of API messages in each of the chests in a common definition format, and the message helper unit has a structure that can be referenced from multiple chests, making it possible to share and reuse the same message processing definition between multiple chests.

[0026] In the API usage support system of the present invention, the data flow configuration processing body is equipped with a stream display unit that displays summary information regarding the processing results or status associated with each chest as a stream-type interface that is dynamically updated along a timeline or processing order, and via the stream display unit, the user can continuously and visually grasp the summary information of multiple chests on a single screen, making it possible to efficiently track state changes in the entire processing flow and dynamically monitor changes in the dependencies between chests and the processing results.

[0027] In the API usage support system of the present invention, the chest flow execution control body comprises a chest initial calculation unit that, when creating a new chest in the data flow, performs initial calculation processing based on a script or template associated with the chest and generates the necessary properties and tags, and a recalculation unit that re-edits and updates dependencies for a range of the chests selected by the user, and then re-executes the entire or partial processing flow, and the user can selectively switch between and apply the initial calculation unit and the recalculation unit to the chest via the graphical user interface.

[0028] In the API usage support system of the present invention, the chest flow execution control body includes a message tag unit that manages a message tag that is assigned to each message as information that can identify the conversion rule or processing condition when the message is processed between chests. The message tag unit can be used as a mapping rule when converting the message tag between chests, and the tag can also be used as a flag for classifying the message, prioritizing it, specifying the execution target, or switching the processing mode.

[0029] In the API usage support system of the present invention, the chest flow execution control body is provided with a data flow backup unit that saves the configuration information of the data flow constructed by the user in template format, and the backup unit stores the entire data flow including the chest configuration, connection relationships, message processing definitions and tag information as a template, and the saved data flow template can be loaded and applied to any project and reused as a component of the project.

[0030] an output stream display unit that can display messages output from each chest or processing result data in a list format; a chest display unit that controls the display state of each chest and is responsible for interactions and object representation on the field; a flow display unit that visually displays the data flow between chests with connecting lines or the like and visualizes the data flow; a sequence management unit that can expand and contract based on the logical sequence relationships of a group of chests and visually displays child chests when expanded; and a field operation processing unit that executes processes related to the creation, update, recalculation, sequence execution, etc. of chests and flows based on operation requests from the interface unit and provides the necessary business logic.

[0031] In the API usage support system of the present invention, the data flow configuration processing body comprises a plurality of function management units that share and provide a plurality of functions within the system in response to user operations, and the function management units include an account management unit that performs user account registration, authentication and setting management, a file operation unit that enables uploading, downloading and deleting of data files, a user support unit that provides information such as system usage methods and FAQs, a message helper management unit that lists, edits, deletes and adds auxiliary information (message helpers) used in message processing, a notebook management unit that allows users to create, edit, execute and delete notebooks, a project management unit that lists, creates, deletes, selects and updates projects, and a data flow template management unit. the system includes a template management unit that saves and loads templates and enables mutual conversion between projects; an AI model management unit that enables users to learn, register, and utilize AI models based on their own data; an application state sharing unit that manages the state of the entire application; a utility frame unit that provides a common UI framework and uniformly controls the pages of each utility function; and a navigation control unit that displays navigation links to each page and can display current page information or usage context.The system is configured around the navigation control unit so that users can efficiently access the various function management units, and the AI ​​model management unit allows users to build custom AI models and use them within the system.

[0032] In the API usage support system of the present invention, the chest flow execution control body includes an AI chat integration unit that executes integration processing with a chat API of an external artificial intelligence (AI) system. The AI ​​chat integration unit includes a message formatting unit that receives message data generated within the chest, filters or converts the message based on preset properties and conditions such as role, tag, and text content, and converts it into a format required by the AI ​​system, for example, a list format of role and content pairs; a chat query generation unit that uses the formatted message to construct request data for a chat model of the AI ​​system, sends the request, and obtains an AI response; and a response generation unit that receives the AI ​​response, extracts necessary information, and performs tagging and format conversion as necessary to generate a final response message and stores the response message in an executor or a state management unit in the system. The AI ​​chat integration unit dynamically executes dialogue processing with the AI ​​system based on input from the user, and can automatically generate and provide an appropriate response.

[0033] In the API usage support system of the present invention, the chest flow execution control body comprises an AI model tuning unit that constructs and manages AI models. The AI ​​model tuning unit comprises: a custom model tuning module that trains and updates a user-defined AI model using the dataset processed by the message reformatting unit as learning data; an embedded model query module that performs embedding-based inference processing; a model registration management module that registers each of the modules in an AI model helper and makes each registered model available for matching and calling in subsequent chest processing; and a model identification response module that obtains identification information of the registered AI model and returns it to the user, thereby visualizing the availability status of the AI ​​model. This configuration enables users to dynamically register, reference, and use AI models that they have constructed or learned within the system.

[0034] In the API usage support system of the present invention, the chest flow execution control body comprises an external search collaboration unit that supports information acquisition using an external search engine, and this unit includes: (a) a search message extraction module that extracts keywords or URLs from messages in the chest and converts them into a format suitable for an external search API; (b) a search execution module that sends a query to the API of an external search service (such as Google) based on the extracted keywords or URLs and acquires search result data; and (c) a search response generation module that automatically generates a response message based on the acquired search results, stores the message in an executor within the system, and formats the message in a format that can be presented to a client. The external search collaboration unit acquires useful external information in real time from user input or messages in the chest and presents it in an integrated manner as part of the system processing, enabling dynamic and insightful response generation.

[0035] In the API usage support system of the present invention, chat queries from the standard AI system include a query processing control module (Query Function Controller) that defines the main processing functions for chat queries and controls various sub-function modules, a message formatter module (Message Formatter) that formats, formats, tags, and combines query messages with system messages, an external API communication module (AI API Communicator) that communicates with the API of the external AI system and is responsible for inquiries and receiving responses, and a system message management module (System Message Manager) that holds system message templates used for input to the model and incorporates instructions according to the context.With the query processing control module at the center, each module works together to perform effective interactive processing with the external AI system, making it possible to realize a configuration that allows for dynamic AI response generation, processing scalability, and high reusability. [Effects of the Invention]

[0036] Specifically, the system aims to comprehensively address the various issues faced by conventional technologies by introducing a unified and highly scalable architecture, an intuitive UI / UX, and a modular design. First, to eliminate the need for individual implementations according to the API specifications of each AI service, an API usage support system is introduced as an intermediate layer, allowing users to handle multiple services across multiple services using simple syntax. Furthermore, the system significantly reduces the burden of security management by enabling centralized management of authentication, log management, usage restrictions, and more. The system employs a structure that supports the integrated management and switching of multiple AI models, and is designed so that even non-engineers can operate it from data collection to model construction using a GUI.

[0037] Additionally, by shifting the architecture from a monolithic structure to a separated microservice, and designing query functions, chest processing, etc. as independent scalable units, load balancing and function additions have been made easier, improving the availability and scalability of the entire system. The data flow configuration processor, chest flow execution controller, and database are separated into layers, and clear responsibility design for each role has significantly improved maintainability. Data flow construction can also be completed by simply clicking and selecting chests, and LLM context management can be set up with just drag and drop, greatly improving user usability.

[0038] Furthermore, by eliminating the coupling between message generation and external API processing and restructuring the message helper as an independent module, it is now possible to separate processes such as message processing, template definition, and query generation / correction, allowing for individual modifications and expansion. The message helper is equipped with a structure that allows for the addition of processing logic using plug-ins, tag and variable embedding processing, and the ability to insert hooks before and after API transmission / reception, making it possible to scale independently as a lightweight module. In addition, a function has been implemented to visualize execution dependencies by linking the dependency chest and stream view.

[0039] The parallel / sequential processing structure has been designed in a unified manner, allowing users to grasp the entire flow on a single screen and improving debugging efficiency. A mechanism has been introduced that dynamically updates processing results on a stream in real time, and chest operations have been reconstructed into a unified flow, enabling reuse through common functionality. Chest processing branches can be dynamically redefined, and the structure allows processing content to be dynamically optimized in response to changes in external API specifications and the output results of dependent chests.

[0040] Query processing is implemented using a continuous workflow of "property generation → message creator → query function → generator," with each process robustly separated while maintaining a structure that ensures data consistency. Previously separate registration and execution processes have been integrated into a structure that unifies everything from UI operations to execution flows, and consistently processes the immediate reflection of registered content, consistency verification, tag completion, and more. Furthermore, the system handles continuous conversion and inverse conversion of local values ​​from global management of tag identifiers, enabling automatic bidirectional data mapping.

[0041] Regarding user interactions, selections and changes made in the UI are now instantly reflected in the data model, improving recovery from erroneous operations and operability. Simply clicking on a blank area on the screen allows you to access the message helper editor and edit the properties of related queries in one go, reducing construction time. Furthermore, a flexible branching design has been introduced that integrates loop processing such as map / yield into a single flow and enables linking with partial execution mode and recalculation wait processing.

[0042] This invention standardizes message data structures and comprehensively manages text / file carrier containers, data type validation, and history management, thereby safely and efficiently integrating external API integration and AI response processing. The design integrates messages, properties, and function processing information, and allows structured and unstructured data, tag / asset management, and extraction types to be understood and managed in one place, improving maintainability and scalability.

[0043] All query functions, including REST-API processing, notebook execution, embedded search, and web scraping, are integrated into a single configuration, enabling centralized management of configuration, development, and input / output consistency. The response extraction logic is implemented as a plug-in extraction engine that integrates 12 types of extraction conditions, such as isCodeExtract and isJSONExtract, achieving both maintainability and scalability. Furthermore, a matching mechanism between argument definitions and notebook structures has been implemented, enabling the appropriate association of properties and arguments for notebooks or APIs based on AI-generated statements and generated data. The overall flow, based on a set of messages constructed by sequentially merging properties, function outputs, tags, and arguments, can be managed as a consistent workflow, right up to the generation of the final message or function result. [Brief explanation of the drawings]

[0044] [Figure 1] 1 is a block diagram showing an overview of an API usage support system according to an embodiment of the present invention. [Figure 2] This is a block diagram showing an example in which the API usage support system shown in Figure 1 is applied to multiple external AI services and linked with them. [Figure 3] 3 is a block diagram illustrating the configuration of the API usage support system shown in FIG. 2. [Figure 4] FIG. 4 is a block diagram showing the configuration and functions of a chest flow configuration GUI processor in the API usage support system shown in FIG. 3. [Figure 5] FIG. 4 is a block diagram showing the configuration of a chest flow execution control unit in the API usage support system shown in FIG. 3. [Figure 6] FIG. 6 is a block diagram illustrating the configuration of a chest management screen in the chest flow execution control unit shown in FIG. 5. [Figure 7A] 7 is a flowchart showing the operation flow when a chest tab is selected on the chest screen shown in FIG. 6. [Figure 7B]7 is a flowchart showing a process when a chest body is selected on the chest management screen shown in FIG. 6. [Figure 7C] 7 is a flowchart showing a process when a region tab is selected on the chest management screen shown in FIG. 6. [Figure 8] FIG. 2 is a block diagram showing the configuration of a message helper and message processing according to the present embodiment. [Figure 9] 10 is a flowchart showing the structure of function data and a message list editing process according to the present embodiment. [Figure 10] 10 is a flowchart illustrating the process of registering and running a message helper and chest according to an embodiment of the present invention. [Figure 11] 10 is a flowchart relating to a flow generation and message tag editing process according to the present embodiment. [Figure 12] 10 is a flowchart illustrating a target chest process according to the present embodiment. [Figure 13] 10 is a block diagram showing the transition of data storage modes of a chest according to the present embodiment. [Figure 14A] 10 is a flowchart illustrating the selection of a field according to an embodiment of the present invention. [Figure 14B] 10 is a flowchart illustrating the selection of a field according to an embodiment of the present invention. [Figure 15] 10 is a flowchart relating to sequence registration according to the present embodiment. [Figure 16A] 10 is a flowchart relating to chest registration according to the present embodiment. [Figure 16B] 10 is a flowchart relating to chest execution according to the present embodiment. [Figure 17] 10 is a flowchart relating to chest recalculation according to the present embodiment. [Figure 18] FIG. 2 is a block diagram relating to message data and a message format according to the present embodiment. [Figure 19]3 is a block diagram showing the configuration of function processing information, messages, and properties according to the embodiment. FIG. [Figure 20A] FIG. 2 is a block diagram of a query function in a REST API format according to the present embodiment. [Figure 20B] FIG. 1 is a block diagram of an example REST API query according to an embodiment. [Figure 21A] FIG. 10 is a block diagram of message pre-processing according to an embodiment of the present invention. [Figure 21B] FIG. 10 is a block diagram of an API output process according to the present embodiment. [Figure 21C] FIG. 2 is a block diagram of common properties of message processing according to an embodiment. [Figure 21D] FIG. 1 is a block diagram of a process for extracting data from an AI-generated sentence according to an embodiment of the present invention. [Figure 21E] FIG. 10 is a block diagram of a process for extracting text information from a file according to the present embodiment. [Figure 22A] FIG. 10 is a block diagram of a query process that utilizes a message helper list for yield processing according to an embodiment. [Figure 22B] 10 is a flowchart illustrating a system query process according to the present embodiment. [Figure 22C] 10 is a flowchart illustrating roles involved in a system query process according to the present embodiment. [Figure 23A] FIG. 2 is a block diagram showing the functions of an LLM query process according to the present embodiment. [Figure 23B] FIG. 10 is a block diagram of an example of an LLM query process. [Figure 23C] FIG. 2 is a block diagram illustrating a function of a data query according to the embodiment. [Figure 23D] FIG. 10 is a functional block diagram of an embodiment of a data query process according to an embodiment. [Figure 24] 10 is a flowchart illustrating a conversion process of an LLM output statement according to the present embodiment. [Figure 25] 10 is a block diagram of functions related to message processing of file information according to the embodiment; [Figure 26] FIG. 10 is a block diagram relating to an argument processing function. DETAILED DESCRIPTION OF THE INVENTION

[0045] In the following description of the present invention, the term "unit" refers to a state in which a computer's central processing unit (CPU) or graphics processing unit (GPU) loads a necessary computer program and functions. Because both CPUs and GPUs are chips consisting of integrated circuits, these units are components of a product invention. Therefore, the present invention is a product invention. In this sense, the term "function" used in this specification can be interpreted as "unit" as appropriate. Furthermore, the present invention uses a graphical user interface (GUI) to visually display objects to the user and prompt the user to select and operate them, thereby making the complex processing performed by an artificial intelligence (AI) model easier for the user to understand and helping them organize their thoughts. Therefore, it is significantly different from simply having a machine do something that a human mind can do. Furthermore, in this specification, the term "database unit" refers to a unit in which each piece of information is linked (associated) with other pieces of information and stored, and information can be extracted and used based on these associations. In other words, it is a data structure that has the properties of a collection of multiple tables. The AI ​​system usage support system of the present invention is made up of multiple units (components) working together, with each unit located between the AI ​​system's API and the user. The multiple units work together via a computer network. Due to the nature of the AI ​​system, services are provided to users via the Internet. Overall structure

[0046] This application programming interface (API) support system is a platform that allows users to visually construct data flows and utilize data processing and artificial intelligence (AI) models. It is a computer-implemented API support system that runs on a computer system with multiple processors and memory and supports complex data processing in conjunction with the API of an AI system. It primarily consists of a chest flow configuration GUI processor, a database unit, and a chest flow execution controller. The chest flow configuration GUI processor allows users to visually create, connect, and select multiple data processing nodes (chests) on a canvas, generates a flow structure that defines the data flow between the chests, and enables users to define the processing order and dependencies for each chest, providing a graphical interface (GUI). The database unit stores multiple tables containing at least account information, project information, chest details, connection relationship information between chests, message processing support helper information, AI model information, uploaded data file information, script data, and data flow identification information. The chest flow execution controller performs input and output with the database unit based on sequential operation requests from the GUI, creates, deletes, places, and updates chests, controls data flow, and saves and updates dependencies, enables the construction of a data flow by graphically selecting an existing chest when placing a new chest, sequentially executes the processing steps associated with the chest, constructs and sends messages to be sent to the API of an external AI system, obtains corresponding responses, associates them with the chest, and executes the processing.The data flow constructor, database unit, and chest flow execution controller work together via a network, making it possible to construct and execute complex processing flows including interactions with external AI systems based on visual and sequential input by the user.

[0047] The following describes the chest flow configuration GUI processor. The chest flow configuration GUI processor provides a user interface that allows users to intuitively construct data flows and place and connect data processing nodes (chests). It also provides functions for user authentication and account management, including login and logout and account information management, as well as the creation, editing, and deletion of projects and the management of data flows within projects. It also provides functions for drag-and-drop chest placement, setting up inter-chest flows (data flow) (chest placement and connection), viewing data in stream format, and displaying results (data visualization). It also provides functions for users to upload data files and make them available within chests, as well as the upload and download functions for creating, editing, and deleting AI model helpers.

[0048] Tables for managing the main data of the application are defined in the database. This enables data persistence and efficient access. The main tables are as follows: (1)users: Manage user account information (username, password, storage limit, etc.). (2) projects: Manages information about projects created by users (such as names, notes, tags, and chest limits). (3) unified_chests: Manages detailed chest information (title, location, type, query, response, etc.). (4) chest_flows: Manages flows (data flow) between chests and links source chests with target chests. (5) message_helpers: Manages information about helpers that assist in message processing. (6) ai_model_helpers: Manages information about AI models (model name, properties, owner, etc.). (7) files: Manages information about files uploaded by users (file names, paths, tags, etc.). (8) notebooks: Manages notebook execution data and identification tags.

[0049] The Chest Flow Execution Controller will be explained below. The Chest Flow Execution Controller processes requests from the Chest Flow Configuration GUI Processor, and implements database interactions and business logic, fulfilling the central functions of the present invention. Specifically, it has the functions of secure user management and session maintenance (user authentication and session management), the functions of managing information such as users, projects, chests, and files in a database (database operation), and the functions of creating, updating, and deleting chests and controlling data flow (business logic implementation). It also has the functions of generating and processing messages using a message helper (message processing), and saving, retrieving, and managing files (linking with file storage).

[0050] Preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings. These embodiments are merely examples for facilitating understanding of the invention, and unless otherwise specified, do not limit the present invention. In this specification and drawings, elements having substantially the same functions and configurations are designated by the same reference numerals to avoid redundant explanation, and elements not directly related to the present invention are not shown.

[0051] FIG. 1 is a block diagram showing an overview of an API usage support system 2 according to an embodiment of the present invention. In FIG. 1, user 1 refers to a user terminal device, which may be a personal computer, tablet, smartphone, or the like. The API usage support system 2 is a system according to the present invention, positioned between user 1 and an external AI service 4, and supporting the use of the API 3 of the external AI service 4. The external AI service 4 may include, for example, a generative AI service such as ChatGPT provided by OpenAI, as well as other external AI services. While the API usage support system 2 is preferably configured primarily on a server computer on the Internet, parts of it may also be implemented as applications on user 1's terminal.

[0052] This specification assumes that the API usage support system 2 may be implemented separately on the server side and the user side, but which functions are provided on the server side and which functions are provided on the terminal side are a matter of design choice and no particular limitations are imposed. Therefore, this specification describes the API usage support system 2 as being configured as a unified system in which the server-side functions and user-side applications work together.

[0053] FIG. 2 is a block diagram showing an example in which the API usage support system 2 shown in FIG. 1 is applied to and linked with multiple external AI services. FIG. 2 shows a configuration in which a user 1 uses multiple external AI services 400, 401, and 402 and an external search server 5 via the Internet 6. By using the API usage support system 2 of the present invention, the user 1 can visually build external API usage models 700, 701, and 702 customized to suit each user's objectives and needs through a series of processes, including data collection, learning, and evaluation. These customized API usage models may be referred to simply as "models" in this specification.

[0054] FIG. 3 is a block diagram illustrating the configuration of the API usage support system 2 according to the embodiment of the present invention shown in FIG. 2. In FIG. 3, the API usage support system 2 is mainly composed of the following three elements: a chest flow configuration GUI processor 8 (hereinafter simply referred to as the chest flow configuration GUI processor 8), a chest flow execution controller 9 (hereinafter simply referred to as the chest flow execution controller 9), and a database 10. The chest flow configuration GUI processor 8 is responsible for the user interface of the system, providing login / logout functions and account information management functions. Furthermore, it also has a function that allows users to visually operate and manage data processing nodes called "chests" when creating and editing projects and constructing data flows.

[0055] Meanwhile, the Chest Flow Execution Controller 9 processes various requests from the Chest Flow Configuration GUI Processor 8 and, in cooperation with the Database 10, centrally manages various information such as user information, project information, chests, and files. The Chest Flow Execution Controller 9 dynamically controls data flow through the creation, update, deletion, and placement of chests. Additionally, it can perform server-side calculations such as arithmetic processing by utilizing the microservices 11 built into it. Furthermore, the Chest Flow Execution Controller 9 can connect to external large-scale language model APIs (LLM APIs) and web query APIs by using the query function 12. This connection is realized through external AI services 4, such as the ChatGPT API provided by OpenAI or the Claude API provided by Anthropic.

[0056] Figure 4 is a block diagram showing the configuration and functions of the chest flow GUI processor 8 in the API usage support system 2 shown in Figure 3. In Figure 4, the chest flow GUI processor 8 is primarily responsible for providing a user interface (UI) and visually displaying data flows for the user 1. The chest flow GUI processor 8 is composed of (1) a user information management function 13, (2) a data flow management function 14, (3) a chest management function 15, (4) a data display function 16, (5) a data upload / download function 17, and (6) an AI model management function 18. The user information management function 13 manages login / logout and account information based on information from the user terminal 1. The data flow management function 14 manages data flows within a project and controls the selection status of existing chests. The chest management function 15 allows intuitive drag-and-drop operations such as creating, placing, and editing data processing nodes called "chests," which will be described later, and allows visual configuration of flows between chests. The data display function 16 allows users to view data in stream format and display processing results. The upload / download function 17 allows users to upload or download data files and use them within the chest. The AI ​​model management function 18 allows users to create, edit, and delete AI models on the chest flow configuration GUI processing body, supporting user model control.

[0057] Figure 5 is a block diagram showing the configuration of the chest flow execution controller 9 in the API usage support system shown in Figure 3. In Figure 5, the chest flow execution controller 9 is a core component that receives and processes requests from the chest flow configuration GUI processor 8 shown in Figure 4, and is responsible for implementing business logic through cooperation with a database (not shown).

[0058] The Chest Flow Execution Controller 9 manages user information using the user management function 19, and maintains and manages login status, authority information, account settings, etc. The session maintenance function 20 also maintains and controls the user's login session, ensuring the continuity of the data flow. These functions enable the Chest Flow Execution Controller 9 to flexibly and continuously manage the data flow for each user.

[0059] Furthermore, the chest flow execution controller 9 has a business logic implementation function 22 (a core function for performing operations such as creating, updating, arranging, and deleting "chests" described later), as well as controlling and manipulating data flows, and operates through a database linkage function 21. The message processing function 24 also makes use of a message helper 23 to generate and process messages from dependent chests and to send queries to external APIs. The file storage linkage function 26 then links with file storage 25, making it possible to manage the saving, retrieval, and deletion of data files. With these functions, the chest flow execution controller 9 plays a role in integrating and supporting the linkage processing between chests, communication with external APIs, and file management.

[0060] FIG. 6 is a block diagram illustrating the configuration of the chest management screen in the chest flow execution controller 9 shown in FIG. 5. FIG. 6 shows an example of the configuration of a chest 30 visually displayed on a main screen 31 on a user terminal. This main screen 31 is broadly divided into a field section 32 and a stream section 33. A visually formed first chest 3000 is displayed as an object in the field section 32 and can be operated on the field. When the first chest 3000 is executed, a second chest 3001 or a third chest 3002 is deployed accordingly. Furthermore, when the second chest 3001 is opened after the first chest 3000 is executed, the first chest 3000 and the second chest 3001 are grouped and deployed as a first sequence block 3010 (yield type or split type). Child chests 3011, 3012, 3013, and 3014 are generated in a stored format in this first sequence block 3010. Furthermore, when a map-type second sequence block 3020 is expanded with the first sequence block 3010 as a group (base), child chests 3021, 3022, 3023, and 3024 are similarly stored and generated inside.

[0061] On the screen of the stream section 33, when the user selects a first chest 3000, a second chest 3001, and a second sequence block 3020 as a group, the corresponding information is displayed as a stream chest. Information about the first chest 3000 is displayed in the first stream chest 3002, and information about the second chest 3001 is displayed in the second stream chest 3003. Furthermore, information about child chests 3021, 3022, 3023, and 3024 are displayed in order in the third to sixth stream chests (3004 to 3007). This makes it possible to visually and intuitively grasp the chest configuration in the field section and the data flow and processing content in the stream section.

[0062] Fig. 7A is a flowchart showing the operation flow when the chest tab 34 is selected on the chest screen shown in Fig. 6. Fig. 7A explains operation functions common to all chests 30. By calling up the tab menu of the chest tab 34, the user can select various functions.

[0063] When "Delete Chest" is selected from the tab menu (S10), the following process is executed: (1) The system checks whether or not there are any dependent files in the chest (S11). (2) If it is determined that there are no dependent files, the chest is deleted (S12). (3) On the other hand, if there are dependent files, the deletion process is canceled (S13).

[0064] When "Edit Chest" is selected from the tab menu (S20), the following process is executed. (1) It is determined whether the selected chest is a sequence (S21). (2) If it is determined to be a sequence, the state (whether it is a recalculation mode or not) is then determined (S22). (3) If the state is in the non-recalculation mode (normal), the unlimited edit form is applied (S23). (4) Furthermore, if the chest was generated as an automatic sequence chest item, the reference group is reset (S24) and the chest flow is updated (S25), and the editing is completed (S26). (4) Even if the chest was not generated automatically, the unlimited form proceeds directly to the chest update process (S28), and the editing is completed (S26). (5) If it is determined that the state is not a sequence or not a normal state, a restricted edit form is applied (S27), followed by a chest update process (S28), and then the edit is completed (S26).

[0065] If "Move Chest" is selected in the tab menu (S30), DD (Drag & Drop) mode is enabled, and when the user moves a chest, the position change process is performed.

[0066] When "Sequence Deployment" is selected in the tab menu (S40), the corresponding sequence is deployed, and then the position of the containing chest is corrected.

[0067] Fig. 7B is a flowchart showing the processing when a chest body is selected on the chest management screen shown in Fig. 6. In Fig. 7B, when a chest body, which is the main body of each chest, is selected by the user (S50), the system determines whether to select a "chest" or a "sequence" depending on the type of chest, checks the current selection status, and if it has not yet been selected (or if there are stages in the selection status, moves to the next stage), a chest selection process or a sequence selection process is executed (S51). If it has already been selected, the chest selection or sequence selection is deselected (S52).

[0068] When a flow line connecting multiple chests is selected, the system treats this as flow editing (S60). At this time, the user can register or edit condition keywords, and then a process is performed to determine whether editing is possible (S61). If it is determined that editing is possible, a flow update process is executed (SS62). If it is determined that editing is not possible, the editing process is stopped (SS63).

[0069] When the user selects the sequence chest execution process (S70), the system either specifies partial execution for each child element included in the sequence chest (S71) or executes the entire sequence chest all at once (S72).Then, the system transitions to the partial execution process according to the specification (S73).

[0070] FIG. 7C is a flowchart showing the processing that occurs when the Region tab is selected on the chest management screen shown in FIG. 6. In FIG. 7C, when the user selects the Region tab (S80), the system transitions to region selection mode (S81). In this mode, the user selects a comprehensive chest (S82). If a region move is then selected (S84), the position of the region is updated by drag-and-drop (S85), and the position of the comprehensive chest is also updated. If a region deletion is selected (S88), a determination is made as to whether or not there are any dependent chests for the region to be deleted (S89). If it is determined that no dependent chests exist, the region deletion process is executed (S90). On the other hand, if it is determined that a dependent chest exists, the deletion process is canceled (S91). The above-described FIGS. 7A to 7C systematically show the flow processing for operations common to all chests on the chest management screen shown in FIG. 6, namely, deletion, editing, moving, sequence deployment, and region operation.

[0071] FIG. 8 is a block diagram showing the configuration of the message helper and message processing according to this embodiment. This diagram explains the flow of property processing and message tag processing in the flow generation process executed when creating a target chest, from the generation and update process on the source chest side in chest creation / update 41. In FIG. 8, chest 30 indicates the source chest, and the processing configuration on the chest side is expressed as a flowchart. Here, indexes 52 and 53 are indexes for identifying function data defined in the message helper in chest 30. Conditions 54 and 55 indicate the conditions for executing each function, and functions 56 and 57 indicate the function call statements that execute that processing. In addition, property box 60 stores property definitions for each function (properties 61 and 62), and message tag list unit 63 stores message tag lists 64 and 65 associated with each function.

[0072] 8 are integrated by the property integration unit with identifiers (S92), resulting in the generation of message helper properties corresponding to the message helpers 40 (S93). Meanwhile, the message tag list 63 is integrated through a message tag integration process (S94), resulting in the generation of a tag inventory list (S95).

[0073] Furthermore, the chest property values ​​are updated by the chest editor 45 (S96). Similarly, the message helper edit process 47 executes the message helper property update process (S97), and also performs property reintegration process as needed (S98). These update processes update the message helper properties and tag inventory list to their latest state. After that, the message tag information stored in the tag inventory list is converted into tag definition information for the flow by the edit form generation process 50 (S99), and becomes editable by the user in the edit 51. However, this editing is actually only possible in recalculation mode; in normal mode, the value updated in the chest is automatically passed to the target side as the message tag value.

[0074] 9 is a flowchart showing the structure of function data and the message list editing process according to this embodiment. This diagram shows the structure of function data 79 included in the function data list 78 and the processing flow from generating a property set to adding it to the message list 74.

[0075] First, the method for storing function data 79 in the function data list 78 and the processing sequence are described below. (1) Each function integrates its unique function information 70 with context information of the property execution unit 71 provided by the executor or the like to generate a property set (S100). (2) The message creator then integrates the generated property set, the processing result information up to that point, and the processing result information of the preceding chest, and processes it into data that can be converted into the message list 74 format (S101). (3) Next, the query function uses this message list format data to execute API query processing on large-scale language models (LLMs), web queries, microservices, etc. (S102). The processing results are received by the generator and finally processed as message data, generating a last message (S103). (4) This last message is again added to the message list 74 and passed on to the next processing step (S104).

[0076] The function data list 78 stores multiple pieces of function data 79, 80, 81, and 82 in sequence format, with corresponding execution conditions 83, 84, 85, and 86 defined for each. The execution of each piece of function data is determined based on the message information and property information of each piece to see if the conditions are met, and only steps that meet the conditions are executed sequentially.

[0077] FIG. 10 is a flowchart showing the processes involved in registering and running the message helper 40 and chest 30 according to this embodiment. First, the message helper 40 registers a function data list (S110). The properties included in the registered function data list are integrated through an identifier globalization process (S111) and generated and registered as message helper properties 90. When a message helper is selected, the associated chest definition is imported and edited through a chest modification form 91, and the updated content is registered as message helper properties 92 (S113). Message tags are also integrated through the identifier globalization process and generated and registered as tag inventory 94. Similarly, tag definitions are imported when the message helper is selected, and the tag information updated through the chest modification form 91 is registered as tag inventory 93 (S116).

[0078] The bottom part of Figure 10 shows the processing flow when a chest is executed. During execution, the property and message tag information sent to the execution unit 97 is extracted and registered in the function result (S119). This extracted data is sent to the function processing and registered as the processing result in the function data list 95. When the processing is complete, a final message is generated (S117), and this final message 96 is registered in the executor 97 (S118). The registered message is finally added to the message list 99 and passed on to subsequent processing.

[0079] FIG. 11 is a flowchart of the flow generation and message tag editing process according to this embodiment. In FIG. 11, chest generation is first performed (S121). This generates a preprocessing flow for the source chest, and then the process transitions to an editable state (S123). In this editable state, tag definition form information generated by the correction form generation process is passed to the message tag (S126). In normal mode, this information is passed to the subsequent process as is along with default values. However, in recalculation mode, tag editing is possible at the generation stage, and the tag is reflected in the recalculation process before proceeding to the subsequent process. If editing is performed, the information is added as tag information to the source execution information (S124), and then converted into message data before being sent to the target chest (S125). The converted data is configured in the message tag:identifier map format, and a global identifier is assigned (S127). This message data is passed to the next process, message data processing (S128).

[0080] FIG. 12 is a flowchart of the target chest processing according to this embodiment. This diagram illustrates the process flow from the flow update processing (S130) to the target chest processing (S131). The target chest 141 in the diagram is composed of the following five pieces of information: (1) index information 146 (e.g., first index 147, second index 148), (2) execution conditions 149 (e.g., first execution conditions 150, second execution conditions 151), (3) function definition information 152 (e.g., first function definition 153, second function definition 154), (4) property definition information 155 (e.g., first property definition 156, second property definition 157), and (5) message tag definition information 158 (e.g., first message tag definition 159, second message tag definition 160). As a result of processing based on these definitions, message data 161 is generated and output as a first execution result 162 or a second execution result 163. This message data 161 has the necessary message tag added (S137), undergoes identifier map conversion and is expanded as a global identifier (S138), and is finally integrated as final message data and stored in the target chest 130 (S139).

[0081] The function list processing is executed by a chest execution unit 141 generated by a generation execution unit 140. This chest execution unit 141 has, as elements, (1) property sequence message tag item 142 and (2) value tag list 143 as information defined by the property processing, (3) message list sequence data 144 as message-related data, and (4) response list sequence message data 145 as the function execution result.

[0082] The flow of the message data generation process will be explained below. First, source chest information with message tags is sent in message data tag identifier map format (S132). This is converted into message data format (S133) and (3) configured as conforming message data (S134). Among these, message tags with global identifiers are checked against predefined tag definition information 158 and converted into message tag items based on the tag definition. The converted information is stored in a localized form in message list sequence message data 144 (S135). Furthermore, tag elements that do not modify the message and are treated as variables in function definition information 152 are separated by value tag extraction processing (S136) and stored in value tag list 143.

[0083] FIG. 13 is a block chart showing the transition of data retention modes for chests according to this embodiment. In this diagram, when a chest 30 is selected, the type information box 36 in the chest group 170 is sequentially switched. By repeatedly selecting a chest 30, the unselected state 37 changes to a selected state 38, and the selected state 38 changes to a base selected state 39. By clicking again, the chest returns to the unselected state 37. This selection operation is immediately reflected in the data in the chest group 170, and the type information is updated. Furthermore, when the unselected state 37 is reached, the previous data is discarded.

[0084] The data model 171 of the chest group 170 stores the selection status of the chest 30 and message order information. The index information is automatically updated based on the operation order, but can also be manually modified as a property. In a given project, the group information in the selected state 38 corresponds to the chest group 170. Selecting "Generate Chest" 172 creates a chest flow 173 with the selected chest as the source and the newly generated chest as the target. The relationship between groups is recorded as a persistent relationship definition object. The chest flow data model 174, which stores this relationship information, includes basic group information as well as information about the source and target chests. Furthermore, selecting "Execute Chest" 175 activates the message generation logic 176, which obtains the final message information 177 of the source chest. Tag information and other information are added to this information and converted into message data 181. Meanwhile, in the map operation, a map-type chest is used as the primary reference source for the generated chest. At this time, for each target sequence child chest, it is determined whether a base type chest is used as a message, and an extraction operation 178 is performed. Next, sequence processing 179 is performed, and individual reference source chest information is provided for each child chest. The message data 181 in the message data array 180 thus generated is sequence-sorted based on the index information to form a message data array. This array is stored as a history message 182 and is used for execution processing in the target chest 183.

[0085] FIG. 14 is a flowchart illustrating the field selection operation according to this embodiment. In FIG. 14A, field selection begins by clicking a blank field (S150). This displays a field menu, allowing field selection. When "Create a New Chest" is first selected (S151), a message helper list is obtained from the Chest Flow Execution Controller (S152), and a message helper selection menu is displayed. A message helper object is then imported (S154). When a helper is selected, property JSON extraction (S156) is performed, and the query editor is launched. This editor allows editing of the following items: (1) Location Information 190, (2) Properties 191, (3) Query 192, (4) Query File 193, (5) Automatic Sequence Chest Item Generation 194, and (6) YieldTestNum 195. The edited information is sent to the chest flow execution control body as a property transmission (S158), and then the message creator is called (S159), a history message is obtained from the chest group information 196, and it is integrated with the transmitted property to generate a message to be sent to the LLM. After that, it is determined whether the chest type is a sequence, and if it is, it proceeds to sequence registration (S161), and if it is not, it proceeds to chest registration (S162).

[0086] When recalculation standby mode is selected (S163), the system enters recalculation standby mode and its initial processing begins (S164). Subsequently, when recalculation execution is selected (S165), the recalculation range is determined based on the range selection information from the standby chest group 197 or the group information remaining after the previous standby group processing, and the standby group is determined (S167). Next, management processing related to recalculation, such as dependency analysis, is performed, and the chest group to be recalculated is determined (S170), and the target chest group is extracted. Then, group recalculation is performed for these groups (S172). At this time, if sequence execution is performed (S172A), sequence affiliation and chest registration are performed (S173), partial execution processing is applied (S174), and the chest is executed (S175). Meanwhile, for single chests with a reduce specification, they are executed as is. After the recalculation, when the group recalculation is completed, a determination of remaining groups is made (S176), and if there are remaining groups, the process returns to S167 again, and if there are no remaining groups, the execution mode ends (S177).

[0087] In Figure 14B, when template registration (recalculation mode) is selected (S178), the template range is determined based on the group information at that time (S179). After that, when naming information is entered from the form (S180), a template is generated (S181), and it is registered (S182), completing the template registration process. Next, when template placement is selected (S184), the template position is determined by clicking on the screen or other means (S185), the template is deployed there, and the template chest is registered (S186). The system then transitions to recalculation standby mode (S187), and enters the recalculation standby mode state.

[0088] When region creation mode is selected (S189), the mode switches to polygon designation mode on the field, and the cursor event configuration is changed so that vertex checks (S191) become possible. When the starting point is clicked again to close the polygon (S192), the range is confirmed, and a determination is made for each chest as to whether it can be made into a region (S193). Chests determined to be within the region are registered as part of the region (S194), and the mode finally ends (S195).

[0089] 15 is a flowchart of the sequence registration process according to this embodiment. In FIG. 15, when executing sequence registration (S200), first, it is determined whether or not to generate an automatic sequence chest item (S201). If this determination determines that "automatic generation is enabled," the process transitions to post-processing in recalculation standby mode (S202), and the process ends there (S203). On the other hand, if it determines that "automatic generation is disabled," the subsequent process branches into three types of sequence processing (map, yield, split) and proceeds (S204). (1) Map 200: Based on the chest information extracted as the base sequence, the chests belonging to the sequence are registered in the chest registration section 203 (S205). (2) Similarly, depending on the yield 201:testNumber, the chest is registered in the chest registration section 203 (S206). (3) Split 202 (see below). When the map process is complete, a determination is made as to whether or not recalculation standby mode is required (S207). Similarly, a determination is made as to whether or not recalculation standby mode is required for yield processing (S208). Subsequently, a call for sequence expansion and preprocessing for partial execution mode are performed (S210). After this, the process waits for user input or transitions to re-execution mode, but in either case, the partial execution mode remains unchanged at this stage.

[0090] If a partial execution (range) selection is made (S215) and the sequence display screen is left without any selection (S216), unreached processing is performed (S217) and the process ends (S227). If the range selection is valid, a determination is made (S221) as to whether the sequence is "full execution" or "partial execution" based on the user selection information. If partial execution is selected (S222), partial execution post-processing is performed (S224), each chest transitions to execution in sequence (S226), and then partial execution mode is canceled. If full execution is selected (S223), all chests transition to execution (S226). Furthermore, if a SHOT (range) selection is made simultaneously with partial execution (S215) (S218), a SHOT reference registration is performed (S219), and this reference is referenced in the subsequent execution processing (S222) and reflected in the partial execution post-processing (S223).

[0091] Split 202 also branches according to the processing flow. First, a determination is made as to whether or not the recalculation standby mode is in effect (S209), and then the parent chest (sequence chest) is executed (S212). The resulting output is split based on the response split logic (S213), and based on each output, the executed chest is generated as a new sequence child chest (S214).

[0092] FIG. 16 is a flowchart of the chest registration process according to this embodiment. In FIG. 16, the chest registration process is first started (S230). Next, it is determined whether the current processing mode is the recalculation standby mode (S231). If it is determined that it is the recalculation standby mode, post-processing corresponding to the recalculation standby mode is executed (S232), and the process ends (S233). On the other hand, if it is determined that it is not the recalculation standby mode, the process proceeds to the chest execution process (S234), and then the process ends (S235).

[0093] Fig. 16B is a flowchart illustrating the detailed flow of the chest execution process in Fig. 16. In Fig. 16B, if the recalculation standby mode is not selected (S232), the chest execution process is similarly executed (S234), and then the process ends (S235).

[0094] 17 is a flowchart showing the recalculation process for a chest according to this embodiment. In FIG. 17, the recalculation process for a chest is started (S240). Next, the process branches depending on the type 205 of the chest.

[0095] For map type 200 and yield type 201, it is determined whether an automatic sequence chest item is generated (S241). If it is automatically generated, for the map type, "(sequence belonging) chest registration for base sequence" is executed based on the base sequence information (S242). For the yield type, "(sequence belonging) chest registration for test number" is executed based on the test number information (S243). If it is not automatically generated: The process proceeds directly to "sequence expansion call (partial execution mode pre-processing)" (S244). After automatic registration, the process similarly continues to the sequence expansion process of S244.

[0096] In the case of Split type 202, the chest is executed first (S245). Next, the response is split using the response split process (S246). After that, a sequence child chest (executed) is generated based on the split data (S247). In the case of Reduce type 204, no special split process is performed, and only the chest is executed (S248).

[0097] 18 is a block diagram showing the configuration of message data and message format according to this embodiment. The message data 210 shown in the figure is a basic data format that forms the basis for information distribution within this system, and is optimized specifically for text data that handles AI output.

[0098] Message data 210 is saved as the final message (last message 212) in a chest 211, and is aggregated as the execution result of a group within a project, that is, a flow process. These messages are stored as components of a message data array 213 and are passed on to the next process.

[0099] Each piece of data 216 included in the message data 210 is managed as an array of two types of containers: a message carrier 214 (a container for storing text-type information (plain or structured format)) and a file carrier 215 (a container for handling file information on storage). The type of information handled by the message carrier 214 is strictly defined by a data type 217, making it possible to safely link AI response data with other APIs. Each piece of data 216 is handled appropriately by authenticating this data type 217. The file carrier 215 is a container for handling file information on storage, and contains file index information and meta information for calling data from file storage 218.

[0100] The message format 219 corresponds to the chest form of the user interface 220 in the chest flow configuration GUI processor, and has a function for two-way conversion with the message data 210. This format makes it possible to maintain query input from the user and response information from the API in a format that can be appropriately displayed and edited on the UI.

[0101] 19 is a block diagram showing the configuration of function processing information, messages, and properties according to this embodiment. Function processing information 230 shown in the figure is configured around messages 231 and properties 232, and visually shows what elements are integrated into each item.

[0102] Text 233 indicates the configuration of text information integrated into function processing information 230, and its subordinate text structure 234 is composed of structured text 235 and plain text 236. Structured text 235 is composed based on code blocks and stylistic patterns extracted from AI responses. Information formats (structure types) classified as this structured text include URL 237, keywords 238, CSV 239, HTML 240, notebook execution data (noteExecutionData 241), JSON-formatted text 242, vector embedding (Embedding 243), and list 244. Plain text 236 is general text data and includes types 245 such as AI responses 246, user queries 247, and file contents 248.

[0103] Assets 249 are persistent information stored in a database and are integrated with messages 231 via properties. Types of information 250 that can be registered in assets include prompts 251, fine-tuned models 252, embeddings 253, files 254, API setup information 255, message helpers 256, and main arguments 257.

[0104] Other data formats 257 include formats that require special processing, such as argument information 258 and files 259. These require special processing mechanisms 261 for argument processing and file processing. The last non-text data 260 is explicitly stated to be usable within the system only in the corresponding dedicated format.

[0105] FIG. 20A is a block diagram showing the configuration of a query function in REST API format according to this embodiment. In FIG. 20A, a general REST API processing data format 270 is extracted as structured text 272 and data 273 that conform to a query JSON type 271, and function processing is executed based on the extracted data (S251). API access information required for function processing includes a URL, HTTP method, parameters, a body, and an API key, which are stored in properties as access data 274. Function output formats include data such as JSON text format 275 and structured data 276 (assumed to be stored in argumentation or file generation processing). These outputs are converted by a response conversion unit 277 into one of the following formats: a message format (S252), a plain text format (S253), or a user-oriented response format (S254).

[0106] FIG. 20B is a block diagram illustrating an example of a REST API query according to this embodiment. The main query function in this diagram is an API request query function 279, which is configured to issue queries to various external services and functions. A notebook execution query 280 receives a query in notebook execution data format 281 as input and receives a response in the same format 281. This corresponds to processing in a notebook execution environment such as Jupyter Notebook.

[0107] The embedding similarity query 283 takes a query string 284 and an OpenAI message data array 285 (such as a past conversation history) as input. Based on these, it returns a vector space of similar chunk arrays and their scored text 286. This function is used for similarity search and information reuse. Google search and scraping queries, or Google search queries 290 and Google search scraping queries 291 (which take keywords 292 as input and return results in Google data format 293), and Google scraping queries 294 (which take URL type 295 as input and return scraping results in Google search data format 293) are also supported and are used to extract information from external web resources and obtain search results.

[0108] FIG. 21A is a block diagram showing the configuration of message preprocessing according to this embodiment. Here, we will explain the flow of various preprocessing steps that are executed prior to message generation by AI. The message generation function 300 performs processing to extract necessary information from the input message. The OpenAI format conversion 301 converts the extracted information into message data in OpenAI format. The OpenAI extraction tool 302 extracts information in JSON format that conforms to the OpenAI tool specifications. The keyword / URL integration 303 extracts keywords and URLs from the message, and if there are multiple, integrates and formats them into a single string. The execution data generation 304 generates information for notebook execution from the extracted JSON information. The argument matching 305 matches and extracts data that matches defined conditions from the argumentized information.

[0109] The following processes are performed to convert the data into a standard format. First, Standard AIQ Conversion: R Message 306 converts the extracted and converted data into a standard AI query (AIQ) format and, if necessary, converts it into an R message (reference message) format. Then, Conformance Standard APIQ Filter: R Message 307 filters and extracts only data that matches the standard API query format.

[0110] The following processes are performed when converting arguments and outputting execution data. First, Matching Arguments 308: The filtered information is processed to create arguments. Then, Execution Data Generation 309: Finally, execution data that can be used in notebooks and APIs is generated. Finally, Matching Arguments 310: The necessary arguments are re-formatted and converted.

[0111] 21B is a block diagram showing the configuration of API output processing according to this embodiment. Here, the flow of converting and processing the execution results of various query functions into a format that can be used within the system as message data is shown.

[0112] The generation function 313 is a core processing unit that extracts and converts necessary information from the output results of the query function, and performs integrated output conversion processing. Conversion units according to the query type perform appropriate conversion depending on the type of data to be processed. These units include the OpenAI message conversion unit 314, which converts OpenAI-format responses into the system's standard message format; the search result conversion unit 315, which formats and converts the search results of web queries; the execution data conversion unit 316, which formats the execution results obtained from notebook queries into data formats such as JSON; and the OpenAI function call conversion unit 317, which converts the results of function calls or JSON queries via the OpenAI API into the system format.

[0113] The message format storage process involves: Data Pass Process 318: storing output data that does not require conversion as message data as is; Standard AIQ Conversion / R Message Generation 319: generating information to be output as an AI query (AIQ) as a standard format response message; and Standard APIQ / R Generation 320: generating output that conforms to the API query format in a standard API response format.

[0114] In the specialized processing unit, search result generation 321: Search results to be presented to the user are formatted and generated from the output of the search query, and execution data generation processing 322: Execution data that can be applied to API integration or the next step is generated from the processing results of the notebook, etc.

[0115] 21C is a block diagram showing the common property configuration for message processing according to this embodiment. This diagram shows the system of common properties for defining which message data is used or referenced in flow processing between chests and API response processing.

[0116] Message data range 325 is a property that defines the target range of the output (message data) up to the previous process. For example, it could be the range selected from the immediately preceding chest, the output group of the previous stage, or multiple flow outputs. A typical message selection property is function message selection 326 (a property for selecting a message obtained from a function that has already been executed in the chest). This property can be accompanied by detailed index information 329 of the function index, message data index, and message index.

[0117] The prompt message selection 327 specifies the response obtained from the previous query processing. This property allows you to select a retrieval mode 330 such as "all: all messages," "first: first message," or "last: last message" from the message sequence.

[0118] The result message selection 328 specifies the final output resulting from the function execution, typically used as a message to be passed to subsequent processing or the next chest.

[0119] 21D is a block diagram showing the configuration of the data extraction process from AI-generated sentences according to this embodiment. This diagram shows the process flow and functional modules for extracting data with a specific format or structure from text output by an LLM (large-scale language model). The response text extraction unit 333 is a central processing module that analyzes the natural language text output from the LLM and detects and extracts various data structures.

[0120] The main functions of the extraction process are listed below. (1) Code extraction determination 334: Detects code blocks (e.g., python) in the text and extracts them as code snippets. (2) CSV / Main CSV Extraction Decision 335: Recognizes structured tabular data based on delimiters (commas, tabs, etc.) and extracts CSV or main matrix information. (3) JSON extraction determination 336: JSON format strings in the text are detected and extracted in a parsable state. (4) URL extraction decision 337: A URL is detected using a regular expression and extracted as link information. (5) Notebook-related JSON extraction determination 338: From the extracted JSON information, data having a schema related to Jupyter Notebook, etc. is identified and extracted. (6) Keyword extraction and determination 339: Keywords in the sentence are collectively identified and extracted as tags or classification information. (7) List structure extraction and determination 340: Numbered lists, itemized lists, or repetitive structure patterns are detected and extracted as array format data. (8) Meta-list format extraction determination 341: The entire document is overlooked and extracted in list format as a meta-structure including headers, lead sentences, etc. (9) OpenAI tool schema extraction determination 342: Identify and extract structures (JSON, etc.) that correspond to OpenAI function call schemas. (10) Notebook argument schema extraction determination 343: Identify and extract a schema (JSON format) that describes the arguments required for notebook execution.

[0121] 21E is a block diagram showing the configuration of a process for extracting text information from a file according to this embodiment. This diagram shows the flow of a process for extracting usable text information by format from a file uploaded or specified by a user.

[0122] The file text extraction unit 345 is a general term for processing aimed at extracting internal text information from any file format. Depending on the type and content of the target file, it converts it to text using the following methods. (1) Plain Text Extraction 346: Extracts character information in a file as plain text. This applies to files that do not have a special structure (such as .txt). (2) Extraction in JSON format 347: If the file contents conform to the JSON format, they are structurally analyzed and extracted. The extracted JSON can be used as properties or messages. (3) Extraction in CSV format 348: If there is a structure delimited by commas or tabs, it is analyzed as CSV and extracted as table format data. (4) Markdown Extraction 349: This is applied when Markdown format with structures such as headings, lists, and code blocks is identified. The structure is preserved and the data is extracted as text data. (5) Conversion 350 for binary files: For binary file formats such as Word, Excel, PDF, etc., a corresponding conversion method is applied to extract and format the internal text information.

[0123] FIG. 22A is a block diagram showing the configuration of query processing using a message helper list in this embodiment. The helper yield type 355 shown in this figure is a processing method that utilizes an array of message helpers sequentially (yield processing). Target data 356 and text 357 are sent sequentially as processing targets by a message helper list 358 specified in the properties, and individual processing is executed for each. This format is used when you want to use multiple message components in a certain pattern or as part of a repetitive process (map / yield).

[0124] FIG. 22B is a flowchart showing the flow of the system query process in this embodiment. The system 359 executes ANY type (general purpose) processing (S260). After that, ANY type output is generated and passed to other processes (S261). The ANY type is designed to enable flexible processing that is not limited to predefined types, and functions as a common interface when connecting with other data formats and external queries.

[0125] FIG. 22C is a flow chart illustrating the steps involved in system query processing. (1) Generate an embedding vector from the OpenAI message sequence (S265). (2) A query for generating a file format of the embedded data is executed (S266) to obtain the embedded type data 360. (3) A fine tune query is executed (S267) to obtain call information of the tuned model 361. (4) Obtain the properties and tags of the running project (S268), execute a query for a different project (S269), and call the processing of the other project via ANY362. (5) By executing a result query of another chest, the current result information is registered and linked to the chest of another project (S270). This series of processes is an important foundation for storing, sharing, and utilizing the inference and fine-tuning results of LLM in a reusable format.

[0126] 23A is a block diagram illustrating the basic functionality of LLM (Large Scale Language Model) query processing according to an embodiment of the present invention. In this diagram, an LLM query 365 receives as input a message in plain text format 366 and returns as output either JSON text 367 or data in regular text format that is treated as an AI response 368.

[0127] Figure 23B is a block diagram explaining the specific execution format of LLM query processing. The OpenAI message data array 370 is message information formatted for queries and is supplied to various LLM queries. The standard OpenAI chat query 371 performs a normal query to the OpenAI chat API. The continuous OpenAI chat query 372 operates in a mode that obtains all LLM output. The OpenAI mini query 373 is a lightweight query for simple queries. The OpenAI function API query 374 performs queries based on function data and JSON-formatted data structures. Finally, the output results of each query are obtained as OpenAI response data 375.

[0128] Figure 23C is a block diagram explaining the functional configuration of query processing targeting data. A data processing type function 380 receives a message input as data 381 or text 382, ​​and further acquires asset information 383 and the like as properties, and performs processing. After processing, it returns a response in the form of text 384 or data 385 as output. Furthermore, splitter type 386 data processing receives a list-format message 387 or asset list 388, splits it into each, and performs processing.

[0129] Figure 23D is a block diagram explaining a specific implementation example of data query processing. Passer 390 has a simple relay function that transfers input message data 391 as is as output message data 392. Meanwhile, file data query 393 receives ANY type information 394, saves it as a file, and outputs that information as ANY call information 395. In this way, the LLM response processing and data processing / storage processing are closely linked, supporting flexible information utilization.

[0130] 24 is a flowchart showing the flow of the conversion process of an LLM (Large Scale Language Model) output sentence according to this embodiment. In this figure, first, the response text conversion module 500 receives the output text from the LLM. Then, the following series of extraction and classification processes are executed in sequence. (1) Extracting code blocks 501 (extracting code parts from output text) (2) Extraction of CSV format table data 502 (detects and extracts data that can be formatted as a table) (3) Automatic detection and extraction of JSON structure 503 (extracting JSON format data that can be detected by the passer) (4) URL format extraction 504 (Extract URL based on regular expressions) (5) Extracting JSON structure related to notebooks 505 (detecting JSON with schema information required for notebook execution) (6) Keyword structure extraction 506 (extracting semantic keywords contained in LLM output sentences in blocks) (7) List structure extraction 507 (extracting list-format data from repetitive structures, etc.) (8) Classification extraction based on overall structure 508 (analyzes the entire sentence and performs meta-structural classification) (9) Extraction of OpenAI tool call information 509 (extracting tool information such as function calls) (10) Extract notebook argument structure 510 (extract argument configuration information required for notebook execution) The structured data obtained by each of these processes is stored and integrated as message data 511 and is reused in the subsequent processing units.

[0131] FIG. 25 is a block chart showing the functional configuration related to the message processing of file information according to this embodiment. As shown in the diagram, different processing is applied to file information 610 called from storage by file carrier processing 600 depending on its structure. That is, if the file information is not of binary structure type 611, the processing branches depending on the structure type, such as plain text structure 612, JSON structure 613, CSV structure 614, or Markdown structure 615. For files conforming to these structures, text content extraction processing 616 is executed according to the respective format, and the extracted data is stored as message data 617. This configuration efficiently realizes conversion from various file formats on storage to message data in a unified format that can be used for AI processing, API calls, and the like.

[0132] 26 is a block diagram showing the configuration of the argument processing function according to this embodiment, and illustrates an example of various argument processing and notebook information message extraction processes using the message execution unit 400. The argument processing mechanism shown in this diagram is originally derived from notebook processing, but is characterized by its extensibility to general API processing.

[0133] When a notebook argument definition 410 is applied, information 402 and message data 403 from the registered file that have a data type that matches the corresponding argument definition are converted into arguments (S400). Then, AI-generated statements 404 and AI-generated data 405 that can be converted into appropriate data types are typed (data-typed) (S401), given argument definition information, and used as arguments 411 for subsequent processing.

[0134] On the other hand, if the AI-generated statement 407 and AI-generated data 408 conform to the notebook execution data format, they are typed (S402) and sent to subsequent processing as notebook data 416 via messages 419 selected by query registration 406, or directly extracted 418 from the AI-generated statement 407, or via query registration in the appropriate format 417.

[0135] The message generation process 401 represents the argument processing and notebook matching process. If an argument definition 420 exists, information 421 registered from the query or existing arguments 411 that match the definition information is selected (S404), and if a match is found, extraction processing is performed according to the definition information (S405). Then, the notebook definition information is matched with the argument information (S406), and a notebook object with the required properties is generated (S407). This notebook generation mechanism is not limited to notebook objects; it can also be used for APIs that have property information defined as arguments via the matching improvement function 424.

[0136] <Detailed description of functions and components> From here on, each function and component used in the API usage support system of the present invention will be described in detail.

[0137] The project page is made up of multiple components working together to provide users with a visual and intuitive way to build and manage data flows. Each component has a clear role and is designed to allow users to effectively operate chests and flows in the field. The project page is the main page for users to manage projects and operate chests in the field. This page is made up of multiple components, each of which is responsible for a specific function. The structure and functions of each component are described in detail below.

[0138] Projects.js is the main component of the project page, providing functionality for listing, selecting, creating, updating, and deleting a user's projects. It also displays fields and fetches data for selected projects. Its main functions include: Retrieving and displaying a list of projects, retrieving the projects owned by the user from the Chestflow execution control and displaying them as a list. The project selection function fetches the data for that project when the user selects it, and displays a chest in the field. Projects can be created, updated, or deleted, and new projects can be created or existing projects can be edited or deleted through a form. The field data retrieval function retrieves field data and stream data related to the selected project from the Chestflow execution control. The message display function displays a message to the user depending on the operation result (success or error). The drawer management function displays a drawer next to the field and displays the ChestStream component.

[0139] ChestField.js is a component that visually displays chests and flows on the field and allows users to operate chests. Its main functions are as follows: The chest display function places chests on the field and reflects their position and status. The chest drag-and-drop function allows users to drag chests to change their position. The flow display function displays the flow (data flow) between chests with lines and arrows. The chest selection and editing function allows you to click on a chest to select it and view or edit detailed information. The sequence chest expand / collapse function allows you to expand and collapse sequence chests (chests with multiple processes).

[0140] ChestStream.js is a component that displays a list of messages and data generated from the chest, allowing users to check the contents. Its main functions are as follows: The message card display function displays each message in card format, allowing users to check the content and title; the message detail display function displays detailed information when a message card is clicked; and the download function allows the displayed message to be downloaded in Markdown format.

[0141] ChestBox.js is a component that represents individual chests and is responsible for displaying and operating them on the field. Its main functions are as follows: The chest display function displays the chest title, status, group status, etc. The icon button provision function displays icon buttons for group selection, partial execution specification, sequence expansion / contraction, chest deletion, etc., which the user can operate. Draggable chests Chests can be moved by drag and drop using react-dnd.

[0142] Chest flow.js is a component that visually displays the flow (data flow) between chests. Its main functions are as follows: The flow line drawing function draws a line between the source chest and the target chest to show the data flow; The flow button provision function places a button on the flow, and clicking it allows you to view and edit detailed information about the flow.

[0143] ExpandingChestBox.js is a component that manages the expansion and contraction of sequence chests, and displays child chests when expanded. Its main functions are as follows: The sequence chest display function displays the parent chest and its child chests together. The child chest display area management function displays many child chests in a scrollable container, optimizing the display area. The sequence execution button provides buttons for partial or full execution.

[0144] This section describes in detail the main components of the chest flow execution controller related to field processing and their functions. The main contents are as follows: ChestFieldController receives requests from the chest flow configuration GUI processor and provides API endpoints related to chest and flow operations. ChestFieldService implements business logic and provides functions such as creating chests, managing recalculation, and executing sequences. FieldObjectService is responsible for detailed operations on objects (chests and flows) on fields.

[0145] The overall flow of the project page is as follows: First, the user selects or creates a project in Projects.js, and data for the selected project is fetched. Then, the field display (ChestField.js) displays chests and flows in the field, allowing the user to operate the chests. Then, to operate the chests, the user can move chests by dragging and dropping them, or perform specific operations using the icon buttons. The stream display (ChestStream.js) allows the user to check messages and data generated from the chest. Sequence management (ExpandingChestBox.js) allows the expansion and partial execution of sequence chests. Then, in cooperation with the chest flow execution controller, user operations are sent as requests to the chest flow execution controller, and the ChestFieldController and related services process them.

[0146] Below are the main configuration files of the Chestflow configuration GUI processor and detailed functionality of each page. Account.js is responsible for the user account management page. It provides functions such as user login, logout, registration, password change, and account deletion. The main functions are as follows: (1) A login form where users log in by entering their username and password. (2) A registration form where new users can create accounts. (3) A password change function where logged-in users can change their passwords. (4) An account deletion function where users can delete their own accounts.

[0147] FileManager.js provides a file management page for uploading, downloading, and deleting files. Its main functions are as follows: (1) A file list display function that displays a list of files uploaded by the user; (2) A file upload function that allows you to upload files from the local computer; (3) A file download function that allows you to download files that have already been uploaded; and (4) A file deletion function that allows you to delete unnecessary files.

[0148] Help.js is a help page that provides application usage instructions and FAQs. Its main functions are as follows: (1) FAQ list function that displays frequently asked questions and their answers in list format; (2) Usage guide that explains step-by-step procedures for using the application; (3) Support inquiry information that provides contact information when additional support is needed.

[0149] MessageHelperList.js is a message helper management page, and is used to display a list of message helpers, create new ones, edit them, delete them, and perform other operations. Its main functions are as follows: (1) A message helper list function that displays a list of message helpers owned by the user. (2) A new creation function that allows you to create new message helpers. (3) An edit modal function that displays a modal window (a small window that displays by restricting the operation of the original screen) for editing the details of the selected message helper. (4) A delete function that allows you to delete unnecessary message helpers.

[0150] NotebookManager.js is a management page for creating, editing, running, and deleting notebooks. Its main functions are as follows: (1) A notebook list display function that displays a list of existing notebooks (2) New notebook creation function that allows you to create new notebooks (3) A notebook editing function that allows you to open the selected notebook in an editor and edit its contents. (4) Notebook execution function that executes notebook code on the server (5) A notebook deletion function that allows you to delete notebooks that you no longer need.

[0151] Projects.js is the main project management page where you can list, select, create, delete, and update projects. It also includes the ability to view and edit the details of a selected project. Its main features are: (1) Project list display function that displays a list of user projects (2) Project creation function that allows you to create new projects (3) Project selection function that displays the details of the selected project and allows you to edit or delete it. (4) Project deletion allows you to delete unnecessary projects. (5) Field display function that displays and allows you to manipulate detailed fields of the selected project.

[0152] TemplateManager.js is a template management page that provides functions to create templates from projects and create projects from templates. It also allows importing and exporting templates. Its main functions are as follows: (1) Template list display function that displays a list of templates owned by the user (2) Template creation function to create templates from existing projects (3) Project creation function to create a new project from a template (4) Template deletion function that allows you to delete unnecessary templates (5) Template import / export function that allows you to import templates from a file or export them as a file.

[0153] AIModelHelperManager.js is a page for managing AI model helpers, and provides functions that allow users to tune, register, and manage AI models based on their own data. Its main functions are as follows: (1) An AI model helper list display function that displays a list of AI model helpers created by the user. (2) A model tuning and registration function that uses a dataset processed by Message Creator to tune an existing AI model to user-specific data and create and register a new model. (3) An embedding vector generation function that generates an embedding vector from a dataset and uses it for information search and similarity calculations. (4) A model editing and deletion function that allows you to edit the properties of registered AI model helpers and delete models that are no longer needed. (5) A del usage display function that clearly shows users the names and usage status of registered models and allows you to check which models are being used in which chests.

[0154] Dataset preparation and processing involves users collecting and processing data to be used for model training through the message creator. Data is preprocessed (cleaning, tokenization, tagging, etc.) and formatted into a suitable format for model tuning. For model tuning and registration, the query function uses the processed dataset to tune the model in the Chestflow execution controller. The tuned model is registered in the database as an AI Model Helper. When registering, the model name, identifier, associated properties, owner information, etc. are set.

[0155] In the model listing and management section, users can check the list of AI model helpers they have registered. Detailed information about each model (such as name, creation date and time, and usage status) is displayed. Models can be edited or deleted as needed. Registered models can be called and used from other chests or query functions. By specifying the model name or identifier, a process that applies a specific model can be executed. Model parameters and properties can be dynamically set to adjust the processing content. When model registration or updating is complete, the model name and identifier are returned to the user as a response. This allows users to confirm that the model generated from their data has been successfully registered and is available for use.

[0156] The features of AIModelHelperManager.js are as follows: (1) Support for building custom AI models: Users can use their own data to build and manage more appropriate AI models. (2) Improved reusability of models: Once a model is registered, it can be used by other functions, enabling efficient data processing. (3) Intuitive management interface: Model status and usage can be visually checked, making model management easier. (4) Integrated data management: Maintain consistency across the system by centrally managing models and related datasets and properties.

[0157] AppContext.js uses React contexts to manage shared state across an app, and has three main functions: (1) Authentication token management: Manages tokens to maintain the user's authentication status. (2) CSRF token management: Manage CSRF tokens as a security measure. (3) Current Context and Mode: Manages the current page and context mode and controls navigation and display.

[0158] UtilityFrame.js is a component that provides a common framework for utility pages. Its main functions are as follows: (1) A navigation drawer function that provides a drawer that is always visible on the side, making it easy to navigate between utility pages. (2) Responsive design feature that adjusts the drawer display and content layout according to screen size.

[0159] Navbar.js is a component that provides the top navigation bar for the entire application. It displays links to key pages within the app and indicates the current page and context. This application is designed around a navigation bar powered by Navbar.js, allowing users to efficiently access various functions. The newly added AIModelHelperManager.js allows users to build custom AI models from their own data and use them within the system. Each page focuses on a specific function and serves to improve the user experience. Key features include: (1) a page title display function that displays the current page or context name in capital letters; (2) a navigation link function that provides links to Projects, Utilities, Account, and Help; (3) a page highlighting function that changes the style of the corresponding navigation button depending on the current page; and (4) a context mode display function that displays information when the user is in a specific context mode.

[0160] Below is a detailed explanation of the functions and process. The functions of the message creator, OpenAI Standard Chat Message Creator, are as follows: (1) A message preparation function that receives message data, including queries, in a chest (data container) and processes it into a format suitable for the OpenAI API. (2) Property utilization function. Filtering conditions and conversion settings are obtained from properties. This allows for flexible control of message selection and processing methods. (3) Message extraction and filtering function to extract required messages based on specified conditions (role, tag, text content, etc.). (4) A message conversion function that converts the extracted messages into an OpenAI format (e.g., a list of role-content pairs).

[0161] The flow consists of four steps: (1) Get properties: Get filtering conditions (e.g., roleFilter, filterText) and conversion options from properties. (2) Message extraction: Select the required messages from all messages in the chest based on their properties. (3) Message processing: The selected message is converted into the format required by OpenAIAPI. Here, helpers such as Query Helpers are used to format the text and remove unnecessary information. (4) Storing the results: The processed message is stored in Function Results and passed to the next query function.

[0162] The query function, Standard OpenAI Chat Query, has the following three functions: (1) An API request construction function that constructs request data to the Open AI API based on the message passed from the message creator. (2) A function to query the API to make queries to the OpenAI chat model using the constructed request. You can select a model and also make a FUNCTION CALL by entering the format in the query. (3) Response acquisition and analysis function that receives responses from the API and extracts the necessary information.

[0163] The flow consists of the following six steps: (1) Message preparation: Flatten the message list and adapt it to the API request format. (2) Adding system messages: If necessary, add system messages (conversation context and instructions) to the message list. (3) Setting API parameters: Parameters such as the model name, temperature (a parameter that adjusts the creativity and unpredictability of the generated text), and number of tokens are obtained from the properties and set in the request. (4) Send a request to the API: Send a request to the OpenAI endpoint. (5) Extract the response (reply content). (6) Storing results: The extracted data is stored in Function Results and passed to the generator.

[0164] The OpenAI Chat Response Standard Generator has the following three functions: (1) A response message generation function that generates the final message based on the data received from the query function; (2) A message processing and tagging function that processes the message content and adds specific tags as needed; and (3) A storage function that stores the generated message in the executor and manages its status within the system.

[0165] The flow consists of the following six steps: (1) Obtaining response data: Obtain the response from the query function from Function Results. (2) Extraction of message content: If there are multiple candidates, extract the content of each message. (3) Message Creation: Create a new message object using the extracted content. (4) Apply Tags: Attach specific tags to messages based on properties or conditions. (5) Message storage: The generated message is stored in the executor, preparing for subsequent processing or response return. (6) Return response: Update the executor state and return it to the user as the final response.

[0166] There are five detailed characteristics of the process. (1) Clear division of responsibilities among modules: Each component has a clear role and functions independently, improving the readability and maintainability of the entire system. (2) Flexible property settings: Behavior can be finely controlled through properties, making it possible to accommodate a variety of use cases and requirements. (3) Use of helper classes: Common processing and complex conversion processing are implemented simply using utilities such as Query Helpers. (4) Thorough error handling: Errors that may occur at each processing step are properly captured and handled to maintain system stability. (5) Use of tags and metadata: By adding tags to messages, subsequent processing and conditional branching can be flexibly controlled.

[0167] The overall process can be summarized as follows: (1) Message preparation and processing (Message Creator): Extracts and processes messages in the chest and formats them suitable for the OpenAI API. (2) Querying the API (Query function: Uses the processed message to query the OpenAI chat model. (3) Response processing and message generation (generator): Analyzes the response from the API and generates and processes the message to be returned to the user. (4) Store in executor and return response: The generated message is stored in the executor and returned as the final response. This series of processes makes it possible to utilize OpenAI's functions based on user input to efficiently generate and provide appropriate responses.

[0168] Based on the code in the AI ​​Model Helper and AI Model Helper Repository, the AI ​​Model Helper builds query functions that tune models using datasets processed by the message creator, as well as query functions that use embedded models. These are registered in the AI ​​Model Helper and can be used for subsequent matching with chests (data containers). The name of the registered model is also returned as a response, clearly communicating the model usage status to users. This function allows users to customize AI models using their own data and improve the overall system performance and response accuracy. By making it easier to register and reuse models, we can expect to improve development efficiency and simplify maintenance. Furthermore, by enhancing feedback to users, we provide a better user experience.

[0169] The AI ​​Model Helper has the following five detailed functions: (1) Dataset processing by the message creator: Collects user input and messages in the chest and formats them into a format suitable for tuning the model. This involves preprocessing the text data, such as cleaning, tokenizing, and filtering. (2) Building a query function for model tuning: Using the processed dataset, existing AI models are tuned to fit specific tasks or domains. The model tuning process is executed asynchronously in the Chestflow execution controller. (3) Building query functions using embedding models: Generate embedding vectors from datasets and use them for advanced information retrieval and similarity calculations. Embedding models represent the semantic relationships between words and sentences as numerical vectors. (4) Registration in AI Model Helper: The tuned model and embedded data are stored in the AI ​​Model Helper database, along with the model identifier, associated properties, and owner information. (5) Model usage in the chest and response generation: The registered model can be called from the query function in the chest. The model name and identification information are returned as a response to the user, indicating the processing result.

[0170] The detailed flow of the AI ​​Model Helper follows these six steps: (1) Dataset preparation: The message creator collects user input and existing chest information in the form of messages to create a dataset. If necessary, the data is tagged and classified to create a suitable format for model training. (2) Model Tuning: The query function receives the dataset and starts training the model. The model parameters and hyperparameters are dynamically set by the properties. (3) Embedding vector generation: Another query function generates embedding vectors from the dataset. The generated vectors are stored in a database and used for similarity searches. (4) Model Registration: Once the tuning is complete, the model and generated embeddings are registered as an AI Model Helper, along with the model metadata and related information. (5) Applying a model in a chest: Registered models can be called and used from other chests or AI call query functions. By specifying the model name or identifier, it is possible to apply a specific model to processing. It can also be used to select a model for an AI query from the registration information of the AI ​​model helper. Model parameters and properties can be specified to adjust the model's behavior. (6) Response to the user: Once the model registration is complete, the model name and ID are returned to the user, allowing the user to confirm that the model created based on their data is available for use.

[0171] There are five characteristics: (1) Building custom models: Tuning models from user-specific datasets can result in better responses and results. (2) Reusability of the model: Once a model is registered, it can be reused by other chests and functions, enabling efficient system operation. (3) Dynamic property settings: Model settings can be flexibly changed through properties to meet diverse needs. (4) Improved user experience: By returning the registered name of the model as a response, users can intuitively understand how the system works. (5) Integrated data management: Centralized management of models and related data ensures data consistency and integrity.

[0172] <Details of the flow incorporating Google search>

[0173] <Message Creator> Extract Google Search Message Creator extracts keywords or URLs from messages in the chest and processes them into a format that can be used by subsequent query functions. The flow details consist of the following four steps: (1) Property acquisition: The type of data to be extracted (keyword or URL) and other extraction conditions are acquired from the properties. Specifically, properties such as isSelectKeywords and isMergeContent are used. (2) Message extraction and filtering: Select messages that contain keywords or URLs from the messages in the chest according to the specified conditions. For example, if isSelectKeywords is true, messages whose data type is keyword are filtered. (3) Message integration and processing: If isMergeContent is true, the contents of the extracted messages are integrated and compiled into a single text data. The extraction results are stored in MessageArrier and set up so that they can be used in subsequent processing. (4) Storing the results: The processed data is stored in Function Results and passed to the query function.

[0174] In the query function, Google Search Query performs a Google search using the received keywords, retrieves the results, performs a Google search by specifying the URL, and analyzes the destination web page. The detailed flow consists of the following four steps: (1) Obtaining keywords: Extract keywords and URLs from the Function Results passed from the message creator. (2) Setting search parameters: Use the settings obtained from the property (maxResults), such as the maximum number of search results. (3) Perform a Google search: Use the Google API to search for the keywords you obtained. Extract necessary information such as links and snippets from the search results. (4) Formatting the results: The search results are formatted into a specified format and stored in the queryResult of Function Results.

[0175] The generator, Extract Google Search Message Generator, generates a response message based on the search results from the query function. The detailed flow consists of the following five steps: (1) Obtaining search results: Obtain search results from the Function Results passed from the query function. (2) Message Generation: A separate message is generated for each search result, including a title, link, and content. (3) Message Processing and Tagging: If necessary, the message content is processed and tagged with specific tags. The message is formatted so that it is displayed appropriately to the user. (4) Creating message data: The generated message is created as a Message Data object and stored in the executor. (5) Return the response: Update the executor state and return it to the client as the final response.

[0176] The characteristics of a flow that incorporates Google search are as follows: (1) Flexible data extraction: Message Creator can dynamically extract keywords and URLs, making it possible to respond to various search queries. (2) Real-time information acquisition: By using Google Search, the latest information can be provided to users. (3) Customizable search: The number of search results and the information to be extracted can be controlled using properties, providing results tailored to the user's requirements. (4) Structured data management: Search results are handled in a unified data structure, making subsequent processing and display easier. (5) Thorough error handling: Errors that may occur at each step are properly captured and handled, increasing the reliability of the system.

[0177] To summarize the overall process of incorporating Google search, it consists of the following four steps: (1) Extraction of keywords or URLs (Message Creator): Extract keywords or URLs required for searching from user input or messages in the chest. (2) Perform a Google search (query function): Perform a Google search using the extracted keywords and obtain the results. (3) Message generation of search results (generator): Generate and process messages to be presented to users based on the search results. (4) Storing in the executor and returning a response: The generated message is stored in the executor and returned to the client as the final response. This series of processes enables real-time search results to be provided based on user input, enabling effective information provision.

[0178] Regarding query processing, from the provided code, the four main files for query processing and their interrelationships are as follows: (1) QueryFunctions.scala: Defines the main query functions and calls other query-related functions. (2) OpenAIMessageHelper.scala: Processes and formats messages and interacts with OpenAI's API. (3) OpenAIService.scala: Responsible for communicating with OpenAI’s API, executing queries and retrieving results. (4) SystemMessages.scala: Defines templates for system messages and manages instructions to the model.

[0179] QueryFunctions.scala has the following three functions: (1) Definition and implementation of query functions: We define an abstract class, Query Function, which is the core of query processing, and implement specific query functions that inherit it. (2) Integration with other functions: It has a query function that integrates with external services such as OpenAI API and Google Search, and in the process calls other service classes and helper classes. (3) Query execution flow management: Each step of query input, processing, and output is managed in an integrated manner, enhancing reusability and scalability.

[0180] The flow of QueryFunctions.scala consists of four steps. The first step is the abstract class definition of Query Function. This is the base class for all query functions and has four common properties and one method. The four properties are: (1) properties: Defines the parameters required for query execution (2) messageTags: Defines tags to apply to messages (3) typeName: Name that identifies the type of query function (4) creatorResultType and queryResultType: These are the input and output data types of the query. One common method is query: an abstract method that implements specific processing for each query function.

[0181] The second step is to implement specific query functions. Various query processes are implemented in classes that inherit Query Function. Standard OpenAI Chat Query uses OpenAI's chat API to generate a response to a user's message. It constructs the message and sets parameters, and calls the API through the OpenAI Service. Google SearchQuery uses Google's search API to obtain search results for specified keywords. It formats the search results and makes them usable for subsequent processing.

[0182] The third step is external service invocation. The query function calls other services and helper classes as needed. The OpenAI Service is used to communicate with the OpenAI API. The OpenAI Message Helper handles message formatting and tagging. The Query Helpers reference supports message extraction and transformation operations.

[0183] The fourth step is to execute the query and obtain the results. The query method of the query function uses the necessary properties and messages to perform processing. Responses and processing results from the external API are received and returned as FunctionResults. The results are used in the next processing step or to generate a response.

[0184] The features of QueryFunctions.scala are as follows: (1) Extensibility and reusability: New query functions can be easily added using the Query Function as a base class. (2) Modular design: Each query function is implemented independently, and its integration with other functions and services is clear. (3) Seamless integration with external services: Effectively utilizes external APIs such as those from OpenAI and Google to provide advanced functionality for query processing.

[0185] OpenAIMessageHelper.scala has the following three functions: (1) A message processing and tagging function that applies the necessary tags to messages and formats their content; (2) A message format generation function for the OpenAI API that converts messages into the format required by the OpenAI API; and (3) A system message addition function that retrieves system messages from SystemMessages and adds them to the beginning of the message sequence.

[0186] The flow of OpenAIMessageHelper.scala consists of the following five steps: (1) Message collection and integration: Collects messages from multiple Message Data and combines them into a single list. (2) Message filtering: Extracts only the required role types (e.g., System Message, user, assistant). (3) Tag application and content formatting: Applies tags to each message and formats the content. (4) A conversion function to the OpenAI format that converts the message role type to conform to the OpenAI API specifications and generates a JSON-formatted message object. (5) A system message addition function that adds the system message obtained from System Messages to the beginning.

[0187] OpenAIMessageHelper.scala has the following three features: (1) Flexible message processing: Flexible control of message content and format through tagging and filtering. (2) Output of debug information: Output of debug information at each step of processing makes development and troubleshooting easier. (3) Strengthening collaboration with OpenAI PI: Formatting messages in the format expected by OpenAI’s API to facilitate collaboration.

[0188] OpenAIService.scala has three functions: (1) Communication with OpenAI API: Communicate with OpenAI's chat API and function call API and execute queries. (2) Constructing an API request: Construct an HTTP request including the required headers and body. (3) Response processing: Receive the response from the API, parse it appropriately, and return it.

[0189] The OpenAIService.scala flow consists of the following five steps: (1) Obtaining the API key: Obtain the OpenAI API key from the configuration file. (2) Construct an HTTP request: Construct a request that includes the specified model, parameters, and message. (3) Sending a request to the API: Send a request asynchronously and wait for a response. (4) Error handling: If an error occurs in a request or response, handle it appropriately. (5) Parse and return the response: Parse the response body, extract the necessary information, and return it.

[0190] OpenAIService.scala has three features: (1) Asynchronous processing: Sending requests and receiving responses is processed asynchronously to optimize performance. (2) Versatility: It supports multiple endpoints, including not only chat APIs but also function calls and file uploads. (3) Secure data storage: Requests and responses are stored in a database or log for subsequent analysis and tracing.

[0191] OpenAIService.scala's function output support for AI processing calls a function suggested in a model response, and then calls that function to obtain the results. It defines available functions and enables the model to recognize them. First, it detects function calls from the model. It parses the OpenAI API response and detects the function_call field. It then executes the corresponding function based on the specified function name and arguments. It then provides the function execution results to the model and continues generating a response. It then obtains the final response from the model and provides it to the user. OpenAIService.scala allows the model to call functions, enabling more precise and dynamic responses, and makes it possible to extend the model's capabilities by adding new functions.

[0192] SystemMessages.scala provides templates for system messages and defines instructions and output format guidelines for models. It manages messages to ensure unified communication and consistent interaction with models. It controls the output format by clearly specifying the output format expected by the model and preventing unexpected output. It is also flexible, allowing system messages to be extended or modified as needed to meet new requirements. The flow of SystemMessages.scala consists of two steps. (1) Constant definition: Define the templates of basic chat query messages and response messages as strings. (2) Use from other classes: Reference these system messages from classes such as OpenAI Message Helper and incorporate them into message sequences.

[0193] The query processing system, centered around QueryFunctions.scala, achieves high scalability and reusability through abstraction and modularization. Using Query Function as a base class and implementing specific query functions individually makes it easy to integrate with external services and add new functions. Integration with OpenAI Service and OpenAI Message Helper effectively utilizes OpenAI's API to provide advanced AI functions. Communication with the model is optimized through system messages and message tagging, providing high-quality responses to users. Furthermore, the system is flexible and extensible, including the ability to follow function outputs, and is designed to accommodate future requirements and technological advances.

[0194] This system uses tags and properties to exchange data and manage status between chests and functions. In particular, the MessageData.scala file implements a series of processes, such as defining tags and properties, retaining values, propagating, evaluating, and applying them. Tag and property definition and management are performed by defining the name, data type, default value, value range, etc. of each tag in the message tag definition. This determines the specifications of tags shared between messages and functions. Next, the property definition defines the property name, data type, default value, value range, display control, etc. These are configuration items for controlling the behavior of functions and generators.

[0195] The role of the GlobalIdentifier is as follows: (1) Global Identifier Definitions Mapping: (Definition and Management) Global Identifier Definitions Mapping maps tags and properties to global identifiers. This prevents tags and properties with the same identifier from having different definitions. (Maintaining Consistency) Tags and properties are managed using global identifiers to maintain consistency across multiple functions and messages. This ensures data consistency across different components. (2) Integration and verification of definition information: (Integration of definitions) Multiple definitions with the same identifier are integrated and managed consistently. This prevents tags or properties with the same identifier from having different definitions. (Verification of inconsistencies) Verification is performed to check whether there are any inconsistencies between the definition information and the global identifier. In particular, it is required that the message type and value range are the same. (3) Managing tag and property values: (Value retention and propagation) Global MessageTags retains tag values ​​shared across the entire application. This allows data sharing between chests. (Value conversion and application) Tag and property values ​​are converted and applied using Global Identifier Definitions Mapping. This allows dynamic control when messages and functions are executed.

[0196] The characteristics of GlobalIdentifier are as follows: (1) Flexibility and extensibility: Using a global identifier makes it easy to flexibly control processing and expand functions. (2) Maintaining consistency: By using global identifiers, individual functions and messages can operate appropriately while maintaining overall consistency. (3) Dynamic control: Processing can be dynamically changed based on the values ​​of tags and properties, allowing for flexible responses to user input or the results of other functions. (4) Data sharing and propagation: Data sharing and state propagation between chests can be done seamlessly through Global Message Tags. (5) Global Identifier Definition Mapping: Tags and properties are mapped to global identifiers to maintain consistency across multiple functions and messages. In the case of properties, this becomes a global property definition mapping, which is used to unify properties within the same message helper.

[0197] A closer look at how tag and property values ​​are preserved and propagated: (1) Value item: Holds the tag and property values ​​associated with each function. It has a map of function IDs and values, and propagates values ​​at runtime. (2) Value tag list: Aggregates multiple Value Items With Function Data Ids and manages the values ​​of tags and properties uniformly during processing. This is used to correspond to the function execution conditions and function processing tags. (3) Message Tag: The tag stored in the tags of Message describes the details of the processing of the corresponding message to the function. If the tag value is modified by the processing of the function, the modified tag value is stored in this modified tag list. (4) Global Message Tag: Holds tag values ​​shared across the entire application. Managed as a map of tag keys and values, it enables data sharing between chests. For messages tagged with a global tag in the receiving chest, if there is a global identifier definition mapping corresponding to the tag definition on the receiving side, the tag value is allocated and applied to each tag. This allows for detailed argument correspondence between functions in chests connected by a flow. (5) Global property: Holds the values ​​of multiple properties to which the same value is applied through user input at the front end. Managed as a map of property keys and values, it enables data sharing between chests. For messages to which a global property has been assigned through user input, if there is a global identifier definition mapping that corresponds to the property definition on the receiving side, the value of that property is allocated and applied to each property. For example, if multiple AI query functions in a function list have the same upper limit on responses, the value of that property can be defined as a global property, and that value can be shared across user inputs.

[0198] When a message or function is executed, it is necessary to perform a specific action based on the current value of a tag or property. Examples of uses include performing an action when a tag value meets a certain condition, or dynamically changing the content of a message using a tag value.

[0199] Tag processing within the Chest Executor Services class is responsible for preparing the data required for chest execution by evaluating tags contained in message data and converting them into the appropriate format. In particular, the convert Message Tag To Index Sequence and evaluate Message Tags methods play a central role.

[0200] The purpose of the Convert Message Tag To Index Sequence method is to receive a list of message data, evaluate the tags of each message, and classify and convert them into modification tags and value tags. Finally, it returns a list of the converted message data and tags. The processing flow consists of the following five steps: (1) Merging tag definitions: Adds a common tag definition to the tag definition passed as an argument to create a merged tag definition, so that all tags are evaluated based on a consistent definition. (2) Tag evaluation for each message: For each message, the evaluateMessageTags method is called to evaluate the tags. As a result of the evaluation, a modification tag and a value tag are obtained. (3) Message update: The evaluated modification tag is used to update the message data. (4) Tag List Generation: All value tags are aggregated to generate a Value Tag List, which is used to centrally manage tag values. (5) Returning the results: The updated message data list and the generated Value Tag List are returned.

[0201] The purpose of the Evaluate Message Tags method is to evaluate the tags contained in the message data and classify them into modification tags and value tags. The processing flow consists of five steps. (1) Tag evaluation: If message tags are Global Message Tags, the tag key-value pairs are evaluated based on the tag definition. Each tag is determined to be either a modification tag or a value tag, and sorted into the respective lists. (2) Extraction of modification tags: Based on the tag definition, tags defined as modification tags are extracted. (3) Extraction of value tags: Similarly, tags defined as value tags are extracted. (4) Returning the results: Return a list of the extracted modification tags and value tags. (5) Allocation of existing tags: If message Tags is Seq[Value Items With Function DataId], all tags are allocated to both modification tags and value tags.

[0202] The evaluated tag value is applied to message data and function properties, allowing dynamic control of message content and function behavior. The use of tags and properties in functions and generators is function data, which holds the information necessary for the definition and execution of each function. This includes tag and property definitions, function types, and execution order. Furthermore, it is a message creator or generator, which uses tag and property values ​​to generate messages and process data. The content and format of the generated message can be changed depending on the property value, and processing can be branched depending on the tag value.

[0203] Tag and property integration and updating has the following characteristics: (1) Definition integration: The definitions of multiple tags and properties are integrated and managed consistently, preventing tags and properties with the same identifier from having different definitions. (2) Value update and propagation: As functions are executed and messages are processed, the values ​​of tags and properties are updated. The updated values ​​are propagated to other related functions and messages, affecting the overall behavior.

[0204] The characteristics of tag processing and property processing are as follows: (1) Flexibility and extensibility: The tag and property mechanism makes it easy to flexibly control processing and expand functionality. (2) Maintaining consistency: By using global identifiers and definition mappings, individual functions and messages operate appropriately while maintaining overall consistency. (3) Dynamic control: Processing can be dynamically changed based on the values ​​of tags and properties, allowing for flexible responses to user input or the results of other functions. (4) Data sharing and propagation: Data sharing and state propagation between chests can be done seamlessly through global message tags and value tag lists.

[0205] In conclusion, the tag and property processing mechanisms centered around MessageData.scala form the core of the application's data flow and processing logic, enabling complex processing, dynamic behavior, and advanced functionality.

[0206] The functional description and processing flow of tag and property processing are described below. The code related to tag and property processing in the specified file is analyzed to clarify its function and overall processing flow. Tags and properties play an important role in dynamically controlling the flow of data and processing within the system. The main functions are as follows: (1) Defining and managing tags and properties: Message Tag Definition and Property Item Definition. These are classes for defining message tags and properties. They specify the name, data type, default value, value range, etc. of tags and properties. Global Identifier Definitions Mapping. Multiple tags and properties are mapped to global identifiers and managed centrally. This allows common tags and properties to be shared between different functions and generators. (2) Holding and propagating tag and property values: Value Items With Function Data Id. Holds the values ​​of tags and properties associated with each function. Contains a map of function IDs and values, and propagates values ​​at runtime. Value Tag List. Aggregates multiple Value Items With Function Data Ids and manages tag and property values ​​in a unified manner. Holds tag change history and supports tag merging and updates. (3) Tag evaluation and application function: evaluate Message Tags. Evaluates the changes or new values ​​to be applied to the message based on the tag definition and current value. Depending on the tag type, appropriate processing (e.g., value replacement, message modification, etc.) is performed. Convert Message Tag To Index Sequence. Applies the evaluated tag to the message data to generate the final message sequence. (4) Using tags and properties in functions and generators: FunctionData. It holds information about each function and defines tags and properties. It manages the tags and properties required when executing a function. QueryFunction and Generator use tags and properties to generate and convert data. Properties control dynamic behavior, and tags are used to propagate results and perform conditional branching. (5) Combining and updating tags and properties: FunctionData.combinePropertyDefinition and FunctionData.combineTagDefinition. Combine multiple property and tag definitions. This allows a single function to have multiple properties and tags.

[0207] When adding new functions, the Message Helper Service integrates them with existing tag and property definitions to ensure consistency. The processing flow consists of the following four steps: (1) Adding Functions and Merging Definitions: When adding a new function, the Message Helper Service merges the function's property and tag definitions with existing ones. The Function Data property and tag definitions are added to the helper-wide message Helper Properties and tag inventory. (2) Evaluating tags and applying them to messages: In Chest Executor Services, evaluate Message Tags is called to evaluate the message tags. Based on the evaluation results, convert Message Tag To IndeSequence generates message data. (3) Updating and Propagating Tag and Property Values: During function execution, tag and property values ​​are updated. The updated values ​​are propagated to other functions and generators via the Value Tag List. (4) Result integration and final message generation: The results from functions and generators are integrated with tag and property information. The final message data is generated with all tag evaluations and property settings reflected.

[0208] We will analyze the code related to chest group processing, especially the code related to chest selection and conversion to chest flow at runtime, and summarize its functions and processing flow. The main files and classes we will look at are as follows: (1) ChestGroups.scala (2) Chest flows.scala (3)MessageData.scala (4)ChestExecutionService.scala (5)FieldObjectService.scala

[0209] The role of ChestGroups.scala is to group multiple chests and share a series of processes and message tags. The main attributes are as follows: (1)groupChestId: The ID of the chest to be grouped. (2) currentIndex: The index indicating the order of the chest within the group. (3) baseChestSequence: Flag indicating whether it is a base chest sequence (4) messageTags: Message tags shared across the group. (5) messageTagDefinition: Message tag definition information.

[0210] Chest flows.scala is a data structure for managing data flows and dependencies between chests. Its main attributes are as follows: (1) instructionType: The instruction type of the flow (e.g., "normal", "base", "precede"). (2) expressionType: The expression type of the flow (e.g., "expression", "hidden"). (3) isReference: A flag indicating whether it is a reference flow. (4) sourceId: The ID of the chest that is the source of the data flow. (5) targetId: The ID of the chest that is the target of the data flow. (6) messageTags: Message tags associated with the flow.

[0211] MessageData.scala is a data structure for storing messages and data exchanged between chests. Its main attributes are messages (a list of messages) and message Tags (tag information associated with messages).

[0212] The main methods of ChestExecutionService.scala are the following two: (1) map Group To Flow: The purpose is to generate a chest flow based on chest group information. The processing involves setting the flow according to the chest type (e.g., "map," "yield," "split," or "reduce"). For each chest group, the flow instruction type, message tag, and message index are set. If there are additional source chests, a flow is generated that includes these as well. (2) set Flows To Messages: The purpose is to prepare message data based on the given chest flow. The processing involves obtaining the latest message from the source chest of each flow. The flow's message tag is applied, and the tag is updated if necessary. Only if the message is not empty is it collected as message data.

[0213] The main method of FieldObjectService.scala is update Group Message Tags, whose purpose is to update the message tags of the specified group. The purpose of Update Flow Message Tags is to update the message tags of the specified flow. The purpose of Select Chest is to select a chest and add or update it to a chest group. The processing content is to check whether the specified chest already exists in the group. If it does not exist, a new chest group is created. If necessary, the source chest is also included in the grouping.

[0214] The details of the processing flow are described below. First, the chest selection process is performed. When a chest is selected by the user, the select Chest method is called. A check is made to see if the target chest is included in an existing group. If it is not included, a new chest group is created and the chest is added. Then, if the apply To Source Chests flag is enabled, the related source chests are also included in the grouping.

[0215] Next, the conversion to chest flows is performed. The Map Group To Flow method is used to generate chest flows from the chest group information. Depending on the chest type, the instruction type and isReference flag of the flow are set. If additional source chests are specified, flows are also generated for them.

[0216] Next, messages are prepared for chest execution. The Set Flows To Messages method prepares the message data required for execution based on the chest flow. Messages are obtained from the source chest of each flow and the necessary tag information is added. Only flows whose isReference flag is false are eligible for messages.

[0217] Next, the chest is executed. The flow is as follows: (1) Executing a sequence: The execute Sequence method executes the specified sequence chest and its child chests in sequence. Identify any incomplete child chests and execute them individually with the execute Sequence Child method. (2) Executing individual chests: Execute each chest using the execute Sequence Child method. Prepare the necessary message data and execute it using the execute Chest method. Save the execution results in the chest and update the state.

[0218] Finally, message tags are updated. The Update Group Message Tags and Update Flow Message Tags methods update the message tags of the chest group and chest flow. The tag updates are reflected when preparing a message or executing a chest.

[0219] The overall processing flow can be summarized as follows: (1) Chest Selection: The user selects a chest and creates or updates a chest group as needed. (2) Chest flow generation: Based on the chest group information, chest flow is generated using the map Group To Flow method. (3) Preparing message data: Use the set Flows To Messages method to prepare message data according to the chest flow. (4) Chest execution: The execute Sequence method executes the sequence chest and its child chests sequentially. (5) Save the result and update the status: Save the result of the chest execution and update the status to “completed.”

[0220] This system utilizes chest groups and chest flows to manage data flows and dependencies between chests. The entire process from chest selection to execution is implemented using various services and model classes, and flexible processing is possible using message tags and definition information.

[0221] Below is a detailed analysis of the processing flow from chest group selection to chest execution. The main related elements are the following three model classes: Chest Group, Chest Flow, and Message Data, and two service classes: Chest Execution Service and FieldObject Service. We will explain in detail how these classes and methods interact to realize the process from chest selection to execution.

[0222] First, we will explain chest selection and chest group updates. Here, the user selects a chest in the Chest Flow Configuration GUI processor. This action calls the select Chest method of the Field Object Service of the Chest Flow Execution Controller. The Select Chest method retrieves the chest: the specified chestId is used to retrieve the target chest from the database. (1) Check group information: Check whether the chest is already included in a chest group. (2) If not present: Create a new Chest Group object. Set the Group ChestId to the ID of the selected chest. Set the Current Index based on the maximum index value in the project (e.g., Max + 1). Save the new chest group to the database using the Chest Group Repository. (3) If it exists: Update the current group information and specify the base. - If it is already specified as a base, delete the chest group and ungroup it. - Also update the baseChestSequence flag, etc. (4) Apply to Source Chests: If the applyToSourceChests flag is true, we group the source chests related to the selected chest as well. This is done by taking the chests that are inputs to the selected chest (previous chests) and adding them to the chest group.

[0223] Next, we will explain how to generate a chest flow. Here, in the chest group information acquisition step, all chest group information in the project is acquired in order to generate a chest flow. This is done using the chestGroupRepository method. Then, in the mapGroupToFlow method processing, the mapGroupToFlow method of ChestExecutionService generates a chest flow from the chest group information. (1) Flow initialization: A Chest flow object is created for each chest group. The flow attributes are set based on the chest type and group information. (2) Attribute settings: instructionType: If the chest type is "map", set "base" or "normal" depending on whether it is a base sequence. For other types, set an appropriate value. expressionType: Normally set to "expression". isReference: If the chest type is "map", "split", or "yield", set to true. Otherwise set to false. messageTags and messageTagDefinition: Use those from the chest group. (2) Additional flow processing: If additional source chests are specified, flows for them are also generated. These flows set message indexes and tag information appropriately. (3) Flow filtering and shaping: Delete unnecessary flows (e.g., flows with instructionType "delete"). Adjust message indexes to make them consistent. (4) Setting message tag definition: Set a unified message tag definition for the flow. This is done using the unifiedChestRepositoryService method.

[0224] Next, we will explain how to prepare message data. The setFlowsToMessages method of ChestExecutionService prepares the message data required to execute the chest based on the generated chest flow. In addition, it performs the following processing for each flow. (1) Get source chest: Use the flow's sourceId to get the source chest. (2) Message data generation: Process only if the flow's isReference flag is false. Retrieve the latest message in the source chest. Update or add message tags based on the flow's messageTags. For example, set the flow's instructionType value to the "sourceMessage" tag. Create a MessageData object using the retrieved message and the updated tag. (3) Message data collection: Message data generated in each flow is collected and an overall message data list is created. (4) Filtering: Only non-empty messages are kept in the list.

[0225] The following explains how the chest is executed. When the sequence is executed, the following process is performed: (1) Identifying the sequence chest: The sequence chest ID of the target is used to obtain the chest. (2) Identifying child chests: Obtaining child chests related to the sequence chest. Identifying incomplete child chests (those whose status is not "completed"). (3) Partial execution: Execute all incomplete child chests in order. Use the executeSequenceChild method.

[0226] During each chest execution, the following process occurs: (1) Get a chest and associated flows: Based on the specified chest ID, get the chest and its targeted flows. (2) Preparing message data: Use the setFlowsToMessages method to obtain message data based on the flow. (3) Execute Chest: Execute the chest using the executeChest method, which uses the message helper to process the query and get the response. (4) Save result and update status: Save the execution result to the chest. If necessary, update the status of the chest (e.g., change it to "completed").

[0227] When a chest is executed, the following process occurs: (1) Get Message Helper: Get the message helper associated with the chest. (2) Creating and running an executor: Use chestExecutorService to create a chest executor and execute the processing. (3) Obtaining the execution result: Obtain the execution result (lastMessage) of the executor. If necessary, convert it to a response format. (4) Error handling: If an error occurs during execution, output a log appropriately and handle the error.

[0228] During the message tag update phase, the following two updates are performed: (1) Update group message tags: Use the updateGroupMessageTags method of FieldObjectService to update the message tags for the specified group. The updated message tags will be used when preparing subsequent message data or executing chests. (2) Updating the message tags of a flow: Similarly, the updateFlowMessageTags method updates the message tags of a flow.

[0229] Next, we will explain the relationships and interactions between classes. Of the ChestGroup and Chest flow, ChestGroup is used to group chests and give them common message tags and definitions. The mapGroupToFlow method generates a Chest flow based on chest group information. Chest group information (chest ID, message tag, etc.) is input when generating a flow, and the flow defines the data flow between chests within the group.

[0230] Among Chest flow and MessageData, Chest flow defines the data flow and dependencies between chests. The setFlowsToMessages method prepares message data based on the chest flow. It also uses the flow's sourceId to retrieve messages from the source chest and apply the flow's message tag to the message data.

[0231] MessageData and chest execution: MessageData is used as input data required when executing a chest. It is processed by the message helper and executor to obtain the execution result. The executeChest method executes a query using MessageData. The execution result is saved in the chest again as message data.

[0232] Finally, the overall processing flow will be explained. (1) Chest selection: The user selects a chest. The chest is added or updated to the chest group. (2) Obtaining chest group information: Obtaining chest group information within a project. (3) Generating chest flow: The mapGroupToFlow method generates a chest flow from the chest group information. (4) Preparing message data: The setFlowsToMessages method prepares message data based on the chest flow. (5) Chest execution: Execute the sequence chest and its child chests sequentially. Each chest executes its own process using the executeChest method. (6) Save result and update status: Save the execution result to the chest. Update the status of the chest (e.g., "completed"). (7) Update message tags as needed: Update message tags for chest groups and flows.

[0233] In this detailed analysis, we have looked closely at each step from chest selection to execution. A chest group is a collection of chests with common message tags and definitions. A chest flow defines the data flow and dependencies between chests. Message data is the input data required for chest execution and is prepared based on the flow. Chest execution is performed using message helpers and executors, and the results are saved. These elements work together to realize a flexible and scalable chest processing flow.

[0234] Below is an analysis and detailed explanation of the Chest Stream feature. The Chest Stream feature is called up from the field screen and allows users to view summary information for selected chest objects in stream format. Users can check important information for multiple chests on a single screen, enabling efficient information organization and access. Summary information for AI chests and related chest information can be viewed in stream format using a chat-like interface. All displayed information can also be downloaded as a file.

[0235] It has four functions: (1) Chest summary display function: Displays key information such as the chest title, query, response, creation date and time, update date and time, and message tags in a list. (2) Stream-style interface function: Provides information in a scrollable list format, allowing users to operate it intuitively. (3) Access to detailed information: Quick access to detailed information and editing screens is possible from each chest summary. (4) Filtering and Sorting: Filter information based on message tags or chest types to quickly find the information you need.

[0236] The system flow is explained below. First, data acquisition occurs. The user launches ChestStream on the field screen. The ChestStreamController, the chest flow execution controller, receives the request and checks the current project ID. It then retrieves the relevant chest groups and chest data from the database via the ChestStreamRepositoryService.

[0237] Next, data processing takes place. For each chest obtained, the chest type (e.g., reduce, map, split) is determined. Depending on the chest type, data is constructed along with appropriate display control information. The data is then formatted as a ChestStreamDisplay object, which can be easily handled by the chest flow configuration GUI processor.

[0238] Next, the data is displayed in the chest flow configuration GUI processor. The ChestStream.js component of the chest flow configuration GUI processor receives the data and renders it in a stream format. Each chest is displayed in a card format, and the user can scroll to view the information. If necessary, the user can click on a chest to access more information or editing functions. Detailed information about the chest is displayed in a modal window (a small window that displays with limited operations on the original screen). It is also possible to download the summary information of the chest stream as a file.

[0239] Finally, the system responds to user actions. If the user edits a chest or displays details, a modal window appears. The edits are sent to the Chestflow execution controller via a handler in Projects.js, which updates the database. The updated results are reflected in the stream in real time.

[0240] The Chest Stream feature has the following four features: (1) Intuitive user interface: Stream-style display allows seamless viewing of information between chests. (2) Efficient information management: Important information in the chest can be viewed in a centralized location, making it easier to grasp the overall picture of the project. (3) Dynamic data updates: Data additions, updates, and deletions are reflected in real time, ensuring that the latest information is always maintained. (4) Flexible expandability: The design allows for the addition of new chest types and display elements.

[0241] There are three things to consider about the Chest Stream feature: (1) Performance optimization: When dealing with large amounts of chest data, proper data retrieval and rendering optimization are required. (2) User Experience: It is important to enhance filtering and sorting functions so that users can quickly access the information they need. (3) Data consistency: Accurately synchronize data between the chest flow configuration GUI processor and the chest flow execution controller to prevent display inconsistencies.

[0242] The ChestStream function is a powerful tool that allows users to efficiently view and manage chest information within a project. The user experience is improved by flexible data acquisition in the ChestStream execution control unit and intuitive display in the ChestStream configuration GUI processing unit. It is expected that the system will continue to be expanded and optimized in the future, aiming to become an even more convenient system.

[0243] Below, we will explain the component configuration of the Chest Form and the details of each function. The Chest Form is the main component for displaying and editing details of a Chest (a unit of data processing). It is used when the user enters and edits chest information and incorporates it into the data flow. Below, we will explain in detail the configuration and each function of the Chest Form and its related components.

[0244] ChestForm.js is a form component for displaying and editing chest details, allowing users to select the chest title, type, message helper, and edit the query and response.

[0245] The main features of ChestForm.js are as follows: (1) A function to input basic information about a chest, allowing you to select and input the title and chest type (reduce, map, yield, split, etc.). (2) A message helper selection function that selects an appropriate one from available message helpers and sets the message format. (3) A query message editing function that uses the MessageEditor component to edit the query content in detail. (4) A function to display and edit the contents of the response, also using MessageEditor. (5) A file association function to select and manage files related to the query or response, if necessary, using FileCarrierSelectorContainer. (6) A global property setting function that sets properties and identifiers used throughout the chest via GlobalValueForms. (7) Ability to view, edit, and set chest state and test number. (8) A save / cancel function to save the user's input or cancel the edit.

[0246] Below we will explain MessageEditor.js. MessageEditor.js is a component for editing message content. It is used when editing queries and responses, and supports a variety of input formats.

[0247] The main features of MessageEditor.js include: (1) Dynamic field rendering function that renders the appropriate input component depending on the field type of the message. (2) An input assistance function for text, numbers, and Boolean values ​​that provides appropriate input forms for fields with simple data types. (3) Editor integration function that integrates TextEditor, NotebookEditor, CSVEditor, etc. to support editing of complex data formats. (4) Code editor support, providing a rich editor using CodeMirror for editing code, Markdown, JSON, HTML, etc. (5) A field hierarchy management function that allows you to properly display and edit nested data structures such as objects and arrays. (6) A field display / hide function that allows you to hide or display specific fields depending on user operations and settings.

[0248] The following explains the features of TextEditor.js. TextEditor.js is a component for editing simple text and Markdown-formatted text. It is used within MessageEditor to assist in entering text data.

[0249] The main features of TextEditor.js include: (1) A Markdown preview function that displays a real-time preview of Markdown-formatted text. (2) Editor / Preview switching function that allows you to easily switch between edit mode and preview mode with a button. (3) Prompt holder integration, which supports inserting templates and snippets by calling the PromptHolderManager using a context menu while editing text.

[0250] Below we will explain NotebookEditor.js. NotebookEditor.js is a component for editing notebook-format data. It handles data in JupyterNotebook format, and allows you to add and edit cells, set execution ranges and arguments, etc.

[0251] The main features of NotebookEditor.js include: (1) Cell management function that allows you to add, edit, delete, and reorder code cells and Markdown cells. (2) Notebook metadata editing function that allows you to set identification tags and execution modes (execute all cells, execute specific range). (3) A function to set the execution range, which allows you to specify the range of cells you want to execute and supports partial execution. (4) A function to set arguments to be used when executing a notebook, which allows you to respond to dynamic changes in data. (5) Code editor integration using CodeMirror to provide syntax highlighting and code completion when editing code cells.

[0252] CSVEditor.js is a component for editing CSV format data. It displays and edits data in table format and is called from MessageEditor. Its main function is to display data in a table, reading CSV data and displaying it in row and column format. Cell editing allows you to directly edit the values ​​of individual cells. Row addition and deletion allows you to add or delete rows in response to increases or decreases in data.

[0253] FileCarrierSelector.js is a component for selecting and managing files associated with messages. Users can upload and select files according to the specified file type. Its main features include: (1) A file selection function that allows you to select the necessary files from the available files. (2) A file upload feature that allows you to upload new files and associate them with messages. (3) A file download function that allows you to download selected files locally. (4) A file removal feature that allows you to remove file associations from messages.

[0254] FileCarrierSelectorContainer.js is a container component that manages multiple FileCarrierSelectors. It is used when handling multiple file carriers within a message. Its main functions are to receive multiple file carriers as an array, support the selection and editing of each, and to reflect bulk changes by aggregating changes in individual file carriers and transmitting them to the parent component.

[0255] ConditionEditor.js is a component for editing conditional expressions. It is used to control message processing and flow branching based on conditions. Its main features include: (1) The ability to add new conditions and edit existing conditions. (2) Ability to delete unnecessary conditions from the list. (3) A condition content input assistance function that provides an input form for setting tags, value ranges, negation conditions, etc. (4) A list display function for conditions that displays an overview of the currently set conditions in list format.

[0256] Below we will explain CreateNotebookForm.js. CreateNotebookForm.js is a form component for creating a new notebook. Users can enter an identification tag for the notebook and create a new one.

[0257] The main features of CreateNotebookForm.js include: (1) A function that allows you to enter tags for newly created notebooks, and if no tags are entered, the notebook's identification tag will be automatically generated. (2) A draggable window function allows forms to be moved by dragging, improving user operability. (3) The ability to create a new notebook based on input.

[0258] The Chest Form and its associated components support detailed configuration and editing of the chest, which is the core of the data processing flow. Each component is clearly separated by its role and supports a variety of data formats and functions, including text data, code, files, and conditional expressions. This allows users to intuitively build and manage complex data processing flows.

[0259] The functions of ChestExecutorServices are explained below. The ChestExecutorServices class is a chest flow execution control service that manages and controls the execution of chest objects. This class comprehensively supports the entire chest execution process, and in particular operates starting from the controlExecutorProcess method. The controlExecutorProcess method is the main entry point for controlling the chest execution process.

[0260] The main functions of the controlExecutorProcess method are as follows: (1) A message and tag converter that converts user-provided messages and tags into an internal format suitable for running the chest. (2) A property merge function that integrates properties from the chest and message helper and compiles the settings required for execution. (3) An executor creation function that generates a new executor (execution instance) based on chest information and prepared data. (4) A function to get and execute a list of functions from the message helper and execute each function in the order defined. (5) Saving execution results in a database and handling errors appropriately if an error occurs.

[0261] The following explains functionList. functionList is a list of a series of functions (FunctionData) used in the execution of a chest, and a complex processing flow is realized by executing each function sequentially.

[0262] The execution flow of functionList is as follows: (1) Initialization: Receives a message provided by the user, converts tags, prepares properties, and creates a new ChestExecutor instance based on the initial data. (2) Obtaining and sorting the functionList: Obtain the functionList associated with the chest. Each function has an index that indicates the execution order, and sort the function list based on this index. (3) Execute each function (loop processing): Execute each function in the sorted functionList in sequence in a loop.

[0263] The flow of execution (loop processing) of each function described above is as follows: (1) The condition set in the function is evaluated, and the function is executed only if the current tag value meets the condition. (2) Use the mergeProperties method to merge the function-specific properties with the executor properties. (3) The integrated properties are divided using the divideTagPropertyValues ​​method and classified into query properties, message creator properties, and generator properties. (4) Update properties based on the current execution environment, such as user ID and project ID. (5) Use the convertMessageTagToIndexSequence method to parse the message tag and convert it to an internal format. (6) Prepare a message list required for function execution. (7) Initialize the FunctionResults object to store the execution results and status of the function. (8) Obtain the specified message creator and execute its create method to generate the required message. (9) Obtain the specified query function and execute its query method to obtain data or perform calculations. (10) Obtain the specified generator and execute its generate method to generate the final message or response. (11) The execution results, generated messages, and updated tag values ​​are reflected in the executor state. The functionMessageList, lastMessage, valueTagList, etc. are updated. (12) If an error occurs during execution, catch it, set the executor's isError flag, and preserve the error message.

[0264] At the end of the execution flow of functionList, the execution result is saved. The executor state is saved to a database and returned as a response, if necessary.

[0265] There are three auxiliary methods: (1) convertMessageTagToIndexSequence: Parses the message tags and classifies and converts them into modification tags and value tags based on the chest tag definition. This organizes the message tags into the appropriate format and prepares them for use in the chest execution. (2) mergeProperties: Combines the default properties of the function with the properties of the executor. It merges the default values ​​with the user-specified values ​​and prepares the settings required for function execution. (3) executeFunction: Executes the specified function and reflects the results in the executor. It updates properties and tags, calls message creators, query functions, and generators, combines the execution results, and handles errors.

[0266] The ChestExecutorServices class oversees the series of processes required to execute a chest. It has the following four functions: (1) A data preparation and conversion function that properly prepares the data required to execute a chest, such as messages, tags, and properties. (2) An execution flow management function that obtains a functionList and executes each function in the appropriate order and under the appropriate conditions. (3) A result integration and storage function that reflects the execution results and updated status in the executor and database. (4) An error detection and handling function that detects errors that occur during execution and takes appropriate action.

[0267] A consideration of the characteristics of the ChestExecutorServices class is as follows: (1) Flexible function execution: FunctionList allows multiple functions to be executed in a flexible order, enabling complex processing flows and conditional branching. (2) Control by condition evaluation: By setting a condition for each function, dynamic execution control according to the tag value becomes possible. (3) Utilizing properties and tags: Properties and tags are used to share data between functions and perform runtime configuration and state management. (4) Modular design: Components such as message creators, query functions, and generators are clearly separated, making it easy to add new features and make changes. (5) Thorough error handling: By properly capturing errors during execution and reflecting them in the executor state, we have achieved a highly reliable system. (6) Data consistency and integrity: By integrating management of tags and properties, we maintain data consistency.

[0268] ChestExecutorServices is an important class that centrally manages the chest execution process. Starting with the controlExecutorProcess method, it efficiently and reliably performs a series of processes, including data preparation, tag and property integration, execution of each function in the functionList, and saving the results. This class integrates the data flow and processing logic between chests, improving the reliability and scalability of the entire system.

[0269] The executeFunction method plays an important role in the chest execution process: it executes each function data sequentially and reflects the results in the executor state. This method manages a series of processes, such as message generation, query execution, and result generation, in an integrated manner.

[0270] Below, we will explain the overall flow of executing the executeFunction method. (1) Merging and splitting properties: Use the merge:mergeProperties method to merge the properties of the function data with the current properties of the executor. Then, use the divideTagPropertyValues ​​method to split the merged properties into query properties, message creator properties, and generator properties. (2) Update properties: Update each property with information such as the current user ID and project ID. This is done using the updateTagValuesWithCurrentData method. (3) Convert message tags: Use the convertMessageTagToIndexSequence method to convert message tags based on the tag definitions in the chest. Use the converted tags to generate a ValueTagList. (4) Message Arrangement: Extract messages and tags related to the current function from the executor's message list and prepare them as arrangedMessageList. Arrange the message list for each function to create functionArrangedMessageList. (5) Prepare a FunctionResults object: Initialize a FunctionResults object to store the execution results and status of the function. (6) Execute message creator: Obtain the specified message creator defined in messageCreators and execute its create method. The necessary message data is generated and used to execute the function. (7) Execute query function: Retrieves the specified query function defined in queryFunctions and executes its query method. This retrieves the necessary data and performs calculations, such as calling an external API or querying a database. (8) Generator execution: Obtain the specified generator defined in generators and execute its generate method. Based on the results of the query function, the final message data and response are generated. (9) Update Executor: Update the Executor state with the created messages, tags, and function execution results. Update functionMessageList, lastMessage, valueTagList, etc. (10) Error handling: If an exception occurs during execution, catch it, set the executor's isError flag, and preserve the error message.

[0271] The relationship with related classes is explained below. (1) The Functions.scala:FunctionData class stores the function definition and attributes. In the executeFunction method, we use this data to merge properties and obtain function IDs. (2) MessageCreators.scala: Defines abstract classes and concrete implementation classes that contain message generation logic. - Each message creator has a create method, which is called in executeFunction. (3) QueryFunctions.scala: Defines abstract classes and concrete implementation classes that have logic for data retrieval and communication with external services. Each query function has a query method, which is called in executeFunction. (4) Generators.scala: Defines abstract classes and concrete implementation classes that contain the logic to generate the final message or response. Each generator has a generate method, which is called in executeFunction.

[0272] The executeFunction method plays a central role in managing the overall execution of a series of functions in a chest. It performs complex processing step by step, including merging properties, preparing messages, executing various functions, and integrating results. It also realizes a flexible and extensible execution flow for chests through cooperation with related classes and methods.

[0273] Below, we will analyze the chest generation process and explain its functions. We will analyze the generation and execution process of an object called a "chest" that is managed and executed by the chest flow execution controller service, and explain its functions. Chests come in three types: "map," "yield," "reduce," and "split," and each has a specific processing flow.

[0274] First, let's explain the chest creation process. (1) Receiving a request and preparing data: Receives a request from a client, parses the initial data in JSON format, validates numeric fields, deserializes the required data, obtains the message format, and sets the query and response configuration. (2) Get Project and Set State: Get the project associated with the request from the database. Set the chest state appropriately based on the project mode (e.g., "recalculation"). (3) Creating a chest: Different processes are performed depending on the chest type. For the "map", "yield", and "split" types, the chest is treated as a sequence chest and the createChest method is used to create the chest. If necessary, the createSequenceChests method is called to generate multiple child chests ("reduce" type). For the "reduce" type, the chest is created directly and executed as needed. A flow is set up and the chest is registered in the database.

[0275] Next, we will explain the chest execution process. (1) Obtaining a flow and preparing a message: The flow associated with the target chest is obtained from the database. Based on the flow information, the message required to execute the chest is prepared. (2) Executing the chest: The executeReduce method is executed for a chest of type "reduce". The message helper is used to process the chest query and obtain the results. The execution result is saved as a chest response and the state is updated to "completed". The executeSplit method is executed for a chest of type "split". If the execution result includes multiple responses, a new chest is generated for each response. The necessary information is set for each generated chest and the state is updated to "completed".

[0276] Next, the details of specific processes will be explained. (1) createSequenceChests method: Generates multiple child chests for "map" or "yield" type chests. The processing procedure is to get the chest group in the project, get the base chest group, determine the number of chests to generate, generate child chests equal to the number of base chests for "map" type, generate the specified number of child chests for "yield" type, create each child chest as a "reduce" type, and set the required flow.

[0277] (2) executeReduce method: Executes a "reduce" type chest and processes the results. The processing procedure involves getting the flow associated with the chest, preparing a message based on the flow information, executing the chest query using the executeChest method, getting the response, saving the response in the chest, and updating the state to "completed."

[0278] (3) executeSplit method: Executes a "split" type chest and processes multiple results. The processing procedure involves obtaining the flow associated with the chest, preparing a message based on the flow information, executing a chest query using the executeChest method, obtaining multiple responses, creating a new chest for each response, setting the necessary information, and updating the state of the created chest to "completed."

[0279] (4) executeChest method: The executeChest method executes the specified chest (UnifiedChest) and generates a sequence of responses as a result. The main role of this method is to evaluate the queries held by the chest and obtain the results.

[0280] The processing flow of the executeChest method is explained below. (1) Get Message Helper: The message helper associated with the chest is retrieved from the database. The message helper provides the logic required to evaluate queries and process messages. (2) Creating and running an executor: Call the controlExecutorProcess method to create a new executor. This executor will perform processing using the chest query, message helper, and the provided message. An executor ID will be generated and used for subsequent processing. (3) Obtaining the execution result: After the executor has executed, its latest state is obtained from the database. The last message held by the executor is obtained and converted into an appropriate format based on the chest's response format. The converted responses are compiled into a sequence and returned as the final result. (4) Error handling: If an exception occurs during processing, the error is handled by outputting an error message to the log and returning an empty response sequence.

[0281] The executeChest method can perform dummy processing depending on the type and settings of the method chest, but it is usually executed according to the flow above. Its main purpose is to correctly evaluate the chest query and provide the results in a form that can be used in subsequent processes.

[0282] This system manages the entire process from creating a chest to executing it and generating a new chest based on the results. The process for each type of chest is as follows: (1) "map" and "yield" types: Generate multiple child chests and perform processing on each one. (2) "reduce" type: Run a single chest and process the results. (3) "split" type: Generates a new chest if multiple results are obtained. (4) State management: The state of the chest is set and updated appropriately depending on the project mode and processing status. The state can be "wait" or "completed", and affects the processing flow of the chest. (5) Flow and Message Management: Flows define the flow of data and operations between chests. Messages are prepared based on the flows and used to query chests.

[0283] This chest management system provides a framework for efficiently performing complex data processing and calculations. It performs appropriate processing for each chest type and controls the flow of data through flows and messages. This enables flexible and scalable processing, and is expected to be used in a variety of applications.

[0284] This section explains the sequence execution process. The sequence execution process executes the chest sequence and processes each child chest as needed. This process is performed by cooperation between three files: ChestFieldController.scala, ChestFieldService.scala, and ChestExecutionService.scala.

[0285] This section explains how to receive requests in the controller. The request from the client is received by the controlSequenceExecution method of ChestFieldController.scala. This request includes sequenceId (the ID of the sequence chest) and isAll (whether to execute all child chests).

[0286] This section explains how to delegate processing to a service. The controller calls the controlSequenceExecution method of ChestFieldService.scala. This method first gets the partial execution state (PartialExecutionState) associated with the project, and if the isAll flag is true, resets the partial execution state. Next, it calls the executeSequence method of ChestExecutionService.scala to start executing the sequence.

[0287] The executeSequence method of ChestExecutionService.scala executes a sequence using the following steps: (1) Obtaining sequence chests and child chests: Obtain a sequence chest with the specified sequenceId from the database, obtain all child chests (ChestSequenceChest) belonging to the sequence, and identify chests that are incomplete (state is not "completed"). (2) Selecting partially executed chests: Determine the ID list (selectedChestIds) of child chests to be executed based on the isAll flag. If isAll is true, all incomplete child chests are targeted. (3) Execute child chests: Depending on the type of sequence chest ('map' or 'yield'), each child chest is executed in order. The executeSequenceChild method is used to execute child chests. (4) Update the status of the sequence chest. After all child chests have completed execution, update the status of the sequence chest to “completed.”

[0288] The executeSequenceChild method first obtains the flow associated with the target child chest. Next, it prepares a message based on the flow. It then calls the executeChest method to execute the chest. Finally, it saves the execution result as a chest response and updates the chest state as necessary.

[0289] The executeChest method is responsible for actually executing the chest. This method first obtains the message helper associated with the chest. Next, it calls the controlExecutorProcess method of ChestExecutorServices to create and run a new executor. Finally, it obtains the execution result (the executor's final message), converts it into the chest's response format, and returns it.

[0290] As described above, the sequence execution process starts from the controller, and the service layer executes the sequence and child chests sequentially. The controlSequenceExecution method oversees this series of processes and plays a central role in executing the sequence and managing its status.

[0291] Below, we will explain the flow and characteristics of each type of sequence execution. In this system, there are three types of chest sequence execution: "map," "yield," and "split." Each of these types has its own unique processing flow and characteristics. Below, we will analyze each type based on the code and explain its flow and characteristics.

[0292] The features of the "map" type sequence execution are as follows: (1) Parallel processing of data is possible, contributing to shortening processing time, and independent results can be obtained for each base chest. (2) Generate a separate child chest (of type "reduce") for each base chest. (3) Each child chest receives data from the corresponding base chest and processes it independently. (4) It is capable of parallel processing and is effective when applying the same processing to large data sets.

[0293] Next, we will explain the processing flow steps of the "map" type sequence. (1) Obtaining a base chest: Obtain a chest from the chest group that will become the base chest. (2) Generating a child chest: Generate one child chest for each base chest. The child chest is created as a "reduce" type. (3) Chest flow setting: The instructionType of the flow is set to "base" for the base chest and "normal" for others. In the flow of a child chest, the ID of the base chest corresponding to the sourceId is set. (4) Child Chest Execution: The generated child chests are executed sequentially. Each child chest performs processing using data from the corresponding base chest.

[0294] The "yield" type sequence execution is characterized by its suitability for repeating the same process multiple times, and its usefulness for repeatedly executing simulations and test cases. It also generates a user-specified number of child chests and performs continuous processing, and is mainly used when repeating the same process with different trial counts (each child chest may not be independent).

[0295] This section explains the processing flow steps for a "yield" type sequence. (1) Determining the number of child chests: Determine the number of child chests to generate based on the testNumber specified by the user (a default value may be set). (2) Create child chests: Create the specified number of child chests. The child chests are created as the "reduce" type. (3) Chest flow setting: For the first child chest, a flow that does not depend on the results of the previous one is set. For the second and subsequent child chests, it is possible to set a flow that uses the results of the previous child chest as the source. The instruction type of the flow is set to "precede" the first time, and "normal" thereafter. (4) Execute child chests: Execute child chests sequentially. If necessary, use the results of the previous child chest.

[0296] The "split" type sequence execution allows dynamic processing according to the data content, and is suitable for branching flows and allocating processing based on conditions. Its features are as follows: (1) Dynamically generate child chests based on the execution results of sequence chests. (2) Creating and processing each child chest from multiple results obtained during execution. (3) It is suitable for data branching processing and conditional branching.

[0297] This section explains the "split" type sequence processing flow. (1) Execute a sequence chest: Execute a “split” type sequence chest and obtain multiple responses. (2) Creating child chests: Create child chests according to the number of responses received. The child chests are created as the “reduce” type. (3) Chest flow setting: For each child chest, a flow is set with the result of the sequence chest as the source. The instruction type of the flow is set to “normal”. (4) Execution of child chests: Execute the child chests sequentially. Each child chest performs processing using the corresponding response data.

[0298] The three sequence execution types, "map," "yield," and "split," each have different uses and characteristics. The "map" type performs individual processing for each base chest, making it suitable for parallel processing of large data sets. The "yield" type repeats processing a specified number of times, making it suitable for continuous execution of the same processing, such as testing and simulation. The "split" type performs dynamic branching processing based on the execution results, making it suitable for allocating processing based on the data content and for conditional branching. By appropriately utilizing these sequence execution types, it is possible to build a flexible and efficient data processing flow.

[0299] Below, we will explain the role and flow of the recalculation function of the chest creation and editing function. The recalculation function is an important function that recalculates the chest calculation results and reflects data changes and updates. Mode management is essential to realize this function, and the editChest method and controlCreateChest method play a central role. Here, we will explain how these methods work with the recalculation function.

[0300] The controlCreateChest method controls the creation of a new chest. This method sets the state of the chest and the subsequent processing flow appropriately depending on the current mode of the project (normal mode or recalculation mode).

[0301] Below, we will explain the flow and features of the controlCreateChest method. (1) Project mode determination: Get the project from the specified project ID. Check whether the project mode is "recalculation". (2) Chest state setting: In recalculation mode, the state of the new chest is set to "wait." In normal mode, the chest is created with a default state based on the initial data. (3) Create Chest: Creates a chest in the database with the configured state. Depending on the chest type (e.g., "map", "yield", "reduce", etc.) and the flag for automatic sequence item generation, additional processing may be performed. (4) Control of additional processing: In normal mode, if the chest type is "map" or "yield", the createSequenceChests method is called to generate a sequence chest. In recalculation mode, the chest state remains "wait" and is not executed immediately.

[0302] Below, we will explain the relationship with the recalculation function of the controlCreateChest method. (1) Mode Management: In recalculation mode, newly created chests are queued and executed at the appropriate time within the recalculation process, taking into account dependencies, ensuring that recalculation is performed while maintaining data integrity. (2) Deferred Processing: In recalculation mode, the execution of the chest is deferred and managed by the recalculation process.

[0303] The editChest method provides functionality for editing the information of an existing chest. This method controls the editable fields and operations depending on whether you are in recalculation mode.

[0304] Below, we will explain the flow and features of the editChest method. (1) Get chest: Get the chest to edit from its ID. (2) Mode and editable fields determination: Determine whether the mode is recalculation mode or normal mode. In recalculation mode, editable fields are limited and some attributes cannot be changed. (3) Chest Update: Updates only allowed fields. Depending on the chest type and the automatic sequence item generation flag, deletes or recreates related child chests and flows. (4) Reconstructing the flow (if necessary): If a change to the flow is required, delete the existing flow and create a new one. As the flow is updated, the state and dependencies of the related chests are also adjusted appropriately.

[0305] This section explains the relationship with the recalculation function of the editChest method. (1) Mode Management Control: In recalculation mode, the content and timing of edits to the chest are carefully managed to ensure that edits do not affect the recalculation process. Changes to critical attributes are restricted to maintain the integrity of the recalculation process. (2) Dependency management: When an edit changes the dependencies between chests, the flow and related chests are updated appropriately so that the recalculation process works correctly.

[0306] The controlCreateChest and editChest methods play an important role in the recalculation functionality through mode management. These methods take the project mode into account when creating or editing a chest, ensuring the recalculation process is accurate and efficient. (1) Mode management function: Controls the state transition and execution timing of the chest, and properly manages data consistency and dependencies during recalculation. (2) Integration with the recalculation process: By working with the RecalculationService, chest recalculation is performed when necessary, maintaining the consistency and integrity of the entire system. By correctly understanding and operating these methods, you can effectively utilize the recalculation function and provide high-quality data processing and results.

[0307] Below, we will explain the overview, flow, and features of the template function. The template function allows you to save and reuse project settings, data, and configurations as templates. This allows users to create templates from existing projects and reuse them in other projects, or generate new projects from templates. Templates include information such as integrated chests, chest flows, chest sequence chests, and message helpers.

[0308] The template function is explained below. The template function allows you to generate a template from an existing project. It is possible to include the entire project or only specific components, and it also provides the option of whether to include message helpers. It also allows you to delete templates that are no longer needed, making it easier to organize and manage data. In addition, it has the following functions: (1) Create a new project based on a template: This allows you to start a project efficiently without having to configure settings and data from scratch. (2) Import / Export Templates: Export templates in JSON format and share them with other users or systems, or import template data provided by an external source and make it available in your own system. (3) Displaying a list of templates: Obtaining a list of templates owned by the user and displaying it in a list makes management and selection easier.

[0309] The flow of the template function is explained below. (1) Template creation: A user submits a request to create a template. The server extracts data from the specified project and generates the template content. The content is then saved in the database along with the template metadata. (2) Creating a project from a template: A user submits a request to create a project from a template. The server parses the template content and generates a new project and related data. The project is created, including message helpers if necessary. (3) Template Import and Export: The user selects an external file and uploads the template data. The server validates the data and saves it as a template. The user then selects the template they want to export and performs the export operation. The server returns the template data in JSON format, which the user can download as a file.

[0310] The following explains the features of the template function. (1) Improved reusability: The template function makes it easy to reuse project configurations and settings that you use repeatedly. (2) Efficient project initiation: New projects can be launched quickly, improving productivity. (3) Sharing and collaboration: The template export / import feature makes it easy to share and collaborate with other users. (4) Flexible customization: You can create templates to suit your needs, such as adding or removing message helpers or templating only some components of a project.

[0311] Below, we will explain the technical details of the template function. First, the configuration of the chest flow execution control unit will be summarized. (1) Model layer: The Template model defines the data structure of a template, with fields such as name, content, owner ID, and tag. (2) Repository layer: The TemplateRepository is responsible for interacting with the database and creating, retrieving, updating, and deleting templates. (3) Service layer: TemplateService implements business logic and provides functions such as template creation, project generation, import / export, etc. (4) Utility layer: TemplateCreator is responsible for generating and analyzing the contents of templates.

[0312] Next, we will explain the configuration of the chest flow configuration GUI processor. (1) Template management screen: The TemplateManager component provides a UI for listing, creating, deleting, importing / exporting templates. (2) API communication: The chest flow configuration GUI processor calls the API endpoint of the chest flow execution controller to send and receive the necessary data. (3) API endpoint (4) Get a list of templates: Use the templates endpoint to get a list of the user's templates. (5) Create a template: Create a template using the / template / createFromProject or / template / createFromComponents endpoints. (6) Create a project: Create a project from a template using the / project / createFromTemplate endpoint. (7) Delete template: Delete a template at the / templates / {templateId} endpoint. (8) Template import / export: Import and export using the / template / import and / template / export endpoints.

[0313] Use cases for the template function are as follows: (1) Project standardization: If your organization or team uses a common project structure, you can use templates to ensure consistency. (2) Quick start to development: Save frequently used settings and configurations as templates and use them immediately when starting a new project. (3) Knowledge sharing: Creating templates of successful project structures and sharing them with other team members leads to overall skill improvement.

[0314] Below we will explain the error handling and validation of the template function. When importing a template, data validation is performed to prevent invalid data and format errors. If the operation fails, an appropriate error message is displayed to the user to help resolve the problem.

[0315] The template feature is a powerful tool for improving project management and reusability. Users can save project settings and data as templates and easily apply them to new projects. This promotes efficiency, standardization, and collaboration in the development process. Its technically robust design makes it highly scalable and maintainable.

[0316] Let's analyze the details of notebook processing. Message Creator: ExecuteNotebookMessageCreator extracts the data required to execute the notebook from the message in the chest, takes in arguments, and calls an existing notebook by its identification tag. The flow is as follows: (1) Property acquisition: Obtain information such as how to extract notebook arguments and whether or not merging is performed from the properties. Specifically, use properties such as isMergeNotebookExecution and motherNotebookArgument. (2) Message extraction and processing: Use messageExtractor to extract relevant messages in the chest. From the extracted messages, obtain notebook arguments and notebook execution data. (3) Argument assignment and notebook data completion: Assign the arguments extracted from the message to the arguments in the notebook execution data. If the notebook data is empty and an identifying tag exists, use the tag to retrieve an existing notebook from the database and complete it. (4) Merging notebook execution data: If isMergeNotebookExecution is enabled, multiple notebook execution data are merged and treated as a single notebook, integrating arguments and cells, and setting the execution scope and mode appropriately. (5) Produce results: The processed notebook execution data is returned as FunctionResults, making it available for subsequent query functions.

[0317] The query function: NotebookExecutionQuery actually executes the received notebook execution data and obtains and processes the results. The flow is as follows: (1) Get properties: Get whether or not a notebook needs to be uploaded from the properties. Specifically, use isUploadNotebook. (2) Execute the notebook: Use QueryNotebookExecutor to execute the notebook. - Insert arguments as cells into the notebook before execution and execute only the required range. (3) Processing the execution results: Obtain the notebook data after execution, parse and process it as necessary, and update the result as NotebookExecutionData. (4) Upload Notebook: If isUploadNotebook is valid and an identifying tag is present, save / update the notebook to the database. (5) Returning the results: Return a FunctionResults containing the execution results, making them available to subsequent generators.

[0318] Generator: NotebookGenerator generates messages to be presented to the user from the results of the query function. The flow is as follows: (1) Property acquisition: The message splitting method and query replacement type are acquired from the properties. (2) Message generation: Obtain notebook execution data from the query function and convert it into a message format. Replace or modify the query as needed. (3) Returning the message: The generated message is returned to the executor and delivered to the user as the final response.

[0319] The following describes the auxiliary classes and utilities. (1) QueryNotebookExecutor: A utility class that executes notebooks, inserts arguments, validates imports, etc. It can insert arguments as cells in a notebook and execute only a specific range of cells. It also detects invalid import statements and validates notebook data. (2) NotebookService: A service class that creates, updates, deletes, and searches notebooks. It connects to a database based on notebook execution data and supports notebook persistence. It also provides functions to generate notebooks from files and dump notebooks as files.

[0320] The following summarizes the features of notebook processing. (1) Argument acceptance function: Extracts arguments required for notebook execution from user input or messages and dynamically reflects them in the notebook. The arguments are inserted as cells in the notebook and used at runtime. (2) Calling notebooks by identification tag: Existing notebooks are managed by unique identification tags, and you can retrieve and run a notebook by specifying the tag. Even if the notebook is empty, the identification tag is used to complete the notebook data from the database. (3) Flexible message processing and data extraction: Using message creators and query helpers, it is possible to extract data in various formats from messages. Various data formats are supported, including code blocks, CSV, JSON, URLs, and keywords. (4) Advanced Error Handling and Validation: Validates import statements and notebook data before executing a notebook to ensure safe execution. Provides appropriate exception handling and messages when an error occurs.

[0321] This series of notebook processes allows users to dynamically specify arguments and reuse existing notebooks to perform flexible data analysis and processing. The system efficiently manages everything from message analysis to notebook execution and result return, providing high-quality responses.

[0322] This section explains the functions and flow of the notebook processing microservice. This microservice is an API service for processing and executing Jupyter Notebook. Its main purpose is to execute notebook data provided by the client on the server side and obtain and return the results. The details of the functions and the processing flow are explained below.

[0323] The main features of the notebook processing microservice are: (1) The ability to run all cells in a notebook by specifying the entire notebook and executing all cells at once. (2) A cell range specification execution function that executes a specific range of cells by specifying the indexes of the starting and ending cells, and executes only the cells within that range. (3) A function to obtain the execution results (including cell output and error information) that obtains the notebook data after execution and returns it to the client. (4) An error handling function that catches errors that occur during execution and returns them to the client along with an appropriate error message. (5) A dependency management feature that pre-installs key libraries such as NumPy and Pandas in the environment and makes them available within the notebook.

[0324] Below, we will explain the processing flow of the notebook processing microservice. (1) Receiving a request: A request containing the following data is received from a client. notebook_json: Notebook data in JSON format (nbformat compliant) mode: execution mode (all or range) start_cell: The starting index of the cell range execution (in range mode) end_cell: End index of the cell range execution (in range mode) (2) Reading the notebook: Parse the received notebook_json and read it as a Notebook object. (3) Determining the execution mode and preparation (4) Execute all cells (all mode): Execute the entire notebook as is. (5) Cell range execution (range mode): Creates a partial notebook from the specified start cell to the specified end cell, and executes only that part. (6) Execute the notebook: Use ExecutePreprocessor to execute the notebook. The kernel uses Python 3. The timeout period is set to 600 seconds. Restart the kernel if necessary before execution. (7) Obtaining the execution results: The Notebook object after execution is converted to JSON format and returned to the client along with the execution results (output, error information, etc.). (8) Error handling: If an error occurs during execution, or if an invalid parameter or mode is specified in a request error, an error message is returned with HTTP status 400. If an execution error occurs, such as a code syntax error or runtime error, detailed information about the error is returned to the client.

[0325] The following explains the environment and dependencies. (1) Execution environment: Runs on a Python virtual environment and starts the API server using uvicorn. The main libraries are -nbformat-nbconvert-jupyter_client-numpy-pandas-matplotlib. (2) Installing libraries: Install the libraries listed in requirements.txt using pip.

[0326] The test framework pytest is used for testing, covering a wide range of cases, including all cell execution, cell range execution, error handling, and dependency checking.

[0327] There are three limitations to the test. The first is a timeout; execution longer than 600 seconds will time out. Secondly, the only supported language is Python (using the Python 3 kernel). The third is security; since it includes the possibility of arbitrary code execution by the user, appropriate security measures are required.

[0328] The points to note about the test are as follows: (1) Cell index: start_cell and end_cell are specified with an index starting from 0. (2) Dependencies: If there are any additional libraries you want to use within the Notebook, they must be installed in your environment beforehand. (3) Kernel state: If necessary, restart the kernel before executing, but careful management of the kernel state is required.

[0329] This notebook processing microservice can flexibly execute notebook data provided by a client and return the results. It can meet a wide range of needs, such as executing all cells at once, executing a specific cell range, and providing detailed error messages. It can be used for a variety of purposes, including data analysis, testing machine learning models, and automatic report generation.

[0330] This system effectively manages and utilizes files uploaded by users, and realizes various data processing through the execution of chests (data processing pipelines). Below, we will explain the detailed mechanism of file and storage processing and how it works with the chest execution service.

[0331] The following explains how to upload and save files. (1) File reception: The file is received from the ChestFlow configuration GUI processor and processed by the ChestFlow execution controller. The user uploads a file through the web interface. The uploaded file is received by the ChestFlow execution controller server and processing begins. (2) File name validation and uniqueness: Duplicate checks, unique file name generation, and error handling are performed. A database is checked to see if a file with the same name already exists, and if a duplicate exists, a unique name is generated by adding a suffix to the file name. In strict mode, an error is returned if a duplicate exists. (3) Saving a file: The storage directory is checked, the file is written, and errors are handled. If the destination directory for the file does not exist, a new one is created. When writing a file, the received file is saved to the specified path. If an error occurs during saving, it is handled appropriately and the user is notified. (4) Metadata database registration: File information is saved and tags are managed. Metadata such as file name, path, user ID, and creation date and time are saved in the database. Tags associated with files are saved and used for later search and classification.

[0332] The following explains how to obtain and download files. (1) Searching for file information: The database is queried and information about the target file is obtained from the database based on the user ID and file name. (2) Checking file existence: Accesses the storage and checks whether the specified file exists on the storage. If the file does not exist, an error message is generated and notified to the user. (3) Providing a file: The file is read on the server side and a download response is generated in a format that allows the file data to be sent to the user.

[0333] The following explains how to delete files. (1) Obtaining file information from the database: Obtaining information about the file to be deleted. (2) Physical deletion of files from storage: Deletes files from the file system. If the deletion fails, a log is recorded, and if necessary, retries are performed, the user is notified, or an error handling is performed. (3) Update database: Delete the file's metadata from the database.

[0334] Below we will explain how to process and convert file contents. The uploaded file contents are analyzed and used in the chest execution. (1) Text extraction: Supported file formats are txt, .doc, .docx, and .pdf. Text files are read directly as strings. Word documents: Extract text using libraries such as Apache POI. PDFs: Extract text using tools such as PDFBox. (2) JSON conversion: Supported file formats are html and .htm. Parse the HTML content using Jsoup or similar, recursively traverse the DOM tree, and convert it to a JSON structure. (3) CSV conversion: Supported file formats are .xls and .xlsx. Excel files are read using Apache POI and cell data is converted to CSV format.

[0335] The following explains how to link with the chest execution service. The contents of the file are used in the chest execution process. (1) Message Creation: The contents of the file are imported as a message and a message is created. A message carrier is used to store the data in a MessageCarrier object and use it in the chest. (2) Using a file carrier: The FileCarrier object manages file metadata such as file name, file type, structure type, etc. The necessary file data is used at each processing step of the chest through the file carrier.

[0336] Below, we will explain file processing in query functions. (1) Acquiring a file and reading its contents: The file specified in the query function is acquired from storage, and then the contents are read in an appropriate way depending on the file structure type. (2) Data usage: The read data is analyzed and processed, and returned as a query result. The analysis results are then generated as a message for use in subsequent processing.

[0337] Error handling and logging are explained below. (1) Error handling: Exceptions that occur during file processing are caught, an appropriate error message is generated, and the error content is clearly communicated to the user, with suggestions for retry and alternatives being offered. (1) Logging: Recording errors that occur in a log file or monitoring system. Based on the log information, system problems can be analyzed (audit and debug) and used for improvement.

[0338] The following explains security and access control. (1) User authentication and permission management: Only authenticated users are allowed to access files. Accessible files are restricted for each user, preventing unauthorized access to other users' files. (2) Secure file handling: Input validation is performed to check whether file names and paths contain invalid values. Furthermore, file path operations properly handle relative paths and special characters to prevent unauthorized file access (directory traversal).

[0339] Below we will discuss performance and scalability. (1) Asynchronous processing: Reading and writing files asynchronously improves system responsiveness. Asynchronous file I / O. (2) Caching: Caches frequently accessed files, analysis results, and other data to improve processing speed.

[0340] Below, we will explain the positioning of file processing within the entire system. (1) Files as part of the data flow: Files provided by users are used as input data for the chest. Files (intermediate products) generated during the process are also managed and used in the next processing step. (2) Flexible data processing: By supporting a variety of file formats, it can flexibly respond to user needs. Furthermore, it is extensible and designed to make it easy to add new file formats and processing methods.

[0341] File and storage processing is a key component that supports the foundation of this system. It enables advanced data processing through a series of processes, starting with file uploads from users, file storage, retrieval, analysis, and integration with the chest execution service. This allows users to effectively utilize a variety of data and realize efficient business processes and data analysis.

[0342] Below, we provide a detailed analysis of message processing during function list execution. Function list execution is the process of sequentially executing a series of functions defined within a chest. Message processing, including message generation, processing, extraction, and tagging, is at the core of this process. This analysis details the functions, flow, and characteristics of how message creators and generators process messages, in particular.

[0343] First, the overall flow of message processing will be explained. (1) Obtaining and preparing a function list: Obtain a list of functions associated with the chest. Each function has its own index, condition, and properties that indicate its execution order. (2) Sequential execution of functions: Each function in the function list is executed in the order defined. Each function consists of a message creator, a query function, and a generator. (3) Message creator execution: Generate and process the required messages, including selecting, extracting, filtering, and tagging messages. (4) Query function execution: Executes queries to external services and databases and retrieves results. This includes calling AIAPIs and retrieving data. (5) Generator execution: Generates new messages based on query results or existing messages, generates response messages, formats data, etc. (6) Update messages and tags: Add or update the generated messages and tags to the message list in the chest. Tags are used for conditional branching and message selection in subsequent functions.

[0344] Next, we will explain the functions of the message creator. (1) Message generation function to generate new required messages: (e.g., user, assistant), set content, message carrier, etc. (2) Extract messages that match specific conditions from an existing message list: Use conditions such as role, tag, or content type. (3) Editing or converting the content of extracted messages: (e.g., message processing functions such as formatting text, deleting unnecessary information, and converting to a specific format.) (4) A tag application function that assigns or updates specific tags to messages. Tags indicate the attributes or status of messages.

[0345] The following explains the message creator flow. (1) Getting and setting properties: Gets the properties defined in the function. Properties include extraction conditions, processing methods, tag information, etc. (2) Message selection and extraction: Extracting target messages from a message list based on properties, such as role, tag, and index. (3) Message processing: The extracted message is processed as needed. The processing content varies depending on the property. (4) Create a new message: Create a new message as needed. The generated message is configured with content, role, tags, etc. The argument information is matched with the argument definition information to provide the parameters required to execute the query function. (5) Applying and updating tags: Tags are applied or updated to messages so that they can be properly identified in subsequent processing. (6) Returning the result: The processed or generated message is returned as the execution result of the function.

[0346] The characteristics of the message creator are listed below. (1) Flexible message manipulation: Messages can be generated, processed, and extracted in a consistent manner. Properties allow for detailed control of behavior. (2) Condition-based processing: Messages are selected and processed based on role, tag, and content conditions. Flexible processing is possible through conditional branching. (3) Use of tags: Use tags to manage message status and attributes. Tags are useful for selecting messages and making conditional decisions.

[0347] The generator functions are explained below. (1) Message Creation: Creates a new message based on the result of a query function or an existing message. Creates a response message or a message containing data. (2) Data analysis and transformation: Analyzes query results and transforms them into the required format. For example, parsing JSON data and formatting text data. (3) Information Extraction: Extracting specific information from query results or messages, including code blocks, URLs, keywords, etc. (4) Message splitting and merging: Messages can be split into multiple parts or merged as needed. Multiple replies can be generated as separate messages.

[0348] The generator flow is explained below. (1) Getting and setting properties: Gets the properties defined in the function, such as the extraction method and the format of the message to be generated. (2) Getting query results: Getting the results from the query function. The results can be in the form of data objects, text, or other formats. (3) Data analysis and transformation: Analyze the query results and extract the necessary information. Transform and format the data as needed. (4) Message generation: A new message is generated based on the extracted and converted data. The message is set with the appropriate role, content, and tags. (5) Message splitting / combining: Messages are split or combined according to their properties. This determines whether to return them as individual messages or all at once. (6) Applying and updating tags: Tags are applied or updated to the generated messages so that they can be handled appropriately in subsequent processing. (7) Returning the result: The generated message is returned as the execution result of the function.

[0349] The generator's features are described below. (1) Data-driven message generation: Dynamically generates messages based on query results. Suitable for generating AI responses and responses incorporating external data. (2) Advanced information extraction: Analyzes data and extracts information, and creates messages containing only the necessary information. Specific information such as code, data, and URLs can be extracted. (3) Message control: Properties can be used to control message splitting, merging, and the level of detail of the content. The format and number of responses can be flexibly changed.

[0350] Below, we will explain the features and advantages of message processing. (1) Modularized function execution: Message creators, query functions, and generators operate as independent modules. This design is highly extensible and maintainable. (2) Flexible control through properties: The behavior of each function can be finely configured through properties, allowing the behavior of the function to be adjusted according to the user's requirements and scenarios. (3) State management using tags: Manage the state of messages and data using tags. By utilizing tags for conditional branching and message selection, flexible processing flows can be achieved. (4) Data reuse and integration: Messages and data are shared and reused between functions, enabling efficient processing while maintaining data consistency and integrity. (5) Error handling and logging: Properly handle exceptions and errors within functions and leave logs, improving system reliability and debugging efficiency.

[0351] Message creators and generators play a central role in message processing during function list execution. Message creators extract, generate, and process messages, while generators generate new messages based on query results. Both use properties and tags to control their behavior, enabling flexible and scalable message processing. This enables the system to handle complex processing flows and diverse user scenarios, providing high-quality responses and functionality.

[0352] Below, we provide a detailed analysis of the functions and flow of QueryHelpers. The QueryHelpers class is the core of message processing during chest execution. This class provides a wide range of functions, including message extraction and conversion, data extraction from files, and information extraction from AI output results. This analysis focuses on the functions of QueryHelpers and details the functions, flow, and features of message processing during function list execution. In particular, we focus on the functions for file extraction and extraction of various information from AI output statements.

[0353] The overall flow of message processing is explained below. (1) Message selection and extraction: Extract messages that match specified criteria from the message list in the chest. The criteria can be based on message role (e.g., userQuery, response), tag, content type, etc. (2) File Data Processing: If the message contains file data (file carrier), the file is read in the appropriate format and the text data is extracted. Different extraction methods are applied depending on the file type (e.g. PDF, Word, Excel, CSV). (3) Information extraction from AI output: Extract specific information from the AI ​​response message, such as code blocks, JSON data, CSV data, and URLs. Analyze and process the extracted information and convert it into a message carrier as needed. (4) Message processing and generation: A new message is generated based on the extracted and processed data. The generated message is assigned appropriate roles and tags and is used in subsequent processing. (5) Tag application and management: Tags are applied to messages and extracted data. Tags indicate message attributes and are used for conditional branching and filtering.

[0354] The details of each of the main functions are explained below: QueryHelpers has a file extraction function that processes file data contained in messages and extracts text information. (1) File type detection: Identify the file type in the file carrier and select the appropriate extraction method. Supported file types include PDF, Word, Excel, CSV, HTML, Markdown, etc. (2) Text Extraction Techniques: PDF: Use OCR and text extraction libraries to extract text from PDF documents. Word / Excel: Use Office file passers to get text and data from documents and spreadsheets. **CSV**: Use CSV passers to read data in a structured format. (3) Integration of extracted data: Data extracted from multiple files is integrated and compiled into a single message carrier. If necessary, data preprocessing and cleansing are performed.

[0355] The ability to extract and analyze specific information from AI responses is also important. (1) Code block extraction: Detects and extracts code blocks (parts with the syntax of a specific programming language) from the response. The extracted code is used for subsequent analysis and execution. (2) Parsing JSON data: Detecting JSON-formatted text from the response, parsing it, and obtaining it as a data object. Validating the data and extracting keys to extract the necessary information. (3) CSV data analysis: CSV format text in the response is detected, parsed, and retrieved as a two-dimensional array. This is used for data formatting and aggregation. (4) URL extraction: Using regular expressions, URLs are detected from text and listed. These can be used to access or reference external resources. (5) Keyword extraction: Using natural language processing, important keywords and phrases are extracted from text for use in tagging, classification, and search engine queries. (6) Message Segmentation: Analyzes text and extracts list structures, treating each as a separate message. Multiple lists can be extracted and stored in the metadata. (7) Extraction of notebook execution data: Extracts the results of notebook execution and converts them into a re-executable format. Cell and npFormat format data can also be extracted and converted. (8) Extraction of argument information: Function argument information is extracted from the message. The data contained in the message can also be analyzed and labeled with variable names to create arguments. The argument information provides the parameters required to execute the query function via variable definition information.

[0356] The specific flow of message processing is explained below. (1) Collect Messages: Get all message data in the chest, including messages generated as a result of function execution, if necessary. (2) Message filtering: Select messages of interest based on specified criteria (role, tag, index, etc.). For example, you can select only the most recent user input or messages with a specific tag. (3) Processing file data: Among the selected messages, identify those that contain file carriers. Use the file extraction function to extract text data from the files. (4) Information extraction from AI output: Analyze the AI ​​response message and extract the necessary information (code, JSON, CSV, URL, keywords, etc.) using regular expressions, parsers, and natural language processing techniques. (5) Data organization and message generation: The extracted data is organized and stored in a message carrier. Necessary metadata and tags are added, and a new message is generated. (6) Applying and updating tags: Appropriate tags are applied to the extracted data and generated messages. The tags are used in subsequent processing (conditional branching and filtering). (7) Message List Integration: The generated message is added to the message list of the chest and integrated. The index is adjusted to maintain the order and relevance of the messages.

[0357] The features and advantages are explained below. (1) Highly versatile data extraction: Supports a wide variety of file and data formats, allowing you to obtain information from a variety of sources. (2) Advanced information analysis: It has strengths in response generation and data analysis because it can accurately extract the necessary information from the output of AI. (3) Seamless message integration: Extracted and generated messages can be naturally incorporated into existing message flows. (4) Flexible tag management: Fine control is possible using tags, making it easy to perform complex conditional branching and customization. (5) Modular design: Each function is modularized, making it easy to maintain and expand.

[0358] QueryHelpers is a class that handles messages during function list execution and has advanced data processing functions such as file extraction and information extraction from AI output, enabling the system to utilize information from a variety of data sources and provide advanced responses and functions to users.

[0359] A detailed analysis and functionality of field processing is provided below. First, let us explain ChestFieldController. ChestFieldController is a controller class that receives requests from the chest flow configuration GUI processor and calls the appropriate service method. It provides API endpoints related to the operation of chests and flows on the field.

[0360] The ChestFieldController has the following 10 main functions: (1) Getting, creating, updating, and deleting chests, (2) Managing chest data on the field, (3) Moving chests, (4) Updating chest location information, (5) Expanding sequences, (6) Controlling the expansion and contraction of sequence chests, (7) Updating message tags, (8) Updating message tags related to groups and flows, and (9) Controlling the recalculation mode. (10) Switching to recalculation mode, canceling, and executing recalculation

[0361] Next, we will explain ChestFieldService. ChestFieldService is a service class that receives requests from the controller and implements business logic. It provides functions such as creating chests, managing recalculations, and executing sequences.

[0362] The ChestFieldService has six main functions: (1) creating a chest, (2) creating a new chest according to the project status, (3) executing a sequence, (4) managing the execution of sequence chests, (5) managing recalculation mode, and (6) transitioning to recalculation mode, canceling, and recalculation execution flow.

[0363] Next, we will explain FieldObjectService. FieldObjectService is a service class that handles detailed operations on objects in fields. It provides functions such as editing, deleting, moving, and selecting chests.

[0364] The main functions of FieldObjectService are as follows: (1) Editing a chest, (2) Updating chest properties and message formats, (3) Deleting a chest, (4) Deleting a specified chest from the database, (5) Moving a chest, (6) Updating the position information of a chest and adjusting the positions of related child chests, (7) Expanding and collapsing a sequence, (8) Changing the display state of sequence chests, (9) Selecting a chest, and (10) Adding to a chest group or specifying a target chest for partial execution. (11) Update message tags, (12) Update message tags related to groups and flows.

[0365] Below we will explain in detail how to operate chests on the field. (1) Creating a chest User interaction: Place a new chest on the field and enter the required settings. Chest flow execution control process: ChestFieldController receives the request and calls the controlCreateChest method of ChestFieldService. Sets the chest state depending on the project mode (e.g., normal mode, recalculation mode). Performs appropriate processing depending on the chest type (e.g., "map", "yield", "reduce", "split"). Generates sequence chests and child chests as needed. (2) Editing Chests User operation: Changes the settings, message format, properties, etc. of an existing chest. Chest flow execution control processing: The editChest method of ChestFieldController receives the request and calls the editChest method of FieldObjectService. It validates the chest data and updates any fields that can be updated. If necessary, it rebuilds related flows and child chests. (3) Chest removal User operation: Delete a chest on the field. Chest flow execution control processing: The deleteChest method of ChestFieldController receives the request and calls the deleteChest method of FieldObjectService. The specified chest is deleted from the database, and any related flows and child chests are also processed appropriately. (4) Moving a chest User operation: Drag the chest on the field to change its position. Chest flow execution control process: The moveChest method of ChestFieldController receives the request and calls the moveChest method of FieldObjectService. The new position of the chest is saved, and in the case of a sequence chest, the positions of the child chests are also adjusted relatively. (5) Expanding and contracting sequences User operation: Click on the sequence chest to toggle between showing and hiding child chests. Chest flow execution control process: The expandSequence method of ChestFieldController receives the request and calls the expandSequence method of FieldObjectService. - Updates the expansion state of the sequence chest. (6) Selecting a chest and specifying partial execution User operation: Select a specific chest on the field and specify it as the target for partial execution. Chest flow execution control processing: The selectChest method of ChestFieldController receives the request and calls the selectChest method of FieldObjectService. - Updates chest groups and partial execution status, and adjusts existing groups as necessary. (7) Update message tag User operation: Edit message tags related to groups or flows. Chest flow execution controller processing: The updateGroupMessageTags or updateFlowMessageTags method of ChestFieldController receives the request and calls the corresponding method of FieldObjectService. The message tag information of the group or flow in the database is updated.

[0366] The details of the recalculation function are explained below. (1) Switch to recalculation mode User operation: Enter recalculation mode to perform recalculation. Chest flow execution controller processing: The enterRecalculationMode method of ChestFieldController receives the request and calls the same-named method of ChestFieldService. Sets the project mode to "recalculation". Updates the status of related chests to "wait" and organizes chest groups. (2) Execute recalculation User operation: Starts recalculation. Chest flow execution control process: The executeRecalculation method of ChestFieldController receives the request and calls the manageRecalculation method of ChestFieldService. The recalculation service identifies the target chest and performs recalculation while taking dependencies into account. Once recalculation is complete, it updates the chest status and returns the project mode to normal if necessary. (3) Canceling recalculation mode: User operation: Cancel recalculation mode. (4) Chest flow execution control processing: The cancelRecalculationMode method of ChestFieldController receives the request and calls the same-named method of ChestFieldService. It returns the project mode to normal and updates chests in the "wait" state appropriately.

[0367] Flow management will be explained below. (1) Creating, updating, and deleting flows: User operations Create, edit, or delete flows connecting chests. Chest flow execution control processing: Calls the corresponding service method through the endpoint related to the flow. Manages flow information in the database and sets the data flow between chests appropriately. (2) Update the message tag of the flow User operation: Edit the message tags related to the flow. Chest flow execution controller processing: The updateFlowMessageTags method of ChestFieldController receives the request and calls the same-named method of FieldObjectService. It updates the message tag information of the flow and manages tags when propagating data.

[0368] Below we will explain the types of chests and how to deal with them. (1) "map" type Features: Used to apply the same process to multiple datasets. Processing flow: Creates child chests for each base chest. The child chests are processed in parallel. (2) "Yield" type Features: Used to repeat the same process multiple times. Process flow: Generates the specified number of child chests. The child chests are processed sequentially or in parallel. (3) "Reduce" type Characteristics: Used to aggregate and integrate data. Processing flow: Aggregates data from multiple sources and generates results. (4) "split" type- Features: Used to divide data and apply different processing. Processing flow: Dynamically generates the required number of child chests based on the execution results.

[0369] The overall processing flow is explained below. (1) Receiving user operations: A user's action on the ChestFlow configuration GUI processor is sent as a request to the ChestFlow execution controller. (2) Controller: The ChestFieldController receives the request and invokes the appropriate service method. (3) Execution of business logic: ChestFieldService and FieldObjectService execute the business logic. (4) Database operations: Update chest, flow and project data as needed. (5) Returning a response: The processing result is returned to the chest flow configuration GUI processing body, and the state of the GUI is updated.

[0370] Field processing is an important feature that allows users to visually build and manage data processing flows on a GUI. A wide range of functions, such as creating, editing, deleting, and recalculating chests and flows, are supported by the Chest Flow Execution Control Service. By appropriately linking these components and functions, a flexible and scalable system is realized.

[0371] This project is designed around the following main object models to efficiently process complex data and exchange messages. This section provides a detailed explanation of the project's main object models and their relationships. The five main object models are UnifiedChest, Chest flow, ChestGroup, ChestSequenceChest, and MessageHelper.

[0372] UnifiedChest represents a basic data processing unit called a "chest" within the system. This chest has a wide range of functions, including data storage, processing, and display, as well as message generation and response. It is a comprehensive model with many attributes, such as location information on the user interface, cooperation with related message helpers, and state management. UnifiedChest functions as a basic unit within the data flow, and realizes complex processing by coordinating with other chests and flows. Users can place chests and set queries and message helpers for each chest to perform the desired data processing and message generation.

[0373] The key attributes of Unified Chestm are: (1) id: A unique identifier for this chest. (2) title: The name or title of the chest. This is set so that users can easily identify it. positionX / positionY: The position coordinates of the chest on the chest flow configuration GUI processing body. This visually represents the relative positions of the chests. (3) chestType: Chest type. For example, types include "reduce", "map", "split", and "yield". (4) query: Query information for the chest to process, which is executed through the message helper. (5) response: The response data obtained as a result of executing the query. (6) messageHelperId: The ID of the message helper associated with this chest, used to generate and transform messages. (7) messageHelperProperties: Property information related to the message helper. Contains detailed settings. (8) tagInventory: A list of message tags. Tag information shared between chests and messages. (9) state: The current state of the chest. Examples include "wait", "inprogress", and "completed". (10) createdAt / updatedAt: The creation and last update dates of the chest. Used for data management and history tracking. (11) isExpanding: A flag indicating whether the chest is expanded. (12) autoSequenceItemGeneration: Sets whether to automatically generate items in a sequence. (13)displayControl: Detailed settings for controlling the display of chests.

[0374] Chest flow is a model that defines the data flow and dependencies between chests. It manages the transmission of information from a specific chest to another chest, the order of processing, the type of flow, etc. Chest flow manages the relationships between chests and defines how data and messages flow. This makes it possible to combine multiple chests to build complex processing flows and pipelines. The main attributes are as follows: (1) id: A unique identifier for the flow. (2) instructionType: The instruction type of the flow. Examples include "normal" (normal flow), "base" (basic flow), and "precede" (preceding flow). (3) expressionType: The expression type of the flow, which indicates the type of processing and the characteristics of the flow. (4) isReference: A boolean value indicating whether this flow is a reference flow. A reference flow is treated as a reference, not a copy of the data. (5) sourceId: The ID of the chest from which the data originates. (6) targetId: The ID of the chest that will receive the data. (7) messageTags: Message tags associated with a flow, used for filtering data between flows and for conditional branching. (8) messageTagDefinition: Message tag definition information. It describes the tag structure and attributes in detail. (9) messageIndex: An index indicating the order and position of a message. (10) displayControl: Control settings for displaying the flow. (11)ownerProjectId: The ID of the project to which this flow belongs.

[0375] ChestGroup is a model for grouping multiple related chests together. Chests in a group share common properties and message tags, allowing for unified management. Using ChestGroup makes it possible to configure and operate multiple chests at once. For example, it is possible to group chests with a specific tag, update message tags at once, or perform operations on the entire group. The main attributes are as follows: (1) id: A unique identifier for the group. (2) groupChestId: The ID of the chest that represents the group. Generally, this refers to the main chest of the group. (3) currentIndex: The current index or position within the group. Used during sequence processing. (4) baseChestSequence: A flag indicating whether this group is a base chest sequence. (5) messageTags: Message tags shared across the group. (6) messageTagDefinition: Definition information of the message tag. (7)ownerProjectId: The ID of the project to which the group belongs.

[0376] ChestSequenceChest is a model that manages each chest in a sequence of chests. It defines the order and execution order of chests within the sequence. ChestSequenceChest manages the execution order of chests and controls sequence processing. For example, it is used when building a data processing pipeline and executing chests in order. Chests in a sequence receive the results of the previous chest and pass them on to the next chest. The main attributes are as follows: (1) id: A unique identifier for the sequence chest. (2) sequenceId: The ID of the sequence to which this chest belongs. (3) chestId: ID of an individual chest. (4) ownerProjectId: The ID of the project to which the sequence chest belongs. (5) sequenceIndex: An index indicating the order of the chest within the sequence.

[0377] MessageHelper is a model for generating and processing messages, managing tags, and integrating properties. It supports chest message processing and enables complex message flows and conditional processing. MessageHelper is a tool for highly customizing chest message processing. By selecting or configuring a message helper, users can flexibly control message generation methods, conversion logic, tag application, conditional branching, and more. This allows for detailed design of message flows between chests and the realization of complex processing. The main attributes are as follows: (1) id: A unique identifier for the message helper. (2) name: The name of the message helper. It is set so that users can easily identify it. (3) processType: Message processing type. Examples include "chat", "function", and "data". (4) resultType: The result type of the operation. Examples include "reduce", "map", "yield", and "split". (5) queryFormat: Query message format. Defines the structure and format of the message. (6) responseFormat: Response message format. (7) functionList: A list of functions used for message processing. Each function has a specific processing logic. (8) messageHelperProperties: Properties related to the message helper. These hold detailed processing settings. (9) tagInventory: Message tag inventory, which contains a list of available tags and their definitions. (10)ownerId: The ID of the owner of the message helper.

[0378] The detailed relationships between the models are explained below. (1) In the relationship between UnifiedChest and MessageHelper, UnifiedChest has a messageHelperId and is associated with MessageHelper through that ID. How a chest generates and processes messages is determined by the associated message helper. The message helper provides the message processing logic for the chest. (2) In the relationship between UnifiedChest and Chest flow, Chest flow defines the data flow between chests using sourceId and targetId. These IDs are UnifiedChest IDs. The role of Chest flow is to define how data and messages are exchanged between chests, as well as the order and conditions of processing. (3) In the relationship between UnifiedChest and ChestGroup, a chest can belong to a ChestGroup. A ChestGroup groups multiple chests and applies common settings and tags. Grouped chests can be controlled and their settings changed collectively. This allows chests with common processes to be managed collectively. (4) In the relationship between ChestGroup and Chest flow, Chest flow can be defined between chests in the group or between the group and other chests. This is used to have a unified flow throughout the group or to control data flow under certain conditions. (5) In the relationship between ChestSequenceChest and UnifiedChest, ChestSequenceChest is associated with UnifiedChest by chestId. It points to each chest in the sequence and manages the execution order and relationships of chests in sequence processing. (6) In the relationship between MessageHelper and message processing flow, MessageHelper provides the core logic and settings for the chest's message processing flow. It controls the complex message flow between chests by realizing message generation, transformation, conditional branching, etc. through function lists, properties, and tag management.

[0379] The overall data flow and processing flow will be explained below. (1) Chest placement and configuration: The user places UnifiedChest on the chest flow configuration GUI processor and sets MessageHelper and queries for each chest. (2) Chest flow definition: If necessary, define the relationships between chests as chest flows, which determine the data flow and processing order. (3) Creating a Chest Group: Chests with common settings and tags are grouped together as a ChestGroup. (4) Setting the sequence: If sequence processing is required, use ChestSequenceChest to define the order in which chests are executed. (5) Message Creation and Processing: Each chest creates and processes messages using an associated MessageHelper, which uses a list of functions and properties to execute the message logic. (6) Data flow execution: Data and messages flow between chests according to the Chest flow. Conditional branching and tag filtering are applied. (7) Acquiring and displaying results: The processing results are stored in the response of each chest and presented to the user.

[0380] Additional relevant information is provided below. (1) Utilizing message tags: Message tags are used to add metadata to messages and chests, and are used for data filtering and conditional branching. Using tags allows for flexible flow control, such as processing only under certain conditions. (2) Conditional Processing and Function Lists: Within MessageHelper's function lists, you can use condition objects to control whether a function is executed under certain conditions, allowing you to dynamically change the processing flow of messages. (3) Property integration and management: The properties of message helpers and chests are integrated during processing. Consistent configuration management is possible by merging properties and applying default values. (4) Scalability and flexibility of the entire system: These models and their relationships give the system high scalability and flexibility. New processing logic and data flows can be easily added or changed, making it possible to handle large-scale data processing and complex business logic.

[0381] The main object models in this project, UnifiedChest, Chest flow, ChestGroup, ChestSequenceChest, and MessageHelper, each play an important role and interact with each other to realize complex data processing and message flow. Understanding the detailed attributes and functions, and the relationships between the models, allows for a deep understanding of the operation of the entire system.

[0382] Below we will explain the functions, flow, and features of project processing. This system provides users with the ability to create, update, delete, and select projects. The Chestflow execution controller and Chestflow configuration GUI processor are linked, with the logic for the Chestflow execution controller implemented in the following files: ProjectController.scala-Projects.scala-ProjectRepository.scala-ProjectService.scala, and the logic for the Chestflow configuration GUI processor implemented in the following files: projectAPI.js-Projects.js-ProjectList.js-ChestField.js.

[0383] The following are the function details. (1) Acquisition of a project Chestflow execution control processing: The getProjects method in ProjectController.scala obtains the user ID based on the authentication information and retrieves the projects related to that user. It calls the getProjectsByUserId method in ProjectService.scala, and then retrieves the projects from the database using findByUserId in ProjectRepository.scala. Chestflow configuration GUI processing: The getProjects function in projectAPI.js sends a request to the API endpoint to retrieve a list of projects. The status of the projects retrieved in Projects.js is managed, and ProjectList.js displays them as a list.

[0384] (2) Creating a project Chestflow execution control processing: The createProject method in ProjectController.scala retrieves ProjectData from the request body and creates a new project. The new project is inserted into the database using the create method in ProjectRepository.scala through the createProject method in ProjectService.scala. Chestflow configuration GUI processing: The createProject function in projectAPI.js sends the new project data to the API. ProjectList.js displays an input form where the user can enter the project name, notes, and tags to create the project.

[0385] (3) Project Update Chestflow execution control processing: The updateProject method in ProjectController.scala updates the project with the specified project ID. The updateProject method in ProjectService.scala updates the database using the update method in ProjectRepository.scala. Chestflow configuration GUI processing: The updateProject function in projectAPI.js sends the updated project data to the API. An edit button is provided in ProjectList.js, allowing users to update project information.

[0386] (4) Delete the project Chestflow execution control processing: The deleteProject method in ProjectController.scala deletes the project with the specified project ID. It is deleted from the database by the delete method in ProjectRepository.scala via the deleteProject method in ProjectService.scala. Chestflow configuration GUI processing: The deleteProject function in projectAPI.js sends a deletion request to the API for the specified project. A delete button is provided in ProjectList.js, allowing users to delete projects.

[0387] (5) Current project settings Chestflow execution controller processing: The setCurrentProject method in ProjectController.scala sets the user's current project. The setCurrentProject method in ProjectService.scala updates the database via the setCurrentProject method in ProjectRepository.scala. Chestflow configuration GUI processing: The setCurrentProject function in projectAPI.js makes a request to the API to set the selected project as the current project. Selecting a project in Projects.js sets that project as the current project.

[0388] The following is an explanation of the flow. (1) User authentication: The user has an authentication token, which is required for every request. (2) Data Acquisition and Display: The Chest Flow configuration GUI processor uses the getProjects function to acquire the list of projects for the user. The acquired data is displayed in the ProjectList component. (3) Project operations: To create a project, click the Create New button. A dialog will appear, allowing you to enter project information and create the project. To update a project, click the Edit Project button, allowing you to update the information in the dialog. To delete a project, click the Delete button, and the project will be deleted. When selected, clicking on the project name will set that project as the current project and take you to the details screen. (3) Operations on the details screen: The ChestField.js component is displayed, allowing detailed operations related to the project.

[0389] Below, we will explain the features of project processing. (1) MVC architecture: The Chestflow execution control system is divided into Controller, Service, Repository, and Model, with clear separation of responsibilities. (2) Asynchronous processing: Communication between the ChestFlow configuration GUI processor and the ChestFlow execution controller is performed asynchronously, improving the user experience. (3) Authentication and Security: All API requests require an authentication token and a CSRF token, enhancing security. (4) User-friendly UI: Projects can be filtered and you can narrow down projects using tags. It has an intuitive dialog-based project creation and editing interface. (5) Reusability and scalability: The component-based chest flow configuration GUI processing design makes it easy to reuse and expand functions. The business logic is consolidated in the service layer, making it easy to add or change functions. (6) Error handling: In the Chestflow configuration GUI processor, an error message is displayed to the user when an operation fails, allowing the user to recognize the problem.

[0390] This system is designed with a robust architecture, a user-friendly UI, and scalability and maintainability in mind, with a Chestflow execution controller and a Chestflow configuration GUI processor working together to enable user-centered project management.

[0391] The following explains the functions, flow, and features of Prompt Holder. Prompt Holder allows users to save, manage, and utilize data of various content types, such as text, JSON, Markdown, code, CSV, keywords, and URLs. It is designed to allow users to efficiently reuse frequently used templates, code snippets, and document fragments.

[0392] First, let's explain the main functions of Prompt Holder. (1) Save function: Users can create prompt holders with information such as title, content type, actual content, tags, etc., which allows users to save information systematically. (2) Editing function: You can edit existing prompt holders and update their contents and related information, thereby keeping the information up-to-date and accurate. (3) Deletion function: By deleting unnecessary prompt holders, you can easily organize and manage data. (4) Search function: You can search for prompt holders using tags or titles. Filtering by tags is especially useful for quickly finding relevant information. (5) Insert function: The saved prompt holder content can be inserted directly into the editor or input field at the cursor position, allowing for efficient text entry and code writing.

[0393] Prompt Holder Flow (1) Creating a prompt holder: The user selects text or code, etc., and opens the prompt holder management screen. They enter the title, content type, content, and tags, and save it. The data is received on the server side and saved in the database as a new prompt holder. (2) Edit prompt holder: The user selects an existing prompt holder, enters edit mode, updates the required information, and saves it. The changes are accepted on the server side, and the corresponding entry in the database is updated. (3) Deleting a prompt holder: The user selects the prompt holder they want to delete and executes the delete action. The delete request is processed on the server side, and the corresponding entry is deleted from the database. (4) Search prompt holder: User enters tags or keywords into the search bar. The query is processed on the server side and a list of prompt holders that match the criteria is returned. User can browse the results and select the prompt holder they need. (5) Insert content: The user selects the prompt holder they want to insert and executes the insert action. The selected content is inserted at the cursor position.

[0394] The following explains the features of prompt holders. (1) Support for various content types: It can handle not only text but also various data formats such as JSON, Markdown, code, CSV, keywords, and URLs. (2) Organizing and searching by tags: By using tags, you can effectively classify and search related prompt holders. (3) User-friendly UI: Intuitive operation is possible using modal windows and forms, reducing learning costs. (4) Improved reusability: By saving frequently used text and code snippets, you can significantly improve your work efficiency. (5) Real-time updates: Operations such as creating, editing, and deleting are reflected immediately, providing a smooth user experience.

[0395] Below we explain the technical details of Prompt Holder. (1) Chestflow GUI processor: It uses React and adopts a component-oriented design. It properly manages state and API communication, and responds quickly to user interactions. The PromptHolderManager component manages functions such as creating, editing, deleting, searching, and inserting prompt holders. (2) Chestflow Execution Controller: It uses Scala and the Play framework. The PromptHolder class is defined as the data model and interacts with the database. It uses the repository pattern and aggregates data access logic into the PromptHolderRepository. It has a PromptHolderService as the service layer, which is responsible for business logic. (3) API endpoint: Provides a RESTful API and supports prompt holder CRUD (Create, Retrieve, Update, Delete) operations. Equipped with authentication and authorization functions, it ensures the security of each user's data.

[0396] Below we explain the use cases of prompt holders. (1) Saving code snippets: You can save frequently used code snippets and insert them quickly during development. (2) Managing templates: You can save standard email and document templates and use them as needed. (3) Accumulating learning notes: You can save what you have learned and important points as notes and refer to them later. (4) Organizing keywords and tags: Manage keywords and tags related to the project to improve information searchability.

[0397] Promptholder is a powerful tool for increasing user productivity. It makes it easy to store, manage, and reuse information, contributing to work efficiency and time savings. It has a technically robust design, and is highly scalable and maintainable.

[0398] Message helpers prepare important functions in advance in the chest flow, such as message generation, conversion, tag management, and property integration. This allows users to implement a variety of functions in their chests simply by selecting the most suitable message helper when creating a chest. Detailed settings can also be changed when registering a chest. During chest execution processing, message helpers support message processing for each chest.

[0399] In Chest Flow, the Message Helper fulfills four roles: (1) Message Generation and Conversion: The message helper generates the messages required for the chest execution. Based on the function list, it uses message creators and generators to create and convert messages. (2) Tag management: Manages tag information shared between chests and controls message flow. Tag inventory is used to process tags in messages appropriately. (3) Property integration and management: The properties required by each chest are integrated and the settings required at runtime are centrally managed. Properties are merged and default values ​​are applied. (4) Conditional Branching: Message Helper dynamically controls the flow of message processing using condition objects and tag conditions. It switches the execution of functions and the generation of messages depending on the conditions.

[0400] Message Helper is the core of message processing in Chestflow. It provides a wide range of functions, such as message generation and conversion, tag management, property integration, and conditional processing, and supports the flexibility and extensibility of Chestflow as a whole. This makes it possible to efficiently implement complex data processing and business logic.

[0401] The specific role of the message helper in the flow is as follows: (1) Starting the Chest Execution Process: When a chest is executed, it first obtains the associated message helper, which provides the message format and processing logic depending on the chest type and configuration. (2) Message preparation and conversion: The executor obtains message format and tag information from the message helper, executes the message helper's function list in order, and generates and converts messages and tags in each function. (3) Function execution and result integration: The message helper maintains a list of functions that define the steps of message processing. Each function combines a query function, a message creator, and a generator to process the message or obtain external data. The results of the function execution are integrated by the executor and used in the next step. (4) Conditional Processing and Flow Control: Condition objects in the message helper allow for control such as executing functions only under certain conditions. This allows for flexible message processing flows and dynamic control of the entire chest flow. (5) Chest result generation: Finally, a chest response is generated based on the message and tag information obtained from the message helper. This optimizes the data flow within the chest flow and collects and generates the necessary information.

[0402] The following explains the details of the Message Helper's function and flow. The Message Helper is an important component of the Chestflow execution control service, which processes and generates messages, manages tags, and integrates properties. It mainly consists of the following four classes: (1) MessageHelperServices: Service classes that provide the main business logic of the Message Helper. (2) MessageHelperController: A controller class that provides API endpoints related to the Message Helper. (3) MessageHelper: A model class for message helpers, defining the data structure of message helper objects. (4) MessageHelperRepository: A repository class that interacts with the database.

[0403] Below are details of each component. The role of MessageHelperServices is to provide business logic such as creating, updating, deleting, and retrieving message helpers, as well as to manage function lists, add, update, and delete conditions, and manipulate the internal data structures of message helpers, such as merging properties and managing tags. Its six main functions are as follows: (1) create method: Creates a new message helper. (2) findById method: Gets the message helper for the specified ID. (3) update method: Updates an existing message helper. (4) delete method: Deletes the message helper with the specified ID. (5) Methods for adding, inserting, updating, and deleting function lists. (6) Methods for adding, updating, deleting, and searching conditions.

[0404] The role of MessageHelperController is to receive requests from clients, call the appropriate service method, provide API endpoints related to message helpers, validate requests and format responses. There are six main endpoints: (1) findById: Get details of the message helper. (2) create: Creates a new message helper. (3) update: Updates an existing message helper. (4)delete: Deletes the message helper. (5) Endpoints for adding, updating, and deleting functions. (6) Endpoints for adding, updating, deleting, and searching conditions.

[0405] MessageHelper is a model class whose role is to define the data structure of the message helper and to hold the message helper's properties, function list, tag inventory, etc. There are seven main fields: (1) id: Message helper identifier. (2) name: The name of the message helper. (3) processType: Processing type (chat, function, data, etc.). (4) resultType: Result type (reduce, map, yield, split, etc.). (5) functionList: A list of function data. (6) messageHelperProperties: Message helper properties. (7) tagInventory: Tag inventory.

[0406] The role of MessageHelperRepository is to interact with the database and implement the CRUD (Create, Read, Update, Delete) operations of the MessageHelper. It has the following five main methods: (1) findById: Retrieves the message helper with the specified ID from the database. (2) create: Inserts a new message helper into the database. (3) update: Updates an existing message helper. (4) delete: Deletes the message helper from the database. (5) A method to get a message helper based on the user ID.

[0407] Message helpers enable complex user-defined message processing flows through message generation, processing, and tag and property management.

[0408] Creating and updating a message helper is explained below. (1) Creation flow: The client sends the message helper data, the create endpoint of MessageHelperController receives the request, validates the request data, calls the create method of MessageHelperServices, performs the necessary initialization in the service class, and saves it to the database via MessageHelperRepository. (2) Update flow: The client sends update data, the update endpoint of MessageHelperController receives the request, validates the request data, calls the update method of MessageHelperServices, merges and validates the data in the service class, and updates the database through the repository.

[0409] Below, (in message helper?) Function list management Flexibly build message processing flows through add, insert, update, and delete functions. Each function has components such as query functions, message creators, and generators, and includes properties and tags.

[0410] Condition management uses ConditionObject and TagCondition to achieve complex conditional branching and filtering. Message processing logic can be dynamically changed by adding, updating, or deleting conditions.

[0411] Regarding property and tag merging, we merge the properties of the entire message helper with the properties of each function to integrate the settings required at runtime. We manage the tag inventory and organize the tag information shared between messages.

[0412] The documents "Chest Execution Service.md" and "Analysis and Functional Description of Chest Generation Execution Process.md" explain the execution process of chests (a collection of messages or processing units) and the service that controls it, and explain the main processing steps involving message helpers, such as creating executors and the execution flow of functions, converting messages and tags, merging properties, obtaining and executing function lists, saving results, and handling errors, focusing on the controlExecutorProcess method.

[0413] Message Helpers are the core components for message processing, allowing for user-defined message creation and processing, and the implementation of complex conditional logic. Services, Controllers, Models, and Repositories work together to manage and manipulate data, provide APIs, and implement business logic. Understanding these components and their flow is important for extending and maintaining the entire system.

[0414] Below is an analysis of the functions and features of message processing related files. The message processing related files build a message processing system for managing and distributing query information and responses (AI responses, API query results, uploaded files, etc.) between chests. A message is designed as a central concept for uniformly handling data content, metadata, and related properties.

[0415] We will analyze each file related to message processing. First, we will explain MessageData.scala. Its main roles are as follows: (1) Definition of the basic class for message data: A MessageData class is provided to manage message IDs, execution IDs, indexes, queries, message contents, and message tags. (2) Message and tag management: Messages are represented by the Message class and have a role (e.g., "systemMessage," "query," or "response"), content, and tag. Message content holds text data or file data via MessageCarrier or FileCarrier. (3) Defining tags and properties: Classes for managing global tags and properties are provided, allowing for centralized management of metadata attached to messages.

[0416] The distinctive features of MessageData.scala are that it handles messages and related data in a unified data structure, facilitating data exchange between chests, allowing additional information and settings to be added to messages through tags and properties, and clearly managing the hierarchical structure and dependencies of messages.

[0417] Next, we will explain MessageCarrier.scala. Its main roles are as follows: (1) Definition of a carrier class that holds message content: MessageCarrier holds the specific content of a message (text, numbers, JSON data, etc.). (2) Data type management and validation: Define the DataType trait to represent various data types (string, number, Boolean, JSON, array, object, etc.). For each data type, define value validation and data structure to ensure that message data is in the correct format. (3) Message content manipulation: Message values ​​can be extracted and set, and text content can be retrieved and set. Editing can be controlled by locking / unlocking the message carrier. (4) Error handling: When an error occurs, a message carrier containing an error message and detailed information can be generated.

[0418] The distinctive features of MessageCarrier.scala are that it strictly manages message contents based on data types to maintain data consistency, it supports flexible data types to handle various types of message contents, and its error handling function makes it easy to debug when unexpected problems occur.

[0419] Next, we will explain FileCarrier.scala. It has the following three main roles: (1) Definition of a carrier class that holds file data: FileCarrier manages the file name, type, structure, list, maximum number, etc. (2) Defining file types: Define the FileType trait (a mechanism for extending class functionality) to represent file types such as images, videos, audio, PDFs, text, etc. Each file type has a corresponding file extension, which is used for file validation. (3) File validation and manipulation. It verifies whether a file name list meets the specified file type and maximum number restrictions. It is possible to create new file carriers and set values ​​for existing carriers.

[0420] The distinctive features of FileCarrier.scala are that it handles file data in a unified manner, simplifying file operations within the message system, automating file validation by linking file types and extensions, and applying file management policies such as limiting the maximum number of files.

[0421] Next, we will explain messageFormat.scala. It has three main roles: (1) Define message format and its behavior: MessageFormatConfig holds message format configuration (name, whether to use a file, file carrier, message carrier, whether to use a query or response, etc.). MessageFormatBehavior trait defines behavior such as message conversion and validation for a specific message format. (2) Implementation of specific message formats: For example, specific formats such as TextTypeMessageFormatBehavior and StandardMessageFormatBehavior are implemented. Each format has a corresponding message structure and conversion logic. (3) Message format factory class: MessageFormatFactory provides the appropriate message format and its behavior based on the specified name. It provides a list of available message formats, enhancing extensibility.

[0422] Finally, we will explain messageFormat.scala. Its distinctive features are that it abstracts message formats and is designed to handle different message formats flexibly, it makes it easy to add new message formats, and it is highly extensible for the system, and it encapsulates the behavior of each format, improving maintainability.

[0423] The relationships and characteristics of the entire system are as follows: (1) Unified data management: Different types of data, such as messages and files, are handled under the common concept of a carrier, enabling unified data manipulation. Text data and file data are managed in a consistent manner through MessageCarrier and FileCarrier. (2) Extensibility and flexibility: Abstracted data types, file types, and message formats make it easy to add new functions and data formats. New message formats can be dynamically generated and added using MessageFormatFactory. (3) Metadata management: Metadata related to messages can be systematically managed through tags and properties, and additional information about data can be handled centrally. Using global tags makes it easy to share and identify data between chests. (4) Data validation and integrity. Strict validation based on data type and file type ensures the reliability and integrity of data within the system. A mechanism is built in to eliminate the input of invalid data or data in unexpected formats.

[0424] Other key features include error handling and logging. The error handling function makes it easy to debug and output logs when problems occur, contributing to improved system reliability. When an exception occurs, a detailed stack trace is obtained, allowing developers to quickly identify the problem.

[0425] These files provide the foundation for efficient and flexible message processing between chests. Uniform handling of message and file data structures, formats, and carriers facilitates data exchange and processing, improving the scalability and maintainability of the entire system. Furthermore, functions such as data validation and error handling enable highly reliable system operation.

[0426] This article explains the cooperation with the Chest Flow Configuration GUI Processor and display management. The cooperation between the Chest Flow Configuration GUI Processor and the Chest Flow Execution Controller is an important point when the user operates messages and files. Here, we will explain how the Chest Flow Configuration GUI Processor uses the data structure of the Chest Flow Execution Controller to manage the display, as well as its specific functions, flow, and features in nine points.

[0427] (1) Sharing and synchronization of data structures: The data type and format information defined in the MessageCarrier and FileCarrier of the Chestflow execution controller is received by the Chestflow configuration GUI processor, and a UI is dynamically generated based on this (utilizing the data definition of the Chestflow execution controller).The data type information defined in DataType is used to render appropriate input fields (text boxes, numeric inputs, check boxes, file upload fields, etc.) in the Chestflow configuration GUI processor (utilizing data types).

[0428] (2) Dynamic form generation: Components of the Chestflow configuration GUI processor (e.g., MessageEditor) analyze the message format information provided by the Chestflow execution controller and generate a dynamic form that allows users to input and edit messages (construction of a message editor). An appropriate input component is displayed depending on the data type. For example, a text area is used for string types, a number field for numeric types, and a code editor is used for JSON types (field rendering).

[0429] (3) Two-way binding of user input and data: The Chest Flow configuration GUI processor stores the user input values ​​as state data and allows them to be reflected in the data structure of the Chest Flow execution controller in real time (state management). The user input collected by the Chest Flow configuration GUI processor is converted into the data format expected by the Chest Flow execution controller and sent via the API (data assembly).

[0430] (4) Validation and error handling: The Chest Flow configuration GUI processor performs initial input checks and provides immediate feedback to the user (client-side validation). For example, detecting missing required fields or invalid formats. The validation results of the Chest Flow configuration GUI processor are used as third-party information, and final data validation is performed by the Chest Flow execution controller. Error messages from the Chest Flow execution controller are displayed to the user in an easy-to-understand manner by the Chest Flow configuration GUI processor (cooperation with server-side validation).

[0431] (5) Display control and improved user experience: Using expType, the expType field of the MessageCarrier in the Chestflow execution controller is referenced to control whether specific fields are displayed or hidden, and whether they can be edited. This allows users to see only the information they need, keeping the UI simple. Depending on the type and content of the message, the display method in the Chestflow configuration GUI processor can be customized (custom rendering). For example, Markdown-formatted text can be displayed as rich text, or code blocks can be displayed with syntax highlighting.

[0432] (6) Component reusability and extensibility: Chestflow GUI components such as TextEditor, NotebookEditor, and CSVEditor are designed to be generic so that they can handle a variety of data types. This makes it easy to accommodate new data types and display formats (generic component design). In the Chestflow GUI components, when a user performs a specific operation (e.g., right-click) in an input field, a support function (prompt holder) is activated, which provides template insertion and completion (utilization of prompt holder).

[0433] (7) File operation interface: Based on the information from FileCarrier, the Chestflow configuration GUI processor generates a file upload UI. It presents restrictions such as allowed file types and maximum upload numbers to the user in advance (File upload). It displays a list of uploaded files, previews them if supported, and provides download links (File preview and download).

[0434] (8) Optimized user interaction: Dynamically update relevant fields and options based on user input to provide real-time feedback. For example, additional configuration items that only appear when a specific data type is selected. Use UnifiedChest state information to visually indicate the current state of each chest (e.g., not configured, in progress, completed, etc.) to visualize its status.

[0435] (9) Communication with API and data synchronization: The Chestflow configuration GUI processor calls the API of the Chestflow execution controller in response to user operations to save, update, and retrieve data (sending and receiving data). If a communication error or server error occurs, it displays an appropriate error message to the user and handles the error by encouraging them to try again or perform another operation.

[0436] In cooperation with the Chestflow Configuration GUI Processor and display management, the Chestflow Configuration GUI Processor faithfully reflects the data structure and rules defined in the Chestflow Execution Control Body, while providing an intuitive and easy-to-use interface for users. By combining functions such as dynamic form generation, real-time validation, and prompt holders, the user experience is improved while maintaining data integrity.

[0437] Let's explain user-related processing. First, AuthController is a controller of the Play framework that processes HTTP requests for user authentication and account management. It has the following seven main functions: (1) Login function: Authenticates the user name and password received from the client. If authentication is successful, a JWT (JSON Web Token) is generated and returned as a response. This token is used to identify the user in subsequent requests. (2) Logout function: Invalidates the token of an authenticated user, which ends the session and requires authentication again unless the user logs in again. (3) User registration function: Create a new user. Register the user with the username and password received from the client. During registration, a duplicate username check is performed to prevent registration with an already existing username. (4) User deletion function: Deletes a user with a specified user ID. This operation is assumed to be executable only by users with administrator privileges. (5) Delete your own account: The authenticated user can delete their own account. (6) Password change function: Updates the password of an authenticated user to a new one. (7) User list acquisition function: Acquires information on all registered users. This operation is assumed to require administrator privileges.

[0438] Let's explain Users.scala. User is a case class that represents user information. There are seven main fields: (1) id: A unique identifier for the user. (2)username:User name (3) password: Password. Hashing is recommended for practical applications. (4) token: JWT token used for authentication (optional). (5) storageLimit: The maximum storage capacity that a user can use. (6) projectLimit: The maximum number of projects a user can create. (7)createdAt: The date and time the account was created. Data is converted to and from the database using the fromResultSet and toPreparedStatement methods.

[0439] Let's look at UserRepository.scala. UserRepository is responsible for database access. It has the following 10 methods: (1)findById: Search for a user by ID. (2) findByUsername: Search for a user by username. (3) findByToken: Search for a user by token. (4) create: Inserts a new user into the database and returns the generated ID. (5) updateToken: Updates the user's token. Used when logging in and out. (6)delete: Delete a user. (7) isUsernameUnique: Checks whether the username is already in use. (8)updateUser: Updates user information. (9)updatePassword: Update your password. (10)listUsers: Get a list of all users.

[0440] This section explains UserService.scala. UserService implements business logic. It uses UserRepository to provide the following eight user-related operations: (1)getUserById: Get user information from ID. (2) getUserByUsername: Get user information from the username. (3) createUser: Creates a new user. Checks the uniqueness of the username. (4) updateUser: Updates user information. (5)deleteUser: Delete a user. (6) updateToken: Updates the token. (7)updatePassword: Update your password. (8)listUsers: Get a list of all users.

[0441] This section explains authAPI.js. authAPI.js is a utility that communicates from the Chestflow configuration GUI processor to the Chestflow execution controller API. It has the following six main functions, each of which calls the corresponding endpoint of the Chestflow execution controller and handles responses and errors. (1) getCsrfToken: Gets the CSRF token. This is necessary as a security measure. (2) login: Log in using your username and password and obtain a token and CSRF token. (3) logout: Log out. The token is invalidated on the server side. (4)register: Register a new user. (5)changePassword: Change your password. (6)deleteMyAccount: Delete the user's own account.

[0442] This article explains Account.js. Account.js is an account management page for a Chestflow-based GUI processor using React, and has the following four functions: (1) State management: Manage tokens and user information using the useState hook and AppContext. (2) Form manipulation: Providing forms for login, registration, and password...

Claims

1. A computer-implemented API usage support system that operates on a computer system equipped with multiple processors and memories and supports complex data processing in cooperation with an application programming interface (API) of an external artificial intelligence (AI) system, a chest flow configuration GUI processor that allows multiple data processing nodes (chests) to be visually created, connected, and selected on a canvas, generates a flow structure that defines the data flow between the chests, allows the processing order and dependencies for each chest to be defined, and provides a graphical interface (GUI); a database unit that stores a plurality of tables including at least account information, project information, chest detail information, connection relationship information between chests, message processing support helper information, AI model information, upload data file information, script data, and data flow identification information; a chest flow execution control unit that performs input and output with a database unit based on sequential operation requests from the GUI, creates, deletes, places, and updates chests, controls data flow, and saves and updates dependencies, enables the construction of a data flow by graphically selecting an existing chest when placing a new chest, sequentially executes processing steps associated with the chest, constructs and sends messages to be sent to an API of an external AI system, obtains corresponding responses, and executes processing in association with the chest; The data flow construct, the database unit, and the chest flow execution control unit are linked via a network, and a complex processing flow including dialogue with an external AI system can be constructed and executed based on visual and sequential inputs from the user. API usage support system.

2. a notebook executor that safely and virtually executes scripts or structured queries associated with the chests in the chest flow execution control body and saves and outputs the execution results in a format that can be used for subsequent processing within the system; and a file storage that stores and manages the data files uploaded by users and files generated by the system. The API usage support system according to claim 1.

3. The chest flow execution control unit further comprises a calculation processing support module that transmits a script associated with the chest and corresponding input data to an API of an external AI system, acquires a response from the API, analyzes and formats the response as a processing result, and then passes the response to the chest or a subsequent process. The API usage support system according to claim 1.

4. The chest flow execution control unit is characterized in that it includes a text preprocessing unit that analyzes unstructured or semi-structured text data and extracts structured data formatted in a format that can be processed by the API of an external AI system. The API usage support system according to claim 1.

5. The chest flow execution control unit controls the execution order and dependencies of data processing across multiple chests based on the construction information of the data flow defined by the chest flow configuration GUI processing unit, generates and sends queries from each chest to the API of the AI ​​system in a consistent message format according to the definition of that chest, stores the obtained API responses as messages corresponding to each chest, and the messages are propagated and processed sequentially in subsequent chests while undergoing content conversion, thereby dynamically updating the entire processing flow in real time and enabling feedback control of output throughout the entire system. The API usage support system according to claim 1.

6. The chest functions as a basic unit of the data processing, and has at least one or more different operation modes, such as a map type chest that applies the same processing in parallel to multiple target data sets, a yield type chest that sequentially repeats the same processing, a reduce type chest that integrates multiple input data, and a split type chest that divides input data and applies different processing to it, and these chests are visually displayed as objects in a field on the user interface of the chest flow configuration GUI processing body, and a user can configure the entire data flow by setting visual flow objects between multiple chests in the field. The API usage support system according to claim 1.

7. The chest flow execution control unit includes a partial execution unit that selectively executes only a portion of chests selected by a user from among a plurality of chests included in the data flow, and the partial execution unit generates a shot data structure that records the input / output states of a group of target chests as snapshots based on user designation, and performs control to selectively execute the portion of chests while checking and comparing the states of the portion of chests with other chests based on the shot data structure. The API usage support system according to claim 1.

8. The chest flow execution control unit further comprises a recalculation unit that performs recalculation processing based on dependency relationships and re-executes related flows for multiple chests included in the data flow, and the recalculation unit enables the re-editing of the configuration content of a selected group of chests in response to a range specification input by a user on a GUI, and automatically verifies and resolves consistency with dependent chests based on the editing results, and then executes recalculation processing for the relevant range. The API usage support system according to claim 1.

9. The chest flow execution control unit includes a message helper unit that describes processing logic related to the generation, conversion, formatting, or transmission of API messages in each chest in a common definition format, and the message helper unit has a structure that can be referenced from multiple chests, and the same message processing definition is shared and reused among the multiple chests. The API usage support system according to claim 1.

10. The chest flow configuration GUI processing unit is characterized by comprising a stream display unit that displays summary information on the processing results or status associated with each chest as a stream-type interface that is dynamically updated along a time axis or processing order, and by allowing a user to continuously and visually grasp summary information on multiple chests on one screen via the stream display unit, thereby enabling efficient tracking of status changes in the entire processing flow and dynamic monitoring of dependencies between chests and transitions in processing results. The API usage support system according to claim 1.

11. The chest flow execution control unit comprises a chest initial calculation unit that, when creating a new chest in the data flow, executes initial calculation processing based on a script or template associated with the chest and generates necessary properties and tags, and a recalculation unit that re-edits and updates dependencies for a range of the chests selected by a user, and then re-executes the entire or part of the processing flow, and the user can selectively switch between the initial calculation unit and the recalculation unit and apply them to the chest via the graphical user interface. The API usage support system according to claim 1.

12. The chest flow execution control unit includes a message tag unit that manages a message tag that is assigned to each message as information that can identify a conversion rule or processing condition when the message is processed between chests, and the message tag unit can be used as a mapping rule when converting the message tag between chests, and the tag can also be used as a flag for message classification, priority, execution target specification, or processing mode switching. The API usage support system according to claim 1.

13. The chest flow execution control unit includes a data flow backup unit that saves the configuration information of the data flow created by the user in a template format, and the backup unit stores the entire data flow including the chest configuration, connection relationships, message processing definitions, and tag information as a template, and the saved data flow template can be read and applied to any project and can be reused as a component of the project. The API usage support system according to claim 1.

14. The API usage support system includes a project operation interface unit for visually managing projects and operating chests in the field, the project operation interface unit comprising: (a) a project management unit that allows a user to list, select, create, update, and delete multiple projects, and retrieve and display information related to the selected project; (b) a chest operation unit that visually displays chests and the data flow between them on a field corresponding to a selected project and accepts operations such as adding, moving, and connecting chests; (c) an output stream display unit that can display messages or processing result data output from each chest in a list format; (d) a chest display unit that controls the display state of each chest and is responsible for interactions and object representation on the field; (e) a flow display unit that visually displays the data flow between the chests using connecting lines or the like to visualize the data flow; (f) a sequence management unit that enables expansion and contraction based on the logical sequence relationship of the chest group and visually displays the child chests when expanded; (g) a field operation processing unit that executes processes related to creation, update, recalculation, sequence execution, etc. of chests and flows based on operation requests from the interface unit, and provides necessary business logic. The API usage support system according to claim 1.

15. 2. The API usage support system according to claim 1, wherein the chest flow configuration GUI processor comprises a plurality of function management units that share and provide a plurality of functions within the system in response to user operations, and the function management units: (a) an account management unit for registering, authenticating, and managing settings for user accounts; (b) a file operation unit that allows uploading, downloading, and deleting data files; (c) A user support unit that provides information on how to use the system, FAQs, etc.; (d) a message helper management unit for displaying a list of, editing, deleting, and adding auxiliary information (message helpers) used in message processing; (e) a notebook management unit for users to create, edit, run, and delete notebooks; (f) a project management unit for listing, creating, deleting, selecting and updating projects; (g) a template management unit that saves and loads data flow templates and enables mutual conversion with projects; (h) an AI model management unit that allows users to learn, register, and utilize AI models based on their own data; (i) an application state sharing unit that manages the state of the entire application; (j) a utility frame unit that provides a common UI framework and controls pages of each utility function in a unified manner; (k) a navigation control unit that displays navigation links to each page and is capable of displaying current page information or usage context; The system is configured so that users can efficiently access various function management units, with the navigation control unit at the center, and the AI ​​model management unit allows users to build custom AI models and use them within the system. API usage support system.

16. 2. The API utilization support system according to claim 1, wherein the chest flow execution control unit includes an AI chat cooperation unit that executes cooperation processing with a chat API of an external artificial intelligence (AI) system, and the AI ​​chat cooperation unit: (a) a message formatting unit that receives message data generated in the chest, filters or converts the message according to conditions such as role, tag, and text content based on pre-set properties, and converts it into a format required by the AI ​​system, for example, a list format of role and content pairs; (b) a chat query generation unit that uses the formatted message to construct request data for a chat model of an AI system, and sends the request to obtain an AI response; (c) a response generation unit that receives the AI ​​response, extracts necessary information, and performs tagging and format conversion as necessary to generate a final response message, and stores the response message in the executor or a state management unit in the system; The AI ​​chat collaboration unit dynamically executes dialogue processing with the AI ​​system based on input from the user, and automatically generates and provides appropriate responses. API usage support system.

17. 17. The API usage support system according to claim 16, wherein the chest flow execution control unit includes an AI model tuning unit that constructs and manages an AI model, and the AI ​​model tuning unit: (a) a custom model tuning module that uses the data set processed by the message shaping unit as training data to train and update a user-defined AI model; (b) an embedding model query module that performs embedding-based inference; (c) a model registration management module that registers each of the modules in the AI ​​model helper and makes each registered model available for matching and calling in subsequent chest processing; (d) a model identification response module that obtains identification information of the registered AI model and returns it to the user, thereby visualizing the availability status of the AI ​​model; and These configurations enable users to dynamically register, reference, and use their own built or trained AI models within the system. API usage support system.

18. 18. The API usage support system according to claim 17, wherein the chest flow execution control unit includes an external search collaboration unit that supports information acquisition using an external search engine, the unit comprising: (a) a search message extraction module that extracts keywords or URLs from messages in the chest and converts them into a format suitable for an external search API; (b) a search execution module that sends a query to an API of an external search service (such as Google) based on the extracted keywords or URLs and obtains search result data; (c) a search response generation module that automatically generates a response message based on the acquired search results, stores the message in an executor within the system, and formats the message in a format that can be presented to a client; The external search collaboration unit acquires useful external information in real time from user input or messages in the chest, and presents it in an integrated manner as part of the system's processing, thereby enabling dynamic and insightful response generation. API usage support system.

19. In the API usage support system according to claim 16, the chat query of the standard AI system is (a) a query processing control module (Query Function Controller) that defines main processing functions for chat queries and controls various sub-function modules; (b) a message formatter module (Message Formatter) that formats, tags, and combines query messages with system messages; (c) An external API communication module (AI API Communicator) that communicates with the API of an external AI system and receives inquiries and responses; (d) a system message manager that holds system message templates used as input to the model and incorporates context-sensitive instructions; The query processing control module is central to the system, and each module works together to perform effective dialogue processing with an external AI system, realizing dynamic AI response generation, processing scalability, and a highly reusable configuration. API usage support system.

Images