Remote Intent Service: Supporting Transparent Task-Oriented Collaboration for Mobile Devices

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This paper introduces a platform service, Remote Intent Service (RIS), that enables transparent task delegation between mobile devices by extending Android's intent mechanism - allowing applications to seamlessly outsource tasks (e.g., document viewing or audio playback) to optimal remote devices while maintaining sub-200ms latency. The system achieves mission-aware collaboration without application modifications through intent hijacking and resource synchronization, though the evaluation could better address multimedia streaming limitations and security implications. The main suggestions are as follows:

1. The application potential of RIS in more practical scenarios, such as healthcare, education, or industrial fields, could be further explored to enhance the universality and impact of the paper.
2. In the "Introduction" section, the research motivation could be summarized more concisely, avoiding redundant descriptions of the background of mobile device collaboration.
3. In "Related Work," the differences between RIS and existing technologies could be highlighted more prominently, for example, through tables or summary paragraphs, to help readers quickly understand the innovations.
4. The paper mentions that RIS can prevent privacy leaks on public devices (e.g., IVI system logins) but does not specify how RIS ensures the security of sensitive data during transmission. It is recommended to supplement the relevant design or encryption mechanisms.

Author Response

Comments 1: The application potential of RIS in more practical scenarios, such as healthcare, education, or industrial fields, could be further explored to enhance the universality and impact of the paper.
Response 1: We fully agree with your suggestion to add more scenarios that can show how RIS can be used in different fields to strengthen the impact of the paper. Based on your suggestion, we looked for more possible use cases of RIS. In the Introduction section of the revised manuscript, we have added practical examples where RIS can be applied. We hope these examples will better explain why RIS can be useful in the future.
“RIS can be useful in a wide range of applications that can make use of task-oriented collaboration for various purposes. For instance, when we need to see an attached PDF document to an e-mail, a tablet device that has a larger screen fits better to show the document than a smartphone, even if the tablet has fewer computation resources than the smartphone. Then the task-oriented collaboration technology enables the e-mail application in a smartphone to delegate the document displaying task to a document viewer application not in the smartphone but in a remote tablet. Another practical use of RIS can also be found in educational purposes, where a teacher can open a lecture material on the student’s tablet with a single touch on their own tablet. Also, within a corporate environment, employee A can request a specific type of file (for example, a PowerPoint file) to employee B through RIS on A’s phone. Then, employee B can simply choose the requested file on their file exploring app on B’s phone and the selected file can be delivered back to employee A. Furthermore, RIS can also be used for calling a specific phone number found on the internet while using a tablet by handing the number over to their smartphone using RIS, where it also automatically launches the phone call app with the specified number.”

Comments 2: In the ”Introduction” section, the research motivation could be summarized more concisely, avoiding redundant descriptions of the background of mobile device collaboration.
Response 2: Thank you for the suggestion. We agree that the Introduction section contained too much historic information on mobile collaboration. We have made the motivation part more concise by merging the three paragraphs that describe the general goals of mobile collaboration, as well as removing unnecessary statements that explain the ”stages” of its evolution.
“As a single person comes to use more than one device with possibly different types, many researches have been developed to synchronize data between different devices. For example, internet service providers started to provide N-screen service, so that users can enjoy the same services seamlessly regardless of devices being used, and A user who paused watching a YouTube video on a smart TV has become able to resume watching it on his(her) smartphone out of home. As mobile platforms keep evolving, higher-level collaboration technologies have emerged to overcome the weaknesses of mobile devices including small screen size, limited battery capacity, and less powerful computing resources. Modern mobile platforms support screen sharing/mirroring to overcome the small screen size of mobile devices by enabling users to enjoy content stored in a mobile device on a smart TV. In academia, lots of collaboration technologies between mobile devices and cloud/edge infrastructures have been developed, under the umbrella of Mobile Cloud/Edge Computing, to overcome the limited battery and computing resources in mobile devices or guarantee safe and secure execution of apps.”

Comments 3: In ”Related Work,” the differences between RIS and existing technologies could be highlighted more prominently, for example, through tables or summary paragraphs, to help readers quickly understand the innovations.
Response 3: We have added another column ”additional resource sharing” and changed ”mission-awareness” to ”task-oriented operation” in Table 1. We hope that it shows all major differences between RIS and existing works better. Also, an additional paragraph that summarizes these differences has been added at the end of the ”Related Work” section. We hope these changes show the strengths of RIS clearer.
“To summarize, RIS is a platform-level service for apps that are not developed for remote execution in mind, as well as being the first study that operates accordingly depending on the task details such as inspecting required additional resources that the other device might not have and send them along with the message (intent) itself, supporting collaboration direction of both from local to remote and remote to local device. On the other hand, to the best of our knowledge, no studies that are designed for such service have existed yet. These researches either require the apps to use the specific API they provide, or simply offload resources or fixed type of tasks to other devices without considering its execution context. Furthermore, their purpose is mostly limited to tasks specified by the apps, while the purpose of RIS can vary within a wide range of user preferences.”

Comments 4: The paper mentions that RIS can prevent privacy leaks on public devices (e.g., IVI system logins) but does not specify how RIS ensures the security of sensitive data during transmission. It is recommended to supplement the relevant design or encryption mechanisms.
Response 4: We are sorry that we did not clearly explain how we handle security issues. Although the current design of RIS has a mechanism to prevent privacy leaks within each device (mainly regarding the shared directory), it does not include techniques to eliminate security risks during transmission, as it is more a general concern of all collaborative systems involving multiple devices than an issue specific to RIS. However, we do have a plan to add a suitable encryption step during transmission in the future. We have added ”Conclusion and Future Work” section in the revised manuscript and included the details of these plans in the section.
“While RIS can perform a variety of mobile collaboration in many practical scenarios with reasonable latency, it has a few aspects that can possibly be improved. We are planning to conduct further researches to complement the following (but not limited to) issues:
• Energy efficiency: In general, energy and computational resources consumption in RIS is trivial because an intent object itself is lightweight and the time taken to execute the specified app is nearly instant. However, energy consumption can be problematic if the operations involve huge file transmissions. As mobile devices are usually highly limited in battery capacity, it will be important to develop a method to minimize energy consumption in such cases. 
• Latency for large file transmission: The current design of RIS can execute the remote app only after retrieving all required files from the local device, because it has no control over the remote app’s attempt to access the files. However, waiting for all files to be transmitted can cause a huge delay when the files are large, and it will be a waste of time if the remote app will not actually have used the file. We have two plans to reduce the latency in such cases. First, we will add streaming functionality support for multimedia files, where only a part of the files is transferred whenever the app requests it. Streaming rules, including which type of files should be streamed and which apps can use the functionality, can be specified in the intent table. Second, we will introduce asynchronous file transfer. This method requires a technique supported by the file system to block the app when the app tries to access to a file in the shared directory that is yet to be transferred. With this solution, the remote app can be executed first while other additional files are still being transferred. 
• Security & privacy risks: Currently, the only authentication phase between two devices is through the RIS section we created in the Settings app, where the user can confirm to add other devices to the trusted list. However, RIS does not have fundamental prevention method against network attacks such as sniffing, revealing risks on privacy leak. Moreover, the other device may be infected by malware or has maliciously manipulated RIS. To protect RIS from these risks, we will add encryption method for transmission, and introduce a proper authentication phase when two devices are first connected to each other. 
• Platform dependency: The design of RIS uses Android-specific features, mainly regarding intents and the shared directory. These components are not available on other platforms, for example, iOS, and thus cannot be universally implemented. Along with the research of RIS, we are also looking for a way to provide a similar mobile collaboration support that is less (hopefully not at all) dependent on the platform. 
• Android version: Android 12, where LineageOS 19.1 is based on, is an old version of Android at the time of writing this paper. Many structures have changed in the latest versions of Android and migrating RIS to these versions may require some minor changes in its implementation. However, to the best of our knowledge, the overall execution flow of an app using the intent has not changed drastically and we have not found any critical change that makes the core design of RIS invalid. We believe that migrating RIS to new Android versions is trivial, and we are planning to implement an advanced form of RIS on the latest Android version possible in the future.”

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

