Comments 1: 1.  The related-work section is thorough on SIM/eSIM, NFC/RFID, and smart-card security, but the positioning of your contribution within broader secure edge‑hardware and coordination architectures could be clearer. It would help to:  
- Explicitly contrast your “coordination-only” SIM interface with prior antenna‑integrated SIMs, external BLE tokens, and OS‑based activation logic in terms of attack surface, energy, and integration complexity.  
- Reference work on secure edge hardware interfaces and coordination layers beyond the SIM world, for example, recent architectures using secure elements, passive triggers, or low-power receivers, such as in:

[1] Ji Y, Zheng S. Distributed Mode-Dependent Event-Triggered Passive Filtering for Flexible Manipulator with Semi-Markov Parameters.

[2] M. D'Addato, Nanowatt Clock and Data Recovery for Ultra-Low Power Wake-Up Based Receivers.

Response 1: We thank the reviewer for this valuable suggestion. We agree that the original version of the manuscript emphasized SIM and smart-card related literature but did not sufficiently position the proposed architecture within the broader context of secure hardware coordination mechanisms and low-power activation architectures.

In the revised manuscript, we expanded the Related Work section to better contextualize the proposed coordination-only SIM interface within a wider class of architectures designed to trigger higher-power subsystems through low-power detection mechanisms. In particular, we added explicit discussion comparing the proposed design with:

·       antenna-integrated SIM and NFC-enabled SIM solutions, which embed complete RF communication subsystems within the SIM form factor;

·       external BLE tokens and wireless activation devices, which rely on independent transmitters and additional pairing mechanisms;

·       OS-based activation logic, which depends primarily on software-level event detection within the host device.

The revised manuscript clarifies that the proposed architecture differs from these approaches by introducing a hardware-mediated coordination layer within the SIM domain that focuses on passive RF detection and trusted trigger generation, while relying on the host device’s native wireless subsystems.

Following the reviewer’s recommendation, we also incorporated literature on event-triggered architectures and ultra-low-power wake-up mechanisms from related fields beyond SIM technology. In particular, we added references discussing event-triggered coordination models and low-power wake-up receivers that illustrate similar architectural principles of separating passive detection mechanisms from higher-power communication subsystems.

Revisions Made

1.     The Related Work section was expanded to include an explicit architectural comparison between:

o   antenna-integrated SIM designs,

o   external BLE tokens and wireless activation devices, and

o   OS-based software activation mechanisms.

2.     A new discussion was added explaining how the proposed SIM-compatible coordination interface differs from these approaches in terms of:

o   attack surface,

o   energy consumption, and

o   system integration complexity.

3.     Additional literature from adjacent domains was incorporated to highlight the broader concept of event-triggered and low-power coordination architectures, including:

o   Ji and Zheng on distributed event-triggered architectures for low-power systems;

o   D’Addato et al. on nanowatt wake-up receiver architectures.

4.     These references were integrated into Section 2.4 (Design Limitations and Research Gap) to demonstrate how the proposed architecture relates to broader research on low-power hardware coordination mechanisms.

Comments 2: On which handset/platform(s) has this been tested, and how generalizable is the BLE wake‑up behavior across different baseband/OS implementations? Are you relying on a vendor‑specific debug or test mode, or on a standardized SIM‑side signal?  

Response 2: We thank the reviewer for this important question.

In the revised manuscript, the work is explicitly presented as a conceptual architectural study, and therefore the proposed coordination interface has not yet been experimentally evaluated on specific smartphone platforms. The goal of the present work is to introduce and analyze a SIM-compatible hardware coordination mechanism, rather than to report platform-specific prototype testing.

The architecture does not rely on vendor-specific debug interfaces or proprietary hardware control mechanisms. Instead, the proposed model assumes that trigger events generated within the SIM/UICC domain would propagate through existing telephony interaction pathways, consistent with standard SIM/UICC communication frameworks defined by ISO/IEC 7816 and related telephony architectures.

Importantly, the revised manuscript clarifies that the proposed interface does not directly control the BLE subsystem. Any BLE-related behavior is assumed to be mediated by the host device’s telephony framework and operating system, which means that the exact system response and timing may vary across smartphone platforms, baseband implementations, and OS versions.

Because of these platform-specific differences, the generalizability of the mechanism can only be fully assessed through future prototype implementation and cross-platform validation, which are outside the scope of the present architectural study.

Revisions Made

1.     All wording implying experimental platform testing was removed from the manuscript.

2.     In Section 3.6 (Host Device Interaction Model), we clarified that:

o   trigger events originate in the SIM domain,

o   event interpretation occurs through telephony and OS pathways,

o   system response behavior is platform-dependent.

3.     Statements implying deterministic BLE activation behavior across devices were removed.

4.     In Section 7 (Limitations and Future Work), we added clarification that future work will include prototype implementation and evaluation across different smartphone platforms and telephony stacks.

