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 04/16/2026. Claims 1, 8, 10, 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.
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 § 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.
First set of rejection:
Claims 1, 4-8, and 10-14 are rejected under 35 U.S.C. 103 as being unpatentable over Ren Wei (CN108768662A), and in view of Tong-yi ZHAO (CN113407912A ), hereinafter “ZHAO”.
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( equated to multi-signing).], 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(equated to ARK file with a APK Signing Block), 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. Step 5, if it is a signature operation, go to step 6, if it is a check operation, go to step 7; Step 6, according to the end block of the central directory record obtained in step 3, modify the comment segment size, and add a corresponding custom "ID-value" pair in the comment segment content, the ID is a custom ID, and the value is obtained in step 2. P7 signature block size, the unit32 value is used to identify the size, followed by the P7 signature data block; go to step 14], and [ see Figs 1-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 ARK 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… Step 8. In the presence of the v2 signature scheme, the APK adds an "APK signature block" to the standard ZIP format, and the end block of the central directory record obtained according to step 3 is recorded in the end block of the central directory record. Core Central Directory Offset can be found in APK Signing Block; 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].
While Wei discloses wherein the reconstructed APK file is a multi-signing file that formally includes one signing block as: [Page 2, last para.- Page 3 2nd, 3rd para. Step 8. In the presence of the v2 signature scheme, the APK adds an "APK signature block" to the standard ZIP format, and the end block of the central directory record obtained according to step 3 is recorded in the end block of the central directory record. Core Central Directory Offset can be found in APK Signing Block; Step 10, according to the APK Signing Block obtained in step 8, because the v2 signature adds verification to the integrity of the APK, but the verification content only includes three parts of Contents of ZIP entries, Central Directory, End of Central Directory and the APK Signing Block… Step 11, calculating a new core central directory offset according to the modified Signing APK Block in step 10, and modifying the core central directory offset recorded in the EOCD block to the latest latest partial offset according to the EOCD block obtained in step 3].
However, Wei does not explicitly disclose, and ZHAO discloses wherein the reconstructed APK file is a multi-signing file that formally includes one signing block as:
[ Pages 5-6, As shown in Figure 1, unlike the overall data structure of Android application native signature V1, V2/V3 adds APK Signature Block to the original mobile application data block to form a content block including ZIP roads. (Contents of ZIP Entries), APK Signature Block (APK Signature Block), ZIP Central Directory block (Central Directory), Central Directory end block (End of Central Directory) four-part data block, there is ID-VALUE pairing in the signature block the data structure of the ID 0x7109871a represents the V2 signature, and the ID 0xf05368c0 represents the V3 signature… This embodiment is based on the V2 signature block and realizes that multiple countersignatures can be added to the Android signature mechanism V2 version without affecting the original verification mechanism of the Android signature V2 version. It can be installed and upgraded normally and can Achieve countersignature effect.
PNG
media_image1.png
864
662
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 Wei by incorporating “computer information security technology and is used to provide a third-party countersignature signature”, as taught by ZHAO. One could have been motivated to do so in order for a countersignature is to attach a signature to a signed document as a recognition and certification of the signed document. Its purpose is to prove the data, actions or stipulations in the document that the signed person and the countersigner approve. [ ZHAO, see technical file and background technique of the application)].
Regarding claim 4, WEI discloses wherein the instructions that, when executed by the at least one processor, individually and/or collectively, is configured to cause the electronic device to: generate a new end of central directory comprising location information of the new central directory and include the new end of central directory in the reconstructed APK file [ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 5, WEI discloses wherein the instructions that, when executed by the at least one processor, individually and/or collectively, is configured to cause the electronic device to: determine the size and location of the new signing block to be added to the APK file according to the multi-signing [ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 6, WEI 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 [ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 7, WEI 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 [ 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 wherein the instructions that, when executed by the at least one processor, individually and/or collectively, is configured to cause the electronic device to: verify the disassembled APK file comprising the old contents of ZIP entries, the old central directory, and the old end of central directory based on the old signing block [ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 11, WEI 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[ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 12, WEI discloses wherein the old signing block is a block included in the disassembled APK file to ensure the integrity of the disassembled APK file and corresponds to a second signing key different from the first signing key [ Pages 2-3, steps 1-15, Page 4, steps 1-4].
Regarding claim 13, WEI discloses wherein the instructions that, when executed by the at least one processor, individually and/or collectively, is configured to cause the electronic device to: obtain the APK file by reassembling the disassembled APK file based on completion of the verifying the disassembled APK file and verifying that there are no other signing blocks in the disassembled APK file [ 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.
Second set of rejection:
Claims 1, 8, and 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 in view of Yang LU ( WO2021097704 A1), and further in view of LIU HAIHUA(CN109829285A ).
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,
[0002] The Android Application Market is publishing applications], and
[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).
[0041] the application market server 20 can post the final application in which the dual signature is performed to the market.
Seo does not explicitly disclose; however, LU discloses 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
[0081-0082, In the application, when the compressed package is an Android application package, the expected digest information of all the data blocks in the compressed package may be stored in the Android application package signature block (APK Signing Block), or the digest information block including the expected digest information of all the data blocks in the compressed package may also be generated, and then the digest information block is stored in the Android application package signature block, and the digest information block is an aggregate formed by the expected digest information of all the data blocks in the compressed package. 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].
PNG
media_image2.png
316
548
media_image2.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].
Seo , and LU do not explicitly disclose, however, LIU discloses:
reconstruct the APK file based on the new signing block by separating the signing block… wherein the reconstructed APK file is a multi-signing file that formally includes one signing block [Page 3, 2nd paragraph, Further, when the APK application does not use the V2 signature, the first magic number is used as the magic number of the signature block; when the APK application uses the V2 signature, the signature data is inserted into the original signature data, and then the second magic number is used as the magic number of the signature block.
[ Page 6, 4th paragraph, signature scheme of the present embodiment is directly compressed to the whole the APK file (i.e. the APK file has passed the Android signature in signature, according to V1 scheme or V2 scheme) for signature, the signature data generated is inserted into the compressed file content, between the source data and the directory source data APK in the signature block, and not to Android native effect.
[ Page 6, 6th paragraph, as shown in FIG. 5, a schematic diagram of a signature block format of a signature application in this embodiment includes two cases: a native signature is a V1 scheme, and a native signature is a V2 scheme.
1)Scene 1: The native signature is the V1 scheme.
The first is the 8-byte signature block size, which does not contain the 8 bytes of the field itself, and then is at least one signature data field (including an 8-byte ID-Value block size, a 4-byte ID number). And the corresponding signature data, the customized signature block ID is 0x78676432), then an 8-byte signature block size, which is equal to the first 8 bytes, and finally a fixed 16-byte signature block magic number. The magic number is: "XGD Sig Block 42".
2)Scene 2: The native signature is the V2 scheme.
The first is the 8-byte signature block size (this size does not contain the 8 bytes of the field itself), then the native signature data field of a V2 scheme (including an 8-byte ID-Value block size, a 4-byte) The native signature ID number and the corresponding signature data, the native signature ID number is 0x7109871a), followed by the signature data field as at least one of the scene one, followed by an 8-byte signature block size, and the first 8 bytes. Is equal, and finally is a fixed 16-byte signature block magic number, the magic number in this scene is: "APK Sig Block 42".
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 LU by incorporating “implement signature scheme V2 in APK applications;”, as taught by LU. One could have been motivated to do so in order for improving authority efficiency and solve Janus vulnerability existed in the V1 solution of. [ LIU, see background technology section].
Regarding claim 8, this claim is interpreted and rejected for the same rational set forth in claim 1.
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_image3.png
76
574
media_image3.png
Greyscale
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
Prosecution Insights