RDETAILED ACTION
1. Claims 1-23 are pending in this examination.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
3. 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.
Response to Arguments
4.1. Applicant’s arguments filed 4/14/2026 have been fully considered but they are not persuasive.
4.2. Applicant’s Response applicant argues, in substance that “…Ross fails to teach what is claimed, namely two cloud services being connected via authentication with a service provider. …No where in Ross is there a discussion of the two separate internet service providers being connected as specifically recited in the claims…. it is unclear how Ross can be alleged to teach the claimed subject matter that is centric to cloud service functionality and connections between to such types of services when Ross admittedly fails to teach that exact type of service.” (remark, pages 6-7).
4.3. The Examiner respectfully disagrees with Applicant's arguments; the examiner submits that the combination of Ross, Hassani and Bonefas discloses above feature. For example, Ross teaches two cloud services being connected via authentication with service provider (See 1 0010. 042 -9044, 094, Fig.4 A &4B). Furthermore, Ross teaches authorizing respective access by each of a plurality of internet users to a respective one or more internet services (two cloud services) provided by each of a plurality of internet service provider (10010). These internet services provided by the plurality of service provider enables the relying parties (RPs) to connect to them. Additionally, Ross discloses in para 43 Referring again to FIG. 1, the Internet user interface module 110 provides an interface between Internet user devices 102-N, 104-N, 106-N of a plurality of Internet users and the cloud 100 (e.g. a public cloud). The Internet user in this context may refer to a customer N of the cloud (e.g. employee, government agency, agent, analyst, etc.) provided by an IDP service core 150-N of the single IDP, or an individual N at a customer site with a network connection to the cloud 100, and that is requesting authorization to access one or more Internet services provided by one or more relying parties 160-i.").
4.4. Applicant's argues, " Hassani … does not teach or suggest, inter alia, responsive to a successful login, establishing a connection between the first cloud service and a second cloud service, the connection enabling communication between the first cloud service and the second cloud service, as claimed... it falls short of the claimed functionality, which recites that a successful login itself results in the establishment of a connection between distinct cloud services, where that connection enables communication beyond the narrow confines of user credential verification (remark, pages 7-8).
The Examiner respectfully disagrees with Applicant's arguments; the examiner submits that the combination of Ross, Hassani and Bonefas discloses above feature.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
For example, Ross teaches as describe above, two cloud services being connected via authentication with service provider (See 1 0010. 042 -9044, 094, Fig.4 A &4B)). Furthermore, Ross teaches authorizing respective access by each of a plurality of internet users to a respective one or more internet services (two cloud services) provided by each of a plurality of internet service provider (10010). These internet services provided by the plurality of service provider enables the relying parties (RPs) to connect to them. Additionally, Ross discloses in para 43 Referring again to FIG. 1, the Internet user interface module 110 provides an interface between Internet user devices 102-N, 104-N, 106-N of a plurality of Internet users and the cloud 100 (e.g. a public cloud). The Internet user in this context may refer to a customer N of the cloud (e.g. employee, government agency, agent, analyst, etc.) provided by an IDP service core 150-N of the single IDP, or an individual N at a customer site with a network connection to the cloud 100, and that is requesting authorization to access one or more Internet services provided by one or more relying parties 160-i.").
Hassani teaches a first server 160, and a second server 170. A user may request, using a mobile application executing on a user device in an example, an autonomous vehicle ride. The request may be sent to the second server 170. In some instances, the request may include a user account identifier associated with a user account from which the request was made. The second server 170 may receive the request and may determine the user account identifier. The second server 170 may be in communication with one or more local or remote datastores storing user account identifiers in association with authentication identifiers (which may be an anonymous identifier devoid of personally identifiable information associated with a user and/or user account) for the respective user accounts. The second server 170 may query the one or more databases to determine the authentication identifier that is associated with the user account identifier from the request. The second server 170 may then wait for a message from the first server 160 indicating that a biometric challenge has been satisfied ([0013]- [0014]).
4.5. Applicant’s Response applicant argues, in substance that “… Bonefas fail to teach the claimed "responsive to successful login, establishing a connection between the first cloud service and a second cloud service, the connection being a new connection that enables communication between the first cloud service and the second cloud service" functionality….Bonefas does not teach this sequence wherein an authorization token is received prior to login presentation, nor does it teach establishing a new inter-cloud connection as a conditional response to successful login.” (remark, pages 8-10).
4.6. The Examiner respectfully disagrees with Applicant's arguments; the examiner submits that the combination of Ross, Hassani and Bonefas discloses above feature.
For example, Bonefas discloses in col.44, lines 48-60, establishing a connection between the first cloud service and a second cloud service, the connection being a new connection that enables enabling communication between the first cloud service and the second cloud service, also see col. 13, lines 4-45.
Furthermore, Ross, Hassani and Bonefas all are an analogous art, it has been held that a prior art reference must either be in the field of applicant’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the applicant was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). Furthermore, The Supreme Court has determined that the conclusion of obviousness can be based on the interrelated teachings of multiple patents, the effects of demands known to the design community or present in the marketplace, and the background knowledge possessed by a person having ordinary skill in the art. KSRInt'l Co. v. TeleflexInc., 550 U.S. 398,416 (2007). The skilled artisan would "be able to fit the teachings of multiple patents together like pieces of a puzzle" since the skilled artisan is "a person of ordinary creativity, not an automaton." Id. at 420-21. Combining the arts was "uniquely challenging or difficult for one of ordinary skill in the art." Leapfrog Enters., Inc. v. Fisher-Price, Inc., 485 F.3d 1157, 1162 (Fed. Cir. 2007) (citing KSR at 418). The Examiner's proffered combination of familiar prior art elements according to their established functions (see below) would have conveyed a reasonable expectation of success to a person of ordinary skill having common sense at the time of the application filing.
Ross teaches as describe above, two cloud services being connected via authentication with service provider (See 1 0010. 042 -9044, 094, Fig.4 A &4B)). Furthermore, Ross teaches authorizing respective access by each of a plurality of internet users to a respective one or more internet services (two cloud services) provided by each of a plurality of internet service provider (10010). These internet services provided by the plurality of service provider enables the relying parties (RPs) to connect to them. Hassani teaches a first server 160, and a second server 170. A user may request, using a mobile application executing on a user device in an example, an autonomous vehicle ride. The request may be sent to the second server 170. In some instances, the request may include a user account identifier associated with a user account from which the request was made. The second server 170 may receive the request and may determine the user account identifier. The second server 170 may be in communication with one or more local or remote datastores storing user account identifiers in association with authentication identifiers (which may be an anonymous identifier devoid of personally identifiable information associated with a user and/or user account) for the respective user accounts. The second server 170 may query the one or more databases to determine the authentication identifier that is associated with the user account identifier from the request. The second server 170 may then wait for a message from the first server 160 indicating that a biometric challenge has been satisfied ([0013]- [0014]).
Bonefas discloses in col.44, lines 48-60, establishing a connection between the first cloud service and a second cloud service, the connection being a new connection that enables enabling communication between the first cloud service and the second cloud service, also see col. 13, lines 4-45.
It would have been obvious to one of ordinary skill in the art at the time of filling, one of ordinary skill will find some teaching “be able to fit the teachings of multiple patents together like pieces of a puzzle" since the skilled artisan is "a person of ordinary creativity, not an automaton.
4.7. Applicant’s argues, “… there is no motivation in any of the references to modify them to change the functionality of what is taught by the references into what is taught and claimed in the instant application. Nor is there any teaching or suggestion or motivation to combine the references to achieve what is taught in the instant application and using the instant application as a roadmap to combine the art is impermissible hindsight reconstruction.” (remark, pages 9-10).
4.8. In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
Furthermore, as describe above, Ross, Hassani and Bonefas all are an analogous art, it has been held that a prior art reference must either be in the field of applicant’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the applicant was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). Furthermore, The Supreme Court has determined that the conclusion of obviousness can be based on the interrelated teachings of multiple patents, the effects of demands known to the design community or present in the marketplace, and the background knowledge possessed by a person having ordinary skill in the art. KSRInt'l Co. v. TeleflexInc., 550 U.S. 398,416 (2007). The skilled artisan would "be able to fit the teachings of multiple patents together like pieces of a puzzle" since the skilled artisan is "a person of ordinary creativity, not an automaton." Id. at 420-21. Combining the arts was "uniquely challenging or difficult for one of ordinary skill in the art." Leapfrog Enters., Inc. v. Fisher-Price, Inc., 485 F.3d 1157, 1162 (Fed. Cir. 2007) (citing KSR at 418). The Examiner's proffered combination of familiar prior art elements according to their established functions (see below) would have conveyed a reasonable expectation of success to a person of ordinary skill having common sense at the time of the application filing.
Ross teaches two cloud services being connected via authentication with service provider (See 1 0010. 042 -9044, 094, Fig.4 A &4B).
Hassani teaches a first server 160, and a second server 170. A user may request, using a mobile application executing on a user device in an example, an autonomous vehicle ride. The request may be sent to the second server 170. In some instances, the request may include a user account identifier associated with a user account from which the request was made. The second server 170 may receive the request and may determine the user account identifier. The second server 170 may be in communication with one or more local or remote datastores storing user account identifiers in association with authentication identifiers (which may be an anonymous identifier devoid of personally identifiable information associated with a user and/or user account) for the respective user accounts. The second server 170 may query the one or more databases to determine the authentication identifier that is associated with the user account identifier from the request. The second server 170 may then wait for a message from the first server 160 indicating that a biometric challenge has been satisfied ([0013]- [0014]).
Bonefas discloses in col.44, lines 48-60, establishing a connection between the first cloud service and a second cloud service, the connection being a new connection that enables enabling communication between the first cloud service and the second cloud service, also see col. 13, lines 4-45.
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 teaching of Ross with the teaching of Bonefas /Hassani by including the feature of connection between two clouds, in order for Ross’s system for reliable message transport service. An intelligent messaging network provides multiple software development kits (SDKs) to assist, e.g., engineers in developing client and server applications. The SDKs can contain a consistent set of application program interfaces (APIs) and a set of platform specific libraries for all intelligent messaging network supported platforms and networks. In addition to the SDKs, the intelligent messaging network can provide developers a resource kit including a set of tools to assist the developers when designing, implementing, and testing their client and server applications. The intelligent messaging network can provide a mobile client and server SDK environment to assist engineers developing client applications and servers. The SDKs can provide an easy to use APIs and a set of platform specific libraries to perform, e.g., compression, network management services, server-to-server communication, server registration/de-registration, and reliable message transport services (Bonefas, Abstract).
By this rationale, the Examiner has provided sufficient motivation for the combination of Ross, Hassani and Bonefas.
Therefore, in view of the above reasons, the rejections are maintained.
Claim Rejections - 35 USC § 103
5.1. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
5.2. Claims 1-9, 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application No. 20160134599 to Ross et al (“Ross”), in view of US Patent Application No. 20200023812 to Hassani et al (“Hassani”), further in view of US Patent No. 8090856 issued to Bonefas et al (“Bonefas”).
As per claim 1, Ross discloses a method ([0044]-"Cloud computing Internet centric environment 100 can also include respective communications interface modules A 130 and 8 135 communicating with IDP service core 150-N of the single IDP, authentication engine 120 of the single IDP, user interface 110 for each of a plurality of Internet users, and/or RP interface 165-i for each of a plurality of RPs and to a respective one or more Internet services provided by each of the plurality of RPs."):
([0010]-"The program code executable by the processor is for requiring the respective identity provider application residing on each of the respective mobile devices to create the respective authentication token and to store a respective private key portion of the respective authentication token on the respective mobile device"; [0042]-"ln various embodiments, a base Internet address may be a base Uniform Resource Locator (URL) for a particular Internet service for a particular relying party. In some embodiments, a base Internet address may be a base Uniform Resource Locator (URL) for a particular relying party.", also see [0094], [0044]),
the authorization token provided responsive to the user selecting a feature on a first cloud service for connecting the first cloud and the second cloud ([0094]-"At block 732, in response to the respective Internet user's selection of a respective link displayed on the respective RP's web page (e.g. FIGS. 4A, 48) that identified a respective Internet service provided by the RP and the RP's transmission of the respective RP service identifier and the web browser identifier, the IDP service core 750 directs the Internet user's web browser 710 to the website of the single IDP that is operatively coupled to IDP service core 750, and, as shown in FIGS. SA and 58, the IDP service core 750 presents an appropriate web page in the graphical user interface (GUI) of ,a device 704 in the web browser 71 0 user that requires dlD app 750 Internet users to provide an input of an Internet user identifier (e.g. an electronic mail address, an IDP service generated anonymous identifier) into the web browser 710 of the device.");
receiving the authorization token; identifying a service provider associated with the user based on the authorization token; presenting the user with a login associated with the identified service provider ([0051]-"ln various embodiments, the unique RP Identifier code allows the IDP service core 150 to identify authentication requests received over a communications network from varied RPs 160-i. In various embodiments, during an initial registration process, IDP service core 150 may generate a respective unique Internet service identifier (e.g. uniquely generated pseudorandom string) for each Internet service provided by each respective RP. In various embodiments, the unique Internet service identifiers allow the IDP service core 150 to identify an Internet user request to access the particular Internet service from a plurality of Internet services provided by a plurality of RPs 160-i."); and
responsive to a successful login, a connection between the first cloud service and a second cloud service ([0043]-"Referring again to FIG. 1, the Internet user interface module 110 provides an interface between Internet user devices 102-N, 104-N, 106-N of a plurality of Internet users and the cloud 100 (e.g. a public cloud). The Internet user in this context may refer to a customer N of the cloud (e.g. employee, government agency, agent, analyst, etc.) provided by an IDP service core 150-N of the single IDP, or an individual N at a customer site with a network connection to the cloud 100, and that is requesting authorization to access one or more Internet services provided by one or more relying parties 160-i.").
Ross does not explicitly disclose however in the same field of endeavor, Hassani discloses a successful login, establishing a connection between the first cloud service/ resources and a second cloud service resources; the connection enabling
communication between the first cloud service and the second cloud service ([0013]-[0014], a first server 160, and a second server 170. A user may request, using a mobile application executing on a user device in an example, an autonomous vehicle ride. The request may be sent to the second server 170. In some instances, the request may include a user account identifier associated with a user account from which the request was made. The second server 170 may receive the request and may determine the user account identifier. The second server 170 may be in communication with one or more local or remote datastores storing user account identifiers in association with authentication identifiers (which may be an anonymous identifier devoid of personally identifiable information associated with a user and/or user account) for the respective user accounts. The second server 170 may query the one or more databases to determine the authentication identifier that is associated with the user account identifier from the request. The second server 170 may then wait for a message from the first server 160 indicating that a biometric challenge has been satisfied, also see fig. 1 and associated texts);
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 teaching of Ross with the teaching of Hassani by including the feature of cloud services, in order for Ross’s system for autonomous vehicles because a human operator may not be available to verify a rider's identity. This may result in a rider entering the wrong autonomous vehicle, a rider being driven to an incorrect destination, and so forth. Some methods of rider verification use biometric features, such as facial features, fingerprints, gait analysis, and the like. However, such data may be desired by hackers and other cybersecurity threats. Accordingly, safeguarding information used to verify rider identity may be desired. (Hassani, [0010]);
Ross and Hassani do not explicitly disclose however in the same field of endeavor, Bonefas discloses establishing a connection between the first cloud service and a second cloud service, the connection being a new connection that enables enabling communication between the first cloud service and the second cloud service (col.44, lines 48-60, establishing a connection between the first cloud service and a second cloud service, the connection being a new connection that enables enabling communication between the first cloud service and the second cloud service, also see col. 13, lines 4-45.);
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 teaching of Ross with the teaching of Bonefas /Hassani by including the feature of connection between two clouds, in order for Ross’s system for reliable message transport service. An intelligent messaging network provides multiple software development kits (SDKs) to assist, e.g., engineers in developing client and server applications. The SDKs can contain a consistent set of application program interfaces (APIs) and a set of platform specific libraries for all intelligent messaging network supported platforms and networks. In addition to the SDKs, the intelligent messaging network can provide developers a resource kit including a set of tools to assist the developers when designing, implementing, and testing their client and server applications. The intelligent messaging network can provide a mobile client and server SDK environment to assist engineers developing client applications and servers. The SDKs can provide an easy to use APIs and a set of platform specific libraries to perform, e.g., compression, network management services, server-to-server communication, server registration/de-registration, and reliable message transport services (Bonefas, Abstract).
As per claim 2, the combination of Ross, Hassani and Bonefas discloses the method of claim 1, wherein the service provider is one of a plurality of service providers for the first cloud service (Ross, [0015]-"FIG. 1 is a block diagram of an example of an Internet-accessible cloud service platform of a single identity provider in accordance with some embodiments of the present disclosure."; [0034]-"The inventors have developed computer implemented systems and methods of authorizing respective access by each of a plurality of Internet users to a respective one or more Internet services provided by each of a plurality of Internet service providers that provides Internet users and Internet-accessible relying parties with decentralized, secure, seamless, authentication capabilities to improve revenue, decrease costs, resolve vulnerabilities and' technical implementation challenges, and achieve enhanced security Internet-centric authentication processes previously unrealized by existing schemes.").
As per claim 3, the combination of Ross, Hassani and Bonefas discloses the method of claim 1, wherein the feature of the second cloud service enables the second cloud service to control aspects of the first cloud service (Ross, [0077]-" In various embodiments, IDP service core (150, 250) can validate that the registering internet, user controls the registering Internet user device that transmitted the user registration request.").
As per claim 4, the combination of Ross, Hassani and Bonefas discloses the method of claim 1, wherein the authorization token is encoded with information, including information about the user’s identity or information about which service provider is associated with the user (Ross, [0077]-"ln various embodiments, IDP service core (150,250) of the single IDP can store single IDP registered Internet. user's identity information (e.g. user identifier (e.g. email address(es), anonymous identifier), first name, last name, etc.)").
As per claim 5, the combination of Ross, Hassani and Bonefas discloses the method of claim 1, wherein the authorization token is a code provided to the user by an application associated with the service provider (Ross, [0077]-"ln some embodiments, during registration, authentication engine 120 (220) of IDP service core (150,250) can validate that the registering Internet user controls the user identifier (e.g. electronic mail address) provided during an initial registration step via an out-of-band from dID app 850 confirmation process. In various embodiments, for example, IDP service core (150,250) can send a generated page of an electronic mail or other communication (e.g. text message, SMS message, page, etc.) to an application other than dID app 850 to display identity information provided by the Internet user (e.g. e-mail address, phone number, pager number), and provide instructions for the Internet user to respond and/or to confirm the registration information (e.g. e-mail address) initially supplied by the Internet user using the application other than dID app 850."; Para [0078]-"The dID Application: Authentication Token Generation and Management").
As per claim 6, the combination of Ross, Hassani and Bonefas discloses the method of claim 5, wherein the code is a temporary code which cycles to reduce security risks (Ross, [0082]-"ln some embodiments, the Cryptographic component 720 of dID app 850 may generate a temporary symmetric transport key pair to encrypt the public key portion of the generated authentication token and created binding (e.g. error correction code, Cryptographic hash) for transmission from the device (704, 104, 106) to the IDP service core (150-N, 250-N) of the single IDP.").
As per claim 7, the combination of Ross, Hassani and Bonefas discloses the method of claim 5, wherein the code is generated at the time the user accesses the application or generated by a specific action to trigger the generation of the code (Ross, [0089]-"ln various embodiments, once an Internet user registers with IDP service core (150,250) and dID app generates an authentication token, an Internet user can use dlD app 750 to authenticate to RP Internet services of RPs (160-i, 260-i) (e.g. Internet services accessed via an RP website) with which each RP (160-i, 260-i) has preregistered with the single IDP. In various embodiments, an Internet user may register with a respective one or more RP Internet services at each of one or more RPs (160, 260) at the respective one or more RP Internet services' websites via user interface (110, 201). For example, an Internet user may register with two or more RPs (160, 260) (e.g. Facebook®, Amazon®) and indicate, during or after registration, that he/she desires to use identity provider services of the single IDP to authenticate to the RPs and to be authorized access to a respective one or more RP Internet services of each of the RPs. In some embodiments, for example in embodiments where dlD app 850, the IDP service core (150,250) of the single IDP and a respective one or more RP Internet services (160-i, 260-i) of RPs are bound and dedicated to each other, an Internet user can use dlD app 850 to authenticate to the respective one or more RP Internet services of each RP to which dlD app 850 and the IDP service core (150, 250) are bound. In. various embodiments, authentication requests are initiated from the respective RP Internet service of the respective RP (160-i, 260-i) as described herein, and brokered by the Identity Provider service (150, 250) as described herein.").
As per claim 8, the combination of Ross, Hassani and Bonefas discloses the method of claim 1, wherein the service provider is an Identity Provider (IDP) for the first cloud service (Ross, [0037]-"Various embodiments of the present disclosure provide multifactor device-based authentication capabilities with an identity provider (IDP) service of a single IDP").
As per claim 9, the combination of Ross, Hassani and Bonefas discloses the method of claim 1, wherein the URL provided to the user is specific to the second cloud service, and the URL is operated by the first cloud service (Ross, [0042]-"ln various embodiments, a base Internet address may be a base Uniform Resource Locator (URL) for a particular Internet service for a particular relying party. In some embodiments, a base Internet address may be a base Uniform Resource Locator (URL) for a particular relying party. In various embodiments, a base Internet address does not include http or any subdomain. In various embodiments, a call-back Internet address may be a re-direct URL that determines where the single IDP re-directs a web browser of an Internet user requesting access to a particular Internet service of a particular relying party over the Internet in response to the single IDP's validation of an associated approved authentication challenge message.").
As per claim 13, the combination of Ross, Hassani and Bonefas discloses the method implemented by a first and second cloud service (Ross, [0044]-"Cloud computing Internet centric environment 100 can also include respective communications interface modules A 130 and 8 135 communicating with IDP service core 150-N of the single IDP, authentication engine 120 of the single IDP, .user interface 110 for each of a plurality of Internet users, and/or RP interface 165-i for each of a plurality of RPs and to a respective one or more Internet services provided by each of the plurality of RPs."):
the method comprising steps of: responsive to a user requesting to connect the first and second cloud, the second cloud presenting to the user a Uniform Resource Locator (URL) to a web page having a field for the user to input an authorization token (Ross, [0010]-"The program code executable by the processor is for requiring the respective identity provider application residing on each of the respective mobile devices to create the respective authentication token and to store a respective private key portion of the respective authentication token on the respective mobile device"; Para [0042]-"ln various embodiments, a base Internet address may be a base Uniform Resource Locator (URL) for a particular Internet service for a particular relying party. In some embodiments, a base Internet address may be a base Uniform Resource Locator (URL) for a particular relying party."),
the authorization token provided responsive to the user selecting a feature on a first cloud service for connecting the first and second cloud (Ross, [0094]-"At block 732, in response to the respective Internet user's selection of a respective link displayed on the respective RP's web page (e.g. FIGS. 4A, 4B) that identified a respective Internet service provided by the RP and the RP's transmission of the respective RP service identifier and the web browser identifier, the /DP service core 750 directs the Internet user's web browser 710 to. the website of the single IDP that is operatively coupled to IDP service core 750, and, as shown in FIGS. 5A and 5B, the IDP service ·core· 750 presents an appropriate web page in the graphical user interface (GUI) of a device 704 in the web browser 710 user that requires dlD app 750 Internet users to provide an input of an Internet user identifier (e. g. an electronic mail address, an IDP service generated anonymous identifier) into the web browser 71 O of the device.");
receiving the authorization token, the authorization token having encoded within it the credentials required to connect the two clouds (Ross, [0029]-"ln various embodiments, Internet users can utilize a respective identity provider application of a single identity provider residing on a respective device that is configured with an authentication token and an user credential of the Internet user, where the authentication token is specific to an user identifier of the Internet user, the user credential of the Internet user, a device identifier for one or more devices including the device, and the identity provider application."; Para [0041]-"For example, IDP service core 350-N may be hosted on a web services cloud computing infrastructure and include a Domain Name Server (DNS) (e.g. Route 53 DNS) (not shown), an Elastic Load Balancer (ELB) (not shown) to distribute traffic across servers 352, Elastic Compute Cloud (EC2) (not shown) instances to host IDP service core 350-N, and an electronic mail service for electronic mail delivery."); and
responsive to successfully receiving the authorization token, allowing a connection between the first cloud service and second cloud service (Ross, [0043]-"Referring again to FIG. 1, the Internet user interface module 110 provides an interface between Internet user devices 102-N, 104-N, 106-N of a plurality of Internet users and the cloud 100 (e. g. a public cloud). The Internet user in this context may refer to a customer N of the cloud (e. g. employee, government agency, agent, analyst, etc.) provided by an IDP service core 150-N of the single IDP, or an individual N at a customer site with a network connection to the cloud 100, and that is requesting authorization to access one or more Internet services provided by one or more relying parties 160-i.");
Ross and Hassani do not explicitly disclose however in the same field of endeavor, Bonefas discloses allowing a connection between the first cloud service and second cloud service, the connection being a new connection that enables communication between the first cloud service and the second cloud service (col.44, lines 48-60, establishing a connection between the first cloud service and a second cloud service, the connection being a new connection that enables enabling communication between the first cloud service and the second cloud service, also see col. 13, lines 4-45.);
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 teaching of Ross with the teaching of Bonefas /Hassani by including the feature of connection between two clouds, in order for Ross’s system for reliable message transport service. An intelligent messaging network provides multiple software development kits (SDKs) to assist, e.g., engineers in developing client and server applications. The SDKs can contain a consistent set of application program interfaces (APIs) and a set of platform specific libraries for all intelligent messaging network supported platforms and networks. In addition to the SDKs, the intelligent messaging network can provide developers a resource kit including a set of tools to assist the developers when designing, implementing, and testing their client and server applications. The intelligent messaging network can provide a mobile client and server SDK environment to assist engineers developing client applications and servers. The SDKs can provide an easy to use APIs and a set of platform specific libraries to perform, e.g., compression, network management services, server-to-server communication, server registration/de-registration, and reliable message transport services (Bonefas, Abstract).
As per claim 14, the combination of Ross, Hassani and Bonefas discloses the method of claim 13, wherein a service provider is identified based on the authorization token, and wherein the service provider is one of a plurality of service providers for the first cloud service (Ross, [0015]-"FIG. 1 is a block diagram of an example of an Internet-accessible cloud service platform of a single identity provider in accordance with some embodiments of the present disclosure."; [0034]-"The inventors have developed computer-implemented systems and methods of authorizing respective access by each of a plurality of Internet users to a respective one or more Internet services provided by each of a plurality of Internet service providers that provides Internet users and Internet-accessible relying parties with decentralized, secure, seamless, authentication capabilities to improve revenue, decrease costs, resolve vulnerabilities and technical implementation challenges, and achieve enhanced security Internet-centric authentication processes previously unrealized by existing schemes.").
Claims 15-20, are rejected for similar reasons as stated above.
5.3. Claims 10-12, and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Ross, Hassani and Bonefas as applied to claim above, and in view of US Patent Application No. 20210133650 to Cella et al (“Cella”).
As per claim 10, the combination of Ross, Hassani and Bonefas discloses the invention as described above. Ross, Hassani and Bonefas do not explicitly disclose however, In the same field of endeavor, Cella discloses the method of claim 1, wherein the first cloud service is a home network, and the second cloud service is a smart home service enabled to control the home network ([0517]-"ln embodiments, the unified set of Internet of Things systems includes a set of smart home"; Para [1344]-"ln embodiments, the recurrent neural network may use internal memory to process a sequence of inputs, such as from other nodes and/or from sensors and other data inputs from an environment, of the various types described herein, -such as a social network, a home or work environment, a health care environment, a recreational or sports environment, or the like.").
It would have been obvious to one of ordinary skill in the art to construct the ISP authorization of Ross, Hassani and Bonefas to account for smart home services as taught in Cella in order to optimize authorization services; the overall performance (e.g., speed/latency, reliability, quality of service, cost reduction, or other factors) of the connectivity facilities 642; ones that can improve other capabilities within the adaptive intelligent systems layer 614; ones that improve the performance (e.g., speed/latency, energy utilization, storage capacity, storage efficiency, reliability, security, or the like) of one or more of the components, or the overall performance (Cella, [1052]).
As per claim 11, the combination of Ross, Hassani, Bonefas and Cella discloses the method of claim 1, wherein the first cloud service is a home network, and the second cloud service is a wellness, health, personal wellbeing, fitness, or exercise application (Cella, [1052]-"ln embodiments, the recurrent neural network may use internal memory to process a sequence of inputs, such as from other nodes and/or from sensors and other data inputs from an environment, of the various types described herein, such as a social network, a home or work environment, a health care environment, a recreational or sports environment, or the like."). The motivation regarding the obviousness of claim 10 is also applied to claim 11.
As per claim 12, the combination of Ross, Hassani, Bonefas and Cella discloses the method of claim 1, wherein the first cloud service is a home network, and the second cloud service is a utility, energy, power consumption monitoring, or power usage control application (Cella [1161]-"activity prediction systems, fault prediction systems, failure prediction systems, accident prediction systems, event predictions systems, event prediction systems, and many others), configuration systems (such as protocol selection systems, storage configuration systems, peer-to-peer network configuration systems, power management systems"). The motivation regarding the obviousness of claim 10 is also applied to claim 12.
Claims 21-23, are rejected for similar reasons as stated above.
6.1. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
6.2. a). US Patent Application No. 20150135257 to Shah et al., discloses a user may utilize a set of credentials to access, through a managed directory service, one or more services provided by a computing resource service provider. The managed directory service may be configured to identify one or more policies applicable to the user. These policies may define the level of access to the one or more services provided by the computing resource service provider. Based at least in part on these policies, the managed directory service may transmit a request to an identity management system to obtain a set of temporary credentials that may be used to enable the user to access the one or more services. Accordingly, the managed directory service may be configured to enable the user, based at least in part on the policies and the set of temporary credentials, to access an interface, which can be used to access the one or more services.
b). US Patent Application No. 20180075231 to Subramanian et al., discloses a cloud-based identity and access management system that implements single sign-on (“SSO”) receives a first request for an identity management service configured to allow for accessing an application. Embodiments send the first request to a first microservice which performs the identity management service by generating a token. The first microservice generates the token at least in part by sending a second request to a SSO microservice that is configured to provide SSO functionality across different microservices that are based on different protocols. Embodiments then receive the token from the first microservice and provide the token to the application, where the token allows for accessing the application.
c). US Patent Application No. 20160044035 to Huang et al., discloses systems and apparatuses for a secure mobile cloud framework (referred to as MobiCloud) for mobile computing and communication are disclosed. Embodiments of MobiCloud transfer each mobile node from a traditional strictly layer-structured communication node into a service node (SN). Each SN may be used as a service provider or a service broker according its capability. Each SN may be incorporated as a virtualized component of the MobiCloud. In some embodiments, MobiCloud mirrors an SN to one or multiple virtual images in the Cloud for addressing communication and computation deficiencies of mobile devices. Virtual images can create a visualized MANET routing and communication layer that can maximally assist the mobile nodes to enable pervasive computing services for each mobile device owner. A secure data processing framework is disclosed for the MobiCloud.
Conclusion
7. 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 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 HARUNUR RASHID whose telephone number is (571)270-7195. The examiner can normally be reached 9 AM to 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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
HARUNUR . RASHID
Primary Examiner
Art Unit 2497
/HARUNUR RASHID/Primary Examiner, Art Unit 2497
Prosecution Insights