Comments 3: It would strengthen the paper to clarify, at least conceptually, how different OSes/basebands would interpret the trigger (e.g., as a GPIO‑like interrupt, a specific SIM event, or a voltage signaling pattern), and to discuss any limitations or portability concerns.

Response 3: We thank the reviewer for this helpful suggestion. We agree that additional clarification regarding how SIM-domain trigger events could be interpreted by different smartphone architectures improves the clarity of the proposed coordination model.

In the revised manuscript, we added a conceptual discussion describing possible pathways through which a SIM-originated trigger event may propagate within the mobile device architecture. In particular, the manuscript now explains that the proposed interface does not directly control the BLE controller but instead generates a SIM-domain event that may be interpreted by the device’s telephony framework.

Depending on the smartphone platform and baseband implementation, such events could conceptually be propagated through mechanisms including:

·       SIM Toolkit (STK) or proactive SIM event signaling;

·       baseband-mediated notifications delivered through the telephony framework;

·       internal signaling interpreted by operating-system services responsible for SIM interaction.

The revised text emphasizes that the proposed coordination interface should be understood as generating a hardware-originated trigger condition within the SIM domain, while the interpretation and subsequent system behavior remain dependent on platform-specific telephony stack implementations.

We also added a discussion of portability considerations, noting that different mobile operating systems and baseband architectures may interpret SIM-originated events differently. As a result, the behavior of any downstream wireless subsystem activation is expected to vary across devices and therefore requires platform-specific evaluation during future prototype implementation.

Revisions Made

1.     In Section 3.6 (Host Device Interaction Model), we added a conceptual description of how SIM-domain trigger events may propagate through the telephony stack and operating-system services.

2.     The revised manuscript now clarifies that the proposed architecture does not rely on a specific signaling mechanism (e.g., GPIO or vendor debug mode) but instead assumes interaction through standard SIM/UICC interaction pathways.

3.     A new paragraph was added discussing platform portability and implementation variability across different smartphone operating systems and baseband architectures.

4.     In Section 7 (Limitations and Future Work), we added clarification that detailed evaluation of trigger interpretation mechanisms will require platform-specific prototype testing.

Comments 4: How are policies and credentials within the secure element provisioned, updated, and revoked in practice? Is there a risk that an attacker with physical access to the phone could replace the activation substrate with a malicious one that always authorizes any RF field?  

Response 4: We thank the reviewer for raising this important security consideration.

In the proposed architecture, the secure element (SE) is intended to function as the policy-validation component within the trusted coordination domain. In the current conceptual design, policy rules and authorization parameters are assumed to be provisioned using mechanisms similar to those commonly used in SIM/UICC and secure-element environments, such as trusted personalization procedures or operator-controlled provisioning workflows.

Because the present work focuses on architectural design rather than a finalized implementation, the manuscript does not prescribe a specific provisioning protocol. However, the intended model assumes that policy configuration and credential management would occur through trusted provisioning channels, consistent with established SIM lifecycle management processes used in telecommunications infrastructure.

Regarding the risk of hardware substitution, we agree that physical replacement of the coordination interface could represent a potential attack scenario. In the revised manuscript, we clarify that protection against such attacks would depend on secure-element–based authentication mechanisms and device-level trust verification. For example, a host device or network service could require cryptographic authentication of the coordination interface before accepting trigger events, thereby preventing unauthorized hardware from generating trusted activation signals.

We also emphasize that the proposed architecture does not assume unconditional trust in the external detection substrate. Instead, the secure element serves as the trust anchor, ensuring that trigger authorization depends on validated policy conditions rather than solely on the presence of an RF field.

Revisions Made

1.     In Section 3.2 (Trusted Coordination Domain), we added clarification describing the conceptual role of the secure element in storing and enforcing authorization policies.

2.     A new paragraph was added discussing policy provisioning, update mechanisms, and credential management, referencing typical SIM/UICC provisioning models.

3.     The manuscript now explicitly acknowledges the risk of physical interface replacement attacks and discusses mitigation strategies based on secure-element authentication and trusted provisioning.

4.     In Section 7 (Limitations and Future Work), we added a statement that detailed provisioning protocols and hardware authentication mechanisms will require further investigation during prototype implementation.

Comments 5: Some concrete examples of policy logic (e.g., field‑strength thresholds, time‑of‑day constraints, cryptographic challenge–response sequences with external tags) and how they are enforced in the SE would clarify the real‑world robustness against replay and spoofing.  

Response 5: We thank the reviewer for this helpful suggestion. We agree that providing examples of possible authorization policies improves the clarity of the proposed security model.

In the revised manuscript, we added a discussion describing representative policy logic that could be evaluated within the secure element (SE) of the trusted coordination domain. The SE is conceptually responsible for validating trigger conditions before allowing the generation of a SIM-domain activation event.

Examples of such policy rules include:

