Detailed Action
This office action is in response to applicant’s submission filed on February 19, 2026. Claims 1-20 are pending and rejected.
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 Amendment
This communication is in response to the amendment filed on February 19, 2026. The Examiner has acknowledged the amended claims 1, 6, 14, 16, and 20. Claims 1-20 are pending and are rejected.
Response to Arguments
Applicant’s Arguments (Remarks) filed February 19, 2026 have been fully considered, but are not persuasive. Note that this action is made FINAL. See MPEP § 706.07(a).
The applicant argues the prior art fails to teach the amendments. Examiner respectfully disagrees. The added limitation does not meaningfully distinguish the claim because it fails to define any concrete relationship between the first protection level and the second protection level. Stating that one “provides more protection or less protection than” the other is logically non-limiting as any two non-identical levels will inherently satisfy this condition. It fails to narrow the scope in a meaningful way and is not specific in the relation between the first protection level and the second protection level in order to fully differentiate from the interpretation as the Examiner advised in the last interview. See also 102 rejection below.
Therefore, Examiner notes that the amended claim limitations are still taught by Baldwin.
The amendments to claims 6 and 16 has resolved the claim rejections.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 2023/0409756 A1 to Baldwin et al. (hereinafter, “Baldwin”).
Regarding claim 1, Baldwin discloses: A system comprising:
a processing system; and memory comprising computer executable instructions that, when executed, perform operations comprising (“The transformation module 118 and the ML module 120 may be implemented by processing circuitry (e.g., in the form of a dedicated chip on the computing device 102 platform or via use of a processing and/or memory resource implemented by the computing device 102 such as the CPU 110 and/or memory 112)... The transformation module 118 and the ML module 120 may comprise or have access to memory (e.g., dedicated/local memory that is part of the module 118/120 itself or another dedicated or non-dedicated memory accessible to the module 118/120 such as the memory 112) for storing instructions which, when executed by the processing circuitry of the module 118/120, cause the processing circuitry to implement the instructions” [0074]):
receiving a request to distribute an artificial intelligence (AI) model to a client device (“The computing device 102 may give a handle back to the calling process so that it can request use of the ML model 114” [0063]),
the AI model comprising model weights and a model structure (“the model weights” [0030]; “the ML model 114 could be implemented in different ways depending on the hardware architecture” [0091]);
identifying a license for the AI model, wherein the license specifies a first protection level for the model weights and a second protection level for the model structure, wherein the first protection level provides at least one of more protection or less protection than the second protection level (“In some examples, the additional information (e.g., a model contract) may define the expected data flows (e.g., data sources, transformation paths and security properties) that are acceptable to the third party entity in use of the ML model 114 by the computing device 102. In some examples, the ML model 114 may indicate a choice available to the computing device 102 for adapting its particular hardware architecture to execution of the ML model 114” [0058]; “In some examples, the send/use result instructions 116 c comprise data request instructions where data being used for training an ML model 114 at the cloud 104 may download a data collection specification or contract from the cloud 104 to define the expected data processing path that the data is to go through at the computing device 102. An attestation as to the actual data processing path used may be linked to the data used for the training. The data request instructions may define an expected lineage for the data that the cloud service has collected, which may protect against poisoning of the training set. In some examples, the send/use result instructions 116 c comprises model results and attestation request instructions to allow model execution results along with an attestation to be requested for a given service. In some examples, these instructions may obtain a nonce from the requester (e.g., the third party entity such as a service provider) to demonstrate the freshness of the attestation and/or specify the time over which a sequence of model results have been obtained and/or the regularity over which the results are to be sent to the requesting service (e.g., due to the requester receiving the expected nonce with the results). The request may be accompanied with a public key (e.g., validated against the additional information content such as a model contract) such that a message can be securely sent from the computing device 102 to the service relying on the results and/or attestation. Thus, the OS 116 may not have any visibility as to the results and/or the attestation due to this cryptographic control, even though the results may be handled by the OS 116. As will be explained in more detail below, the architecture of the computing device 102 may facilitate this cryptographic control to avoid exposing the ML model 114 to the OS 116 or certain other entities of the computing device 102 which may not necessarily be trusted by the third party entity” [0066-0067] [Examiner notes that this text aligns with the concept of a request identifying a desired protection level/type since the protections described (attestation, secure path, cryptographic control, OS isolation, etc.) are present in the request instructions and the model contract. Examiner also notes that these text show that the model contract acts like a license, as it defines acceptable use and constraints security wise. It evaluates the contract which is seen analogous to evaluating a license before using the model. The security rules must be followed by the device in order to execute the AI model as there are several]; “For example, the service provider may have intellectual property (IP) concerns due to the confidential information relating to the ML model (e.g., model type, neural network weights, etc) released to the edge computing device. Further, the service provider may have security concerns due to the potential for the released model being stolen or corrupted” [0020] [Examiner notes that this text specifically mentions model weights as it states that they must be protected from theft or corruption. This is exactly what a “protection level” is, a prescribed set of protections for the weights]);
evaluating capabilities of the client device; determining the capabilities of the client device enable the client device to support the first protection level and the second protection level (“The instructions 402 comprise instructions 406 to determine whether or not a computing device 102 under control of the at least one processor 404 is capable of operating in accordance with a model execution specification (e.g., in the ‘additional information’) associated with a machine learning model 114 under control of a third party entity” [0128]); and
in response to determining the capabilities of the client device enable the client device to support the first protection level and the second protection level, providing the AI model to the client device (“In response to determining that the computing device 102 is capable of operating in accordance with the model execution specification, the instructions 402 comprise instructions 408 to cause the computing device 102 to establish a data processing pipeline for executing the machine learning model in accordance with the model execution specification. For example, the instructions 408 may cause the at least one processor 404 to control the control plane of the computing device 102 in order to set up the data processing pipeline as specified by the third party entity (via the model execution specification)” [0129]).
Regarding claim 2, Baldwin discloses: wherein the request identifies at least one of: a particular AI model; a particular AI model class; a desired protection level; or a protection type (“In some examples, the send/use result instructions 116 c comprise data request instructions where data being used for training an ML model 114 at the cloud 104 may download a data collection specification or contract from the cloud 104 to define the expected data processing path that the data is to go through at the computing device 102. An attestation as to the actual data processing path used may be linked to the data used for the training. The data request instructions may define an expected lineage for the data that the cloud service has collected, which may protect against poisoning of the training set. In some examples, the send/use result instructions 116 c comprises model results and attestation request instructions to allow model execution results along with an attestation to be requested for a given service. In some examples, these instructions may obtain a nonce from the requester (e.g., the third party entity such as a service provider) to demonstrate the freshness of the attestation and/or specify the time over which a sequence of model results have been obtained and/or the regularity over which the results are to be sent to the requesting service (e.g., due to the requester receiving the expected nonce with the results). The request may be accompanied with a public key (e.g., validated against the additional information content such as a model contract) such that a message can be securely sent from the computing device 102 to the service relying on the results and/or attestation. Thus, the OS 116 may not have any visibility as to the results and/or the attestation due to this cryptographic control, even though the results may be handled by the OS 116. As will be explained in more detail below, the architecture of the computing device 102 may facilitate this cryptographic control to avoid exposing the ML model 114 to the OS 116 or certain other entities of the computing device 102 which may not necessarily be trusted by the third party entity” [0066-0067] [Examiner notes that this text aligns with the concept of a request identifying a desired protection level/type since the protections described (attestation, secure path, cryptographic control, OS isolation, etc.) are present in the request instructions]).
Regarding claim 3, Baldwin discloses: wherein receiving the request comprises: receiving, by a distribution service, the request from the client device, the distribution service being external to the client device and having access to a plurality of AI models (“In some examples, the send/use result instructions 116 c comprise additional data request instructions to allow a data flow defined by the content of the additional information (e.g., model contract) to obtain additional data (e.g., from a user) of the computing device 102 and/or to send a request to the cloud 104 for enrichment data used by the ML model 114. The cloud 104 may therefore possess or receive data such as training data (e.g., from the computing device 102 itself or another source). The cloud 104 may be trusted by the third party entity that owns the ML model 114 and at least part of the ML model 114 may be stored in and accessible from the cloud 104. The cloud 104 may store the additional information and/or implement cryptographic controls for ensuring the integrity of the ML model 114 and/or the additional information. The cloud 104 may be under the control of the third party entity or at least be trusted by the third party entity” [0068-0069] [Examiner notes that this text describes how the cloud (distribution service) can handle requests as it interfaces securely with the client device even as an external entity]).
Regarding claim 4, Baldwin discloses: wherein receiving the request further comprises: identifying a task to be performed using the AI model; and selecting, by the distribution service, the AI model based on the task, wherein the AI model is configured to be used to perform the task (“A third party entity such as a service provider that uses an ML model 114 as part of the service offered may deliver a package comprising the ML model 114 and associated instructions for data acquisition and/or pre-processing to ensure that the ML model 114 may be correctly handled by the computing device 102. The computing device 102 described in FIG. 1 defines separate control and data planes along with a trusted control module 122 in order to control execution of an ML model 114. In some examples, ML models may be designed with a certain data processing pipeline in mind where data is taken from particular sensors (e.g., data sources 108), potentially combined, and then passed through a series of pre-processing and feature extraction prior to reaching the ML module 120. When a service is running in the cloud 104, it may be straightforward for the service provider who created the ML model 114 to ensure that the correct data pipeline and ML model 114 is used. However, where the ML model 114 is sent to the edge (or at any device not under control of the service provider) and a service provider executes an ML model 114 on an end-point computing device 102, the service provider may have certain queries about the execution of the ML model 114” [0102-0103] [Examiner notes that this text shows that each ML model is designed for a particular task. The model and instructions correspond to a specific tasks, such as processing sensor data. This reinforces that the cloud provider chooses the model appropriate for the task when executing the cloud]).
Regarding claim 5, Baldwin discloses: wherein selecting the AI model based on the task comprises at least one of: evaluating properties of the AI model; or evaluating a stored description of the AI model (“For example, a party may wish to establish whether the output data comes from an ML model that is trusted. Example threats include malicious changes to model weights or the code used to execute the ML model. There are multiple examples of the machine learning pipeline which may affect the trust in a model. In some examples, certain static properties may affect whether to trust the data output from the model. For example, the party may wish to establish proof that the model used is the one that was intended. For example, this proof may include whether the model update is secure (e.g., if the model is pushed from the cloud) and/or whether the model is trained with legitimate and trusted data. In some examples, certain dynamic properties may affect whether to trust the data output from the model. For example, an attacker may actively change model decision boundaries by altering unprotected model parameters. Such changes may be an issue with incremental learning, for example, the party may wish to establish trust that the model has not evolved too far from an acceptable model” [0032]).
Regarding claim 6, Baldwin discloses: wherein selecting the AI model based on the task comprises: selecting A third party entity such as a service provider that uses an ML model 114 as part of the service offered may deliver a package comprising the ML model 114 and associated instructions for data acquisition and/or pre-processing to ensure that the ML model 114 may be correctly handled by the computing device 102. The computing device 102 described in FIG. 1 defines separate control and data planes along with a trusted control module 122 in order to control execution of an ML model 114. In some examples, ML models may be designed with a certain data processing pipeline in mind where data is taken from particular sensors (e.g., data sources 108), potentially combined, and then passed through a series of pre-processing and feature extraction prior to reaching the ML module 120. When a service is running in the cloud 104, it may be straightforward for the service provider who created the ML model 114 to ensure that the correct data pipeline and ML model 114 is used. However, where the ML model 114 is sent to the edge (or at any device not under control of the service provider) and a service provider executes an ML model 114 on an end-point computing device 102, the service provider may have certain queries about the execution of the ML model 114” [0102-0103]).
Regarding claim 7, Baldwin discloses: wherein selecting the AI model based on the task comprises: selecting a multiple candidate AI models based on the task, the AI model being included in the multiple candidate AI models, wherein each of the multiple candidate AI models is configured to be used to perform the task; evaluating the multiple candidate AI models based on at least one of: creation date of the multiple candidate AI models; performance of the multiple candidate AI models; cost of the multiple candidate AI models cost; or popularity of the multiple candidate AI models; and selecting, by the distribution service, the AI model based on evaluating the multiple candidate AI models (“...such as predefined boundaries within which certain model parameters may lie or performance specifications (e.g., # alerts, performance on given test samples, etc). In some examples, the additional information may comprise a test property (e.g., a test to be performed on model load and/or acceptable performance thresholds resulting from such a test). In some examples, the test property may be used for monitoring or controlling the execution of the ML model 114 when incremental learning is implemented” [0059-0060] [Examiner notes that the evaluation of the AI models here are based on the performance]; “For example, a party may wish to establish whether the output data comes from an ML model that is trusted. Example threats include malicious changes to model weights or the code used to execute the ML model. There are multiple examples of the machine learning pipeline which may affect the trust in a model. In some examples, certain static properties may affect whether to trust the data output from the model. For example, the party may wish to establish proof that the model used is the one that was intended. For example, this proof may include whether the model update is secure (e.g., if the model is pushed from the cloud) and/or whether the model is trained with legitimate and trusted data. In some examples, certain dynamic properties may affect whether to trust the data output from the model. For example, an attacker may actively change model decision boundaries by altering unprotected model parameters. Such changes may be an issue with incremental learning, for example, the party may wish to establish trust that the model has not evolved too far from an acceptable model” [0032]; “In some examples, the apparatus 200 (and indeed other apparatus, machine readable media and methods described herein) may facilitate multi-tenant models and/or multi-tasking using the computing device 102. In some examples, multi-tenancy may refer to being able to support multiple ML models 114 and context switches between the multiple ML models 114. Within the model load process, an ML model 114 may be loaded to an internal context and comprise a ‘loaded and validated’ version of the ML model 114 that is secured for the computing device 102. Such loading may provide a basis for multi-tasking and/or running multiple models so that if the computing device 102 has a number of loaded model contexts then it can switch between the different ML models 114 (e.g., by accessing different ML models 114 stored in the memory 112, for example, with reference to a model table stored in the apparatus 200/control module 122). In some examples, the context may be associated with the certification of results (e.g., storing partial results and previous model results) and/or the maintenance of the ML model 114 (e.g., weights and setup)” [0016] [Examiner notes that this text supports selecting multiple candidate AI models based on the task and the model being included in the multiple because it says the system can support multiple ML models at once and these models are stored and selectable. The system can switch between models, which implies a set of candidate models and multi0-tasking means different tasks may include different models (task-based selection)]; “A third party entity such as a service provider that uses an ML model 114 as part of the service offered may deliver a package comprising the ML model 114 and associated instructions for data acquisition and/or pre-processing to ensure that the ML model 114 may be correctly handled by the computing device 102. The computing device 102 described in FIG. 1 defines separate control and data planes along with a trusted control module 122 in order to control execution of an ML model 114. In some examples, ML models may be designed with a certain data processing pipeline in mind where data is taken from particular sensors (e.g., data sources 108), potentially combined, and then passed through a series of pre-processing and feature extraction prior to reaching the ML module 120. When a service is running in the cloud 104, it may be straightforward for the service provider who created the ML model 114 to ensure that the correct data pipeline and ML model 114 is used. However, where the ML model 114 is sent to the edge (or at any device not under control of the service provider) and a service provider executes an ML model 114 on an end-point computing device 102, the service provider may have certain queries about the execution of the ML model 114” [0102-0103] [Examiner notes that this text shows that each ML model is designed for a particular task. The model and instructions correspond to a specific tasks, such as processing sensor data. This reinforces that the cloud provider chooses the model appropriate for the task when executing the cloud. It evaluates which ML models is correct for the computing device and uses model requirements, data pipelines, pre-processing instructions, and device capabilities to choose. Selecting the correct model for the task is the same as selecting from the candidate models]).
Regarding claim 8, Baldwin discloses: wherein identifying the license comprises: identifying a licensing repository comprising licenses for multiple AI models, the license repository being external to the client device; and evaluating the licenses for the multiple AI models by matching properties of the license to properties of the licenses for the multiple AI models; and retrieving the license from the license repository based on evaluating the licenses for the multiple AI models (“A third party entity such as a service provider that uses an ML model 114 as part of the service offered may deliver a package comprising the ML model 114 and associated instructions for data acquisition and/or pre-processing to ensure that the ML model 114 may be correctly handled by the computing device 102. The computing device 102 described in FIG. 1 defines separate control and data planes along with a trusted control module 122 in order to control execution of an ML model 114” [0102]; “In some examples, the additional information (e.g., a model contract) may define the expected data flows (e.g., data sources, transformation paths and security properties) that are acceptable to the third party entity in use of the ML model 114 by the computing device 102. In some examples, the ML model 114 may indicate a choice available to the computing device 102 for adapting its particular hardware architecture to execution of the ML model 114” [0058] [Examiner notes that the first text shows a package which can include the license information along with the model and how the provider controls how the model can be used (license specification). It implies that there is structured information external to the client device that must be consulted to use the model correctly. The second text is more so showing that the model contract acts like a license, as it defines acceptable use and constraints security wise. It evaluates the contract which is seen analogous to evaluating a license before using the model]).
Regarding claim 9, Baldwin discloses: wherein evaluating the capabilities of the client device comprises: querying the client device for the capabilities of the client device; receiving the capabilities of the client device from the client device; and comparing the capabilities of the client device to client device requirements specified by the license (“In some examples, the method 700 comprises, at block 704, in response to receiving an attestation that the computing device 102 complies with the condition, causing the control module 122 to facilitate execution of the machine learning model 114 by the computing device 102 in accordance with the condition. In some examples, block 704 comprises, in response to the received attestation comprising an indication that the signed machine learning model 114 was verified against a public key associated with the private key, verifying whether or not the control module has set up the computing device 102 in accordance with the condition. For example, the attestation may contain information derived from the control module 122 to allow the service provider to determine whether the computing device 102 has been set up in accordance with the condition (e.g., by comparing the received attestation with the ‘condition’ specified by the third party entity)” [0150-0151]; “In some examples, the ML model 114 and the additional information may form a ‘model package’ as created by the controller or owner of the ML model 114. In some examples, the additional information may be referred to as a ‘contract’, ‘model contract’, ‘model specification’, ‘model execution specification’, ‘a condition’, ‘model execution condition’, ‘third party policy’, etc.” [0054] [Examiner notes that the attestation represents the capabilities and the condition represents the license requirements]).
Regarding claim 10, Baldwin discloses: wherein evaluating the capabilities of the client device comprises: providing client device requirements for the AI model to the client device; and receiving, from the client device, a determination of whether the client device satisfies the client device requirements (“The instructions 402 comprise instructions 406 to determine whether or not a computing device 102 under control of the at least one processor 404 is capable of operating in accordance with a model execution specification (e.g., in the ‘additional information’) associated with a machine learning model 114 under control of a third party entity. In response to determining that the computing device 102 is capable of operating in accordance with the model execution specification, the instructions 402 comprise instructions 408 to cause the computing device 102 to establish a data processing pipeline for executing the machine learning model in accordance with the model execution specification. For example, the instructions 408 may cause the at least one processor 404 to control the control plane of the computing device 102 in order to set up the data processing pipeline as specified by the third party entity (via the model execution specification)” [0128-0129]).
Regarding claim 11, Baldwin discloses: the first protection level specifies software-based protection and the second protection level specifies hardware-based protection; or the first protection level specifies the hardware-based protection and the second protection level specifies the software-based protection (“In some examples, an ML model 114 may be sent to an endpoint device (e.g., the computing device 102 which decrypts the ML model 114 and then certifies the results as having come from a suitable set up based on trust in the ML sub-system. In some examples, implicit attestation and trusted computing may be used. A workflow may be defined where the model provider can validate the trustworthiness of the remote ML sub-system. An example trusted computing approach may involve requesting an attestation of the sub-system to show it has started with the correct firmware/hardware based on a TPM root of trust. An alternative example may be to use implicit attestation so that keys are encrypted for a TPM key that is sealed and only accessible with a given set of measurements (and hence firmware/software). Another example may be to use a trusted computing approach where there is a key hierarchy and a (hash-based) measurement system under which keys can be sealed and only accessible given a record of certain system measurements (such as with a TPM). Thus, for a given set of system measurements, a key pair kbind in the key hierarchy may be sealed to a given set of measurements that are to be taken at boot time or when the ML module 120 is started. The public portion pkbind can be shared along with a proof of creation from the TPM to show that access to the associated secret key skbind can be accessed. In some examples, the model provider can then send an encrypted model to the computing device 102 where the encryption key Kenc and a nonce, nonce, is encrypted with the pkbind. The ML model 114 can then be decrypted by the ML module 120 if the software is in an appropriate state (i.e. it has the appropriate measurements enabling the skbind key to be accessed which in turn means the process started with the appropriate firmware/software set-up). In some examples, the model provider may be securely supplied with the nonce, in order to demonstrate that the ML model 114 has been decrypted and based on the trust in the software/firmware being measured, the ML model 114 may provide trust that the ML model 114 is being correctly used. The information inferred due to receipt of the correct nonce may be enough for the model provider to trust the results” [0222-0224] [Examiner notes that this text repeatedly references TPM-based attestation, which is explicitly hardware-rooted security. The two layers are treated as different types of protection, aligning with the claim limitations]).
Regarding claim 12, Baldwin discloses: wherein the license includes first properties for the first protection level and second properties for the second protection level (“In some examples, the additional information (e.g., a model contract) may define the expected data flows (e.g., data sources, transformation paths and security properties) that are acceptable to the third party entity in use of the ML model 114 by the computing device 102. In some examples, the ML model 114 may indicate a choice available to the computing device 102 for adapting its particular hardware architecture to execution of the ML model 114” [0058]).
Regarding claim 13, Baldwin discloses: wherein the first properties indicate at least one of: threats managed by the first protection level; a customer usage scenario for the first protection level; or operating system platform requirements for implementing the first protection level (“For example, if a service provider has trained an ML model (and invested considerable time and effort into doing so), the service provider may wish to determine whether or not to deploy the model on an untrusted end-point so that they have reasonable guarantees that the user cannot get the model. An example threat scenario involves the model weights being directly read (e.g., in plaintext) out of the endpoint by the user of the device (who may have operating system (OS) admin rights) or an attacker gaining access through the user account or through subverting the OS kernel. Another example threat scenario involves the model being reconstructed using extraction techniques, e.g., by querying a model (whose weights cannot be read directly) with a carefully constructed set of queries” [0030]).
Claim 14 recites substantially the same limitation as claim 1, in the form of a method for implementing the corresponding system, therefore it is rejected under the same rationale. Examiner wants to note that the addition of a “second license” is still read upon as there can be more than one model contract as there are security properties associated, therefore this does not add novelty to the claim.
Regarding claim 15, Baldwin discloses: identifying a third license for the AI model, wherein the third license specifies a third protection level for user input data provided to the AI model (“A cloud-based service where a user device accessing the cloud-based computing resource sends data to and/or receives results from the service provider-controlled computing resource may experience lag when communicating data via the network. At certain times the cloud-based service may restrict the availability of the computing resource for processing requests submitted by the user device. Further, a user may have to pay for use of network bandwidth when transmitting data over the network, which could be pricy for transmitting large amounts of data. In some examples, there may be scenarios where a user has a concern about transmitting certain types of data to a cloud-based service such as privacy-sensitive data (e.g., speech and/or other personal data). An edge computing device that is physically closer to the data source and/or the user device (e.g., the user device could be the edge computing device itself) that submits a request for processing the data may provide a way to reduce the lag, free up processing resource in a network, reduce network usage/cost and/or ensure that certain types of data is not exposed to reduce privacy and/or security concerns. However, the service provider may not be able to trust the configuration of the edge computing device running the ML model. For example, the service provider may have intellectual property (IP) concerns due to the confidential information relating to the ML model (e.g., model type, neural network weights, etc) released to the edge computing device. Further, the service provider may have security concerns due to the potential for the released model being stolen or corrupted. Further still, the results output by the edge computing device may not be trusted if the machine learning model is not executed in a manner expected by the service provider” [0019-0020] [Examiner notes that the text explicitly mentions privacy-sensitive data, such as speech or personal data, which the user provides to the system. It highlights potential exposure risks when sending data to a cloud-based service. The edge computing device is presented as a solution to reduce privacy and security risks. By moving processing closer to the user, data is less exposed, network usage is reduced, and privacy/security is maintained. These are exactly the types of protection measures that a “protection level” for user input data would enforce]).
Regarding claim 16, Baldwin discloses: providing the first license and the second license to the client device (“In some examples the ML model 114 (or at least part of the ML model 114) downloaded from the cloud 104 may be accompanied by additional information in order to support third party entity (e.g., service provider) control over the implementation of the ML model 114 and/or whether to allow the computing device 102 to receive the ML model 114. In some examples, the ML model 114 and the additional information may form a ‘model package’ as created by the controller or owner of the ML model 114. In some examples, the additional information may be referred to as a ‘contract’, ‘model contract’, ‘model specification’, ‘model execution specification’, ‘a condition’, ‘model execution condition’, ‘third party policy’, etc.” [0054]).
Regarding claim 17, Baldwin discloses: wherein first client device requirements for implementing the first license on the client device are different from second client device requirements for implementing the second license on the client device (“In another example, different computing devices 102 may have different platform properties that involve different protections of the data flow” [0104]).
Regarding claim 18, Baldwin discloses: wherein resolution rules stored by the client device are used to resolve differences between the first client device requirements and the second client device requirements (“In some examples, the service provider may query whether the correct data pipeline is set up. In some examples, the service provider may query whether there are any guarantees that the pipeline is to be set-up on the computing device 102 in a way that avoids interference to the data flow from other processes running on the computing device 102. In some examples, the service provider may query whether the data pipeline can be customized according to the edge device and its hardware properties. For example, different computing devices 102 may be heterogeneous and comprise a range of different sensors which may produce data with different pre-processing properties in order to make it suitable for execution by the ML model 114. In another example, different computing devices 102 may have different platform properties that involve different protections of the data flow” [0104] [Examiner notes that this text shows that the client device applies logic to adjust the pipeline, effectively resolving differences between the AI model’s requirements and the device’s actual capabilities. The data pipeline is not the resolution rules itself, but it is what gets configured based on the resolution rules. These rules live on the device and control how to pipeline adapts to reconcile different between the model requirements and device capabilities (pipeline is execution and rules dictate how it is set up)]).
Regarding claim 19, Baldwin discloses: wherein providing the AI model to the client device comprises applying an indication of the first protection level and the second protection level to the AI model (“In some examples, the additional information (e.g., a model contract) may define the expected data flows (e.g., data sources, transformation paths and security properties) that are acceptable to the third party entity in use of the ML model 114 by the computing device 102. In some examples, the ML model 114 may indicate a choice available to the computing device 102 for adapting its particular hardware architecture to execution of the ML model 114” [0058] [Examiner notes that the security properties are associated with the model when it is distributed/executed, which is conceptually the same as applying an indication of a protection level]).
Claim 20 recites substantially the same limitation as claims 1 and 15, in the form of a device for implementing the corresponding system/method, therefore it is rejected under the same rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should
be directed to SARON MATTHEWOS WORKU whose telephone number is (703)756-1761. The
examiner can normally be reached Monday - Friday, 9:30am - 6:30pm.
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, Linglan Edwards can be reached on 571-270-5440. 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.
/SARON MATTHEWOS WORKU/Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights