DETAILED ACTION
This Office Action is in response to the Amendment filed on 04/15/2026.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the instant Amendment, filed on 04/15/2026, no claims have been amended.
Claims 1-20 have been examined and are pending in this application. Claims 1, 4, and 16 are independent. This Action is made FINAL.
Response to Arguments/Remarks
Applicant’s arguments in the instant Amendment, filed on 04/15/2026, with respect to the prior-art rejections to claims 1-20, and limitations listed below, have been fully considered but they are not persuasive.
Applicant’s Remarks: As to the independent claim 1, the Applicant submits that the applied prior art does not teach the limitation “performing, by the serving cloud, device discovery for devices linked to the destination cloud.” Providing evidence, the Applicant described the features of the applied reference, Shanmugasundaram, in detail, with respect to the cited paragraphs in the rejection, and concluded that nothing in these passages describes any device discovery operation performed by a serving cloud. The devices in Shanmigasundaram are already provisioned and represented within the system (e.g., through "data representation[s]" administrated by the servers), and the cloud adapter simply accesses them using APIs and access tokens (Applicant Arguments/Remarks, 04/15/2026, pages 8-11).
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Shanmugasundaram reference teaches the limitations as applied in the rejections. The claim limitation does not refine as to what specific algorithm, technology, or process is applied to conduct the discovery, nor provide any data identification that would equate to that indicate that the result of the discovery. In attempt to differentiate the applied PriorArt from the claim limitations, the Applicant analyzed the disclosure of Shanmugasundaram, and made interpretation and conclusion of the Shanmugasundaram’s teaching of what it does and what cannot. However, the Applicant has not made any analysis of the addressed claim limitation, what the claim limitation’s scope is, and how it functions, at what condition(s) and/or algorithm(s) is been followed, to show a difference from the applied PriorArt. To one of ordinary skill in the art, a result or a fact that the devices are in initial communication or linked/provisioned, as the Applicant rightfully pointed out, would be considered that the discovery has been made. As applied din the rejection, Shanmugasundaram teaches of cloud server pulling information from the first or second IOT device or pushing commands to the first or second IOT device (Pars 0004-0005, 0024-0025; Fig 2, 3). Therefore, broadly interpreted Shanmugasundaram teaches the addressed claim limitation.
Applicant’s Remarks: As to the independent claim 1, the Applicant submits that the applied prior art does not teach the limitation “determining, based at least in part on a connector selection rule set, a particular cloud-to-cloud connector from a plurality of cloud-to-cloud connectors that are capable of [connecting] from the serving cloud to the destination cloud; [ ] using the access token,” as mapped in the claim rejection. Providing evidence, the Applicant, again, described the features of the applied reference, Shanmugasundaram, in detail, with respect to the cited paragraphs in the rejection, and concluded that nothing in these paragraphs indicates that a serving cloud evaluates a plurality of connectors and determines which connector should be used for communication with a destination cloud. Instead, the connector already exists and is configured with attribute mappings, and it is invoked when an attribute change occurs (Applicant Arguments/Remarks, Arguments/Remarks, 04/15/2026, pages 11-13).
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Shanmugasundaram reference teaches the limitations as applied in the rejections. The claim limitation does not refine as to what specific algorithm, technology, or process is applied to perform the “determining” function; but merely citing that “based … on a connector selection rule set, without citing any algorithm/process that is followed for the “based … on” nor cites any detail of the “rule set.”. In attempt to differentiate the applied PriorArt from the claim limitations, the Applicant analyzed the disclosure of Shanmugasundaram, and made interpretation and conclusion of the Shanmugasundaram’s teaching of what it does and what cannot. However, the Applicant has not made any analysis of the addressed claim limitation, what the claim limitation’s scope is, and how the “determining” function is performed, to show a difference from the applied PriorArt. To one of ordinary skill in the art, a result or a fact that the connection has been made using the connectors, and some rule has been followed, would be considered that the “determination” process is made. Shanmugasundaram teaches of using the cloud connectors 303 and 304, the cloud 204 [i.e., the serving cloud] creates a connection path between devices of clouds 305 and 307, cloud connectors ensure synchronization of device attributes across all clouds, facilitating the enforcement of consistency between all clouds using access token. The core adaptor executes the rules for connection and communication (Pars 0005, 0024-0025, 0028-0029, 0047). Therefore, broadly interpreted Shanmugasundaram teaches the addressed claim limitation.
As to the independent claims 4 and 16, the Applicant submits that the claims cite similar limitations as to the independent claim 1, and the rejections be withdrawn for the same reasons set forth above for claim 1.
The Examiner disagrees with the Applicants. The Examiner respectfully submits that the claims 4 and 16 are rejected at least based on the reference applied to the claims and the rationale and response presented to the argument above for claim 1.
Additionally, as to the dependent claims 2, 3, 5-15, and 17-20, the Applicant requested that the rejections to the claims be withdrawn based on their dependency from the allowable base claims, respectively, and furthermore, the additional patentable elements that the claims cite (Applicant Arguments/Remarks, 04/15/2026, pages 13-14).
The Examiner disagrees with the Applicants. The Examiner respectfully submits that the dependent claims 2, 3, 5-15, and 17-20 are rejected at least based on the rationale and response presented to the argument for their respective base claims, and the reference applied to the claims 2, 3, 5-15, and 17-20.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the Examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the Examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-7, 9-14, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Shanmugasundaram et al (“Shanmugasundaram,” US 2018/0084085, published on 03/22/2018), in view of Devendran et al (“Devendran,” US 2023/0031921, published on 02/02/2023).
As to claim 1, Shanmugasundaram teaches a computer-implemented method, comprising:
obtaining, by a serving cloud, an access token for a destination cloud based at least in part on account-based linking (Shanmugasundaram: pars 0004-0005, 0024-0025; Fig 2, 3, a virtual/cloud native server [i.e., serving cloud] obtains access token for a second cloud server [destination cloud] which is in communication with the native server over network connection [i.e., based on linking]);
performing, by the serving cloud, device discovery for devices linked to the destination cloud (Shanmugasundaram: pars 0004-0005, 0024-0025; Fig 2, 3, the cloud server pulls information from the first or second IOT device or pushes commands to the first or second IOT device [i.e., device discovery]);
determining, based at least in part on a connector selection rule set, a particular cloud-to-cloud connector from a plurality of cloud-to-cloud connectors that are capable of [connecting] from the serving cloud to the destination cloud; [ ] using the access token (Shanmugasundaram: pars 0005, 0024-0025, 0028-0029, 0047, using the cloud connectors 303 and 304, the cloud 204 [i.e., the serving cloud] creates a connection path between devices of clouds 305 and 307, cloud connectors ensure synchronization of device attributes across all clouds, facilitating the enforcement of consistency between all clouds using access token. The core adaptor executes the rules for connection and communication).
While Shanmugasundaram teaches of setting up connection using adaptor and connection between plurality of cloud servers, Shanmugasundaram, does not explicitly teach receiving, by the serving cloud, network traffic to be sent to the destination cloud, the network traffic being relative to a device managed in the destination cloud; forwarding the network traffic from the serving cloud to the destination cloud; forwarding the network traffic via the particular cloud-to-cloud connector to the destination cloud.
However, in an analogous art, Devendran teaches receiving, by the serving cloud, network traffic to be sent to the destination cloud, the network traffic being relative to a device managed in the destination cloud; forwarding the network traffic from the serving cloud to the destination cloud; forwarding the network traffic via the particular cloud-to-cloud connector to the destination cloud (Devendran: pars 0018, 0042-0044, in a multi-cloud environment, with a cloud-to-cloud connectivity, redirecting/routing network traffic, received from an interest point, to a destination cloud, implementing rules for directing incoming network traffic by controllers and router).
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 teachings of Devendran with the method/system of Shanmugasundaram to include the limitation(s), teaches receiving, by the serving cloud, network traffic to be sent to the destination cloud, the network traffic being relative to a device managed in the destination cloud; forwarding the network traffic from the serving cloud to the destination cloud; forwarding the network traffic via the particular cloud-to-cloud connector to the destination cloud, where one would have been motivated for the benefit of forwarding the network traffic from a source cloud to destination cloud by the routing mechanism of serving cloud, including resolving any problematic path issue (Devendran: pars 0042-0044).
As to claim 2, the combination of Shanmugasundaram and Devendran teaches the computer-implemented method of claim 1,
Devendran further teaches further comprising: determining that the particular cloud-to-cloud connector has experienced a failure; determining, based at least in part on the connector selection rule set, an alternative cloud-to-cloud connector from the plurality of cloud-to-cloud connectors; and forwarding subsequent traffic of the network traffic via the alternative cloud-to-cloud connector to the destination cloud instead of via the particular cloud-to-cloud connector (Devendran: pars 0018, 0042-0044, in a multi-cloud environment, with a cloud-to-cloud connectivity, redirecting/routing network traffic, received from an interest point, to a destination cloud, implementing rules for directing incoming network traffic by controllers and router, executing rules and operations, including resolving any problematic path issue).
As to claim 3, the combination of Shanmugasundaram and Devendran teaches the computer-implemented method of claim 1,
Shanmugasundaram further teaches wherein the serving cloud is operated by a first entity, the destination cloud is operated by second entity, and the particular connector is operated by a third entity (Shanmugasundaram: pars 0005, 0024-0025, 0028-0029, the cloud connectors 303 and 304, the cloud 204 [i.e., the serving cloud] creates a connection path between devices of clouds 305 and 307).
As to claim 4, Shanmugasundaram teaches a system, comprising: at least one computing device in a serving cloud; and instructions executable in the at least one computing device, wherein when executed the instructions cause the at least one computing device (Shanmugasundaram: pars 0004-0005, 0024-0025; Fig 2, 3, a virtual/cloud native server [i.e., serving cloud] obtains access token for a second cloud server [destination cloud] which is in communication with the native server over network connection) to at least:
determine, based at least in part on a connector selection rule set, a particular connector from a plurality of connectors that are capable of [connecting] from the serving cloud to the destination cloud (Shanmugasundaram: pars 0005, 0024-0025, 0028-0029, 0047, using the cloud connectors 303 and 304, the cloud 204 [i.e., the serving cloud] creates a connection path between devices of clouds 305 and 307, cloud connectors ensure synchronization of device attributes across all clouds, facilitating the enforcement of consistency between all clouds using access token. The core adaptor executes the rules for connection and communication).
While Shanmugasundaram teaches of setting up connection using adaptor and connection between plurality of cloud servers, Shanmugasundaram, does not explicitly teach receive network traffic to be sent to a destination cloud different from the serving cloud, the network traffic being relative to a device managed in the destination cloud; forwarding the network traffic from the serving cloud to the destination cloud; forward the network traffic via the particular connector to the destination cloud;
However, in an analogous art, Devendran teaches receive network traffic to be sent to a destination cloud different from the serving cloud, the network traffic being relative to a device managed in the destination cloud; forwarding the network traffic from the serving cloud to the destination cloud; forward the network traffic via the particular connector to the destination cloud (Devendran: pars 0018, 0042-0044, in a multi-cloud environment, with a cloud-to-cloud connectivity, redirecting/routing network traffic, received from an interest point, to a destination cloud, implementing rules for directing incoming network traffic by controllers and router).
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 teachings of Devendran with the method/system of Shanmugasundaram to include the limitation(s), teaches receiving, by the serving cloud, network traffic to be sent to the destination cloud, the network traffic being relative to a device managed in the destination cloud; forwarding the network traffic from the serving cloud to the destination cloud; forwarding the network traffic via the particular cloud-to-cloud connector to the destination cloud, where one would have been motivated for the benefit of forwarding the network traffic from a source cloud to destination cloud by the routing mechanism of serving cloud, including resolving any problematic path issue (Devendran: pars 0042-0044).
As to claim 5, the combination of Shanmugasundaram and Devendran teaches the system of claim 4,
Shanmugasundaram further teaches wherein the serving cloud includes a control device located in an environment, and the device managed in the destination cloud is located in the environment (Shanmugasundaram: pars 0005, 0024-0025, 0028-0029, 0047, using the cloud connectors 303 and 304, locating in the native server, the cloud 204 creates a connection path between devices of clouds 305 and 307).
As to claim 6, the combination of Shanmugasundaram and Devendran teaches the system of claim 4,
Shanmugasundaram further teaches wherein the instructions further cause the at least one computing device to at least receive return network traffic from the device via the particular connector (Shanmugasundaram: pars 0005, 0024-0025, 0028-0029, using the cloud connectors 303 and 304, the cloud 204 creates a connection path between devices of clouds 305 and 307 for communication in both direction).
As to claim 7, the combination of Shanmugasundaram and Devendran teaches the system of claim 6,
Shanmugasundaram further teaches wherein the instructions further cause the at least one computing device to at least: determine, based at least in part on the connector selection rule set, a particular second connector from a plurality of second connectors that are capable of forwarding the return network traffic from the serving cloud to a second destination cloud; and forward the return network traffic via the particular second connector to the second destination cloud (Shanmugasundaram: pars 0005, 0024-0025, 0028-0029, using the cloud connectors 303 and 304, the serving cloud creates a connection path between devices of clouds 305 and 307).
As to claim 9, the combination of Shanmugasundaram and Devendran teaches the system of claim 4,
Shanmugasundaram further teaches wherein a first connector of the plurality of connectors is associated with a higher priority tier than a second connector of the plurality of connectors (Shanmugasundaram: pars 0005, 0024-0025, 0028-0029, uses a set of cloud connectors for connecting the cloud server).
As to claim 10, the combination of Shanmugasundaram and Devendran teaches the system of claim 4,
Devendran further teaches wherein a first connector of the plurality of connectors is a publicly accessible connector, and a second connector of the plurality of connectors is a private connector that is not publicly accessible (Devendran: pars 0018, 0042-0044, in a multi-cloud environment, with a cloud-to-cloud connectivity, redirecting/routing network traffic, received from an interest point, to a destination cloud, implementing rules for directing incoming network traffic by controllers and router, executing rules and operations, including resolving any problematic path issue).
As to claim 11, the combination of Shanmugasundaram and Devendran teaches the system of claim 4,
Devendran further teaches wherein each respective connector of the plurality of connectors is associated with a corresponding capability set, and determining the particular connector is further based at least in part on identifying a particular capability invoked by the network traffic and determining that the corresponding capability set of the particular connector supports the particular capability (Devendran: pars 0018, 0042-0044, in a multi-cloud environment, with a cloud-to-cloud connectivity, redirecting/routing network traffic, received from an interest point, to a destination cloud, implementing rules for directing incoming network traffic by controllers and router, executing rules and operations, including resolving any problematic path issue).
As to claim 12, the combination of Shanmugasundaram and Devendran teaches the system of claim 4,
Devendran further teaches wherein the instructions further cause the at least one computing device to at least: determine that the particular connector has experienced a failure; determine, based at least in part on the connector selection rule set, an alternative connector from the plurality of connectors; and forward subsequent traffic of the network traffic via the alternative connector to the destination cloud instead of via the particular connector (Devendran: pars 0018, 0042-0044, in a multi-cloud environment, with a cloud-to-cloud connectivity, redirecting/routing network traffic, received from an interest point, to a destination cloud, implementing rules for directing incoming network traffic by controllers and router, executing rules and operations, including resolving any problematic path issue).
As to claim 13, the combination of Shanmugasundaram and Devendran teaches the system of claim 12,
Shanmugasundaram further teaches wherein the particular connector and the alternative connector are in a user-defined connector group (Shanmugasundaram: pars 0015, 0028, user configures the connection path and the devices that are connected between the cloud servers. The cloud connector facilitates the enforcement of consistency across all clouds for which compatible functionality is desired by users of the platform offered by cloud).
As to claim 14, the combination of Shanmugasundaram and Devendran teaches the system of claim 4,
Shanmugasundaram and Devendran further teaches wherein the particular connector is configured to provide a dynamic behavior based at least in part on routing rules pertaining to the network traffic (Shanmugasundaram: pars 00047, 0049, the core adaptor executes the rules for connection and communication. The device data could be handled in real time for executing rules and operations [i.e., dynamic behavior]).
As to claim 16, Shanmugasundaram teaches a computer-implemented method (Shanmugasundaram: pars 0004-0005, 0024-0025; Fig 2, 3, a virtual/cloud native server [i.e., serving cloud] obtains access token for a second cloud server [destination cloud] which is in communication with the native server over network connection [i.e., based on linking]), comprising:
receiving, by a serving cloud, network traffic to be sent to a destination cloud different from the serving cloud, the network traffic being relative to a device managed in the destination cloud;
determining, based at least in part on a connector selection rule set, a particular connector that is capable of [connecting] from the serving cloud to the destination cloud token (Shanmugasundaram: pars 0005, 0024-0025, 0028-0029, 0047, using the cloud connectors 303 and 304, the cloud 204 [i.e., the serving cloud] creates a connection path between devices of clouds 305 and 307, cloud connectors ensure synchronization of device attributes across all clouds, facilitating the enforcement of consistency between all clouds using access token. The core adaptor executes the rules for connection and communication); and
forwarding the network traffic via the particular connector to the destination cloud, wherein the particular connector provides a dynamic behavior based at least in part on routing rules (Shanmugasundaram: pars 00047, 0049, the core adaptor executes the rules for connection and communication. The device data could be handled in real time for executing rules and operations [i.e., dynamic behavior]).
While Shanmugasundaram teaches of setting up connection using adaptor and connection between plurality of cloud servers, Shanmugasundaram, does not explicitly teach receiving, by a serving cloud, network traffic to be sent to a destination cloud different from the serving cloud, the network traffic being relative to a device managed in the destination cloud; forwarding the network traffic from the serving cloud to the destination cloud; forwarding the network traffic via the particular connector to the destination cloud;
However, in an analogous art, Devendran teaches receiving, by a serving cloud, network traffic to be sent to a destination cloud different from the serving cloud, the network traffic being relative to a device managed in the destination cloud; forwarding the network traffic from the serving cloud to the destination cloud; forwarding the network traffic via the particular connector to the destination cloud (Devendran: pars 0018, 0042-0044, in a multi-cloud environment, with a cloud-to-cloud connectivity, redirecting/routing network traffic, received from an interest point, to a destination cloud, implementing rules for directing incoming network traffic by controllers and router).
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 teachings of Devendran with the method/system of Shanmugasundaram to include the limitation(s), teaches receiving, by the serving cloud, network traffic to be sent to the destination cloud, the network traffic being relative to a device managed in the destination cloud; forwarding the network traffic from the serving cloud to the destination cloud; forwarding the network traffic via the particular cloud-to-cloud connector to the destination cloud, where one would have been motivated for the benefit of forwarding the network traffic from a source cloud to destination cloud by the routing mechanism of serving cloud, including resolving any problematic path issue (Devendran: pars 0042-0044).
As to claim 17, the combination of Shanmugasundaram and Devendran teaches the computer-implemented method of claim 16,
further comprising sending the routing rules from the serving cloud to the particular connector, wherein the dynamic behavior provides different capabilities for the device according to the routing rules (Shanmugasundaram: pars 00047, 0049, the core adaptor executes the rules for connection and communication. The device data could be handled in real time for executing rules and operations).
As to claim 18, the combination of Shanmugasundaram and Devendran teaches the computer-implemented method of claim 16,
further comprising determining the particular connector based at least in part on the particular connector being in a user-defined connector group of a plurality of connectors, wherein the plurality of connectors in the user-defined connector group are capable of forwarding the network traffic from the serving cloud to the destination cloud (Shanmugasundaram: pars 0015, 0028, user configures the connection path and the devices that are connected between the cloud servers. The cloud connector facilitates the enforcement of consistency across all clouds for which compatible functionality is desired by users of the platform offered by cloud).
As to claim 19, the combination of Shanmugasundaram and Devendran teaches the computer-implemented method of claim 16, further comprising: determining that the particular connector has experienced a failure; determining, based at least in part on the connector selection rule set, an alternative connector from a user-device connector group; and forwarding subsequent traffic of the network traffic via the alternative connector to the destination cloud instead of via the particular connector (Shanmugasundaram: pars 0015, 0028, user configures the connection path and the devices that are connected between the cloud servers. The cloud connector facilitates the enforcement of consistency across all clouds for which compatible functionality is desired by users of the platform offered by cloud).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Shanmugasundaram et al (“Shanmugasundaram,” US 2018/0084085, published on 03/22/2018), in view of Devendran et al (“Devendran,” US 2023/0031921, published on 02/02/2023), and further in view Gandhi et al (“Gandhi,” US 2023/0029987, published on 02/02/2023).
As to claim 15, the combination of Shanmugasundaram and Devendran teaches the system of claim 4,
Shanmugasundaram or Devendran does not exclusively teaches wherein the particular connector is selected based at least in part on a respective energy consumption of the particular connector compared to the plurality of connectors.
However, in an analogous art, Gandhi teaches wherein the particular connector is selected based at least in part on a respective energy consumption of the particular connector compared to the plurality of connectors (Gandhi: pars 0031, 0039, a controller applies policies in selecting path that satisfies certain criteria. The controller uses energy efficiency node quotients to generate a plurality of energy efficiency path quotients for all available paths from node to node, and ranks the plurality of paths from most energy efficient to least energy efficient based on energy efficiency path quotients for path selection).
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 teachings of Gandhi with the method/system of Shanmugasundaram and Devendran to include the limitation(s), wherein the particular connector is selected based at least in part on a respective energy consumption of the particular connector compared to the plurality of connectors, where one would have been motivated for the benefit identifying energy efficiency path, and applying policy to select the energy efficiency path for communicating in the cloud network (Devendran: pars 0042-0044).
Claim 8 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Shanmugasundaram et al (“Shanmugasundaram,” US 2018/0084085, published on 03/22/2018), in view of Devendran et al (“Devendran,” US 2023/0031921, published on 02/02/2023), and further in view Tucker et al (“Tucker,” US 2024/0154946, published on 05/09/2024).
As to claim 8, the combination of Shanmugasundaram and Devendran teaches the system of claim 4,
Shanmugasundaram or Devendran does not exclusively teaches wherein the instructions further cause the at least one computing device to at least: perform account-based linking with the destination cloud based at least in part on a user-specified security credential; obtain an access token from the account-based linking; and provide the access token to the particular connector to enable the particular connector to perform device discovery for devices linked to the destination cloud and to communicate with the destination cloud regarding the device.
However, in an analogous art, Tucker teaches wherein the instructions further cause the at least one computing device to at least: perform account-based linking with the destination cloud based at least in part on a user-specified security credential (Tucker: 0004, 0006-0008, disclosure systems and methods for authenticating and authorizing users across a domain in a cloud-based environment. Where a mapping [i.e., linking] of the user of the third-party service to a user account [i.e., account-based] of the cloud-based storage system can be generated);
obtain an access token from the account-based linking (Tucker: 0004, 0006-0008, a one or more tokens for the user of the service can in turn be generated based on the mapping of the user of the service to the user account of the cloud-based storage system); and
provide the access token to the particular connector to enable the particular connector to perform device discovery for devices linked to the destination cloud and to communicate with the destination cloud regarding the device (Tucker: 0008-0009, the one or more tokens is used providing access to services of the cloud-based storage system [i.e., connecting to the destination] in a domain-wide authentication and authorization process).
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 teachings of Tucker with the method/system of Shanmugasundaram and Devendran to include the limitation(s), wherein the instructions further cause the at least one computing device to at least: perform account-based linking with the destination cloud based at least in part on a user-specified security credential; obtain an access token from the account-based linking; and provide the access token to the particular connector to enable the particular connector to perform device discovery for devices linked to the destination cloud and to communicate with the destination cloud regarding the device, where one would have been motivated for the benefit mapping/linking a destination in cloud based on user account, and a generated token associated with the user account to provide service by connecting to destination services of the cloud-based storage system in a domain-wide authentication and authorization process (Tucker: pars 0006-0008).
As to claim 20, the claim is directed to a method, and the scope of the claim limitation is similar to the scope of system claim 8, and therefore, rejected for the same reason set forth above for claim 8.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jahangir Kabir whose telephone number is (571) 270-3355. The examiner can normally be reached on 9:00- 5:00 Mon-Thu.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached on (571) 270-5002. The fax 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/JAHANGIR KABIR/ Primary Examiner, Art Unit 2439
Prosecution Insights