·       RF field strength thresholds, where the trigger is accepted only when the detected electromagnetic field exceeds predefined amplitude limits, reducing susceptibility to weak spoofing signals;

·       temporal constraints, where activation may be permitted only within defined time windows or under specific device states;

·       cryptographic authentication with external tokens, where an external NFC/RFID tag provides a challenge–response sequence validated by keys stored in the secure element;

·       rate-limiting policies, preventing repeated trigger attempts within a short time window in order to mitigate replay attempts.

In the proposed architecture, these policy rules are conceptually evaluated within the trusted coordination domain, where the secure element acts as the trust anchor responsible for validating authorization conditions. Only after successful policy validation does the coordination interface generate a SIM-domain trigger event.

We emphasize that the present work focuses on the architectural model rather than on a finalized protocol specification. The specific policy combinations, cryptographic protocols, and key-management strategies will depend on the target application and platform implementation and are therefore considered part of future prototype development and experimental validation.

Revisions Made

1.     In Section 3.2 (Trusted Coordination Domain), we added concrete examples of authorization policies evaluated within the secure element.

2.     The revised text now explains how the secure element functions as the policy enforcement component responsible for validating trigger conditions.

3.     The discussion now includes examples of replay and spoofing mitigation strategies, such as field-strength validation and rate-limiting policies.

4.     In Section 7 (Limitations and Future Work), we added clarification that detailed protocol design and cryptographic interaction models will be evaluated during future prototype implementation.

Comments 6: You might also briefly discuss the potential for side‑channel attacks on the SE during activation, even if full side‑channel analysis is future work.

Response 6: We thank the reviewer for this helpful suggestion. We agree that discussing potential side-channel considerations improves the completeness of the security analysis.

In the revised manuscript, we added a short discussion addressing possible side-channel attack vectors associated with the secure element (SE) within the trusted coordination domain. As in other smart-card and secure-element environments, operations involving policy validation and cryptographic checks may potentially be exposed to side-channel leakage mechanisms such as power analysis, electromagnetic emissions, or fault injection attempts.

The manuscript now clarifies that the proposed architecture assumes the use of standard tamper-resistant secure-element technology, similar to those commonly deployed in SIM/UICC platforms and hardware security modules. These components typically include countermeasures against common side-channel attacks, including protected execution environments, randomized cryptographic operations, and fault-detection mechanisms.

Because the present study focuses on architectural design and system-level modeling, detailed side-channel evaluation and experimental attack analysis were not included in the current work. However, such analysis will be an important part of future prototype validation.

Revisions Made

1.     A paragraph discussing potential side-channel attack vectors was added to the Security Analysis section.

2.     The revised text explains that secure elements typically include hardware countermeasures against power analysis, electromagnetic leakage, and fault injection attacks.

3.     In Section 7 (Limitations and Future Work), we added clarification that formal side-channel and fault-injection evaluation will be conducted during future prototype development.

Comments 7: How sensitive are the LF and HF antennas to off‑frequency interferers or strong nearby RF sources (e.g., wireless chargers, NFC payments, other tags)? Is there a risk of false triggers or denial‑of‑activation due to interference?

Response 7: We thank the reviewer for raising this important practical consideration.

We agree that passive RF detection structures operating within the limited nano-SIM form factor may be influenced by nearby electromagnetic sources, including wireless charging systems, NFC payment terminals, and other RF devices operating in adjacent frequency bands. Because the proposed architecture relies on RF field presence detection rather than full NFC/RFID communication, the possibility of false triggers or missed activation events due to environmental interference must be considered.

In the revised manuscript, we added clarification that the detection stage should be interpreted as a coarse RF presence sensor, whose output is subsequently validated within the trusted coordination domain. The architecture therefore does not rely solely on raw RF detection. Instead, additional validation mechanisms can be applied before trigger generation.

Examples of mitigation strategies discussed in the revised manuscript include:

·       frequency-selective filtering, limiting the detection circuitry to the intended LF or HF bands;

·       field-strength thresholding, ensuring that only sufficiently strong and stable RF fields are considered valid triggers;

·       temporal stability checks, requiring the field to persist for a minimum duration before policy validation;

·       secure-element policy validation, preventing RF detection alone from directly generating activation events.

These mechanisms reduce the likelihood of false triggers caused by incidental RF emissions or transient electromagnetic disturbances.

Because the present work focuses on architectural design, the exact sensitivity, coupling efficiency, and interference tolerance of the detection structures will depend on the final antenna geometry, device enclosure, and platform-specific RF environment. Detailed electromagnetic characterization and interference testing are therefore identified as part of future prototype validation.

Revisions Made

1.     In Section 3.3 (Passive RF Detection Layer), we added discussion of potential RF interference sources and their impact on detection reliability.

2.     The manuscript now clarifies that RF detection alone does not directly generate activation events, but must be validated through policy checks within the trusted coordination domain.

3.     Additional text was added describing filtering, thresholding, and temporal validation mechanisms that can reduce false-trigger risk.

