DETAILED ACTION
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/30/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Examiner’s Note
The Examiner cites particular columns, paragraphs, figures, 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 also apply. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in its 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.
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, 4, 7-8, 11, 14-15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Weld et al. (US 20190235913 A1) hereafter Weld in view of Weber (US 20030074520 A1), further in view of Brazier (US 20120266182 A1), further in view of Meijer et al. (US 20150128149 A1) hereafter Meijer.
Regarding claim 1, Weld teaches:
A system comprising:
at least one hardware processor (Paragraph 106; “OS 510 can execute directly on the bare hardware 520 (e.g., processor(s) 604) of computer system 600.”);
and at least one non-transitory memory storing instructions (Paragraph 114; “Main memory 606 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 604. Such instructions, when stored in non-transitory storage media accessible to processor 604, render computer system 600 into a special-purpose machine that is customized to perform the operations specified in the instructions.”), which, when executed by the at least one hardware processor, cause the system to:
receive a request to perform multiple operations on multiple threads of the processor to perform a requested process (Paragraph 45; “two CPU bound tasks are incoming at the same time, using the first and second mappings as discussed herein, one task may be assigned 5 threads, where another task may also be assigned 5 threads, and the tasks may execute concurrently”, where an incoming task is interpreted as a received request. The task is assigned multiple threads, thereby performing multiple operations on multiple threads of the processor, which may occur concurrently.);
wherein the request to perform the multiple operations on multiple threads of the processor causes the multiple operations to be run concurrently (Paragraph 45; “two CPU bound tasks are incoming at the same time, using the first and second mappings as discussed herein, one task may be assigned 5 threads, where another task may also be assigned 5 threads, and the tasks may execute concurrently” explicitly discloses concurrent execution.);
wherein an operation is a structured set of tasks used to perform a specific computation required to execute the requested process (Paragraph 40; “when a client invokes a graph processing task such as “Load Graph”, the set of workload characteristics for that task are looked-up in the first mapping 202, and then using the looked-up set of workload characteristics from the first mapping 202, the corresponding set of execution parameters is looked up in the second mapping 204.”, where load graph and run analytics perform a specific set of tasks associated with a requested process.);
analyze the multiple operations (Paragraph 40; “when a client invokes a graph processing task such as “Load Graph”, the set of workload characteristics for that task are looked-up in the first mapping 202, and then using the looked-up set of workload characteristics from the first mapping 202, the corresponding set of execution parameters is looked up in the second mapping 204. The looked-up set of execution parameters is used to adjust the thread pool configuration for each task. Thus, using the first and second mappings provides fine grained control of the thread pool configuration for each task.”, which looks up workload characteristics for a task, thereby analyzing the multiple operations);
wherein analyzing the multiple operations determines a type of operation or dependency of an operation on other operations (Paragraph 37; “FIG. 2 shows a second mapping 204 of sets of workload characteristics such as [IO_bound, parallel], [IO_bound, sequential], [CPU bound, long running, parallel], [CPU_bound, long running, sequential], [CPU_bound, short, sequential], [Caller, interactive, sequential] to sets of execution parameters. For example, the workload characteristic set: [IO_bound, parallel] is mapped to the execution parameter set: [IO thread pool, default thread pool size]. Thus, the second mapping 204 provides how the workload characteristics are mapped to thread pools and execution parameters. In an embodiment, a set of execution parameters comprises one or more execution parameters.”, the mapping of workload characteristics corresponding to an analysis of the type of operation.);
categorize the multiple operations based on operation type or dependency on other operations (Paragraph 37; “FIG. 2 shows a second mapping 204 of sets of workload characteristics such as [IO_bound, parallel], [IO_bound, sequential], [CPU bound, long running, parallel], [CPU_bound, long running, sequential], [CPU_bound, short, sequential], [Caller, interactive, sequential] to sets of execution parameters. For example, the workload characteristic set: [IO_bound, parallel] is mapped to the execution parameter set: [IO thread pool, default thread pool size]. Thus, the second mapping 204 provides how the workload characteristics are mapped to thread pools and execution parameters. In an embodiment, a set of execution parameters comprises one or more execution parameters.”, discloses mapping workload characteristic sets to execution parameter sets, corresponding to a categorization based on operation type.);
generation (Paragraph 84; “one or more processors and memory (such as random access memory (RAM)) that stores software instructions that, when executed, cause the one or more processors to perform graph analytics operations, such operations including generating data in-memory or persistently”.);
execute, on a single thread of the processor, the tasks (Paragraph 35; “tasks submitted to the direct caller execution bound thread pool execute directly on a thread that handles a request to execute the graph processing task. For example, when a request in received to execute a graph processing task, a thread is assigned to handle the request. Tasks submitted to the direct caller execution thread pool will directly execute on the thread assigned to handle the request.”, the one thread assigned to handle the request corresponding to the single processor thread assigned to execute the tasks.).
Weld does not teach wherein an operation includes multiple dependencies; dividing each operation into at least one task; wherein an outcome of the at least one task can either be a success or a failure; a queue of tasks; wherein the queue of tasks contains the tasks for each of the multiple operations; wherein generating the queue of tasks converts the multiple operations from a multi-threaded process to a single-threaded process; output a result for each task executed in the queue of tasks; wherein the result represents either a success or a failure of the execution of the at least one task
However, Weber teaches:
a queue of tasks (Paragraph 16; “Requests 10 from different initiators are communicated across different threads that are identified by different thread identifiers ("thread IDs") at the interface. This allows requests to be split by thread (or initiator) into per-thread request queues, e.g. 20, 25, 30.”, where requests are split by thread into per-thread request queues and the queues are populated as requests are received.);
wherein the queue of tasks contains the tasks for each of the multiple operations (Paragraph 16; “Requests 10 from different initiators are communicated across different threads that are identified by different thread identifiers ("thread IDs") at the interface. This allows requests to be split by thread (or initiator) into per-thread request queues, e.g. 20, 25, 30. Requests from these thread queues 20, 25, 30 are presented in parallel to the DRAM and thread scheduler block 35. The scheduler block 35 decides the order in which requests are presented to the DRAM Controller 40, which in turn is responsible for sending the requests to the actual DRAM subsystem 45.”, discloses per-thread request queues containing split request units corresponding to incoming operations.);
output a result for each task executed in the queue of tasks (Paragraph 16; “The scheduler block 35 decides the order in which requests are presented to the DRAM Controller 40, which in turn is responsible for sending the requests to the actual DRAM subsystem 45. When responses 50 return from the DRAM controller 45, they are sent back to the initiators via the multi-threaded interface 15. The delivery of requests from the initiators was described using a multi-threaded interface and thread identifiers. An alternative embodiment uses individual single-threaded interfaces for each initiator.”, discloses result responses returning from the controller to initiators.).
Weld and Weber are considered to be analogous to the claimed invention because they are in the same field of resource allocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld to incorporate the teachings of Weber and have a queue of tasks that contains tasks for each of the multiple operations and output a result for each task executed in the queue. A person of ordinary skill in the art would have recognized the use of a queue for managing task execution to be a known method in the art of organizing and scheduling execution, yielding the predictable result of ordered task processing, tracking execution status, and generating execution results foe ach of the processed tasks.
Weld in view of Weber does not teach converting from a multi-threaded process to a single-threaded process; wherein the tasks are ordered sequentially according to the multiple dependencies; wherein the result represents either a success or a failure of the execution of the at least one task
However, Brazier teaches:
converting from a multi-threaded process to a single-threaded process (Paragraph 37; “Another specific advantage of disclosed embodiments is that the conversion in the Intermediate Layer between single-thread processes and multiple-thread processes in each direction does not create significant performance overhead.”, which explicitly discloses bidirectional conversion between single and multi-threaded processes.);
wherein the tasks are ordered sequentially according to the dependencies (Paragraphs 40-41; “In particular, these requesting process calls can be simultaneous or sequential process call from a non-thread-safe process that is calling a thread-safe process.”, and “The system identifies any dependencies between the requesting process calls (step 310).”.).
Weld, Weber, and Brazier are considered to be analogous to the claimed invention because they are in the same field of resource allocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber to incorporate the teachings of Brazier and convert from a multi-threaded to a single-threaded process and order tasks sequentially, within the queue of Weber, according to the multiple dependencies. A person of ordinary skill in the art would have recognized that converting execution from multi- to single-threaded is a known technique for controlling execution concurrency and simplifying execution flow, yielding the predictable result of serialized task execution in one thread. Further, a person of ordinary skill in the art would have recognized that ordering tasks sequentially according to identified dependencies is a known method for ensuring that dependent tasks are executed in proper dependency order consistent with relationships, yielding the predictable result of correct execution of inter-related tasks.
Weld in view of Weber, further in view of Brazier does not teach wherein an operation includes multiple dependencies; wherein the result represents either a success or a failure of the execution of the at least one task.
However, Meijer teaches:
wherein an operation includes multiple dependencies (Paragraph 79; “A task can have multiple dependencies that must be met before the Ready flag is set to TRUE, and therefore may have multiple TaskDependency fields to allow for such processing.”);
wherein the result represents either a success or a failure of the execution of the at least one task (Paragraph 48; “In some systems, success or failure of a distribution operation can only be identified by checking back with the system to check the status of the operation.”).
Weld, Weber, Brazier, and Meijer are considered to be analogous to the claimed invention because they are in the same field of resource allocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier to incorporate the teachings of Meijer and have an operation include multiple dependencies. A person of ordinary skill in the art would have recognized that the incorporation of dependency relationships into the execution of operations provides a known mechanism for ensuring that dependent tasks are executed in an order consistent with their constraints, yielding the predictable result of operations in which dependent tasks are coordinated and executed in a manner that respects their relationships. Further, it would have been obvious to someone of ordinary skill in the art to have the result representing either a success or a failure of the execution of the at least one task. Determining whether individual tasks succeed or fail is a known requirement for controlling execution flow and ensuring that dependent tasks are executed only when prerequisite tasks successfully complete. Providing a success/fail result for each task yields the predictable result of enabling execution monitoring and dependency based control of subsequent processing steps.
Claim 8 recites similar limitations as those of claim 1, additionally reciting a non-transitory, computer-readable storage medium comprising instructions recorded thereon. Weld further teaches:
A non-transitory, computer-readable storage medium comprising instructions recorded thereon (Paragraph 114; “Main memory 606 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 604. Such instructions, when stored in non-transitory storage media accessible to processor 604, render computer system 600 into a special-purpose machine that is customized to perform the operations specified in the instructions.”).
Claim 8 is rejected for similar reasons as those of claim 1.
Claim 15 recites similar limitations as those of claim 1. Claim 15 is rejected for similar reasons as those of claim 1.
Regarding claim 4, Weld in view of Weber, further in view of Brazier, further in view of Meijer teach the system of claim 1. Weld teaches:
assign a priority to each task contained in the queue of tasks (Paragraphs 32-33; “tasks submitted to the CPU bound thread pool can be controlled by execution parameters such as: “task weight”, “task priority”, “minimum threads”, “maximum threads”.”, and “In various embodiments, “task weight” supplies a relative weight on a task that decides how many threads are allocated for the task. “Task priority” provides a way to prioritize tasks over other tasks that are submitted to the thread pool. Tasks with higher priority may be executed before tasks with lower priority. If there are multiple tasks with same priority, “task weight” determines how to distribute threads to tasks with the same priority.”);
wherein the priority of the at least one task is determined by what order the at least one task was inputted into the queue, a dependency of the at least one task, or a predetermined priority rating (Paragraph 32; “tasks submitted to the CPU bound thread pool can be controlled by execution parameters such as: “task weight”, “task priority”, “minimum threads”, “maximum threads”.”, where task weight and task priority correspond to a priority rating determined prior to submission to the CPU, thereby corresponding to a predetermined priority rating. ).
Claim 11 recites similar limitations as those of claim 4. Claim 11 is rejected for similar reasons as those of claim 4.
Regarding claim 7, Weld in view of Weber, further in view of Brazier, further in view of Meijer teach the system of claim 1. Weld teaches:
multiple operations (Paragraph 40; “when a client invokes a graph processing task such as “Load Graph”, the set of workload characteristics for that task are looked-up in the first mapping 202, and then using the looked-up set of workload characteristics from the first mapping 202, the corresponding set of execution parameters is looked up in the second mapping 204. The looked-up set of execution parameters is used to adjust the thread pool configuration for each task. Thus, using the first and second mappings provides fine grained control of the thread pool configuration for each task.”, which looks up workload characteristics for a task, thereby containing multiple operations.).
Brazier teaches:
converting processes coded to run on the multiple threads of the processor to run on the single thread of the processor (Paragraph 37; “Another specific advantage of disclosed embodiments is that the conversion in the Intermediate Layer between single-thread processes and multiple-thread processes in each direction does not create significant performance overhead.”, discloses a conversion between single and multi-threaded processes in both directions.);
wherein converting processes to run on the single thread of the processor minimizes race conditions and concurrent modification issues (Paragraph 37; “Another specific advantage of disclosed embodiments is that the conversion in the Intermediate Layer between single-thread processes and multiple-thread processes in each direction does not create significant performance overhead.”, discloses a conversion between single and multi-threaded processes in both directions).
A person of ordinary skill in the art would recognize that because tasks that would otherwise execute concurrently on multiple threads are ordered and executed serially within a single thread using the known method for controlling concurrent execution, it would be found obvious to yield the predictable result of opportunities for race conditions and concurrent modification being minimized as a result of the disclosed multi-thread to single-thread conversion architecture.
Claim 14 recites similar limitations as those of claim 7. Claim 14 is rejected for similar reasons as those of claim 7.
Claim 20 recites similar limitations as those of claim 7. Claim 20 is rejected for similar reasons as those of claim 7.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Thrasher (US 7685269 B1), further in view of Maeda (US 20200310869 A1).
Regarding claim 2, Weld in view of Weber, further in view of Brazier, further in view of Meijer teach the system of claim 1. Weld in view of Weber, further in view of Brazier, further in view of Meijer does not teach receive a failed task alert; analyze the failed task alert to determine that failure affects at least one other task; and end the operation based on the failed task alert when the failure of the task causes a failure of the operation.
However, Thrasher teaches:
receive a failed task alert (Col. 5, lines 57-63; “If a condition that may affect performance is detected on any group member, then an alert may be issued at the application level identifying that there is a condition that may affect operation of the application and/or scheduled task. Regardless of which group member fails, the alert may indicate which application(s) and/or scheduled task(s) are affected.”);
analyze the failed task alert to determine that failure affects at least one other task (Col. 5, lines 57-63; “If a condition that may affect performance is detected on any group member, then an alert may be issued at the application level identifying that there is a condition that may affect operation of the application and/or scheduled task. Regardless of which group member fails, the alert may indicate which application(s) and/or scheduled task(s) are affected.”, where identifying that the condition may affect operation of the application corresponds to an analysis of the alert to determine that failure would affect at least one other task.);
performing an action based on the failed task alert when the failure of the task causes a failure of the operation (Col. 11, lines 29-33; “If a condition that may cause a problem is detected, the task group monitor may generate a backup application-level alert and notify an operator of the alert so that the condition may be addressed”, where notifying the operator corresponds to performing an action based on the alert.).
Weld, Weber, Brazier, Meijer, and Thrasher are considered to be analogous to the claimed invention because they are in the same field of resource allocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier, further in view of Meijer to incorporate the teachings of Thrasher and receive a failed task alert, analyze the failed task alert to determine that failure affects at least one other task, and perform an action based on the failed task alert when the failure of the task causes a failure of the operation. A person of ordinary skill in the art would have recognized failure-aware execution to be a known method for coordinating execution flow in an operation containing multiple dependent tasks, applied on the tasks of Weld, yielding the predictable result of execution outcomes of individual tasks being evaluated in relation to other dependent tasks. In such systems, receiving a failed task alert and analyzing the alert to determine whether the failure impacts dependent tasks is a known method for propagating execution status within a dependency structure, yielding the predictable result of identifying affected downstream tasks. Further, performing an action when a task failure causes failure of an operation is a known method to troubleshoot dependency-based execution failures, yielding the predictable result of consistent control of operation execution in response to task failures.
Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Thrasher does not teach end the operation
However, Maeda teaches:
end the operation (Paragraph 74; “if the current thread becomes unwanted due to termination of the task, the thread scheduler 122 returns the current thread to the thread pool 121.”, task termination corresponding to ending the operation.).
Weld, Weber, Brazier, Meijer, Thrasher, and Maeda are considered to be analogous to the claimed invention because they are in the same field of resource allocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Thrasher to incorporate the teachings of Maeda and modify the failure control mechanism of Thrasher to include ending the operation in view of Maeda. A person of ordinary skill in the art would recognize that, in systems with many dependent tasks, a single point of failure may cause cascading failures which may yield undesirable outcomes. In such systems, when a task failure propagates such that the operation cannot successfully complete, ending the operation provides a predictable mechanism for halting further execution and conserving resources, yielding the predictable result of controlled termination of operation execution in response to failure conditions.
Claim 9 recites similar limitations as those of claim 2, additionally reciting that the failure belongs to the execution of the at least one task. Weld teaches:
execution of the at least one task (Paragraph 45; “two CPU bound tasks are incoming at the same time, using the first and second mappings as discussed herein, one task may be assigned 5 threads).
Thrasher teaches:
failure (Col. 5, lines 57-63; “If a condition that may affect performance is detected on any group member, then an alert may be issued at the application level identifying that there is a condition that may affect operation of the application and/or scheduled task.).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have utilized the failure reporting of Thrasher in the task execution system of Weld. A person of ordinary skill in the art would have recognized failure-aware execution of tasks to be a known method for coordinating execution flow in an operation containing multiple dependent tasks yielding the predictable result of execution outcomes of individual tasks being evaluated in relation to other dependent tasks.
Claim 9 is rejected for similar reasons as those of claim 2.
Claim 16 recites similar limitations as those of claim 2, additionally reciting that the failure belongs to the execution of the at least one task. Weld teaches:
execution of the at least one task (Paragraph 45; “two CPU bound tasks are incoming at the same time, using the first and second mappings as discussed herein, one task may be assigned 5 threads).
Thrasher teaches:
failure (Col. 5, lines 57-63; “If a condition that may affect performance is detected on any group member, then an alert may be issued at the application level identifying that there is a condition that may affect operation of the application and/or scheduled task.).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have utilized the failure reporting of Thrasher in the task execution system of Weld. A person of ordinary skill in the art would have recognized failure-aware execution of tasks to be a known method for coordinating execution flow in an operation containing multiple dependent tasks yielding the predictable result of execution outcomes of individual tasks being evaluated in relation to other dependent tasks.
Claim 16 is rejected for similar reasons as those of claim 2.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Maeda.
Regarding claim 3, Weld in view of Weber, further in view of Brazier, further in view of Meijer teach the system of claim 1. Weber teaches:
A queue of tasks (Paragraph 16; “Requests 10 from different initiators are communicated across different threads that are identified by different thread identifiers ("thread IDs") at the interface. This allows requests to be split by thread (or initiator) into per-thread request queues, e.g. 20, 25, 30. Requests from these thread queues 20, 25, 30 are presented in parallel to the DRAM and thread scheduler block 35. The scheduler block 35 decides the order in which requests are presented to the DRAM Controller 40, which in turn is responsible for sending the requests to the actual DRAM subsystem 45.”, discloses per-thread request queues containing split request units corresponding to incoming operations.).
Weld in view of Weber, further in view of Brazier, further in view of Meijer does not teach removing repeated entries.
However, Maeda teaches:
removing repeated entries (Paragraph 61; “The deduplication unit 113 performs control for deduplicating the data stored in the storage 300 in response to the I/O request The I/O processing unit 114 writes the deduplicated data in the storage 300.”).
Weld, Weber, Brazier, Meijer, and Maeda are considered to be analogous to the claimed invention because they are in the same field of resource allocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier, further in view of Meijer to incorporate the teachings of Maeda and have removed repeated entries from the queue of tasks of Weber. A person of ordinary skill in the art would have recognized that removing repeated entries from a queue is a known technique for preventing duplicate execution of identical tasks, yielding the predictable result of avoiding unnecessary re-execution and improving execution efficiency.
Claim 10 recites similar limitations as those of claim 3. Claim 10 is rejected for similar reasons as those of claim 3.
Claim 17 recites similar limitations as those of claim 3. Claim 17 is rejected for similar reasons as those of claim 3.
Claims 5, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Felice-Steele et al. (US 20200076813 A1) hereafter Felice-Steele, further in view of Haapanen (US 20200293670 A1), further in view of Thrasher, further in view of Maeda.
Regarding claim 5, Weld in view of Weber, further in view of Brazier, further in view of Meijer teaches the system of claim 1. Weld teaches:
execute the multiple tasks (Paragraph 35; “tasks submitted to the direct caller execution bound thread pool execute directly on a thread that handles a request to execute the graph processing task. For example, when a request in received to execute a graph processing task, a thread is assigned to handle the request. Tasks submitted to the direct caller execution thread pool will directly execute on the thread assigned to handle the request.”).
Weber teaches:
executing the queue of tasks (Paragraph 16; “Requests 10 from different initiators are communicated across different threads that are identified by different thread identifiers ("thread IDs") at the interface. This allows requests to be split by thread (or initiator) into per-thread request queues, e.g. 20, 25, 30.”, where requests are split by thread into per-thread request queues and the queues are populated as requests are received and executed in queue order.);
divide the operation into multiple tasks (Paragraph 16; “Requests 10 from different initiators are communicated across different threads that are identified by different thread identifiers ("thread IDs") at the interface. This allows requests to be split by thread (or initiator) into per-thread request queues, e.g. 20, 25, 30.”, where requests are split by thread into per-thread request queues and each queue entry corresponds to a thread-specific unit of work derived from a request.);
queue the multiple tasks (Paragraph 16; “Requests 10 from different initiators are communicated across different threads that are identified by different thread identifiers ("thread IDs") at the interface. This allows requests to be split by thread (or initiator) into per-thread request queues, e.g. 20, 25, 30.”, where requests are split by thread into per-thread request queues and each queue entry corresponds to a thread-specific unit of work derived from a request.).
Brazier teaches:
based on a dependency of the tasks (Paragraphs 40-41; “In particular, these requesting process calls can be simultaneous or sequential process call from a non-thread-safe process that is calling a thread-safe process.”, and “The system identifies any dependencies between the requesting process calls (step 310).”.).
Weld in view of Weber, further in view of Brazier, further in view of Meijer does not teach authenticating a user.
However, Felice-Steele teaches:
authenticates a user (Paragraph 147; “Depending on the embodiment, user authentication may be performed using various methods and based on various information.”);
receive an operation request to authenticate the user (Paragraph 25; “receiving authentication information from a user computing device, the authentication information including at least a name and address of a user”, the authentication information comprising a request to authenticate a user.);
wherein the multiple tasks include receiving a user credential (Paragraph 14; “receiving, via network communication with a user computing device, selection of a third-party entity from a plurality of third-party entities indicated in a user interface displayed on the user computing device, and credentials for directly accessing, by proxy on behalf of the user”), validating the user credential (Paragraph 147; “token gateway environment may validate the credentials with a security and access management environment using a standard open protocol such as OAuth”), and authenticating the user (Paragraph 147; “token gateway environment may validate the credentials with a security and access management environment using a standard open protocol such as OAuth (for example, OAuth 2.0, which is generally an authorization framework that enables applications to obtain limited access to user accounts).”);
receive the user credential (Paragraph 14; “receiving, via network communication with a user computing device, selection of a third-party entity from a plurality of third-party entities indicated in a user interface displayed on the user computing device, and credentials for directly accessing, by proxy on behalf of the user”);
wherein the user credential includes a username or password for the user (Paragraph 17; “In one embodiment, the credentials comprises a username and password.”);
validate the user credential with an authentication server (Paragraph 147; “For example, a requesting user may send an electronic request to a token gateway environment (of the account discovery system 110 or account access system 202) with credentials, and then the token gateway environment may validate the credentials with a security and access management environment”. Paragraph 110 contemplates the use of a server. “In some embodiments, these components are distributed amongst multiple computer systems, servers, devices, and so forth”.);
validating the user credential (Paragraph 147; “various authentication protocols may be implemented to authenticate the user and/or any entities that are requesting information regarding the user's credit information, such as the service providers discussed herein. For example, a requesting user may send an electronic request to a token gateway environment (of the account discovery system 110 or account access system 202) with credentials, and then the token gateway environment may validate the credentials with a security and access management environment”);
authenticate the user (Paragraph 147; “token gateway environment may validate the credentials with a security and access management environment using a standard open protocol such as OAuth (for example, OAuth 2.0, which is generally an authorization framework that enables applications to obtain limited access to user accounts).”, where a user obtaining limited access to user accounts corresponds to successfully authenticating the user using credentials.).
Weld, Weber, Brazier, Maijer, and Felice-Steele are considered to be analogous to the claimed invention because they are in the same field of task management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier, further in view of Meijer to incorporate the teachings of Felice-Steele and incorporate authentication processing including authenticating a user, receiving a user credential, and validating the user credential with an authentication server because credential-based authentication is a well known technique for controlling access to computing resources. Receiving user credentials and validating those credentials on an authentications server represents a known method for verifying the identity of a requesting user, yielding the predictable result of permitting access to authorized users.
Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Felice-Steele does not teach obtaining an authentication token; validating the authentication token.
However, Haapanen teaches:
obtaining and validating an authentication token (Paragraph 71; “In situations where mobile device 130 has previously obtained an authentication token that is still valid, mobile device 130 may itself authenticate the user using, for example, biometric information such as a finger print or face ID, and then provide the authentication token to authentication application 172 for validation.”);
obtain, based on a successful validation, the authentication token from the authentication server (Paragraphs 70-71; “Authentication application 172 processes the request, which may include validating the user credentials contained in the request using information maintained by authentication manager 170, or via an external service, such as an Authentication, Authorization, and Accounting (AAA) service. Authentication application 172 then generates the authentication data for mobile device 130 and stores the authentication data in authentication data 174. For purposes of explanation, embodiments are described herein in the context of authentication tokens”. Paragraph 85 explicitly discloses an authentication server; “This method involves an authentication server”.);
validate the authentication token with a resource server (Paragraph 71; “mobile device 130 may itself authenticate the user using, for example, biometric information such as a finger print or face ID, and then provide the authentication token to authentication application 172 for validation”. Paragraph 102 contemplates the use of a separate computing device which may be a server, corresponding to a resource server, “The techniques may be implemented in whole or in part using a combination of at least one server computer and/or other computing devices that are coupled using a network”, and “The computing devices may be server computers”.);
performing an action based on a successful execution of each task (Paragraph 74; “Assuming that the response from authentication manager 170 in step 218 indicates that the authentication token is still valid, then in step 220, printing device manager 160 grants access to printing device 110 by mobile device 130.”, the response indicating token validity only occurring after successful execution of each task.).
Weld, Weber, Brazier, Meijer, Felice-Steele, and Haapanen are considered to be analogous to the claimed invention because they are in the same field of task management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Felice-Steele to incorporate the teachings of Haapanen and have obtained and validated an authentication token, obtain an authentication from an authentication server following successful credential validation, validate the authentication with a resource server, and perform an action based on a successful execution of each task. A person of ordinary skill in the art would have recognized token-based authentication as a known technique used in distributed systems for conveying verified authentication status beteen systems, and validating suc a token with a resource server provides a known mechanism to authorize access to protected resources, yielding the predictable result of enabling a system to conditionally perform requested actions only when authorized to do so. Performing a subsequent action after subsequent completion of prerequisite authentication tasks is a known method of enforcing access control yielding the predictable result of allowing authorized requests to proceed only when all prerequisite authorization tasks return successfully.
Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Felice-Steele, further in view of Haapanen does not teach wherein a failure to validate the user credential notifies the user of the failure and ends the operation.
However, Thrasher teaches:
wherein a failure creates a notification of the failure (Col. 5 lines 57-63; “If a condition that may affect performance is detected on any group member, then an alert may be issued at the application level identifying that there is a condition that may affect operation of the application and/or scheduled task. Regardless of which group member fails, the alert may indicate which application(s) and/or scheduled task(s) are affected.”);
wherein a failure creates a notification of the failure (Col. 5 lines 57-63; “If a condition that may affect performance is detected on any group member, then an alert may be issued at the application level identifying that there is a condition that may affect operation of the application and/or scheduled task. Regardless of which group member fails, the alert may indicate which application(s) and/or scheduled task(s) are affected.”).
Weld, Weber, Brazier, Meijer, Felice-Steele, Haapanen, and Thrasher are considered to be analogous to the claimed invention because they are in the same field of task management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Felice-Steele, further in view of Haapanen to incorporate the teachings of Thrasher and have a failure create a notification of the failure. A person of ordinary skill in the art would have recognized failure-aware execution to be a known method for coordinating execution flow in an operation containing multiple dependent tasks, applied on the tasks of Weld, yielding the predictable result of execution outcomes of individual tasks being evaluated in relation to other dependent tasks. In such systems, receiving a failed task notification and analyzing the alert to determine whether the failure impacts dependent tasks is a known method for propagating execution status within a dependency structure, yielding the predictable result of identifying if there are any affected downstream tasks.
Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Felice-Steele, further in view of Haapanen, further in view of Thrasher does not teach end the operation.
However, Maeda teaches:
end the operation (Paragraph 74; “if the current thread becomes unwanted due to termination of the task, the thread scheduler 122 returns the current thread to the thread pool 121.”, task termination corresponding to ending the operation.).
Weld, Weber, Brazier, Meijer, Felice-Steele, Haapanen, Thrasher, and Maeda are considered to be analogous to the claimed invention because they are in the same field of resource allocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Felice-Steele, further in view of Haapanen, further in view of Thrasher to incorporate the teachings of Maeda and modify the failure control mechanism of Thrasher to include ending the operation in view of Maeda. A person of ordinary skill in the art would recognize that, in systems with many dependent tasks, a single point of failure may cause cascading failures which may yield undesirable outcomes. In such systems, when a task failure propagates such that the operation cannot successfully complete, ending the operation provides a predictable mechanism for halting further execution and conserving resources, yielding the predictable result of controlled termination of operation execution in response to failure conditions.
Claim 12 recites similar limitations as those of claim 5. Claim 12 is rejected for similar reasons as those of claim 5.
Claim 18 recites similar limitations as those of claim 5. Claim 18 is rejected for similar reasons as those of claim 5.
Claims 6, 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Mundar (US 20190391980 A1), further in view of Haapanen, further in view of Cheng (US 12462004 B2), further in view of Maeda.
Regarding claim 6, Weld in view of Weber, further in view of Brazier, further in view of Meijer teach the system of claim 1. Weld teaches:
execute the multiple tasks (Paragraph 35; “tasks submitted to the direct caller execution bound thread pool execute directly on a thread that handles a request to execute the graph processing task. For example, when a request in received to execute a graph processing task, a thread is assigned to handle the request. Tasks submitted to the direct caller execution thread pool will directly execute on the thread assigned to handle the request.”).
access to an application (Paragraph 107; “VMM 530 instantiates and runs one or more virtual machine instances (“guest machines”). Each guest machine comprises a “guest” operating system, such as OS 510, and one or more applications, such as application(s) 502”.).
Weber teaches:
executing a queue of tasks (Paragraph 16; “Requests 10 from different initiators are communicated across different threads that are identified by different thread identifiers ("thread IDs") at the interface. This allows requests to be split by thread (or initiator) into per-thread request queues, e.g. 20, 25, 30.”, where requests are split by thread into per-thread request queues and the queues are populated as requests are received.);
divide the operation into multiple tasks (Paragraph 16; “Requests 10 from different initiators are communicated across different threads that are identified by different thread identifiers ("thread IDs") at the interface. This allows requests to be split by thread (or initiator) into per-thread request queues, e.g. 20, 25, 30.”, where requests are split by thread into per-thread request queues and each queue entry corresponds to a thread-specific unit of work derived from a request.);
queue the multiple tasks (Paragraph 16; “Requests 10 from different initiators are communicated across different threads that are identified by different thread identifiers ("thread IDs") at the interface. This allows requests to be split by thread (or initiator) into per-thread request queues, e.g. 20, 25, 30.”, where requests are split by thread into per-thread request queues and each queue entry corresponds to a thread-specific unit of work derived from a request.).
Brazier teaches:
based on a dependency of the tasks (Paragraphs 40-41; “In particular, these requesting process calls can be simultaneous or sequential process call from a non-thread-safe process that is calling a thread-safe process.”, and “The system identifies any dependencies between the requesting process calls (step 310).”.).
Weld in view of Weber, further in view of Brazier, further in view of Meijer does not teach receive an operation request to receive the access token; wherein the access token stores security information and allows the user to access resources; wherein the multiple tasks include receiving a request for the access token, making a connection, and assigning the access token; receive the request for the access token from a user device; determine a connection over a communication network; receive a time code; receive the access token; and associate the access token to the user device.
However, Mundar teaches:
receive an operation request to receive the access token (Paragraph 33; “Notifications of available access tokens can be accompanied by options to request that one or more access tokens be assigned to a user. Therefore, user 105 can provide input to mobile device 110 via an interface to request such assignment and provide other pertinent information.”);
wherein the access token stores security information and allows the user to access resources (Paragraph 32; “Access management system 185 can be configured to manage a dynamic set of access tokens to one or more resources. More specifically, access management system 185 can track which resources are to be made available to users, specifications of the resources and times at which they will be available. Access management system 185 can also allocate access tokens for resources and facilitate transmissions of notifications of the available rights to a set of user devices.”);
wherein the multiple tasks include receiving a request for the access token (Paragraph 33; “Notifications of available access tokens can be accompanied by options to request that one or more access tokens be assigned to a user. Therefore, user 105 can provide input to mobile device 110 via an interface to request such assignment and provide other pertinent information.”), making a connection (Paragraph 152; “Connections to site system 180 and site network 716 can be established by mobile devices 724 connecting to access points 720.”), receiving a time code (Paragraph 73; “a status-update communication identifies assignment details, such as a user, account and/or user device associated with an access token assignment; and/or a time that the assignment was made.”), receiving the access token (Paragraph 45; “As described in further detail herein, an interaction between mobile device 110 and a client device (e.g., client agent device 170, client register 160 or client point device 165) can facilitate, for example, verification that user 105 has a valid and applicable access token, obtaining an assignment of an access token, and/or obtaining an assignment of an upgraded access token.”), and assigning the access token (Paragraph 34; “Assigning an access token can include, for example, associating an identifier of the right with an identifier of a user, changing a status of the right from available to assigned, facilitating a cease in notifications that the access token is available, generating an access-enabling code to use such that the corresponding access will be permitted and/or generating a notification to be received at mobile device 110 confirming the assignment and/or including data required for corresponding access to be permitted.”);
receive the request for the access token from a user device (Paragraph 33; “Notifications of available access tokens can be accompanied by options to request that one or more access tokens be assigned to a user. Therefore, user 105 can provide input to mobile device 110 via an interface to request such assignment and provide other pertinent information.”, where the user’s mobile device 110 corresponds to the user device.);
determine a connection over a communication network (Paragraph 152; “Connections to site system 180 and site network 716 can be established by mobile devices 724 connecting to access points 720.”. Paragraph 31 confirms connection over a network. “Mobile device 110 may transmit data to access point 145, which is connected to network 155”.);
receive a time code (Paragraph 73; “a status-update communication identifies assignment details, such as a user, account and/or user device associated with an access token assignment; and/or a time that the assignment was made.”);
receive the access token (Paragraph 40; “A resource can include one managed or provided by a client, such as a performing entity or an entity operating a location. A mobile device 110 can transmit data corresponding to the access token (e.g., an access-enabling code) to a client device upon, for example, detecting the client device, detecting that a location of the mobile device 110 is within a prescribed geographical region, or detecting particular input.”);
and associate the access token to the user device (Paragraph 52; “The coordination can include updating an access token data store to change a status of the one or more access tokens (e.g., to assigned); to associate each of the one or more access tokens with a user and/or user device”.).
Weld, Weber, Brazier, Meijer, and Mundar are considered to be analogous to the claimed invention because they are in the same field of task management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier, further in view of Meijer to incorporate the teachings of Mundar and implement a token-based access workflow in which an operation request is received to obtain an access token, the acess token stores security information and is used to authorize access to resources, and a series of authentication tasks are performed including receiving a request for the access token from a user device, establishing a connection over a connection network, receiving a time code, receiving the access token, and associating the access token with the user device. A person of ordinary skill in the art would have recognized that credential and token-based authentication systems typically apply these known authentication methods to authenticate users, and performing these tasks would yield the predictable result of securely verifying user identities, obtaining a valid access token containing authentication information, and enabling access to resources, the resources corresponding to the application of Weld, by associating the validated access token with the requesting user device for future interactions.
Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Mundar does not teach an authentication server, or saving.
However, Haapanen teaches:
an authentication server (Paragraph 85; “This method involves an authentication server or a printing device manager contacting an application on the mobile device to verify a login with the user of the mobile device.”);
and saving (Paragraphs 70-71; “Authentication application 172 processes the request, which may include validating the user credentials contained in the request using information maintained by authentication manager 170, or via an external service, such as an Authentication, Authorization, and Accounting (AAA) service. Authentication application 172 then generates the authentication data for mobile device 130 and stores the authentication data in authentication data 174. For purposes of explanation, embodiments are described herein in the context of authentication tokens”, obtaining and storing corresponding to an operation functionally equivalent to saving.).
Weld, Weber, Brazier, Meijer, Mundar, and Haapanen are considered to be analogous to the claimed invention because they are in the same field of task management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Mundar to incorporate the teachings of Haapanen and utilize an authentication server and save the access token in association with the user device because authentication servers are a known method for issuing, managing, and validating authentication credentials yielding the predictable result of facilitating access to protected domains. Further, once an access token has been obtained and associated with a user device, saving the access token is a known method for maintaining authentication state and enabling authenticated communications without repeatedly obtaining a new token or repeatedly verifying the user/device against authorized users. Such storage yields the predictable result of preserving the relationship between the user device and the issued access token, facilitating access to protected resources.
Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Mundar, further in view of Haapanen does not teach wherein a failure wherein a failure to validate the time code against the user device ends the operation.
However, Cheng teaches:
wherein a failure to validate the time code against the user device performs an action (Col. 60, lines 55-57; “verifying whether the verification time-period code is the same as the time-period unique code of the user card”. Col. 61, line 64 – Col. 62, line 4 contemplates actions taken on verification failure. “If results of all verification items are “yes”, the application website sends a user login response to the terminal device to inform the target user that the login is successful. If the result of any one of the verification items (1) to (4) is “no”, then the application website may also send a user login response to the terminal device to inform the target user that the login to the website fails, and may further inform the user of the reason for the login failure.”).
Weld, Weber, Brazier, Meijer, Mundar, Haapanen, and Cheng are considered to be analogous to the claimed invention because they are in the same field of task management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Mundar, further in view of Haapanen to incorporate the teachings of Cheng and have a failure to validate the time code against the user device perform an action. A person of ordinary skill in the art would have recognized that failure response processing is a known method of handling unsuccessful authentication attempts, yielding the predictable result of preventing further processing based on invalid authentication information.
Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Mundar, further in view of Haapanen, further in view of Cheng does not teach ending the operation.
However, Maeda teaches:
end the operation (Paragraph 74; “if the current thread becomes unwanted due to termination of the task, the thread scheduler 122 returns the current thread to the thread pool 121.”, task termination corresponding to ending the operation.).
Weld, Weber, Brazier, Meijer, Mundar, Haapanen, Cheng, and Maeda are considered to be analogous to the claimed invention because they are in the same field of resource allocation. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Weld in view of Weber, further in view of Brazier, further in view of Meijer, further in view of Mundar, further in view of Haapanen, further in view of Cheng to incorporate the teachings of Maeda and modify the failure response mechanism of Cheng to include ending the operation in view of Maeda. A person of ordinary skill in the art would recognize that, in systems with many dependent tasks, a single point of failure may cause cascading failures which may yield undesirable outcomes. In such systems, when a task failure propagates such that the operation cannot successfully complete, ending the operation provides a predictable mechanism for halting further execution and conserving resources, yielding the predictable result of controlled termination of operation execution in response to failure conditions.
Claim 13 recites similar limitations as those of claim 6. Claim 13 is rejected for similar reasons as those of claim 6.
Claim 19 recites similar limitations as those of claim 6. Claim 19 is rejected for similar reasons as those of claim 6.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Li et al. (US 20200409754 A1) discloses a server computer system is configured to maintain first and second sets of task queues that have different performance characteristics, and to collect performance metrics relating to processing of program tasks from the first and second sets of task queues. Based on the collected performance metrics, the server computer system is further configured to update a scheduling algorithm for assigning program tasks to queues in the first and second sets of task queues (see [0030]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH P TRAN whose telephone number is (571)272-6926. The examiner can normally be reached M-TH 4:30 a.m. - 12:30 p.m. PT, F 4:30 a.m. - 8:30 a.m. PT, or at Kenneth.Tran@uspto.gov.
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.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Blair can be reached at (571) 270-1014. 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.
/KENNETH P TRAN/Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights