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 Amendment
The amendments filed on 1/2/2026 have been entered.
Claims 32-33, 35, 41-44, 50-51 have been amended.
Response to Arguments
Applicant’s arguments filed on 12/3/2025 have been fully considered but not persuasive.
Applicant 1st argument
Double Patenting
Examiner response to applicant 1st argument:
Terminal disclaimer filed and approved on 1/3/2026 overcame the double patenting rejection.
Applicant 2nd argument
112 (b) rejection.
Examiner response to applicant 2nd argument:
Amendments filed on 1/2/2026 overcame the 112(b) rejections.
Applicant 3rd argument
102 rejection.
Examiner response to applicant 3rd argument:
Examiner respectfully disagrees. Applicant argues Joshi does not disclose a plurality of enterprises without providing additional details in the claims. However, as presented here Joshi teaches this subject matter ([0106-0109] Fig. 1, Receive Request for Service, the consumer details the technical and functional specifications that a service needs to fulfill, he consumer also specifies non-functional attributes like characteristics of the human agent providing the service, constraints and preferences on data quality and required security policies for the service. Service compliance details like certifications needed, standards to be adhered to etc. are also identified. The technical specifications lay down the hardware, software, application standards and language support policies to which a service should adhere. Once the consumers have identified and classified their service needs, they issue a Request for Service (RFS))([0116, 0115, 0120] Fig. 2, The security constraints specified in the RFS include policies regarding service role/permission levels, data security policies and cloud location/ownership policies.),. Furthermore, the applicant argues that Joshi does not teach “a communication infrastructure that includes a plurality of enterprises, receiving S-SLA requests from one or more of a plurality of enterprises, or converting each S-SLA request from multiple enterprises into unique S-SLAs for those respective enterprises” without providing additional definition or details in the claims what the multiple enterprises are, however as presented here and below Joshi teaches this subject matter ([0135-0158] Fig. 7 Cloud provider creates contract associated with consumer and list of services that meet the constraints and the available requested service, negotiating the RFS)(Fig. 3, consumer ID is unique for each consumer identifying the unique SLA for that enterprise)(Fig. 5, RFS ID);
The applicant argues that Joshi reference does teach consumer to provider or enterprise, however these languages and details are not provided in the claim limitations, examiner recommends applicant to add these languages to the claim limitation in order to be read differently.
Applicant argues that Joshi does not teach “Joshi does not disclose an SSOF receiving requests from other CSPs and converting those requests into consistent and unified S-SLAs offerable to each other CSP” without providing additional language why Joshi is not teaching, however as presented here and below Joshi teaches this subject matter ([0106-0109] Fig. 1, Receive Request for Service, the consumer details the technical and functional specifications that a service needs to fulfill, he consumer also specifies non-functional attributes like characteristics of the human agent providing the service, constraints and preferences on data quality and required security policies for the service. Service compliance details like certifications needed, standards to be adhered to etc. are also identified. The technical specifications lay down the hardware, software, application standards and language support policies to which a service should adhere. Once the consumers have identified and classified their service needs, they issue a Request for Service (RFS))([0116, 0115, 0120] Fig. 2, The security constraints specified in the RFS include policies regarding service role/permission levels, data security policies and cloud location/ownership policies.) ([0116-0120] Fig. 2, The Specification class consists of six main classes that define the functional specifications, technical specifications, Human agent specifications, security policies, service compliance policies and data quality policies, the specifications listed in the RFS)(Fig. 5, availability requirement in the specification, Encryption),([Fig. 3] Consumer-ID)([0158-0160] Fig. 9, SLA Name attached to consumer ID)([0030] Negotiate service level agreement object, security policies object) Fig. 3, consumer ID is unique for each consumer identifying the unique SLA for that enterprise)(Fig. 5, RFS ID related to SLA for that enterprise requesting the services); and converting each S-SLA request into a consistent and unified S-SLA offerable to each other CSP, wherein the consistent and unified S-SLA comprises security attributes that the CSP provides the other CSPs ([0135-0158] Fig. 7 Cloud provider creates contract associated with consumer and list of services that meet the constraints and the available requested service, negotiating the RFS)(Fig. 3, consumer ID is unique for each consumer identifying the unique SLA for that enterprise)(Fig. 5, RFS ID);
Applicant further argues that Joshi does not teach SSOF function without defining or providing details what this function is. It is reasonable under BRI that this function is interpreted as any function or policy implemented in the cloud or the enterprise. Examiner recommends applicant to provide more details in the limitation in order to overcome the current rejections.
Applicant argues that Joshi does not teach target CSP identifier, however examiner has interpreted the target CSP as the enterprise requesting service as presented here, wherein the mandatory information element or object comprise a target CSP identifier (Fig. 5, RFS ID related to SLA for that enterprise requesting the services).
Furthermore, applicant argues in clam 36 that Joshi does not disclose discloses the "plurality of optional information elements or objects" enumerated in claim 18 such as “wherein each S-SLA request comprises a plurality of requirements, and the S-SLA request from each of the one or more of the plurality of enterprises comprises a plurality of optional information elements or objects and mandatory information elements or objects, wherein the plurality of optional information elements or objects comprises: confidentiality attributes, target integrity attributes, target authentication attributes, target availability attributes, target non-repudiation attributes, target isolation attributes, target data sovereignty attributes, validity condition, temporal validity condition, subscription of S-SLA compliance monitoring events, allowed internet protocol domains, and extra data protection controls, and wherein the mandatory information elements or objects comprise a target enterprise identifier”. The claim recites that the request from each of the one or more comprises. Examiner has interpreted this limitation with the language provided that under BRI it is sufficient to choose one feature out of these recited in the claim. Examiner recommends applicant to provide clear limitation especially if all attributes are required to be listed in the claim.
Applicant argues in claim 43 and claim 50 that Joshi does not teach CSP to CSP architecture without providing more details about CSP introduced in the claims language, therefore, examiner under BRI interprets consumer to provider as CSP to CSP. Examiner recommends applicant to define what CSP in the limitations of the claim in order to be interpreted differently.
Applicant argues that Joshi does not teach “merging the security attributes received from each other CSP into a common security baseline template S-SLA for communication to business services users of the CSP” without providing details about the merging limitation, under BRI, Joshi teaches that combing the services with other resources into single service teaches this subject matter as presented here and below ([0091] Providers may need to combine their services with other resources or providers' services to meet consumer needs)([0135] the service provider will need to combine a set of services or compose a service from various components delivered by distinct service providers in order to meet the consumer's requirements)([0160-0161] one or more components provided by one or more providers are combined and delivered as a single service).
Applicant 4th argument
103 rejection.
Examiner response to applicant 4th argument:
Examiner respectfully disagrees. Applicant argues in claims 38-39 and 47-48 that Joshi in view of Trapero do not teach “Trapero's SPECS system is not designed for, and does not teach or suggest, simultaneously managing S-SLAs among multiple CSPs. Trapero's architecture handles one CSC-to-CSP relationship-the CSC negotiates with the CSP, the CSP implements the secSLA, and the CSP monitors its own compliance with that single secSLA.”, and “consumer-to-provider architecture to simultaneously orchestrate S-SLAs among multiple CSPs using Trapero's single CSC-to-CSP monitoring system. Neither reference teaches or suggests adapting a single-customer monitoring system to orchestrate and manage S-SLAs among multiple CSPs concurrently.” however these terms are not written in claims 38-39, 47-48. Therefore, this argument is moot. Examiner recommends applicant to add details about these terms introduced here in the arguments in order for the examiner to examine the limitations in these claims differently.
Applicant argues in claim 39 that Trapero does not disclose “calculating compliance status for "each CSP" in a multi-CSP environment, nor does it disclose maintaining historical compliance information "per CSP." However as presented below in claim 39, the applicant has recited the support security management function comprises at least one of the limitations, therefore, examiner has chosen the limitation “monitoring S-SLA status of NF and NE according to set security attributes” ([page 202] Consider a CSC who wants to acquire a pool of web servers and secure them with the SVA mechanism. Let us assume that the CSC signs a secSLA with two SLOs, namely SLO1 with medium importance defined as VSF = 24 h and SLO2 with low importance defined as MCS = 4. According to Table 4, the CSP has to monitor all defined SVA measurements, and the following monitoring rules have to be periodically evaluated: SRA ≤ 24 h, MDCS ≤ 4, RAV = yes, VLAV = yes, and SAV = yes., web servers on VMs); it is sufficient for the examiner to choose one function out of these limitations in order to reject the claim. Applicant is reminded to change the language of the claims in order to overcome the current rejection or the prior art.
Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). An examiner must construe claim terms in the broadest reasonable manner during prosecution as is reasonably allowed in an effort to establish a clear record of what applicant intends to claim. Thus, the Office does not interpret claims in the same manner as the courts. In re Morris, 127 F.3d 1048, 1054, 44 USPQ2d 1023, 1028 (Fed. Cir. 1997); In re Zletz, 893 F.2d 319, 321-22, 13 USPQ2d 1320, 1321-22 (Fed. Cir. 1989). Though understanding the claim language may be aided by explanations contained in the written description, it is important not to import into a claim limitations that are not part of the claim. For example, a particular embodiment appearing in the written description may not be read into a claim when the claim language is broader than the embodiment." Superguide Corp. v. DirecTV Enterprises, Inc., 358 F.3d 870, 875, 69 USPQ2d 1865, 1868 (Fed. Cir. 2004). See also Liebel-Flarsheim Co. v. Medrad Inc., 358 F.3d 898, 906, 69 USPQ2d 1801, 1807 (Fed. Cir. 2004).
Applicant is reminded that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See in re Fine, 837 F.2d 1071, 5USPQ2d 1596 (Fed. Cir. 1988), In re Jones, F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR international Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007).
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 32-37, 40-46, and 49-51 are rejected under 35 U.S.C. 102(a1) as being anticipated by Joshi et al. (“Joshi”, US 20210203570 A9) hereinafter Joshi.
Regarding claim 32, Joshi teaches a method implemented by a security service orchestration function, SSOF, in a communication infrastructure ([0168] A Cloud-provider end server process interprets the policies specified by the user(s) and establishes SLAs by the process of negotiation)([0010-0014] list of service providers), that includes a plurality of communication service providers, CSPs ([0062, 0118, 0169, 0207] organizations with enterprise data policies, large organizations with enterprise policies, Table 1, Table 2), for orchestration of a security service level agreement, S-SLA ([0168-0169] A Cloud-provider end server process interprets the policies specified by the user(s) and establishes SLAs by the process of negotiation, Data Encryption policy (data stored encrypted or not; encryption algorithm used, key strength) 13. Compliance policy—compliance or noncompliance for a Trusted Internet Connection (TIC) specification, CC Evaluation Assurance Level (EAL) levels)([0063-0068] Data security policies)([0112] Security Policy a. Roles and Permissions b. Cloud/Service Provider Location constraints c. Data Encryption, Deletion constraints d. Virtualization—Virtual Machine separation e. Multi-tenancy policies), the method comprising:
receiving a S-SLA request, by a CSP of the plurality of CSPs, from one or more other CSPs of the plurality of CSPs, wherein each S-SLA request comprises a plurality of requirements ([0106-0109] Fig. 1, Receive Request for Service, the consumer details the technical and functional specifications that a service needs to fulfill, he consumer also specifies non-functional attributes like characteristics of the human agent providing the service, constraints and preferences on data quality and required security policies for the service. Service compliance details like certifications needed, standards to be adhered to etc. are also identified. The technical specifications lay down the hardware, software, application standards and language support policies to which a service should adhere. Once the consumers have identified and classified their service needs, they issue a Request for Service (RFS))([0116, 0115, 0120] Fig. 2, The security constraints specified in the RFS include policies regarding service role/permission levels, data security policies and cloud location/ownership policies.) ([0116-0120] Fig. 2, The Specification class consists of six main classes that define the functional specifications, technical specifications, Human agent specifications, security policies, service compliance policies and data quality policies, the specifications listed in the RFS)(Fig. 5, availability requirement in the specification, Encryption),([Fig. 3] Consumer-ID)([0158-0160] Fig. 9, SLA Name attached to consumer ID)([0030] Negotiate service level agreement object, security policies object) Fig. 3, consumer ID is unique for each consumer identifying the unique SLA for that enterprise)(Fig. 5, RFS ID related to SLA for that enterprise requesting the services);
converting each S-SLA request into a consistent and unified S-SLA offerable to each other CSP, wherein the consistent and unified S-SLA comprises security attributes that the CSP provides the other CSPs ([0135-0158] Fig. 7 Cloud provider creates contract associated with consumer and list of services that meet the constraints and the available requested service, negotiating the RFS)(Fig. 3, consumer ID is unique for each consumer identifying the unique SLA for that enterprise)(Fig. 5, RFS ID);
offering the consistent and unified S-SLA to each other CSP that submitted the S-SLA request ([0135-0158] Fig. 7 Cloud provider creates contract associated with consumer and list of services that meet the constraints and the available requested service, negotiating the RFS) Fig. 3, consumer ID is unique for each consumer identifying the unique SLA for that enterprise)(Fig. 5, RFS ID); and
receiving a response from each other CSP, wherein the response from each other CSP comprises an acknowledgement or a decline of the consistent and unified S-SLA including a non-repudiation signature of acknowledgement or declining ([0135-0158] Fig. 7, consumer decline or accept services under that RFS-ID/ consumer ID).
Regarding claim 33, Joshi teaches the method of claim 32,
Joshi teaches exchanging information security attributes and associated attribute value ranges between the plurality of CSPs that each CSP provides the other CSPs ([0168-0169] A Cloud-provider end server process interprets the policies specified by the user(s) and establishes SLAs by the process of negotiation, Data Encryption policy (data stored encrypted or not; encryption algorithm used, key strength) 13. Compliance policy—compliance or noncompliance for a Trusted Internet Connection (TIC) specification, CC Evaluation Assurance Level (EAL) levels)([0063-0068] Data security policies)([0112] Security Policy a. Roles and Permissions b. Cloud/Service Provider Location constraints c. Data Encryption, Deletion constraints d. Virtualization—Virtual Machine separation e. Multi-tenancy policies), ([0034-0035] rendering within the graphical user interface of the service consumer a list of matching service providers resulting from the Request for Service, and where the list of matching services contains at least one service provider, automatically generating a service level agreement based upon a user accepting an offer of service from a service provider that is listed in the list of matching services;)( Fig. 3)([0062-0068][0122-0123])([0206-0209] Table 1, Table 2)([0134-0138] service negotiating including data quality, security, response).
Regarding claim 34, Joshi teaches the method of claim 32,
Joshi teaches wherein receiving the S-SLA request comprises receiving a S-SLA request to support specific business services with specified security attributes ([0034-0035] rendering within the graphical user interface of the service consumer a list of matching service providers resulting from the Request for Service, and where the list of matching services contains at least one service provider, automatically generating a service level agreement based upon a user accepting an offer of service from a service provider that is listed in the list of matching services;)( Fig. 3)([0062-0068][0122-0123])([0206-0209] Table 1, Table 2)([0134-0138] service negotiating including data quality, security, response)([0189] the service attributes are the storage size, backup rules, service availability and service costs. Specifications also list acceptable security levels, data quality and performance levels ).
Regarding claim 35, Joshi teaches the method of claim 32,
Joshi teaches negotiating a set of appropriate security attributes and levels that the CSP provides each of the other CSPs ([0034-0035] rendering within the graphical user interface of the service consumer a list of matching service providers resulting from the Request for Service, and where the list of matching services contains at least one service provider, automatically generating a service level agreement based upon a user accepting an offer of service from a service provider that is listed in the list of matching services;)([] Fig. 3)([0062-0068][0122-0123])([0206-0209] Table 1, Table 2)([0134-0138] service negotiating including data quality, security, response).
Regarding claim 36, Joshi teaches the method of claim 32,
Joshi teaches wherein the S-SLA request from each other CSP comprises a plurality of optional information elements or objects and a mandatory information element or object, wherein the plurality of optional information elements or objects comprises, confidentiality attributes, target integrity attributes, target authentication attributes, target availability attributes, target non-repudiation attributes, target isolation attributes, target data sovereignty attributes, validity condition, temporal validity conditions, subscription of S-SLA compliance monitoring events, allowed internet protocol, IP, domains, and extra data protection controls ([0106-0109] Fig. 1, Receive Request for Service, the consumer details the technical and functional specifications that a service needs to fulfill, he consumer also specifies non-functional attributes like characteristics of the human agent providing the service, constraints and preferences on data quality and required security policies for the service. Service compliance details like certifications needed, standards to be adhered to etc. are also identified. The technical specifications lay down the hardware, software, application standards and language support policies to which a service should adhere. Once the consumers have identified and classified their service needs, they issue a Request for Service (RFS))([0116, 0115, 0120] Fig. 2, The security constraints specified in the RFS include policies regarding service role/permission levels, data security policies and cloud location/ownership policies.) ([0116-0120] Fig. 2, The Specification class consists of six main classes that define the functional specifications, technical specifications, Human agent specifications, security policies, service compliance policies and data quality policies, the specifications listed in the RFS)(Fig. 5, availability requirement in the specification, Encryption),([Fig. 3] Consumer-ID)([0158-0160] Fig. 9, SLA Name attached to consumer ID)([0030] Negotiate service level agreement object, security policies object) Fig. 3, consumer ID is unique for each consumer identifying the unique SLA for that enterprise)(Fig. 5, RFS ID related to SLA for that enterprise requesting the services), and
wherein the mandatory information element or object comprise a target CSP identifier (Fig. 5, RFS ID related to SLA for that enterprise requesting the services).
Regarding claim 37, Joshi teaches the method of claim 32, further comprising:
Joshi teaches transforming each S-SLA request into security policies and controls to be enforced within an infrastructure of the CSP (Fig. 8, SLA services converted to security attributes such as requirement, encryption, availability); and/or
monitoring of compliance with the consistent and unified S-SLA of each other CSP that acknowledged or accepted the consistent and unified S-SLA ([0018] monitoring the agreement after establishing the SLA)([0063-0069][0158][0162-0164]).
Regarding claim 40, Joshi teaches the method of claim 32,
Joshi teaches wherein the SSOF comprises a northbound interface reference point configured to interface with each other CSP for negotiating the S-SLA with each other CSP and for exchanging information on S-SLA security attributes ([0136-0145] Fig. 7 Event 1 is where the reference point for starting negotiating the SLA and attributes between consumer and cloud provider).
Regarding claim 41, claim 41 is rejected with the same reasoning as claim 32.
Regarding claim 42, claim 42 is rejected with the same reasoning as claim 33.
Regarding claim 43, Joshi teaches a method implemented by a security service orchestration function, SSOF ([0168] A Cloud-provider end server process interprets the policies specified by the user(s) and establishes SLAs by the process of negotiation)([0010-0014] list of service providers), in a communication infrastructure, that includes a plurality of communication service providers, CSPs, for orchestration of a security service level agreement, S-SLA ([0062, 0118, 0169, 0207] organizations with enterprise data policies, large organizations with enterprise policies, Table 1, Table 2)([0168-0169] A Cloud-provider end server process interprets the policies specified by the user(s) and establishes SLAs by the process of negotiation, Data Encryption policy (data stored encrypted or not; encryption algorithm used, key strength) 13. Compliance policy—compliance or noncompliance for a Trusted Internet Connection (TIC) specification, CC Evaluation Assurance Level (EAL) levels)([0063-0068] Data security policies)([0112] Security Policy a. Roles and Permissions b. Cloud/Service Provider Location constraints c. Data Encryption, Deletion constraints d. Virtualization—Virtual Machine separation e. Multi-tenancy policies), the method comprising:
transmitting a S-SLA request, by a CSP of the plurality of CSPs, to one or more other CSPs of the plurality of CSPs, wherein the S-SLA request comprises security attributes and associated levels to support specific business services with specific security attributes ([0106-0109] Fig. 1, Receive Request for Service, the consumer details the technical and functional specifications that a service needs to fulfill, he consumer also specifies non-functional attributes like characteristics of the human agent providing the service, constraints and preferences on data quality and required security policies for the service. Service compliance details like certifications needed, standards to be adhered to etc. are also identified. The technical specifications lay down the hardware, software, application standards and language support policies to which a service should adhere. Once the consumers have identified and classified their service needs, they issue a Request for Service (RFS))([0116, 0115, 0120] Fig. 2, The security constraints specified in the RFS include policies regarding service role/permission levels, data security policies and cloud location/ownership policies.) ([0116-0120] Fig. 2, The Specification class consists of six main classes that define the functional specifications, technical specifications, Human agent specifications, security policies, service compliance policies and data quality policies, the specifications listed in the RFS)(Fig. 5, availability requirement in the specification, Encryption),([Fig. 3] Consumer-ID)([0158-0160] Fig. 9, SLA Name attached to consumer ID)([0030] Negotiate service level agreement object, security policies object) Fig. 3, consumer ID is unique for each consumer identifying the unique SLA for that enterprise)(Fig. 5, RFS ID related to SLA for that enterprise requesting the services);
receiving a response from each other CSP comprising a unique S-SLA based on the S-SLA request, the unique S-SLA from each other CSP comprising security attributes the other CSP provides ([0135-0158] Fig. 7 Cloud provider creates contract associated with consumer and list of services that meet the constraints and the available requested service, negotiating the RFS) Fig. 3, consumer ID is unique for each consumer identifying the unique SLA for that enterprise)(Fig. 5, RFS ID) ([0135-0158] Fig. 7 Cloud provider creates contract associated with consumer and list of services that meet the constraints and the available requested service, negotiating the RFS)(Fig. 3, consumer ID is unique for each consumer identifying the unique SLA for that enterprise)(Fig. 5, RFS ID) and
merging the security attributes received from each other CSP into a common security baseline template S-SLA for communication to business services users of the CSP ([0091] Providers may need to combine their services with other resources or providers' services to meet consumer needs)([0135] the service provider will need to combine a set of services or compose a service from various components delivered by distinct service providers in order to meet the consumer's requirements)([0160-0161] one or more components provided by one or more providers are combined and delivered as a single service).
Regarding claim 44, Joshi teaches the method of claim 43,
Joshi teaches exchanging information security attributes and associated attribute value ranges between the plurality of CSPs that each CSP provides the other CSPs ([0168-0169] A Cloud-provider end server process interprets the policies specified by the user(s) and establishes SLAs by the process of negotiation, Data Encryption policy (data stored encrypted or not; encryption algorithm used, key strength) 13. Compliance policy—compliance or noncompliance for a Trusted Internet Connection (TIC) specification, CC Evaluation Assurance Level (EAL) levels)([0063-0068] Data security policies)([0112] Security Policy a. Roles and Permissions b. Cloud/Service Provider Location constraints c. Data Encryption, Deletion constraints d. Virtualization—Virtual Machine separation e. Multi-tenancy policies), ([0034-0035] rendering within the graphical user interface of the service consumer a list of matching service providers resulting from the Request for Service, and where the list of matching services contains at least one service provider, automatically generating a service level agreement based upon a user accepting an offer of service from a service provider that is listed in the list of matching services;)( Fig. 3)([0062-0068][0122-0123])([0206-0209] Table 1, Table 2)([0134-0138] service negotiating including data quality, security, response); and/or
negotiating a set of appropriate security attributes and associated levels that each other CSP provides the CSP that transmitted the S-SLA request.
Regarding claim 45, Joshi teaches the method of claim 43, wherein the S-SLA request comprises a plurality of optional information elements or objects and a mandatory information element or object,
wherein the plurality of optional information elements or objects comprises, confidentiality attributes, target integrity attributes, target authentication attributes, target availability attributes, target non-repudiation attributes, target isolation attributes, target data sovereignty attributes, validity condition, temporal validity conditions, subscription of S-SLA compliance monitoring events, allowed internet protocol, IP, domains, and extra data protection controls ([0106-0109] Fig. 1, Receive Request for Service, the consumer details the technical and functional specifications that a service needs to fulfill, he consumer also specifies non-functional attributes like characteristics of the human agent providing the service, constraints and preferences on data quality and required security policies for the service. Service compliance details like certifications needed, standards to be adhered to etc. are also identified. The technical specifications lay down the hardware, software, application standards and language support policies to which a service should adhere. Once the consumers have identified and classified their service needs, they issue a Request for Service (RFS))([0116, 0115, 0120] Fig. 2, The security constraints specified in the RFS include policies regarding service role/permission levels, data security policies and cloud location/ownership policies.) ([0116-0120] Fig. 2, The Specification class consists of six main classes that define the functional specifications, technical specifications, Human agent specifications, security policies, service compliance policies and data quality policies, the specifications listed in the RFS)(Fig. 5, availability requirement in the specification, Encryption),([Fig. 3] Consumer-ID)([0158-0160] Fig. 9, SLA Name attached to consumer ID)([0030] Negotiate service level agreement object, security policies object) Fig. 3, consumer ID is unique for each consumer identifying the unique SLA for that enterprise)(Fig. 5, RFS ID related to SLA for that enterprise requesting the services), and
wherein the mandatory information element or object comprise a target CSP identifier (Fig. 5, RFS ID related to SLA for that enterprise requesting the services).
Regarding claim 46, Joshi teaches the method of claim 43, further comprising:
Joshi teaches monitoring, by the CSP, that the other CSPs are in compliance with the common security baseline template S-SLA (Fig. 8, SLA services converted to security attributes such as requirement, encryption, availability)([0018] monitoring the agreement after establishing the SLA)([0063-0069][0158][0162-0164]); and/or
monitoring, by the CSP, a service specific capability on demand or at service specific intervals.
Regarding claim 49, claim 49 is rejected with the same reasoning as claim 40.
Regarding claim 50, claim 50 is rejected with the same reasoning as claim 43.
Regarding claim 51, claim 51 is rejected with the same reasoning as claim 33.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 38-39, and 47-48 are rejected under 35 U.S.C. 103 as being un-patentable by Joshi et al. (“Joshi”, US 20210203570 A9) hereinafter Joshi, in view of Trapero et al. (“Trapero”, A Noval Approach to manager cloud Security SLA, Elsevier 2017) hereinafter Trapero.
Regarding claim 38, Joshi teaches the method of claim 32,
Joshi does not explicitly teach, but Trapero teaches
wherein the SSOF interacts with supporting security management functions to perform a set of ([Page 198] Fig. 4, SPECS architecture, Negotiating/monitoring module, and Enforcement Module including implementation component)([Page 197]) functions comprising:
sending enterprise S-SLA information and security attribute information associated with a particular CSP to the supporting security management functions ([Page 197] The signed secSLA is sent to the Planning component of the Enforcement module, which prepares a so-called implementation plan which specifies resources to be set up, security mechanisms to be deployed in order to enforce and monitor the negotiated
security features, and their configuration.);
receiving S-SLA compliance status reports on requested intervals and on demand in response to a request from the particular CSP ([Page 201] the CSP should (a) retrieve data related to published vulnerabilities, (b) generate vulnerability list, (c) perform vulnerability scan, (d) generate scanning report, and (e) check if the age of the report is under the threshold set by the CSC (to ensure that the report has been generated). Similarly, in order to enforce and verify validity of the SLO associated to metric MCS, the CSP (a) retrieves data related to disclosed vulnerabilities, (b) generates vulnerability list, (c) performs vulnerability scan, (d) generates scanning report, (e) determines maximum CVSS of all detected vulnerabilities, and (f) checks if the risk level of the vulnerability with the highest
CVSS score is below the threshold set by the CSC)(tables 8 and 9, generate scanning reports frequently); and
receiving S-SLA compliance violation reports in real-time ([page 203] The involved measurement MDCS is the core measurement for the metric MCS, so the event represents a violation of SLO2 and thus a violation of the entire secSLA. The CSP can determine the severity level of the violation according to CSC’s assigned importance weights to SLO2.)(Fig. 8, Fig. 9, alert/violation SLO).
It would have been obvious to a person skilled in the art, before the effective filing date of the invention, to modify Joshi in view of Trapero in order to have monitoring component along with implementation component to provide status reports and detect any violation in the SLA because it detects occurrences that lead to unfulfillment of commitments, and also provide mitigation to the harmful events that may or do compromise the validity of secSLAs. (Trapero [Abstract]).
Regarding claim 39, Joshi and Trapero teach the method of claim 38,
Joshi does not explicitly teach, but Trapero teaches
receiving, from the SSOF, security requirement and security attribute information for fulfilling the S-SLA of each other CSP and mapping the security requirement and security attribute information into security policies and security controls for enforcement within the communication infrastructure and network entities of the CSP;
supporting security management activities related to safeguarding of network functions, NF, and network elements, NE;
monitoring S-SLA status of NF and NE according to set security attributes ([page 202] Consider a CSC who wants to acquire a pool of web servers and secure them with the SVA mechanism. Let us assume that the CSC signs a secSLA with two SLOs, namely SLO1 with medium importance defined as VSF = 24 h and SLO2 with low importance defined as MCS = 4. According to Table 4, the CSP has to monitor all defined SVA measurements, and the following monitoring rules have to be periodically evaluated: SRA ≤ 24 h, MDCS ≤ 4, RAV = yes, VLAV = yes, and SAV = yes., web servers on VMs);
calculating compliance status in real-time for the S-SLA of each CSP and notifying compliance scores and compliance violations to the security service orchestration function; and
maintaining historical information for S-SLA compliance per CSP.
It would have been obvious to a person skilled in the art, before the effective filing date of the invention, to modify Joshi in view of Trapero in order to have monitoring component along with implementation component to provide status reports and detect any violation in the SLA because it detects occurrences that lead to unfulfillment of commitments, and also provide mitigation to the harmful events that may or do compromise the validity of secSLAs. (Trapero [Abstract]).
Regarding claim 47, claim 47 is rejected with the same reasoning as claim 38.
Regarding claim 48, claim 48 is rejected with the same reasoning as claim 39.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FADI HAJ SAID whose telephone number is (571)272-2833. The examiner can normally be reached on 8:00 AM - 5:00 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, John Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/FADI HAJ SAID/Primary Examiner, Art Unit 2444