4.     In Section 7 (Limitations and Future Work), we added clarification that RF interference characterization and antenna sensitivity measurements will be evaluated during prototype development.

Comments 8: Please improve the quality of Fig. 1, 2 and 3.

Response 8: Thank you for the suggestion. The quality of Figures 1–3 has been improved in the revised manuscript. The figures were redrawn using higher-resolution vector graphics to enhance clarity, readability of labels, and overall visual quality.

Revisions Made

Figures 1, 2, and 3 were replaced with improved high-resolution versions with clearer labeling and enhanced graphical quality.

Comments 1: 1. The core claim that triggering a SIM ISO 7816 contact can wake up the native BLE module without OS modification is technically unsound. Modern smartphones isolate the baseband modem from the application processor Bluetooth controller. How is this achieved?.

Response 1: We thank the reviewer for this important comment. We agree that the original wording overstated the role of the SIM-compatible interface and could be interpreted as implying direct electrical control of the smartphone’s native BLE hardware through the ISO/IEC 7816 interface. This was not our intended claim.

In the revised manuscript, we have substantially clarified the architectural scope of the work and reframed the contribution as a conceptual hardware coordination architecture rather than as a direct hardware-level BLE control mechanism. Specifically, the SIM-compatible interface is now described as generating a SIM-domain trigger event after passive RF detection and secure validation within the trusted coordination domain. This trigger event is not assumed to directly wake up the BLE controller. Instead, it is intended to propagate through existing telephony and system-service pathways available in supported smartphone architectures.

We now explicitly state that the proposed architecture relies on the established separation between the SIM/UICC domain, the baseband processor, and the host operating system. Any subsequent BLE activation is therefore treated as an OS-mediated or telephony-framework–mediated response to a SIM-originated event, rather than as direct electrical activation via ISO/IEC 7816 contacts. This clarification resolves the ambiguity in the previous version.

Revisions Made

We revised the manuscript in the following places:

1.     Title and overall framing were changed to present the work as a SIM-compatible hardware coordination architecture rather than an experimentally validated direct BLE activation interface.

2.     In Section 3.5 (SIM/UICC Interface Interaction Model), we now explain that:

o   the coordination interface operates within the standard SIM/UICC interaction framework;

o   trigger signals are generated as structured events in the SIM domain;

o   these events are conceptually propagated through SIM Toolkit / telephony pathways rather than directly controlling host wireless hardware.

3.     In Section 3.6 (Host Device Interaction Model), we explicitly clarify that:

o   the proposed interface does not directly control the BLE controller;

o   BLE-related behavior depends on the host operating system and telephony stack;

o   platform-specific implementations may interpret SIM-originated events differently.

4.     In the Abstract, Introduction, and Conclusions, all statements implying deterministic or direct “hardware-level BLE wake-up” were revised to more accurate formulations such as “SIM-domain trigger event,” “OS-mediated interaction,” and “coordination mechanism.”

Comments 2:  Figure 3 is highly suspicious and appears to be AI generated. The text on the flexible substrate is illegible gibberish, and the objects holding the substrate look unnatural. Please provide actual raw photographs of the fabricated prototype in a real testbed.

Response 2: We thank the reviewer for carefully examining the figure and for pointing out the potential ambiguity regarding the nature of the illustration.

We agree that the previous version of Figure 3 could be interpreted as representing a fabricated physical prototype. This was not the intention of the manuscript. The figure was originally included as a conceptual illustration of the proposed SIM-compatible flexible interface, rather than as a photograph of an implemented hardware prototype.

To avoid any misunderstanding, we have revised the manuscript and replaced the previous image with a clean schematic architectural diagram that explicitly illustrates the functional layers of the proposed system. The new figure focuses on the conceptual architecture and clearly identifies the following components:

·       passive RF detection layer

·       trusted coordination domain (control unit + secure element)

·       SIM/UICC interface interaction layer

·       host-device coordination pathway toward the native BLE subsystem

The revised figure contains no graphical elements resembling a fabricated hardware prototype and therefore avoids any potential confusion regarding experimental implementation.

We also clarified throughout the manuscript that the present study focuses on architectural modeling and system-level analysis, while prototype fabrication and experimental validation are planned as future work.

Revisions Made

1.     Figure 3 has been replaced with a schematic conceptual architecture diagram representing the coordination layers of the system.

2.     The figure caption was revised to clearly state that the illustration represents a conceptual architecture rather than a fabricated prototype.

3.     The manuscript text was updated in several sections (Introduction, Architecture, and Conclusions) to emphasize that the current work focuses on architectural design and system modeling, with prototype implementation planned for future work.

Revised Figure Caption

The caption of Figure 3 now reads:

Figure 3. Conceptual architecture of the proposed SIM-compatible coordination interface illustrating passive RF detection, trusted coordination domain, SIM/UICC interaction layer, and host-device coordination pathway toward the native BLE subsystem.

