Multi-terminal AI job tutoring cooperative control system based on family account

Abstract

The invention discloses a multi-terminal AI homework tutoring cooperative control system based on a family account, and aims to realize permission controllability, behavior auditing and content output supervision of artificial intelligence in a student homework tutoring process. The system comprises a family account structure and master control parent binding mechanism, a student terminal registration and authority management and control module, a multi-terminal cooperation and binding relation management module, a behavior chain synchronization and authority path management and control module, and a controlled content playing and authority prompting module of an auxiliary terminal. By constructing an account system with a master control parent as a core, the system realizes unified management and authority division of a plurality of parent terminals, student terminals and auxiliary terminals; through a behavior chain recording and path verification mechanism, the system realizes whole-course recording and path legality judgment on behaviors such as an AI calling process, a prompt path and an answer request; the auxiliary terminal can only broadcast the content which is marked to be playable by the system and does not have the generation capability, so that the content boundary and authority security in the use process of the low-age user are ensured. The method can be widely applied to an intelligent homework tutoring system in a family scene, and the standardization, transparency and education guiding effect of AI use are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of artificial intelligence and educational informatization technology, in particular to a multi-terminal AI homework tutoring collaborative control system based on family account management, and especially to a system architecture for realizing controlled use of AI-generated content in a student learning scenario through family member permission setting, terminal role binding, and behavior chain recording mechanism. BACKGROUND

[0002] With the rapid development of generative artificial intelligence technology, the application of AI models in the education field has gradually become popular, especially in scenarios such as student after-school homework tutoring, knowledge point explanation, and question analysis, which have shown strong expression and intelligent feedback capabilities. A large number of AI learning products for students have begun to support functions such as automatic problem solving, intelligent question answering, and stylized explanation, significantly improving the efficiency of students in obtaining learning resources.

[0003] However, most existing AI homework tutoring systems use a single terminal + student-led use structure, lack systematic management of family members, terminal roles, permission paths, and behavior processes, and mainly have the following technical shortcomings: 1. Lack of permissions: students can directly operate AI models to obtain complete answers or high-grade explanation content, which can easily lead to dependency and lack of guidance and constraints in the learning process; 2. Lack of parental involvement: the system usually does not have a parental involvement path, making it impossible to monitor, control, or intervene in student behavior, resulting in invisible and uncontrollable AI usage; 3. Terminal fragmentation: multiple terminals (such as mobile phones, tablets, e-paper books, and voice devices) lack unified account structures and behavior chain attribution management, with scattered behavior data and difficult supervision; 4. Lack of content control: auxiliary terminals (such as voice speakers and smart dolls) can passively call content, but the system cannot determine their playback permissions, age appropriateness, or parental review, posing a risk of dissemination; 5. Behavior cannot be traced: AI call paths, prompt words, style selection, model versions, and other key processes are not structured and recorded, lacking a traceable and auditable behavior chain mechanism.

[0004] To address the above problems, there is an urgent need for an AI homework tutoring system with a family account system, permission control mechanism, multi-terminal collaboration structure, and behavior chain recording capability to ensure the controllability, safety, and educational guidance of AI content generation processes at the structural level.

[0005] It is worth noting that the applicant has proposed several related technical solutions for the use of AI in homework tutoring, including a prompt word-driven expression generation method, a parental intervention and answer approval mechanism, an expression behavior chain recording and version sedimentation mechanism, and other method-based inventions.

[0006] On this basis, the application further focuses on the system structure design, and constructs a permission control and behavior management system taking the family account as the core, the parents as the main controller, and multiple terminals as the collaborative carrier, strengthens the path control and process audit ability of the student AI use behavior, and is the structural support and use landing path of the above-mentioned method mechanism. SUMMARY

[0007] I. Invention purposes

[0008] Under the background of the rapid development of generative artificial intelligence, AI is widely introduced into the student homework tutoring scene, and is used for question explanation, idea prompting and expression reconstruction. However, the existing AI learning system mostly takes "student autonomous calling model" as the core path, lacks necessary permission control and parent monitoring mechanism, and is easy to cause the following problems: 1. Students directly ask for answers and bypass the thinking training link, forming "dependent use"; 2. Parents cannot grasp the specific use of AI by children, and there is a monitoring blind area; 3. Young children lack safety boundaries in using AI, and may be exposed to inappropriate content or misuse model functions; 4. Multiple device collaboration is missing, and behavior chain records are chaotic, which cannot be traced and controlled to spread and call the generated content.

[0009] To solve the above problems, the application provides a multi-terminal AI homework tutoring collaborative control system based on a family account system. Through a parent master control identity binding mechanism, a student terminal permission registration strategy, a terminal role division and collaboration structure, a behavior chain synchronous recording and permission path control mechanism, the intelligent learning process of "AI can be used but not overstepped, parents can let go but can take over at any time" of students in the family scene is realized.

[0010] The system especially emphasizes constructing a closed-loop structure of "generation in control, learning in guidance, and permission in path" in technical implementation, which fundamentally improves the monitorability, safety and educational effectiveness of AI homework tutoring, and meets the compliance, controllability and auditability requirements in the intelligent learning process of minors.

[0011] II. System module description

[0012] In order to realize the effective use and controllable management of artificial intelligence generated content in the homework tutoring process of students in the family scene, the system constructs an AI homework tutoring control system with multiple terminal collaborative operation, traceable behavior chain and controlled content permission based on the design concept of "family account as the core, parent-led as the premise, and permission path as the guarantee". The overall structure of the system is divided into five functional modules, which correspond to account binding, terminal permission, collaborative relationship, behavior monitoring and content broadcasting, and the like. The specific description is as follows:

[0013] (I) Family account structure and master parent binding mechanism

[0014] The system organizes and manages the user system and permissions with "family account" as the basic unit, and supports multiple parent terminals and multiple student terminals to run collaboratively under a unified account system. The family account is created by the "master parent terminal" and serves as the only master subject of the account system, bearing core functions such as account initialization, device binding, permission setting, and behavior chain attribution management.

[0015] The master parent terminal completes identity verification through mobile phone registration, password verification, and face recognition authentication. The system binds the device identifier (such as device ID, MAC address, mobile phone number, etc.) of the terminal to the account structure, forming the master authentication basis of the family account. After successful creation, the master parent terminal can perform the following management operations on all devices under the family account: 1. Authorize other parent terminals to join the family account; 2. Bind, name, or unbind student terminals and auxiliary terminals; 3. Audit and control the online and usage permissions of student terminals; 4. Review and download behavior chain records and learning process content under the family account.

