Method and apparatus for proving the human creator of a creative work

Abstract

The present invention relates to the technical field of proving the source, authenticity, and human creation of a creative work. More specifically, the invention relates to a method and apparatus in which a creator terminal equipped with a front camera, a rear camera, and an Inertia Measurement Unit (IMU) simultaneously captures a creative scene and the creator's face, generates a Proof of Human Creator (PoHC) token by binding and signing sensor sequences and capture metadata collected during a specific time window of a predetermined length in a Trusted Execution Environment (TEE), and a validator terminal or server determines whether the work is a human creation using said token, remote attestation, sensor fusion consistency, and anti-spoofing (liveness) results. Furthermore, the present invention enables the results of creative activities to be transmitted or stored over a network (including a blockchain network) to allow for mutual verification and distribution.

Description

Technology Field

[0001] The present invention relates to the technical field of proving the source, authenticity, and human creation of a creative work. More specifically, the invention relates to a method and apparatus in which a creator terminal equipped with a front camera, a rear camera, and an Inertia Measurement Unit (IMU) simultaneously captures the creative scene and the creator's face, generates a Proof of Human Creator (PoHC) token by binding and signing sensor sequences and capture metadata collected during a specific time window of a predetermined length in a Trusted Execution Environment (TEE), and a validator terminal or server determines whether the work is a human creation using said token, remote attestation, sensor fusion consistency, and anti-spoofing (liveness) results. Furthermore, the present invention enables the results of creative activities to be transmitted or stored over a network (including a blockchain network) to allow for mutual verification and distribution. The present invention relates to a method and apparatus on the creator's side, a method and apparatus on the validator's side, and a computer-readable recording medium and system applicable to various creative works such as photographs, videos, drawings, designs, documents, and audio. Background Technology

[0002] With the widespread adoption of digital cameras, smartphones, and tablet computers, as well as the advancement of generative AI, various creative works—including photographs, videos, drawings, designs, documents, and audio—are being mass-produced and distributed. Consequently, there is a rapidly increasing demand to reliably distinguish and verify whether specific content was actually created or recorded by humans, or generated or synthesized by AI. In particular, strong trust in the creator is essential for commercial works, educational and research datasets, and legal and administrative procedures.

[0003] Traditionally, metadata-based source information such as EXIF ​​(Exchangeable Image File Format) or integrity proofs utilizing hashes and timestamps have been widely used. Additionally, methods to record the creation time and owner through blockchain or NFTs have been proposed. However, metadata has the problem of being easily removed or altered, and the causal relationship between originality and creation is weakened through workarounds such as re-encoding or screen re-capturing. It is difficult to confirm who actually created the result using only a simple hash.

[0004] Recently, there has been an increasing number of attempts to sign and record device information and editing history at the time of shooting by introducing content source (provenance) frameworks at the camera device and platform level. However, this approach primarily deals with the documentary consistency of files and editing history and has limitations in strongly guaranteeing human physical participation or action. For example, it is difficult to identify who the actual shooter or producer is, even when using the same device or account.

[0005] Face recognition and biometric-based liveness (anti-spoofing) verification have been considered to enhance human participation. However, spoofing attacks, such as screen playback and sophisticated masks / synthesized images, continue to become more advanced, making it difficult to completely rule out forgery or alteration using only a single video signal. Furthermore, given the significant privacy issues associated with biometric data, technical considerations are required to process and store data at the level of irreversible feature summaries instead of the original video.

[0006] In terms of sensors, sensor fusion, which combines video / image data with an Inertial Measurement Unit (IMU) within a specific time window of a predetermined length, is gaining attention. Acceleration and angular velocity sequences immediately before and after shooting can reflect signature human motions, such as wrist flicks or rotation-stopping. However, in practice, it is difficult to ensure alignment between the camera timeline and the IMU timeline due to factors such as rolling shutter, the operation of Optical Image Stabilization (OIS), and differences in exposure times. Furthermore, simple logs pose a risk of post-hoc forgery, requiring security signatures within a trust boundary.

[0007] To strengthen trust boundaries, modern terminals provide Trusted Execution Environment (TEE), Secure Element (SE), and attestation functions. The TEE manages key generation / storage / signing, monotonic counters, and boot integrity status within an execution environment isolated by hardware, providing resistance to tampering and forgery that is difficult to achieve with software alone. By connecting these on-device security functions to the evidence generation and verification points of the creation process, a trusted chain can be constructed.

[0008] Another challenge involves frame-level binding and process history. Signing only a single final file does not sufficiently demonstrate the causal relationships of the creative process. It is necessary to sign the creation scene (rear camera), the creator's face (front camera), and IMU sequences collected within a specific time window of a predetermined length, grouping them frame by frame. For videos and sequential images, the step-by-step connections must be recorded using chaining hashes. Only then can the connection to the original creative process be verified, even if editing or re-encoding occurs later.

[0009] For real-world deployment, it is required to (i) interoperate the aforementioned evidence with standardized metadata / signature containers (e.g., origin frameworks), (ii) have a policy engine calculate a human creation trust index by combining liveness, sensor consistency, and security counter states, (iii) preserve privacy (irreversible facial feature summaries, minimal disclosure of location / device information), (iv) time synchronization with external sensors such as wearables, (v) provisional verification in offline environments followed by delayed re-verification, and (vi) optional linkage with network records (including blockchain networks). These technical and operational requirements clearly demonstrate the need for a solution that strongly proves human creation while seamlessly integrating with the distribution ecosystem. The problem to be solved

[0010] The present invention aims to solve the following problems in order to solve the aforementioned problems.

[0011] The present invention provides a method and apparatus for reliably proving that a creative work was actually recorded / produced by a human by simultaneous capture of a front camera and a rear camera, binding an IMU sequence collected during a specific time window of a predetermined time length to a creator's face / scene frame on a frame-by-frame basis, and configuring this into a Proof of Human Creator (PoHC) token signed in a secure execution environment (TEE).

[0012] The present invention provides a method and apparatus for calculating a Human Behavior Proof Score (H-score) by combining a liveness (anti-spoofing) result, a sensor fusion consistency index (concurrency / physical alignment of front / rear capture and IMU), and TEE remote authentication evidence in a verification step, and for determining / outputting / transmitting whether it is a human creation through threshold comparison.

[0013] The present invention provides a method and apparatus that can verify the causal relationship between the creative process and the final result retrospectively, even if post-processing such as editing, resizing, or re-encoding is performed, by forming a process history using a chaining hash for a video or continuous image.

[0014] The present invention provides a method and apparatus that maintain the validity of proof while protecting privacy by processing a creator's biometric information into an irreversible feature summary and selectively including location / device information under precision control.

[0015] The present invention provides a method and apparatus that utilizes TEE-based key management, digital signatures, and monotonic counters to provide a trust boundary robust against re-flash, rollback, and replay attacks, and stores or transmits generated tokens and metadata to a network (including a blockchain network) so that a third party can independently verify them.

[0016] The present invention provides a method and apparatus that supports interoperability with standardized source frameworks such as C2PA / Content Credentials, includes / validates PoHC-specific claims in a custom namespace, and implements a consistent display / validation UX across platforms and services.

[0017] The present invention provides a method and apparatus for setting threshold values ​​based on a calibration dataset according to security / operational goals (e.g., false positive rate, equal error rate, F1 optimization), performing runtime correction according to environmental contexts such as illuminance, face-camera distance, synchronization quality of a specific time window of a predetermined time length, and OIS status, and managing verification policies and logs so as to be auditable.

[0018] The problems solved by the present invention are not limited to the above items, and various modifications / extensions that can be easily derived by a person skilled in the art from the description below (e.g., time synchronization linkage with a wearable sensor, delayed re-verification after offline verification, etc.) are also included within the scope of the present invention.

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

[0020] According to various embodiments of the present invention, a method for proving a human creator performed by a creator terminal comprises: a creator terminal including a front camera, a rear camera, an Inertia Measurement Unit (IMU), a Trusted Execution Environment (TEE), memory, a processor, and a transceiver; a step of simultaneously performing a session for capturing a creation target by the rear camera and a session for capturing the creator's face by the front camera; a step of collecting a sequence of acceleration or angular velocity of the IMU during a specific time window of a predetermined time length based on the rear camera and the shutter event of the front camera; a step of calculating a feature vector from the sequence and calculating a first human behavior proof score by the processor based on the matching of the feature vector with a motion template associated with one or more predetermined signature motions; and a step of generating PoHC (Proof of Human Creator)-claim data by the processor by binding face features obtained from the front camera, a frame hash of the rear camera, timestamps within the specific time window, and terminal identification security authentication information to the same sequence identifier. A method is provided comprising the steps of: generating a PoHC token by the processor by performing an electronic signature on the above PoHC-claim data with a terminal-specific key in the above TEE; and transmitting at least one of frames captured by the rear camera and the front camera or metadata of the frames and the PoHC token to an external terminal or an external network by the transceiver.

[0021] According to various embodiments of the present invention, a method performed by a verifier terminal comprises: the verifier terminal including an input device, an output device, a transceiver, a memory, and a processor; and receiving by the transceiver at least one of frames captured with respect to the face of a creation subject and a creator, or metadata of said frames, and a PoHC (Proof of Human Creator) token corresponding to said frames from an external terminal or an external network; parsing said PoHC token to extract by the processor a frame hash of the rear camera of said creator terminal, a summary of said creator's facial features, and a timestamp within a specific time window of a predetermined time length; verifying the digital signature and certificate chain of said PoHC token, and confirming by the processor the Trusted Execution Environment (TEE) remote authentication evidence and security patch level whitelist conformity of said creator terminal included in said PoHC token. A step of verifying the simultaneity within the specific time window between face capture based on the front camera of the creator terminal, capture of the creation subject through the rear camera, and data collection by the Inertia Measurement Unit (IMU) of the creator terminal, confirming the allowable range of time synchronization error, and inspecting the monotonic counter rollback or replay window by the processor; a step of performing a sensor fusion consistency check, calculating a consistency index between rolling shutter parameters, Optical Image Stabilization (OIS) drive, exposure time, frame timing, and IMU sequence, and setting a warning flag by the processor in case of discrepancy;A method is provided comprising the steps of: (i) calculating a second human behavior proof score by combining the results of an anti-spoofing verification of liveness, (ii) the consistency indicator, and (iii) the security counter state of the PoHC-token based on the weights of the policy engine, and determining by the processor whether the second human behavior proof score is human creation by comparing it with a second human behavior proof threshold; if the second human behavior proof score is determined to be greater than or equal to the second human behavior proof threshold, generating by the processor a confirmation result that the creation target is indeed human creation; outputting the confirmation result by the output device, or transmitting the confirmation result to the external terminal or the external network by the transceiver.

[0022] According to various embodiments of the present invention, a creator terminal is provided, comprising a front camera, a rear camera, an Inertia Measurement Unit (IMU), a Trusted Execution Environment (TEE), a memory, a processor, and a transceiver, wherein the memory stores instructions for operations performed by the processor, and the operations include steps of a method of operation of the creator terminal according to various embodiments of the present invention.

[0023] According to various embodiments of the present invention, a creator terminal is provided, comprising a verifier terminal, an input device, an output device, a transceiver, a memory, and a processor, wherein the memory stores instructions for operations performed by the processor, and the operations include steps of a method of operation of a verifier terminal according to various embodiments of the present invention.

[0024] According to various embodiments of the present invention, a non-transitory computer-readable storage medium having stored thereon instructions that, when executed by at least one processor, cause the at least one processor to perform operations is provided, wherein the operations include steps of a method of operating a creator terminal according to various embodiments of the present invention.

[0025] According to various embodiments of the present invention, a non-transitory computer-readable storage medium having stored thereon instructions that, when executed by at least one processor, cause the at least one processor to perform operations is provided, wherein the operations include steps of a method of operating a verifier terminal according to various embodiments of the present invention. Effects of the invention

[0026] The present invention can provide a method and apparatus for reliably proving that a creation was actually recorded / produced by a human by binding IMU sequences collected during a specific time window of a predetermined time length and simultaneous capture of a front camera and a rear camera with the creator's face / scene frame on a frame-by-frame basis, and configuring this into a Proof of Human Creator (PoHC) token signed in a secure execution environment (TEE).

[0027] The present invention can provide a method and apparatus for calculating a Human Behavior Proof Score (H-score) by combining a liveness (anti-spoofing) result, a sensor fusion consistency index (concurrency / physical alignment of front / rear capture and IMU), and TEE remote authentication evidence in a verification step, and for determining / outputting / transmitting whether it is a human creation through threshold comparison.

[0028] The present invention can provide a method and apparatus that can verify the causal relationship between the creative process and the final result retrospectively, even if there is post-processing such as editing, resizing, or re-encoding, by forming a process history with a chaining hash for a video or continuous image.

[0029] The present invention can provide a method and apparatus that maintain the validity of proof while protecting privacy by processing the creator's biometric information into an irreversible feature summary and selectively including location / device information under precision control.

[0030] The present invention can provide a method and apparatus that utilizes TEE-based key management / digital signature / monotonic counters to provide a trust boundary robust against re-flash / rollback / replay attacks, and stores or transmits generated tokens and metadata to a network (including a blockchain network) so that a third party can independently verify them.

[0031] The present invention can provide a method and apparatus that supports interoperability with standardized source frameworks such as C2PA / Content Credentials, includes / validates PoHC-specific claims in a custom namespace, and implements a consistent display / validation UX across platforms and services.

[0032] The present invention can provide a method and apparatus for setting threshold values ​​based on a calibration dataset according to security / operational goals (e.g., false positive rate, equal error rate, F1 optimization), performing runtime correction according to environmental contexts such as illuminance, face-camera distance, specific time window synchronization quality of a predetermined time length, and OIS status, and managing verification policies and logs so as to be auditable.

[0033] The effects of the present invention are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art from the description below. Brief explanation of the drawing

[0034] FIG. 1 illustrates a communication system according to various embodiments of the present invention. FIG. 2 illustrates an example of the structure of a creator terminal according to various embodiments of the present invention. FIG. 3 illustrates an example of the structure of a verifier terminal according to various embodiments of the present invention. FIG. 4 illustrates an example of the structure of a management server according to various embodiments of the present invention. FIG. 5 illustrates an example of the operation process of a creator terminal according to various embodiments of the present invention. FIG. 6 illustrates an example of the operation process of a verifier terminal according to various embodiments of the present invention. FIG. 7 illustrates exemplary steps of a creation process according to various embodiments of the present invention. FIG. 8 shows an example of a scene in which a creative subject is photographed using a rear camera of a creator terminal according to various embodiments of the present invention. FIG. 9 shows an example of a scene in which a creator's face is captured using a front camera of a creator terminal according to various embodiments of the present invention. FIG. 10 illustrates an example of a process in which hashes are sequentially formed for frames / evidence generated at each creation stage according to various embodiments of the present invention and converge to a final result hash. FIG. 11 illustrates an example of a procedure for image metadata, timestamping, hash generation, and optionally recording on a blockchain to prove and disclose according to various embodiments of the present invention. FIG. 12 illustrates an example of a configuration in which a data layer is generated through simultaneous shooting with app execution according to various embodiments of the present invention, and hash data is generated based on the results of proof of action and face recognition to prove the creation and the human creator through blockchain registration. FIG. 13 illustrates an example of a concept in which image metadata, timestamping data, face recognition data, and behavioral pattern data are combined and linked to a final proof token according to various embodiments of the present invention. Specific details for implementing the invention

[0035] Best form for carrying out the invention

[0036] Hereinafter, embodiments of the present invention are described in detail with reference to the attached drawings so that those skilled in the art can easily implement the present invention. The present invention may be embodied in various different forms and is not limited to the embodiments described herein.

[0037] FIG. 1 illustrates a communication system according to various embodiments of the present invention.

[0038] FIG. 1 illustrates a human creator certification system according to various embodiments of the present invention.

[0039] Referring to FIG. 1, a system according to an embodiment of the present invention includes a creator terminal (100), a validator terminal (300: 300-1, 300-2, …, 300-n), a management server (400), a blockchain network (500), and a communication network (600). The creative design (200) on the left side of the drawing represents an example of a creative object.

[0040] A creator terminal (100) is an electronic device operated by a creator, which can simultaneously capture a creation scene and the creator's face using a front camera, a rear camera, and an Inertial Measurement Unit (IMU), and generate a Proof of Human Creator (PoHC) token by binding and signing the sensor sequence and capture metadata collected during a specific time window of a predetermined length based on a camera shutter event in a Trusted Execution Environment (TEE). The generated token and related metadata can be transmitted to a management server (400) or a blockchain network (500) via a communication network (600). The creator terminal (100) can be implemented as a computer, smartphone, tablet, or smart glasses including a transceiver, memory, processor, input device, output device, camera, IMU, and TEE.

[0041] The validator terminal (300: 300-1, 300-2, …, 300-n) receives PoHC tokens and capture metadata and performs a determination of whether it is human creation based on signature verification, certificate chain verification, TEE Remote Attestation Evidence verification, concurrency check, sensor fusion consistency check, and liveness anti-spoofing results, or can display results by querying information stored in the management server (400) or blockchain network (500).

[0042] In this specification, "liveness" refers to a property indicating that a biosignal input at the time of capture originated from a real person currently present at the scene. Liveness evaluation is based on physiological and behavioral temporal change cues observed during a specific time window of a predetermined length, and, by example, uses one or more of the following: temporal rates of change of blinks, lips, and microexpressions and optical flow patterns; continuity of depth, infrared, and stereo parallax; presence of remote photoplethysmography (rPPG) signals and frequency band compatibility; and the mutual alignment of 3D facial landmark-based head pose with Inertial Measurement Unit (IMU) rotation and translation. Liveness results may be expressed as a score or binary judgment and may be corrected according to ambient illumination, camera settings, and user profile. The above examples are for illustrative purposes only and are not limited thereto.

[0043] In this specification, "Anti-Spoofing" refers to procedures and techniques for excluding abnormal inputs by detecting spoofing, playback, and synthesis attacks, such as photos, screen playback, 3D masks, synthetic images, and playback tokens. Implementation may be made of one or more of software, firmware, or hardware, and may include multi-sensor fusion such as front camera image analysis, depth and infrared sensors, stereo cameras, microphones, and IMUs. The output of Anti-Spoofing may consist of a score for signs of tampering, a warning flag, and a reason code, and threshold values ​​are configured by a Policy Engine and preserved in an audit log. The above examples are for illustrative purposes only and are not limited thereto.

[0044] In this specification, Liveness Anti-Spoofing refers to an integrated verification procedure that determines whether spoofing has occurred by using a liveness score calculated from the liveness evaluation as a core input. The procedure aligns front-end captures, back-end captures, and IMU sequences within a specific time window of a predetermined time length, and calculates a Proof of Human Behavior score by combining the liveness score, sensor fusion consistency indicators, and the state of a Trusted Execution Environment (TEE)-based security counter as weights for the policy engine. The resulting score is compared with a threshold set by the policy and reflected in the determination of human creation, and the summary value and reason code may be recorded in the fields of Proof of Human Creator Claim Data (PoHC-claim data) and Proof of Human Creator Token (PoHC-token). If facial recognition is impossible or has low reliability, it may be switched to alternative identification features such as finger joint poses, palm veins, or short voice segments. The above examples are for illustrative purposes only and are not limited thereto.

[0045] The management server (400) performs registration, policy management, whitelist management, trust anchor storage, and log management, and can distribute a policy profile including thresholds and weights as needed, or aggregate and provide verification results. Additionally, the management server (400) can relay the recording and verification of tokens or metadata by linking with a blockchain network (500).

[0046] A blockchain network (500) refers to a set of multiple nodes that record and share transactions in blocks based on distributed ledger technology. It can be implemented as a public blockchain or a private blockchain, and examples of consensus algorithms include Proof of Work (PoW), Proof of Stake (PoS), Practical Byzantine Fault Tolerance (PBFT), Tendermint, Raft, and Proof of Authority (PoA). Depending on the embodiment, summary information of the PoHC token, the chaining hash, and part of the content source metadata may be recorded.

[0047] The communication network (600) includes wired or wireless internet, cellular network, wireless local area network (WLAN), Bluetooth, etc., and provides signal and data transmission between creator terminal (100), validator terminal (300), management server (400) and blockchain network (500).

[0048] Each of the above configurations is merely an example, and depending on the embodiment, some configurations may be omitted, integrated, or added, and two or more functional modules may be combined and implemented within a single device.

[0049] FIG. 2 illustrates an example of the structure of a creator terminal according to various embodiments of the present invention.

[0050] Referring to FIG. 2, the creator terminal (100) includes a front camera (110), a rear camera (120), an Inertial Measurement Unit (IMU) (130), a Trusted Execution Environment (TEE) (140), a memory (150), a processor (160), and a transceiver (170).

[0051] The front camera (110) and the rear camera (120) are connected to and operated by the processor (160), and according to the embodiment, the two cameras can perform a capture session that operates simultaneously. The front camera (110) acquires an image of the creator's face, and the rear camera (120) captures the subject of creation. Each camera provides shutter event information to the processor (160) so that it can be used as a reference for subsequent sensor collection time.

[0052] The IMU (130) measures inertial data, such as acceleration and angular velocity, and provides it to the processor (160). The processor (160) can control the IMU (130) to collect an IMU sequence during a specific time window of a predetermined time length based on a camera shutter event. The IMU data serves as the basis for signature motion recognition and sensor fusion consistency verification.

[0053] The TEE (140) is an isolated execution environment responsible for security operations such as generating and storing terminal-specific keys, digital signatures, generating remote authentication evidence, and managing monotonic counters. The processor (160) can instruct the TEE (140) to perform digital signatures on core data related to PoHC.

[0054] As used herein, a Trusted Execution Environment (TEE) refers to an isolated execution environment configured to execute code and protect data within a security boundary isolated from the general operating system area, and may be implemented as a combination of one or more of hardware, firmware, and software. The TEE includes forms that operate in the security mode of the main processor or on an independent chip such as a separate security processor or a Secure Element (SE), and, for example, ensures isolation from the general operating system area by utilizing security mode isolation technology, secure memory and bus protection, secure boot and measurement boot, access control, and secure interprocess communication. Within the TEE, a TEE Operating System and one or more Trusted Applications may exist, which are called via security APIs provided by the platform.

[0055] The TEE can perform security functions such as the generation and protection of device-specific keys, digital signatures and encryption / decryption, secure key derivation and storage, management of monotonic counters and rollback resistance, provision of trust clocks and high-resolution timestamps, and generation of Remote Attestation evidence and certificate chain management. In embodiments of the present invention, the TEE is used for binding and digital signatures of PoHC claim data, reporting of security counter status, and generation of Remote Attestation evidence of platform security status, and is interpreted as a comprehensive concept including a Secure Enclave or Secure Element (SE) that provides corresponding functions. It is not limited to specific trademarks or architectures, and any implementation providing equivalent security isolation, key protection, and Remote Attestation functions is included in this definition.

[0056] The memory (150) may include volatile memory and non-volatile memory and stores captured images and videos, sensor sequences, metadata, application programs, setting information, and data necessary for the operation of the processor (160). The memory (150) provides the stored data upon request from the processor (160).

[0057] The processor (160) is configured to execute a program stored in memory to implement the procedure proposed in the present invention. For example, the processor (160) controls the simultaneous capture of the front camera and the rear camera, collects IMU sequences, binds capture metadata and security information, performs a signature in the TEE (140), and transmits data through the transceiver (170). The processor (160) may be implemented as one or more central processing units, signal processing units, or application processors.

[0058] A transceiver (170) is connected to a processor (160) to transmit or receive signals. All or part of the transceiver (170) may be referred to as a transmitter, a receiver, or a transceiver. The transceiver (170) may support wired and wireless connections, and in the case of wireless, may support at least one of various communication standards such as the Institute of Electrical and Electronics Engineers (IEEE) 802 series, Wi-Fi (Wireless Fidelity), Long Term Evolution (LTE) and New Radio (NR) of the 3rd Generation Partnership Project (3GPP), Bluetooth, and a Wireless Local Area Network (WLAN).

[0059] Each of the above components is merely an example for convenience of explanation, and depending on the embodiment, some components may be omitted, integrated, or added, and a single component may be implemented to perform two or more functions.

[0060] FIG. 3 illustrates an example of the structure of a verifier terminal according to various embodiments of the present invention.

[0061] Referring to FIG. 3, the verifier terminal (300: 300-1, 300-2, …, 300-n) includes an input device (310), an output device (320), a transceiver (330), a memory (340), and a processor (350).

[0062] The input device (310) is connected to the processor (350) and accepts operations such as inputting user commands, selecting policies, selecting or scanning token files. The input device (310) may be implemented as a touch display, keyboard, keypad, pointer device, microphone, etc.

[0063] The output device (320) is connected to the processor (350) and provides verification results, human creation reliability index, badge display, warning messages, and audit log summary in a visual or auditory form. The output device (320) may be implemented as a display or speaker, etc.

[0064] The transceiver (330) is connected to the processor (350) to transmit or receive signals. All or part of the transceiver (330) may be referred to as a transmitter, a receiver, or a transceiver. The transceiver (330) may support wired and wireless connections, and for wireless connections, may support at least one of the Institute of Electrical and Electronics Engineers (IEEE) 802 series, Wi-Fi (Wireless Fidelity), Long Term Evolution (LTE) and New Radio (NR) of the 3rd Generation Partnership Project (3GPP), Bluetooth, and a Wireless Local Area Network (WLAN). If necessary, a secure channel such as Transport Layer Security (TLS) may be used.

[0065] The memory (340) may be composed of one or more combinations of volatile memory and non-volatile memory and stores the received Proof of Human Creator (PoHC) token and capture metadata, trust anchors and certificate chains, remote authentication policies, policy profiles including thresholds and weights, and verification logs. The memory (340) provides the stored data upon request from the processor (350).

[0066] The processor (350) is configured to perform the verification procedure proposed in the present invention by executing instructions stored in memory. For example, the processor (350) receives and parses PoHC tokens and metadata through the transceiver (330) to extract frame hashes, face feature summaries, timestamps within a specific time window of a predetermined time length, and device and firmware information. Subsequently, it performs digital signature and certificate chain verification, verifies the trustworthiness of the Trusted Execution Environment Remote Attestation Evidence included in the token, performs concurrent checks between front capture, rear capture, and inertial measurement unit data collection, and checks whether the monotonic counter has been rolled back or played back. Additionally, it calculates sensor fusion consistency indicators between rolling shutter parameters, Optical Image Stabilization (OIS) drive, exposure time, frame timing, and inertial measurement unit sequences, calculates a human behavior proof score by combining the liveness result and the security counter state with weights defined in the policy engine, and then determines whether it is human creation by comparing it with a threshold value. The judgment result may be displayed on the output device (320) or transmitted to an external system via the transceiver (330).

[0067] Each of the above components is merely an example for illustrative purposes. Depending on the embodiment, some components may be omitted, integrated, or added, and a single component may be implemented to perform two or more functions.

[0068] FIG. 4 illustrates an example of the structure of a management server according to various embodiments of the present invention.

[0069] The management server (400) can be implemented as an example of an external device that transmits metadata of captured frames and PoHC tokens to the creator terminal. Referring to FIG. 4, the management server (400) includes a transceiver (410), memory (420), and a processor (430).

[0070] The transceiver (410) is connected to the processor (430) to transmit or receive signals and data through a network. In one embodiment, the transceiver (410) supports connection with an Internet Protocol (IP) network, a Wireless Local Area Network (WLAN), a Cellular Network, etc., and can use a Transport Layer Security (TLS)-based secure channel. The transceiver (410) relays data exchange between the creator terminal (100), the validator terminal (300), and the blockchain network.

[0071] The memory (420) may be composed of volatile memory, non-volatile memory, or a combination thereof, and stores the following information: the original or summary of the Proof of Human Creator Token (PoHC) and related metadata, the Trust Anchor and certificate chain, the remote authentication policy and whitelist and rollback metric criteria, the Policy Profile including thresholds and weights, the audit log and statistics, and the application and configuration information. According to the embodiment, the memory (420) also stores the Application Programming Interface (API) key and access control information.

[0072] The processor (430) performs the functions of a management server by executing a program stored in memory. For example, the processor (430) parses PoHC tokens received through the transceiver (410), verifies digital signature and certificate chains, and checks the trustworthiness of Trusted Execution Environment Remote Attestation Evidence. It also stores capture metadata provided by the creator terminal and provides it as a lookup service, and creates and updates a policy profile containing thresholds and weights to be distributed to the validator terminal (300). If necessary, the processor (430) may interact with a blockchain network to record the summary value or chaining hash of the token or relay verification requests. Depending on the operational policy, it may cache temporary verification results in an offline environment and control delayed re-verification upon returning to the network.

[0073] The above configuration is merely an example for illustrative purposes. Depending on the embodiment, some configurations may be omitted, integrated, or added, and a single component may be implemented to perform two or more functions.

[0074] FIG. 5 illustrates an example of the operation process of a creator terminal according to various embodiments of the present invention.

[0075] FIG. 5 relates to an example of a method for verifying a human creator performed by a creator terminal. In the embodiment of FIG. 5, the creator terminal includes a front camera, a rear camera, an Inertia Measurement Unit (IMU), a Trusted Execution Environment (TEE), memory, a processor, and a transceiver.

[0076] Referring to FIG. 5, in step S501, the creator terminal simultaneously performs a session for capturing a creation target by the rear camera and a session for capturing the creator's face by the front camera.

[0077] In step S502, the creator terminal collects a sequence of acceleration or angular velocity of the IMU during a specific time window of a predetermined time length based on the shutter events of the rear camera and the front camera. The creator terminal sets a specific time window of a predetermined time length based on the shutter events of the rear camera and the front camera, and collects the sequence of acceleration and angular velocity of the Inertial Measurement Unit (IMU) within that time window. The time window is defined as a bilateral window before and after the shutter, and is adaptively set within a range of 50 milliseconds to 500 milliseconds depending on the shooting mode, focal length, exposure time, and frame rate. The creator terminal precisely synchronizes the camera timestamp and the IMU timestamp, performs a sampling period uniformity check, and masks sections where saturation or drop is detected to display them in the quality metadata. At the same time, it records the rolling shutter period, the Optical Image Stabilization (OIS) operation status, and exposure information to be used for calculating the sensor fusion matching index thereafter.

[0078] In step S503, the creator terminal calculates a feature vector from the sequence and calculates a first human behavior proof score by the processor based on the matching of the feature vector with one or more motion templates associated with a predetermined signature motion. The processor of the creator terminal calculates a feature vector from the collected IMU sequence, consisting of time domain mean and variance, energy and duration, frequency domain peak and spectral centroid, gesture tempo and phase, directionality index, gravity component separation index, etc. Then, the feature vector is matched with one or more motion templates of a pre-registered signature motion, and the matching technique may use one or more of Dynamic Time Warping (DTW), Hidden Markov Model (HMM), and deep learning embedding cosine similarity. The matching result is converted into a first human behavior proof score after normalization and outlier suppression, and the scale of the score is corrected by referring to the historical distribution accumulated in the user-specific personalization registration procedure, and weighted correction according to the environmental context is applied.

[0079] In step S504, the creator terminal generates Proof of Human Creator (PoHC) claim data by the processor by binding the face features obtained from the front camera, the frame hash of the rear camera, the timestamp within the specific time window, and the terminal identification security authentication information to the same sequence identifier. The processor of the creator terminal converts the face features obtained from the front camera into an irreversible feature summary for privacy protection, and generates Proof of Human Creator Claim Data (PoHC-claim data) by binding the frame hash of the rear camera, the high-resolution timestamp within the specific time window, and the terminal identification security authentication information under the same sequence identifier. The face feature summary can be expressed as a salt hash using a terminal-specific seed, or as a summary value based on secure embedding quantization or homomorphic encryption, and the timestamp includes a monotonic counter and a time of creation. The data structure is serialized into JavaScript Object Notation (JSON) or Concise Binary Object Representation (CBOR) and optionally includes location information, a liveness result summary, and chaining hash references.

[0080] In step S505, the creator terminal generates a PoHC-token by the processor by performing a digital signature on the PoHC-claim data in the TEE using the terminal-specific key. The processor of the creator terminal transmits the PoHC-claim data to the Trusted Execution Environment (TEE) to perform a digital signature using the terminal-specific key, and, if necessary, generates a Proof of Human Creator (PoHC-token) by including a Remote Attestation evidence summary, a certificate chain identifier, a patch level, and a monotonic counter value. In the case of video or continuous recording, a process history is formed by including a chaining hash that interconnects the PoHC-tokens at the start, checkpoint, and end points. The generated token is temporarily stored in a TEE protected repository or security element, and a nonce, session identifier, and expiration policy are recorded together to ensure freshness.

[0081] In step S506, the creator terminal transmits at least one of the frames captured by the rear camera and the front camera or the metadata of the frames and the PoHC-token to an external terminal or external network via the transceiver. Examples of an external device include, but are not limited to, the management server of FIG. 4, a validator terminal, a Time Stamping Authority (TSA), a public key infrastructure verification service, and a blockchain node; examples of an external network include, but are not limited to, the Internet, a cellular network, a wireless local area network, and a public or private configuration of a blockchain network. The creator terminal transmits at least one of the frames captured by the rear camera and the front camera (which may include original, re-encoded, keyframe, or thumbnail) or the metadata of the frames and the PoHC-token to an external terminal or external network via the transceiver. The transmission path is protected by a secure channel such as Transport Layer Security (TLS), and interoperability is ensured by inserting a PoHC summary into a custom namespace of the Coalition for Content Provenance and Authenticity (C2PA) manifest if necessary. In the event of network instability, data is stored in a secure queue and deferred transmission is performed according to a retransmission policy; acknowledgments, response codes, blockchain record identifiers, or management server receiving identifiers are logged to prepare for future verification and auditing.

[0082] In this specification, an External Device refers to a computing system that is separate from the Creator Device and performs one or more of the functions of storing, verifying, managing policies, publishing, or relaying PoHC tokens, and includes physical equipment or virtual instances, single devices or distributed systems, on-premises or cloud services. Examples of External Devices include, but are not limited to, Management Servers, Verifier Devices, Key Management Services, Time Stamping Authorities (TSAs), Public Key Infrastructure Verification Services (PKI OCSPs or CRLs), Content Source Registrys, and Blockchain Nodes. The External Device may be managed by the same or different trust domains as the Creator Device and by the same or third-party operating entities.

[0083] In this specification, the term "External Network" refers to a communication infrastructure that provides signal and data paths between a creator terminal, an external terminal, and a blockchain node, and includes, but is not limited to, wired or wireless internet, cellular networks (3GPP LTE, NR), wireless local area networks (WLAN, Wi-Fi), personal area networks (Bluetooth, etc.), satellite communication, peer-to-peer overlays, distributed ledger networks, and public or private and permissioned or permissionless configurations of blockchain networks. If necessary, time synchronization sources and trusted anchor distribution channels are considered part of the External Network.

[0084] Simultaneous capture and Inertial Measurement Unit (IMU)-based collection according to S501 to S503 physically bind the face capture from the front camera and the creative scene capture from the rear camera within a specific time window of a predetermined time length. Since a first human behavior proof score is calculated through time alignment based on shutter events and signature motion template matching, it provides strong separation against synthetic playback and screen re-capturing attacks that are difficult to distinguish with a single video signal alone, and enhances the directness of human creative acts by providing evidence of minute behavioral patterns such as actual human hand tremors or stopping after rotation.

[0085] The data binding and signature scheme according to S504 to S506 combines front face features, back frame hashes, timestamps within a time window, and terminal identification security authentication information into the same sequence identifier, and then digitally signs it with a terminal-specific key of a Trusted Execution Environment (TEE) to fix it as a Proof of Human Creator Token (PoHC). Accordingly, integrity and non-repudiation characteristics are secured from the time of creation to the time of transmission, and signature verification and sequence consistency verification are possible on an external terminal or external network, allowing a third party to independently and reliably determine whether it is a human creation.

[0086] According to various embodiments of the present invention, the specific time window is defined as a bilateral time window including before and after the shutter event, and the specific time window may be adaptively set in the range of 50 to 500ms based on at least one of a shooting mode, focal length, exposure time, or frame rate. The feature vector includes domain statistics of time and frequency, tempo, phase, directionality index, and gravity component separation index of the gesture, and the matching of the feature vector and the motion template may be based on Dynamic Time Warping (DTW), a Hidden Markov Model (HMM), or deep learning embedding cosine similarity. The motion template associated with the signature motion is obtained through a user-specific personalized registration procedure, and the first human behavior proof threshold associated with the first human behavior proof score may be updated based on the distribution of past behavior proof scores of the creator terminal. The above signature motion is defined as at least one of a wrist flick, double tap, and rotation-stop pattern, and the action proof score may be based on whether the energy, duration, or directionality of the sequence is within a predetermined range.

[0087] By setting a specific time window of a predetermined length as a dual window before and after the shutter event, and adaptively setting it within the range of 50ms to 500ms according to the shooting mode, focal length, exposure time, and frame rate, the clocks of the front capture, rear capture, and Inertial Measurement Unit (IMU) are aligned to the shooting situation. Consequently, individual differences in hand movement speed or timing deviations due to scene exposure conditions are absorbed, making it robust against time distortion and speed changes in the sequence, and feature vectors composed of time and frequency domain statistics, gesture tempo and phase, directionality, and gravitational component separation more richly capture human-specific fine motions. Furthermore, matching using one or more of Dynamic Time Warping (DTW), Hidden Markov Models (HMM), and Deep Learning Embedding Cosine Similarity evaluates the sequence from a complementary perspective, thereby improving detection sensitivity and robustness against tampering such as playback attacks and screen re-capture.

[0088] By combining signature motion templates obtained through personalized user registration with a first proof of human behavior threshold updated based on historical score distributions, individual habitual movement characteristics are reflected, enabling simultaneous reduction of misidentification rejection and suppression of misidentification acceptance. In particular, by adopting gestures such as wrist flicks, double taps, and rotation-stops, and evaluating whether the sequence's energy, duration, and directionality fall within a predetermined range, mechanical repetitive movements or unnatural patterns are effectively excluded while maintaining a low user input burden. As a result, the discriminative power and consistency of the first proof of human behavior score calculated at the terminal stage are enhanced, thereby improving the upper limit of the overall PoHC (Proof of Human Creator) confidence during subsequent signature binding and external verification stages.

[0089] According to various embodiments of the present invention, the embodiment of FIG. 5 may further include: a step of performing anti-spoofing verification for liveness using at least one of eye blinking, changes in lips or micro-expressions, depth mismatch, and screen replay detection for an image captured by the front camera; and a step of irreversibly converting face features into a salt hash using a terminal-specific seed, secure embedding quantization, or a homomorphic encryption-based summary value and including them in PoHC-claim data. The PoHC-claim data may have a field structure including a back frame hash, a face feature summary, a high-resolution timestamp within the specific time window, a device and firmware version, and optional location information. The digital signature may be configured to include a platform certificate chain and a security counter in the TEE to enable the detection of re-flash and rollback attacks. An embodiment of FIG. 5 may further include the step of forming a process history by attaching the PoHC token at frame-by-frame or designated intervals and adding a chaining hash to the session start, intermediate checkpoint, and end frames when the creation target is a video.

