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 .
Response to Amendment
The amendment filed on November 5, 2025 cancelled no claims. Claims 1, 5-6, 8, 12-13, 15, and 19 were amended and no new claims were added. Thus, the currently pending claims addressed below are claims 1-20.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shen (CN108829405A) in view of Xu et al. (PGPUB: 2019/0245870) in view of Fadeev (Frida’s Gadget Injection on Android: No Root, 2 Methods, March 24, 2020, https:// fadeevab.com/frida-gadget-injection-on-android-no-root-2-methods/, pgs. 1-20).
Claims 1, 7-8, 14-15 and 20: Shen discloses a method, an apparatus, and a non-transitory computer-readable storage medium implemented by a data processing apparatus comprising:
one or more processors; a memory coupled to the one or more processors; a communication interface coupled to the processor; and configured to store instructions that, when executed by the one or more processors (Shen - Page 2, line 26 through Page 3, line 8), perform the steps of:
obtaining, from a user through a communication interface coupled to the processor, a first Android package (APK) of a software application used to present media data (Shen - Page 2, lines 26-30: obtaining a second APK, wherein the second APK is used for providing an external interface of a target application; Page 4, lines 10-11: abbreviation APK, is the application installation package (such as Android Package));
encapsulating an advertisement software development kit (SDK) into a second APK of an advertisement carrier application (Shen - Page 2, lines 26-30: obtaining a first APK, wherein the first APK comprises a channel SDK; Page 5, lines 21-22: the first APK can be generated to encapsulate an SDK);
Shen does not specifically disclose that the encapsulated SDK is an advertisement SDK.
However, the analogous art of Xu discloses that it is well known to encapsulate an advertisement SDK into a second APK of an advertisement carrier application in at least paragraph 25.
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the invention, to modify Shen for use with an advertisement SDK as disclosed by Xu.
The rationale for doing so is that merely requires the simple substitution of one known element for another to obtain predictable results. Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests non on any individual element or function but in the very combination itself – that is in the substitution of the advertisement SDK of the Xu reference for the channel SDK of Shen. Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
unpacking the first APK to obtain first APK directory information (Shen - Page 2, lines 26-30: decompiling the second APK; Page 8, lines 27 – Page 9, line 3 and Figures 10-12: decompiling the first APK results in first APK directory information);
wherein unpacking the first APK comprises unpacking the first APK through an Android package packing tool (apktool) to obtain the first APK directory information (Shen - Page 9, lines 4-6: decompilation of the first APK performed using apktool);
unpacking the second APK to obtain second APK directory information (Shen - Page 2, lines 26-30: decompiling the first APK; Page 8, lines 27 – Page 9, line 3 and Figures 10-12: decompiling the second APK results in second APK directory information)
wherein unpacking the second APK comprises unpacking the second APK through the apktool to obtain the second APK directory information (Shen - Page 9, lines 4-6: decompilation of the second APK performed using apktool);
searching for a specified location in the first APK directory information to insert a preset advertisement code into a specified location of the first APK directory information in an automatic manner.
While Shen and Xu disclose encapsulating the advertisement software development kit (SDK) into a second APK of an advertisement carrier application, Shen and Xu do not disclose searching for a specified location in the first APK directory information to insert a preset advertisement code into a specified location of the first APK directory information.
However, the analogous art of Fadeev discloses that it is known to locate a specified location in the first APK directory information to inserting preset code to execute an entry calling class of an SDK (e.g., the advertisement software development kit (SDK)) into a specified location of the first APK directory information and inserting, before merging the second APK directory information into the first APK directory information, the preset code of the entry calling class into said specified location of the first APK directory information, wherein the specified location is a bytecode smali file corresponding to a startup activity class in at least Page 9, line 11 through Page 13, line 10..
It would have been obvious to one or ordinary skill in the art, before the effective filing date of the invention, to modify the invention of Shen and Xu to include searching for a specified location in the first APK directory information to insert a preset advertisement code into a specified location of the first APK directory information and inserting, before merging the second APK directory information into the first APK directory information, the preset code of the entry calling class into a specified location of the first APK directory information, wherein the specified location is a bytecode smali file corresponding to a startup activity class as disclosed by Fadeev.
The rationale for doing so is that it would be obvious to try as in order to execute the encapsulated SDK a preset code to initiate the execution must be placed in the First APK and there are a limited number of predictable locations in which the preset code to execute the advertisement SDK can be placed that would likely result in the execution of said code, and the Activity class of the smali file is one such predictable location.
While the claim limitation has been amended to indicate that searching for a specified location in the first APK directory information to insert a preset advertisement code into a specified location of the first APK directory information is performed “in an automatic manner” and the combination of Shen , Xu, and Fadeev disclose searching for a specified location in the first APK directory information to insert a preset advertisement code into a specified location of the first APK directory information manually, broadly claiming an automatic means to replace the manual activity taught by the combination of Shen , Xu, and Fadeev which accomplished the same result is not sufficient to distinguish over the prior art of Shen, Xu, and Fadeev (see MPEP 2144.04(III).
merging the second APK directory information into the first APK directory information to obtain third APK directory information comprises: determining a value range of a first resource identifier (ID) within the first APK directory information when a first value of the first resource ID matches a second value of a second resource ID within the second APK directory information; copying the second resource ID into the first APK directory information; adjusting the second value of copied second resource ID based on the value range to obtain an adjusted value of the second resource ID; and assigning, for each i-th resource ID of the second APK directory information, the adjusted value to be a sum of a maximum value within the value range and i, wherein i sequentially represents each positive integer from 1 to n, and wherein n is a quantity of resource IDs in the second APK directory information (Shen - Page 2, lines 26-30: merging the decompiled first APK and second APK to generate the channel package of the target application; Page 9, lines 7-12 and Figure 12: combining the first APK directory information and the second APK directory to obtain a third APK directory information; and Page 9, line 1 – Page 10, line 2: each index must correspond to one resource, so when combining the APKs, each of the plurality of resource IDs that are the same are recalculated by incrementing by 1 until all resource values are unique; Examiner note: Since each index must correspond to one resource, incrementing the first resource until it finds achieves a unique resource value mean the values for original resource ID are traversed until an empty resource value is found, thus Shen discloses making a determination regarding the value range of the first resource identifier (original resource value to max resource value); Shen then teaches the second resource ID is assigned the empty resource value. Doing this for all resource values means that the i-th value resource is added to the next empty resource value which is means that for each i-th resource ID of the second APK directory information, the adjusted value is a sum of a maximum value within the value range and i. As such, the cited disclosure of Shen discloses the limitations of the claim, as currently amended, with regards to merging); and
encapsulating the third APK directory information into the first APK. (Shen - Page 2, lines 26-30: generate the channel package of the target application; Page 5, lines 10-22: the game provides the master package APK, then the game master package APK and the channel APK are unlocked according to the APK format and the file structure of the files in the APK by using the method, then the two parts of files after unlocking are merged, and then the files are repackaged back again according to the structure of the APK files, so that the real channel package can be output; Page 10, lines 19-23: recompiling, signing, and aligning to obtain the final channel packets for the user to download)
Claims 2-3, 9-10 and 16-17: Shen, Xu and Fadeev disclose the method according to claim 1, the apparatus according to claim 8, and the non-transitory computer-readable storage medium according to claim 15, wherein encapsulating the advertisement SDK into the second APK comprises:
encapsulating the advertisement SDK and an entry calling class of the advertisement SDK into the second APK (Shen - Page 2, lines 26-30: obtaining a first APK, wherein the first APK comprises a channel SDK; Page 5, lines 21-22: the first APK can be generated to encapsulate/package an SDK; Page 6, lines 11-25: packaging all classes, which includes an entry calling class, from the first APK and the SDK into the first; APK; Page 8, line 1 – Page 10, line 26: describes how the various directories are combined including the class name file in the smali directory); and
inserting, before merging the second APK directory information into the first APK directory information, the preset advertisement code of the entry calling class into the specified location of the first APK directory information, wherein the specified location is a bytecode smali file corresponding to a startup activity class, and wherein the preset advertisement code is inserted into the first APK directory information without user interaction. (Fadeev - Page 9, line 11 through Page 13, line 10).
Shen, Xu, and Fadeev disclose inserting, before merging the second APK directory information into the first APK directory information, the preset advertisement code of the entry calling class into the specified location of the first APK directory information, wherein the specified location is a bytecode smali file corresponding to a startup activity class, and wherein the preset advertisement code is inserted into the first APK directory information in at least Fadeev, page 9, line 11 through page 13, line 10.
Shen, Xu, and Fadeev do not disclose that the preset advertisement code is inserted into the first APK directory information is done in an automated fashion such that it is performed without user interaction.
It would have been obvious to one of ordinary skill in the art, before the effective filing, to modify the invention of Shen, Xu, and Fadeev such that the preset advertisement code is inserted into the first APK directory information is performed in an automated fashion such that it is performed without user interaction.
The rationale for doing so is that it would be obvious to try as it merely requires the automating of a manual process already taught by Sen, Xu, and Fadeev as currently combined.
Claims 4, 11, and 18: Shen, Xu, and Fadeev disclose the method according to claim 2, the apparatus according to claim 9, and the non-transitory computer-readable storage medium according to claim 16, wherein merging the second APK directory information into the first APK directory information comprises merging, in the first APK directory information and the second APK directory information, an Android package list (AndroidManfifest.xml) file, an image resource, a layout file, a character string, or a resource identifier (ID). (Shen - Page 2, lines 26-30: merging the decompiled first APK and second APK to generate the channel package of the target application; Page 9, lines 7-12 and Figure 12: combining the first APK directory information and the second APK directory to obtain a third APK directory information that includes at least a merged Android package list (AndroidManifest.xml))
Claims 5, 12, and 19: Shen, Xu, and Fadeev disclose the method according to claim 4, the apparatus according to claim 11, and the non-transitory computer-readable storage medium according to claim 18, wherein the first value is different from the adjusted value. (Shen – Page 9, line 1 – Page 10, line 2: each index must correspond to one resource, so when combining the APKs, each of the plurality of resource IDs that are the same are recalculated by incrementing by 1 until all resource values are unique)
Claims 6 and 13: Shen, Xu, and Fadeev disclose the method according to claim 5 and the apparatus of claim 12, wherein the value range is from 0 to 50 (Shen – Page 9, line 1 – Page 10, line 2: each index must correspond to one resource, so when combining the APKs, each of the plurality of resource IDs that are the same are recalculated by incrementing by 1 until all resource values are unique; Examiner note: The disclosure of Shen discloses that this process for each resource value, thus it discloses performing the incrementing when there is one resource already assigned to value 0, when there are 51 previously assigned resource values from 0 to 50, and when there are 1,000,000 resource values previously assigned resource values from 0 to 999,999. Furthermore, it would appear that whether or not the value range of the first resource identifier with the first APK directory information is between 0 and 50 is a matter of information contained within the unpacked first APK which is obtained by the applicant’s invention from a user. Thus, the applicant’s invention did not limit the value range from 0 to 50, instead the applicant’s invention is assuming that the user the provided the first APK limited said value range to be from 0-50. Making the same assumption, when the invention of Shen, Xu, and Fadeev receives a first APK from a user and performs the marching steps disclosed in Shen – Page 9, line 1 – Page 10, line 2, then the determined value range of Shen, Xu, and Fadeev is from 0-50)
Response to Arguments
Applicant's arguments filed November 5, 2025 have been fully considered but they are not persuasive.
In regards to the 35 USC 103 rejection, the applicant argues that Shen, Xu, and Fadeev fail to disclose the newly added limitation of “assigning, for each i-th resource ID of the second APK directory information, the adjusted value to be a sum of a maximum value within the value range and i, wherein i sequentially represents each positive integer from 1 to n, and wherein n is a quantity of resource IDs in the second APK directory information”. The examiner disagrees. Shen clearly discloses, on page 9, line 1 through page 10, line 2, each index must correspond to one resource, so when combining the APKs, each of the plurality of resource IDs that are the same are recalculated by incrementing by 1 until all resource values are unique. So how is this reassigning being performed. Assuming that the first APK had three resources, then each resource was assigned a resource ID value between the ranges of 0 and 2, such as resource 1 ID = 0, resource 2 ID = 1, and resource 3 ID = 2. Assuming the second APK also had 3 resources. Given that resource IDs 0 through 2 are already in use, the first resource ID of the second APK would be assigned a resource ID =3 (e.g., 2+1), the second resource ID of the second APK would be assigned resource ID=4 (e.g., 2 +2), and the third resource ID of the second APK would be assigned resource ID=5 (e.g., 2+3). As such, each i-th resource of the second APK is assigned an adjusted value that is the sum of maximum value of the original resource IDs and i. Thus, it is clear that the process described by Shen teaches the argued limitation in the argued limitation. Hence, the limitations of the claims, as currently amended, are taught by the prior art of Shen, Xu, and Fadeev and the rejection has been maintained.
In regards to the 35 USC 103 rejection, the applicant argues that Shen, Xu, and Fadeev fail to disclose the newly added limitation of determining a value range of the first APK or a maximum value within that range. The examiner disagrees. Shen clearly discloses, on page 9, line 1 through page 10, line 2, each index must correspond to one resource, so when combining the APKs, each of the plurality of resource IDs that are the same are recalculated by incrementing by 1 until all resource values are unique. Thus, by progressing from the first resource ID in the first APK to the last resource ID in the first APK before assigning the first resource ID in the second APK to a new resource ID, Shen is absolutely disclosing determining a value range of the first APK and determining a maximum value within that range. Thus, it is clear that the prior art of Shen discloses the argued limitations. Hence, the limitations of the claims, as currently amended, are taught by the prior art of Shen, Xu, and Fadeev and the rejection has been maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jin (CN109522030A) which discloses using the apktool to unpack an application and encapsulate a channel SDK into one of the unpacked applications, by unpacking the classes.dex into a smali file then merging SDK manifest file into an AndroidManifest.xml, and repackaging the application.
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 JOHN W VAN BRAMER whose telephone number is (571)272-8198. The examiner can normally be reached Monday-Thursday 5:30 am - 4 pm EST.
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, Spar Ilana can be reached on 571-270-7537. 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.
/John Van Bramer/Primary Examiner, Art Unit 3622
Prosecution Insights