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 .
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 § 2146 et seq. 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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Double Patenting
Claims 1-3, 6-7 and 12-15 are rejected on the ground of non statutory double patenting as being unpatentable over claims 1-3, 7-8 and 15-18 of U.S. Patent No. 12381882. Although the claims at issue are not identical, they are not patentably distinct from each other because the limitations in each claim set relate to the same concept.
US Patent 12381882
19/233,991
A system, comprising:
a database configured to store source application information associated with a set of source application servers; and
one or more processors configured to:
monitor an update across the set of source application servers, wherein the update comprises a set of changes across two or more application servers;
translate the update into a synthetic message using the source application information and an attribute associated with a target authorization system, wherein to translate the update comprises to:
determine the set of changes comprises a pattern; and generate a cross-application synthetic message that combines the set of changes across the two or more application servers; and send the synthetic message to the target authorization system, wherein the target authorization system is configured to instruct an authorization action to be performed at one or more of the set of source application servers.
A system, comprising:
a database configured to store source application information associated with a set of source application servers; and
one or more processors configured to:
monitor a set of updates across the set of source application servers;
package the set of updates into a synthetic message using the source application
information and an attribute associated with a target authorization system;
send the synthetic message to the target authorization system, wherein the target
authorization system is configured to instruct an authorization action to be performed at one or more of the set of source application servers; and
perform an implementation at the one or more of the set of source application servers based at least in part on the authorization action.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Morrison (US Patent Publication 2015/0213449) in view of Digikar (US Patent Pub. 2023/0370347).
As per claims 1 and 19: Morrison discloses a system, comprising:
a database configured to store source application information associated with a set of source application servers (Paragraph 16; The API transaction risk assessment equipment 120 can operate on each of the API transaction requests to generate a risk assessment score based on context information that characterizes the API transaction request. The risk assessment score indicates a level of trustworthiness of the API transaction request for processing by an application on the application servers 110. The API transaction risk assessment equipment 120 can control deliverability of the API transaction request through one or more data networks 110b to the application servers 110 for processing based on the risk assessment score); and
one or more processors configured to:
monitor a set of updates across the set of source application servers; package the set of updates into a synthetic message using the source application information and an attribute associated with a target authorization system (claim 6; receiving an authentication response message from the source node; and controlling deliverability of the API transaction request to the destination node based on content of the authentication response message);
send the synthetic message to the target authorization system, wherein the target authorization system is configured to instruct an authorization action to be performed at
one or more of the set of source application servers; and perform an implementation at the one or more of the set of source application servers based at least in part on the authorization action (Paragraph 27; The destination node 110 processes (block 220) the API transaction request to generate an API transaction response (e.g., by retrieving or generating information requested by the API transaction request), and communicates (block 222) the API transaction response to the source node 100. The source node 100 receives (block 224) the API transaction response, and provides (block 226) the API transaction response to the application on the source node 104 for processing).
However, Morrison does not specifically disclose synthetic message.
Digikar discloses API monitoring (e.g., synthetic monitoring), on the other hand, is done using one or more API monitoring agents 430 that “hit” (ping, send messages to, send requests to, etc.) the APIs 415 of the server 410 periodically with a synthetic message 435, thus providing data related to the API and its performance (Paragraph 55).
Therefore, it 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, having the teachings of Morrison and Digikar in it’s entirety, to modify the technique of Morrison for API monitoring (e.g., synthetic monitoring), on the other hand, is done using one or more API monitoring agents 430 that “hit” (ping, send messages to, send requests to, etc.) the APIs 415 of the server 410 periodically with a synthetic message by adopting Digikar's teaching for API monitoring (e.g., synthetic monitoring), on the other hand, is done using one or more API monitoring agents that “hit” (ping, send messages to, send requests to, etc.) the APIs of the server periodically with a synthetic message . The motivation would have been to improve bridging between source applications and authorizations systems.
As per claim 2: The system of claim 1, wherein to monitor the set of updates across the set of source application servers comprises to monitor logs or events of the set of source application servers (Paragraph 16; The API transaction risk assessment equipment 120 can operate on each of the API transaction requests to generate a risk assessment score based on context information that characterizes the API transaction request).
As per claim 3: The system of claim 1, wherein the set of updates comprises one or more of the following: an entity gaining an access, the entity performing an action in a source application, the entity connecting to another system, the entity changing an Internet Protocol (IP) address, the entity changing a location, the entity elevating a permission, the entity using administrative or elevated permissions, and the entity performing an operation on data (claim 6; receiving an authentication response message from the source node; and controlling deliverability of the API transaction request to the destination node based on content of the authentication response message).
As per claim 4: The system of claim 3, wherein the entity refers to one of the following: a user, an integration, and an automated process (Paragraph 16; The API transaction risk assessment equipment 120 can operate on each of the API transaction requests to generate a risk assessment score based on context information that characterizes the API transaction request).
As per claim 5: The system of claim 1, wherein to monitor the set of updates across the set of source application servers comprises to receive messages from the set of source application servers (Paragraph 18; attempting to obtain information from application servers 110 for delivery to a falsely identified API client application, attempting to obtain information from the application servers 110 that is not authorized by access privileges of an API client application, attempting to improperly modify operation of one or more applications on the application servers 110, and/or attempting to improperly utilize resources of the application servers 110 (e.g., access resources that are not authorized for use by the API client application)).
As per claim 6: The system of claim 5, wherein to package the set of updates into the synthetic message
comprises to:
determine a source application-specific user identifier (ID) of a user identified in the set of updates (Paragraph 46);
determine a global user ID corresponding to the source application-specific user ID (Paragraph 46; packets can be examined by network agents to identify the business transaction identifier (ID) (e.g., a Globally Unique Identifier (GUID) or Universally Unique Identifier (UUID))); and
add the global user ID into the synthetic message that is generated from the set of updates (Paragraph 55; API monitoring (e.g., synthetic monitoring), on the other hand, is done using one or more API monitoring agents 430 that “hit” (ping, send messages to, send requests to, etc.) the APIs 415 of the server 410 periodically with a synthetic message 435).
As per claim 7: The system of claim 5, wherein to package the set of updates into the synthetic message comprises to:
determine a format of data that is to be ingested by the target authorization system; and based on the format of the data that is to be ingested by the target authorization system, add a new field to the synthetic message (Paragraph 55; API monitoring (e.g., synthetic monitoring), on the other hand, is done using one or more API monitoring agents 430 that “hit” (ping, send messages to, send requests to, etc.) the APIs 415 of the server 410 periodically with a synthetic message 435).
As per claim 8: The system of claim 5, wherein to package the set of updates into the synthetic message comprises to:
score the received messages (Paragraph 16); filter the received messages based on their respective scores; and generate the synthetic message based on received messages that are not filtered out based on their respective scores (Paragraph 16; The API transaction risk assessment equipment 120 can operate on each of the API transaction requests to generate a risk assessment score based on context information that characterizes the API transaction request. The risk assessment score indicates a level of trustworthiness of the API transaction request for processing by an application on the application servers 110. The API transaction risk assessment equipment 120 can control deliverability of the API transaction request through one or more data networks 110b to the application servers 110 for processing based on the risk assessment score);.
As per claim 9: The system of claim 5, wherein to package the set of updates into the synthetic message comprises to enable efficient transmission of the synthetic message by one or more of the following: compression, bulk packaging, message grouping, and pruning with respect to the received messages (Paragraph 55; API monitoring (e.g., synthetic monitoring), on the other hand, is done using one or more API monitoring agents 430 that “hit” (ping, send messages to, send requests to, etc.) the APIs 415 of the server 410 periodically with a synthetic message 435).
As per claim 10: The system of claim 5, wherein to package the set of updates into the synthetic message comprises to:
obtain a data classification associated with a source application server from which at least
a subset of the set of updates was monitored; and add the data classification to the synthetic message (Paragraph 55; API monitoring (e.g., synthetic monitoring), on the other hand, is done using one or more API monitoring agents 430 that “hit” (ping, send messages to, send requests to, etc.) the APIs 415 of the server 410 periodically with a synthetic message 435).
As per claim 11: The system of claim 1, wherein to monitor the set of updates across the set of source application servers comprises to receive telemetric updates from the set of source application servers (Paragraph 18; attempting to obtain information from application servers 110 for delivery to a falsely identified API client application, attempting to obtain information from the application servers 110 that is not authorized by access privileges of an API client application, attempting to improperly modify operation of one or more applications on the application servers 110, and/or attempting to improperly utilize resources of the application servers 110 (e.g., access resources that are not authorized for use by the API client application)).
As per claim 12: The system of claim 1, wherein to package the set of updates into the synthetic message comprises to:
determine that a change included in the update had originated from a first source
application server (Paragraph 16; The API transaction risk assessment equipment 120 can operate on each of the API transaction requests to generate a risk assessment score based on context information that characterizes the API transaction request. The risk assessment score indicates a level of trustworthiness of the API transaction request for processing by an application on the application servers 110. The API transaction risk assessment equipment 120 can control deliverability of the API transaction request through one or more data networks 110b to the application servers 110 for processing based on the risk assessment score); and
masquerade a content of the synthetic message to emulate that the change included in the update had originated from a second source application server, wherein the second source application server is different from the first source application server (Paragraph 27; The destination node 110 processes (block 220) the API transaction request to generate an API transaction response (e.g., by retrieving or generating information requested by the API transaction request), and communicates (block 222) the API transaction response to the source node 100. The source node 100 receives (block 224) the API transaction response, and provides (block 226) the API transaction response to the application on the source node 104 for processing).
As per claim 13: The system of claim 1, wherein to package the set of updates into the synthetic message comprises to combine the set of updates into a single synthetic message that conforms to a format or protocol that is recognized by the target authorization system (claim 9; identifying one of a plurality of known API transaction protocols that is being used by the API transaction request; and generating the risk assessment score based on whether the identified one of the plurality of known API transaction protocols that is being used by the API transaction request matches an API transaction protocol that is expected to be used by the application processed by the source node).
As per claim 14: The system of claim 13, wherein the set of updates comprises updates monitored across at least two different source application servers (Paragraph 16; The risk assessment score indicates a level of trustworthiness of the API transaction request for processing by an application on the application servers 110. The API transaction risk assessment equipment 120 can control deliverability of the API transaction request through one or more data networks 110b to the application servers 110 for processing based on the risk assessment score).
As per claim 15: The system of claim 1, wherein the one or more processors are further configured to receive, from the target authorization system, an instruction describing the authorization action (claim 6; receiving an authentication response message from the source node; and controlling deliverability of the API transaction request to the destination node based on content of the authentication response message).
As per claim 16: The system of claim 15, wherein the one or more processors are further configured to determine whether the authorization action is able to be performed natively at the one or more of the set of source application servers relative to the instruction (Paragraph 16; The risk assessment score indicates a level of trustworthiness of the API transaction request for processing by an application on the application servers 110. The API transaction risk assessment equipment 120 can control deliverability of the API transaction request through one or more data networks 110b to the application servers 110 for processing based on the risk assessment score).
As per claim 17: The system of claim 16, wherein in the event that the authorization action is able to be performed natively at the one or more of the set of source application servers, the one or more processors are configured to make one or more application programming interface (API) calls to the one or more of the set of source application servers to implement the authorization action (Paragraph 25; The PDP 124 generates (block 204) a risk assessment score based on context information that characterizes the API transaction request (e.g., the context information may be received from the PEP 122 or may be generated by the PDP 124 based on one or more defined rules). The risk assessment score indicates a level of trustworthiness of the API transaction request for processing by an application on the destination node 110).
As per claim 18: The system of claim 16, wherein in the event that the authorization action is not able to be performed natively at the one or more of the set of source application servers, the one or more processors are configured to perform an action at the one or more of the set of source application servers that approximates an effect of the authorization action that is instructed by the target authorization system (Paragraph 25; The PDP 124 generates (block 204) a risk assessment score based on context information that characterizes the API transaction request (e.g., the context information may be received from the PEP 122 or may be generated by the PDP 124 based on one or more defined rules). The risk assessment score indicates a level of trustworthiness of the API transaction request for processing by an application on the destination node 110).
As per claim 20: The method of claim 19, wherein packaging the set of updates into the synthetic message comprises combining the set of updates into a single synthetic message that conforms to a format or protocol that is recognized by the target authorization system (claim 9; identifying one of a plurality of known API transaction protocols that is being used by the API transaction request; and generating the risk assessment score based on whether the identified one of the plurality of known API transaction protocols that is being used by the API transaction request matches an API transaction protocol that is expected to be used by the application processed by the source node).
Relevant Prior Art References
The following prior art is cited as being of interest to the claimed invention but has not been applied in any of the current rejections.
Panitsas et al.- US Patent Publication 2024/0095073- the prior art teaches techniques for automatic cluster scaling.
Mangalam et al.- US Patent Pub. 2023/0254210 - the prior art teaches techniques for drift detection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANTHONY D BROWN whose telephone number is (571)270-1472. The examiner can normally be reached 730-330pm.
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, Linglan Edwards can be reached at 5712705440. 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.
/ANTHONY D BROWN/Primary Examiner, Art Unit 2408
Prosecution Insights