The paper proposed a platform service that supports collaboration between mobile devices. In this paper, a method to realize mission-oriented collaboration between mobile devices was proposed through a system service called remote intent service. A feature of the paper is that ris applications allow remote devices to delegate specific tasks, which allows users to open email attachments on other devices with a larger screen than smartphones, or to play music files smoothly on other devices.

However, the proposed method causes considerable delay in playing multimedia files on a remote device. When processing mp3 files or video files, the size of the file to be transmitted is large, and thus the delay that users may experience may increase. This problem can be solved by integrating streaming functions, but the current system does not explain whether it supports this.

Therefore, it is necessary to propose a plan to add a streaming function to the proposed method so that multimedia content can be quickly played on a remote device without transmitting large files. This will expand the range of content ris can handle and improve the user experience.

In addition, by optimizing the performance of ris, it is necessary to find a way to provide more consistent performance regardless of network state or file size. For example, it is required to apply a method that may prioritize processing some files before file transfer is completed.

Comments on the Quality of English Language

.

Author Response

Comments 1: However, the proposed method causes considerable delay in playing
multimedia files on a remote device. When processing mp3 files or video files, the size of the file to
be transmitted is large, and thus the delay that users may experience may increase. This problem
can be solved by integrating streaming functions, but the current system does not explain whether
it supports this.
Therefore, it is necessary to propose a plan to add a streaming function to the proposed method
so that multimedia content can be quickly played on a remote device without transmitting large
files. This will expand the range of content ris can handle and improve the user experience.
Response 1: Thanks for pointing out the delay issue with large multimedia files. It seems we did not make
it clear whether RIS has streaming functionality. Streaming is currently not supported by RIS, but we
definitely plan to add it in the future. In fact, it is one of our top priorities. We have clarified our
plan for streaming support in the ”Conclusion and Future Work” section shown below. We believe such
functionality will significantly widen the applicability of RIS without causing inconvenience to users.
"While RIS can perform a variety of mobile collaboration in many practical scenarios with reasonable
latency, it has a few aspects that can possibly be improved. We are planning to conduct further researches
to complement the following (but not limited to) issues:
• Energy efficiency: In general, energy and computational resources consumption in RIS is trivial
because an intent object itself is lightweight and the time taken to execute the specified app is
nearly instant. However, energy consumption can be problematic if the operations involve huge file
transmissions. As mobile devices are usually highly limited in battery capacity, it will be important
to develop a method to minimize energy consumption in such cases.
• Latency for large file transmission: The current design of RIS can execute the remote app only
after retrieving all required files from the local device, because it has no control over the remote
app’s attempt to access the files. However, waiting for all files to be transmitted can cause a huge
delay when the files are large, and it will be a waste of time if the remote app will not actually have
used the file. We have two plans to reduce the latency in such cases. First, we will add streaming
functionality support for multimedia files, where only a part of the files is transferred whenever
the app requests it. Streaming rules, including which type of files should be streamed and which
apps can use the functionality, can be specified in the intent table. Second, we will introduce
asynchronous file transfer. This method requires a technique supported by the file system to block
the app when the app tries to access to a file in the shared directory that is yet to be transferred.
With this solution, the remote app can be executed first while other additional files are still being
transferred.
• Security & privacy risks: Currently, the only authentication phase between two devices is through
the RIS section we created in the Settings app, where the user can confirm to add other devices
to the trusted list. However, RIS does not have fundamental prevention method against network
attacks such as sniffing, revealing risks on privacy leak. Moreover, the other device may be infected
by malware or has maliciously manipulated RIS. To protect RIS from these risks, we will add
encryption method for transmission, and introduce a proper authentication phase when two devices
are first connected to each other.
• Platform dependency: The design of RIS uses Android-specific features, mainly regarding intents
and the shared directory. These components are not available on other platforms, for example,
iOS, and thus cannot be universally implemented. Along with the research of RIS, we are also
looking for a way to provide a similar mobile collaboration support that is less (hopefully not at
all) dependent on the platform.
• Outdated Android version: Android 12, where LineageOS 19.1 is based on, is an old version of
Android at the time of writing this paper. Many structures have changed in the latest versions of
Android and migrating RIS to these versions may require some minor changes in its implemen-
tation. However, to the best of our knowledge, the overall execution flow of an app using the
intent has not changed drastically and we have not found any critical change that makes the core
design of RIS invalid. We believe that migrating RIS to new Android versions is trivial, and we
are planning to implement an advanced form of RIS on the latest Android version possible in the
future."

Comments 2: In addition, by optimizing the performance of ris, it is necessary to find a
way to provide more consistent performance regardless of network state or file size. For example,
it is required to apply a method that may prioritize processing some files before file transfer is
completed.
Response 2: We believe the streaming functionality you suggested above will reduce latency in certain cases
(when we know that the file is to be streamed). Unfortunately, the current design of RIS does not have
a general way to remove file transmission latency because it has no control over the application’s timing
to access the files, and therefore all files must be fully ready when the application is executed. However,
we have been thinking about this for some time and have come up with a file system support plan to
”block” the application when it tries to access a file that has not yet been transmitted, so that RIS can
transmit files lazily and prioritize the files that are being requested. We have added the details of this
plan to the ”Limitation and Future Work” section.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

The manuscript presents a novel mobile collaboration system called Remote Intent Service (RIS) for Android platforms. While the technical contribution has definitely merit, the work feels more like a well-executed implementation than a research endeavour. Here are my remarks.

The introduction is long and meandering; its evolution narrative feels forced, without leading to the proposed solution.

Terms like "mission-oriented collaboration" and "transparent hijacking" seem to me imprecisely defined. "Mission-oriented collaboration" means delegating a "mission" to another device, but then "mission" is simply a "particular task". What constitutes a "particular task" vs. any other task? What makes a task qualify as a "mission" or how does it differ from the existing general task delegation?

The examples provided (viewing PDFs on larger screens, avoiding credential input on public devices) are practical but don't necessarily demonstrate compelling research challenges.

The technical explanation of Android's intent mechanism is thorough and well-structured; I particularly appreciate the clear explanation of explicit and implicit intents, the role of ActivityManager and PackageManager, and the activity stack management.

The authors survey a broad range of mobile collaboration systems and compare them across multiple dimensions (Table 1), but these comparison dimensions don't clearly demonstrate why existing solutions are inadequate. The "mission-awareness" criterion seems a bit forced here, apparently favouring RIS instead of reflecting genuine technical requirements.

The related work section could also discuss how important recent work in cross-device computing and mobile offloading, and also in security-focused mobile collaboration systems, relates to RIS: both in functionality & UI and in trustworthiness / safe execution.

The positioning of the core contribution should be strenghtened: why is transparent intent hijacking (“RIS transparently hijacks an issued intent by an application”) superior to existing RPC-based or API-based approaches? Applications still need to be designed with remote execution in mind. In this respect, please also clarify “RIS enables seamless collaboration among applications on different devices without requiring application modifications”.

The background section focuses on Android intents but it should address core challenges of remote execution such as resource discovery and capability matching, security management, network reliability and latency sensitivity, etc. The problem framing seems oversimplified to me.

I appreciate the clear technical architecture and the implementation solutions in Section 4. However, the design introduces security risks; please discuss them (I’m concerned about the system-wide shared directory and potential intent injection attacks).

