New card importing method of child card machine based on data collaboration

Abstract

The invention relates to the technical field of data collaboration, and discloses a data collaboration-based child card machine new card import method, which comprises the following steps: S1, creating a standardized description file containing a card identification field, a question type field and a question content field for storing basic information of a card; s2, setting a relational data table at least comprising an answer data table and an audio information data table in a database, wherein the data table associates and stores interaction logic data by taking a card identification field as an index; s3, reading and analyzing the structured description file through a card machine processing program, and extracting a card identifier, a question type and display content; s4, querying a corresponding audio resource identifier from an audio information data table of a database according to the card identifier obtained by analysis, and obtaining corresponding judgment rule data from an answer data table; and S5, selecting a preset general processing rule based on the question type field, and executing card interaction in combination with the audio resource identifier obtained by query and the judgment rule data.

Description

Technical Field

[0001] The present invention relates to the field of data collaboration technology, and in particular to a new card importing method for a children's card machine based on data collaboration. Background Art

[0002] Children's card readers, as electronic products that combine education with entertainment, offer content such as knowledge popularization, language learning, and games through interactive interaction with physical cards. They are increasingly popular among parents and children. One of their core appeals lies in their ability to continuously update and expand card content to meet children's evolving learning interests and cognitive levels. In existing children's card reader technologies, especially in common C language embedded development environments, efficient and reliable importing and managing new card content is a key technical challenge.

[0003] Traditional children's card game development typically involves writing independent processing code for each card to implement its functionality. When developing a new card, such as one introducing a specific topic (such as the solar system or a specific animal), developers need to complete a series of low-level operations and logic implementations in the C language code module specific to that card. This includes, but is not limited to:

[0004] Hard-coded or tightly bound content and resources: The file names and storage paths for the text displayed on cards and audio files associated with card functions (such as question readings, prompt sounds, and background sound effects) often need to be defined directly in the C language source file or precisely specified and hard-coded through specific file operation functions. Different cards correspond to different file names and paths, which need to be set independently in their own code segments.

[0005] Duplication of underlying hardware interaction code: Tasks such as audio data reading, decoding, format parsing (e.g., parsing WAV file parameters like sampling rate, channels, and quantization bits), and data adaptation and transmission to specific audio playback hardware devices require extensive C code. While the principles of these underlying audio processing operations may be similar, they often need to be repeatedly implemented or called in the processing code for each card due to their association with specific card content and files, and must be configured based on the parameters of the specific audio file.

[0006] Hard-coding complex interaction logic: If a card involves more complex interactions, such as playing different audio clips based on the user's action sequence, answering questions, or recognizing specific rhythm patterns, developers need to use C language control structures (such as if-else statements, switch statements, and loops) to write customized logic code specific to the card's functionality. This logic code is the core of the card's functionality and is highly dependent on the specific card content and the pre-defined interaction flow.

[0007] However, this method of writing independent C language processing code for each card exposes significant technical problems when faced with the large-scale and rapidly updated content needs of children's card machines. The most important and critical problem is the slow development and import of new card content.

[0008] The defects and reasons are:

[0009] First, development involves a significant amount of repetitive work. Although different cards may have similar functional types (e.g., all are knowledge quizzes), the traditional implementation method hard-codes or scatters the content, resource paths, and specific logic details in the independent code of each card. This means that even to implement similar basic functions (such as audio playback and simple judgment), each new card must be rewritten from scratch or extensively copied and modified. This highly repetitive and atomic development process significantly consumes developers' time and energy. For example, in a system containing dozens or even hundreds of cards, the cumulative workload of simply configuring the audio file path and basic playback logic for each card is enormous, significantly extending the cycle from content design to final product availability for new cards.

[0010] Secondly, the tight coupling of content and implementation logic means that content updates are dependent on the software development process. Because the card content (such as question text, answers) and resource (audio file) information are directly embedded in or closely linked to the C language code, content creators or non-technical personnel cannot independently modify or add card content. Any change to the content (such as modifying the answer to a question or replacing an audio file) may require developers to modify the code, recompile, test, and deploy. This model limits the speed of content iteration to the software development and release cycle, making it difficult to quickly respond to market demand and the need for freshness among children's users.

