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 .
DETAILED ACTION
This action is in response to communication filed on 4/2/2025.
Claims 21- 40 are pending.
Claims 1-20 have been canceled.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21, 29 and 35 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 9 and 16 of U.S. Patent No. US12316707B1. The instant claims are being anticipated by the patented application. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the patent disclose the limitations in the instant application as follows:
Instant Application
US12316707B1
21. (New) A method for operating a mobile application, the method comprising: activating a feature at a frontend of the mobile application, wherein: the feature is associated through business logic with a service of the mobile application,
the frontend executes in a mobile device, and
the service executes remotely from the mobile device;
responsive to activating the feature, generating, at the frontend, a first message in a first protocol to
a mobile aggregator of the mobile application, wherein:
the mobile aggregator executes remotely from the mobile device, the mobile aggregator subscribes to the service such that any update to the service is automatically propagated to the mobile aggregator,
the first protocol enables the frontend to call the mobile aggregator as a local object, receiving the first message at the mobile aggregator triggers second messages in a second protocol, the second protocol is different from the first protocol, and
the second messages comprise at least: (i) a call by the mobile aggregator to the service to execute
the feature according to the business logic, and (ii) a result of the call from the service;
responsive to sending the first message, suspending a calling environment in the mobile device;
receiving, at the frontend, a third message in the first protocol from the mobile aggregator, the third
message comprising the result from the service; and
responsive to receiving the third message, resuming the calling environment in the mobile device and
displaying the result at the frontend.
1. A method for operating a mobile application using backend-for-frontend in a tiered software framework, the method comprising:
receiving, by a mobile aggregator, a set of first messages over a wireless communication network from a frontend of the mobile application executing in a mobile device, the set of first messages comprising instructions in Remote Procedure Call (RPC) protocol to execute a feature of the mobile application, wherein:
invoking the RPC protocol triggers suspending a calling environment in the mobile device and transferring procedure parameters across the wireless communication network from the mobile device to the mobile aggregator,
the feature comprises one or more services of the mobile application executing in a cloud network,
the set of first messages identifies the mobile aggregator as recipient, and
different features of the mobile application are associated with respectively different sets of first messages;
executing, by the mobile aggregator, the instructions in the first messages, wherein executing the instructions comprises:
identifying, by the mobile aggregator, the one or more services of the mobile application called by the instructions in the first messages;
generating second messages comprising other instructions in another protocol compatible with communication in the cloud network to execute the feature of the mobile application;
communicating, by the mobile aggregator, the second messages in the another protocol to the one or more services in the cloud network;
receiving results from the one or more services; and
generating a set of response messages with the results in the RPC protocol; and
sending the set of response messages to the frontend, wherein:
sending the response messages triggers unsuspending the calling environment and resuming execution at the frontend,
and
transaction history between any two of the first messages is stored in the frontend or in the one or more services.
29.(New) Non-transitory computer-readable tangible media that includes instructions for
execution, which when executed by a processor of a computing device, is operable to perform
operations comprising:
activating a feature at a frontend of a mobile application, wherein:
the feature is associated through business logic with a service of the mobile application,
the frontend executes in a mobile device, and
the service executes remotely from the mobile device;
responsive to activating the feature, generating, at the frontend, a first message in a first protocol to
a mobile aggregator of the mobile application, wherein:
the mobile aggregator executes remotely from the mobile device,
the mobile aggregator subscribes to the service such that any update to the service is
automatically propagated to the mobile aggregator,
the first protocol enables the frontend to call the mobile aggregator as a local object,
receiving the first message at the mobile aggregator triggers second messages in a second
protocol,
the second protocol is different from the first protocol, and
the second messages comprise at least: (i) a call by the mobile aggregator to the service to execute
the feature according to the business logic, and (ii) a result of the call from the service;
responsive to sending the first message, suspending a calling environment in the mobile device;
receiving, at the frontend, a third message in the first protocol from the mobile aggregator, the third
message comprising the result from the service; and
responsive to receiving the third message, resuming the calling environment in the mobile device and
displaying the result at the frontend.
9. Non-transitory computer-readable tangible media that includes instructions for execution, which when executed by a processor of a computing device, is operable to perform operations comprising:
receiving, by a mobile aggregator, a set of first messages over a wireless communication network from a frontend of a mobile application executing in a mobile device, the set of first messages comprising instructions in Remote Procedure Call (RPC) protocol execute a feature of the mobile application, wherein:
invoking the RPC protocol triggers suspending a calling environment in the mobile device and transferring procedure parameters across the wireless communication network from the mobile device to the mobile aggregator,
the feature comprises one or more services of the mobile application executing in a cloud network,
the set of first messages identifies the mobile aggregator as recipient, and
different features of the mobile application are associated with respectively different sets of first messages;
executing, by the mobile aggregator, the instructions in the first messages, wherein executing the instructions comprises:
identifying, by the mobile aggregator, the one or more services of the mobile application called by the instructions in the first messages;
generating second messages comprising other instructions in another protocol compatible with communication in the cloud network to execute the feature of the mobile application;
communicating, by the mobile aggregator, the second messages in the another protocol to the one or more services in the cloud network;
receiving results from the one or more services; and
generating a set of response messages with the results in the RPC protocol; and
sending the set of response messages to the frontend, wherein:
sending the response messages triggers unsuspending the calling environment and resuming execution at the frontend,
and
transaction history between any two of the first messages is stored in the frontend or in the one or more services.
35. (New) An apparatus comprising:
a processing circuitry;
a memory storing data; and
a communication circuitry, wherein the processing circuitry executes instructions associated with the
data, the processing circuitry is coupled to the communication circuitry and the memory, and the
processing circuitry and the memory cooperate, such that the apparatus is configured for:
activating a feature at a frontend of a mobile application, wherein:
the feature is associated through business logic with a service of the mobile application,
the frontend executes in a mobile device, and
the service executes remotely from the mobile device;
responsive to activating the feature, generating, at the frontend, a first message in a first protocol
to a mobile aggregator of the mobile application, wherein:
the mobile aggregator executes remotely from the mobile device,
the mobile aggregator subscribes to the service such that any update to the service is
automatically propagated to the mobile aggregator,
the first protocol enables the frontend to call the mobile aggregator as a local object,
receiving the first message at the mobile aggregator triggers second messages in a second
protocol,
the second protocol is different from the first protocol, and
the second messages comprise at least: (i) a call by the mobile aggregator to the service to
execute the feature according to the business logic, and (ii) a result of the call from the
service; responsive to sending the first message, suspending a calling environment in the
mobile device;
receiving, at the frontend, a third message in the first protocol from the mobile aggregator, the
third message comprising the result from the service; and
responsive to receiving the third message, resuming the calling environment in the mobile device
and displaying the result at the frontend.
16. An apparatus comprising:
a processing circuitry;
a memory storing data; and
a communication circuitry, wherein the processing circuitry executes instructions associated with the data, the processing circuitry is coupled to the communication circuitry and the memory, and the processing circuitry and the memory cooperate, such that the apparatus is configured for:
receiving, by a mobile aggregator, a set of first messages over a wireless communication network from a frontend of a mobile application executing in a mobile device, the set of first messages comprising instructions in Remote Procedure Call (RPC) protocol to execute a feature of the mobile application, wherein:
invoking the RPC protocol triggers suspending a calling environment in the mobile device and transferring procedure parameters across the wireless communication network from the mobile device to the mobile aggregator,
the feature comprises one or more services of the mobile application executing in a cloud network,
the set of first messages identifies the mobile aggregator as recipient, and
different features of the mobile application are associated with respectively different sets of first messages;
executing, by the mobile aggregator, the instructions in the first messages, wherein executing the instructions comprises:
identifying, by the mobile aggregator, the one or more services of the mobile application called by the instructions in the first messages;
generating second messages comprising other instructions in another protocol compatible with communication in the cloud network to execute the feature of the mobile application;
communicating, by the mobile aggregator, the second messages in the another protocol to the one or more services in the cloud network;
receiving results from the one or more services; and
generating a set of response messages with the results in the RPC protocol; and
sending the set of response messages to the frontend, wherein:
sending the response messages triggers unsuspending the calling environment and resuming execution at the frontend,
and
transaction history between any two of the first messages is stored in the frontend or in the one or more services.
2. “A later patent claim is not patentably distinct from an earlier patent claim if the later claim obvious over, or anticipated by, the earlier claim. In re Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding obviousness-type double patenting where a patent application claim to a genus is anticipated by a patent claim to a species within that genus)”. ELI LILLY AND COMPANY vs. BARR LABORATORIES INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
This is a non-provisional obviousness-type double patenting rejection because the conflicting claims have not in fact been patented.
3. Thus, this double patenting rejection is necessary to prevent unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees.
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.
1. Claim(s) 21-23, 25-27, 29, 30, 32-36 and 38-40 are rejected under 35 U.S.C. 103 as being unpatentable over Loo (US 20150229638 A1) in view of Bose (US 20120130987 A1) in view of Ding (US 20030055929 A1).
With respect to independent claims:
Regarding claim(s) 21, a method for operating a mobile application, the method comprising:
Loo teaches activating a feature at a frontend of the mobile application, wherein: the feature is associated through business logic with a service of the mobile application, the frontend executes in a mobile device, and the service executes remotely from the mobile device; (Loo, [0053], FIGs.1-2, cloud computer system 110 may include a dispatcher 118 that may handle requests and dispatch them to the appropriate service. [0074], mobile computing devices 202, 212 may each implement an application (an “app”) that can provide specific user interfaces to communicate with cloud computer system 110.)
responsive to activating the feature, generating, at the frontend, a first message in a first protocol to a mobile aggregator of the mobile application, wherein: the mobile aggregator executes remotely from the mobile device, (Loo, [0012] The protocol translator may convert the response received from the enterprise computer system, where the response is converted from the ser format of the second communication protocol to the first format of the first communication protocol, and where the converted response is sent as the response to the mobile computing device. [0049], Fig.1, computing device 102 may communicate (e.g., send a request message) with mobile cloud service (MCS) 112 to request service provided by an enterprise computer system. [0053], Cloud computer system 110 may include a dispatcher 118 that may handle requests and dispatch them to the appropriate service. [examiner notes: mobile cloud service (MCS) 112 or dispatcher 118 interprets to be mobile aggregator.])
the first protocol enables the frontend to call the mobile aggregator as a local object, receiving the first message at the mobile aggregator triggers second messages in a second protocol, the second protocol is different from the first protocol, and (Loo, [0012] The protocol translator may convert the response received from the enterprise computer system, where the response is converted from the second format of the second communication protocol to the first format of the first communication protocol, and where the converted response is sent as the response to the mobile computing device. [0052], FIG.1, Cloud computer system 110 may include, implement, and/or communicate with one or more load balancer systems 106, 108. Upon determining security authentication, cloud computer system 110 may request any one of load balancer systems 106, 108 to examine a request that it receives and to detect which service the request is directed to. MCS 112 may be configured with load balancers 106, 108 and updated with resources that get started up, so that when a request comes in, load balancers 106, 108 can balance a requested load across the different resources. [0077], FIG.2, Protocol translator 252 may process a message to determine a communication protocol for a message and/or to convert a message to a communication protocol for a destination. Protocol translator 252 may convert a request received from mobile computing devices 202, 212. The request may be converted from a format of a communication protocol supported by computing device 202, 212 to a format of a communication protocol supported by enterprise computer system 282, 292.)
the second messages comprise at least: (i) a call by the mobile aggregator to the service to execute the feature according to the business logic, and (ii) a result of the call from the service;(Loo, [0095], FIG.3; process 300 may include sending enterprise data 330 to enterprise computer system 150. Enterprise data 330 may include a request and may be sent using a communication protocol supported by enterprise computer system 150. The request may correspond to a request received from computing device 302. Enterprise data 330 may include enterprise data described above, such as enterprise data stored by cloud computer system 110. Enterprise data 330 may include a security token generated for a request. Enterprise data 330 may include multiple requests, each corresponding to a request received from computing device 302. In some embodiments, enterprise data 330 may include multiple requests selected based on a single request received from computing device 302. When including multiple requests, enterprise data 330 may include a security token corresponding to each request. In the example shown in FIG. 3, enterprise data 330 may indicate multiple requests, each corresponding to a different requested service. Each requested service may be provided by enterprise computer system 150 or other enterprise computer systems accessible to enterprise computer system 150. In some embodiments, enterprise data 330 may be directed to agent system 152. As explained above, agent system 152 may support a common security protocol for handling requests for services. Enterprise data 330 may be formatted according to a common security protocol.)
receiving, at the frontend, a third message in the first protocol from the mobile aggregator, the third message comprising the result from the service; and (Loo, [0012] The protocol translator may convert the response received from the enterprise computer system, where the response is converted from the second format of the second communication protocol to the first format of the first communication protocol, and where the converted response is sent as the response to the mobile computing device. [0105], FIG.3; process 300 may include cloud computer system 110 sending one or more responses (e.g., response 360 or response 380) to computing device 302. Response 360 and response 380 may be sent including enterprise data from response 352 and response 372, respectively. In some embodiments, response 360 or response 380 may be sent including enterprise data included in both. In some embodiments, cloud computer system may merge stored enterprise data with enterprise data received in either or both of response 352 or response 372. Response 360 and/or response 380 may include a notification about data 310 originally sent to cloud computer system 110.)
Loo does not teach the mobile aggregator subscribes to the service such that any update to the service is automatically propagated to the mobile aggregator, responsive to sending the first message, suspending a calling environment in the mobile device; responsive to receiving the third message, resuming the calling environment in the mobile device and displaying the result at the frontend.
Boss however in the same field of computer networking teaches the mobile aggregator subscribes to the service such that any update to the service is automatically propagated to the mobile aggregator, (Boss, [0012] The protocol translator may convert the response received from the enterprise computer system, where the response is converted from the second format of the second communication protocol to the first format of the first communication protocol, and where the converted response is sent as the response to the mobile computing device. [0048] With reference now to FIG. 3, a diagram of a data aggregation system is depicted in accordance with an illustrative embodiment. Data aggregation system 300 is a system of hardware and software components that are used to aggregate data from a plurality of distributed data sources, without utilizing a centralized data warehouse. Data aggregation system 300 may aggregate data as a service to subscribing clients. The data aggregation service may, for example, be implemented as a Web service. [0052] Data dimensions catalog 320 is a database that maintains all available facts and dimensions across an enterprise, along with the associated metadata and annotations. Data dimensions catalog 320 is updated by data aggregation server 302 whenever any change in dimensional information is received from data sources 306, 308, and 310 as part of a data model lifecycle. In addition, data dimensions catalog 320 stores information regarding which data dimensions are to be shared with which client application. Data dimensions catalog 320 may, for example, be stored in a storage device, such as persistent storage 208 in FIG. 2.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Loo by incorporating the teachings of Boss. The motivation/suggestion would have been because there is a need to keep track of any new dimensions added to a data source and make these new dimensions available to the information access layer of business intelligence applications so that reports can be built dynamically with minimal changes in the business applications (Boss, [0044]).
Loo does not teach responsive to sending the first message, suspending a calling environment in the mobile device; responsive to receiving the third message, resuming the calling environment in the mobile device and displaying the result at the frontend.
Ding however in the same field of computer networking teaches responsive to sending the first message, suspending a calling environment in the mobile device; (Ding, [0047] The receiving Ethernet switching module makes an RPC service call in order to retrieve one or more network management objects from the cooperating Ethernet switching module. The RPC service uses IMC services to send a request to the cooperating Ethernet switching module, and suspends the calling application in the receiving Ethernet switching module (by making the appropriate operating system call) until the response is received from the cooperating Ethernet switching module.)
responsive to receiving the third message, resuming the calling environment in the mobile device and displaying the result at the frontend. (Ding, [0047] The receiving Ethernet switching module makes an RPC service call in order to retrieve one or more network management objects from the cooperating Ethernet switching module. The RPC service uses IMC services to send a request to the cooperating Ethernet switching module, and suspends the calling application in the receiving Ethernet switching module (by making the appropriate operating system call) until the response is received from the cooperating Ethernet switching module.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Loo by incorporating the teachings of Ding. The motivation/suggestion would have been because there is a need to enables a plurality of interconnected modules to be managed and controlled as an integrated unit without requiring any one of the interconnected modules to operate as a fully centralized manager (Ding, [0016]).
Claim(s) 29 and 35 is/are substantially similar to claim 21, and is thus rejected under substantially the same rationale.
With respect to dependent claims:
Regarding claim(s) 22, the method of claim 21,
Loo-Boss-Ding teach wherein: a load balancer receives the first message from the mobile device, the load balancer enables communication of the second messages between the mobile aggregator and the service, and the load balancer forwards the third message to the mobile device. (Loo, [0052], Fig.1, Cloud computer system 110 may include, implement, and/or communicate with one or more load balancer systems 106, 108. Upon determining security authentication, cloud computer system 110 may request any one of load balancer systems 106, 108 to examine a request that it receives and to detect which service the request is directed to. MCS 112 may be configured with load balancers 106, 108 and updated with resources that get started up, so that when a request comes in, load balancers 106, 108 can balance a requested load across the different resources. [0053] Cloud computer system 110 may include a dispatcher 118 that may handle requests and dispatch them to the appropriate service.)
Regarding claim(s) 23, the method of claim 21,
Loo-Boss-Ding teach wherein the first message identifies the mobile aggregator and
not the service as recipient. (Loo, [0049] Computing device 102 may communicate (e.g., send a request message) with MCS 112 to request service provided by an enterprise computer system. Requests that are received through firewall 104 may be processed first by security service 132. [examiner notes: the examiner interprets the limitation as “send a request/message to the mobile aggregator and not the service provider])
Regarding claim(s) 25, the method of claim 21,
Loo-Boss-Ding teach wherein: the mobile aggregator comprises a plurality of services,
the business logic of the mobile application associates more than one service with the feature, (Loo, [0035] An enterprise computer system may include various computing systems that are configured to operate for an entity or an enterprise. For example, an enterprise computer system may include one or more computer systems, such as an enterprise server computer (e.g., a back-end server computer), to handle requests for services. An enterprise computer system may include applications and/or services, which can process and/or operate using enterprise data. For example, enterprise computer system 150 may provide one or more services and/or applications for managing or operating an enterprise. Services may include, without restriction, customer relationship management (CRM), human capital management (HCM), human resource (HR) management, supply chain management, enterprise communication, email communication, business services, other enterprise management services or applications, or combinations thereof. Enterprise computer system 150 may include one or more computer systems dedicated to providing one or more services. [0039] Metadata repository 124 may store all the metadata associated with MCS 112. This information may be composed of both run-time and design-time data, each having their own requirements on availability and performance. A tenant or subscriber of MCS 112 may have any number of applications. Each application may be versioned and may have an associated zero or more versioned resource APIs and zero or more versioned services implementations those resource application programming interface (API) contracts. These entities are what the run-time uses to map virtual requests (mAPIs) to the concrete service implementation (service). This mapping provides a mobile developer with the luxury of not having to know the actual implementation service when she designs and builds her application.) and the second messages further comprise: (i) calls by the mobile aggregator to the more than one service to execute the feature according to the business logic, and (ii) results of the calls from the more than one service. (Loo, [0103], FIG.3; process 300 may include enterprise computer system 150 sending one or more responses (e.g., response 352 or response 372) to cloud computer system 110. A response may include enterprise data received in a response from an enterprise server computer. The enterprise data may be formatted according to a communication protocol supported by cloud computer system 110. A response may be sent for each response received from an enterprise server computer. For example, response 352 may include enterprise data received from response 350 and response 372 may include enterprise data received from response 370. Enterprise computer system 150 may send a response as responses are received from an enterprise server computer, or a response may include enterprise data received from multiple responses that have been gathered. Such techniques may be useful to minimize communication and/or improve efficiency for communication. In some embodiments, multiple responses may be gathered to receive enterprise data to provide a requested service. As such, enterprise computer system 150 may send multiple responses to cloud computer system 110 to provide enterprise data related to a requested service.)
Regarding claim(s) 26, the method of claim 25,
Loo-Boss-Ding teach wherein the mobile aggregator translates the first message into
the calls, each call to a separate one of the more than one service. (Loo, [0059], cloud computer system 110 may enable computing device to access and/or request one or more services, such as an object store service, database service, access web services, social services, resource services, or combinations thereof.)
Regarding claim(s) 27, the method of claim 21,
Loo-Boss-Ding teach wherein: the first protocol is Remote Procedure Call (RPC), (Ding, [0047], a Remote Procedure Call (RPC) service is used by the receiving Ethernet switching module to retrieve the requested network management object from the cooperating Ethernet switching module. The RPC service utilizes acknowledged IMC services for reliability.) and the second protocol is at least one of: server to server (STS) protocol or intra-app protocol. (Loo, [0070] One or more of enterprise computer systems 282, 292 may communicate with cloud computer system 110 using one or more different protocols. A protocol may include a communication protocol, such as SPDY. A protocol may include an application protocol such as an HTTP-based protocol. In some embodiments, enterprise computer systems 282, 292 may communicate with cloud computer system 110 using a REST or SOAP communication protocols. For example, REST protocol may support a formats including URI or URL. Enterprise Data formatted for communication using REST protocol may be easily converted to data formats such as JSON, comma-separated values (CSV), and really simple syndication (RSS). Enterprise computer systems 282, 292 and cloud computer system 110 may communicate using other protocols such as remote procedure calls (RPC) (e.g., XML RPC). [examiner notes: REST protocol is one of server-to-server protocol.])
The same motivation to combine as the independent claim applies here.
Claim(s) 30 and 36 is/are substantially similar to claim 22, and is thus rejected under substantially the same rationale.
Claim(s) 32 and 38 is/are substantially similar to claim 25, and is thus rejected under substantially the same rationale.
Claim(s) 33 and 39 is/are substantially similar to claim 23, and is thus rejected under substantially the same rationale.
Claim(s) 34 and 40 is/are substantially similar to claim 27, and is thus rejected under substantially the same rationale.
2. Claim(s) 24, 31 and 37 is/are rejected under 35 U.S.C. 103 as being unpatentable over Loo in view of Bose in view of Ding further in view of Leibmann (US 20210250361 A1).
Regarding claim(s) 24, the method of claim 21,
Loo-Boss-Ding does not teach wherein the mobile aggregator does not have credentials to modify the service.
Leibmann however in the same field of computer networking teaches wherein the mobile aggregator does not have credentials to modify the service. (Leibmann, [0005] Authentication and authorization across microservices"): Teaches methods for extracting application identifiers from tokens and enforcing authorization policies to decide whether a calling entity has explicit permissions to access or modify a microservice. [0016] Thus, the present description proceeds with respect to a central microservice authorization and authentication computing system (collectively referred to as a microservice AUTH computing system). Each microservice has authentication metadata and authorization policy metadata. The authentication metadata identifies the microservice and can be used to request an access token to access a different microservice. The authorization policy metadata defines the types of permissions that the microservice exposes to other microservices or other requesting entities (such as mobile device applications, web applications, etc.), and it defines permissions that are granted to different microservices (or requesting entities) using different access patterns. While the authentication and authorization metadata corresponds to a particular microservice, it is managed at a central microservice AUTH computing system. In this way, changes can more easily be made to the authentication and authorization metadata during runtime, and they can also be made to accommodate for new microservices or modified microservices.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Loo by incorporating the teachings of Leibmann. The motivation/suggestion would have been because there is a need to changes can more easily be made to the authentication and authorization metadata during runtime, and they can also be made to accommodate for new microservices or modified microservices (Leibmann, [0016]).
Claim(s) 31 and 37 is/are substantially similar to claim 24, and is thus rejected under substantially the same rationale.
3. Claim(s) 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Loo in view of Bose in view of Ding further in view of Ehimah Obuse (Optimizing Microservice Communication with gRPC and Protocol Buffers in Distributed Low-Latency API-Driven Applications, Published: 13-05-2020, International Journal of Multidisciplinary Futuristic Development.)
Regarding claim(s) 28, the method of claim 21,
Loo-Boss-Ding does not teach wherein the second protocol has lower latency than the first
protocol.
Obuse however in the same field of computer networking teaches wherein the second protocol has lower latency than the first protocol. (Obuse, P.46 and P.49, One of the most foundational design patterns in gRPC is the unary RPC, where the client sends a single request and receives a single response. This closely mirrors the traditional request-response model of REST but with significantly lower latency and reduced payload size due to the use of binary Protobuf encoding.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Loo by incorporating the teachings of Obuse. The motivation/suggestion would have been because there is a need to optimizing microservice communication has emerged as a critical concern, especially for low-latency, API-driven applications (Obuse, abstract).
Conclusion
The prior art made of record and no0t relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WUJI CHEN whose telephone number is (571)270-0365. The examiner can normally be reached on 9am-6pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, VIVEK SRIVASTAVA can be reached on (571) 272-7304. The fax phone number for the organization where this application or procee oopo;;;llooiiding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WUJI CHEN/
Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449
Prosecution Insights