DETAILED ACTION
This action is in response to the claims filed September 29, 2025. Claims 16-18, and 20-31 are pending. Claims 16, 27, and 31 are independent claims. Claims 16, 18, 20-22, 24-25, 27, and 28 have been amended. Claims 30-31 are new claims. Claim 19 has been cancelled.
The objection to the drawings is withdrawn in view of applicant’s amendment of the drawings.
The objections to claims 16, 18, 19, 21, 27, and 28 are withdrawn in view of Applicant’s amendments to the claims.
The objection to claim 25 is maintained in view of Applicant’s amendments to the claims.
The rejection of the claims under 35 U.S.C. §112(b) is withdrawn in view of Applicant’s amendments to the claims.
The rejection of the claims under 35 U.S.C. §101 is maintained 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 Objections
Claim 25 is objected to because of the following informalities:
In claim 25, “wherein eligibility of a piece of software is ensured that is to be installed on” should likely read “wherein eligibility is to be ensured on a piece of software that is to be installed on”.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“an entity being arranged to create” in claim 27.
“an interface entity being arranged to transmit” in claim 27.
“a detection entity being arranged to detect” in claim 27.
“a deployment entity being arranged to deploy” in claim 27.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 101
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 method for ensuring eligibility of a piece of software to be installed on an end device” 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 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 method for ensuring eligibility of a piece of software to be installed on an end device” 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 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”, “wherein a software currently installed on the end device comprises and upper software layer and a lower software layer”, “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”, “wherein a software currently installed on the end device comprises and upper software layer and a lower software layer”, “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 computer program product being arranged to detect actual deployment requirements on an end device as the detection step of a method according to claim 16, when being installed on and executed by the end device.” merely describes in generic terms the intended function of a “computer program product” 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/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 method for ensuring eligibility of a piece of software to be installed on an end device” 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 method for ensuring eligibility of a piece of software to be installed on an end device” 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 29 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 29 is directed to a system. However, the recited components of the system appear to lack the necessary physical components (hardware) to constitute a machine or manufacture under § 101. The recited components of the system can be construed to cover software under the broadest reasonable interpretation. Therefore, the claimed system is ineligible subject matter under § 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-31 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 method for ensuring eligibility of a piece of software to be installed on an end device, comprising the steps:
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 and (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:
- 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:
- 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 “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 information1 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 that 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 that 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 that 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 eligibility of a piece of software is ensured that is to be installed on a mobile phone, a wearable, a portable end device, a tablet computer or notebook, and/or on an end device comprising 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 further discloses:
A system arrangement for ensuring eligibility of a piece of software to be installed on an end device, comprising:
- 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 and (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 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 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” 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 computer program product being arranged to detect actual deployment requirements on an end device as the detection step of a method according to claim 16, when being installed on and executed by 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 [A computer program product being arranged to detect actual deployment requirements on an end device as the detection step of a method according to claim 16, when being installed on and executed by the end device]”).
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.].
Regarding claim 31, Morley discloses:
A method for ensuring eligibility of a piece of software to be installed on an end device, comprising the steps:
- 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 automatically in real-time (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]”; Paragraph [0050], “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 [automatically in real-time]”; 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 and (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:
- 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
However, Ningombam discloses:
…
- 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
…
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 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.
Response to Arguments
Applicant's arguments filed September 29, 2025 have been fully considered but they are not persuasive.
Regarding the rejection under 35 U.S.C. 101, Applicant argues:
Reconsideration of the rejection is requested in view of the following observations.
The current claims are currently rejected as being directed to an abstract idea based on nothing precluding the claimed limitations from being performed in the mind. However, it is respectfully submitted that the current claims do not recite mental processes because they cannot be practically performed in the mind but require the manipulation of specific data structures and result in modified data structures (see MPEP 2106.04(a)(2)(III)(A)).
[See Remarks – Page 12]
Examiner’s Response:
Examiner respectfully disagrees. At least the “creating a requirements specification…”, “detecting actual deployment requirements…”, “…determine that the requirements specification…”, “creating the requirements specification”, and “detecting the actual deployment requirements” limitations are limitations that, under their broadest reasonable interpretation, encompass a human mind carrying out the function through observation, evaluation, judgement, and/or opinion, or even with the aid of pen and paper. The human mind is capable of creating requirements for evaluating new software, detecting the actual deployment requirements of an end device, and comparing two requirements. The human mind is further able to determine such requirements based on the interplay between different layers of software. The process does not require specific data structures, nor do the claims describe a process requiring specific data structures or modified data structures. The claims merely specify “requirements specification” which does not have to have any specific format.
Applicant further argues:
In addition, even if the current claims were interpreted to recite an abstract idea, the claims would still be patent eligible as "the claim as a whole integrates the recited judicial exception into a practical application of the exception" (84 Fed. Reg. at 54-55 (citing MPEP 2106.05(a)-(c), (e)-(h)). More specifically, under step 2A - Prong 2 of the eligibility analysis, claim 16, as a whole, integrates any judicial exception into a practical application. Rather than only generally linking a judicial exception to a particular technological environment or field that does not impose any meaningful limits on the abstract idea, the limitations of claim 16 include a new combination of steps in a process that provides an improvement to the technological field of automatic installation and updating of software on an end device. Accordingly, the claims "[incorporate] rules of a particular type that [improve] an existing technological process" with a high degree of specificity and are not directed to an abstract idea (see MPEP 2106(II)).
[See Remarks – Page 12]
Examiner’s response:
Examiner respectfully disagrees. Additional non-mental claims are not specific and are not sufficient to integrate the claims into a practical application nor to amount to significantly more. As discussed in the above rejection under 35 U.S.C. 101, the transmitting steps amount to mere data transmission which does not integrate the claims into practical application nor amount to significantly more. See MPEP 2106.05(g) and MPEP 2106.05(d). The deploying step is not specific and amounts to mere instruction to apply, which does not integrate the claims into practical application nor amount to significantly more. See MPEP 2106.05(f). Claim 16 (and analogous claims) do not contain additional limitations which integrate the judicial exception into a practical application, nor amount to significantly more.
Applicant further argues:
It is noted that "software and business methods are not excluded categories of subject matter," and that "software is not automatically an abstract idea, even if performance of a software task involves an underlying mathematical calculation or relationship," as set forth in MPEP 2106.04(a). "For example, in McRO, the court relied on the specification's explanation of how the particular rules recited in the claim enabled the automation of specific animation tasks that previously could only be performed subjectively by humans, when determining that the claims were directed to improvements in computer animation instead of an abstract idea. McRO, 837 F.3d at 1313-14, 120 USPQ2d at 1100-01." (Id.)
In like manner, the current claims recite particular rules enabling an unconventional solution to the time-consuming methods of software distribution and maintenance in the prior art. As taught in at least para. [09] of the current disclosure:
According to the known art, the available testing methods are typically performed manually and do not respond to large amounts of available end devices. Consequently, such methods are not performed using automated mechanisms which can be accomplished over a network. Moreover, such methods are not available at run-time and are prone to errors as they involve significant technical effort to be performed by human operators.
As explained in at least para. [25] of the disclosure:
According to the present invention it can be defined if the requirements specification complies with the actual deployment requirements. A set of rules indicating compatibility and functionality may be provided and can likewise be specified according to the needs of the new piece of software. Such a set of rules may furthermore determine which hardware components are available within the end device and provide specifications of the supported functionality. It is also possible to perform real-time tests and check if the provided instructions of the new piece of software are able to handle the underlying hardware infrastructure.
[See Remarks – Page 12-13]
Examiner’s Response:
Examiner respectfully disagrees. The claims, as written, do not cite specific rules regarding the deployment of software, but rather merely that deployment requirements are met. The claims consist mainly of steps to determine target and software requirements, and comparing the given requirements, which may be done by the human mind. The remaining steps merely consist of data transmission steps and mere application steps, which as noted in above arguments and 35 U.S.C. 101 analysis, is not sufficient to overcome the 35 U.S.C. 101 rejection.
Applicant further argues:
The current claims are similar to those at issue in Enfish, LLC V. Microsoft Corp., 822 F.3d 1327, 1335 (Fed. Cir. 2016) as the claims overcome a problem arising in the realm of computer technology and have no pre-computer analog. The data structure of Enfish was "not simply directed to any form of storing tabular data," but instead, included a very specifically defined means for configuring a logical data table. Enfish, 822 F.3d at 1336. Here, independent claim 16 recites a particular way to configure software installation and upgrades across large numbers of devices while preventing incompatible software components from being installed on an end device which would harm or destroy the same. As the Enfish court found that "the plain focus of the claims is on an improvement to computer functionality itself, not on economic or other tasks for which a computer is used in its ordinary capacity," the improvement recited in the current claims and described in the disclosure is similarly patent eligible. Enfish, 822 F.3d at 1336.
Thus, the disclosed method is used to reduce problems of software compatibility during installation and distribution by causing software items to be stored and distributed in a more favorable manner. As such, the invention is directed to an improvement in computer operation rather than an improvement of a task that is performed on a computer (i.e., it is improving the manner in which the system installs the file system items), and overcomes a problem specifically arising in the realm of computer networks, and thus, "the claimed solution is necessarily rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks," and, accordingly, the claims are not directed to an abstract idea. DDR Holdings, LLC V. Hotels.com, L.P., 773 F.3d 1245, 1257 (Fed. Cir. 2014); see also MPEP § 2106.05(a).
For at least the reasons discussed above, claims 16-18 and 20-29 are directed to patent eligible subject matter.
[See Remarks – Pages 13-14]
Examiner’s Response:
Examiner respectfully disagrees. As discussed above in the arguments and the rejection under 35 U.S.C. 101, the current claims are directed mainly to a mental process, to which a generic computer is applied. The claimed solution may be completed in the human mind (as noted by applicant, previous solutions completed the process manually) and only generic computer processes are applied to the judicial exception. Therefore, the rejection under 35 U.S.C. 101 is maintained.
Regarding the rejection under 35 U.S.C. 103, Applicant argues:
As amended, independent claim 16 requires that transmitting said requirements specification is performed along with transmitting the new piece of software to the end device. There is no similar teaching or suggestion derivable from the combination of Morley and Ningombam.
In the rejection, Morley is relied on for finding a teaching of an application checker which identifies and isolates incompatible applications on a mobile device during a platform update. After receiving a target platform version number from an update server, the application checker generates a list of installed applications on the mobile device. As can be seen from Fig. 2 of Morley, the App Checker obtains only a target platform version number from the Update Server in step S220, such that there is no teaching that the new piece of software is transmitted along with requirements specification to the end device, as required by amended claim 16.
In view of this deficiency, the rejection relies on Ningombam for finding a teaching of transmitting a requirements specification is performed along with transmitting a new piece of software to the end device, such that it would be obvious to modify the method of Morley according to Nongombam.
Specifically, Ningombam is relied on for finding a patch analysis computer which retrieves from a website, metadata describing one or more patch files to be used to change software in one or more target computers. According to Ningombam, prior to installation of the patch files in a target computer, the patch analysis computer performs analysis on the patch files and on the target computer and on application of the patch files to the target computer. The analysis is based on the retrieved metadata and based on configuration data of the target computer and based on configuration data of the target computer.
According to Ningombam, the management computer displays a report resulting from the analysis including one or more operations to fix issues found during analysis, and receives input from a human on specific patch files and operations. In response to receipt of this human input, the patch analysis computer of Ningombam performs operations approved by the human and applies the patch files to the target computer.
In contrast to the cited prior art, amended claim 16 requires that transmitting said requirements specification is performed along with transmitting the new piece of software to the end device. As taught in at least para. [27] of the current disclosure:
…
There is no similar teaching or advantage derivable from the combination of Morley and Ningombam.
For at least the reasons discussed above, amended claim 16 is patentable over the combination of Morley and Ningombam.
Claim 27 is amended similarly as claim 16 and is at least patentable for the same reasons discussed above.
[See Remarks – Pages 15-16]
Examiner’s Response:
Examiner respectfully disagrees. While Examiner agrees that Morley does not explicitly disclose “wherein the transmitting said requirements specification is performed along with transmitting the new piece of software to the end device”, Examiner does not agree that Ningombam fails to teach this limitation. Ningombam discloses in 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” and in 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”. Metadata may be regarded as requirements for a patch and a patch may be regarded as the new piece of software. As taught in Paragraph [0030], both may be sent to the corresponding target computer together in an update. Therefore, the rejection of claim 16 under 35 U.S.C. 103 is maintained, as well as that of claim 27 for the stated reasons.
Regarding the rejection under 35 U.S.C. 103 of the new claims, Applicant argues:
New dependent claim 30 is added to the claims depending from claim 16 and requiring that 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. The new claim is supported in at least paras. [10], [25] and [29] of the disclosure.
New claim 30 is at least patentable based on dependency from claim 16 and further in view of the added limitation, which is not disclosed or suggested in the cited prior art.
New independent claim 31 is added to the claims including the limitations of previous claim 16 and more particularly requiring detecting actual deployment requirements on the end device and comparing the transmitted requirements specification with the detected actual deployment requirements automatically in real-time. The new claim is supported in at least paras. [10], [25] and [29] of the disclosure.
As relied on in the rejection of claim 16, Morley teaches that application compatibility is determined based on empirical whitelist and blacklist databases of other mobile devices, for example as explained in at least paras. [0031] and [0040-41] of Morley. However, the approach of Morley differs from the method of claim 31, where eligibility is determined based on analysing internal software structures of the mobile device at issue and deriving a specific internal hierarchical software structure for determining eligibility automatically in real-time.
Similar to the deficiency of Morley, Ningombam teaches in at least paras. [0015] and [0038-40] that the patch analysis receives manual input from a human on specific patch files and operations. As such, the method of Ningombam shares the deficiencies taught in the current disclosure at para. [09]:
According to the known art, the available testing methods are typically performed manually and do not respond to large amounts of available end devices. Consequently, such methods are not performed using automated mechanisms which can be accomplished over a network. Moreover, such methods are not available at run-time and are prone to errors as they involve significant technical effort to be performed by human operators.
In contrast to the cited prior art, new claim 31 requires detecting actual deployment requirements on the end device and comparing the transmitted requirements specification with the detected actual deployment requirements automatically in real-time. Particularly where 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.
According to the present disclosure, operation of the upper software layer depends on the new piece of software and the upper software layer may comprise applications or system functions that require capabilities provided by the new piece of software. On the other hand, operation of the new piece of software depends on the lower software layer. The lower software layer may comprise applications, system functions or hardware access that provides capabilities to the new piece of software.
If and when a software installed on the end device exhibits the specific hierarchical software structure, eligibility of the new piece of software comprises two separate aspects, eligibility of the new piece of software in relation to the upper software layer and eligibility of the new piece of software in relation to the lower software layer, wherein the eligibility is determined automatically in real-time.
There are no similar teachings or suggestions derivable from the cited prior art, and new independent claim 31 is accordingly patentable over the combination of Morley and Ningombam.
[See Pages 17-19]
Examiner’s Response:
Examiner respectfully disagrees. In regards to Applicant’s argument that claim 30 should be allowable for being based on an allowable claim 16, claim 16 is further rejected under 35 U.S.C. 103. See Rejection under 35 U.S.C. 103 and above arguments.
Regarding the argument that “Morley teaches that application compatibility is determined based on empirical whitelist and blacklist databases of other mobile devices, for example as explained in at least paras. [0031] and [0040-41] of Morley. However, the approach of Morley differs from the method of claim 31, where eligibility is determined based on analysing internal software structures of the mobile device at issue and deriving a specific internal hierarchical software structure for determining eligibility automatically in real-time”, the claims, as presented, do not require that specific internal software structures are analyzed or derived from specific internal hierarchical software structures and compared in real-time, but rather just that detecting actual deployment requirements and a comparison of the requirements documents to the deployment requirements is done in real time. To this end, Morley discloses in Paragraph [0050], “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”. In combination with previous citations regarding the comparison and derivation of deployment requirements, Morley discloses that the process of checking and updating requirements is done in real-time. Therefore, at least Morley discloses the newly cited limitation and the rejection of claim 31 under 35 U.S.C. 103 is proper and maintained.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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