The conclusions are well aligned with the manuscript.

And a final remark: although I understand this, the design is tied to Android's specific architecture, thus limiting generalizability and research impact.

To conclude, the manuscript describes a solid technical implementation with practical merit, but I highly recommend a clearer positioning of the research contribution relative to existing cross-device computing solutions.

Comments on the Quality of English Language

Some grammatical errors and awkward phrasing (e.g., "confirm us that", "commensurate not only to") should be corrected.

Author Response

Comments 1: The introduction is long and meandering; its evolution narrative feels
forced, without leading to the proposed solution.
Response 1: We fully agree with your opinion that the introduction explains the evolution of mobile col-
laboration too deeply, and a significant part of it is not closely related to our work. We have merged
the three paragraphs explaining the history of mobile collaboration into a single paragraph and removed
unnecessary statements that describe the ”stages” of its evolution. We hope that the revised ”Introduc-
tion” section provides a clearer motivation for proposing RIS.
"As a single person comes to use more
than one device with possibly different types, many researches have been developed to synchronize data
between different devices. For example, internet service providers started to provide N-screen service,
so that users can enjoy the same services seamlessly regardless of devices currently being used, and
A user who paused watching a YouTube video on a smart TV has become able to resume watching
it on his(her) smartphone out of home. As mobile platforms keep evolving, higher-level collaboration
technologies have emerged to overcome the weaknesses of mobile devices including small screen size,
limited battery capacity, and less powerful computing resources. Modern mobile platforms support screen
sharing/mirroring to overcome the small screen size of mobile devices by enabling users to enjoy content
stored in a mobile device on a smart TV. In academia, lots of collaboration technologies between mobile
devices and cloud/edge infrastructures have been developed, under the umbrella of Mobile Cloud/Edge
Computing, to overcome the limited battery and computing resources in mobile devices or guarantee
safe and secure execution of apps."

Comments 2: Terms like ”mission-oriented collaboration” and ”transparent hijacking”
seem to me imprecisely defined. ”Mission-oriented collaboration” means delegating a ”mission” to
another device, but then ”mission” is simply a ”particular task”. What constitutes a ”particular
task” vs. any other task? What makes a task qualify as a ”mission” or how does it differ from the
existing general task delegation?
Response 2: It seems that the meaning of ”mission” is unclear and may cause confusion. We tried our best
to come up with a proper word to describe RIS’ design goal of ”recognizing the task details and acting
accordingly,” but ”mission” does not seem to be the best term. In this regard, ”mission” may not be
fundamentally different from a ”particular task,” as you pointed out. Therefore, we decided to change
it to ”task,” and hopefully the revised manuscript makes the meaning clearer.
As for the term ”transparent hijacking,” we suspect that the word ”hijacking” may have given the
wrong impression to describe the action of the RIS gateway. Therefore, we have changed ”hijacking” to
”intercept” so that the term has a more general meaning that the intent is taken by the RIS gateway
from its usual execution flow.

Comments 3: The examples provided (viewing PDFs on larger screens, avoiding creden-
tial input on public devices) are practical but don’t necessarily demonstrate compelling research
challenges.
Response 3: The most technical research challenge to achieve the goal of RIS is that the remote app has to
be executed just as it is executed on the same device where the calling app runs, even though the apps
are not aware of the presence of the other device and RIS. We are afraid that the examples provided were
not enough to show this. We have added a few more practical example cases that better demonstrate
technically challenging aspects of RIS in the ”Introduction” section of the revised manuscript.
"RIS can be useful in a wide range of applications that can make use of task-oriented collaboration for
various purposes. For instance, when we need to see an attached PDF document to an e-mail, a tablet
device that has a larger screen fits better to show the document than a smartphone, even if the tablet
has fewer computation resources than the smartphone. Then the task-oriented collaboration technology
enables the e-mail application in a smartphone to delegate the document displaying task to a document
viewer application not in the smartphone but in a remote tablet. Another practical use of RIS can also
be found in educational purposes, where a teacher can open a lecture material on the student’s tablet
with a single touch on their own tablet. Also, within a corporate environment, employee A can request
a specific type of file (for example, a PowerPoint file) to employee B through RIS on A’s phone. Then,
employee B can simply choose the requested file on their file exploring app on B’s phone and the selected
file can be delivered back to employee A. Furthermore, RIS can also be used for calling a specific phone
number found on the internet while using a tablet by handing the number over to their smartphone
using RIS, where it also automatically launches the phone call app with the specified number."

Comments 4: The authors survey a broad range of mobile collaboration systems and
compare them across multiple dimensions (Table 1), but these comparison dimensions don’t clearly
demonstrate why existing solutions are inadequate. The ”mission-awareness” criterion seems a bit
forced here, apparently favouring RIS instead of reflecting genuine technical requirements.
Response 4: We understand your concern about the comparison criteria we used. The meaning of ”mission-
awareness” may have been unclear. To address this vagueness, we decided to separate it into more
specific points (”additional resource sharing” and ”task-oriented operation”) and show the comparison
details one by one. We hope the differences between RIS and other existing mobile collaboration works
are now more obvious.

Comments 5: The related work section could also discuss how important recent work
in cross-device computing and mobile offloading, and also in security-focused mobile collaboration
systems, relates to RIS: both in functionality & UI and in trustworthiness / safe execution.
Response 5: We have added a new paragraph in the ”Related Work” section that summarizes the overall
comparison between RIS and other works, along with the contributions RIS provides but existing works
do not. We expect this addition will clearly show the importance of RIS compared to related work in
many aspects, especially in functionality & UI. For trustworthiness / safe execution, we have added a
discussion regarding them in ”Limitation and Future Work” section.
"While RIS can perform a variety of mobile collaboration in many practical scenarios with reasonable
latency, it has a few aspects that can possibly be improved. We are planning to conduct further researches
to complement the following (but not limited to) issues:
• Energy efficiency: In general, energy and computational resources consumption in RIS is trivial
because an intent object itself is lightweight and the time taken to execute the specified app is
nearly instant. However, energy consumption can be problematic if the operations involve huge file
transmissions. As mobile devices are usually highly limited in battery capacity, it will be important
to develop a method to minimize energy consumption in such cases.
• Latency for large file transmission: The current design of RIS can execute the remote app only
after retrieving all required files from the local device, because it has no control over the remote
app’s attempt to access the files. However, waiting for all files to be transmitted can cause a huge
delay when the files are large, and it will be a waste of time if the remote app will not actually have
used the file. We have two plans to reduce the latency in such cases. First, we will add streaming
functionality support for multimedia files, where only a part of the files is transferred whenever
the app requests it. Streaming rules, including which type of files should be streamed and which
apps can use the functionality, can be specified in the intent table. Second, we will introduce
asynchronous file transfer. This method requires a technique supported by the file system to block
the app when the app tries to access to a file in the shared directory that is yet to be transferred.
With this solution, the remote app can be executed first while other additional files are still being
transferred.
• Security & privacy risks: Currently, the only authentication phase between two devices is through
the RIS section we created in the Settings app, where the user can confirm to add other devices
to the trusted list. However, RIS does not have fundamental prevention method against network
attacks such as sniffing, revealing risks on privacy leak. Moreover, the other device may be infected
by malware or has maliciously manipulated RIS. To protect RIS from these risks, we will add
encryption method for transmission, and introduce a proper authentication phase when two devices
are first connected to each other.
• Platform dependency: The design of RIS uses Android-specific features, mainly regarding intents
and the shared directory. These components are not available on other platforms, for example,
iOS, and thus cannot be universally implemented. Along with the research of RIS, we are also
looking for a way to provide a similar mobile collaboration support that is less (hopefully not at
all) dependent on the platform.
• Outdated Android version: Android 12, where LineageOS 19.1 is based on, is an old version of
Android at the time of writing this paper. Many structures have changed in the latest versions of
Android and migrating RIS to these versions may require some minor changes in its implemen-
tation. However, to the best of our knowledge, the overall execution flow of an app using the
intent has not changed drastically and we have not found any critical change that makes the core
design of RIS invalid. We believe that migrating RIS to new Android versions is trivial, and we
are planning to implement an advanced form of RIS on the latest Android version possible in the
future."

