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 . In communications filed on 12/20/2025. Claims 1, 4, 8, and 14 are amended. Claims 2-3, 9, and 15 are cancelled. Claims 1, 4-8, and 10-14 are pending in this examination.
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. This examination is in response to US Patent Application No. 18/608,321.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission has been entered.
Examiner Note
Claims 1, and 8 recites that “one or more storage mediums storing”. This has been described in the specification as: The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, the "non-transitory" storage medium is a tangible device, and may not include a signal (e.g., an electromagnetic wave). Therefore, claims 1-13 are statutory under 35 USC 101.
Response to Argument
Applicant’s arguments with respect to claims 1, 8, and 14 for newly added limitation have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
First set of rejection:
Claims 1, 4-8, and 10-14 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Ren Wei (CN108768662A).
Regarding claim 1, Wei discloses an electronic device comprising at least one processor comprising processing circuitry; and memory including one or more storage mediums storing instructions that, when executed by the at least one processor individually or collectively, cause the electronic device to
[Page 1, Every application running on the Android platform must have a developer signature, and the package installer on the app store or Android device will reject the app that was attempted to install without a signature]; and
receive an Android Package (APK) file for which multi-signing is requested,
[Page 1, 2nd, paragraph, the invention relates to a method for signing and checking, in particular to a method for adding a custom signature check in an APK integrity check mechanism in Android… At present, Android supports two signature schemes… in order to be compatible with Android 6.0 (Marshmallow) and lower version installation, in most cases v1 + v2 signature scheme will be adopted, that is, first use v1 signature pair APK Sign it and then sign it with a v2 signature.], and [ Pages 2-3, Summary of the invention, A method for adding a custom signature to an Android APK, including the following steps…..If it is a signature operation, perform the P7 signature processing without the original text according to the APK byte stream obtained in step 1, and obtain the P7 signature with the original APK byte stream as the original text…determine the signature scheme, if only the v1 signature scheme, proceed to step 5, if there is a v2 signature scheme, proceed to step 8…In step 15, if the result of the verification is true, the verification of the corresponding additional signature is successful, and if the result of the verification is false, the verification of the corresponding additional signature fails. In a preferred embodiment of the present invention, in the step 4, the v2 signature scheme includes a v2 only signature scheme and a v1, and the v2 signature scheme has a good overall situation at the same time]; and
verify a signing block included in the APK file,
[ Page 2, Summary of the invention, Step 3, the APK is a standard ZIP format, and obtains an end (EOCD) block of the corresponding central directory record; Step 4, according to the APK byte stream obtained in step 1, determine the signature scheme, if only the v1 signature scheme, proceed to step 5, if there is a v2 signature scheme, proceed to step 8], and [ see FIG.3 , flow chart of the verification of the additional signature added by the APK]; and
determine a new signing block to be added to the APK file according to the multi-signing based on completion the verifying of the signing block,
[Page 1, 2nd, paragraph, the invention relates to a method for signing and checking, in particular to a method for adding a custom signature check in an APK integrity check mechanism in Android… At present, Android supports two signature schemes… in order to be compatible with Android 6.0 (Marshmallow) and lower version installation, in most cases v1 + v2 signature scheme will be adopted, that is, first use v1 signature pair apk Sign it and then sign it with a v2 signature.], and [ Pages 2-3, Summary of the invention, A method for adding a custom signature to an Android APK, including the following steps…..If it is a signature operation, perform the P7 signature processing without the original text according to the APK byte stream obtained in step 1, and obtain the P7 signature with the original APK byte stream as the original text…determine the signature scheme, if only the v1 signature scheme, proceed to step 5, if there is a v2 signature scheme, proceed to step 8…In step 15, if the result of the verification is true, the verification of the corresponding additional signature is successful, and if the result of the verification is false, the verification of the corresponding additional signature fails. In a preferred embodiment of the present invention, in the step 4, the v2 signature scheme includes a v2 only signature scheme and a v1, and the v2 signature scheme has a good overall situation at the same time]; and
reconstruct the APK file based on the new signing block by separating the signing block and the central directory in the ARK file based on the size of the new signing block, determining the signing block and contents of ZIP entries included in the ARK file to be new contents of ZIP entries, and determining a central directory and an end of central directory included in the ARK file to be a new central directory, and insert the new signing between new contents of ZIP entries and the new central directory in the reconstructed ARK file.[ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 4, WEI discloses[ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 5, WEI discloses[ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 6, WEI discloses [ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 7, WEI discloses [ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 8 , the claim is interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 10, WEI discloses [ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 11, WEI discloses [ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 12, WEI discloses [ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 13, WEI discloses[ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 14 , the claim is interpreted and rejected for the same rational set forth in claim 1.
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 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.
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.
Second set of rejection:
Claims 1, 4-8, and 10-14 are rejected under 35 U.S.C. 103 as being unpatentable over Seo, Seung Hyun (KR 1324693 B1) hereinafter, “Seo” (filed in IDS 03/18/2024), see the attached English version of this application, and in view of US Patent No. (US2020/0327227) issued to Chebyshev and furthermore in view of Yang LU ( WO2021097704 A1).
Regarding claim 1, Seo discloses an electronic device comprising at least one processor comprising processing circuitry; and memory including one or more storage mediums storing instructions that, when executed by the at least one processor individually or collectively, cause the electronic device to
[0079] the storage medium may be integral with the processor. The processor and the storage medium may reside within an application specific integrated circuit (ASIC). The ASIC may reside within the user terminal. Alternatively, the processor and the storage medium may reside as discrete components in a user terminal.
receive an Android Package (APK) file for which multi-signing is requested,
[0002] The Android Application Market is publishing applications], and
[0036] Then, the developer terminal 10 uploads the application with the first signature to the application market server 20.
[0037] Subsequently, the application market server 20 may perform a second signature on the contents of the entire application including the first signature with the second signature key using the Java signing tool, which is a Java tool (S22).
verify a signing block included in the APK file,
[0036] the application market server 20 may verify the first signature of the application uploaded by the developer terminal 10.
determine a new signing block to be added to the APK file according to the multi-signing based on completion the verifying of the signing block,
[0037] Subsequently, the application market server 20 may perform a second signature on the contents of the entire application including the first signature with the second signature key using the Java signing tool, which is a Java tool (S22).
While Seo discloses:
reconstruct the APK file based on the new signing block and insert the new signing block into the reconstructed APK file as: [0041] the application market server 20 can post the final application in which the dual signature is performed to the market.
And while Chebyshev discloses:
By determining a central directory and an end of central directory included in the ARK file to be a new central directory
[¶¶37-40, FIG. 1 shows the structure of an archive file 110 according to aspects of the present disclosure. For purposes of discussion, the archive file 110 may be formatted as an Android Package (APK) file for the Android operating system (OS)… Files of APK format are not encrypted; they are a subset of ZIP archive format. Each APK file is a compressed archive… In one aspect, each ZIP archive 110 (and consequently APK file) contains a so-called “central directory” 120, which comes at the end of the archive to make possible the adding of new files to the archive. This directory contains a list of the records 125 (names of files and directories) appearing in the archive, as well as the headers of the records. Each header within the central directory may contain, for the file(s) contained within the archive: the size (of a file within the archive) after compression; the size before compression; the length of the file name (of a file within the archive 110); the size of additional data on the file; the size of the commentary on the file; the disk number where the file begins; the relative offset to the local file header (the number of bytes from the start of the disk, where the file begins, to the local header for the file); the file name; additional data about the file; and the commentary on the file. In one aspect, the central directory 120 ends with an end record 126 (end of central directory or “EOCD” record), which may contain: the number of the current disk; the number of the disk where the central directory begins; the number of records in the central directory on this disk; the total number of records in the central directory; the size of the central directory; the offset to the central directory relative to the start of the archive; the size of the commentary; and the commentary. Thus, after the reading and analysis of the central directory, it is possible to gain access directly to the compressed data of any record 140 (to the compressed files) stored in the central directory by the offset as described in the header. The data of the record also starts from the local file header 141. The local file header partly includes information, which is contained in the central directory, namely: the size (of the corresponding file within the archive) after compression; the size before compression; the length of the file name; the size of additional data on the file; the file name; and additional data about the file. In a record 140, the compressed file data 142 begins (i.e., is arranged) immediately after the corresponding header 141. The data of the records inside the archive 110 may be saved in an order different from their sequence within the central directory].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seo by incorporating “ZIP archive (and consequently APK file)”, as taught by Chebyshev. One could have been motivated to do so in order to indicate that the achieve file contains a so-called “central directory” 120, which comes at the end of the archive to make possible the adding of new files to the archive. This directory contains a list of the records 125 (names of files and directories) appearing in the archive, as well as the headers of the records. [ Chebyshev, ¶¶37-40].
Furthermore , LU discloses:
reconstruct the APK file based on the new signing block by separating the signing block and the central directory in the ARK file based on the size of the new signing block, determining the signing block and contents of ZIP entries included in the ARK file to be new contents of ZIP entries, and determining a central directory and an end of central directory included in the ARK file to be a new central directory, and insert the new signing between new contents of ZIP entries and the new central directory in the reconstructed ARK file [0035]In an application, the data block may be several program segments, data segments, or independent files obtained by dividing the target data. For example, the data block may be a file independent from each other in the compressed package and may be specifically a dex file in the Android application package (an executable file on the Android platform), a manifest file, a resource file, or the like.[0077] In an application, when the data block is a data block obtained by dividing each file in the compressed package, the central directory, and the end of the central directory, a plurality of consecutively arranged data blocks obtained by dividing each file, the central directory, and the central directory in the compressed package are separately obtained by using the preset data amount as a division unit. The preset data amount may be set according to actual needs, for example, the preset data amount may be any value between 0.5 MB and 2 MB, which may be 1 MB, so that the second terminal may accurately identify the damage to the file interval of 1 MB unit. Because the size of the end of the file, the central directory, or the central directory is not necessarily an integer multiple of the preset data volume, since the size of the end of the file, the central directory, or the central directory is not necessarily an integer multiple of the preset data amount, the size of the last data block is less than or equal to the preset data amount.[0082-0083] As shown in FIG. 5, on the basis of FIG. 4, an exemplary implementation process of step S400-S403 is exemplarily shown; The compressed package includes Contents of ZIP entries 51, Android application package signature blocks 52, a central directory 53 and a central directory end 54, the file content 51, the central directory 53, and the central directory end 54 are respectively divided into a plurality of consecutive data blocks (a part shown in 55 in FIG. 5), the first terminal respectively generates summary information of each data block (the part shown in FIG. 5 in FIG. 5), and all the abstract information constitutes a digest information block 57. In the embodiment corresponding to FIG. 4, the first terminal separately generates the expected summary of each data block in the compressed package by separately dividing each file, the central directory, and the end of the central directory in the compressed package into several data blocks arranged in succession. Information, generating a summary information block including expected summary information of all data blocks in the compressed package, inserting the summary information block between the file of the compressed package and the central directory, and then sending the compressed package carrying the summary information block to the second terminal; The second terminal parses the compressed package, parses out the expected summary information of each data block in the compressed package, traverses all the data blocks in the compressed package, calculates the actual summary information of each data block in the compressed package, and then compresses them separately The expected summary information of each data block in the packet is compared with the actual summary information; if the comparison results are consistent, the verification is determined to be successful; otherwise, the verification is determined to be a failure; the second terminal records the location information of the file that failed the verification; The location information of the file that fails the verification is sent to the first terminal; the first terminal re-sends the intact data block located at the location information to the second terminal according to the location information of the data block that fails the verification; the second terminal sends the data that fails the verification The block is replaced with the data block located at the location information to complete the repair of the data block that failed the verification, so that the second terminal can perform segment verification on the compressed package it downloaded. When the verification fails, it only needs to re-download the data block. The damaged data block can effectively reduce the data traffic consumption of the second terminal. The first terminal only needs to re-send the damaged data block to the second terminal, which can effectively reduce the content distribution network traffic consumption of the first terminal.
PNG
media_image1.png
316
548
media_image1.png
Greyscale
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Seo, and Chebyshev by incorporating “compressed package as an Android application package;”, as taught by LU. One could have been motivated to do so in order for storing the expected digest information of all data blocks in the compressed package to an Android application package signature block, where the Android application package signature block is located between a file of the compressed package and a central directory, where the compressed package includes Contents of ZIP entries 51, Android application package signature blocks 52, a central directory 53 and a central directory end 54[ LU, ¶¶78-82].
Regarding claim 4, Seo does not explicitly disclose, however the combination of Chebyshev, and LU disclose:
Chebyshev discloses [ see FIG 1 and corresponding text for more details ¶¶37-40].
LU discloses[ see FIG 5 ¶¶35.77 82-83].
Regarding claim 5, the combination of, Seo, Chebyshev and LU disclose:
Seo discloses: [¶¶2, 33, 36-37, 41, 79].
Chebyshev discloses [ see FIG 1 and corresponding text for more details ¶¶37-40].
LU discloses[ see FIG 5 ¶¶35.77 82-83].
Regarding claims 6, and 11, Seo discloses, wherein the signing block is a block included in the APK file to ensure the integrity of the APK file and corresponds to a first signing key[0033] Then, the developer terminal 10 can perform a first signature on the application with the first signature key using a Java signature tool (Jarsigner), which is a Java tool (S21). The first signature is a signature for authenticating the application, which may be referred to herein as the signature of the application developer. The Java Archive Signer is a kind of Java tool that can be used to sign applications using signing keys.
Regarding claim 7 Seo discloses, wherein the new signing block is a block included in the reconstructed APK file to ensure the integrity of the reconstructed APK file and corresponds to a second signing key different from the first signing key.
[0037] Subsequently, the application market server 20 may perform a second signature on the contents of the entire application including the first signature with the second signature key using the Java signing tool, which is a Java tool (S22). The second signature is a signature for authenticating the application, which may be referred to herein as the signature of the application market
Regarding claim 8, this claim is interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 10, Seo does not explicitly disclose, however the combination of Chebyshev, and LU disclose:
Chebyshev discloses [ see FIG 1 and corresponding text for more details ¶¶37-40].
LU discloses[ see FIG 5 ¶¶35.77 82-83].
Regarding claim 12, the combination of, Seo, Chebyshev, and LU disclose:
Seo discloses: [¶¶2, 33, 36-37, 41, 79].
Chebyshev discloses [ see FIG 1 and corresponding text for more details ¶¶37-40].
LU discloses[ see FIG 5 ¶¶35.77 82-83].
Regarding claim 13, Seo does not explicitly disclose, however the combination of Chebyshev, and LU disclose:
Chebyshev discloses [ see FIG 1 and corresponding text for more details ¶¶37-40].
LU discloses[ see FIG 5 ¶¶35.77 82-83].
Regarding claim 14, this claim is interpreted and rejected for the same rational set forth in claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See submitted 892 for more relevant references.
LI, Sheng-hu (CN 113568626 A) It should be noted that the signature block described in the embodiment can be a specific area of APK packet (application package), APK packet file composition can be shown in FIG. 3, wherein the file is mainly composed of Contents of ZIP entries (compressed file entity content); APK Signing Block (APK signature block), Central Directory (central directory), End of Directory (directory ending position) four parts, wherein the APK Signing Block is the signature block. In FIG. 3, the length of Block (block) is sequentially recorded from top to bottom; ID-VALUE pair; the length of Block; the signature area magic number (for verifying the validity of signature area); because the ID-VALUE pair number is dynamic, so it provides the positive sequence (from up to down, in the figure is positive number) and reverse (from bottom to top, in the figure is negative) two kinds of calculation offset . The signature block can be used for storing n (not less than 1) ID-VALUE pair (ID can be used for identifying each service, VALUE can be used for storing service data). wherein, the dynamic packing id in FIG. 3 can be the service code, dynamic packing service data can be the service data.
WO2024/041428A1 [Taking the operating system of the terminal device as [AltContent: rect] Taking the operating system as an example, the application installation file can usually be an Android application package (Android package, APK) file (or "APK installation package"). As a possible example, the data format of the APK installation package may be a compressed (such as ZIP) file format.
For example, taking the APK installation package in ZIP file format as an example, when dividing the APK installation package into blocks, the APK installation package based on the V1 signature scheme can include the Contents of ZIP entries block and the ZIP comments block as shown in Table 1 below. , the APK installation package based on the V2/V3 signature scheme can include the Contents of ZIP entries block, Signing Block block, Central Directory block and End of Central Directory block shown in Table 2 below:
PNG
media_image2.png
76
574
media_image2.png
Greyscale
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496