DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Remarks page 12-13, Applicant contends:
Amended claims include the training of the machine learning model in a closed environment, which Duggan does not teach.
Response:
Applicant’s arguments with respect to claim(s) 1 have been considered but are moot because the new ground of rejection contain elements that have not been previously examined or does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Remarks page 12-13, Applicant contends:
Duggan does not teach “creating metadata indicative of a training environment of the training system and linking the meta data to the machine learning model”
Response:
Applicant notes the paragraphs 32 to 37 of the specification of the current application in reference to why Duggan’s teachings are distinguished from what is taught in the claims. Paragraphs 32 to 37 cover the ideas of creating metadata that can contain dependencies of a training environment that are linked to a machine learning model trained in said environment. Duggan teaches the creation of metadata and the linking of metadata (storing metadata of the analytical model (Duggan Figure 4 408)). Figure 4 of Duggan notes receiving a selection of an analytical model, training the model, then storing the model and the model’s metadata. Storing the metadata shows metadata was created, as none of the previous steps note receiving metadata of the model, thus what metadata that is being stored was implied to have been created. The metadata is linked to the model as the metadata stores data related to the model and is noted to store parts related to training, such as error rate ([Duggan Column 6, Line 66]: “The model metadata 328 may include, for example, model approach metadata 330, model parameters metadata 332, input variables metadata 334, model storage location metadata 336, results storage location metadata 338, error rate metadata 340, and model state metadata 342. Other types of model metadata may also be stored as part of the model metadata 328 such as, for example, analytical model subclass metadata, analytical model type metadata, output variables metadata, date metadata, update history metadata, and version metadata.”).
The current specification also supports the idea of dependencies being meta data, thus reinforcing the idea that the dependencies shown in Duggan (such as in Figure 10 of Duggan) teach the metadata in the current application ([Current Specification 0029]: “Figure 2 shows an example document presenting one of the metadata Meta_1… Meta_N. It shows a list of packages used to train a model and their versions.”)
([Duggan Column 22, Line 64]: “The following is an example of an API call to verify that the code bundle is executable in a run time environment by inspecting 1) it has all dependencies and 2) the dependencies do not conflict. This may correspond to steps 1006, 1008, and 1010 of FIG. 10. The following example verifies the code bundle for a Spark YARN environment, but this can be extended to verify the code bundle for any target environment. In the first example, the code bundle is verified...”)
The quote above shows that information related to the environment and the dependencies of the machine learning model is taught by Duggan. The dependencies are seen as related to the training environment, as the requirements to run the model in the deployment environment are seen as the same as the requirements or dependencies to run the model in the training environment. This means the idea is to make the environments closer to each other. Duggan also teaches that information is gathered around the training of the model.
[Duggan Column 6, Line 66]: “The memory 206 may also store model metadata 328. In one embodiment, the model metadata 328 stored on the memory 206 operates as the model metadata storage database 112 or as another metadata store 242 shown in FIG. 2. In another example, the model metadata 328 shown in FIG. 3 may be stored in another location, such as metadata store 242. The model metadata 328 may include, for example, model approach metadata 330, model parameters metadata 332, input variables metadata 334, model storage location metadata 336, results storage location metadata 338, error rate metadata 340, and model state metadata 342. Other types of model metadata may also be stored as part of the model metadata 328 such as, for example, analytical model subclass metadata, analytical model type metadata, output variables metadata, date metadata, update history metadata, and version metadata. The model metadata 328 may be stored in a persistent cache for fast access.”
The quote above from Duggan notes some metadata includes information that can be associated with training or during training of the model, such as update history, version, and error rate metadata. Metadata, such as the model storage location metadata, also provides metadata information related to the location of the model. The combination of the above quotes shows that Duggan teaches aspects of metadata is related to the training period and information about the training environment of the machine learning model.
Aspects related to release numbers are shown by Duggan by showing that a comparison of versions can be made to determine an incompatibility ([Duggan Column 23, Line 40]: “In the next API call example, the verification returns false because the dependencies in the code bundle conflict. [and release numbers of the one or more libraries (the conflict is a version error, as noted by below post)] A Request (POST) may be as follows:
curl -X POST -H ‘Content-Type:application/json’ -d ‘{ “classPath”: “com.Sample” }’ 52.23.153.208:8080/v1/verify/version-error-sample-1.0.jar
A Response may appear as follows:
{ “message”: [ “Version conflicts in jar dependencies - no method found for JsonFactory.class” ], “status”: false } ”)
Remarks page 14, Applicant contends:
Duggan and Falko fail to teach the adapting and updating of the local environment.
Response:
Falko teaches the adaptation and updating portion of the claim limitations in combination with Duggan. Falko, describing aspects of package managers, discusses numerous elements related to the functioning of a package manager. One of the functions of a package manager involves the installation and updating of libraries/dependencies. As noted in previous claim 10 mapping, Falko specifically notes the installation of not installed libraries and the upgrading of release numbers [Falko page 94]. The client system is seen as the system that requires the environment for software installation being checked and works in combination with Duggan which teaches installation into a client system ([Duggan Figure 4 414] notes deploying the model to a compute engine which is seen as a client system).
([Falko page 94]: “First, Vestigium cycles through what is in the install queue. If the user did not set --nodep, it continues with the process. Vestigium extracts dependency information contained within a specific package’s INFO file. It creates a list of dependencies whose existence must be checked. If the latest version of a dependency is already installed then nothing needs to be added to any queues. If a dependency is not installed or is not the latest version, Vestigium adds the dependency [updating the one or more libraries of the client system, wherein updating the one or more libraries of the client system includes at least, installing uninstalled libraries on the client system], along with its latest available version [and/or downgrading or upgrading the release numbers of the one or more libraries of the client system], to depQueue.”)
The downgrading of a release number is shown by the mapping used in previous action claim 24 mapping. In the quote from [Falko 2.2.1 Directory and PATH Method] Falko notes reverting to an older version should a newer version not work, such as in the case of multiple programs depending upon one dependency and updating that dependency could create issues with some of the programs.
To help note that Falko teaches finding a version that matches the version from the client system, Falko also notes it will go to older versions if the newer one isn’t as compatible with the package ([Falko 2.2.1 Directory and PATH Method]: “Perhaps the greatest benefit to this package management technique is easily having multiple versions of packages installed on the same system. Having multiple versions of the same package allows us to quickly revert to an older version [wherein at least one of the at least two installed libraries is downgraded] if the new version does not work. This can be very handy if we update a program that other programs depend on. However, if the program has some ABI20 changes, it might require that other packages be rebuilt. If we need to use those packages more than we need to work with the new package, we change our PATH variable to give precedence to the older package.”). Falko also mentions a routine that notes what version are installed ([Falko 3.3.1 Libraries]: “Another routine is findProg, which, given a program name, returns all of the versions available for installation. Next is findInstalledProgVer, which, given a program name and version, returns whether it is installed or not.”).
Falko teaching reverting to an older version of a dependency teaches “downgrading at least one release number of the plurality of libraries of the client system”.
The notifying of a user of user using the API of the incompatibility is a new limitation. Thus Applicant’s arguments with respect to notification of a user have been considered but are moot because the new ground of rejection contain elements that have not been previously examined or does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The arguments of the applicant are not considered persuasive, thus the rejections upon the independent claims are sustained.
As the independent claims are still considered rejected, the dependent claims of the independent claims are not considered allowable for being dependent upon allowable claims.
Claim Objections
Claims 1, 16, and 20 are objected to because of the following informalities: Claim 1 recites “a client system” in “determining a compatibility of a local environment of a client system”. “a client system” is interpreted as a typo, as “a client system” was already introduced in “providing, in a client system,…”. Correction to “the client system” can help resolve the typo. Appropriate correction is required.
Claims 16 and 20 contain the same claim objection as claim 1.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 16 and 27-30 are rejected under 35 U.S.C. 101 because the claimed invention is not directed towards patentable subject matter.
Regarding claim 16:
Step 1: Is the claim directed towards a process, machine, manufacture, or composition of matter?
No, the claim is directed towards software per se.
The claim recites the following software per se:
“A computer system for deploying at a client system a machine learning model, comprising…”
The claim limitations for claim 16 do not recite any hardware for the computer system. The specification does not appear to list any hardware for “a computer system”. Hardware is given in the specification as an option, such as in paragraph 42 “In exemplary embodiments though, the methods described herein can be implemented in a (partly) interactive system. These methods can further be implemented in software 612, 622 (including firmware 622), hardware (processor) 605, or a combination thereof.”. Figure 6 notes representing a general computerized system 600, which contains hardware mentioned in paragraph 43, but no indication is given to indicate that “a computer system” is “a general computerized system”.
Regarding dependent claims of claim 16:
Dependent claims of claim 16 are rejected for being dependent upon a claim rejected under 101 for being software per se without implementing hardware.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1,3-4,6,11,16,20,22 and 26-34 is/are rejected under 35 U.S.C. 103 as being unpatentable over Duggan et al (US 10614375 B2), referred to as Duggan in this document, in further view of Falko (Package Manager: The Core of a GNU/Linux Distribution), referred to as Falko in this document, and even further in view of Polleri et al (US 20210081819 A1), referred to as Polleri in this document.
Regarding Claim 1:
Duggan teaches:
training, in a training system, a machine learning model
Duggan Figure 4 404 notes training the analytical model [training, in a training system, a machine learning model]
PNG
media_image1.png
720
607
media_image1.png
Greyscale
wherein the training system is a closed environment
[Duggan Column 6 Line 23]: “The memory 206 may also include compute engine interface instructions 314 for interfacing with the compute engine 118. The processor 204, memory 206, and compute engine interface instructions 314 may implement or work with portions of the model builder circuitry 102 and/or the model deployment circuitry 104 that interface with the compute engine 118. For example, the compute engine 118 may be a third-party cloud computing service [wherein the training system is a closed environment] or analytics service which may utilize a particular API, instruction set, or other interface, with which the compute engine interface instructions 314 may provide instructions for interaction. In one example, the compute engine 118 includes a job server to start and stop data processing jobs via Hypertext Transfer Protocol (HTTP) instructions and the compute engine interface instructions 314 may enable interaction therewith.”
The spec gives two ideas of what a closed environment is: cloud service ([Specification page 9]: "The model ML1 may be trained in a training system that is a closed environment like a cloud service and may not be exposed explicitly to end users as machine learning model objects.") and container ([Current Application 0016]: “Another solution may be closed environments such as containers with hard-coded version of libraries;”). Duggan notes teaching a cloud service for performing instructions from an API, thus under BRI Duggan teaches the utilizing of a closed environment for the training system.
creating metadata indicative of a training environment of the training system and linking the metadata to the machine learning model,
storing metadata of the analytical model [creating metadata indicative of a training environment of the training system and linking the metadata to the machine learning model,] (Duggan Figure 4 408). Further reasoning for the mapping of creating and linking metadata is given in the response to arguments.
wherein the metadata indicative of the training environment includes a list of dependent libraries, wherein the list of dependent libraries is comprised of a plurality of libraries required during training of the machine learning model
([Duggan Column 22, Line 64]: “The following is an example of an API call to verify that the code bundle is executable in a run time environment by inspecting 1) it has all dependencies [wherein the metadata indicative of the training environment includes a list of dependent libraries, wherein the list of dependent libraries (a list of dependencies is required in order to check that it has them all) wherein the list of dependent libraries is comprised of a plurality of libraries required during training of the machine learning model] and 2) the dependencies do not conflict. This may correspond to steps 1006, 1008, and 1010 of FIG. 10. The following example verifies the code bundle for a Spark YARN environment, but this can be extended to verify the code bundle for any target environment. In the first example, the code bundle is verified.
curl -X POST -H ‘Content-Type:application/json’ -d ‘{ “classPath”: “com.Sample” }’ 52.23.153.208:8080/v1/verify/project-sample-1.0.jar ”)
providing, in a client system, access to the metadata indicative of the training environment in which the machine learning model was trained to a user in response to a metadata request submitted by the user utilizing an application programming interface (API) service
([Duggan Column 22, Line 64]: “The following is an example of an API call to verify that the code bundle is executable in a run time environment by inspecting 1) it has all dependencies and 2) the dependencies do not conflict [providing, in a client system, access to the metadata indicative of the training environment in which the machine learning model was trained to a user in response to a metadata request submitted by the user utilizing an application programming interface (API) service]. This may correspond to steps 1006, 1008, and 1010 of FIG. 10. The following example verifies the code bundle for a Spark YARN environment, but this can be extended to verify the code bundle for any target environment. In the first example, the code bundle is verified.”)
It is noted that dependency data is metadata in the specification of current invention ([Current Specification 0029]: “Figure 2 shows an example document presenting one of the metadata Meta_1… Meta_N. It shows a list of packages used to train a model and their versions.”)
Figure 10 shows verification, thus inspection of the metadata, is done before deployment or downloading of the model (Duggan Figure 10 1006 to 1010 are before 1014).
PNG
media_image2.png
617
313
media_image2.png
Greyscale
and release numbers of the plurality of libraries
([Duggan Column 23, Line 40]: “In the next API call example, the verification returns false because the dependencies in the code bundle conflict. [and release numbers of the plurality of libraries (the conflict is a version error, as noted by below post)] A Request (POST) may be as follows:
curl -X POST -H ‘Content-Type:application/json’ -d ‘{ “classPath”: “com.Sample” }’ 52.23.153.208:8080/v1/verify/version-error-sample-1.0.jar
A Response may appear as follows:
{ “message”: [ “Version conflicts in jar dependencies - no method found for JsonFactory.class” ], “status”: false }
”)
The paragraph from [Duggan Column 6, Line 66]:
“The memory 206 may also store model metadata 328. In one embodiment, the model metadata 328 stored on the memory 206 operates as the model metadata storage database 112 or as another metadata store 242 shown in FIG. 2. In another example, the model metadata 328 shown in FIG. 3 may be stored in another location, such as metadata store 242. The model metadata 328 may include, for example, model approach metadata 330, model parameters metadata 332, input variables metadata 334, model storage location metadata 336, results storage location metadata 338, error rate metadata 340, and model state metadata 342. Other types of model metadata may also be stored as part of the model metadata 328 such as, for example, analytical model subclass metadata, analytical model type metadata, output variables metadata, date metadata, update history metadata, and version metadata. The model metadata 328 may be stored in a persistent cache for fast access.”
The above paragraph is considered useful for understanding that metadata relating to the machine learning model.
determining a compatibility of a local environment of a client system with the training environment of the training system in which the machine learning model was trained based on whether the release numbers of the plurality of libraries of the list of dependent libraries are the same as release numbers of a plurality of libraries of the local environment of the client system
([Dugan Column 15, Line 50]: “the pre-determined compatibility requirements may include dependency requirements or other requirements dictating rules which the source code or compiled code of the pre-defined analytical model must follow [determining a compatibility of a local environment of a client system with the training environment of the training system in which the machine learning model was trained based on whether the release numbers of the plurality of libraries of the list of dependent libraries are the same as release numbers of a plurality of libraries of the local environment of the client system]. In one embodiment, verifying may include determining that the pre-defined analytical model includes all the necessary dependencies required for the model code type (1008). In another embodiment, verifying may include determining that the dependencies included with the pre-defined analytical model do not conflict (1010).”)
Support for the release numbers being relevant to the verification, such as needing to be the same, ([Duggan Column 23, Line 40]: “In the next API call example, the verification returns false because the dependencies in the code bundle conflict. [release numbers of the one or more libraries (the conflict is a version error, as noted by below post)] A Request (POST) may be as follows:
curl -X POST -H ‘Content-Type:application/json’ -d ‘{ “classPath”: “com.Sample” }’ 52.23.153.208:8080/v1/verify/version-error-sample-1.0.jar
A Response may appear as follows:
{ “message”: [ “Version conflicts in jar dependencies - no method found for JsonFactory.class” ], “status”: false }
”)
determining the local environment of the client system is incompatible with the training environment of the training system;
([Duggan Column 16, Line 1]: “The model deployment circuitry 104 may store the pre-defined analytical model in model storage database 106 only upon successful verification, or, alternatively, may store the pre-defined analytical model in model storage database 106 even upon failed verification [determining the local environment of the client system is incompatible with the training environment of the training system] while possibly providing flags or other feedback to the user with respect to a failure to verify.”)
determining the adapted local environment of the client system is compatible with the training environment of the training system
([Duggan Column 15, Line 44]: “The model deployment circuitry 104 may verify that the pre-defined analytical model and/or the corresponding coefficients conform to pre-determined compatibility requirements [determining the adapted local environment of the client system is compatible with the training environment of the training system] applicable to the model code type (1006).”)
and notifying the user using the API service of the incompatibility
([Duggan Column 16, Line 1]: “The model deployment circuitry 104 may store the pre-defined analytical model in model storage database 106 only upon successful verification, or, alternatively, may store the pre-defined analytical model in model storage database 106 even upon failed verification while possibly providing flags or other feedback to the user [and notifying the user using the API service of the incompatibility] with respect to a failure to verify.”)
and downloading, in the adapted local environment of the client system, the machine learning model from the training environment of the training system, wherein the machine learning model is executable within the adapted environment of the client system.
Figure 4 notes retrieving a model from a database [Duggan Figure 4 412] [and download… the machine learning model from the training environment of the training system] [machine learning model]
PNG
media_image3.png
634
585
media_image3.png
Greyscale
Quote noting the ability of the pieces to be remote, thus requiring a connection ([Duggan Column 3, Line 50]: “The various components and circuitry of the machine 100 are interconnected, for example, by one or more system busses 215 of communication interfaces 208 (see FIG. 2)… The communication interfaces 208, and particularly the wireless communication circuitry 210 or wired communication circuitry 214, may also be connected to a network 216 (see FIG. 2) such as the Internet or another intranet.”)
Duggan does not explicitly teach:
and the machine learning model persists in accordance with a pickle persistence model of the training system
adapting the local environment of the client system by updating the plurality of libraries of the local environment including at least installing at least one uninstalled library on the client system, downgrading at least one release number of the plurality of libraries of the client system, and upgrading at least one release number of the plurality of libraries of the client system
and downloading, in the adapted local environment of the client system, the machine learning model from the training environment of the training system, wherein the machine learning model is executable within the adapted environment of the client system
Falko teaches:
adapting the local environment of the client system by updating the plurality of libraries of the local environment including at least installing at least one uninstalled library on the client system, downgrading at least one release number of the plurality of libraries of the client system, and upgrading at least one release number of the plurality of libraries of the client system
([Falko page 94]: “First, Vestigium cycles through what is in the install queue. If the user did not set --nodep, it continues with the process. Vestigium extracts dependency information contained within a specific package’s INFO file. It creates a list of dependencies whose existence must be checked. If the latest version of a dependency is already installed then nothing needs to be added to any queues. If a dependency is not installed or is not the latest version, Vestigium adds the dependency [adapting the local environment of the client system by updating the plurality of libraries of the local environment including at least installing at least one uninstalled library on the client system], along with its latest available version [and upgrading at least one release number of the plurality of libraries of the client system], to depQueue.”)
downgrading at least one release number of the plurality of libraries of the client system
Falko also notes it will go to older versions if the newer one isn’t as compatible with the package ([Falko 2.2.1 Directory and PATH Method]: “Perhaps the greatest benefit to this package management technique is easily having multiple versions of packages installed on the same system. Having multiple versions of the same package allows us to quickly revert to an older version [downgrading at least one release number of the plurality of libraries of the client system] if the new version does not work. This can be very handy if we update a program that other programs depend on. However, if the program has some ABI20 changes, it might require that other packages be rebuilt. If we need to use those packages more than we need to work with the new package, we change our PATH variable to give precedence to the older package.”). Falko also mentions a routine that notes what version are installed ([Falko 3.3.1 Libraries]: “Another routine is findProg, which, given a program name, returns all of the versions available for installation. Next is findInstalledProgVer, which, given a program name and version, returns whether it is installed or not.”).
and downloading, in the adapted local environment of the client system, the machine learning model from the training environment of the training system, wherein the machine learning model is executable within the adapted environment of the client system.
([Falko Page 54]: “Apt automatically downloads anything that it needs. This includes the list of newest packages and the packages themselves. In other words, with apt, the user does not have to search manually for package files on the Internet. Third, apt allows the user to search for text in the names and descriptions of all packages. With dpkg, we would have to do so on a package by package basis. Furthermore, apt also contains a database of all files that can possibly be installed by all packages. The user can use apt to search for individual files. This is extremely helpful if a user is looking for an executable, but the executable is not part of a package description or name. Fourth, apt automatically queues up dependencies and does so in the right order. Whereas dpkg does not let the user install the package until the user installs all dependencies,50 apt automatically downloads and installs all dependencies for a package [wherein the machine learning model is executable within the adapted environment of the client system] along with the package [and downloading, in the adapted local environment of the client system]. Fifth, apt allows a user to update every single package with one simple command: apt-get upgrade. Upgrading is synonymous with updating in our terminology. If a user has six hundred packages, he can run this command, eat lunch, come back, and apt will have completed a task that would have taken more than several hours using dpkg and probably days with LFS. Sixth, apt does not just remove packages but also removes a package’s dependencies in such a way that the removal of the dependencies will not render any other programs malfunctional.”)
The last part of the quote (“Sixth, apt does not just remove packages but also removes a package’s dependencies in such a way that the removal of the dependencies will not render any other programs malfunctional.”) is important, as the quote notes that the purpose of the package manager is to make and keep packages in a state that allows the packages to be run, also known as executable.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Duggan and Falko to utilize adapting the environment being installed to or a client environment. Duggan and Falko are in the same field of endeavor, as they both are based in software dependencies or management. One of ordinary skill in the art would have been motivated to make such a combination as it improves the user or client experience, for they don’t have to figure out how to manage dependencies ([Falkon Page 27]: “However, if the user needs to do other steps or configure a package to his liking, he will have to read a lot more documentation and sometimes even the source code itself. Although not always the case, a package manager is often useful, because it allows a user to get what he wants without reading any extra documentation.”).
Polleri teaches:
and the machine learning model persists in accordance with a pickle persistence model of the training system
[Polleri 0247] Persisted machine learning models can be typically implemented with executable code (e.g., Pickle).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Duggan and Polleri to use persisted machine learning models, such as pickle. Duggan and Polleri are in the same field of endeavor, as they both are based in neural networks. One of ordinary skill in the art would have been motivated to make such a combination for it makes loading pretrained or saved models convenient to the user ([Duggan Column 10, Line 37]: “From here on, the machine 100 has a reference to where the trained analytical model is persisted and how it can be used to make predictions on incoming data and batch data. Once an analytical model has been trained and stored, deployment of the trained analytical model can be achieved according to the following.”).
Regarding Claim 3:
The method of claim 1 is taught by Duggan, Falko, and Polleri.
Duggan teaches:
wherein the client system is configured in a client-server configuration with the training system, the training system providing the machine learning model and the metadata on the training environment as a service for the client system.
([Duggan Column 8, Line 26]: “The communication interfaces 208 may support communication with external client devices [wherein the client system is configured in a client-server configuration with the training system], such as a client computer 228 or a client mobile device 230.”)
Figure 9 from Duggan shows the UI that shows being able to train [the training system providing the machine learning model] and deploy models using the system (Duggan Figure 9 906 for train and 738 for deploy).
PNG
media_image4.png
589
833
media_image4.png
Greyscale
([Duggan Column 22, Line 24]: “The following is an example API call to retrieve information about an uploaded pre-defined analytical model [and the metadata on the training environment as a service for the client system]. Note this API call is not asking the model developer for the status of any running code bundles in the target environment (described further below). The Request (GET) API call may be as follows:”)
Regarding Claim 4:
The method of claim 3 is taught by Duggan, Falko, and Polleri..
Duggan teaches:
wherein the service is the API service, further comprising
downloading, by the client system, an API package from a public repository that enables access to the API service, wherein at least the requesting, the adapting, and the downloading are performed using API functions of the API package.
[Duggan Column 16, Line 11] For example, if a pre-defined analytical model will be implemented using Amazon Web Services™ (AWS), a pre-determined requirement may be that the pre-defined analytical model be compiled with the AWS API code, which makes the AWS API code library a dependency. [downloading, by the client system, an API package from a public repository that enables access to the API service]
([Duggan Column 22, Line 24]: “The following is an example API call [wherein the service is the API service, further comprising] to retrieve information about an uploaded pre-defined analytical model. [wherein at least the requesting, the adapting, and the downloading are performed using API functions of the API package] Note this API call is not asking the model developer for the status of any running code bundles in the target environment (described further below). The Request (GET) API call may be as follows:”)
Duggan does not explicitly teach:
wherein at least the requesting, the adapting, and the downloading are performed using API functions of the API package.
Falko teaches:
an API package from a public repository
([Falko Page 2-3, specifically end of page 2 to beginning of page 3]: “The short history behind the development of GNU software is that a group of software enthusiasts came together in the early 1990s and re-wrote the core user space applications contained within the Unix operating system. Beyond re-writing these applications, they keep their code open to the public under a new license called the GPL. The main point of the GPL is that users can distribute the source of GPL licensed software in any way they like, so long as they keep the distributed package also under the GPL. Linux is an operating system kernel. We can think of it as a software package licensed under the GPL.” [an API package from a public repository as it notes linux is a software package that being GPL has its code open to the public])
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the invention to combine Duggan and Falko to incorporate having the API package being downloaded from a public repository. Duggan and Falko are in the same field of endeavor, as they are both based in software dependencies or management. One of ordinary skill in the art would have been motivated to make such a combination as it makes the API of the software more accessible (as Falko Pages 2-3 notes the code is open to the public). This allows the API to be easily accessible to clients and their computers.
wherein at least the requesting, the adapting, and the downloading are performed using API functions of the API package.
([Falko page 94]: “First, Vestigium cycles through what is in the install queue. If the user did not set --nodep, it continues with the process. Vestigium extracts dependency information contained within a specific package’s INFO file. It creates a list of dependencies whose existence must be checked. If the latest version of a dependency is already installed then nothing needs to be added to any queues. If a dependency is not installed or is not the latest version, Vestigium adds the dependency, along with its latest available version, to depQueue.” [wherein at least the requesting, the adapting, and the downloading are performed using API functions of the API package]) It is noted in paragraph 84 of the current invention that adapting involves updating or downloading libraries ([0084]: “wherein adapting the local environment comprises installing uninstalled libraries and/or changing the installed libraries for downgrading or upgrading the release numbers of the installed libraries.”)
([Falko page 79] “A CLI-only option for Vestigium will be --download, or -d. This option will enable the user to download [wherein at least the requesting, the adapting, and the downloading are performed using API functions of the API package] everything that is needed without doing the actual installing or updating. This is handy for a user who might have a limited amount of time to download packages, and therefore desires to download everything that is needed for him to use when he does have access to the Internet.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Duggan and Falko to utilize adapting and downloading as part of the API. Duggan and Falko are in the same field of endeavor, as they both are based in software dependencies or management. One of ordinary skill in the art would have been motivated to make such a combination as it improves the user or client experience, for they don’t have to figure out how to manage dependencies ([Falkon Page 27]: “However, if the user needs to do other steps or configure a package to his liking, he will have to read a lot more documentation and sometimes even the source code itself. Although not always the case, a package manager is often useful, because it allows a user to get what he wants without reading any extra documentation.”).
Regarding Claim 6:
The method of claim 1 is taught by Duggan, Falko, and Polleri..
Duggan does not explicitly teach:
wherein the machine learning model is received in the adapted local environment of the client system as a binary file
Falko teaches:
wherein the machine learning model is received in the adapted local environment of the client system as a binary file
([Falko page 43 in Binary Packages section]: “We have had a taste of how tedious it is for a user to work with LFS and some low-level package management techniques. Fortunately a user does not have to touch any part of them because of the existence of binary packages [wherein the machine learning model is received in the adapted local environment of the client system as a binary file]. To install a program we just extract a pre-compiled package to its default directory and proceed to use it.”)
It would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the invention to combine Duggan and Falko to incorporate having the machine learning model be a binary file. Duggan and Falko are in the same field of endeavor, as they are both based in software dependencies or management. One of ordinary skill in the art would have been motivated to make such a combination as it makes the machine learning model file easier to work with compared to some formats ([Falko page 43 in Binary Packages section]: “We have had a taste of how tedious it is for a user to work with LFS and some low-level package management techniques. Fortunately a user does not have to touch any part of them because of the existence of binary packages.”)
Regarding Claim 11:
The method of claim 1 taught by Duggan, Falko, and Polleri.
Duggan teaches:
wherein the client system is remotely connected to the training system via a communication network,
([Duggan Column 8 Line 26]: “The communication interfaces 208 may support communication with external client devices, such as a client computer 228 or a client mobile device 230 [wherein the client system is remotely connected to the training system via a communication network]. Communication with the external client devices may be effected through user interface circuitry 114 and/or with user interface instructions 322. A dynamically reconfigurable GUI may be provided to the external client devices via the networks 216 to enable interaction between the client devices and the machine 100.”) A diagram showing the remote connection is below from Duggan Figure 2.
PNG
media_image5.png
601
887
media_image5.png
Greyscale
and wherein the training system is in a cloud service environment.
([Duggan Column 16, Line 11]: “For example, if a pre-defined analytical model will be implemented using Amazon Web Services™ (AWS) [wherein the training system is in a cloud service environment], a pre-determined requirement may be that the pre-defined analytical model be compiled with the AWS API code, which makes the AWS API code library a dependency.”)
Regarding Claim 16:
Claim 16 is rejected under the same rationale as cited for claim 1.
Regarding Claim 20:
Duggan teaches:
A computer system for deploying at a client system a machine learning model, comprising: one or more non-transitory computer-readable storage media and program instructions stored on at least one of the one or more tangible storage media, the program instructions executable by a processor to cause the processor to perform a method comprising:
([Duggan Column 26, Line 1 to 35]: “The methods, devices, processing, circuitry, structures, architectures, and logic described above may be implemented in many different ways and in many different combinations of hardware and software. For example, all or parts of the implementations may be circuitry that includes an instruction processor, such as a Central Processing Unit (CPU), microcontroller, or a microprocessor; or as an Application Specific Integrated Circuit (ASIC), Programmable Logic Device (PLD), or Field Programmable Gate Array (FPGA); or as circuitry that includes discrete logic or other circuit components, including analog circuit components, digital circuit components or both; or any combination thereof. The circuitry may include discrete interconnected hardware components or may be combined on a single integrated circuit die, distributed among multiple integrated circuit dies, or implemented in a Multiple Chip Module (MCM) of multiple integrated circuit dies in a common package, as examples. Accordingly, the circuitry may store or access instructions for execution, or may implement its functionality in hardware alone. The instructions may be stored in a tangible storage medium [A computer system for deploying at a client system a machine learning model, comprising: one or more non-transitory computer-readable storage media and program instructions stored on at least one of the one or more tangible storage media] that is other than a transitory signal, such as a flash memory, a Random Access Memory (RAM), a Read Only Memory (ROM), an Erasable Programmable Read Only Memory (EPROM); or on a magnetic or optical disc, such as a Compact Disc Read Only Memory (CDROM), Hard Disk Drive (HDD), or other magnetic or optical disk; or in or on another machine-readable medium. A product, such as a computer program product, may include a storage medium and instructions stored in or on the medium, and the instructions when executed [the program instructions executable by a processor to cause the processor to perform a method comprising] by the circuitry in a device may cause the device to implement any of the processing described above or illustrated in the drawings.”)
The rest of Claim 20 is rejected under the same rationale as cited for claim 1.
The motivation is the same as cited for claim 1.
Regarding Claim 22:
The method of claim 1 is taught by Duggan, Falko, and Polleri.
Falko teaches:
wherein determining the adapted local environment of the client system is compatible with the training environment of the training system further comprises:
determining that each of the plurality of libraries in the metadata is installed in the client system;
and determining that each version of the plurality of libraries matches the version installed in the client system.
([Falko page 94]: “First, Vestigium cycles through what is in the install queue. If the user did not set --nodep, it continues with the process. Vestigium extracts dependency information contained within a specific package’s INFO file [the metadata]. It creates a list of dependencies whose existence must be checked. If the latest version of a dependency is already installed then nothing needs to be added to any queues. If a dependency is not installed or is not the latest version, Vestigium adds the dependency [determining that each of the one or more libraries in the metadata is installed in the client system;], along with its latest available version [and determining that each version of the one or more libraries matches the version installed in the client system], to depQueue.”)
To help note that Falko teaches finding a version that matches the version from the client system, Falko also notes it will go to older versions if the newer one isn’t as compatible with the package ([Falko 2.2.1 Directory and PATH Method]: “Perhaps the greatest benefit to this package management technique is easily having multiple versions of packages installed on the same system. Having multiple versions of the same package allows us to quickly revert to an older version if the new version does not work. This can be very handy if we update a program that other programs depend on. However, if the program has some ABI20 changes, it might require that other packages be rebuilt. If we need to use those packages more than we need to work with the new package, we change our PATH variable to give precedence to the older package.”). Falko also mentions a routine that notes what version are installed ([Falko 3.3.1 Libraries]: “Another routine is findProg, which, given a program name, returns all of the versions available for installation. Next is findInstalledProgVer, which, given a program name and version, returns whether it is installed or not.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine Duggan and Falko to utilize checking dependencies or libraries. Duggan and Falko are in the same field of endeavor, as they both are based in software dependencies or management. One of ordinary skill in the art would have been motivated to make such a combination as it improves the user or client experience, for they don’t have to figure out how to manage dependencies ([Falkon Page 27]: “However, if the user needs to do other steps or configure a package to his liking, he will have to read a lot more documentation and sometimes even the source code itself. Although not always the case, a package manager is often useful, because it allows a user to get what he wants without reading any extra documentation.”).
Regarding Claim 26:
The method of claim 1 is taught by Duggan, Falko, and Polleri.
Duggan teaches:
wherein the metadata is provided to the user in a format specified by the user using one or more functions of the API service
[Duggan Column 11 Line 28]: “In certain embodiments, the API 110 may expose functions of the model builder circuitry 102, the model deployment circuitry 104, and other elements of the machine 100 to the user interface circuitry 114, the GUI, or the user to enable control of the functionality of the machine 100. The API 110 may comprise a Representational State Transfer (REST) API, which may make use of standards such as HTTP, Uniform Resource Identifier (URI), JavaScript Object Notation (JSON), and Extensible Markup Language (XML). [wherein the metadata is provided to the user in a format specified by the user using one or more functions of the API service] Other API types may be possible in the implementation of the API 110.”
Duggan supports the idea of the metadata being passed using elements like the API in [Duggan Column 6 Line 59]: “Further, the processor 204, memory 206, and the metadata management instructions 326 may operate with the API implementation instructions 324 or the API 110 to interface with a model metadata storage database 112 and/or to enable the user interface circuitry 114 to interact with model metadata stored within the model metadata storage database 112 or elsewhere.”
The interpretation that the metadata is given in a format specified by the user is noted as taught by Duggan, as Duggan notes being able to use the API to send data, such as the metadata, using the formats given in the specification ([Current Specification 0019]: “The methods may be executed in a given order e.g., the method for requesting the information on the trained model may be executed before being able to execute the method for downloading the trained model. Each resource may be represented in a format such as JavaScript Object Notation (JSON) or Extensible Markup Language (XML) format. For example, to retrieve the metadata, the client system can specify a resource name along with a method in a request, and send the request to the training system; the training system may then return the requested resource to the client system in the specified format.”).
Regarding claim 27:
The computer system of claim 16 is taught by Duggan, Falko, and Polleri.
Claim 27 is analogous to claim 3.
Regarding claim 28:
The computer system of claim 27 is taught by Duggan, Falko, and Polleri.
Claim 28 is analogous to claim 4.
Regarding claim 29:
The computer system of claim 16 is taught by Duggan, Falko, and Polleri.
Claim 29 is analogous to claim 6.
Regarding claim 30:
The computer system of claim 16 is taught by Duggan, Falko, and Polleri.
Claim 30 is analogous to claim 11.
Regarding claim 31:
The computer program product of claim 20 is taught by Duggan, Falko, and Polleri.
Claim 31 is analogous to claim 3.
Regarding claim 32:
The computer program product of claim 31 is taught by Duggan, Falko, and Polleri.
Claim 32 is analogous to claim 4.
Regarding claim 33:
The computer program product of claim 20 is taught by Duggan, Falko, and Polleri.
Claim 33 is analogous to claim 6.
Regarding claim 34:
The computer program product of claim 20 is taught by Duggan, Falko, and Polleri.
Claim 33 is analogous to claim 11.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
Yao et al (“MLPM: Machine Learning Package Manager”)
Yao et al is considered relevant art due to the reference teaching the idea of a package manager designed for the distribution of machine learning models, which is seen as the idea of the current application.
Wang et al (“Watchman: Monitoring Dependency Conflicts for Python Library Ecosystem”)
Wang et al is considered relevant art due to the reference teaching aspects of managing software and dependencies in the context of Python. Python is a popular programming language choice for machine learning applications, thus the managing of dependencies in regards to Python is considered relevant to the current application.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER D DEVORE whose telephone number is (703)756-1234. The examiner can normally be reached Monday-Friday 7:30 am - 5 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Michael J Huntley can be reached at (303) 297-4307. 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.
/C.D.D./Examiner, Art Unit 2129
/MICHAEL J HUNTLEY/Supervisory Patent Examiner, Art Unit 2129
Prosecution Insights