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 § 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ramadorai et al. (US 20240166376), hereinafter referred to as Ramadorai in view of Shen et al. ( CN 1094955384 A), hereinafter referred as Shen.
Regarding claim 1, Ramadorai teaches in fig 1 and 2 of a system for improving routing of software defined radio networks [radio nodes], comprising:
a delay tolerant network [DTN network, see paragraph 0010-0011, figs 1-2] having a sender including a first software radio and a receiver including a second software radio that can communicate wirelessly with the first software radio according to a contact plan [DTN includes wireless nodes such as satellite, ground stations which uses (software) radio that communicates with each other via a contact plan, see 0009-0011, 0024 and fig. 1-2];
a first transmission block module [transmission block functionality, see figs. 1-2, see paragraphs 0014, 0021, 0028] interconnected to the first software radio and programmed to transmit frame with a set of link performance data for wireless transmission by the first software radio [one or more nodes continuously/periodically communicate to each other orbital parameters including position, velocity, orientation, orbital trajectory, RF capability, link budget, and other performance data between nodes, see figs. 1-2, paragraphs 0014, 0021, 0028 ];
a second transmission block module [receive block functionality, see figs. 1-2, see paragraphs 0014, 0021, 0028] interconnected to the second software radio and programmed to receive the transmit frame with the set of link performance data from the first software radio when wirelessly received by the second software radio, [see figs. 1-2, see paragraphs 0014, 0021, 0028, 0034, where reception of link performance data frame occurs via periodic performance communication data exchanged between nodes; In other words, the receiving node is a second transmission black that receives link performance data from the sender.]; and
an adapter module programmed [adaptor module functionality is equivalent to the system logic, see figs. 1-2] to pass the transmit frame with the set of link performance data [performance data frame is propagated between nodes] from the second transmission block module [communication relay node, see in fig. 2] to a reactive routing module [contact plan generator, see fig. 2],
wherein the reactive routing module[contact plan generator, see fig. 2] is programmed to adjust the contact plan based on the set of link performance data [dynamic routing and contact plan updates based on link data clearly serve as reactive routing to adjust the contact plan based on exchanged propagated performance data between nodes; Also, Ramdorai 0029 mentions that contact plan generator 202 can then generate a contact plan update message 210 that either includes the updated contact plan or data indicating changes to the initial contact plan and transmit the contact plan update message 210 to one or more communication relays 110A-D, see paragraphs 0015-0016, 0028-0029, 0034-0035, 0047, figs. 1-4].
While Ramadorai teaches in figs. 1 and 2 of periodically and continually exchanging performance data messages between nodes, it is silent in that the performance data messages are sent and received with encapsulated frame. Shen in the same field of endeavor teaches of improving reliability of networking routing in the space network technology. Shen teaches in S102 and S103 of detecting failures via retransmissions to informs and updates the contact plan. As a result the failure node is excluded from the forwarding path in time to update the contact plan. Shen further teaches in step S103 that node failure notification information is encapsulated in data packet and sent and received by other nodes. Therefore, it would have been obvious to one of ordinary skills in the art prior the effective filing date to combine Ramadorai’s dynamic, link-aware contact plan updating for delay-tolerant networks with Shen’s node failure detection and exclusion mechanisms and encapsulating failure notification packets exchanged to other nodes, thereby yielding a system that adjusts routing based on real-time link performance data and node status encapsulated frames as claimed.
Regarding claim 7, Ramadorai teaches in fig 1 and 2 of a method of improving routing of software defined radio networks, comprising the steps of:
sending a communication from a first software radio having a first transmission block module interconnected to the first software radio, wherein the first transmission block module transmits frame with a set of link performance data into the communication [DTN includes wireless nodes such as satellite, ground stations which uses (software) radio that communicates with each other via a contact plan, see 0009-0011, 0024 and fig. 1-2];;
wirelessly receiving the communication over a delay tolerant network according to a contact plan with a second software receiver having a second transmission block module interconnected to a second software radio that receives the transmit frame with set of link performance data from the first software radio , [see figs. 1-2, see paragraphs 0014, 0021, 0028, 0034, where reception of link performance data frame occurs via periodic performance communication data exchanged between nodes; In other words, the receiving node is a second transmission black that receives link performance data from the sender.;
passing the transmit frame with the set of link performance data [performance data described above is propagated between nodes] from the second transmission block module [communication relay node, see figs. 1-2, paragraphs 0014, 0021, 0028] to a reactive routing module [contact plan generator, see fig. 2],; and
adjusting the contact plan with the reactive routing module based on the set of link performance data [dynamic routing and contact plan updates based on link data clearly serve as reactive routing to adjust the contact plan based on exchanged propagated performance data between nodes; Also, Ramdorai 0029 mentions that contact plan generator 202 can then generate a contact plan update message 210 that either includes the updated contact plan or data indicating changes to the initial contact plan and transmit the contact plan update message 210 to one or more communication relays 110A-D, see paragraphs 0015-0016, 0028-0029, 0034-0035, 0047, figs. 1-4].
While Ramadorai teaches in figs. 1 and 2 of periodically and continually exchanging performance data messages between nodes, it is silent in that the performance data messages are sent and received with encapsulated frame. Shen in the same field of endeavor teaches of improving reliability of networking routing in the space network technology. Shen teaches in S102 and S103 of detecting failures via retransmissions to informs and updates the contact plan. As a result the failure node is excluded from the forwarding path in time to update the contact plan. Shen further teaches in step S103 that node failure notification information is encapsulated in data packet and sent and received by other nodes. Therefore, it would have been obvious to one of ordinary skills in the art prior the effective filing date to combine Ramadorai’s dynamic, link-aware contact plan updating for delay-tolerant networks with Shen’s node failure detection and exclusion mechanisms and encapsulating failure notification packets exchanged to other nodes, thereby yielding a system that adjusts routing based on real-time link performance data and node status encapsulated frames as claimed.
Regarding claims 2 and 8, Ramadorai teaches in figs. 3 and 4 of wherein the reactive routing module is programmed to adjust the contact plan so that the first software radio will communicate wirelessly with a third software radio instead of the second software radio [Ramadoria mentions in fig. 3 and 0033-0034 of a contact plan update messages between exchanged between communication relay nodes and existing contact plan is modified based on the contact plan update message. First and second communication relays may communicate with one another a different times based on updated contact plan. Additionally, Fig. 4, clearly mentions that when a new node is added to a communication network, hence the contact plan is updated, and an optima path from source to destination is selected clearly establishing that an adjustment of contact plan can lead first note to communicate to a new node (i.e. 3rd node) instead of second node in the existing contact plan].
Regarding claims 3 and 9, Ramadorai teaches wherein the set of link performance data comprises at least one performance factor selected from the group consisting of a signal to noise ratio, a background noise level, a corrected bit error count, an uncorrected bit error count, a Doppler velocity, and a transmission power level, and a carrier drop count [one or more nodes continuously/periodically communicate to each other orbital parameters including position, velocity, orientation, orbital trajectory, RF capability, link budget, and other performance data between nodes, see figs. 1-2, paragraphs 0014, 0021, 0028].
Regarding claims 4 and 10, Ramadorai teaches in fig. 2 of a reactive routing module in the form of a contact plan generator that updates contact plan based on data performance messages received from nodes. Ramadorai is silent wherein the reactive routing module is programmed to determine whether an aggregate bit error rate or an aggregate frame loss rate exceeds a predetermined threshold before adjusting the contact plan. Shen teaches in S102 and example 4 of a set normal link error rate of 10-6 and a present threshold set to 10, where 10 times retransmission of the checkpoint determines a node failure. Furthermore, step S102 generates node failure notification information encapsulated in data packet to other nodes in the network and the corresponding check point record removed in the failure node recording list. The node failure notification information for notifying other nodes in the network and failure node except the node which detects the failure information, the node failure notification information includes failure originating node, terminating node and a termination time of the failure. Thereafter, S106-S109 establishes removing the forward path to obtain a new contact plan and forwards the forwarding data packet according to the new contact plan. Therefore, it would have been obvious to one of ordinary skill in the art prior to the effective date to incorporate teachings of error rate threshold to determine a new for contact adjustment into Ramadorai’s invention in order to reliably optimize update contact plan for routing based on real-time link performance data and node status
Regarding claims 5 and 11, Ramadorai teaches in paragraph 0029-0030, 0034, and figs. 1-2 of wherein the reactive routing module is programmed to consider a history of link performance between the first software radio and the second software radio when determining whether to adjust the contact plan [processing nodes stores existing contact plan (with history of link performance that is continuously exchanged) and upon receiving indication of the change in communication network and updated contact plan is made by the reactive routing module functioning as contact plan generator, see paragraph 0029-0030, 0034, and figs. 1-2].
Regarding claims 6 and 12, Ramadorai teaches in figs 1-2, paragraph 0010 and abstract wherein the delay tolerant network comprises an interplanetary overlay network.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHIRAG G SHAH whose telephone number is (571)272-3144. The examiner can normally be reached 7-3:30 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.
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.
/CHIRAG G SHAH/Supervisory Patent Examiner, Art Unit 2477
Prosecution Insights