Method for providing recovery mission service providing artificial intelligence based customized recovery mission information based on self-diagnosis of condition after exercise

Abstract

A method for providing a recovery mission service may include the following operations: in response to receiving a designated signal from a wearable device, identifying a target stadium among a plurality of stadiums based on the GPS signal of the designated signal; identifying a target sports match performed at the target stadium based on stadium identification information of the target stadium and the time of receiving the designated signal; in response to identifying that the target sports match has ended through schedule information of the target sports match, providing a self-diagnosis input interface to a user terminal; receiving self-diagnosis data and identifying a risk of injury area based on the sports type of the target sports match and the self-diagnosis data; confirming a target recovery mission set in correspondence with the risk of injury area and mission information for the target recovery mission; and transmitting the mission information to the user terminal whenever the leisure time arrives each day.

Description

Technology Field

[0001] The present invention relates to a method for providing a recovery mission service that provides AI-customized recovery mission information based on self-diagnosis of condition after exercise. Background Technology

[0002] After participating in or watching sports events, users often find themselves in a state requiring recovery due to muscle fatigue, joint strain, and micro-injuries. However, in real-world settings, the problem of failing to perform recovery routines in a timely manner immediately after the game or on the evening of the same day repeatedly occurs. Such gaps in recovery management can lead to chronic pain and an increased risk of injury.

[0003] Conventional recovery guidance technology typically operates by providing a predefined routine based on the user's input of pain locations or physical condition. However, this approach has limitations in terms of personalization; if the input information is fragmentary or subjective, it may differ from the actual risk areas, and it fails to adequately reflect injury patterns based on treatment history or sport characteristics. Furthermore, it is difficult for service providers to quantitatively verify whether the user is performing the routine and the quality of that performance, making it challenging to encourage continued use.

[0004] Even if wearable-based fatigue estimation and recovery recommendation technologies exist, relying solely on wearable data has limitations in identifying injury-risk areas at the individual body part level. Additionally, there are cases where situational information, such as collisions during a game or specific joint usage patterns, is not sufficiently reflected. Furthermore, because it is difficult to accurately verify the performance of recovery missions using only wearable data, the rate of actual execution of recovery missions may be low.

[0005] While video-based motion analysis technology can determine exercise quality through posture estimation or motion evaluation, instances where it is implemented as a continuous service flow—connecting from specific matches performed at a stadium to the provision of recovery missions after the game—may be limited. Even if match footage exists, actual service application is difficult due to the complexity of the data linkage structure required for identifying and tracking specific users, extracting exercise data, and incorporating it into recovery missions.

[0006] While the continuous execution of recovery missions is crucial from a long-term perspective, it is difficult to maintain user participation because they are often limited to providing notifications or simple points. In particular, if benefits are not provided in a form that allows users to experience content directly related to the game, or if a quantitative evaluation system based on performance history is absent, the persuasiveness of reward provision decreases, which may lead to a decline in sustainability. The problem to be solved

[0007] According to the present invention, a target stadium can be identified using a designated signal and location information generated by a button input of a wearable device, a target sports match can be identified based on the time of reception of the designated signal, and the end of the match can be confirmed through match schedule information to provide a self-diagnosis input interface. Accordingly, the recovery process is automatically initiated at a point where the user is likely to miss the recovery routine, thereby reducing the omission of recovery execution.

[0008] According to the present invention, injury risk areas can be identified by considering the pain location, treatment history, leisure time, and sport type received from a user terminal. Accordingly, compared to recommendations based on simple surveys, it is possible to identify risk areas that match the user's condition and sport characteristics, thereby enabling the improvement of personalization accuracy.

[0009] According to the present invention, user exercise data is extracted based on a plurality of video data acquired from a game data server, and injury risk areas can be determined by combining the exercise data with self-diagnosis information. Accordingly, since actual motion characteristics and collision characteristics in game situations can be reflected rather than relying solely on the user's subjective input, the effect of strengthening the basis for recovery missions can be expected.

[0010] According to the present invention, the number of repetitions per mission can be set based on load-related values ​​and range-of-motion-related values ​​of injury-risk areas included in exercise data. Accordingly, the amount of work can be adjusted to suit the user's condition, thereby preventing deterioration caused by excessive work and mitigating the reduction in effectiveness caused by insufficient work, so that recovery efficiency can be expected.

[0011] According to the present invention, after providing mission information a certain number of times, execution history data is received, and if the mission score based on the execution history data exceeds a threshold score, the number of virtual album slots is increased, and a highlight video featuring the user is extracted and provided from the video data. Accordingly, a feedback loop is formed in which the execution, evaluation, and provision of benefits of the recovery mission are linked, thereby promoting user participation and improving continuous performance.

[0012] The technical problems of the present invention are not limited to those mentioned above, and other unmentioned technical problems will be clearly understood by those skilled in the art from the description below. means of solving the problem

[0013] A method for providing a recovery mission service, which is performed by a service providing server including a processor according to one embodiment of the present invention and provides AI-customized recovery mission information based on self-diagnosis of post-exercise condition, wherein

[0014] The above processor may include the operation of identifying a target stadium among a plurality of stadiums based on the GPS signal of the designated signal in response to receiving a designated signal from a wearable device; the operation of identifying a target sports game among a plurality of sports games performed at the target stadium based on stadium identification information of the target stadium and the time of reception when the designated signal is received; the operation of providing a self-diagnosis input interface to a user terminal registered in correspondence with the wearable device in response to identifying that the target sports game has ended through schedule information of the target sports game received from a game data server; the operation of receiving self-diagnosis data including a pain area, treatment history, and leisure time from the user terminal and identifying a risk of injury area based on the sports type of the target sports game and the self-diagnosis data; and the operation of confirming mission information including a target recovery mission set in correspondence with the risk of injury area, a method for performing the mission for the target recovery mission, a time for performing the mission, and precautions, and transmitting the mission information to the user terminal whenever the leisure time arrives every day.

[0015] According to one embodiment, the recovery mission service providing method may include the operation of the processor acquiring a plurality of video data captured for the target sports game from a game data server, the operation of the processor extracting exercise data including the load amount and range of motion of the user's joints and collision areas based on the plurality of video data, and the operation of the processor determining the injury risk area based on the pain area and treatment history included in the self-diagnosis data and the exercise data.

[0016] According to one embodiment, the operation of determining the injury risk area may include the operation of the processor comparing the pain area included in the self-diagnosis data and the collision area included in the exercise data with a body part classification table, and the operation of the processor determining a preset representative area corresponding to the target category as the injury risk area when the pain area and the collision area are included in one of the target categories among the plurality of categories included in the body part classification table. For example, the operation of determining the injury risk area may include the operation of the processor determining the pain area as the injury risk area in response to the pain area and the treatment area according to the treatment history being the same when the pain area and the collision area are not included in one of the target categories among the plurality of categories included in the body part classification table. For example, the operation of determining the injury risk area may include the operation of the processor determining the collision area as the injury risk area when the pain area and the collision area are not included in one of the target categories among the plurality of categories included in the body part classification table and the pain area and the treatment area according to the treatment history are different.

[0017] According to one embodiment, the operation of providing the mission information may include the operation of the processor setting the number of repetitions per mission and providing it to the user terminal in proportion to the size of the target load amount and the target operating range of the injury risk area included in the exercise data.

[0018] According to one embodiment, the recovery mission service providing method may include: the operation of the processor receiving execution history data for the mission information from the user terminal after providing the mission information seven times; the operation of the processor increasing the number of virtual album slots corresponding to the user terminal and provided for video storage in proportion to the difference between the mission score and the threshold score when the mission score according to the execution history data exceeds a threshold score; and the operation of the processor extracting the highlight video in which the user appears within the plurality of video data and providing it to the user terminal. For example, the mission score may be calculated based on the average execution time for each of the mission information, the number of consecutive executions, the average start delay time from the time the mission information is provided to the time the recovery mission is started, the number of uploaded mission execution videos, the ratio of the total length of the uploaded mission execution videos to the mission execution time, and the total playback time of the mission execution videos by the user terminal.

[0019] The above method of providing recovery mission services is,

[0020] The above processor includes an operation of calculating the mission score based on the following mathematical formula 1, and

[0021]

[0022] S is the mission score, T_avg is the average execution time for each of the mission information, T_unit,avg is the average value of the standard execution time set for each mission information provided, C_seq is the number of consecutive executions, N_up is the number of uploaded mission execution videos, P_total is the total playback time during which the uploaded mission execution videos were actually played on the user terminal, D_delay is the average start delay time from the time the mission information was provided until the time the recovery mission execution began, w_1 to w_4 are weights assigned according to the importance of each indicator, and k is a damping coefficient for adjusting the damping intensity for the average start delay time.

[0023] The above recovery mission service provision method includes, when the processor receives the mission performance video from the user terminal for three consecutive days, generating a high-quality image based on the target frame with the largest bounding box corresponding to the user within the highlight video, and inserting the high-quality image into a specific slot of the virtual album corresponding to the user terminal.

[0024] The above recovery mission service provision method includes: an operation in which the processor transmits a push notification to the user terminal in response to the arrival of the leisure time, and simultaneously transmits a vibration generation signal of a preset pattern to the wearable device; and an operation in which the first execution step screen of the mission information is forcibly activated on the screen of the user terminal only when a button input of the wearable device is confirmed.

[0025] The above recovery mission service provision method includes: an operation in which the processor determines whether to pay virtual points and the amount to pay based on a preset winning probability when the mission score exceeds the threshold score; and an operation in which the processor transmits a reward winning notification to the user terminal according to the determined result, and at the same time confirms that the highlight video has been played for 15 seconds or more on the user terminal, finally pays the virtual points.

[0026] The above recovery mission service provision method includes the operation of the processor sharing the mission performance video received from the user terminal with at least one external terminal and opening a tournament-style voting game; and the operation of providing additional points to the user terminal in addition to the virtual points when the mission performance video is determined to be within a predetermined rank according to the voting results by the at least one external terminal.

[0027] The above method for providing a recovery mission service comprises: an operation in which the processor determines the injury risk area, wherein the operation determines whether the pain area and the treatment area according to the treatment history are the same; an operation in which the processor extracts the user's address data from the account information of the user terminal if the pain area and the treatment area are the same; and an operation in which the processor identifies a target medical institution located at the shortest distance based on the address data from a pre-set external medical institution database corresponding to the pain area, and provides to the user terminal, together with the mission information, detailed location information of the target medical institution and distance information calculated from the address data to the target medical institution. Effects of the invention

[0028] The effects of the recovery mission service provision method according to embodiments of the present invention are described as follows.

[0029] According to the present invention, a target stadium can be identified using a designated signal and location information generated by a button input of a wearable device, a target sports match can be identified based on the time of reception of the designated signal, and the end of the match can be confirmed through match schedule information to provide a self-diagnosis input interface. Accordingly, the recovery process is automatically initiated at a point where the user is likely to miss the recovery routine, thereby reducing the omission of recovery execution.

[0030] According to the present invention, injury risk areas can be identified by considering the pain location, treatment history, leisure time, and sport type received from a user terminal. Accordingly, compared to recommendations based on simple surveys, it is possible to identify risk areas that match the user's condition and sport characteristics, thereby enabling the improvement of personalization accuracy.

[0031] According to the present invention, user exercise data is extracted based on a plurality of video data acquired from a game data server, and injury risk areas can be determined by combining the exercise data with self-diagnosis information. Accordingly, since actual motion characteristics and collision characteristics in game situations can be reflected rather than relying solely on the user's subjective input, the effect of strengthening the basis for recovery missions can be expected.

[0032] According to the present invention, the number of repetitions per mission can be set based on load-related values ​​and range-of-motion-related values ​​of injury-risk areas included in exercise data. Accordingly, the amount of work can be adjusted to suit the user's condition, thereby preventing deterioration caused by excessive work and mitigating the reduction in effectiveness caused by insufficient work, so that recovery efficiency can be expected.

[0033] According to the present invention, after providing mission information a certain number of times, execution history data is received, and if the mission score based on the execution history data exceeds a threshold score, the number of virtual album slots is increased, and a highlight video featuring the user is extracted and provided from the video data. Accordingly, a feedback loop is formed in which the execution, evaluation, and provision of benefits of the recovery mission are linked, thereby promoting user participation and improving continuous performance.

[0034] In addition, various effects that can be identified directly or indirectly through this document may be provided. Brief explanation of the drawing

[0035] FIG. 1 is a block diagram showing the components of a service providing server according to one embodiment of the present invention. FIG. 2 is a block diagram showing the components of a recovery mission service providing system according to an embodiment of the present invention. FIG. 3 is a flowchart of the operation of a recovery mission service provision method according to an embodiment of the present invention. FIG. 4 is a flowchart of the operation sequence of a recovery mission service provision method according to an embodiment of the present invention. In relation to the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Specific details for implementing the invention

[0036] Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. It should be noted that in assigning reference numerals to the components of each drawing, the same components are given the same reference numeral whenever possible, even if they are shown in different drawings. Furthermore, in describing the embodiments of the present invention, if it is determined that a detailed description of related known components or functions would hinder understanding of the embodiments of the present invention, such detailed description is omitted.

[0037] In describing the components of the embodiments of the present invention, terms such as first, second, A, B, (a), (b), etc., may be used. These terms are intended merely to distinguish the components from other components, and the essence, order, or sequence of the components is not limited by the terms. Furthermore, unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which the present invention pertains. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this application.

[0038] Hereinafter, embodiments of the present invention will be described in detail with reference to FIGS. 1 to 4.

[0040] FIG. 1 is a block diagram showing the components of a service providing server according to one embodiment of the present invention.

[0041] According to one embodiment, the service providing server (100) may include a memory (110), a processor (120), a communication interface (130), and / or a display device (140). The configuration of the service providing server (100) illustrated in FIG. 1 is exemplary and the embodiments of the present invention are not limited thereto. For example, the service providing server (100) may further include components not illustrated in FIG. 1 (e.g., a web crawler, a user interface, an input device, a notification unit, a sensor unit, or at least one of any combination thereof).

[0042] According to one embodiment, the memory (110) may store instructions or data. For example, the memory (110) may store one or more instructions that cause the service provider server (100) to perform various operations when executed by the processor (120).

[0043] For example, the memory (110) may be implemented as a single chipset with the processor (120). The processor (120) may include at least one of a communication processor or a modem.