Comments 3:. In Section 4.1 you claim Figure 5 is a representative oscilloscope capture. However, this figure is clearly a digital vector drawing or simulated timing chart. Real oscilloscope traces always contain noise and imperfect edges. Where is the actual measurement data?

Response 3: We thank the reviewer for carefully examining the figure and for raising this concern.

After reconsidering the presentation of the experimental section, we agree that the previous wording could create the impression that the figure represented a real oscilloscope measurement. In the revised manuscript, we have therefore removed the experimental subsection and the associated figure entirely.

The current version of the paper focuses on the architectural design and system-level modeling of the proposed SIM-compatible coordination interface rather than on prototype-based experimental validation. Consequently, the figure previously labeled as an oscilloscope capture has been removed to avoid any potential misunderstanding regarding experimental measurements.

The manuscript now presents the work explicitly as a conceptual hardware coordination architecture, and prototype implementation and empirical evaluation are described as part of future work.

Revisions Made

1.     Section 4.1 containing the experimental timing analysis was removed.

2.     Figure 5 was removed from the manuscript.

3.     All statements referring to oscilloscope measurements or experimental waveform capture were deleted.

4.     The scope of the work was clarified in the Introduction, Architecture sections, and Conclusions to emphasize that the current study focuses on architectural modeling and system design, with prototype implementation and experimental validation planned for future work.

Comments 4: The paper lacks detailed schematics of the hardware interface. You mention an activation controller and a secure element, but you do not provide specific microcontroller models, part numbers, or the actual circuit design used in your physical prototype.

Response 4:

We thank the reviewer for this important comment.

We agree that a prototype-oriented implementation paper would require detailed circuit schematics, component part numbers, and hardware bill-of-material information. However, in the revised version of the manuscript, the work has been explicitly reframed as a conceptual hardware coordination architecture rather than as a prototype implementation report.

Accordingly, the terms activation controller and secure element are now used to describe functional architectural roles within the proposed coordination domain, rather than specific commercially implemented hardware components. The purpose of the revised manuscript is to present the architectural model, interaction pathways, and security rationale of a SIM-compatible coordination mechanism, rather than a finalized circuit-level implementation.

To avoid ambiguity, we have revised the relevant sections so that they no longer imply the existence of a fully fabricated and experimentally characterized prototype. Instead, the manuscript now presents:

·       a conceptual functional decomposition of the trusted coordination domain;

·       a system-level architectural model of passive RF detection, policy validation, and SIM-domain trigger generation;

·       a discussion of implementation constraints and future hardware realization.

We also explicitly state that specific controller selection, secure-element integration, circuit design, and component-level optimization are part of future prototype development and validation work.

Revisions Made

We revised the manuscript in the following ways:

1.     The paper was reformulated as a conceptual architecture study, and statements implying a fully implemented prototype were removed.

2.     In Section 3.2 (Trusted Coordination Domain), the activation controller and secure element are now described as functional components of the architecture rather than as identified hardware parts.

3.     In Section 4 (Conceptual Evaluation and Design Considerations) and Section 7 (Limitations and Future Work), we now explicitly state that:

o   detailed circuit-level implementation,

o   controller selection,

o   secure-element integration, and

o   prototype fabrication
remain subjects of future work.

4.     We retained and improved the architectural block diagrams to clarify system structure at the conceptual level, while avoiding misleading prototype-specific implications.

Comments 5: You state the system uses less than 100 uA during activation. Driving an ISO 7816 interface and operating a secure element usually consumes much more peak current. Your power consumption analysis in Table 2 seems like rough estimates rather than actual measured data.

Response 5: We thank the reviewer for this important observation.

The reviewer is correct that the current consumption values presented in the previous version of the manuscript could be interpreted as experimentally measured values. This was not our intention. The values reported in Table 2 were intended to represent order-of-magnitude design estimates derived from typical low-power smart-card and ultra-low-power control circuitry characteristics, rather than measurements obtained from a fabricated prototype.

To avoid any misunderstanding, the manuscript has been revised to clearly state that the presented power values correspond to a conceptual power-budget analysis describing the expected operating envelope of the proposed coordination architecture. These estimates are based on typical current ranges reported for passive RF detection circuits, low-power control logic, and secure-element policy validation operations under intermittent activation conditions.

We agree with the reviewer that actual current consumption will depend strongly on the specific secure-element implementation, controller microarchitecture, and platform-level electrical constraints of the target smartphone environment. For this reason, the revised manuscript now explicitly states that precise power characterization requires prototype implementation and experimental measurement, which are outside the scope of the present architectural study.

Revisions Made

1.     The wording in Section 4 (Power and Design Considerations) was revised to clarify that the reported current values represent estimated design ranges rather than measured values.

2.     Table 2 has been updated to explicitly indicate that the power values correspond to conceptual design estimates.