Comments 6: The positioning of the core contribution should be strenghtened: why is
transparent intent hijacking (“RIS transparently hijacks an issued intent by an application”) supe-
rior to existing RPC-based or API-based approaches? Applications still need to be designed with
remote execution in mind. In this respect, please also clarify “RIS enables seamless collaboration
among applications on different devices without requiring application modifications”.
Response 6: We are sorry that our description about intent hijacking was not clear enough. We should have
made it more clear that one of the strongest points of RIS is that applications do not need to be designed
for remote execution, but the applications on the remote device can be invoked as if they are on the
local device. We have added an explanation to clarify why being ”transparent” is important and what
makes it better than existing RPC or API techniques in the revised manuscript.
"There are research efforts that use remote procedure calls (RPC) to delegate tasks to remote de-
vices. Intent to Share provides platform-level support for inter-component communication using Android
intents. However, it enforces using the APIs they provide to benefit from the functionality. Android RMI
provides a remote method invocation (RMI) mechanism at the user level to call application or system
services on remote devices. Mobile Plus supports cross-device RPC, enabling the sharing of various
functionalities of applications and system components. These approaches mainly focus on executing
procedures on remote devices. In contrast, RIS transparently intercepts an intent issued by a local ap-
plication that does not know the existence of such a service, identifies its execution context specified in
the intent, and executes the task by running an appropriate application on the remote device. As such,
RIS enables seamless collaboration among applications on different devices without requiring application
modifications."

Comments 7: The background section focuses on Android intents but it should address
core challenges of remote execution such as resource discovery and capability matching, security
management, network reliability and latency sensitivity, etc. The problem framing seems oversim-
plified to me.
Response 7: We agree with your concern that RIS does not fully cover all challenges it should overcome to
be practically used. The current design of RIS mainly focuses on the process of remote execution itself
but lacks measures to prevent security risks and handling of network-related issues. In fact, our plan is to
add functionalities that complement these weaknesses to RIS in the near future. We have added several
points that describe these plans in the ”Limitation and Future Work” section. We aim to strengthen
RIS by adding these various techniques.

Comments 8: I appreciate the clear technical architecture and the implementation
solutions in Section 4. However, the design introduces security risks; please discuss them (I’m
concerned about the system-wide shared directory and potential intent injection attacks).
Response 8: We have added more explanations regarding how the shared directory prevents access attempts
from other apps. By intent injection attacks, we assume it means the attacker can purposefully send
malicious intents to other devices. It is our future challenge to prevent such attacks by inspecting the
intent before executing the app, and apply strict policies to intent table to allow safe intents only.
Currently, RIS has a section on the Settings app where the user can choose which device to connect to,
and the user is recommended to connect only to trustworthy devices. We have added our various plans
to strengthen security and to protect privacy in the ”Limitation and Future Work” section.

Comments 9: And a final remark: although I understand this, the design is tied to
Android’s specific architecture, thus limiting generalizability and research impact.
Response 9: We understand your concern. In the added ”Limitation and Future Work” section, we included
platform-independence as one of its points. We believe that generalizing RIS requires design at a higher
level than the platform itself, which is beyond the scope of our current work, but we will absolutely try
to conduct researches regarding it.

Comments 10: To conclude, the manuscript describes a solid technical implementation
with practical merit, but I highly recommend a clearer positioning of the research contribution
relative to existing cross-device computing solutions.
Response 10: Thank you for the valuable opinions. We have tried to apply as many suggestions as possible. We
hope these changes make our work more solid and better position RIS among other mobile collaboration
studies.

Author Response File: Author Response.pdf

Reviewer 4 Report

Comments and Suggestions for Authors

This paper introduces a mobile platform service called Remote Intent Service (RIS), which enables a running application in a device to outsource the execution of a specific task to other applications in a remote device. RIS is mainly introduced for mission-oriented collaboration. This service is tested on Android LineageOS 19.1 platform and measures the latency for executing such tasks in a remote device. Meanwhile, there are several comments concerning this paper, which are:

1. The latency in the range of 250 ms can be considered annoying for interactive applications, hence, more efforts should be made to optimize this value to reach an acceptable level for interactive applications. Additionally, the study should show how this service can be optimized for energy-efficient operation since this is a prime factor of mobile devices.
2. The detailed implication of RIS on the security and privacy of the devices should be provided since it might be a major limitation of this service, for example, RIS can handle malicious applications that can be a launching point for malicious attacks against collaborative devices. Additionally, how the authentication of the participating devices is handled is not clear in the paper, … etc.
3. More use cases should be investigated with diverse devices and operating environments.
4. The reliance of a specific version of Android platform, which is an old version and almost obsolete now raises an important question on how this service can work with current versions of Android. It is important to provide the analysis and results on the currently used version, which is mostly version 15 and some devices now use version 16, which actually contains many changes as compared with the outdated one used in this paper.
5. Relying on latency only for the performance evaluation is very limited in this study, there are many other metrics that are as important as the latency that should be measured and analyzed such as success and failure percentages of the intent task.
6. There are a couple of self-citations in the paper, which are outdated and more recent work has been done as compared to them. Hence, it is very important to provide recent alternatives to them.
7. More than 50% of references are dated before 2020 (with more than half of them are dated before 2015), it is important to find alternative recent references given that there are many recent research efforts in similar directions.
8. Reference [2] is not relevant for the study and actually it is non-peer reviewed.
9. More than 30% of the references used are non-peer reviewed sources.
10. There is no comparative analysis to existing approaches or to any benchmark in either the methodology or the results.
11. The results provided in the paper are very limited and even the results provided need more detailed analysis. For example, why do the results not include variety of mobile devices to evaluate the performance of the introduced approach. No comparative analysis with similar approaches has been provided even though there are many approaches stated in section 2.1, which is worth comparing against some of them that are most similar to the provided approach. Additionally, using only the latency as the sole measure is not reliable to measure the performance of the introduced service mainly because there are many other parameters that should be taken into consideration (for example, CPU usage, memory, energy consumption … etc.) All these aspects are completely missing in the paper, even though they could be as important as the latency itself. Meanwhile, the baseline for the latency is not defined based on real measurements, the paper just stated that 250 ms is fine, however, I can consider this figure of number as too long for interactive application, which is highly subjective baseline. Moreover, such subjective measure should be judged via subjective evaluation for the latency measurements, which is also not provided in the paper.
12. The paper lacks any theoretical analysis of the different performance measures that should be targeted by such approaches with detailed assumptions.
13. The abstract should refer to the obtained results of applying RIS service in a quantitative manner.

Comments on the Quality of English Language

1. Line 63: “less amount of computation resources” should be corrected into “fewer number of computation resources” or “fewer computation resources”
2. Line 559, “except ‘Play music’ ” should be “except for ‘Play music’ ”
3. Line 125: “application’s package name” should be “application package name”
4. Line 129 “system’s role” should be “system role”, please correct similar occurrences, since “’” is used mainly with humans.
5. Better to move Table 1 after the reference to it in section 2.2.

Author Response