[0044] For example, the memory (110) can store various information related to the service provider server (100). For example, the memory (110) can store information regarding the operation history of the processor (120). For example, the memory (110) can store input data acquired by the service provider server (100), output data output by the service provider server (100), data acquired from an external server, a wearable device, a plurality of cameras and / or user terminals, etc.

[0045] For example, the memory (110) may include multiple storage devices of different types. For example, the memory (110) may include volatile and / or non-volatile storage media. For example, the memory (110) may include at least one of RAM (random-access memory), ROM (read only memory), eMMC (Embedded Multi-Media Card), or any combination thereof.

[0046] The steps of the method or algorithm described in connection with the embodiments disclosed in this specification may be directly implemented in hardware, software modules, or a combination of both, executed by the processor (120). The software modules may reside in a storage medium (i.e., memory (110)) such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, or a CD-ROM.

[0047] For example, the memory (110) is coupled to a processor (120), and the processor (120) can read information from a storage medium and write information to a storage medium. Alternatively, the memory (110) may be integrated with the processor (120). The memory (110) and the processor (120) may reside within an application-specific integrated circuit (ASIC). The ASIC may reside within a user terminal. Alternatively, the memory (110) and the processor (120) may reside as separate components within the user terminal.

[0048] According to one embodiment, the processor (120) may be operatively connected to the memory (110), the communication interface (130), and / or the display device (140). For example, the processor (120) may control the operation of the memory (110), the communication interface (130), and / or the display device (140).

