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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over Knight et al. (US Pub. No. 20040030816), hereinafter referred to as Knight in view of Schmidt (US Pat. No. 6782465).
As to claim 1, Knight discloses a method for managing transfer groups, comprising:
transfer via a transfer channel (DMA data paths between I/O devices 130, 134 and DMA controllers 136, 138, wherein selected ports/devices are serviced via corresponding DMA interfaces that route data to and from buffer memory and FIFOs, Fig. 1).
performing a querying step (NextPort logic 120 polls I/O devices 130, 134 and their DMA controllers 136, 138 for status, Fig. 1; device class register 122 and port number register 124 identify the selected device/port, para. [0037]–[0039]) that includes sequentially querying and updating the transfer status of each transfer group in the transfer group queue (polling of I/O devices via NextPort logic 120 to receive status inputs, Fig. 1; device class register 122 and port number register 124 store identifiers, para. [0037]-[0041]) according to the priorities of the transfer groups (NextPort logic 120 polls devices 130, 134 and their DMA controllers 136, 138, and applies priority inputs when selecting ports to be serviced, Fig. 1, para. [0037]–[0039]);
performing a configuring step (processor 112 uses NextPort logic 120 outputs and dispatch software to select appropriate handler routines and context pointers, Fig. 2; para. [0040]–[0044]) that includes configuring the transfer group queue based on the results of the query and the priorities of the transfer groups (dispatch software re-writes table entries dynamically with handler routine address and context pointer to reflect updated status and priorities, Fig. 2; para. [0043]–[0044]); and
performing a triggering step (processor 112 and DMA controllers 136, 138 initiate DMA transfers after the NextPort-selected handler routine executes, Fig. 1; para. [0044]–[0045]) that includes triggering the DMA to transfer the transfer group queue (DMA controllers 136, 138 execute transfers to and from buffer memory and FIFOs, Fig. 8–9; para. [0074]–[0075]).
Schmidt discloses, what Knight lacks, a hardware-linked list (linked list of DMA descriptors with next-descriptor pointer and variable number of data pointers, Fig. 1–2) at a DMA PMM (DMA controller architecture including counter 52 and next descriptor address register 54 that manage descriptor processing, Fig. 3) of a Direct Memory Access (DMA) (linked list of DMA descriptors including next descriptor pointer fields forming a chained structure, Fig. 1–2; Col. 2, lines 12–34; Col. 2, line 35 – Col. 3, line 41), the hardware-linked list implementing a transfer group queue (plurality of DMA descriptors stored in memory and linked via subsequent address fields, each descriptor representing a set of data pointers to be transferred, thereby forming a queued sequence of transfer operations, Fig. 2; Col. 2, line 35 – Col. 3, line 41), the transfer group queue defining an order with which the transfer groups are to be transferred (sequential processing of descriptors by the DMA controller following the next descriptor pointer chain, wherein each descriptor points to the next descriptor to be processed, establishing an ordered sequence of transfers, Fig. 2; Fig. 3; Col. 3, line 42 – Col. 4, line 7).
Knight and Schmidt are analogous art because they are from the same field of endeavor, namely DMA controller scheduling and data transfer management.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Knight and Schmidt before him or her, to modify the DMA scheduling system of Knight to include the hardware-linked list of Schmidt.
The suggestion/motivation for doing so would have been to improve transfer efficiency, reduce processor scheduling overhead, and allow dynamic priority-based updates with less latency.
Therefore, it would have been obvious to combine Schmidt with Knight to obtain the invention as specified in the instant claim.
As to claim 2, Schmidt discloses the method according to claim 1, wherein the transfer status comprises: completed transfer, in-progress transfer, and not yet transferred (each descriptor includes a pointer to the next descriptor along with an indication of the number of data pointers it contains; this count is stored in the DMA controller and used to determine pending transfers until all pointers are processed, thereby indicating in-progress versus completed status, col. 1, lines 37–40).
As to claim 3, Knight discloses the method according to claim 1, wherein, when the DMA is idle (e.g. DMA engine has no active transfer, para. 0044), the triggering further comprises: triggering the DMA to directly transfer a new transfer group (DMA controllers 136, 138 executing DMA when selected, and if idle, no active transfer, immediately transferring the buffer data, Fig. 1, Fig. 8; para. [0044]–[0045], para. [0078]).
As to claim 4, Schmidt discloses the method according to claim 1, wherein, when the DMA is not idle (e.g. controller is active, Fig. 2), the configuring further comprises: configuring the new transfer group into the transfer group queue to wait for transfer (linked list of descriptors being appended to the list while DMA controller is active, Fig. 2–3; col. 3, lines 20–45).
As to claim 5, Schmidt discloses the method according to claim 4, wherein the configuring further comprises: when the transfer group queue is empty, directly configuring the new transfer group into the transfer group queue to wait for transfer (updating the “next descriptor pointer” when the list is empty (null pointer condition), Fig. 2; col. 2, lines 30–40).
As to claim 6, Knight discloses the method according to claim 4, wherein the configuring further comprises: when the transfer group queue is not empty (table, Fig. 2; para. [0040]–[0044]) and flow structures, Fig. 5; para. [0073]–[0074]), which together represent pending DMA tasks. When these structures already contain entries, new transfer requests are configured into them, the functional equivalent of a non-empty queue), configuring the order of the new transfer group in the transfer group queue by comparing the priority of the new transfer group with the priorities of the transfer groups in the transfer group queue (NextPort logic 120 applies priority inputs to select which port/device is serviced first, Fig. 1; para. [0037]–[0039]).
As to claim 7, Knight discloses the method according to claim 6, wherein the configuring further comprises: in the transfer group queue (table, Fig. 2; para. [0040]–[0044] stores handler routines and context pointers for multiple flows/devices, each representing a pending DMA task), configuring the transfer group with high priority that has not yet been transferred before the transfer group with low priority that has not yet been transferred (applies priority-based selection among pending ports, Fig. 1; para. [0037]–[0039]; The claim phrase “that has not yet been transferred” aligns with Knight’s pending ports, because a port identified by NextPort but not yet serviced is by definition pending. Thus, when NextPort applies priority to pending ports, it is effectively placing the higher-priority pending task ahead of the lower-priority pending task).
As to claim 8, Knight discloses the method according to claim 6, wherein the configuring further comprises: in the transfer group queue (table, Fig. 2; para. [0040]–[0044]) stores handler routines and context pointers for multiple flows/devices, each representing a pending DMA task), configuring the transfer group with high priority that has not yet been transferred after the transfer group with low priority that is in-progress (ongoing DMA transfers continue while NextPort dispatch configures upcoming handler routines, Fig. 2; para. [0043]–[0044]; The NextPort logic determines which port or device should be serviced next while other transfers are already executing. In this way, pending handler routines are effectively treated as higher priority candidates for upcoming service, while transfers that are already executing function as lower priority relative to new scheduling decisions. This operational distinction in Knight most closely corresponds to the claimed concept of high-priority pending tasks versus low-priority in-progress tasks).
As to claim 9, Knight discloses the method according to claim 1, wherein the triggering further comprises: completing the transfer of one transfer group in the transfer group queue will trigger a start of a transfer of a next transfer group (processor reads NextPort registers again after DMA completes to trigger next handler routine, Fig. 2; para. [0044]–[0045]).
Claims 10 - 18 recite the corresponding limitation of claims 1 - 9. Therefore, they are rejected accordingly.
Claims 19 - 20 recite the corresponding limitation of claim 1. Therefore, they are rejected accordingly.
Response to Arguments
Applicant contends that, in view of the recent amendment, the combination of Knight and Schmidt fails to teach (i) “sequentially querying and updating a transfer status of each transfer group in the transfer group queue according to priorities of the transfer groups,” and (ii) “configuring the order of the transfer group queue.” Applicant further relies on the amended limitations reciting “of a Direct Memory Access (DMA),” “the hardware-linked list implementing a transfer group queue,” “the transfer group queue defining an order with which the transfer groups are to be transferred,” and “transfer via a transfer channel,” to distinguish over the applied references.
These arguments are not persuasive.
(1) Amended limitation: DMA hardware-linked list implementing a transfer group queue — Schmidt
The amendment recites a “hardware-linked list of a Direct Memory Access (DMA), the hardware-linked list implementing a transfer group queue.”
Schmidt discloses this limitation. Specifically, Schmidt discloses a DMA controller utilizing a linked list of DMA descriptors, wherein each descriptor includes a next descriptor pointer forming a chained structure (Fig. 1–2; Col. 2, lines 12–34; Col. 2, line 35 – Col. 3, line 41). The descriptors are stored in memory and linked via subsequent address fields, with each descriptor representing a set of data pointers to be transferred.
Thus, the linked descriptors form a queued sequence of transfer operations, i.e., a transfer group queue implemented via a hardware-linked list of a DMA, as now claimed.
(2) Amended limitation: transfer group queue defining an order — Schmidt
The amendment further recites that “the transfer group queue defin[es] an order with which the transfer groups are to be transferred.”
Schmidt discloses this limitation. The DMA controller processes descriptors sequentially by following the next descriptor pointer chain, wherein each descriptor points to the next descriptor to be processed (Fig. 2; Fig. 3; Col. 3, line 42 – Col. 4, line 7). This establishes an ordered sequence of transfers.
Accordingly, Schmidt explicitly teaches that the transfer group queue defines the order in which transfer groups are transferred.
(3) Amended limitation: transfer via a transfer channel — Knight
The amendment further recites transfer “via a transfer channel.”
Knight discloses this limitation. Knight discloses DMA data paths between I/O devices 130, 134 and DMA controllers 136, 138, wherein selected ports/devices are serviced via corresponding DMA interfaces that route data to and from buffer memory and FIFOs (Fig. 1; Fig. 8–9; para. [0074]–[0075]). These DMA data paths correspond to the claimed transfer channel.
(4) Querying and updating transfer status — Knight
Knight discloses the claimed querying step. Specifically, NextPort logic 120 polls I/O devices 130, 134 and their DMA controllers 136, 138 to obtain status inputs, including whether a device requires servicing, buffer conditions, and completion indicators (Fig. 1; para. [0037]–[0039]). The device class register 122 and port number register 124 identify the selected device/port (para. [0037]–[0041]).
Under the broadest reasonable interpretation, each such device/port corresponds to a transfer group, as it represents a discrete unit of DMA transfer work. Thus, Knight discloses querying transfer status of transfer groups.
Moreover, because Knight continuously polls and evaluates these status inputs and updates scheduling decisions accordingly, Knight inherently discloses updating transfer status over time. Knight further applies priority inputs when selecting which transfer is to be serviced (para. [0037]–[0039]), thereby satisfying the limitation that querying and updating are performed according to priorities of the transfer groups.
(5) Configuring the order — Knight in view of Schmidt
Applicant argues that Knight does not configure the order of the transfer group queue. This argument is not persuasive.
Knight discloses that processor 112 uses outputs from NextPort logic 120 and dispatch software to select handler routines and context pointers (Fig. 2; para. [0040]–[0044]). The dispatch software dynamically updates table entries based on current status and priority (para. [0043]–[0044]).
Under the broadest reasonable interpretation, configuring the order of a queue includes determining which transfer is executed next based on priority. Knight’s priority-based scheduling therefore constitutes configuring the execution order.
When combined with Schmidt’s explicit ordered linked-list structure, Knight teaches configuring the order of the transfer group queue based on query results and priorities, as claimed.
(6) Proper combination
Applicant’s arguments improperly analyze Knight and Schmidt individually. The rejection is based on a proper combination in which:
Schmidt provides the hardware-linked list DMA structure implementing a transfer group queue and defining an ordered sequence of transfers, and
Knight provides querying, prioritization, configuration, triggering, and transfer via DMA channels.
It would have been obvious to apply Knight’s priority-based scheduling to Schmidt’s hardware-linked list DMA structure to improve transfer efficiency and reduce processing overhead.
(7) Claim 10 and dependent claims
Applicant presents substantially the same arguments for independent claim 10, which recites modules corresponding to the steps of claim 1.
Knight discloses corresponding structures, including:
NextPort logic 120 (query module),
processor 112 and dispatch logic (configuring module), and DMA controllers 136, 138 (triggering module), which collectively perform the recited functions. Therefore, for the same reasons discussed above, the arguments regarding claim 10 are not persuasive.
Claims 2 – 9 and 11 - 20 depend from and incorporate the limitations of claims 1 and 10, respectively, and fall therewith.
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUANITO C BORROMEO whose telephone number is (571)270-1720. The examiner can normally be reached on Monday - Friday 9 - 5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Henry Tsai can be reached on 5712724176. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.C.B/ Assistant Examiner, Art Unit 2184
/HENRY TSAI/ Supervisory Patent Examiner, Art Unit 2184
Prosecution Insights