DETAILED ACTION
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439).
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in China 6/23/2021. It is noted, however, that applicant has not perfected priority (i.e. file a translation of the application if it is not in English) and effective filing date of application is 6/22/2022.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 5, 8-11, 13, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Vane (U.S. PG PUB 2020/0110643) in view of Salehpour (U.S. Patent 9,509,697).
Regarding claim 1, Vane teaches a service process invoking method, comprising:
obtaining, by an application process, a context of a binder process from a call stack (see ¶[0126] “The Android operating system may also provide a driver that facilitates and enables inter-process communication (IPC) between processes, including between frameworks and the HAL. This IPC driver may be referred to as “binder”. The binder driver manages traffic between processes by using binder contexts”, see ¶[0122] “Platform architecture 600 is represented by a “stack” in which successive layers represent increasing levels of abstraction from a bottom physical device layer.”);
obtaining, by the application process, a handle of a service process based on the context of the binder process (see ¶[0310] “As noted, the above-described modules can interact with message handler 1542. Message handler 1542 generally serves to interact with a master service of the wearable computing device 1510 and one or more microservices provided by remote computing devices 1580a to 1580d. Message handler 1542 can consolidate messages received from each of the local modules and handle delivery to the appropriate cloud microservice, e.g., via the gateway service of remote computing device 1580b. Similarly, message handler 1542 can receive consolidated messages from cloud microservices, e.g., via the gateway service of remote computing device 1580b and deliver the individual messages to the appropriate local module for further processing.”),
wherein the obtaining the handle of the service process comprises:
running, by the application process, a program of the binder process based on the context of the binder process, to obtain a handle of a service manager process (see ¶[0317] “Local message handler can relay data to and from application programs 1511 or at least one local system service” see ¶[0158] “Generally, host routing service 755 may implement a host data communications endpoint by calling functions from the companion service library to handle data routing to or from the host device.”);
obtaining, by the application process, a context of the service manager process based on the handle of the service manager process (see ¶[0132] “In response to a connection attempt, the processor creates an inter-process communication context specific to the requesting application or service, and the requested HAL interface (which corresponds to a physical device).”);
and running, by the application process, a program of the service manager process based on the context of the service manager process (see ¶[0133] “Next, at 1625, the processor provides a socket interface within the created IPC context. The socket interface may be, or may emulate, TCP sockets or UNIX domain sockets. The application or service may thereafter communicate with the physical device, via the HAL interface, using a socket-based communication scheme.”),
to obtain the handle of the service process based on an identifier of a system service requested by the application process (see ¶[0221] “When encapsulating, each packet may be associated with a connection identifier, which can be unique for each discrete socket that is accessing the physical channel.”);
running, by the application process, a program of the binder process based on the context of the binder process, to obtain a context of the service process based on the handle of the service process (see ¶[0310] “As noted, the above-described modules can interact with message handler 1542. Message handler 1542 generally serves to interact with a master service of the wearable computing device 1510 and one or more microservices provided by remote computing devices 1580a to 1580d.”); and
running, by the application process, a program of the service process based on the context of the service process (see ¶[0132] ”In response to a connection attempt, the processor creates an inter-process communication context specific to the requesting application or service, and the requested HAL interface (which corresponds to a physical device).” ), to respond to a binder request, of the application process, requesting a system service provided by the service process (see ¶[0189] “The wearable computing device receives the request at 818 and transmits a services list to the host computing device in response”).
Vane does not expressly disclose, however Salehpour teaches obtaining from a call stack (see col. 8, lines 57-67, “In some examples, inspection module 108 may use a call stack to identify one or more methods that initiated a call to a shared library by iterating through the stack frames of the call stack. Using FIG. 5 as an example, inspection module 108 may use call stack 210 to identify methods 534-540 that initiated a call to API method 214 of shared library 212 by iterating through stack frames 514-520. On some platforms (e.g., the ANDROID platform), the inspection module 108 may be able to identify the method name, class name, and/or package name associated with the method represented by a stack frame”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Vane by adapting Salehpour store a record of methods called at the run time of a process and the order in which the methods were called (see col. 7, lines 39-45 of Salehpour).
Regarding claim 5, Vane teaches wherein the application process runs on a processor (see ¶[0009]).
Regarding claim 8, Vane teaches wherein the running, by the application process, the program of the binder process based on the context of the binder process, to obtain a handle of a service manager process comprises: running, by the application process, the program of the binder process based on the context of the binder process, to obtain the handle of the service manager process from a memory of the binder process (see ¶[0127] “In the Android operating system, the default IPC binder architecture incurs delays as data being relayed between processes may be copied in memory several times by binder.”).
Regarding claim 9, Vane teaches wherein before the running, by the application process, a program of the service manager process based on the context of the service manager process, to obtain the handle of the service process based on an identifier of a system service requested by the application process, the method further comprises: obtaining, by the service process, the context of the binder process (see ¶[0126] “The Android operating system may also provide a driver that facilitates and enables inter-process communication (IPC) between processes, including between frameworks and the HAL. This IPC driver may be referred to as “binder”. The binder driver manages traffic between processes by using binder contexts”);
obtaining, by the service process, the handle of the service manager process based on the context of the binder process (see ¶[0310] “As noted, the above-described modules can interact with message handler 1542. Message handler 1542 generally serves to interact with a master service of the wearable computing device 1510 and one or more microservices provided by remote computing devices 1580a to 1580d. Message handler 1542 can consolidate messages received from each of the local modules and handle delivery to the appropriate cloud microservice, e.g., via the gateway service of remote computing device 1580b. Similarly, message handler 1542 can receive consolidated messages from cloud microservices, e.g., via the gateway service of remote computing device 1580b and deliver the individual messages to the appropriate local module for further processing.”);
running, by the service process, the program of the binder process based on the context of the binder process, to obtain the context of the service manager process based on the handle of the service manager process (see ¶[0310] “As noted, the above-described modules can interact with message handler 1542. Message handler 1542 generally serves to interact with a master service of the wearable computing device 1510 and one or more microservices provided by remote computing devices 1580a to 1580d.”);
running, by the service process, the program of the service manager process based on the context of the service manager process (see ¶[0132] ”In response to a connection attempt, the processor creates an inter-process communication context specific to the requesting application or service, and the requested HAL interface (which corresponds to a physical device).” ), to respond to a binder request, of the application process, requesting a system service provided by the service process (see ¶[0189] “The wearable computing device receives the request at 818 and transmits a services list to the host computing device in response”),
to store, in an associated manner, an identifier of a system service provided by the service process and the handle of the service process in a memory of the service manager process (see ¶[0158] “Generally, host routing service 755 may implement a host data communications endpoint by calling functions from the companion service library to handle data routing to or from the host device. As noted above, a corresponding companion service library may also be used by the client data communications endpoint in application 724 or proxy service 726. A data routing service 730 of wearable computing device 710 may also make use of the companion service library.”); and
the running, by the application process, a program of the service manager process based on the context of the service manager process (see ¶ [0317] “Local message handler can relay data to and from application programs 1511 or at least one local system service 1512. Local system services 1512 may be, for example, a weather service, calendar service, navigation service, maps service, configuration service, or other service. At least some local system services 1512 may have counterpart microservices provided by a remote computing device 1580. For example, the system weather service may query a weather microservice provided by a remote computing device 1580 for weather updates. The query may be transmitted, and response received, via the host computing device, as described herein.”),
to obtain the handle of the service process based on an identifier of a system service requested by the application process (see ¶[0302] “In some implementations, socket module 1544 may be used to handle protocol encapsulation and de-encapsulation, for example by using the companion service libraries described herein. In some cases, socket module 1544 may implement a host routing service, such as host routing service 755.”) comprises:
running, by the application process, a program of the service manager process based on the context of the service manager process (see ¶ [0317] “Local message handler can relay data to and from application programs 1511 or at least one local system service 1512. Local system services 1512 may be, for example, a weather service, calendar service, navigation service, maps service, configuration service, or other service. At least some local system services 1512 may have counterpart microservices provided by a remote computing device 1580. For example, the system weather service may query a weather microservice provided by a remote computing device 1580 for weather updates. The query may be transmitted, and response received, via the host computing device, as described herein.”),
to obtain, from the memory of the service manager process, the handle of the service process based on the identifier of the system service requested by the application process (see ¶[0127] “In the Android operating system, the default IPC binder architecture incurs delays as data being relayed between processes may be copied in memory several times by binder.”).
Regarding claim 10, Vane teaches wherein the running, by the service process, the program of the binder process based on the context of the binder process, to obtain a handle of a service manager process comprises: running, by the service process, the program of the binder process based on the context of the binder process, to obtain the handle of the service manager process from a memory of the binder process (see ¶[0127] “In the Android operating system, the default IPC binder architecture incurs delays as data being relayed between processes may be copied in memory several times by binder.”).
Regarding claim 11, is an electric device claim, corresponding with claim 1, and is rejected for the same reasons. In addition, Vane teaches an electronic device, comprising a processor and a memory (see ¶[0008]).
Regarding claim 13, is a medium claim, corresponding with claim 1, and is rejected for the same reasons. In addition, Vane teaches a non-transitory, computer-readable storage medium, storing instructions (see ¶[0060]).
Regarding claim 17, is a system claim, corresponding with claim 1, and is rejected for the same reasons. In addition, Vane teaches at least one processor and at least one interface circuit (see ¶[0061]); each configured to read and instructions stored in a memory, and send the instructions to the at least one processor (see ¶[0062]).
Claims 2, 3, 4, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Vane (U.S. PG PUB 2020/0110643) in view of Salehpour (U.S. Patent 9,509,697) as applied to claim 1 and 17 above, further in view of Guo et al. (U.S. PG PUB 2016/0344846).
Regarding claim 2, Vane and Salehpour do not expressly disclose, however, Guo teaches the context of the binder process comprises one or more of a value of a register used by the binder process (see ¶[0056] “On the other hand, the IPC Service responds to requests of all the applications and assigns corresponding services to the applications. When receiving the request of the application, the IPC Service acquires a requested Binder reference according to the package name, then calls an interface of the Binder, and forwards data.”), a stack address used by the binder process, or a page table used by the binder process.
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Vane and Salehpour by adapting Guo for mutual communication between system-level applications and user applications, and virtualized as a client side (see ¶[0012] of Guo).
Regarding claim 3, Vane and Salehpour do not expressly disclose, however, Guo teaches wherein the context of the service manager process comprises one or more of a value of a register used by the service manager process, a stack address used by the service manager process, or a page table used by the service manager process (see ¶[0058] “It is assumed that an application A sends data to an application B. When receiving a request from the application A, the IPC Service processes a header of the received data packet, parses out an object to which the data packet is to be sent, that is, the application B, and then acquires a Binder reference of the application B from a stored lookup table, and calls the reference of the application B, thus sending data to the application B. If the object to which the data packet is to be sent cannot be found in the lookup table, it indicates that the application B has not been started, and in this case, the data packet may be discarded directly, because all application that inherit from this communication mechanism will initiate registration and service binding to the IPC Service when being started.”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Vane and Salehpour by adapting Guo for mutual communication between system-level applications and user applications, and virtualized as a client side (see ¶[0012] of Guo).
Regarding claim 4, Vane teaches wherein the running, by the application process, the program of the binder process based on the context of the binder process, to obtain a handle of a service manager process comprises: running, by the application process, the program of the binder process based on the context of the binder process, to obtain the handle of the service manager process from a memory of the binder process (see ¶[0127] “In the Android operating system, the default IPC binder architecture incurs delays as data being relayed between processes may be copied in memory several times by binder.”).
Regarding claim 18, is a system claim corresponding to claim 2 above, and is rejected for the same reasons.
Regarding claim 19, is a system claim corresponding to claim 3 above, and is rejected for the same reasons.
Response to Arguments
Applicant's arguments filed 8/24/2026 have been fully considered but they are not persuasive.
Regarding priority documents, there is no English translation of the priority document, therefore, applicant has not perfected priority, the application effective filing date is 6/22/2022.
All claim objections have been withdrawn in light of applicants amendments.
All 35 USC 112 rejections have been withdrawn in light of applicants amendments.
Regarding 103 rejections, applicants argue that Vane does not disclose obtaining a Binder context from a call stack. Examiner has cited Salehpour as disclosing this limitation.
Applicants argue Vane does not disclose “running, by the application process, a program of the binder process based on the context of the binder process, to obtain a handle of a service manager process.” Applicants state that Vane’s context manger does not describe the service manager process.
Examiner disagrees. Applicant has not pointed out how a service manager differs from a context manager, and examiner does not find the argument persuasive.
Applicants argue that Vane does not disclose “obtaining, by the application process, a context of the service manager process based on the handle of the service manager process” and argues that Vane only teaches communications routing.
Examiner disagrees. Vane teaches obtaining a context of the service manager by describe an attempt to acquire the context of the service, see ¶[0132] “In response to a connection attempt, the processor creates an inter-process communication context specific to the requesting application or service, and the requested HAL interface (which corresponds to a physical device).
Applicants argue that Vane does not disclose “handle of service manager process” or “the handle of the service process.”
Examiner disagrees. Vane discloses handle by disclosing a handler can relay data to and from application programs or at least one local system service, see ¶[0317].
Applicants argue that Vane does not disclose “running, by the application process, a program of the binder process based on the context of the binder process, to obtain a handle of a service manager process; obtaining, by the application process, a context of the service manager process based on the handle of the service manager process; and running, by the application process, a program of the service manager process based on the context of the service manager process, to obtain the handle of the service process based on an identifier of a system service requested by the application process.”
Examiner disagrees. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicants argue that Salehpour stack technique would not result in the subject matter of claim 1. Examiner disagrees. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jung et al. (U.S. PG PUB 2022/0405385) teaches a secure container construction device and method executable by an Android application, and a computer-readable recording medium on which a program thereof is recorded, the device and the method being capable of summoning a container at an application level without root privilege while showing performance that is faster than that of a conventional secure container technology, and thus can be implemented without invading an Android framework.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARINA YUN whose telephone number is (571)270-7848. The examiner can normally be reached Mon, Tues, Thurs, 9-4 (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to call.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached on (571) 270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Carina Yun
Patent Examiner
Art Unit 2194
/CARINA YUN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights