DETAILED ACTION
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 Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Regarding claim 13, claim 13 is being interpreted under 112(f). However, claim 13 is a single means claim and lacks enablement under 35 USC112(a). Please see the rejection that follows.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 13 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement.
Regarding claim 13, claim 13 is a single means claim. A single means claim, i.e., where a means recitation does not appear in combination with another recited element of means, is subject to an enablement rejection under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph. In re Hyatt, 708 F.2d 712, 714-715, 218 USPQ 195, 197 (Fed. Cir. 1983) (A single means claim which covered every conceivable means for achieving the stated purpose was held nonenabling for the scope of the claim because the specification disclosed at most only those means known to the inventor.).
Therefore, claim 13 lacks enablement because it is a single means claim.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1-12, claim 1 recites ‘a reference node’ throughout. This terminology is unclear in context of the claim. Later in the claims it is recited ‘the respective node’. Examiner believes ‘respective node’ refers back to ‘each node’. However, it is not clear if reference node is referring to ‘respective node’ or ‘each node’ or some other node. Examiner believes Applicant means ‘each node’. Claims 2-12 do not cure the deficiencies of claim 1.
Regarding claim 13, claim 13 recites ‘a reference node’ throughout. This terminology is unclear in context of the claim. Later in the claims it is recited ‘the respective node’. Examiner believes ‘respective node’ refers back to ‘each node’. However, it is not clear if reference node is referring to ‘respective node’ or ‘each node’ or some other node. Examiner believes Applicant means ‘each node’.
Regarding claim 14, claim 14 recites ‘a reference node’ throughout. Later in the claims it is recited ‘the respective node’. Examiner believes ‘respective node’ refers back to ‘each node’. However, it is not clear if reference node is referring to ‘respective node’ or ‘each node’ or some other node. Examiner believes Applicant means ‘each node’.
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.
Claims 1-3 are rejected under 35 U.S.C. 103 as being unpatentable Bian (Bian, Chaoyi, et. al. “Boosting Named Data Networking for Efficient Packet Forwarding in Urban VANET Scenarios” The 21st IEEE International Workshop on Local and Metropolitan Area Networks, 2015.) and further in view of Alasaad (2017/0134306).
Regarding claim 1, Bian discloses a computer-implemented method for generating and broadcasting routing information within a wireless information centric network, (See Bian abstract, I Intro; named data networking, NDN, data-centric architecture using VANET which is a wireless ad hoc network) the network including a plurality of nodes, each node having a network address and a geographic location, wherein a plurality of data objects is distributed over one or more destination nodes in the network, each data object being identifiable by a name prefix, wherein each node in the network is configured to exchange hello messages with one or more neighbor nodes that are reachable from the respective node via a wireless connection link, the method comprising: (See Bian pg. 3, section III, A, para. 5; each vehicle (e.g. a node) has (e.g. stored) a neighbor table (e.g. neighbor information base) which is periodically updated with a special hello message which has node ID (e.g. neighbor network address) and geo-location (e.g. geographic location) which are sent to one hop neighbors and received from one hop neighbors)
a) storing, in each node, a neighbor information base, wherein the neighbor information base of a reference node contains:
the network address of each neighbor node that is reachable from the reference node via a wireless connection link as neighbor network address, and
for each neighbor network address, the geographic location of a corresponding neighbor node as corresponding neighbor location; (See Bian pg. 3, section III, A, para. 5; each vehicle (e.g. a node) has (e.g. stored) a neighbor table (e.g. neighbor information base) which is periodically updated with a special hello message which has node ID (e.g. neighbor network address) and geo-location (e.g. geographic location) which are sent to one hop neighbors and received from one hop neighbors)
b) storing, in each node, a routing information base, wherein the routing information base of the reference node contains: (See Bian pg. 3, Section III, A, para. 1; maintaining a FIB, forwarding information base (e.g. a routing information base))
the name prefix of each data object stored in such one or more destination nodes that are reachable on one or more destination paths starting from a next hop node associated with the respective destination path as routing name prefix, (See Bian pg. 2, B, fig. 1; FIB stores name prefix (e.g. name prefix of each data object) and outgoing face (e.g. a next hop node associated with the respective destination path))
for each routing name prefix, the network address of each said next hop node as corresponding next hop network address, and (See Bian pg. 2, B, fig. 1; FIB stores name prefix (e.g. name prefix of each data object) and outgoing face represented as a number (e.g. next hop network address))
c) updating, in each node, the neighbor information base and the routing information base based on a hello message received by the respective node, wherein the hello message sent by the reference node includes:
a network address indicator corresponding to the network address of the reference node,
a location indicator corresponding to the geographic location of the reference node, (See Bian pg. 3, section III, A, para. 5; each vehicle (e.g. a node) has (e.g. stored) a neighbor table (e.g. neighbor information base) which is periodically updated with a special hello message which has node ID (e.g. neighbor network address) and geo-location (e.g. geographic location) which are sent to one hop neighbors and received from one hop neighbors)
one or more name prefix indicators, each name prefix indicator corresponding to the name prefix of the data object stored in such one or more destination nodes that are reachable on one or more destination paths starting from the reference node, and (See Bian pg. 2, fig. 1, section B; incoming data from one hop neighbors contain a name prefix indicator of the data object that is stored in one or more destination nodes that is reachable from the node; hello message and CS combined are the recited hello message)
d) generating, by each node, the hello message based on the neighbor information base and the routing information base of the respective node, and broadcasting the generated hello message. (See Bian pg. 3, section III, A, para. 5; each vehicle (e.g. a node) has (e.g. stored) a neighbor table (e.g. neighbor information base) which is periodically updated with a special hello message which has node ID (e.g. neighbor network address) and geo-location (e.g. geographic location) which are sent to one hop neighbors and received from one hop neighbors)
Bian does not explicitly disclose a path length of a corresponding destination path starting from a length corresponding next hop node as corresponding routing path length and at least one corresponding path length indicator corresponding to the path length of the corresponding destination path starting from the reference node. However, Mendes does disclose a path length of a corresponding destination path starting from a length corresponding next hop node as corresponding routing path length and at least one corresponding path length indicator corresponding to the path length of the corresponding destination path starting from the reference node. (See Alasaad fig. 2; para. 37; observing from received broadcast/multicast packets the hop count to certain nodes) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the method of Bian to include the teaching of a path length of a corresponding destination path starting from a length corresponding next hop node as corresponding routing path length and at least one corresponding path length indicator corresponding to the path length of the corresponding destination path starting from the reference node of Alasaad with the motivation being to reduce network traffic by determining the best path and further to determine feasibility of routing data between a source and destination and further to make intelligent routing decisions which optimize limited wireless resources and device resources (including battery, processing and/or memory).
Regarding claim 2, Bian in view of Alasaad discloses the method according to claim 1, wherein step c) further comprises:
c1) updating the neighbor information base of the respective node by identifying:
the network address indicator as neighbor network address, and
for the network address indicator as neighbor network address, the corresponding location indicator as corresponding neighbor location. (See Bian pg. 3, section III, A, para. 5; each vehicle (e.g. a node) has (e.g. stored) a neighbor table (e.g. neighbor information base) which is periodically updated with a special hello message which has node ID (e.g. neighbor network address) and geo-location (e.g. geographic location) which are sent to one hop neighbors and received from one hop neighbors)
Regarding claim 3, Bian in view of Alasaad discloses the method according to claim 1, wherein step c) further comprises:
c2) updating the routing information base of the respective node by identifying:
each name prefix indicator as routing name prefix, (See Bian pg. 2, B, fig. 1; FIB stores name prefix (e.g. name prefix of each data object) and outgoing face (e.g. a next hop node associated with the respective destination path))
for each name prefix indicator as routing name prefix, the network address indicator as corresponding next hop network address, and (See Bian pg. 3, section III, A, para. 5; each vehicle (e.g. a node) has (e.g. stored) a neighbor table (e.g. neighbor information base) which is periodically updated with a special hello message which has node ID (e.g. neighbor network address) and geo-location (e.g. geographic location) which are sent to one hop neighbors and received from one hop neighbors)
Bian does not explicitly disclose a path length. However, Alasaad does disclose a path length. (See Alasaad fig. 2; para. 37; observing from received broadcast/multicast packets the hop count to certain nodes) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the method of Bian to include the teaching of a path length of Alasaad with the motivation being to reduce network traffic by determining the best path and further to determine feasibility of routing data between a source and destination and further to make intelligent routing decisions which optimize limited wireless resources and device resources (including battery, processing and/or memory).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable Bian (Bian, Chaoyi, et. al. “Boosting Named Data Networking for Efficient Packet Forwarding in Urban VANET Scenarios” The 21st IEEE International Workshop on Local and Metropolitan Area Networks, 2015.) and further in view of Alasaad (2017/0134306) and further in view of Dowdell (2016/0105356).
Regarding claim 7, Bian in view of Alasaad discloses the method according to claim 1. Bian in view of Alasaad do not explicitly disclose using dynamic link exchange protocol. However, Dowdell does disclose using dynamic link exchange protocol. (See Dowdell para. 41) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the method of Bian in view of Alasaad to include the teaching of using dynamic link exchange protocol of Dowdell with the motivation being to conform to standardized protocols which provides compatibility and saves time and money and further to enable faster network changes, better path selection, and efficiency in mobile/challenging environments
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable Bian (Bian, Chaoyi, et. al. “Boosting Named Data Networking for Efficient Packet Forwarding in Urban VANET Scenarios” The 21st IEEE International Workshop on Local and Metropolitan Area Networks, 2015.) and further in view of Alasaad (2017/0134306) and further in view of Kim (2009/0092112).
Regarding claim 10, Bian in view of Alasaad discloses the method according to claim 1. Bian in view of Alasaad does not explicitly disclose a link quality indicator in a hello message. However, Kim does disclose a link quality indicator in a hello message. (See Kim para. 27) Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the method of Bian in view of Alasaad to include the teaching of a link quality indicator in a hello message of Kim with the motivation being to reduce network traffic by determining the best path and further to determine feasibility of routing data between a source and destination and further to make intelligent routing decisions which optimize limited wireless resources and device resources (including battery, processing and/or memory).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable Bian (Bian, Chaoyi, et. al. “Boosting Named Data Networking for Efficient Packet Forwarding in Urban VANET Scenarios” The 21st IEEE International Workshop on Local and Metropolitan Area Networks, 2015.) and further in view of Alasaad (2017/0134306) and further in view of Kim (2009/0092112).
Regarding claim 13, Bian in view of Alasaad discloses a data processing device comprising a means for carrying out the method of claim 1. (See Claim 1 rejection above; devices have a processor executing an algorithm stored in memory)
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable Bian (Bian, Chaoyi, et. al. “Boosting Named Data Networking for Efficient Packet Forwarding in Urban VANET Scenarios” The 21st IEEE International Workshop on Local and Metropolitan Area Networks, 2015.) and further in view of Alasaad (2017/0134306) and further in view of Kim (2009/0092112).
Regarding claim 14, Bian in view of Alasaad discloses a non-transitory computer readable medium storing a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of claim 1. (See Claim 1 rejection above; devices have a processor executing an algorithm stored in memory)
Allowable Subject Matter
Claims 4-6, 8-9, 11-12 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHEN J CLAWSON whose telephone number is (571)270-7498. The examiner can normally be reached M-F 7:30-5:00 pm 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, Huy D Vu can be reached at (571) 272-3155. 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.
/Stephen J Clawson/Primary Examiner, Art Unit 2461