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 .
DETAILED ACTION
This action is in response to the communication filed on 03/28/2024.
Claims 1-20 are pending and addressed in the Action.
Claim Objections
Claims 6-7, 13-14, and 20 are objected to because the claims recited the limitations “invoking a second preset code resource attribute analysis algorithm” without a predefining “first preset code” in the preceding claims. For example,
Claims 6-7, where claim 6 is depends on claim 1 and it recites the limitation "invoking a second preset code" in “invoking a second preset code resource attribute analysis algorithm”. Claim 6 should be amended to depend on claim 4 since claim 4 recites “prior to generating a Dex file based on the code resource file, invoking a first preset code resource attribute analysis algorithm;” .
Claims 13-14, where claim 13 is depends on claim 8, and it recites the limitation "invoking a second preset code" in “invoking a second preset code resource attribute analysis algorithm”. Claim 13 should be amended to depend on claim 11 which is recited with the “first preset code…”.
Claim 20 is depends on claim 15, and it recites the limitation "invoking a second preset code" in “invoking a second preset code resource attribute analysis algorithm”. Claim 20 should be amended to depend on claim 18.
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, 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 1-2, 4, 6, 8-9, 11, 13, 15-16, 18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Android Developers, “Create an Android library”, 2022, retrieved from https://developer.android.com/studio/projects/android-library, 11 pages, in view of Artyom, “[AAR to DEX] Loading and Running Code at Runtime in Android Application”, 2019, Medium, https://medium.com/ , 8 pages.
As per Claim 1: Android Developers discloses the limitations in bold below:
1. A method for application package generation comprising:
acquiring a code resource file of a target application, and [parsing attribute information] of a code resource in each class file in the code resource file;
(See in p. 1: in sec. Create a library module , esp., item “3. Give your library a name and select a minimum SDK version for the code in the library, then click Finish.”, reads on acquiring…
See in p. 8: in sec. Choose resources to make public , “All resources in a library default to public. To make all resources implicitly private, you must define at least one specific attribute as public. Resources include all files in your project’s res/ directory, such as images..” (emphasis added: project: reads a target application) , and
“The following example code creates two public string resources with the
names mylib_app_name and mylib_public_string:
<resources>
<public name="mylib_app_name" type="string"/>
<public name="mylib_public_string" type="string"/>
</resources>”
Then, the above reads the ‘code resource file’ of a project : ‘target application’
mylib_app_name and mylib_public_string are attribute values identified accordingly by the attribute “name” for JAR file or AAR file. Thus, these values are classes in the JAR/AAR.
For “mylib_app_name”, it responds to library modules referred to first bullet in p. 1:
“. AAR files can contain Android resources and a manifest file, which allows you to
bundle in shared resources like layouts and drawables in addition to Java classes and methods.”).
With shared resources and Java classes are used to bundle in the project , Android Developers do not explicitly address parsing attribute information.
Android Developers further disclose,
distributing each class file into a corresponding sub-code resource package in accordance with the attribute information; and
(See in pages 6 to 8, in sec. Add your AAR or JAR as a dependency, with selecting “Jar Dependency” and in item 3, referred to “Add Jar/Aar Dependency dialog, first enter the path to your .aar or .jar file,” – the action Add Jar/Aar Dependency reads sub-code resource package, in accordance to the example code <resource> that creates the lib application in p. 8 ).
generating, based on each sub-code resource package (i.e. aar or jar dependency selected from Module Dependency in the dropdown as in the Figure in p. 3 or the Figure in p. 5 ), a target application package in a target format; wherein the code resource file of the target application is an AAR file of the target application.
(See in p.11, sec. Anatomy of an AAR file, “The file extension for an AAR file is .aar, and the Maven artifact type should be aar as well. The file itself is a zip file. The only mandatory entry is /AndroidManifest.xml.”. Thus the target format: aar, zip file, or xml)
Android Developers do not explicitly mention “parsing attribute information”.
Artyom discloses the limitation of “parsing attribute information” (See Artyom: The flow chart on the top in p. 1, where .java file compiled into class file in bundled in bin/classes, and second para. in heading The difference between JAR and AAR, “During the build, an R.java file is generated for each android library and for the main project of course, and all java files are compiled to a one or multiple DEX files (DEX is a Dalvik executable format which can be loaded by android runtime (ART) )……. Android R.java file is an autogenerated file by AAPT (Android Asset Packaging Tool) that contains resource IDs for all the resources of res/ directory.” , and
in p. 4, in the top portion “…So the solution to this problem is to manulay create a R.java file which will delegate all resources ids to the R file with the app package name and compile that R file and put it in jar file which can be done with jar -ufv option. And now imagine that an update for this library is released.” ) (emphasis added).
Thus, incorporating with the flow chart in p. 1, the reference addresses the resource code r.java are parsed, and compiling in .java is parsing information in resource r.java to for converting into package file in res/ directory .
It should be noted that it is well-known in Java for compiling a .java file involved in parsing it. The parse process includes analyzing attributes, annotations, and the overall syntax.
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to combing parsing attribute information of r.java/ java class in a compile process in an Android application of Artyom with the teaching for obtaining resources for developing Android project of Android Developers. The combination would yield predictable results because Java classes and resources are Android codebase and in Android developing, parsing in class files is a formal and necessary step in compilation for obtaining information for package generation.
As per Claim 2: Android Developers and combining Artyom, where
Artyom discloses,
2. The method of claim 1, wherein parsing the attribute information of the code resource in each class file in the code resource file includes:
extracting information indicating a class file dependency in a bytecode content of each class file as the attribute information (referred to compile to .class shown in flow chart in p. 1).
(See Artyom, the flow chart in p. 1, and referred to .class file: the .class file is known containing bytecode, and see heading JAR to DEX in p. 3, “The DEX file is generated and there is no need to build the android project with that JAR library, so in gradle dependancies section..” (*) ,
and heading AAR to DEX , “…So the right thing to do is to merge that resources with the main project resources and change that dependency to be a provided dependency and convert the JAR file to DEX
file.”(**))
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to combing parsing attribute information of r.java/ java class in a compile process and handle dependencies in an Android application of Artyom with the teaching for obtaining resources for developing Android project of Android Developers. The combination would yield predictable results because Java classes and resources are Android codebase and compiling to class files with indicated dependencies is a formal and necessary step for obtaining information for package generation.
As per Claim 4: Android Developers and combining Artyom, where
Artyom discloses,
4. The method of claim 1, wherein parsing the attribute information of the code resource in each class file in the code resource file includes:
prior to generating a Dex file based on the code resource file, invoking a first preset code resource attribute analysis algorithm (Artyom: See the flow chart in p. 1, the process of Dexing before forming .dex, and in bin/class, a .class dexing to .dex reads on invoking a first preset code resource attribute analysis algorithm ); and
obtaining the attribute information by analyzing a dependency of a code resource of each class file in a Jar file of a base resource package in the code resource file through the first preset code resource attribute analysis algorithm (See flow chart in p. 1, referred to .JAR as set of .class in bin/classes. It should be noted JAR is an archive file that contain .class files. See heading JAR To DEX in p. 3. “Android does not support loading JAR file, so there must be a way to compile the JAR file to DEX file”, and (*) and (**) in claim 2).
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing of the application to combing parsing attribute information of r.java/ java class in a compile process and handle dependencies before to DEX of Artyom with the teaching for obtaining resources for developing Android project of Android Developers. The combination would yield predictable results because of conforming to JAR to DEX process requirement.
As per Claim 6: Regarding,
6. The method of claim 1, wherein parsing the attribute information of the code resource in each class file in the code resource file includes:
in a process of generating a Dex file based on the code resource file, invoking a second preset code resource attribute analysis algorithm; and
obtaining the attribute information by analyzing a dependency of a code resource of each class file in an initial Dex file corresponding to the code resource file through the second preset code resource attribute analysis algorithm.
(Claim addresses the limitation “a second preset code resource attribute analysis algorithm” with the functionality of the claim having the same as the first preset code of claim 4.)
The rejection of claim has been addressed in same manner as in claim 4.
As per claims 8, 9, 11, 13: The claims are directed to a device and recite the limitations having functionality corresponding to the method of claims 1-2, 4, 6 above. The claims are rejected with the same rationales addressed in claims 1-2, 4, 6.
As per claims 15, 16, 18, 20: The claims are directed to a non-transitory machine-readable storage medium and recite the limitations having functionality corresponding to the method of claims 1-2, 4, 6 above. The claims are rejected with the same rationales addressed in claims 1-2, 4, 6.
Allowable Subject Matter
Claims 3, 5, 10, 12, 17, 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claims 7, 14 are also being objected to but the claims would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims that are clear from any objection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ted T Vo whose telephone number is (571)272-3706. The examiner can normally be reached 8am-4:30pm ET.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
TTV
February 18, 2026
/Ted T. Vo/
Primary Examiner, Art Unit 2191