[0090] Liveness anti-spoofing verification of front camera footage and irreversible summarization of facial features simultaneously reduce tampering and privacy risks. By combining one or more of eye blinking, micro-expression changes, depth mismatch, and screen playback detection, playback attacks and screen capture are excluded early. Furthermore, the possibility of leakage of original biometric data is minimized by converting facial features into a salt hash using a terminal-specific seed, secure embedding quantization, and homomorphic encryption-based summary value. Additionally, by bundling PoHC-claim data (Proof of Human Creator Claim Data) into a structured field structure consisting of a back-frame hash, facial feature summary, high-resolution timestamp, device and firmware version, and optional location information, item-by-item cross-checking is possible during subsequent verification steps, thereby increasing reliability and reproducibility.

[0091] Since digital signatures are performed in a Trusted Execution Environment (TEE) including a Platform Certificate Chain and a Security Counter, terminal re-flashing, rollback, and token replay attacks can be detected solely through signature verification. When the subject of creation is a video, PoHC tokens are attached at the frame level or at specified intervals, and a process history is formed by connecting the session start, intermediate checkpoint, and end frame with a Chaining Hash. This allows for the tracking of temporal continuity and causality even after post-processing such as editing, resizing, or re-encoding. As a result, integrity at the time of terminal creation and the detection of manipulation during the post-verification stage are simultaneously guaranteed, significantly improving the reliability and legal and practical utility of determining whether the work was created by a human.

[0092] According to various embodiments of the present invention, the embodiment of FIG. 5 may further include: a step of detecting a synthetic attack or a replay attack through an IMU-video sensor fusion consistency check and including a warning flag in the PoHC token in case of a discrepancy; a step of verifying that the IMU may be collected from a wearable device connected to the terminal in addition to the terminal, and that the timestamp synchronization between the terminal and the wearable device is within the tolerance of the specific time window; and a step of switching to at least one alternative identification feature among palm vein, finger joint pose, or voice short segment in a situation where face identification is not possible.

[0093] By verifying the consistency of Sensor Fusion between the Inertial Measurement Unit (IMU) and the video, it is confirmed whether the back capture, front capture, and IMU sequence are physically aligned within a specific time window of a predetermined length, thereby enabling early detection of synthesis and playback attacks. If a warning flag is included in the Proof of Human Creator (PoHC) in the event of a consistency violation, the verifier terminal can immediately reflect the danger signal along with signature verification to lower the trust score, resulting in a reduction in the acceptance of false positives and an improvement in the feasibility of forensic audits. Furthermore, when the IMUs of the terminal and the wearable device are used together, it is verified that the timestamp synchronization between the two devices is within the tolerance of a specific time window; this strengthens the causal link between the creator's actual body movements and the recording event, significantly reducing the possibility of forgery through reenactment or proxy recording.

[0094] Automatic switching to alternative identification features such as palm veins, finger joint poses, and short voice segments in environments where facial identification is difficult enhances resilience in failure modes. Since these alternative features are bound to the same sequence identifier and included in PoHC, a continuous chain of evidence is maintained even in situations where full-face capture is limited due to lighting, mask usage, or missing frames. Consequently, the system simultaneously improves coverage and real-world reliability by covering various field conditions and user constraints while maintaining tamper detection sensitivity.

[0095] Examples of conditions for switching to Alternate Identification Mode are as follows. The Policy Engine switches to Alternate Identification Mode when front camera-based face recognition is deemed unreliable—specifically, when one or more of the following are detected: a Liveness score below a threshold, a decrease in face detection reliability, occlusion or mask wearing, insufficient illumination, severe motion blur, inability to use the camera, disabling due to privacy settings, or failure to meet legal or age consent requirements. Upon switching, while maintaining the sequence identifier of the same session, priority is given to Finger Joint Pose, Short Voice Segment, or Palm Vein, whichever best aligns with available sensors and privacy settings. The example priority order is Finger Joint Pose, Short Voice Segment, and Palm Vein; however, Palm Vein may be activated if the terminal supports necessary hardware, such as near-infrared. Each Alternate Identification feature is subjected to its own Liveness or tamper detection procedures, and the reason for the switch and the type of feature applied are recorded in a reason code and summarized in the PoHC token. When front face confidence is restored, the policy engine automatically returns to default mode and processes subsequent frames in default mode.

[0096] Examples of conditions and priorities for wearable cooperative collection are as follows. Wearable cooperative collection is enabled in cases of Inertial Measurement Unit (IMU) signal degradation, sampling interval drops, saturation, or when creative actions primarily occur on the wrist or stylus while the smartphone is stationary. IMU sequences from wearables, such as smartwatches or styluses, are combined with the smartphone only when the time difference error within a specific time window of a predetermined length is below an acceptable range; if it exceeds the acceptable range, the weights are downscaled, the combination is rejected, or a mismatch flag is set. The confidence weight is increased only if the wearable provides evidence of Remote Attestation; in the absence of such evidence, it is used only as a secondary signal. The final sensor fusion is weighted and combined using the smartphone IMU as the primary signal and the wearable IMU, whose synchronization compatibility has been verified, as a secondary signal. If the deviation between the directionality or energy indicators of the two signals exceeds a threshold, the Human Attestation score is deducted, and a warning flag is included in the PoHC. By doing so, a balance of tamper detection sensitivity, privacy, and operational flexibility is secured while maintaining the causal link between body movements and shooting events even under complex field conditions.

[0097] According to various embodiments of the present invention, the metadata may be a C2PA Manifest (Coalition for Content Provenance and Authenticity Manifest). An embodiment of FIG. 5 may further include the step of inserting the PoHC-token into a custom claim namespace of the C2PA Manifest to perform a cross-validation routine with standard claims. To enable inverse mapping with the original PoHC-token even after editing, resizing, and re-encoding of the frames, the PoHC-token may additionally include a thumbnail fingerprint or a fixed-length summary.

[0098] By operating metadata as a Coalition for Content Provenance and Authenticity (C2PA) manifest, inserting a Proof of Human Creator (PoHC) token into a Custom Claim Namespace, and performing a cross-verification routine with a Standard Claim, the evidence structure of the present invention becomes directly compatible with the C2PA ecosystem. As a result, existing editors and verification tools can verify standard metadata such as signature chains, edit history, and device characteristics together with PoHC-specific evidence, thereby increasing the possibility of independent verification by a third party, reducing inter-system integration costs, and facilitating the indication of trustworthiness and audit trails during the distribution process.

[0099] Adding a thumbnail fingerprint or fixed-length digest to a PoHC token enables reverse mapping to the original token even after frame editing, resizing, or re-encoding, thereby preserving source continuity. This means that even if metadata is partially removed or transformed during the platform upload process, the original evidence and its derivatives can be linked through visual similarity fingerprints and hash summaries, making it easier to detect tampering and prove legitimate lineage in the event of a post-dispute, which significantly enhances legal and practical utility.

[0100] The Proof of Human Creator (PoHC) of the present invention can be implemented as a custom assertion inserted into the Custom Claim Namespace of the C2PA manifest. The assertion identifier is defined, for example, as urn:poHC:1, and the payload is encoded in JavaScript Object Notation (JSON) or Concise Binary Object Representation (CBOR). During verification, the capture device information, edit history, and signature chain included in the Standard Assertion of C2PA are cross-verified with the PoHC custom assertion of the present invention to confirm temporal consistency, physical consistency, and trust anchor matching among evidence generated in the same session. If necessary, the PoHC token itself is stored separately with a COSE signature (CBOR Object Signing and Encryption, COSE) or JSON Web Signature (JWS), and only the summary hash and reference of the token are recorded in the C2PA assertion to minimize file size increase and exposure of personal information.

[0101] An example of a custom namespace field structure can be defined as follows. Required fields: pohc_token_digest (PoHC token hash, 86-character Base64 URL based on SHA-512, no padding), frame_hash (back frame hash, 44-character Base64 URL based on SHA-256), face_feature_digest (irrecoverable face feature summary, 32-byte fixed-length lowercase hexadecimal), timestamp_window (a specific time window of a given length, integer range of 50–500 in milliseconds), device_id (device identifier, 8–64 alphanumeric characters), firmware_version (firmware version string, e.g., MAJOR.MINOR.PATCH), attestation_summary (TEE remote authentication evidence summary, nonce_echo Base64 URL of 32–64 characters, patch_level YYYY-MM, including monotonic_counter unsigned 64-bit integer). Optional fields: location (location summary and precision level, precision is one of none city region), thumbnail_fingerprint (thumbnail fingerprint, fixed 16-byte hexadecimal), edit_history_ref (edit history reference, URI format), chaining_hash (chaining hash, SHA-256 Base64 URL 44 characters), wearable_sync_ok (wearable sync compliant, boolean). All strings use UTF-8, and length and format constraints are specified in the assertion schema. Using this structure enables backmapping to the original PoHC token and step history verification via thumbnail_fingerprint, pohc_token_digest, and chaining_hash even after frame editing, resizing, and re-encoding, and allows the unique proof fields of the present invention to be securely transmitted while maintaining interoperability with the standard C2PA tool suite.

[0102] According to various embodiments of the present invention, a creator terminal is provided that includes a front camera, a rear camera, an Inertia Measurement Unit (IMU), a Trusted Execution Environment (TEE), a memory, a processor, and a transceiver, wherein the processor is operably coupled to the transceiver and the memory, and the processor is configured to perform a method, and the method includes a method of operation of the creator terminal according to the embodiment of FIG. 5.

[0103] According to various embodiments of the present invention, a non-transitory computer-readable storage medium having stored thereon instructions that, when executed by at least one processor, cause the at least one processor to perform operations is provided, wherein the operations include a method of operation of a creator terminal according to the embodiment of FIG. 5.

[0104] FIG. 6 illustrates an example of the operation process of a verifier terminal according to various embodiments of the present invention.

[0105] FIG. 6 relates to an example of a method for verifying a human creator performed by a verifier terminal. In the embodiment of FIG. 6, the verifier terminal includes an input device, an output device, a transceiver, a memory, and a processor.

[0106] Referring to FIG. 6, in step S601, the validator terminal receives, via the transceiver, at least one of frames captured with respect to the face of the creator and the creator, or metadata of said frames, and a PoHC (Proof of Human Creator) token corresponding to said frames from an external terminal or an external network. Examples of external devices include, but are not limited to, the management server of FIG. 4, the validator terminal, the Time Stamping Authority (TSA), the Public Key Infrastructure Verification Service, and the blockchain node, and examples of external networks include, but are not limited to, the Internet, cellular networks, wireless local area networks, and public or private configurations of blockchain networks. A validator terminal receives, via a transceiver, at least one of captured frames (which may include originals, re-encoded images, keyframes, or thumbnails) or metadata of said frames, and a Proof of Human Creator (PoHC) corresponding to said frames, captured with respect to the faces of the creation subject and the creator from an external terminal (e.g., a management server) or an external network. The transmission channel is protected by Transport Layer Security (TLS) as necessary, and the metadata may include a capture device identifier, shooting parameters, a high-resolution timestamp, and an optional Coalition for Content Provenance and Authenticity (C2PA) manifest. Upon reception, the validator terminal performs a primary check for message integrity, duplicate reception, and session identifier match, and securely loads the data into a queue or buffer for subsequent processing.

[0107] In step S602, the validator terminal parses the PoHC token to extract the frame hash of the creator terminal's rear camera, the creator's facial feature summary, and the timestamp within a specific time window of a predetermined length by the processor. The processor of the validator terminal parses the structure of the PoHC token according to the schema to extract the creator terminal's rear camera frame hash, the facial feature summary, and the timestamp within a specific time window of a predetermined length. At this time, the hash and feature summary are verified for encoding format (JSON or CBOR, etc.) and length constraints, and the timestamp is checked for net increment based on a monotonic counter and for inclusion within the session boundary. If necessary, preprocessing such as Base64url decoding, endian normalization, and field existence checks is performed, and if a missing field is found, a conservative replacement value is set according to the policy or a warning flag is raised in a subsequent step.

[0108] In step S603, the validator terminal verifies the digital signature and certificate chain of the PoHC-token, and the processor verifies the Trusted Execution Environment (TEE) Remote Attestation Evidence and security patch level whitelist conformity of the creator terminal included in the PoHC-token. The processor of the validator terminal verifies the digital signature and certificate chain of the PoHC-token to determine whether the token has been tampered with, and verifies the Trusted Execution Environment (TEE) Remote Attestation Evidence of the creator terminal included in the token. This includes verifying the chain to the platform root, checking for a match in the key identifier allowlist, satisfying minimum criteria for the patch level, checking for the absence of a Monotonic Counter reversal, and validating the freshness indicator. Subsequently, it determines the conformity of the allowed firmware and security patch level by comparing it with the whitelist registered in the policy, and summarizes the result as a security counter state.

[0109] In step S604, the verifier terminal verifies the concurrency within the specific time window between face capture based on the front camera of the creator terminal, capture of the creation target via the rear camera, and data collection by the Inertia Measurement Unit (IMU) of the creator terminal, checks the allowable range of time synchronization error, and examines the monotonic counter rollback or replay window by the processor. The processor of the verifier terminal precisely verifies whether the operations between the front camera-based face capture, the rear camera-based creation target capture, and the Inertia Measurement Unit (IMU) data collection of the creator terminal exist within the specific time window in the same session. It aligns the front and rear shutter timelines, checks if the time difference with the sample timestamp of the IMU sequence is within the allowable error, and examines for signs of a rollback or replay window based on the correlation consistency between the system time and the monotonic counter. If the allowable error is exceeded or the counter stagnates or reverses, the corresponding reason code is recorded, and a deduction or warning flag is reflected during score calculation in subsequent steps.

[0110] In step S605, the validator terminal performs a sensor fusion consistency check, calculates a consistency index between rolling shutter parameters, Optical Image Stabilization (OIS) operation, exposure time, frame timing, and the IMU sequence, and sets a warning flag by the processor in the event of a discrepancy. The processor of the validator terminal calculates the consistency index by evaluating the physical alignment between the rear camera's rolling shutter parameters, the OIS operation status, exposure time, frame timing, and the IMU sequence. Specifically, it models the expected image change between frames using camera motion predicted by the IMU, and calculates the reprojection error corrected by actual capture parameters, the time delay estimate, and the consistency of the directional index. If the index falls below a threshold or the discrepancy persists, a warning flag is set, and the flag is subsequently reflected as a danger signal in the policy engine's weighted combination.

[0111] In step S606, the validator terminal calculates a second human behavior proof score by combining (i) the anti-spoofing verification result for liveness, (ii) the consistency indicator, and (iii) the security counter state of the PoHC-token based on the weights of the policy engine, and the processor determines whether it is a human creation by comparing the second human behavior proof score with the second human behavior proof threshold. The processor of the validator terminal calculates the second human behavior proof score by combining the liveness anti-spoofing result, the consistency indicator, and the security counter state with weights defined in the policy engine. The calculated score is compared with a pre-corrected second human behavior proof threshold; if it is above the threshold, it is determined to be a human creation, and if it is below the threshold, it is classified as rejected or pending. All input values, weights, intermediate indicators, final determinations, and reason codes are recorded in the audit log to support post-verification and reproducibility, and subsequent processing is performed via user interface output or external system notification if necessary.

[0112] In step S607, if the verifier terminal determines that the second human behavior proof score is greater than or equal to the second human behavior proof threshold, the processor generates a confirmation result that the creation target is indeed a human creation.

[0113] In step S608, the verifier terminal outputs the verification result via the output device, or transmits the verification result to the external terminal or the external network via the transceiver.

[0114] The procedures of S601 through S605 securely isolate the Proof of Human Creator (PoHC) and metadata received from an external terminal or external network through digital signature and certificate chain verification, and then objectify the device trust status by verifying the Remote Attestation Evidence of the Trusted Execution Environment (TEE) and the conformity of the security patch level whitelist. Additionally, it checks the concurrency within a specific time window of a predetermined time length between the front capture, the back capture, and the Inertial Measurement Unit (IMU) collection, the tolerance range for time synchronization errors, and whether the monotonic counter is rolled back or replayed. Furthermore, through Sensor Fusion consistency checks, the physical alignment of Rolling Shutter, Optical Image Stabilization (OIS), exposure time, frame timing, and IMU sequences is quantified, and warning flags are set in the event of discrepancies to identify reshooting, synthesis, and playback attacks at an early stage. This ensures multi-layered reliability anchors, temporal alignment, and physical alignment within the verification path, significantly enhancing the sensitivity of forgery detection and the evidentiary value of the data.

[0115] Procedures S606 through S608 calculate a second human behavior proof score by combining liveness anti-spoofing results, consistency indicators, and security counter states as weights in the Policy Engine, and automatically determine whether the content was created by a human by comparing it to a predefined threshold. The verification result generated when the score exceeds the threshold can be immediately utilized as a user interface output or external transmission, facilitating service integration; furthermore, the structured logs and indicators make it suitable for subsequent audits and reproducibility verification. Consequently, this procedure achieves operational objectives by reducing false passes and mitigating false rejections, while simultaneously providing deterministic determinations verifiable independently by a third party and traceable audit records.

[0116] In this specification, a Policy Engine refers to policy evaluation logic configured to calculate a human behavior proof score and judgment by combining inputs such as liveness results, sensor fusion consistency indicators, and security counter states, and may be implemented in one or more of hardware circuits, firmware, or software in which a processor executes instructions stored in memory. The Policy Engine may include configurable rules, thresholds, weights, statistical models, or machine learning models.

[0117] According to various embodiments of the present invention, the anti-spoofing verification result may be based on a liveness score calculated based on a face image segment obtained from a front camera or a face-related evidence field included in a PoHC token. The liveness score may be calculated by combining two or more of: (i) the temporal rate of change and optical flow patterns of blinking, lips, or microexpressions; (ii) continuity of depth, continuity of infrared (IR), continuity of stereo parallax, presence of remote photoplethysmography (rPPG) signals, and frequency band compatibility; (iii) detection of periodic banding and moiré in screen playback; and (iv) mutual alignment of 3D face landmark-based head pose and IMU-based rotation and translation. The security counter status can be calculated by extracting monotonic counters, patch levels, key identifiers, and freshness information from the TEE remote authentication evidence of the PoHC token, and determining rollback, replay, and whitelist suitability. The second human behavior proof score is calculated by weighted combination of the liveness score, the consistency indicator, and the security counter status, and the weights can be configured by the policy engine. The second human behavior proof threshold can be set by the policy engine to evaluate the score distribution obtained by combining the liveness score, the consistency indicator, and the security counter status based on a labeled correction dataset, and to satisfy at least one objective among the False Acceptance Rate (FAR), Equal Error Rate (EER), or F1 score optimization.

[0118] Temporal rate of change is an indicator representing how much, how quickly, and in what direction eyelids, lips, and micro-expressions deform between frames. For example, values ​​such as the opening and closing speeds and durations of blinks, the opening and closing cycles and displacement of lips, and the degree of fine muscle deformation in micro-expressions fall into this category. Typically, inter-frame displacement of facial landmark locations, temporal changes in region brightness or texture, and the velocity and acceleration of displacement are calculated and used as characteristics. These natural micro-dynamics serve as liveness clues that distinguish the image from synthesized video or still images.

[0119] Optical flow is a motion vector field that represents the amount and direction of movement of each pixel between two consecutive frames. In real faces, complex, localized, and non-rigid flows appear around the eyelids and corners of the mouth, accompanied by radial or rotational components combined with head rotation or translation. In contrast, forgeries, such as screen reproductions or printed materials, primarily exhibit a monotonous flow where the entire screen moves in one direction almost like a rigid body, lacking local deformation patterns associated with micro-expressions. Therefore, evaluating the temporal rate of change and optical flow patterns together allows for the differentiation between real facial movements and reproduced images with high reliability.

[0120] Depth continuity refers to examining whether depth maps or estimated distance values ​​flow naturally from frame to frame and change reasonably according to head movement. In the case of a real 3D face, the distance relationship between the nose and cheeks changes consistently over time when the head is turned slightly. On the other hand, flat forgeries such as screen playback or printed materials have nearly constant depth or unnatural patterns of change.

[0121] IR continuity verifies whether the reflection patterns of a face viewed by an infrared camera or infrared illumination-based sensor appear natural over time and whether the response to changes in lighting resembles real skin. Flat screens or masks exhibit poor temporal consistency because their infrared reflection characteristics differ from those of skin.

[0122] The continuity of stereo parallax refers to whether the disparity of the face in images obtained from left and right cameras continues without interruption from frame to frame and changes smoothly in accordance with head movements. In the case of a real 3D object, the disparity varies by position and changes smoothly over time, but in the case of a planar forgery, the disparity is poor or distorted.

[0123] The presence of rPPG (Remote Photoplethysmography) signals and frequency band compatibility involves examining whether remote photoplethysmography signals are detected in subtle skin color variations within a frontal image and whether their frequencies fall within the normal range corresponding to a human heart rate. In a real human face, periodic subtle color changes appear in areas such as the eyes or cheeks, and the energy of these frequency components is concentrated in the typical heart rate band. In forged images or screen replays, this signal is either absent or obscured by noise, and even if present, the frequency band is highly likely to be unnatural. By combining the temporal continuity of depth, IR, and stereo parallax with the presence and band compatibility of rPPG, it is possible to detect synthesis or replay attacks with high reliability.

[0124] A screen refresh attack refers to a situation where video or images being played on another display are captured again with a camera, and the typical artifacts that appear in this case are periodic banding and moiré. Periodic banding is a phenomenon in which regular streaks of brightness appear across the entire or part of the screen as they flicker over time due to mutual interference between the display refresh rate, the backlight's pulse width modulation (PWM), and the camera's exposure and rolling shutter. Moiré is an artificial pattern generated by the interference between the display's subpixel grid, the camera sensor's pixel grid, and the color filter array; it is a phenomenon in which unnatural wavy or comb-like patterns are spatially repeated in an image.

[0125] Periodic banding and moiré detection are typically performed by combining time-domain and spatial-frequency-domain analysis. In the time domain, brightness signals from the face and background regions are extracted, and techniques such as the Fast Fourier Transform (FFT) are used to determine whether specific energy peaks persist near refresh rates—such as 50, 60, 90, and 120 Hz—and at their harmonics. In the spatial domain, edge maps and frequency spectra are analyzed to evaluate whether narrow-band periodic patterns with a specific directionality are widely distributed, and whether the pattern period and direction remain stable aligned with the display grid even with camera movement or zoom changes. To minimize confusion with natural causes such as lighting flickering or fabric patterns, cross-checking for the simultaneous occurrence of identical patterns on diffuse surfaces like facial skin, along with verifying exposure time, frame timing, and alignment with IMU signals, allows for the identification of periodic banding and moiré patterns unique to screen playback with high reliability.

[0126] The mutual alignment of 3D face landmark-based head pose and IMU-based rotation and translation is a procedure that checks whether the 3D face landmark-based head pose trajectory calculated from the front camera image and the angular rotation and translation trajectory measured by the terminal's Inertial Measurement Unit (IMU) are consistently explained by aligning them to the same coordinate system and time axis within a specific time window of a predetermined time length. Face landmarks are detected for each front camera frame, and the 3D pose (yaw, pitch, roll) of the face and its relative position to the camera are obtained through Perspective-n-Point (PnP) estimation using camera intrinsic parameters. At the same time, the camera's rotation and translation trajectories are obtained by integrating and filtering the IMU's gyroscope and acceleration data within the time window. After performing extrinsic calibration and timestamp synchronization between the camera coordinate system and the IMU coordinate system, predict how the relative pose of the face should change when the camera actually moves in this way, and check if the residual is small and highly correlated with the head pose change observed in the video.

[0127] Matching evaluation is performed using the following indicators as an example. First, it is checked whether the correlation coefficients and sign match of the yaw, pitch, and roll angular velocities, and the cross-correlation peaks for delay correction, are above a threshold. Second, it is verified whether the landmark reprojection error generated by camera motion predicted by the IMU is below a threshold. Third, excessive or unnatural relative motion is blocked by applying physical range constraints on head pose changes relative to the amount of rotation. Fourth, matching indicators such as Dynamic Time Warping (DTW) are used as auxiliary indicators to account for minute misalignments along the time axis. If this matching is good, it is determined that the actual movement of the terminal and the relative movement of the face in the video physically match, increasing the likelihood of live recording; conversely, if there is a misalignment, it can warn of potential tampering, such as screen playback or composite rearrangement.

[0128] To determine the security counter status, several values ​​are extracted from the Remote Attestation Evidence of the Trusted Execution Environment (TEE) included in the PoHC token and verified. Based on these values, the rollback status, replay status, and whitelist suitability are determined to produce the final state. In other words, the trust level or flag is determined by mechanically checking whether the device where the token was generated is in the latest security state, whether it has not been exploited by reverting to a past state, and whether evidence that has already been used has been reused.

[0129] The meaning of each term is as follows.

[0130] Monotonic Counter: A hardware or TEE-protected counter capable of only incrementing. If the current value is smaller than a previously seen value, it is a sign of a rollback, and if the same value is repeated abnormally, it raises suspicion of a potential rollback.

[0131] Patch Level: This refers to the level at which security patches are applied to device firmware or the operating system. Example formats are YYYY-MM or MAJOR.MINOR.PATCH. If the level falls below the minimum required by the policy, it is considered non-compliant.

[0132] Key Identifier (Key ID): A value that identifies the device-specific key used by the TEE for signing. It is rejected if the key ID is not on the allowlist or is a revoked key ID. It is used for key rotation or revocation management.

[0133] Freshness Information: These are one-time indicators designed to prevent reuse, such as challenge value nonces, creation timestamps, and session binding values. If the nonce echo is inconsistent or the expiration time is exceeded, it is considered to be replayed.

[0134] Rollback: An attack that generates a token after reverting to vulnerable past firmware or a past state. It is detected by decreasing the monotonic counter, dropping the patch level, or inconsistencies in measured boot values.

[0135] Replay: An attack that resubmits tokens or authentication evidence that were valid in the past. It is detected through nonce mismatches, duplicate token summary hashes, and counter identities.

[0136] Whitelist Compliance: This is a procedure to verify whether the attestation attribute matches the list of allowed device models, TEE vendor versions, key IDs, minimum patch levels, etc. If they do not match, they are flagged as non-compliant.

[0137] In summary, the validator reads monotonic counters, patch levels, key identifiers, and freshness information from the TEE remote authentication evidence, compares them against the policy, and summarizes the results into security counter states to score them or set warning flags. These calculated states are reflected as weights in the final human behavioral proof score.

