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 action is made non-final.
Claims 1-20 are pending in the case. Claims 1 and 12 are independent claims.
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 (i.e., changing from AIA to pre-AIA ) 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-3 and 5-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Iinuma (US 2009/0074291 A1), in view of Yumiki (US 2009/0021586 A1).
Regarding claim 1, Iinuma teaches a method for reducing data usage by a document processing system (FIG. 5 and [0072]), comprising:
detecting a segmented layout of a page from a preprocessed image thereof (S508 of FIG. 5 and FIG. 6A and [0079-0080]: a segmented layout of a page from a preprocessed image, like the image of FIG. 6A, is detected);
separating components of the layout into one or more blocks (S508-S509 of FIG. 5 and FIGS. 6A-B and [0079-0084]: components of the layout are separated into one or more blocks, such as a text region, image region, and/or graphics region);
identifying each type of the one or more blocks (S510 of FIG. 5 and FIGS. 6A-B and [0084]: each type of the one or more blocks is identified as a text, image, or graphics type);
converting a block of the one or more blocks identified as a text block to text (S510, S511, and S512 of FIG. 5 and [0088-0090]: a block is converted as a text block to text via at least OCR);
storing meta information for the block (S509 of FIG. 5 and [0081-0083]: metadata is generated and stored with the final binary image; For additional details regarding the meta information see FIGS. 11 and 8 and [0115-0120]);
constructing a formatted page for the page including the text and the meta information (S515 and S516 of FIG. 5, FIG. 8, and [0085-0091]: for example, a formatted page as seen in FIG. 8 is constructed, including the text and the meta information); and
([0016], S515 of FIG. 5 and [0085-0093]: requisite memory capacity is reduced due to the formatted page having a smaller storage size as a result of processing).
Iinuma does not explicitly teach determining whether the formatted page has a smaller storage size than the preprocessed image associated with the formatted page.
Yumiki teaches determining whether the formatted page has a smaller storage size than the preprocessed image associated with the formatted page ([0073-0076]: the formatted page is determined to have a smaller storage size than the preprocessed image when it is processed by the image compressor 10. As supported in [0074], “The image signal is compressed to a data size that is smaller than that of the original data”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Iinuma by incorporating the teachings of Yukimi so as to include determining whether the formatted page has a smaller storage size than the preprocessed image associated with the formatted page. Doing so would allow for the formatted page to be formatted in such a way that conserves memory space as opposed to the storage space required for the preprocessed image. The determination requires compression of data, which is akin to the compression disclosed in Iinuma as part of the image processing (Iinuma, [0085], [0092], [0093], [0114]).
Regarding claim 2, Iinuma further teaches the method according to claim 1, wherein the one or more blocks are two or more blocks, and wherein the block is a first block (S510, S511, and S512 of FIG. 5, [0084], and [0088-0090]: a first block is a text region. A second block may be an image region), the method further comprising:
separating a second block of the two or more blocks from the preprocessed image of the page identified as an image block (S510, S514, and S515 of FIG. 5, [0084-0085]: a second block is separated from the preprocessed image and identified as an image block);
converting the image block into an object (S510, S514, and S515 of FIG. 5, [0084-0085]); and
wherein the constructing of the formatted page for the page includes the text, the meta information, and the object (S515 and S516 of FIG. 5, FIG. 8, and [0085-0091]).
Regarding claim 3, Iinuma further teaches the method according to claim 2, wherein the detecting, the separating of the first block, the separating of the second block, the identifying, the converting of the text block, and the converting of the image block are performed in software (FIG. 5 and [0079-0091]: these steps are performed via data processing unit 206, which is a control unit. As stated in [0062], “The control unit includes a read only memory (ROM), which stores control programs according to which the CPU can execute the processing described with reference to FIGS. 5, 12, and 17”).
Regarding claim 5, Iinuma further teaches the method according to claim 1, further comprising:
separating one or more lines of the layout;
converting the one or more lines of the layout into drawing commands;
wherein the constructing of the formatted page for the page includes the text, the meta information, the object, and the drawing commands (S510, S513, S515 of FIG. 5, [0084], [0087], and [0114]: one or more lines of the layout separated and converted into drawing commands via vectorization processing; S515 and S516 of FIG. 5, FIG. 8, and [0085-0091]: construction includes text, meta information, object, and drawing commands).
Regarding claim 6, Iinuma further teaches the method according to claim 5, wherein:
the drawing commands are portable document format drawing commands; and
the formatted page is a portable document format page ([0087] and [0066]: As supported in [0066], “Furthermore, the MFP 100 can convert an image into an image file that can store vector data (e.g., an XML Paper Specification (XPS) file or a Portable Document Format (PDF) file), and can transfer the image file to the client PC 102.”).
Regarding claim 7, Iinuma further teaches the method according to claim 6, wherein the image block is a picture or a table (S510, S514, and S515 of FIG. 5, [0084-0085]: a second block is separated from the preprocessed image and identified as an image block; FIGS. 6A-B: see image region 602).
Regarding claim 8, Iinuma in view of Yumiki further teaches the method according to claim 5, further comprising responsive to the formatted page having a smaller storage size than the preprocessed image of the page, sending the formatted page from the document processing system in place of the preprocessed image (Iinuma, S515 and S516 of FIG. 5, FIG. 8, and [0085-0091]) (Yumiki, [0073-0077]).
Regarding claim 9, Iinuma in view of Yumiki teaches the method according to claim 5, further comprising:
responsive to the formatted page having a smaller storage size than the preprocessed image of the page, storing the formatted page from the document processing system in place of the preprocessed image; and
distributing the formatted page responsive to a send command (Iinuma, S515 and S516 of FIG. 5, FIG. 8, and [0085-0091], and [0118-0120]) (Yumiki, [0073-0077]).
Regarding claim 10, Iinuma teaches the method according to claim 9, wherein the formatted page is stored in page form (Iinuma, S515 and S516 of FIG. 5, FIG. 8, and [0085-0091]) (Yumiki, [0073-0077]).
Regarding claim 11, Iinuma teaches the method according to claim 10, wherein the first block is converted to text with optical character recognition of the document processing system (S510, S511, and S512 of FIG. 5 and [0088-0090]: a block is converted as a text block to text via at least OCR).
Regarding claims 12-14, the claims recite an apparatus (FIG. 2 AND [0062-0071]), comprising: a document processing system with a system memory, a data storage, one or more processor units, and an interface; the system memory configured to store program code including document services; the interface coupled for receiving user requests for the document services; wherein, in response to executing the program code, the document processing system is configured to initiate operations for implementing a process for reducing data usage, the process including operations corresponding to the method of claims 1-3, respectively, and are therefore rejected on the same premises.
Regarding claims 15-20, the claims recite an apparatus dependent on claim 13, but otherwise corresponding to the method of claims 5 and 7-11, respectively, and are therefore rejected on the same premises.
Claim 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Iinuma (US 2009/0074291 A1), in view of Yumiki (US 2009/0021586 A1), in view of Lin et al. (US 2025/0111690 A1).
Regarding claim 4, Iinuma teaches the method according to claim 3.
Lin teaches wherein the software is LayoutLMv3 ([0003-0004], FIG. 5 and [0042]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Iinuma in view of Yukimi by incorporating the teachings of Lin so as to include wherein the software is LayoutLMv3. Doing so would leverage a publicly available layout language model that “is pre-trained on 11 million invoices and forms” ([0042]) that allows “many document image understanding tasks, including but not limited to document type classification, information extraction from scanned documents, and scanned document image segmentation, to be executed with increased accuracy and generalizability” ([0004]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNY NGUYEN whose telephone number is (571)272-4980. The examiner can normally be reached M-Th 7AM to 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, KIEU D VU can be reached on (571)272-4057. 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.
/KENNY NGUYEN/Primary Examiner, Art Unit 2171