3.     Statements implying experimentally validated current consumption were removed from the manuscript.

4.     In Section 7 (Limitations and Future Work), we now explicitly state that detailed power measurements will be performed during future prototype development.

Comments 6: The manuscript does not explain the software side at all. Even if the SIM sends a signal, the Android or iOS system must have a background service or SIM Toolkit app listening to interpret this trigger. Claiming no OS dependency is incorrect.

Response 6: We thank the reviewer for this important observation and agree that the previous version of the manuscript did not sufficiently clarify the role of the host operating system and telephony framework.

The reviewer is correct that modern smartphone architectures isolate the SIM/UICC environment, the baseband processor, and the application processor. Consequently, any SIM-originated signal must be interpreted by the host device through existing telephony services or operating-system–level mechanisms. The proposed coordination architecture does not bypass this separation.

In the revised manuscript, we clarified that the SIM-compatible interface does not directly control the BLE subsystem, nor does it operate independently of the host operating system. Instead, the proposed mechanism generates a SIM-domain trigger event that may propagate through established telephony pathways (e.g., SIM Toolkit events or baseband-mediated notifications) and may subsequently be interpreted by system services or background processes within the smartphone operating system.

We have therefore removed statements suggesting “no OS dependency” and replaced them with more precise wording indicating that BLE activation behavior is mediated by the host platform’s telephony framework and operating-system services. The proposed architecture should thus be understood as a hardware-originated coordination mechanism, while the final interpretation and execution of the event depend on platform-specific software components.

Revisions Made

1.     Statements implying absence of operating-system dependency were removed from the manuscript.

2.     In Section 3.6 (Host Device Interaction Model), we added clarification that:

o   SIM-originated trigger events are propagated through telephony and system-service pathways;

o   interpretation of such events is platform-specific and mediated by the host operating system.

3.     Additional discussion was added to highlight the role of SIM Toolkit / telephony framework interactions as potential mechanisms for host-side interpretation of the coordination signal.

4.     The Abstract, Introduction, and Conclusions were revised to emphasize that the proposed interface operates as a hardware coordination layer, while wireless subsystem activation remains dependent on host-system software.

Comments 7: The authors affiliations are mainly software engineering and commercialization, yet the paper focuses heavily on flexible printed circuit fabrication, RF impedance matching, and materials like polyimide. The mismatch between author expertise and the deep hardware content is concerning.

Response 7: We thank the reviewer for raising this important point.

We agree that the original presentation of the manuscript may have given the impression that the work focuses on detailed materials engineering or fabrication processes for flexible RF hardware. This was not the intended scope of the study.

The revised manuscript clarifies that the primary contribution of this work lies in the system-level architecture and coordination model of a SIM-compatible activation interface rather than in the detailed fabrication of flexible electronics or RF antenna engineering. The references to flexible substrates, RF detection structures, and related materials were intended only to illustrate a plausible physical integration pathway compatible with nano-SIM form-factor constraints.

To address the reviewer’s concern, we have revised several sections of the manuscript to emphasize that the work focuses on:

·       architectural modeling of a SIM-compatible coordination mechanism,

·       interaction pathways between passive RF detection and smartphone telephony frameworks, and

·       security and system-level design considerations.

Detailed antenna design, RF impedance matching optimization, materials engineering, and fabrication processes are not the central focus of the study and would require dedicated experimental research in flexible electronics and RF hardware design. These aspects are now explicitly described as part of future interdisciplinary prototype development.

The interdisciplinary nature of modern embedded and mobile systems research frequently involves collaboration between software engineering, hardware architecture, and wireless systems domains. The present study therefore focuses on the architectural and system-integration perspective, while detailed hardware implementation will be addressed in future work involving specialized RF and hardware design expertise.

Revisions Made

1.     Sections describing flexible substrates and antenna structures were revised to avoid the impression of detailed fabrication claims.

2.     The manuscript now explicitly states that these hardware elements are presented at a conceptual integration level, consistent with the architectural scope of the work.

3.     In Section 7 (Limitations and Future Work), we added clarification that detailed RF antenna design, impedance matching, and flexible electronics fabrication will require future experimental hardware research.

4.     The overall framing of the manuscript was revised to emphasize system-level architecture and coordination mechanisms rather than hardware fabrication.

Comments 8: The acknowledgement section mentions using GPT 5.2. To my knowledge no such version exists. This casts heavy doubt on the authenticity of the entire manuscript and raises concerns about AI generated scientific content beyond just language translation.

Response 8: We thank the reviewer for pointing out this issue and appreciate the opportunity to clarify it.

The mention of “GPT-5.2” in the acknowledgement section was an unintentional wording error introduced during manuscript preparation. We acknowledge that this designation may cause confusion, as specific version numbering of large language models is not always publicly defined in this way.

In the revised manuscript, the acknowledgement has been corrected to remove the incorrect version reference. The statement now simply indicates that a generative AI language model was used for limited language editing and grammar assistance during manuscript preparation.