[0138] Calculation of Second Human Behavior Proof Score and Composition of Weights: The validator terminal normalizes the liveness score, consistency metric, and security counter state to confidence levels ranging from 0 to 1. The liveness score is the confidence level for anti-spoofing judgments based on the front-facing image. The consistency metric is the confidence level for concurrency and physical alignment between the front-facing capture, the back-facing capture, and the Inertial Measurement Unit (IMM) signal. The security counter state is the confidence level for the device trust signal based on remote authentication evidence from the secure execution environment. The Policy Engine configures weights for the three confidence levels according to the profile and calculates the Second Human Behavior Proof Score by combining the three confidence levels with the configured weights. Weights can be set differently based on factors such as service risk level, device and operating system profiles, environmental context illumination, face-to-camera distance, and temporal synchronization quality, and are subject to governance constraints such as minimum and maximum weights and importance rankings. If some inputs are missing, the Policy Engine applies predefined conservative substitutions or temporarily downscales the corresponding weights; if two or more key inputs are missing, the result is withheld or escalated to a manual review. All decisions and weights used are recorded in the audit log.

[0139] Procedure for Setting Second Human Behavior Proof Thresholds: The policy engine sets thresholds using a labeled remediation dataset. The remediation dataset includes abnormal cases such as normal creations by humans, synthetic attacks, and replay attacks. First, the liveness score, consistency indicator, and security counter status are calculated from the dataset in the same manner, and the Second Human Behavior Proof score is obtained using the aforementioned weighting configuration. Next, the score distribution is evaluated to select a threshold that aligns with the operational objective. If the False Acceptance Rate (FAR) objective is selected, the threshold is set to the minimum score value at which the rate of attack samples passing through is below the target value. If the Equal Error Rate (EER) objective is selected, the threshold is set to the intersection point where the False Acceptance Rate and the False Rejection Rate are equal. If the F1 score optimization objective is selected, the threshold is set to the point where the harmonic mean of precision and recall is maximized. The selected thresholds are stored separately by device and operating system profiles or service risk tiers and may be slightly adjusted based on runtime contexts such as illumination, face-to-camera distance, and time synchronization quality. The policy engine periodically checks for performance drift, recalibrates it if necessary, and stores the threshold values ​​and performance indicators before and after recalibration along with the version.

[0140] The liveness score, calculated based on a face image segment acquired from the front camera or the face-related evidence field of the PoHC token, enhances detection sensitivity against synthesis and playback attacks by combining two or more of the following: the temporal rate of change of eye blinks, lips, and micro-expressions and optical flow patterns; the continuity of depth, infrared, and stereo parallax, or the presence and band suitability of Remote Photoplethysmography (rPPG) signals; the detection of periodic banding and moiré unique to screen playback; and the mutual alignment of 3D face landmark-based head poses with IMU rotation and translation. At the same time, monotonic counters, patch levels, key identifiers, and freshness information are extracted from remote authentication evidence of the Trusted Execution Environment (TEE) to determine rollback, playback, and whitelist suitability, thereby objectively ensuring the device's trust status, and the spoofing detection signal and the security status signal complement each other, significantly improving robustness against forgery.

[0141] The Policy Engine calculates a Second Human Behavior Proof score by weighting the liveness score, Sensor Fusion consistency indicators, and security counter states. By utilizing the distribution of the labeled remediation dataset to set the Second Human Behavior Proof threshold to satisfy False Acceptance Rate (FAR), Equal Error Rate (EER), or F1 score optimization goals, the operational point between service risk and user experience can be precisely adjusted. As a result, judgment consistency and reproducibility are enhanced regardless of the environment or device. Furthermore, by numerically guaranteeing the target security level while enabling policy-based management of the balance between false passes and false rejections, it is advantageous for both operational practice and post-audits.

[0142] According to various embodiments of the present invention, the embodiment of FIG. 6 may further include: a step of performing original comparison reconstruction using a token chain, a thumbnail fingerprint, and an edit history field when the metadata is partially missing; and a step of verifying the TEE remote authentication evidence to determine the suitability of the allowed firmware and security patch level whitelist.

[0143] Even if some metadata is missing, source continuity is maintained by performing reconstruction against the original using Token Chain, Thumbnail Fingerprint, and Edit History fields. Causal relationships between stages are restored using chaining hashes, and the combination of visual similarity-based thumbnail fingerprints and edit history enables the inverse mapping of original evidence and derivatives even after transformations such as resizing, re-encoding, and cropping. As a result, verification failures caused by metadata stripping or format conversion are reduced, and integrity and consistency can be reconfirmed based on process history in the event of a subsequent dispute, thereby improving practical reliability and auditability.

[0144] By determining the compliance of firmware and security patch level whitelists through Trusted Execution Environment (TEE) Remote Attestation Evidence, the trust status of the device at the time of shooting can be objectively guaranteed. Specifically, by verifying certificate chains, monotonic counters, patch levels, key identifiers, and freshness information, rollback or playback attacks are excluded, and firmware and security levels that do not conform to the whitelist are automatically rejected. As a result, the verification pipeline blocks the inflow of evidence of tampering in advance, and compliance and policy enforcement are managed numerically, reducing the risk of false passing and increasing legal and operational efficiency.

[0145] According to various embodiments of the present invention, a verifier terminal comprises a front camera, a rear camera, an Inertia Measurement Unit (IMU), a Trusted Execution Environment (TEE), a memory, a processor, and a transceiver, wherein the processor is operably coupled to the transceiver and the memory, and the processor is configured to perform a method, wherein the method includes a method of operation of the verifier terminal according to the embodiment of FIG. 6.

[0146] According to various embodiments of the present invention, a non-transitory computer-readable storage medium having stored thereon instructions that, when executed by at least one processor, cause the at least one processor to perform operations is provided, wherein the operations include a method of operation of a verifier terminal according to the embodiment of FIG. 6.

[0147] FIG. 7 illustrates exemplary steps of a creation process according to various embodiments of the present invention.

[0148] FIG. 7 illustrates exemplary steps of a creative process according to various embodiments of the present invention. The illustrated example represents four steps proceeding from left to right: a motivation cut, a concept sketch, a detailed drawing, and a finished design. Each arrow illustrates a transition of steps over time, and the number, names, and order of the steps may be changed according to the embodiment. In each step, the creator terminal photographs the subject of creation with a rear camera and photographs the creator's face with a front camera, and collects an Inertial Measurement Unit (IMU) sequence for a specific time window of a predetermined length based on a camera shutter event. The collected information is bound and signed in a Trusted Execution Environment (TEE) and can be generated in each step as a Proof of Human Creator (PoHC) token.

[0149] The motivation cut stage represents the starting point of creation, such as rough shapes or reference poses. The frame hash, facial feature summary, and timestamp generated in this stage are bound to the same sequence identifier, and a primary PoHC token is formed through TEE signature. Facial features may be processed into irreversible summary values ​​for privacy protection. Liveness and anti-spoofing verification may be performed on the frontal image.

[0150] In the concept sketch stage, form and proportions are refined. The creator terminal verifies the simultaneity of front-side and back-side captures and IMU sequences, and can calculate the terminal-side first human action proof score through matching with signature motions. The PoHC token in this stage may include the summary value of the token from the previous stage in the form of a chaining hash, providing a causal link with the previous stage.

[0151] The detailed drawing stage represents the section where textures or fine line processing are performed. When continuous shooting is performed, PoHC tokens are generated at the start, checkpoint, and end points, respectively, and each token is linked to others via a chaining hash to form a process history. The consistency of Optical Image Stabilization (OIS) operation, exposure time, frame timing, and IMU sequence is utilized as an indicator of sensor fusion consistency in subsequent verification.

[0152] The final design phase represents the final deliverable and forms the endpoint of the phase chaining. If necessary, PoHC-specific claims can be inserted into a manifest in the Coalition for Content Provenance and Authenticity (C2PA) format, and a thumbnail fingerprint or fixed-length summary can be included to enable reverse mapping to the original token even after editing or resizing. The final summary information can optionally be recorded on a blockchain network.

[0153] Each step of Fig. 7 is not limited to a specific genre. It can be applied to various creative works such as photography, video production, illustration, commercial design, document creation, and audio production, and the steps may be further subdivided, or some steps may be integrated or omitted. For example, in the case of real-time performance recording, tokens can be continuously generated for multiple short segments using the same procedure.

[0154] In an embodiment where a wearable sensor is used, the IMU sequence of the wearable can be time-synchronized with the creator terminal and combined within the tolerance range of a specific time window. In an offline environment, the step PoHC token can be temporarily stored inside the terminal and then transmitted to an external system upon network recovery to perform delayed registration.

[0155] During the verification phase, the validator terminal receives the PoHC token and metadata corresponding to each phase to verify the signature and certificate chains, and examines the Remote Attestation Evidence (TEE). Subsequently, it verifies the concurrency of front-end and back-end captures and IMU collection, as well as sensor fusion consistency. It then combines the liveness results and security counter states with weights defined in the policy to calculate a Human Attestation Score, which is compared to a threshold to determine whether the content was created by a human. These verification results can be visualized step-by-step or for the entire chaining, or transmitted to an external system.

[0156] In summary, Figure 7 shows that evidence generated at each key point in the creation process is accumulated step-by-step as PoHC tokens and linked by a chaining hash, explaining that this allows for the reliable proof of the causal relationship between the final result and each intermediate step.

[0157] FIG. 8 shows an example of a scene in which a creative subject is photographed using a rear camera of a creator terminal according to various embodiments of the present invention.

[0158] FIG. 8 illustrates an example of a scene in which a creative subject is photographed using a rear camera of a creator terminal according to various embodiments of the present invention. In some embodiments, the shooting of FIG. 8 is performed simultaneously with the front shooting of FIG. 9.

[0159] The rear camera acquires a frame of the creative subject, and the shutter event at the time of shooting serves as a standard for defining a specific time window of a predetermined length. The Inertial Measurement Unit (IMU) of the creator's terminal collects sequences of acceleration and angular velocity in the intervals before and after this time window. During collection, operating parameters of the rear camera, such as the frame timing of the rolling shutter, optical image stabilization (OIS) operation, exposure time, and focal length, are recorded together and can be used later for sensor fusion consistency verification.

[0160] The frame hash calculated from the backframe, the high-resolution timestamp within the time window, and the terminal identification information are bound to the sequence identifier of the same session. At this time, the Trusted Execution Environment (TEE) inside the terminal signs the bound data using a terminal-specific key and generates Remote Attestation Evidence (REE) as needed. The data thus formed is included as part of the Proof of Human Creator (PoHC) token.

[0161] In continuous shooting or video mode, the rear camera attaches PoHC tokens on a frame-by-frame basis or at specified intervals. Each token is linked by a chaining hash containing a summary value of the previous token, forming a history that can track the development of the creation process. In an optional embodiment, the tokens and metadata are embedded in a manifest in the format of the Coalition for Content Provenance and Authenticity (C2PA) to support interoperable origin verification.

[0162] FIG. 9 shows an example of a scene in which a creator's face is captured using a front camera of a creator terminal according to various embodiments of the present invention.

[0163] FIG. 9 illustrates an example of a scene in which a creator's face is captured using a front camera of a creator terminal according to various embodiments of the present invention. The front capture can be performed in the same session as the rear capture of FIG. 8 and shares a specific time window of the same predetermined time length.

[0164] The front camera captures the creator's face, and liveness anti-spoofing verification can be performed on the captured video. For example, a liveness score can be calculated by combining two or more of the following: temporal changes in eye blinking, lips, and micro-expressions; light flow pattern analysis; continuity of depth or infrared-based parallax; presence and band compatibility of remote photoplethysmography (rPPG) signals; detection of periodic banding unique to screen playback; and mutual alignment of head pose based on 3D face landmarks and IMU rotation and translation.

[0165] To protect privacy, face features obtained from the front camera are converted into an irreversible feature summary and stored. For example, a salt hash using a terminal-specific seed, secure embedding quantization, or a homomorphic encryption-based summary value may be used. The converted face feature summary is bound to the same sequence identifier along with the back frame hash, timestamp, and terminal security information described in FIG. 8.

[0166] Simultaneously with the front view, the terminal's processor recognizes signature motion in the IMU sequence within the time window and can calculate a first human behavior proof score along with the simultaneity indicators of the front, rear, and IMUs. At this time, the bound data is digitally signed in a secure execution environment (TEE) and generated as a PoHC token. If the face is obscured or front view is difficult, it can be converted to alternative identification features such as palm veins, finger joint poses, or short voice segments according to the embodiment, and said features are summarized and bound in the same way.

[0167] The completed PoHC token and related metadata are stored within the terminal or transmitted to a management server or blockchain network via a communication network in a network environment. Subsequently, the validator terminal verifies the signature, certificate chain, and TEE remote authentication evidence according to the procedure in Fig. 6, and can determine whether it is a human creation by combining the concurrency and sensor fusion consistency indicators of the front, back, and IMU, along with the liveness results, using weights defined in the policy engine.

[0168] In summary, FIGS. 8 and 9 show that a rear camera-based creation scene capture and a front camera-based creator face capture are combined under the same time window and security binding to form key evidence proving that the creative act was ultimately performed physically by a person.

[0169] FIG. 10 illustrates an example of a process in which hashes are sequentially formed for frames / evidence generated at each creation stage according to various embodiments of the present invention and converge to a final result hash.

[0170] FIG. 10 illustrates a process in which hashes are formed in a chaining for frames and evidence generated at each creation stage according to various embodiments of the present invention and converge to the final hash of the final result. In the illustrated example, four steps (Step 1, Step 2, Step 3, Step 4) and hashes corresponding to the final result are formed in sequence. Below each step, a snapshot of the creation result at that point in time is exemplified, and above each step, it indicates that a front-view capture-based face recognition and behavior verification procedure is performed.