Comments 1: The latency in the range of 250 ms can be considered annoying for
interactive applications, hence, more efforts should be made to optimize this value to reach an
acceptable level for interactive applications. Additionally, the study should show how this service
can be optimized for energy-efficient operation since this is a prime factor of mobile devices.
Response 1: We agree with your concern about the 250 ms latency. This amount of latency is indeed quite
noticeable when the apps are used repeatedly and interactively. Thankfully, when we searched for use
cases of Android intents, we could hardly find scenarios where they are used interactively. In most cases,
the operation is singular, meaning that the user moves their attention to another device once they have
executed a remote intent, and in such cases the 250 ms latency is hardly noticeable. We have tried to
explain this point better in the ”Performance Evaluation” section of the revised manuscript.
"Despite such a remote processing overhead, the entire latency (< 250 ms) is small enough for RIS
to be practical unless the service is to be repeatedly used in interactive manner, which is not a common
usage for intents. In most cases, both devices are controlled by a single user, and in such cases the user
has to move their head (or eye) from the local to the remote device, which makes the latency of 250
ms hardly recognizable. Besides, overall performance of Pixel 5 is lower than most smartphones used
nowadays, and therefore we expect the latency to be even lower if RIS is implemented in commercial
products in the future."

Comments 2: The detailed implication of RIS on the security and privacy of the devices
should be provided since it might be a major limitation of this service, for example, RIS can handle
malicious applications that can be a launching point for malicious attacks against collaborative
devices. Additionally, how the authentication of the participating devices is handled is not clear in
the paper, . . . etc.
Response 2: The concerns regarding security and privacy of RIS are valid. Currently, RIS focuses on the
remote execution itself, and the trustworthiness of the other device or the other app is only addressed by
providing a section in the Settings app where the user can choose which device the RIS should connect
to and interact with. We have added a brief explanation of this procedure in the revised manuscript.
"Although the current design of RIS does not include strict security policies, broader security issues will
be addressed in our future work so that RIS can be applied to real commercial products. We have added
a ”Limitation and Future Work” section in the revised paper to discuss various issues RIS has yet to
address, including security and privacy. We hope to handle these in the near future.
While RIS can perform a variety of mobile collaboration in many practical scenarios with reasonable
latency, it has a few aspects that can possibly be improved. We are planning to conduct further researches
to complement the following (but not limited to) issues:
• Energy efficiency: In general, energy and computational resources consumption in RIS is trivial
because an intent object itself is lightweight and the time taken to execute the specified app is
nearly instant. However, energy consumption can be problematic if the operations involve huge file
transmissions. As mobile devices are usually highly limited in battery capacity, it will be important
to develop a method to minimize energy consumption in such cases.
• Latency for large file transmission: The current design of RIS can execute the remote app only
after retrieving all required files from the local device, because it has no control over the remote
app’s attempt to access the files. However, waiting for all files to be transmitted can cause a huge
delay when the files are large, and it will be a waste of time if the remote app will not actually have
used the file. We have two plans to reduce the latency in such cases. First, we will add streaming
functionality support for multimedia files, where only a part of the files is transferred whenever
the app requests it. Streaming rules, including which type of files should be streamed and which
apps can use the functionality, can be specified in the intent table. Second, we will introduce
asynchronous file transfer. This method requires a technique supported by the file system to block
the app when the app tries to access to a file in the shared directory that is yet to be transferred.
With this solution, the remote app can be executed first while other additional files are still being
transferred.
• Security & privacy risks: Currently, the only authentication phase between two devices is through
the RIS section we created in the Settings app, where the user can confirm to add other devices
to the trusted list. However, RIS does not have fundamental prevention method against network
attacks such as sniffing, revealing risks on privacy leak. Moreover, the other device may be infected
by malware or has maliciously manipulated RIS. To protect RIS from these risks, we will add
encryption method for transmission, and introduce a proper authentication phase when two devices
are first connected to each other.
• Platform dependency: The design of RIS uses Android-specific features, mainly regarding intents
and the shared directory. These components are not available on other platforms, for example,
iOS, and thus cannot be universally implemented. Along with the research of RIS, we are also
looking for a way to provide a similar mobile collaboration support that is less (hopefully not at
all) dependent on the platform.
• Outdated Android version: Android 12, where LineageOS 19.1 is based on, is an old version of
Android at the time of writing this paper. Many structures have changed in the latest versions of
Android and migrating RIS to these versions may require some minor changes in its implemen-
tation. However, to the best of our knowledge, the overall execution flow of an app using the
intent has not changed drastically and we have not found any critical change that makes the core
design of RIS invalid. We believe that migrating RIS to new Android versions is trivial, and we
are planning to implement an advanced form of RIS on the latest Android version possible in the
future."

Comments 3: More use cases should be investigated with diverse devices and operating
environments.
Response 3: We would absolutely love to confirm RIS’ usability with a variety of environmental settings;
however, the revision timeline was limited, so we were unable to prepare more devices for testing. At
the very least, we have added two more use case scenarios (”set an alarm”, ”initiate a phone call”) in
the revised manuscript. We plan to conduct more experiments on other devices in the future to confirm
that RIS works well in a wide range of environments.

Comments 4: The reliance of a specific version of Android platform, which is an old
version and almost obsolete now raises an important question on how this service can work with
current versions of Android. It is important to provide the analysis and results on the currently used
version, which is mostly version 15 and some devices now use version 16, which actually contains
many changes as compared with the outdated one used in this paper.
Response 4: We understand that the Android version being outdated is concerning. In fact, upgrading the
Android version is one of our priorities for future work. We wanted to upgrade it during the revision
phase, but migrating our work to a new version takes more time than we had to make the necessary
changes and redo all experiments. However, to the best of our knowledge, the overall flow of intent
execution, at least for the parts related to our implementation, has barely changed up to the newest
version of Android. Thus, we believe that almost all of the design choices of RIS can still be applied to
Android 15 or 16, and only minor changes should be needed in the implementation.

Comments 5: Relying on latency only for the performance evaluation is very limited
in this study, there are many other metrics that are as important as the latency that should be
measured and analyzed such as success and failure percentages of the intent task.
Response 5: As a system that involves multiple devices interacting wirelessly with each other, it is unavoidable
that the operation of RIS may sometimes fail unexpectedly during transmission. However, the causes of
failure mainly come from the wireless environment and the hardware, which are not precisely controllable
from our side and are not part of RIS’ design. Therefore, we assumed that the operation regarding
network always succeeds and excluded failure cases. Without network failure, the rest of the operations
have a 100% success rate, assuming that the intent issued by the application is correct. Therefore, we
think it is enough to show only the latency of RIS as its performance. We have clarified these points in
the revised manuscript. Also, we have added in the ”Conclusion and Future Work” section that we will
improve RIS to be more fault-tolerant, so that RIS will never cause a fatal error on the system or apps,
even if network issues occur or the user performs operations incorrectly.
"Although RIS, as a system that involves interaction between different devices, has a nontrivial chance
to fail during operations, we assumed 100% success rate of all experiments. This is because such failure
occurs mostly due to by-nature unstable wireless network, which is uncontrollable and the design of RIS
is not related to it. Other than such cases, we have found no internal failure of RIS yet."

Comments 6: There are a couple of self-citations in the paper, which are outdated and
more recent work has been done as compared to them. Hence, it is very important to provide recent
alternatives to them.
Response 6: Thank you for pointing this out. We have been able to find several references that can replace
our own earlier work. We have added introductions to the newer studies in the revised manuscript.

Comments 7: More than 50% of references are dated before 2020 (with more than half
of them are dated before 2015), it is important to find alternative recent references given that there
are many recent research efforts in similar directions.
Response 7: We have searched for more recent studies and added several studies dated after 2020 to the
”Introduction” and ”Related Work” sections. We hope the citations are now much more up-to-date.

Comments 8: Reference [2] is not relevant for the study and actually it is non-peer
reviewed.
Response 8: We agree that the reference is not appropriate for this paper. We have removed it from the
revised manuscript.

Comments 9: More than 30% of the references used are non-peer reviewed sources.
Response 9: We have removed some references that are only articles published by organizations. Some of
the web page references, however, are for citing products made by specific companies. Even though they
cannot be peer-reviewed, we used these pages as references because we thought they best represent the
products. We hope this explains our intention well.

Comments 10: There is no comparative analysis to existing approaches or to any
benchmark in either the methodology or the results.
Response 10: We have added a paragraph in the ”Related Work” section that summarizes the comparisons
between RIS and other related work regarding methodologies. We would like to include a comparison
of experimental results too, but we could not find any research that performs a task similar to RIS, so
their performance could not be directly compared to RIS.
"To summarize, RIS is a platform-level service for apps that are not developed for remote execution
in mind, as well as being the first study that operates accordingly depending on the task details such as
inspecting required additional resources that the other device might not have and send them along with
the message (intent) itself, supporting collaboration direction of both from local to remote and remote
to local device. On the other hand, to the best of our knowledge, no studies that are designed for such
service have existed yet. These researches either require the apps to use the specific API they provide, or
simply offload resources or fixed type of tasks to other devices without considering its execution context.
Furthermore, their purpose is mostly limited to tasks specified by the apps, while the purpose of RIS
can vary within a wide range of user preferences."

Comments 11: The results provided in the paper are very limited and even the results
provided need more detailed analysis. For example, why do the results not include variety of mobile
devices to evaluate the performance of the introduced approach. No comparative analysis with
similar approaches has been provided even though there are many approaches stated in section 2.1,
which is worth comparing against some of them that are most similar to the provided approach.
Additionally, using only the latency as the sole measure is not reliable to measure the performance
of the introduced service mainly because there are many other parameters that should be taken into
consideration (for example, CPU usage, memory, energy consumption . . . etc.) All these aspects
are completely missing in the paper, even though they could be as important as the latency itself.
Meanwhile, the baseline for the latency is not defined based on real measurements, the paper just
stated that 250 ms is fine, however, I can consider this figure of number as too long for interactive
application, which is highly subjective baseline. Moreover, such subjective measure should be judged
via subjective evaluation for the latency measurements, which is also not provided in the paper.
Response 11: We are sorry that we were not able to include diverse target devices. As we stated above, we
would like to have a chance to conduct experiments with various devices in the near future. For the time
being, we have added a conclusion to the revised manuscript that Pixel 5 is one of the mobile devices
with very low performance among all commercial smartphones nowadays, and therefore on most recent
devices the performance of RIS would likely be better than shown in our experiments, if not the same.
We also wanted to make a direct result comparison to other approaches if possible, but we deemed that
none of them can be evaluated with the same criteria due to how unique the action of RIS is compared
to the other studies. We hope, though, that once we add more functionalities to RIS in the future, we
will be able to make a separate comparison between the specific feature and other researches. For other
measurable aspects, in the added ”Limitation and Future Work” section of the revised manuscript, we
have stated that the whole process of RIS is almost instant and lightweight and thus does not consume
much resource for intents themselves, but battery use can increase along with large file transmission,
which we will definitely discuss in our future work. We hope the reason we think 250 ms is fine is
explained enough in our reply to point 1.

Comments 12: The paper lacks any theoretical analysis of the different performance
measures that should be targeted by such approaches with detailed assumptions.
Response 12: Although we were not able to add more evaluations with various criteria within the revision
stage, we plan to extend RIS to become a more generic service that can and should be evaluated in
such aspects in the future. We have added these plans in the ”Conclusion and Future Work” section.

Comments 13: The abstract should refer to the obtained results of applying RIS service
in a quantitative manner.
Response 13: We have added some details of the evaluation to the abstract, including the specific latencies
measured in milliseconds.
"We implemented the remote intent service to the Android platform, and measured the latency for
executing such tasks in a remote device. Experimental results confirm that the remote intent service,
for sending the intent plus retrieving the result, incurs additional delay within 250 milliseconds in total
and thus is practical."

Author Response File: Author Response.pdf

Round 2

Reviewer 3 Report

Comments and Suggestions for Authors

I greatly appreciate the improvements made in this version. I still have the feeling of not completely getting the “task-oriented operation” AND “app intactness” with existing applications (i.e. invoking a task, on another device, task which may consist of a set of functions performed by another application, not of running the application as it is). This is why the “task-oriented operation” in Table 1 still seems a bit forced. Please further clarify this distinction in the manuscript's opening sections to help readers better understand the conceptual contribution. Thank you.

Author Response

Comments 1: I greatly appreciate the improvements made in this version. I still have
the feeling of not completely getting the “task-oriented operation” AND “app intactness” with
existing applications (i.e. invoking a task, on another device, task which may consist of a set of
functions performed by another application, not of running the application as it is). This is why the
“task-oriented operation” in Table 1 still seems a bit forced. Please further clarify this distinction
in the manuscript’s opening sections to help readers better understand the conceptual contribution.
Thank you.
Response 1: Thank you for the concrete clarification of your point once again. We think that ”task-oriented
operation” was not the best choice in Table 1 for its meaning, as the term was meant to represent a
general action of executing tasks on other devices itself. What we wanted to express through the last
column of Table 1 was that the system can interpret the task’s details and take appropriate actions
accordingly, but the original wording did not properly imply such characteristics. We have renamed the
column header to ”task interpretation” and fixed the explanations as follows:
"During the past decade, the mobile computing community has actively worked on mobile collaboration aiming to provide users with more convenient and effective functionalities by networking smart
devices. Table 1 compares prior efforts with RIS in terms of the need for app modification (Source
code modification), the layer where the collaboration functionalities are implemented (Level of collaboration), whether devices can act as both providers and consumers of the collaborative functionalities
(Direction), ability to share additional resources other than a fixed type of object with other devices (Additional resource sharing), and the capacity to interpret the task details and adapt behavior
accordingly (Task interpretation)."
We think the table now provides much clearer criteria to compare our work to existing work. We
hope these changes better show our intended meaning.
As for “app intactness”, we are sorry that the term did not clearly represent our intention. Our
intended meaning of “app intactness” was that the app does not need to be modified to make use of
RIS (to invoke remote executions or to be remotely executed), meaning that RIS does not require any
kind of API calls to it. Tasks consisting of a set of functions that reside in the unmodified app can be
invoked through RIS when the content of the intent specifies such tasks. We have changed the wording
to “source code modification” (as the opposite meaning) in Table 1, and clarified in the Introduction
section that RIS does not require app modification and this is a significant advantage for existing apps.
With the added explanation in the following paragraph, we expect readers to better understand the
positioning of RIS in mobile collaboration systems more easily.
"In this work, we develop a novel system service for Android, Remote Intent Service (RIS), that
further extends the current mobile collaboration technologies. RIS supports task-oriented collaboration,
which we define as delegating a particular task in a device to a remote device that best fits to
execute it. An intent in Android is a messaging object that can be used to request an action to
another application component. It allows an application to start an activity or service even in another
application in the same device, so as to delegate a specific functionality to another capable application,
instead of implementing the functionality in itself. Such concept and capability of the intent greatly
facilitate realizing the task-oriented collaboration. Furthermore, existing applications leverage RIS
without requiring any modifications or awareness of the remote device, operating as if the target
application were installed locally on the same device. RIS transparently extends the current intent
processing procedure in Android so that an application in a device can also start an activity or service
in a remote device."

Author Response File: Author Response.pdf

