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 .
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 USC 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1 recites
1. A computer-implemented method, wherein the method is performed using one or more processors, the method comprising:
providing or generating a plurality of code branches associated with a plurality of code sets which, when executed, produce respective datasets, stored in one or more memory locations;
upon determining that one or more code sets executed by one of the code branches failed to commit, regenerating a respective code branch and
reexecuting the respective code branch until the one or more code sets have successfully committed;
and upon determining that code sets executed by the plurality of code branches have successfully committed,
updating other code branches and
updating a downstream process.
Examiner finds that the emphasized portions of claim 1 above recite an abstract idea—namely, mental processes. See MPEP 2106.04(a)(2)(III):
Accordingly, the ‘mental processes’ abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, judgments, and opinions
When read as a whole, the recited limitations are directed to using mental steps to observe, evaluate, and make judgements about electronic data. Stated another way, Examiner finds the abstract idea elements recite observing and evaluating errors in computer code and using judgment to correct those errors.
Taking each element individually, Examiner provides the following analysis:
Bolded Abstract Idea Claim Elements
Examiner analysis of bolded abstract idea elements considered individually
Relevant MPEP sections
Providing or generating a plurality of code branches associated with a plurality of code sets which, when executed, produce respective datasets, stored in one or more memory locations;
This element merely recites using human judgment to craft computer code that will produce datasets. Examiner finds the clause “when executed, produce respective datasets, stored in one or more memory locations” (emphasis added) has no patentable weight because it does not cause any steps to be performed.
2106.04(a)(2)(III);
2111.04
upon determining that one or more code sets executed by one of the code branches failed to commit, regenerating a respective code branch and updating other code branches
Determining whether code set fails to commit merely requires observation and evaluation of the commit process. Regenerating merely requires human evaluation and judgment as to which code branches caused the error and judgment as to how to correct the error (i.e. how to regenerate (fix) and update the code).
2106.04(a)(2)(III);
Turning to the additional elements and whether they integrate the exception or recite an inventive concept, Examiner provides the following analysis:
Italicized Additional elements
Examiner analysis of italicized additional elements and whether they integrate the exception and whether they recite an inventive concept.
Relevant MPEP sections
1. A computer-implemented method, wherein the method is performed using one or more processors, the method comprising:
This element recites mere instructions to apply the exception and thus does not integrate the exception and does not recite an inventive concept.
2106.05(f)
reexecuting the respective code branch until the one or more code sets have successfully committed;
This element generally links the abstract ide to the field of use of computer programming. It does not integrate the exception and does not recite an inventive concept.
2106.05(h)
updating a downstream process
This element recites mere data gathering (i.e. an insignificant extra solution activity) and thus fails to integrate the exception.
This element recites a well-understood, routine, and conventional (WURC) computer function (storing and retrieving information in memory; electronic recordkeeping) and thus fails to recite an inventive process.
2106.05(g)
2106.05(d)(II)
The additional elements above “[a]dd nothing … that is not already present when the steps are considered separately’”. MPEP 2106.05 (I)(B)(quoting Alice).
When considered as a whole claim 1 recites observing and evaluating errors in computer code and using judgment to correct those errors without significantly more.
As such, when the claim elements are considered as a whole and individually, claim 1 recites an abstract idea without significantly more.
Claims 8 and 15 are also rejected for the reasons given above for claim 1. Additionally, the elements “A computing system comprising :one or more processors; and memory storing instructions that, when executed by the one or more processors cause the computing system to perform:” and “A computer program product comprising a non-transitory computer-readable medium readable by a processing circuit, the non-transitory computer-readable medium storing instructions executable by the processing circuit to cause a method to be performed” recite mere instructions to apply the exception and thus do not integrate or recite an inventive concept.
Dependent claims 2-7 are rejected under 35 USC 101 for the reasons indicated below.
Claim
Abstract idea = bold
Additional element = italics
Analysis
MPEP
2. . .
determining that one or more code sets executed by one of the code branches failed to commit,
This element merely requires observation and evaluation of the execution of the code set and a judgment as to whether the commit failed or not.
2106.04(a)(2)(III);
deleting a downstream or dependent code branch.
This element recites Selecting a particular data source or type of data to be manipulated and thus fails to integrate the exception.
Examiner takes official notice that deleting a downstream or dependent code branch was a WURC computer function at the time of filing. This element fails to recite an inventive concept.
2106.05(g)
2106.05(d)(I)
3. The computer-implemented method of claim 1, wherein the method further comprises: detecting an updating event associated with a first code branch;
Detecting an updating event merely requires observation and evaluation of the code and a judgment as to whether the code contains an updating event.
2106.04(a)(2)(III)
And generating a second code branch and
This element merely requires judgment on the part of human as to how to generate the code branch.
2106.04(a)(2)(III)
executing the plurality of code sets responsive to detection of the updating event.
This element recites mere instructions to apply the exception. It does not integrate or recite an inventive concept.
2106.05(f)
4. The computer-implemented method of claim 1, wherein the update to the downstream process indicates that time-series datasets generated upon the code sets successfully committing are stored in a memory
This element recites mere data gathering (i.e. an insignificant extra solution activity) and thus fails to integrate the exception.
This element recites a well-understood, routine, and conventional (WURC) computer function (storing and retrieving information in memory; electronic recordkeeping) and thus fails to recite an inventive process.
2106.05(g)
2106.05(d)(II)
5. The computer-implemented method of claim 1, wherein determining that one or more code sets executed by one of the code branches failed to commit comprises detecting an error in a code set, detecting unavailability of raw data relied upon or referenced by the code sets
This element merely requires observation and evaluation of the code set and an evaluation/judgment as to whether there is an error in the set.
2106.04(a)(2)(III)
or determining that the raw data is nonconforming to an ontology according to the one or more code sets.
This element merely requires observation and evaluation of the ontology and an evaluation/judgment as to whether the data conforms to the ontology.
2106.04(a)(2)(III);
6. The computer-implemented method of claim 1, wherein each code branch corresponds to a different version of generated time-series datasets.
This element merely requires human judgment as to how to craft the code such that it corresponds to a different version of generated time-series datasets.
2106.04(a)(2)(III)
7. The computer-implemented method of claim 1, wherein the plurality of code sets comprise code which, when executed, receives or causes receipt of, in one time-series dataset, data representing component failure reports and, in another time-series dataset, data representing at least a set of entities and constituent components of the entities,
This element recite mere data gathering (i.e. an insignificant extra solution activity) and thus fails to integrate the exception.
This element recites a well-understood, routine, and conventional (WURC) computer function (storing and retrieving information in memory; electronic recordkeeping) and thus fails to recite an inventive process.
2106.05(g)
2106.05(d)(II)
the downstream process being configured to
This purely functional limitation fails to recite how to configure the process and thus recites mere instruction to apply the exception. It does not integrate or recite an inventive concept.
2106.05(f)
When determining whether a claim simply recites a judicial exception with the words "apply it" (or an equivalent), such as mere instructions to implement an abstract idea on a computer, examiners may consider the following:
(1) Whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished.
identify entities having constituent components that require updating or servicing based on the component failure reports.
This element merely requires observation and evaluation of the datasets and an evaluation/judgment as to whether they contain entities having constituent component.
This element merely requires observation and evaluation of the failure reports and an evaluation/judgment as to whether the components require updating or servicing.
2106.04(a)(2)(III);
Claims 9-14 and 16-20 are rejected for the same reasons given above for claims 2-7.
The additional elements above “[a]dd nothing … that is not already present when the steps are considered separately’”. MPEP 2106.05 (I)(B)(quoting Alice).
When considered as a whole the claimed invention recites observing and evaluating errors in computer code and using judgment to correct those errors without significantly more,
As such, when the claim elements above are considered as a whole and individually, the claims recite an abstract idea without significantly more.
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(s) 1, 5-6, 8, 12-13, 15, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Baker US 20210064475 A1 in view of Lev US 7516366 B2.
With respect to claim 1, Baker (US 20210064475 A1) teaches “ A computer-implemented method, wherein the method is performed using one or more processors, the method comprising: providing or generating a plurality of code branches associated with a plurality of code sets which, when executed, produce respective datasets, stored in one or more memory locations”
[0086] The example data management system 800 includes one or more applications 802, one or more services 804, one or more initial datasets 806, and a data transformation process 808 (also referred to herein as a build process). The data management system 800 can transform data and record the data transformations. The one or more applications 802 can include applications that enable users to view datasets, interact with datasets, filter data sets, and/or configure dataset transformation processes or builds. The one or more services 804 can include services that can trigger the data transformation builds and API services for receiving and transmitting data. The one or more initial datasets 806 can be automatically retrieved from external sources and/or can be manually imported by a user. The one or more initial datasets 806 can be in many different formats such as a tabular data format (SQL, delimited, or a spreadsheet data format), a data log format (such as network logs), or time series data (such as sensor data).
[0095] The catalog may store information representing a non-linear history of a dataset. Specifically, the history of a dataset may have different dataset branches. Branching may be used to allow one set of changes to a dataset to be made independent and concurrently of another set of changes to the dataset. The catalog may store branch names in association with dataset version identifiers for identifying dataset items that belong to a particular dataset branch.
[0103] The data management system 800 can support branching for both data and code. Build branches allow the same transformation code to be executed on multiple branches. For example, transformation code on the master branch can be executed to produce a dataset on the master branch or on another branch (e.g., the develop branch). Build branches also allow transformation code on a branch to be executed to produce datasets on that branch. For example, transformation code on a development branch can be executed to produce a dataset that is available only on the development branch. Build branches provide isolation of re-computation of graph data across different users and across different execution schedules of a data management. To support branching, the catalog may store information represents a graph of dependencies as opposed to a linear dependency sequence.
It appears Baker fails to explicitly teach “upon determining that one or more code sets executed by one of the code branches failed to commit, regenerating a respective code branch and reexecuting the respective code branch until the one or more code sets have successfully committed; and”
“upon determining that code sets executed by the plurality of code branches have successfully committed, updating other code branches and updating a downstream process”
However, Lev US 7516366 B2 teaches ““upon determining that one or more code sets executed by one of the code branches failed to commit, regenerating a respective code branch and reexecuting the respective code branch until the one or more code sets have successfully committed” in col. 17:34-45:
(79) For brevity, code related to retrying the transaction if the split hardware transaction fails to commit has been omitted from the above pseudo-code. In the exemplary pseudo-code above, SpHT_resume in function foo( ) is passed a different fail address than passed to SpHT_begin and SpHT_resume. Thus, if the function body fails to execute atomically, execution branches to the function exit code prior to returning to the calling function. Also, prior to returning to the caller, SpHT_failed is called, which notifies the SpHT mechanism that part of the SpHT failed and that a subsequent SpHT_resume executed by the caller must immediately fail
col. 19:30-40:
In some embodiments, retrying the child code sequence may include restoring the read and/or write sets of the atomic block according to the checkpoint saved before initial execution of the child transaction. In this way, the child transaction may be re-executed consistent with the state of the execution of the atomic block up to, but not including, the failed child transaction. In other words, in such embodiments, the child transaction may be re-executed as if no read and/or write accesses targeted to the shared memory have been performed since the last checkpoint was saved.
(Examiner finds restoring teaches regenerating);
“upon determining that code sets executed by the plurality of code branches have successfully committed, updating other code branches and updating a downstream process” in col. 12:50-59
(53) The example embodiment discussed above regarding FIG. 4 may have involved a split hardware transaction that uses two hardware transactions--one to initially read values from shared memory into the local buffer prior to performing an NHT operation and another to finish and commit the split hardware transaction after performing the NHT operation(s). In other embodiments, however, a split hardware transaction may utilize more than two hardware transactions. In general, a split hardware transaction may be implemented using virtually any number of hardware transactions.
col. 12:60-col. 13:10:
54) One reason the SpHT may be considered to be logically atomic is that each hardware transaction initiated by the SpHT may verify that all locations read by the SpHT so far have their pre-transactional values, as indicated by the read-set maintained in the thread-local buffer. An active hardware transaction of a split hardware transaction aborts if any relevant location has changed during execution of the split hardware transaction. This guarantees that as long as no active transaction is aborted, all values read by the SpHT represent a consistent view of memory. In particular, when the last hardware transaction, that copies the values from the thread-local write-set to shared memory, commits, all locations read by the SpHT are guaranteed to contain their pre-transactional values. Therefore the SpHT may seem to take effect atomically at this point, in which all values written by the SpHT become visible to all other threads, and all locations read by the SpHT are guaranteed to have their pre-transactional values.
(Examiner finds “all values. . . visible to all other threads” teaches updating a downstream process with the values).
Lev and Baker are analogous art because they are from the same field of endeavor.
It would have been obvious to one skilled in the art before the effective filing date of the invention to modify “A computer-implemented method, wherein the method is performed using one or more processors, the method comprising: providing or generating a plurality of code branches associated with a plurality of code sets which, when executed, produce respective datasets, stored in one or more memory locations” as taught by Baker to include “upon determining that one or more code sets executed by one of the code branches failed to commit, regenerating a respective code branch and reexecuting the respective code branch until the one or more code sets have successfully committed” and “upon determining that code sets executed by the plurality of code branches have successfully committed, updating other code branches and updating a downstream process” as taught by Lev.
The motivation would have been to maintain data integrity. See id (“Therefore the SpHT may seem to take effect atomically at this point, in which all values written by the SpHT become visible to all other threads, and all locations read by the SpHT are guaranteed to have their pre-transactional values.”).
With respect to claim 5, Lev teaches “The computer-implemented method of claim 1, wherein determining that one or more code sets executed by one of the code branches failed to commit comprises detecting an error in a code set, detecting unavailability of raw data relied upon or referenced by the code sets or determining that the raw data is nonconforming to an ontology according to the one or more code sets” in col. 31:39-51
Spawning each thread with its own stack and checkpoint may in some embodiments allow it to access them without synchronizing them with any other threads, and may allow the implementation of the stack and/or checkpoint to be relatively simple and efficient. In some embodiments, each thread may manipulate its stack in the same way as with the sequential algorithm. In particular, when a state is found invalid, it may be popped from the stack, and the next state may be tested. If, however, the last state on the thread's stack is popped after being found invalid, the thread may terminate with an error code, indicating to the spawning thread that the parent block should be retried.
(error code teaches detecting error in code set). The motivation to combine this portion of Lev with Baker is the same motivation given in claim 1 above.
With respect to claim 6, Baker teaches “6. The computer-implemented method of claim 1, wherein each code branch corresponds to a different version of generated time-series datasets.”
[0095] The catalog may store information representing a non-linear history of a dataset. Specifically, the history of a dataset may have different dataset branches. Branching may be used to allow one set of changes to a dataset to be made independent and concurrently of another set of changes to the dataset. The catalog may store branch names in association with dataset version identifiers for identifying dataset items that belong to a particular dataset branch.
Claim 8 and claim 15 are rejected for the reasons given above for claim 1.
Claims 12-13 and 19-20 are rejected for the same reasons given above for 5-6.
Claim(s) 2,9, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Baker (US 20210064475 A1) in view of Lev US 7516366 B2 as applied to claims 1, 8, and 15 above and further in view of Hwang US 11886439 B1.
With respect to claim 2, It appears Lev et al. fail to explicitly teach “2. The computer-implemented method of claim 1, wherein the method further comprises: determining that one or more code sets executed by one of the code branches failed to commit, deleting a downstream or dependent code branch.”
However, Hwang (US 11886439 B1) teaches “determining that one or more code sets executed by one of the code branches failed to commit, deleting a downstream or dependent code branch.” in col. 3:27-48
(17) In various embodiments, change indications may be first stored in memory 120 (e.g., volatile or non-volatile memory, such as memory 1020 in FIG. 10) as part of change indications 122. In at least some embodiments, the change indications may be grouped according to transaction, as discussed below with regard to FIGS. 5, 7 and 8. For example, data structures such as hash tables and/or queues may be created to separate change indications into the corresponding transaction that caused the change and then update the respective portion of the data structure to record that change indication as part of the transaction. Change indications 122 may be maintained in memory 120 (e.g., without ever storing the change indications to a second storage device, such as a persistent storage device) until sent 142 to stream processor 140 after the transaction is committed, after a transaction is determined to fail (in which case the change indication(s) for that transaction may be deleted), or if spill criteria for change indications 122 in memory 120 is satisfied and the transaction is selected to be spilled 124 to persistent storage 130 (e.g., a block-based storage device, such as a disk drive, solid-state drive, and so on).
Hwang and Lev et al. are analogous art because they are from the same field of endeavor. It would have been obvious to one skilled in the art before the effective filing date of the invention to modify the code sets in Lev et al. to include “determining that one or more code sets executed by one of the code branches failed to commit, deleting a downstream or dependent code branch” as taught by Ward et al. to include responsive to a negative determination deleting the second code branch as taught by Hwang.
The motivation would have been to save memory and/or disk space.
Claims 9 and 16 are rejected for the same reasons above.
Claim(s) 3-4 and 10-11 and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Baker (US 20210064475 A1) in view of Lev US 7516366 B2 as applied to claim 1 and 8 and 15 above and further in view of Ward 20170228405.
With respect to claim 3, it appears Lev et al. fails to explicitly teach “teaches “3. The computer-implemented method of claim 1, wherein the method further comprises: detecting an updating event associated with a first code branch and generating a second code branch and executing the plurality of code sets responsive to detection of the updating event.”
However, Ward teaches “The computer-implemented method of claim 1, wherein the method further comprises: detecting an updating event associated with a first code branch” in
[0045] It may be desirable in certain circumstances to generate one or more additional time-slice datasets (illustrative example shown in FIG. 5). One common scenario would be generation of new, later time-slice datasets as time passes and new time-series data is generated, with each new corresponding TSTI later than all others (except perhaps an “end-of-time’ slice as described earlier, if employed). In the drone example, a new time-slice dataset is generated every hour on the hour that is later than the existing time-slice datasets. More generally, a new time-slice might be inserted with a corresponding new TSTI between two other extant TSTIs among the time-slice datasets. In the drone example, it might be decided that TSTIs every hour are not sufficiently frequent, that every half-hour would be more suitable, and that new time-slice datasets should be generated.
(updating event is new time-series data).
and generating a second code branch and executing the plurality of code sets responsive to detection of the updating event.”
[0045] It may be desirable in certain circumstances to generate one or more additional time-slice datasets (illustrative example shown in FIG. 5). One common scenario would be generation of new, later time-slice datasets as time passes and new time-series data is generated, with each new corresponding TSTI later than all others (except perhaps an “end-of-time’ slice as described earlier, if employed). In the drone example, a new time-slice dataset is generated every hour on the hour that is later than the existing time-slice datasets. More generally, a new time-slice might be inserted with a corresponding new TSTI between two other extant TSTIs among the time-slice datasets. In the drone example, it might be decided that TSTIs every hour are not sufficiently frequent, that every half-hour would be more suitable, and that new time-slice datasets should be generated.
It would have been obvious to one skilled in the art before the effective filing date of the invention to modify the method in Lev et al. to include “wherein the method further comprises: detecting an updating event associated with a first code branch and generating a second code branch and executing the plurality of code sets responsive to detection of the updating event.” in as taught by Ward.
The motivation would have been to have up-to-date, relevant data for querying.
With respect to claim 4, it appears Lev et al. fails to explicitly teach “The computer-implemented method of claim 1, wherein the update to the downstream process indicates that time-series datasets generated upon the code sets successfully committing are stored in a memory location via an updated pointer from a code branch to the memory location.”
However, Ward teaches “wherein the update to the downstream process indicates that time-series datasets generated upon the code sets successfully committing are stored in a memory location via an updated pointer from a code branch to the memory location” in
[0052] After an new time-slice dataset is generated, it may be necessary or desirable to update one or more pointers of one or more later time-slice datasets. For several of the sequences described above, properly updated pointers in later time-slice datasets are necessary if those datasets are to be employed in the disclosed query methods and time-slice insertion methods. In certain instances it is preferable that later time-slice datasets not be updated (see below).
[0053] Assuming that one or more previously extant later time-slice datasets are to be updated after a new time-slice dataset is generated, only pointers for certain data fields need to be updated. Generally, any pointer of a later time-slice dataset that indicates a time-slice dataset earlier than the new time-slice dataset could be replaced with a new pointer that indicated the corresponding data string or pointer of the new time slice. More specifically, such pointers typically should be replaced in later time-slice data subsets that include at least one field for which a latest FVTI before the new TSTI was found that is also later than the first-earlier TSTI. It should be noted that “replacing” a pointer to an earlier data string or pointer with a new pointer to a later data string or pointer can be accomplished by replacing a single pointer or a first pointer of a sequence with a single, direct new pointer, or by replacing one or more or all of the pointers of a sequence.
Ward and Lev et al. are analogous art because they are from the same field of endeavor.
It would have been obvious to one skilled in the art before the effective filing date of the invention to modify the update to the downstream process in Lev et al. to include “wherein the update to the downstream process indicates that time-series datasets generated upon the code sets successfully committing are stored in a memory location via an updated pointer from a code branch to the memory location” as taught by Ward.
The motivation would have been to increase the speed at which the program is executed.
Claims 10-11 and 17-18 are rejected for the reasons given above for claims 3-4.
Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Baker (US 20210064475 A1) in view of Lev US 7516366 B2 as applied to claim 1 and 8 above and further in view of Kumar US-20180240290-A1.
With respect to claim 7, Baker et al. teaches at least two time-series datasets and a downstream process. See above and Baker para. 95. Baker et al. fails to explicitly teach “7. The computer-implemented method of claim 1, wherein the plurality of code sets comprise code which, when executed, receives or causes receipt of, in one time-series dataset, data representing component failure reports and, in another time-series dataset, data representing at least a set of entities and constituent components of the entities, the downstream process being configured to identify entities having constituent components that require updating or servicing based on the component failure reports.”
However, Kumar teaches “7. The computer-implemented method of claim 1, wherein the plurality of code sets comprise code which, when executed, receives or causes receipt of, in one time-series dataset, data representing component failure reports” in ¶ 38
[0038] A vehicle can also track correspondence to failure situations with regards to how long a particular part or system has been exposed to a deleterious condition. For example, a vehicle may receive information indicating that under certain heat and humidity conditions, a belt has a 20% likelihood of failure after 2000 hours of exposure, a 40% likelihood of failure after 3500 hours of exposure, and a 75% percent likelihood of failure after 6000 hours of exposure (these numbers being illustrative and hypothetical for the sake of the example provided). If a vehicle has currently only traveled (or been parked/stored) in areas corresponding to the identified condition for less than 500 hours, the system may elect to take no action, since failure is unlikely. In another instance, however, a person may indicate that they wish to avoid component-deteriorating conditions as much as possible, so the vehicle may determine coordinate sets (and/or geo-fences) for each deteriorating condition and recommend a route or parking location accordingly. In still another example, the vehicle may take a least-cost avoidance approach, considering a variety of variables to determine a whole cost-effective approach for a customer.
[0041] FIG. 2 shows an illustrative process for malfunction and condition data gathering. In this example, the process receives a repair or malfunction report from a vehicle diagnostic unit and/or a dealer or mechanic maintenance system 201. Since this is actual data of a malfunction, the system can use this data to attempt to pinpoint a cause or multiple possible causes of the particular malfunction. Also, in this example, the vehicle has been tracking travel (at least coordinates) data. The analytics system aggregates this travel data (which can include parking data) 203. If a vehicle gathers comprehensive data, the vehicle may actually have gathered weather (precipitation, humidity, temperature, etc.) 205 data and/or traffic data, and the analytics system may receive this data along with the travel data. In other examples, the travel data can be cross referenced with known environmental, travel and weather conditions (which can be looked up or reported by other vehicles over time) to establish a condition map of a given route. The system may also receive driver behavior data 207, which the vehicle can record and report. This can include a general profile (such as “cautious” or “aggressive”) or a more detailed report including acceleration habits, stopping habits, etc.
[0048] If a threshold number of vehicles traveling in a locality report a problem, this can be used as a basis for an assumption that traveling in the locality results in the reported problem. The boundaries of the locality can be defined, for example, as areas where correlation between problem-reporting vehicles diminishes (e.g., many vehicles may report being at various coordinates within a city, but those vehicles will likely have dissimilar exit patterns, so the overlap of coordinates will fall roughly within the boundaries of a city). In another example, the locality may be bounded by defined boundaries, such that sufficient reporting within the boundaries is enough to designate the entire area represented by the boundaries.
[0049] Timestamps associated with reported malfunctions can be used to bound a temporal snapshot for obtaining a baseline. During the time between when a first and last malfunction in a locality was reported, a total number of vehicles traveling in that locality can be estimated (or obtained through comprehensive reporting). If only one manufacturer receives data from their own vehicles, that data will at least be useful for considering malfunction likelihood with respect to that manufacturer's own vehicles and parts. The number of malfunctions can be compared to the number of vehicles to obtain a likelihood of malfunction. Iterations of this data, based on operating time, can be used to further refine the predictions (e.g., only vehicles with more than X hours of operation in the locality could be considered).
[0055] While the above data may not be extremely useful when considering a single vehicle, if reporting of the above data for 1000 vehicles occurred in a day, the dealer would expect to need 287 tires (this assumes that all 1000 vehicles are from the exact same dealer) and each of the 10 local centers would expect to need 19 tires (193/10). Recording data of actual observed occurrences may allow for more fine tuning of the above data, but this broad example shows the relevance of the types of determinations discussed herein. As the data can be refined with better correlation to variables and observed behavior, the number of projected needed tires should begin to closely approach the number of actual needed tires.
“in another time-series dataset, data representing at least a set of entities and constituent components of the entities, the downstream process being configured to identify entities having constituent components that require updating or servicing based on the component failure reports”
[0052] FIG. 4 shows an illustrative process for data analysis and customer reporting. In this example, the process receives the warning data issued from the FIG. 3 threshold analysis, indicating that a vehicle both contains a failure-candidate component and that conditions for possible failure have been met. The vehicle can compare the requirements for expected failure (e.g., travel time under the failure-associated conditions), looking at past, recorded travel, current conditions and expected upcoming conditions. If there is a correlation between travel conditions and an expected degree of failure that is designated to merit reporting 405, the process may alert both the driver 407 and an associated dealer 409. The “associated dealer” may be a vehicle-associated dealer (the dealer who sold the vehicle), or a driver identified preferred dealer or service center. In other examples, the report may also be sent to dealers in a local region and/or a driver identified home-region. Based on comparison of a likelihood of failure and a likelihood of a driver using a particular dealer (which can be known to some extent based on observed behavior), each and any dealer can make an assessment as to the likely need for a part. Aggregating all of these assessments will allow the dealer to predict likely part need.
[0053] For example, a driver may receive a warning that a tire will likely fail with a 20% threshold. This warning may be issued to local tire dealers and to a driver-preferred service location. Drivers may (based on observed history) have tires fixed wherever the blow-out occurs with 95% frequency and at a preferred dealer with a 5% frequency. There may also be 10 tire-repair stores that are local to the driver location, which all receive the notification. Drivers may also be observed to address tire potential issues with 35% frequency at a 20% likelihood of failure (i.e., perform preventative replacement). In those cases, drivers may be observed to address the issue at a preferred location 80% of the time and at a local tire dealer 20% of the time.
[0057] FIG. 5 shows an illustrative process for dealer reporting. In this example, the process receives customer data, such as that described above 501. For example, the process can receive an identification of likely-failing parts, a chance of failure and any relevant customer information. The process may elect to send a notification to the customer in this example 503, which could include an offer for service and, for example, a coupon. In some instances, whether or not the customer is contacted can depend on the customer's observed reception to previous such contacts and/or the actual likelihood of failure. Another factor the process could consider would be the cost of later repair vs. maintenance repair (e.g. the cost of replacing a tire may be the same, although a blowout may involve a tow and time in addition, or, e.g., the cost of replacing an engine component may be low, but the cost of replacing a much more expensive component may be expected if the first component fails—the notification may be sent at a lower likelihood threshold with regards to the second example, in order to avoid a high-cost repair).
Baker et al. and Kumar are analogous art because they are from the same field of endeavor as the claimed invention.
It would have been obvious to one skilled in the art before the effective filing date of the invention to modify the at least two time-series datasets in Baker et al. to include “7. The computer-implemented method of claim 1, wherein the plurality of code sets comprise code which, when executed, receives or causes receipt of, in one time-series dataset, data representing component failure reports and, in another time-series dataset, data representing at least a set of entities and constituent components of the entities, the downstream process being configured to identify entities having constituent components that require updating or servicing based on the component failure reports.” as taught by Kumar.
It would have been obvious to one skilled in the art before the effective filing date of the invention to modify the downstream process taught in Baker et al. to include “being configured to identify entities having constituent components that require updating or servicing based on the component failure reports” as taught by Kumar.
The motivation would have been to allow a user or dealer to accurately predict inventory needed for repairs. See Kumar ¶ 46 and ¶ 47.
Claim 14 is rejected for the reasons above given for claim 7.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALBERT M PHILLIPS, III whose telephone number is (571)270-3256. The examiner can normally be reached 10a-6:30pm EST M-F.
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, Ann J Lo can be reached at (571) 272-9767. 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.
/ALBERT M PHILLIPS, III/Primary Examiner, Art Unit 2159
Prosecution Insights