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 .
This Office Action is in response to amendment filed on 10/14/2025.
Response to Amendment
By this amendment, claims 1, 9, 12, and 15-16 are amended. Therefore, claims 1-20 are pending. Any objections and rejections not repeated below is withdrawn due to Applicant's amendment.
Response to Arguments
Applicant's arguments filed 10/14/2025 have been fully considered but they are not persuasive. Applicant argues in substance:
The Office Action rejected claims 1-20 under 35 U.S.C. § 101 because the present claims are directed to non-statutory subject matter. In particular, the Office Action recites the claims and concludes that they cover performing all of the claimed limitations in one's mind. Id., at p. 6.
For example, the Office Action (at p.3) states that a "person can observe and verify that all processing requests of a cancelled service request on a local processing resource have completed, and thus this limitation is an abstract idea." Again, Applicant asserts that this statement fails to understand to details recited in the claims needed to guarantee the "cancellation of the service request by indicating that the local processing resource will not be accessed to further process the processing request associated with the service request." Furthermore, in view of the amendments to the independent claims, Applicant assert that the local processing resource processing the processing request completion indicator, which indicates that processing requests that have arrived at the local processing resource before the processing request completion indicator have completed processing, in connection with, the verification check that checks for invalidated sequence numbers and added before the local processing resource contribute to operations that cannot be performed in one's mind or with pen and paper.
Furthermore, as briefly discussed in the interview, the independent claims integrate the alleged abstract idea into several practical applications, such as those provided in paragraphs [0022]-[0025] of the filed Specification. To illustrate, paragraph [0004] of the Specification describes how many existing systems suffer from approaches that cause "the local resources to be locked, unavailable, and wasted." In contrast, the claimed invention guarantees that both local and remote service requests, when canceled, are not further processed by a local processing resource. This is indicated by the request verification check and the processing request completion indicator recited in the independent claims. As a result, the claimed invention "improves efficiency by ... asynchronously canceling pending or outstanding service requests regardless of where the requests are currently being processed in a request processing flow, even for processing requests residing on one or more remote processing resources" Id at [0022]. Paragraph [0022] continues, "the processing engine system efficiently and flexibly cancels requests without having to track down the current location of processing requests" and "the processing engine system performs local cancellation operations that prevent the processing engine system from processing canceled requests while allowing non-canceled requests to be processed." As discussed in the interview, existing systems allow canceled services to be processed even after cancelation requests are sent, especially if the canceled service involves a remote processing component before returning for local processing.
As another example, the claimed invention reduces computational processing operations by utilizing the claimed request verification check to modify sequence numbers and the processing request completion indicator. Together, "the processing engine system utilizes a verification check before processing requests locally to ensure that canceled requests are not processed" and "utilizes the verification check to drop canceled requests before they advance to the next processing stage of the request processing flow," id at [0024], which prevents wasted processing. While the Office Action (at p. 5) notes that "the prevention of wasteful processing of request is an outcome of cancelling the request," it does not refute that this a not an improvement to the computing system. Indeed, when a request is canceled, the claimed invention "does not allow the processing request to access the local processing resources, including any resources previously associated with the canceled request, as they have been deallocated at the time the request was asynchronously canceled." Id. at [0102]. Furthermore, the claimed invention "prevents any additional fields of the processing request from being accessed before the validity of the processing request is first confirmed, thus ensuring that computing resources are not wasted on handling portions of a canceled processing request."
With regard to point (a), Examiner agrees with Applicant and all 101 claim rejections are withdrawn due to Applicant’s arguments in combination with Applicant’s stated improvements above. Specifically, the limitations of “modifying a sequence number to generate a modified sequence number at a target context entry of a request context table to indicate the target context entry as invalid”, “the request verification check preventing invalid processing requests from accessing the local processing resource”, and “confirming cancellation of the service request by indicating that the local processing resource will not be accessed to further process the processing request associated with the service request” cannot be done mentally and thus fails Step 2A Prong One of MPEP 2106.
To illustrate, Chakrabarti does not appear to teach or suggest "in response to the cancellation indication, modifying a sequence number to generate a modified sequence number at a target context entry of a request context table to indicate the target context entry as invalid, the target context entry comprising a request context for a processing request being associated with the service request," as recited in independent claim 1. Independent claims 12 and 16 recite similar subject matter.
Chakrabarti relates to "mobile network and Internet of Things (IOT) convergence." Id., [0002]. While Chakrabarti (at [0048]) discloses an Authentication, Authorization, and Accounting (AAA) server that keeps a record for each unique combination of service type (what kind of IoT data/service it is), customer ID (which customer it belongs to), and gateway address (which IoT gateway is involved), along with an active or inactive status flag, Chakrabarti does not appear to teach or suggest modifying a sequence number of a target context entry within a request context table. During the interview, Examiner Tong asserted that the Office interpreted the AAA record of an AAA server as the claimed "target context entry" of a "request context table." First off, a database on a separate server device is not patentably equivalent to a request context table of a local processing service, as claimed.
Second, the Examiner Tong asserted that the Office interpreted the unique combination of service type, customer ID, gateway address, and active/inactive state status flag in Chakrabarti reads on the claimed sequence number of a service request. Because the active/inactive status flag in Chakrabarti does not read on the claimed sequence number, the Office asserts that the entire contents of an entry combine to read on the claimed sequence number, which is both unreasonable and nonsensical. Furthermore, nowhere in Chakrabarti does it teach either the active/inactive status flag or the entire entry on the separate IOT AAA server from being modified "in response to the cancellation indication [to cancel a service request that is currently being processed]," as recited by the independent claims.
With regard to point (b), Examiner respectfully disagrees with Applicant that a database on a separate server device (AAA record of an AAA server) is not patentably equivalent to a request context table of a local processing service. As Applicant's claims do not define the breadth nor scope of "local processing services", the term, “local” does not have significant patentable weight. In addition, Examiner utilizes broadest reasonable interpretation on the term, sequence number, to read on Applicant’s claims as described by Applicant above. Furthermore, Applicant’s claims do not disclose the location of the request context table. Thus, Chakrabarti’s AAA records still read on Applicant’s claims. Argument has not been found to be persuasive.
Moreover, the Office Action (at p.25) states that a person of ordinary skill in the art would have combined Knight with Chakrabarti "to determine which operator to send the received data of a customer request." However, Knight does not discuss customers, mobile network devices, or operators. Accordingly, this explanation lacks the rational underpinning required to make such a combination. Additionally, the cited portion of Chakrabarti is included to justify the combination discusses subject matter unrelated to any subject matter included in Knight. Indeed, Knight and Chakrabarti do not appear to be analogous art or solve the same problem.
The addition of Allen does not cure the deficiencies of Knight and Chakrabarti with respect to the above subject matter. Accordingly, the §103 rejection should be withdrawn.
With regard to point (c), Examiner respectfully disagrees with Applicant that Knight does not discuss customers, mobile network devices, or operators. Knight’s equivalent to operators are users whom request processing (Col 1 lines 41-44: “For various reasons such as cancellation by a user, expiration of a time limit or system termination of a particular task, a particular program routine may seek to cancel a previously-issued Request.”). In addition, Knight and Chakrabarti do appear to be analogous as they both disclose terminating a request by a data structure. Argument has not been found to be persuasive.
As another example, Knight does not appear to teach or suggest "adding a request verification check before a local processing resource, the request verification check preventing invalid processing requests from accessing the local processing resource," as recited by independent claim 1 and similarly recited by independent claims 12 and 14. While Knight (at 5:56-64) discloses sending a high-priority Cancel message to reach a layer of the Cancel System before the request, Knight does not appear to teach or suggest a request verification check as claimed. Indeed, a single message priority intercept is not the same as a request verification check that requires each message to be verified before accessing a local processing resource (e.g., if no Cancel message is sent, the is no request verification check in Knights case).
Furthermore, the next sentence in Knight (at 5:64-66) indicates that
even if a Cancel message is intercepted at the Cancel System, the target
system 240 (e.g., the claimed local processing system) still needs to be
informed of the cancellation. Thus, Knight does not support the
assertion that the Office Action relies on it to assert. Accordingly, the §
103 rejection should be withdrawn.
With regard to point (d), Examiner respectfully disagrees with Applicant that Knight does not appear to teach or suggest a request verification check as claimed. Knight discloses Col. 5, lines 56-64: “If the message has been forwarded, administrative system 360 adds to context data structures 330 contextual information including a Cancel tag to inform family 320 that the Request is "to be canceled." Since the administrative system 360 processes the Cancel asynchronously and at high priority, a Cancel message may reach a particular layer 250 ahead of the Request. Accordingly, maintaining contextual information on the Cancel enables canceling the Request when the Request finally does arrive at the layer.”, Figs. 4-5. In other words, requests are checked against any Cancel messages before execution. Furthermore, Applicant’s claims do not disclose a verification check on the request context table. Thus, Knight teaches "adding a request verification check before a local processing resource, the request verification check preventing invalid processing requests from accessing the local processing resource". Argument has not been found to be persuasive.
As a further example, Allen does not appear to teach or suggest "providing a processing request completion indicator to the local processing resource to verify, by processing the processing request completion indicator through the local processing resource, that any processing requests associated with the service request, which have arrived at the local processing resource before arrival of the processing request completion indicator, have completed processing" as recited by currently amended independent claim 1. Currently amended independent claims 12 and 14 recite analogous subject matter.
As discussed in the interview, Allens (at 8:55-65) signals go to a cancellation manager/token, not to the local processing resource as a verification mechanism. Furthermore, Allen discloses sending a cancellation signal and counter-based thresholds from a request processor to a separate cancellation token/manager to coordinate distributed cancellation, which is unrelated to the claimed "processing request completion indicator." First, the Office asserts that the Cancel message is the processing request completion indicator, which is incorrect. Second, the Cancel message in Allen does not reach the local processing resource to be processed to verify that all tasks associated with the canceled request have been cleared out of the local processing resource.
Indeed, while Allen discloses that the counter is expressly maintained by a cancellation manager ( or other service) to decide when to propagate cancellation based on how many distributed requests have completed, and that signaling is sent to a cancellation token/manager, Allen does not appear to teach or suggest "providing a processing request completion indicator to the local processing resource" that the local resource uses "to verify ... that any processing requests ... that arrive ... before ... the processing request completion indicator have completed processing." Furthermore, Allen does not appear to teach or suggest "processing the processing request completion indicator through the local processing resource," "indicating that the local processing resource will not be accessed to further process the processing request associated with the service request," as recited by currently amended independent claim 1. Accordingly, the § 103 rejection should be withdrawn.
With regard to point (e), Examiner respectfully disagrees with Applicant that Allen does not appear to teach or suggest "providing a processing request completion indicator to the local processing resource to verify, by processing the processing request completion indicator through the local processing resource, that any processing requests associated with the service request, which have arrived at the local processing resource before arrival of the processing request completion indicator, have completed processing" as claimed. Allen discloses Col. 8, lines 56-65: “For example, multiple completed or committed requests may be required before processing of a request may be canceled. In such an environment, a counter may be maintained by the cancellation manager or some other service in order to track the number of completed request. Two or more distinct cancellation signals may be used to differentiate between signaling of a committed request and signaling that the requisite number of request have been completed and outstanding requests may be terminated.”, wherein the counter is interpreted as the processing request completion indicator to count the number of completed requests which includes all outstanding requests before request cancellation. Furthermore, Allen also discloses in Fig. 3 a cancellation manager 308 in the same geographic location 326 as the request processor 316. This shows that each request processor (local processing resource) utilizes a counter (processing request completion indicator) to complete outstanding requests before request cancellation. Argument has not been found to be persuasive.
As another example, Knight does not appear to teach or suggest "confirming cancellation of the service request by indicating that the local processing resource will not be accessed to further process the processing request associated with the service request," as recited by independent claim 1 and similarly recited by independent claims 12 and 14. While Knight (at 6: 14-21) discloses "cleaning up" layers of the Cancelation System 190, Knight does not appear to teach or suggest "indicating that the local processing resource will not be accessed." Indeed, the "cleaning up" in Knight occurs at the wrong system from what is being recited in the independent claims (e.g., Knight's Cancelation System vs. Target System).
The additions of Chakrabarti and Allen do not cure the deficiencies
of Knight with respect to the above subject matter. Accordingly, the §
103 rejection should be withdrawn.
With regard to point (f), Examiner respectfully disagrees with Applicant that Knight does not appear to teach or suggest “confirming cancellation of the service request by indicating that the local processing resource will not be accessed to further process the processing request associated with the service request” as claimed. Knight expands upon Examiner’s disclosure in Col. 5, lines 56-64: “If the message has been forwarded, administrative system 360 adds to context data structures 330 contextual information including a Cancel tag to inform family 320 that the Request is "to be canceled." Since the administrative system 360 processes the Cancel asynchronously and at high priority, a Cancel message may reach a particular layer 250 ahead of the Request. Accordingly, maintaining contextual information on the Cancel enables canceling the Request when the Request finally does arrive at the layer.”, Col. 6, lines 14-21: “Each layer 250 propagates the responses upward through the above layers back to program routine 210. As each layer 250 receives the Request status response, the layer deletes or "cleans up" its contextual information from context data structures 330, and frees all resources allocated for the Request. Further, as the Cancel status response propagates upward, each layer 250 cleans up the contextual information on the Cancel from context data structures 330.”, Col. 7, lines 32-36: “Alternatively, if in step 515 target system 240 is currently executing the Request, then the Cancel message proceeds on path 540. If target system 240 in step 545 supports cancellation, target system 240 in step 550 attempts to cancel the Request”, Col. 7, lines 43-61: ”if the Cancel in step 555 was successful or the Cancel waited in step 565 for target system 240 to complete the Request as described above, then method 500 proceeds to step 575 of determining whether program routine 210 issued the Request as transactional or non-transactional. If transactional, program routine 210 requires that an exact status of the Request and of the Cancel be reported back to program routine 210. For example, if target system 240 completes the Request despite the attempted Cancel, the process results are not discarded. Instead, the target system 240 results and a "Cancel Fails" response are reported to program routine 210. If target system 240 has completed only a portion of the Request before a Cancel succeeds in terminating operations of target system 240, then the intermediate results and a "Cancel succeeds" response are reported to program routine 210. However, if non-transactional, the results are discarded and a "Cancel Succeeds" response is reported to program routine 210.”, Figs. 4-5. In other words, a request processed in the target system is terminated (and results may be discarded) whilst “cleaning” up any remaining operations of the request in layers. Argument has not been found to be persuasive.
As a further example, independent claim 16 includes additional subject matter not included in independent claim 1 regarding remote processing services. For example, independent claim 16 recites "receiving, from a remote processing service, a processing result of a remote processing request, wherein the remote processing request was sent to the remote processing service based on the service request, and wherein the processing result comprises a token having a context identifier for the target context entry and the sequence number." The Office Action (at p.46) relies on Chakrabarti to read on this subject matter, citing the Authentication, Authorization, and Accounting (AAA) server as the claimed remote processing service. This is incorrect. First, the Offices conflates the AAA server as both the claimed request verification check added to the local processing resource and the claimed remote processing service, which is not possible. Second, the AAA server in Chakrabarti does not perform any type of processing service of a service request, but rather indicates when "records are marked as active once a successful request matching that record from the [Machine-to-Machine Aggregation Routing Service] 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record." Chakrabarti at [0002]. Accordingly, the §103 rejection of independent claim 16 should be withdrawn.
With regard to point (g), firstly as stated in the Arguments above, Knight discloses the claimed request verification check added to the local processing resource. Thus, Chakrabarti is correct to read on this subject matter, citing the Authentication, Authorization, and Accounting (AAA) server as the claimed remote processing service as described in the 103 rejection below. Secondly, as Applicant's claims do not define the breadth nor scope of "remote processing services", the modification of request statuses qualifies as a type of processing. Argument has not been found to be persuasive.
Claim Objections
Claims 16-20 are objected to because of the following informalities:
In Claim 16, “the request verification check preventing prevents invalid
processing requests” should read “the request verification check preventing invalid processing requests”.
Any claim not specifically mentioned above, is objected due to its dependency on
an objected claim.
Appropriate correction is required.
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-19 are rejected under 35 U.S.C. 103 as being unpatentable over Knight et al. Pat. No. US 6,178,464 Bl (hereafter Knight which was cited in the IDS filed 01/22/2024) in view of CHAKRABARTI et al. Pub. No. US 2015/0365278 Al (hereafter CHAKRABARTI), and further in view of Allen Pat. No. US 9,781,053 Bl (hereafter Allen which was cited in the IDS filed 01/22/2024).
Regarding claim 1, Knight teaches a computer-implemented method comprising: identifying a cancellation indication to cancel a service request that is currently being processed (Col. 4, lines 28-35: “For various reasons, such as cancellation by a user, expiration of a time limit or system termination of a particular task, program routine 210 may attempt to cancel a previously-issued Request. Program routine 210 sends the Cancel message through FPI 220 to Family Server 230, in search of the original Request. Program routine 210 maintains contextual information that the Cancel message was sent.”, Figs. 4-5); in response to the cancellation indication … the target context entry comprising a request context for a processing request being associated with the service request (Col. 4 lines 60-67 and Col. 5 lines 1-2: “When issuing a service Request, program routine 210 sends a Request message through FPI 220 to family 320, which includes the program code for controlling the family services. The FPI 220 generates ID information, such as a Request ID or a connection ID, and returns the information to program routine 210. Routine 210 then adds this ID information, and possibly other contextual information, to context data structures 310. Family 320 recognizes the Request, and adds contextual information to context data structures 330 to "remember" the Request.”, Figs. 4-5); adding a request verification check before a local processing resource, the request verification check preventing invalid processing requests from accessing the local processing resource (Col. 5, lines 56-64: “If the message has been forwarded, administrative system 360 adds to context data structures 330 contextual information including a Cancel tag to inform family 320 that the Request is "to be canceled." Since the administrative system 360 processes the Cancel asynchronously and at high priority, a Cancel message may reach a particular layer 250 ahead of the Request. Accordingly, maintaining contextual information on the Cancel enables canceling the Request when the Request finally does arrive at the layer.”, Figs. 4-5) … and confirming cancellation of the service request by indicating that the local processing resource will not be accessed to further process the processing request associated with the service request (Col. 6, lines 8-10: “a "Cancel Succeeds" response propagates back to program routine 210.”, Col. 6, lines 14-21: “Each layer 250 propagates the responses upward through the above layers back to program routine 210. As each layer 250 receives the Request status response, the layer deletes or "cleans up" its contextual information from context data structures 330, and frees all resources allocated for the Request. Further, as the Cancel status response propagates upward, each layer 250 cleans up the contextual information on the Cancel from context data structures 330.”, Figs. 4-5).
Knight fails to teach modifying a sequence number to generate a modified sequence number at a target context entry of a request context table to indicate the target context entry as invalid.
In analogous art CHAKRABARTI teaches modifying a sequence number to generate a modified sequence number at a target context entry of a request context table to indicate the target context entry as invalid ([0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number, wherein modifying the active/inactive flag (bit) to inactive (0 or 1) invalidates the service (request)).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Knight to incorporate the teachings of CHAKRABARTI to determine which operator to send the received data of a customer request (CHAKRABARTI [0046] “…The MARS service 114 may be able to communicate with more than one operator, as each customer sending a customer request may be associated with separate operators. To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106…”).
Knight and CHAKRABARTI fail to teach providing a processing request completion indicator to the local processing resource to verify, by processing the processing request completion indicator through the local processing resource, that any processing requests associated with the service request, which have arrived at the local processing resource before arrival of the processing request completion indicator, have completed processing.
In analogous art Allen teaches providing a processing request completion indicator to the local processing resource to verify, by processing the processing request completion indicator through the local processing resource, that any processing requests associated with the service request, which have arrived at the local processing resource before arrival of the processing request completion indicator, have completed processing (Col. 8, lines 56-65: “For example, multiple completed or committed requests may be required before processing of a request may be canceled. In such an environment, a counter may be maintained by the cancellation manager or some other service in order to track the number of completed request. Two or more distinct cancellation signals may be used to differentiate between signaling of a committed request and signaling that the requisite number of request have been completed and outstanding requests may be terminated.”, Fig. 3, Note: The counter acts as the processing request completion indicator to count the number of completed requests which can include all the outstanding requests).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Knight and CHAKRABARTI to incorporate the teachings of Allen to partially process a request and return the result (Allen Col. 2, lines 10-13: “In order to enable conditional processing of the request at various locations a cancellation token may be used to coordinate request processing among the various locations.”, Allen Col. 12, lines 4-7: “Returning to FIG. 7, once the cancellation signal has been transmitted 712, the request processor may complete processing of the request and return the result 714.”).
Regarding claim 2, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 1, and Knight further teaches receiving, at a processing engine, the service request requesting a returned result; and in response to receiving the service request, generating the processing request by adding the request context for the processing request to the target context entry in the request context table, wherein the request context for the processing request comprises a context identifier, the sequence number, and request servicing information (Col. 4 lines 60-67 and Col. 5 lines 1-2: “When issuing a service Request, program routine 210 sends a Request message through FPI 220 to family 320, which includes the program code for controlling the family services. The FPI 220 generates ID information, such as a Request ID or a connection ID, and returns the information to program routine 210. Routine 210 then adds this ID information, and possibly other contextual information, to context data structures 310. Family 320 recognizes the Request, and adds contextual information to context data structures 330 to "remember" the Request.”, Figs. 4-5).
Regarding claim 3, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 2, and Knight further teaches wherein identifying the cancellation indication to cancel the service request comprises identifying the processing request generated in response to receiving the service request within the request context table (Col. 5, lines 56-59: “If the message has been forwarded, administrative system 360 adds to context data structures 330 contextual information including a Cancel tag to inform family 320 that the Request is "to be canceled."”).
Regarding claim 4, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 3, and CHAKRABARTI further teaches wherein generating the modified sequence number at the target context entry of the request context table comprises changing a most-significant bit of the sequence number or adding a number to the sequence number ([0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number, wherein modifying the active/inactive flag (bit) to inactive changes the most-significant bit of the sequence number).
Regarding claim 5, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 3, Knight further teaches the request verification check is present at the local processing resource before the processing request arrives at the local processing resource to be processed; and providing the request verification check before the local processing resource comprises (Col. 5, lines 61-62: “a Cancel message may reach a particular layer 250 ahead of the Request”), and CHAKRABARTI further teaches determining that the sequence number associated with the processing request is invalid based on the sequence number within a token associated with the processing request not matching the sequence number in the target context entry for the processing request in the request context table ([0046] “…The MARS service 114 may be able to communicate with more than one operator, as each customer sending a customer request may be associated with separate operators. To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, [0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number, wherein modifying the active/inactive flag (bit) to inactive invalidates the service (request). When the MARS service checks the records in the AAA server, the combination of a unique service type, customer ID, GW Address, and an inactive flag (bit) (combination is the sequence number) will not “match” the sequence number of the request currently searching for its record to send data to an operator. Therefore, the request was invalidated.).
Regarding claim 6, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 5, and Knight further teaches based on determining that the processing request is invalid: preventing the processing request from accessing the local processing resource; and dropping the processing request (Col. 6, lines 14-21: “Each layer 250 propagates the responses upward through the above layers back to program routine 210. As each layer 250 receives the Request status response, the layer deletes or "cleans up" its contextual information from context data structures 330, and frees all resources allocated for the Request. Further, as the Cancel status response propagates upward, each layer 250 cleans up the contextual information on the Cancel from context data structures 330.”, Col. 6, lines 3-10: “Based on the type of Cancel, the layer 250 where the Cancel reaches the Request generates a Request status response and a Cancel status response. If the Cancel is non-transactional, i.e. where the actual target system actions are deemed immaterial, the results of target system 240 operations may be discarded at this time and a "Cancel Succeeds" response propagates back to program routine 210.”, Figs. 4-5).
Regarding claim 7, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 5, and CHAKRABARTI further teaches further comprising identifying the target context entry for the processing request in the request context table by utilizing the context identifier within the token of the processing request to identify the target context entry ([0046] “…To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, Note: The combination of the service type identifier, customer ID, and IP address of the selected 610 GW is the context identifier of the request).
Regarding claim 8, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 2, and Knight further teaches further comprising overwriting data in the target context entry after the target context entry is marked as invalid, wherein overwriting the data in the target context entry comprises generating a new sequence number while maintaining the context identifier for the target context entry (Col. 4 line 67 and Col. 5 lines 1-5: “Family 320 recognizes the Request, and adds contextual information to context data structures 330 to "remember" the Request. Family 320 may generate new ID information associated with the original ID information for the new Request, and may replace the original ID with the new ID in the Request.”).
Regarding claim 9, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 1, and Allen further teaches wherein providing the processing request completion indicator to the local processing resource comprises: processing the processing request completion indicator at the local processing resource to confirm that any processing requests currently in the local processing resource upon the arrival of the processing request completion indicator have been cleared out (Col. 8, lines 56-65: “For example, multiple completed or committed requests may be required before processing of a request may be canceled. In such an environment, a counter may be maintained by the cancellation manager or some other service in order to track the number of completed request. Two or more distinct cancellation signals may be used to differentiate between signaling of a committed request and signaling that the requisite number of request have been completed and outstanding requests may be terminated.”, Fig. 3, Note: The counter acts as the processing request completion indicator to count the number of completed requests which can include all the outstanding requests); and returning the processing request completion indicator to indicate that the local processing resource has been cleared out (Col. 8, lines 56-65: “Two or more distinct cancellation signals may be used to differentiate between signaling of a committed request and signaling that the requisite number of request have been completed and outstanding requests may be terminated.”, Fig. 3, Note: A signal is sent that the requisite number of requests have been completed (which can include all the outstanding requests), and thus also indicating that the resource has been cleared out).
Regarding claim 10, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 1, Allen further teaches the processing request is a remote processing request sent to a remote computing device for processing (Col. 5, lines 5-7: “In various embodiments, the request registered with the cancellation manager 114 may be duplicated and distributed over the network to one or more remote locations.”), CHAKRABARTI further teaches the remote processing request is sent to the remote computing device with a token comprising a context identifier and the sequence number for the processing request ([0046] “…The MARS service 114 may be able to communicate with more than one operator, as each customer sending a customer request may be associated with separate operators. To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, [0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The request must be sent with at least the combination of a unique service type, customer ID, GW Address, and “active” flag (combination is the sequence number) to be able to search for its record in the AAA server. The context identifier may be the combination of a unique service type, customer ID, and GW Address), and Allen further teaches the cancellation indication is identified while the remote processing request is at the remote computing device (Col. 5, lines 10-22: “The remote location may contain request processors 110 and 112 for processing the replicated request transmitted by the cancellation manager 114. In various embodiments, the request processors 110 and 112 may have associated cancellation managers and/or queues to facilitate request handling and processing. The cancellation manager may create a cancellation token associated with the one or more duplicated requests. The cancellation token may be associated with the request by including identification information for the cancellation token in metadata for the request in the request queue. Creation of the cancellation token by the cancellation manager 114 may occur in parallel or in serial with the timeout period described above.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Knight and CHAKRABARTI to incorporate the teachings of Allen to reduce latency of a response to a request (Allen Col. 1, lines 63-66: “Latency in processing requests (also referred to simply as requests) may be reduced by transmitting copies of the request to nearby network locations with greater computing capacity.”).
Regarding claim 11, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 10, and CHAKRABARTI further teaches receiving a result for the remote processing request from the remote computing device, the result comprising the token; providing the result and the token to the local processing resource ([0046] “…To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, Note: The combination of the service type identifier, customer ID, and IP address of the selected 610 GW is the context identifier of the request (part of the token) and the received data (results) are provided to the AAA server (local processing resource)); and determining, utilizing the request verification check, that the processing request has been invalidated based on the sequence number in the token not matching the modified sequence number ([0046] “…The MARS service 114 may be able to communicate with more than one operator, as each customer sending a customer request may be associated with separate operators. To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, [0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number, wherein modifying the active/inactive flag (bit) to inactive invalidates the service (request). When the MARS service checks the records in the AAA server, the combination of a unique service type, customer ID, GW Address, and an inactive flag (bit) (combination is the sequence number) will not “match” the sequence number of the request currently searching for its record to send data to an operator. Therefore, the request was invalidated.).
Regarding claim 12, Knight teaches a processing engine comprising: a memory comprising a request context table having context entries each comprising a context identifier, a unique sequence number, and request servicing information; a local processing resource for processing one or more processing requests; and the processing engine is programmed to (Col. 3, lines 33-39: “An operating system 180 is a program that controls processing by CPU 110, and is typically stored in data storage 160 and loaded into RAM 150 for execution by CPU 110. CPU 110 has access to RAM 150 for storing intermediate results and miscellaneous data. Operating system 180 includes a cancellation system 190, which is a program that cancels previously-issued service Requests.”, Col. 4 lines 60-67 and Col. 5 lines 1-2: “When issuing a service Request, program routine 210 sends a Request message through FPI 220 to family 320, which includes the program code for controlling the family services. The FPI 220 generates ID information, such as a Request ID or a connection ID, and returns the information to program routine 210. Routine 210 then adds this ID information, and possibly other contextual information, to context data structures 310. Family 320 recognizes the Request, and adds contextual information to context data structures 330 to "remember" the Request.”, Fig. 1): identify a cancellation indication to cancel a service request that is currently being processed (Col. 4, lines 28-35: “For various reasons, such as cancellation by a user, expiration of a time limit or system termination of a particular task, program routine 210 may attempt to cancel a previously-issued Request. Program routine 210 sends the Cancel message through FPI 220 to Family Server 230, in search of the original Request. Program routine 210 maintains contextual information that the Cancel message was sent.”, Figs. 4-5); in response to the cancellation indication … wherein the target context entry represents a processing request associated with the service request (Col. 4 lines 60-67 and Col. 5 lines 1-2: “When issuing a service Request, program routine 210 sends a Request message through FPI 220 to family 320, which includes the program code for controlling the family services. The FPI 220 generates ID information, such as a Request ID or a connection ID, and returns the information to program routine 210. Routine 210 then adds this ID information, and possibly other contextual information, to context data structures 310. Family 320 recognizes the Request, and adds contextual information to context data structures 330 to "remember" the Request.”, Figs. 4-5) … add a request verification check before the local processing resource, the request verification check preventing invalid processing requests from accessing the local processing resource (Col. 5, lines 56-64: “If the message has been forwarded, administrative system 360 adds to context data structures 330 contextual information including a Cancel tag to inform family 320 that the Request is "to be canceled." Since the administrative system 360 processes the Cancel asynchronously and at high priority, a Cancel message may reach a particular layer 250 ahead of the Request. Accordingly, maintaining contextual information on the Cancel enables canceling the Request when the Request finally does arrive at the layer.”, Figs. 4-5) … and confirm cancellation of the service request by indicating that the local processing resource will not be accessed to further process the processing request associated with the service request (Col. 6, lines 8-10: “a "Cancel Succeeds" response propagates back to program routine 210.”, Col. 6, lines 14-21: “Each layer 250 propagates the responses upward through the above layers back to program routine 210. As each layer 250 receives the Request status response, the layer deletes or "cleans up" its contextual information from context data structures 330, and frees all resources allocated for the Request. Further, as the Cancel status response propagates upward, each layer 250 cleans up the contextual information on the Cancel from context data structures 330.”, Figs. 4-5).
Knight fails to teach modify a sequence number to generate a modified sequence number within a target context entry of the context entries of the request context table … and wherein modifying the sequence number invalidates the processing request.
In analogous art CHAKRABARTI teaches modify a sequence number to generate a modified sequence number within a target context entry of the context entries of the request context table … and wherein modifying the sequence number invalidates the processing request ([0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number, wherein modifying the active/inactive flag (bit) to inactive (0 or 1) invalidates the service (request)).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Knight to incorporate the teachings of CHAKRABARTI to determine which operator to send the received data of a customer request (CHAKRABARTI [0046] “…The MARS service 114 may be able to communicate with more than one operator, as each customer sending a customer request may be associated with separate operators. To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106…”).
Knight and CHAKRABARTI fail to teach in response to the cancellation indication, provide a processing request completion indicator to the local processing resource to verify, by processing the processing request completion indicator through the local processing resource, that processing requests at the local processing resource, which have preceded arrival of the processing request completion indicator, have completed processing at the local processing resource.
In analogous art Allen teaches in response to the cancellation indication, provide a processing request completion indicator to the local processing resource to verify, by processing the processing request completion indicator through the local processing resource, that processing requests at the local processing resource, which have preceded arrival of the processing request completion indicator, have completed processing at the local processing resource (Col. 8, lines 56-65: “For example, multiple completed or committed requests may be required before processing of a request may be canceled. In such an environment, a counter may be maintained by the cancellation manager or some other service in order to track the number of completed request. Two or more distinct cancellation signals may be used to differentiate between signaling of a committed request and signaling that the requisite number of request have been completed and outstanding requests may be terminated.”, Fig. 3, Note: The counter acts as the processing request completion indicator to count the number of completed requests which can include all the outstanding requests).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Knight and CHAKRABARTI to incorporate the teachings of Allen to partially process a request and return the result (Allen Col. 2, lines 10-13: “In order to enable conditional processing of the request at various locations a cancellation token may be used to coordinate request processing among the various locations.”, Allen Col. 12, lines 4-7: “Returning to FIG. 7, once the cancellation signal has been transmitted 712, the request processor may complete processing of the request and return the result 714.”).
Regarding claim 13, Knight, CHAKRABARTI, and Allen teach the processing engine of claim 12, and CHAKRABARTI further teaches wherein generating the modified sequence number at the target context entry of the request context table comprises changing a most-significant bit of the sequence number or adding a number to the sequence number ([0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number, wherein modifying the active/inactive flag (bit) to inactive changes the most-significant bit of the sequence number).
Regarding claim 14, Knight, CHAKRABARTI, and Allen teach the processing engine of claim 12, Knight further teaches wherein providing the request verification check before the local processing resource comprises (Col. 5, lines 61-62: “a Cancel message may reach a particular layer 250 ahead of the Request”), and CHAKRABARTI further teaches determining that an additional sequence number associated with an additional processing request is valid based on the additional sequence number within an additional token associated with the additional processing request matching the additional sequence number in an additional context entry for the additional processing request in the request context table ([0046] “…The MARS service 114 may be able to communicate with more than one operator, as each customer sending a customer request may be associated with separate operators. To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, [0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number. When the MARS service checks the records in the AAA server, the combination of a unique service type, customer ID, GW Address, and an active flag (bit) (combination is the sequence number) will “match” the sequence number of the request currently searching for its record to send data to an operator. Therefore, the request was allowed); and based on the additional processing request being valid, allowing the additional processing request to access the local processing resource ([0046] “…The MARS service 114 may be able to communicate with more than one operator, as each customer sending a customer request may be associated with separate operators. To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, Note: When the MARS service checks the records in the AAA server, the combination of a unique service type, customer ID, GW Address, and an active flag (bit) (combination is the sequence number) will “match” the sequence number of the request currently searching for its record to send data to an operator. Therefore, the request was allowed and data will be sent (accessing) to the operator (local processing resource)).
Regarding claim 15, Knight, CHAKRABARTI, and Allen teach the processing engine of claim 14, and Allen further teaches wherein providing the processing request completion indicator to the local processing resource includes: processing the processing request completion indicator at the local processing resource to confirm that any processing requests currently in the local processing resource upon the arrival of the processing request completion indicator have been cleared out (Col. 8, lines 56-65: “For example, multiple completed or committed requests may be required before processing of a request may be canceled. In such an environment, a counter may be maintained by the cancellation manager or some other service in order to track the number of completed request. Two or more distinct cancellation signals may be used to differentiate between signaling of a committed request and signaling that the requisite number of request have been completed and outstanding requests may be terminated.”, Fig. 3, Note: The counter acts as the processing request completion indicator to count the number of completed requests which can include all the outstanding requests); and returning the processing request completion indicator to indicate that the local processing resource has been cleared out (Col. 8, lines 56-65: “Two or more distinct cancellation signals may be used to differentiate between signaling of a committed request and signaling that the requisite number of request have been completed and outstanding requests may be terminated.”, Fig. 3, Note: A signal is sent that the requisite number of requests have been completed (which can include all the outstanding requests), and thus also indicating that the resource has been cleared out)).
Regarding claim 16, Knight teaches a computer-implemented method comprising: identifying, by a processing engine, a cancellation indication to cancel a service request that is currently being processed (Col. 4, lines 28-35: “For various reasons, such as cancellation by a user, expiration of a time limit or system termination of a particular task, program routine 210 may attempt to cancel a previously-issued Request. Program routine 210 sends the Cancel message through FPI 220 to Family Server 230, in search of the original Request. Program routine 210 maintains contextual information that the Cancel message was sent.”, Figs. 4-5); in response to the cancellation indication … the target context entry comprising a request context for a processing request being associated with the service request (Col. 4 lines 60-67 and Col. 5 lines 1-2: “When issuing a service Request, program routine 210 sends a Request message through FPI 220 to family 320, which includes the program code for controlling the family services. The FPI 220 generates ID information, such as a Request ID or a connection ID, and returns the information to program routine 210. Routine 210 then adds this ID information, and possibly other contextual information, to context data structures 310. Family 320 recognizes the Request, and adds contextual information to context data structures 330 to "remember" the Request.”, Figs. 4-5); providing, at the processing engine, a request verification check that occurs before a local processing pipeline resource, the request verification check preventing invalid processing requests from accessing the local processing pipeline resource (Col. 5, lines 56-64: “If the message has been forwarded, administrative system 360 adds to context data structures 330 contextual information including a Cancel tag to inform family 320 that the Request is "to be canceled." Since the administrative system 360 processes the Cancel asynchronously and at high priority, a Cancel message may reach a particular layer 250 ahead of the Request. Accordingly, maintaining contextual information on the Cancel enables canceling the Request when the Request finally does arrive at the layer.”, Figs. 4-5)…
Knight fails to teach modifying a sequence number to generate a modified sequence number at a target context entry of a request context table to indicate the target context entry as invalid … receiving, from a remote processing service, a processing result of a remote processing request, wherein the remote processing request was sent to the remote processing service based on the service request, and wherein the processing result comprises a token having a context identifier for the target context entry and the sequence number; and dropping the processing result based on determining that the sequence number in the token does not match the modified sequence number in the target context entry.
In analogous art CHAKRABARTI teaches modifying a sequence number to generate a modified sequence number at a target context entry of a request context table to indicate the target context entry as invalid ([0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number, wherein modifying the active/inactive flag (bit) to inactive (0 or 1) invalidates the service (request)) … receiving, from a remote processing service, a processing result of a remote processing request, wherein the remote processing request was sent to the remote processing service based on the service request, and wherein the processing result comprises a token having a context identifier for the target context entry and the sequence number ([0046] “…To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number; and the combination of the service type identifier, customer ID, and IP address of the selected 610 GW is the context identifier of the request (part of the token)); and dropping the processing result based on determining that the sequence number in the token does not match the modified sequence number in the target context entry ([0046] “…The MARS service 114 may be able to communicate with more than one operator, as each customer sending a customer request may be associated with separate operators. To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, [0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number, wherein modifying the active/inactive flag (bit) to inactive invalidates the service (request). When the MARS service checks the records in the AAA server, the combination of a unique service type, customer ID, GW Address, and an inactive flag (bit) (combination is the sequence number) will not “match” the sequence number of the request currently searching for its record to send data to an operator. Therefore, the request was invalidated.).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Knight to incorporate the teachings of CHAKRABARTI to determine which operator to send the received data of a customer request (CHAKRABARTI [0046] “…The MARS service 114 may be able to communicate with more than one operator, as each customer sending a customer request may be associated with separate operators. To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106…”).
Knight and CHAKRABARTI fail to teach providing, at the processing engine, a processing request completion indicator to the local processing pipeline resource to verify, by processing the processing request completion indicator through the local processing pipeline resource, that any local processing requests triggered in response to the service request have, if started before receiving the processing request completion indicator, complete processing at the local processing pipeline resource.
In analogous art Allen teaches providing, at the processing engine, a processing request completion indicator to the local processing pipeline resource to verify, by processing the processing request completion indicator through the local processing pipeline resource, that any local processing requests triggered in response to the service request have, if started before receiving the processing request completion indicator, complete processing at the local processing pipeline resource (Col. 8, lines 56-65: “For example, multiple completed or committed requests may be required before processing of a request may be canceled. In such an environment, a counter may be maintained by the cancellation manager or some other service in order to track the number of completed request. Two or more distinct cancellation signals may be used to differentiate between signaling of a committed request and signaling that the requisite number of request have been completed and outstanding requests may be terminated.”, Note: The counter acts as the processing request completion indicator to count the number of completed requests which can include all the outstanding requests).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Knight and CHAKRABARTI to incorporate the teachings of Allen to partially process a request and return the result (Allen Col. 2, lines 10-13: “In order to enable conditional processing of the request at various locations a cancellation token may be used to coordinate request processing among the various locations.”, Allen Col. 12, lines 4-7: “Returning to FIG. 7, once the cancellation signal has been transmitted 712, the request processor may complete processing of the request and return the result 714.”).
Regarding claim 17, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 16, and Knight further teaches by the processing engine, cancellation of the service request by indicating that the local processing pipeline resource will not be accessed to further process the service request (Col. 6, lines 8-10: “a "Cancel Succeeds" response propagates back to program routine 210.”, Col. 6, lines 14-21: “Each layer 250 propagates the responses upward through the above layers back to program routine 210. As each layer 250 receives the Request status response, the layer deletes or "cleans up" its contextual information from context data structures 330, and frees all resources allocated for the Request. Further, as the Cancel status response propagates upward, each layer 250 cleans up the contextual information on the Cancel from context data structures 330.”, Figs. 4-5).
Regarding claim 18, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 16, and Allen further teaches the processing request is a remote processing request sent to a remote computing device for processing (Col. 5, lines 5-7: “In various embodiments, the request registered with the cancellation manager 114 may be duplicated and distributed over the network to one or more remote locations.”), CHAKRABARTI further teaches the remote processing request is sent to the remote computing device with a token comprising a context identifier and the sequence number for the processing request ([0046] “…The MARS service 114 may be able to communicate with more than one operator, as each customer sending a customer request may be associated with separate operators. To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, [0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The request must be sent with at least the combination of a unique service type, customer ID, and GW Address (combination is the sequence number) to be able to search for its record in the AAA server. The context identifier may be a subset of the request’s sequence number), and Allen further teaches the cancellation indication is identified while the remote processing request is at the remote computing device (Col. 5, lines 10-22: “The remote location may contain request processors 110 and 112 for processing the replicated request transmitted by the cancellation manager 114. In various embodiments, the request processors 110 and 112 may have associated cancellation managers and/or queues to facilitate request handling and processing. The cancellation manager may create a cancellation token associated with the one or more duplicated requests. The cancellation token may be associated with the request by including identification information for the cancellation token in metadata for the request in the request queue. Creation of the cancellation token by the cancellation manager 114 may occur in parallel or in serial with the timeout period described above.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Knight and CHAKRABARTI to incorporate the teachings of Allen to reduce latency of a response to a request (Allen Col. 1, lines 63-66: “Latency in processing requests (also referred to simply as requests) may be reduced by transmitting copies of the request to nearby network locations with greater computing capacity.”).
Regarding claim 19, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 18, and CHAKRABARTI further teaches receiving the processing result from the remote computing device after modifying the sequence number at the target context entry, wherein the processing result comprises the token; providing the processing result and the token to the local processing pipeline resource ([0046] “…To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, [0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number, wherein modifying the active/inactive flag (bit) to inactive (0 or 1) invalidates the service (request)); and determining, utilizing the request verification check before access is allowed to the local processing pipeline resource, that the processing request has been invalidated based on the sequence number in the token not matching the modified sequence number ([0046] “…The MARS service 114 may be able to communicate with more than one operator, as each customer sending a customer request may be associated with separate operators. To determine which operator to send the received data to, the MARS service sends a request to an AAA (authentication, authorization, and accounting) server 102 to cause the AAA server 102 to determine if it has a record associated with the service type identifier, customer ID, and IP address of the selected 610 GW corresponding to the received customer request 106 … If the AAA server 102 determines that a record does exist, the MARS service 114 receives from the AAA server the operator identifier associated with the particular service type, customer ID, and 610 GW address…”, [0048] “In some embodiments, each record on the AAA corresponding to unique service type, customer ID, and GW address combination also includes an active/inactive flag, and records are marked as active once a successful request matching that record from the MARS service 114 is made, or marked as inactive if the MARS service 114 communicates a termination request to the AAA server 102 for the service corresponding with the record.”, Note: The combination of a unique service type, customer ID, GW Address, and an active/inactive flag (bit) is the sequence number, wherein modifying the active/inactive flag (bit) to inactive invalidates the service (request). When the MARS service checks the records in the AAA server, the combination of a unique service type, customer ID, GW Address, and an inactive flag (bit) (combination is the sequence number) will not “match” the sequence number of the request currently searching for its record to send data to an operator. Therefore, the request was invalidated.).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Knight et al. Pat. No. US 6,178,464 Bl (hereafter Knight which was cited in the IDS filed 01/22/2024) in view of CHAKRABARTI et al. Pub. No. US 2015/0365278 Al (hereafter CHAKRABARTI), further in view of Allen Pat. No. US 9,781,053 Bl (hereafter Allen which was cited in the IDS filed 01/22/2024) as applied to claims 1-19 above, and further in view of WONG et al. Pub. No. US 2023/0102063 Al (hereafter WONG).
Regarding claim 20, Knight, CHAKRABARTI, and Allen teach the computer-implemented method of claim 18.
Knight, CHAKRABARTI, and Allen fail to teach wherein the processing engine comprises a hardware accelerator, and wherein the local processing pipeline resource comprises an on-chip pipeline.
In analogous art WONG teaches wherein the processing engine comprises a hardware accelerator, and wherein the local processing pipeline resource comprises an on-chip pipeline ([0013] “An implementation is directed to a method of providing an optimized service-based pipeline. The method includes receiving a request that includes a description of a workload from a workload initiator. The method also includes inspecting runtime utilization metrics of a plurality of processing resources based on the workload description, where the plurality of processing resources includes at least a first GPU and a second GPU…”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified Knight, CHAKRABARTI, and Allen to incorporate the teachings of WONG to select a GPU that has the ability and resources to execute a workload (WONG [0010] “…The operating system can respond by identifying the GPUs that have the ability to execute the workload. Based on the operating system's response, the application can select a GPU and assign the workload to that GPU…”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. In particular, US 2007/0160080 Al is cited because it discloses process and task lists with states. In addition, US 2009/0327468 Al is cited because it discloses terminating a request by asynchronously setting a termination flag in the command thread executing the request.
THIS ACTION IS MADE FINAL. 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.
Examiner respectfully requests, in response to this Office action, support be
shown for language added to any original claims on amendment and any new claims.
That is, indicate support for newly added claim language by specifically pointing to
page(s) and line number(s) in the specification and/or drawing figure(s). This will assist
Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111 (c).
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN CHE-CHUN TONG whose telephone number is (703)756-1737. The examiner can normally be reached Monday-Thursday: 7:30 AM to 5:00 PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on (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.
/J.C.T./Examiner, Art Unit 2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196