Reviewer 4 Report

Comments and Suggestions for Authors

1. Points number 3, 4, 11, and 12 in the previous review report are not addressed at all in the revised manuscript even though they are fundamental in having a solid scientific value of the paper.
2. Even after adding more references in responding to point number 7 in the previous review report. Still we have around 50% of them dated before 2020. Meanwhile, there are around 30% of the references dated before 2015, which can be considered really old given the recent advances in such a field. Hence, there is a major concern about the recency of the used references.
3. The paper really needs full proof-reading
    

Comments on the Quality of English Language

1. Line 8: "task to other application" should be "task to another application"
2. Line 9: "we can see an attached document to an email" should be "we can view an attached document to an email"
3. Lines 4, 5: "a new kind of applications that run across multiple devices." should be "a new kind of applications that runs across multiple devices."
4. Lines 50, 51: "RIS supports the task-oriented collaboration which ..." should be "RIS supports task-oriented collaboration, which ..."

Author Response

Comments 1: Points number 3, 4, 11, and 12 in the previous review report are not
addressed at all in the revised manuscript even though they are fundamental in having a solid
scientific value of the paper.
Response 1: Thank you for showing your deep concern for the lack of explanation on technical aspects of our
work. After your second review, we came up with some ways to address these points within this version
of the paper. To provide diverse measures for RIS, we have conducted the following experiments:
• Performance evaluation with direct connection: The previous experiments were all performed with
both devices being connected to the same public access point. This may have caused concerns
that RIS may not work without such an external networking device. We have newly added this
experiment where both devices communicate with each other through the hotspot of one of the
smartphones, showing that the whole process can work solely with the functionality of both devices,
even in an isolated environment. This experimental result has been added to Figure 7, and the
following paragraph has been modified:
"Figure 7 shows the average latency for processing a single remote intent that triggers a specific
action of the main activity in the remote RISBench app. In case of communication through the public
access point (‘Pub. AP’), the intent (and file) transfer time from local to remote devices (i.e., ‘Transfer
to remote’ interval) takes the largest portion of the total latency in all cases. Although the time varies
greatly depending on the network condition and the amount of transferred data, it is noticeably larger
than the result intent (and file) transfer time from remote to local devices (i.e., ‘Transfer to local’
interval). This is because the former includes the time to establish a network session between two
devices, which is not included in the latter. However, the networking overhead can be significantly
reduced when devices are directly connected to each other (‘Direct’). The time for ‘Call local ICS’
significantly differs depending on whether the intent requires results or not. When it requires results,
the Dummy app is launched during the time, resulting in larger ‘Call local ICS’ times for ‘Launch &
return’ and ‘Launch & generate a file’ cases."
• Inspecting CPU and energy consumption: We have conducted an experiment to measure resource
consumption of RIS, mainly regarding its CPU and battery usage. Although a single execution of
the whole process is nearly instant and thus its resource consumption is negligible and not precisely
measurable, we thought it would still be valuable to evaluate resource usage under an extreme use
case by repeating the experiment many times. Thus, we have added a functionality in RISBench
that automatically repeats the experiments for 15 minutes at 1 Hz, and recorded both devices’
total and average resource consumptions. We think that these experiments will confirm that RIS
uses only a trivial amount of energy, and does not excessively use CPU to the point where the
performance of other apps are greatly affected during its execution. We have added Table 6 and
the following paragraph to show the experimental results:
"Table 6 shows the average CPU load and total battery consumption of the whole system when the
”Launch & Return” experiment which was repeated every second for 15 minutes (a total of 900 runs),
compared to the ”Idle” scenario where both devices keep on without addressing any intents. In both
scenarios, both devices maintained 50% display brightness without being charged. The results for the
local device show that even when RIS was extremely actively used, its CPU load increased only by
around 9.38 percentage points compared to when the device was idle and RIS consumed negligible
energy. Conversely, CPU load of the remote device increased by approximately 22.63 percentage points
and it consumed 4% of total battery capacity. This increase in resource consumption is unavoidable
for RIS, primarily because most of the overhead arises from launching the app, of which the operation
involves not only the app execution process but also storage access to open the APK file. Even though
the app used in this experiment is relatively lightweight compared to real-world apps, it still consumes
significantly more energy than other components of the RIS process."
We also wanted to include experiments that use various devices, but unfortunately, we could not
afford to buy more Android devices to work with. We have specified this in the revised paper, however,
that the performance of Pixel 5 is relatively low compared to most average mobile devices nowadays,
and therefore the performance of RIS is also likely to be better than shown in our paper when tested on
recent smartphones. We believe that the experiments we provided are enough to show that RIS works
with reasonable latency in most environments, even though we could not perform the actual tests in all
of them. We have specified these points in the Evaluation section of the revised paper as follows:
"Despite the overhead associated with remote processing, the total latency (under 250 ms for public
access points and under 200 ms for direct communication) remains sufficiently low for RIS to be
practical, except in cases where the service is used repeatedly in an interactive manner, which is
uncommon for intents. In most cases, both devices are controlled by a single user, and in such cases
the user has to move their head (or eye) from the local to the remote device, which makes the latency
of 250 ms hardly recognizable. Moreover, since the Pixel 5’s overall performance is lower than that of
most modern smartphones, we expect even lower latency if RIS is implemented in commercial products
in the future."
For point 11 in your previous review report, we regret to say that we could not find suitable methods
for direct comparison between RIS and other existing work, because RIS is a new form of mobile
collaboration and thus its characteristics are not quantitatively comparable. We would like to emphasize,
that we will improve RIS by integrating various other collaboration techniques into it so that RIS becomes
a platform for more general mobile collaboration. Once this is achieved, the operations of RIS will likely
have common aspects to be measured in the same way as other work has been measured. We promise
that its evaluation criteria will become richer in the future. We have added emphasis to this point in
the revised manuscript as follows:
"• Generalization of the service: The design of RIS relies on Android-specific features, mainly
regarding intents and the shared directory. These components are not available on other platforms, for example, iOS, and thus limiting its universal applicability. We are conducting further
research to develop a more generic platform-independent framework for mobile collaboration.
This would enable integration with existing solutions and we will be able to evaluate its performance comparatively to their prior implementations."
We also want to ensure that the latency of 250 ms is hardly noticeable in most practical cases,
considering that the general use case of RIS is not interactive and typically involves multiple devices
where the user has to move their focus onto the other device every time they use the functionality of
RIS. Also, the 250 ms value was derived from summing up the L-to-R and R-to-L phases, and each
phase has strictly lower latency than 200 ms. Furthermore, as our new experiments suggest, the latency
can be greatly improved when the devices are able to directly communicate with each other, reducing
the L-to-R phase latency to near 100 ms including the activity launch phase.
For point 4 in your previous review report, we have searched for the changes in newer Android
versions related to the execution of RIS. We have found that the feature and changes list mention
several points regarding security enhancement for intent and starting activity. We will need to apply
these restrictions to RIS if we migrate RIS to the latest version of Android. Other than these security
updates, we have found no critical change that heavily affects our design of RIS. Although it may take
some time for us to apply the rules regarding security & privacy, it should not require any fundamental
change to its design. We also checked the source code of Android 16 and concluded that our current
source code of RIS implementation needs to be modified only slightly to be integrated into Android 16.
However, although migrating RIS to Android 16 itself may not be too difficult, fixing the whole paper
based on the updated implementation is a large task that we could not complete within the revision
period. We have specified the points that need to be addressed for RIS to be migrated to a recent
version of Android in the ”Limitation and Future Work” section of the revised manuscript as follows:
"• Android version: RIS is built on top of LineageOS 19.1, which is based on Android 12. Migrating
RIS to newer versions may require a few fixes in its implementation to cope with the following
changes:
– Restrictions on specific intents: Android 14 introduced several new rules for implicit and
pending intents, as well as restrictions on starting activities from the background.
– Added rules for safer intents: Android 15 and 16 introduced stronger regulations to
improve the security of intents.
– Protection against intent redirection attacks: Android 16 improved its security policies
regarding intents to safeguard sensitive data from redirection attacks.
These changes mainly regarding security need to be taken into account by RIS, by checking if
the intent to be transferred follows updated policies and the remote app is compatible to them.
Other than the minor modifications needed to fulfill security requirements, to the best of our
knowledge, the overall execution flow of an app using the intent has not changed drastically
and we have not identified any critical alterations that would invalidate the core design of RIS.
We believe that implementing RIS on new Android versions remains feasible with our proposed
design. We also plan to implement an advanced version of RIS on the latest Android releases in
the future."