Importantly, the use of AI tools was restricted to linguistic support, such as improving clarity, grammar, and readability of the English text. All scientific ideas, architectural concepts, system models, figures, and technical arguments presented in the manuscript were developed and written by the authors. The authors take full responsibility for the scientific content of the paper.

To ensure transparency, the acknowledgement section has been revised to comply with the journal’s guidance regarding the disclosure of AI-assisted writing tools.

Revisions Made

1.     The reference to “GPT-5.2” was removed from the acknowledgement section.

2.     The acknowledgement was rewritten to clarify that generative AI tools were used only for language editing and proofreading assistance.

3.     The revised acknowledgement now follows standard disclosure wording recommended by academic publishers.

Comments 9: For the NFC and RFID detection, you rely on a flexible printed antenna within a nano SIM footprint. The area is extremely small to achieve enough inductive coupling at 125 kHz or 13.56 MHz through a metal smartphone tray. Where are the antenna parameter measurements?

Response 9: We thank the reviewer for this insightful comment and for highlighting the physical constraints associated with antenna integration within the nano-SIM form factor.

We agree that the extremely limited area of a nano-SIM footprint presents significant challenges for efficient inductive coupling at both LF RFID (125–134 kHz) and HF NFC (13.56 MHz) frequencies, particularly in the presence of metallic smartphone trays and surrounding RF subsystems.

In the revised manuscript, we clarified that the proposed structures are intended primarily for passive electromagnetic field detection rather than full NFC/RFID communication functionality. The objective of the architecture is not to establish reliable bidirectional communication with external readers but rather to detect the presence of sufficiently strong external RF fields that may serve as proximity-triggering events for the coordination mechanism.

As a result, the detection structures described in the paper are conceptual integration elements illustrating how passive RF sensing may be incorporated within the dimensional constraints of a nano-SIM-compatible flexible interface. Detailed antenna design parameters—including inductance, quality factor, impedance matching, coupling efficiency, and interaction with metallic device enclosures—are highly dependent on the specific device platform and require dedicated RF design and experimental validation.

Because the current study focuses on architectural design and system-level modeling, antenna parameter measurements and RF performance characterization are outside the scope of the present work. These aspects will be addressed in future prototype implementation and experimental evaluation.

Revisions Made

1.     The description of the LF and HF detection structures in Section 3 (Passive Detection Architecture) was revised to explicitly state that the structures serve as RF field presence detectors rather than full NFC/RFID transceivers.

2.     Statements implying robust RF communication capability were removed to avoid overstating the functionality of the detection structures.

3.     In Section 7 (Limitations and Future Work), we added clarification that:

o   antenna geometry optimization,

o   impedance matching,

o   coupling efficiency analysis, and

o   experimental RF measurements within smartphone environments
will be addressed in future prototype development.

Comments 10: You claim a BLE wakeup latency of exactly 9.2 ms. Smartphone OS task scheduling and BLE stack initialization take highly variable amounts of time, often much longer than 10 ms. Your deterministic timing claim for the host device is very unrealistic.

Response 10: We thank the reviewer for this important comment and agree with the underlying technical point. In modern smartphone architectures, any BLE-related response depends on operating-system scheduling, telephony-framework mediation, power-management state, and platform-specific implementation details. Therefore, a fixed deterministic wake-up latency for the host device should not have been claimed in the previous version of the manuscript.

In the revised manuscript, we removed the specific latency value and all wording implying deterministic BLE wake-up timing. The work is now framed as a conceptual coordination architecture, in which the SIM-compatible interface generates a SIM-domain trigger event following passive RF detection and validation within the trusted coordination domain. Any subsequent BLE-related behavior is treated as a host-side, OS-mediated response, whose timing may vary across platforms and operating conditions.

Accordingly, the manuscript no longer presents a precise BLE wake-up latency value. Instead, it explicitly states that trigger propagation and subsystem response are platform-dependent and should be experimentally characterized in future prototype validation work.

Revisions Made

We revised the manuscript as follows:

1.     The exact BLE wake-up latency value (9.2 ms) was removed from the manuscript.

2.     Statements implying deterministic host-side BLE wake-up timing were deleted from the Abstract, Architecture section, and Conclusions.

3.     In Section 3.6 (Host Device Interaction Model), we now clarify that:

o   the SIM-compatible interface does not directly control the BLE subsystem;

o   trigger events are propagated through telephony and operating-system pathways;

o   the resulting response timing depends on the host device platform, telephony framework, and OS behavior.

4.     In Section 7 (Limitations and Future Work), we added clarification that future work will include experimental evaluation of platform-specific trigger propagation latency and subsystem response variability.

Comments 11: The security analysis section is too generic. It just lists standard threat models without showing any real attack experiments or cryptographic protocol flows between the activation controller and the secure element. It reads like a textbook summary rather than research.