[0171] (1) Step-by-step evidence collection and token generation: In each step, the creator terminal captures the creation subject with the rear camera and captures the creator's face with the front camera. Both captures are performed in the same session, and an Inertial Measurement Unit (IMU) sequence is collected for a specific time window of a predetermined length based on the camera shutter event. The collected data is bound and signed in a Trusted Execution Environment (TEE), and a Proof of Human Creator (PoHC) token is generated for each step. At this time, liveness and anti-spoofing verification are performed on the front image, and facial features are converted into irreversible feature summaries and included.

[0172] (2) Step hash and chaining: “Hash 1, Hash 2, Hash 3, Hash 4” in FIG. 10 represent examples of frame hashes or token summary hashes for each step. Examples of implementations may include Secure Hash Algorithm 2 (SHA-256 or SHA-512), Secure Hash Algorithm 3 (SHA-3), BLAKE3, etc.

[0173] The PoHC token of each stage contains a hash summary of the previous stage to form a chained hash. This is intended to detect tampering with the entire process by utilizing the property that if any stage is later modified or omitted, the chain of subsequent stages becomes inconsistent.

[0174] (3) Convergence to the final hash: The “SHA-512 / Hash 5” on the far right represents the final hash calculated for the final result, exemplarily. The final hash is not a value that summarizes only one step, but is connected to the entire process history through the chaining structure of the preceding steps. Therefore, even if the final file has undergone post-processing such as resizing or re-encoding, it can be inversely mapped to the hash chain of the original steps by the thumbnail fingerprint or fixed-length summary included in the PoHC token. In an optional embodiment, the final hash and some summary information are recorded as custom claims in the Coalition for Content Provenance and Authenticity (C2PA) manifest and, if necessary, stored as a transaction on the blockchain network.

[0175] (4) Verification flow and mismatch handling: The validator terminal receives the step-by-step PoHC token and hash chain and performs (4-1) token signature and certificate chain verification, (4-2) TEE Remote Attestation Evidence verification, (4-3) checks for concurrency and sensor fusion consistency between front-end capture, back-end capture, and IMU collection, and (4-4) liveness results and security counter status evaluation. Subsequently, it checks whether each step hash conforms to the chaining rules, and if there are missing steps, it marks the chain as broken and downgrades the trust level. If all verifications pass, it acknowledges that the final hash is the cumulative result of the process and determines whether it is human-created.

[0176] (5) Variation Example: The number of steps in Fig. 10 is merely an example, and the same chaining structure can be applied if there are two or more steps. In the case of continuous video, tokens are generated at frame units or at specified intervals, and strong chaining is applied to the start, intermediate checkpoints, and end. In an offline environment, the tokens and hashes of each step are stored internally in the terminal, and upon returning to the network, they are transmitted in batches to an external system to perform delayed registration. In addition, the same principle can be applied to various creative works such as photos, videos, documents, and audio, in addition to drawings and designs.

[0177] In summary, Figure 10 shows that evidence generated at each stage of the creation process is connected by a chaining hash and converges to a final hash, and this structure reliably verifies the integrity of the entire process and the act of creation by a person.

[0178] FIG. 11 illustrates an example of a procedure for image metadata, timestamping, hash generation, and optionally recording on a blockchain to prove and disclose according to various embodiments of the present invention.

[0179] FIG. 11 illustrates an example of a procedure according to various embodiments of the present invention, which involves generating image metadata, timestamping, generating a hash, and, if necessary, recording it on a blockchain network to lead to proof and disclosure. The left ladder illustrates the flow of source data generated within the terminal, the central ladder illustrates the evidence packaging, summary hash generation, and optional recording steps, and the right illustrates disclosure and utilization.

[0180] First, the creator performs the creative act using the creator's device and initiates smartphone recording. At this time, the rear camera captures the subject of the creation, and the front camera captures the creator's face; both captures are performed within the same session, and an Inertial Measurement Unit (IMU) sequence is collected during a specific time window of a predetermined length based on the camera shutter event. The device generates image metadata, such as shooting mode, exposure, focal length, and frame timing, along with high-resolution timestamping data. Liveness and anti-spoofing verification are performed on the front image, and facial features are converted into unrecoverable feature summaries.

[0181] The generated source data is bound to the same sequence identifier and digitally signed in the terminal's Trusted Execution Environment (TEE). If necessary, the TEE generates Remote Attestation Evidence, including security states such as signature chains, monotonic counters, and patch levels in the evidence. The bound data thus formed is packaged into a Proof of Human Creator (PoHC) token, and in the case of videos or sequence images, is linked by a chaining hash for the start, checkpoint, and end.

[0182] “NFT step 1” of the central ladder exemplifies proof tokenization based on a Non-Fungible Token (NFT) as an implementation example. The present invention is not limited to NFTs but equally encompasses other forms of storage, such as a central repository or a distributed ledger. From the tokens or frame summaries generated step by step, a Secure Hash Algorithm 2 512-bit (SHA-512) or an equivalent hash is calculated to obtain a summary value denoted as a “HASH code.” This summary value and the minimum necessary metadata may optionally be recorded on a blockchain network, or stored in a database on a management server if private operation is required.

[0183] In the “Disclosure of Human Creator Creation Proof” stage on the right, a third party performs verification by querying or receiving the relevant summary value and PoHC token. The validator terminal checks the token signature and certificate chain, determines the trustworthiness of the TEE remote authentication evidence, examines the concurrency and sensor fusion consistency of front-end and back-end captures and IMU collection, and calculates a Human Behavior Proof score by combining the liveness results and security counter states with the policy engine's weights. If the threshold is exceeded, it confirms that the work is a human creation and displays this on the user interface or transmits the result to an external system.

[0184] To protect privacy, facial features are processed into an irreversible form using methods such as salt hashing with a unique terminal seed, secure embedding quantization, and homomorphic encryption-based summarization. Location and device information can be optionally included by specifying the precision level. Additionally, for interoperability with the Coalition for Content Provenance and Authenticity (C2PA), PoHC-specific claims can be inserted into the manifest as a custom namespace, and thumbnail fingerprints or fixed-length summaries can be stored together to enable reverse mapping to the original token even after editing, resizing, and re-encoding.

[0185] In an environment where the network is unstable, the PoHC token and hash are temporarily stored inside the terminal, and when communication is restored, delayed registration is performed to the management server or blockchain network. In an embodiment where a wearable sensor is used in parallel, the IMU sequence of the wearable is time-synchronized with the creator terminal and combined within the tolerance range of a specific time window of the same predetermined time length.

[0186] In summary, FIG. 11 illustrates the entire flow in which multi-sensor evidence and security signatures generated at the time of creation are normalized into a PoHC token and a summary hash, optionally recorded on a blockchain or management server, and lead to a public procedure that can be independently verified by a third party. This procedure is designed to reliably prove actual creation by a human while preserving the causal relationship between the creation process and the final result.

[0187] FIG. 12 illustrates an example of a configuration in which a data layer is generated through simultaneous shooting with app execution according to various embodiments of the present invention, and hash data is generated based on the results of proof of action and face recognition to prove the creation and the human creator through blockchain registration.

[0188] FIG. 12 illustrates a configuration in which a data layer is formed through app execution and simultaneous shooting according to various embodiments of the present invention, hash data is generated based on the results of proof of action and face recognition, and then optionally registered on a blockchain to prove the creation and the human creator. The flowchart on the left shows the process of preparation at the terminal, simultaneous shooting, and metadata and timestamp generation; the flowchart in the center shows face data processing, normalization of the data layer, hash calculation, and blockchain recording; and the annotation on the right shows the concept of creator proof based on proof of action and simultaneous face recognition using a smartphone's built-in Inertial Measurement Unit (IMU).

[0189] First, the user accesses the application on their smartphone, logs in, and launches the app. The app simultaneously captures the subject of creation using the rear camera and the creator's face using the front camera. A specific time window of a predetermined length is set based on the camera shutter event, and the IMU collects acceleration and angular velocity sequences in the intervals before and after this time window. Simultaneously, the device generates image metadata, such as shooting mode, exposure, focal length, and frame timing, along with high-resolution timestamping data.

[0190] In the first step of the central flowchart, face image data generation, liveness anti-spoofing verification is performed on the front camera image. In the next creator-specific step, face features are converted into irretrievable feature summaries. For example, a salt hash using a terminal-specific seed, secure embedding quantization, or homomorphic encryption-based summaries may be used. Subsequently, a data layer is formed. The data layer is normalized into a structure that binds the back frame hash, face feature summaries, timestamps within the time window, device and firmware versions, optional location information, and the Remote Attestation Evidence (REE) summary and monotonic counter values ​​from the Trusted Execution Environment (TEE) under the same session sequence identifier.

[0191] In the next step, a summary hash of the data layer is calculated. As an implementation example, the Secure Hash Algorithm 2 512-bit (SHA-512) or an equivalent hash may be used. The data layer is digitally signed with a terminal-only key in the TEE and packaged into a Proof of Human Creator (PoHC) Token. In the case of video or continuous recording, tokens are generated at the start, intermediate checkpoints, and end points, and each token is linked by a chaining hash to form a process history.

[0192] “Action verification through the operation of the smartphone’s built-in IMU sensor” and “Creator verification via facial recognition simultaneously with artwork capture” highlight the core of the above procedure. Specifically, rear capture, front capture, and IMU collection occur within the same session and timeframe, and the simultaneity and physical alignment of these three signals are calculated as a sensor fusion consistency metric, which is then utilized in the subsequent verification stage. This result supports the causal directness between the artwork and the creator, while the causal integrity of both the creator and the artwork is guaranteed by chaining hashes and signed data layers.

[0193] The generated hash and PoHC token can be optionally recorded on a blockchain network. Both public and private forms are possible, and interoperability is ensured by including PoHC-specific fields as custom claims in the Coalition for Content Provenance and Authenticity (C2PA) manifest if necessary. In environments requiring private operation, they can be stored on a management server, and upon a third-party request, the proof package and summary hash can be provided for verification.

[0194] If the network is unstable, the app temporarily stores the token and hash inside the terminal, and then performs delayed registration with an external system when communication is restored. In an embodiment where a wearable device is used together, the IMU sequence of the wearable is time-synchronized with the creator terminal and combined within the tolerance range of a specific time window of the same predetermined time length.

[0195] In summary, FIG. 12 shows that a data layer and a hash are generated through app-based simultaneous shooting and TEE-based security binding, and a public proof is completed through optional blockchain registration, thereby technically guaranteeing a direct causal relationship and an integrity link between the creation and the human creator.

[0196] FIG. 13 illustrates an example of a concept in which image metadata, timestamping data, face recognition data, and behavioral pattern data are combined and linked to a final proof token according to various embodiments of the present invention.

[0197] FIG. 13 illustrates a conceptual flow in which image metadata, timestamping data, face recognition data, and behavioral pattern data are combined into a single proof layer and linked to a final proof token according to various embodiments of the present invention. The “NTF” notation on the right side of the figure can be understood as an exemplary Non-Fungible Token (NFT).

[0198] First, the image metadata path includes parameters such as shooting mode, exposure time, focal length, frame timing, rolling shutter characteristics, and Optical Image Stabilization (OIS) operation status for frames acquired from the creator's device's rear camera. Since this metadata reflects a continuous and irreversible workflow, it serves as evidence supporting the causality between the creative process and the resulting output.

[0199] The timestamping data path records high-resolution timestamps and monotonic counters in a specific time window of a predetermined length set based on camera shutter events. In this embodiment, clock and counter values ​​from a Trusted Execution Environment (TEE) are used together to increase resistance to attacks such as re-flashing or rollback. If necessary, freshness can be enhanced through mutual signing with an external time source.

[0200] The User Facial Recognition Data path performs liveness and anti-spoofing verification on face images captured by the front camera and converts face embeddings into irreversible feature summaries. For example, salt hashes using a unique terminal seed, secure embedding quantization, and homomorphic encryption-based summaries may be used; to protect privacy, the original face images are stored only to the minimum extent necessary or discarded after PoHC generation.

[0201] The Behavior Pattern Data path utilizes acceleration and angular velocity sequences collected by the Inertial Measurement Unit (IMU) within a specific time window of a predetermined duration in the same session. The sequences are evaluated based on template matching or embedding similarity for signature motions, such as wrist flicks, double taps, and rotation followed by a stop, to calculate behavioral proof indices. Subsequently, a sensor fusion consistency check is performed to verify concurrency and physical alignment between the front capture, back capture, and IMU sequences.

[0202] The outputs of these four paths are normalized into a Data Layer within the terminal. Under the same sequence identifier, the backframe hash, facial feature summary, timestamp within the time window, device and firmware version, optional location information, and a summary of the TEE Remote Attestation Evidence are bound. The Data Layer is digitally signed by the TEE with a terminal-specific key to generate a Proof of Human Creator (PoHC) Token. For video or continuous capture, tokens are generated for the start, intermediate checkpoint, and end, and linked together using a Chaining Hash to form a process history.

[0203] The generated PoHC token and summary hash are linked externally in various ways depending on the usage environment. In one embodiment, a PoHC field is inserted into a custom claim of a Coalition for Content Provenance and Authenticity (C2PA) manifest and includes a thumbnail fingerprint or a fixed-length summary. In another embodiment, the final summary value and optional metadata are recorded on a blockchain network to provide public verifiability, and the PoHC summary can be linked to NFT metadata.

[0204] In the verification phase, the validator terminal receives the PoHC token and related metadata, verifies the signature and certificate chain, and checks the trustworthiness of the TEE remote authentication evidence. Subsequently, it verifies the consistency of the timestamp and monotonic counter, and calculates a human behavior proof score by combining the sensor fusion consistency metric, liveness results, and security counter status with weights determined by the policy engine. If the score exceeds a threshold, it is determined to be human creation and is displayed in the user interface or transmitted to an external system.

[0205] The structure of FIG. 13 is not limited to a specific medium. It can be applied in the same way to various creative works such as photographs, videos, illustrations, commercial designs, documents, and audio, and variations such as time synchronization with a wearable IMU, delayed registration after offline collection, and field minimization according to the level of privacy requirements are also possible. Consequently, FIG. 13 summarizes the core concept of the present invention, which combines the causality of the creative process, temporal integrity, creator identification, and human behaviorality in a complementary manner and links them with a final proof token.

[0206] When implementing an embodiment of the present invention using hardware, ASICs (application specific integrated circuits) or DSPs (digital signal processors), DSPDs (digital signal processing devices), PLDs (programmable logic devices), FPGAs (field programmable gate arrays), etc. configured to perform the present invention may be provided in the processor of the present invention.

[0207] Meanwhile, the method described above can be written as a program executable on a computer and can be implemented on a general-purpose digital computer that operates said program using a computer-readable medium. Additionally, the structure of the data used in the method described above can be recorded on a computer-readable storage medium through various means. Program storage devices that may be used to describe a storage device containing executable computer code for performing various methods of the present invention should not be understood to include transient objects such as carrier waves or signals. The computer-readable storage medium includes storage media such as magnetic storage media (e.g., ROM, floppy disk, hard disk, etc.) and optical reading media (e.g., CD-ROM, DVD, etc.).

[0208] The embodiments described above are combinations of the components and features of the present invention in a specific form. Each component or feature should be considered optional unless otherwise explicitly stated. Each component or feature may be implemented in a form not combined with other components or features. Additionally, it is possible to construct embodiments of the present invention by combining some components and / or features. The order of operations described in the embodiments of the invention may be changed. Some components or features of one embodiment may be included in another embodiment, or may be replaced with corresponding components or features of another embodiment. It is obvious that embodiments may be constructed by combining claims that do not have an explicit citation relationship in the claims, or that they may be included as new claims through amendments made after filing.

[0209] It will be apparent to those skilled in the art that the present invention may be embodied in other forms without departing from the technical spirit and essential features of the present invention. Accordingly, the above embodiments should be considered in all illustrative aspects rather than as a limiting one. The scope of the present invention shall be determined by a reasonable interpretation of the appended claims and all possible variations within the equivalent scope of the present invention.

Claims

Claim 1 A method for proving a human creator performed by a creator terminal, wherein the creator terminal includes a front camera, a rear camera, an Inertia Measurement Unit (IMU), a Trusted Execution Environment (TEE), memory, a processor, and a transceiver; and a step of simultaneously performing a session for capturing a creation target by the rear camera and a session for capturing the creator's face by the front camera; a step of collecting a sequence of acceleration or angular velocity of the IMU during a specific time window of a predetermined time length based on the rear camera and the shutter event of the front camera; a step of calculating a feature vector from the sequence and calculating a first human behavior proof score by the processor based on the matching of the feature vector with a motion template associated with one or more predetermined signature motions; a step of generating PoHC (Proof of Human Creator)-claim data by the processor by binding the face feature obtained from the front camera, the frame hash of the rear camera, the timestamp within the specific time window, and terminal identification security authentication information to the same sequence identifier; and the PoHC-claim data the A method comprising: a step of generating a PoHC-token by the processor by performing an electronic signature with a terminal-specific key in the TEE; and a step of transmitting at least one of frames captured by the rear camera and the front camera or metadata of the frames and the PoHC-token to an external terminal or an external network by the transceiver. Claim 2 In claim 1, the specific time window is defined as a bilateral time window including before and after the shutter event, the specific time window is adaptively set in the range of 50 to 500ms based on at least one of a shooting mode, focal length, exposure time, or frame rate, the feature vector includes domain statistics of time and frequency, tempo, phase, directionality index of the gesture, and gravity component separation index, the matching of the feature vector and the motion template is based on Dynamic Time Warping (DTW), a Hidden Markov Model (HMM), or deep learning embedding cosine similarity, the motion template associated with the signature motion is obtained through a user-specific personalized registration procedure, the first human behavior proof threshold associated with the first human behavior proof score is updated based on the distribution of past behavior proof scores of the creator terminal, the signature motion is defined as at least one of a wrist flick, a double tap, or a rotation-stop pattern, and the behavior proof score is the energy, duration, or directionality of the sequence A method based on whether it is within a predetermined range. Claim 3 In claim 1, the method comprises, in the step of generating the PoHC-claim data: performing an anti-spoofing verification for liveness using at least one of eye blinking, changes in lips or micro-expressions, depth mismatch, and screen playback detection for an image captured by the front camera; further comprising, in the step of irreversibly converting face features into a salt hash using a terminal unique seed, secure embedding quantization, or homomorphic encryption-based summary value and including them in the PoHC-claim data, wherein the PoHC-claim data has a field structure including a back frame hash, a face feature summary, a high-resolution timestamp within the specific time window, a device and firmware version, and optional location information, and wherein the digital signature is configured to enable the detection of re-flash and rollback attacks by including a platform certificate chain and a security counter in the TEE, and wherein, in the step of generating the PoHC-token: if the creation subject is a video, forming a process history by adding a chaining hash to the session start, intermediate checkpoint, and end frames, and wherein the PoHC-token containing the process history is frame-by-frame or designated A method comprising the additional step of configuring to be attached at intervals. Claim 4 The method of claim 1 further comprises: a step prior to the step of generating the PoHC-token, of detecting a synthetic attack or a replay attack through an IMU-video sensor fusion consistency check and generating a warning flag in case of a discrepancy; a step of digitally signing including the warning flag so that the warning flag is included in the PoHC-token in the step of generating the PoHC-token; a step of verifying that the IMU may be collected from a wearable device connected to the terminal in addition to the terminal, and that the timestamp synchronization between the terminal and the wearable device is within the tolerance of the specific time window; and a step of switching to at least one alternative identification feature among palm vein, finger joint pose, or voice short segment in a situation where face identification is impossible during the step of performing the capturing session. Claim 5 The method of claim 1, wherein the metadata is a C2PA Manifest (Coalition for Content Provenance and Authenticity Manifest), and the transmitting step comprises: inserting the PoHC-token into a custom claim namespace of the C2PA Manifest to perform a cross-validation routine with standard claims, and wherein the PoHC-token additionally includes a thumbnail fingerprint or a fixed-length summary so that inverse mapping with the original PoHC-token is possible even after editing, resizing, and re-encoding of the frames. Claim 6 A method performed by a validator terminal, wherein the validator terminal comprises an input device, an output device, a transceiver, a memory, and a processor, and receives by the transceiver at least one of frames captured with respect to the face of the creator and the creator, or metadata of said frames, and a PoHC (Proof of Human Creator) token corresponding to said frames from an external terminal or an external network; a step of parsing said PoHC token to extract by the processor a frame hash of the rear camera of the creator terminal, a summary of the creator's facial features, and a timestamp within a specific time window of a predetermined time length; a step of verifying the digital signature and certificate chain of said PoHC token, and confirming by the processor the Trusted Execution Environment (TEE) remote authentication evidence and security patch level whitelist conformity of the creator terminal included in said PoHC token; face capture based on the front camera of said creator terminal, capture of the creator target through said rear camera, and Inertia Measurement Unit of said creator terminal, A step of verifying simultaneity within the specific time window between data collection of the IMU, checking the allowable range of time synchronization error, and inspecting the monotonic counter rollback or replay window by the processor; a step of performing a sensor fusion consistency check, calculating a consistency index between rolling shutter parameters, Optical Image Stabilization (OIS) drive, exposure time, frame timing, and IMU sequence, and setting a warning flag by the processor in case of discrepancy;(i) an anti-spoofing verification result for liveness, (ii) the consistency indicator, and (iii) the security counter state of the PoHC-token combined based on the weights of the policy engine to calculate a second human behavior proof score, and a step of determining whether the second human behavior proof score is human creation by the processor by comparing the second human behavior proof score with a second human behavior proof threshold; a step of generating a confirmation result by the processor that the creation target is human creation if the second human behavior proof score is determined to be greater than or equal to the second human behavior proof threshold; and a step of outputting the confirmation result by the output device or transmitting the confirmation result to the external terminal or the external network by the transceiver. Claim 7 In claim 6, the anti-spoofing verification result is based on a liveness score calculated based on a face image segment acquired from a front camera or a face-related evidence field included in a PoHC-token, wherein the liveness score is calculated by combining two or more of: (i) the temporal rate of change and optical flow patterns of blinks, lips, or microexpressions; (ii) continuity of depth, continuity of infrared (IR), continuity of stereo parallax, presence of a remote photoplethysmography (rPPG) signal, and frequency band conformity; (iii) detection of periodic banding and moire in screen playback; and (iv) mutual alignment of a 3D face landmark-based head pose and an IMU-based angular rotation and translation, and the security counter state is calculated by extracting a monotonic counter, patch level, key identifier, and freshness information from the TEE remote authentication evidence of the PoHC-token, and rollback, playback, and whitelist. A method in which a second human behavior proof score is calculated by determining suitability, wherein the second human behavior proof score is calculated by weighted combination of the liveness score, the consistency indicator, and the security counter state, wherein the weights are configurable by the policy engine, and wherein the second human behavior proof threshold is evaluated by the score distribution obtained by combining the liveness score, the consistency indicator, and the security counter state based on a labeled correction dataset, and is set by the policy engine to satisfy at least one objective among the False Acceptance Rate (FAR), Equal Error Rate (EER), or F1 score optimization. Claim 8 In claim 6, if the metadata is partially missing: a method further comprising the step of performing original comparison reconstruction using the token chain, thumbnail fingerprint, and edit history field; and a step of verifying the TEE remote authentication evidence to determine the allowed firmware and security patch level whitelist conformity. Claim 9 A creator terminal comprises a front camera, a rear camera, an Inertia Measurement Unit (IMU), a Trusted Execution Environment (TEE), memory, a processor, and a transceiver, wherein the memory stores instructions for operations performed by the processor, and the operations include: simultaneously performing a session for capturing a creation target by the rear camera and a session for capturing the creator's face by the front camera; collecting a sequence of acceleration or angular velocity of the IMU during a specific time window of a predetermined time length based on the shutter events of the rear camera and the front camera; calculating a feature vector from the sequence and calculating a first human behavior proof score by the processor based on the matching of the feature vector with a motion template associated with one or more predetermined signature motions; and binding face features obtained from the front camera, the frame hash of the rear camera, timestamps within the specific time window, and terminal identification security authentication information to the same sequence identifier to provide PoHC (Proof of Human Creator)-claim data to the processor. A creator terminal comprising: a step of generating by; a step of generating a PoHC-token by the processor by performing an electronic signature of the PoHC-claim data with a terminal-specific key in the TEE; and a step of transmitting at least one of frames captured by the rear camera and the front camera or metadata of the frames and the PoHC-token to an external terminal or external network by the transceiver. Claim 10 A validator terminal comprises an input device, an output device, a transceiver, a memory, and a processor, wherein the memory stores instructions for operations performed by the processor, and the operations include: receiving by the transceiver at least one of frames captured regarding the face of the creator and the creator from an external terminal or network, or metadata of said frames, and a PoHC (Proof of Human Creator) token corresponding to said frames; parsing said PoHC token to extract by the processor a frame hash of the rear camera of the creator terminal, a summary of the creator's facial features, and a timestamp within a specific time window of a predetermined time length; verifying the digital signature and certificate chain of said PoHC token, and confirming by the processor the Trusted Execution Environment (TEE) remote authentication evidence and security patch level whitelist conformity of the creator terminal included in said PoHC token; face capture based on the front camera of said creator terminal, and the creator target through the rear camera of said creator terminal A step of verifying the simultaneity within the specific time window between capture and data collection by the Inertia Measurement Unit (IMU) of the creator terminal, checking the allowable range of time synchronization error, and inspecting the monotonic counter rollback or replay window by the processor; a step of performing a sensor fusion consistency check, calculating a consistency index between rolling shutter parameters, Optical Image Stabilization (OIS) drive, exposure time, frame timing, and IMU sequence, and setting a warning flag by the processor in case of discrepancy;(i) an anti-spoofing verification result for liveness, (ii) the consistency indicator, (iii) a second human behavior proof score by combining the security counter state of the PoHC-token based on the weights of the policy engine, and determining whether the second human behavior proof score is human creation by the processor by comparing the second human behavior proof score with the second human behavior proof threshold; if the second human behavior proof score is determined to be greater than or equal to the second human behavior proof threshold, generating a confirmation result that the creation target is indeed human creation; outputting the confirmation result by the output device, or transmitting the confirmation result to the external terminal or the external network by the transceiver. A validator terminal.

Images