[0049] According to one embodiment, the communication interface (130) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between a service provider server (100) and an external device (e.g., user terminal (210) of FIG. 2, game data server (220) and database, etc.), and the performance of communication through the established communication channel. The communication interface (130) may include one or more communication processors that operate independently of the processor (120) (e.g., application processor) and support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication interface (130) may include a wireless communication module (e.g., cellular communication module, short-range wireless communication module, or GNSS (global navigation satellite system) communication module) or a wired communication module (e.g., LAN (local area network) communication module, or power line communication module). Among these communication modules, the corresponding communication module can communicate with an external electronic device through a first network (e.g., a short-range communication network such as Bluetooth, WiFi (wireless fidelity) direct, or IrDA (infrared data association)) or a second network (e.g., a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a long-range communication network such as a computer network (e.g., LAN or WAN). These various types of communication modules may be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module can identify or authenticate a service provider server (100) within a communication network, such as the first network or the second network, using subscriber information (e.g., International Mobile Subscriber Identifier (IMSI)) stored in a subscriber identification module.

[0050] According to one embodiment, the display device (140) may include at least one output device that provides various information and a user interface to the user.

[0051] For example, the display device (140) may include a display device, an audio output device, a virtual reality output device, etc.

[0052] For example, the display device (140) can provide the administrator with various types of user interfaces (e.g., images) described in the present disclosure visually and / or audibly.

[0053] The components of the service provider server (100) illustrated in FIG. 1 are exemplary and the embodiments of the present disclosure are not limited thereto.

[0054] At least some of the embodiments of the present disclosure may be implemented as artificial intelligence (AI) through the processor (120) and memory (110) of the service providing server (100). The processor (120) may be composed of one or more processors, and the one or more processors may be general-purpose processors such as a CPU, AP, DSP (digital signal processor), etc., graphics-dedicated processors such as a GPU, VPU (vision processing unit), or artificial intelligence-dedicated processors such as an NPU. The one or more processors may be controlled to process input data according to predefined operation rules or artificial intelligence models stored in the memory (110). Alternatively, if the one or more processors are artificial intelligence-dedicated processors, the artificial intelligence-dedicated processors may be designed with a hardware structure specialized for processing a specific artificial intelligence model.

[0055] The predefined operation rules or artificial intelligence models are characterized by being created through learning. Here, being created through learning means that a predefined operation rules or artificial intelligence models configured to perform a desired characteristic (or purpose) are created by a basic artificial intelligence model being trained using a number of learning data by a learning algorithm. Such learning may be performed on the service providing server (100) itself where the artificial intelligence according to the present disclosure is performed, or it may be performed through a separate server and / or system. Examples of learning algorithms include supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but are not limited to the examples described above.

[0056] An artificial intelligence model may be composed of multiple neural network layers. Each of the multiple neural network layers has multiple weight values ​​and can perform neural network operations through operations between the results of previous layers and the multiple weights. The multiple weights possessed by the multiple neural network layers can be optimized based on the learning results of the artificial intelligence model. For example, the multiple weights can be updated so that the loss value or cost value obtained from the artificial intelligence model during the learning process is reduced or minimized. Artificial neural networks may include, but are not limited to, deep neural networks (DNN), convolutional neural networks (CNN), recurrent neural networks (RNN), restricted Boltzmann machines (RBM), deep belief networks (DBN), bidirectional recurrent deep neural networks (BRDNN), or deep Q-networks.

[0057] The service providing server (100) may use an artificial intelligence-based posture estimation model to determine the load amount, range of motion, and collision area of ​​each joint of the user based on multiple video data. The posture estimation model may be implemented with a structure including a convolutional neural network and is performed on a frame-by-frame basis for each of the multiple video data to calculate the body keypoint coordinates of the user. For example, the posture estimation model may output the reliability of each keypoint along with the two-dimensional or three-dimensional coordinates of keypoints corresponding to the head, shoulders, elbows, wrists, pelvis, knees, and ankles. Accordingly, the service providing server (100) calculates the joint angle, joint angular velocity, and acceleration from the time change of the keypoint coordinates per frame, calculates the load amount index of each joint of the user based on the calculated joint angle, joint angular velocity, and acceleration, and can also calculate the range of motion of each joint based on the difference between the maximum and minimum values ​​of the joint angle. Furthermore, the service providing server (100) can determine whether a collision has occurred and the collision area based on the change in distance between the user's body keypoint and the location information of another person's keypoint or game tool.

[0058] The service providing server (100) may use an artificial intelligence-based multi-object tracking model to identify the collision site of the user based on multiple video data. The multi-object tracking model may include a neural network structure that considers continuity between frames and may be configured to receive frame-by-frame person detection results as input to maintain the user's track identifier. For example, the multi-object tracking model may output a bounding box and track identifier of a person corresponding to the user on a frame-by-frame basis, and simultaneously output a bounding box for other people or game tools around the user. Accordingly, the service providing server (100) may calculate the distance and relative velocity between the user track and surrounding objects on a frame-by-frame basis, identify a section that rapidly converges below a threshold distance as a collision candidate section, and determine the body part to which the key point having the minimum distance from other objects among the user key points in the collision candidate section belongs as the collision site. Additionally, the service providing server (100) may quantify the collision site included in the motion data by determining the frame range of the collision candidate section as the start and end times of the collision event.

[0059] The service providing server (100) may use an artificial intelligence-based multi-viewpoint fusion model to more stably verify the load amount and range of motion of each user's joints based on multiple video data. The multi-viewpoint fusion model may be implemented in a structure that aligns frames of the same viewpoint from multiple video data captured at different shooting locations and integrates keypoints for the aligned frames to reconstruct a three-dimensional posture. For example, the multi-viewpoint fusion model may back-project keypoints estimated in each frame into three-dimensional space using the intrinsic and extrinsic parameters of each camera, and output three-dimensional keypoint coordinates of the user's joints by combining multiple observations in a least-squares manner. Accordingly, the service providing server (100) may calculate joint angles from the three-dimensional keypoint coordinates, calculate the range of motion of each joint based on the time change of the joint angles, and calculate a load amount index for each joint based on the magnitude of the joint angular velocity and joint acceleration. In addition, the reliability of the location of the collision event and the collision area may be improved by using distance calculation based on three-dimensional coordinates.

[0060] A service providing server (100) may use an artificial intelligence-based exercise event segmentation model to generate exercise data including joint-specific load, range of motion, and collision areas based on multiple video data. The exercise event segmentation model may include a neural network structure that processes time-axis features and may be configured to classify exercise segments and collision segments by receiving frame-specific keypoint features and object tracking features as inputs. For example, the exercise event segmentation model may output segment labels that distinguish normal movement segments, sudden stop segments, jump segments, and contact segments for a frame sequence. Accordingly, the service providing server (100) may determine collision areas in a set of frames labeled as contact segments and generate exercise data by aggregating joint-specific range of motion and joint-specific load indicators in a set of frames labeled as exercise segments. Additionally, the service providing server (100) may reflect movement characteristics by sport type by applying different sets of event labels depending on the sport type.

[0061] The service providing server (100) may use an artificial intelligence-based risk estimation model to determine the injury risk area using the load amount, range of motion, and collision area for each joint calculated based on multiple image data. The risk estimation model may be implemented in a structure including a multilayer perceptron or a graph neural network and may be configured to receive a user-specific feature vector as input and output a risk score for each body part. For example, the feature vector may include sports type, pain area, treatment history, load amount indicator for each joint, range of motion for each joint, and collision area information. Accordingly, the service providing server (100) may determine the area having the maximum value among the risk scores for each body part as the injury risk area, select a recovery mission mapped to the injury risk area, and transmit it to the user terminal.

[0062] The service providing server (100) may use an artificial intelligence-based highlight section detection model to extract a highlight video in which a user appears within multiple video data. The highlight section detection model may include a neural network structure that processes time-axis features and may be configured to receive features such as changes in the speed of the user track, whether a collision event occurs, changes in the load indicator of a specific joint, and rapid changes in the range of motion of the joint as inputs, and output a highlight score. For example, the highlight section detection model may output the start and end times of the highest score section along with a score for each section of the frame sequence. Accordingly, the service providing server (100) may generate a highlight video in which a user appears by cutting a synchronized frame section from multiple video data based on the output section, and provide the generated highlight video so that it can be saved in a virtual album slot of the user terminal.

[0064] FIG. 2 is a block diagram showing the components of a recovery mission service providing system according to an embodiment of the present invention.

[0065] According to one embodiment, the recovery mission service providing system may include a service providing server (100), a user terminal (210), and a game data server. Additionally, the recovery mission service providing system may further include a wearable device worn by a user participating in a target sports game.

[0066] According to one embodiment, the service providing server (100) is a server device including a processor and memory, and may be configured to store and execute a function module for providing a recovery mission service. The service providing server (100) may be configured to identify a target stadium and specify a target sports match by receiving a designated signal from a wearable device as a trigger, and then initiate a recovery mission provision procedure. Here, the designated signal may be implemented as a signal generated by an input in which a user presses a button on a wearable device.

[0067] The service providing server (100) may be configured to identify a target stadium among multiple stadiums based on location information included in or associated with a designated signal. After verifying the stadium identification information of the target stadium, the service providing server (100) may be configured to identify a target sports match among multiple sports matches performed at the target stadium based on the time of reception when the designated signal is received. For example, the service providing server (100) may identify a target sports match by matching the stadium identification information with a match identifier corresponding to the time of reception.

[0068] The service providing server (100) may be configured to identify whether the target sports match has ended using schedule information of the target sports match received from the match data server. The service providing server (100) may be configured to provide a self-diagnosis input interface to a user terminal in response to the identification of the end of the target sports match, and to receive self-diagnosis data including the pain area, treatment history, and leisure time from the user terminal. The service providing server (100) may be configured to identify the injury risk area based on the sports type and self-diagnosis data.

[0069] The service providing server (100) may be configured to acquire multiple video data captured for a target sports game from a game data server and to extract user exercise data based on the multiple video data. The service providing server (100) may execute an artificial intelligence-based posture estimation model on the multiple video data to calculate the user's body keypoints on a frame-by-frame basis and may calculate the range of motion for each joint based on the time change of the calculated keypoints. Additionally, the service providing server (100) may calculate a load index for each joint based on the joint angular velocity or joint acceleration and the amount of change in the joint angle, and may determine whether a collision event has occurred and the collision location based on the change in distance between the user and another person or game tool.

[0070] The service providing server (100) may be configured to determine an injury risk area by combining self-diagnosis data and exercise data, and to verify mission information including a target recovery mission set in response to the injury risk area, a method for performing the mission, a time for performing the mission, and precautions, and to transmit it to a user terminal. The service providing server (100) may transmit mission information to the user terminal whenever leisure time arrives each day, and may be configured to receive performance history data after providing mission information seven times and to calculate a mission score. The service providing server (100) may be configured to increase the number of virtual album slots when the mission score exceeds a threshold score, and to extract a highlight video featuring the user from multiple video data and provide it to the user terminal.

[0071] According to one embodiment, the user terminal (210) is a terminal device identifiable in association with a user account and may be configured to communicate with a service provider server (100) to display a self-diagnosis input interface and to receive and transmit self-diagnosis data. The user terminal (210) may receive input regarding the pain area, treatment history, and leisure time, and transmit the received self-diagnosis data to the service provider server (100). Additionally, the user terminal (210) may be configured to display mission information received from the service provider server (100) and to provide guidance on the mission execution method, mission execution time, and precautions.

[0072] The user terminal (210) may include a notification function to expose mission information to the user when leisure time arrives. When the user terminal (210) receives mission information transmitted by the service provider server (100), it may be configured to display a notification or automatically output a mission screen at a time corresponding to leisure time. Accordingly, the user can easily recognize the performance of recovery missions within their daily schedule.

[0073] The user terminal (210) may be configured to collect recovery mission execution history and generate execution history data. For example, the user terminal (210) may record the start time and end time of mission execution, and calculate and store the mission execution time. Additionally, the user terminal (210) may be configured to store an execution state to determine whether to perform continuously in response to mission information provided seven times, and to transmit execution history data to a service provider server (100).

[0074] The user terminal (210) may include a function for capturing and uploading a mission performance video. The user terminal (210) may store the video captured during the mission performance in a local storage and may upload the mission performance video to a service provider server (100) upon the user's upload request. Additionally, the user terminal (210) may calculate the total playback time of the uploaded mission performance video or store a playback log to include in the performance history data.

[0075] The user terminal (210) may be configured to receive a highlight video from the service providing server (100) and display it in the form of a virtual album. The user terminal (210) may be configured to manage the number of video items that can be stored in correspondence with the number of virtual album slots, and to activate an additional storage area when the number of slots increases. Additionally, the user terminal (210) may provide a highlight video playback function and generate a playback log to provide to the server as execution history data or service usage data.

[0076] According to one embodiment, the match data server (220) is a server device that stores and manages match metadata of a target sports match and may be configured to provide match schedule information to the service providing server (100). The match metadata may include stadium identification information, a match identifier, a match start time, and a match end time. The service providing server (100) may determine whether the target sports match has ended using the schedule information received from the match data server.

[0077] The match data server (220) may be configured to support the identification of a specific match among multiple sports matches performed at a target stadium. For example, the match data server (220) may provide stadium identification information and a list of matches corresponding to a specific time interval, and the service provider server (100) may select one of the candidate matches corresponding to the time of receiving a designated signal as the target sports match. Accordingly, the target sports match can be reliably identified even in a multi-match operation environment.

[0078] The game data server (220) may be configured to manage multiple video data captured for a target sports game and provide them to the service providing server (100). The game data server (220) may provide metadata including a video identifier per camera and shooting time information or frame index information, and the service providing server (100) may sort multiple video data based on the time axis according to the metadata and use them for analysis.

[0079] The game data server (220) may support at least one of a file transmission method or a streaming method as a method of providing multiple video data. The game data server (220) may be configured to provide a video segment corresponding to a specific time interval or to provide the entire game video in response to a request from the service providing server 100. Accordingly, the service providing server (100) can efficiently secure video data necessary for verifying the load amount, range of motion, and collision area for each joint.

[0080] The match data server (220) may include access control and authentication functions. The match data server (220) may be configured to perform authentication token-based verification on a request from the service provider server (100) and to allow access to schedule information or video data only upon successful verification. Accordingly, unauthorized viewing or leakage of match schedule information and video data can be prevented.

[0081] According to one embodiment, a wearable device (not shown) is a device that can be worn by a participant in a target sports game and may be configured to generate a designated signal and provide it to a service providing server (100). The designated signal may be generated by an input in which a user presses a button on the wearable device, and the time at which the designated signal is generated may be used as a reference time for the service providing server (100) to perform a target game identification procedure. Accordingly, the user may explicitly indicate a specific time to induce a subsequent service procedure.

[0082] A wearable device can generate or collect location information and can include location information in a designated signal or provide location information in a form associated with a designated signal. A service providing server (100) can identify a target stadium using location information included in or associated with a designated signal. At this time, the location information may include coordinate information such as latitude and longitude.

[0083] The wearable device may be configured to operate in conjunction with a user terminal (210). The wearable device may transmit a designated signal to the user terminal (210) via short-range wireless communication, and the user terminal (210) may be configured to relay the designated signal to a service provider server (100). Additionally, the wearable device may be configured to directly connect to a network and directly transmit the designated signal to the service provider server (100).

[0084] The wearable device may include linkage information with a user terminal (210). The linkage information may include a user account identifier, a wearable device identifier, or pairing information, and the service providing server (100) may identify the user terminal 210 corresponding to a designated signal using the linkage information. Accordingly, the provision of a self-diagnosis input interface and the transmission of mission information may be performed on the appropriate terminal.

[0085] The wearable device may include limiting logic to prevent incorrect input or repeated input. For example, the wearable device may be configured to apply a minimum interval between designated signal transmissions or to limit the number of consecutive inputs. Accordingly, the service providing server (100) can reduce unnecessary processing requests caused by excessive designated signals and efficiently utilize system resources.

[0087] FIG. 3 is a flowchart of the operation of a recovery mission service provision method according to an embodiment of the present invention.

[0088] According to one embodiment, the components of a recovery mission service providing system may perform the operations disclosed in FIG. 3. For example, among the components included in the recovery mission service providing system, at least some of the components included in the service providing server (100) (e.g., memory (110), processor (120), communication interface (130), and display device (140) of FIG. 1) may be configured to perform the operations of FIG. 3.

[0089] In the following embodiments, the operations S310 to S350 may be performed sequentially, but are not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel. Additionally, content corresponding to or overlapping with the above description in relation to FIG. 3 may be briefly explained or omitted.

[0090] According to one embodiment, the processor (120) can identify a target stadium among a plurality of stadiums based on the GPS signal of the designation signal in response to receiving a designation signal from a wearable device (S310).

[0091] Here, the designated signal may be an event signal generated by an input in which a user presses a button provided on a wearable device, and may be implemented in a scenario in which the user presses the button to indicate a specific moment during a match or to initiate a recovery mission provision procedure after the end of a match.

[0092] For example, a user may press a button on a wearable device during or immediately after the end of a game while watching or participating in the game, and the wearable device may generate and transmit a message including a device identifier and the time of the event occurrence along with the button input event.

[0093] When the processor (120) receives the message, it records the time of receipt and can use the device identifier included in the message (or, designated signal) as an input value for subsequent processing to identify the user account and user terminal corresponding to the wearable device.

[0094] The processor (120) may be configured to identify a target stadium among a plurality of stadiums based on location information included in or associated with a designated signal.

[0095] For example, the wearable device may acquire the current location coordinates at the time of button input and include them in a designated signal message, or cache the most recently measured location coordinates separately from the button input event and include them in a designated signal message.

[0096] The processor (120) can identify the target stadium by extracting location coordinates from a designated signal message and comparing them with a stadium database that stores reference location information for multiple stadiums.

[0097] For example, the stadium database may include stadium identification information along with the center coordinates of the stadium and stadium boundary area information, and the stadium boundary area information may be defined as a polygonal geofence area or a radius-based circular area.

[0098] The processor (120) can determine which stadium boundary area the location coordinates are included in to determine the target stadium.

[0099] For example, the processor (120) can determine the stadium identification information of a specific stadium as the target stadium if the location coordinates are included in the geofence area of ​​that stadium, and if there is a possibility that it is included in two or more stadium boundary areas simultaneously, it can select the final target stadium by considering the distance from the center coordinates or location accuracy information. In addition, considering the degradation of the accuracy of the location information, if the location coordinates exist near the boundary, the reliability of the target stadium identification can be improved by additionally using the location trajectory of a recent certain time interval or by determining the stadium where the location was stayed using multiple location samples.

[0100] The processor (120) can be used to store the target stadium identification results and to limit the search range of subsequent steps.

[0101] For example, in an environment where multiple stadiums are operated in the same city, the target stadium can be determined first, thereby reducing the number of target sports match candidates in subsequent steps and shortening processing time. Additionally, the processor (120) can apply a policy to set the user's recently visited stadium or the stadium the user frequently visits as priority candidates, taking into account cases where repeated use by the same user occurs, and thereby improve the stability of target stadium identification.

[0102] According to one embodiment, the processor (120) can identify a target sports game among a plurality of sports games performed at a target stadium based on the stadium identification information of the target stadium and the time of reception when a designation signal is received (S320).

[0103] The processor (120) may be configured to identify a target sports match among a plurality of sports matches performed at a target stadium based on the stadium identification information of the target stadium confirmed in operation S310 and the time of receiving a designated signal.

[0104] Here, the reception time may be defined as at least one of the time when the wearable device generates a button input event or the time when the processor (120) receives a designated signal, and according to the embodiment, the time when the event occurs may be adopted as the priority time or the time when the server receives may be adopted as the priority time.

[0105] For example, if the wearable device includes an event timestamp in a designated signal message, the processor (120) records the event timestamp as the time of reception and, in an environment with high network latency, determines whether the difference between the server reception time and the event timestamp exceeds a preset allowable range and selects the timestamp to be used as the time of reception. Accordingly, the processor (120) can reduce match identification errors caused by discrepancies in time standards.

[0106] The processor (120) may be configured to generate target sports match candidates based on stadium identification information and the time of reception. For example, the processor (120) may transmit query information including stadium identification information and the time of reception to a match data server and receive a list of matches performed at the corresponding stadium within a certain time interval from the match data server. At this time, the certain time interval may be defined as a time range before and after that is pre-set based on the time of reception, for example, it may be set from 3 hours before the time of reception to 1 hour after. The processor (120) may determine whether the time of reception falls between the time of the start of the match and the time of the end of the match from the received match list to form a first candidate group, or may form a second candidate group of matches where the difference between the time of reception and the time of the end of the match is within a pre-set threshold time. By configuring the candidate group based on multiple criteria in this way, it is possible to cover both cases where the user presses the button immediately after the end of the match and cases where the user presses the button in the middle of the match.

[0107] The processor (120) can automatically confirm the target sports match among the candidate matches or confirm it through user confirmation. For example, if there is only one candidate match, the processor (120) confirms that candidate as the target sports match, and if there are multiple candidate matches, it can sort the candidates according to their time proximity to the time of reception and provisionally confirm the top candidate. Additionally, in cases where there is a possibility of confusion, such as with a preliminary match and a main match within the same stadium or the operation of multiple courts at the same time, the processor (120) can provide a list of candidate matches to the user terminal and receive confirmation input from the user before finally confirming the target sports match. At this time, metadata such as the match start time, end time, sports type, and team information may be displayed together in the list of candidate matches, and the user can intuitively select the match they participated in or watched.

[0108] The processor (120) may use additional matching information to improve the reliability of identifying target sports matches. For example, the processor (120) may verify a user account from the registration information of a wearable device and a user terminal, and if entry records, reservation information, or seat information of the user account exist, it may reflect this in the selection of candidate matches. Additionally, the processor (120) may determine whether the location coordinates where a designated signal occurred are close to a specific area inside the stadium, thereby adjusting the priority of candidate matches in an environment where multiple areas within the same stadium are operated for different sports. Such auxiliary information may be applied optionally according to the embodiment, and whether to apply it may be determined by system policy or user settings.

[0109] The processor (120) may be configured to store the match identifier assigned to the target sports match when the target sports match is confirmed, and to provide it as an input value for subsequent actions. For example, the processor (120) may record the match identifier along with the user account and wearable device identifier and the designated signal timestamp, thereby maintaining the same match context during the subsequent process of providing a self-diagnosis interface, providing missions, and evaluating performance history. Additionally, the processor (120) may consider cases where the same user generates a designated signal multiple times in the same match, connect multiple designated signals to the same match identifier, and store the time of reception of each designated signal to be used for extended functions for analysis purposes or for providing highlights.

[0110] According to one embodiment, the processor (120) may provide a self-diagnosis input interface to a user terminal registered in correspondence with a wearable device in response to identifying that the target sports game has ended through schedule information of the target sports game received from the game data server (S330).

[0111] The processor (120) may be configured to provide a self-diagnosis input interface to a user terminal registered in correspondence with a wearable device in response to identifying that the target sports match has ended through schedule information of the target sports match received from the match data server.

[0112] Here, schedule information may be implemented as metadata including the match start time, the scheduled match end time, and the match progress status, and the match progress status may be expressed as at least one of the scheduled status, the progress status, and the finished status.

[0113] The processor (120) can identify the end of a match by using the match identifier confirmed in operation S320 to send a request for schedule information to the match data server and determining whether the current time has passed the scheduled end time or whether the match progress status is in a finished state based on the schedule information received from the match data server.

[0114] The processor (120) may be configured to identify a user terminal after the end of the game and provide a self-diagnosis input interface. For example, the processor (120) may look up a pre-registered user account and user terminal identifier using a wearable device identifier included in a designation signal (or a corresponding message), and may send a notification message or a screen switching request message that provides a self-diagnosis input interface to the looked-up user terminal. In addition, considering cases where the user terminal is offline or cannot receive push notifications, the processor (120) may be implemented by performing retransmission at regular intervals or delivering a waiting interface provision event at the time the user terminal connects.

[0115] The processor (120) may be configured to induce standardization of user input by pre-defining the components of the self-diagnosis input interface. For example, the self-diagnosis input interface may include a human body diagram-based input screen for selecting a pain area, a recent treatment selection item, a treatment area selection item, and a treatment time selection item for entering treatment history, and may include a time or time interval selection item for entering leisure time. At this time, the pain area and treatment area may be configured to be stored in a part code system identical to the category of the body part classification table, and the part selected by the user may be converted into a part code at the user terminal and transmitted to the processor (120). The processor (120) may perform validation for each input item to determine whether required items are missing and whether there are errors in the visual format, and if there are errors, provide a notice to the user terminal requesting re-input.

[0116] The processor (120) can adjust the timing of providing the self-diagnosis input interface according to the user's situation. For example, since the user may be on the move or the communication environment may be unstable immediately after the end of a game, the processor (120) can provide the interface in a simple input mode immediately after identifying the end of the game, and then guide the user to switch to a detailed input mode when stable input is possible. In addition, to prepare for cases where the user does not input leisure time, the processor (120) can reduce the input burden by suggesting default leisure time candidates or displaying previously saved leisure time as the default value. In this case, the use of the default value can be configured on the premise of user consent input, thereby ensuring both user experience and data accuracy.

[0117] The processor (120) may be configured to provide a self-diagnosis input interface and, at the same time, display to the user terminal that the interface is connected to a specific match. For example, the type of sport, the end time of the match, and the name of the stadium of the target sports match may be displayed together on the screen of the user terminal, and the user may be aware of the context that a condition diagnosis is being performed after the match. This display configuration can provide the effect of reducing user input errors and increasing service reliability.

[0118] According to one embodiment, the processor (120) receives self-diagnosis data including pain area, treatment history and leisure time from a user terminal and can identify injury risk areas based on the type of sport of the target sports game and the self-diagnosis data (S340).

[0119] The processor (120) may be configured to receive self-diagnosis data including pain area, treatment history and leisure time from a user terminal, and to identify injury risk areas based on the type of sport of the target sports game and the self-diagnosis data.

[0120] Here, the pain area refers to the location of discomfort or pain subjectively felt by the user and can be transmitted in the form of a area code from the user terminal. The treatment history may consist of at least one of whether treatment was received within a recent period, the treatment area, and the time of treatment, and can also be transmitted in a structure including an area code. Leisure time can be defined as a specific time or time interval that is repeatable daily, and the processor (120) can use the said leisure time to generate a mission information transmission schedule in a subsequent step.

[0121] The processor (120) can obtain the sports type from the metadata of the target sports game. For example, the processor (120) can determine the sports type using the sport code included in the game metadata received from the game data server. The processor (120) can store a sports type-specific risk area mapping table and a body part classification table in memory to identify injury risk areas by combining the sports type, pain area, and treatment history. The sports type-specific risk area mapping table may include injury areas that occur frequently or joint areas where the burden is concentrated in the form of weights for each sport; for example, it may be defined so that high weights are assigned to the ankle and knee for soccer, high weights to the ankle, knee, and calf for basketball, and high weights to the shoulder and elbow for baseball.

[0122] The processor (120) may perform a risk score calculation procedure to determine the injury risk area as a single area. For example, the processor (120) may assign a basic score to the area when a pain area is input, and assign an additional score to the area if a treated area exists in the treatment history. Additionally, the processor may assign sport weights to areas included in the sports type mapping table, and apply combined weights to increase the score if the pain area and the sport high-risk area are the same or belong to the same category. The processor (120) may determine the area with the maximum value among the scores calculated for each area as the injury risk area, and if there are multiple areas with the same score, it may determine the priority using whether a treatment history exists, the magnitude of the pain intensity input value, or the order of recent inputs.

[0123] The processor (120) may apply branching rules that clearly reflect the meaning of the treatment history. For example, if the pain area and the treatment area of ​​the treatment history are the same, the processor may be configured to determine the pain area as the injury risk area, and if the pain area and the treatment area are different, the processor may be configured to determine the injury risk area by considering whether it is a high-risk area by sports type or whether multiple pains are entered. In addition, if multiple pain areas are entered, the processor may calculate an individual risk score for each pain area, select the area with the highest score as a priority candidate, and then further apply the relationship with the treatment history area to determine the final injury risk area.

[0124] The processor (120) can provide the results of identifying injury risk areas to the user terminal so that the user can recognize the results. For example, the mission screen of the user terminal may display the area determined to be an injury risk area along with a summary of the input used for the determination. Additionally, the processor (120) may be configured to notify the user terminal that the results are not medical diagnoses but risk estimation results for providing recovery missions. Such notification configuration can provide the effect of preventing user misunderstanding by clarifying the scope of the service purpose.

[0125] According to one embodiment, the processor (120) can check mission information including a target recovery mission set in response to an injury risk area, a method for performing the mission for the target recovery mission, a time for performing the mission, and precautions, and transmit the mission information to a user terminal whenever leisure time arrives every day (S350).

[0126] The processor (120) can be configured to check mission information including a target recovery mission set in response to an injury risk area, a method for performing the mission for the target recovery mission, a time for performing the mission, and precautions, and to transmit the mission information to a user terminal whenever leisure time arrives each day.

[0127] Here, the target recovery mission can be selected from a mission library mapped to injury risk area codes, and the mission library can be implemented as a data structure including area codes, mission identifiers, a list of mission steps, time for each step, cautionary phrases, and contraindication tags. For example, if the injury risk area is the ankle, a list of steps including preparatory, stretching, and balancing movements to restore mobility around the ankle can be selected, and each step can be configured to include a description of the posture, the number of repetitions or holding time, and instructions to stop if pain occurs.

[0128] The processor (120) can exclude contraindicated movements or convert them into alternative movements by reflecting the treatment history in the composition of mission information. For example, in the case of a user whose treatment history includes knee treatment, movements requiring a large knee flexion angle may be designated as contraindicated movement tags, and the processor (120) can exclude movements containing such tags from the mission stage list and replace them with low-intensity movements that achieve the same purpose. Additionally, the processor (120) can select different combinations of mission stages for the same body part by considering muscle group fatigue patterns that commonly occur after a game depending on the type of sport. For example, the mission composition may differ by increasing the proportion of lower body stretching in running-centered sports and increasing the proportion of shoulder stabilization movements in pitching-centered sports.

[0129] The processor (120) can generate a mission information transmission schedule by processing leisure time into a specific time or a specific time interval. For example, if a user enters 9:00 PM every day as leisure time, the processor (120) can be configured to generate a schedule entry corresponding to the user account and transmit mission information at 9:00 PM every day. Additionally, if a user enters a time interval from 8:00 PM to 10:00 PM, the processor (120) can be configured to transmit mission information along with a notification at the start time of the interval, and to transmit a re-notification at a time in the middle of the interval if the user does not enter the mission screen. In this case, the number and interval of re-notifications can be limited by a system policy, for example, it can be set to perform a re-notification only once a day.

[0130] The processor (120) may apply a transmission policy by simultaneously considering the reachability of mission information transmission and the prevention of duplicate transmission. For example, if a transmission failure occurs because the user terminal is offline, the processor (120) may perform retries within a preset number of retransmissions, and after the leisure time interval ends, the transmission of the mission for that day may be terminated so as not to be carried over to the next day's mission. Additionally, the processor (120) may be configured to stop duplicate mission transmission for the same day if it receives a confirmation event indicating that the mission screen has already been opened on the user terminal. Such a policy can provide the effect of efficiently using server resources and network resources without compromising the user experience.

[0131] The processor (120) can configure a data format so that mission information can be specifically displayed on the user terminal. For example, the processor (120) can configure a mission execution method in the form of step cards and transmit each card including execution time and precautions, and the user terminal can be configured to provide a step timer according to the card order and receive a step completion input to switch to the next card. In addition, the processor (120) can specify the execution time for each step so that the mission execution time can be calculated as a sum of the steps, and define a start signal and an end signal so that the execution time can be counted on the user terminal. This data format can function as a basis for ensuring that the average execution time and start delay time are calculated on a consistent standard when execution history data is generated in subsequent steps.

[0134] FIG. 4 is a flowchart of the operation of a recovery mission service provision method according to one embodiment of the present invention.

[0135] According to one embodiment, the components of a recovery mission service providing system may perform the operations disclosed in FIG. 4. For example, among the components included in the recovery mission service providing system, at least some of the components included in the service providing server (100) (e.g., memory (110), processor (120), communication interface (130), and display device (140) of FIG. 1) may be configured to perform the operations of FIG. 4.

[0136] In the following embodiments, the operations S410 to S430 may be performed sequentially, but are not necessarily performed sequentially. For example, the order of each operation may be changed, and at least two operations may be performed in parallel. Additionally, content corresponding to or overlapping with the above description in relation to FIG. 4 may be briefly explained or omitted.

[0137] According to one embodiment, the processor (120) can obtain a plurality of video data captured for the target sports game from a game data server (S410).

[0138] The processor (120) may be configured to acquire multiple video data captured for a target sports match from a match data server.

[0139] Here, multiple video data may be images captured by multiple cameras installed at different locations within the target stadium, and each video data may be provided along with metadata including a camera identifier and shooting time information.

[0140] For example, cameras that photograph the direction of the goalpost, cameras that photograph the center line, and cameras that photograph the side of the bench may be installed in the stadium, and the processor (120) may receive a list of cameras corresponding to the game identifier of the target sports game from the game data server and then request video data corresponding to each camera.

[0141] The processor (120) may be configured to determine the requested section of video data using the start time and end time of the target sports game and game progress event information in order to efficiently limit the range of video data acquisition. For example, the processor (120) may be implemented in a way that secures video data for at least the entire section of the game during the process of providing recovery mission services after the game ends, or may be implemented in a way that requests a specific time section first to prioritize analysis of sections where collisions or sudden changes in motion occur frequently during the game. In addition, considering the case where the amount of video data is excessive, the processor (120) may apply a step-by-step acquisition method in which it first requests a low-resolution or low-bitrate version to perform a primary analysis, and then requests high-resolution video only for the necessary sections according to the analysis results.

[0142] The processor (120) may use timestamp information to align multiple video data based on the same time. For example, a game data server may provide video including absolute time-based timestamps for each frame or at regular frame intervals, and the processor (120) may use the timestamps to correct time errors between cameras and then align frames corresponding to the same time. In an embodiment where absolute time information in frame units is not provided, the processor (120) may calculate the frame time using the frame index per camera and the video start time, and if necessary, apply an additional alignment procedure using common features such as audio peaks or electronic display events to correct synchronization errors between cameras.

[0143] The processor (120) may be configured to secure initial conditions for reliably tracking a target corresponding to a user in the video. For example, the processor (120) may obtain clues to narrow down user candidates within the video based on participant information provided by a game data server or user identification information provided by a user terminal. The user identification information may include at least one of a user registration image, user registration physical condition, user registration uniform number and uniform color, and / or an identifier associated with a user account, and the processor (120) may be implemented in such a way that it uses this information to initially detect a user in at least one of a plurality of video data and then propagate the same user track to the remaining videos.

[0144] The processor (120) may be configured to apply access control and security during the process of acquiring video data. For example, the processor (120) may include an authentication token when making a request to a game data server, and apply a retry policy by receiving the success or failure of the request and an error code. Additionally, the processor (120) may be configured to initiate a video processing procedure related to a user only when the authority for the user account has been verified, thereby preventing unauthorized analysis or unauthorized provision.

[0145] According to one embodiment, the processor (120) can extract motion data including the load amount and range of motion and collision area for each joint of the user based on a plurality of image data (S420).

[0146] The processor (120) may be configured to extract user exercise data based on multiple image data, and the exercise data may be configured to include joint-specific load, joint-specific range of motion, and collision area. Here, the joint-specific load is not limited to absolute force or torque, but may be implemented as a load indicator representing the intensity of joint movement that can be estimated from the image. Additionally, the joint-specific range of motion may be implemented as a range of motion indicator calculated from the time change of the joint angle, and the collision area may be configured to refer to a part of the user's body where contact with another person or game equipment occurs.

[0147] The processor (120) may use an artificial intelligence-based pose estimation model to estimate key points of the user's body. For example, the processor (120) may calculate key point coordinates and reliability corresponding to the user's head, shoulders, elbows, wrists, pelvis, knees, and ankles for each frame of multiple image data. In order to select a target user associated with a user terminal in a frame where there are multiple user candidates, the processor (120) may apply a re-identification procedure based on user identification information or apply a tracking procedure that maintains the user track obtained from the initial frame. By generating a key point sequence after reliably identifying the user in this way, the reliability of calculating joint-specific indicators can be improved.

[0148] The processor (120) may be configured to calculate joint angles from keypoint coordinates to calculate the range of motion for each joint. For example, the knee range of motion may be implemented by calculating the angle formed by the hip keypoint, the knee keypoint, and the ankle keypoint frame by frame, and calculating the range of motion by calculating the difference between the maximum and minimum values ​​of the angle in a certain time interval. Additionally, the shoulder range of motion may be calculated using the relative angle between the shoulder keypoint, the elbow keypoint, and the torso axis, and the wrist range of motion may be calculated using the relative angle between the wrist and the elbow or the range of motion of the wrist. Considering that the meaningful joints may vary depending on the type of sport, the processor (120) may be configured to define a priority list of joints for each sport and to calculate the range of motion for the corresponding joints first. For example, if the type of sport for the target sport is soccer, the ankle and knee may be determined as priority joints, and exercise data may be determined based on the load amount for the corresponding parts.

[0149] The processor (120) may be configured to calculate a load indicator using the rate of change and the amount of change of joint angles to calculate the load per joint. For example, the processor (120) may calculate joint angular velocity from the frame-to-frame change of joint angles and joint acceleration from the frame-to-frame change of joint angular velocity. The processor (120) may define the magnitude of joint angular velocity or joint acceleration, or a combination of the two values, as the load indicator per joint, and joints with repeated rapid changes may have a relatively high load indicator. Additionally, the processor (120) may be implemented in a way that strengthens the load indicator for lower body joints by considering the user's movement speed and the rapid deceleration pattern of the landing section together. In this case, since the load indicator is defined as a combination of values ​​obtainable from the video, it can reflect the relative magnitude of the burden applied to the joints.

[0150] The processor (120) may be configured to detect proximity and contact between the user and another person or game tool in order to determine the collision area. For example, the processor (120) may use an artificial intelligence-based object detection model to detect game tools or other people frame by frame, and calculate the distance from the user keypoint or user bounding box to identify a section that rapidly approaches below a threshold distance as a collision candidate section. In the collision candidate section, the processor (120) may map the body part to which the keypoint having the minimum distance from other objects among the user keypoints belongs as the collision area. For example, if a frame in which the wrist keypoint is closest to the center point of the ball is repeatedly observed, the wrist or forearm may be determined as the collision area, and if the pelvis or knee keypoint rapidly overlaps with the bounding box of another person, the hip joint or knee may be determined as the collision area.

[0151] The processor (120) may be configured to improve the accuracy of calculating joint-specific indicators using multiple image data. For example, since a part of the body may be obscured in a single camera view, the processor (120) may correct the keypoint by selecting a viewpoint with high keypoint reliability among the synchronized multiple camera frames, or calculate more stable coordinates by combining keypoints from multiple viewpoints. Additionally, if there is a possibility of false detection in determining the collision site, the processor (120) may determine the final collision site by cross-verifying whether collision candidates observed at the same time from different cameras match. Such combination of multiple viewpoints can provide the effect of increasing the utility value of multiple image data and improving the reliability of motion data.

[0152] The processor (120) may be configured to package and store the calculated load amount, range of motion, and collision area per joint as user exercise data. For example, the exercise data may include the maximum value, average value, and upper range average value of the load amount indicator per joint, the range of motion per joint may include the maximum range of motion per joint and the average range of motion during repetitive movements, and the collision area may include the body part code where the collision occurred and the time interval at which the collision occurred. Additionally, the processor (120) may store interpretation criteria for the exercise data in conjunction with the type of sport, which can be used as rules or weights in determining the risk area in a subsequent step.

[0153] According to one embodiment, the processor (120) can determine the injury risk area based on the pain area included in the self-diagnosis data, the treatment history, and the exercise data (S430).

[0154] The processor (120) can be configured to determine the injury risk area based on the pain area and treatment history and exercise data included in the self-diagnosis data.

[0155] Here, the pain area may be represented by a body part code subjectively selected by the user, and the treatment history may include information on whether treatment was recent, the treatment area code, and the time of treatment. The exercise data may include joint-specific load indicators, joint-specific range of motion, and collision area codes calculated from the preceding movement. The processor (120) may be configured to determine the risk area after integrating information from different sources into the same body part code system to make it comparable.

[0156] The processor (120) may perform a rule-based decision procedure to determine the risk area. For example, the processor (120) may be implemented such that if a collision area exists, the collision area is set as a priority candidate for the risk area, and if the collision area is identical to or falls into the same category as the pain area, the representative area set corresponding to that category is confirmed as the injury risk area. Conversely, even if a collision area exists, if the user does not complain of pain at all, the processor (120) may determine the risk area by considering the joint with a high joint load index together with the collision area. Additionally, a branching rule may be applied to determine the risk area based solely on the joint load index and range of motion index in game types where no collision area exists.

[0157] The processor (120) can determine the risk area by performing a score-based decision procedure. For example, the processor (120) can define risk scores for each body part, assign a basic weight to the score corresponding to the pain area, and assign a treatment weight to the score corresponding to the treatment area. Additionally, load weights can be assigned to body parts corresponding to joints with high load indicators per joint, and range of motion excess weights can be assigned to joints with abnormally small or abnormally large ranges of motion per joint. Furthermore, if a collision area is identified, collision weights can be assigned to that area, and the processor (120) can determine the body part with the highest final score as the injury risk area. The score-based method has high flexibility as it can be supplemented with other items even if input items are missing or uncertain.

[0158] The processor (120) can apply the treatment history as a reliability correction factor for determining the risk area. For example, if the pain area and the treatment area are the same, the priority for determining that area as the risk area can be increased, which is a configuration that reflects the relatively high probability of recurrence of the existing injury area. Conversely, if the pain area and the treatment area are different, the processor can check whether the treatment area shows a high load indicator in the exercise data, and if the treatment area is evaluated to have been subjected to a high load again in the current game, the treatment area can be determined as the risk area. This correction can provide the effect of improving personalization quality by reflecting the meaning of the treatment history in the actual decision logic rather than leaving it as mere stored information.

[0159] The processor (120) can be implemented in a manner that incorporates the range of motion of each joint into the determination of the risk area. For example, if a pattern in which the range of motion of the knee is significantly reduced compared to normal is derived from video data, the processor (120) may elevate the knee or an adjacent area as a candidate for the risk area by considering the possibility that a compensatory movement to protect the knee may have occurred. Additionally, if the range of motion of a specific joint appears excessively large, the joint may be elevated as a candidate for the risk area by considering the possibility of reduced joint stability or hyperextension. This method of incorporation can improve the precision of the determination of the risk area when used in conjunction with the load indicator for each joint.

[0160] The processor (120) may be configured to provide the determined injury risk area as a criterion for selecting a subsequent recovery mission. For example, the processor (120) may store the basis for determination along with the injury risk area code, and the basis for determination may include input of the pain area, input of treatment history, results of collision area determination, and a list of top joints with load indicators. Additionally, the processor (120) may provide a summary of the risk area to the user terminal to help the user understand their condition, and may be configured to provide guidance that the information is not a medical diagnosis but a risk estimation for providing a recovery mission.

[0162] Additionally or generally, the processor (120) compares the pain area included in the self-diagnosis data and the collision area included in the exercise data with a body part classification table, and if the pain area and the collision area are included in one of the target categories among the plurality of categories included in the body part classification table, a preset representative area corresponding to the target category can be determined as the injury risk area.

[0163] The processor (120) may be configured to compare the pain area included in the self-diagnosis data and the collision area included in the exercise data with a body part classification table. Here, the comparison may not be a simple string comparison, but may be implemented as a process of normalizing the pain area and the collision area to the same standard system and then determining which category of the body part classification table each part belongs to.

[0164] For example, when a pain area is selected based on a human body diagram on a user terminal, the pain area can be transmitted as a body part code, and the collision area can also be stored by mapping the image analysis result to a body part code. The processor (120) receives the pain area code and the collision area code as input, looks up the category identifier to which each code belongs in a body part classification table, and can use the lookup result for subsequent branching decisions.

[0165] The processor (120) stores a body part classification table in memory and may predefine a part code system to ensure consistency in table lookup. For example, the body part classification table may include a category identifier, a category name, and a list of included part codes. Examples of categories may include an upper limb category, a lower limb category, a torso category, or more subdivided shoulder group categories, elbow group categories, wrist group categories, hip group categories, knee group categories, ankle group categories, etc. Additionally, the list of part codes may be configured to include a representative part and an adjacent part together. For example, the knee group category may include the knee and patella, as well as adjacent parts such as the upper tibia and lower femur. Accordingly, even if the pain area is calculated as the knee and the collision area as the upper tibia, the processor (120) may determine that the two parts are included in the same category.

[0166] The processor (120) may be configured to handle exceptions where the input area does not exist in the table during the comparison process. For example, in an embodiment where the user terminal provides the pain area as free input, there may be cases where the user inputs ambiguous expressions, so the processor (120) may additionally apply mapping rules to replace the pain area with a predefined area code. Additionally, since the image-based collision area may be calculated as a non-specific area due to reduced keypoint reliability, the processor (120) may mark the collision area as undetermined when the collision area is unclear, and branch to determine the pain area and treatment history in a subsequent operation.

[0167] The processor (120) may not simply store the comparison result as whether it is identical, but may store it as a flag distinguishing whether it is included in or excluded from the same category. For example, the processor (120) may store whether the category lookup of the pain area was successful, whether the category lookup of the conflicting area was successful, and whether the two categories match, respectively, and then use these flags to evaluate branching conditions in subsequent branching operations. Accordingly, the processor (120) can perform same category branching, exclusion branching, and treatment history-based correction branching with consistent logic.

[0168] The processor (120) may be configured to determine a pre-set representative area corresponding to a target category as the injury risk area when the pain area and the collision area are included in one of the target categories among the multiple categories included in the body part classification table. Here, the representative area may be defined as a standard area representing the category, and the processor (120) may use the representative area to unify the pain area and the collision area, which are entered as different expressions or different detailed areas, into a single risk area. For example, if the pain area is calculated as the knee and the collision area as the shin, but both areas are included in the knee group category, the processor (120) may define the representative area as the knee and determine the injury risk area as the knee.

[0169] The processor (120) may separately store a representative part mapping table for determining representative parts. For example, the representative part mapping table may store representative part codes corresponding to category identifiers, and the representative parts may be used as key values ​​for mission library lookups on user terminals. Additionally, since representative parts may also be used as risk parts to be displayed on user guidance screens, the processor (120) may define representative parts at a level suitable for user recognition. For example, the representative part of the ankle group category may be defined as the ankle, the representative part of the shoulder group category as the shoulder, and the representative part of the wrist group category as the wrist.

[0170] The processor (120) may apply auxiliary rules to more precisely reflect the risk level even when included in the same category. For example, if the target category is the knee group category, the processor (120) may differentiate the priority display area depending on whether the pain area is mapped directly to the knee or to an adjacent area. Additionally, if the reliability of the collision area calculation is high, it may be configured to select a representative area closer to the collision area; however, in an embodiment where the representative area is fixed, this auxiliary rule may be configured to be applied only to the guidance text after the representative area is determined. For example, the risk area may be confirmed as the representative area, but the detailed area where the collision was observed may be displayed together on the user terminal to enhance explanatory power.

[0171] The processor (120) can be configured to store the representative part determination result as the risk part determination result and to use the representative part code in the subsequent mission selection procedure. For example, the processor (120) can query a list of recovery missions mapped to the representative part code from a mission library, generate mission information including a mission execution method specialized for the representative part, mission execution time, and precautions, and provide it to the user terminal. Accordingly, the key value of the mission selection is consistently maintained despite different input forms, thereby simplifying system implementation and stabilizing service quality.

[0173] Additionally or generally, the processor (120) may determine the pain area as the injury risk area in response to the fact that the pain area and the collision area fall into different categories among the plurality of categories included in the body part classification table and the pain area and the treatment area according to the treatment history are the same. Additionally, the processor (120) may determine the collision area as the injury risk area if the pain area and the collision area fall into different categories among the plurality of categories included in the body part classification table and the pain area and the treatment area according to the treatment history are different.

[0174] The processor (120) receives a pain area code from self-diagnosis data and a collision area code from exercise data, and then queries a body part classification table to calculate a first category containing the pain area and a second category containing the collision area, respectively. Subsequently, the processor (120) compares whether the first category and the second category are identical, and if it is determined that they are different, it may be configured to perform a correction branching procedure based on treatment history without applying a representative area determination procedure based on identical category mapping. At this time, the condition of being different categories may include cases where the pain area and the collision area are classified into different categories even if they are adjacent areas, for example, a situation where the pain area is included in the shoulder group category and the collision area is included in the wrist group category, or a situation where the pain area is included in the knee group category and the collision area is included in the shoulder group category.

[0175] The processor (120) may be configured to determine whether the pain area and the treatment area based on the treatment history are the same, thereby determining the pain area as the injury risk area. For example, the treatment history may include information on whether treatment was performed within a recent period, the treatment area code, and the time of treatment, and the processor (120) may determine whether the treatment area code is the same as the pain area code by comparing them. Since the case where the pain area and the treatment area are the same may suggest the possibility that the discomfort currently felt by the user may recur or worsen in the area where past treatment was performed, the processor (120) may be configured to prioritize the pain area and determine it as the injury risk area even if the collision area exists in a different category. For example, if the user inputs the pain area as the knee and there is a history of knee treatment in the treatment history, the processor (120) may be configured to confirm the knee as the injury risk area and select a recovery mission corresponding to the knee, even if the collision area is calculated as the wrist. Such a priority determination reflects a conservative safety policy based on the treatment history, and can directly reflect the need to manage existing injury areas in the provision of recovery missions.

[0176] The processor (120) may include recording and guidance procedures to ensure that information regarding the collision area is not ignored even when the pain area is determined as the risk area. For example, the processor (120) may confirm the determination of the risk area as the pain area, but may store in a log the fact that the collision area exists in a different category and the time of occurrence of the collision event. Additionally, the user terminal may display that the knee has been determined as the priority area for management, and provide additional guidance that contact was observed in another area during the game, thereby allowing the user to recognize that additional caution is required. However, since the determination of the risk area remains as the pain area, the focus of the recovery mission is provided based on the pain area, and auxiliary guidance regarding the collision area is provided in the form of precautions. Accordingly, consistency of service logic and user safety can be ensured even in an environment where events in different body areas exist simultaneously.

[0177] After determining the pain area as a risk area, the processor (120) can query the mission mapped to the pain area from the recovery mission library and configure the mission stages by considering contraindicated movement tags applied to the area where a treatment history exists. For example, if there is a history of knee treatment, the processor (120) can configure the missions centered on low-intensity mobility recovery movements and stabilization movements, excluding movements that require significant knee flexion. In this case, the mission information may include guidance on stopping if pain worsens and recommending professional counseling if pain persists, which can clarify the scope of the service purpose and provide the effect of preventing user misunderstanding.

[0178] The processor (120) may be configured to determine the collision area as the injury risk area when the pain area and the collision area are included in different categories of a body part classification table, and the pain area and the treatment area according to the treatment history are different. For example, if a user enters the pain area as the shoulder and the treatment area in the treatment history as the knee, it is difficult to use the past treatment history as the primary basis because the pain area and the treatment area are different, and it is also difficult to apply a method of grouping the two areas into the same category to select a representative area because the pain area and the collision area belong to different categories. Under these conditions, since the collision area calculated based on actual contact or sudden proximity changes during the game can more directly reflect the possibility of new injury, the processor (120) may be configured to prioritize the collision area and determine it as the injury risk area.

[0179] The processor (120) may be configured to verify the reliability of the collision area calculation before determining the collision area as a risk area. For example, the collision area may be expressed as a reliability score based on whether it is observed at the same time in multiple image data, whether the collision candidate section persists for more than a certain number of frames, whether the user keypoint reliability is above a threshold, and whether the minimum distance between the user and other objects decreases below a threshold distance. The processor (120) may be configured to confirm the collision area as an injury risk area only if the reliability score is above a preset threshold, and to perform exception processing such as maintaining the pain area as a risk area or requesting additional verification from the user terminal if it is below the threshold. Such a reliability verification procedure can provide the effect of preventing the risk area from being incorrectly determined due to image-based false detection.

[0180] After confirming the collision site as a risk area, the processor (120) may be configured to select a recovery mission corresponding to the collision site and configure mission information. For example, if the collision site is determined to be the wrist, the processor (120) may select a recovery mission for restoring wrist mobility and relaxing forearm muscles, and generate mission information including the method of execution, execution time, and precautions. Additionally, if the collision site is determined to be the knee or ankle, the processor may be configured to prioritize low-intensity mobility recovery movements considering the possibility of swelling after landing impact or contact, and to include a notice to stop in case of increased pain or swelling in the precautions. At this time, considering that the situations in which collisions frequently occur may differ depending on the type of sport, the processor (120) may adjust the mission information to include different precaution phrases for each sport, even for the same collision site.

[0181] The processor (120) may be configured to provide auxiliary guidance to the user terminal by taking into account that the pain area entered by the user is different from the collision area. For example, the user terminal may display that the collision area has been determined to be a dangerous area and provide guidance based on the fact that contact with that area was observed in the game video. Additionally, a separate reference guidance item regarding the pain area may be displayed to encourage the user to observe both areas, and the system may be configured to include guidance recommending that the recovery mission be stopped and professional counseling be sought if the pain persists or worsens. Such guidance can provide the effect of increasing the acceptability of the service results in situations where collision-based decisions may feel unfamiliar to the user.

[0182] The processor (120) can record the results of determining the collision area as a risk area and use them for subsequent analysis and service improvement. For example, the processor (120) can store cases where the pain area, treatment area, and collision area are included in different categories by tagging them, and subsequently analyze whether similar patterns are repeated in the same user or the same sport. In addition, the validity of the collision-based decision policy can be verified by tracking whether the user's performance history and pain changes improve after the mission provided based on the collision area. By defining a recording structure that enables such data-based verification, the scalability of the embodiment and service reliability can be secured together.

[0184] Additionally or generally, the processor (120) may set and provide the number of repetitions per mission to the user terminal in proportion to the size of the target load amount and the target operating range of the injury risk area included in the exercise data.

[0185] The processor (120) may be configured to set and provide the number of repetitions per mission to the user terminal in proportion to the magnitude of the target load amount and the target range of motion of the injury risk area included in the exercise data. Here, the exercise data may be calculated based on multiple image data, and the exercise data may include the load amount per joint, the range of motion per joint, and the collision area. The processor (120) first checks which body part code the injury risk area is determined to be, identifies the joint or group of joints mapped to the corresponding body part code, and then retrieves the load amount indicator and range of motion indicator corresponding to the corresponding joint or group of joints from the exercise data. For example, if the injury risk area is determined to be the knee, the processor (120) may retrieve the load amount indicator corresponding to the knee joint and the flexion range of motion indicator of the knee joint, and if the injury risk area is determined to be the shoulder, the processor (120) may retrieve the load amount indicator corresponding to the shoulder joint and the abduction range of motion indicator or flexion range of motion indicator of the shoulder.

[0186] The processor (120) can define the size of the target load amount as a single value or an aggregate value of multiple values ​​and use it to set the number of repetitions per mission. For example, the processor (120) can define the average value of the load amount indicator calculated in the entire course of the game or a pre-set analysis section as the target load amount, and can also define the average value or maximum value of the upper section as the target load amount to reflect the influence of a section where rapid movements are concentrated. In addition, since the load amount indicator can be defined as a value based on joint angular velocity or joint acceleration and posture change amount rather than an absolute force value, the processor (120) can convert the load amount indicator into a normalized scale to compare values ​​of different units. For example, the processor (120) can divide the load amount indicator into a pre-set reference range to convert the load level into a value between 0 and 1, or convert and store the load level into a step grade of low load, medium load, or high load.

[0187] The processor (120) may be configured to calculate the size of the target range of motion based on the range of change of joint angles and to reflect this in the setting of the number of repetitions. For example, the processor (120) may calculate the joint angle corresponding to the injury risk area frame by frame, and then define the difference between the maximum and minimum values ​​of the joint angle in a certain interval as the range of motion. Additionally, considering that the risk implications may differ when the range of motion is lower than usual and when it is higher, the processor (120) may not interpret the range of motion value solely as an absolute size, but rather interpret it as a difference from a reference value or as a ratio relative to the reference range. For example, if the range of motion is lower than the reference range, it may be configured to set the number of repetitions low to reflect the possibility of avoiding stiffness or pain, or to suggest low-intensity repetitions for the purpose of recovering the range of motion. Conversely, if the range of motion is excessively larger than the reference range, it may be configured to lower the number of repetitions and prioritize a stabilization-centered mission to reflect the possibility of reduced joint stability.

[0188] The processor (120) may apply a pre-set calculation rule to calculate the number of repetitions in proportion to the size of the target load and the size of the target operating range. For example, the processor (120) may apply a conservative policy that lowers the number of repetitions as the load increases and increases the number of repetitions as the load decreases, or conversely, may apply a policy that increases the number of repetitions but strictly sets an upper limit, based on the view that the need for recovery management increases as the load increases. In this case, the expression "proportional" may be interpreted to mean that the number of repetitions is determined as a function of the target load and the target operating range, and the processor (120) may round or truncate the calculation result to provide the number of repetitions as an integer value, and apply a range of minimum and maximum repetitions to prevent abnormal values ​​from being provided. Additionally, the processor (120) may apply different minimum and maximum values ​​for each body part or category, taking into account the characteristics of each category and the sensitivity of the injury risk area.

[0189] The processor (120) may be configured to provide the calculated number of repetitions to the user terminal by including them in mission information. For example, the mission information may include data describing the method of performing the mission step by step, the execution time and precautions for each step, and the number of repetitions may be included as a repetition parameter corresponding to each step or a specific step. The user terminal may be configured to display the number of repetitions provided by the processor (120) on the screen and to support the achievement of the number of repetitions by providing a progress display or counter function when the user proceeds with the repetitions. Additionally, the processor (120) may be configured to ensure safety by including a precaution that instructs the user to stop immediately if they feel pain, along with the number of repetitions.

[0190] The processor (120) may store the input values ​​used to calculate the number of repetitions and the calculation results in a log to ensure consistency in the results of the repetition count setting. For example, the processor (120) may store the values ​​of the target load indicator, the target operating range indicator, and the applied calculation rule identifier together, which can be used to adjust the difficulty of missions provided to the same user in the future or to verify service quality. Additionally, in an embodiment where the user provides performance history data, it is possible to analyze how closely the repetition count setting matches the user's actual performance, thereby enabling an operation that gradually corrects the repetition count calculation rule.

[0191] In other words, mission information refers to a set of information displayed on a user terminal to guide the user in actually performing a recovery mission. It is not limited to a single text instruction but can be implemented in a form that includes step-by-step execution instructions, performance quantity parameters, and safety instructions according to a predefined data structure. For example, mission information may include a mission identifier, an injury risk area code, a sports type code, a mission version identifier, a transmission date, and a transmission time. It may also include a list of steps constituting the mission execution method, the execution time and number of repetitions or maintenance time for each step, and precautions for each step. Additionally, it may include a safety phrase as a common item instructing the user to stop if pain increases during execution.

[0192] The processor (120) may be configured to pre-store a mission library for configuring mission information in memory or storage. The mission library may include a set of mission templates with similar recovery purposes for each injury risk area, and each mission template may be configured to include one or more mission candidates mapped to an injury risk area code. For example, each mission candidate in the mission library may include a list of steps divided into a preparation phase, a main execution phase, and a cleanup phase, and each step may include a description of the execution method, a description of the execution posture, a range of execution time or repetition counts, and tags for contraindicated movements. Additionally, each mission candidate may include information on recommended intensity levels and recommended frequency, and a list of suitable sports types, and the processor (120) may be configured to select a suitable candidate based on the sports type and self-diagnosis data.

[0193] The processor (120) can store pre-set mission templates for each injury-risk area in different ways, as the characteristics of the recovery movements required for each area differ. For example, a mission template for the ankle may consist of an ankle circle drawing step for recovering ankle mobility, a foot sole support stabilization step, and a calf relaxation step, and the time for each step may be defined in seconds, and the precautions may include instructions to stop immediately and reduce weight bearing if ankle pain increases. A mission template for the knee may consist of a knee muscle relaxation step, a knee stabilization step, and a light mobility recovery step, and the precautions may include instructions to stop if there is a feeling of the knee bending or if swelling is severe. A mission template for the shoulder may consist of a scapular stabilization step, a shoulder mobility recovery step, and a rotator cuff protection step, and the precautions may include instructions to reduce the range of motion and recommend professional consultation if necessary if sharp pain occurs in the shoulder. A mission template for the wrist may consist of gentle mobility phases for wrist flexion and extension, forearm relaxation, and grip tension relief phases, and precautions may include instructions to stop if numbness persists.

[0194] The processor (120) may be configured to selectively configure mission information, including the method of performing the mission, the time of performing the mission, and precautions, when there are multiple mission candidates corresponding to the injury risk area. For example, even if the injury risk area is determined to be the ankle, different mission candidates may be selected depending on whether the user's treatment history includes surgery or immobilization treatment, or whether the pain area input is the lateral or medial side of the ankle. Additionally, since the load pattern may differ even for the same area depending on the type of sport, the processor (120) may be configured to provide ankle missions for soccer and ankle missions for basketball with different stage configurations. This selection logic may be performed based on the list of suitable sports types, contraindicated movement tags, and recommended intensity levels in the mission library, and the processor (120) may be implemented by excluding candidates whose contraindicated movement tags conflict with the treatment history and prioritizing candidates with lower recommended intensity levels among the remaining candidates.

[0195] The processor (120) may be configured to determine performance parameters, such as mission execution time and number of repetitions, from the default values ​​of the mission template, or to adjust them according to load indicators and range of motion indicators included in the exercise data and reflect them in the mission information. For example, the mission template may include a minimum and maximum execution time for each stage, and the processor (120) may be configured to set the execution time close to the minimum execution time when the load indicator is high, and to set the execution time close to the maximum execution time when the load indicator is low and the range of motion is close to the normal range. In addition, in an embodiment where the number of repetitions is set, the processor (120) may calculate the number of repetitions as a stage parameter and include it in the mission information. By using template-based default values ​​and data-based adjustment values ​​together in this way, mission information can always be generated while maintaining personalization, thereby improving the feasibility of execution.

[0196] The processor (120) may configure mission information into a structured message to transmit the mission information in a form that can be displayed by the user terminal. For example, the processor (120) may transmit mission information including a step sequence number, a step title, a step description, execution time, number of repetitions, and precautions, and the user terminal may be configured to sequentially switch screens according to the step sequence number and display an execution time timer or a repetition counter. Additionally, the processor (120) may include general precautions and body part-specific precautions separately in the mission information, and the user terminal may be configured to display general precautions first when the mission starts, and then display body part-specific precautions when switching steps. This message structure prevents the user from misunderstanding the execution method and supports the consistent recording of the execution start time, execution end time, and step-by-step execution results in the subsequent generation of execution history data.

[0197] The processor (120) may be configured to generate and manage a transmission schedule to transmit mission information whenever leisure time arrives each day. For example, the processor (120) may store the leisure time entered by the user as a specific time or time interval, and when the specific time arrives, transmit mission information for that day to the user terminal. In addition, if stored as a time interval, it may be configured to transmit mission information at the start time of the interval, and if the user's entry into the mission screen is not confirmed, to perform a re-notification at the middle time of the interval. The processor (120) may record whether transmission was successful, and in the event of transmission failure, may retry within a preset number of retransmissions, and may be configured to terminate the transmission of mission information when the leisure time interval for that day ends.

[0199] Additionally or generally, after providing mission information 7 times, the processor (120) receives execution history data for the mission information from the user terminal, and if the mission score according to the execution history data exceeds a threshold score, the number of virtual album slots corresponding to the user terminal and provided for storing images is increased in proportion to the difference between the mission score and the threshold score, and the highlight image in which the user appears within the plurality of image data is extracted and provided to the user terminal.

[0200] The processor (120) may be configured to receive performance history data for mission information from the user terminal after providing mission information seven times. Here, the seven provision times may include mission information provided once each day when leisure time arrives, accumulated over seven days, and provided a total of seven times. The processor (120) may be configured to store the transmission time for each provision time and the time of reception confirmation by the user terminal along with the time of the time. For example, the processor (120) may generate mission information transmission logs from the first to the seventh time for a user account and store the transmission success status, transmission time, and mission identifier for each time in each log. When the processor (120) determines that the seventh transmission is completed, it may be configured to initiate a procedure to receive performance history data, or to send a request to upload performance history data to the user terminal at a preset time after the seventh transmission is completed.

[0201] The processor (120) can standardize the components of the execution history data to induce the user terminal to generate execution history data in a consistent format. For example, the execution history data may include whether the mission was performed by round, the start time of the mission by round, the end time of the mission by round, the duration of the mission by round, and user confirmation events by round. Additionally, if the user uploads a mission performance video, the execution history data may include the number of uploads, the upload time, and the video identifier; and if a playback time log of the uploaded mission performance video exists, it may include the playback time per video or the total playback time. The processor (120) may predefine the required items to be included in the execution history data and be configured to perform a retransmission request to supplement the missing items if the user terminal omits the required items.

[0202] The processor (120) may be configured to use both a log verifiable on the server side and a value generated on the terminal side to ensure the reliability of the execution history data. For example, the processor (120) may determine the time when mission information is provided using a server log, and the time when recovery mission execution begins may be generated by an event of entering the mission screen or entering a start button on the user terminal. The processor (120) may calculate the start delay time by combining the time of mission provision per round stored in the server log and the time of start per round reported by the terminal, and may be configured to apply a correction rule to check for missing end events or to truncate values ​​exceeding the maximum allowable execution time if the execution time reported by the terminal is abnormally large. Such a correction rule can provide the effect of improving the reliability of the execution history data and enhancing the stability of subsequent mission score calculations.

[0203] The processor (120) may be configured to support both a method of receiving execution history data in bulk and a method of receiving it in installments. For example, in the case of a user terminal with an unstable network environment, the execution history may be transmitted by installment, and the processor (120) may aggregate the accumulated installment data to form an execution history data set in units of 7 installments. Conversely, in the case of a user terminal with a stable network environment, the entire execution history of the 7 installments may be transmitted in bulk when the 7 installments are completed. Allowing multiple transmission methods in this way enables the collection of execution history in various terminal environments, thereby strengthening the feasibility of implementation.

[0204] The processor (120) may be configured to increase the number of virtual album slots corresponding to the user terminal and provided for storing images in proportion to the difference between the mission score and the threshold score when the mission score based on the execution history data exceeds the threshold score.

[0205] Here, a virtual album slot may refer to the number of storable items allocated to a user terminal or user account; it is not limited to the physical storage space of the actual file system but may refer to the limit on the number of items that can be displayed on the album interface of the server or terminal. For example, the user may be configured to have a certain number of slots by default, and if the mission score exceeds a threshold score, additional slots may be granted depending on the degree of excess, allowing more highlight videos to be stored or pinned.

[0206] The processor (120) may predefine slot increase rules to implement proportional increase. For example, the processor (120) may be configured to define the difference between the mission score and the threshold score as the excess score, and to determine the value obtained by multiplying the excess score by a slot conversion factor as the number of increase slots. Additionally, since the number of increase slots must be an integer, the processor (120) may apply at least one integerization rule among rounding, floor, or ceiling, and may limit the maximum number of increase slots to prevent excessive slot increase. Conversely, to encourage user participation, the minimum number of increase slots may be set to 1 to provide an immediate visible reward even if the threshold score is slightly exceeded.

[0207] The processor (120) may be configured to provide the increased number of slots and the reason for the increase together when providing the slot increase result to the user terminal. For example, the user terminal may display that the album slot has increased according to the result of the 7th round of execution, and may summarize and display whether the threshold score has been exceeded and the level of the excess score. In addition, the processor (120) may set the time at which the slot increase is applied to at least one of immediate application or application at the start of the next round, and may include an embodiment in which the slot is applied immediately so that it is reflected simultaneously with the provision of a highlight video, taking into consideration the user experience.

[0208] The processor (120) may be configured to store the remaining slots and usage on a per-user account basis for consistency in virtual album slot management. For example, the processor (120) may store the total number of slots and the number of slots in use for a user account, and when a request to save a highlight video occurs, it may check the number of remaining slots to determine whether saving is possible. Additionally, the processor (120) may selectively apply a policy that allows cumulative increase when slot increases are applied repeatedly, or causes slots assigned on a per-round basis to expire after a certain period. Such slot policies may be implemented in various ways depending on the service design, and may be configured to maintain at least the basic principle of proportional increase.

[0209] The processor (120) may be configured to extract a highlight video featuring a user from multiple video data and provide it to a user terminal. Here, the multiple video data may include video footage of a target sports game captured from multiple camera viewpoints, and the processor (120) may use timestamps included in the video metadata to align the time between cameras and then align and analyze frames at the same point in time. Additionally, the highlight video featuring a user may be a short segment video generated from the entire video of the game, centered on the segment where the user is included on the screen, and may be configured to include the segment where the user is positioned at the center of the screen or where a specific event occurs.

[0210] The processor (120) may use user identification information provided from a user terminal or a game data server for user identification and appearance section identification. For example, the user identification information may include at least one of a user registration image, a uniform number, or person feature information mapped to a user account. The processor (120) may perform person detection and person re-identification procedures on multiple image data to form a person track corresponding to the user, and may identify a frame section where the user track is maintained as the user's appearance section. Additionally, if the reliability of the user track drops below a certain standard, the processor (120) may supplement the appearance section using a user track from another camera viewpoint or interpolate the track's discontinuous section to form a continuous section.

[0211] The processor (120) can evaluate sections of high importance among the user appearance sections to select a highlight section. For example, the processor (120) can calculate a highlight score characterized by the user's size within the screen, proximity to the screen center, rapid changes in user movement, and whether a collision event occurs. In particular, in an embodiment where motion data is calculated, the processor (120) can elevate sections where the load indicator per joint increases rapidly, sections where a large change in the range of motion occurs, or sections where a collision area is determined, as highlight candidates. The processor (120) can determine a section where the highlight score is above a threshold as a highlight section, determine the start and end times of the section, and generate a highlight video featuring the user by cutting the same time section from multiple video data.

[0212] The processor (120) may include a connection with a virtual album when providing the generated highlight video to the user terminal. For example, the processor (120) may check the remaining amount of virtual album slots allocated to the user account, and if there are remaining slots, register the highlight video as an album item and update and provide the album list to the user terminal. Additionally, if there are insufficient remaining slots, it may be configured to provide it in a temporary storage form or to guide the user to delete existing items and save it. This method of provision can be combined with a slot increase operation to provide the user with an experience where the number of videos that can be saved increases through the user's actions.

[0213] According to one embodiment, the processor (120) may be configured to calculate a mission score based on execution history data, and the mission score may be calculated based on the correlation between the average execution time for each of the mission information provided seven times, the number of consecutive executions, the average start delay time from the time the mission information was provided until the time the recovery mission was started, the number of uploaded mission execution videos, and the total playback time of the uploaded mission execution videos multiplied by the mission execution time seven times. Here, the average execution time may be defined as the average of the execution times recorded in each of the seven times, the number of consecutive executions may be defined as the maximum consecutive length of execution confirmed in consecutive days or consecutive times among the seven times, and the average start delay time may be defined as the average of the difference between the time the mission was provided for each time and the time the execution started for each time. The number of uploads may be defined as the number of mission execution videos uploaded during the seven times, and the total playback time may be defined as the sum of the times the uploaded videos were played on the user terminal.

[0214] The processor (120) may be configured to generate an average execution time by collecting the execution times of each of the seven provided rounds and averaging them. Here, the execution time may be defined as the elapsed time from the point in time when an input to start the recovery mission occurs at the user terminal until the point in time when an input to end the recovery mission occurs, and in an embodiment providing a step-by-step execution timer, the step-by-step execution times may be summed to form the execution time of the round. The processor (120) may be configured to treat the round as unexecuted or exclude it from the average calculation if the execution time of the round is less than the minimum execution time, and may be configured to cut off the maximum allowable execution time and reflect it in the average if it exceeds the maximum allowable execution time. Accordingly, the average execution time may be maintained as a stable indicator that reflects the actual execution level.

[0215] The processor (120) may be configured to determine whether each of the seven rounds is performed and to calculate the length of the continuous interval in order to calculate the number of consecutive performances. Here, whether a performance is performed may be determined based on whether there is a termination event received from a user terminal or whether the time of the round's performance is longer than or equal to a preset threshold time. The processor (120) may generate a sequence of performance results by arranging the performance results for each round in chronological order and define the maximum length of continuous performance without interruption as the number of consecutive performances. For example, if the performance is performed from the first day to the third day of the seven rounds, is not performed on the fourth day, and is performed from the fifth day to the seventh day, the number of consecutive performances may be calculated as 3.

[0216] The processor (120) may be configured to define the time of mission provision for each round and the time of execution start for each round, and to aggregate the difference therefrom in order to calculate the average start delay time. Here, the time of mission provision may be defined as at least one of the time when the processor (120) transmits mission information to the user terminal or the time when the user terminal reports acknowledgment of receipt. The time of execution start may be defined as the time when the user terminal enters the mission screen or the time when the start button is pressed. The processor (120) may calculate the difference between the time of provision and the time of start for each round as the round delay time, and then calculate the average value for the 7th round as the average start delay time. Additionally, rounds with excessively large delay times may be configured to be treated as unexecuted or to apply a delay time upper limit to prevent the average value from being distorted.

[0217] The processor (120) may use upload logs received from a user terminal to calculate the number of uploaded mission performance videos. Here, the upload logs may include a video identifier, an upload time, and a round identifier, and the processor (120) may calculate the number of uploads by aggregating the number of videos uploaded during a 7-round period. In addition, to prevent duplicate uploads of the same video, the processor (120) may be configured to check for duplicate video identifiers and calculate the number of uploads after excluding duplicate items. The number of uploads may be used as an indicator of the extent to which the user has recorded mission performance and created shareable assets.

[0218] The processor (120) may be configured to calculate the ratio of the total length of the uploaded mission performance video to the mission performance time. Here, the total length of the uploaded mission performance video may be defined as the sum of the video lengths of each video uploaded during the 7th round, and the video length may be defined as the total playable length included in the video file metadata. The processor (120) may calculate the total length by transmitting the video length together when the user terminal uploads, or by extracting the video length from the video file received by the processor (120). Additionally, the mission performance time may be defined as at least one of the sum of the 7th round performance times or the average performance time extended by the number of rounds, and the processor (120) may calculate the ratio value by dividing the total length by the mission performance time. For example, if the user films and uploads the performance video sufficiently compared to the actual performance time, the ratio value may increase, and if the video recording is insufficient compared to the performance time, the ratio value may decrease. In addition, since the mission execution time may become 0 when there is no execution at all, the processor (120) may be configured to prevent the denominator from becoming 0 by setting the ratio value to 0 or applying a preset minimum denominator value when the mission execution time is 0.

[0219] The processor (120) may use the playback log of the user terminal to calculate the total playback time of the mission execution video by the user terminal. The total playback time refers to the sum of the times the uploaded mission execution video was actually played on the user terminal, and the playback log may include the playback start time, the playback end time, or the length of the playback section. The processor (120) may calculate the total playback time by aggregating the playback log, and the total playback time may be defined to increase when the same video is played repeatedly. The total playback time may be used as an indicator reflecting the extent to which the user has checked the execution quality by re-checking the execution video.

[0220] The processor (120) may be configured to calculate a final mission score by combining the above items. For example, the processor (120) may calculate the mission score by converting the average execution time, number of consecutive executions, average start delay time, number of uploads, ratio value, and total playback time into normalized scores, and then summing them up with weights. In this case, the average start delay time may be converted so that the score increases as the value decreases, and the average execution time, number of consecutive executions, number of uploads, ratio value, and total playback time may be configured so that the score increases as the values ​​increase. Additionally, the processor (120) may be configured to limit the mission score to a preset range to prevent extreme values ​​from occurring, and to determine whether to increase the virtual album slot by comparing the calculated mission score with a threshold score.

[0221] The service provider server (100) (or processor (120)) can calculate the mission score based on the following mathematical formula 1.

[0222] [Mathematical Formula 1]

[0223]

[0224] S is the mission score, T_avg is the average execution time for each of the mission information, T_unit,avg is the average value of the standard execution time set for each mission information provided, C_seq is the number of consecutive executions, N_up is the number of uploaded mission execution videos, P_total is the total playback time during which the uploaded mission execution videos were actually played on the user terminal, D_delay is the average start delay time from the time the mission information was provided until the time the recovery mission execution began, w_1 to w_4 are weights assigned according to the importance of each indicator, and k is a damping coefficient for adjusting the damping intensity for the average start delay time.

[0225] The processor (120) can calculate a mission score S based on Equation 1 to quantify the user's participation in the recovery mission and use the result as a trigger for increasing virtual album slots and providing highlights. Equation 1 has a structure that weighted sums multiple terms representing performance fidelity, continuity, recording activity, and feedback activity, and then additionally reflects an exponential function corresponding to the start delay time. Accordingly, it can be designed so that S increases as the user performs close to the standard performance time, continuous performance is maintained, and video uploading and video playback are active, and S decreases as the average start delay time increases.

[0226] In mathematical formula 1, the terms related to T_avg and T_unit,avg are normalization terms indicating how faithfully the actual execution was performed relative to the standard execution time provided to the user. The processor (120) can calculate the execution time for each round using the execution start event time and execution end event time received from the user terminal or the accumulated value of the step timer, and can calculate the arithmetic mean of the 7th execution time as T_avg. Additionally, the processor (120) can collect the standard execution time included in the mission information for each round and calculate the average value as T_unit,avg, and can compare the user's execution based on a consistent standard even if the missions for each round have different standard times. For example, the above-mentioned T_unit,avg may correspond to the value obtained by dividing the total mission execution time according to the mission information provided for 7 rounds by 7.

[0227] In mathematical formula 1, the term related to C_seq is a term that normalizes and reflects the degree to which continuous execution is maintained during the 7th round. The processor (120) may pre-set criteria for determining whether to perform for each round, for example, if a mission end event is received or if the execution time is greater than or equal to a minimum execution time threshold, it may determine that it is performed. After generating the execution status sequence for the 7th round, the processor (120) calculates the maximum continuous length for which execution is confirmed without interruption as C_seq, and divides this by 7 to normalize it into a value in the range of 0 to 1. Accordingly, unlike the simple cumulative number of executions, habituation and persistence can be reflected as key indicators.

[0228] In mathematical formula 1, the N_up related term is a term intended to moderately reflect the impact of an increase in the number of uploads on the score. The processor (120) can aggregate the number of uploads using upload logs received from user terminals, and the upload logs may include video identifiers, upload timestamps, and round identifiers. To exclude cases where the same video is uploaded multiple times, the processor (120) can calculate the total number of uploads over 7 rounds as N_up after removing duplicates based on video identifiers. By applying ln, the increase in the score gradually decreases as the number of uploads increases, thereby reducing the phenomenon where a specific item excessively dominates the score.

[0229] In mathematical formula 1, the terms related to P_total and T_avg are normalization terms for evaluating the user's feedback behavior in proportion to the amount of performance. The processor (120) can calculate P_total by receiving or collecting video playback logs generated from the user terminal, and the playback logs may include the start and end of playback or the length of the playback interval. The processor (120) can calculate P_total by accumulating and summing the time during which the uploaded mission performance video was actually played on the user terminal. Additionally, by placing 7 times T_avg in the denominator, users with a large amount of performance and users with a small amount of performance can be compared on the same standard, and it can reflect how actively the video was played and self-checked relative to the amount of performance.

[0230] In mathematical formula 1, the term related to D_delay is a damping term that causes the score to decrease as the average start delay time increases. The processor (120) can determine the time of mission provision for each round as the server transmission log or the time of reception acknowledgment by the user terminal, and the time of recovery mission execution start as the time of entry into the mission screen by the user terminal or the time of the start input event. The processor (120) can calculate the difference between the time of provision and the time of start in each round as the delay time and calculate the average of the 7 rounds as D_delay. By using the exp structure, the value of k can be adjusted so that the score decreases gradually or rapidly as the delay increases, allowing for a flexible design according to the service policy.

[0231] In Equation 1, w_1 to w_4 and k are constants for controlling the degree to which each parameter contributes to the mission score S and the damping intensity according to the average start delay time in Equation 1, and can be applied by the processor (120) by loading from a pre-set policy table or a configuration file. According to one embodiment, the processor (120) may be configured to select different sets of weights according to user groups, sports types, or injury risk areas, thereby enabling an evaluation suitable for the service policy even for the same performance history data.

[0232] For example, w_1 is a performance fidelity weight that controls the extent to which the average performance time T_avg, normalized by the standard performance time average T_unit,avg, is reflected in the mission score. As w_1 increases, the processor (120) may be configured to evaluate whether the user actually performed for the recommended time as a key factor. For example, in a policy that places the safety and effectiveness of a recovery mission on compliance with performance time, w_1 may be set relatively large. In one embodiment, considering that the range of the T_avg divided by T_unit,avg term is generally formed to be 0 to 2, w_1 may be set to a value in the range of 2 to 8, and specifically, w_1 may be set to 5.

[0233] For example, w_2 is a persistence weight that controls the extent to which the value of the number of consecutive executions C_seq normalized to 7 is reflected in the mission score. The larger w_2 is, the more the processor (120) can be configured to reflect consistent execution habits with a higher score than one-time executions. For example, in a policy to enhance user retention, w_2 can be set relatively large to be advantageous to users with high consecutive executions. In one embodiment, since the term C_seq divided by 7 forms a value having a range of 0 to 1, w_2 can be set to a range of 3 to 12, and specifically, w_2 can be set to 8.

[0234] For example, w_3 is a recording activity weight that controls the extent to which the log term for the number of uploads N_up is reflected in the mission score. Since ln(1+N_up) is a term designed so that the increase in score becomes gradual as the number of uploads increases, users with uploads can be meaningfully distinguished even without setting w_3 to an excessively large value. For example, when the number of uploads is 0, ln(1+N_up) becomes 0, and when the number of uploads is 3, a value of approximately ln(4) can be produced, so w_3 can be set in the range of 0.5 to 4. Specifically, w_3 can be set to 2, which can be a balanced setting that requires inducing uploads but does not excessively overwhelm execution time and persistence.

[0235] For example, w_4 is a feedback activity weight that controls the extent to which the value normalized by 7 times T_avg to the total playback time P_total is reflected in the mission score. The term P_total divided by 7 times T_avg can be interpreted as a value indicating how much the user plays the video and performs self-checks relative to the amount of execution, and can generally be formed in a range of 0 to 3. For example, if the video is played once at a level similar to the execution time, it may approach 1, and if it is played repeatedly multiple times, it may exceed 1. In one embodiment, w_4 can be set in the range of 1 to 6, and specifically, w_4 can be set to 3.

[0236] For example, k is a damping coefficient that determines the slope of the damping term for the average start delay time D_delay. As k increases, the score can be configured to decrease more sharply for the same increase in delay time, and as k decreases, the damping for the delay time can be gentler. The processor (120) can define the unit of D_delay as either minutes or seconds and select the size of k according to the defined unit. For example, if D_delay is defined in minutes, k can be set to a range of 0.01 to 0.2, specifically, k can be set to 0.05. In this case, if the average start delay time is 10 minutes, exp(-0.5) is applied so that the damping is significantly reflected. Conversely, if D_delay is defined in seconds, k can be set to a range of 0.0001 to 0.01, specifically, k can be set to 0.001. In this case, if the average start delay time is 300 seconds, exp(-0.3) is applied to reflect an appropriate level of attenuation.

[0237] The processor (120) may apply a fixed set of weights, or select and apply one of a plurality of preset weight profiles. For example, the basic profile may set w_1 to 5, w_2 to 8, w_3 to 2, w_4 to 3, and k to 0.05, the record-oriented profile may set w_3 and w_4 to relatively large values, and the timeliness-oriented profile may set k to relatively large values ​​to strongly induce a quick start to execution. Additionally, the processor (120) may be configured to select a profile based on the membership level, sports type, or injury risk area of ​​the user terminal, which allows the evaluation criteria to be flexibly adjusted according to the goal of the service.

[0238] The method by which the processor (120) collects each parameter can be implemented by classifying it according to the source of the execution history data. The processor (120) can store the time of provision for each round using the mission information transmission log, and can collect the execution start time, execution end time, upload event, and playback event using the event log transmitted by the user terminal. In addition, the processor (120) can check the video length from the uploaded video file or video metadata, and can aggregate the actual playback time from the playback log provided by the user terminal.

[0239] The technical significance of Mathematical Formula 1 lies in the fact that it allows for the evaluation of performance fidelity, consistency, recording activities, feedback activities, and timeliness by integrating them into a single quantitative indicator, rather than merely assessing whether performance was performed or simply counting the number of times. In particular, performance time is normalized relative to standard performance time to maintain comparability even when mission difficulty or length changes; continuous performance reflects the level of habituation; and the upload and playback terms reflect the user's self-monitoring behavior. Furthermore, the start delay reduction term is designed to favor users who start missions faster, even with the same amount of performance, thereby inducing immediacy in recovery routines.

[0240] The recovery mission service providing server (100) according to the present disclosure is differentiated in that the condition for granting rewards or benefits is not simple attendance or simple completion of execution, but rather uses a composite indicator combining execution logs and video logs. For example, a simple check-in-based service makes it difficult to distinguish whether the user actually performed the task or checked the quality of the execution. On the other hand, Equation 1 can quantitatively select users who maintain diligent execution and feedback loops by reflecting the execution time, start delay time, upload logs, and playback logs generated at the user terminal together. In addition, since it is directly linked to the action of increasing virtual album slots and providing highlight videos of user appearances when the calculated mission score exceeds a threshold score, it is differentiated in that the execution-based benefit is combined with the accumulation of video content assets.

[0242] The above recovery mission service provision method includes, when the processor receives the mission performance video from the user terminal for three consecutive days, generating a high-quality image based on the target frame with the largest bounding box corresponding to the user within the highlight video, and inserting the high-quality image into a specific slot of the virtual album corresponding to the user terminal.

[0243] The processor (120) may be configured to store the date of receipt, the user account identifier, and the video identifier together whenever it receives a mission performance video from a user terminal. The processor (120) may be configured to determine whether at least one mission performance video has been received each day for the past three days based on the stored reception history, and to initiate a subsequent benefit provision procedure only if the condition of three consecutive days is satisfied. At this time, whether three consecutive days are determined based on calendar dates, and even if multiple videos are received on a specific date, that date may be limited to being counted as one performance.

[0244] The processor (120) may be configured to identify the user appearance section in the highlight video received from or stored by the game data server and to select the target frame in which the bounding box corresponding to the user is calculated to be the largest. The processor (120) may calculate the user bounding box area for each frame and determine the frame with the maximum area as the target frame, and may perform high-quality image generation processing including super-resolution conversion, sharpening filtering, or noise removal on the target frame. Additionally, the high-quality image may optionally include a watermark or metadata tag containing the time of capture, a game identifier, and a user identifier.

[0245] The processor (120) may be configured to designate a specific slot of a virtual album corresponding to a user account and to insert a generated high-definition image into that slot. The specific slot may be pre-designated as a reward slot for achieving three consecutive days, and a policy may be applied to move existing content to a storage area instead of overwriting it when inserting into the slot if existing content exists. Additionally, the processor (120) may send an album update event to the user terminal so that the high-definition image is displayed immediately, and may control the user interface so that the user long-presses the image to perform sharing or lock settings.

[0247] The above recovery mission service provision method includes: an operation in which the processor transmits a push notification to the user terminal in response to the arrival of the leisure time, and simultaneously transmits a vibration generation signal of a preset pattern to the wearable device; and an operation in which the first execution step screen of the mission information is forcibly activated on the screen of the user terminal only when a button input of the wearable device is confirmed.

[0248] The processor (120) may be configured to send a push notification to a user terminal in response to the arrival of leisure time, and simultaneously send a vibration signal of a preset pattern to a wearable device. The push notification may include a notification card containing a mission title, an estimated time to take, and a start button, and the vibration pattern may be fixed in a form such as two short vibrations followed by one long vibration. The processor (120) may apply a policy to store a flag for sending notifications for the day to prevent duplicate notifications from occurring for the same leisure time, and to limit retransmission to one time.

[0249] The processor (120) may be configured to forcibly activate the first execution step screen of the mission information on the screen of the user terminal only when a button input from the wearable device is confirmed. When the processor (120) receives a button input event from the wearable device, it may send a forced activation command to the user terminal, and the user terminal may be configured to switch the mission application to the front and immediately display the first step screen when it receives the command. Additionally, the processor (120) may be configured not to perform forced activation if a button input is not received within a certain period of time, but instead to expire the notification to prevent unintended screen switching by the user.

[0250] The processor (120) may be configured to receive a start input or a timer start event on the first step screen to check whether the user has actually started the execution after forced activation. If a start event is confirmed, the processor (120) may record the start time in the execution history data, and if there is no start event, it may treat it as not executed or determine whether the re-notification condition is satisfied. Additionally, forced activation may be restricted in the user terminal's Do Not Disturb mode or screen lock state, and if a reason for restriction occurs, the processor (120) may be configured to provide an alternative guidance vibration to a wearable device.

[0252] The above recovery mission service provision method includes: an operation in which the processor determines whether to pay virtual points and the amount to pay based on a preset winning probability when the mission score exceeds the threshold score; and an operation in which the processor transmits a reward winning notification to the user terminal according to the determined result, and at the same time confirms that the highlight video has been played for 15 seconds or more on the user terminal, finally pays the virtual points.

[0253] The processor (120) may be configured to determine whether to pay virtual points and the amount to pay based on a preset winning probability when the mission score exceeds a threshold score. The processor (120) may determine whether to win using a random number generation value, and the amount to be paid may be limited to 10 points, 30 points, or 50 points depending on the range of the mission score exceedance. Additionally, the processor (120) may simplify the rules by adopting a fixed policy that applies a single probability value rather than applying the winning probability differently to each user.

[0254] The processor (120) may be configured to send a reward winning notification to a user terminal according to a determined result and simultaneously withhold the final payment. The processor (120) may display the fact of winning, the expected payment points, and the payment conditions in the reward winning notification, and the payment conditions may be limited to when it is confirmed that the highlight video has been played for 15 seconds or more. At this time, the withholding status may be stored as a reward withholding record, and the withholding record may include a user account identifier, a point quantity, and an expiration time.

[0255] The processor (120) may be configured to finally pay virtual points only when it is confirmed that a highlight video has been played for 15 seconds or more on the user terminal. The processor (120) may receive a playback start event and a cumulative playback time event from the user terminal to detect when the cumulative playback time exceeds 15 seconds, and at that time, may convert a pending record to payment completed and increase the virtual point balance. Additionally, if the user ends playback before 15 seconds, the processor may be configured to maintain the pending record or automatically discard it when the expiration time arrives.

[0257] The above recovery mission service provision method includes the operation of the processor sharing the mission performance video received from the user terminal with at least one external terminal and opening a tournament-style voting game; and the operation of providing additional points to the user terminal in addition to the virtual points when the mission performance video is determined to be within a predetermined rank according to the voting results by the at least one external terminal.

[0258] The processor (120) may be configured to share a mission performance video received from a user terminal with at least one external terminal. The processor (120) may create an external access link for sharing and issue a transmission authorization token so that an external terminal connected to the link can play the video, and may narrow the scope by limiting the number of external terminals to be shared to eight. Additionally, the processor (120) may be configured to group eight of the shared videos into candidates and open a tournament-style voting game.

[0259] According to one embodiment, the processor (120) may be configured to receive votes from external terminals in a tournament voting game and determine the winner for each round. For example, the processor (120) may automatically generate a bracket in the order of quarterfinals, semifinals, and finals, and determine the video that obtains more votes in each bracket as the winner. Additionally, the processor (120) may be configured to limit voting to only one time per round per external terminal to prevent fraudulent voting, and to store the voting time and terminal identifier in a log.

[0260] According to one embodiment, the processor (120) may be configured to provide additional points to the user terminal in addition to virtual points when the mission performance video is determined to be within a predetermined rank based on the voting results. The predetermined rank may be narrowly set to 1st or 2nd place, and a fixed additional point table may be applied, such as 100 points for 1st place and 30 points for 2nd place. Additionally, the processor (120) may be configured to display the details of the additional point payment along with a result notification on the user terminal when the voting ends.

[0262] The above method for providing a recovery mission service comprises: an operation in which the processor determines the injury risk area, wherein the operation determines whether the pain area and the treatment area according to the treatment history are the same; an operation in which the processor extracts the user's address data from the account information of the user terminal if the pain area and the treatment area are the same; and an operation in which the processor identifies a target medical institution located at the shortest distance based on the address data from a pre-set external medical institution database corresponding to the pain area, and provides to the user terminal, together with the mission information, detailed location information of the target medical institution and distance information calculated from the address data to the target medical institution.

[0263] The processor (120) may be configured to determine whether the pain area and the treatment area based on the treatment history are the same during the process of determining the injury risk area. The processor (120) can check the pain area code received from the user terminal, check the treatment area code included in the treatment history, and then determine whether the two codes match. Additionally, the processor (120) may configure the scope of application of the function to be very narrow by restricting the external medical institution guidance procedure to be performed only when the match is determined to be the same.

[0264] The processor (120) may be configured to extract the user's address data from the account information of the user terminal when the pain area and the treatment area are the same. The address data may be stored as at least one of a road name address, a postal code, or an administrative district code, and the processor (120) may be configured to use only the coordinate values ​​after geocoding processing for distance calculation, rather than transmitting the address data externally as is. Additionally, if the user does not consent to providing the address, the processor may be configured to provide a consent screen first without performing a medical institution recommendation.

[0265] The processor (120) may be configured to identify a target medical institution located at the shortest distance based on address data from a pre-set external medical institution database corresponding to the pain area, and to provide detailed location information of the target medical institution and calculated distance information to the user terminal along with mission information. The external medical institution database may include medical specialty tags, institution coordinates, and institution contact information, and the processor (120) may first filter candidate institutions using medical specialty tags mapped to the pain area code and then perform the shortest distance calculation. Additionally, the processor (120) may be configured to display a medical institution guidance item close to the precaution area of ​​the mission information to induce the user to take immediate action.

[0267] The above description is merely an illustrative explanation of the technical concept of the present invention, and those skilled in the art to which the present invention pertains will be able to make various modifications and variations within the scope of the essential characteristics of the present invention.

[0268] Accordingly, the embodiments disclosed in this invention are intended to illustrate, not limit, the technical concept of the invention, and the scope of the technical concept of the invention is not limited by these embodiments. The scope of protection of this invention shall be interpreted by the claims below, and all technical concepts within an equivalent scope shall be interpreted as being included within the scope of rights of this invention.

Claims

Claim 1 A method for providing a recovery mission service, which is performed by a service providing server including a processor and provides AI-customized recovery mission information based on self-diagnosis of condition after exercise, wherein the processor performs the operation of identifying a target stadium among a plurality of stadiums based on the GPS signal of the designated signal in response to receiving a designated signal from a wearable device; the processor performs the operation of identifying a target sports match among a plurality of sports matches performed at the target stadium based on stadium identification information of the target stadium and the time of reception when the designated signal is received; the processor performs the operation of providing a self-diagnosis input interface to a user terminal registered corresponding to the wearable device in response to identifying that the target sports match has ended through schedule information of the target sports match received from a match data server; and the processor performs the operation of receiving self-diagnosis data including a pain area, treatment history, and leisure time from the user terminal, and identifying an injury risk area based on the sport type of the target sports match and the self-diagnosis data. The above processor includes the operation of confirming mission information including a target recovery mission set in response to the injury risk area, a method for performing the mission for the target recovery mission, a time for performing the mission, and precautions, and transmitting the mission information to the user terminal whenever the leisure time arrives each day, and the recovery mission service providing method includes the operation of the processor acquiring a plurality of video data captured for the target sports game from a game data server; and the operation of the processor extracting exercise data including the load amount and range of motion for each joint of the user and the collision area based on the plurality of video data.and the processor includes an operation of determining the injury risk area based on the pain area included in the self-diagnosis data, the treatment history, and the exercise data, and the operation of determining the injury risk area includes the processor comparing the pain area included in the self-diagnosis data and the collision area included in the exercise data with a body part classification table; A method for providing a recovery mission service, wherein the processor includes an operation of determining a preset representative area corresponding to a target category as the injury risk area when the pain area and the collision area are included in one of the target categories among the plurality of categories included in the body part classification table; the operation of determining the injury risk area includes an operation in which the processor determines the pain area as the injury risk area in response to the fact that the pain area and the collision area are included in different categories among the plurality of categories included in the body part classification table and the pain area and the treatment area according to the treatment history are the same; the operation of determining the injury risk area includes an operation in which the processor determines the collision area as the injury risk area when the pain area and the collision area are included in different categories among the plurality of categories included in the body part classification table and the pain area and the treatment area according to the treatment history are different; and the operation of providing mission information includes an operation in which the processor sets the number of repetitions per mission and provides it to the user terminal in proportion to the size of the target load amount and the size of the target range of motion of the injury risk area included in the exercise data. Claim 2 delete Claim 3 delete Claim 4 delete Claim 5 In claim 1, the recovery mission service providing method comprises: the operation of the processor receiving execution history data for the mission information from the user terminal after providing the mission information seven times; the operation of the processor increasing the number of virtual album slots corresponding to the user terminal and provided for video storage in proportion to the difference between the mission score and the threshold score when the mission score according to the execution history data exceeds a threshold score; and the operation of the processor extracting a highlight video in which the user appears within the plurality of video data and providing it to the user terminal, wherein the mission score is calculated based on the average execution time for each of the mission information, the number of consecutive executions, the average start delay time from the time the mission information is provided until the time the recovery mission is started, the number of uploaded mission execution videos, the ratio of the total length of the uploaded mission execution videos to the mission execution time, and the total playback time of the mission execution videos by the user terminal.

Images