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 .
This office action is in response to amendments filed on June 19, 2025.
Claims 60, 62 have been amended.
Claims 54-73 are pending.
Response to Arguments
The rejections regarding 35 U.S.C. 112(b) with regards to the limitation of “the third party” and “the first TCS” as recited in Claims 61 and 62 respectively have been withdrawn as the claims have been amended. Applicant's arguments filed June 19, 2025 have been fully considered but they are not persuasive.
Regarding the rejection regarding 35 U.S.C. 112(b), Applicant argues that the phrase "the software and/or the computing platform associated with the cryptographic attestation" has antecedent basis earlier in Claim 60 (Remarks, Page 10, Par. 3). Examiner respectfully disagrees. The phrase “the software and/or the computing platform associated with the cryptographic attestation" can be read as the two items “the software” and “the computing platform associated with the cryptographic attestation” joined by the conjunction of “and/or”. Therefore, the recitation of “the software” can refer to the software recited in Claim 54 from which Claim 60 depends upon, or the software recited in Claim 60.
Regarding the rejections regarding 35 U.S.C. 103, Applicant explains the concept of the claimed invention with regards to trusted computing services in Pages 11-12 of Remarks. In particular, Applicant discusses issues with regards to “trusted computing” and provides the example that “there are currently no solutions that enable a user to find a domain name service (DNS) resolver running specific software inside a trusted computing environment”. Examiner would like to note that the claimed term of a “trusted computing service” is not defined within the Applicant’s specification and is subject to the broadest reasonable interpretation. In particular, the term “trusted computing service” can broadly be interpreted to mean a “computing service” which is considered “trusted” in some manner, or alternatively a “service” related to “trusted computing”. In these examples, the scope of the word “service” has broad connotations, and it is recommended by the Examiner to narrow the meaning of what they consider to be a trusted computing service if they believe the aspects of the invention differ from the prior art.
In pages 12-13 of Remarks, Applicant mainly argues that prior art reference Scott-Nash does not teach the claimed limitations of Claim 54 of the claimed invention with regards to selecting a trusted computing service. This argument is moot as prior art reference He was used to teach these limitations in the previous Office Action.
In pages 14-15 of Remarks, Applicant mainly argues that prior art reference He does not teach the claimed limitations of Claim 54 with a first assertion that He does not teach identification of software or trust indicia, and a second assertion that “the list of control nodes” of He has no relation to “information related to one or more available trusted computing services”. Regarding the first assertion, this argument is moot as prior art reference Scott-Nash was used to teach these limitations. Regarding the second assertion, the phrase “information related to one or more available trusted computing services” is subject to broad interpretation, as it is directed to information which is merely related to a trusted computing service, and a trusted computing service as argued above was already subject to broad interpretation. The task described in He can be considered a trusted computing service merely by the use of encryption under the broadest reasonable interpretation as claimed (He, Par. [0084]). Furthermore, in the context of the combination of Scott-Nash and He taken together, the task handling of He is combined with the service requested by Scott-Nash which was previously argued to be a trusted computing service.
In pages 16-17 of Remarks, Applicant argues that prior art reference Scott-Nash does not teach the claimed limitations of Claim 63 with regards to identifiers regarding a trusted computing service and associated software, and mainly argues that Scott-Nash’s digital object identifiers (DOI) as relied upon in the previous Office Action relate to data as opposed to software or a trusted computing service. Examiner respectfully disagrees. In Scott-Nash, code is also assigned a digital object identifier; this can be seen in Par. [0037] of Scott-Nash: “repository 507 may store both registered data and code, each identified by a DOI”. The aspects of treating code with a DOI is further elaborated in Par. [0029], Par. [0031], Par. [0032] of Scott-Nash.
In pages 17-18 of Remarks, Applicant argues that prior art reference He does not teach the claimed limitations of Claim 63 with a first assertion that He is silent about trusted computing and a second assertion that He does not teach “an indication of a selection of” a TCS. Examiner respectfully disagrees. With regards to the first assertion, this has been previously argued against above in the arguments regarding Claim 54. With regards to the second assertion, the phrase “indication of a selection of” is subject to broad interpretation through the use of the word “indication”. The mere attempt at connection between a user device and a selected node as in He can be considered an “indication of a selection” under the broadest reasonable interpretation. It is recommended by the Examiner to clarify what this “indication” entails and to narrow the scope of the term.
In pages 17-18 of Remarks, Applicant argues that prior art references Scott-Nash/He do not teach the claimed limitations of Claim 72 and rely upon the previous arguments above. Accordingly, the above arguments by the Examiner are used with respect to the Applicant’s arguments with regards to Claim 72.
For these reasons, the rejections regarding 35 U.S.C. 103 are maintained.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 60-62 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 60 recites the limitation "the software" in line 6 of Claim 60. There is insufficient antecedent basis for this limitation in the claim. Claim 60 previously recites software in line 3 of Claim 60 and depends upon Claim 54 which recites software required to provide a required TCS, so it is ambiguous as to which “the software” is meant to refer to and the claim is rendered indefinite. It is recommended by the Examiner to more clearly distinguish the software recited in Claim 60.
Claims 61 and 62 are rejected by virtue of depending upon Claim 60. Claim 61 further recites “the software” in line 3 of Claim 61.
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.
Claims 54-57, 60-66, 69-73 are rejected under 35 U.S.C. 103 as being unpatentable over Scott-Nash et al. (U.S. Pub. No. 2018/0096412 A1) hereinafter referred to as “Scott-Nash” and in view of He (U.S. Pub. No. 2018/0341662 A1) hereinafter referred to as “He”.
Regarding Claim 54:
Scott-Nash teaches the following limitations:
A method performed by a computing device to obtain trusted computing services (TCS), from service providers (SPs) [publishers], the method comprising: querying one or more remote service databases for one or more TCS [analytics code] required by a user of the computing device [subscriber] or by an application executing on the computing device (Par. [0015], Par. [0024], Par. [0025], Par. [0029], Par. [0037]). Scott-Nash teaches a digital brokerage service where subscribers request trusted computation from publishers.
wherein the query for each of the required TCS includes the following: identification of software required to provide the required TCS [uniform resource identifiers], and one or more indicia of trust for any computing platform that provides the required TCS [specific trusted environment] (Par. [0026], Par. [0037], Par. [0038]). Scott-Nash teaches that a request from a subscriber identifies the analytics code requested through URIs, and specifies the required trusted execution environment, i.e. indicia of trust under the broadest reasonable interpretation.
(taught by He below)
(taught by He below)
He teaches the following limitations:
receiving, from the one or more remote service databases, information related to one or more available TCS and corresponding SPs of the available TCS [control nodes] (Par. [0207], Par. [0270]). He teaches users receiving a list of control nodes for performing a task and their reliability in response to their computation requirements. This is information related to the available trusted computing services (TCS) under the broadest reasonable interpretation as the control nodes provide the TCS.
and based on the received information, selecting one of the available TCS and establishing a connection with the SP corresponding to the selected TCS (Par. [0207], Par. [0247], Par. [0252], Par. [0270]). He teaches a user selecting the nodes for performing the task and sending a service request from the user to the node, i.e. establishing a connection.
Scott-Nash teaches matching subscribers and publishers for trusted computation according to satisfying execution policies, does not teach user selection of the trusted computing service. He however teaches that a user can be presented with a list of nodes approved to perform a requested service as an alternative for task orchestration, and that this has the benefit of increased service reliability by allowing end users to select nodes according to the nodes’ reliability and their computation requirements (Par. [0084], Par. [0270]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the digital brokerage system of Scott-Nash with the user selection of He in order to gain the benefit of increased service reliability. One of ordinary skill in the art would have recognized that the user selection of He is compatible with the digital brokerage system of Scott-Nash as they both relate to task orchestration, and that by having users select the nodes for performing the requested computation, reliability is increased as users can choose nodes according to their reliability and the user’s needs.
Regarding Claim 55:
Scott-Nash teaches the following limitation:
wherein the identification of software in the query for each required TCS includes one of the following: a hash value [signed digest] of a software image and of all associated configuration data; or an indication of a third party that can sign a statement that a particular software image and configuration data is acceptable for the required TCS (Par. [0022], Par. [0029], Par. [0046]). Scott-Nash teaches including a signed digest, i.e. hash, of the requested analytics code as part of the identifying the software.
Regarding Claim 56:
Scott-Nash teaches the following limitations:
wherein: the query for each required TCS includes a human-readable service name [header] associated with the required TCS (Par. [0038], Par. [0046]). Scott-Nash teaches identifying services with a header. This is considered to be a human-readable service name under the broadest reasonable interpretation.
and the identification of software in the query for each required TCS includes a location from which the software can be obtained (Par. [0038], Par. [0046]). This further includes URIs which include a location for obtaining the analytics code.
Regarding Claim 57:
Scott-Nash teaches the following limitation:
wherein the indicia of trust in the query for each TCS include one or more of the following: roots of trust from a manufacturer of CPUs trusted to perform the TCS; one or more types of computing technology trusted to perform the TCS; one or more types of computing technology not trusted to perform the TCS; and features that must be enabled or disabled for trusting a computing platform to perform the TCS (Par. [0026], Par. [0038], Par. [0046]). Scott-Nash specifies the requested trusted execution environment and execution policy.
Regarding Claim 60:
Scott-Nash teaches the following limitations:
further comprising: receiving, from the selected TCS via the connection, a cryptographic attestation [dynamic attestation] associated with software and/or computing platform used for the selected TCS (Par. [0033], Par. [0036], Par. [0039]). Scott-Nash teaches requiring an attestation to verify the node being used to perform the TCS.
and based on verifying the cryptographic attestation is valid and meets requirements provided in the query [verify acceptable TEE], obtaining the selected TCS via the software and/or the computing platform associated with the cryptographic attestation [submit package] (Par. [0033], Par. [0036], Par. [0039]). Scott-Nash teaches verifying the attestation involves checking whether the TEE is an acceptable TEE with the requirements, and then supplying the package for the analytics code, i.e. TCS.
Regarding Claim 61:
Scott-Nash teaches the following limitations:
wherein: the method further comprises receiving, from the selected TCS, a digital signature indicating that a particular version of the software is acceptable for the selected TCS (Par. [0022], Par. [0029], Par. [0032]). Scott-Nash additionally teaches including a digital signature for the software to be run.
and obtaining the selected TCS is also based on verifying that the third party is trusted and the digital signature is valid (Par. [0022], Par. [0029], Par. [0032]). Scott-Nash teaches verifying a remote attestation and digital signature in order to proceed with performing the TCS.
Regarding Claim 62:
Scott-Nash teaches the following limitations: wherein: the received information related the one or more available TCS includes information related to a first TCS (Par. [0027], Par. [0033], Par. [0039]).
the information related to the first TCS includes an indication that the first TCS is willing to run any user-provided software (Par. [0027], Par. [0033], Par. [0039]). Previously, Scott-Nash was combined with the user selection of He in such a manner that the list of nodes presented represent approved nodes which satisfy the subscriber’s and publisher’s execution policies. For this reason, this is considered to be an indication of the TCS being willing to run user-provided software, as both parties have agreed on the execution requirements. and selecting one of the available TCS and establishing a connection with the SP corresponding to the selected TCS comprises: selecting the first TCS based on the indication that the first TCS is willing to run any user-provided software (Par. [0027], Par. [0033], Par. [0039]). This selection is based on this indication, as the list was formed from such matching in Scott-Nash in combination with He.
and sending one of the following to the first TCS via the connection: a software image and all associated configuration data; or an indication of a trusted location from which the selected TCS can obtain a software image and all associated configuration data (Par. [0038], Par. [0046]). As argued previously, the URIs for fetching software for execution are provided for running analytics code.
Regarding Claim 63:
Scott-Nash teaches the following limitations:
A method performed by a service provider (SP) of trusted computing services (TCS), the method comprising: sending, to a remote service database (Par. [0015], Par. [0024], Par. [0025], Par. [0029], Par. [0037], Par. [0061]). Scott-Nash teaches publishers registering their services/data in a digital brokerage system.
the following information related to each of one or more TCS available from the SP: an identifier of the available TCS (Par. [0020], Par. [0022], Par. [0037], Par. [0044]). Scott-Nash teaches providing identifiers related to the policies/digital objects offered by a publisher.
identification of software used to provide the available TCS (Par. [0020], Par. [0022], Par. [0037], Par. [0044]). These further include identifiers of code, i.e. software.
and one or more indicia of trust for a computing platform used to provide the available TCS (Par. [0025], Par. [0030], Par. [0037], Par. [0044]). Scott-Nash further teaches publisher nodes storing their capabilities, i.e. the security protocols/trusted environments provided by the publisher, which are indicias of trust under the broadest reasonable interpretation.
(taught by He below)
He teaches the following limitation:
and receiving, from a computing device, an indication of selection of one of the available TCS by a user of the computing device or by an application executing on the computing device, and establishing a connection with the computing device (Par. [0207], Par. [0247], Par. [0252], Par. [0270]).
Scott-Nash teaches matching subscribers and publishers for trusted computation according to satisfying execution policies, does not teach user selection of the trusted computing service. He however teaches that a user can be presented with a list of nodes approved to perform a requested service as an alternative for task orchestration, and that this has the benefit of increased service reliability by allowing end users to select nodes according to the nodes’ reliability and their computation requirements (Par. [0084], Par. [0270]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the digital brokerage system of Scott-Nash with the user selection of He in order to gain the benefit of increased service reliability. One of ordinary skill in the art would have recognized that the user selection of He is compatible with the digital brokerage system of Scott-Nash as they both relate to task orchestration, and that by having users select the nodes for performing the requested computation, reliability is increased as users can choose nodes according to their reliability and the user’s needs.
Regarding Claim 64:
Scott-Nash teaches the following limitation:
wherein the identification of software for each available TCS includes one of the following: a hash value of a software image and of all associated configuration data; or an indication of a third party that can sign a statement that a particular software image and configuration data is acceptable for the available TCS (Par. [0022], Par. [0029], Par. [0046]). It was previously shown in the rejection of Claim 55 that Nash teaches identifying software by including a signed digest.
Regarding Claim 65:
Scott-Nash teaches the following limitation:
wherein for each available TCS: the identifier of the available TCS includes a human-readable service name; and the identification of the software includes a location from which the software can be obtained (Par. [0038], Par. [0046]). It was previously shown in the rejection of Claim 56 that Nash teaches identifying services with a header and URIs.
Regarding Claim 66:
Scott-Nash teaches the following limitation:
wherein the indicia of trust for each available TCS include one or more of the following: roots of trust from a manufacturer of CPUs used to provide the available TCS; one or more types of computing technology used to provide the available TCS; and features that are enabled or disabled in the computing platform used to provide the available TCS (Par. [0026], Par. [0038], Par. [0046]).
Regarding Claim 69:
Scott-Nash teaches the following limitations:
further comprising: providing, by the selected TCS to the computing device via the connection, a cryptographic attestation associated with software and/or computing platform used for the selected TCS; and providing the selected TCS to the computing device via the software and/or the computing platform associated with the cryptographic attestation (Par. [0033], Par. [0036], Par. [0039]).
Regarding Claim 70:
Scott-Nash teaches the following limitations:
further comprising providing, by the selected TCS to the computing device via the connection, a digital signature indicating that a particular version of the software is acceptable for the selected TCS (Par. [0022], Par. [0029], Par. [0032]).
Regarding Claim 71:
Scott-Nash teaches the following limitations:
wherein: the information related to a first TCS, of the available TCS, that is sent to the remote service database includes an indication that the first TCS is willing to run any user-provided software; the selected TCS is the first TCS (Par. [0027], Par. [0033], Par. [0039]).
the method further comprises obtaining a software image and all associated configuration data for the software used for the first TCS from one of the following: directly from the computing device via the connection, or from a trusted location indicated by the computing device; and the cryptographic attestation is based on the obtained software image and all associated configuration data (Par. [0038], Par. [0046]).
Regarding Claim 72:
Scott-Nash teaches the following limitations:
A method performed by a service database of trusted computing services (TCS) to match required TCS to available TCS, the method comprising: receiving, from a plurality of service providers (SPs) (Par. [0015], Par. [0024], Par. [0025], Par. [0029], Par. [0037], Par. [0061]).
the following information related to each of one or more TCS available from each of the SPs: an identifier of the available TCS (Par. [0020], Par. [0022], Par. [0037], Par. [0044]).
identification of software used to provide the available TCS (Par. [0020], Par. [0022], Par. [0037], Par. [0044]).
and one or more indicia of trust for a computing platform used to provide the available TCS (Par. [0025], Par. [0030], Par. [0037], Par. [0044]).
storing the information from the SPs in the service database (Par. [0020], Par. [0022], Par. [0037], Par. [0044]). Scott-Nash was previously shown to teach recording the capabilities of a publisher for a TCS in a repository of the digital brokerage system.
receiving a query for one or more TCS required by a user of a computing device or by an application executing on the computing device (Par. [0015], Par. [0024], Par. [0025], Par. [0029], Par. [0037]).
wherein the query for each of the required TCS includes: identification of software required to provide the required TCS and one or more indicia of trust for any computing platform that provides the required TCS (Par. [0026], Par. [0037], Par. [0038]).
identifying, from the stored information, one or more available TCS that corresponds to the information provided with the query (Par. [0027], Par. [0033], Par. [0039]). Scott-Nash matches subscribers and providers according to the query.
(taught by He below)
He teaches the following limitations:
and sending, to the computing device in response to the query, an indication of the identified available TCS and corresponding SPs of the identified available TCS (Par. [0207], Par. [0247], Par. [0252], Par. [0270]). He was previously shown to teach providing a list of nodes for performing a service, i.e. an indication of the TCS and SPs under the broadest reasonable interpretation.
Scott-Nash teaches matching subscribers and publishers for trusted computation according to satisfying execution policies, does not teach user selection of the trusted computing service. He however teaches that a user can be presented with a list of nodes approved to perform a requested service as an alternative for task orchestration, and that this has the benefit of increased service reliability by allowing end users to select nodes according to the nodes’ reliability and their computation requirements (Par. [0084], Par. [0270]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the digital brokerage system of Scott-Nash with the user selection of He in order to gain the benefit of increased service reliability. One of ordinary skill in the art would have recognized that the user selection of He is compatible with the digital brokerage system of Scott-Nash as they both relate to task orchestration, and that by having users select the nodes for performing the requested computation, reliability is increased as users can choose nodes according to their reliability and the user’s needs.
Regarding Claim 73:
Scott-Nash teaches the following limitations:
wherein each identification of software used to provide an available TCS and each identification of software required to provide a required TCS includes one of the following: a hash value of a software image and of all associated configuration data; or an indication of a third party that can sign a statement that a particular software image and configuration data is acceptable for the required TCS (Par. [0022], Par. [0029], Par. [0046]).
Claims 58, 67 are rejected under 35 U.S.C. 103 as being unpatentable over Scott-Nash/He, and further in view of Zapata et al. (U.S. Pub. No. 2007/0112944 A1) hereinafter referred to as “Zapata”.
Regarding Claim 58:
Zapata teaches the following limitation:
wherein the query for each required TCS includes one of the following: a requirement for the required TCS to be single-user; a requirement for the required TCS to be multi-user; or an indication that the required TCS can be single-user or multi-user (Par. [0044], Par. [0046]). Zapata teaches a service request containing an identification of multiple users being served.
Scott-Nash/He do not teach indicating a TCS to be single-user or multi-user. Zapata however teaches that while a service deployment request is commonly assumed to be for a single user, a service request can additionally indicate a set of users for the service (Par. [0046]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the digital brokerage system of Scott-Nash/He with the user specification of Zapata in order to gain the predictable result of indicating in the query whether the TCS is single-user or multi-user. One of ordinary skill in the art would have recognized that the user specification of Zapata is compatible with the digital brokerage system of Scott-Nash/He as they both relate to service deployment requests, and that such a user specification would lead to the predictable result of indicating whether the TCS is single-user or multi-user.
Regarding Claim 67:
Zapata teaches the following limitation:
wherein information sent to the remote service database also includes one of the following for each available TCS: an indication that the available TCS can only be single-user; an indication that the available TCS can only be multi-user; or an indication that the available TCS can be single-user or multi-user (Par. [0044], Par. [0046]).
Scott-Nash/He do not teach indicating a TCS to be single-user or multi-user. Zapata however teaches that while a service deployment request is commonly assumed to be for a single user, a service request can additionally indicate a set of users for the service (Par. [0046]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the digital brokerage system of Scott-Nash/He with the user specification of Zapata in order to gain the predictable result of indicating in the query whether the TCS is single-user or multi-user. One of ordinary skill in the art would have recognized that the user specification of Zapata is compatible with the digital brokerage system of Scott-Nash/He as they both relate to service deployment requests, and that such a user specification would lead to the predictable result of indicating whether the TCS is single-user or multi-user.
Claim 59 is rejected under 35 U.S.C. 103 as being unpatentable over Scott-Nash/He, and further in view of el Essaili et al. (U.S. Pub. No. 2020/0267517 A1) hereinafter referred to as “el Essaili”.
Regarding Claim 59:
el Essaili teaches the following limitations:
further comprising: querying one or more first remote databases for information concerning further remote databases of available TCS (Par. [0014], Par. [0017]). el Essaili teaches that an application server can be queried for further address information for service discovery.
and receiving, from the one or more first databases, addresses of the one or more remote service databases (Par. [0014], Par. [0017]). This further address information is returned as a response.
Scott-Nash/He do not teach querying databases for the addresses of additional service databases. el Essaili however teaches that such querying can be performed to discover other services, and that this has the benefit of facilitating service access (Par. [0012], Par. [0014]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the digital brokerage system of Scott-Nash/He with the querying of el Essaili in order to gain the benefit of improved service discovery. One of ordinary skill in the art would have recognized that the querying of el Essaili is compatible with the digital brokerage system of Scott-Nash/He as both relate to service requesting systems, and that performing such additional querying as in el Essaili allows for easier and improved discovery of available services for computing.
Claim 68 is rejected under 35 U.S.C. 103 as being unpatentable over Scott-Nash/He, and further in view of Iyengar et al. (U.S. Pub. No. 10,924,340 B1) hereinafter referred to as “Iyengar”.
Regarding Claim 68:
Iyengar teaches the following limitations:
wherein: receiving the indication of a selection is via a first address (Col. 16, lines 4-29). Iyengar teaches identifying data source systems by address.
and the method further comprises: when an instance of the selected TCS is already running on the computing platform and a load level of the already-running instance is below a threshold, assigning the computing device to the already-running instance (Claim 1, Col. 5, lines 42-67, Col. 17, lines 1-9). Iyengar teaches that data source systems can be checked for load against a threshold, and creating a new instance if the load surpasses a threshold for handling requests. This suggests that the load being below a threshold means that an already running instance services a request.
otherwise, initiating an instance of the selected TCS and assigning the computing device to the initiated instance (Claim 1, Col. 5, lines 42-67, Col. 17, lines 1-9). On the other hand, a new instance is replicated to handle a new request when the load is above the threshold.
and redirecting the connection from the first address to a second address associated with the assigned instance of the selected TCS (Claim 1, Col. 20, lines 1-28, Col. 22, lines 1-12). Iyengar teaches port forwarding for the clone instance, i.e. at a second address, to service the request.
Scott-Nash/He do not teach creating a new instance in response to a load threshold. Iyengar however teaches that a system can replicate an instance in order to load balance and reduce the load on a source system by offloading tasks to the new instance (Col. 2, lines 36-47). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the digital brokerage system of Scott-Nash/He with the instance replication of Iyengar in order to gain the benefit of load balancing through offloading computation. One of ordinary skill in the art would have recognized that the instance replication of Iyengar is compatible with the digital brokerage system of Scott-Nash/He as they both relate to servicing user requests in the cloud, and that such instance replication has the benefit of reducing load on a particular system through load balancing.
Related Art
The following prior art made of record and cited on PTO-892, but not relied upon, is considered pertinent to applicant’s disclosure:
Sun et al. (U.S. Pub. No. 2018/0329729 A1) – Includes methods regarding workflow orchestration
Jagana et al. (U.S. Pub. No. 2015/0127795 A1) – Includes methods regarding trusted computing
Bursell (U.S. Pub. No. 2022/0103379 A1) – Includes methods regarding trusted workload provisioning
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 ETHAN V VO whose telephone number is (571)272-2505. The examiner can normally be reached M-F 8am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571)272-2092. 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.
/E.V.V./Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431
