DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-24 are pending in this application.
Response to Arguments
Applicant’s arguments regarding the rejections of claims 18-24 under 35 U.S.C. 112a have been withdrawn, but new 35 U.S.C. 112a rejections of claims 11-24 are made based on the amendments.
Applicant's arguments regarding the 35 U.S.C. 101 rejections of claims 11-14 and 19 have been fully considered but the arguments regarding the 35 U.S.C. 101 rejections of claims 11-14 are unpersuasive and the arguments regarding the 35 U.S.C. 101 rejection of claim 19 is persuasive.
Regarding the 35 U.S.C. 101 rejection, the applicant argues the following in the remarks:
It is simply impossible for a human to analyze a computer queue.
A human mind cannot practically determine the maximum available transaction length of a queue including a plurality of requests in the mind because the problem requires precise, parallel evaluation of ordering, constraints, and cumulative state across many elements.
Examiner has thoroughly considered Applicant’s arguments, but respectfully finds them unpersuasive for at least the following reasons:
As to point (a), the examiner respectfully disagrees. Humans can access queues in computers. One of the most common queues that humans access is the print queue in a computer. Humans can access queues and mentally observe and evaluate queues.
As to point (b), the examiner considers this argument to be moot since the mental process recited in claim 11 is “determining…a maximum available transaction length based at least in part on the plurality of requests in the queue” and not “determine the maximum available transaction length of a queue including a plurality of requests”.
Applicant's arguments regarding the 35 U.S.C. 103 rejections of claims 1-24 have been fully considered but they are either unpersuasive or moot in light of the references being applied in the current rejection.
Regarding the 35 U.S.C. 103 rejection, the applicant argues the following in the remarks:
Farrell fails to disclose sending a notification that includes the grace period after preempting the process.
Bates does not disclose the operating system determining whether the lower priority thread can complete processing within the time provided by the wait-time attribute.
Shari does not teach “notifying…the first requester that the first request exceeds the maximum available transaction length before processing any portion of the first request by the shared resource”.
The previously applied references used to teach claim 18 fail to teach receive a third request from the first requester, the third request being the same as the first request; and add the third request to the queue for the shared resource.
Examiner has thoroughly considered Applicant’s arguments, but respectfully finds them unpersuasive for at least the following reasons:
As to point (a), the examiner respectfully disagrees. Farrell recites in [0050] “In accordance with an aspect of the present invention, a grace period or extension is provided that includes a warning indicating to the guest program that particular action should be taken (e.g., complete a dispatchable unit or make the dispatchable unit re-dispatchable). As examples, the grace period is provided in response to expiration of the timeslice, or in response to the host pre-empting the guest”. Therefore, the grace period is provided in response to preemption.
As to point (b), the examiner argues that this is not what the claim recites. The claims recite “in response to determining, by the resource manager, the shared resource can complete the first request within the hold time” and “in response to determining, by the resource manager, the shared resource cannot complete the first request within the hold time”. The claims do not recite that the resource manager has to be an operating system. Figure 2 of Bates shows a step of determining whether or not the first thread can be wound up in time TW. Figure 2 is a method performed by a computer system consisting of one or more processors.
As to point (c), this point is moot in light of the references being applied in the current rejection.
As to point (d), a new reference is applied to teach receive a third request from the first requester, the third request being the same as the first request, so the point that the previously applied references do not teach this limitation is moot. Regarding the limitation “add the third request to the queue for the shared resource”, this limitation is taught by Kandhalu.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 11-24 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As per claim 11:
Line 8-10 recite “notifying, by the processor, the first requestor that the first request exceeds the maximum available transaction length before processing any portion of the first request by the shared resource” but this is not supported by the specification. The specification recites in [0075] that “the resource manager 110 notifies the first requestor that the first request exceeds the maximum available transaction length”. Therefore, it is the resource manager and not processor that notifies the first requestor that the first request exceeds the maximum available transaction length.
As per claim 18:
Lines 2-9 recite “a processor configured to:…preempt the processing of the first request and notify the first requestor; send, after the first request is preempted, a notification that the first request was preempted; receive a third request from the first requester, the third request being the same as the first request” but this is not supported by the specification. The specification recites in [0005] “The processor is configured to receive a notification that the first request was preempted”, in [0034] “The requestor, such as an application, context, or processor, may be notified by resource manager 110 that the task was preempted”, in [0064] “where the resource manager 110 preempts the processing of the first request and notifies the first requestor of the preemption”, and in [0041] “The requestor of thread T2 may resubmit a request that is identical to thread T2 to resource manager 110”. It is the resource manager and not the processor that preempts the processing of the first request and notifies the first requestor. It is the resource manager and not the processor that sends a notification that the first request was preempted after the first request is preempted. It is the resource manager and not the processor that receives the third request.
Claims 12-17 and 19-24 are dependent claims of claims 11 and 18, and fail to resolve the deficiencies of claims 11 and 18, so they are rejected for the same reasons.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 8-24 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claim 8:
Line 6 recites “processing, by the resource manager, the first request at the shared resource” so it is unclear if the resource manager or the shared resource is processing the first request.
As per claim 11:
Lines 2-3 recite “adding, by a processor, a plurality of requests from one or more requestors to a queue for a shared resource” and line 6 recites “receiving, by the processor, a first request from a first requestor”. Therefore, it is redundant for the processor to receive the first request from the first requestor since the processor already adds the plurality of requests from one or more requestors to a queue.
As per claim 18:
Lines 7-9 recite “preempt the processing of the first request and notify the first requestor; send, after the first request is preempted, a notification that the first request was preempted” which is redundant.
Claims 9-10, 12-17, and 19-24 are dependent claims of claims 2, 11, and 18, and fail to resolve the deficiencies of claims 2, 11, and 18, so they are rejected for the same reasons.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 11-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more.
As per claim 11, in step 1 of the 101 analysis, the examiner has determined that the claim
is directed to a method. Therefore, the claim is directed to one of the four statutory categories of invention.
In step 2A prong 1 of the 101 analysis, the examiner has determined that the claim recites
a judicial exception. Specifically, the limitation “determining a maximum available transaction length based at least in part on the plurality of requests in a queue” is a mental process. Determining a maximum available transaction length is a mental process since humans can observe data to determine a duration that the shared resource is available for a transaction.
In step 2A prong 2 of the 101 analysis, the examiner has determined that the additional elements, alone or in combination do not integrate the judicial exceptions into a practical application for the following rationale:
The limitations "adding a plurality of requests from one or more requestors to a queue for a shared resource", “receiving a first request from a first requestor”, and “notifying the first requestor that the first request exceeds the maximum available transaction length before processing any portion of the first request by the shared resource” represent insignificant, extra-solution activities. The term "extra-solution activity" can be understood as "activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim" (MPEP 2106.05(g)). The examiner has determined that the limitations "adding a plurality of requests from one or more requestors to a queue for a shared resource", “receiving a first request from a first requestor”, and “notifying the first requestor that the first request exceeds the maximum available transaction length before processing any portion of the first request by the shared resource” are directed to mere data gathering activities which is a category of insignificant extra-solution activities (MPEP 2106.05(g)).
The limitations "by a processor" and "by the processor" apply judicial exceptions on a generic computer. "Alappat 's rationale that an otherwise ineligible algorithm or software could be made patent-eligible by merely adding a generic computer to the claim was superseded by the Supreme Court's Bilski and Alice Corp. decisions" so therefore applying judicial exceptions on a processor which is a generic computer does not integrate the judicial exceptions into a practical application (MPEP 2106.05(b)).
In step 2B of the 101 analysis, the examiner has determined that the additional elements, alone or in combination do not recite significantly more than the abstract ideas identified above for the following rationale:
The limitations "adding a plurality of requests from one or more requestors to a queue for a shared resource", “receiving a first request from a first requestor”, and “notifying the first requestor that the first request exceeds the maximum available transaction length before processing any portion of the first request by the shared resource” represent insignificant, extra-solution activities. The limitations "adding a plurality of requests from one or more requestors to a queue for a shared resource", “receiving a first request from a first requestor”, and “notifying the first requestor that the first request exceeds the maximum available transaction length before processing any portion of the first request by the shared resource” are well-understood, routine, or conventional because they are directed to "receiving or transmitting data" or “storing and retrieving information in memory” (MPEP 2106.05(d)). These are additional elements that the courts have recognized as well understood, routine, or conventional (MPEP 2106.05(d)). The citation of court cases in the MPEP meets the Berkheimer evidentiary burden since citation of a court case in the MPEP is one of the 4 types of evidentiary support that can be used to prove that the additional elements are well-understood, routine, or conventional (see 125 USPQ2d 1649 Berkheimer v. HP, Inc.). Thus, the limitations do not amount to significantly more than the abstract idea.
The limitations "by a processor" and "by the processor" apply judicial exceptions on a generic computer and therefore do not provide significantly more.
As per claim 12, it recites “notifying the first requestor of the maximum available transaction length” which is an insignificant extra solution activity that is well understood, routine, or conventional because it is directed to "receiving or transmitting data". Therefore, the additional element neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 13, it recites “wherein the revised request fits within the maximum available transaction length” which is an attribute of the technological environment and “adding a revised request from the first requestor to the queue for the shared resource” which is an insignificant extra solution activity that is well understood, routine, or conventional because it is directed to “storing and retrieving information in memory”. Therefore, the additional elements neither integrate the judicial exception into a practical application nor recite significantly more.
As per claim 14, it recites “wherein the revised request is scheduled to execute when its transaction length fits within an estimated duration of availability window” which is a mental process since scheduling can be performed in the human mind.
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 and 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu Raghu et al. (US 11219039 B2 hereinafter Kandhalu) in view of Farrell et al. (US 20130185732 A1 hereinafter Farrell).
Kandhalu was cited in the IDS filed on 04/28/2023.
As per claim 1, Kandhalu teaches a method, comprising: adding a first request from a first requestor to a queue for a shared resource, wherein the first request has a first priority (Col. 7 lines 39-40 three low priority radio commands B1, B2, and B3 from protocol stack B 306; Col. 7 lines 35-36 a queued low priority radio command; Col. 6 lines 10-12 the new radio command is low priority, the radio command scheduler 314 attempts to add the new radio command to the radio command queue; Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks);
providing the first request to the shared resource from the queue; processing the first request at the shared resource (Fig. 7; Col. 7 lines 62-64 the low priority non-time critical radio command B1 is currently being executed by the radio driver 310; Col. 7 lines 35-36 a queued low priority radio command);
adding a second request from a second requestor to the queue for the shared resource, wherein the second request has a second priority that is higher than the first priority (Col. 7 lines 22-24 receives a new radio command A4 from protocol stack A 308. The radio command scheduler 314 attempts to add A4 to the radio command queue 320; Col. 7 lines 40-45 At time T2, the radio command scheduler 314 receives a new radio command A4 from the protocol stack A 308 that is high priority as per the scheduling policy for the current states of the protocol stack. The radio command scheduler 314 attempts to add A4 to the radio command queue 320; Col. 6 lines 64-66 If the new radio command is high priority and the queued radio command occupying the specified time slot is low priority);
preempting the processing of the first request; notifying the first requestor of the preemption, providing duration of availability for the shared resource; providing the second request to the shared resource from the queue; and processing the second request at the shared resource (Col. 6 line 64-Col. 7 line 9 If the new radio command is high priority and the queued radio command occupying the specified time slot is low priority, the radio command scheduler 314 pre-empts the queued low priority radio command to free up the specified time slot for the new radio command in the radio command queue 320 and inserts the new radio command in the radio command queue 314…the radio command scheduler 314 aborts the pre-empted radio command and notifies the protocol stack that issued the low priority radio command that the radio command has been pre-empted; Col. 5 lines 59-66 If the new radio command is a high priority command as per the scheduling policy, the currently executing radio command is a low priority command, and the start and end time parameters of the new radio command overlap the time slot of the low priority command, the scheduler 314 aborts execution of the low priority radio command and places the new radio command at the head of the radio command queue 320 to be immediately executed; Col. 6 lines 2-4 the radio command scheduler 314 notifies the protocol stack that issued the low priority radio command that the radio command was aborted; Col. 6 lines 18-20 If the time slot specified by the start time and end time parameters of the new radio command is available between two queued radio commands; Col. 7 lines 16-18 FIG. 5 is an example of inserting a radio command in an available time slot in the radio command queue 320; Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks).
Kandhalu fails to teach after preempting the processing of the first request, notifying the first requestor of the preemption, wherein notifying the first requestor of the preemption includes providing the first requestor with duration of availability for the shared resource.
However, Farrell teaches after preempting the processing of the first request, notifying the first requestor of the preemption, wherein notifying the first requestor of the preemption includes providing the first requestor with duration of availability for the shared resource ([0033] In one particular embodiment, a capability is provided in which a guest program executing on a guest CPU provisioned by a host CPU is provided a warning of expiration of a timeslice given to the guest CPU from the host CPU or of pre-emption by the host of the guest's timeslice. The warning provides a grace period that the guest CPU can use to perform a particular function, such as complete execution of a dispatchable unit; [0050] In accordance with an aspect of the present invention, a grace period or extension is provided that includes a warning indicating to the guest program that particular action should be taken (e.g., complete a dispatchable unit or make the dispatchable unit re-dispatchable). As examples, the grace period is provided in response to expiration of the timeslice, or in response to the host pre-empting the guest; [0035] Each processor (and/or a program, such as an operating system, executing on the processor) is given a certain amount of time, referred to as a timeslice, to share the resources; claim 8 the grace period provides a period in addition to the timeslice; [0110] In one embodiment, a logical (guest) processor running in a timeslice on a physical processor receives a warning signal indicating a grace period, e.g., an amount of time before the logical processor will be interrupted (deallocated from the physical processor that may be shared) enabling the work being done by the logical processor to be either completed; A grace period is a duration of availability for the shared resource since it is an extension of a timeslice which is an amount of time that a guest processor is allocated to a shared resource. ).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu with the teachings of Farrell to improve execution duration of time sensitive work (see Farrell [0145] In a further embodiment, one or more aspects of the invention can be used with requests from an operating system to let an individual execution thread continue to improve elapsed time of time sensitive work. That is, a thread may request or be provided additional time to perform a function.).
As per claim 5, Kandhalu and Farrell teach the method of claim 1. Kandhalu teaches wherein the first request is associated with a Bluetooth® Low Energy protocol (Col. 2 lines 17-19 Embodiments of the disclosure provide for concurrent execution of multiple protocols, e.g., Bluetooth Low Energy (BLE); Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks.).
As per claim 6, Kandhalu and Farrell teach the method of claim 5. Kandhalu teaches wherein the second request is associated with a Zigbee protocol (Col. 2 lines 56-58 he protocol software includes protocol stacks for the supported protocols, e.g., Thread, Zigbee; Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks.).
As per claim 7, Kandhalu and Farrell teach the method of claim 1. Kandhalu teaches further comprising: receiving a third request with a third priority at the queue; receiving a fourth request with a fourth priority at the queue (Col. 7 lines 16-21 FIG. 5 is an example of inserting a radio command in an available time slot in the radio command queue 320. The original schedule 500 includes three radio commands A1, A2, and A3 from protocol stack A 308 and three radio commands B1, B2, and B3 from protocol stack B 306; Col. 7 lines 37-40 The original schedule 600 includes three high priority radio commands A1, A2, and A3 from protocol stack A 308 and three low priority radio commands B1, B2, and B3 from protocol stack B 306.); when the third priority is higher than the fourth priority, complete the third request first with the shared resource; when the fourth priority is higher than the third priority, complete the fourth request first with the shared resource (Col. 6 line 64-Col. 7 line 3 If the new radio command is high priority and the queued radio command occupying the specified time slot is low priority, the radio command scheduler 314 pre-empts the queued low priority radio command to free up the specified time slot for the new radio command in the radio command queue 320 and inserts the new radio command in the radio command queue 314; Col. 6 lines 40-45 If the new radio command is low priority, the radio command scheduler 314 cannot pre-empt the queued radio command occupying the specified time slot in favor of the new radio command as a low priority radio command cannot pre-empt either a high priority radio command; Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks); and when the third priority and the fourth priority are equal, complete the third request and the fourth request with round robin scheduling (Col. 6 lines 52-60 If the new radio command is high priority and the queued radio command occupying the specified time slot is also high priority, the radio command scheduler 314 cannot pre-empt the queued radio command in the specified time slot in favor of the new radio command as a high priority radio command cannot pre-empt another high priority radio command. In this instance, the radio command scheduler 314 appends the new radio command to the end of the radio command queue 320).
Claims 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu and Farrell, as applied to claim 1 above, in view of Nikuie et al. (US 20230141986 A1 hereinafter Nikuie).
As per claim 2, Kandhalu and Farrell teach the method of claim 1. Kandhalu teaches further comprising: resending the first request from the first requestor to the queue for the shared resource, wherein the first request fits within the duration of availability (Fig. 7; Col. 7 lines 3-5 The radio command scheduler 314 appends the pre-empted low priority radio command to the end of the radio command queue 320; Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks; Col. 8 lines 3-9 The radio command scheduler 314 causes the radio driver 310 to abort execution of the low priority radio command B1 and places the new radio command A at the head of the radio command queue 320. Because B1 is not time critical, the radio command scheduler 314 reschedules B1 by appending B1 to the radio command queue 320, as shown in the new schedule 702; Col. 7 lines 16-18 FIG. 5 is an example of inserting a radio command in an available time slot in the radio command queue 320).
Kandhalu and Farrell fail to teach after notifying the first requestor of the preemption, resending the first request.
However, Nikuie teaches after notifying the first requestor of the preemption, resending the first request ([0014] In another example, CPU 102 may issue a series of five requests to complete a write transaction of 16 KB to flash target 104, e.g., four write transfer requests followed by a write request. Because write requests are low priority, a read request arriving before all five requests in the write sequence can interrupt may be scheduled by arbiter 110 immediately, thus interrupting the larger write transaction. In some examples, arbiter 110 may mark all five requests as incomplete and return them to the queue. In some examples, arbiter 110 may signal CPU 102 that the write transaction was preempted. CPU 102 may requeue or cancel the preempted write transaction.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu and Farrell with the teachings of Nikuie so low priority requests can be requeued to be continued (see Nikuie [0014] In another example, CPU 102 may issue a series of five requests to complete a write transaction of 16 KB to flash target 104, e.g., four write transfer requests followed by a write request. Because write requests are low priority, a read request arriving before all five requests in the write sequence can interrupt may be scheduled by arbiter 110 immediately, thus interrupting the larger write transaction. In some examples, arbiter 110 may mark all five requests as incomplete and return them to the queue. In some examples, arbiter 110 may signal CPU 102 that the write transaction was preempted. CPU 102 may requeue or cancel the preempted write transaction.).
As per claim 3, Kandhalu, Farrell, and Nikuie teach the method of claim 2. Kandhalu teaches wherein resending the first request includes altering the first request to fit within the duration of availability (Fig. 7; Col. 7 lines 9-14 In each of the above instances in which the radio command scheduler 314 appends a radio command to the radio command queue 320, the radio command scheduler 314 modifies the time parameters of the appended radio command as needed to accommodate the start time and end time deferral.).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu and Farrell, as applied to claim 1 above, in view of Dignum et al. (US 20070113222 A1 hereinafter Dignum).
As per claim 4, Kandhalu and Farrell teach the method of claim 1.
Kandhalu and Farrell fail to teach wherein the shared resource is a cryptographic engine.
However, Dignum teaches wherein the shared resource is a cryptographic engine ([0058] a single parser unit or cryptographic unit is included in an accelerator and may be shared by multiple cores and/or multiple processor threads.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu and Farrell with the teachings of Dignum to provide security (see Dignum [0070] Cryptographic engines 214a-214n may be configured to decrypt an encrypted portion of an XML document, encrypt a portion of an outgoing document, verify or compute a digital signature, and/or perform other security-related functions. For example, a cryptographic unit 214 may facilitate the enforcement of SSL (Secure Sockets Layer) security, web services security, XML security, IPSec or some other security scheme. The cryptographic unit may be configured to apply a cryptographic algorithm such as DES, 3DES, AES, MD5, RC4, SHA or some other algorithm now known or hereafter developed.).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu in view of Bates (US 20090049451 A1).
As per claim 8, Kandhalu teaches a method, comprising: adding, by a resource manager, a first request from a first requestor to a queue for a shared resource, wherein the first request has a first priority (Col. 7 lines 39-40 three low priority radio commands B1, B2, and B3 from protocol stack B 306; Col. 7 lines 35-36 a queued low priority radio command; Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks; Col. 3 lines 54-56 The radio command scheduler 314 manages the radio command queue 320, both adding radio commands to the queue 320); providing, by the resource manager, the first request to the shared resource from the queue; processing, by the resource manager, the first request at the shared resource (Fig. 7; Col. 7 lines 62-64 the low priority non-time critical radio command B1 is currently being executed by the radio driver 310; Col. 7 lines 35-36 a queued low priority radio command; Col. 3 lines 54-57 The radio command scheduler 314 manages the radio command queue 320, both adding radio commands to the queue 320 and dispatching radio commands from the queue 320 to the radio driver 310; Col. 3 lines 26-27 time shared access to the radio for radio commands issued by multiple protocol stacks); adding, by the resource manager, a second request from a second requestor to the queue for the shared resource, wherein the second request has a second priority that is higher than the first priority (Col. 7 lines 22-24 receives a new radio command A4 from protocol stack A 308. The radio command scheduler 314 attempts to add A4 to the radio command queue 320; Col. 7 lines 40-45 At time T2, the radio command scheduler 314 receives a new radio command A4 from the protocol stack A 308 that is high priority as per the scheduling policy for the current states of the protocol stack. The radio command scheduler 314 attempts to add A4 to the radio command queue 320; Col. 6 lines 64-66 If the new radio command is high priority and the queued radio command occupying the specified time slot is low priority; Col. 3 lines 54-56 The radio command scheduler 314 manages the radio command queue 320, both adding radio commands to the queue 320; Col. 3 lines 26-27 time shared access to the radio for radio commands issued by multiple protocol stacks).
Kandhalu fails to teach the second request also includes a hold time; in response to determining, by the resource manager, the shared resource can complete the first request within the hold time, completing the first request and then processing the second request; and in response to determining, by the resource manager, the shared resource cannot complete the first request within the hold time, preempting the first request and then processing the second request.
However, Bates teaches the second request also includes a hold time; in response to determining, by the resource manager, the shared resource can complete the first request within the hold time, completing the first request and then processing the second request; and in response to determining, by the resource manager, the shared resource cannot complete the first request within the hold time, preempting the first request and then processing the second request ([0043] Each wait-time attribute T.sub.W1 . . . T.sub.W2 specifies how long the corresponding thread can wait before pre-empting a lower priority thread; [0026] The operating system may also notify the first thread of a time limit for pre-emption (referred to herein as a pre-emption wait time attribute) associated with the second thread. The application running the first thread may yield the one the processor(s) held by the first thread to the second thread within the time limit without saving a context of the first thread if the first thread can wind up within the time limit; [0011] Co-processors and cache may be shared among different software threads; Fig. 2; Figure 2 shows a step regarding determining if the 1st thread is wound up in time TW. [0032] The flow diagram of FIG. 2 illustrates an example of method 200 multi-threaded operation of a computer system like that shown in FIG. 1; [0026] According to embodiments of the present invention a computer system having one or more processors coupled to a memory may implement multi-threaded processing in a way that significantly reduces the need for context switches or avoids them altogether; [0034] The processor module 101 may manage multi-threaded operation; [0031] The main processor MPE runs an operating system OS; [0032] As indicated at 204 the operating system OS may wait for the first thread to wind up execution. The first thread may wind up execution by completing its execution within the allotted wait time T.sub.W. Alternatively, the first thread may wind up execution by saving data that it needs to save before exiting. In addition, in some situations, the first thread may wind up execution by removing a lock on a mutex 122 so that other threads may access to the mutex 122 after the first thread exits. If the first thread winds up its execution within the allotted wait time T.sub.W, the first thread may yield the processor to the second thread without a context switch as indicated at 206; [0033] If the first thread does not wind up execution within the wait time T.sub.W, the first thread may be preempted as indicated at 208. A context switch from the first thread to the second thread may then be performed, as indicated at 210.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu with the teachings of Bates to increase performance (see Bates [0026] According to embodiments of the present invention a computer system having one or more processors coupled to a memory may implement multi-threaded processing in a way that significantly reduces the need for context switches; [0013] In addition to being detrimental to performance, context switches are often unnecessary.).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu and Bates, as applied to claim 8 above, in view of Dignum.
As per claim 9, Kandhalu and Bates teach the method of claim 8.
Kandhalu and Bates fail to teach wherein the shared resource is a cryptographic engine.
However, Dignum teaches wherein the shared resource is a cryptographic engine ([0058] a single parser unit or cryptographic unit is included in an accelerator and may be shared by multiple cores and/or multiple processor threads.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu and Bates with the teachings of Dignum to provide security (see Dignum [0070] Cryptographic engines 214a-214n may be configured to decrypt an encrypted portion of an XML document, encrypt a portion of an outgoing document, verify or compute a digital signature, and/or perform other security-related functions. For example, a cryptographic unit 214 may facilitate the enforcement of SSL (Secure Sockets Layer) security, web services security, XML security, IPSec or some other security scheme. The cryptographic unit may be configured to apply a cryptographic algorithm such as DES, 3DES, AES, MD5, RC4, SHA or some other algorithm now known or hereafter developed.).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu and Bates, as applied to claim 8 above, in view of Proejts et al. (US 11265052 B1 hereinafter Proejts).
As per claim 10, Kandhalu and Bates teach the method of claim 8.
Kandhalu and Bates fail to teach wherein the shared resource is an antenna.
However, Proejts teaches wherein the shared resource is an antenna (Col. 22 lines 15-16 determine which wireless protocol may take priority on the shared antennas).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu and Bates with the teachings of Proejts to reduce utilized resources (see Proejts Col. 3 lines 45-49 sharing of antenna systems is possible between wireless protocols thus reducing the number of antennas needed to be formed within the C-cover and D-cover of the base chassis or in the display chassis.).
Claims 11 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu, in view of Giusto et al. (US 20140040904 A1 hereinafter Giusto), and further in view of Maheshwari et al. (US 20210224275 A1 hereinafter Maheshwari).
As per claim 11, Kandhalu teaches a method, comprising: adding, by a processor, a plurality of requests from one or more requestors to a queue for a shared resource (Fig. 5; Col. 7 lines 16-21 FIG. 5 is an example of inserting a radio command in an available time slot in the radio command queue 320. The original schedule 500 includes three radio commands A1, A2, and A3 from protocol stack A 308 and three radio commands B1, B2, and B3 from protocol stack B 306; Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks);
receiving, by the processor, a first request from a first requestor (Col. 3 lines 25-26 A dynamic multi-protocol manager (DMM) executing on the main CPU 202; Col. 5 lines 37-39 the DMM 300 receives 400 a new radio command to be scheduled from one of the protocol stacks 306, 308).
Kandhalu fails to teach determining, by the processor, a maximum available transaction length based at least in part on the plurality of requests in the queue; notifying, by the processor, the first requestor that the first request exceeds the maximum available transaction length before processing any portion of the first request by the shared resource.
However, Giusto teaches determining, by the processor, a maximum available transaction length based at least in part on the plurality of requests in the queue ([0041] A non-preemptive duration Bn(i, j) of lower-priority tasks is bounded by using the maximum non-preemptive duration, which is determined as a maximum I(M)CM over all mutexes M that can be held by any task with lower priority than Ti; [0021] For any lock M protecting a mutually exclusive shared resource, the term I(M) is employed to denote the number of tasks that access lock M, and C.sub.M is employed to represent the maximum duration for which M can be held; Equation 4 page 6 above paragraph [0056]
PNG
media_image1.png
426
1023
media_image1.png
Greyscale
; [0056] The first term corresponds to the maximum duration for which the mutex M can be held by any lower-priority task Tl when Ti requests M. The second term represents the maximum duration for which higher-priority tasks Th can hold the mutex M before task Ti can acquire M. Here, W'.sub.l.sup.M is the maximum global-mutex-holding time of task Tl with respect to global mutex M; [0051] Each global mutex maintains a priority queue of tasks waiting to acquire it; claim 1 A method for managing task execution in a multi-core processor).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu with the teachings of Giusto to provide better resource utilization (see Giusto [0039] A priority inversion occurs when a high-priority task waits for a low-priority task to release a resource…Long durations of priority inversion thus lead to significant loss in useful system utilization. Bounding such priority inversion is important to achieve both timing predictability and better utilization.).
Kandhalu and Giusto fail to teach notifying, by the processor, the first requestor that the first request exceeds the maximum available transaction length before processing any portion of the first request by the shared resource.
However, Maheshwari teaches notifying, by the processor, the first requestor that the first request exceeds the maximum available transaction length before processing any portion of the first request by the shared resource ([0051] A trained model may be used to classify and/or predict one or more performance metrics associated with executing a new query based on learned query patterns even though the new query has not previously been seen or executed within an environment; [0054] notification to alert an administrator if a new query is classified as non-performant or if the predicted performance otherwise does not satisfy one or more thresholds; [0129] an alert should be trigger for a new query if and only if the predicted execution time is greater than a threshold; [0147] the database may be shared by multiple tenants; [0162] According to some embodiments, the techniques described herein are implemented by one or more special-purpose computing devices. The special-purpose computing devices may be hard-wired to perform the techniques, or may include…one or more general purpose hardware processors; [0040] In some embodiments, clients 102a and 102b are applications or application components that submit requests to store and fetch data to/from database 112. The requests may include or be used to construct a database query).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu and Giusto with the teachings of Maheshwari to optimize performance (see Maheshwari [0001] The present disclosure relates to machine learning and query processing systems. In particular, the present disclosure relates to training, tuning, and leveraging neural networks for optimizing query performance.).
As per claim 14, Kandhalu, Giusto, and Maheshwari teach the method of claim 13. Kandhalu teaches wherein the revised request is scheduled to execute when its transaction length fits within an estimated duration of availability window (Fig. 7; Col. 7 lines 9-14 In each of the above instances in which the radio command scheduler 314 appends a radio command to the radio command queue 320, the radio command scheduler 314 modifies the time parameters of the appended radio command as needed to accommodate the start time and end time deferral; Col. 7 lines 16-18 FIG. 5 is an example of inserting a radio command in an available time slot in the radio command queue 320).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu, Giusto, and Maheshwari, as applied to claim 11 above, in view of Landais et al. (US 20180368202 A1 hereinafter Landais).
As per claim 12, Kandhalu, Giusto, and Maheshwari teach the method of claim 11.
Kandhalu, Giusto, and Maheshwari fail to teach further comprising: notifying the first requestor of the maximum available transaction length.
However, Landais teaches further comprising: notifying the first requestor of the maximum available transaction length (claim 40 after having rejected a MT NIDD Request from the SCEF, send to the SCEF, in a notification indicating that the UE is reachable again, information indicating a maximum UE availability time).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu, Giusto, and Maheshwari with the teachings of Landais to improve performance (see Landais [0008] There is also a need to improve the support of Mobile-Terminated Short Message Service (MT-SMS) towards a User Equipment UE using extended idle mode DRX. [0009] Embodiments of the present invention in particular address such needs.).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu, Giusto, and Maheshwari, as applied to claim 11 above, in view of Saeki (US 20100064151 A1).
As per claim 13, Kandhalu, Giusto, and Maheshwari teach the method of claim 11. Kandhalu teaches further comprising: adding a revised request from the first requestor to the queue for the shared resource, (Fig. 7; Col. 7 lines 9-14 In each of the above instances in which the radio command scheduler 314 appends a radio command to the radio command queue 320, the radio command scheduler 314 modifies the time parameters of the appended radio command as needed to accommodate the start time and end time deferral; Col. 7 lines 39-40 three low priority radio commands B1, B2, and B3 from protocol stack B 306; Col. 7 lines 16-18 FIG. 5 is an example of inserting a radio command in an available time slot in the radio command queue 320;).
Kandhalu, Giusto, and Maheshwari fail to teach wherein the revised request fits within the maximum available transaction length.
However, Saeki teaches wherein the revised request fits within the maximum available transaction length ([0122] Equation (5) is to allow a judgment on whether or not the request UPS duration time UT.sub.req desired for responding to the change request from the client unit Ci falls within a range of the maximum UPS duration time UT.sub.max. Here, the determination unit 814 determines that the change in the power supply-distribution capacity is allowable if the request UPS duration time UT.sub.req is equal to or shorter than the maximum UPS duration time UT.sub.max.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu, Giusto, and Maheshwari with the teachings of Saeki to prevent overutilization of resources (see Saeki [0221] This embodiment may achieve advantageous effects of effectively suppressing the supply of electric power that exceeds the power supply-distribution capacity of the facility).
Claims 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu, Giusto, and Maheshwari, as applied to claim 11 above, in view of Bates.
As per claim 15, Kandhalu, Giusto, and Maheshwari teach the method of claim 11. Kandhalu teaches further comprising: adding a second request from a second requestor to the queue for the shared resource (Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks; Col. 7 lines 37-40 The original schedule 600 includes three high priority radio commands A1, A2, and A3 from protocol stack A 308 and three low priority radio commands B1, B2, and B3 from protocol stack B 306.).
Kandhalu, Giusto, and Maheshwari fail to teach wherein the second request includes a hold time; when the shared resource can complete a currently executing request within the hold time, completing the currently executing request and then processing the second request; and when the shared resource cannot complete the currently executing request within the hold time, preempting the currently executing request and then processing the second request.
However, Bates teaches wherein the second request includes a hold time; when the shared resource can complete a currently executing request within the hold time, completing the currently executing request and then processing the second request; and when the shared resource cannot complete the currently executing request within the hold time, preempting the currently executing request and then processing the second request ([0043] Each wait-time attribute T.sub.W1 . . . T.sub.W2 specifies how long the corresponding thread can wait before pre-empting a lower priority thread; [0032] As indicated at 204 the operating system OS may wait for the first thread to wind up execution. The first thread may wind up execution by completing its execution within the allotted wait time T.sub.W; [0026] The operating system may also notify the first thread of a time limit for pre-emption (referred to herein as a pre-emption wait time attribute) associated with the second thread. The application running the first thread may yield the one the processor(s) held by the first thread to the second thread within the time limit without saving a context of the first thread if the first thread can wind up within the time limit; [0011] Co-processors and cache may be shared among different software threads; [0033] If the first thread does not wind up execution within the wait time T.sub.W, the first thread may be preempted as indicated at 208. A context switch from the first thread to the second thread may then be performed).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu, Giusto, and Maheshwari with the teachings of Bates to increase performance (see Bates [0026] According to embodiments of the present invention a computer system having one or more processors coupled to a memory may implement multi-threaded processing in a way that significantly reduces the need for context switches or avoids them altogether; [0013] In addition to being detrimental to performance, context switches are often unnecessary.).
As per claim 16, Kandhalu, Giusto, Maheshwari, and Bates teach the method of claim 15. Kandhalu teaches further comprising: responsive to preempting the currently executing request, notifying a requestor of the currently executing request that the currently executing request was preempted (Col. 6 line 64-Col. 7 line 9 If the new radio command is high priority and the queued radio command occupying the specified time slot is low priority, the radio command scheduler 314 pre-empts the queued low priority radio command to free up the specified time slot for the new radio command in the radio command queue 320 and inserts the new radio command in the radio command queue 314…the radio command scheduler 314 aborts the pre-empted radio command and notifies the protocol stack that issued the low priority radio command that the radio command has been pre-empted.).
As per claim 17, Kandhalu, Giusto, Maheshwari, and Bates teach the method of claim 15. Kandhalu teaches further comprising: after processing the second request, resuming processing of the currently executing request (Col. 5 line 66-Col. 6 line 7 The scheduler 314 appends the aborted low priority radio command to the radio command queue 320 if the low priority command is not time critical; otherwise, the radio command scheduler 314 notifies the protocol stack that issued the low priority radio command that the radio command was aborted. If the low priority radio command is pre-empted and appended to the radio command queue 320, the low priority radio command will be executed from the beginning).
Claims 18 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu in view of Mase (US 20120246304 A1).
As per claim 18, Kandhalu teaches a system, comprising: a processor configured to: add a first request from a first requestor to a queue for a shared resource, wherein the first request has a first priority (Col. 1 lines 59-61 a processor coupled to the memory to execute the software instructions; Col. 7 lines 39-40 three low priority radio commands B1, B2, and B3 from protocol stack B 306; Col. 7 lines 35-36 a queued low priority radio command; Col. 6 lines 10-12 the new radio command is low priority, the radio command scheduler 314 attempts to add the new radio command to the radio command queue; Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks);
add a second request from a second requestor to the queue for the shared resource, wherein the second request has a second priority that is higher than the first priority (Col. 7 lines 22-24 receives a new radio command A4 from protocol stack A 308. The radio command scheduler 314 attempts to add A4 to the radio command queue 320; Col. 7 lines 40-45 At time T2, the radio command scheduler 314 receives a new radio command A4 from the protocol stack A 308 that is high priority as per the scheduling policy for the current states of the protocol stack. The radio command scheduler 314 attempts to add A4 to the radio command queue 320; Col. 6 lines 64-66 If the new radio command is high priority and the queued radio command occupying the specified time slot is low priority);
preempt the processing of the first request and notify the first requestor; send, after the first request is preempted, a notification that the first request was preempted (Col. 6 line 64-Col. 7 line 9 If the new radio command is high priority and the queued radio command occupying the specified time slot is low priority, the radio command scheduler 314 pre-empts the queued low priority radio command to free up the specified time slot for the new radio command in the radio command queue 320 and inserts the new radio command in the radio command queue 314…the radio command scheduler 314 aborts the pre-empted radio command and notifies the protocol stack that issued the low priority radio command that the radio command has been pre-empted; Col. 7 lines 49-55 The radio command scheduler 314 pre-empts B2 in favor of A4, removes B2 from the queue 320…The radio command scheduler 314 also determines that B2 cannot be rescheduled because B2 is time critical and notifies the protocol stack B 306 that the radio command B2 has been pre-empted);
a third request, the third request being the same as the first request; add the third request to the queue again for the shared resource (Col. 7 lines 3-5 The radio command scheduler 314 appends the pre-empted low priority radio command to the end of the radio command queue 320; Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks; Col. 6 line 64-Col. 7 line 9 If the new radio command is high priority and the queued radio command occupying the specified time slot is low priority, the radio command scheduler 314 pre-empts the queued low priority radio command to free up the specified time slot for the new radio command in the radio command queue 320 and inserts the new radio command in the radio command queue 314…the radio command scheduler 314 aborts the pre-empted radio command and notifies the protocol stack that issued the low priority radio command that the radio command has been pre-empted;).
Kandhalu fails to teach receiving a third request from the first requester, the third request being the same as the first request.
However, Mase teaches receiving a third request from the first requester, the third request being the same as the first request (Fig. 23; Abstract when the communication controller receives the request from the upper-level apparatus, a processing content of the request is the same as a processing content of a previously received request; [0173] each time the request 10590 is transmitted, the supervisor terminal 4a according to the present embodiment adds 1 each to the value of the sequence ID 10590d).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu with the teachings of Mase to increase processing speed (see Mase [0204] In view of the above, according to the present embodiment, by transmitting the response 10591 to the retransmitted request 10590 on the basis of the previous request 10590, a response speed to the apparently retransmitted request 10590 is increased).
As per claim 24, Kandhalu and Mase teach the system of claim 18. Kandhalu teaches wherein the processor and the shared resource are integrated in a same integrated circuit (Fig. 2; Col. 3 lines 5-14 The RF core 204 includes a processor implemented as an ARM® Cortex®-M0 processor for executing software that, e.g., interfaces the analog RF and base-band circuitry, handles data transmission to and from the main CPU 202, and assembles packets for transmission based on the particular protocol corresponding to the packets. The software includes a command-based application program interface (API) used by applications executing on the main CPU 202 to communicate with the RF core 204.).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu and Mase, as applied to claim 18 above, in view of Giusto.
As per claim 19, Kandhalu and Mase teach the system of claim 18. Kandhalu teaches wherein the processor is further configured to: add a plurality of requests from one or more requestors to the queue for the shared resource (Col. 7 lines 16-21 FIG. 5 is an example of inserting a radio command in an available time slot in the radio command queue 320. The original schedule 500 includes three radio commands A1, A2, and A3 from protocol stack A 308 and three radio commands B1, B2, and B3 from protocol stack B 306; Col. 3 lines 25-27 A dynamic multi-protocol manager (DMM) executing on the main CPU 202 provides time shared access to the radio for radio commands issued by multiple protocol stacks).
Kandhalu and Mase fail to teach determine a maximum available transaction length based at least in part on the plurality of requests in the queue for the shared resource.
However, Giusto teaches determine a maximum available transaction length based at least in part on the plurality of requests in the queue for the shared resource ([0041] A non-preemptive duration Bn(i, j) of lower-priority tasks is bounded by using the maximum non-preemptive duration, which is determined as a maximum I(M)CM over all mutexes M that can be held by any task with lower priority than Ti; [0021] For any lock M protecting a mutually exclusive shared resource, the term I(M) is employed to denote the number of tasks that access lock M, and C.sub.M is employed to represent the maximum duration for which M can be held; Equation 4 page 6 above paragraph [0056]
PNG
media_image1.png
426
1023
media_image1.png
Greyscale
; [0056] The first term corresponds to the maximum duration for which the mutex M can be held by any lower-priority task Tl when Ti requests M. The second term represents the maximum duration for which higher-priority tasks Th can hold the mutex M before task Ti can acquire M. Here, W'.sub.l.sup.M is the maximum global-mutex-holding time of task Tl with respect to global mutex M; [0053] A benefit of using the multi-processor priority ceiling protocol includes permitting priority-driven access to shared resources, wherein each global mutex has a priority queue of tasks suspended on it.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu and Mase with the teachings of Giusto to provide better resource utilization (see Giusto [0039] A priority inversion occurs when a high-priority task waits for a low-priority task to release a resource…Long durations of priority inversion thus lead to significant loss in useful system utilization. Bounding such priority inversion is important to achieve both timing predictability and better utilization.).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu and Mase, as applied to claim 18 above, in view of Dignum.
As per claim 20, Kandhalu and Mase teach the system of claim 18.
Kandhalu and Mase fail to teach wherein the shared resource is a cryptographic engine.
However, Dignum teaches wherein the shared resource is a cryptographic engine ([0058] a single parser unit or cryptographic unit is included in an accelerator and may be shared by multiple cores and/or multiple processor threads.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu and Mase with the teachings of Dignum to provide security (see Dignum [0070] Cryptographic engines 214a-214n may be configured to decrypt an encrypted portion of an XML document, encrypt a portion of an outgoing document, verify or compute a digital signature, and/or perform other security-related functions. For example, a cryptographic unit 214 may facilitate the enforcement of SSL (Secure Sockets Layer) security, web services security, XML security, IPSec or some other security scheme. The cryptographic unit may be configured to apply a cryptographic algorithm such as DES, 3DES, AES, MD5, RC4, SHA or some other algorithm now known or hereafter developed.).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu and Mase, as applied to claim 18 above, in view of Averbuch et al. (US 20020186678 A1 hereinafter Averbuch).
As per claim 21, Kandhalu and Mase teach the system of claim 18.
Kandhalu and Mase fail to teach wherein adding the first request again includes adding a revised first request with a shorter length.
However, Averbuch teaches wherein adding the first request again includes adding a revised first request with a shorter length ([0017] the slots for the subscriber sent as the shorter first message are not discarded but are resent at a later time.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu and Mase with the teachings of Averbuch to efficiently use resources (see Averbuch [0002] provide an efficient use of air resources.).
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu and Mase, as applied to claim 18 above, in view of Farrell.
As per claim 22, Kandhalu and Mase teach the system of claim 18.
Kandhalu and Mase fail to teach wherein the notification includes a maximum available transaction length for the shared resource.
However, Farrell teaches wherein the notification includes a maximum available transaction length for the shared resource ([0033] In one particular embodiment, a capability is provided in which a guest program executing on a guest CPU provisioned by a host CPU is provided a warning of expiration of a timeslice given to the guest CPU from the host CPU or of pre-emption by the host of the guest's timeslice. The warning provides a grace period that the guest CPU can use to perform a particular function, such as complete execution of a dispatchable unit; [0050] the grace period is provided in response to expiration of the timeslice, or in response to the host pre-empting the guest; [0035] Each processor (and/or a program, such as an operating system, executing on the processor) is given a certain amount of time, referred to as a timeslice, to share the resources; claim 8 the grace period provides a period in addition to the timeslice; [0110] In one embodiment, a logical (guest) processor running in a timeslice on a physical processor receives a warning signal indicating a grace period, e.g., an amount of time before the logical processor will be interrupted (deallocated from the physical processor that may be shared) enabling the work being done by the logical processor to be either completed; [0051] the grace period limits the remaining time (or other period) given to the guest CPU and is not itself extendable.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu and Mase with the teachings of Farrell to improve execution duration of time sensitive work (see Farrell [0145] In a further embodiment, one or more aspects of the invention can be used with requests from an operating system to let an individual execution thread continue to improve elapsed time of time sensitive work. That is, a thread may request or be provided additional time to perform a function.).
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over Kandhalu and Mase, as applied to claim 18 above, in view of Bates.
As per claim 23, Kandhalu and Mase teach the system of claim 18.
Kandhalu and Mase fail to teach wherein the second request includes a hold time.
However, Bates teaches wherein the second request includes a hold time ([0043] Each wait-time attribute T.sub.W1 . . . T.sub.W2 specifies how long the corresponding thread can wait before pre-empting a lower priority thread; [0026] In particular an operating system may notify a first thread running on one or more of the processors of a pre-emption by a second thread having a higher priority than the first thread.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Kandhalu and Mase with the teachings of Bates to increase performance (see Bates [0026] According to embodiments of the present invention a computer system having one or more processors coupled to a memory may implement multi-threaded processing in a way that significantly reduces the need for context switches or avoids them altogether; [0013] In addition to being detrimental to performance, context switches are often unnecessary.).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HSING CHUN LIN whose telephone number is (571)272-8522. The examiner can normally be reached Mon - Fri 9AM-5PM.
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, Aimee Li can be reached at (571) 272-4169. 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.
/H.L./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights