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 .
Response to Arguments
Applicant's arguments filed 04/28/2025 have been fully considered but they are not persuasive. The arguments have been addressed below.
On:
Page 12, in response to arguments associated with 35 USC § 101. Applicant argues claims are not directed towards a mental process. The examiner respectfully disagrees. The steps of “receiving a notification”, “analyzing the notification to determine applicability” and “modifying a local resource based on the analysis” are all steps that can be practically performed in the human mind or by a human with pen and paper. For example a human, with the aid of a computer, would receive a notification (e.g. a message or email about a resource change), mentally determine if the change is relevant to their group or context, and then manually, using the computer as a tool, update a local resource/record. The specification supports this interpretation. Fig. 4 and the corresponding description paragraphs [pg. 12, lines 9 – pg. 13, line 29]. Shows that a client initiates creation or updating of federation resources by sending a message to the API, which forwards it to the federation database. This description indicates that a human client is the entity submitting the claim or request, and the subsequent analysis (determining if the notification if applicable. The application expressly teaches scenario in which a human performs the claimed functions.
Page 14, in response to arguments associated with 35 USC § 102. Applicant argues Little does not teach a federation controller or equivalent “analyze the first notification to determine whether the change relating to the federation resource is applicable to the cluster”. The examiner respectfully disagrees. Little expressly teaches that the transactional middleware system (including the notification service client, such as FAN server 210) processes received notifications (events) and determines their applicability to the relevant local context. See paragraph [0035-0038] describes receiving threads that receive and handle events. [0055-0056] states that high availability events (HA) “can be applied to different scopes, such as the database 311, service 312, node 313, and instance 314 scopes.” And that the system acts only when such an event pertains to its own managed resources (e.g. creating new connections UP events, terminating sessions DOWN events). This inherently includes the steps of analyzing each notification to determine whether if applicable to the server/cluster as stated in the claim.
Page 14, in response to arguments associated with 35 USC § 102. Applicant Little refers only to the idea of performing database connection management actions (e.g., creating or terminating sessions) based on the state changes. The examiner respectfully disagrees. Little discloses local resource management in the form of local memory and state tables for each cluster/server, as well as conditional management based on received events. Paragraphs [0039-0043] “the FAN server 210 can create a new entry in the database service state table 204, the instance states table 205 and the hostname table, when it is needed. Also, the FAN server 210 can update and clean the database service state table 204, the instance states table 205 and the hostname table, when it is appropriate.” These operations are explicit examples of clusters and resource management.
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-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In adhering to the 2019 Revised Patent Subject Matter Eligibility Guidance (2019 PEG), claim 1’s evaluation under Step 1 indicates it is directed to a statutory class. Herein, the claims fall within statutory class of machine.
With Step 1 being directed to a statutory category, 2019 PEG flowchart is directed to Step 2. Step 2 is a two prong inquiry. Prong one considers whether the claim recites a judicial exception (an abstract idea enumerated in the 2019 PEG, a law of nature, or a natural phenomenon). In this case independent claim 1 recite mental process.
Further, claim 1 recites step 2 prong 1 steps of:
“receive a first notification from the distributed federation database, wherein the first notification indicates a change relating to a federation resource that is stored in the distributed federation database;
analyze the first notification to determine whether the change relating to the federation resource is applicable to the cluster;
in response to determining that the change relating to the federation resource is applicable to the cluster, applying the change to a local resource based on the first notification;
and update a status of the federation resource in the distributed federation database when the change to the local resource has been applied. “
The steps of receiving, analyzing, determining applicability, applying change and updating the status are all steps that can be performed by the a human using pen and paper or mentally, for example, a human operator could receive a message (notification), mentally analyze tis content to determine if it applies to their context, make a decision about whether to act, if so, update a record and notify a central database of the update . See MPEP 2106.05(d). Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network).
The additional elements such as the plurality of cluster, the distributed federation database, the cluster interface, cluster local memory and federation controller are all recited at a high level of generality, they represent routine and conventional computing hardware used to perform the abstract idea.
Dependent claim 2 and 14 recites initiating receive or notifications by sending a “watch” message. This is merely requesting or subscribing into data updates which is a routine data gathering transmitting step and does not integrate to an extra idea into a practical application.
Dependent claim 3 and 15 recites deriving and storing a cluster of resources when the notification indicates creation. these are additional steps of analyzing and storing data conventional computer functions that amount to insignificant extra solution and activity.
Dependent claim 4 and 16 for recites updating a previously stored resource when the notification indicates an update this an extension of claim 3 and amounts to routine updating of data records.
Dependent claim 5 and 17 recites dilation of resources and notification indicates deletion and a follow-up deletion at the federation level. These steps amounts to routine data management which is well understood routine and convention.
Dependent claim 6 and 18 recites receiving a notification for a scheduling resource and deriving suitability parameters and allocation numbers. These steps are abstract mental processes of evaluating and calculating suitability followed by storing and updating data no integration into a practical application.
Dependent claim 7 and 19 recites retrieving suitability parameters of other clusters and adjusting resources accordingly this amounts to further mental evaluation comparing parameters and adjusting store values.
Dependent claim 8 and 20 recites creating and storing derived resources this is simply additional data creation and storage which is insignificant extra solution activity.
Dependent claim 9 and 21 recites applying a policy in the driving the suitability parameters . Applying rules or policies to a decision is a an example of mental process which is that not integrate the idea into a practical application.
Dependent claim 10 and 22 recites derive into ability based on a cluster specific information. This is using additional data inputs for the same mental process and it's still abstract idea.
Dependent claim 11 and 23 recites selecting a higher number of resources if the suite available is higher. This is a conditional decision making step which is a mental process.
Dependent claim 12 recites the distributed federation database. This restates a generic computing component already present in claim one and does not amount to significantly more.
Claim 1, as well as independent claims 13 and 24 which contain similar limitations and all claims dependent thereon, are directed to an abstract idea without significantly more.
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.
Claims 1-24 are rejected under 35 U.S.C. 103 as being unpatentable over Little (20150324222 A1) in view of Beardsmore (US 20120272252 A1).
Regarding claim 1, Little teaches:
An arrangement comprising: a plurality of clusters; and an interface through which a distributed federation database is accessible by the plurality of clusters, wherein each cluster included in the plurality of clusters comprises. ([0020] In accordance with an embodiment of the invention, a transactional middleware system, such as the Oracle Tuxedo system, can take advantage of fast machines with multiple processors, such as an Oracle Exalogic middleware machine, and a high performance network connection, such as an IB network. Additionally, the Oracle Tuxedo system can take advantage of a clustered database, such as the Oracle Real Application Clusters (RAC) Enterprise database, which is a clustered database with shared cache architecture and can be a component of a cloud architecture. The Oracle RAC can overcome the limitations of traditional shared-nothing and shared-disk approaches to provide highly scalable and available database solutions for business application. 0023] FIG. 1 shows an illustration of supporting database state notification integration in a transactional middleware machine environment 100, in accordance with an embodiment of the invention. As shown in FIG. 1, a transactional middleware system 101, which includes one or more transaction servers 111-112, can adaptively respond to state changes in a database service 102, which may include one or more database instances 121-122.)
a cluster interface. ([0025] When the transactional middleware system 101 connects with the database service 102, the transactional middleware system 101 can use a notification service client 103 to receive the various events 105 from the notification service 104 that is associated with the database service 102. Then, the applications in the transactional middleware system 101 can respond immediately to the database service state changes. See also [0023]. E.N. Under BRI the notification client server (interface) allows all clusters to access and receive information about the distributed database)
a cluster local memory configured to store local cluster resources; and ([0039] In accordance with an embodiment of the invention, the transactional middleware machine 201 can store the database service state information in a share memory 203, such as the Tuxedo Bulletin Board (BB). [0040] As shown in FIG. 2, the FAN server 210 can create and maintain different state tables in the share memory 203. These tables can include a database service state table 204 and a database instance state table 205. Furthermore, the transactional middleware machine 201 can support the instance awareness feature and other related features based on these tables.)
a federation controller wherein the federation controller is configured to: receive a first notification from the distributed federation database, wherein the first notification indicates a change relating to a federation resource that is stored in the distributed federation database; ([0025] When the transactional middleware system 101 connects with the database service 102, the transactional middleware system 101 can use a notification service client 103 to receive the various events 105 from the notification service 104 that is associated with the database service 102. Then, the applications in the transactional middleware system 101 can respond immediately to the database service state changes. And [0031] FIG. 2 shows an illustration of handling various database state notification events in a transactional middleware environment 200, in accordance with an embodiment of the invention. As shown in FIG. 2, a transaction middleware machine 201, which includes one or more transaction servers 211-212, can use a notification service client (such as a FAN server 210) to receive various events, which are published by the database state notification service 202. See also [0023])
analyze the first notification to determine whether the change relating to the federation resource is applicable to the cluster; ([0055] In accordance with an embodiment of the invention, the transactional servers 302 can handle various types of HA events, such as the UP events and DOWN events associated with the database service 301. Furthermore, these HA events can be applied to different scopes, such as the database 311, service 312, node 313, and instance 314 scopes. See also [0036-0039])
in response to determining that the change relating to the federation resource is applicable to the cluster, applying the change to a local resource based on the first notification; ([0056] For UP events, when services and instances are started, the system can create new database connections so that the application can immediately take advantage of the extra resources. On the other hand, for DOWN events, the system can minimize the disruption to the applications by terminating the sessions related to the failed instances or nodes. Also, the system can terminate the incomplete transactions and notifies the application users immediately afterwards.[0057] For example, when a Tuxedo server receives an HA event, which indicates that the database status changes from UP to DOWN, the Tuxedo server can return a NOENTRY or RMERR message to the client 303.)
Little does not appear to explicitly teach :and update a status of the federation resource in the distributed federation database when the change to the local resource has been applied.
However, Beardsmore teaches a known technique for event notification wherein: [0047] FIG. 3 is a flow chart of an example of an implementation of a process 300 for automated monitoring of subscriber message processing in a publish/subscribe (pub/sub) messaging environment. At block 302, the process 300 receives, at a publish/subscribe message tracking device, a message published by a publisher device and associated with a subscription topic hosted by the publish/subscribe message tracking device. At block 304, the process 300 determines to monitor action completion processing of the message by at least one subscriber device. At block 306, the process 300 sends the message to the at least one subscriber device that is registered to the subscription topic and configured to report action completion processing of the message. At block 308, the process 300 monitors the action completion processing of the message by the at least one subscriber device. At block 310, the process 300 publishes monitoring results of the monitored action completion processing. See also [0048], [0061-0062]
Accordingly, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Little’s database state notification system by incorporating Beardsmore’s known technique of event notification wherein published update action completion and monitoring results are notified to local subscribers. Little provides the base system a cluster middleware/database state notification environment while Beardsmore teaches the technique of monitoring and publishing status updates in a publish/subscribe environment that will notify local subscribers of changes performed on other systems such that when the down event is applied on a local device, the notification of such is sent to subscriber databases to update their status of the devices. A person of ordinary skill in the art would have recognized that applying Beardsmore’s publishing technique to Little’s cluster database environment will have predictably resulted in improved synchronization and efficiency of federation database updates. The combination merely applies a known technique (publishing updated status information) to a known system Little’s state notification federation database that was ready for such an improvement and the results timely and accurately dissemination of update status information across the distributed system will have been predictable to one of ordinary skill in the art.
Regarding claim 2, Beardsmore teaches:
The arrangement of claim 1, wherein the federation controller being configured to receive the first notification from the distributed federation database comprises the federation controller being configured to initiate receipt of notifications from the distributed federation database by sending a watch federation resources message to the distributed federation database. [0054] In response to determining to configure the message to instruct the selected subscriber devices to report message processing completion and status, the process 400 configures the message with an instruction to report the action completion processing of the message and action completion processing report criteria to instruct the selected subscriber devices to report message processing completion and status at block 422. The action completion processing report criteria may include time-based constraints, such as a fixed time after publication, fixed time intervals, when any of the information in the report changes, or any other action completion processing report messaging constraint appropriate for a given implementation. As such, monitoring the action completion processing of the message by subscriber devices may include monitoring the action completion processing of the message based upon the configured action completion processing report criteria. See also [0017].
Same motivation as claim 1.
Regarding claim 3, Little teaches:
The arrangement of claim 1, wherein the first notification from the distributed federation database indicates that the federation resource has been created, and wherein the federation controller is further configured to: in response to determining that the change relating to the federation resource is applicable to the cluster, determine that a cluster local resource should be derived; derive the cluster local resource; and store the derived cluster local resource in the cluster local memory; and update the status of the federation resource in the distributed federation database when the derived cluster local resource has been stored. ([0056] For UP events, when services and instances are started, the system can create new database connections so that the application can immediately take advantage of the extra resources. On the other hand, for DOWN events, the system can minimize the disruption to the applications by terminating the sessions related to the failed instances or nodes. Also, the system can terminate the incomplete transactions and notifies the application users immediately afterwards. See also [0040] and [0043])
Regarding claim 4, Little teaches:
The arrangement of claim 1, wherein the first notification from the distributed federation database indicates that the federation resource has been updated, and wherein the federation controller is further configured to: in response to determining that the change relating to the federation resource is applicable to the cluster, determine that a previously stored cluster local resource should be updated; update the previously stored cluster local resource to derive an updated cluster local resource; store the derived updated cluster local resource in the cluster local memory; and update the status of the federation resource in the distributed federation database when the derived updated cluster local resource has been stored. ([0043] Additionally, the FAN server 210 can create a new entry in the database service state table 204, the instance states table 205 and the hostname table, when it is needed. Also, the FAN server 210 can update and clean the database service state table 204, the instance states table 205 and the hostname table, when it is appropriate. And [0049] Additionally, the transaction middleware machine 201 can adapt to the changes in the database topology, such as adding or removing a node, and can distribute runtime work requests to all active database instances including the instances rejoining a cluster.; see also [0045-0046, claim 11 and 14; figures 1 and 4])
Regarding claim 5, Little teaches:
The arrangement of claim 1,wherein the first notification from the distributed federation database indicates that the federation resource has been marked for deletion, and wherein the federation controller is further configured to: in response to determining that the change relating to the federation resource is applicable to the cluster, determine that a corresponding derived cluster local resource should be deleted; delete the corresponding derived cluster local resource from the cluster local memory; update the status of the federation resource in the distributed federation database when the corresponding derived cluster local resource has been deleted from the cluster local memory; and receive a second notification from the distributed federation database indicating that no derived cluster local resources corresponding to the federation resource are stored in any of the plurality of clusters, and in response to the second notification, delete the federation resource from the distributed federation database. ([0043] Additionally, the FAN server 210 can create a new entry in the database service state table 204, the instance states table 205 and the hostname table, when it is needed. Also, the FAN server 210 can update and clean the database service state table 204, the instance states table 205 and the hostname table, when it is appropriate. [0045] In accordance with an embodiment of the invention, the HA events 221 can include the up/down notification for a node, a database instance and/or a service in a database service. For example, in Oracle RAC, the services can be continuously available with loads shared across one or more instances. The high availability framework monitors the database and its services and sends event notifications using FAN events. When the database cluster configuration changes, the system can immediately publish a FAN event that indicates a state change occurs in the cluster. The Oracle RAC high availability framework can maintain service availability. Also, Oracle RAC can recover and balance services according to business rules and the service attributes. E.N.: A DOWN notification is equivalent to a deletion/termination notice. The system determines that the corresponding local session/resource must be remove) Further, Beardsmore teaches a known technique for event notification wherein: [0047] FIG. 3 is a flow chart of an example of an implementation of a process 300 for automated monitoring of subscriber message processing in a publish/subscribe (pub/sub) messaging environment. At block 302, the process 300 receives, at a publish/subscribe message tracking device, a message published by a publisher device and associated with a subscription topic hosted by the publish/subscribe message tracking device. At block 304, the process 300 determines to monitor action completion processing of the message by at least one subscriber device. At block 306, the process 300 sends the message to the at least one subscriber device that is registered to the subscription topic and configured to report action completion processing of the message. At block 308, the process 300 monitors the action completion processing of the message by the at least one subscriber device. At block 310, the process 300 publishes monitoring results of the monitored action completion processing. See also [0048], [0061-0062]
Regarding claim 6, Little teaches:
The arrangement of claim 1, wherein the federation controller is further configured to: receive a second notification from the distributed federation database, wherein the second notification indicates a scheduling resource is to be created and specifies of an aggregate amount of resources to be committed among the plurality of clusters; in response to receiving the second notification:. ([0051] In accordance with an embodiment of the invention, the RLB events 222 can indicate the runtime load and affinity per database instance within a database service. The transactional middleware machine 201 can support runtime connection load balancing features, based on the RLB events 222 that are published by the database state notification service 202. The run-time connection load balancing features can enable the routing of work requests to an instance that offers the best performance and minimizes the need for relocating works. And [0052] In Tuxedo, the applications can take advantage of the load balancing advisory FAN events to direct work requests to the instance in the cluster that is currently providing the best service quality. Thus, Tuxedo can route request to the database instance with a light load.; see also [0053-0066], claim 11 and 14-16; figures 1 and 4)
Regarding claim 7, Little teaches:
The arrangement of claim 6, wherein the federation controller is further configured to: receive at least a third notification indicating an updated status of the scheduling resource; in response . ([0051] In accordance with an embodiment of the invention, the RLB events 222 can indicate the runtime load and affinity per database instance within a database service. The transactional middleware machine 201 can support runtime connection load balancing features, based on the RLB events 222 that are published by the database state notification service 202. The run-time connection load balancing features can enable the routing of work requests to an instance that offers the best performance and minimizes the need for relocating works.; see also [0053-0066], claim 11 and 14-16; figures 1 and 4)
Regarding claim 8, Little teaches:
The arrangement of claim 6, wherein the federation controller is further configured to: create a number of derived local cluster resources in correspondence with the number of resources to be handled by the cluster; store the derived local cluster resources in the cluster local memory; and update the status of the federation resource in the distributed federation database when the derived local cluster resources have been stored in the cluster local memory. ([0048] Furthermore, the transaction middleware machine 201 can provide rapid failure detection. The system can ensure that the database connections are valid without the need to test the database connections. Also, the transaction middleware machine 201 can remove invalid database connections from the transactional servers and create valid database connections. If a transactional server cannot create a valid database connection, the system can remove the Tuxedo server from the routing list. And [0051] In accordance with an embodiment of the invention, the RLB events 222 can indicate the runtime load and affinity per database instance within a database service. The transactional middleware machine 201 can support runtime connection load balancing features, based on the RLB events 222 that are published by the database state notification service 202. The run-time connection load balancing features can enable the routing of work requests to an instance that offers the best performance and minimizes the need for relocating works.; see also [0053-0066], claims 1-20; figures 1 and 4)
Regarding claim 9, Little teaches:
The arrangement of claim 6, wherein: the scheduling resource includes a policy that governs creation of the resources to be created among the plurality of clusters; and the federation controller is configured to derive the suitability parameter based at least in part on the policy. ([0045] In accordance with an embodiment of the invention, the HA events 221 can include the up/down notification for a node, a database instance and/or a service in a database service. For example, in Oracle RAC, the services can be continuously available with loads shared across one or more instances. The high availability framework monitors the database and its services and sends event notifications using FAN events. When the database cluster configuration changes, the system can immediately publish a FAN event that indicates a state change occurs in the cluster. The Oracle RAC high availability framework can maintain service availability. Also, Oracle RAC can recover and balance services according to business rules and the service attributes.; see also [0027-0030] (wherein features of the middleware system allows for dynamic steering / guiding on a suitable system for load balance processing), [0039-0044]; [0053-0066], claims 1-20; figures 1 and 4)
Regarding claim 10, Little teaches:
The arrangement of claim 6, wherein the federation controller is configured to derive the suitability parameter based on cluster-specific information. ([0052] In Tuxedo, the applications can take advantage of the load balancing advisory FAN events to direct work requests to the instance in the cluster that is currently providing the best service quality. Thus, Tuxedo can route request to the database instance with a light load. .; see also [0027-0030] (wherein features of the middleware system allows for dynamic steering / guiding on a suitable system for load balance processing), [0039-0044]; [0053-0066], claims 1-20; figures 1 and 4)
Regarding claim 11, Little teaches:
The arrangement of claim 6, wherein deriving the number of resources to be handled by the cluster comprises selecting a higher number of resources to be handled by the cluster in response to determining that the suitability parameter is higher than a suitability parameter associated with one or more other clusters included in the plurality of clusters. ( [0051] In accordance with an embodiment of the invention, the RLB events 222 can indicate the runtime load and affinity per database instance within a database service. The transactional middleware machine 201 can support runtime connection load balancing features, based on the RLB events 222 that are published by the database state notification service 202. The run-time connection load balancing features can enable the routing of work requests to an instance that offers the best performance and minimizes the need for relocating works. [0071] At step 407, the system can perform load balancing according to the load on the different database instances. For example, if one database instance is invalid, the system can select the transactional server, which is associated with a valid database instance. Furthermore, the system can select a transactional server with a lighter database load from multiple transactional servers associated with the same database service. And [0052] In Tuxedo, the applications can take advantage of the load balancing advisory FAN events to direct work requests to the instance in the cluster that is currently providing the best service quality. Thus, Tuxedo can route request to the database instance with a light load. .; see also [0027-0030] (wherein features of the middleware system allows for dynamic steering / guiding on a suitable system for load balance processing), [0039-0044]; [0053-0066], claims 1-20; figures 1 and 4).
Regarding claim 12, Little teaches:
The arrangement of claim 1, further comprising: the distributed federation database. (As shown in FIG. 1, a transactional middleware system 101, which includes one or more transaction servers 111-112, can adaptively respond to state changes in a database service 102, which may include one or more database instances 121-122.)
Regarding claim 13, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale. Little also teaches:
A method of operating a federation comprising a plurality of clusters and a distributed federation database, the method comprising. (Claim 1. A method for handling various database state notifications in a transactional middleware machine environment, comprising)
Regarding claim 14, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 15, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 16, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 17, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 18, the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Regarding claim 19, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 8 and is rejected for similar reasons as claim 8 using similar teachings and rationale.
Regarding claim 21, the claim recites similar limitation as corresponding claim 9 and is rejected for similar reasons as claim 9 using similar teachings and rationale.
Regarding claim 22, the claim recites similar limitation as corresponding claim 10 and is rejected for similar reasons as claim 10 using similar teachings and rationale.
Regarding claim 23, the claim recites similar limitation as corresponding claim 11 and is rejected for similar reasons as claim 11 using similar teachings and rationale.
Regarding claim 24, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale. Little also teaches:
A computer program product stored on a non-transitory tangible computer readable medium comprising instructions that cause a processor to. (Claim 20. A non-transitory machine readable storage medium having instructions stored thereon that when executed cause a system to perform the steps comprising)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199