SOFTWARE ELIGIBILITY

§101 §103 §112

DETAILED ACTION This action is in response to the claims filed May 29, 2025. Claims 16-18 and 20-31 are pending. Claims 16, 27, and 31 are independent claims. Claims 16, 22, 25, 27, 29, and 31 have been amended. Claim 19 has been cancelled. The objection to claim 25 is withdrawn in view of Applicant’s amendments to the claims. The rejection of the claims under 35 U.S.C. 101 for being directed to an abstract idea is maintained in view of Applicant’s arguments and amendments to the claims. The rejection of the claims under 35 U.S.C. 101 for being directed to non-statutory subject matter is withdrawn in view of Applicant’s arguments and amendments to the claims. 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 . Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim 28 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 28 recites “System arrangement according to claim 27” on line 1. Specifically, in regard to “System arrangement”, it is unclear whether the system arrangement refers to the system arrangement of claim 27 or to a different system arrangement. For the purposes of examination, the “system arrangement is interpreted to belong to refer to the system arrangement of claim 27, and the claim is interpreted to read “The system arrangement according to claim 27”. Claim 28 recites “wherein the detection entity preferably is realized by a detection software installed on the end device”. Specifically, in regard to “preferably”, it is unclear whether the detection entity should be realized by the detection entity. For the purposes of examination, the claim is interpreted without the “preferably” and is interpreted to read “wherein the detection entity is realized by a detection software installed on the end device”. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 16-18 and 20-31 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Regarding claim 16, the limitations “creating a requirements specification by evaluating a new piece of software regarding deployment requirements of the end device”, “detecting actual deployment requirements on the end device and comparing the transmitted requirements specification with the detected actual deployment requirements”, “…if it is determined that the requirement specification complies with the actual deployment requirements”, “creating the requirements specification comprises determining information about capabilities the new piece of software provides to the upper software layer and/or about requirements of the new piece of software for the lower software layer” and “detecting the actual deployment requirements comprises determining information about capabilities the lower software layer provides to the new piece of software and/or about requirements of the upper software layer for the new piece of software” as drafted, are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. The limitation encompasses a human mind carrying out the function through observation, evaluation, judgement, and/or opinion, or even with the aid of pen and paper. Thus, this limitation falls within the “Mental Processes” grouping of abstract ideas under Prong 1. Under Prong 2, this judicial exception is not integrated into a practical application. The additional limitations “A computer-implemented method for ensuring eligibility of a piece of software to be installed on an end device, the method being implemented automatically by a processor of the end device” and “wherein a software currently installed on the end device comprises and upper software layer and a lower software layer, the upper software layer requiring the new piece of software for operation” are recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception using a generic computer component, and/or mere computer components. See MPEP 2106.05(f). The additional limitation “deploying the new piece of software on the end device…” fails to meaningfully limit the claim because it does not require any particular application of the recited “deploying”, and is at best, the equivalent of merely adding the words “apply it” to the judicial exception. See MPEP 2106.05(f). The additional limitations “transmitting said requirements specification to the end device” and “wherein the transmitting said requirements specification is performed along with transmitting the new piece of software to the end device” does nothing more than add the insignificant extra solution activity of merely gathering and transmitting data to the judicial exception. See 2106.05(g). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the limitations “A computer-implemented method for ensuring eligibility of a piece of software to be installed on an end device, the method being implemented automatically by a processor of the end device” and “wherein a software currently installed on the end device comprises and upper software layer and a lower software layer, the upper layer requiring the new piece of software for operation” amount to no more than mere instructions, or generic computer/computer components to carry out the exception. Furthermore, the limitation “deploying the new piece of software on the end device…” does not require any particular application of the recited evaluation and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Mere instruction to apply an exception cannot provide an inventive concept. See MPEP 2106.05(d). For the limitations “transmitting said requirements specification to the end device” and “wherein the transmitting said requirements specification is performed along with transmitting the new piece of software to the end device”, the courts have identified mere data gathering and transmitting as well-understood, routine, and conventional activity. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 U.S.C. §101. Regarding claim 17, the limitations “creating the requirements specification comprises determining information about capabilities the new piece of software provides to the end device and/or about requirements of the new piece of software for the end device” and “detecting the actual deployment requirements comprises determining information about capabilities the end device provides to the new piece of software and/or about requirements of the end device for the new piece of software” are additional mental steps. Claim 17 does not recite additional limitations which may integrate the judicial exception into a practical application, or amount to significantly more. Claim 18 does not recite any additional mental processes. Under Prong 2, the limitation “wherein creating the requirements specification comprises providing information about the new piece of software, and/or regarding Java Card packages if the new piece of software relates to a Java Card operating system, and/or a version of the new piece of software, or a memory requirement, and/or a memory map, and/or a data format version, and/or a hardware information1 and/or deployment information” amounts to the insignificant extra solution activity of mere data gathering and transmission, which does not amount to practical application, nor amount to significantly more under Step 2B as explained above. Claim 20 does not recite any additional mental processes. The limitation “wherein the actual deployment requirements are detected by a detection software installed on the end device” merely describes in generic terms the intended function of a “detection software” and thus is considered to merely apply the abstract idea using a generic computer/computer component which is neither a practical application under Prong 2, nor amounts to significantly more under Step 2B. The limitation “wherein, the detection software is integrated into an operating system of the end device” merely indicates a technological environment (preferably on an operating system) in which to apply a judicial exception, which does not amount to practical application under Prong 2, nor amount to significantly more under Step 2B. See MPEP 2106.05(h). Claim 21 does not recite any additional mental processes under Prong 1. Under Prong 2, the limitation “wherein deploying the new piece of software comprises unpacking an image file of the new piece of software, checking its integrity, amending currently installed software components, updating currently installed software components, exchanging currently installed software components, deleting currently installed software components, and/or installing the new piece of software on the end device” merely defines “deploying the new piece of software” recited in claim 16, thus amounting to merely applying the abstract idea, which is neither a practical application under Prong 2, nor amounts to significantly more under step 2B. Claim 22 merely further describes the “requirements specification” and “actual deployment requirements” of claim 16, thus amounts to merely describing the mental process. Claim 22 does not recite additional limitations which may integrate the judicial exception into a practical application, or amount to significantly more. Regarding claim 23, the limitation “wherein compliance of the requirements specification with the actual deployment requirements is determined by evaluating a table indicating compatibility information” is an additional mental step. Claim 23 does not recite additional limitations which may integrate the judicial exception into a practical application, or amount to significantly more. Claim 24 does not contain additional mental processes. The limitation “wherein the method is terminated when the requirements specification does not comply with the actual deployment requirements” amounts to merely applying the abstract idea, which is neither a practical application under Prong 2, nor amounts to significantly more under step 2B. Claim 25 merely further describes the generic computer component of “end device” in claim 16, which is neither a practical application under Prong 2, nor amounts to significantly more under step 2B. Claim 26 does not recite additional mental steps. The limitation “wherein a new operating system or operating system image is installed on the end device as the new piece of software” merely describes the “new piece of software” of claim 16 which does not integrate the judicial exception into a practical application, or amount to significantly more. Regarding claim 27, the limitations “an entity arranged to create a requirements specification by evaluating a new piece of software regarding deployment requirements of the end device”, “a detection entity being arranged to detect actual deployment requirements on the end device and compare the transmitted requirements specification with the detected actual deployment requirements”, “…if it is determined that the requirement specification complies with the actual deployment requirements”, “the entity being arranged to create a requirements specification is configured to determine information about capabilities the new piece of software provides to the upper software layer and/or about requirements of the new piece of software for the lower software layer” and “the detection entity is configured to determine, information about capabilities the lower software layer provides to the new piece of software and/or about requirements of the upper software layer for the new piece of software” as drafted, are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. The limitation encompasses a human mind carrying out the function through observation, evaluation, judgement, and/or opinion, or even with the aid of pen and paper. Thus, this limitation falls within the “Mental Processes” grouping of abstract ideas under Prong 1. Under Prong 2, this judicial exception is not integrated into a practical application. The additional limitations “A system arrangement for ensuring eligibility of a piece of software to be installed on an end device, the system arrangement being implemented automatically by a processor of the end device”, “wherein a software currently installed on the end device comprises and upper software layer and a lower software layer, the upper software layer requiring the new piece of software for operation”, “an entity”, “an interface entity”, “a detection entity”, and “a deployment entity” are recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception using a generic computer component, and/or mere computer components. See MPEP 2106.05(f). The additional limitation “deploy the new piece of software on the end device…” fails to meaningfully limit the claim because it does not require any particular application of the recited “deploy”, and is at best, the equivalent of merely adding the words “apply it” to the judicial exception. See MPEP 2106.05(f). The additional limitation “an interface entity being arranged to transmit said requirements specification to the end device along with transmitting the new piece of software to the end device” does nothing more than add the insignificant extra solution activity of merely gathering and transmitting data to the judicial exception. See 2106.05(g). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the limitations “A system arrangement for ensuring eligibility of a piece of software to be installed on an end device, the system arrangement being implemented automatically by a processor of the end device”, “wherein a software currently installed on the end device comprises and upper software layer and a lower software layer, the upper software layer requiring the new piece of software for operation”, “an entity”, “an interface entity”, “a detection entity”, and “a deployment entity” amount to no more than mere instructions, or generic computer/computer components to carry out the exception. Furthermore, the limitation “deploy the new piece of software on the end device…” does not require any particular application of the recited evaluation and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Mere instruction to apply an exception cannot provide an inventive concept. See MPEP 2106.05(d). For the limitation “an interface entity being arranged to transmit said requirements specification to the end device along with transmitting the new piece of software to the end device”, the courts have identified mere data gathering and transmitting as well-understood, routine, and conventional activity. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 U.S.C. §101. Claim 28 does not recite any additional mental processes. The limitation “wherein the entities of the systems arrangement are realized by one or more computer program products, wherein the detection entity preferably is realized by a detection software installed on the end device” merely describes in generic terms the intended function of a “computer program product” and “a detection software” and thus are considered to merely apply the abstract idea using a generic computer/computer component which is neither a practical application under Prong 2, nor amounts to significantly more under Step 2B. Claim 29 does not recite any additional mental processes. The limitation “A non-transitory computer-readable memory comprising instructions that, when executed by a processor of the end device, cause the processor to automatically detect actual deployment requirements on an end device as the detection step of a method according to claim 16” merely describes in generic terms the intended function of a “non-transitory computer-readable memory” and “processor” and thus is considered to merely apply the abstract idea using a generic computer/computer component which is neither a practical application under Prong 2, nor amounts to significantly more under Step 2B. Regarding claim 30, the limitation “wherein said detecting actual deployment requirements on the end device and comparing the transmitted requirements specification with the detected actual deployment requirements are performed in real-time” merely further describes the mental step of claim 16, and thus is considered a mental step. Regarding claim 31, the limitations “creating a requirements specification by evaluating a new piece of software regarding deployment requirements of the end device”, “detecting actual deployment requirements on the end device and comparing the transmitted requirements specification with the detected actual deployment requirements automatically in real-time…”, “…if it is determined that the requirement specification complies with the actual deployment requirements”, “creating the requirements specification comprises determining information about capabilities the new piece of software provides to the upper software layer and about requirements of the new piece of software for the lower software layer” and “detecting the actual deployment requirements comprises determining information about capabilities the lower software layer provides to the new piece of software and about requirements of the upper software layer for the new piece of software” as drafted, are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. The limitation encompasses a human mind carrying out the function through observation, evaluation, judgement, and/or opinion, or even with the aid of pen and paper. Thus, this limitation falls within the “Mental Processes” grouping of abstract ideas under Prong 1. Under Prong 2, this judicial exception is not integrated into a practical application. The additional limitations “A computer-implemented method for ensuring eligibility of a piece of software to be installed on an end device, the method being implemented automatically by a processor of the end device”, “…by the processor” and “wherein a software currently installed on the end device comprises and upper software layer and a lower software layer” are recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception using a generic computer component, and/or mere computer components. See MPEP 2106.05(f). The additional limitation “deploying the new piece of software on the end device…” fails to meaningfully limit the claim because it does not require any particular application of the recited “deploying”, and is at best, the equivalent of merely adding the words “apply it” to the judicial exception. See MPEP 2106.05(f). The additional limitation “transmitting said requirements specification to the end device” does nothing more than add the insignificant extra solution activity of merely gathering and transmitting data to the judicial exception. See 2106.05(g). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the limitations “A computer-implemented method for ensuring eligibility of a piece of software to be installed on an end device, the method being implemented automatically by a processor of the end device”, “…by the processor”, and “wherein a software currently installed on the end device comprises and upper software layer and a lower software layer” amount to no more than mere instructions, or generic computer/computer components to carry out the exception. Furthermore, the limitation “deploying the new piece of software on the end device…” does not require any particular application of the recited evaluation and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Mere instruction to apply an exception cannot provide an inventive concept. See MPEP 2106.05(d). For the limitation “transmitting said requirements specification to the end device”, the courts have identified mere data gathering and transmitting as well-understood, routine, and conventional activity. See MPEP 2106.05(d). Accordingly, the claims are not patent eligible under 35 U.S.C. §101. 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 16-18 and 20-30 are rejected under 35 U.S.C. 103 as being unpatentable over US 20160162275 A1 (hereinafter “Morley”) in view of US 20110225575 A2 (hereinafter “Ningombam”). Regarding claim 16, Morley discloses: A computer-implemented method for ensuring eligibility of a piece of software to be installed on an end device, the method being implemented automatically by a processor of the end device and comprising the steps (Paragraph [0022], “Mobile device 15 also has an App Checker module 17 installed and executes the App Checker module 17 during software platform upgrades. The applications 16A-N and App Checker module 17 are typically installed as applications after being downloaded from the App Store Server 40”; Paragraph [0024], “ App Checker module 17 pings or queries the Update Server 35 and requests whether a platform update is available. When a platform update is available, App Checker module 17 determines whether each of the applications 16A-N installed on mobile device 15 that are not preloaded software and not part of the software platform itself are compatible with the target platform version that is available in the update”) [Examiner’s remarks: The steps for ensuring eligibility of software is performed in an automated fashion using App Checker which is installed on the mobile device (end device).]: creating a requirements specification by evaluating a new piece of software regarding deployment requirements of the end device (Paragraph [0040], “App Checker module 17 then issues a service request via an API call to the App Store Server 40 requesting the application catalog of compatible applications for the target platform version [creating a requirements specification by evaluating a new piece of software regarding deployment requirements of the end device]”) [Examiner’s remarks: A catalog is created based on evaluation of whether applications on an end device are compatible with a given platform number.]; transmitting said requirements specification to the end device (Paragraph [0040], “App Checker module 17 then issues a service request via an API call to the App Store Server 40 requesting the application a catalog of compatible applications for the target platform version [transmitting said requirements specification to the end device]”); detecting actual deployment requirements on the end device and comparing the transmitted requirements specification with the detected actual deployment requirements (Paragraph [0040], “Continuing now to block S225, after receiving versioning information regarding the target platform. App Checker module 17 generates a list of applications that are current installed on the mobile device 15. In order to generate the list, for example, an application registry of the mobile device 15 is pulled and a list is created that includes the unique application identifier (“app ID”), such as an iOS ®, App ID, as well as version and build numbers of the installed applications (collectively, “application credentials”) [detecting actual deployment requirements on the end device]”; Paragraph [0041], “Proceeding now to step S230, when the App Store Server 40 receives the request to provide application information about compatibility with the target platform version, the App Store Server 40 queries accessible databases which contain whitelist and blacklist information for applications on particular platforms, specifically the target platform at issue. The whitelist and blacklist databases include tables that house a developer's certification as to whether an application is compatible with specific platform versions or empirically derived data to this effect, as shown in FIGS. 4A-B [and comparing the transmitted requirements specification with the detected actual deployment requirements]”); and deploying the new piece of software on the end device if it is determined that the requirements specification complies with the actual deployment requirements (Paragraph [0043], “The generated application list of installed applications on the current platform version with app ID, version number, and build number is compared to the application catalog of the target platform version on an iterative basis to find out whether each of the currently installed applications is or is not compatible with the target platform version. When a match (or yes/whitelist hit) is found in the target version catalog indicating the application is deemed compatible with the target platform version, no further action is taken with regard to the compatible application”; Paragraph [0046], “After populating the quarantine or removal database, App Checker module 17 upgrades the mobile device 15 to the target platform version. During the platform upgrade process, the target software platform package is downloaded and then installed in order to deploy updates to the native applications or mobile device operating system developed by the carrier or OEM of the mobile device [deploying the new piece of software on the end device if it is determined that the requirements specification complies with the actual deployment requirements]”) [Examiner’s remarks: The App Checker checks whether each application is “whitelisted” or compatible based on the requirements specification and actual deployment specification. When all applications are either whitelisted or quarantined, the new piece of software is deployed], - wherein a software currently installed on the end device comprises an upper software layer and a lower software layer, (Paragraph [0024], “Such changes can include updates to the native applications developed by the carrier and OEM of the mobile device, such as a telephony application, as well as updates to the mobile device operating system. Generally, such software components are preloaded on the mobile device 15 prior to sale to an individual, and thus are referred to herein as “preloaded software” [wherein a software currently installed on the end device comprises an upper software layer] ... When a platform update is available, App Checker module 17 determines whether each of the applications 16A-N installed on mobile device 15 that are not preloaded software and not part of the software platform itself are compatible with the target platform version that is available in the update [and a lower software layer]”)… … - detecting the actual deployment requirements comprises determining information about capabilities the lower software layer provides to the new piece of software and/or about requirements of the upper software layer for the new piece of software (Paragraph [0040], “Continuing now to block S225, after receiving versioning information regarding the target platform. App Checker module 17 generates a list of applications that are current installed on the mobile device 15. In order to generate the list, for example, an application registry of the mobile device 15 is pulled and a list is created that includes the unique application identifier (“app ID”), such as an iOS ®, App ID, as well as version and build numbers of the installed applications (collectively, “application credentials”) [detecting the actual deployment requirements comprises determining information about capabilities the lower software layer provides to the new piece of software and/or about requirements of the upper software layer for the new piece of software]”) [Examiner’s remarks: Applications (lower level of software) are capabilities which may be provided on the new piece of software and included in the actual deployment requirements.], … Morley does not explicitly disclose: - … the upper software layer requiring the new piece of software for operation, and - creating the requirements specification comprises determining information about capabilities the new piece of software provides to the upper software layer and/or about requirements of the new piece of software for the lower software layer; and … - wherein the transmitting said requirements specification is performed along with transmitting the new piece of software to the end device. However, Ningombam discloses: - … the upper software layer requiring the new piece of software for operation (Paragraph [0002], “Any software that is previously installed (“pre-installed software”) and currently executing in systems of computers in an enterprise or organization may need to be changed, for example to keep up with new requirements, latest technologies, and fix defects (“bugs”). A vendor of the pre-installed software may release additional software (“patch”) to fix bugs in the pre-installed software. Patches are typically released in a binary form, and used to overwrite portions of pre-installed software also in binary form. Note that if the pre-installed software is in another form, e.g. byte codes, then the patch is also released in the same form, e.g. also byte codes. For example, Oracle® Corporation releases a bundle of patches (“Critical Patch Update” or CPU) on a quarterly basis to provide security fixes for ORACLE® products”) [Examiner’s remarks: The patch code is necessary for the operation of the upper software layer (pre-installed software being patched) because it fixes defects or introduces new technology for the software.], and - creating the requirements specification comprises determining information about capabilities the new piece of software provides to the upper software layer and/or about requirements of the new piece of software for the lower software layer (Paragraph [0028], “As illustrated in FIG. 2B, metadata 241 is related to patches and is available from a vendor that releases the patches. Metadata 241 identifies, for example, (a) version number of the patches, and a flag indicating whether or not the patches are obsolete (b) prior patches and/or software products that are required as pre-requisites and/or co-requisites, and/or that cause conflicts [creating the requirements specification comprises determining information about capabilities the new piece of software provides to the upper software layer and/or about requirements of the new piece of software for the lower software layer]”) [Examiner’s remarks: The metadata (requirements specification) provides requirements of the new software for the lower layer (patches and/or software products required as prerequisites or co-requisites.]; and … - wherein the transmitting said requirements specification is performed along with transmitting the new piece of software to the end device ([Paragraph [0028], “As illustrated in FIG. 2B, metadata 241 is related to patches and is available from a vendor that releases the patches. Metadata 241 identifies, for example, (a) version number of the patches, and a flag indicating whether or not the patches are obsolete (b) prior patches and/or software products that are required as pre-requisites and/or co-requisites, and/or that cause conflicts”; Paragraph [0030], “Metadata 215 is also used in some embodiments to identify a specific patch that is applicable to each of target computers 212-214 (depending on software installed therein) and to download the identified patch 242 and its related metadata 241 into a computer-readable non-transitory storage medium, such as a hard disk for use in installation of the identified patch in target computers 212-214” [wherein the transmitting said requirements specification is performed along with transmitting the new piece of software to the end device]) [Examiner’s remarks: Metadata represents requirement data of a given patch. The patch may be sent along with its corresponding metadata upon download.]. Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Ningombam into the teachings of Morley to include “… the upper software layer requiring the new piece of software for operation”, “creating the requirements specification comprises determining information about capabilities the new piece of software provides to the upper software layer and/or about requirements of the new piece of software for the lower software layer” and “wherein the transmitting said requirements specification is performed along with transmitting the new piece of software to the end device”. As stated in Ningombam, “Inventors of the current patent application further note that restoring an adversely affected computer back to its original configuration is difficult and time consuming. Even if there is no critical failure, a newly-applied patch in one software tier (e.g. application software) may conflict with a previously-applied patch in another software tier (e.g. middleware software), requiring roll-back (i.e. removal) of the previously-applied patch” (Paragraph [0014]). Installing incompatible patches may break a system that requires time and resources to fix. Including a list of required software prior to installation may mitigate the effects of ineffectual installs. Therefore, it would be obvious to one of ordinary skill in the art of software updates to include system prerequisites in a method for software installation. Regarding claim 17, the rejection of claim 16 is incorporated; and Morley further discloses: - … - detecting the actual deployment requirements comprises determining information about capabilities the end device provides to the new piece of software and/or about requirements of the end device for the new piece of software (Paragraph [0040], “Continuing now to block S225, after receiving versioning information regarding the target platform. App Checker module 17 generates a list of applications that are current installed on the mobile device 15. In order to generate the list, for example, an application registry of the mobile device 15 is pulled and a list is created that includes the unique application identifier (“app ID”), such as an iOS ®, App ID, as well as version and build numbers of the installed applications (collectively, “application credentials”)”) [Examiner’s remarks: Applications (part of end device) are capabilities which may be provided to the new software and included in the actual deployment requirements.]. Morley does not explicitly disclose: - creating the requirements specification comprises determining information about capabilities the new piece of software provides to the end device and/or about requirements of the new piece of software for the end device However, Ningombam discloses: - creating the requirements specification comprises determining information about capabilities the new piece of software provides to the end device and/or about requirements of the new piece of software for the end device (Paragraph [0028], “As illustrated in FIG. 2B, metadata 241 is related to patches and is available from a vendor that releases the patches. Metadata 241 identifies, for example, (a) version number of the patches, and a flag indicating whether or not the patches are obsolete (b) prior patches and/or software products that are required as pre-requisites and/or co-requisites, and/or that cause conflicts.”) [Examiner’s remarks: The metadata (requirements specification) provides requirements of the new software for the end device (patches and/or software products required as prerequisites or co-requisites.]; and … Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Ningombam into the teachings of Morley to include “creating the requirements specification comprises determining information about capabilities the new piece of software provides to the end device and/or about requirements of the new piece of software for the end device”. As stated in Ningombam, “Inventors of the current patent application further note that restoring an adversely affected computer back to its original configuration is difficult and time consuming. Even if there is no critical failure, a newly-applied patch in one software tier (e.g. application software) may conflict with a previously-applied patch in another software tier (e.g. middleware software), requiring roll-back (i.e. removal) of the previously-applied patch” (Paragraph [0014]). Installing incompatible patches may break a system that requires time and resources to fix. Including a list of required software prior to installation may mitigate the effects of ineffectual installs. Therefore, it would be obvious to one of ordinary skill in the art of software updates to include system prerequisites in a method for software installation. Regarding claim 18, the rejection of claim 16 is incorporated; and Morley further discloses: - wherein creating the requirements specification comprises providing information about the new piece of software, and/or regarding Java Card packages if the new piece of software relates to a Java Card operating system, and/or a version of the new piece of software, or a memory requirement, and/or a memory map, and/or a data format version, and/or a hardware information, and/or deployment information (Paragraph [0039], “For example, the Update Server 35 may notify the App Checker module 17 when a platform upgrade becomes available, and then push the new platform version number to the App Checker module 17 of mobile device 15”) [Examiner’s remarks: Version information (platform version number) is provided.]. Regarding claim 20, the rejection of claim 16 is incorporated; and Morley further discloses: - wherein the actual deployment requirements are detected by a detection software installed on the end device wherein, the detection software is integrated into an operating system of the end device (Paragraph [0040], “Continuing now to block S225, after receiving versioning information regarding the target platform, App Checker module 17 generates a list of applications that are currently installed on the mobile device 15. In order to generate the list, for example, an application registry of the mobile device 15 is pulled and a list is created that includes the unique application identifier (“app ID”), such as an iOS® App ID, as well as version and build numbers of the installed applications (collectively, “application credentials”)”) [Examiner’s remarks: Detection software (App Checker) is integrated into the end device and detects the software installed on the end device.]. Regarding claim 21, the rejection of claim 16 is incorporated; and Morley further discloses: - wherein deploying the new piece of software comprises unpacking an image file of the new piece of software, checking its integrity, amending currently installed software components, updating currently installed software components, exchanging currently installed software components, deleting currently installed software components, and/or installing the new piece of software on the end device (Paragraph [0024], “App Checker module 17 handles the deployment of software platform updates on the mobile device 15 of the subscriber when platform update packages become available, such as those updates involving major underlying software platform changes. Such changes can include updates to the native applications developed by the carrier and OEM of the mobile device, such as a telephony application, as well as updates to the mobile device operating system”) [Examiner’s remarks: Deployment updates currently installed software components.]. Regarding claim 22, the rejection of claim 16 is incorporated; and Morley does not explicitly disclose: - wherein the requirements specification complies with the actual deployment requirements when a new operating system is compatible with a currently installed operating system and/or hardware of the end device. However, Ningombam discloses: - wherein the requirements specification complies with the actual deployment requirements when a new operating system is compatible with a currently installed operating system and/or hardware of the end device (Paragraph [0015], “Still another kind of analysis is based on use of both patch metadata and configuration metadata, to check whether a patch is suitable for application to a target computer”) [Examiner’s remarks: Based on compatibility between the actual deployment data and the requirements specification, a determination that the hardware (system) is compatible may be reached.]. Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Ningombam into the teachings of Morley to include “wherein the requirements specification complies with the actual deployment requirements when a new operating system is compatible with a currently installed operating system and/or hardware of the end device”. As stated in Ningombam, “Inventors of the current patent application further note that restoring an adversely affected computer back to its original configuration is difficult and time consuming. Even if there is no critical failure, a newly-applied patch in one software tier (e.g. application software) may conflict with a previously-applied patch in another software tier (e.g. middleware software), requiring roll-back (i.e. removal) of the previously-applied patch” (Paragraph [0014]). Installing incompatible patches may break a system that requires time and resources to fix. Checking for hardware compatibility before install mitigates the effects of incompatible installation. Therefore, it would be obvious to one of ordinary skill in the art of software updates to include system prerequisites in a method of software installation. Regarding claim 23, the rejection of claim 16 is incorporated; and Morley further discloses: - wherein compliance of the requirements specification with the actual deployment requirements is determined by evaluating a table indicating compatibility information (Paragraph [0041], “The whitelist and blacklist databases include tables that house a developer's certification as to whether an application is compatible with specific platform versions or empirically derived data to this effect [a table indicating compatibility information], as shown in FIGS. 4A-B. App Store Server 40 searches the whitelist and blacklist databases for each of the applications that reside in the generated application list received from App Checker module 17 and matches each application on the generated application list with a whitelist or blacklist entry on the target platform”). Regarding claim 24, the rejection of claim 16 is incorporated; and Morley further discloses: wherein the method is terminated when the requirements specification does not comply with the actual deployment requirements (Paragraph [0046], “Alternatively, the App Checker module 17 allows the subscriber to cancel the platform upgrade altogether if compatibility of particular application(s) are important enough to justify the maintenance of the current platform version”) [Examiner’s remarks: When the update is determined to be incompatible with the device, the update may be terminated by subscriber.]. Regarding claim 25, the rejection of claim 16 is incorporated; and Morley further discloses: - wherein the end device is a mobile phone, a wearable, a portable end device, a tablet computer or notebook, and/or comprises a Tamper Resistant Element (Paragraph [0015], “FIGS. 1A-B illustrate functional block diagrams of systems 5, 6 that support communications for identifying and isolating applications on a customized mobile device [mobile phone, portable end device] that are incompatible with a platform update”). Regarding claim 26, the rejection of claim 16 is incorporated; and Morley further discloses: wherein a new operating system or operating system image is installed on the end device as the new piece of software (Paragraph [0024], “App Checker module 17 handles the deployment of software platform updates on the mobile device 15 of the subscriber when platform update packages become available, such as those updates involving major underlying software platform changes. Such changes can include updates to the native applications developed by the carrier and OEM of the mobile device, such as a telephony application, as well as updates to the mobile device operating system [a new operating system]”). Regarding claim 27, Morley discloses: A system arrangement for ensuring eligibility of a piece of software to be installed on an end device, the system arrangement being implemented automatically by a processor of the end device, comprising (Paragraph [0022], “Mobile device 15 also has an App Checker module 17 installed and executes the App Checker module 17 during software platform upgrades. The applications 16A-N and App Checker module 17 are typically installed as applications after being downloaded from the App Store Server 40”; Paragraph [0024], “ App Checker module 17 pings or queries the Update Server 35 and requests whether a platform update is available. When a platform update is available, App Checker module 17 determines whether each of the applications 16A-N installed on mobile device 15 that are not preloaded software and not part of the software platform itself are compatible with the target platform version that is available in the update”) [Examiner’s remarks: The steps for ensuring eligibility of software is performed in an automated fashion using App Checker which is installed on the mobile device (end device).]: an entity being arranged to create a requirements specification by evaluating a new piece of software regarding deployment requirements of the end device (Paragraph [0040], “App Checker module 17 then issues a service request via an API call to the App Store Server 40 requesting the application catalog of compatible applications for the target platform version [an entity being arranged to create a requirements specification by evaluating a new piece of software regarding deployment requirements of the end device]”) [Examiner’s remarks: A catalog is created based on evaluation of whether applications on an end device are compatible with a given platform number.]; … a detection entity being arranged to detect actual deployment requirements on the end device and to compare the transmitted requirements specification with the detected actual deployment requirements (Paragraph [0040], “Continuing now to block S225, after receiving versioning information regarding the target platform. App Checker module 17 generates a list of applications that are current installed on the mobile device 15. In order to generate the list, for example, an application registry of the mobile device 15 is pulled and a list is created that includes the unique application identifier (“app ID”), such as an iOS ®, App ID, as well as version and build numbers of the installed applications (collectively, “application credentials”) [a detection entity being arranged to detect actual deployment requirements on the end device]”; Paragraph [0041], “Proceeding now to step S230, when the App Store Server 40 receives the request to provide application information about compatibility with the target platform version, the App Store Server 40 queries accessible databases which contain whitelist and blacklist information for applications on particular platforms, specifically the target platform at issue. The whitelist and blacklist databases include tables that house a developer's certification as to whether an application is compatible with specific platform versions or empirically derived data to this effect, as shown in FIGS. 4A-B [and to compare the transmitted requirements specification with the detected actual deployment requirements]”); and a deployment entity being arranged to deploy the new piece of software on the end device if it is determined that the requirements specification complies with the actual deployment requirements (Paragraph [0043], “The generated application list of installed applications on the current platform version with app ID, version number, and build number is compared to the application catalog of the target platform version on an iterative basis to find out whether each of the currently installed applications is or is not compatible with the target platform version. When a match (or yes/whitelist hit) is found in the target version catalog indicating the application is deemed compatible with the target platform version, no further action is taken with regard to the compatible application”; Paragraph [0046], “After populating the quarantine or removal database, App Checker module 17 upgrades the mobile device 15 to the target platform version. During the platform upgrade process, the target software platform package is downloaded and then installed in order to deploy updates to the native applications or mobile device operating system developed by the carrier or OEM of the mobile device [a deployment entity being arranged to deploy the new piece of software on the end device if it is determined that the requirements specification complies with the actual deployment requirements]”) [Examiner’s remarks: The App Checker checks whether each application is “whitelisted” or compatible based on the requirements specification and actual deployment specification. When all applications are either whitelisted or quarantined, the new piece of software is deployed.], - wherein a software currently installed on the end device comprises an upper software layer and a lower software layer (Paragraph [0024], “Such changes can include updates to the native applications developed by the carrier and OEM of the mobile device, such as a telephony application, as well as updates to the mobile device operating system. Generally, such software components are preloaded on the mobile device 15 prior to sale to an individual, and thus are referred to herein as “preloaded software” [wherein a software currently installed on the end device comprises an upper software layer] ... When a platform update is available, App Checker module 17 determines whether each of the applications 16A-N installed on mobile device 15 that are not preloaded software and not part of the software platform itself are compatible with the target platform version that is available in the update [and a lower software layer]”), … … - the detection entity is configured to determine, information about capabilities the lower software layer provides to the new piece of software and/or about requirements of the upper software layer for the new piece of software (Paragraph [0040], “Continuing now to block S225, after receiving versioning information regarding the target platform. App Checker module 17 generates a list of applications that are current installed on the mobile device 15. In order to generate the list, for example, an application registry of the mobile device 15 is pulled and a list is created that includes the unique application identifier (“app ID”), such as an iOS ®, App ID, as well as version and build numbers of the installed applications (collectively, “application credentials”) [the detection entity is configured to determine, information about capabilities the lower software layer provides to the new piece of software and/or about requirements of the upper software layer for the new piece of software]”) [Examiner’s remarks: Applications (lower level of software) are capabilities which may be provided on the new piece of software and included in the actual deployment requirements.]. Morley does not explicitly disclose: - an interface entity being arranged to transmit said requirements specification to the end device along with transmitting the new piece of software to the end device; … - …the upper software layer requiring the new piece of software for operation (Paragraph [0002], “Any software that is previously installed (“pre-installed software”) and currently executing in systems of computers in an enterprise or organization may need to be changed, for example to keep up with new requirements, latest technologies, and fix defects (“bugs”). A vendor of the pre-installed software may release additional software (“patch”) to fix bugs in the pre-installed software. Patches are typically released in a binary form, and used to overwrite portions of pre-installed software also in binary form. Note that if the pre-installed software is in another form, e.g. byte codes, then the patch is also released in the same form, e.g. also byte codes. For example, Oracle® Corporation releases a bundle of patches (“Critical Patch Update” or CPU) on a quarterly basis to provide security fixes for ORACLE® products”) [Examiner’s remarks: The patch code is necessary for the operation of the upper software layer (pre-installed software being patched) because it fixes defects or introduces new technology for the software.], and - the entity being arranged to create a requirements specification is configured to determine information about capabilities the new piece of software provides to the upper software layer and/or about requirements of the new piece of software for the lower software layer; and However, Ningombam discloses: - an interface entity being arranged to transmit said requirements specification to the end device along with transmitting the new piece of software to the end device ([Paragraph [0028], “As illustrated in FIG. 2B, metadata 241 is related to patches and is available from a vendor that releases the patches. Metadata 241 identifies, for example, (a) version number of the patches, and a flag indicating whether or not the patches are obsolete (b) prior patches and/or software products that are required as pre-requisites and/or co-requisites, and/or that cause conflicts”; Paragraph [0030], “Metadata 215 is also used in some embodiments to identify a specific patch that is applicable to each of target computers 212-214 (depending on software installed therein) and to download the identified patch 242 and its related metadata 241 into a computer-readable non-transitory storage medium, such as a hard disk for use in installation of the identified patch in target computers 212-214” [an interface entity being arranged to transmit said requirements specification to the end device along with transmitting the new piece of software to the end device]) [Examiner’s remarks: Metadata represents requirement data of a given patch. The patch may be sent along with its corresponding metadata upon download to an end device.]); … - …the upper software layer requiring the new piece of software for operation, and - the entity being arranged to create a requirements specification is configured to determine information about capabilities the new piece of software provides to the upper software layer and/or about requirements of the new piece of software for the lower software layer ([Paragraph [0028], “As illustrated in FIG. 2B, metadata 241 is related to patches and is available from a vendor that releases the patches. Metadata 241 identifies, for example, (a) version number of the patches, and a flag indicating whether or not the patches are obsolete (b) prior patches and/or software products that are required as pre-requisites and/or co-requisites, and/or that cause conflicts [the entity being arranged to create a requirements specification is configured to determine information about capabilities the new piece of software provides to the upper software layer and/or about requirements of the new piece of software for the lower software layer]”) [Examiner’s remarks: The metadata (requirements specification) provides requirements of the new software for the lower layer (patches and/or software products required as prerequisites or co-requisites.]; and Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Ningombam into the teachings of Morley to include “an interface entity being arranged to transmit said requirements specification to the end device along with transmitting the new piece of software to the end device”, “the upper software layer requiring the new piece of software for operation, and”, and “the entity being arranged to create a requirements specification is configured to determine information about capabilities the new piece of software provides to the upper software layer and/or about requirements of the new piece of software for the lower software layer”. As stated in Ningombam, “Inventors of the current patent application further note that restoring an adversely affected computer back to its original configuration is difficult and time consuming. Even if there is no critical failure, a newly-applied patch in one software tier (e.g. application software) may conflict with a previously-applied patch in another software tier (e.g. middleware software), requiring roll-back (i.e. removal) of the previously-applied patch” (Paragraph [0014]). Installing incompatible patches may break a system that requires time and resources to fix. Including a list of required software prior to installation may mitigate the effects of ineffectual installs. Therefore, it would be obvious to one of ordinary skill in the art of software updates to include system prerequisites in a method for software installation. Regarding claim 28, the rejection of claim 27 is incorporated; and Morley further discloses: - wherein the entities of the systems arrangement are realized by one or more computer program products, wherein the detection entity preferably is realized by a detection software installed on the end device (Paragraph [0096], “Aspects of the methods of identifying and isolating incompatible applications during a platform update as outlined above may be embodied in programming, for example, for one or more server and/or for mobile devices. Program aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of executable code and/or associated data that is carried on or embodied in a type of machine readable medium [wherein the entities of the systems arrangements are realized by one or more computer program products]”; Paragraph [0022], “Mobile device 15 also has an App Checker module 17 installed and executes the App Checker module 17 during software platform upgrades”) [whereas the detection entity preferably is realized by a detection software installed on the end device]”; Paragraph [0040], “Continuing now to block S225, after receiving versioning information regarding the target platform. App Checker module 17 generates a list of applications that are current installed on the mobile device 15”). Regarding claim 29, the rejection of claim 16 is incorporated; and Morley further discloses: A non-transitory computer-readable memory comprising instructions that, when executed by a processor of the end device, cause the processor to automatically detect actual deployment requirements on an end device as the detection step of a method according to claim 16 (Paragraph [0096], “Aspects of the methods of identifying and isolating incompatible applications during a platform update as outlined above may be embodied in programming, for example, for one or more server and/or for mobile devices. Program aspects of the technology may be thought of as “products” or “articles of manufacture” typically in the form of executable code and/or associated data that is carried on or embodied in a type of machine readable medium [A non-transitory computer-readable memory comprising instructions that, when executed by a processor of the end device, cause the processor to automatically detect actual deployment requirements on an end device as the detection step of a method according to claim 16]”). Regarding claim 30, the rejection of claim 16 is incorporated; and Morley further discloses: - wherein said detecting actual deployment requirements on the end device and comparing the transmitted requirements specification with the detected actual deployment requirements are performed in real- time (Paragraph [0050], “The Update Server 35 searches the empirically derived whitelist and blacklist databases for each of the applications that reside in the generated application list that was received from App Checker module 17. The empirically derived database tables contain the number of incompatibility reports or malfunction reports of an application by app ID, version number, and build number and are linked to a specific target platform number. Along with the reported incompatibility reports is a running count (i.e., tally) of the total incompatibility incidents alongside a whitelist or blacklist status which indicates whether the application is compatible (see FIG. 4B) with a given platform. The empirically derived compatibility (i.e., whitelist or blacklist) status is continuously monitored and updated by the Update Server 35, as discussed in step S345 below. Continuously monitoring in this context means the Update Server 35 updates the number of malfunction reports as the reports are received in real time or in near real time, and then adjusts the empirically derived compatibility status based on a threshold value of malfunction reports, as explained in S345 below. For purposes of step S330, once this compatibility status is retrieved during the search of the empirically derived database, the Update Server 35 processes and returns that status as a part of a specific or general application catalog to the App Checker module 17 in the same manner that was discussed in step S230 of FIG. 2 above.”) [Examiner’s remarks: The search of whitelists/blacklists in the deployment requirements process and the updates of the lists are done in real-time based on incompatibility incident reports from other uses.]. Claim 31 is rejected under 35 U.S.C. 103 as being unpatentable over US 20160162275 A1 (hereinafter “Morley”) in view of US 20110225575 A2 (hereinafter “Ningombam”), and further in view of US 6370686 B1 (hereinafter “Delo”). Regarding claim 31, Morley discloses: A computer-implemented method for ensuring eligibility of a piece of software to be installed on an end device, the method being implemented automatically by a processor of the end device and comprising the steps (Paragraph [0022], “Mobile device 15 also has an App Checker module 17 installed and executes the App Checker module 17 during software platform upgrades. The applications 16A-N and App Checker module 17 are typically installed as applications after being downloaded from the App Store Server 40”; Paragraph [0024], “ App Checker module 17 pings or queries the Update Server 35 and requests whether a platform update is available. When a platform update is available, App Checker module 17 determines whether each of the applications 16A-N installed on mobile device 15 that are not preloaded software and not part of the software platform itself are compatible with the target platform version that is available in the update”) [Examiner’s remarks: The steps for ensuring eligibility of software is performed in an automated fashion using App Checker which is installed on the mobile device (end device).]: creating a requirements specification by evaluating a new piece of software regarding deployment requirements of the end device (Paragraph [0040], “App Checker module 17 then issues a service request via an API call to the App Store Server 40 requesting the application catalog of compatible applications for the target platform version [creating a requirements specification by evaluating a new piece of software regarding deployment requirements of the end device]”) [Examiner’s remarks: A catalog is created based on evaluation of whether applications on an end device are compatible with a given platform number.]; transmitting said requirements specification to the end device (Paragraph [0040], “App Checker module 17 then issues a service request via an API call to the App Store Server 40 requesting the application a catalog of compatible applications for the target platform version [transmitting said requirements specification to the end device]”); detecting actual deployment requirements on the end device and comparing the transmitted requirements specification with the detected actual deployment requirements …by the processor (Paragraph [0040], “Continuing now to block S225, after receiving versioning information regarding the target platform. App Checker module 17 generates a list of applications that are current installed on the mobile device 15. In order to generate the list, for example, an application registry of the mobile device 15 is pulled and a list is created that includes the unique application identifier (“app ID”), such as an iOS ®, App ID, as well as version and build numbers of the installed applications (collectively, “application credentials”) [detecting actual deployment requirements on the end device]”; Paragraph [0041], “Proceeding now to step S230, when the App Store Server 40 receives the request to provide application information about compatibility with the target platform version, the App Store Server 40 queries accessible databases which contain whitelist and blacklist information for applications on particular platforms, specifically the target platform at issue. The whitelist and blacklist databases include tables that house a developer's certification as to whether an application is compatible with specific platform versions or empirically derived data to this effect, as shown in FIGS. 4A-B [and comparing the transmitted requirements specification with the detected actual deployment requirements…by the processor]” [Examiner’s remarks: The transmitted requirements and actual deployment requirements are compared by the processor.]; and deploying the new piece of software on the end device if it is determined that the requirements specification complies with the actual deployment requirements (Paragraph [0043], “The generated application list of installed applications on the current platform version with app ID, version number, and build number is compared to the application catalog of the target platform version on an iterative basis to find out whether each of the currently installed applications is or is not compatible with the target platform version. When a match (or yes/whitelist hit) is found in the target version catalog indicating the application is deemed compatible with the target platform version, no further action is taken with regard to the compatible application”; Paragraph [0046], “After populating the quarantine or removal database, App Checker module 17 upgrades the mobile device 15 to the target platform version. During the platform upgrade process, the target software platform package is downloaded and then installed in order to deploy updates to the native applications or mobile device operating system developed by the carrier or OEM of the mobile device [deploying the new piece of software on the end device if it is determined that the requirements specification complies with the actual deployment requirements]”) [Examiner’s remarks: The App Checker checks whether each application is “whitelisted” or compatible based on the requirements specification and actual deployment specification. When all applications are either whitelisted or quarantined, the new piece of software is deployed], - wherein a software currently installed on the end device comprises an upper software layer and a lower software layer (Paragraph [0024], “Such changes can include updates to the native applications developed by the carrier and OEM of the mobile device, such as a telephony application, as well as updates to the mobile device operating system. Generally, such software components are preloaded on the mobile device 15 prior to sale to an individual, and thus are referred to herein as “preloaded software” [wherein a software currently installed on the end device comprises an upper software layer] ... When a platform update is available, App Checker module 17 determines whether each of the applications 16A-N installed on mobile device 15 that are not preloaded software and not part of the software platform itself are compatible with the target platform version that is available in the update [and a lower software layer]”) , and … - detecting the actual deployment requirements comprises determining information about capabilities the lower software layer provides to the new piece of software … (Paragraph [0040], “Continuing now to block S225, after receiving versioning information regarding the target platform. App Checker module 17 generates a list of applications that are current installed on the mobile device 15. In order to generate the list, for example, an application registry of the mobile device 15 is pulled and a list is created that includes the unique application identifier (“app ID”), such as an iOS ®, App ID, as well as version and build numbers of the installed applications (collectively, “application credentials”) [detecting the actual deployment requirements comprises determining information about capabilities the lower software layer provides to the new piece of software …”) [Examiner’s remarks: Applications (lower level of software) are capabilities which may be provided on the new piece of software and included in the actual deployment requirements.]. Morley does not explicitly disclose: - … in real-time… - creating the requirements specification comprises determining information about capabilities the new piece of software provides to the upper software layer and about requirements of the new piece of software for the lower software layer; and - - … and about requirements of the upper software layer for the new piece of software However, Ningombam discloses: - … in real-time (Paragraph [0034], “In certain illustrative embodiments of the invention, prior to installation of patch files in target computers 212-214 (FIG. 2B), computer 220 (also called “patch analysis computer”) performs at least three kinds of checks 203, 204 and 205 (FIG. 2A) to determine issues that would arise in application of specific patches to the to-be-patched software that is previously installed and running in one or more of target computers 212-214 (FIG. 2B). Specifically, in act 203, computer 220 checks if a predetermined patch is currently supported by the vendor (e.g. latest version released by the vendor). In act 204, computer 220 checks if the predetermined patch to be applied is appropriate for the specific software to be patched (e.g. whether disk space required for patching is less than disk space available in target). In act 205, computer 220 checks if the target has one or more resources (e.g. installer software, and administrator privilege) that are known to be needed to apply any patch”) [Examiner’s remarks: The patch is determined to meet requirements or not as it is about to be deployed, and is thereby all the requirements tests are performed in real-time.]… - creating the requirements specification comprises determining information about … about requirements of the new piece of software for the lower software layer ([Paragraph [0028], “As illustrated in FIG. 2B, metadata 241 is related to patches and is available from a vendor that releases the patches. Metadata 241 identifies, for example, (a) version number of the patches, and a flag indicating whether or not the patches are obsolete (b) prior patches and/or software products that are required as pre-requisites and/or co-requisites, and/or that cause conflicts [creating the requirements specification comprises determining … about requirements of the new piece of software for the lower software layer]”) [Examiner’s remarks: The metadata (requirements specification) provides requirements of the new software for the lower layer (patches and/or software products required as prerequisites or co-requisites.]; and Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Ningombam into the teachings of Morley to include “in real-time”, “creating the requirements specification comprises determining information about … about requirements of the new piece of software for the lower software layer”. As stated in Ningombam, “Inventors of the current patent application further note that restoring an adversely affected computer back to its original configuration is difficult and time consuming. Even if there is no critical failure, a newly-applied patch in one software tier (e.g. application software) may conflict with a previously-applied patch in another software tier (e.g. middleware software), requiring roll-back (i.e. removal) of the previously-applied patch” (Paragraph [0014]). Installing incompatible patches may break a system that requires time and resources to fix. Including a list of required software prior to installation may mitigate the effects of ineffectual installs. Therefore, it would be obvious to one of ordinary skill in the art of software updates to include system prerequisites in a method for software installation. The combination of Morley and Ningombam does not explicitly disclose: … information about capabilities the new piece of software provides to the upper software layer and … and about requirements of the upper software layer for the new piece of software However, Delo discloses: … information about capabilities the new piece of software provides to the upper software layer and (Column 3, lines 12-27, “To perform the present invention, an Installer, an Installation Registry, Descriptors and a Publish Component table are utilized. The Installation Registry contains a listing of the products, associated features and components used by the features. In the case where the component is installed, the registry will contain a keypath designating the location of where the component is located. Descriptors are structures containing a product, feature and component information. This information is used to generate a token located in the Installer Registry. The Publish Component Table contains a qualifier, a feature and a category field. In addition, the Publish Component Table may contain an AppData field. The category field is a string that identifies the category of the component being qualified. The feature and category fields provide the information for installing the component referred to by this qualifier”; Column 6, lines 1-9, “A “feature” is a granular piece of the product that a user may choose to install or execute. Features typically correspond roughly to the functional features of the product itself, such as a “Proofing Tools” feature or a “Word” feature. Each feature is essentially a grouping of components and may also include other features”; Column 2, lines 40-47, “Categorizing and installing a component on demand is beneficial for several reasons. First, by categorizing components, an application or other process may request all related components by using a qualifier submitted to the installer. This increases the efficiency of the application or process by reducing the number of searches required to find related components”)… … and about requirements of the upper software layer for the new piece of software (Column 3, lines 12-27, “To perform the present invention, an Installer, an Installation Registry, Descriptors and a Publish Component table are utilized. The Installation Registry contains a listing of the products, associated features and components used by the features. In the case where the component is installed, the registry will contain a keypath designating the location of where the component is located. Descriptors are structures containing a product, feature and component information. This information is used to generate a token located in the Installer Registry. The Publish Component Table contains a qualifier, a feature and a category field. In addition, the Publish Component Table may contain an AppData field. The category field is a string that identifies the category of the component being qualified. The feature and category fields provide the information for installing the component referred to by this qualifier”; Column 6, lines 1-9, “A “feature” is a granular piece of the product that a user may choose to install or execute. Features typically correspond roughly to the functional features of the product itself, such as a “Proofing Tools” feature or a “Word” feature. Each feature is essentially a grouping of components and may also include other features”; Column 2, lines 40-47, “Categorizing and installing a component on demand is beneficial for several reasons. First, by categorizing components, an application or other process may request all related components by using a qualifier submitted to the installer. This increases the efficiency of the application or process by reducing the number of searches required to find related components”) Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Delo into the combined teachings of Morley and Ningombam to include “and about requirements of the upper software layer for the new piece of software” and “… information about capabilities the new piece of software provides to the upper software layer and”. As stated in Delo, “Categorizing and installing a component on demand is beneficial for several reasons. First, by categorizing components, an application or other process may request all related components by using a qualifier submitted to the installer. This increases the efficiency of the application or process by reducing the number of searches required to find related components” (Column 2, lines 40-47). Allowing for installation of code based on functionality matches ensures that code for required capabilities may be easily acquired and installed. Therefore, it would be obvious to one of ordinary skill in the art of software updates to include software ability matching. Response to Arguments Applicant's arguments filed May 29, 2026 have been fully considered but they are not persuasive. Regarding the rejection under 35 U.S.C. 101, Applicant argues: As amended, independent claims 16 and 31 do not merely recite a disembodied evaluation of compatibility information. Rather, claim 16 recites a computer- implemented method that is implemented automatically by a processor of the end device and that controls whether a new piece of software is deployed on that end device. Claim 31 further requires that detecting actual deployment requirements and comparing the transmitted requirements specification with the detected actual deployment requirements are performed automatically in real-time by the processor. The Advisory Action maintains that creating and detecting requirements of various software/software layers and determining software eligibility are mental steps. Respectfully, the amended claims do not reasonably support that characterization. In particular, the claims expressly require automatic implementation by a processor of the end device and recite a specific end-device software structure in which the upper software layer requires the new piece of software for operation. [See Remarks – Pages 10-11] Examiner’s response: Examiner respectfully disagrees. Applicant argues that because the steps are performed by a processor, the claim is no longer directed to a mental step. However, merely citing use of a processor, even a processor on an end device, or automatic performance of the mental step, does not overcome a rejection for abstract idea. The use of a processor is analyzed under Prong 2 and amounts to mere application of a generic computer component to the abstract idea which does not amount to practical application. Under Step 2B, mere application of a generic computer component cannot amount to significantly more. See MPEP 2106.05(f). Therefore, the rejection under 35 U.S.C. 101 for mental process is maintained. In the remarks, Applicant argues: The present disclosure explains that this is a technical compatibility problem arising in software deployment on an end device. Incompatible new software components can damage or render the end device inoperable, and rollback may no longer be possible (see at least paras. [07]-[010] and [52]-[57]). The disclosed solution is not simply to think about compatibility, but to detect actual deployment requirements on and by the end device, compare those requirements with a requirements specification for the new piece of software, and deploy the new piece of software only when the specified technical requirements are satisfied (see at least paras. [20]-[25], [29], [33], [36], and [58]). The amended upper-layer limitations are not merely an intended field of use, but they define the specific technical data being determined and compared by the end device processor. As explained in at least paras. [38]-[39] and [60]-[65] of the disclosure, eligibility of the new piece of software depends on these two reciprocal functional relationships. Fig. 4 illustrates the corresponding demand/provide relationship between the upper software layer, the new piece of software, and the lower software layer. Because the claims require automatic implementation by a processor of the end device and deploying the new piece of software on the end device if it is determined that the requirements specification complies with the actual deployment requirements, the claimed method cannot practically be performed in the human mind. A human may conceptually reason about whether one software layer is compatible with another, but the claimed method requires processor-implemented detection of actual deployment requirements on the end device and processor-implemented control of deployment of new software on that same end device. The presence of decision logic does not convert the claim into a mental process, as the claim as a whole recites technical operations on device software and controls a technical deployment process. [See Remarks – Pages 11-12] Examiner’s response: Examiner respectfully disagrees. Applicant argues that the disclosed solution requires detection of deployment requirements, comparison of requirement specifications, and deployment of new software. The human mind is capable of detecting the requirements of a software, an is also capable of comparing requirement specifications. For deploying of new software, deployment is not analyzed under Prong 1 for being directed to a mental process, but rather under Prong 2 and Step 2B as amounting to merely adding the words “apply it” to the judicial exception. Amending upper layer with limitations merely further describes a software that is being analyzed in the mental step. Furthermore, while the specification defines a reciprocal relationship, the relationship is not defined in the claims, and is therefore not analyzed for the purposes of 35 U.S.C. 101 analysis. The recited additional elements do not amount to practical application, nor do they amount to significantly more than the judicial exception. Therefore, the rejection under 35 U.S.C. 101 is maintained. In the remarks, Applicant argues: The amended claims also integrate any alleged abstract idea into a practical application. As discussed in previous responses, the claimed operations improve the technical process of installing and updating software on end devices by automatically preventing incompatible software from being deployed, by permitting runtime and real-time testing on the end device, and by reducing the risk of locking or damaging the device (see at least paras. [10], [25], [33], [36], and [52]-[57]). Under MPEP §§ 2106.04(d) and 2106.05(a), such an improvement to a technological process is a practical application. The transmitting and deploying limitations are also not merely insignificant extra- solution activity. The claims require that the requirements specification is transmitted along with the new piece of software to the end device, and the disclosure explains that this allows the end device to perform tests on the image of the new piece of software as it is provided with the requirements specification (para. [27]). Deployment is then conditioned on the processor-implemented determination that the requirements specification complies with the detected actual deployment requirements. If compliance is not present, the method is terminated and the incompatible new piece of software is not installed (para. [33]). [See Remarks – Page 12] Examiner’s Response: Examiner respectfully disagrees. The cited improvements are not recited in the claims, which merely recite the transmission of data, which amounts to the insignificant extra solution activity of mere data gathering and transmission, and deploying software, which amounts to mere application. Therefore, the transmitting and deploying limitations are not sufficient to amount to practical application, nor to significantly more. In regards to the rejection under 35 U.S.C. 103, Applicant argues: The Advisory Action states that the prior "and/or" claim language was interpreted under the broadest reasonable interpretation as an "or" statement, and therefore concluded that the rejection needed to teach only one side of the upper/lower-layer relationship. Independent claim 31 is currently amended to replace the "and/or" limitation with "and," and claim 31 is accordingly patentable over the combination of Morley and Ningombam. Examiner’s response: The referenced limitations are taught with additional reference Delo. Therefore, the rejection under 35 U.S.C. 103 is maintained. In the remarks, Applicant argues: Independent claims 16 and 27 are currently amended to more particularly describe the upper software layer requiring the new piece of software for operation. There is no similar teaching or suggestion derivable from the combination of Morley and Ningombam. Morley is directed to an App Checker that identifies and isolates third-party applications already installed on a customized mobile device that may be incompatible with a target platform update (Abstract; paras. [0001]-[0002], [0015], and [0024]). Morley generates a list of applications currently installed on the mobile device, requests a catalog of applications compatible with a target platform version, and compares the installed- application list to the received application catalog (paras. [0040]-[0043]). After incompatible applications are quarantined or removed, the mobile device may be upgraded to the target platform version (paras. [0044]-[0046]). Notably, Morley contains no teaching of an upper software layer that requires the new piece of software. The present disclosure explains that the upper software layer requires the new piece of software to provide certain capabilities, while the new piece of software requires the lower software layer to provide certain capabilities, and that eligibility is determined from those reciprocal relationships (see, e.g., paras. [38-39], [60-62]). Ningombam does not cure this deficiency. Ningombam describes an enterprise patch- analysis computer that retrieves patch metadata and target-computer configuration metadata, analyzes whether patches are suitable for target computers, displays a report, receives human input, and then applies approved patches (Abstract; paras. [0015], [0027]-[0030], and [0038]-[0040]). Even if such prerequisites were arguendo treated as disclosing requirements of the new software for some lower layer, the cited disclosure still does not teach an upper software layer that requires the new piece of software. Examiner’s remarks: Examiner respectfully disagrees. First, the present claims do not explicitly define a reciprocal relationship as defined by Applicant. Furthermore, Ningombam may be used to disclose software required by the upper layer. As discussed in the rejection of the claims under 35 U.S.C. 103, Ningombam’s discloses patches either fix an existing error or add additional capabilities to existing software. Therefore, the patches of Ningombam disclose software which introduces additional capabilities to existing upper software layer. In the remarks, Applicant argues: Ningombam further teaches away from the recited automatic end-device implementation of the amended claims. As taught in at least paras. [0038]-[0040], Ningombam performs its analysis at a patch analysis computer and displays a report for review by a human before patch files are applied. In contrast, the present claims require automatic implementation by a processor of the end device, and claim 31 further requires automatic real-time detection and comparison by that processor. Examiner’s response: Examiner respectfully disagrees. First, teaching away requires that the reference specifically teaches not to perform an action, rather than simply performing a different action. Secondly, Ningombam is not used to disclose automatic end-device implementation of the claims. Rather, Ningombam discloses specific steps of creating requirements and transmitting requirements which is combined with the end-device executed method of Morley. Therefore, the rejection under 35 U.S.C. 103 is maintained. In the remarks, Applicant argues: The "real time" discussion of Morley similarly fails to reach the amended claims. Morley's cited real-time feature is a remote Update Server updating an empirically derived whitelist/blacklist status as malfunction reports are received after platform updates have been installed on devices (paras. [0050]-[0052]). This server-side, post- installation, crowd-sourced database update is not the processor of the end device automatically detecting actual deployment requirements on the end device and comparing those requirements with a requirements specification before deployment, in the manner required by the amended claims. Examiner’s response: The rejection for real time has been amended to instead be taught by Ningombam. Ningombam discloses comparing the patch requirements to the requirements as the patch is being deployed. Therefore, the requirements are detected and checked in real-time. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached Monday-Friday 8:30AM-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, 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. /V.W.D./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191