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 § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Dhatchinamoorthy et al., US PGPub 2021/0397351, hereafter “Dhatchinamoorthy.”
With respect to claim 1, Dhatchinamoorthy teaches a processor-implemented method comprising:
responsive to detecting a change to a non-volatile memory express (NVMe) entity (par. 28, NVM):
creating or updating an entry in a datastore that correlates the NVMe entity that experienced a change (“the changed NVMe entity”) to an event indicator (par. 74, incrementing the generation counter); and
sending a notification to one or more other NVMe entities that are associated with the changed NVMe entity (par. 76, sending the notification message);
receiving a request for information from a requesting NVMe entity that received the notification, in which the request comprises a last seen value of the requesting NVMe entity (par. 76, the discovery request);
identifying NVMe entities that are associated with the requesting NVMe entity that have a value greater than the last seen value of the requesting NVMe entity; sending a response to the requesting NVMe entity that comprises information about the NVMe entity or NVMe entities with values greater than the last seen value of the requesting NVMe entity (par. 76, “Management service notifier 548 may be configured to initiate discovery log synchronization automatically at runtime, responsive to processing the mapping request, to provide real-time discovery log updates and synchronization across fabric nodes and their discovery controllers,” and par. 99, “At block 816, the prior discovery log may be updated based on the mapping changes determined at block 812. For example, a new log entry may be created for a new storage volume or a prior log entry may be modified or deleted based on the mapping changes to generate an updated discovery log. A generation counter may be incremented to identify the updated discovery log.”).
With respect to claim 2, Dhatchinamoorthy teaches the processor-implemented method of claim 1 wherein the entry also comprises an indication of what changed for the changed NVMe entity (par. 99).
With respect to claim 3, Dhatchinamoorthy teaches the processor-implemented method of claim 1 wherein the one or more other NVMe entities that are associated with the changed NVMe entity are NVMe entities that are in a zone with the changed NVMe entity (par. 77, the storage volume/namespace corresponding to the claimed zone).
With respect to claim 4, Dhatchinamoorthy teaches the processor-implemented method of claim 1 wherein the value is a counter value and the method further comprises:
updating the requesting NVMe entity’s last seen counter value in an entry in the datastore to a highest counter value of an NVMe entity that is included in the response sent to the requesting NVMe entity (par. 103).
With respect to claim 5, Dhatchinamoorthy teaches the processor-implemented method of claim 1 wherein the response is a response to a get log page request (par. 76).
With respect to claim 6, Dhatchinamoorthy teaches the processor-implemented method of claim 1 wherein the response includes an indication of what changed (par. 76).
With respect to claim 7, Dhatchinamoorthy teaches the processor-implemented method of claim 1 further comprising:
determining from a log page request whether the requesting NVMe entity is requesting a subset of log page entries based upon versioning or requesting all log page entries (par. 76, complete set of discovery log entries).
With respect to claim 8, Dhatchinamoorthy teaches the processor-implemented method of claim 1 wherein each NVMe entity included in the response has experienced at least one change since the last seen value of the requesting NVMe entity was set (par. 76).
With respect to claim 16, Dhatchinamoorthy teaches a processor-implemented method comprising:
responsive to detecting, by a centralized discovery controller (CDC), a change to a non- volatile memory express (NVMe) entity, creating or updating an entry in a datastore that correlates the NVMe entity that experienced a change (“the changed NVMe entity”) to an event indicator (par. 74, incrementing the generation counter);
receiving, at the CDC, a request for information from a requesting NVMe entity, in which the request comprises a last seen value of the requesting NVMe entity (par. 76, the discovery request);
identifying NVMe entities that are associated with the requesting NVMe entity that have a value greater than the last seen value of the requesting NVMe entity; and sending, from the CDC, a response to the requesting NVMe entity that comprises information about the NVMe entity or NVMe entities with values greater than the last seen value of the requesting NVMe entity (par. 76, “Management service notifier 548 may be configured to initiate discovery log synchronization automatically at runtime, responsive to processing the mapping request, to provide real-time discovery log updates and synchronization across fabric nodes and their discovery controllers,” and par. 99, “At block 816, the prior discovery log may be updated based on the mapping changes determined at block 812. For example, a new log entry may be created for a new storage volume or a prior log entry may be modified or deleted based on the mapping changes to generate an updated discovery log. A generation counter may be incremented to identify the updated discovery log.”).
With respect to claim 17, Dhatchinamoorthy teaches the processor-implemented method of claim 16 wherein the request from the requesting NVMe entity is triggered by one condition from a set of one or more conditions (par. 76, the discovery request).
With respect to claim 18, Dhatchinamoorthy teaches the processor-implemented method of claim 17 wherein one condition is expiration of a time interval (par. 85).
With respect to claim 19, Dhatchinamoorthy teaches the processor-implemented method of claim 17 wherein one condition is receipt, by the requesting NVMe entity, of a notification from the CDC that a change has occurred (par. 76).
With respect to claim 20, Dhatchinamoorthy teaches the processor-implemented method of claim 16 wherein:
if the value is a counter value, the method further comprises:
updating the requesting NVMe entity’s last seen counter value in an entry in the datastore to a highest counter value of an NVMe entity that is included in the response sent to the requesting NVMe entity (par. 103); and
if the value is a timestamp value, the method further comprises:
purging all entries that were reported to NVMe entities that are associated with the changed NVMe via zoning (par. 77, the storage volume/namespace corresponding to the claimed zone).
Claims 9-15 are an information handling system corresponding to claims 1-4 and 6-7, and are rejected using similar logic.
Response to Arguments
Applicant’s arguments, see remarks, filed 12/11/2025, with respect to the rejection(s) of claim(s) 1-8 and 16-20 under 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of 35 U.S.C. 102(a)(1) as being anticipated by Dhatchinamoorthy et al., US PGPub 2021/0397351.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RYAN DARE whose telephone number is (571)272-4069. The examiner can normally be reached M-F 9:00-5:00.
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, Hosain Alam can be reached at 571-272-3978. 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.
/RYAN DARE/Examiner, Art Unit 2132
/HOSAIN T ALAM/Supervisory Patent Examiner, Art Unit 2132
Prosecution Insights