DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is responsive to a response filed on October 27th, 2025. In this office action:
Claims 1-9, 19, and 21-30 are pending
Claims 1-9, 19, and 21-30 are rejected
Response to Amendment
The amendments filed on October 27th, 2025 have been entered.
Claims 5-6, 8, 24-25, and 27 have been amended.
The previously raised claim objections for claims 5 and 24 are withdrawn in light of the amendments.
The previously raised 35 U.S.C. 112(b) rejection for claims 6 and 25 is withdrawn in light of the amendments.
Response to Arguments
Applicant’s arguments filed on October 27th, 2025 have been fully considered by the Examiner, but are moot in view of the new grounds of rejection.
Claim Objections
Claims 5 and 24 are objected to because of the following informality:
“wherein positioning the chunks in the packet in the priority order of the priority is based on the parameters in the request” should read (Examiner’s suggestion for consistency) “wherein positioning the chunks in the packet in the priority order of the priority of the chunks is based on the parameters in the request”
Appropriate correction(s) is/are required.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 5-6, 19, 21, 24-25, and 29-30 are rejected under 35 U.S.C. 103 as being unpatentable over Nakata (Pub. No. US 2017/0249108); in view of Shimada et al. (Pub. No. US 2009/0115798), hereinafter Shimada.
Claim 1. Nakata discloses [a] method implemented by an image source, the method comprising:
designating, by one or more processors of the image source (See Parag. [0027] [0053]), each chunk of a plurality of chunks of an interlaced image file as critical or ancillary (See Parag. [0032]; The chunk can store various kinds of information about an image. The chunks are classified into a “critical chunk” and an “ancillary chunk”);
positioning, by the one or more processors, the chunks in a packet in a priority order (See Parag. [0031-0033]; The meta image is generated conforming to a format to be described with reference to FIGS. 5A and 5B … FIG. 5A is a schematic diagram illustrating a data example of the meta image in the present exemplary embodiment. The image format of PNG is defined in a form including a plurality of data areas each referred to as a “chunk”, following a file header of 8 bytes ... The chunks are classified into a “critical chunk” and an “ancillary chunk”. Four types of chunks are each defined as the critical chunk. The four types are image header (IHDR), palette table (PLTE), image data (IDAT), and image trailer (IEND) ... the document data including the meta image is converted into the print data and then transmitted to a printer ... the meta image in the present exemplary embodiment includes the four chunks of IHDR, IDAT, naNo, and IEND. Examiner’s interpretation: The chunks are placed following the file header to be transmitted to the printer, see also Fig. 5A, which is reasonably interpreted by the Examiner as the chunks are positioned in a priority order); and
transmitting, by a transmitter of the image source, the packet toward an image destination (See Parag. [0033]; the document data including the meta image is converted into the print data and then transmitted to a printer. See also Parag. [0028] [0036]. Examiner’s interpretation: sending an image to a printer involves sending packet(s) (or frames/packets in the context of network printing) that are transmitted over a network/connection).
Nakata doesn’t explicitly disclose the PNG image is an interlaced image file; [and] positioning the chunks in a priority order according to a priority of the chunks and their designation as critical or ancillary.
However, Shimada discloses: PNG image is an interlaced image file (See Parag. [0097]; Still image data such as an image material is written as, for example, a PNG image file in the memory 80 or 81. This PNG image file is supplied via a graphics unit 69 to a color lookup table (CLUT) 70. Reference is made to the index number, and the PNG image file is converted into RGB data, and supplied via a scaling unit 71 to the .alpha. blending unit 72. The scaling unit 71 converts the data into interlaced data ...); [and] positioning, by the one or more processors, the chunks in a priority order according to a priority of the chunks and their designation as critical or ancillary (See Parag. [0086-0087]; FIGS. 11A and 11B show an exemplary structure of a PNG image file. A PNG image file includes, as shown in FIG. 11A, a PNG signature, an IHDR chunk, a PLTE chunk, an IDAT chunk, an IEND chunk, two ancillary chunks, and, if necessary, additional chunks ... Referring to FIG. 11B, a PNG signature is an identifier of the PNG image and stores an 8-byte sequence for identifying a PNG image. An IHDR chunk is an image header and stores important data of the overall image, such as the image size and bit depth of the PNG image. An ancillary chunk placed after the IHDR chunk contains one or a plurality of chunks relating to displaying colors, such as a gamma value and a chroma of the PNG image. A PLTE chunk stores a palette in which an element is designated using an index number, as described above. The PLTE chunk is critical in an index color mode. The next ancillary chunk containing one or a plurality of chunks relating to displaying transparent colors or the like. The next additional chunk is optional and is not critical. An IDAT chunk is image data and stores a compressed and encoded image data sequence. A plurality of IDAT chunks may exist in one PNG image file. An IEND chunk marks the end of the PNG image file and has a data length of 0).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the positioned chunks, taught by Nakata, to include positioning, by the one or more processors, the chunks in a priority order according to a priority of the chunks and their designation as critical or ancillary, as taught by Shimada. This would be convenient to provide image processing program which are suitable for use in displaying an image represented by image data having a significantly large number of pixels on a display device having a standard number of pixels (Shimada, Parag. [0003]).
Claim 2. Nakata in view of Shimada discloses [t]he method of claim 1,
Nakata further discloses wherein positioning the chunks comprises positioning critical chunks at a head of the packet, positioning an image trailer (IEND) chunk as a last chunk of the critical chunks (See Parag. [0031-0032]; The meta image is generated conforming to a format to be described with reference to FIGS. 5A and 5B … FIG. 5A is a schematic diagram illustrating a data example of the meta image in the present exemplary embodiment. The image format of PNG is defined in a form including a plurality of data areas each referred to as a “chunk”, following a file header of 8 bytes. The chunk includes a chunk size (4 bytes), a chunk type (4 bytes), a data part (an arbitrary length), and a cyclic redundancy code (CRC) (4 bytes). The chunk can store various kinds of information about an image. The chunks are classified into a “critical chunk” and an “ancillary chunk”. Four types of chunks are each defined as the critical chunk. The four types are image header (IHDR), palette table (PLTE), image data (IDAT), and image trailer (IEND)).
Nakata doesn’t explicitly disclose positioning ancillary chunks at a tail of the packet after the IEND chunk.
However, Shimada discloses positioning ancillary chunks at a tail of the packet after the IEND chunk (See Parag. [0087]; An IEND chunk marks the end of the PNG image file and has a data length of 0).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the positioned chunks, taught by Nakata, to include positioning ancillary chunks at a tail of the packet after the IEND chunk, as taught by Shimada. This would be convenient to provide image processing program which are suitable for use in displaying an image represented by image data having a significantly large number of pixels on a display device having a standard number of pixels (Shimada, Parag. [0003]).
Claim 5. Nakata in view of Shimada discloses [t]he method of claim 1,
Nakata further discloses the method further comprising receiving, by a receiver of the image source, a request for the image file containing parameters, and wherein positioning the chunks in the packet in the priority order of the priority is based on the parameters in the request (See Parag. [0027]; An application 301 is a software program for creating document data, and receiving a print instruction via a print dialog. Upon receiving a print instruction from a user, the application 301 transmits a rendering command for document data to a V3 graphics module 307 using API of GDI. See Parag. [0031-0032]; The meta image is generated conforming to a format to be described with reference to FIGS. 5A and 5B … FIG. 5A is a schematic diagram illustrating a data example of the meta image in the present exemplary embodiment … See Parag. [0033]; the document data including the meta image).
Nakata doesn’t expliclty disclose the PNG image is an interlaced image file.
Shimada further discloses: PNG image is an interlaced image file (See Parag. [0097]; Still image data such as an image material is written as, for example, a PNG image file in the memory 80 or 81. This PNG image file is supplied via a graphics unit 69 to a color lookup table (CLUT) 70. Reference is made to the index number, and the PNG image file is converted into RGB data, and supplied via a scaling unit 71 to the .alpha. blending unit 72. The scaling unit 71 converts the data into interlaced data ...)
Claim 6. Nakata in view of Shimada discloses [t]he method of claim 5,
Nakata further discloses wherein the parameters in the request indicate one or more of: an image smoothness requirement of the image destination, an image attribute preference of the image destination, or a decoding capability of the image destination (See Parag. [0027]; Upon receiving a print instruction from a user, the application 301 transmits a rendering command for document data to a V3 graphics module 307 using API of GDI. The V3 printer driver using GDI has no step for converting GDI into XPS. The V3 graphics module 307 directly converts GDI into a printer description language (PDL). The PDL is print data for performing print processing in the printer 20. The V3 graphics module 307 then outputs this PDL. A spooler 305 buffers the output PDL, and then a port monitor 306 transmits the PDL to the printer 20).
Claim 19. Nakata discloses [a]n image source comprising:
a memory storing instructions; and at least one processor in communication with the memory (See Parag. [0027] [0053]), the at least one processor configured, upon execution of the instructions, to perform the following steps:
designating each chunk of a plurality of chunks of an image file as critical or ancillary (See Parag. [0032]; The chunk can store various kinds of information about an image. The chunks are classified into a “critical chunk” and an “ancillary chunk”);
positioning the chunks in a packet in a priority order (See Parag. [0031-0033]; The meta image is generated conforming to a format to be described with reference to FIGS. 5A and 5B … FIG. 5A is a schematic diagram illustrating a data example of the meta image in the present exemplary embodiment. The image format of PNG is defined in a form including a plurality of data areas each referred to as a “chunk”, following a file header of 8 bytes ... The chunks are classified into a “critical chunk” and an “ancillary chunk”. Four types of chunks are each defined as the critical chunk. The four types are image header (IHDR), palette table (PLTE), image data (IDAT), and image trailer (IEND) ... the document data including the meta image is converted into the print data and then transmitted to a printer ... the meta image in the present exemplary embodiment includes the four chunks of IHDR, IDAT, naNo, and IEND. Examiner’s interpretation: The chunks are placed following the file header to be transmitted to the printer, see also Fig. 5A, which is reasonably interpreted by the Examiner as the chunks are positioned in a priority order); and
transmitting the packet toward an image destination (See Parag. [0033]; the document data including the meta image is converted into the print data and then transmitted to a printer. See also Parag. [0028] [0036]. Examiner’s interpretation: sending an image to a printer involves sending packet(s) (or frames/packets in the context of network printing) that are transmitted over a network/connection).
Nakata doesn’t explicitly disclose the PNG image is an interlaced image file; [and] positioning the chunks in a priority order according to a priority of the chunks and their designation as critical or ancillary.
However, Shimada discloses: PNG image is an interlaced image file (See Parag. [0097]; Still image data such as an image material is written as, for example, a PNG image file in the memory 80 or 81. This PNG image file is supplied via a graphics unit 69 to a color lookup table (CLUT) 70. Reference is made to the index number, and the PNG image file is converted into RGB data, and supplied via a scaling unit 71 to the .alpha. blending unit 72. The scaling unit 71 converts the data into interlaced data ...); [and] positioning the chunks in a priority order according to a priority of the chunks and their designation as critical or ancillary (See Parag. [0086-0087]; FIGS. 11A and 11B show an exemplary structure of a PNG image file. A PNG image file includes, as shown in FIG. 11A, a PNG signature, an IHDR chunk, a PLTE chunk, an IDAT chunk, an IEND chunk, two ancillary chunks, and, if necessary, additional chunks ... Referring to FIG. 11B, a PNG signature is an identifier of the PNG image and stores an 8-byte sequence for identifying a PNG image. An IHDR chunk is an image header and stores important data of the overall image, such as the image size and bit depth of the PNG image. An ancillary chunk placed after the IHDR chunk contains one or a plurality of chunks relating to displaying colors, such as a gamma value and a chroma of the PNG image. A PLTE chunk stores a palette in which an element is designated using an index number, as described above. The PLTE chunk is critical in an index color mode. The next ancillary chunk containing one or a plurality of chunks relating to displaying transparent colors or the like. The next additional chunk is optional and is not critical. An IDAT chunk is image data and stores a compressed and encoded image data sequence. A plurality of IDAT chunks may exist in one PNG image file. An IEND chunk marks the end of the PNG image file and has a data length of 0).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the positioned chunks, taught by Nakata, to include positioning the chunks in a priority order according to a priority of the chunks and their designation as critical or ancillary, as taught by Shimada. This would be convenient to provide image processing program which are suitable for use in displaying an image represented by image data having a significantly large number of pixels on a display device having a standard number of pixels (Shimada, Parag. [0003]).
Claim 21 is taught by Nakata in view of Shimada as described for claim 2.
Claim 24 is taught by Nakata in view of Shimada as described for claim 5.
Claim 25 is taught by Nakata in view of Shimada as described for claim 6.
Claim 29. Nakata discloses [a] non-transitory, computer-readable medium storing instructions that when executed by a processor cause the processor (See Parag. [0027] [0053]) to:
designate each chunk of a plurality of chunks of an image file as critical or ancillary (See Parag. [0032]; The chunk can store various kinds of information about an image. The chunks are classified into a “critical chunk” and an “ancillary chunk”);
position the chunks in a packet in a priority order (See Parag. [0031-0033]; The meta image is generated conforming to a format to be described with reference to FIGS. 5A and 5B … FIG. 5A is a schematic diagram illustrating a data example of the meta image in the present exemplary embodiment. The image format of PNG is defined in a form including a plurality of data areas each referred to as a “chunk”, following a file header of 8 bytes ... The chunks are classified into a “critical chunk” and an “ancillary chunk”. Four types of chunks are each defined as the critical chunk. The four types are image header (IHDR), palette table (PLTE), image data (IDAT), and image trailer (IEND) ... the document data including the meta image is converted into the print data and then transmitted to a printer ... the meta image in the present exemplary embodiment includes the four chunks of IHDR, IDAT, naNo, and IEND. Examiner’s interpretation: The chunks are placed following the file header to be transmitted to the printer, see also Fig. 5A, which is reasonably interpreted by the Examiner as the chunks are positioned in a priority order); and
transmit the packet toward an image destination (See Parag. [0033]; the document data including the meta image is converted into the print data and then transmitted to a printer. See also Parag. [0028] [0036]. Examiner’s interpretation: sending an image to a printer involves sending packet(s) (or frames/packets in the context of network printing) that are transmitted over a network/connection).
Nakata doesn’t explicitly disclose the PNG image is an interlaced image file; [and] position the chunks in a priority order according to a priority of the chunks and their designation as critical or ancillary.
However, Shimada discloses: PNG image is an interlaced image file (See Parag. [0097]; Still image data such as an image material is written as, for example, a PNG image file in the memory 80 or 81. This PNG image file is supplied via a graphics unit 69 to a color lookup table (CLUT) 70. Reference is made to the index number, and the PNG image file is converted into RGB data, and supplied via a scaling unit 71 to the .alpha. blending unit 72. The scaling unit 71 converts the data into interlaced data ...); [and] position the chunks in a priority order according to a priority of the chunks and their designation as critical or ancillary (See Parag. [0086-0087]; FIGS. 11A and 11B show an exemplary structure of a PNG image file. A PNG image file includes, as shown in FIG. 11A, a PNG signature, an IHDR chunk, a PLTE chunk, an IDAT chunk, an IEND chunk, two ancillary chunks, and, if necessary, additional chunks ... Referring to FIG. 11B, a PNG signature is an identifier of the PNG image and stores an 8-byte sequence for identifying a PNG image. An IHDR chunk is an image header and stores important data of the overall image, such as the image size and bit depth of the PNG image. An ancillary chunk placed after the IHDR chunk contains one or a plurality of chunks relating to displaying colors, such as a gamma value and a chroma of the PNG image. A PLTE chunk stores a palette in which an element is designated using an index number, as described above. The PLTE chunk is critical in an index color mode. The next ancillary chunk containing one or a plurality of chunks relating to displaying transparent colors or the like. The next additional chunk is optional and is not critical. An IDAT chunk is image data and stores a compressed and encoded image data sequence. A plurality of IDAT chunks may exist in one PNG image file. An IEND chunk marks the end of the PNG image file and has a data length of 0).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the positioned chunks, taught by Nakata, to include positioning the chunks in a priority order according to a priority of the chunks and their designation as critical or ancillary, as taught by Shimada. This would be convenient to provide image processing program which are suitable for use in displaying an image represented by image data having a significantly large number of pixels on a display device having a standard number of pixels (Shimada, Parag. [0003]).
Claim 30 is taught by Nakata in view of Shimada as described for claim 2.
Claims 3-4, 8-9, 22-23, and 27-28 are rejected under 35 U.S.C. 103 as being unpatentable over Nakata (Pub. No. US 2017/0249108); in view of Shimada et al. (Pub. No. US 2009/0115798), hereinafter Shimada; and further in view of Popelo et al. (Pub. No. US 2016/0335500), hereinafter Popelo.
Claim 3. Nakata in view of Shimada discloses [t]he method of claim 1,
Nakata in view of Shimada doesn’t explicitly disclose wherein positioning the chunks comprises positioning all critical chunks of a layer before all ancillary chunks of the layer.
However, Popelo discloses wherein positioning the chunks comprises positioning all critical chunks of a layer before all ancillary chunks of the layer (See Parag. [0083]; A series of critical “chunks” 302 to 305 then follows. The IHDR chunk 302 contains image 300's width, height, and bit depth. The PLTE chunk 303 contains the palette or list of colors used in image 300. One or more IDAT chunks 304 contain the actual image data of image 300. Finally, the IEND chunk 305 indicates the end of the image data. According to the PNG specification, a variety of ancillary chunks may be included in a PNG image file 300. One such chunk is the iTXt chunk 310, which allows for storage of text comprising characters encoded according to the UTF-8 character encoding. Examiner’s interpretation: Fig. 7 shows that “critical chunks 302 to 305” are positioned before “ancillary chunks 310”).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the positioned chunks, taught by Nakata in view of Shimada, to include positioning all critical chunks of a layer before all ancillary chunks of the layer, as taught by Popelo. This would be convenient in associating a generated image with generated image metadata, where the IEND chunk indicates the end of the image data (Popelo, Parag. [0083]).
Claim 4. Nakata in view of Shimada discloses [t]he method of claim 1,
Nakata in view of Shimada doesn’t explicitly disclose wherein positioning the chunks comprises positioning a critical chunk of a lower priority layer before an ancillary chunk of a higher priority layer.
However, Popelo discloses wherein positioning the chunks comprises positioning a critical chunk of a lower priority layer before an ancillary chunk of a higher priority layer (See Parag. [0083]; A series of critical “chunks” 302 to 305 then follows. The IHDR chunk 302 contains image 300's width, height, and bit depth. The PLTE chunk 303 contains the palette or list of colors used in image 300. One or more IDAT chunks 304 contain the actual image data of image 300. Finally, the IEND chunk 305 indicates the end of the image data. According to the PNG specification, a variety of ancillary chunks may be included in a PNG image file 300. One such chunk is the iTXt chunk 310, which allows for storage of text comprising characters encoded according to the UTF-8 character encoding. Examiner’s interpretation: Fig. 7 shows that critical chunk 305 is positioned before ancillary chunk 310).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the positioned chunks, taught by Nakata in view of Shimada, to include positioning a critical chunk of a lower priority layer before an ancillary chunk of a higher priority layer, as taught by Popelo. This would be convenient in associating a generated image with generated image metadata, where the IEND chunk indicates the end of the image data (Popelo, Parag. [0083]).
Claim 8. Nakata in view of Shimada and Popelo discloses [t]he method of claim 3,
Nakata in view of Shimada doesn’t explicitly disclose the method further comprising: assigning, by the one or more processors, a layer priority level to each layer, wherein each successive layer receives a decreasing priority level; ordering, by the one or more processors, the chunks of each layer based on a layer priority level; and positioning, by the one or more processors, the chunks of each layer prior to an IEND chunk or subsequent to the IEND chunk based on the layer priority level of the each layer.
However, Popelo discloses assigning, by the one or more processors, a layer priority level to each layer, wherein each successive layer receives a decreasing priority level; ordering, by the one or more processors, the chunks of each layer based on a layer priority level; and positioning, by the one or more processors, the chunks of each layer prior to an IEND chunk or subsequent to the IEND chunk based on the layer priority level of the each layer (See Parag. [0083]; associating the generated image and the generated image metadata is by writing an image file including them both to a computer-readable storage medium, such as a memory of smartphone 120 … FIG. 7 shows a block diagram of a PNG image file 300. The first eight bytes of the file (labeled 301) consist of the standard PNG file signature. A series of critical “chunks” 302 to 305 then follows. The IHDR chunk 302 contains image 300's width, height, and bit depth. The PLTE chunk 303 contains the palette or list of colors used in image 300. One or more IDAT chunks 304 contain the actual image data of image 300. Finally, the IEND chunk 305 indicates the end of the image data. According to the PNG specification, a variety of ancillary chunks may be included in a PNG image file 300. Examiner’s interpretation: the chunks are positioned in a priority order).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the positioned chunks, taught by Nakata in view of Shimada, to include assigning, by the one or more processors, a layer priority level to each layer, wherein each successive layer receives a decreasing priority level, ordering, by the one or more processors, the chunks of each layer based on a layer priority level, and positioning, by the one or more processors, the chunks of each layer prior to an IEND chunk or subsequent to the IEND chunk based on the layer priority level of the each layer, as taught by Popelo. This would be convenient in associating a generated image with generated image metadata, where the IEND chunk indicates the end of the image data (Popelo, Parag. [0083]).
Claim 9. Nakata in view of Shimada and Popelo discloses [t]he method of claim 8,
Nakata doesn’t explicitly disclose wherein the IEND chunk indicates a threshold beyond which no packet wash can be applied when proceeding from a tail of the packet to a head of the packet
However, Shimada discloses wherein the IEND chunk indicates a threshold beyond which no packet wash can be applied when proceeding from a tail of the packet to a head of the packet (See Parag. [0087]; An IEND chunk marks the end of the PNG image file and has a data length of 0).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the positioned chunks, taught by Nakata, to include wherein the IEND chunk indicates a threshold beyond which no packet wash can be applied when proceeding from a tail of the packet to a head of the packet, as taught by Shimada. This would be convenient to provide image processing program which are suitable for use in displaying an image represented by image data having a significantly large number of pixels on a display device having a standard number of pixels (Shimada, Parag. [0003]).
Claim 22 is taught by Nakata in view of Shimada and Popelo as described for claim 3.
Claim 23 is taught by Nakata in view of Shimada and Popelo as described for claim 4.
Claim 27 is taught by Nakata in view of Shimada and Popelo as described for claim 8.
Claim 28 is taught by Nakata in view of Shimada and Popelo as described for claim 9.
Claims 7 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Nakata (Pub. No. US 2017/0249108); in view of Shimada et al. (Pub. No. US 2009/0115798), hereinafter Shimada; and further in view of AHN (Pub. No. US 2017/0026493).
Claim 7. Nakata in view of Shimada discloses [t]he method of claim 1,
Nakata in view of Shimada doesn’t explicitly disclose wherein the chunks are positioned to support removal of ancillary chunks by a packet wash process during packet transit.
However, AHN discloses wherein the chunks are positioned to support removal of ancillary chunks by a packet wash process during packet transit (See Parag. [0160]; In the case of the PNG image resource, the chunks of the attributes such as IHDR, sBIT, pHYs, IDAT and IEND are retained in the source as they are; the chunk of the attribute such as tEXT is deleted from the resource).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the positioned chunks, taught by Nakata in view of Shimada, to support removal of ancillary chunks by a packet wash process during packet transit, as taught by AHN. This would be convenient to minimize problem such that the unnecessary data increases the total size of the application package, increases time to be taken in downloading and installing the application package, requires high memory or buffer capacity for execution, and delays execution time due to process of the unnecessary data (AHN, Parag. [0009]).
Claim 26 is taught by Nakata in view of AHN as described for claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Gehtman et al. (Pub. No. US 2021/0042410) – Related art in the area of malicious code purification of graphics files, (Parag. [0024]; Every chunk has a similar structure which includes a 4-byte length field, a 4-byte chunk type field, between 2,147,483,647 bytes of chunk data, and a 4-byte cyclic redundancy check value (CRC). The length field refers to the length of the chunk data field. The chunk type field may be one of several chunk types which include an image header (IHDR) chunk usually located at the beginning followed by one or more image data (IDAT) chunks and an image end (IEND) chunk at the end. The IDAT chunk contains the actual image data. The IHDR chunk specifies information regarding image size, color model, bit depth, and interlacing. The IEND chunk is a four-byte chunk that marks the end of the PNG file).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
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, Oscar Louie can be reached on 571-270-1684. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/Abdelbasst Talioua/Examiner, Art Unit 2445