[0011] Furthermore, the independent and complex code structure increases the risk of errors and the difficulty of maintenance. Since the code of each card is relatively independent and contains details such as low-level file operations, hardware interactions, and complex logic, it is very easy to introduce errors due to negligence during the development process, such as entering the wrong audio file name or path, or writing errors in logical judgment conditions. When it is necessary to uniformly modify or optimize the card functions (such as improving audio playback effects and adjusting feedback logic), modifications must be made in many independent code modules. This is not only a huge workload, but also prone to omissions or inconsistent modifications, making code maintenance difficult, increasing the potential instability and debugging costs of the system, and affecting the overall reliability of the children's card camera.

[0012] In summary, the existing children's card reader technology, which relies on writing independent C language processing code for each card, suffers from inherent flaws such as high repetitiveness, tight coupling of content and logic, and complex code management. This leads to inefficient development and integration of new cards, making it difficult to support rapid content updates and product iterations. This has become a key technical bottleneck restricting the development of children's card readers. Therefore, the industry urgently needs a technical solution that can decouple card content and resource-related information from the underlying processing logic, enabling fast and flexible integration of new cards. Summary of the Invention

[0013] The purpose of this invention is to design a new card import method for children's card machines based on data collaboration, which solves the problem that there is a lot of repetitive labor in development work and the tight coupling of content and implementation logic causes content updates to depend on the software development process.

[0014] The present invention provides a new card import method for a children's card machine based on data collaboration, comprising:

[0015] S1. Create a standardized description file containing a card identification field, a question type field, and a question content field to store basic card information;

[0016] S2. Setting a relational data table in the database that includes at least an answer data table and an audio information data table, wherein the data table uses the card identification field as an index to associate and store the interactive logic data;

[0017] S3, read and parse the structured description file through the card machine processing program, extract the card identifier, question type and display content;

[0018] S4. Based on the card identifier obtained through analysis, the corresponding audio resource identifier is searched from the audio information data table in the database, and the corresponding judgment rule data is obtained from the answer data table;

[0019] S5. Select a preset general processing rule based on the topic type field, and perform card interaction in combination with the audio resource identifier and judgment rule data obtained by the query.

[0020] In the above scheme, step S1 defines the structured method for describing card content. By creating a pre-formatted "standardized description file," the basic attributes, type, and textual content directly presented to the user for each card or each independent interactive unit (question) within it are structured and stored. The "card identification field" here and the "card identification" in subsequent steps are used to uniquely identify a physical card or a specific content module. The "question type field" and its corresponding "question type" specify the functional type of the interactive unit, such as single-choice, multiple-choice, rhythm game, or pure information presentation. This type information is crucial for subsequent processing logic dispatch. The "question content field" directly stores the textual information on the card, such as the question text itself and introductory text. Separating this basic, descriptive information from the program code and storing it in a separate, standardized file is the foundation for achieving a preliminary decoupling of content and code.

[0021] Step S2 establishes a mechanism for centrally managing core data and resource association information that are closely related to the card interaction logic. By introducing a "database system", such as SQLite or MySQL, and constructing a specific "relational data table". This application clearly states that it is necessary to at least include an "answer data table" for storing the correct answers to the questions and an "audio information data table" for storing the mapping relationship of audio files related to the card functions. The design of these data tables is structured, and the key is that they use the "card identification field" defined in step S1 as an index to associate specific "interaction logic data" with specific cards / questions. This method centrally and structuredly manages answers and resource information that may have been scattered in the code or specified by hard coding, and provides the ability to quickly find and associate data through card identification. This is a key link in achieving a complete decoupling of core interaction data and resource links from processing logic.

[0022] Step S3 describes the initial operation initiated by the general processing program inside the children's card machine when processing a specific card / topic. When the card machine system recognizes a card (for example, obtaining the card identification through the RFID or printed code on the card) or needs to present a certain content unit, the "card machine processing program" will first access the "structured description file" created in step S1. The program reads and parses this file to obtain the "card identification", "topic type" corresponding to the card / topic, and the "display content" that needs to be displayed on the screen. This step is the beginning of the data-driven process. The program no longer relies on built-in logic code for specific cards, but instead obtains the object to be processed and its basic properties by reading external data.

