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 .
Priority
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994)
The disclosure of the prior-filed applications, Application No. 15/268,802, 62/221,124, 15/077,626, 62/137,079 fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. Only a claim with all of its limitations fully supported by the disclosure of the parent application is entitled to the parent’s earlier priority date. Claims 1 and 14, include subject matter not covered by prior filed applications and therefore will not be granted a priority date of prior filed applications. The rest of the claims depend on claims 1 and 14 and therefore will also not be granted a filing date based on the prior filed applications.
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 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 of this title, 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, 30, 32 in view of are/is rejected under 35 U.S.C. 103 as being unpatentable over Rodriguez et al. US2018/0032980 in view of Prasad et al. US8381094 in view of Akoglu US2013/0151536 in view of Muller et al. US2018/0288506
Regarding claim 1, Rodriguez teaches: A method for an automated invoice payment for goods/services using a finite-state automation with marketplace-hosted third-party interaction the method comprising the steps of: (Rodriguez see paragraphs 0002 0036-0039 0098 state machine in conjunction with electronic bill presentation and payment system sending users invoices from business online used by biller for customer to make invoice payments on payment application. State machine reads on finite state automation, business reads on marketplace-hosted third party, electronic invoice payment for services reads on invoice payment for goods)
Defining a listing of necessary states for a plurality of a data processing tasks to enable automated invoice payment, wherein defining the listing of necessary states comprises defining the following:
awaiting a bank customer in whose name an invoice is issued to enter a service channel, awaiting delivery of the invoice to customer, and awaiting the bank customer consent to pay; (Rodriguez see paragraph 0003 0039 0040 0079 0098 0099 user in financial institution submits request to view or pay bill starting workflow, then in view state invoice bills are retrieved and presented to the user, then state machine transitions to next state where user inputs information for bill payment. Start state to start workflow and pay for bill reads on enter a service channel, invoice being retrieved for customer reads on awaiting delivery of an invoice to customer, user inputting payment info and processing payment reads on consent to pay, financial institution reads on bank)
determining data parameters used for designation of the necessary states, wherein determining the data parameters comprises determining the data parameters that relate at least to a service type, a customer ID, and an invoice amount; (Rodriguez see paragraph 0098 0099 see figure 12 invoice used in state machine for cellular phone bill to make a bill payment includes customer name and customer ID, invoice amount, invoice description. User inputs payment information to select bill payment as an example of another state. Cellular phone and invoice description and bill payment reads on service type, customer name and customer ID reads on customer ID, invoice amount reads on invoice amount, inputted information for bill payment also reads on data parameters)
assembling the data structure and a process corresponding to information about at least the necessary states of the data processing tasks, passing requests through a graph of the data processing tasks upon occurrence of an event corresponding to at least one data processing task, the system moves to a next state, wherein the event is at least one of the following:
presence of the customers presence in the service channel, delivery of the invoice, or confirmed customer consent to pay; (Rodriguez see paragraph 0039 0040 0079 0098 0099 0108 see figure 2 user submits request to view or pay bill starting workflow, then in view state invoice bills are retrieved and presented to the user, then state machine transitions to next state where user inputs information for bill payment with each action state processing data. Customized work flow state machine is shown in a diagram in figure 2 showing each transition of a state with the workflow to be stored on template where workflow reads on process. Each customization of the work flow state machine is stored on a data structure. Workflow and graph of state machine with template reads on graphical diagram. Each state is already explained above in the mapping of each state in the state machine and each state transitioning upon completion of action reads on occurrence of event)
publishing the graph on marketplace allowing third-parties to copy the graph with an option for modification
launching a process execution corresponding to the third-party copied graph with the modifications for enabling automated invoice payment with marketplace-hosted third-party interaction. (Rodriguez see paragraph figure 2 0108 0110 0117-0119 customizations to workflow and graph of state machine with template for state machine are saved to data structure in portal to be shared and reused by other billers with option for other billers being able to use and customize already saved workflow templates. Other billers using and modifying reads on other third parties copying workflow with option to make modifications, portal reads on marketplace, workflow and graph of state machine with template reads on process and graph)
Rodriguez does not teach: computing nodes
creating a plurality of computing nodes for representing a data processing task of the plurality of data processing tasks, each of the plurality of computing nodes being associated with a particular state of the data processing task of the plurality of data processing tasks, of the necessary states, each computing node being configured to reference a function associated with the particular state of the data processing task of the plurality of data processing tasks and to pass the data structure to another computing node, of the plurality of computing nodes, upon completion of the function
wherein the graph comprises a plurality of vertexes representing to the plurality of computing nodes configured to reference a function associated with the particular state of the data processing task, and a plurality of edges associated with transitions between the vertexes
However, Prasad teaches: creating a plurality of computing nodes for representing a data processing task of the plurality of data processing tasks, each of the plurality of computing nodes being associated with a particular state of the data processing task of the plurality of data processing tasks, of the necessary states, each computing node being configured to reference a function associated with the particular state of the data processing task of the plurality of data processing tasks and to pass the data structure to another computing node, of the plurality of computing nodes, upon completion of the function (Prasad see col 8 lines 50-67 col. 9 lines 1-24 finite state machine for processing of user event driven application includes a state graph including nodes and vertices representing states in the state machine and nodes are connected via edges representing transition between states. Examiner more broadly interprets this limitation to be generically applying a state machine to a graph)
a plurality of edges associated with transitions between the vertexes (Prasad see col 8 lines 50-67 col. 9 lines 1-24 nodes are connected via edges representing transition between states)
Rodriguez does not teach: computing nodes
wherein the graph comprises a plurality of vertexes representing to the plurality of computing nodes configured to reference a function associated with the particular state of the data processing task
However, Akoglu teaches: wherein the graph comprises a plurality of vertexes representing to the plurality of computing nodes (Akoglu see paragraph 0061 0064 vertex cluster in graph identifying computing nodes)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a method of using a state machine with invoice payments as taught by Rodriguez to include computing nodes as taught by Akoglu for the predictable result of efficiently organizing a workflow so that when one component of the workflow changes other parts are updated.
Rodriguez does not teach: computing nodes
computing nodes configured to reference a function associated with the particular state of the data processing task
However Muller teaches: computing nodes
computing nodes configured to reference a function associated with the particular state of the data processing task (Muller see paragraph 0003 0082 0083 0104 send to one mode where end node continuously transfers data to a single destination until end node’s max transmission time or bulk data transfer completes such that nodes are computing nodes)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a method of using a state machine with invoice payments as taught by Rodriguez to include computing nodes as taught by Muller for the predictable result of efficiently organizing a workflow.
Regarding claim 30, Rodriguez teaches: receiving, from a first user of the marketplace, a request to modify the published graph; (Rodriguez see paragraphs 0109 0110 0117-0119 other billers on portal to use existing templates for workflow as baseline for edits where other biller read on first user)
creating a modified graph based on the published graph, the modified graph comprising a change to one or more of the vertexes of the graph; and (Rodriguez see paragraphs 0109 0110 0116-0119 fig 2 other billers on portal to use existing templates for workflow as baseline for edits such that component of a workflow and be modified by defining components and ordering of components as seen in fig 2 where definition and order of components of the template and the squares and circles representing states of the workflow read on vertexes of the graph)
creating a modified process based on the modified graph. (Rodriguez see paragraphs 0109 0110 0117-0119 other billers on portal to use existing templates for workflow as baseline for edits and customizations for the workflow template where state machine running based on modified workflow template reads on modified process)
Regarding claim 32, Rodriguez as modified teaches: configuring a system associated with the first user to execute the modified process. (Rodriguez see paragraphs 0109 0110 0117-0119 other billers on portal to use existing templates for workflow as baseline for edits and customizations for the workflow template such that state machine is run based on modified workflow template and pushed to live production where state machine running on live production reads on system executing modified process)
Claim(s) 14, 34, 35, 37 in view of are/is rejected under 35 U.S.C. 103 as being unpatentable over Rodriguez et al. US2018/0032980 in view of Prasad et al. US8381094 in view of Fairbrothers et al. US2015/0066524 in view of Akoglu US2013/0151536
Regarding claim 14, Rodriguez teaches: A method for an automated task flow said method comprising the steps of:
Defining a listing of necessary states for a plurality of data processing tasks; (Rodriguez see paragraph 0003 0039 0040 0079 0098 0099 user in financial institution submits request to view or pay bill starting workflow, then in view state invoice bills are retrieved and presented to the user, then state machine transitions to next state where user inputs information for bill payment.)
determining data parameters used for designation of the necessary states; (Rodriguez see paragraph 0098 0099 see figure 12 invoice used in state machine for cellular phone bill to make a bill payment includes customer name and customer ID, invoice amount, invoice description. User inputs payment information to select bill payment as an example of another state. Customer name and customer ID, invoice amount, inputted information for bill payment reads on data parameters)
assembling the data structure and a process corresponding to information about at least one state required for an execution of a process run by way of a graphical task loop ; (Rodriguez see paragraph 0108 see figure 2 customized work flow state machine is shown in a diagram in figure 2 showing each transition of a state. Each customization of the work flow state machine is stored on a data structure. Workflow and graph of state machine reads on graphical task loop)
publishing a graph associated with the process on a host allowing third-parties without access to the host to copy the graph for modification
and executing a process run corresponding to the third-party copied graph with the modifications. (Rodriguez see paragraph figure 2 0108 0110 0117-0119 customizations to workflow and graph of state machine with template for state machine are saved to data structure in portal to be shared and reused by other billers with option for other billers being able to use and customize already saved workflow templates. Other billers using and modifying reads on other third parties copying workflow with option to make modifications, portal reads on marketplace, workflow and graph of state machine with template reads on process and graph)
Rodriguez does not teach: computing nodes
creating a plurality of computing nodes for representing a data processing task of the plurality of data processing tasks, each of the plurality of computing nodes being associated with a particular state of the data processing task of the plurality of data processing tasks, of the necessary states, each computing node being configured to reference a function associated with the particular state of the data processing task of the plurality of data processing tasks and to pass the data structure to another computing node, of the plurality of computing nodes, upon completion of the function
wherein the modification of the graph comprises:
modifying an at least one vertex of the published graph representing to at least one computing node of the plurality of the computing nodes,
modifying the at least one computing node represented by the at least one modified vertex
However, Prasad teaches: creating a plurality of nodes for representing a data processing task of the plurality of data processing tasks, each of the plurality of nodes being associated with a particular state of the data processing task of the plurality of data processing tasks, of the necessary states, each computing node being configured to reference a function associated with the particular state of the data processing task of the plurality of data processing tasks and to pass the data structure to another computing node, of the plurality of computing nodes, upon completion of the function (Prasad see col 8 lines 50-67 col. 9 lines 1-24 finite state machine for processing of user event driven application includes a state graph including nodes and vertices representing states in the state machine and nodes are connected via edges representing transition between states. Examiner more broadly interprets this limitation to be generically applying a state machine to a graph)
Rodriguez does not teach: computing nodes
modifying an at least one vertex of the published graph representing to at least one computing node of the plurality of the computing nodes,
modifying the at least one computing node represented by the at least one modified vertex
However, Fairbrothers teaches: wherein the modification of the graph comprises:
modifying an at least one vertex of the published graph corresponding to at least one computing node of the plurality of the computing nodes,
modifying the at least one computing node based on the at least one modified vertex (Fairbrothers see paragraph 0028 data to be implemented in graph database with vertices such that when a vertex is modified the data model creates a new node version of the corresponding node to which the vertex is related to)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a method of using a state machine with invoice payments as taught by Rodriguez to include updating node based on modified vertex as taught by Fairbrothers for the predictable result of efficiently organizing a workflow so that when one component of the workflow changes other parts are updated.
Rodriguez does not teach: vertex of graph representing at least one computing node of the plurality of computing nodes
However Akoglu teaches: computing node represented by vertex (Akoglu see paragraph 0061 0064 vertex cluster in graph identifying computing nodes)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a method of using a state machine with invoice payments as taught by Rodriguez to include computing nodes as taught by Akoglu for the predictable result of efficiently organizing a workflow.
Regarding claims 34, 35, 37 note the rejection of claims 14. The instant claims recite substantially same limitations as the above-rejected claims and are therefore rejected under same prior-art teachings.
Claim(s) 31 in view of are/is rejected under 35 U.S.C. 103 as being unpatentable over Rodriguez et al. US2018/0032980 in view of Prasad et al. US8381094 in view of Akoglu US2013/0151536 in view of Muller et al. US2018/0288506 in view of Fairbrothers et al. US2015/0066524
Regarding claim 31, Rodriguez as modified does not teach: modifying an at least one vertex of the published graph,
modifying an at least one node based on the modified vertex
However, Fairbrothers teaches: modifying an at least one vertex of the published graph,
modifying an at least one node based on the modified vertex (Fairbrothers see paragraph 0028 data to be implemented in graph database with vertices such that when a vertex is modified the data model creates a new node version of the corresponding node to which the vertex is related to)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a method of using a state machine with invoice payments as taught by Rodriguez to include updating node based on modified vertex as taught by Fairbrothers for the predictable result of efficiently organizing a workflow so that when one component of the workflow changes other parts are updated.
Claim(s) 38, 39 in view of are/is rejected under 35 U.S.C. 103 as being unpatentable over Rodriguez et al. US2018/0032980 in view of Prasad et al. US8381094 in view of Akoglu US2013/0151536 in view of Muller et al. US2018/0288506 in view of Miller et al. US2013/0138593
Regarding claim 38, Rodriguez as modified does not teach: wherein each node, of the plurality of nodes, comprises at least one of a start node, an execute node, or a final node
Miller teaches: wherein each node, of the plurality of nodes, comprises at least one of a start node, an execute node, or a final node (Miller see paragraph 0035-0037 inner node to execute function where inner node reads on execute node)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a method of using a state machine with invoice payments as taught by Rodriguez to include a finite state machine using nodes as taught by Miller for the predictable result of efficiently transmitting data in an organized way using a finite state machine.
Regarding claim 39, Rodriguez as modified teaches: further comprising executing, by the execute node, a task upon the condition with the set of parameters are met by the event (Miller see paragraph 0035-0037 inner node to execute function when matching key is found in event subtree where inner node reads on execute node and found matching key in event subtree reads on condition with parameters met by event)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a method of using a state machine with invoice payments as taught by Rodriguez to include a finite state machine using nodes as taught by Miller for the predictable result of efficiently transmitting data in an organized way using a finite state machine.
Claim(s) 40 in view of are/is rejected under 35 U.S.C. 103 as being unpatentable over Rodriguez et al. US2018/0032980 in view of Prasad et al. US8381094 in view of Akoglu US2013/0151536 in view of Muller et al. US2018/0288506 in view of Miller et al. US2013/0138593 in view of Mick et al. US2013/0304903
Regarding claim 40, Rodriguez as modified does not teach: wherein each node comprises a queue, a counter, and the function applied to the data structure
However, Mick teaches: wherein each node comprises a queue, a counter, and the function applied to the data structure (Mick see paragraph 0123 implement a policy based on age where oldest object in the queue is delivered first. Policy implementation reads on function and keeping track of age reads on counter)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified a method of using a state machine with invoice payments as taught by Rodriguez to include a policy tracking age as taught by Mick for the predictable result of efficiently organizing data by keeping track of age.
Response to arguments
Applicant’s argument: Prior art does not teach necessary states of processing tasks and data parameters used for designation of necessary states as a list of bill information is not a list of necessary states
Examiner’s response: Applicant’s argument is considered but is not persuasive. Rodriguez reference specifies that presenting a bill view is a state within the state machine. The bill view includes an account identifier, invoice number and information that is necessary for this particular state. Rodriguez goes on the to say that the user may enter payment information and select to pay bill which is also another state in the state machine such that the entered payment information would teach parameters necessary for this particular state. Without more specific details or a specific definition, Rodriguez teaches data parameters. Rodriguez also goes on to show in multiple figures these parameters for each state within the state machine with further strengthens examiner’s argument. Examiner’s interpretation is not unreasonably broad as it uses even examples of parameters given by the claims. Rodriguez does not merely present a bill view, it discloses that user must fill out parameters in order to move to the next state. Furthermore the supposed “bill view” is itself state in the state machine and these parameters define the state of the state machine. Examiner’s interpretation is directed at the definition of what it means to be a parameter designated for the state, otherwise it would be unclear what “parameter designated for the states” even means in context of any state machine.
Applicant’s argument: Prior art does not teach passing requests through a graph of data processing tasks, Rodriguez reference stores workflows and elements not information about necessary states
Examiner’s response: Applicant’s argument is not persuasive. Examiner interprets the graph to be a graph of the states of the state machine. Rodriguez teaches a workflow for the state machine for bill and invoice payment. The bill and invoice payment using the workflow or state machine graph provided by Rodriguez reads on passing requests through the graph. Furthermore, Rodriguez even shows the graph in figure 2 which further makes this argument not persuasive. To a degree applicant’s recitation of graph of data processing tasks is the definition of a state machine which Rodriguez teaches.
Applicant’s argument: Prasad does not teach node being configured to perform a function associated with a particular state
Examiner’s response: Applicant’s argument is considered but is not persuasive. Prasad teaches nodes of a finite state machine which exactly teaches the claimed limitation. This also highlights why the claims need more clarification in order to make sense. The claims recite computing nodes but also recites them as nodes in a finite state machine. First if they are computing nodes then the entire claim does not make sense because computing nodes are not nodes in a finite state machine. Second, if nodes are nodes in a workflow finite state machine then they are not “computing nodes” which preform computations. Either way the rejection has both interpretations taught.
Applicant’s argument: Prior art is multiple unconnected references which is improper and merely based on similar terms
Examiner’s response: Applicant’s argument is considered but is not persuasive. In addition to the fact that applicant does not specify which prior art is improper to be connected, prior art of record deals with finite state machines which makes it logical to combine. As indicated in the above argument, claims do not make full sense given that two separate unconnected ideas are somehow combined into the same claim set which may result in the prior art seemingly to be unconnected.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALLEN S LIN whose telephone number is (571)270-0612. The examiner can normally be reached on M-F 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kavita Stanley can be reached on (571)272-8352. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ALLEN S LIN/Primary Examiner, Art Unit 2153