Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Status of the Claims
This Non-Final Office action is in reply to the application filed 12/29/2022.
Claims 1-15 are pending.
Information Disclosure Statement
The Information Disclosure Statement filed 12/29/2022 has been considered by the Examiner, it has been initialed and enclosed herewith.
Claim Objections
Claim 15 recites, “A system, comprising: c) at least one processor; and d) a memory comprising computer-readable instructions which when executed by the at least one processor causes the processor to execute an Al workflow, wherein the Al workflow: iv. scans data for determining limited data to work on among data sets that are too large or complex to be dealt with; v. drills down to the next data that correlates with the previously determined limited data until obtaining a desired number of workable live results suitable to manage by traditional data-processing application software; and vi. saves the results as new data that capture only limited capacity, thereby providing an in-house collection that, due to its limited capacity, information can be retrieved and worked on it live” There appears to be a typographical error in the steps identified for claim 15. Examiner requests clarification regarding steps “a”, “b”, “i”, “ii”, “iii”, and “iv” – they appear to be missing and/or the steps as recited are not sequentially numbered.
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.
Claims 1-15 are 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.
Claims 1 and 15 recite, “scanning data for determining limited data to work on among data sets that are too large or complex to be dealt with”, and “iv. scans data for determining limited data to work on among data sets that are too large or complex to be dealt with”. Examiner is unable to determine the metes and bounds of the claim limitations. Applicant fails to distinctly describe how the data is being scanned. Meaning, “what” exactly is used to scan the data?... and “how” does it determine “the limited data to work on”? The respective dependent claims do not remedy this flaw; therefore, they are also rejected.
Claims 1 and 15 recite, “scanning data for determining limited data to work on among data sets that are too large or complex to be dealt with”, and “iv. scans data for determining limited data to work on among data sets that are too large or complex to be dealt with”. Examiner is unable to determine the metes and bounds of the claim limitations. Applicant fails to distinctly describe the term “to be dealt with”; nor does applicant define what exactly the term “work on” means in this limitation. Appropriate clarification is request.
Claims 1 and 15 recite, “scanning data for determining limited data to work on among data sets that are too large or complex to be dealt with”, and “iv. scans data for determining limited data to work on among data sets that are too large or complex to be dealt with”. The term “too large or complex” in claims 1 and 15 are relative terms which renders the claim indefinite. The terms “too large or complex” are not defined by the claim(s), the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. How are the term(s) “too large or complex” measured such that one of ordinary skill in the art can determine that the data is “too large or complex”. Is a formula or mathematical equation used to determine when/if/how data is deemed to be “too large or complex”? The respective dependent claims do not remedy this flaw and are also are also rejected based on the same rationale.
Claim 6 recites, “A method according to claim 1, wherein the method is applied in parallel on any other pre-determined outcome to receive multiple outlets and save them as very small data capacity, thereby enabling prompt access and visualization. The term “very small” in claim 6 is a relative term which renders the claim indefinite. The term “very small” is not defined by the claim(s), the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. How is the term(s) “very small” measured such that one of ordinary skill in the art can determine that the data is “very small”. Is a formula or mathematical equation used to determine when/if/how data is deemed to be “very small”? The respective dependent claims do not remedy this flaw and are also are also rejected based on the same rationale.
Claim 10 recite in part, “wherein the machine learning process comprises verifying whether a workflow has an outcome by comparing results and updating accordingly, wherein said process involves the steps of: - Once a suggested parameter has been established, it is marked; [need example]”. Examiner is unable to determine the metes and bounds of the claim limitations. Applicant fails to distinctly describe how the suggested parameter that has been established is marked. Meaning, “how” exactly is/are the parameters marked? The respective dependent claims do not remedy this flaw and are also are also rejected based on the same rationale.
Claim 9 recites “the database”. There is insufficient antecedent basis for this limitation in the claim. The respective dependent claims are also rejected based on the same rationale.
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-15 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. Claims 1-15 are directed to a process (method, an act or step or a series of acts or steps), and a machine (a concrete thing, consisting of parts, or of certain devices and combination of devices). Thus, each of the claims fall within one of the four statutory categories.
Step 2A-Prong 1: Representative claim 1 recites in part, “ a. scanning data for determining limited data to work on among data sets that are too large or complex to be dealt with; b. drilling down to the next data that correlates with the previously determined limited data until obtaining a desired number of workable live results; and c. saving the results as new data that capture only limited capacity, thereby providing an in-house collection that, due to its limited capacity, information can be retrieved and worked on it live.”
The underlined limitations above demonstrate representative independent claim 1 is directed toward the abstract idea for determining, correlating, and saving data to be retrieved for further processing (to be worked on live) in a computing environment. Applicant’s specification emphasizes a system for managing data relative to relationships and interactions with customers and potential customers; providing dynamic data and insights required for a fluent and efficient working process in real-time whereby a massive flow of information is provided, learning every input provided and reacting immediately to any situation. The disclosure further discusses applying a machine learning process for learning each clickable measurement, including time duration entered into a database and verifying whether a workflow has an outcome (page 1, ¶1; page 2, ¶1, ¶2; page 3, ¶7; page 4, ¶1). It further discusses that the method/system can be applied on a personal computer system (i.e. a personal server) and not a supercomputer; and that it may also be implemented in combination with other computer systems, including but not limited to cloud computing system, servers, and the like. The processor-based system 11 comprises a processing unit (PU) 12, a memory 13, a communication module 14, an Al module 15, a data network 16, a plurality of terminal computing devices 17 (e.g., a personal computer configured to act as a call center unit suitable to be operated by an agent 18), and a database 19.Database 19 can be part of server 11 or can be provided as an external unit that may communicate with server 11 via data network 16 (page 9, ¶1; page 15, ¶2, ¶3).
Representative Claim 1 is considered an abstract idea because the steps for a. scanning data for determining limited data to work on among data sets that are too large or complex to be dealt with; b. drilling down to the next data that correlates with the previously determined limited data until obtaining a desired number of workable live results; and c. saving the results as new data that capture only limited capacity, thereby providing an in-house collection that, due to its limited capacity, information can be retrieved and worked on it live pertains to (i) mathematical relationships and (ii) managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)) since the steps are directed to determining limited data to work on among data sets; drilling down to the next data that correlates with the previously determined limited data until obtaining a desired number of workable live results; and c. saving the results as new data that capture only limited capacity, thereby providing an in-house collection that, due to its limited capacity, information can be retrieved and worked on it live which pertains to (i) mathematical concepts and (ii) certain methods of organizing human activity. Hence, the claim recites an abstract idea--see MPEP 2106.04(II). Independent claim 15 recites essentially the same abstract idea as independent claim 1, therefore, it is also abstract based on the same rationale as independent claim 1.
Step 2A-Prong 2: This judicial exception is not integrated into a practical application because the additional elements; “scanning”; “at least one processor”, “memory”, “computer-readable instructions”, “AI workflow”, “data-processing application software” [claim 15] merely provide an abstract-idea based solution using data gathering and analysis and merely provide instructions for mathematical concepts, organizing human activity, and implementing the abstract idea recited above utilizing “scanning”; “at least one processor”, “memory”, “computer-readable instructions”, “AI workflow”, “data-processing application software” [claim 15] as tools to perform the abstract idea, and generally links the abstract idea to a particular technological environment. See MPEP 2106.05 (f-h). Further, the additional elements do not impose any meaningful limits on practicing the abstract idea—see MPEP 2106.05(g). Independent claim 1 fails to operate the recited “scanning”; “at least one processor”, “memory”, “computer-readable instructions”, “AI workflow”, “data-processing application software” [claim 15] (which are merely standard computer technology and hardware/software components-see applicant’s disclosure, (page 2, ¶4): “In one aspect, the scan determines the percentage of data to work on among the entire data set”; (page 5,¶1): “(a) at least one processor, and b) a memory comprising computer-readable instructions which, when executed by the at least one processor, causes the processor to execute an AI workflow”; (page 9, ¶2): “the method of the present can be applied on a personal computer system (e.g., a personal server) and not a supercomputer”; (page 15, ¶3): “According to an embodiment of the invention, processor-based system 11 comprises a processing unit (PU) 12, a memory 13, a communication module 14, an Al module 15, a data network 16, a plurality of terminal computing devices 17 (e.g., a personal computer configured to act as a call center unit suitable to be operated by an agent 18), and a database 19.Database 19 can be part of server 11 or can be provided as an external unit that may communicate with server 11 via data network 16”; (page 15, ¶5): “the functions that were described hereinabove may be performed by executable code and instructions stored in computer-readable medium and running on one or more processor-based systems”; (page 16, ¶1): “Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks. Moreover, those skilled in the art will appreciate that the invention may be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through data network 16 or other communication networks. In a distributed computing environment, program modules may be located in both local and remote memory storage devices”; (page 4, ¶1): “comparing results and updating accordingly”) in any exceptional manner, and there is no evidence in the disclosure to suggest achieving an actual improvement in the computer functionality itself, or improvement in any specific computer technology other than utilizing ordinary computational tools to automate and perform the abstract idea for determining, correlating, and saving data to be retrieved for further processing (to be worked on live) in a computing environment —see MPEP 2106.05(a). Accordingly, applicant has not shown an improvement or practical application under the guidance of MPEP section 2106.04(d) or 2106.05(a).
Dependent claims 2-14 fail to cure the deficiencies of the above noted independent claim from which they depend and are therefore rejected under the same grounds. The dependent claims further recite the abstract idea without imposing any meaningful limits on practicing the abstract idea. Dependent claims 2-14, recite additional data gathering and processing steps (determining, applying, assigning, saving, accessing, comparing, presenting, verifying, updating, providing). For example dependent claims 2, 3, 12 and 13 recite in part, “wherein the scan determines”; claims 4 and 14 recite in part, “wherein the percentages of data to work on is”; claims 5 and 15 recite in part, “wherein the desired number of workable live results are”; claims 6 and 16 recite in part, “wherein a procedure to drill down”; claims 8 and 18 recite in part, “wherein the method is applied in parallel on any other pre-determined outcome to receive”; claim 7 recites in part, further comprising assigning a number for”, claim 8 recites in part, “further comprising: - saving the data daily in a database”; claim 9 recites in part, “further comprising applying machine learning process configured for”; claim 10 recites in part, further comprising applying machine learning process configured for”; claim 11 recites in part, “wherein the in-house data collection enables providing; claim 12 recites in part, “wherein the live information includes data relative to one or more of the following”; claim 13 recites in part, “further comprising tags-based notifications system”; claim 14 recites in part, “further providing positive feedback by” which are still directed toward the abstract idea identified previously and are no more than mere instructions to apply the exception using a computer or with computing components.
The additional elements in the dependent claims, “machine learning process”, “database”, “tags-based notifications system”, only serves to further limit the abstract idea utilizing the “machine learning process”, “database”, “tags-based notifications system” as a tool, and generally link the use of the abstract idea to a particular technological environment, (page 4, ¶1: “the machine learning process comprises verifying whether a workflow has an outcome by comparing results and updating accordingly”; page 4, ¶4: the tags-based notifications system enables to provide real-time data count, timestamp, immediate data filtration and recovery, and speed”; “page 3, ¶3: “.Database 19 can be part of server 11 or can be provided as an external unit that may communicate with server 11 via data network 16”) and hence are nonetheless directed towards fundamentally the same abstract idea as their respective independent claim since they fail to impose any meaningful limits on practicing the abstract idea. Therefore, the abstract idea fails to integrate into any practical application. Thus, under Step 2A-Prong Two the claims are directed to an abstract idea.
Step 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above, with respect to integration of the abstract idea into a practical application, the additional elements “scanning”; “at least one processor”, “memory”, “computer-readable instructions”, “AI workflow”, “data-processing application software” [claim 15], amount to no more than mere instructions to apply the exception using a generic computer component which does not integrate a judicial exception into a practical application nor provide an inventive concept (significantly more than the abstract idea).
Further, the additional elements including applicant’s “AI workflow”, “machine learning process”, “database”, “tags-based notifications system”, are generically used to further process information via common computing components. Moreover, applicant’s AI workflow is generically used on a personal server to further process and transmit received information utilizing rules logic in a manner that is well-understood, routine and conventional in the field. The additional elements amount to no more than applying the judicial exception using generic computing components, and linking the use of the judicial exception to a computing environment. Therefore, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Accordingly, even when considered as a whole, the claims do not transform the abstract idea into a patent-eligible invention since the claim limitations do not amount to a practical application or significantly more than an abstract idea for determining, correlating, and saving data to be retrieved for further processing (to be worked on live) in a computing environment. Hence, claims 1-15 are directed to non-statutory subject matter and are rejected as ineligible subject matter under 35 USC 101. See 2019 PEG and MPEP 2106.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1--13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Crupi et al., US Patent Application Publication No US 2014/0351233 A1.
With respect to claims 1 and 15,
Crupi discloses,
a. scanning data for determining limited data to work on among data sets that are too large or complex to be dealt with (¶16: “the first source of the static data is from a different source than the second source of the real-time data, the combination of static data and real-time data is referenced in the query as a single variable, and the processor is further configured to determine a source of the data, the data being referenced in the single variable, and to process the data differently based on the source of the data”; ¶40: “FIG. 9 is a block diagram illustrating the process flow of the analytic engine when it selects the proper data scanner referenced in the "from" variable of the RAQL query”; ¶56: “a new analytics language that can handle large data”; ¶100: “Streaming data can arrive as large data sets that do not need to be all loaded into memory at one time”;¶102: “)for sorting and grouping of data, when large amounts of memory are needed, it is stored so that it won't occupy all of the JVM. Also, when doing aggregate or window functions, the system can leverage streaming along with in-memory. The excess data can be stored in in-memory. The goal is to avoid, for certain types of operations (for example, filter), having all of the data in memory”)
iv. scans data for determining limited data to work on among data sets that are too large or complex to be dealt with (¶16: “the first source of the static data is from a different source than the second source of the real-time data, the combination of static data and real-time data is referenced in the query as a single variable, and the processor is further configured to determine a source of the data, the data being referenced in the single variable, and to process the data differently based on the source of the data”; ¶40: “FIG. 9 is a block diagram illustrating the process flow of the analytic engine when it selects the proper data scanner referenced in the "from" variable of the RAQL query”; ¶56: “a new analytics language that can handle large data”; ¶100: “Streaming data can arrive as large data sets that do not need to be all loaded into memory at one time”;¶102: “)for sorting and grouping of data, when large amounts of memory are needed, it is stored so that it won't occupy all of the JVM. Also, when doing aggregate or window functions, the system can leverage streaming along with in-memory. The excess data can be stored in in-memory. The goal is to avoid, for certain types of operations (for example, filter), having all of the data in memory”)
b. drilling down to the next data that correlates with the previously determined limited data until obtaining a desired number of workable live results (¶19: “analyze the real-time data and the existing static data which are temporally correlated, in a moving window of the real-time data, as streaming data; and discard the real-time data which has been analyzed and temporally correlated to make room for the real-time data which continues to be received”; ¶20: “the processor is further configured to store information about a running calculation being made by the analytic function, to re-use the information about the running calculation in continuously performing the analytic function with the real-time data which is newly received”; ¶62: “The new query language has an engine underneath. In an example of 10 mb of data, a tree has to be created in a conventional approach and then it can be queried… In the new query language, chunks of data can be processed instead, which avoids requiring lots of memory. The chunks can be discarded when done”; ¶63: “the ability to support hierarchical and streaming data; (6) a functionality that works with static and real-time data; (7) the ability to run the new query language dynamically, including the ability of the new query language to discover the data format without being aware of a priori the data structures; (8) analytic data cubes for the new query language; and (9) an expanded discussion of the mechanism”; ¶159: “"Live data" can mean data that is coming in which is being reviewed and applied against historical information; live data has not been stored as historical data. "Live data" is not necessarily streaming data”) Examiner interprets at least the “real-time data which is newly received” of Crupi as teaching applicant’s “workable live results”
v. drills down to the next data that correlates with the previously determined limited data until obtaining a desired number of workable live results suitable to manage by traditional data-processing application software (¶19: “analyze the real-time data and the existing static data which are temporally correlated, in a moving window of the real-time data, as streaming data; and discard the real-time data which has been analyzed and temporally correlated to make room for the real-time data which continues to be received”; ¶20: “the processor is further configured to store information about a running calculation being made by the analytic function, to re-use the information about the running calculation in continuously performing the analytic function with the real-time data which is newly received”; ¶62: “The new query language has an engine underneath. In an example of 10 mb of data, a tree has to be created in a conventional approach and then it can be queried… In the new query language, chunks of data can be processed instead, which avoids requiring lots of memory. The chunks can be discarded when done”; ¶63: “the ability to support hierarchical and streaming data; (6) a functionality that works with static and real-time data; (7) the ability to run the new query language dynamically, including the ability of the new query language to discover the data format without being aware of a priori the data structures; (8) analytic data cubes for the new query language; and (9) an expanded discussion of the mechanism”; ¶159: “"Live data" can mean data that is coming in which is being reviewed and applied against historical information; live data has not been stored as historical data. "Live data" is not necessarily streaming data”) Examiner interprets at least the “real-time data which is newly received” of Crupi as teaching applicant’s “workable live results”.
Crupi discloses a method/system for continuous analytics on a combination of static and real-time data when data is exceptionally large, whereby a result of the analytic function is produced, stored and time-stamped in memory storage. Crupi further discloses a streaming mechanism, iteration and chunking techniques to avoid loading all of the large data into memory at one time. The system can bring big data into memory in chunks, operate on the chunk, send the operated chunk to the client, and bring in the next chunk. Crupi teaches that the system can read each record, see if it validates and if not successful the record is not stored anywhere via a filter operation based on user specified chunk size (partition size).
Examiner asserts that the claim would have been obvious since all of the claimed elements (scanning data, drilling down, determining limited data) were known in Crupi, and one skilled in the art before the effective filing date of applicant’s invention could have combined the elements as claimed with the known techniques of Crupi with no change in their respective functions and the combination would yield nothing more than predictable results to one of ordinary skill in the art. Narrowing the percentages of data to work on to about 20% of the entire data set would have been predictable based on the streaming mechanism, filtering operation based on user specified chunk size, iteration and chunking techniques for large data) as taught by Crupi.
c. saving the results as new data that capture only limited capacity, thereby providing an in-house collection that, due to its limited capacity, information can be retrieved and worked on it live (¶23: “in response to receiving the query that indicates the analytic function to be performed on the combination of static data and real-time data: loading, by a processor, an in-memory storage from a first source external to the processor with data which was stored as the static data; at the same time that the in-memory storage is already loaded with the static data, continuously receiving, by the processor, real-time data as it is being generated by a second source external to the processor, the real-time data being ephemeral; in response to the real-time data which is continuously received subsequent to receipt of the query: temporally correlating, by the processor, the real-time data with existing static data in the in-memory storage; and continuously running, by the processor, the analytic function from the query against, in combination, both the real-time data which is being continuously received and the existing static data which is loaded in the in-memory storage and which is temporally correlated to the real-time data, to continuously produce a result of the analytic function”; ¶47: “continuously analyze data which is based on a combination of static (non-changing) temporal data and real-time temporal data (data that is continuously changing). Real-world operational decisions need decisions that are based on analytics derived from data that is changing and data "at rest.", ¶66: “With temporal data there can be a real-time nature of the data; data can be real-time; can be large data sets; and/or can be arbitrary data sets "in memory". There can be a time stamp of the record, or a single time stamp of a set of records, and/or a single time stamp on a chunk of records (also referred to as a "record chunk"). As a consequence, the mechanism using the new query language is not tied to the data source”; ¶67: “For the time stamping, when querying large data sets, the results are stored into "in-memory" stores. A query is done, and if intermediate result sets are acquired, they are stored into the memory with time stamps on the information. Thus, if dealing with data which changes constantly, data can be compared/analyzed on a temporal basis. Every time data is stored in the memory, it is time stamped. Every record and every chunk of record can be time stamped. Further queries can be run on a temporal basis”). Examiner interprets applicant’s “work on it live” as “real-time”.
vi. saves the results as new data that capture only limited capacity, thereby providing an in-house collection that, due to its limited capacity, information can be retrieved and worked on it live (¶23: “in response to receiving the query that indicates the analytic function to be performed on the combination of static data and real-time data: loading, by a processor, an in-memory storage from a first source external to the processor with data which was stored as the static data; at the same time that the in-memory storage is already loaded with the static data, continuously receiving, by the processor, real-time data as it is being generated by a second source external to the processor, the real-time data being ephemeral; in response to the real-time data which is continuously received subsequent to receipt of the query: temporally correlating, by the processor, the real-time data with existing static data in the in-memory storage; and continuously running, by the processor, the analytic function from the query against, in combination, both the real-time data which is being continuously received and the existing static data which is loaded in the in-memory storage and which is temporally correlated to the real-time data, to continuously produce a result of the analytic function”; ¶47: “continuously analyze data which is based on a combination of static (non-changing) temporal data and real-time temporal data (data that is continuously changing). Real-world operational decisions need decisions that are based on analytics derived from data that is changing and data "at rest.", ¶66: “With temporal data there can be a real-time nature of the data; data can be real-time; can be large data sets; and/or can be arbitrary data sets "in memory". There can be a time stamp of the record, or a single time stamp of a set of records, and/or a single time stamp on a chunk of records (also referred to as a "record chunk"). As a consequence, the mechanism using the new query language is not tied to the data source”; ¶67: “For the time stamping, when querying large data sets, the results are stored into "in-memory" stores. A query is done, and if intermediate result sets are acquired, they are stored into the memory with time stamps on the information. Thus, if dealing with data which changes constantly, data can be compared/analyzed on a temporal basis. Every time data is stored in the memory, it is time stamped. Every record and every chunk of record can be time stamped. Further queries can be run on a temporal basis”). Examiner interprets applicant’s “work on it live” as “real-time”.
c) at least one processor; and d) a memory comprising computer-readable instructions which when executed by the at least one processor causes the processor to execute an Al workflow, wherein the Al workflow: (¶172: “Responsive to signaling from the user input device 135, in accordance with instructions stored in memory 107, or automatically upon receipt of certain information via the communication port and/or transceiver 103, the processor 105 may direct the execution of the stored programs”)
With respect to claim 2,
Crupi discloses all of the above limitations, Crupi further discloses,
wherein the scan determines the percentage of data to work on among the entire data set (¶101-104, ¶101: “Iteration and chunking can be used to avoid loading all of the data… The system can bring the big data into memory in "chunks" operate on the chunk, send the operated-on chunk to the client, and bring in the next chunk”; ¶102: “for sorting and grouping of data, when large amounts of memory are needed, it is stored so that it won't occupy all of the JVM. Also, when doing aggregate or window functions, the system can leverage streaming along with in-memory. The excess data can be stored in in-memory… The goal is to avoid, for certain types of operations (for example, filter), having all of the data in memory”; ¶103: With respect to "chunking," consider 1 million records and a filter operation. The system can read each record, see if it validates, and if not successful the record is discarded/not stored anywhere. The chunk can be just one record. If the data is stored in-memory: the user can specify the chunk-size (=partition size), for example, 10,000 records. The system can read in and store the records in buckets of 10,000 tuples. The operation, for example, a filter operation, will be read in 10,000 chunks, operate on them, and then push them out to the client”; ¶104: “the system can repeatedly validate, discard or forward depending on validation results”; ¶409: “The innermost query groups stocks data by year and quarter and calculates the average volume for each group. These results are used in the middle subquery to retrieve the previous quarter's average volume for each row and then calculate the percentage of change using a simple math expression”) Examiner interprets at least the system for streaming, iteration and chunking of data, filtering operation and grouping techniques as taught by Crupi as teaching applicant’s limitation, “wherein the scan determines the percentage of data to work on among the entire data set”.
With respect to claim 3,
Crupi discloses all of the above limitations, Crupi further discloses,
wherein the percentages of data to work on is about 20% of the entire data set (¶101-104, ¶101: “Iteration and chunking can be used to avoid loading all of the data… The system can bring the big data into memory in "chunks" operate on the chunk, send the operated-on chunk to the client, and bring in the next chunk”; ¶102: “for sorting and grouping of data, when large amounts of memory are needed, it is stored so that it won't occupy all of the JVM. Also, when doing aggregate or window functions, the system can leverage streaming along with in-memory. The excess data can be stored in in-memory… The goal is to avoid, for certain types of operations (for example, filter), having all of the data in memory”; ¶103: “With respect to "chunking," consider 1 million records and a filter operation. The system can read each record, see if it validates, and if not successful the record is discarded/not stored anywhere. The chunk can be just one record. If the data is stored in-memory: the user can specify the chunk-size (=partition size), for example, 10,000 records. The system can read in and store the records in buckets of 10,000 tuples. The operation, for example, a filter operation, will be read in 10,000 chunks, operate on them, and then push them out to the client”; ¶104: “the system can repeatedly validate, discard or forward depending on validation results”; ¶409: “The innermost query groups stocks data by year and quarter and calculates the average volume for each group. These results are used in the middle subquery to retrieve the previous quarter's average volume for each row and then calculate the percentage of change using a simple math expression …The final outer query then filters the results to include only those rows where the percentage of change is greater than 15%.”)
Crupi discloses a method/system for continuous analytics on a combination of static and real-time data when data is exceptionally large, whereby a result of the analytic function is produced, stored and time-stamped in memory storage. Crupi further discloses a streaming mechanism, iteration and chunking techniques to avoid loading all of the large data into memory at one time. The system can bring big data into memory in chunks, operate on the chunk, send the operated chunk to the client, and bring in the next chunk. Crupi teaches that the system can read each record, see if it validates and if not successful the record is not stored anywhere via a filter operation based on user specified chunk size (partition size).
Examiner asserts that the claim would have been obvious since all of the claimed elements were known in Crupi, and one skilled in the art before the effective filing date of applicant’s invention could have combined the elements as claimed with the known techniques of Crupi with no change in their respective functions and the combination would yield nothing more than predictable results to one of ordinary skill in the art. Narrowing the percentages of data to work on to about 20% of the entire data set would have been predictable based on the streaming mechanism, filtering operation based on user specified chunk size, iteration, grouping and chunking techniques for large data as taught by Crupi.
With respect to claim 4,
Crupi discloses all of the above limitations, Crupi further discloses,
wherein the desired number of workable live results are up to 1000 workable live results (¶101-104, ¶101: “Iteration and chunking can be used to avoid loading all of the data… The system can bring the big data into memory in "chunks" operate on the chunk, send the operated-on chunk to the client, and bring in the next chunk”; ¶102: “for sorting and grouping of data, when large amounts of memory are needed, it is stored so that it won't occupy all of the JVM. Also, when doing aggregate or window functions, the system can leverage streaming along with in-memory. The excess data can be stored in in-memory… The goal is to avoid, for certain types of operations (for example, filter), having all of the data in memory”; ¶103: “With respect to "chunking," consider 1 million records and a filter operation. The system can read each record, see if it validates, and if not successful the record is discarded/not stored anywhere. The chunk can be just one record. If the data is stored in-memory: the user can specify the chunk-size (=partition size), for example, 10,000 records. The system can read in and store the records in buckets of 10,000 tuples. The operation, for example, a filter operation, will be read in 10,000 chunks, operate on them, and then push them out to the client”; ¶104: “the system can repeatedly validate, discard or forward depending on validation results”; ¶409: “The innermost query groups stocks data by year and quarter and calculates the average volume for each group. These results are used in the middle subquery to retrieve the previous quarter's average volume for each row and then calculate the percentage of change using a simple math expression …The final outer query then filters the results to include only those rows where the percentage of change is greater than 15%.”)
Examiner asserts that the claim would have been obvious since all of the claimed elements were known in Crupi, and one skilled in the art before the effective filing date of applicant’s invention could have combined the elements as claimed with the known techniques of Crupi with no change in their respective functions and the combination would yield nothing more than predictable results to one of ordinary skill in the art. Narrowing the desired number of workable live results up to 1000 would have been predictable based on the streaming mechanism, filtering operation based on user specified chunk size, iteration, grouping and chunking techniques for large data as taught by Crupi.
With respect to claim 5,
Crupi discloses all of the above limitations, Crupi further discloses,
wherein a procedure to drill down from the entire data set configured to run until reveling the desired number of workable live results (¶21: “ According to another embodiment, the combination of static and real-time data indicated in the query which is received and on which the analytic function is performed, indicates at least one of:… 3) combinations of different types of static data and real-time data; and the processor is further configured to: normalize the at least one of:… the combinations of different types of static data and real-time data, into normalized data which is stored in the in-memory storage in the form of a tuple. The analytic function which is run is applied against the normalized data stored in the in-memory storage”; ¶23: “a method for continuous analytics run against a combination of static and real-time data. The method comprises: receiving, in a query engine, from a client, a query that indicates an analytic function to be performed on a combination of static data and real-time data…continuously running, by the processor, the analytic function from the query against, in combination, both the real-time data which is being continuously received and the existing static data which is loaded in the in-memory storage and which is temporally correlated to the real-time data, to continuously produce a result of the analytic function”; ¶47: “a mechanism to continuously analyze data which is based on a combination of static (non-changing) temporal data and real-time temporal data (data that is continuously changing). Real-world operational decisions need decisions that are based on analytics derived from data that is changing and data "at rest.", ¶66: “With temporal data there can be a real-time nature of the data; data can be real-time; can be large data sets; and/or can be arbitrary data sets "in memory"; ¶67: “if dealing with data which changes constantly, data can be compared/analyzed on a temporal basis. Every time data is stored in the memory, it is time stamped. Every record and every chunk of record can be time stamped. Further queries can be run on a temporal basis. For example, an initial query is done and the original time stamped results are stored; a later query is done which specifies, for example, time1 to time2. Consequently, temporal analyses and comparisons can be performed.”; ¶101-104; ¶101: “Iteration and chunking can be used to avoid loading all of the data… The system can bring the big data into memory in "chunks" operate on the chunk, send the operated-on chunk to the client, and bring in the next chunk”; ¶102: “for sorting and grouping of data, when large amounts of memory are needed, it is stored so that it won't occupy all of the JVM. Also, when doing aggregate or window functions, the system can leverage streaming along with in-memory. The excess data can be stored in in-memory… The goal is to avoid, for certain types of operations (for example, filter), having all of the data in memory”; ¶103: “With respect to "chunking," consider 1 million records and a filter operation. The system can read each record, see if it validates, and if not successful the record is discarded/not stored anywhere. The chunk can be just one record. If the data is stored in-memory: the user can specify the chunk-size (=partition size), for example, 10,000 records. The system can read in and store the records in buckets of 10,000 tuples. The operation, for example, a filter operation, will be read in 10,000 chunks, operate on them, and then push them out to the client”; ¶104: “the system can repeatedly validate, discard or forward depending on validation results”)
With respect to claim 6,
Crupi discloses all of the above limitations, Crupi further discloses,
wherein the method is applied in parallel on any other pre-determined outcome to receive multiple outlets and save them as very small data capacity, thereby enabling prompt access and visualization (¶115: “The system can pre-compute and store small sets of analytics about a data source that is repeatedly requested by a user. Analytic cubes can be created dynamically or in advance. Analytic cubes can be thought of as analytics which are stored in-memory for direct queries or as data provided for subsequent analytic queries… the system can aggregate this information into a structure, which is sometimes referred to herein as an "analytic data cube" or a "mini-cube" which are the same thing. Then, instead of going through all of the data in response to a subsequent query on the data source, the system can just examine the mini-cube and retrieve the information from the mini-cube. The information stored in the mini-cube may not be 100% current, but it is good enough for further aggregations or analytics on the data source”; ¶258: “You use mashups in Presto to access and work with small or large datasets. To work with large datasets, mashups use EMML extension statements specifically designed for Presto Analytics and the RAQL query language”)
With respect to claim 7,
Crupi discloses all of the above limitations, Crupi further discloses,
further comprising assigning a number for each obtained result, wherein each result configured with a top number in accordance with applied statistics score that includes: sum, average, top, and low (¶24: “in response to a command that indicates an analytic function to be performed on at least real-time data: continuously receiving, by the processor, real-time data as it is being generated by a source external to the processor, the real-time data being ephemeral; in response to the real-time data which is continuously received subsequent to the command: continuously running, by the processor, the analytic function from the command against the at least real-time data which is being continuously received, to continuously produce a result of the analytic function… and in response to a subsequent calculation for the real-time data having a time period which includes the time stamp, re-using, by the processor, the result of the analytic function from the in-memory storage based on the time stamp associated therewith, together with the real-time data which is newly received, as a source of data for the subsequent calculation”; ¶123: “Data cubes are modeled in EMML. The cubes specify assorted data sources, which may include, but are not limited to, data that is purely static (files); updatable datasets (SQL, Service); and/or real-time streaming channels. Data cubes measure aggregates and machine learning functions (kmeans, linear/logistic regression) to be computed. The measures can be computed both in batch and incrementally. Caches, such as Big Memory cache, can be associated with data cubes”; Fig 12,