[0023] Step S4 is the data acquisition stage in the data-driven process. The general processing program uses the "card identifier" parsed from the standardized description file in step S3 as a query condition to access the "database" established in step S2. The program will query the "audio information data table" to obtain various audio file identifiers associated with the card / question (such as the audio file name of the question reading, the correct / incorrect prompt sound file name, etc.), and query the "answer data table" to obtain the specific data required for interactive judgment, that is, "judgment rule data" (such as the correct answer to the multiple-choice question, the rhythm pattern sequence of the rhythm question, etc.). This step realizes the dynamic acquisition of the key parameters and resource links required to execute the card function from the centrally stored data source based on the card identifier, further reflecting the separation of content and logic.

[0024] Step S5 is the core execution phase of the data-driven process. After obtaining the "question type" information in step S3 and the specific "audio resource identifier" and "judgment rule data" from the database in step S4, the general processing program no longer executes the hard-coded logic for a specific card. Instead, it dynamically selects or assigns a "pre-set general processing rule" based on the "question type" information obtained in S3. These general processing rules are pre-written general algorithms and processes that can handle a certain type of question (for example, a general single-choice question judgment logic module, a general multiple-choice question judgment logic module, a general audio playback control module, etc.). After selecting a general rule, the specific "audio resource identifier" and "judgment rule data" retrieved in step S4 are input as parameters to the general rule. For example, if the question is a single-choice question, the general rule uses the correct answer and question audio file name retrieved from the database to execute a series of general single-choice question interaction processes, including playing the question audio, receiving user input, comparing it with the answer data, and playing the correct / incorrect prompt tone based on the corresponding audio resource identifier based on the comparison result.

[0025] Preferably, in step S1, the standardized description file is a text file in JSON format; the card identification field contains a card number that uniquely identifies each card, the question type field includes single-choice questions, multiple-choice questions, and rhythm questions, and the question content field is used to store a text description of the question.

[0026] Preferably, the text file in JSON format further includes a topic number field for uniquely identifying a specific topic under the same card number, and the topic type field is used to guide the selection of corresponding logic in subsequent processing.

[0027] Preferably, in step S2, the relational data table is implemented using an SQLite database, and the audio resource identifier is stored as a relative path file name.

[0028] Preferably, the relational data table includes an answer data table and an audio information data table;

[0029] The answer data table uses the card number and the question number as the primary key to store the correct answer data for the corresponding question. For multiple-choice questions, the answer field stores multiple correct answer identifiers separated by commas.

[0030] The audio information data table uses the card number and the question number as the joint primary key, and contains at least the question reading audio file name, error prompt audio file name and success prompt audio file name fields, which are used for audio playback corresponding to different interactive feedback scenarios.

[0031] Preferably, in step S3, the card machine processing program calls the underlying audio playback interface, queries and obtains the audio file name as input, and implements decoding of the corresponding audio file and hardware-driven playback.

[0032] Preferably, in step S4, the judgment rule data obtained from the answer data table includes:

[0033] For multiple-choice question types, store a single correct answer character;

[0034] For multiple-choice questions, store multiple correct answer strings connected by separators;

[0035] For the rhythm question type, rhythm pattern data including time series is stored.

[0036] Preferably, the rhythm pattern data includes an operation sequence and timestamp information, and the accuracy of the user input is determined based on the rhythm pattern, and the corresponding prompt audio playback is triggered based on the determination result.

[0037] Preferably, in step S5, the preset general processing rules include:

[0038] For multiple-choice questions, determine whether the answer entered by the user is consistent with the only correct answer in the database;

[0039] For multiple-choice questions, the user input is matched against the answer set stored in the database to confirm that it is completely correct;

[0040] For rhythm questions, a judgment is made based on whether the user's operation rhythm conforms to the rhythm pattern stored in the database within a limited time window.

[0041] Preferably, after executing the card interaction, the method further includes querying and playing corresponding prompt audio from the database according to the judgment result, including playing a success prompt audio when correct and playing an error prompt audio when an error occurs.

[0042] Compared with the prior art, the present invention has the following beneficial effects:

[0043] (1) Significantly improved the efficiency of developing and importing new card content: By separating data from logic and applying common processing rules, developers or content creators only need to focus on preparing structured data to quickly add and deploy new cards, significantly shortening the product update cycle;

[0044] (2) Significantly enhanced the maintainability and flexibility of card content management: card content, answers, resource links, etc. are all stored in external description files and databases, which are easy to modify without affecting the core program logic and can flexibly adapt to changes and expansions in content.

[0045] (3) Improved stability and reliability: The core interaction logic is centralized in common processing rules, which can be more thoroughly tested and optimized. This reduces the code redundancy and potential errors caused by writing independent code for each card, thereby improving the robustness of the overall system.

