DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
1. Claims 1-23 are presented for the examination.
§ 101 2. 35 U.S.C. 101 reads as follows
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As to Claims 1, 8, 15 are rejected under 35 USC 101 for abstract idea without significantly more. Under Step 2A, Prong 1, the “ determining, based on the request and an API stability index, a current state of the API, determining, based on the update and the current state of the API ” recite a mental process since “determining” is functions that can be reasonably performed in the human mind with the aid of pen and paper through observation, evaluation, judgment, opinion.
Under Prong 2, the additional element “ execution of the update would change the current state of the API to a first state, wherein the first state is less- stable than the current state; and causing, by the management device, based on the determination that execution of the update would change the current state of the API to the first state, execution of the update by the implementation device to be denied ” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic computer or generic computer components to perform the judicial exception, 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. See MPEP 2106.05(f).
Under Step 2B, the additional elements “ execution of the update would change the current state of the API to a first state, wherein the first state is less- stable than the current state – this is mere instructions to apply the mental process under MPEP 2106.05(f) ;
and causing, by the management device, based on the determination that execution of the update would change the current state of the API to the first state, execution of the update by the implementation device to be denied- this generally is a mental process although the management device and implementation device could be a generic computer component, the spec describes they are software in actual computer hardware” amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
4. The claim does 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. See MPEP 2106.05(d). Thus, the claim is not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
2. Claim(s) 1-5, 8-12, 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over YANG(CN 106648557 A) in view of Zuerner(US 20180139109 A1) in view of RAUNDAHL(WO 2011072970 A1) and further in view of Kaminsky( US 20040117783 A1).
As to claim 1, Yang teaches determining, based on the request and an API stability index, a current state of the API( one of the API providers subscribing to the API in the target user API provider....when the user subscription API, condition of interest can be selecting the statistics as sub statistic condition. Further, the user can set the weight of every sub statistic condition. For example, the statistic condition comprises call times x in unit time in unit time success rate m, response speed v, the user can set the value of x is 50%, the weight is 30%, the weight value of v is 20%. Of course, the user can according to the actual need to adjust the weight of each sub statistic condition, Sec: S51, ln 2-43/ one optional embodiment, the network server when obtaining the statistic condition, can obtain target user recommended index for the API of the target type, network server then sends API recommended index greater than or equal to the weighted average of the target type is determined to be the reference API. wherein the recommendation index is one standard measure excellent API, if the recommended index greater than or equal to the weighted average of the API, such API is can be considered as excellent API, sec: step S53, ln 2-24/Figure: 5/ the recommendation index is stability index since the index is used to determine API is excellent API as described above).
Yang does not teach receiving a request for an implementation device to perform an update to an Application Program Interface (API) causing, based on the current state of the API, performance of the update by the implementation device to be blocked. However, Zuerner teaches receiving by a management device a request for an implementation device to execute an update to an Application Program Interface (API) causing, based on the current state of the API, performance of the update by the implementation device to be blocked( FIG. 13 is a diagram of an example process 1300 for changing APIs used to provide a network service. In some implementations, process 1300 may be implemented by API controller 340. Process 1300 may include receiving a request to modify an existing network service (block 1310). For example, API controller 340[ a management device ] may receive a request from an SDN node (such as OSS OSS/BSS 355) to change an existing network service. Process 1300 may include determining whether changes to an API chain are required (block 1320). For instance, in response to the request to modify the network service, API controller 340 may analyze the request to determine whether changes to the API chain of the existing network service will be modified[first state]. In some implementations, API controller 340 may determine this by, for example, comparing the request for the existing network service with the request to modify the network service. In some implementations, API controller 340 may determine whether the API chain should be updated by determining a new API chain for the request to modify the network services and comparing the new API chain with the API chain associated with the existing network services. In some implementations, API controller 340 may determine the new API chain in a manner similar to that described above with reference to FIGS. 7-10.When changes to the API chain are not required (block 1330—No), process 1300 may include indicating that no API changes are required[update by the implementation device to be blocked] for the network service (block 1340). For example, when changes to the API chain are not required, API controller 340 may respond to the request (e.g., OSS/BSS 355) by indicating that the API chain for the existing network service is applicable to the network services being modified[first state ]… When changes to the API chain are required (block 1330—Yes), process 1300 may include updating[the implementation device] the API chain for the network service (block 1350). For example, API controller 340 may modify the API chain in accordance with the modification to the network services ….The manner in which the API chain is updated may depend on the original API chain and the modifications to the network services. In some implementations, the original API chain may undergo isolated changes (e.g., the addition, replacement, or removal[the implementation device] of a single API or service resource locator). In some implementations, the original API chain may undergo complex changes, where multiple APIs (and/or or service resource locators) in the original API chain are added, replaced, or removed[the implementation device] (e.g., the introduction of one new API may require other APIs to be changed and/or new service resource locators to be provided in the API chain), para[0086] to para[0090]/ Fig. 13 ).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Yang with Zuerner to incorporate the feature of receiving a request for an implementation device to perform an update to an Application Program Interface (API) causing, based on the current state of the API, performance of the update by the implementation device to be blocked because this includes implementing application program interfaces (APIs) that enable functions and devices, within the network, to communicate with one another.
Yang and Zuerner do not teach determining, based on the update and the current state of the API, that execution of the update would change the current state of the API to a first state, wherein the first state is less-stable than the current state; and causing, by the management device, based on the determination that execution of the update would change the current state of the API to the first state, execution the update by the implementation device to be denied. However, Raundahl teaches determining, based on the update and the current state of the API, that execution of the update would change the current state of the API to less-stable than the current state; and causing, by the management device, based on the determination that execution of the update would change the current state of the API to the first state, execution the update by the implementation device to be denied(when a client of the first version[API] invokes a method, col 24, n 23-24/the approach also supports updates of component APIs[API] breaking[the first state is less-stable than the current state] binary compatibility with their previous version[the current state]. We use the well-known and simple example of adding a parameter to an existing method as an example. public void createlnstance(String name, int ID) {...} public void createlnstance(String name, int ID, String description) {...} Now, trying to update the component containing the method above may result in broken clients. Therefore, a static dependency verifier[ management device] locates such incompatible component[API] changes before performing the update. If it does not find any incompatibilities[the first state is less-stable than the current state], it carries out the update of the new set of components. Otherwise[the first state is less-stable than the current state], it discards the update[implementation device denied], page 26, ln 15-32/We stress that this limitation is exactly what you get from an offline update scheme, and that it has nothing to do with how the updates are carried out. Any attempt to introduce smarter mechanisms for allowing updates of binary incompatible changes will break programmer transparency[the first state is less-stable], page 27, ln 3-8/ the present invention provides dynamic update by performing transformation on the byte-code of class definitions that enables them to be updated dynamically. Updating of classes takes effect at the granularity level of modules. Changes that do not break module API compatibility with previous running versions have no impact beyond the module itself. The ones that violate the binary compatibility rules [2] expand the update set to also include new API compatible module versions for all running dependents. Changes during updating may include; changing method bodies, add Ing/removing methods, adding/removing constructors, adding/removing fields, adding/removing classes, changing interfaces, replacing superclass, adding/removing implemented interfaces, and transparent object state migration, while ensuring type-safety of the update class definitions and its coexisting dependent in different versions of the running software, page 16, ln 10-122/ Now referring to Fig 3, an illustration of how incoming requests to 304 are intercepted by the component API[API] depicted by 308 and forwarded to 310. This forwarding cannot happen through direct, col 21, ln 20-25/ implementing for each class[API] a common API defined by the framework) , page 6, ln 3-5/ page 20, ln 9-20/ if no other classes depend on a field or method it may be removed. Similarly, changes to a class’s type can be made as long as these changes do not cause type violations with the class’s dependents. As their new dynamic class loader does not support transitive loading of classes causing type violations[the first state is less-stable than the current state], their method is limited[denied] to dynamic update of a single class[ape] at a time, which is to restricting a change scope for any non-trivial software update, page 3, ln 10-19/ the method JDrums, that extends a Java Virtual Machine with the ability to update[implementation device] classes while a program is running, para[8], ln 1-3/ implementing for each class a common API defined by the framework, para[11], ln 8-10/ causing, based on determination that change the current state of the API to less-stable state than the current state by the management device, execution the update by the implementation device to be denied since the verifier [management device ]locate the update and determines the updated of API is incompatibilities[is less-stable than the current state], the update[implementation device] the api is denied as described above. ).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Yang and Zuerner with Raundahl to incorporate the feature of determining, based on the update and the current state of the API, that execution of the update would change the current state of the API to a first state, wherein the first state is less-stable than the current state; and causing, by the management device, based on the determination that execution of the update would change the current state of the API to the first state, execution the update by the implementation device to be denied because this ensures that the updating of a set of classes is done atomically, to avoid binary incompatibilities, due to changes in the type of the former version and the new version of a class, which will cause runtime failures and bring the whole system to a stop.
Zuerner teaches management/implement device ( API controller 340[ a management device ] may receive a request from an SDN node (such as OSS OSS/BSS 355) to change an existing network service. Process 1300 may include determining whether changes to an API chain are required (block 1320). For instance, in response to the request to modify the network service, API controller 340 may analyze the request to determine whether changes to the API chain of the existing network service will be modified[first state]. In some implementations, API controller 340 may determine this by, for example, comparing the request for the existing network service with the request to modify the network service. … process 1300 may include updating[the implementation device] the API chain for the network service (block 1350), para[0086] to para[0090]/ Fig. 13
Raundahl teaches management/implement device( In the example given the verifier will find a removed API-method change. It[management device] then tries to locate updates to client components and checks[determination] the compatibility with the updated set of client components….. the method JDrums, that extends a Java Virtual Machine with the ability to update[implementation device] classes while a program is running, para[8], ln 1-3/ implementing for each class a common API defined by the framework, para[11], ln 8-10).
Kaminsky teaches the management device separated from the implementation device for updating (In the context of an application installation meant to upgrade[update] the components of an application, oftentimes, simply replacing[update] application out-dated versions of application components with newer versions of components will not alone suffice as a complete application upgrade, Rather, in an era of code re-use, shared libraries, and interdependent program objects, replacing a single application component can have a dramatic effect upon other separate, but independent applications. Common disastrous consequences include altered and now incompatible application programming interfaces (APIs), para[0005], ln 1-14/ FIG. 1, / the dependency management system can include a development environment 120 in which application components can be created and modified, para[0031], ln 3-6/ as an autonomic installation process 150 prepares to install[update] the application, including the upgraded application component or components 130, para[0033], ln 1-3/whereas the development environment 120 can manage[management] the entirety of an application formed from many independent and interdependent application components, the development environment 120 can track those application components which are dependent upon both the publicly accessible data members of the upgraded component or components 130, and also the publicly accessible method members of the upgraded component or components 130. In this way, once the upgraded component or components 130 of the application have been completed, the development environment 120 can produce a machine readable ReadMe file 140 into which the development environment 120 can record the identity of those application components which have changed, any new dependencies which have been created by virtue of the changed component or components 130, and any alterations to the API by virtue of the changed component or components 130, para[0032], ln 1-21/ machine readable ReadMe file processor[management] can be coupled to the autonomic installer and configured to identify the required ones of said publicly accessible data and methods implementations. Notably, the machine readable ReadMe file can be an XML formatted file, para[0019], ln 11-16/ the development environment 120[management device] can produce a machine readable ReadMe file 140 into which the development environment 120 can record the identity of those application components which have changed, any new dependencies which have been created by virtue of the changed component or components 130, and any alterations to the API by virtue of the changed component or components 130. , para[0032], ln 10-17/ a machine readable ReadMe file can be created in which dependencies associated with upgrade information regarding an upgrade installation of an application can be listed. The upgrade information can include a listing of system components which have changed, new dependencies created by the system components, altered[update] APIs and the like. In a preferred aspect of the present invention, the listings within machine readable ReadMe file can be formatted with markup language tags such as XML tags so as to facilitate the portability of the machine readable ReadMe file, para[0027], ln 3-15/determine[causing] from the machine readable ReadMe file 140[which causing the update or not update] whether any of the application API has changed so as to "break" a dependent application component. In the event that a mismatch has been detected between the form of the API expected by the dependent application component and the new form of the API, an upgrade to the dependent application can be located which might demonstrate better compatibility with the new form of the API. If an upgrade can be located, the autonomic installation process 150 can proceed to process[update] the installed components 160[ Fig 3. Step 385 of perform update] . Otherwise, if an upgrade cannot be located, again the installation can terminate gracefully, para[0035]/ In block 310, the machine readable ReadMe file can be reviewed to identify externally defined public data which will be required by the upgraded application component or components….In decision block 380, if an updated version of the dependent component cannot be located and loaded, in block 390 the installation can be aborted[update denied/ Fig. 3 step 390 of abort update] and a failure record can be forwarded to an administrative entity. Otherwise, in block 385, the installation of the upgraded component or components can proceed to completion, para[0040, ln 6-11 to para[0044], ln 1-7/ Fig. 3/ Kaminsky teach the development environment[management device] causes the installer device[implement device] to deny the update by creating and storing changed record to readable Read me file that makes the installer device to deny the update therefore , development environment, atomic installer and readme file are separated as described above/ Fig.1 ).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Yang and Zuerner and Raundahl with Kaminsky to incorporate the above feature because this ensures the operability of the upgraded application components, while further assuring that the upgraded application components will not "break" other application components in the system
As to claim 2, Zuerne teaches the current state of the API comprises an experimental state, and wherein causing performance of the update by the implementation device to be blocked comprises causing the implementation device to deny a code commit comprising the update( para[0090]) and Ershov teaches current state of the API comprises an experimental state indicating the API is one or more of: under development or operating below a performance threshold, wherein the first state comprises a state that is less stable than the experimental state( para[0041], ln 5-17) for the same reason as to claim 1 above.
As to claim 3, Zuerner teaches determining that the current state of the API comprises the experimental state based on at least one of: determining, based on at least one attribute in the API stability index associated with the API, that the API is under development; determining, based on the at least one attribute in the API stability index, that the API is operating below a performance threshold; or determining, based on the at least one attribute in the API stability index, that the API is to be removed, disabled, or deprecated( para[0090] ) and Ershov teaches wherein the first state comprise an experimental state, wherein the code commit would cause the current state of the API to change to the experimental state( para[0025]) for the same reason as to claim 1 above.
As to claim 4, Yang teaches wherein the current state of the API comprises a stable state( Sec: S53, ln 1-12) , Zuerner teaches causing performance of the update by the implementation device to be blocked comprises causing the implementation device to deny a code commit comprising the update( para[0089], ln 1-20) for the same reason as to claim 1 above.
As to claim 5, Yang teaches determining that the current state of the API comprises the stable state based on at least one of: determining, based on at least one attribute in the API stability index associated with the API, a reliability of the API indicative of the stable state; determining, based on the at least one attribute in the API stability index, that the API is not subject to an API revision; or determining, based on the at least one attribute in the API stability index, that the API is operating at or above a performance threshold(Sec: S53, ln 1-12) .
As to claim 8, it is rejected for the same reason as to claim 1 above. In additional, Zuerner teaches processor( Processor 1420 may include a processor, microprocessor, or processing logic that may interpret and execute instructions, para[0094], ln 2-5) for the same reason as to claim 1 above.
As to claims 9, 10, 11, 12, 16, 17, 18, 19, they are rejected for the same reasons as to claims 2, 3 , 4, 5 above.
As to claim 15, it is rejected for the same reason as to claim 1 above. In additional, Zuerner teaches processor, client, a management device (Processor 1420 may include a processor, microprocessor, or processing logic that may interpret and execute instructions, para[0094], ln 2-5/ As shown, process 1100 may include receiving a request for a network service from an SDN node (block 1110). For example, API controller 340 may receive, from OSS/BSS 355, a request for a network service, para[0073], ln 1-10 ).
3. Claim(s) 6, 7, 13, 14, 20 are rejected under 35 U.S.C. 103 as being unpatentable over YANG(CN 106648557 A) in view of Zuerner(US 20180139109 A1) view of RAUNDAHL(WO 2011072970 A1) in view of Kaminsky( US 20040117783 A1) and further in view of QIU(WO 2017157202 A1).
As to claim 6, Zuerner teaches wherein causing performance of the update by the implementation device to be blocked comprises causing the implementation device to deny a code commit comprising the update( para[0089], ln 1-20) and Raundahl teaches wherein the first state comprise an experimental state or a stable state, wherein the code commit would cause the current state of the API to change to the experimental state or the stable state( page 26, ln 15-32 ) for the same reason as to claim 1 above .
Yang, Zuerner, Raundahl and Kaminsky do not teach the current state of the API comprises a locked state. However, QIU teaches the current state of the API comprises a locked state( Optionally, a 1 in a binary bit string describing the access authority indicates that the performer has an access right to a corresponding category system call, 0 means no, sec: summary, ln 50-60).
It would have been obvious to one of the ordinary skill in the art before the effective filling date of claimed invention was made to modify the teaching of Yang, Zuerner , Raundahl and Kaminsky with QIU incorporate the feature of API comprises a locked state because this obtains the access rights of the performer to each category system call.
As to claim 7, Qiu teaches determining that the current state of the API comprises the locked state based on at least one of: determining, based on at least one attribute in the API stability index associated with the API, a reliability of the API indicative of the locked state; or determining, based on the at least one attribute in the API stability index, that the API is not subject to an API revision(sec: summary, ln 50-60/ Sec: Further, each system call that can be accessed by the user space, ln 1-20) for the same reason as to claim 6 above .
As to claims 13, 14, 20, they are rejected fort the same reasons as to claims 6, 7 above.
3. Claim(s) 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over YANG(CN 106648557 A) in view of Zuerner(US 20180139109 A1) view of RAUNDAHL(WO 2011072970 A1) in view of Kaminsky( US 20040117783 A1) and further in view of Leff( US 20180077038 Al).
As to claim 21, it is rejected for the same reason as to claim 1 above.
In additional, Leff teaches determining, based on a specification of the API indicated by the request, and based on the API stability index, that the update comprises a modification to at least one portion of the API that is in a locked state or a stable state, (At 604, the WSO system logs the macro-transaction state as ‘in progress’ and, at 606, logs the micro-transaction state 1 as ‘in-progress’. At 608, the system invokes micro-transaction #1 to create the ToDo on the CRM system. The result of micro-transaction #1 may be one of: success, failure, or timeout as shown at 610. For the case the result is ‘failure’, the state of micro-transaction #1 is updated to ‘failed’ as shown in 614, and the state of the macro-transaction is also updated to failed as shown in 618. For this case, since the macro-transaction has failed, the macro-transaction can optionally be re-run starting at 602,para[para[0085], ln 7-18]).
It would have been obvious to one of the ordinary skill in the art before the effective filing date of claimed invention was made to modify the teaching of Yang and Zuerner, Raundahl and Kaminsky with Leff to incorporate the feature of determining, based on a specification of the API indicated by the request, and based on the API stability index, that the update comprises a modification to at least one portion of the API that is in a locked state or a stable state because this allows the update API to be re-invoked safely when a failure occurs in the middle of processing.
As to claims 22-23, they are rejected for the same reason as to claim 21 above.
Response to the argument:
A. Applicant amendment filed on 04/24/2025 has been considered but they are not persuasive:
Applicant argued in substance that :
(1) “ Applicant respectfully traverses these conclusions.
The present claims are not directed to an abstract mental process.”.
(2) “ API stability index" to define an API's current state (e.g., experimental, stable, locked) and to make update decisions based on whether an update would downgrade that state. This is not shown in the prior art. Yang to the "API stability index" element (Office Action, pp. 4-5), but Yang's metrics and "recommendation index" serve an entirely different purpose: evaluating API quality for sharing, not measuring stability of, or updates to, an API. Yang's weighted averages determine if an API is "excellent" relative to others, not whether an API is in a stable or experimental state or how an update would affect its stability”.
(3) “ . There is no managerial device or component in Raundahl issuing a stop command to a separate execution device, for example.
……but even in Kaminsky the management side (development environment) does not directly send a deny instruction to the installer; instead, the installer reads the data and decides not to continue - there are not separate devices”.
B. Examiner respectfully disagreed with Applicant's remarks:
As to the point(1), Under Step 2A, Prong 1, the “ determining, based on the request and an API stability index, a current state of the API, determining, based on the update and the current state of the API ” recite a mental process since “determining” is functions that can be reasonably performed in the human mind with the aid of pen and paper through observation, evaluation, judgment, opinion.
Under Prong 2, the additional element “ execution of the update would change the current state of the API to a first state, wherein the first state is less- stable than the current state; and causing, by the management device, based on the determination that execution of the update would change the current state of the API to the first state, execution of the update by the implementation device to be denied ” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic computer or generic computer components to perform the judicial exception, 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. See MPEP 2106.05(f).
Under Step 2B, the additional elements “ execution of the update would change the current state of the API to a first state, wherein the first state is less- stable than the current state – this is mere instructions to apply the mental process under MPEP 2106.05(f) ;
and causing, by the management device, based on the determination that execution of the update would change the current state of the API to the first state, execution of the update by the implementation device to be denied- this generally is a mental process although the management device and implementation device could be a generic computer component, the spec describes they are software in actual computer hardware” amounts to merely generally linking the use of the judicial exception to a particular technological environment or field or use, and is merely applying the judicial exception, therefore, does not amount to significantly more, hence, cannot provide an inventive concept.
The claim does 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. See MPEP 2106.05(d). Thus, the claim is not patent eligible.
As to the point(2), the feature “ API stability index" to define an API's current state (e.g., experimental, stable, locked) ” was not in the claim , Claim does not required to use the API stability index to determine whether to update the API.
However, Yang teaches one of the API providers subscribing to the API in the target user API provider....when the user subscription API, condition of interest can be selecting the statistics as sub statistic condition. Further, the user can set the weight of every sub statistic condition. For example, the statistic condition comprises call times x in unit time in unit time success rate m, response speed v, the user can set the value of x is 50%, the weight is 30%, the weight value of v is 20%. Of course, the user can according to the actual need to adjust the weight of each sub statistic condition, Sec: S51, ln 2-43/ one optional embodiment, the network server when obtaining the statistic condition, can obtain target user recommended index for the API of the target type, network server then sends API recommended index greater than or equal to the weighted average of the target type is determined to be the reference API. wherein the recommendation index is one standard measure excellent API, if the recommended index greater than or equal to the weighted average of the API, such API is can be considered as excellent API, sec: step S53, ln 2-24/Figure: 5/ the recommendation index is stability index since the index is used to determine excellent API as described above).
As to the point(3), The feature “ management side directly send a deny instruction to the installer” was not in the claims. The claims do not required to have management side to send the deny instruction to implement device. However, Kaminsky teach the development environment[management device] causes the installer device[implement device] to deny the update by creating and storing changed record to readable Read me file that makes the installer device to deny the update therefore , development environment, atomic installer and readme file are separated as described above/ Fig.1 as described below.
Kaminsky teaches the management device separated from the implementation device for updating (In the context of an application installation meant to upgrade[update] the components of an application, oftentimes, simply replacing[update] application out-dated versions of application components with newer versions of components will not alone suffice as a complete application upgrade, Rather, in an era of code re-use, shared libraries, and interdependent program objects, replacing a single application component can have a dramatic effect upon other separate, but independent applications. Common disastrous consequences include altered and now incompatible application programming interfaces (APIs), para[0005], ln 1-14/ FIG. 1, / the dependency management system can include a development environment 120 in which application components can be created and modified, para[0031], ln 3-6/ as an autonomic installation process 150 prepares to install[update] the application, including the upgraded application component or components 130, para[0033], ln 1-3/whereas the development environment 120 can manage[management] the entirety of an application formed from many independent and interdependent application components, the development environment 120 can track those application components which are dependent upon both the publicly accessible data members of the upgraded component or components 130, and also the publicly accessible method members of the upgraded component or components 130. In this way, once the upgraded component or components 130 of the application have been completed, the development environment 120 can produce a machine readable ReadMe file 140 into which the development environment 120 can record the identity of those application components which have changed, any new dependencies which have been created by virtue of the changed component or components 130, and any alterations to the API by virtue of the changed component or components 130, para[0032], ln 1-21/ machine readable ReadMe file processor[management] can be coupled to the autonomic installer and configured to identify the required ones of said publicly accessible data and methods implementations. Notably, the machine readable ReadMe file can be an XML formatted file, para[0019], ln 11-16/ the development environment 120[management device] can produce a machine readable ReadMe file 140 into which the development environment 120 can record the identity of those application components which have changed, any new dependencies which have been created by virtue of the changed component or components 130, and any alterations to the API by virtue of the changed component or components 130. , para[0032], ln 10-17/ a machine readable ReadMe file can be created in which dependencies associated with upgrade information regarding an upgrade installation of an application can be listed. The upgrade information can include a listing of system components which have changed, new dependencies created by the system components, altered[update] APIs and the like. In a preferred aspect of the present invention, the listings within machine readable ReadMe file can be formatted with markup language tags such as XML tags so as to facilitate the portability of the machine readable ReadMe file, para[0027], ln 3-15/determine[causing] from the machine readable ReadMe file 140[which causing the update or not update] whether any of the application API has changed so as to "break" a dependent application component. In the event that a mismatch has been detected between the form of the API expected by the dependent application component and the new form of the API, an upgrade to the dependent application can be located which might demonstrate better compatibility with the new form of the API. If an upgrade can be located, the autonomic installation process 150 can proceed to process[update] the installed components 160[ Fig 3. Step 385 of perform update]. Otherwise, if an upgrade cannot be located, again the installation can terminate gracefully, para[0035]/ In block 310, the machine readable ReadMe file can be reviewed to identify externally defined public data which will be required by the upgraded application component or components….In decision block 380, if an updated version of the dependent component cannot be located and loaded, in block 390 the installation can be aborted[update denied/ Fig. 3 step 390 of abort update] and a failure record can be forwarded to an administrative entity. Otherwise, in block 385, the installation of the upgraded component or components can proceed to completion, para[0040, ln 6-11 to para[0044], ln 1-7/ Fig. 3/ Kaminsky teach the development environment[management device] causes the installer device[implement device] to deny the update by creating and storing changed record to readable Read me file that makes the installer device to deny the update therefore , development environment, atomic installer and readme file are separated as described above/ Fig.1 ).
THIS ACTION IS MADE FINAL. 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.
Conclusion
US 20150169386 A1 teaches Compatibility program 124 can also check client program 122 configuration information to determine whether client program 122 is newer than the server program. In an embodiment, the configuration information contains mapped information, which maps a new version of the required API method to the old version. If compatibility program 124 determines, for example, the client program 122 is newer than the server program 134, the mapped information allows compatibility program 124 to determine if there is a compatible alternative version of the required API method available.
US 11522700 B1 teaches a “print” function, which is another example of a state modifying function, that when called allows for the creation of additional Stable Value Tokens into the totalSupply of Stable Value Tokens; and (5) a “burn” function, which is also another example of a state modifying function, that when called allows for the destruction of previously created Stable Value Token from the total Supply of the Stable Value Tokens.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LECHI TRUONG whose telephone number is (571)272-3767. The examiner can normally be reached 10-8 PM.
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 Young Kevin can be reached on (571)270-3180. 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.
/LECHI TRUONG/ Primary Examiner, Art Unit 2194