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 .
Obvious-type Double Patenting (ODP) Rejections
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1-2, 4-6, 8 and 14 are rejected under the judicially created doctrine of obviousness-type double patenting as being unpatentable over claims 1-20 of U.S. Patent 12/066,955 hereinafter ‘955. Although the conflicting claims are not identical, they are not patentably distinct from each other.
Claims 1-2 and 4-6 of instant Application, respectively contain elements of claim 16 of the ‘955 as follows:
Claims
Instant
Claims
‘955
1
data
a source memory
a read command
store the read command
in 1st frame(s)
a burst buffer
a first beat
discard unwanted byte(s)
from the 1st beat
of the source memory
realign remaining byte(s)
in next available frames
of the burst buffer
14
16
*18
transferring data
a 1st memory
a read command
store the read command
in 1st frames
a burst buffer
read a plurality of bytes
discard 1st bytes
of the plurality of bytes
(from the 1st memory)
realign the … bytes
in second frames
of the burst buffer
2
a source offset
determine a number of bytes
15
a source offset
reading the plurality of bytes
4
a destination memory
a different byte size archt.
10
a 2nd memory
different architectures
5
a 2nd beat
of the source memory
after realigning
the remaining…
realign bytes
from 2nd beats
16
realigned … bytes
of the 1st memory
after realigning
second bytes
realign bytes
(implied)
6
a 2nd beat
discarding unwanted bytes
realigning
next available frames
16
*18
a 2nd bytes
discarding 1st bytes
realigning
2nd frames
Claim 16 of ‘955 does not expressly disclose frames. Claim 18 of ‘955 does disclose frame, i.e. a frame of memory being a block of memory. At the time of the invention it would have been obvious to a person of ordinary skill in the art to incorporate frame when describing a memory group. The suggestion/motivation for doing so would have been to group data to better organize.
Claims 8-9 and 14 of instant Application, respectively contain elements of claim 20 of the ‘955 as follows:
Claims
Instant
Claims
‘955
8
data
a source memory
a 1st beat
discard … unwanted bytes
realign … 1st remaining bytes
in next available frames
a burst buffer
a 2nd beat
discard 2nd unwanted byte(s)
from the 1st beat
realign 2nd remaining byte(s)
in next available frames
1
*8
1
20
*8
transferring data
a 1st memory
a plurality of bytes
discard … first bytes
realign 2nd bytes
2nd frames
a burst buffer
2nd bytes
discard 1st bytes (again)
1st plurality of bytes
realign the 2nd … bytes
2nd frames
9, 14
a source offset
determine a number of bytes
*8
a source offset
reading the plurality of bytes
Regarding Instant Application claim 8, Claim 20 of ‘955 does not expressly disclose frames. Claim 8 of ‘955 does disclose frame, i.e. a frame of memory being a block of memory. At the time of the invention it would have been obvious to a person of ordinary skill in the art to incorporate frame when describing a memory group. The suggestion/motivation for doing so would have been to group data to better organize.
Regarding Instant Application claims 9 and 14, Claim 20 of ‘955 does not expressly disclose a source offset and determining a number of bytes. Claim 8 of ‘955 does disclose a source offset and reading/determining a number of bytes. At the time of the invention it would have been obvious to a person of ordinary skill in the art to incorporate offset and counting bytes from the offset. The suggestion/motivation for doing so would have been to keep account of data.
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 of this title, 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 D’Luna et al. (U.S. Publication 2002/0106018), hereinafter D’Luna in view of
Non-Patent Literature/Publication, “AMBA AXI and ACE Protocol Specification”, hereinafter AMBA.
Referring to claim 1, D’Luna teaches, as claimed, a method of transferring data from a source memory (data from internal memory, see Paragraph 86), the method comprising:
generating a read command (reads via DMA, see Paragraph 89);
storing a command (header with HEC, see Paragraph 89; Note, header in a packet stores command or instruction, see also Paragraph 41) in first one or more frames (packet or frames, see Paragraphs 94 and 111; Note, a frame is like a page or packet of data whether they are audio, video, or any particular data) of a burst buffer (burst FIFO, see Paragraph 80);
reading a first beat (word aligned to 32-bit boundaries, see Paragraph 99; Note, 32 bits are 4 bytes, so the aligned word size is 4 bytes) of the source memory;
discarding one or more unwanted bytes (Padding streams are preferably removed by default, see Paragraph 99) from the first beat of the source memory; and
realigning (align to, see Paragraph 99; Note, purpose of padding data is to align, so when padding are removed, aligning is equivalent to realigning) one or more remaining bytes (Note, retained data that are not padded are remaining bytes) from the first beat of the source memory in next available (prior to end of current, see Paragraph 100; Note, current packet is the next available to the prior transport) frames of the burst buffer.
D’Luna does not disclose expressly storing a read command (i.e. in a header).
AMBA does disclose a read (AXI read, see Page 52) command (header fields, see Page 54).
At the time of the invention it would have been obvious to a person of ordinary skill in the art to incorporate AMBA Protocol on D’Luna’s processor to peripheral connection.
The suggestion/motivation for doing so would have been to take advantage of freely available, well tested protocol.
As to claim 2, the modification teaches the method of claim 1, comprising determining a source offset (see AMBA Page 54, Unaligned transfers) for the first memory, and determining a number of bytes (see AMBA Page 54, wider than one byte) in the first beat based on the source offset (see AMBA Page 54, starts at a byte address of 0x1002).
As to claim 3, the modification teaches the method of claim 1, wherein the one or more unwanted bytes include a lower (see AMBA Page 54, lower-order address) one or more bytes from the first beat.
As to claim 4, the modification teaches the method of claim 1, comprising transferring the realigned one or more remaining bytes from the burst buffer to a destination memory (see AMBA Page 54, a single memory; and Fig. 16, TX FIFO) having a different byte size (see AMBA Fig. A3-12, big-endian) architecture than the source memory (see AMBA Fig. A3-12, Source, little-endian).
As to claim 5, the modification teaches the method of claim 1, comprising reading a second beat of the source memory after realigning (see AMBA Page 54, provide an aligned address) the one or more remaining bytes from the first beat of the source memory in the next available frames (see AMBA Page 55, Burst Type transfer) of the burst buffer, and realigning one or more bytes (see AMBA Page 55, shaded cells indicate bytes that are not transferred) from the second beat of the source memory in the next available frames of the burst buffer (see AMBA Page 55, Figure A3-13); Note, 1st transfer can be unaligned but protocol requires every other transfer after that is aligned).
As to claim 6, the modification teaches the method of claim 1, comprising reading a second beat of the source memory after realigning (see AMBA Page 54, provide an aligned address) the one or more remaining bytes from the first beat of the source memory in the next available frames of the burst buffer, discarding (see AMBA Page 46, the master can discard read data) one or more unwanted bytes from the second beat of the source memory, and realigning one or more remaining bytes from the second beat of the source memory in the next available frames of the burst buffer (see AMBA Page 55, Figure A3-13; Note, 1st transfer can be unaligned but protocol requires every other transfer after that is aligned).
As to claim 7, the modification teaches an application-specific integrated circuit (ASIC, see D’Luna Paragraph 45) or a field-programmable gate array system including a direct memory access controller (DMA, see D’Luna Paragraph 86) programmed to perform the method of claim 1.
Referring to claim 8, D’Luna teaches, as claimed, a method of transferring data from a source memory (data from internal memory, see Paragraph 86), the method comprising:
reading a first beat (32-bit boundaries, see Paragraph 99) of the source memory;
discarding one or more first unwanted bytes (preferably removed by default, see Paragraph 99) from the first beat of the source memory;
realigning (align to, see Paragraph 99) one or more first remaining bytes from the first beat of the source memory in next available frames (packet or frames, see Paragraphs 94 and 111; Note, a frame is like a page or packet of data whether they are audio, video, or any particular data) of a burst buffer (burst FIFO, see Paragraph 80).
D’Luna does not expressly disclose reading a second beat of the source memory; discarding one or more second unwanted bytes from the second beat of the source memory; and realigning one or more second remaining bytes from the second beat of the source memory in the next available frames of the burst buffer.
AMBA does disclose reading (see AMBA Page 52, Narrow Transfer) a second beat (see AMBA Figure A3-8, 2nd transfer) of the source memory; discarding one or more second unwanted bytes (see AMBA Page 52, shaded cells indicate bytes that are not transferred) from the second beat of the source memory; and realigning one or more second remaining bytes (see AMBA Fig. A3-9) from the second beat of the source memory in the next available frames (see AMBA Fig. A3-12, 1st to 3rd transfer) of the burst buffer.
At the time of the invention it would have been obvious to a person of ordinary skill in the art to incorporate AMBA Protocol on D’Luna’s processor to peripheral connection.
The suggestion/motivation for doing so would have been to take advantage of freely available, well tested protocol.
As to claim 9, the modification teaches the 9. The method of claim 8, comprising determining a source offset for the first memory (see AMBA Page 52, When … a transfer is narrow than it’s data bus, the address and control information determines which byte lanes the transfer use, so different byte laned could be used, i.e. different offset), and determining a number of bytes (see AMBA Fig. A3-8 or Fig. A3-9, 4 or 8) in the first beat and the second beat based on the source offset (see AMBA Page 53, the starting address is 4 offset).
As to claim 10, the modification teaches the method of claim 8, wherein the one or more first unwanted bytes include a lower one or more bytes (see AMBA Fig. A3-8 or Fig. A3-9; 0 to 7 bit positions) from the first beat.
As to claim 11, the modification teaches the method of claim 8, comprising transferring the realigned one or more first and second remaining bytes from the burst buffer to a destination memory (see AMBA Page 54, a single memory) having a different byte size (see AMBA Fig. A3-12, big-endian) architecture than the source memory (see AMBA Fig. A3-12, Source, little-endian).
As to claim 12, the modification teaches the method of claim 8, wherein the first beat has a same number of bytes as the second beat (see AMBA Fig. A3-8 or Fig. A3-9, 4 or 8).
As to claim 13, the modification teaches an application-specific integrated circuit (ASIC, see D’Luna Paragraph 45) or a field-programmable gate array system including a direct memory access controller (DMA, see D’Luna Paragraph 86) programmed to perform the method of claim 8.
Referring to claim 14, D’Luna teaches, as claimed, a method of transferring data from a source memory (data from internal memory, see Paragraph 86), the method comprising:
determining at least one of an alignment (align to, see Paragraph 99; Note, data is first aligned by padding and when paddings are removed remain data need to be aligned again) and a source offset (Note, mere alternative to “an alignment”) for the source memory;
distinguishing a plurality (PES packets, see Paragraph 99) of beats (word aligned to 32-bit boundaries, see Paragraph 99; Note, 32 bits are 4 bytes, so the aligned word size is 4 bytes) to be read (reads via DMA, see Paragraph 89) from the source memory based on the at least one of the alignment (align to, see Paragraph 99; Note, data is first aligned by padding and when paddings are removed remain data need to be aligned again) for the source memory and the source offset (Note, mere alternative to “the alignment”) for the source memory;
generating a single command (header with HEC, see Paragraph 89; Note, header in a packet stores command or instruction, see also Paragraph 41) enabling all wanted bytes (retained, see Paragraph 99; Note, retained data are wanted bytes) from the source memory to be written to a destination memory (see Fig. 16, TX FIFO);
storing the single command in first one or more frames (packet or frames, see Paragraphs 94 and 111; Note, a frame is like a page or packet of data whether they are audio, video, or any particular data) of a burst buffer (burst FIFO, see Paragraph 80);
for each of the plurality of beats, realigning (align to, see Paragraph 99; Note, purpose of padding data is to align, so when padding are removed, aligning is equivalent to realigning) one or more wanted bytes in next available frames (prior to end of current, see Paragraph 100; Note, current packet is the next available to the prior transport) of the burst buffer.
D’Luna does not disclose expressly the generating and storing a single read command (i.e. in a header).
AMBA does disclose the generating and storing a single read (AXI read, see Page 52) command (header fields, see Page 54).
At the time of the invention it would have been obvious to a person of ordinary skill in the art to incorporate AMBA Protocol on D’Luna’s processor to peripheral connection.
The suggestion/motivation for doing so would have been to take advantage of freely available, well tested protocol.
As to claim 15, the modification teaches the method of claim 14, wherein the single read command is a single AXI read (AXI read, see AMBA Page 52) command (header fields, see AMBA Page 54).
As to claim 16, the modification teaches the method of claim 14, wherein the single read command includes: SRC addr 0x0 (AxADDR[3:0] = 0x0, see Page 320), arlen =0x2 (AxADDR[3:0] = 0x0, see Page 46; Note, AX14 support 1 to 16 transfers), arsize =0x3 (ARSIZE[2:0], see Page 47; see Page 97 – burst must be a power of 2; and see Page 120 – support up to 64-bits of addressing). Note, Examiner interpreted above combination as ‘addr’ indicates starting address, arlen specifies number of beats minus one – so, 0x2 means (22 -1) or 3 beats (3 data transfer) and arsize defines the data transfer size in bytes – so 23 bytes equals 64 bits.
As to claim 17, the modification teaches the method of claim 14, wherein distinguishing the plurality of beats (beats of a burst, see AMBA Page 129) to be read from the source memory (data from internal memory, see D’Luna Paragraph 86) includes distinguishing the plurality of beats to be read from the source memory based on the alignment (An unaligned start address must be incremented and aligned for subsequent beats… see AMBA Page 129) for the source memory.
As to claim 18, the modification teaches the method of claim 14, wherein distinguishing the plurality of beats (beats of a burst, see AMBA Page 129) to be read from the source memory (data from internal memory, see D’Luna Paragraph 86) includes distinguishing the plurality of beats to be read from the source memory based on the source offset (the smaller physical address space to be positioned in an offset window within the larger physical address space, see AMBA Page 249) for the source memory.
As to claim 19, the modification teaches the method of claim 14, comprising using the single read (AXI read, see AMBA Page 52) command (header fields, see AMBA Page 54) to transfer all wanted (retained, see D’Luna Paragraph 99) bytes from each of the beats from the burst buffer to the destination memory, the destination memory having a different byte size (The protocol supports communication between components that have different physical address space size, see AMBA Page 249) architecture (support the ARMv7 and ARMv8, see AMBA Page 294; big-endian and little endian structures can coexist, see AMBA Page 54) than the source memory.
As to claim 20, the modification teaches an application-specific integrated circuit (ASIC, see D’Luna Paragraph 45) or a field-programmable gate array system including a direct memory access controller (DMA, see D’Luna Paragraph 86) programmed to perform the method of claim 14.
Response to Arguments
Applicant's arguments filed 3/23/2026 have been fully considered but they are not deemed to be persuasive.
Regarding the 35 U.S.C. §112, second paragraph problems, Applicant's amendment has overcome these rejections.
Applicant argues, Applicant respectfully submits that D'Luna does not disclose to discard unwanted bytes and realign bytes as defined by Applicant (e.g., read at position N to position M of the burst buffer). D'Luna instead discloses to add padding bytes at the end of each PES packet to word align to 32-bit boundaries in the memory buffers. (D'Luna, par. [0099].) In other words, D'Luna is not reading wanted bytes from position N to position M of a burst buffer: D'Luna is reading without realignment and then adding padding bytes at the end.
Examiner disagrees with applicant. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “read at position N to position M of the burst buffer”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Even if positions are said to be “implied” there is no claim limitation that suggest M too could not be the very end position of data that is not aligned. Examiner construed when paddings are done, that is realignment and when paddings are taken out that too is realignment. The data simply has to be aligned to how processor read the intended data.
Applicant argues, D'Luna and AMBA do not teach or suggest "generating a single read command enabling all wanted bytes from the source memory to be written to a destination memory" and "storing the single read command in first one or more frames of a burst buffer."
Examiner disagrees with applicant. In addition to above response, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “generating a single read command enabling all wanted bytes from the source memory to be written to a destination memory”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Conclusion
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hyun Nam whose telephone number is (571) 270-1725 and fax number is (571) 270-2725. The examiner can normally be reached on Monday through Friday 8:30 AM to 5:00 PM EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Dr. Henry Tsai can be reached on (571) 272-4176. 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.
/HYUN NAM/Primary Examiner, Art Unit 2183
Prosecution Insights