[0046] (4) Lowering the threshold and cost of content development: Transforming the card production process from complex coding work to structured data configuration work makes the content creation process more convenient, reduces the dependence on the developer's low-level programming ability, and helps to achieve scale and professional division of labor in content production;

[0047] (5) Achieved rapid response to market demand: Due to the improved efficiency of importing new cards and the enhanced flexibility of content management, the product can launch new learning and entertainment content more quickly, better meet the ever-changing needs of children users, and thus enhance the market competitiveness of the product. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 This is a flow chart of a new card importing method for a children's card machine based on data collaboration provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0049] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0050] like Figure 1 As shown, the present application provides a new card import method for a children's card machine based on data collaboration, comprising:

[0051] S1. Create a standardized description file containing a card identification field, a question type field, and a question content field to store basic card information;

[0052] S2. Setting a relational data table in the database that includes at least an answer data table and an audio information data table, wherein the data table uses the card identification field as an index to associate and store the interactive logic data;

[0053] S3, read and parse the structured description file through the card machine processing program, extract the card identifier, question type and display content;

[0054] S4. Based on the card identifier obtained through analysis, the corresponding audio resource identifier is searched from the audio information data table in the database, and the corresponding judgment rule data is obtained from the answer data table;

[0055] S5. Select a preset general processing rule based on the topic type field, and perform card interaction in combination with the audio resource identifier and judgment rule data obtained by the query.

[0056] In this solution, through a standardized JSON file structure and database management system, developers can quickly add new cards simply by editing the JSON file according to the specified format and entering the corresponding data into the database. This eliminates the need to write repetitive code for each card as in traditional methods. This significantly shortens the new card import cycle and speeds up content updates, allowing the children's card machine to provide innovative learning and entertainment content in a more timely manner.

[0057] Compared to writing separate code for each card, this solution provides a more centralized and standardized code logic. JSON files and databases are each responsible for storing different types of data, with clear responsibilities and reduced error rates. Furthermore, when functionality needs to be modified or expanded, adjustments only need to be made within the corresponding JSON file or database table structure, rather than triggering multiple errors due to a single modification like with traditional code. This enhances system stability and reliability.

[0058] Based on the user's answer to a question, the corresponding prompt audio file name can be quickly retrieved from the database and played. This fast and accurate feedback mechanism allows users to know the correctness of the answer in a timely manner when using the children's card camera, increasing the fun of learning and playing games and improving the overall user experience.

[0059] The use of a database provides tremendous flexibility for data management. Whether adding new question types or modifying existing answers or audio files, operations can be easily performed within the database. For example, when updating the audio content for a question, simply modify the corresponding file name in the database's audio information data table, eliminating the need for large-scale changes to the entire system's code, making content maintenance and updates much easier.

[0060] Preferably, in step S1, the standardized description file is a text file in JSON format; the card identification field contains a card number that uniquely identifies each card, the question type field includes single-choice questions, multiple-choice questions, and rhythm questions, and the question content field is used to store a text description of the question.

[0061] In the above solution, by storing descriptive information such as card number, question type, and question content in JSON files, this information is no longer hard-coded in the program code. Content creators can independently edit the basic card information and question text without modifying or compiling the code, thus streamlining the content update process. JSON, as a mature standard format, has readily available, efficient parsing libraries. The card reader processing program only needs to integrate a universal JSON parsing module once to parse all card description files that follow this format. This eliminates the need to write customized file parsing code for different cards, improves development efficiency, and reduces the risk of errors caused by inconsistent parsing formats. A clear question type field allows the processing program to quickly identify the functional attributes of a card, providing direct data input for subsequent selection of general processing logic based on the card type. This enables a single program framework to handle multiple different card types. The card number, as a unique card identifier, bridges the JSON description information with the specific business data stored in the database, ensuring that the corresponding answer and resource information can be accurately found after obtaining the description information.

[0062] Preferably, the text file in JSON format further includes a topic number field for uniquely identifying a specific topic under the same card number, and the topic type field is used to guide the selection of corresponding logic in subsequent processing.

[0063] In the above solution, after introducing the question number, developers can design multiple independent questions or interaction steps on the same physical card (corresponding to the same card number), each identified by a unique question number. This greatly enriches the function and content carrying capacity of a single card, and improves the efficiency and fun of card use; the composite identifier composed of the card number and the question number provides a sophisticated joint primary key for the data table in the database. With this pair of unique IDs, the program can accurately and efficiently locate the answer data and audio resource identifier corresponding to a specific question on a specific card from massive data, avoiding data confusion or inaccurate search problems; at the database level, independent answer and audio file information can be stored for each question number, making the data organization clearer and more organized, and facilitating the addition, deletion, modification, and maintenance of content; the general processing program can drive the interaction process of a specific question based on the combination of the card number and the question number, and combined with the question type selection logic, it can flexibly handle different questions or links on the card, further enhancing the versatility and reusability of the program.

[0064] Preferably, in step S2, the relational data table is implemented using an SQLite database, and the audio resource identifier is stored as a relative path file name.

[0065] In the above solution, the use of SQLite database eliminates the need for an independent database server process and complex configuration management, reducing the demand for hardware resources (CPU, memory, storage) of the children's card machine. It also simplifies the system architecture and deployment process, reducing development and maintenance costs. The reliability of SQLite ensures the integrity of card data in unexpected situations. Its efficient local query capability ensures that answers and audio resource identifiers are quickly and accurately obtained based on the card / question ID, reducing delays in the data reading process. Storing relative path file names allows the entire card content package (including JSON, DB, audio files) to be easily copied and deployed between different devices or different storage locations without modifying the database content, greatly simplifying the batch import and distribution process of new card content, and further improving the overall efficiency of importing new cards. The use of relative path naming rules combined with a reasonable directory structure makes the management of audio files clearer and more organized, reducing the risk of audio being unable to play due to file path errors.

[0066] Preferably, the relational data table includes an answer data table and an audio information data table;

[0067] The answer data table uses the card number and the question number as the primary key to store the correct answer data for the corresponding question. For multiple-choice questions, the answer field stores multiple correct answer identifiers separated by commas.

[0068] The audio information data table uses the card number and the question number as the joint primary key, and contains at least the question reading audio file name, error prompt audio file name and success prompt audio file name fields, which are used for audio playback corresponding to different interactive feedback scenarios.

[0069] In the above solution, the association between answers and audio resources is stored in a database, allowing content updates such as modifying answers and replacing audio files without touching or modifying the underlying processing code. Content producers can update content directly through data operations within certain permissions, significantly reducing reliance on developers and significantly improving the efficiency and flexibility of content updates. Leveraging the database index (a combined primary key of card number and question sub-number), the processing program can quickly and accurately retrieve the answer data and all relevant audio file names required for a specific question. This ensures a smooth and responsive card interaction process. The general processing program no longer needs to hard-code the answer and audio file paths for each card. It only needs to know how to query the database for the corresponding standardized data (answer, file name) based on the card / question ID and the current interaction status / judgment result. Based on the query results, it then executes general processing logic or calls the playback interface. The database provides sophisticated data management features (such as transactions, backups, import and export), making batch addition, modification, and deletion of card data easy and reliable. The structured table format also makes data relationships clearly visible, reducing the complexity of maintenance; defining different fields (such as the audio file names of question reading, error prompts, and success prompts) and answer storage formats (such as comma separation for multiple-choice questions) enables the data model to support a variety of common card interaction requirements and feedback methods.

[0070] Preferably, in step S3, the card machine processing program calls the underlying audio playback interface, queries and obtains the audio file name as input, and implements decoding of the corresponding audio file and hardware-driven playback.

[0071] In this solution, the universal handler no longer needs to write separate audio file processing code for different cards. All audio playback requests are implemented by calling the same underlying interface and passing in the file name, making the core program's audio playback logic highly centralized and simplified. The specific content and file name of the audio file are completely stored in the file system and database and are unrelated to the universal handler code. Replacing or updating audio files only requires modifying the file system and database records, without changing the code, further improving the convenience of content updates. If the card machine's hardware platform or underlying audio driver changes, only the underlying audio playback interface implementation needs to be modified, and the universal handler itself does not need to be modified, enhancing the program's cross-platform capabilities and adaptability to hardware changes. The underlying audio playback interface is a well-tested universal module with a low error rate. Encapsulating the complexity of audio processing at the underlying level reduces the possibility of audio-related errors being introduced into the universal handler.

[0072] Preferably, in step S4, the judgment rule data obtained from the answer data table includes:

[0073] For multiple-choice question types, store a single correct answer character;

[0074] For multiple-choice questions, store multiple correct answer strings connected by separators;

[0075] For the rhythm question type, rhythm pattern data including time series is stored.

[0076] In the above scheme, by defining different answer data storage formats for different types of questions (single-choice, multiple-choice, rhythm questions, etc.), this scheme can flexibly support a variety of different card interaction gameplay and judgment logic, enriching the diversity of card content; the standardized answer data format enables the judgment module in the general processing program to receive and process structured input from the database without having to worry about the specific answer content, but only need to know how to parse the format corresponding to a specific type; the specific answer data (whether it is single-choice, multiple-choice options or rhythm patterns) is completely stored in the database and does not appear in the processing code. Modifying the answer content or format only requires modifying the database record, without changing the code, further improving the flexibility and efficiency of content maintenance; although the general processing program needs to include logical branches to handle different answer formats, these branches are written for types rather than specific cards, greatly reducing the overall code volume and complexity compared to writing independent judgment code for each card.

[0077] Preferably, the rhythm pattern data includes an operation sequence and timestamp information, and the accuracy of the user input is determined based on the rhythm pattern, and the corresponding prompt audio playback is triggered based on the determination result.

[0078] In the above scheme, by storing the operation sequence and timestamp information, this application can effectively handle complex interactive functions such as rhythm questions that require users to complete specific operations within a specific time sequence, thereby expanding the possibilities of card design. By storing specific rhythm pattern data in the database, it is only necessary to modify the database records to add or modify the difficulty and pattern of the rhythm questions, without modifying the core code. This greatly simplifies the process of creating and adjusting the content of the rhythm questions. The general processing program only needs to have a built-in set of general algorithms that can parse the rhythm pattern data and perform time sequence comparison to handle all rhythm questions that follow this data format, further enhancing the versatility and reusability of the program. The judgment based on the time series can more accurately evaluate whether the user's operation conforms to the preset rhythm. Combined with the subsequent prompt audio playback, it can provide users with timely and accurate feedback and optimize the user experience.

[0079] Preferably, in step S5, the preset general processing rules include:

[0080] For multiple-choice questions, determine whether the answer entered by the user is consistent with the only correct answer in the database;

[0081] For multiple-choice questions, the user input is matched against the answer set stored in the database to confirm that it is completely correct;

[0082] For rhythm questions, a judgment is made based on whether the user's operation rhythm conforms to the rhythm pattern stored in the database within a limited time window.

[0083] In the above solution, once the judgment logic for single-choice, multiple-choice, and rhythmic questions is developed and implemented, it can be reused for all newly created cards of the same type, eliminating the need to write new judgment code for each card. This directly addresses the code duplication and inefficiency inherent in the traditional model. When creating a new card, developers only need to correctly specify the question type in the JSON and enter the answer data that conforms to the type's format in the database, without having to modify the judgment logic code in the general handler. This greatly simplifies the import process and improves efficiency. The core judgment logic is concentrated in a few general modules. When optimizing a judgment algorithm, only the corresponding general module needs to be modified, eliminating the need to make modifications across a large number of scattered card codes, reducing maintenance complexity and error risks. The core judgment logic is concentrated in a few general modules. When optimizing a judgment algorithm, only the corresponding general module needs to be modified, eliminating the need to make modifications across a large number of scattered card codes. This reduces maintenance complexity and error risks. When supporting new question types, developers only need to define a new question type identifier in the JSON, a new answer data format in the database, and add a new processing branch and judgment module to the general handler, eliminating the need to restructure the entire system architecture.

[0084] Preferably, after executing the card interaction, the method further includes querying and playing corresponding prompt audio from the database according to the judgment result, including playing a success prompt audio when correct and playing an error prompt audio when an error occurs.

[0085] In the above solution, the prompt audio file is separated from the code and stored in the file system and database. Changing the prompt sound effect or replacing the audio file only requires updating the file and database record, without modifying the program code, which greatly simplifies the management and updating of feedback content. Which prompt sound is played depends entirely on the data (file name) obtained from the database and the judgment result of the general processing program. This data-driven model enables the same general processing program to provide customized feedback for different cards and different user behaviors. Timely, accurate audio feedback that corresponds to the judgment result can enhance the participation and learning effect of child users and improve their enthusiasm for using card machines. Incorporating the feedback link into the general processing flow allows the entire card interaction cycle (presenting the question -> user input -> judgment -> feedback) to be completed by the general program and external data drive, further enhancing the integrity and efficiency of the entire framework.

[0086] In one embodiment provided in the present application, a JSON file architecture is designed: a set of concise and standardized JSON file structures is constructed. Several core fields are set in the file: "Card Number", "Question Number", "Question Type", and "Question Content". "Card Number" and "Question Number" are used to uniquely identify each question; "Question Type" clarifies whether the question belongs to a specific type such as single-choice question, multiple-choice question, rhythm question, etc., so that different processing logic can be executed later; "Question Content" stores the text information of the question itself. Through this design, the JSON file is mainly responsible for storing the basic descriptive information of the card, ensuring the clarity of the data and the efficiency of reading.

[0087] Build a database management system: Choose an appropriate database system, such as SQLite (suitable for embedded devices with limited resources) or MySQL (suitable for scenarios with high performance and scalability requirements). Create multiple tables in the database to manage different types of data.

[0088] Answer Data Table: Use "Card Number" and "Question Number" as the joint primary key, and establish an "Answer" field. For single-choice questions, the "Answer" field stores the single correct answer; multiple-choice questions store multiple correct answers in a specific format (such as a comma-delimited string); rhythm questions store rhythm pattern information for judgment. This ensures accurate storage and fast query of answer data.

[0089] Audio Information Data Table: Also using "Card Number" and "Question Sub-Number" as joint primary keys, set fields such as "Question Audio File Name," "Error Prompt Audio File Name," and "Success Prompt Audio File Name." Each field corresponds to the audio file name of the corresponding function, ensuring a precise association between audio files and questions.

[0090] Develop interaction processing programs: Write a set of card processing programs that can work with JSON files and databases.

[0091] The program first reads the JSON file, retrieves the "question content," and displays it on the children's card reader screen. Next, based on the "card number" and "question sub-number," it searches the database's audio information table for the corresponding "question audio file name." Once the file name is found, the card reader's audio playback function plays the audio corresponding to the question, allowing the child to hear the content.

[0092] Answer Verification and Feedback Mechanism: After the user enters an answer, the program retrieves the correct answer from the answer data table based on the "card number" and "question number." Then, depending on the question type, different answer verification logic is applied. For single-choice questions, the user's answer is directly compared with the answer in the database. For multiple-choice questions, the answer string in the database is parsed and the user's selected answer is compared one by one. Rhythm questions use a specific rhythm analysis algorithm, specifically rhythm logic (during the rhythm song, the corresponding action must be completed within a time limit after the prompt sound is played). The user's action is compared with the rhythm pattern in the database (limited time and multiple answers). Based on the judgment result, the program again queries the audio information data table for the corresponding prompt audio file name. If the answer is correct, the "success prompt audio file name" is queried and the success prompt audio is played. If the answer is incorrect, the "error prompt audio file name" is queried and the error prompt audio is played, providing the user with timely feedback.

[0093] The technical solution of tightly integrating the JSON file with the database greatly simplifies the process of importing new cards. Developers only need to edit the JSON file according to the specified format and enter the corresponding answers and audio information into the database to quickly add new cards. This effectively improves the efficiency of importing new cards, reduces the possibility of code errors, and improves the overall performance and user experience of the children's card reader.

[0094] In the above scheme, this application uses JSON files in combination with a database to store card information. In some specific scenarios, XML files can be used as an alternative to JSON files. XML files also have structured data representation capabilities. They use tags to describe data elements. For some situations that require strict adherence to specific data format standards and focus on data hierarchy display, XML files are more suitable. For example, in some educational resource sharing platforms, if specific educational data specifications need to be followed, XML files can better meet such normative requirements. However, compared with JSON files, XML files have more complex syntax, are usually larger in size, and have lower parsing efficiency. In children's card machine scenarios that require high file reading speeds and storage capacity, the use of XML files may cause performance problems.

[0095] In this application, a relational database (such as MySQL or SQLite) is selected to manage answers and audio information. For some scenarios with smaller data volumes, less stringent requirements for data consistency, but more emphasis on data reading speed, non-relational databases (such as Redis) can be used as an alternative. Redis stores data in the form of key-value pairs, has extremely high read and write speeds, and can quickly obtain the corresponding answer and audio file name information based on the "card number" and "question number". However, Redis is not as good as relational databases in handling complex queries and data relationship management. It lacks complete support for transaction processing. If the children's card machine needs to perform more complex data association operations in the future, Redis may not be able to meet the needs.

[0096] Currently, the correspondence between audio file names and card information is managed with the help of a database. As an alternative, the file system directory structure can be used to manage audio files. Create directories according to the hierarchical structure of "card number-question number", and place the question audio, error prompt audio, and success prompt audio in the corresponding directories respectively, and name them with fixed file names, such as "question_audio.mp3", "error_tip.mp3", and "success_tip.mp3". The advantage of this method is that it does not require an additional database management system, reduces system complexity, and is easy to implement and maintain in some simple children's card machine application scenarios. However, the disadvantage is the lack of efficient query and data consistency assurance capabilities of the database. When audio files need to be updated or managed, the operation is relatively cumbersome, and file management chaos is prone to occur.

[0097] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A new card import method for children's card machine based on data collaboration, characterized in that: include: S1. Create a standardized description file containing a card identification field, a question type field, and a question content field to store basic card information; S2. Setting a relational data table in the database that includes at least an answer data table and an audio information data table, wherein the data table uses the card identification field as an index to associate and store the interactive logic data; S3, read and parse the structured description file through the card machine processing program, extract the card identifier, question type and display content; S4. Based on the card identifier obtained through analysis, the corresponding audio resource identifier is searched from the audio information data table in the database, and the corresponding judgment rule data is obtained from the answer data table; S5. Select a preset general processing rule based on the topic type field, and perform card interaction in combination with the audio resource identifier and judgment rule data obtained by the query.

2. A method for importing new cards into a children's card machine based on data collaboration according to claim 1, characterized in that: In step S1, the standardized description file is a text file in JSON format; the card identification field contains the card number that uniquely identifies each card, the question type field includes single-choice questions, multiple-choice questions, and rhythm questions, and the question content field is used to store the text description of the question.

3. The method for importing new cards into a children's card machine based on data collaboration according to claim 2, characterized in that: The JSON format text file further includes a topic number field for uniquely identifying a specific topic under the same card number, and the topic type field is used to guide the selection of corresponding logic in subsequent processing.

4. A method for importing new cards into a children's card machine based on data collaboration according to claim 3, characterized in that: In step S2, the relational data table is implemented using an SQLite database, and the audio resource identifier is stored as a relative path file name.

5. A method for importing new cards into a children's card machine based on data collaboration according to claim 4, characterized in that: The relational data table includes an answer data table and an audio information data table; The answer data table uses the card number and the question number as the primary key to store the correct answer data for the corresponding question. For multiple-choice questions, the answer field stores multiple correct answer identifiers separated by commas. The audio information data table uses the card number and the question number as the joint primary key, and contains at least the question reading audio file name, error prompt audio file name and success prompt audio file name fields, which are used for audio playback corresponding to different interactive feedback scenarios.

6. A method for importing new cards into a children's card machine based on data collaboration according to claim 5, characterized in that: In step S3, the card machine processing program calls the underlying audio playback interface, queries the obtained audio file name as input, and implements decoding and hardware-driven playback of the corresponding audio file.

7. A method for importing new cards into a children's card machine based on data collaboration according to claim 6, characterized in that: In step S4, the judgment rule data obtained from the answer data table includes: For multiple-choice question types, store a single correct answer character; For multiple-choice questions, store multiple correct answer strings connected by separators; For the rhythm question type, rhythm pattern data including time series is stored.

8. The method for importing new cards into a children's card machine based on data collaboration according to claim 7, characterized in that: The rhythm pattern data includes an operation sequence and timestamp information. The accuracy of the user input is determined based on the rhythm pattern, and the corresponding prompt audio playback is triggered based on the determination result.

9. A method for importing new cards into a children's card machine based on data collaboration according to claim 8, characterized in that: In step S5, the preset general processing rules include: For multiple-choice questions, determine whether the answer entered by the user is consistent with the only correct answer in the database; For multiple-choice questions, the user input is matched against the answer set stored in the database to confirm that it is completely correct; For rhythm questions, a judgment is made based on whether the user's operation rhythm conforms to the rhythm pattern stored in the database within a limited time window.

10. A method for importing new cards into a children's card machine based on data collaboration according to claim 9, characterized in that: It also includes querying and playing corresponding prompt audio from the database according to the judgment result after executing the card interaction, including playing a success prompt audio when correct and playing an error prompt audio when an error occurs.

Images