Response 11: We agree that the previous version of the manuscript presented the security discussion in a manner that could appear overly generic. The intention of this section was to analyze the architectural security properties of the proposed SIM-compatible coordination mechanism rather than to present experimental attack evaluations or finalized cryptographic protocol implementations.

In the revised manuscript, we strengthened the security analysis by clarifying the trust boundaries, attack surfaces, and coordination-domain isolation model associated with the proposed architecture. The revised section now focuses on how the system design minimizes exposure to several classes of threats by:

·       isolating the decision logic within a trusted coordination domain consisting of a control unit and a secure element;

·       avoiding the introduction of additional RF transmitters or bidirectional wireless interfaces within the SIM substrate;

·       limiting external interaction to passive RF field detection events rather than structured RF command exchanges.

We also clarified that the interaction between the control logic and the secure element should be interpreted as a policy-validation mechanism within the trusted domain, rather than a fully specified cryptographic protocol flow. Detailed cryptographic protocol design, key provisioning strategies, and formal attack testing require platform-specific implementation and are therefore considered part of future prototype development.

Revisions Made

1.     The Security Analysis section was revised to emphasize the architectural security model, including:

o   trusted coordination domain boundaries,

o   reduced RF attack surface,

o   isolation from host wireless subsystems.

2.     Generic threat descriptions were replaced with a clearer discussion of how the proposed architecture mitigates specific categories of attacks, including:

o   RF spoofing attempts,

o   unauthorized trigger generation,

o   cross-domain interaction risks between SIM and host subsystems.

3.     We clarified that cryptographic protocol details and attack experiments require a hardware prototype and therefore fall outside the scope of the present architectural study.

4.     In Section 7 (Limitations and Future Work), we added that future work will include:

o   formal adversarial modeling,

o   side-channel and fault-injection analysis,

o   experimental validation of secure-element policy enforcement.

Comments 12: The references are quite outdated for a paper on modern mobile and IoT security. Many cited papers are from 2006 to 2015. You missed a lot of recent literature on smartphone hardware security, baseband isolation, and trusted execution environments.

Response 12: We thank the reviewer for this important observation and agree that the previous version of the manuscript relied too heavily on foundational smart-card and SIM-security literature. While these earlier works remain relevant for establishing the historical and technical basis of SIM/UICC architectures, the reference set required strengthening with more recent studies addressing modern mobile and IoT security contexts.

In the revised manuscript, we substantially updated the literature review and discussion sections to include recent work on:

·       event-triggered and ultra-low-power wake-up architectures relevant to hardware coordination mechanisms;

·       contemporary eSIM and Remote SIM Provisioning security developments;

·       post-quantum and trusted-hardware approaches in mobile and IoT ecosystems;

·       broader hardware coordination and low-power subsystem activation concepts beyond the traditional SIM domain.

These additions help reposition the paper relative to current research on mobile and edge-system security while preserving the necessary historical background on SIM and smart-card architectures.

We also agree that topics such as smartphone hardware isolation, telephony-stack separation, and trusted execution environments are important for contextualizing the proposed coordination model. The revised manuscript now reflects this broader architectural perspective more clearly, particularly in the Introduction, Related Work, and Discussion sections.

Revisions Made

We revised the manuscript as follows:

1.     Recent references (2020–2025) were added to strengthen the paper’s connection to modern low-power coordination and mobile security architectures.

2.     In Section 2.4 (Design Limitations and Research Gap), we added recent literature on:

o   event-triggered hardware coordination mechanisms;

o   ultra-low-power wake-up receivers;

o   wake-up architectures for wireless and cellular IoT systems.

3.     In the Introduction, we added newer references covering:

o   eSIM evolution and Remote SIM Provisioning security;

o   modern hardware-rooted trust infrastructures;

o   recent security trends in mobile and IoT systems.

4.     The revised manuscript now better distinguishes between:

o   foundational smart-card literature used to explain SIM/UICC constraints, and

o   recent architectural literature used to position the proposed concept within current mobile and embedded security research.

Examples of Added Literature

The revised manuscript now includes recent references such as:

·       Ji and Zheng on event-triggered architectures for low-power distributed systems;

·       D’Addato et al. on nanowatt wake-up receiver design;

·       Wang et al. on wake-up receivers for resilient cellular IoT;

·       Fromm et al. on improved wake-up receivers for low-power wireless sensing;

·       Maistriaux et al. on LPWAN wake-up receiver architectures;

·       recent eSIM / PQC-oriented mobile security references already incorporated in the Introduction.

Why this revision was made

The revised manuscript is intended to better reflect the current state of research by combining:

·       foundational SIM/UICC and smart-card security literature, and

·       recent work on low-power coordination, wake-up architectures, and modern mobile trust infrastructures.

This combination is important because the proposed contribution lies at the intersection of historical SIM-based trust models and emerging hardware coordination mechanisms for mobile and embedded systems.