Comments 2: Even after adding more references in responding to point number 7 in the
previous review report. Still we have around 50% of them dated before 2020. Meanwhile, there are
around 30% of the references dated before 2015, which can be considered really old given the recent
advances in such a field. Hence, there is a major concern about the recency of the used references.
Response 2: Thank you for your concern that the references are outdated. Indeed, the references published
before 2015 can be considered obsolete due to how fast mobile technologies have evolved since then.
Following your suggestion, we have removed several references dated before 2015 that were mainly used
for the comparison with our work. We hope the remaining references show our respect to the work
that has been part of the history of mobile collaboration systems and also motivation for our work. In
replacement of the old references, we have added the following references that are dated after 2020:
"1. Distributed Collaborative Learning in Wireless Mobile Communication (2023)
2. Collaborative machine learning for energy-efficient edge networks in 6G (2022)
3. Towards video streaming analysis and sharing for multi-device interaction with lightweight dnns
(2021)
4. MTPS: A Multi-Task Perceiving and Scheduling Framework Across Multiple Mobile Devices (2024)
5. CrossChat: Instant Messaging across Different Apps on Mobile Devices (2023)
6. Pruid: Practical user interface distribution for multi-surface computing (2021)"
References 1, 2, and 3 show mobile collaboration system for machine learning, which is one of the
main purposes for collaborative systems in recent years. Reference 4 is a new framework that mainly
focuses on improving parallelism for collaborative tasks. Reference 5 introduces an architecture targeting
a practical use case of mobile collaboration. Reference 6 is another extension of FLUID (along with
FLUID-XP) that supports multi-surface computing by distributing UI elements across multiple mobile
devices. We think these references to recent work can show the recent trend of mobile collaboration and
better position of our work among the newest research efforts.

Comments 3: The paper really needs full proof-reading
Response 3: We are sorry for having left flaws in the previously revised version of the manuscript. We would
have liked to have more time to check the entire paper more thoroughly. This time, after applying the
points you suggested, we have re-read the whole manuscript multiple times, checking if the flow of our
logic is naturally reflected in each section and if there are grammar mistakes we may have previously
overlooked. We hope the revised manuscript is now more robust and professional.

Comments 4: Comments on the Quality of English Language
1. Line 8: ”task to other application” should be ”task to another application”
2. Line 9: ”we can see an attached document to an email” should be ”we can view an attached
document to an email”
3. Lines 4, 5: ”a new kind of applications that run across multiple devices.” should be ”a new
kind of applications that runs across multiple devices.”
4. Lines 50, 51: ”RIS supports the task-oriented collaboration which ...” should be ”RIS supports
task-oriented collaboration, which ...”
Response  4: Thanks for your comments. We have fixed all of them in the revised manuscript.

Author Response File: Author Response.pdf

Round 3

Reviewer 4 Report

Comments and Suggestions for Authors

The symbols used in columns 2, 5, and 6 in Table 1 are not standard ones and not understandable, please either define them at the bottom of the table or use descriptive names.

Comments on the Quality of English Language

1. Line 7: "enables a running application in a device can outsource" should be "enables a running application in a device to outsource"
2. Line 21 "used in smart televisions, tablets and watches" should be "used in smart televisions, tablets, and watches"
3. Line 26: "many researches have been developed" should be "many research efforts have been developed"
4. Line 597: "to conduct further researches" should be "to conduct further research"
5. Better use passive voice in scientific papers, for example: lines 608, 609, 612 ... etc.

Author Response

Comments 1: The symbols used in columns 2, 5, and 6 in Table 1 are not standard ones
and not understandable, please either define them at the bottom of the table or use descriptive
names.
Response 1: Thank you for pointing out the clarity issue of the column symbols. To make the terms more
understandable, we have moved the definitions of them from the first paragraph of the ”Related Work”
section to a note below Table 1 in the revised manuscript as follows:
"During the past decade, the mobile computing community has actively worked on mobile collabo-
ration aiming to provide users with more convenient and effective functionalities by networking smart
devices. Table 1 compares prior efforts with RIS in terms of source code modification, level of collabo-
ration, direction, additional resource sharing, and task interpretation."
"1. Source code modification indicates whether the source code of the existing apps needs to be
modified to use its functionality.
2. Level of collaboration indicates the layer in which the collaboration functionalities are imple-
mented.
3. Direction indicates whether devices can act as both providers and consumers of the collaborative
functionalities (bidirectional), or their roles are separated (one-way).
4. Additional resource sharing indicates whether the work supports sharing of resources other
than a fixed type of objects.
5. Task interpretation indicates whether the work interprets the task details and behaves adap-
tively."

Comments 2: Comments on the Quality of English Language
1. Line 7: ”enables a running application in a device can outsource” should be ”enables a running
application in a device to outsource”
2. Line 21 ”used in smart televisions, tablets and watches” should be ”used in smart televisions,
tablets, and watches”
3. Line 26: ”many researches have been developed” should be ”many research efforts have been
developed”
4. Line 597: ”to conduct further researches” should be ”to conduct further research”
5. Better use passive voice in scientific papers, for example: lines 608, 609, 612 ... etc.
Response 2: Thank you for further pointing out the flaws on English on our manuscript. We have fixed all
of them. For passive voice, we have changed the following sentences throughout the ”Limitation and
Future Work” section in the revised manuscript:
"• We have two plans to reduce the latency in such cases. → Two solutions are being considered to
reduce the latency in such cases.
• First, we will add streaming functionality support for multimedia files, where only a part of the
files is transferred whenever the app requests it. → First, streaming functionality for multimedia
files can be introduced, where only the necessary part of a file is transferred when the app requests
it.
• Second, we will introduce asynchronous file transfer. → Second, files can be transferred asyn-
chronously.
• To protect RIS from these risks, we will add encryption method for transmission, and introduce
a proper authentication phase when two devices are first connected to each other. → To protect
RIS from these risks, an encryption method will be applied during transmission, and a secure
authentication phase will be introduced for the initial connection between two devices.
• Along with the research of RIS, we are also looking for a way to provide a similar mobile collab-
oration support that is less (hopefully not at all) dependent on the platform. → Along with the
research on RIS, a way to provide similar mobile collaboration support, which is less dependent
on the platform, is being developed.
• We also plan to implement an advanced version of RIS on the latest Android releases in the
future. → In the future, an advanced version of RIS will also be implemented on the latest
Android releases.
• We are conducting further research to develop a more generic platform-independent framework
for mobile collaboration. → Further research on RIS is being conducted to develop a more generic,
platform-independent framework for mobile collaboration.
• This would enable integration with existing solutions and we will be able to evaluate its performance
comparatively to their prior implementations. → This will enable integration of RIS with existing
solutions, and the performance of RIS will be able to be evaluated comparatively to their prior
implementations."

Author Response File: Author Response.pdf