DETAILED ACTION
Status of Claims
This action is in reply to the application filed on 02/02/2026.
Claims 1 and 11 have been amended.
Claims 1-20 are currently pending and have been examined.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/02/2026 has been entered.
Response to Arguments
Applicant’s arguments filed 02/02/2026 with respect to the rejections under 35 USC § 103 have been considered but are not persuasive and/or moot in view of new grounds of rejection as disclosed below.
On pg. 12 of the Remarks, Applicant essentially argues (emphasis original):
“Clark's tasks are simply delivered to a volunteer client and are not embedded in its game binary. Clark's clients and tasks do not carry a TALP payload as required in Applicant's claimed invention. As such, Applicant respectfully asserts that Clark fails at least to teach or suggest systems or devices configured to carry an embedded payload of TALPs to replace one or more functions of the initial application invoked by software execution of an attractive/mobile application or software”
Examiner respectfully disagrees that Applicant’s Specification provides sufficient description to make the asserted distinction. AppSpec does not include the recited adjective “embedded” (see rejections under 112), nor does AppSpec provide any technical description as to how the TALPs are ‘carried as a cached payload’. Clark explicitly discloses the exemplary embodiment where “In some embodiments, the tasks may already have been provided, for example, as part of a game, with the client application” (¶0052) in view of this disclosure and, more critically, that Clark’s game + tasks have the same functional relationship as Applcant’s attractive application + TALPs (i.e. task/TALP consumes unused/idle cycles while the game is running) Examiner maintains they teach the limitation.
Applicant’s remaining arguments are moot in view of new grounds of rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(a) and 112(b):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint invention at the time the application was filed, had possession of the claimed invention.
Claim 1 recites the attractive application is linked to and configured to carry an embedded TALP payload of the one or more cached sets of associated TALPs which is not supported by Applicant’s as-filed Specification (AppSpec). Claim 11 similarly recites providing the selected one or more correct TALPs as an embedded TALP payload which is not supported by AppSpec. Examiner refers to the rejections under 112(b) below for further discussion.
Any claim listed in the rejection heading not explicitly listed in the body is rejected for being dependent upon a rejected claim.
Claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the attractive application is linked to and configured to carry an embedded TALP payload of the one or more cached sets of associated TALPs. It is unclear what the adjective “embedded” requires as recited in the claim. The term does not have a standardized meaning when describing the relationship between two pieces of software. AppSpec provides no guidance as the term does not appear therein (see rejections under 112(a) above). Claim 11 similarly recites providing the selected one or more correct TALPs as an embedded TALP payload, but is even further ambiguous as it recites the “embedded” adjective with no indication as to what it is “embedded” in.
In order to advance prosecution, Examiner has interpreted the language expressing same metes and bounds as their recited functional relationship, i.e. “processing, at the mobile device, such that idle compute cycles of the mobile device are used by the one or more cached sets of associated TALPs while the attractive application is executing”
Any claim listed in the rejection heading not explicitly listed in the body is rejected for being dependent upon a rejected claim.
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, 9, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Clark (US 2018/0349201 A1) in view of Howard et al. (US 2020/0210162 A1) in further view of Mintz et al. (“Adaptive Distributed Computing Middleware for Computational Finance Applications”, 2009).
Claim 1:
Clark discloses the limitations as shown in the rejections below:
A method of converting one or more mobile applications on a mobile device (client device) to a distributed platform of networked mobile devices (volunteer computing grid), comprising: providing one or more cached set of associated [tasks] (work unit (WU)/task/”chunks” for e.g. data mining, machine learning, see below in view of Howard regarding TALPS), providing an attractive application, at the mobile device (e.g. interactive application, game, media streaming application) (see at least ¶0004, 0018-0020, 0039, 0051, 0056; mobile: ¶0024: “client devices 106-114 include…mobile telephone or smartphone 108, a tablet computer 110, a laptop computer 112, a video game console”, ¶0034-0036, 0048; FIG. 1, 3).
wherein the attractive application is linked to and configured to carry an embedded [task] payload (e.g. “tasks may already have been provided as part of a game, with the client application” (¶0052)) of the one or more cached set of associated [tasks]; and processing at the mobile device such that idle compute cycles of the mobile device are used by the one or more cached sets of [tasks] while the attractive application is executing (¶0004, 0018, 0039-0041, 0051, 0056, 0060). Exemplary quotations:
“video games may provide an opportunity for volunteer computing by utilizing computing resources (e.g., processing power, storage capability, and network connections) while the user is playing the video game or during idle time.” (¶0018).
“the server 200 then provides one or more client applications (step 410). For example, in step 410, the server 200 may provide software to client devices (¶0047)…Computing tasks are tasks that utilize computing resources, such as processing, computing, storage, or network resources, of a computing device.)… the tasks may already have been provided, for example, as part of a game, with the client application in step 410.” (¶0052).
As indicated above, Clark discloses distributing parallel tasks to perform iterative ML, data mining, analytics processing, which are at least analogous to the recited time-affecting linear pathways (TALPs), but Clark does not refer to them as such and does not explicitly disclose the subject matter.
Howard, however, discloses a system and method for “for creating and executing parallel TALPs” (¶0070) by decomposing a source program (¶0153, 0174-0177), and further discloses (¶0050-0053, 0059-0068) wherein the one or more cached sets of associated TALPs include at least one algorithmic execution pathway derived from an initial application to optimize and reduce compute processing time with one or more software control statements (“non-loop control statements”) removed in the initial software application.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention modify Clark to implement tasks as TALPs to increase execution predictably and efficiency (Howard ¶0253, 0174), and more generally, because it represents the simple substitution of one known type of executable job for another to obtain predictable results.
Regarding the limitation that the TALPs are provided to at least replace one or more functions of the initial application invoked by execution of the attractive application. Examiner notes the limitation is non-limiting intended use as written as it only the intent behind their distribution; but in the interests of expediting prosecution, Examiner notes Clark/Howard does not explicitly recite the subject matter and Examiner additionally refers to additionally refers to Mintz.
Mintz discloses an analogous system which facilitates automatic parallelization (pg. 1, Abstract) of an existing/initial application for distributed execution on remote notes, wherein “application developers, encapsulate these details, and provides a so-called zFunction z_F for every parallelizable function F” and discloses (pg. 5, § 3.2; pg. 6, col. 2; pg. 7) the zFunctions are provided to at least replace one or more functions of the initial application invoked by execution at a remote volunteer compute resource … zFunction call z_F is a drop-in replacement for the invocation of its corresponding serial function call to F” (pg. 5, § 3.2) executed using idle cycles of a remote node.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention modify Clark/Howard with the function replacement of Mintz because it “enhances complex compute-intensive applications by creating adaptive, real-time, and distributed computing on demand. By utilizing the servers and desktops available within an organization or in a cloud, Zircomp can substantially improve the performance of parallel applications at low cost” (Mintz pg. 8, sect. 6).
Claim 9:
The combination of Clark/Howard/Mintzdiscloses the limitations as shown in the rejections above. Clark further discloses providing one or more co-worker devices (peer client/volunteer devices), wherein the one or more co-worker devices include a co-worker receiver software module and a co-worker transmitter software module. (¶0018, 0024, 0039, 0060-0061).
Claim 10:
The combination of Clark/Howard/Mintz discloses the limitations as shown in the rejections above. Clark further discloses providing a MADP website in operative communication with a client receiver software module of a stationary computer hardware system (¶0044-0046, 0050).
Claims 2-4 and 6-8 are rejected under 35 U.S.C. 103 as being unpatentable over Clark (US 2018/0349201 A1) in view of Howard et al. (US 2020/0210162 A1) in further view of Mintz et al. (“Adaptive Distributed Computing Middleware for Computational Finance Applications”, 2009). In further view of Choi (“Group-based Adaptive Scheduling Mechanism in Desktop Grid”, 2007).
Claims 2-4 and 8:
The combination of Clark/Howard/Mintz discloses the limitations as shown in the rejections above. Clark further discloses (¶0018, 0024) providing one or more co-worker mobile devices (peer client/volunteer devices) and further discusses server implementation options (¶0031) but does not specifically disclose a control mobile device.
Choi, however, is directed architecture implementations for volunteer grids, analogous to Clark/Howard and the claim, including an embodiment (pg. 83-83; 98-101; 104; pg. 100, Fig. 4.6) directed to forming groups of volunteer (co-worker) node devices including selecting a node to be a “deputy” volunteer (control mobile device) which is provided a scheduling mobile agent (S-MA) ([claim 4 and 8] control transmitter software module and a control receiver software module in operative communication with a MADP client (Server) on a stationary computer hardware system…control software module to facilitate processing and messaging between a MADP client (Server) and one or more co-worker devices) to facilitate task distribution to the group/coworker nodes forming a group-based adaptive volunteer grid (Claim 3 Mobile Applications to Distributed Platforms (MADP) server environment)
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention modify Clark/Howard/Mintz to employ the group base adaptive scheduling of Choi to allow the scheduler to adapt to dynamic environmental changes as well as various properties of volunteers, increasing reliability and reducing overhead (Choi pg. 71-72, 97-99).
Claims 6 and 7:
The combination of Clark/Howard/Mintz/Choi discloses the limitations as shown in the rejections above. Clark further discloses the MADP client (server) includes a client receiver software module and a client transmitter software module (network interface) executing on a stationary computer hardware system...wherein the MADP client (server) manages customer data and the one or more cached set of associated TALPs on a stationary computer hardware system (¶0023, 0024-0025, 0027, 0031, 0046-0047, 0053).
Claims 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Clark (US 2018/0349201 A1) in view of Choi (“Group-based Adaptive Scheduling Mechanism in Desktop Grid”, 2007) in further view of Howard et al. (US 2020/0210162 A1) in further view of Mintz et al. (“Adaptive Distributed Computing Middleware for Computational Finance Applications”, 2009).
Claim 11:
Clark discloses the limitations as shown in the rejections below:
providing one or more cached sets of [tasks] (task/project for e.g. data mining machine learning), to one or more [worker](see below in view of Howard and Choi regarding TALPs and control devices) devices in an ad hoc mobile network; providing a discretized dataset (work unit (WUs)/shards) to one or more co-worker devices (client/volunteer devices) in an ad hoc mobile network; (¶0004, 0024, 0039, 0052-0054).
automatically selecting one or more correct [tasks] as an embedded [task] payload required for processing based on the discretized dataset; providing the selected one or more correct [tasks] to the one or more control devices…of the ad hoc mobile device network; (¶0047-0048, 0039, 0052-0053).
processing, at the one or more co-worker devices, such that idle compute cycles of the one or more co-worker devices are used by the one or more correct [tasks] to process the discretized data; (¶0018, 0039-0041, 0051, 0056, 0060). and
agglomerating output data values by the one or more control devices to produce a completed solution (¶0057-0058, 0062-0063).
“distributed computing tasks, including gathering work units (WU), processing WU, storage, and sending WU results back to the server 200. The thread on the client device 300 issues pull request(s) to the server 200. The server 200 provides the client device 300 with a chunk of data (e.g., WU) related to the problem(s) being processed via the server 200. The server 200 can also provide the algorithm to be used to analyze the data (¶0039)...In providing the one or more client applications to one or more or a plurality of client devices, the program code in the one or more client applications provided to different client devices may be different. For example, program code for requesting user input via an interactive application may be sent to some client devices (e.g., based on the type of device such as gaming devices or personal electronic devices” (¶0048).
As indicated above, Clark distributes tasks directly to volunteer clients (co-workers) and does not specifically disclose an intermediate control device for disseminating tasks.
Choi, however, is directed for volunteer grid architecture implementations, analogous to Clark and the claim, where:
“A job is divided into sub-jobs that have their own specific input data. The sub-job is called a task. The server allocates tasks to volunteers using scheduling mechanisms. Each volunteer executes its task when idle, while continuously requesting data from its server. When each volunteer subsequently finishes its task, it returns the result of the task to the server.” (pg. 2)
Choi further discloses an embodiment (pg. pg. 2; 83-83; 98-101; 104; pg. 100, Fig. 4.6) directed to forming groups of volunteer (co-worker) node devices including selecting a node to be a “deputy” volunteer (control device) which is provided a scheduling mobile agent (S-MA) which “distributes the task mobile agents (T-MA) that consist of parallel code and data to the members of the scheduling group.” (pg. 104) disclosing automatically selecting one or more correct [tasks] required for processing based on the discretized dataset; providing the selected correct [tasks] to the one or more control devices…of the ad hoc mobile device network; (¶0047-0048, 0039, 0052-0053; pg. 100, Fig. 4.6).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention modify Clark to employ the group base adaptive scheduling of Choi to allow the scheduler to adapt to dynamic environmental changes as well as various properties of volunteers, increasing reliability and reducing overhead (Choi pg. 71-72, 97-99).
As indicated above, Clark discloses distributing parallel tasks to perform iterative ML, data mining, analytics processing, which are at least analogous to the recited time-affecting linear pathways (TALPs), but Clark does not refer to them as such and does not explicitly disclose the subject matter.
Howard, however, discloses a system and method for “for creating and executing parallel TALPs” (¶0070) by decomposing a source program (¶0153, 0174-0177), and further discloses (¶0050-0053, 0059-0068) wherein the one or more cached sets of associated TALPs include at least one algorithmic execution pathway derived from an initial application to optimize and reduce compute processing time with one or more software control statements (“non-loop control statements”) removed in the initial software application.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention modify Clark to implement tasks as TALPs to increase execution predictably and efficiency (Howard ¶0253, 0174), and more generally, because it represents the simple substitution of one known type of executable job for another to obtain predictable results.
Regarding the limitation that the TALPs are provided to at least replace one or more functions of the initial software application invoked by software execution on at least the one or more co-worker devices. Examiner notes the limitation is non-limiting intended use as written as it only the intent behind their distribution; but in the interests of expediting prosecution, Examiner notes Clark/Choi/Howard does not explicitly recite the subject matter and Examiner additionally refers to additionally refers to Mintz.
Mintz discloses an analogous system which facilitates automatic parallelization (pg. 1, Abstract) of an existing/initial application for distributed execution on remote notes, wherein “application developers, encapsulate these details, and provides a so-called zFunction z_F for every parallelizable function F” and discloses (pg. 5, § 3.2; pg. 6, col. 2; pg. 7) the zFunctions are provided to at least replace one or more functions of the initial application invoked by execution at a remote volunteer compute resource … zFunction call z_F is a drop-in replacement for the invocation of its corresponding serial function call to F” (pg. 5, § 3.2) executed using idle cycles of a remote node.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention modify Clark/Choi/Howard with the function replacement of Mintz because it “enhances complex compute-intensive applications by creating adaptive, real-time, and distributed computing on demand. By utilizing the servers and desktops available within an organization or in a cloud, Zircomp can substantially improve the performance of parallel applications at low cost” (Mintz pg. 8, sect. 6).
Claim 12
The combination of Clark /Choi/Howard/Mintz discloses the limitations as shown in the rejections above. Clark further discloses providing the completed solution to a customer (¶0057-0058, 0062-0063).
Claims 13-17:
The combination of Clark /Choi/Howard discloses the limitations as shown in the rejections above. Clark /Choi/Howard/Mintz further discloses the limitations as shown:
[claim 13] wherein a combination of the one or more control devices and the one or more co-worker devices form a MADP server environment (volunteer grid) (Clark ¶0024-0027; Choi pg. 83-83; 98-101; 104; pg. 100, Fig. 4.6),
[claim 14] wherein the one or more control devices include a control transmitter software module and a control receiver software module in operative communication with a MADP client (server) (Choi pg. 83-83; 98-101; 104; pg. 100, Fig. 4.6)
[claim 15-17] wherein the MADP client (server) includes a stationary computer hardware system…wherein the MADP client (server) includes a client receiver software module and a client transmitter software module…wherein the MADP client (server) manages customer data and the one or more TALPs (Clark ¶0023, 0024-0025, 0027, 0031, 0046-0047, 0053)
Claim 18:
The combination of Clark /Choi/Howard/Mintz discloses the limitations as shown in the rejections above. Choi further discloses wherein the one or more control devices include a control software module (Mobile Agent facilitate processing and messaging between a MADP client and the one or more co-worker devices (Choi pg. 100; pg. 104-105)
Claim 19:
The combination of Clark /Choi/Howard/Mintz discloses the limitations as shown in the rejections above. Clark further discloses the one or more co-worker devices include a co-worker receiver software module and a co-worker transmitter software module (¶0022-0026).
Claim 20:
The combination of Clark /Choi/Howard/Mintz discloses the limitations as shown in the rejections above. Clark further discloses providing a MADP website in operative communication with a client receiver software module of a stationary computer hardware system (¶0044-0046, 0050).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Clark (US 2018/0349201 A1) in view of Howard et al. (US 2020/0210162 A1) in further view of Mintz et al. (“Adaptive Distributed Computing Middleware for Computational Finance Applications”, 2009) in further view of Choi (“Group-based Adaptive Scheduling Mechanism in Desktop Grid”, 2007) in further view of Official Notice.
Claims 5:
The combination of Clark/Howard/Mintz/Choi discloses the limitations as shown in the rejections above. Each of Clark and Choi’s architectures includes a server (MADP client) but do not disclose it includes a rack-mounted system. However, Examiner takes Official Notice that rack mounted system implementations are old and well-known, and It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to deploy the servers of Clark/Howard/Choi as rack-mounted system to efficiently organize and maintain the server’s computing resources.
Conclusion
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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 use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
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.
/P. M./
Paul Mills
06/27/2026
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights