DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed on 03/27/2026.
Claims 1-20 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 20 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 20 recites the limitations “a first message for a first process component with a first framework” and “a second message that provides a corresponding result for a second component associated with a second framework”. Prior to this limitation, the claims recite: “wherein a first one of the first or second frameworks uses an actor pattern and a second one of the first or second frameworks uses an event based asynchronous pattern;”. It is unclear whether the first framework and the second framework are meant to be the same first or second frameworks using the actor pattern or the event based asynchronous pattern, or if the first framework and the second framework are two new frameworks. For the sake of compact prosecution examiner will interpret these limitations to mean “a first message for a first process component with the first framework” and “a second message that provides a corresponding result for a second component associated with the second framework”.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 1-16 are directed to a method and fall within the statutory category of process. Claims 17-19 are directed to a computing system and fall within the statutory category of machine. Claim 20 is directed to a computer-readable storage medium and falls within the statutory category of machine. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claims 1, 17, and 20: The limitations of “mapping, by the compatibility layer, the first message to a second message that provides a corresponding result for a second component associated with the second framework;” and “mapping, by the compatibility layer, the first message to a second message that provides a corresponding result for a second component associated with a/the second framework;”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe a first message and, based on these observations, can mentally map the first message to a second message that provides a corresponding result for a second component associated with the second framework. This may also be done with pencil and paper. Further, the limitations of “and transfers memory ownership between the first and second frameworks,”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally reassign memory ownership from one framework to another. This may also be done with pencil and paper.
Therefore, Yes, claims 1, 17, and 20 recite a judicial exception.
Step 2A Prong 2:
Claims 1, 17, and 20: The judicial exception is not integrated into a practical application. In particular, the claims recite additional element recitations of “A method of enabling interoperation between a first framework and a second framework in a system running a compatibility layer configured to enable the interoperation between the first framework and the second framework,”, “wherein one of the frameworks uses an actor pattern and the other framework uses an event based asynchronous pattern and the frameworks have different concurrency and memory models,”, “wherein a first one of the first or second frameworks uses an actor pattern and a second one of the first or second frameworks uses an event based asynchronous pattern and the frameworks have different concurrency and memory models;”, “and wherein the system supports the first and second frameworks,”, and “and the compatibility layer is exposed as an actor to the framework using the actor pattern and exposed as an asynchronous component to the framework using the event based asynchronous pattern, thereby enabling the first and second frameworks to interoperate and enabling threading models of the first and second frameworks to be adhered to by the compatibility layer”, which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, the claims recite additional element recitations of “executing a compatibility layer configured to enable interoperation between a first framework and a second framework,”, which are merely recitations of generically using a computer as a tool to implement the abstract idea (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Further, the claims recite additional element recitations of “receiving, by the compatibility layer, a first message for a first component associated with the first framework;”, “receiving, by the compatibility layer, a first message for a first process component (associated) with a/the first framework;”, “and sending, by the compatibility layer, the second message to the second component for processing by the second component,”, and “wherein the compatibility layer synchronously returns actor threads while asynchronously processing work” , which are merely recitations of data reception and transmission which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the claims recite additional element recitations of “a processing system comprising a processor; and computer-readable media having thereon computer-executable instructions that are structured such that, when executed by the processing system, cause the computing system to perform operations comprising:” and “A computer-readable storage medium having thereon computer-executable instructions that are structured such that, when executed by a processing system of a computing system, cause the computing system to perform operations comprising:”, which are merely recitations of generic computing components (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application.
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
After having evaluated the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 17, and 20 not only recite a judicial exception but that the claims are directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
Claims 1, 17, and 20: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components, technological environment/field of use, and insignificant extra solution activity which do not amount to significantly more than the abstract idea. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)].
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claims 1, 17, and 20 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 2, the claim recites additional abstract idea recitations of “waiting for a response to the second message from the second component and mapping the response to the second message to a response to the first message from the first component”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally wait for a response to a second message, observe this second message, and based on these observations, can mentally map the second message to a response to a first message. This may also be done with pencil and paper. Further, claim 2 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 2 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 2 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 3 and 18, the claims recite additional element recitations of “wherein structures from the first framework are stored in a part of memory associated with the second framework, further comprising using the structures to access shared state across multiple threads”, which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, claims 3 and 18 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 3 and 18 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, Claims 3 and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 4, the claim recites additional abstract idea recitations of “wherein unknown structures are dynamically cast to specifically typed structures based on a field in the message”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe a field in a message and, based on these observations, can mentally assign a specific type to a structure. This may also be done with pencil and paper. Further, claim 4 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 4 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 4 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 5, the claim recites additional element recitations of “wherein the compatibility layer synchronously hands off messages to an asynchronous channel when an actor framework scheduler calls into the compatibility layer”, which are merely recitations of data transmission and reception which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Further, claim 5 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 5 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 5 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 6, the claim recites additional element recitations of “wherein the second framework is instructed not to free memory of any objects that the second framework has transferred ownership of to the first framework”, which are merely recitations of data reception which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Further, claim 6 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 6 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 6 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 7, the claim recites additional element recitations of “when messages are sent by the first framework, the first framework does not drop the messages and the compatibility layer takes ownership of the messages and ensures that the messages are either freed by the second framework or passed back to the first framework”, which are merely recitations of data transmission and storage which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Further, claim 7 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 7 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 7 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 8, the claim recites additional element recitations of “wherein the compatibility layer prevents memory from being moved by components between frameworks”, which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, claim 8 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 8 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 8 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 9, the claim recites additional element recitations of “storing metadata in memory allocated by the first framework”, which are merely recitations of data storage which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Further, claim 9 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 9 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 9 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 10, the claim recites additional element recitations of “wherein the metadata is stored using a memory model of the second framework”, which are merely recitations of data storage which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Further, claim 10 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 10 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 10 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 11, the claim recites additional element recitations of “wherein the memory model is opaque to the first framework”, which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, claim 11 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 11 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 11 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 12, the claim recites additional abstract idea recitations of “determining whether a message from the first framework can be correlated as a response to a previously sent message;”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe messages and, based on these observations, can mentally determine whether a message can be correlated as a response to a previously sent message. Further, the claim recites additional abstract idea recitations of “and one of: converting the message to a response according to the second framework … or converting the message to a request according to the second framework”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe a message and a second framework and, based on these observations, can mentally convert the message to a response according to the second framework or a request according to the second framework. This may also be done with pencil and paper. Further, the claim recites additional element recitations of “and sending the converted response to the second framework … and sending the converted request to the second framework”, which are merely recitations of data transmission which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Further, claim 12 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 12 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 12 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 13, the claim recites additional element recitations of “using specific per-request channels to track where to send asynchronous responses to requests from the framework using the event based asynchronous pattern and a per-framework channel to track sending requests to the framework using the event based asynchronous pattern”, which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, claim 13 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 13 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 13 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 14, the claim recites additional abstract idea recitations of “including a mapping for extracting a field from a message and a mapping from a value of the field to a channel corresponding to an asynchronous request to enable an asynchronous response to be sent to that request”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe a field in a message and, based on these observations, can mentally map from a value of the field to a channel corresponding to an asynchronous request. This may also be done with pencil and paper. Further, claim 14 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 14 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 14 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 15, the claim recites additional abstract idea recitations of “performing multi-stage message correlation including determining which channel to send a received message based on a type and ID of the received message”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe a type and an ID of a received message and, based on these observations, can mentally determine which channel to send the received message. This may also be done with pencil and paper. Further, claim 15 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 15 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 15 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 16 and 19, the claims recite additional element recitations of “wherein the compatibility layer enables the first and second frameworks to interoperate without modifying the first and second frameworks to enable the interoperation”, which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, claims 16 and 19 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 16 and 19 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, Claims 16 and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Therefore, Claims 1-20 do not recite patent eligible subject matter under U.S.C. §101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 5, 12, 13, 17, and 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Selitser (US 8,719,780 B2).
With regard to claim 1, Selitser teaches:
A method of enabling interoperation between a first framework and a second framework in a system running a compatibility layer configured to enable the interoperation between the first framework and the second framework, “In particular, the application server provides a programming model that is focused on protocol (framework) abstraction and protocol neutrality. This programming model is composed of two layers, namely a basic toolkit layer and a communicating sequential processes (CSP) adaptation layer … In the various embodiments, the CSP adaptation is the ideal target layer in which most applications will be implemented, while the basic toolkit is the model for the remaining few highly specific cases. Since the basic toolkit model is defined as a lower layer of primitives, it can be viewed as implementing the CSP adaptation” [Selitser Col. 3 Lines 4-9, 43-48]. “FIG. 3 is an illustration of the CSP Adaptation layer of the programming model employed by the application server, in accordance with various embodiments of the invention … As illustrated, the CSP Adaptation layer utilizes an actor-based model (framework) where the different actors 306, 314 communicate with each other by using asynchronous events issued via the event broker 304 (compatibility layer). In one embodiment, the "actor" is an entity that represents one or more application components” [Selitser Col. 9 Lines 19-21, 32-36, Fig. 3]. “The cooperation (interoperation) in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/O)” [Selitser Col. 8 Lines 5-8]. “In step 404, an event broker is provided for managing communications between the protocol adapters and the application component(s)” [Selitser Col. 12 Lines 55-57].
wherein one of the frameworks uses an actor pattern “In particular, the application server provides a programming model that is focused on protocol abstraction and protocol neutrality. This programming model is composed of two layers, namely a basic toolkit layer and a communicating sequential processes (CSP) adaptation layer” [Selitser Col. 3 Lines 4-9]. “CSP Adaptation is a higher level abstraction layered on top of the basic toolkit. The CSP adaptation represents simplifications and adaptations of the original basic model, while keeping the main principles in tact. More specifically, the CSP Adaptation layer utilizes an actor-based model, where each actor can group together one or more application components” [Selitser Col. 3 Lines 24-30]. “In various embodiments, actors are special classes that are involved in message passing between each other. In one embodiment, each actor is the owner of its own segment of state, which is only accessible to that actor. Other actors interested in updating that state would send asynchronous events to the owning actor, with the implicit intention that the owning actor will react to those events” [Selitser Col. 3 Lines 30-36].
and the other framework uses an event based asynchronous pattern “In order to achieve protocol abstraction, the basic toolkit employs an event-based model of communications. In this model, a set of protocol adapters is used in conjunction with an event broker. The event broker maps all protocol-specific communications exposed by the adapters into a set of asynchronous events. The various application components executing on the application server can then consume protocol-inbound asynchronous events from the protocol adapters and produce protocol-outbound asynchronous events to the protocol adapters via the event broker” [Selitser Col. 3 Lines 11-21].
and the frameworks have different concurrency “In the context of concurrency, the single-threaded nature of actors can ensure simple, lock-free execution within a single process. In one embodiment, cluster-wide primary election ensures a globally unique actor identity to which all relevant events are directed” [Selitser Col. 11 Lines 22-26]. “In various embodiments, the application components can see two different abstractions depending on which layer of the programming model is being employed. Application components which are based on basic toolkit alone can communicate by pure method calls. In terms of concurrency and atomicity, these types of components may expect a higher level lock and scope isolation in order to protect access to any shared state. In contrast, application components leveraging the actor-model could take advantage of more restrictive isolation. In one embodiment, actors only communicate through state transition events and have no public methods. Actors themselves could encapsulate other lower level components that are not thread safe. Each actor exposes an API that allows tying entries stored in multiple storage service stores to the same cluster location, transaction, and unit of concurrency” [Selitser Col. 14 Lines 14-28].
and memory models, “While actor model fits nicely onto state that could be categorized as being part of a particular application session, there are many other types of state that an application must frequently manage. In various embodiments, the following are four types of state and their corresponding mapping onto the actor model: … c. Application Shared Session State-This state does not belong to any specific application session but is shared between several cooperating sessions. This in-between category becomes a shared actor that receives or produces state change notifications to communicate with other session-specific actors” [Selitser Col. 11 Lines 30-35, 49-54]. “In various embodiments, the application components can see two different abstractions depending on which layer of the programming model is being employed. Application components which are based on basic toolkit alone can communicate by pure method calls. In terms of concurrency and atomicity, these types of components may expect a higher level lock and scope isolation in order to protect access to any shared state. In contrast, application components leveraging the actor-model could take advantage of more restrictive isolation. In one embodiment, actors only communicate through state transition events and have no public methods. Actors themselves could encapsulate other lower level components that are not thread safe. Each actor exposes an API that allows tying entries stored in multiple storage service stores to the same cluster location, transaction, and unit of concurrency” [Selitser Col. 14 Lines 14-28].
and wherein the system supports the first and second frameworks, “In particular, the application server provides a programming model that is focused on protocol abstraction and protocol neutrality. This programming model is composed of two layers, namely a basic toolkit layer and a communicating sequential processes (CSP) adaptation layer” [Selitser Col. 3 Lines 4-9]. “The cooperation in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/O)” [Selitser Col. 8 Lines 5-8].
the method comprising: receiving, by the compatibility layer, a first message for a first component associated with the first framework; “All the protocol specific messages processed by the protocol adapters are abstracted as protocol events. Protocol events are subdivided into inbound ones to represent messages being received and outbound ones for messages being sent out” [Selitser Col. 6 Lines 61-65]. “For inbound protocol events the adapter can be responsible for buffering and assembling a complete message (first message) and delivering it to the event broker as an event. The application components are free to react to that event in any way they prefer” [Selitser Col. 13 Lines 6-10]. “Each protocol adapter implements input and output operations towards a specific protocol, such as SIP or HTTP” [Selitser Col. 12 Lines 50-52]. “A simple example is a monolithic TPC operation via HTTP request that decomposes into a series of fine grained SIP request/response messages. Breaking inbound and outbound messages into events decouples them and allows multiple consumers to react while satisfying a set of features” [Selitser Col. 6 Lines 38-43].
mapping, by the compatibility layer, the first message to a second message that provides a corresponding result for a second component associated with the second framework; “In step 404, an event broker is provided for managing communications between the protocol adapters (components) and the application component(s) (components). This event broker can map all protocol-specific communications exposed by the protocol adapters into asynchronous events, as shown in step 406” [Selitser Col. 12 Lines 55-60]. “Mapping protocol messages onto events allows efficient protocol abstraction and decoupling of interactions between different protocols” [Selitser Col. 6 Lines 34-36]. “While actor model fits nicely onto state that could be categorized as being part of a particular application session, there are many other types of state that an application must frequently manage. In various embodiments, the following are four types of state and their corresponding mapping onto the actor model” [Selitser Col. 11 Lines 30-35]. “As illustrated, the CSP Adaptation layer utilizes an actor-based model where the different actors 306, 314 communicate with each other by using asynchronous events issued via the event broker 304. In one embodiment, the "actor" is an entity that represents one or more application components” [Selitser Col. 9 Lines 32-36].
and sending, by the compatibility layer, the second message to the second component for processing by the second component, “The application components consume protocol-inbound asynchronous events from the protocol adapters which they receive via the event broker. Moreover, the application components also produce protocol-outbound asynchronous events to the protocol adapters by invoking the event broker APIs. On the other side of communication, the protocol adapters can also function as producers and consumers of events” [Selitser Col. 12 Lines 60-67]. “This event broker can map all protocol-specific communications exposed by the protocol adapters into asynchronous events, as shown in step 406. The application components consume protocol-inbound asynchronous events from the protocol adapters which they receive via the event broker” [Selitser Col. 12 Lines 57-62, Fig. 4]. “External protocol messages serve as the initiating events asynchronous with respect to the protocol sockets. Asynchronous behavior is triggered by new events produced as part of processing an event that preceded them. In this way, an event is the unit of asynchrony” [Selitser Col. 6 Lines 24-28].
wherein the compatibility layer synchronously returns actor threads “Application components 206, 208, 210 can serve as consumers of inbound protocol events and producers of outbound protocol events. Protocol adapters 212, 214, 216, 218 can serve as consumers of outbound protocol events and producers of inbound protocol events … These events can indicate any create, read, update and delete (CRUD) type manipulations to instances of state in the storage service. Application components can register for state transition events through the same event broker API 210. In one embodiment, state transition events are the only mechanism for application components to signal to each other. These types of events are transactional with respect to the original state manipulation that has triggered the event. Based on the behavior described above, the event broker 210 can segment its APIs towards specialized consumer and producer types” [Selitser Col. 7 Lines 4-8, 14-23, Fig. 2]. “This programming model is composed of two layers, namely a basic toolkit layer and a communicating sequential processes (CSP) adaptation layer” [Selitser Col. 3 Lines 6-9]. “CSP Adaptation is a higher level abstraction layered on top of the basic toolkit. The CSP adaptation represents simplifications and adaptations of the original basic model, while keeping the main principles in tact. More specifically, the CSP Adaptation layer utilizes an actor-based model, where each actor can group together one or more application components” [Selitser Col. 3 Lines 24-30]. “In various embodiments, state manipulation from the application components is done through synchronous invocations on the storage service. State manipulations can be transactional. Each event can be equated to a single transaction” [Selitser Col. 8 Lines 35-39]. “In certain embodiments, event races and events-out-of-sequence are possible when multiple events which are logically sequential are produced very close to each other in time. The simplification with the defined event types can be to decompose multiple state transition events into an explicit chain that only produces the next event when the logically earlier one has been consumed. The transactionality of state changes would guarantee that a state transition event is only produced when the state changes associated with the earlier event have been committed. Follow up events would thus be side effects of the events that preceded them” [Selitser Col. 8 Lines 24-34].
while asynchronously processing work “In order to achieve protocol abstraction, the basic toolkit employs an event-based model of communications. In this model, a set of protocol adapters is used in conjunction with an event broker. The event broker maps all protocol-specific communications exposed by the adapters into a set of asynchronous events” [Selitser Col. 3 Lines 11-16]. “In one embodiment, each event is processed asynchronously with respect to its producer. For example, a thread from a work manager pool (thread pool) can be allocated to an event for the duration of its lifetime. In this manner, the event broker can be a scheduler for all of the application components never start their own threads or schedule work explicitly. Additional asynchronous work is scheduled implicitly through creation of outbound protocol events and state transition events. The cooperation in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/0)” [Selitser Col. 7-8, Lines 63-67, 1-8].
and transfers memory ownership between the first and second frameworks, “For inbound protocol events the adapter can be responsible for buffering and assembling a complete message and delivering it to the event broker as an event. The application components are free to react to that event in any way they prefer. Errors during the assembly of inbound events are the responsibility of the sender and the adapter. In one embodiment, the application is never aware of these types of errors. In one embodiment, outbound protocol events always originate from the application components and are asynchronously handed off to the adapter through the event broker. From that point, the adapter is responsible for the delivery of the derived message to the end recipient. In the case of unsuccessful delivery, the application can be notified by a special type of protocol error event” [Selitser Col. 13 Lines 6-19 Examiner notes this description of memory ownership transfer is in accordance with the description given in paragraph 62 of the instant specification].
and the compatibility layer is exposed as an actor to the framework using the actor pattern and exposed as an asynchronous component to the framework using the event based asynchronous pattern, “The various application components executing on the application server can then consume protocol-inbound asynchronous events from the protocol adapters and produce protocol-outbound asynchronous events to the protocol adapters via the event broker” [Selitser Col. 3 Lines 17-21]. “In one embodiment, the event broker exposes a set of application programming interfaces (APIs) that represent a uniform event-based abstraction of all protocols used in the application server. This set of event-based APIs can be used for registration and propagation by event consumers and producers” [Selitser Col. 6 Lines 7-12].
thereby enabling the first and second frameworks to interoperate “The cooperation in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/O)” [Selitser Col. 8 Lines 5-8]. “In step 404, an event broker is provided for managing communications between the protocol adapters and the application component(s)” [Selitser Col. 12 Lines 55-57].
and enabling threading models of the first and second frameworks to be adhered to by the compatibility layer. “The contract exposed by the adapter container can be that of a dispatcher that could have multiple concurrency strategies configured for each event through the adapter. In one embodiment, two possible strategies are: (1) thread per event; and (2) thread per protocol specific session. In cases of session based scheduling, events that belong to the same session (as defined by the protocol adapter) can be queued up against that session for serial execution … The transactionality of state changes would guarantee that a state transition event is only produced when the state changes associated with the earlier event have been committed. Follow up events would thus be side effects of the events that preceded them” [Selitser Col. 8 Lines 15-23, 30-34].
With regard to claim 5, Selitser teaches:
The method of claim 1, as referenced above.
wherein the compatibility layer synchronously hands off messages to an asynchronous channel when an actor framework scheduler calls into the compatibility layer. “In various embodiments, state manipulation from the application components is done through synchronous invocations on the storage service. State manipulations can be transactional. Each event can be equated to a single transaction” [Selitser Col. 8 Lines 35-39]. “In this manner, the event broker can be a scheduler for all of the application environment code. In one embodiment, application components never start their own threads or schedule work explicitly” [Selitser Col. 7-8 Lines 66-67, 1-3]. “Additional asynchronous work is scheduled implicitly through creation of outbound protocol events and state transition events. The cooperation in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/O)” [Selitser Col. 8 Lines 3-8]. “In one embodiment, each actor is a single thread with respect to the events it processes. Actors can service logically different, buffered event channels or queues. The asynchronous composition of actors can also rely on making communication with the outside world (protocol adapters 302) completely asynchronous. These asynchronous protocol APIs are exposed as protocol events of the event broker 304. Thus, in one embodiment, state transition events are the only API or protocol between the actors themselves” [Selitser Col. 9 Lines 46-55].
With regard to claim 12, Selitser teaches:
The method of claim 1, as referenced above.
further comprising: determining whether a message from the first framework can be correlated as a response to a previously sent message; “Protocol layers often create protocol specific conversation boundaries by relying on correlation identifiers to define the scope of the conversation at each layer. The event's conversational scope, as well as the actual correlation identifiers, can be made available to the application components. Such conversational scope can be preserved in any follow-on outbound events that the application components decide to produce through special factories and constructors exposed by the adapter” [Selitser Col. 13 Lines 48-56]. “The transactionality of state changes would guarantee that a state transition event is only produced when the state changes associated with the earlier event have been committed. Follow up events would thus be side effects of the events that preceded them” [Selitser Col. 8 Lines 30-34].
and one of: converting the message to a response according to the second framework and sending the converted response to the second framework or converting the message to a request according to the second framework and sending the converted request to the second framework. “All the protocol specific messages processed by the protocol adapters are abstracted as protocol events. Protocol events are subdivided into inbound ones to represent messages being received and outbound ones for messages being sent out” [Selitser Col. 6 Lines 61-65]. “The event broker maps all protocol-specific communications exposed by the adapters into a set of asynchronous events. The various application components executing on the application server can then consume protocol-inbound asynchronous events from the protocol adapters and produce protocol-outbound asynchronous events to the protocol adapters via the event broker” [Selitser Col. 3 Lines 12-21].
With regard to claim 13, Selitser teaches:
The method of claim 1, as referenced above.
further comprising using specific per-request channels to track where to send asynchronous responses to requests from the framework using the event based asynchronous pattern “In one embodiment, each actor is a single thread with respect to the events it processes. Actors can service logically different, buffered event channels or queues. The asynchronous composition of actors can also rely on making communication (responses) with the outside world (protocol adapters 302) completely asynchronous. These asynchronous protocol APIs are exposed as protocol events of the event broker 304” [Selitser Col. 9 Lines 46-53].
and a per-framework channel to track sending requests to the framework using the event based asynchronous pattern. “The contract exposed by the adapter container can be that of a dispatcher that could have multiple concurrency strategies configured for each event through the adapter. In one embodiment, two possible strategies are: (1) thread per event; and (2) thread per protocol specific session (per-framework channel). In cases of session based scheduling, events that belong to the same session (as defined by the protocol adapter) can be queued up against that session for serial execution” [Selitser Col. 8 Lines 15-23]. “Most types of applications deployed in the application server will likely have an associated session that has some duration and keeps state needed to conduct conversations relevant to that application” [Selitser Col. 14 Lines 35-38].
With regard to claim 17, Selitser teaches:
A computing system comprising: a processing system comprising a processor; and computer-readable media having thereon computer-executable instructions that are structured such that, when executed by the processing system, cause the computing system to perform operations comprising: “A non-transitory computer-readable storage medium carrying one or more sequences of instructions for providing a protocol-neutral application server, which instructions, when executed by one or more microprocessors, cause the one or more microprocessors to carry out the steps of:” [Selitser Claim 20].
executing a compatibility layer configured to enable interoperation between a first framework and a second framework, “In particular, the application server provides a programming model that is focused on protocol (framework) abstraction and protocol neutrality. This programming model is composed of two layers, namely a basic toolkit layer and a communicating sequential processes (CSP) adaptation layer … In the various embodiments, the CSP adaptation is the ideal target layer in which most applications will be implemented, while the basic toolkit is the model for the remaining few highly specific cases. Since the basic toolkit model is defined as a lower layer of primitives, it can be viewed as implementing the CSP adaptation” [Selitser Col. 3 Lines 4-9, 43-48]. “FIG. 3 is an illustration of the CSP Adaptation layer of the programming model employed by the application server, in accordance with various embodiments of the invention … As illustrated, the CSP Adaptation layer utilizes an actor-based model (framework) where the different actors 306, 314 communicate with each other by using asynchronous events issued via the event broker 304 (compatibility layer). In one embodiment, the "actor" is an entity that represents one or more application components” [Selitser Col. 9 Lines 19-21, 32-36, Fig. 3]. “The cooperation (interoperation) in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/O)” [Selitser Col. 8 Lines 5-8]. “In step 404, an event broker is provided for managing communications between the protocol adapters and the application component(s)” [Selitser Col. 12 Lines 55-57].
wherein a first one of the first or second frameworks uses an actor pattern “In particular, the application server provides a programming model that is focused on protocol abstraction and protocol neutrality. This programming model is composed of two layers, namely a basic toolkit layer and a communicating sequential processes (CSP) adaptation layer” [Selitser Col. 3 Lines 4-9]. “CSP Adaptation is a higher level abstraction layered on top of the basic toolkit. The CSP adaptation represents simplifications and adaptations of the original basic model, while keeping the main principles in tact. More specifically, the CSP Adaptation layer utilizes an actor-based model, where each actor can group together one or more application components” [Selitser Col. 3 Lines 24-30]. “In various embodiments, actors are special classes that are involved in message passing between each other. In one embodiment, each actor is the owner of its own segment of state, which is only accessible to that actor. Other actors interested in updating that state would send asynchronous events to the owning actor, with the implicit intention that the owning actor will react to those events” [Selitser Col. 3 Lines 30-36].
and a second one of the first or second frameworks uses an event based asynchronous pattern; “In order to achieve protocol abstraction, the basic toolkit employs an event-based model of communications. In this model, a set of protocol adapters is used in conjunction with an event broker. The event broker maps all protocol-specific communications exposed by the adapters into a set of asynchronous events. The various application components executing on the application server can then consume protocol-inbound asynchronous events from the protocol adapters and produce protocol-outbound asynchronous events to the protocol adapters via the event broker” [Selitser Col. 3 Lines 11-21].
and the frameworks have different concurrency “In the context of concurrency, the single-threaded nature of actors can ensure simple, lock-free execution within a single process. In one embodiment, cluster-wide primary election ensures a globally unique actor identity to which all relevant events are directed” [Selitser Col. 11 Lines 22-26]. “In various embodiments, the application components can see two different abstractions depending on which layer of the programming model is being employed. Application components which are based on basic toolkit alone can communicate by pure method calls. In terms of concurrency and atomicity, these types of components may expect a higher level lock and scope isolation in order to protect access to any shared state. In contrast, application components leveraging the actor-model could take advantage of more restrictive isolation. In one embodiment, actors only communicate through state transition events and have no public methods. Actors themselves could encapsulate other lower level components that are not thread safe. Each actor exposes an API that allows tying entries stored in multiple storage service stores to the same cluster location, transaction, and unit of concurrency” [Selitser Col. 14 Lines 14-28].
and memory models; “While actor model fits nicely onto state that could be categorized as being part of a particular application session, there are many other types of state that an application must frequently manage. In various embodiments, the following are four types of state and their corresponding mapping onto the actor model: … c. Application Shared Session State-This state does not belong to any specific application session but is shared between several cooperating sessions. This in-between category becomes a shared actor that receives or produces state change notifications to communicate with other session-specific actors” [Selitser Col. 11 Lines 30-35, 49-54]. “In various embodiments, the application components can see two different abstractions depending on which layer of the programming model is being employed. Application components which are based on basic toolkit alone can communicate by pure method calls. In terms of concurrency and atomicity, these types of components may expect a higher level lock and scope isolation in order to protect access to any shared state. In contrast, application components leveraging the actor-model could take advantage of more restrictive isolation. In one embodiment, actors only communicate through state transition events and have no public methods. Actors themselves could encapsulate other lower level components that are not thread safe. Each actor exposes an API that allows tying entries stored in multiple storage service stores to the same cluster location, transaction, and unit of concurrency” [Selitser Col. 14 Lines 14-28].
receiving, by the compatibility layer, a first message for a first process component associated with the first framework; “All the protocol specific messages processed by the protocol adapters are abstracted as protocol events. Protocol events are subdivided into inbound ones to represent messages being received and outbound ones for messages being sent out” [Selitser Col. 6 Lines 61-65]. “For inbound protocol events the adapter can be responsible for buffering and assembling a complete message (first message) and delivering it to the event broker as an event. The application components are free to react to that event in any way they prefer” [Selitser Col. 13 Lines 6-10]. “Each protocol adapter implements input and output operations towards a specific protocol, such as SIP or HTTP” [Selitser Col. 12 Lines 50-52]. “A simple example is a monolithic TPC operation via HTTP request that decomposes into a series of fine grained SIP request/response messages. Breaking inbound and outbound messages into events decouples them and allows multiple consumers to react while satisfying a set of features” [Selitser Col. 6 Lines 38-43].
mapping, by the compatibility layer, the first message to a second message that provides a corresponding result for a second component associated with the second framework; “In step 404, an event broker is provided for managing communications between the protocol adapters (components) and the application component(s) (components). This event broker can map all protocol-specific communications exposed by the protocol adapters into asynchronous events, as shown in step 406” [Selitser Col. 12 Lines 55-60]. “Mapping protocol messages onto events allows efficient protocol abstraction and decoupling of interactions between different protocols” [Selitser Col. 6 Lines 34-36]. “While actor model fits nicely onto state that could be categorized as being part of a particular application session, there are many other types of state that an application must frequently manage. In various embodiments, the following are four types of state and their corresponding mapping onto the actor model” [Selitser Col. 11 Lines 30-35]. “As illustrated, the CSP Adaptation layer utilizes an actor-based model where the different actors 306, 314 communicate with each other by using asynchronous events issued via the event broker 304. In one embodiment, the "actor" is an entity that represents one or more application components” [Selitser Col. 9 Lines 32-36].
and sending, by the compatibility layer, the second message to the second component for processing by the second component; “The application components consume protocol-inbound asynchronous events from the protocol adapters which they receive via the event broker. Moreover, the application components also produce protocol-outbound asynchronous events to the protocol adapters by invoking the event broker APIs. On the other side of communication, the protocol adapters can also function as producers and consumers of events” [Selitser Col. 12 Lines 60-67]. “The event broker maps all protocol-specific communications exposed by the protocol adapters into asynchronous events The application component consumes protocol-inbound asynchronous events from the protocol adapters …” [Selitser Fig. 4]. “External protocol messages serve as the initiating events asynchronous with respect to the protocol sockets. Asynchronous behavior is triggered by new events produced as part of processing an event that preceded them. In this way, an event is the unit of asynchrony” [Selitser Col. 6 Lines 24-28].
wherein the compatibility layer synchronously returns actor threads “Application components 206, 208, 210 can serve as consumers of inbound protocol events and producers of outbound protocol events. Protocol adapters 212, 214, 216, 218 can serve as consumers of outbound protocol events and producers of inbound protocol events … These events can indicate any create, read, update and delete (CRUD) type manipulations to instances of state in the storage service. Application components can register for state transition events through the same event broker API 210. In one embodiment, state transition events are the only mechanism for application components to signal to each other. These types of events are transactional with respect to the original state manipulation that has triggered the event. Based on the behavior described above, the event broker 210 can segment its APIs towards specialized consumer and producer types” [Selitser Col. 7 Lines 4-8, 14-23, Fig. 2]. “This programming model is composed of two layers, namely a basic toolkit layer and a communicating sequential processes (CSP) adaptation layer” [Selitser Col. 3 Lines 6-9]. “CSP Adaptation is a higher level abstraction layered on top of the basic toolkit. The CSP adaptation represents simplifications and adaptations of the original basic model, while keeping the main principles in tact. More specifically, the CSP Adaptation layer utilizes an actor-based model, where each actor can group together one or more application components” [Selitser Col. 3 Lines 24-30]. “In various embodiments, state manipulation from the application components is done through synchronous invocations on the storage service. State manipulations can be transactional. Each event can be equated to a single transaction” [Selitser Col. 8 Lines 35-39]. “In certain embodiments, event races and events-out-of-sequence are possible when multiple events which are logically sequential are produced very close to each other in time. The simplification with the defined event types can be to decompose multiple state transition events into an explicit chain that only produces the next event when the logically earlier one has been consumed. The transactionality of state changes would guarantee that a state transition event is only produced when the state changes associated with the earlier event have been committed. Follow up events would thus be side effects of the events that preceded them” [Selitser Col. 8 Lines 24-34].
while asynchronously processing work “In order to achieve protocol abstraction, the basic toolkit employs an event-based model of communications. In this model, a set of protocol adapters is used in conjunction with an event broker. The event broker maps all protocol-specific communications exposed by the adapters into a set of asynchronous events” [Selitser Col. 3 Lines 11-16]. “In one embodiment, each event is processed asynchronously with respect to its producer. For example, a thread from a work manager pool (thread pool) can be allocated to an event for the duration of its lifetime. In this manner, the event broker can be a scheduler for all of the application components never start their own threads or schedule work explicitly. Additional asynchronous work is scheduled implicitly through creation of outbound protocol events and state transition events. The cooperation in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/0)” [Selitser Col. 7-8, Lines 63-67, 1-8].
and transfers memory ownership between the first and second frameworks, “For inbound protocol events the adapter can be responsible for buffering and assembling a complete message and delivering it to the event broker as an event. The application components are free to react to that event in any way they prefer. Errors during the assembly of inbound events are the responsibility of the sender and the adapter. In one embodiment, the application is never aware of these types of errors. In one embodiment, outbound protocol events always originate from the application components and are asynchronously handed off to the adapter through the event broker. From that point, the adapter is responsible for the delivery of the derived message to the end recipient. In the case of unsuccessful delivery, the application can be notified by a special type of protocol error event” [Selitser Col. 13 Lines 6-19 Examiner notes this description of memory ownership transfer is in accordance with the description given in paragraph 62 of the instant specification].
and the compatibility layer is exposed as an actor to the framework using the actor pattern and exposed as an asynchronous component to the framework using the event based asynchronous pattern, “The various application components executing on the application server can then consume protocol-inbound asynchronous events from the protocol adapters and produce protocol-outbound asynchronous events to the protocol adapters via the event broker” [Selitser Col. 3 Lines 17-21]. “In one embodiment, the event broker exposes a set of application programming interfaces (APIs) that represent a uniform event-based abstraction of all protocols used in the application server. This set of event-based APIs can be used for registration and propagation by event consumers and producers” [Selitser Col. 6 Lines 7-12].
thereby enabling the first and second frameworks to interoperate “The cooperation in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/O)” [Selitser Col. 8 Lines 5-8]. “In step 404, an event broker is provided for managing communications between the protocol adapters and the application component(s)” [Selitser Col. 12 Lines 55-57].
and enabling threading models of the first and second frameworks to be adhered to by the compatibility layer. “The contract exposed by the adapter container can be that of a dispatcher that could have multiple concurrency strategies configured for each event through the adapter. In one embodiment, two possible strategies are: (1) thread per event; and (2) thread per protocol specific session. In cases of session based scheduling, events that belong to the same session (as defined by the protocol adapter) can be queued up against that session for serial execution … The transactionality of state changes would guarantee that a state transition event is only produced when the state changes associated with the earlier event have been committed. Follow up events would thus be side effects of the events that preceded them” [Selitser Col. 8 Lines 15-23, 30-34].
With regard to claim 19, Selitser teaches:
The computing system of claim 17, as referenced above.
wherein the compatibility layer enables the first and second frameworks to interoperate without modifying the first and second frameworks to enable the interoperation. “The cooperation in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/O)” [Selitser Col. 8 Lines 5-8].
With regard to claim 20, Selitser teaches:
A computer-readable storage medium having thereon computer-executable instructions that are structured such that, when executed by a processing system of a computing system, cause the computing system to perform operations comprising: “A non-transitory computer-readable storage medium carrying one or more sequences of instructions for providing a protocol-neutral application server, which instructions, when executed by one or more microprocessors, cause the one or more microprocessors to carry out the steps of:” [Selitser Claim 20].
executing a compatibility layer configured to enable interoperation between a first framework and a second framework, “In particular, the application server provides a programming model that is focused on protocol (framework) abstraction and protocol neutrality. This programming model is composed of two layers, namely a basic toolkit layer and a communicating sequential processes (CSP) adaptation layer … In the various embodiments, the CSP adaptation is the ideal target layer in which most applications will be implemented, while the basic toolkit is the model for the remaining few highly specific cases. Since the basic toolkit model is defined as a lower layer of primitives, it can be viewed as implementing the CSP adaptation” [Selitser Col. 3 Lines 4-9, 43-48]. “FIG. 3 is an illustration of the CSP Adaptation layer of the programming model employed by the application server, in accordance with various embodiments of the invention … As illustrated, the CSP Adaptation layer utilizes an actor-based model (framework) where the different actors 306, 314 communicate with each other by using asynchronous events issued via the event broker 304 (compatibility layer). In one embodiment, the "actor" is an entity that represents one or more application components” [Selitser Col. 9 Lines 19-21, 32-36, Fig. 3]. “The cooperation (interoperation) in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/O)” [Selitser Col. 8 Lines 5-8]. “In step 404, an event broker is provided for managing communications between the protocol adapters and the application component(s)” [Selitser Col. 12 Lines 55-57].
wherein a first one of the first or second frameworks uses an actor pattern “In particular, the application server provides a programming model that is focused on protocol abstraction and protocol neutrality. This programming model is composed of two layers, namely a basic toolkit layer and a communicating sequential processes (CSP) adaptation layer” [Selitser Col. 3 Lines 4-9]. “CSP Adaptation is a higher level abstraction layered on top of the basic toolkit. The CSP adaptation represents simplifications and adaptations of the original basic model, while keeping the main principles in tact. More specifically, the CSP Adaptation layer utilizes an actor-based model, where each actor can group together one or more application components” [Selitser Col. 3 Lines 24-30]. “In various embodiments, actors are special classes that are involved in message passing between each other. In one embodiment, each actor is the owner of its own segment of state, which is only accessible to that actor. Other actors interested in updating that state would send asynchronous events to the owning actor, with the implicit intention that the owning actor will react to those events” [Selitser Col. 3 Lines 30-36].
and a second one of the first or second frameworks uses an event based asynchronous pattern; “In order to achieve protocol abstraction, the basic toolkit employs an event-based model of communications. In this model, a set of protocol adapters is used in conjunction with an event broker. The event broker maps all protocol-specific communications exposed by the adapters into a set of asynchronous events. The various application components executing on the application server can then consume protocol-inbound asynchronous events from the protocol adapters and produce protocol-outbound asynchronous events to the protocol adapters via the event broker” [Selitser Col. 3 Lines 11-21].
and the frameworks have different concurrency “In the context of concurrency, the single-threaded nature of actors can ensure simple, lock-free execution within a single process. In one embodiment, cluster-wide primary election ensures a globally unique actor identity to which all relevant events are directed” [Selitser Col. 11 Lines 22-26]. “In various embodiments, the application components can see two different abstractions depending on which layer of the programming model is being employed. Application components which are based on basic toolkit alone can communicate by pure method calls. In terms of concurrency and atomicity, these types of components may expect a higher level lock and scope isolation in order to protect access to any shared state. In contrast, application components leveraging the actor-model could take advantage of more restrictive isolation. In one embodiment, actors only communicate through state transition events and have no public methods. Actors themselves could encapsulate other lower level components that are not thread safe. Each actor exposes an API that allows tying entries stored in multiple storage service stores to the same cluster location, transaction, and unit of concurrency” [Selitser Col. 14 Lines 14-28].
and memory models; “While actor model fits nicely onto state that could be categorized as being part of a particular application session, there are many other types of state that an application must frequently manage. In various embodiments, the following are four types of state and their corresponding mapping onto the actor model: … c. Application Shared Session State-This state does not belong to any specific application session but is shared between several cooperating sessions. This in-between category becomes a shared actor that receives or produces state change notifications to communicate with other session-specific actors” [Selitser Col. 11 Lines 30-35, 49-54]. “In various embodiments, the application components can see two different abstractions depending on which layer of the programming model is being employed. Application components which are based on basic toolkit alone can communicate by pure method calls. In terms of concurrency and atomicity, these types of components may expect a higher level lock and scope isolation in order to protect access to any shared state. In contrast, application components leveraging the actor-model could take advantage of more restrictive isolation. In one embodiment, actors only communicate through state transition events and have no public methods. Actors themselves could encapsulate other lower level components that are not thread safe. Each actor exposes an API that allows tying entries stored in multiple storage service stores to the same cluster location, transaction, and unit of concurrency” [Selitser Col. 14 Lines 14-28].
receiving, by the compatibility layer, a first message for a first process component with a first framework; “All the protocol specific messages processed by the protocol adapters are abstracted as protocol events. Protocol events are subdivided into inbound ones to represent messages being received and outbound ones for messages being sent out” [Selitser Col. 6 Lines 61-65]. “For inbound protocol events the adapter can be responsible for buffering and assembling a complete message (first message) and delivering it to the event broker as an event. The application components are free to react to that event in any way they prefer” [Selitser Col. 13 Lines 6-10]. “Each protocol adapter implements input and output operations towards a specific protocol, such as SIP or HTTP” [Selitser Col. 12 Lines 50-52]. “A simple example is a monolithic TPC operation via HTTP request that decomposes into a series of fine grained SIP request/response messages. Breaking inbound and outbound messages into events decouples them and allows multiple consumers to react while satisfying a set of features” [Selitser Col. 6 Lines 38-43].
mapping, by the compatibility layer, the first message to a second message that provides a corresponding result for a second component associated with a second framework; “In step 404, an event broker is provided for managing communications between the protocol adapters (components) and the application component(s) (components). This event broker can map all protocol-specific communications exposed by the protocol adapters into asynchronous events, as shown in step 406” [Selitser Col. 12 Lines 55-60]. “Mapping protocol messages onto events allows efficient protocol abstraction and decoupling of interactions between different protocols” [Selitser Col. 6 Lines 34-36]. “While actor model fits nicely onto state that could be categorized as being part of a particular application session, there are many other types of state that an application must frequently manage. In various embodiments, the following are four types of state and their corresponding mapping onto the actor model” [Selitser Col. 11 Lines 30-35]. “As illustrated, the CSP Adaptation layer utilizes an actor-based model where the different actors 306, 314 communicate with each other by using asynchronous events issued via the event broker 304. In one embodiment, the "actor" is an entity that represents one or more application components” [Selitser Col. 9 Lines 32-36].
and sending, by the compatibility layer, the second message to the second component for processing by the second component; “The application components consume protocol-inbound asynchronous events from the protocol adapters which they receive via the event broker. Moreover, the application components also produce protocol-outbound asynchronous events to the protocol adapters by invoking the event broker APIs. On the other side of communication, the protocol adapters can also function as producers and consumers of events” [Selitser Col. 12 Lines 60-67]. “The event broker maps all protocol-specific communications exposed by the protocol adapters into asynchronous events The application component consumes protocol-inbound asynchronous events from the protocol adapters …” [Selitser Fig. 4]. “External protocol messages serve as the initiating events asynchronous with respect to the protocol sockets. Asynchronous behavior is triggered by new events produced as part of processing an event that preceded them. In this way, an event is the unit of asynchrony” [Selitser Col. 6 Lines 24-28].
wherein the compatibility layer synchronously returns actor threads “Application components 206, 208, 210 can serve as consumers of inbound protocol events and producers of outbound protocol events. Protocol adapters 212, 214, 216, 218 can serve as consumers of outbound protocol events and producers of inbound protocol events … These events can indicate any create, read, update and delete (CRUD) type manipulations to instances of state in the storage service. Application components can register for state transition events through the same event broker API 210. In one embodiment, state transition events are the only mechanism for application components to signal to each other. These types of events are transactional with respect to the original state manipulation that has triggered the event. Based on the behavior described above, the event broker 210 can segment its APIs towards specialized consumer and producer types” [Selitser Col. 7 Lines 4-8, 14-23, Fig. 2]. “This programming model is composed of two layers, namely a basic toolkit layer and a communicating sequential processes (CSP) adaptation layer” [Selitser Col. 3 Lines 6-9]. “CSP Adaptation is a higher level abstraction layered on top of the basic toolkit. The CSP adaptation represents simplifications and adaptations of the original basic model, while keeping the main principles in tact. More specifically, the CSP Adaptation layer utilizes an actor-based model, where each actor can group together one or more application components” [Selitser Col. 3 Lines 24-30]. “In various embodiments, state manipulation from the application components is done through synchronous invocations on the storage service. State manipulations can be transactional. Each event can be equated to a single transaction” [Selitser Col. 8 Lines 35-39]. “In certain embodiments, event races and events-out-of-sequence are possible when multiple events which are logically sequential are produced very close to each other in time. The simplification with the defined event types can be to decompose multiple state transition events into an explicit chain that only produces the next event when the logically earlier one has been consumed. The transactionality of state changes would guarantee that a state transition event is only produced when the state changes associated with the earlier event have been committed. Follow up events would thus be side effects of the events that preceded them” [Selitser Col. 8 Lines 24-34].
while asynchronously processing work “In order to achieve protocol abstraction, the basic toolkit employs an event-based model of communications. In this model, a set of protocol adapters is used in conjunction with an event broker. The event broker maps all protocol-specific communications exposed by the adapters into a set of asynchronous events” [Selitser Col. 3 Lines 11-16]. “In one embodiment, each event is processed asynchronously with respect to its producer. For example, a thread from a work manager pool (thread pool) can be allocated to an event for the duration of its lifetime. In this manner, the event broker can be a scheduler for all of the application components never start their own threads or schedule work explicitly. Additional asynchronous work is scheduled implicitly through creation of outbound protocol events and state transition events. The cooperation in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/0)” [Selitser Col. 7-8, Lines 63-67, 1-8].
and transfers memory ownership between the first and second frameworks, “For inbound protocol events the adapter can be responsible for buffering and assembling a complete message and delivering it to the event broker as an event. The application components are free to react to that event in any way they prefer. Errors during the assembly of inbound events are the responsibility of the sender and the adapter. In one embodiment, the application is never aware of these types of errors. In one embodiment, outbound protocol events always originate from the application components and are asynchronously handed off to the adapter through the event broker. From that point, the adapter is responsible for the delivery of the derived message to the end recipient. In the case of unsuccessful delivery, the application can be notified by a special type of protocol error event” [Selitser Col. 13 Lines 6-19 Examiner notes this description of memory ownership transfer is in accordance with the description given in paragraph 62 of the instant specification].
and the compatibility layer is exposed as an actor to the framework using the actor pattern and exposed as an asynchronous component to the framework using the event based asynchronous pattern, “The various application components executing on the application server can then consume protocol-inbound asynchronous events from the protocol adapters and produce protocol-outbound asynchronous events to the protocol adapters via the event broker” [Selitser Col. 3 Lines 17-21]. “In one embodiment, the event broker exposes a set of application programming interfaces (APIs) that represent a uniform event-based abstraction of all protocols used in the application server. This set of event-based APIs can be used for registration and propagation by event consumers and producers” [Selitser Col. 6 Lines 7-12].
thereby enabling the first and second frameworks to interoperate “The cooperation in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/O)” [Selitser Col. 8 Lines 5-8]. “In step 404, an event broker is provided for managing communications between the protocol adapters and the application component(s)” [Selitser Col. 12 Lines 55-57].
and enabling threading models of the first and second frameworks to be adhered to by the compatibility layer. “The contract exposed by the adapter container can be that of a dispatcher that could have multiple concurrency strategies configured for each event through the adapter. In one embodiment, two possible strategies are: (1) thread per event; and (2) thread per protocol specific session. In cases of session based scheduling, events that belong to the same session (as defined by the protocol adapter) can be queued up against that session for serial execution … The transactionality of state changes would guarantee that a state transition event is only produced when the state changes associated with the earlier event have been committed. Follow up events would thus be side effects of the events that preceded them” [Selitser Col. 8 Lines 15-23, 30-34].
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, 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 2 is rejected under 35 U.S.C. 103 as being unpatentable over Selitser (US 8,719,780 B2) in view of Allen (US 2019/0384695 A1).
With regard to claim 2, Selitser teaches the method of claim 1, as referenced above. Selitser further teaches and mapping the response to the second message to a response to the first message from the first component. “The event broker maps all protocol-specific communications exposed by the protocol adapters into asynchronous events The application component consumes protocol-inbound asynchronous events from the protocol adapters and produces protocol-outbound asynchronous events to the protocol adapters” [Selitser Fig. 4]. “The application components consume protocol-inbound asynchronous events from the protocol adapters which they receive via the event broker. Moreover, the application components also produce protocol-outbound asynchronous events to the protocol adapters by invoking the event broker APIs. On the other side of communication, the protocol adapters can also function as producers and consumers of events” [Selitser Col. 12 Lines 60-67].
Selitser teaches chaining events to operate in order such that each event is produced after the earlier event: “The simplification with the defined event types can be to decompose multiple state transition events into an explicit chain that only produces the next event when the logically earlier one has been consumed” [Selitser Col. 8 Lines 27-30]. Selitser fails to explicitly teach waiting for a response to the second message from the second component. However, Allen teaches further comprising waiting for a response to the second message from the second component “If, in Step 308, it is determined that the next operation is synchronized with another operation assigned to another actor pair, then Step 312 below is performed. In one or more embodiments, the next operation is synchronized with another operation assigned to another actor pair (e.g., where the other operation is performed by the receiver of the other actor pair): when the next operation waits for the result of the other operation” [Allen ¶ 50].
Allen is considered to be analogous to the claimed invention because it is in the same field of message passing systems. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Selitser to incorporate the teachings of Allen and include: waiting for a response to the second message from the second component. Doing so would allow for sequential operations to receive response data before continuing. “For example, the next operation is synchronized with another operation when the next operation is a "receive message" operation that corresponds to a "send message" operation assigned to another actor pair” [Allen ¶ 50].
Claims 3 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Selitser (US 8,719,780 B2) in view of Walker (US 2018/0060256 A1).
With regard to claim 3, Selitser teaches the method of claim 1, as referenced above. Selitser further teaches wherein structures from the first framework are stored in a part of memory associated with the second framework, “In one embodiment, a storage service 142 defines an abstraction for all state management in all stack layers. The performance and querying, as well as the atomicity, consistency, isolation and durability (ACID) properties are configured behind this general abstraction. In one embodiment, the storage service represents a partitioned in-memory database” [Selitser Col. 4 Lines 50-55]. “As previously described, state management is performed via a partitioned, in-memory database. It is in the context of such database that the terms Collocation, Transaction and Concurrency are defined. In one embodiment, actor abstraction is useful if it is always collocated with the primary partition where all of the state it owns is being served. In these embodiments, all state belonging to an Actor (associated with the second framework) therefore must and is guaranteed to be collocated even if it is spread between multiple data types and structures. This can be done through a customized partitioning scheme where data belonging to the same actor is assigned to the same partition, which implies the same physical machine” [Selitser Col. 10 Lines 46-57]. “Each actor exposes an API that allows tying entries stored in multiple storage service stores to the same cluster location, transaction, and unit of concurrency” [Selitser Col. 14 Lines 26-28].
Selitser fails to explicitly teach further comprising using the structures to access shared state across multiple threads.
However, Walker teaches further comprising using the structures to access shared state across multiple threads. “The shared state includes information stored on the storage device that multiple threads of execution access as a result of using the filesystem” [Walker ¶ 57].
Walker is considered to be analogous to the claimed invention because it is in the same field of memory sharing. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Selitser to incorporate the teachings of Walker and include: using the structures to access shared state across multiple threads. Doing so would allow for updating of shared state from different threads. “For example, an application uses the shared state channel 507 for operations that modify shared state, and the non-shared state channels 508A-508C for operations that do not modify shared state” [Walker ¶ 57].
With regard to claim 18, Selitser teaches:
The computing system of claim 17, as referenced above.
wherein structures from the first framework are stored in a part of memory associated with the second framework, “In one embodiment, a storage service 142 defines an abstraction for all state management in all stack layers. The performance and querying, as well as the atomicity, consistency, isolation and durability (ACID) properties are configured behind this general abstraction. In one embodiment, the storage service represents a partitioned in-memory database” [Selitser Col. 4 Lines 50-55]. “As previously described, state management is performed via a partitioned, in-memory database. It is in the context of such database that the terms Collocation, Transaction and Concurrency are defined. In one embodiment, actor abstraction is useful if it is always collocated with the primary partition where all of the state it owns is being served. In these embodiments, all state belonging to an Actor (associated with the second framework) therefore must and is guaranteed to be collocated even if it is spread between multiple data types and structures. This can be done through a customized partitioning scheme where data belonging to the same actor is assigned to the same partition, which implies the same physical machine” [Selitser Col. 10 Lines 46-57]. “Each actor exposes an API that allows tying entries stored in multiple storage service stores to the same cluster location, transaction, and unit of concurrency” [Selitser Col. 14 Lines 26-28].
Selitser fails to explicitly teach further comprising using the structures to access shared state across multiple threads.
However, Walker teaches further comprising using the structures to access shared state across multiple threads. “The shared state includes information stored on the storage device that multiple threads of execution access as a result of using the filesystem” [Walker ¶ 57].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Selitser to incorporate the teachings of Walker and include: using the structures to access shared state across multiple threads. Doing so would allow for updating of shared state from different threads. “For example, an application uses the shared state channel 507 for operations that modify shared state, and the non-shared state channels 508A-508C for operations that do not modify shared state” [Walker ¶ 57].
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Selitser (US 8,719,780 B2) in view of Tuck (US 2007/0294681 A1).
With regard to claim 4, Selitser teaches the method of claim 1, as referenced above. Selitser fails to explicitly teach wherein unknown structures are dynamically cast to specifically typed structures based on a field in the message.
However, Tuck teaches wherein unknown structures are dynamically cast to specifically typed structures based on a field in the message. “If the LSI 100 operates on its own data types, native data types (unknown structures) in the application 20 may be explicitly converted to the LSI's own data types (e.g., using a function that takes an operand (field) using a native data type and returns an object of the corresponding LSI data type)” [Tuck ¶ 42].
Tuck is considered to be analogous to the claimed invention because it is in the same field of message passing systems. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Selitser to incorporate the teachings of Tuck and include: wherein unknown structures are dynamically cast to specifically typed structures based on a field in the message. Doing so would allow for operations on structures of familiar types. “In some embodiments, the use of the LSI's own data types has several advantages over native data types. First, it facilitates the use of data representations in the FE 200 that are different from the native representations of data in the programming language” [Tuck ¶ 43].
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Selitser (US 8,719,780 B2) in view of Kumpera (US 9,032,410 B1).
With regard to claim 6, Selitser teaches the method of claim 1, as referenced above. Selitser further teaches objects that the second framework has transferred ownership of to the first framework. “Due to these characteristics, actors do not need to issue explicit global locks on the state that they access, since they are the sole owners of that state” [Col. 3 Lines 39-42]. “In one embodiment, each actor is the owner of its own segment of state, which is only accessible to that actor” [Selitser Col. 3 Lines 31-33]. “The storage service previously described can be a producer of state transition events. These events can indicate any create, read, update and delete (CRUD) type manipulations to instances of state in the storage service” [Selitser Col. 7 Lines 12-15].
Selitser fails to explicitly teach wherein the second framework is instructed not to free memory of any objects that the second framework has transferred ownership of to the first framework.
However, Kumpera teaches wherein the second framework is instructed not to free memory of any objects that the second framework has transferred ownership of to the first framework. “However, in some cases, if the native code call is determined by the managed runtime to have the ability/possibility to interact with managed memory objects the thread update the thread state information to prevent garbage collection actions from proceeding” [Kumpera Col. 18 Lines 9-13].
Kumpera is considered to be analogous to the claimed invention because it is in the same field of message passing systems. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Selitser to incorporate the teachings of Kumpera and include: wherein the second framework is instructed not to free memory of any objects that the second framework has transferred ownership of to the first framework. Doing so would allow for further thread safety. “The state of Unsafe Managed indicates the thread is executing in the manage code environment but it is unsafe because it is still running” [Kumpera Col. 16 Lines 21-23].
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Selitser (US 8,719,780 B2) in view of Cohen (US 2010/0077155 A1) in view of DASH (US 2023/0297426 A1).
With regard to claim 7, Selitser teaches the method of claim 1, as referenced above.
Selitser further teaches and the compatibility layer takes ownership of the messages and ensures that the messages are either (controlled) freed by the second framework or passed back to the first framework. “Additionally, there can be several event consumer and producer types. Application components 206, 208, 210 can serve as consumers of inbound protocol events and producers of outbound protocol events. Protocol adapters 212, 214, 216, 218 can serve as consumers of outbound protocol events and producers of inbound protocol events … In one embodiment, the event defined by the event broker 210 is a protocol-neutral shared contract between consumers and producers” [Selitser Col. 7 Lines 3-8, 26-28]. “In various embodiments, actors are special classes that are involved in message passing between each other. In one embodiment, each actor is the owner of its own segment of state, which is only accessible to that actor. Other actors interested in updating that state would send asynchronous events to the owning actor, with the implicit intention that the owning actor will react to those events” [Selitser Col. 3 Lines 30-36].
While Selitser teaches messages sent by the first framework [Selitser Col. 6], it does not explicitly teach when messages are sent by the first framework, the first framework does not drop the messages.
However, Cohen teaches further comprising when messages are sent by the first framework, the first framework does not drop the messages “If a portion of the memory has not been marked as shared, it can be processed by the operating system, including clean-up and optimization processes. If, however, a portion of memory has been marked as shared memory, one or more memory management functions, such as the optimization process, can be suspended for that portion (212)” [Cohen ¶ 19].
Cohen is considered to be analogous to the claimed invention because it is in the same field of memory sharing. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Selitser to incorporate the teachings of Cohen and include: when messages are sent by the first framework, the first framework does not drop the messages. Doing so would allow for the protection of shared memory. “The operating system protects the shared memory to prevent any inadvertent relocation or destruction of data during memory management (206)” [Cohen ¶ 19].
Selitser in view of Cohen fails to explicitly teach the messages are either freed by the second framework or passed back to the first framework.
However, DASH teaches the messages are either freed by the second framework or passed back to the first framework. “Both the exiting threads and the suspended threads release their resources, such as registers, shared memory, and/or the like, to the free pool” [DASH ¶ 67].
DASH is considered to be analogous to the claimed invention because it is in the same field of memory sharing. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Selitser in view of Cohen to incorporate the teachings of DASH and include: the messages are either freed by the second framework or passed back to the first framework. Doing so would allow for the freeing of storage space. “The freed resources are returned to the free pool and are available for reuse by other CTAs from same grid and/or CTAs from other independent grids” [DASH ¶ 61].
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Selitser (US 8,719,780 B2) in view of Cohen (US 2010/0077155 A1).
With regard to claim 8, Selitser teaches the method of claim 1, as referenced above. Selitser further teaches that each segment of state is only accessible by its corresponding actor: “In one embodiment, each actor is the owner of its own segment of state, which is only accessible to that actor” [Selitser Col. 3 Lines 31-33]. However, Selitser fails to explicitly teach wherein the compatibility layer prevents memory from being moved by components between frameworks.
However, Cohen teaches wherein the compatibility layer prevents memory from being moved by components between frameworks. “The operating system protects the shared memory to prevent any inadvertent relocation or destruction of data during memory management (206)” [Cohen ¶ 19].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Selitser to incorporate the teachings of Cohen and include: when messages are sent by the first framework, the first framework does not drop the messages. Doing so would allow for the protection of shared memory. “The operating system protects the shared memory to prevent any inadvertent relocation or destruction of data during memory management (206)” [Cohen ¶ 19].
Claims 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over Selitser (US 8,719,780 B2) in view of HA (US 2022/0035561 A1).
With regard to claim 9, Selitser teaches the method of claim 1, as referenced above. Selitser further teaches by the first framework. “Each actor exposes an API that allows tying entries stored in multiple storage service stores to the same cluster location, transaction, and unit of concurrency. Lower level application components could be more flexible if they expect store instances via constructors. Actors or other higher level components could then serve as store factories customizing state management and concurrency strategy” [Selitser Col. 14 Lines 26-32].
Selitser fails to explicitly teach further comprising storing metadata in memory allocated.
However, HA teaches further comprising storing metadata in memory allocated “The metadata area 113 may be a memory area allocated to store metadata for the write data provided by the host 400. The metadata area 113 may be an area allocated to store map data of the data stored in the sequential data areas 111” [HA ¶ 50].
HA is considered to be analogous to the claimed invention because it is in the same field of memory management. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Selitser to incorporate the teachings of HA and include: further comprising storing metadata in memory allocated. Doing so would allow for the storage and access of sequential data. “The sequential data areas 111 may be logical areas defined for the purpose of handling write data based on a logical address group provided by the host 400” [HA ¶ 45].
With regard to claim 10, Selitser in view of HA teaches the method of claim 9, as referenced above. Selitser further teaches wherein the metadata is stored using a memory model of the second framework. “Each actor exposes an API that allows tying entries stored in multiple storage service stores to the same cluster location, transaction, and unit of concurrency. Lower level application components could be more flexible if they expect store instances via constructors. Actors or other higher level components could then serve as store factories customizing state management and concurrency strategy” [Selitser Col. 14 Lines 26-32].
With regard to claim 11, Selitser in view of HA teaches the method of claim 10, as referenced above. Selitser further teaches wherein the memory model is opaque to the first framework. “In one embodiment, a storage service 142 defines an abstraction for all state management in all stack layers. The performance and querying, as well as the atomicity, consistency, isolation and durability (ACID) properties are configured behind this general abstraction” [Selitser Col. 4 Lines 50-54]. “Distributed event communication could be modeled as a distributed queue with store and forward behavior. The store portion of that behavior could be made less reliable, but also less latent by replication. Such a queue would be completely hidden by the event broker” [Selitser Col. 12 Lines 30-35].
Claims 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Selitser (US 8,719,780 B2) in view of Tierman (US 2013/0128897 A1).
With regard to claim 14, Selitser teaches the method of claim 13, as referenced above. Selitser further teaches to enable an asynchronous response to be sent to that request. “In one embodiment, outbound protocol events always originate from the application components and are asynchronously handed off to the adapter through the event broker” [Selitser Col. 13 Lines 13-16].
Selitser fails to explicitly teach including a mapping for extracting a field from a message and a mapping from a value of the field to a channel corresponding to an asynchronous request.
However, Tierman teaches further comprising including a mapping for extracting a field from a message and a mapping from a value of the field to a channel corresponding to an asynchronous request “In the case that more than one message transmit queue is used at the HCC or the CPE, the specific message transmit queue selected for placement of a message by an application is determined by characteristics of the message: including but not limited to application ID, Priority and type, and message length” [Tiernan ¶ 376].
Tierman is considered to be analogous to the claimed invention because it is in the same field of message passing systems. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Selitser to incorporate the teachings of Tierman and include: a mapping for extracting a field from a message and a mapping from a value of the field to a channel corresponding to an asynchronous request. Doing so would allow for the selection of the correct channel to send a message [Tierman ¶ 376].
With regard to claim 15, Selitser in view of Tierman teaches the method of claim 14, as referenced above. Selitser fails to explicitly teach performing multi-stage message correlation including determining which channel to send a received message based on a type and ID of the received message.
However, Tierman teaches further comprising performing multi-stage message correlation including determining which channel to send a received message based on a type and ID of the received message. “In the case that more than one message transmit queue is used at the HCC or the CPE, the specific message transmit queue selected for placement of a message by an application is determined by characteristics of the message: including but not limited to application ID, Priority and type, and message length” [Tiernan ¶ 476].
With regard to claim 16, Selitser in view of Tierman teaches the method of claim 14, as referenced above. Selitser further teaches wherein the compatibility layer enables the first and second frameworks to interoperate without modifying the first and second frameworks to enable the interoperation. “The cooperation in scheduling between adapters and application components can follow a basic "Half-sync/Half-async" pattern for efficient asynchronous input/output (I/O)” [Selitser Col. 8 Lines 5-8].
Response to Arguments
Applicant's arguments filed 03/27/2026have been fully considered but they are not persuasive. Applicant argues in substance:
I. Claims 17-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite. Applicant has amended claims 17 and 20 to clarify the frameworks that are referenced, and respectively requests reconsideration and withdrawal of the rejection.
Examiner respectfully disagrees. The amendments to claim 17 overcome the 112(b) rejection; however, claim 20 lacks any similar clarification.
II. The Office Action asserts that "mapping a first message to a second message" can be done mentally. This oversimplifies the claims. The claims are not merely "mapping data." The claims recite executing a compatibility layer, interoperation between two frameworks, different concurrency paradigms, threading model adherence, and runtime scheduling behavior. The claimed operations are tied to actor scheduler semantics, asynchronous thread execution, and memory ownership enforcement. This is not a fundamental economic practice, method of organizing human activity, or mental process.
Even under broadest reasonable interpretation, a human cannot enforce thread pool constraints, perform non-blocking synchronous return semantics, transfer memory ownership between runtimes, and maintain actor isolation invariants. The claims therefore do not merely recite a mental process.
Examiner respectfully disagrees. In response to applicant's argument that the claims do not recite an abstract idea, it is noted that the features upon which applicant relies (i.e., “threading model adherence, and runtime scheduling behavior” and ”enforce thread pool constraints, perform non-blocking synchronous return semantics, transfer memory ownership between runtimes, and maintain actor isolation invariants”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Further, the mapping recited by the independent claims is considered a mental process because, as claimed, it can be performed in the human mind using mental observation and determinations. Thus, the claims recite a judicial exception. The additional elements of the claims amount to no more than generic computing components, technological environment/field of use, and insignificant extra solution activity which do not amount to significantly more than the abstract idea. The arguments have been considered but were not found to be persuasive.
III. Claim 1 recites steps that are directed to a concrete improvement in computer concurrency architectures, solving technical thread scheduling and memory ownership conflicts between two incompatible frameworks…
Additionally, the claims are integrated into a practical application. Applicant's claims address technical problems such as threading model incompatibility, memory ownership conflicts across frameworks, actor scheduler synchronous return requirements, and asynchronous framework thread constraints. The claimed compatibility layer synchronously returns actor threads while asynchronous work continues, moves work to appropriate thread pools, manages cross-framework object ownership, and correlates asynchronous responses. Such features improve reliability, deadlock avoidance, thread safety, memory safety, and performance. The present claims solve a computer concurrency architecture problem and is not merely automating a business practice. The Office Action's characterization of threading translation and memory ownership management as a "technological environment" is incorrect. These are substantive structural features.
Finally, even if the claims were considered abstract, the additional elements are not conventional. The Office Action provides no evidentiary support that cross-framework thread model translation, memory ownership transfer enforcement, and a dual-exposed compatibility layer architecture were well-understood, routine, and conventional. Under Berkheimer, whether something is well-understood, routine, and conventional is a factual question requiring evidence. No such evidence is cited.
Accordingly, claim 1, and claims 17 and 20 which include similar subject matter, recite complex features that amount to significantly more than an abstract idea. Accordingly, claims 1-20 are patent eligible and withdrawal of the rejection under 35 U.S.C. 101 is respectfully requested.
Examiner respectfully disagrees. In response to applicant's argument that the claims present an improvement to the technology, it is noted that the features upon which applicant relies (i.e., “threading model incompatibility, memory ownership conflicts across frameworks, actor scheduler synchronous return requirements, and asynchronous framework thread constraints”, “moves work to appropriate thread pools, manages cross-framework object ownership, and correlates asynchronous responses”, and “cross-framework thread model translation, memory ownership transfer enforcement, and a dual-exposed compatibility layer architecture”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). It is not clear from the claims that there are incompatibility or ownership conflicts being addressed and it is not clear what computer concurrency architecture problem is being addressed. The mapping and ownership transfer of the independent claims are considered mental processes because they are processes which can be performed within the human mind. These features were not considered within the above rejection as technological environment. As detailed in the rejection above, the additional elements of the claims amount to no more than generic computing components, technological environment/field of use, and insignificant extra solution activity which do not amount to significantly more than the abstract ideas. The limitation: “the compatibility layer is exposed as an actor to the framework using the actor pattern and exposed as an asynchronous component to the framework using the event based asynchronous pattern” without more, simply provides a description of the environment where the mental process of mapping messages is performed. The arguments have been considered but were not found to be persuasive.
VI. Selitser describes a protocol-neutral application server, an event broker layer, protocol adapters that convert protocol-specific communications into asynchronous events, and actor-based state management inside the server. However, Selitser uses actors internally and uses asynchronous events via an event broker, but does not disclose interoperation between two independent frameworks, translation between actor and async threading models, a compatibility layer exposed as actor to one framework and async component to another, memory ownership transfer and lifecycle management between frameworks, and correlation of request/response across two concurrency paradigms. Selitser abstracts protocols into events but does not bridge two runtime concurrency frameworks. Thus Selitser does not anticipate at least these features of claim 1.
For at least the above reasons, Applicant submits that claim 1 is not anticipated by Selitser. Claims 17 and 20 are also directed to at least the features of claim 1 discussed above, and Applicant submits that claims 17 and 20 are not anticipated by Selitser for at least the same reasons. Applicant submits that claims 5, 12, 13, and 19, which depend on claims 1 and 17, are also not anticipated by Selitser by virtue of the subject matter disclosed therein, and also by virtue of their dependency on claims 1 and 17. For at least the above reasons, Applicant respectfully requests withdrawal of the 35 U.S.C. § 102 rejection of claims 5, 12, 13, and 19.
Examiner respectfully disagrees. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “two independent frameworks”, “translation between actor and async threading models”, “lifecycle management between frameworks”, “correlation of request/response across two concurrency paradigms” and “bridge two runtime concurrency frameworks”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Further, as detailed in the rejection above, Selitser teaches interoperation between an actor frame work and asynchronous event framework [Selitser Col. 12] a compatibility layer exposed as actor to one framework and async component to another [Selitser Col. 6, fig. 2] memory ownership transfer [Selitser Col. 13]. It is unclear what difference in function Applicant alleges between the event broker layer of Selitser and the claimed compatibility layer. The arguments have been considered but were not found to be persuasive.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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.
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4:30PM.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/A.F.R./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights