DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. This Office Action is responsive to the applicant’s response to the Non-Final rejection filed on March 16, 2026.
3. Claims 1-20 are pending, of which claims 1 and 11 are in independent form.
Response to Arguments
4. Applicant's arguments, see “§101 Rejections”, filed March 16, 2026 have been fully considered but they are not persuasive. 5, Applicant argues that the claims are not directed a judicial exception because the claims recite an ingestion API mechanism, message queues, data processing engines, databases, and pull APIs. Examiner has carefully considered the argument but respectfully disagrees. The examiner’s rejection is not based on a conclusion that the claims merely recite generic computer components in isolation. Rather, the claims as a whole recite receiving information, identifying data types associated with the information, routing information according to the identified data types, processing the information, storing the information, and providing the information for retrieval and use. These activities constitute collecting, classifying, organizing, processing, storing, and providing information, which is an abstract idea.
6. Applicant further argues that the claims improve scalability, latency, availability, and handling of large volumes of data. Examiner has carefully considered the argument but respectfully disagrees. This argument is not persuasive because the claims do not recite the specific technological mechanisms that allegedly achieve those improvements. The claims broadly recite identifying data types, placing data into message queues, processing data, storing data, and retrieving data. The claims therefore recite desired results rather than a specific technological improvement to the functioning of a computer or another technology.
7. Applicant additionally argues that the claimed ingestion API mechanism prevents the claims from being characterized as a mental process and relies on USPTO Example 37.
Examiner has carefully considered the argument but respectfully disagrees. This argument is not persuasive. The examiner’s rejection is not predicated on a conclusion that every claim limitation can literally be performed in the human mind. Rather, the claims are directed to the abstract concept of collecting, classifying, routing, processing, storing, and providing information implemented using generic computing components. The recitation of an API mechanism merely provides a generic interface through which information is received and does not integrate the judicial exception into a practical application.
8. Applicant further argues that the claims are analogous to those found eligible in Core Wireless. Examiner has carefully considered the argument but respectfully disagrees. This argument is not persuasive. Unlike the claims in Core Wireless, the present claims do not recite a specific user-interface arrangement that improves user interaction with a computing device. The claims merely receive, process, store, and provide information through generic interfaces. Accordingly, the claims do not recite the type of interface improvement discussed in Core Wireless. When considered individually and as an ordered combination, additional claim elements -including APIs, message queues, processing engines, databases, load balancers, related management components—perform their ordinary and expected functions. The claims do not recite a specific improvement to computer functionality or another technology and therefore do not amount to significantly more that the abstract idea itself. Accordingly, the rejection under 35 U.S.C. §101 is maintained.9. Applicant's arguments, see “§103 Rejections”, filed March 16, 2026 have been fully considered but they are not persuasive. 10. Applicant argues that Gale only concerns messages and therefore cannot teach placement based on data type. Examiner has carefully considered the argument but respectfully disagrees. The argument is not persuasive because the rejection does not rely solely on Gale for the claimed plurality of data types. Rajaraman expressly teaches multiple data types, message type fields, selectors, and processing based upon message type. Therefore, the combination of Gale and Rajaraman teaches or at least suggests routing messages according to identified data types. See (Rajaraman [0097] e.g., “Type A value that can be evaluated by a message selector”, see also [0065] e.g., “The business logic execution may be based on the message types used”, and [0066] e.g., “… the data transformation layer 204 supports the following data types: Simple Strings, XML (Complex), Files, Images & Bitmaps (Byte Streams), and Serializable Objects (Marshal By Value) … other data types may be supported”). Therefore, Rajaraman teaches requests/messages containing information identifying a type of input data.
11. Applicant argues that the Office improperly equates priority with type. Examiner has carefully considered the argument but respectfully disagrees. Applicant’s argument has been considered but is not persuasive. The rejection does not rely on Gale’s priority values as corresponding to the claimed data type. Rather, Gale is relied upon for its multi-queue message routing architecture, while Rajaraman is relied upon for message type information, selectors, and type-based message handling. The combination suggests directing messages having identified types to corresponding queues for processing. Gale only concerns messages and therefore cannot teach placement based on data type. Gale teaches a plurality of source queues and queue-based message routing. And Rajaraman teaches message selectors and message type fields used to sort and route messages. It would have been obvious to utilize Rajaraman’s message type information and selector-based routing within Gale’s multi-queue architecture to direct messages of a given type to appropriate queue for subsequent processing.
12. Applicant argues Gale only determines queue information after a message has already been placed. Examiner has carefully considered the argument but respectfully disagrees. This argument is not persuasive because the rejection relies on the combination of references. Gale teaches multiple queues and queue routing mechanisms, while Rajaraman teaches message type identification and selector-based routing. One or ordinary skill in the art would have found it obvious to use Rajaraman’s type information when selecting an appropriate queue within Gale’s multi-queue architecture.
Claim Rejections - 35 USC § 101
13. 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.
14. Claims 1–20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without reciting significantly more, as analyzed under the USPTO’s 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG) and October 2019 Update. The claims, even when read in light of the specification, are directed to receiving data identifying data types, routing data according to the identified types, processing the data, storing the processed data, and providing the processed data for retrieval. These activities can be characterized as collecting, classifying, organizing, processing, storing, and providing information. The claim
Step 1: Statutory CategoryClaims 1–10 are directed to an apparatus (machine).Claims 11–20 are directed to a method (process). Accordingly, all claims fail within a statutory category of invention.
Step 2A, Prong 1 – Judicial ExceptionThe following claim limitations are identified as reciting mental processes and certain methods of organizing human activity, which fall under the abstract idea category.
Representative claim: Claim 1 An apparatus comprising: [a] receiving requests from data source; [b] identifying a type of input data associated with each request; [c] placing the input data into a message queue based on the identified type; [d] processing the input data using a processing engine associated with the type; [e] storing processed data; and [f] retrieving processed data for consumer use. These limitations, considered individually and as an ordered combination, recite abstract ideas including:
- collecting information, namely receiving requests and associated data; - classifying information, namely identifying a type associated with the received data; - organizing information, namely routing data to queues according to classification; - processing information according to the classification; - storing information; and providing information for retrieval and use. These activities fall within the abstract idea grouping of managing information and processing information based on classification criteria. The claims recite the result of classifying and routing information according to data type but do not recite a specific technological mechanism by which the classification, routing, processing, or storage operation are performed.
Accordingly claim 1 recites a judicial exception. Independent claim 11 recites substantially the same abstract idea in method form.
Dependent claims: Claims 2-10 and 12-20 recite additional limitations including authentication, metering, throttling, URI exposure, load balancing, additional processing engines, additional queues, database interface, exchange mechanisms, multiple databases, dynamic instantiation of processing engines, and various categories of input data. These limitations continue the overall information-processing workflow and therefore recite additional aspects of the same abstract idea.
Step 2A, Prong 2 – The Claims do not integrate the abstract idea into a practical application. Although the claims recite: [a] ingestion API’s; [b] pull API’s; [c] message queue; [d] processing engines; [e] databases; [f] load balancers; and [g] API management components, these elements are used as tools to implement the abstract process of receiving, classifying, routing, processing, storing, and providing information.
The claims do not: - recite a specific queue architecture; - recite a specific routing algorithm; - recite a specific database storage mechanism; - recite a specific load-balancing technique; - recite a specific low-latency processing mechanism; - recite a specific scalability mechanism; or - recite a specific improvement to computer functionality. Instead the claims broadly recite: - identifying data types; - routing data according to the identified types; - processing the data; - storing the data; and - retrieving the data. Applicant asserts benefits such as scalability, low latency, high availability, and efficient handling of large volumes of data. However, the claims do not recite the specific technological mechanisms that allegedly achieve those benefits and instead claim the desired results at a high level of abstraction. Applicant’s reliance on the recited ingestion API is not persuasive.The recitation of an API merely provides a generic interface through which information is received and does not itself integrate the abstract idea into a practical application. Applicant’s reliance on Core Wireless is also not persuasive. Unlike the claims in Core Wireless, the present claims do not recite a specific user-interface arrangement that improves user interaction with a device. Rather, the claims merely retrieve and provide information through generic interfaces. Accordingly, the claims do not integrate the abstract idea into a practical application.
Step 2B – Significantly More The additional elements do not amount to “significantly more” than the judicial exception itself. The additional elements beyond the abstract idea include: - ingestion APIs; - pull APIs; - message queues; - processing engines; - databases; - API management components; - load balancers; and - authentication, throttling, and scheduling functionality. These elements are well-understood, routing, and conventional computer components performing their ordinary functions. The claims do not recite: - a specific queue-management improvement; - a specific database improvement; - a specific API architecture improvement; - a specific processing-engine improvement; - a specific computer-network improvement; or - any other unconventional technical implementation. The claims instead recite the desired result of routing and processing information according to data classifications and making the resulting information available to consumers. Considering the elements individually and as an ordered combination, the claims merely implement the abstract idea using generic computer components performing their conventional functions. Therefore, the claims do not include additional elements that amount to significantly more than the abstract idea itself.
Conclusion Claims 1-20 are directed to abstract ideas involving collecting, classifying, organizing, processing, storing, and providing information and do not include additional elements sufficient to integrate the abstract idea into a practical application or amount to significantly more that the abstract idea. Therefore, claims 1-20 are not patent-eligible under 35 U.S.C. §101.
Claim Rejections - 35 USC § 103
15. 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.
16. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
17. Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gale et al. U.S. Patent 8,139,596 B2 (hereinafter Gale) in view of Rajaraman et al. U.S. 2010/0093441 A1 (hereinafter Rajaraman).
Regarding claim 1, Gale discloses a storage apparatus comprising: [a first data processing engine that is configured to process a first type of input data associated with a first storage request of the requests received from data sources to store processed data, thereby generating at least a portion of the processed data to be stored], wherein the first type of input data is a first data type of the plurality of data types a first message queue associated with the first data processing engine (Gale [col. 5, lines 61-65] e.g., “Local message broker 100 contains a set of source queues 110, 120, 130 and 140. Each source queue 110-140” Gale therefore teaches a first message queue), the ingestion API mechanism being configured being configured to place input data of the first type of data into the first message queue (Gale [col. 6, lines 17-18] e.g., “… at step 210 the listener is waiting for a new message to be received on a relevant source queue.”, see also [col. 6, lines 19-31] e.g., “… the priority of the highest priority message currently queued on the given queue 110-140”, see also [col. 6, lines 56-62] e.g., “… when a new notification of a new message on one of the source queues is received…”. These passages establish that: a) messages are placed into source queues, b) source queues hold messages awaiting processing/transmission, and c) queue-specific processing occurs when message arrive. See also [col. 6, 46-48] e.g., “Note the bridge 150 has a mapping definition (not illustrated) defining where messages from a particular source queue are to be targeted.”. This discussing a mapping relationship between queues and message routing.). Gale does not explicitly disclose: an ingestion application programming interface (API) mechanism that receives requests from data sources to store processed data, the requests each containing an indication of a type of input data associated with the request, the type of input data being one of a plurality of data types; wherein placement of the input data is determined based on its data type, a first data processing engine that is configured to process a first type of input data associated with a first storage request of the requests received from data sources to store processed data, thereby generating at least a portion of the processed data to be stored. Rajaraman discloses: an ingestion application programming interface (API) mechanism that receives requests from data sources to store processed data (Rajaraman [0044] e.g., “The applications 14, 16 and other software components 18 may communicate with the integration gateway 12 via an application programming interface 22 (“API”)”. See also [0055] e.g., “Using a MOM-based system, in one embodiment, a Client makes an API call to send a message to a destination managed by the MOM provider”. The integration gateway API receives messages and requests from external application and therefore teaches the claimed ingestion API mechanism that receives requests from data sources), the requests each containing an indication of a type of input data associated with the request, the type of input data being one of a plurality of data types (Rajaraman [0065] e.g., “The business logic execution may be based on the message types used.”, see also [0066] e.g., “… the data transformation layer 204 supports the following data types: Simple Strings, XML (Complex), Files, Images & Bitmaps (Byte Streams), and Serializable Objects”, see also [0097] e.g., “Type A value that can be evaluated by a message selector”. Accordingly, Rajaraman teaches requests/messages containing type information, wherein the type is one of a plurality of data type); a first data processing engine that is configured to process a first type of input data associated with a first storage request of the requests received from data sources to store processed data (Rajaraman [0074] e.g., “The Clients can then consume messages based on the information gained from this inspection”. The message consumers and message processor functionality process messages selected according to message type information and therefore teach a processing engine configured to process a first type of input data), thereby generating at least a portion of the processed data to be stored (Rajaraman [0084] e.g., “The Web Services may use message processor plug-ins to translate messages into the format required by the requested system.” The message processor plug-ins transform incoming messages into processed output and therefore teach generation processed data); and wherein placement of the input data is determined based on its data type (Rajaraman [0039] e.g., “A message service may perform message filtering and routing based on criteria placed in message selectors.”, see also [0096] e.g., “The message header may be a requirement for every valid message. The header may, inter alia, contain the following exemplary fields…”); and a pull API mechanism that is called by the consumers to retrieve the processed data, wherein the processed data is in a format configured for consumer use (Rajaraman [0084] e.g., “The Web Services may use message processor plug-ins to translate messages into the format required by the requested system”. See also [0104] e.g., “The messages produced above may be received by a message consumer, within the context of a connection and/or session. In one embodiment, the client uses a message consumer object (Message Consumer) to receive messages from a specified physical destination, represented in the API as a destination object”. The translated output is provided in formats required by consuming systems and therefore teaches a pull API mechanism through which consumers retrieve processed data in a consumer-configured format). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Rajaraman’s API-based message ingestion, message type identification, selector-based routing, message processing, and message transformation functionality into Gale’s queue-based messaging architecture because both references are directed to message-oriented middleware systems for communication among distributed and heterogeneous computing environments. Such modification would have predictable enabled differentiated routing and processing of multiple data types while preserving Gail’s queue-based message management framework and facilitating communication among heterogeneous components as taught by Rajaraman ([0172]).
Regarding claim 2, the proposed combination of Gale and Rajaraman discloses the apparatus of claim 1, further comprising an API management component that authenticates (Rajaraman [0091] e.g., “The allocation of communication resources and authentication of the Client may take place when a connection is created”), meters (Rajaraman [0186] e.g., “…Messages may also be prioritized… Message scheduling may also be used to define the time for processing a given message”) and throttles the requests and the calls to the ingestion AP] mechanism and the pull API mechanism (Gale [col. 6, lines 19-26] e.g., “The bridge 150 maintains a lookup (priority) table 170 to map a queue name with the priority of the highest priority message currently queued on the given queue 110-140…”, see also [col. 7, lines 7-8] e.g., “…each queue can be assigned a weighting that determines the sequence that should be used”. Rajaraman discloses API components (message processor plug-ins) that authenticate incoming messages. Rajaraman further discloses scheduling and prioritization to regulate throughput, i.e., metering requests. Gale teaches queue weighting and fairness mechanisms, which operate as throttling of requests/calls. .
Regarding claim 3, the proposed combination of Gale and Rajaraman discloses the apparatus of claim 2, wherein the ingestion API mechanism and the pull API mechanism are exposed by the storage apparatus to receive requests at respective Uniform Resource Identifiers (URI) (Rajaraman [0084] e.g., “…message processor plug-ins to translate messages into the format required by the requested system”, see also [0186] e.g., “…Message Processor Plug-ins for Request and Response messages may be configured… message type (e.g., string, xml, etc.)”. Consumers call the integration gateway over standard APIs (HTTP/HTTPS, SOAP). The plug-ins ensure that the processed data is output in consumer-ready formats such as XML or string [0086]. Together, this teaches a pull API mechanism delivering processed data in a format configured for consumer use).It would have been obvious to expose Gale’s ingestion and pull API as URI endpoints, consistent with Rajaraman’s teaching to enable external client to send and retrieve data over a standardized interface.
Regarding claim 4, the proposed combination of Gale and Rajaraman discloses the apparatus of claim 1, wherein the processed data is stored in a non-blocking fashion into one or more of a plurality of databases in accordance with the type of input data indicated in the request to the ingestion API mechanism, the first database being one of the plurality of databases (Gale [col. 5, lines 61-65] e.g., “Local message broker 100 contains a set of source queues 110, 120, 130 and 140. Each source queue 110-140 contains messages which can be retrieved in priority order”. This teaches asynchronous queueing, which ensures non-blocking operation.)..
Regarding claim 5, the proposed combination of Gale and Rajaraman discloses the apparatus of claim 1, wherein the ingestion API mechanism further comprises load balancers that determine resources within the storage apparatus to be utilized in order to minimize response time to store the processed data (Gale [col. 6, lines 7-15] e.g., “Every time a message becomes available on a specified source queue 110-140… the listener 160 is notified by a callback”. This listener dynamically responds to available messages, functionally acting as a balancing mechanism).It would have been obvious to include explicit load balancing in Gale’s ingestion API to allocate resources efficiently, consistent with Rajaraman’s teaching of prioritization and scheduling [0186]to minimize response times.
Regarding claim 6, the proposed combination of Gale and Rajaraman discloses the apparatus of claim 1, further comprising: a second data processing engine that is configured to process a second type of data, thereby generating processed data, wherein the second type of data is a second data type of the plurality of data types (Gale [col. 6, lines 19-24] e.g., “The bridge 150 maintains a lookup (priority) table 170 to map a queue name with the priority of the highest priority message currently queued on the given queue 110-140”. This shows multiple queues (per data types); and a second message queue associated with the second data processing engine, the ingestion API mechanism being configured to place input data of the second type of data into the second message queue, wherein the processed data of the second data processing engine is stored by one of the first database and a second database (Rajaraman [0074] e.g., “The Clients can then consume messages… if they know what messages they want based at least in part on message selectors”. This discloses multiple consumers/engines processing different types of messages. It would have been obvious to configure a second engine and second queue to handle additional data types, with storage into one of several databases, by combining Gale’s multiple-queue design with Rajaraman’s data-type specific processing.
Regarding claim 7, the proposed combination of Gale and Rajaraman discloses the apparatus of claim 1, wherein the first data processing engine further comprises: a data pump that reads a message from the associated message queue (Rajaraman [0084] e.g., “The Web Services may use message processor plug-ins to translate messages into the format required by the requested system; a handler that receives messages from the queue (Rajaraman [0084] e.g., “The Web Services may use message processor plug-ins to translate messages into the format required by the requested system”. This corresponds to a handler and data pump); a database interface that writes the processed data of the first data processing engine to the first database; and an exchange mechanism that provides at least a portion of the processed data directly to the consumers (Rajaraman [0186] e.g., “In one embodiment, the Message Processor Plug-ins for Request and Response messages may be configured. Other message settings may also be configured, such as: message type (e.g., string, xml, etc.). Messages may also be prioritized according to a particular ‘type’ field of the message….” This teaches scheduling and prioritization, functioning like an exchange mechanism to consumers).
Regarding claim 8, the proposed combination of Gale and Rajaraman discloses the apparatus of claim 7, wherein if the first data processing engine receives data of an unknown type, the first data processing engine places the data into a queue of a second data processing engine of the storage apparatus, the second data processing engine being configured to process the data of the unknown type (Gale [col. 7, lines 3-5] e.g., “If there is more than one queue with the highest priority messages, fairness may be ensured by picking a queue at random”. This shows that messages can be redirected).
Regarding claim 9, the proposed combination of Gale and Rajaraman discloses the apparatus of claim 1, wherein the input data is gridded data, and wherein the first data processing engine is instantiated following receipt of the first storage request, thereby satisfying resource requirements associated with the fist storage request (Rajaraman [0104] e.g., “the client uses a message consumer object (Message Consumer) to receive messages from a specified physical destination…” The consume object is instantiated dynamically as needed).
Regarding claim 10, the proposed combination of Gale and Rajaraman discloses the apparatus of claim 9, wherein the first type of input data is one of pollen data, satellite data, forecast models, wind data, lightening data, air quality data, user data, temperature data, and weather station data (Rajaraman [0066] e.g., “… the data transformation layer 204 supports the following data types: Simple Strings, XML (Complex), Files, Images & Bitmaps (Byte Streams), and Serializable Objects…”.The “serializable objects” and “files” can include user data, which satisfies the claim requirement that the first type of input data can be “user data”), wherein the apparatus further comprises a data cartridge having executable instructions for instantiating the first data processing engine and wherein the first data processing engine is destroyed following completion of data processing associated with the first storage request, thereby freeing up system resources (Rajaraman [0104] e.g., “…the client uses a message consumer object (Message Consumer) to receive messages …”. These objects are created and terminated as needed).
Regarding claim 12, the proposed combination of Gale and Rajaraman discloses the method of claim 11, further comprising authenticating (Rajaraman [0091] e.g., “The allocation of communication resources and authentication of the Client may take place when a connection is created”), metering (Rajaraman [0186] e.g., “…Messages may also be prioritized… Message scheduling may also be used to define the time for processing a given message”) and throttling the requests and the calls to the ingestion API mechanism and the pull API mechanism using an API management component (Gale [col. 6, lines 19-26] e.g., “The bridge 150 maintains a lookup (priority) table 170 to map a queue name with the priority of the highest priority message currently queued on the given queue 110-140…”, see also [col. 7, lines 7-8] e.g., “…each queue can be assigned a weighting that determines the sequence that should be used”. Rajaraman discloses API components (message processor plug-ins) that authenticate incoming messages. Rajaraman further discloses scheduling and prioritization to regulate throughput, i.e., metering requests. Gale teaches queue weighting and fairness mechanisms, which operate as throttling of requests/calls..
Regarding claim 13, the proposed combination of Gale and Rajaraman discloses the method of claim 12, further comprising exposing the ingestion API mechanism and the pull mechanism at respective Uniform Resource Identifiers (URI) (Rajaraman [0084] e.g., “…message processor plug-ins to translate messages into the format required by the requested system”, see also [0186] e.g., “…Message Processor Plug-ins for Request and Response messages may be configured… message type (e.g., string, xml, etc.)”. Consumers call the integration gateway over standard APIs (HTTP/HTTPS, SOAP). The plug-ins ensure that the processed data is output in consumer-ready formats such as XML or string [0086]. Together, this teaches a pull API mechanism delivering processed data in a format configured for consumer use).It would have been obvious to expose Gale’s ingestion and pull API as URI endpoints, consistent with Rajaraman’s teaching to enable external client to send and retrieve data over a standardized interface.
Regarding claim 14, the proposed combination of Gale and Rajaraman discloses the method of claim 11, further comprising storing the processed data in a non-blocking fashion into one or more of a plurality of databases in accordance with the type of input data indicated in the request to the ingestion API mechanism, the first database being one of a plurality of databases (Gale [col. 5, lines 61-65] e.g., “Local message broker 100 contains a set of source queues 110, 120, 130 and 140. Each source queue 110-140 contains messages which can be retrieved in priority order”. This teaches asynchronous queueing, which ensures non-blocking operation).
Regarding claim 15, the proposed combination of Gale and Rajaraman discloses the method of claim 11, further comprising providing load balances that determine resources within the storage apparatus to be utilized in order to minimize response time to store the processed data (Gale [col. 6, lines 7-15] e.g., “Every time a message becomes available on a specified source queue 110-140… the listener 160 is notified by a callback”. This listener dynamically responds to available messages, functionally acting as a balancing mechanism).It would have been obvious to include explicit load balancing in Gale’s ingestion API to allocate resources efficiently, consistent with Rajaraman’s teaching of prioritization and scheduling [0186]to minimize response times.
Regarding claim 16, the proposed combination of Gale and Rajaraman discloses the method of claim 11, further comprising storing at least some of the processed data at a second database (Gale [col. 6, lines 19-24] e.g., “The bridge 150 maintains a lookup (priority) table 170 to map a queue name with the priority of the highest priority message currently queued on the given queue 110-140”. This shows multiple queues (per data types)).
Regarding claim 17, the proposed combination of Gale and Rajaraman discloses the method of claim 11, further comprising providing the data processing engine further with a data pump that reads the messages from the associated message queue, a database interface that writes the processed data to a predetermined database among the plurality of databases, and an exchange mechanism that provides processed data directly to the consumers (Rajaraman [0186] e.g., “In one embodiment, the Message Processor Plug-ins for Request and Response messages may be configured. Other message settings may also be configured, such as: message type (e.g., string, xml, etc.). Messages may also be prioritized according to a particular ‘type’ field of the message….” This teaches scheduling and prioritization, functioning like an exchange mechanism to consumers).
Regarding claim 18, the proposed combination of Gale and Rajaraman discloses the method of claim 17, further comprising; determining if the respective data processing engine receives data of an unknown type (Rajaraman [0074] e.g., “ The Clients can then consume messages based on the information gained from this inspection. That is, although the consumption model is normally FIFO (first in, first out), in some embodiments, Clients can consume messages that are not at the head of the Queue if they know what messages they want based at least in part on message selectors”. This teaches that messages carry a type header field and that components (clients/consumers) can use message selectors to examine message headers and decide whether to consume/process a message. If no selector matches or the Type is not recognised, the engine can determine the message is an “unknown type”. Thus, Rajaraman teaches the ability to detect/classify message types and thereby detect “unknown” types); and placing the data into a queue of another of the at least one data processing engines that can process the data (Rajaraman [0074] e.g., “The Clients can then consume messages… if they know what messages they want based at least in part on message selectors”. This discloses multiple consumers/engines processing different types of messages. It would have been obvious to configure a second engine and second queue to handle additional data types, with storage into one of several databases, by combining Gale’s multiple-queue design with Rajaraman’s data-type specific processing).
Regarding claim 19, the proposed combination of Gale and Rajaraman discloses the method of claim 11, wherein the input data is glidded data, and wherein the method further comprises instantiating a plurality of data processing engines following receipt of related storage requests, thereby satisfying resource requirements associated with each storage request (Rajaraman [0104] e.g., “the client uses a message consumer object (Message Consumer) to receive messages from a specified physical destination…” The consume object is instantiated dynamically as needed).
Regarding claim 20, the proposed combination of Gale and Rajaraman discloses the method of claim 19, wherein the type of input data is one of pollen data, satellite data, forecast models, wind data, lightening data, air quality data, user data, temperature data or weather station data, and wherein the method further comprises: providing one or more data cartridges having executable instructions for instantiating each of the plurality of data processing engines (Rajaraman [0104] e.g., “…the client uses a message consumer object (Message Consumer) to receive messages …”. These objects are created and terminated as needed); and destroying at least some of the plurality of data processing engines following completion of data processing associated with the related storage request, thereby freeing up system resources (Rajaraman [0104] e.g., “…the client uses a message consumer object (Message Consumer) to receive messages …”. These objects are created and terminated as needed). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the integration gateway server that stores message oriented middleware server as taught by Rajaraman, into the communicating prioritized messages to a destination queue from multiple source queues using source-queue-specific priority values taught by Gale, to yield the predictable results of Facilitates communication in heterogeneous communications networks. Enable improved communication between heterogeneous components in multiple data type (Rajaraman [0172]).
Conclusion
18. 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.
19. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BERHANU MITIKU whose telephone number is (571)270-1983. The examiner can normally be reached Monday – Friday 8:30AM – 4:00PM.
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, Ajay Bhatia can be reached at 571-272-3906. 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.
/BERHANU MITIKU/Examiner, Art Unit 2156
/AJAY M BHATIA/Supervisory Patent Examiner, Art Unit 2156
Prosecution Insights