[0016] If other parent terminals (such as another parent's mobile phone) need to join the family account, they must be authorized by the master parent terminal in real time. Each authorization login behavior generates a traceable behavior node record on the master terminal, ensuring the closed-loop nature of the permission path and the auditability of behavior attribution.

[0017] The system defaults all operation behaviors of student terminals and auxiliary terminals in the family account to the parent terminal they are bound to, and then aggregates them under the family account system. Even if multiple terminals are running simultaneously, the system can perform behavior layering, chain attribution, and control path division based on terminal roles (such as Parent / Student / Assistant) and terminal IDs, ensuring that behavior control and permission logic are always centered around the "master parent."

[0018] In addition, the system supports the master parent terminal to monitor and record the login behavior of other parent terminals throughout the process, including: 1. Login time; 2. Login terminal ID; 3. The identifier of the student terminal operated; 4. The type and chain summary of the executed behavior.

[0019] This mechanism ensures that the entire family account system has clear authority boundaries, stable role hierarchy, and controllable behavior audit capabilities.

[0020] Summary of reinforcement protection points: 1. The family account structure takes the "master parent" as the only authority center, and the system behavior chain, device management, and permission settings are built from this identity. 2. All parent and student terminal login paths and usage permissions must be authorized by the master parent terminal, forming a path closure mechanism. 3. Login behavior, device binding, and usage operations form an auditable chain record, ensuring that the system has behavior attribution and accountability capabilities. 4. The family account supports flexible expansion of multiple terminals, but control is always focused on a single master entity, avoiding permission drift or path bypass.

[0021] (II) Student terminal registration and permission control module

[0022] This module is used to implement the identity registration, permission binding, and behavior path management of student terminals in the system, ensuring that students are always under the control of the parent control system when using AI homework tutoring functions, forming a closed-loop control structure of "parent authorization - student use - system record - permission controllable".

[0023] In the family account system, the registration and activation process of the student terminal must be initiated or authorized by the master parent terminal. The system does not support student terminals to complete registration and login operations independently, nor does it allow them to bypass the parent permission path to call models or obtain content.

[0024] Each student terminal must be clearly bound to a specific parent terminal in the family account during the registration process. This parent terminal is the permission and responsibility subject of the student terminal in the system. After successful binding, all operations performed by the student terminal in the system - including but not limited to uploading homework problems by taking pictures, initiating AI explanation requests, selecting explanation styles, calling expression templates, and saving explanation results - are recorded in the behavior chain of the bound parent terminal by the system, not recorded or attributed to the student identity, thus building a behavior responsibility structure centered on the parent.

[0025] To ensure that the permission path cannot be bypassed, the system implements structural restrictions on the following behaviors of the student terminal: 1. Prohibit student terminals from logging in independently: login operations must be authorized by the parent terminal through scanning or binding; 2. Prohibit student terminals from unbinding or changing parent accounts: all unbinding behaviors must be performed by the master parent terminal; 3. Prohibit students from configuring model parameters or prompt strategy on their own: the explanation process is guided by templates set by parents or embedded strategy modules in the system. 4. Prohibit students from independently saving, sharing, or disseminating AI-generated content: relevant content falls under the control of the parent terminal.

[0026] The system ensures the uniqueness and unforgeability of student terminals through device ID, MAC address, Bluetooth identifier, and other means, combined with a permission path verification mechanism, to further prevent students from bypassing the parent binding path through resetting, copying, or simulation.

[0027] This module emphasizes in its technical structure that students are only users of the system, not controllers, and their behavior paths must be locked within the scope of parental authorization. Any model invocation behavior that deviates from parental control will be automatically blocked by the system and an alert will be sent to the parent terminal.

[0028] Summary of strengthened protection points: The student terminal registration and use process must be authorized by the parent terminal, and there is no independent student registration path in the system structure. All student behavior chains belong to their bound parent accounts, and there is no student-level permission or record system to prevent data from being out of control. The system sets strong constraints on student login, unbinding, and strategy invocation behavior to prevent any unauthorized operation. The behavior chain of the student terminal is recorded in the parent master path, supporting audit and traceability, and constitutes a key technical mechanism for AI usage boundaries.

[0029] (Three) Multi-terminal collaboration and binding relationship management module

[0030] This module is used to realize the unified registration, role identification, collaborative management, and permission control of multiple terminal devices under the family account system, building an extensible and controllable multi-terminal collaboration structure. This module ensures that all terminals running AI homework tutoring functions are under the control of the family account master path, with clear behavior attribution and terminal responsibility boundaries.

[0031] In system design, the family account supports flexible binding of multiple types of terminal devices, including but not limited to the following three categories: 1. Parent terminal (Parent): such as mobile phones, tablets, computers, etc., with core control permissions such as identity authentication, permission authorization, content scheduling, and behavior monitoring; 2. Student terminal (Student): such as e-paper, tablet, computer, etc., as a learning operation execution end, performing interactive behaviors such as question submission, request for explanation, and content reception; 3. Assistant terminal: such as smart dolls, voice speakers, Bluetooth headsets, etc., which undertake controlled output tasks such as content playback and voice prompts, and do not have the ability to generate content.

[0032] When registering each terminal device, the system assigns it a unique terminal identifier (terminal ID) and indicates its role type (such as Parent / Student / Assistant) through the "Terminal Role Identifier Field". This field is not only used to define the boundaries of terminal permissions, but also serves as an important basis for determining the attribution of behavior chains and the legality of call paths.

[0033] The terminal binding relationship under each family account is uniformly maintained by the system's "binding structure management mechanism".

[0034] This mechanism includes the following core functions: Terminal registration and role assignment: The parent terminal initiates a binding request and assigns a role and name to each terminal; Role-based behavior chain attribution: The system determines which parent terminal or family account path should be attributed to the behavior chain based on the terminal's role field. Collaborative Status Management: The system monitors the online status, running tasks, and control permissions of each terminal in real time, enabling parents to manage multiple terminals in a unified manner. Linkage strategy execution: Supports task synchronization and linkage between multiple terminals. For example, when a student clicks "voice playback" on the e-reader, the auxiliary terminal (such as a doll) plays AI-generated content, provided that the content is marked as "playable" and parental authorization is effective.

[0035] In addition, the system grants the main parent terminal the following control capabilities: 1. View the current status and task execution records of all terminals with one click; 2. Manage the online and offline status of each terminal, including temporarily disconnecting the usage rights of a terminal; 3. Assign default permission templates to different terminals, such as allowing a certain auxiliary terminal to only play first-grade Chinese language content; 4. Configure cross-terminal linkage strategies, such as playback control, behavior synchronization, and usage time restrictions.

[0036] Through the design and operation of this module, the system has achieved structured management of various terminals under the family account, clear division of roles, clear attribution of behavior, and stable control path, providing basic support for subsequent functions such as behavior auditing, permission accountability, and risk interception.

[0037] Summary of reinforced protection points: All terminals in the system have a unique terminal ID and role identification field, forming a clear device identity and permission boundary; All behavior paths, model calls, and execution permissions of the play task are determined according to the terminal role field; The parent terminal has unified terminal management capabilities, and can perform binding, unbinding, state checking, and permission control; The auxiliary terminal cannot actively initiate behavior and only runs as a content play executor to build an "output controllable" mechanism in the system.

[0038] (Four) Behavior chain synchronization and permission path control module

[0039] This module is used to realize the unified recording, path auditing, and permission supervision of all terminal behaviors in the system, and to build a behavior chain recording system and permission path control mechanism centered on the family account. This module ensures that each terminal-initiated AI call, learning interaction, or content request behavior forms a traceable, analyzable, and controllable chain structure record in the system, thereby realizing the whole-process supervision of "who uses AI, under what premise, and what is done".

[0040] 1. Structured recording mechanism of behavior chain

[0041] The system writes all the operation behaviors of the terminals under the family account into the behavior chain according to the standardized field structure. Each behavior node record includes but is not limited to the following fields: Terminal ID (DeviceID) and role identification (Role: Parent / Student / Assistant); Operation timestamp and behavior type (such as asking questions, requesting explanations, requesting answers, downloading content, etc.); Prompt path (PromptPath) and called prompt strategy template; Call model identification (ModelID) and model version; Output content type (explanation / answer / multi-round guidance) and style label; Operation belongs to parent account ID (used for attribution audit); System-determined permission state (compliance / overreach / intercepted); Optional fields: terminal state (active / idle), behavior score, feedback record, etc.

[0042] All behavior chain data is recorded in chronological order and aggregated based on the family account to form a complete behavior trajectory under the cooperation of multiple terminals.

[0043] 2. Real-time permission state synchronization and visualized supervision mechanism

[0044] The parent terminal has the right to view the current operation status of all student terminals in real time. The system can show the following information to the parents: Whether it is currently in AI interaction (such as calling the model); Current task type (such as taking the title, repeating, requesting answers); Whether there is an unauthorized request (such as directly inputting "please tell me the answer"); The current prompt path and the called strategy module; If the auxiliary terminal is playing content, display its content source and authorization status.

[0045] This mechanism ensures that parents have full visibility without intervention, constituting a "soft participation, strong supervision" collaborative use experience.

[0046] 3. Permission blocking and "stop order" mechanism When the system detects the following behaviors of the student terminal: Bypass the prompt path and directly request answers; Upload suspected non-learning content (such as game screenshots, entertainment topics); Frequent requests for "direct answers" trigger system risk control rules; Other illegal content interactions unrelated to homework tutoring; The system will immediately block the path and pop up a notification page to the parent terminal, explaining the blocking reason and risk level.

[0047] Parents can choose: Issue a "stop order" to forcibly interrupt the current AI interaction of the student terminal and record the blocking reason; Or manually approve whether to temporarily release the request and generate an audit record.

[0048] All "stop behaviors" are written into the behavior chain with fields such as handler (parent), handling time, and handling result for subsequent backtracking and behavior analysis.

[0049] 4. Permission path closed loop and behavior audit capability

[0050] Every AI call, strategy decision, and terminal operation behavior in the system must go through permission path verification. The behavior path can only be allowed to execute when the following conditions are met: The terminal is a registered and bound device; The current operation is within the authorized permission range; The parent authorization chain is still in an effective state; The request path meets the prompt specification and strategy module standard.

[0051] If any condition is not met, the system will reject the call request of the behavior, record the behavior chain failure node and trigger the alarm mechanism.

[0052] Through this module, the system realizes the following key capabilities: Prevent copying homework: lock the behavior of directly requesting answers and parental approval; Prevent cross-border use: limit student terminal access to non-learning content or frequent unauthorized interaction; Prevent bypass behavior: Ensure that all behaviors are called through a legal path model and cannot skip the prompt template; Behavior audit capability: Form a complete and traceable behavior chain to support parental supervision and platform security governance.

[0053] Summary of reinforcement protection points: All terminal behaviors are structured and written into a unified behavior chain to form a time series behavior graph under the family account; The parent terminal has real-time supervision rights, stop rights and path approval rights, forming a "clear rights and responsibilities" use closed loop; The permission path is closed through three verifications of prompt path, device identity and parental authorization; The system has a full-process control mechanism of identification, interception, approval and recording, which is one of the core implementation paths of the invention to prevent students from abusing AI.

[0054] (Five) Controlled content playback and permission prompt module of auxiliary terminal

[0055] This module is used to realize the permission verification, output boundary control and parental authorization mechanism of auxiliary terminals (such as smart dolls, voice speakers, Bluetooth earphones, etc.) in the content playback process under the family account system, to ensure that all content playback behaviors are within the legal path specified by the system, and to prevent students from bypassing the main terminal to obtain unauthorized content or misuse content.

[0056] 1. Permission tag and playback eligibility mechanism of broadcast content

[0057] The system structurally annotates all AI-generated content and sets a permission tag of "whether it can be broadcast by an auxiliary terminal". This tag is dynamically generated according to the following conditions: Is the content from a parent terminal initiated (such as explanation content generated by a parent's request to take a test)? Is the content a standard question explanation module built-in the system, which has been audited and adapted to a specific grade? Has the content been audited, selected and authorized by the parent terminal and issued to the auxiliary terminal? Does the system determine that the content is age-appropriate, compliant, does not involve sensitive information, and does not contain direct answer prompts?

[0058] Only the content that meets the above conditions and is marked as "reportable" will be pushed to the auxiliary terminal for voice playback. Unauthorized content requests are intercepted.

[0059] 2. Permission verification mechanism for student terminal request to play

[0060] In actual use, students can trigger the playback behavior by clicking the "play explanation" button on the e-paper. After receiving the request, the system will perform the following verification process: Determine whether the content is marked as "reportable"; Determine whether the terminal triggering the request is a student terminal that has been bound; Determine whether the auxiliary terminal is currently online and in a playback permission enabled state; If any of the above conditions is not met, the request will be blocked immediately, and a blocking record will be generated.

[0061] The system will send a reminder notification to the parent terminal, including: Request time of the student terminal; Content summary of the request to play; Blocking reason (such as unauthorized, content not in compliance, permission setting off, etc.); Optional operation entry (such as parent choosing "temporary authorization once", "marking as long-term reportable", etc.).

[0062] 3. Style prompt and voice control tag mechanism for playback content

[0063] Before each reportable content is sent to the auxiliary terminal, the system will attach a set of control tags for the auxiliary terminal to perform voice output based on the tone, emotional style, and prompt rhythm: Style prompt field: such as "humorous type", "gentle type", "slow rhythm", "suitable for lower grades", etc. Voice template field: the system allocates audited role tone and voice package to the auxiliary terminal, which is pre-selected by the student; Prompt control field: such as "wait for student confirmation before continuing", "pause for three seconds after each sentence", etc.

[0064] The auxiliary terminal relies on the above tags to perform fixed format playback and does not have the ability of semantic understanding, content generation or re-expression, ensuring that it only exists as a playback terminal, strengthening the "output controllable" principle of the system structure.

[0065] 4. Security boundary and behavior isolation mechanism

[0066] To prevent the auxiliary terminal from being mistaken for an intelligent AI terminal, or for students to bypass content generation through voice interaction, this module explicitly restricts the following in the technical path: The auxiliary terminal cannot initiate model calls; The auxiliary terminal has no content generation capability and can only respond to content authorized by parents or system defaults; The voice input of the auxiliary terminal is limited to playback control instructions such as "pause" and "read again", and does not receive question expressions; Students cannot directly call prompt language paths or strategy templates through the auxiliary terminal, and the behavior chain always belongs to the parent-authorized main path.

[0067] This mechanism is particularly suitable for low-grade students, and builds a safe tutoring structure of "controlled playback, closed generation, and isolated content" to prevent children from accessing or misusing inappropriate content without supervision.

[0068] Summary of reinforcement protection points: All content must be marked as "playable" before it can be sent to the auxiliary terminal, forming a positive permission structure for playback rights; The student's playback request must be verified by the system, and parents can learn about all blocked requests and make authorization decisions; The playback content is accompanied by style prompts and voice template tags, and the auxiliary terminal is only a playback carrier and does not have AI capabilities; The auxiliary terminal and the generation terminal are completely isolated to ensure that young users have a controllable experience in companion learning; This module is the key defense line for "only play, not generate" and "read only, not ask", and is an important part of the family learning safety structure.

[0069] III. Overview of System Structure

[0070] This system is based on a family account architecture design and builds a multi-terminal AI homework tutoring collaborative control system with parents as the control center. The overall system includes the following five core modules:

[0071] 1. Family account structure and main parent binding mechanism: The system uses a family account as the management unit, and the main parent terminal completes the creation and identity authentication, and assumes all device authorization, unbinding, and permission configuration responsibilities, forming the control chain starting point.

[0072] 2. Student terminal registration and permission control module: The student terminal must be authorized by the parent before it can be registered and online, and all operation behaviors belong to the behavior chain of the bound parent account, ensuring that the AI usage path cannot bypass the parent control.

[0073] 3. Multi-terminal collaboration and binding relationship management module: Supports binding multiple student terminals and auxiliary devices to a family account, each terminal having a unique ID and role identification field, and the system implements cross-terminal behavior management and permission synchronization based on the binding relationship.

[0074] 4. Behavior chain synchronization and permission path management module: All terminal behaviors are written in real time to a structured behavior chain, and the system supports parents to view student operation status, issue "stop command" and block unauthorized paths, realizing full-process traceability and permission closed loop.

[0075] 5. Controlled content playback and permission prompt module of auxiliary terminal: Smart dolls, voice speakers and other auxiliary devices can only play authorized "playable" content and do not have the ability to generate; playback requests need to pass through system permission verification, and parents can review and decide on authorization.

[0076] Four, model calling structure and boundary protection mechanism

[0077] To ensure the compliance and effectiveness of education of students in using AI for homework tutoring, the present application constructs a model calling structure and boundary protection mechanism based on permission path and role field as the basis for judgment, which is used for controlling and managing the whole process of AI model access, triggering, calling and output, to prevent the model from being misused or misused.

[0078] 1. Model calling path encapsulation structure

[0079] All AI model calling operations in the system are triggered in the encapsulation structure of prompt path + strategy template + permission judgment + behavior chain mounting, forming a standard calling path. The path includes the following key fields: Device ID and role field (Role) of calling source terminal: used to determine whether the call is initiated by an authorized terminal; Prompt path ID (PromptPathID): used to verify whether it is triggered by a system-recognized prompt template; Strategy template ID and grade matching rule: used to determine the calling explanation style, generation method and output control; Binding parent account ID and permission status field: used to check whether the calling request is in a valid authorized state; Model selection and version field (ModelID / Version): used to specify the called AI model and the scope of use.

[0080] Only the calling request that meets the above field constraints is allowed to access the AI model to generate content. Otherwise, the request will be automatically blocked, and an alarm prompt will be sent to the parent terminal.

[0081] 2. Model invocation permission control mechanism

[0082] The system determines the permission of the model invocation behavior according to the terminal role and the parent permission path, including the following situations: Parent terminal invocation: complete model invocation permission, can initiate a request for a topic, select an explanation style, regenerate an explanation, etc. Student terminal invocation: only in the state of binding parent authorization can invoke the model, and is limited to the current prompt path and strategy template; Auxiliary terminal invocation: no model invocation permission, only can play the content copy generated by the system authorization, does not execute any generation task.

[0083] When the student terminal initiates a model invocation, the system will dynamically verify whether the current behavior is compliant, including whether to skip the prompt, whether to request a direct answer, whether to upload a non-learning related image, etc. For any unauthorized, bypass, abnormal invocation behavior, the system will immediately interrupt the invocation process, and process it through the "block → approve → record" three-step mechanism.

[0084] 3. Unauthorized behavior identification and blocking mechanism

[0085] The system realizes the active identification and blocking of the following unauthorized behaviors through behavior path analysis and strategy rule matching: Skip the prompt and directly input the question (such as: "What is the answer to this question?"). Frequently invoke "give me the answer" type requests to bypass the explanation path. Upload images unrelated to the current learning task, such as game screenshots and entertainment pictures. Try to trigger model invocation through voice control on an auxiliary terminal. Use an unregistered terminal or fake identity to initiate a call request.

[0086] Once the above behaviors are identified, the system will automatically block the invocation path, and according to the family account configuration, execute the following processing logic: Push the blocking notification to the binding parent terminal; Show the blocking reason and processing options (such as "stop the terminal" or "temporary authorization once"); Write the behavior node into the behavior chain and mark it as an "unauthorized node"; If the parent chooses "release once", the system records its approval action and responsibility attribution.

[0087] 4. Multi-model scheduling and boundary adaptation mechanism (optional module)

[0088] The system supports access to multiple different purpose large models, such as mathematical analysis model, language style reconstruction model, English composition polishing model, etc., and has the structure capability of "calling by subject + switching by strategy + scheduling by permission". No matter which model is used, all calling paths are constrained by a unified encapsulation structure and permission mechanism, ensuring consistent permissions, controlled paths, and auditable behavior in cross-model scenarios.

[0089] 5. Model calling node mounting mechanism in behavior chain

[0090] Each AI calling behavior generates a model calling node in the behavior chain, which records: Model calling time and version; Calling source terminal and role field; Prompt path and strategy template used; System determines the calling state (normal / unauthorized / parental release); Summary of calling output and whether to allow subsequent broadcast.

[0091] These fields can be used for subsequent: Learning process audit; Unauthorized use traceability; Content dissemination range control; Lesson plan sedimentation and version evolution (e.g., transformed into shared explanation with parental permission).

[0092] 6. Technical value and protection point summary of this module: All AI model calling behaviors are encapsulated in a permission path structure to prevent students from skipping prompts and directly calling; Student calling behavior must be based on parental authorization chain and prompt strategy template, forming a closed loop path; The system has the ability to automatically identify unauthorized behavior and provides a parental approval and stop mechanism; The behavior chain records all model calling nodes, building a traceable and auditable AI usage track; Achieve the "available but not out of bounds" AI calling control mechanism in the homework scenario.

[0093] Five, term definition and identification boundary explanation

[0094] (1) To avoid ambiguity or misjudgment in the implementation of the invention, the key terms involved in this specification and their technical boundaries are explicitly explained, and the following limitation statement is made on the control of large model calling behavior:

[0095] 1. Family account

[0096] The system master account structure created and maintained by parents is the starting point of the system's permission control and the center of behavior chain attribution. A family account can include multiple parent terminals and student terminals, and all their behavior data and model call records belong to the account.

[0097] 2、Parent Terminal

[0098] The parent terminal refers to the device used by parents, such as a mobile phone, tablet, or computer, which is bound through family account authentication. The parent terminal has core control capabilities such as system permission management, terminal authorization, path approval, and behavior supervision, and is the only permission configuration subject of the system.

[0099] 3、Student Terminal

[0100] The student terminal refers to the device used by students to receive AI homework tutoring services, such as an e-book, tablet, or computer. The student terminal cannot be independently registered or operated, and all behavior must be within the authorized range of the parent terminal and subject to system permission path constraints.

[0101] 4、Assistant Terminal

[0102] The assistant terminal refers to auxiliary devices that do not have model calling capabilities and are only used for content playback or voice broadcast, such as smart dolls, voice speakers, and Bluetooth headsets. This type of terminal can only play content explicitly marked as "playable" by the system and cannot generate, modify, or request AI content.

[0103] 5、Behavior Chain

[0104] The behavior chain refers to the structured record chain formed by each operation of the student or parent terminal during use, such as taking notes, calling models, requesting answers, and playing content. The behavior chain includes fields such as operation time, device ID, called model ID, prompt path, output summary, and permission status, which are used for subsequent behavior tracing, risk identification, and content sedimentation.

[0105] 6、Model Calling Path

[0106] The model calling path refers to the complete structured path that an AI model must go through before being called, including terminal identity verification, prompt template matching, strategy rule verification, and permission status confirmation. In this system, all AI calling behaviors must enter through a prompt, and path legality is a prerequisite for judgment, prohibiting any skipping, bypassing, or chain-breaking operations.

[0107] (II) Large Model Control Boundary Explanation (Special Declaration)

[0108] The AI homework tutoring service of the present application provides content generation capabilities based on existing publicly available generative artificial intelligence models (such as large language models, large visual models, etc.), but the present application itself does not involve the internal training, structural optimization or weight fine-tuning of these models, nor does it seek exclusive rights or control over the underlying capabilities of the models.

[0109] The present application only focuses on the design and implementation of the following model calling layer control structure: The encapsulation path of the calling request; The process mechanism of authority approval; Overpower identification and blocking logic; The mounting method of the calling node in the behavior chain; Role separation and path ownership of calling behavior under multiple terminals.

[0110] All model behaviors are considered as "black box calls", and the system only controls their input sources, calling permissions and output purposes. The present application does not rely on any specific model manufacturer or model type in technical implementation, supports multi-model compatible calling, and has platform neutrality and model replacement flexibility.

[0111] (Three) Boundary protection declaration

[0112] To avoid misunderstanding, the present application does not constitute the following technical demands: 1. It does not involve modification, training or distillation of AI models; 2. It does not claim to edit or rewrite the semantic layer of model-generated content, but only controls its generation conditions and calling permissions; 3. It does not use student behavior to train models or form ability profiles; 4. It does not collect students' identity information (such as name, grade, school, etc.), and all permission controls and behavior chains belong to the parent account; 5. It does not use the auxiliary terminal for interactive generation, but only as a controlled content reporting device.

[0113] The term definition and boundary description will serve as the basis for understanding during the review and implementation process. It is clear that the protection core of the present application lies in the family structured control mechanism and the permission management system of the model calling path, rather than the content itself or the research and development behavior of the model.

[0114] Six, path control and abnormal bypass blocking mechanism

[0115] To prevent students from bypassing the parental permission path during the use of AI homework assistance, directly obtaining answers, misusing models, or causing content to exceed boundaries, the invention designs and implements a path control mechanism and an abnormal bypass blocking system to ensure that model invocation behavior must pass through a compliant entry and run within the authorized range. Any attempt to bypass will be immediately identified, blocked, and disposed of by the parent terminal.

[0116] 1. Invocation path legality verification mechanism

[0117] The system performs path compliance checks on each model invocation request, including the following verification elements: Terminal role verification: Only student terminals bound to a family account and authorized to be online can initiate invocation requests; Prompt path verification: All model requests must be initiated through system-built or parent-set prompt templates, and students are not allowed to input free content directly to request answers; Strategy template mapping verification: Each invocation must match a specific strategy template (such as explanation style, grade adaptation, etc.); Permission state verification: Is the current invocation path in the authorized state set by the parent, or has it been disabled or limited by the parent? Invocation frequency and behavior characteristic verification: The system analyzes the semantics and frequency of repeated requests, direct expressions, and high-frequency answer requests to determine whether they are unauthorized behavior.

[0118] Only when all the above conditions are met will the system allow invocation requests to be made to AI models. Any single failure will be considered illegal and will trigger a blocking process.

[0119] 2. Abnormal bypass behavior type identification mechanism

[0120] Based on behavior semantic recognition, terminal invocation log analysis, and user behavior path modeling, the system can identify the following typical abnormal bypass behaviors: Skip the prompt template and directly input "What is the answer" "Help me write it out" and other request content; Try to use someone else's account or copy the behavior chain to invoke the model on an unbound device; Frequently request "change the wording" to indirectly try to get the standard answer; Upload image content containing non-learning scenarios (such as game screenshots, character memes, etc.); Try to activate the model service through voice password on the assistance terminal (such as "Help me answer" "Explain this question"); Replace the device or uninstall and reinstall to bypass the family account binding process and directly start the application.

[0121] Once the behavior is identified, the system will immediately block its call path and suspend the behavior node, waiting for the parent's confirmation processing.

[0122] 3. Block processing flow and parent permission wake-up mechanism

[0123] When the call path is blocked by the system, the system will synchronously execute the following processing flow: Terminal blocking: immediately interrupt the current call behavior and prevent data flow from entering the model service; Behavior record: write the complete abnormal behavior into the behavior chain of the bound parent, marked as "block node", with the blocking reason and behavior summary; Parent reminder: push an alarm notification to the bound parent terminal, showing the operation content attempted by the current terminal, the triggered blocking rule, and the optional processing method; Permission wake-up: the parent can choose "allow this call", "maintain blocking", "temporary unlock for 5 minutes", etc. processing strategy, and the system will decide whether to restore the path according to the processing result; Tracking mark: if the parent releases, the system will mark it as "overpower release behavior" in the behavior chain, with a responsibility confirmation mark.

[0124] This mechanism ensures that even if the student tries to bypass, the final decision is still in the hands of the parent, forming a strong protective closed loop.

[0125] 4. Block node behavior chain mounting and auditing mechanism

[0126] All blocked behavior nodes are mounted separately in the behavior chain and are distinguished from ordinary call nodes. Each block node records the following fields: Blocking time and terminal ID; Path type triggered by blocking (such as overpowered content, illegal device, non-prompt entry, etc.); System automatic blocking or parent stop triggering; Whether to generate an approval process and the final processing result; Optional fields: trigger frequency, semantic deviation degree, system blocking score, etc.

[0127] This mechanism supports the parent's later analysis of student usage behavior, and also provides risk identification and behavior modeling basic data for the platform, building a system-level supervisable and compliant capability.

[0128] 5. Technical value and protection focus of this module: All model call paths must comply with the structured verification mechanism to prevent skipping templates or strategies; The system has semantic analysis capabilities and can actively identify bypass input behavior; Abnormal behavior can be automatically blocked and parents are reminded synchronously, realizing a control loop. The parent terminal has the right to approve and stop, strengthening the family supervision responsibility. All blocking behaviors form independent audit nodes, facilitating behavior tracking and responsibility attribution.

[0129] Seven, beneficial effects

[0130] The application provides a multi-terminal AI homework tutoring collaborative control system based on a family account, which has significant technical advantages and use value in structure system, behavior control, safety boundary and compliance, etc. around the design core of "parent-led + permission path + multi-terminal collaboration + behavior chain supervision". Compared with the prior art, the following beneficial effects are mainly embodied:

[0131] 1. Establish a parent-centered permission control system to solve the problem of AI use out of control The system binds the family account structure and the main control parent through a binding mechanism, establishes the system logic of "parents as the control center", ensures that the use of all student terminals and auxiliary devices needs to run under the authorization of parents, effectively avoids the problem of students bypassing supervision and randomly calling AI models, and improves the controllability of AI use boundaries in the family education environment.

[0132] 2. Support multi-terminal collaborative binding to meet the use requirements in complex family scenarios The system supports the binding of multiple parent terminals, student terminals and auxiliary terminals under one family account, and distinguishes permissions through terminal role fields, adapting to the learning needs of families with different grades and different device combinations. All terminal behaviors are attributed to the parent control path, realizing a system structure with consistent permissions, collaborative behaviors and unified data attribution among terminals.

[0133] 3. Introduce a behavior chain recording mechanism to realize full-process traceability and clear behavior responsibility The application innovatively introduces a structured behavior chain mechanism, which records every model call, explanation request, answer approval and other operations of student and parent terminals, forming an auditable and traceable behavior track, strengthening the compliance and monitorability of the AI use process, especially suitable for compliance requirements in the learning scenario of minors.

[0134] 4. Set up a model call encapsulation path to prevent skipping prompts or bypassing generation Through the encapsulated prompt path and strategy template mechanism, the system clearly limits the model call entry, only allows legal path triggering generation operation, blocks the bypassing means of directly inputting answer requests or non-prompt call models, and improves the standardization of student learning behavior and the participation degree of thinking process.

[0135] 5. Configure abnormal behavior blocking mechanism, build overreach identification and parent stop closed loop The system has the ability to intelligently identify abnormal behaviors such as overreach input, non-learning image upload, and frequent request for answers, and can automatically block the path, generate an alarm, and arouse parental approval, forming a "system identification + parental intervention + behavior record" linkage mechanism to ensure that AI models are not misused or abused.

[0136] 6. Strengthen auxiliary terminal content control boundaries to ensure safe use by young students For voice speakers, smart dolls and other auxiliary terminals, the system sets a "can only play, cannot generate" permission boundary, allowing only the playback of content that has been audited by the system and marked as "playable". This prevents students from bypassing the main terminal restrictions through auxiliary terminals, effectively improving the use safety and content age appropriateness of young users.

[0137] 7. Decouple technology path and model, with high compatibility and scalability The permission path structure, behavior chain control mechanism, and terminal role management logic built by the invention are decoupled from the underlying AI model and do not rely on specific model vendors or training schemes, with good model neutrality and system universality. It can support multi-model access and cross-platform deployment, making it easy to promote application and continuous evolution.

[0138] In summary, the invention solves the key problems of "parents cannot monitor, students easily overreach, content cannot be controlled, and behavior is difficult to audit" in the AI homework tutoring scenario through systematic design of family structure, terminal role, calling path, and behavior chain. It has significant technical effects and social value in ensuring education quality, protecting minors, and improving AI compliance usage levels. List of drawings

[0139] Figure 1 : System overall structure diagram, showing the overall system structure and data interaction path between family account, parent terminal, student terminal, auxiliary terminal, and large model service.

[0140] Figure 2 : Family account structure and master parent binding flowchart, showing the binding process of family account creation, master parent identity authentication, other parent terminal authorized login, and terminal ownership relationship.

[0141] Figure 3 : Student terminal registration and permission path control flowchart, showing the specific path process of student terminal registration → parent authorization → permission initialization → behavior chain ownership judgment.

[0142] Figure 4: Multi-terminal cooperative binding and role field management structure diagram, showing the role identification, terminal ID binding relationship, behavior attribution structure and cooperative control logic of the three types of terminals of parents, students and assistants.

[0143] Figure 5 : Behavior chain synchronization and permission call path record structure diagram, showing the field composition structure of each terminal behavior writing into the behavior chain (such as terminal ID, strategy path, call model, timestamp, parent approval mark, etc.).

[0144] Figure 6 : Model call path encapsulation and exception identification processing flowchart, showing the processing flow of legal call path structure, skip prompt or overstepping behavior being identified and blocked (including parent approval mechanism).

[0145] Figure 7 : Parent terminal stop and approval path closed loop flowchart, showing how parents receive the blocking alarm through the terminal, view student behavior, select release / stop / maintain blocking, and how the system records the approval behavior.

[0146] Figure 8 : Controlled playing of auxiliary terminal and content permission verification flowchart, showing the process of auxiliary terminal playing request → system checking "playable label" → rejecting unauthorized content → parent receiving notification → content control. DETAILED DESCRIPTION

[0147] Example 1: Household account creation and main control parent binding process

[0148] A parent registers a household account in the system App, becomes the main control parent terminal of the account after completing mobile phone binding and face recognition identity verification. The main control parent adds another parent's mobile phone number in the account setting interface and completes login authorization through the App pop-up window, forming a "main + secondary" parent terminal structure in the household account. The system records the login behavior of all terminals and concentrates all subsequent terminal operation permissions in the household account under the main control parent identity, ensuring that the control right does not drift and the behavior chain attribution path is clear.

[0149] Example 2: Student terminal registration and permission control process

[0150] A family binds an e-paper book device as a student terminal, which is bound by the parent using the App to scan the code. The student terminal cannot enter the main interface before the binding is completed, and only displays "waiting for parent authorization". After the binding is completed, the student uses the e-paper book to shoot a math problem to request AI explanation. The system verifies that the request comes from an authorized student terminal, and the binding relationship is still valid, and then starts the explanation process through the specified prompt template. This calling behavior is automatically recorded into the behavior chain of the binding parent, and the student has no right to change the prompt template or view the answer, ensuring that the entire process runs under the control of the parent.

[0151] Example Three: Multi-terminal Cooperation and Terminal Role Division

[0152] The following devices are bound under a certain family account: Father's mobile phone (parent terminal) Mother's tablet (cooperative parent terminal) Child's e-paper book (student terminal) Smart doll (auxiliary terminal)

[0153] The system assigns each device a unique terminal ID and role field (Parent / Student / Assistant). The father can uniformly manage the online status and usage rights of all devices; the mother can perform tutoring operations on the student terminal after being authorized; the e-paper book is the main learning terminal and can only call the model under the authorization of the parents; the smart doll can only play the "playable content" marked by the system and cannot initiate AI calls or receive free instructions. All behavior chain paths are clearly attributed to the master parent, forming a closed-loop control structure.

[0154] Example Four: Behavior Chain Recording and Over-authorization Blocking Process

[0155] When the student uses the e-paper book to learn, he tries to bypass the prompt template and directly input "please tell me the answer". The system recognizes this behavior as an "over-authorization request to skip the prompt template", immediately blocks the model call, and generates a blocking behavior node to write into the behavior chain. At the same time, the system pushes a pop-up window to the binding parent's mobile phone, prompting "the child terminal attempts to directly ask for the answer, do you allow this behavior to pass". The parent chooses "reject the request", the system terminates the call path, and the behavior chain records the parent's approval operation and blocking reason. This mechanism ensures that the model usage process is legal and controllable, and the path behavior is fully auditable.

[0156] Example Five: Broadcast Permission Control Mechanism for Auxiliary Terminal

[0157] The student clicks the "voice playback" button on the e-paper book terminal and requests the smart doll to read the generated explanation content. The system first detects whether the content is marked as "playable" type. If the label field is "allow auxiliary terminal to play", it will be pushed to the smart doll to play. If the content contains sensitive words or is not marked by the audit, the system will reject the playback request and send a notification to the parent terminal: "playback request is blocked, content is not authorized for audit". This mechanism ensures that the auxiliary terminal is only used to play audited content, and students cannot use it to obtain or generate model output content, strengthening the boundary for young users.

[0158] Embodiment six: abnormal path blocking and parent approval closed-loop mechanism

[0159] During a use process, the student attempts to continuously input "change a way" "direct a little more" "is there a standard answer" and other ambiguous expressions in the e-paper book. The system identifies that the behavior has a "strategy bypassing tendency" and determines that it is a high-risk request, blocking the model call and prompting a pop-up window: "the current operation has exceeded the template authorized path, please confirm whether to release by the parent".

[0160] The system synchronously pushes a notification to the parent terminal, and the prompt content includes: summary of the student's current behavior; blocking trigger rules (such as bypassing prompt templates, multiple calls to high-risk words); whether to allow this request to pass temporarily.

[0161] The parent selects "release once", and the system records the approval behavior node and removes the block, which only takes effect for the current request; if the parent selects "maintain blocking", the system terminates the path and records the student's attempt behavior. This mechanism ensures that the parent has the final approval right for model use, realizing the closed-loop control of abnormal path identification, blocking and approval.

[0162] Embodiment seven: multi-student terminal risk linkage and behavior synchronization control

[0163] In a family with two student terminals (for example, the older brother uses an e-paper book and the younger sister uses a tablet), the older brother's terminal has multiple unauthorized behaviors (continuous attempts to directly request answers). After the system identifies that the behavior risk level has risen, it marks it as "high-risk state" in the behavior chain.

[0164] The system notifies the parent terminal according to the family account structure: the current student A has unauthorized risk, and it is recommended to temporarily limit the model call permission of other student terminals (student B) to avoid similar problems when the parent cannot supervise.

[0165] The parent terminal can choose: suspend the AI call permission of all student terminals; only lock the current behavior risk terminal; Ignore and continue monitoring.

[0166] This type of multi-terminal linkage control mechanism builds cross-terminal behavior collaboration and risk control response capabilities, which is particularly suitable for scenarios where multiple children in a family use AI devices at the same time, improving overall compliance.

[0167] Example 8: Expression Version Control and Auxiliary Terminal Broadcast Path Restrictions

[0168] After the parent takes a picture of the question and generates the explanation content, the system generates two versions of the explanation: 1. Standard academic style version; 2. A humorous version using metaphors.

[0169] Parents selected the second version for their child to understand and requested that it be sent to an auxiliary terminal (such as a smart doll) for playback. However, the system detected that this version contained "inappropriate content tags" (e.g., it used popular internet slang and exaggerated metaphors that did not meet the standards for first-grade Chinese language learning), and therefore marked it as "not suitable for playback".

[0170] After the student clicks to play, the system intercepts the request and prompts: "This content is not suitable for playback on auxiliary terminals. Parents, please select another version or use the main device to play it." At the same time, a prompt appears for parents to choose whether to "regenerate the version with the default style" or "allow reading only on the e-reader."

[0171] This mechanism ensures that the auxiliary terminal operates only as a controlled broadcasting channel, and all broadcast content must pass the expression version filtering and playback permission tag verification to prevent students from bypassing the content control boundaries through voice devices.

Claims

1. A multi-terminal AI-based collaborative control system for homework tutoring based on family accounts, characterized in that, include: The family account structure and the parent-control binding mechanism are used by the parent terminal to create family accounts, complete the parent-control identity authentication and account initialization, and assume the responsibilities of terminal authorization, unbinding and permission configuration; The student terminal registration and permission control module is used to complete the registration and binding of student terminals under the authorization of the master parent terminal, and to restrict the AI ​​call permissions, login behavior and operation scope of the student terminal, ensuring that all its behavior belongs to the bound parent account; The multi-terminal collaboration and binding relationship management module is used to bind multiple parent terminals, multiple student terminals and multiple auxiliary terminals under a family account, and to configure a unique terminal identifier and terminal role field for each terminal to realize the division of permissions and the attribution of behavior chain; The Behavior Chain Synchronization and Permission Path Control Module is used to write the interactive behaviors of each terminal during the homework tutoring process into a structured behavior chain, record the prompt path, strategy template, call model information and permission status, and also support parents to view the status of the student terminal in real time and issue a stop command. The system records the stop behavior in the behavior chain. The controlled content playback and permission prompt module of the auxiliary terminal is used to control the auxiliary terminals such as smart dolls and voice speakers to only play content marked as "playable" by the system, and to automatically block and simultaneously prompt the parent terminal when the student requests to play unauthorized content. The auxiliary terminal does not have the ability to generate content, nor can it trigger the AI ​​call path.

2. The system as described in claim 1, characterized in that, The family account structure and the master parent binding mechanism allow multiple parent terminals to join the same family account, but each login requires authorization confirmation from the master parent terminal, and all permission modification behaviors are recorded in the master parent's behavior chain.

3. The system as described in claim 1, characterized in that, The student terminal registration and permission control module prohibits students from logging in, unbinding, or changing permission settings on their own terminals. All behavior permissions and model call requests must be configured by the bound parent terminal and synchronized in real time.

4. The system as described in claim 1, characterized in that, In the multi-terminal collaboration and binding relationship management module, each terminal has a terminal role field, which includes "Parent", "Student" and "Assistant", and serves as the basis for determining the behavior chain affiliation and access permissions.

5. The system as described in claim 1, characterized in that, The multi-terminal collaboration and binding relationship management module allows the parent control terminal to configure the online status, binding relationship, default usage permissions, and time period restriction policies of each terminal through the user interface.

6. The system as described in claim 1, characterized in that, Each behavior chain node recorded by the behavior chain synchronization and permission path control module includes, but is not limited to: terminal identifier, operation time, prompt path identifier, policy template identifier, calling model version, output summary, permission status, parent approval record, and abnormal behavior marker field.

7. The system as described in claim 1, characterized in that, The behavior chain synchronization and permission path control module allows parents to view the current operation status of the student's terminal in real time, including whether it is in AI interaction, whether it is requesting direct answers, whether it is submitting non-learning content, etc., and can stop the subsequent operation of the terminal with one click. The system writes the stop behavior into the behavior chain to form an auditable record.

8. The system as described in claim 1, characterized in that, In the controlled content playback and permission prompting module of the auxiliary terminal, the system adds style prompt tags and voice control fields to each playable content to limit the timbre type, playback rhythm and playback permission range used by the auxiliary terminal.

9. The system as described in claim 1, characterized in that, The controlled content playback and permission prompting module of the auxiliary terminal prohibits the auxiliary terminal from initiating any content generation request, and also prohibits students from triggering the AI ​​content calling process through voice commands or graphical interaction.

10. The system as claimed in claim 1, characterized in that, When a student's terminal requests to play unauthorized content, the system will automatically block the request path and send a notification to the linked parent's terminal. The notification includes a summary of the playback request, the requesting terminal's identifier, and the reason for blocking, allowing the parent's terminal to decide whether to temporarily allow the playback.

Images