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 .
Claims 28-46 are pending.
Claims 28-30, 32, 34-37, 39, and 41-46 are amended.
Claims 1-27 were cancelled prior to prosecution beginning. No claims have been added or cancelled.
Response to Arguments
Applicant’s arguments with respect to the Sections 102 and 103 rejections have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 28-46 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 20220407895 to Surana et al. in view of U.S. Patent Application Publication No. 20230345349 to Kim et al.
With regards to claim 28, Surana et al. teaches a communications network device configured to implement a lawful interception (LI) administration function (ADMF), the communications network device comprising interface circuitry, a processor, and a memory comprising instructions executable by the processor (paragraph [0021], “The system comprises one or more processors, memory in electronic communication with the one or more processors, and instructions stored in the memory. The instructions are executable by the one or more processors to cause a network element to identify a first ADMF among the plurality of ADMFs in the ADMF set as the active ADMF. At any given point in time only one ADMF among the plurality of ADMFs is identified as the active ADMF.”), wherein execution of the instructions by the processor causes the communications network device to:
send, to a network element (NE), an X1 request message configured to request the NE to send, to the LI ADMF (paragraph [0082], “The X1 interface can be based on communication between two entities: a controlling function (e.g., a CSP ADMF) and a controlled function (e.g., a network element or network function).”), status information of … a standard X1 GetAllDetailsResponse message (paragraph [0083], “An X1 transaction can include a request followed by a response. A request can be sent in either direction. In other words, either the ADMF or the network element can initiate the request. The side initiating the request may be referred to as the requester. The other side (which receives and responds to the request) may be referred to as the responder. An ADMF can send a request in order to distribute information and/or request status from a network element. A network element can send a request in order to deliver fault reports or other information.”); and
receive from the NE an X1 response message that includes the requested status information (paragraph [0087], “An issue report can be sent at the start of a fault. A network element can report faults when responding to a status-getting message. A network element can also indicate when a fault has been cleared.”; paragraph [0088], “Messages sent via the X1 interface can include the following information: an ADMF ID that identifies the ADMF to the network element, a network element identifier that identifies the network element to the ADMF, a message timestamp indicating the time the message was sent by the requester, a version identifier indicating the version of ETSI TS 103 221-1 that was used for encoding the message, and an X1 transaction identifier that is used to correlate a request and a response. In addition to the information just described, a request message sent via the X1 interface can indicate the type of request being made and contain the appropriate request parameters for that type of request.”), but fails to explicitly teach a request message configured to request status information of fewer than all fields of a standard X1 GetAllDetailsResponse message.
However Kim et al. teaches send, to a network element (NE), an .. request message configured to request the NE to send, to the … status information of fewer than all fields of a standard X1 GetAllDetailsResponse message (paragraph [0581], “Referring to FIG. 44 , an Extended Request element may include an element ID field, a length field, an Element ID extension field, a Requested Element ID field, and/or a Requested Element IDs Extensions field. The element ID field and the length field may be configured similarly as the element ID field and the length field of FIG. 43 . The Element ID extension field may be combined with the Element ID field, so as to configure the Extended Element ID.”; paragraph [0633], “The Requested Element ID field contains one of the Element IDs used to indicate an extended element. The Requested Element ID Extensions field contains a list of 1-octet element ID extension values that, combined with the value of the Requested Element ID field, identify elements that arc requested to be included in the Probe Response or Information Response frame. The values in this field are listed in increasing order. The requested elements within an Extended Request element transmitted in a Probe Request frame do not identify an element that will be included in the Probe Response frame even in the absence of the Request element, or will be excluded from the Probe Response frame even in the presence of the Extended Request element.”).
This part of Kim et al. is applicable to the system of Surana et al. as they both share characteristics and capabilities, namely, they are directed to communications messaging systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the GetAllDetailsResponse requests of Surana et al. to include the limited status request messaging as taught by Kim et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Surana et al. in order to allow for specific information to be requested (see the paragraph [0581] of Kim et al.).
With regards to claim 29, Surana et al. teaches the X1 request message is configured to request the NE to send, to the LI ADMF, status information of a single field of a standard X1 GetAllDetailsResponse message (paragraph [0106], “A ping message can be sent either from the network element to the ADMF or vice versa. A ping message can be sent at any time to get a response over the X1 interface. In some embodiments, a ping request message may not include any request parameters. A ping response message may include a field that includes either an OK response or an error message. In some embodiments, a ping message can be defined in accordance with section 6.6.1 of ETSI TS 103 221-1 version 1.7.1.”).
With regards to claim 30, Surana et al. teaches the X1 request message is configured to request the NE to send, to the LI ADMF, status information of a ListOfTaskResponseDetails field of a standard X1 GetAllDetailsResponse message (paragraph [0013], “In some embodiments, the auditing request message can comprise a GetAllDetails request message, and the auditing response message can comprise a GetAllDetails response message”; paragraph [0051], “The GetAllDetails request message can include the ADMF ID 106. However, because the same ADMF ID 106 is associated with each ADMF 104 in the ADMF set 102, the network element 108 does not know from the GetAllDetails request message which ADMF 104 is the active ADMF 104.”).
With regards to claim 31, Surana et al. teaches the X1 request message is configured to request the NE to send, to the LI ADMF, TaskDetails of all tasks relating to a LI target list of the NE (paragraph [0089], “Some messages can be sent from the ADMF to the network element. Examples of such messages include an ActivateTask message, a ModifyTask message, a DeactivateTask message, a DeactivateAllTasks message, a CreateDestination message, a ModifyDestination message, a RemoveDestination message, a RemoveAllDestinations message, a GetTaskDetails message, a GetDestinationDetails message, a GetNEStatus message, a GetAllDetails message, and a ListAllDetails message. Some messages can be sent from the network element to the ADMF.”).
With regards to claim 32, Surana et al. teaches the X1 request message is configured to request the NE to send, to the LI ADMF, status information of a ListOfDestinationResponseDetails field of a standard X1 GetAllDetailsResponse message (paragraph [0089], “Some messages can be sent from the ADMF to the network element. Examples of such messages include an ActivateTask message, a ModifyTask message, a DeactivateTask message, a DeactivateAllTasks message, a CreateDestination message, a ModifyDestination message, a RemoveDestination message, a RemoveAllDestinations message, a GetTaskDetails message, a GetDestinationDetails message, a GetNEStatus message, a GetAllDetails message, and a ListAllDetails message. Some messages can be sent from the network element to the ADMF.”).
With regards to claim 33, Surana et al. teaches the X1 request message is configured to request the NE to send, to the LI ADMF, DestinationDetails of all destinations relating to a LI target list of the NE (paragraph [0099], “A GetDestinationDetails message can be sent from the ADMF to the network element. A GetDestinationDetails message can be used by the ADMF to retrieve the details of a particular destination. In some embodiments, a GetDestinationDetails message can be defined in accordance with section 6.4.3 of ETSI TS 103 221-1 version 1.7.1.”; paragraph [0116], “POIs 518 can be divided into two categories. Directly provisioned POIs 518 can be provisioned by the lawful interception provisioning function (LIPF) 524. Triggered POIs 518 can be triggered by a triggering function 526. The directly provisioned POIs 518 detect the target's communications that should be intercepted, and then derive the intercept related information or communication contents from that target's communications. The triggered POIs 518 detect the target's communications based on the trigger received from an associated triggering function 526 and then derive the intercept related information or communication contents of the target's communications.”).
With regards to claim 34, Surana et al. teaches the X1 request message is an X1 GetAllDetailsRequest message that includes a request parameter configured to request the NE to send, to the LI ADMF, status information … of the fields of a standard X1 GetAllDetailsResponse message (paragraph [0026], “In some embodiments, the auditing request message can comprise a GetAllDetails request message, and the auditing response message can comprise a GetAllDetails response message.”; paragraphs [0050]-[0052]), but fails to explicitly teach a request message configured to request status information of fewer than all fields of a standard X1 GetAllDetailsResponse message.
However Kim et al. teaches a request message that includes a request parameter configured to request the NE to send, to the LI ADMF, status information of fewer than all of the fields of the standard X1 GetAllDetailsResponse message (paragraph [0581], “Referring to FIG. 44 , an Extended Request element may include an element ID field, a length field, an Element ID extension field, a Requested Element ID field, and/or a Requested Element IDs Extensions field. The element ID field and the length field may be configured similarly as the element ID field and the length field of FIG. 43 . The Element ID extension field may be combined with the Element ID field, so as to configure the Extended Element ID.”; paragraph [0633], “The Requested Element ID field contains one of the Element IDs used to indicate an extended element. The Requested Element ID Extensions field contains a list of 1-octet element ID extension values that, combined with the value of the Requested Element ID field, identify elements that arc requested to be included in the Probe Response or Information Response frame. The values in this field are listed in increasing order. The requested elements within an Extended Request element transmitted in a Probe Request frame do not identify an element that will be included in the Probe Response frame even in the absence of the Request element, or will be excluded from the Probe Response frame even in the presence of the Extended Request element.”).
This part of Kim et al. is applicable to the system of Surana et al. as they both share characteristics and capabilities, namely, they are directed to communications messaging systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the GetAllDetailsResponse requests of Surana et al. to include the limited status request messaging as taught by Kim et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Surana et al. in order to allow for specific information to be requested (see the paragraph [0581] of Kim et al.).
With regards to claim 35, Surana et al. teaches a communications network device configured to implement a network element (NE), the communications network device comprising interface circuitry, a processor, and a memory comprising instructions executable by the processor (paragraph [0021], “The system comprises one or more processors, memory in electronic communication with the one or more processors, and instructions stored in the memory. The instructions are executable by the one or more processors to cause a network element to identify a first ADMF among the plurality of ADMFs in the ADMF set as the active ADMF. At any given point in time only one ADMF among the plurality of ADMFs is identified as the active ADMF.”), wherein execution of the instructions by the processor causes the communications network device to:
receive, from a lawful interception (LI) administration function (ADMF), an X1 request message configured to request the NE to send, to the LI ADMF, status information of …. a standard X1 GetAllDetailsResponse message (paragraph [0083], “An X1 transaction can include a request followed by a response. A request can be sent in either direction. In other words, either the ADMF or the network element can initiate the request. The side initiating the request may be referred to as the requester. The other side (which receives and responds to the request) may be referred to as the responder. An ADMF can send a request in order to distribute information and/or request status from a network element. A network element can send a request in order to deliver fault reports or other information.”);
obtain the requested status information from a data store of the NE (paragraph [0087], “A network element can report faults when responding to a status-getting message. A network element can also indicate when a fault has been cleared.”); and
send an X1 response message to the LI ADMF including the requested status information obtained from the data store (paragraph [0061], “At 235, after the second ADMF 104-2 transitions from the standby state to the active state, the second ADMF 104-2 sends an auditing request message to the network element 108. At 235, the network element 108 receives the auditing request message. At 237, the network element 108 sends an auditing response message that is received by the second ADMF 104-2. As before, the auditing request message can be a GetAllDetails request message, and the auditing response message can be a GetAllDetails response message.”; paragraph [0100], “A GetNEStatus message can be sent from the ADMF to the network element. A GetNEStatus message can be used by the ADMF to determine the status of the network element. In some embodiments, a GetNEStatus message can be defined in accordance with section 6.4.4 of ETSI TS 103 221-1 version 1.7.1.”) but fails to explicitly teach a request message configured to request status information of fewer than all fields of a standard X1 GetAllDetailsResponse message.
However Kim et al. teaches to receive a request message configured to request the NE to send status information of fewer than all fields of a standard X1 GetAllDetailsResponse message (paragraph [0581], “Referring to FIG. 44 , an Extended Request element may include an element ID field, a length field, an Element ID extension field, a Requested Element ID field, and/or a Requested Element IDs Extensions field. The element ID field and the length field may be configured similarly as the element ID field and the length field of FIG. 43 . The Element ID extension field may be combined with the Element ID field, so as to configure the Extended Element ID.”; paragraph [0633], “The Requested Element ID field contains one of the Element IDs used to indicate an extended element. The Requested Element ID Extensions field contains a list of 1-octet element ID extension values that, combined with the value of the Requested Element ID field, identify elements that arc requested to be included in the Probe Response or Information Response frame. The values in this field are listed in increasing order. The requested elements within an Extended Request element transmitted in a Probe Request frame do not identify an element that will be included in the Probe Response frame even in the absence of the Request element, or will be excluded from the Probe Response frame even in the presence of the Extended Request element.”).
This part of Kim et al. is applicable to the system of Surana et al. as they both share characteristics and capabilities, namely, they are directed to communications messaging systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the GetAllDetailsResponse requests of Surana et al. to include the limited status request messaging as taught by Kim et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Surana et al. in order to allow for specific information to be requested (see the paragraph [0581] of Kim et al.).
With regards to claim 36, Surana et al. teaches the X1 request message is configured to request the NE to send, to the LI ADMF, status information of a single field of the standard X1 GetAllDetailsResponse message (paragraph [0106], “A ping message can be sent either from the network element to the ADMF or vice versa. A ping message can be sent at any time to get a response over the X1 interface. In some embodiments, a ping request message may not include any request parameters. A ping response message may include a field that includes either an OK response or an error message. In some embodiments, a ping message can be defined in accordance with section 6.6.1 of ETSI TS 103 221-1 version 1.7.1.”).
With regards to claim 37, Surana et al. teaches the X1 request message is configured to request the NE to send, to the LI ADMF, status information of a ListOfTaskResponseDetails field of the standard X1 GetAllDetailsResponse message (paragraph [0013], “In some embodiments, the auditing request message can comprise a GetAllDetails request message, and the auditing response message can comprise a GetAllDetails response message”; paragraph [0051], “The GetAllDetails request message can include the ADMF ID 106. However, because the same ADMF ID 106 is associated with each ADMF 104 in the ADMF set 102, the network element 108 does not know from the GetAllDetails request message which ADMF 104 is the active ADMF 104.”).
With regards to claim 38, Surana et al. teaches the X1 request message is configured to request the NE to send, to the LI ADMF, TaskDetails of all tasks relating to a LI target list of the NE (paragraph [0089], “Some messages can be sent from the ADMF to the network element. Examples of such messages include an ActivateTask message, a ModifyTask message, a DeactivateTask message, a DeactivateAllTasks message, a CreateDestination message, a ModifyDestination message, a RemoveDestination message, a RemoveAllDestinations message, a GetTaskDetails message, a GetDestinationDetails message, a GetNEStatus message, a GetAllDetails message, and a ListAllDetails message. Some messages can be sent from the network element to the ADMF.”).
With regards to claim 39, Surana et al. teaches the X1 request message is configured to request the NE to send, to the LI ADMF, status information of a ListOfDestinationResponseDetails field of the standard X1 GetAllDetailsResponse message (paragraph [0089], “Some messages can be sent from the ADMF to the network element. Examples of such messages include an ActivateTask message, a ModifyTask message, a DeactivateTask message, a DeactivateAllTasks message, a CreateDestination message, a ModifyDestination message, a RemoveDestination message, a RemoveAllDestinations message, a GetTaskDetails message, a GetDestinationDetails message, a GetNEStatus message, a GetAllDetails message, and a ListAllDetails message. Some messages can be sent from the network element to the ADMF.”).
With regards to claim 40, Surana et al. the X1 request message is configured to request the NE to send, to the LI ADMF, DestinationDetails of all destinations relating to a LI target list of the NE (paragraph [0089], “Some messages can be sent from the ADMF to the network element. Examples of such messages include an ActivateTask message, a ModifyTask message, a DeactivateTask message, a DeactivateAllTasks message, a CreateDestination message, a ModifyDestination message, a RemoveDestination message, a RemoveAllDestinations message, a GetTaskDetails message, a GetDestinationDetails message, a GetNEStatus message, a GetAllDetails message, and a ListAllDetails message. Some messages can be sent from the network element to the ADMF.”).
With regards to claim 41, Surana et al. teaches the X1 request message is an X1 GetAllDetailsRequest message that includes a request parameter configured to request the NE to send, to the LI ADMF, status information … of the fields of an X1 GetAllDetailsResponse message (paragraph [0026], “In some embodiments, the auditing request message can comprise a GetAllDetails request message, and the auditing response message can comprise a GetAllDetails response message.”; paragraphs [0050]-[0052]), but fails to explicitly teach requesting status information of fewer than all of the fields.
However Kim et al. teaches the request message is a message that includes a request parameter configured to request the NE to send status information of fewer than all of the fields of an X1 GetAllDetailsResponse message (paragraph [0581], “Referring to FIG. 44 , an Extended Request element may include an element ID field, a length field, an Element ID extension field, a Requested Element ID field, and/or a Requested Element IDs Extensions field. The element ID field and the length field may be configured similarly as the element ID field and the length field of FIG. 43 . The Element ID extension field may be combined with the Element ID field, so as to configure the Extended Element ID.”; paragraph [0633], “The Requested Element ID field contains one of the Element IDs used to indicate an extended element. The Requested Element ID Extensions field contains a list of 1-octet element ID extension values that, combined with the value of the Requested Element ID field, identify elements that arc requested to be included in the Probe Response or Information Response frame. The values in this field are listed in increasing order. The requested elements within an Extended Request element transmitted in a Probe Request frame do not identify an element that will be included in the Probe Response frame even in the absence of the Request element, or will be excluded from the Probe Response frame even in the presence of the Extended Request element.”).
This part of Kim et al. is applicable to the system of Surana et al. as they both share characteristics and capabilities, namely, they are directed to communications messaging systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the GetAllDetailsResponse requests of Surana et al. to include the limited status request messaging as taught by Kim et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Surana et al. in order to allow for specific information to be requested (see the paragraph [0581] of Kim et al.).
With regards to claim 42, Surana et al. teaches the request parameter is configured to request the NE to send, to the LI ADMF, status information of a single field of the standard X1 GetAllDetailsResponse message (paragraph [0106], “A ping message can be sent either from the network element to the ADMF or vice versa. A ping message can be sent at any time to get a response over the X1 interface. In some embodiments, a ping request message may not include any request parameters. A ping response message may include a field that includes either an OK response or an error message. In some embodiments, a ping message can be defined in accordance with section 6.6.1 of ETSI TS 103 221-1 version 1.7.1.”).
With regards to claim 43, Surana et al. teaches
the request parameter is configured to request the NE to send, to the LI ADMF, status information of a ListOfTaskResponseDetails field of the standard X1 GetAllDetailsResponse message (paragraph [0013], “In some embodiments, the auditing request message can comprise a GetAllDetails request message, and the auditing response message can comprise a GetAllDetails response message”; paragraph [0051], “The GetAllDetails request message can include the ADMF ID 106. However, because the same ADMF ID 106 is associated with each ADMF 104 in the ADMF set 102, the network element 108 does not know from the GetAllDetails request message which ADMF 104 is the active ADMF 104.”); and
the X1 response message is a GetAllTaskDetails response message (paragraph [0101], “A GetAllDetails message can be sent from the ADMF to the network element. A GetAllDetails message can be used by the ADMF to determine the details of all tasks and destinations on the network element as well as to determine the status of the network element itself. In some embodiments, a GetAllDetails message can be defined in accordance with section 6.4.5 of ETSI TS 103 221-1 version 1.7.1.”) …but fails to explicitly teach a response message having the single ListOfTaskResponseDetails field.
However Kim et al. teaches the request message and response message that may be limited based on specific requested element information (paragraph [0581], “Referring to FIG. 44 , an Extended Request element may include an element ID field, a length field, an Element ID extension field, a Requested Element ID field, and/or a Requested Element IDs Extensions field. The element ID field and the length field may be configured similarly as the element ID field and the length field of FIG. 43 . The Element ID extension field may be combined with the Element ID field, so as to configure the Extended Element ID.”; paragraph [0633], “The Requested Element ID field contains one of the Element IDs used to indicate an extended element. The Requested Element ID Extensions field contains a list of 1-octet element ID extension values that, combined with the value of the Requested Element ID field, identify elements that arc requested to be included in the Probe Response or Information Response frame. The values in this field are listed in increasing order. The requested elements within an Extended Request element transmitted in a Probe Request frame do not identify an element that will be included in the Probe Response frame even in the absence of the Request element, or will be excluded from the Probe Response frame even in the presence of the Extended Request element.”).
This part of Kim et al. is applicable to the system of Surana et al. as they both share characteristics and capabilities, namely, they are directed to communications messaging systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the GetAllDetailsResponse requests of Surana et al. to include the limited status request messaging to specific requested element information as taught by Kim et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Surana et al. in order to allow for specific information to be requested (see the paragraph [0581] of Kim et al.).
With regards to claim 44, Surana et al. teaches the request parameter is configured to request the NE to send, to the LI ADMF, status information of a ListOfDestinationResponseDetails field of an X1 GetAllDetailsResponse message to the LI ADMF (paragraph [0089], “Some messages can be sent from the ADMF to the network element. Examples of such messages include an ActivateTask message, a ModifyTask message, a DeactivateTask message, a DeactivateAllTasks message, a CreateDestination message, a ModifyDestination message, a RemoveDestination message, a RemoveAllDestinations message, a GetTaskDetails message, a GetDestinationDetails message, a GetNEStatus message, a GetAllDetails message, and a ListAllDetails message. Some messages can be sent from the network element to the ADMF.”); and
the X1 response message is a GetAllDestinationDetails response message (paragraph [0089], “Some messages can be sent from the ADMF to the network element. Examples of such messages include an ActivateTask message, a ModifyTask message, a DeactivateTask message, a DeactivateAllTasks message, a CreateDestination message, a ModifyDestination message, a RemoveDestination message, a RemoveAllDestinations message, a GetTaskDetails message, a GetDestinationDetails message, a GetNEStatus message, a GetAllDetails message, and a ListAllDetails message. Some messages can be sent from the network element to the ADMF.”) …but fails to explicitly teach a response message having the single ListOfTaskResponseDetails field.
However Kim et al. teaches the request message and response message that may be limited based on specific requested element information (paragraph [0581], “Referring to FIG. 44 , an Extended Request element may include an element ID field, a length field, an Element ID extension field, a Requested Element ID field, and/or a Requested Element IDs Extensions field. The element ID field and the length field may be configured similarly as the element ID field and the length field of FIG. 43 . The Element ID extension field may be combined with the Element ID field, so as to configure the Extended Element ID.”; paragraph [0633], “The Requested Element ID field contains one of the Element IDs used to indicate an extended element. The Requested Element ID Extensions field contains a list of 1-octet element ID extension values that, combined with the value of the Requested Element ID field, identify elements that arc requested to be included in the Probe Response or Information Response frame. The values in this field are listed in increasing order. The requested elements within an Extended Request element transmitted in a Probe Request frame do not identify an element that will be included in the Probe Response frame even in the absence of the Request element, or will be excluded from the Probe Response frame even in the presence of the Extended Request element.”).
This part of Kim et al. is applicable to the system of Surana et al. as they both share characteristics and capabilities, namely, they are directed to communications messaging systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the GetAllDetailsResponse requests of Surana et al. to include the limited status request messaging to specific requested element information as taught by Kim et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Surana et al. in order to allow for specific information to be requested (see the paragraph [0581] of Kim et al.).
With regards to claim 45, Surana et al. teaches
the communications network device as claimed in claim 28 ((paragraph [0082], “The X1 interface can be based on communication between two entities: a controlling function (e.g., a CSP ADMF) and a controlled function (e.g., a network element or network function).”)); and
at least one second communications network device configured to implement respective at least one network element (NE), wherein each second communications network device comprises interface circuitry, a processor, and a memory comprising instructions executable by the processor (paragraph [0021], “The system comprises one or more processors, memory in electronic communication with the one or more processors, and instructions stored in the memory. The instructions are executable by the one or more processors to cause a network element to identify a first ADMF among the plurality of ADMFs in the ADMF set as the active ADMF. At any given point in time only one ADMF among the plurality of ADMFs is identified as the active ADMF.”), wherein execution of the instructions by the processor causes the second communications network device to:
receive, from a lawful interception (LI) administration function (ADMF), an X1 request message configured to request the NE to send, to the LI ADMF, status information of …. a standard X1 GetAllDetailsResponse message (paragraph [0083], “An X1 transaction can include a request followed by a response. A request can be sent in either direction. In other words, either the ADMF or the network element can initiate the request. The side initiating the request may be referred to as the requester. The other side (which receives and responds to the request) may be referred to as the responder. An ADMF can send a request in order to distribute information and/or request status from a network element. A network element can send a request in order to deliver fault reports or other information.”);
obtain the requested status information from a data store of the NE (paragraph [0087], “A network element can report faults when responding to a status-getting message. A network element can also indicate when a fault has been cleared.”); and
send an X1 response message to the LI ADMF including the requested status information obtained from the data store (paragraph [0061], “At 235, after the second ADMF 104-2 transitions from the standby state to the active state, the second ADMF 104-2 sends an auditing request message to the network element 108. At 235, the network element 108 receives the auditing request message. At 237, the network element 108 sends an auditing response message that is received by the second ADMF 104-2. As before, the auditing request message can be a GetAllDetails request message, and the auditing response message can be a GetAllDetails response message.”; paragraph [0100], “A GetNEStatus message can be sent from the ADMF to the network element. A GetNEStatus message can be used by the ADMF to determine the status of the network element. In some embodiments, a GetNEStatus message can be defined in accordance with section 6.4.4 of ETSI TS 103 221-1 version 1.7.1.”), but fails to explicitly teach a request message configured to request status information of fewer than all fields of a standard X1 GetAllDetailsResponse message.
However Kim et al. teaches to receive a request message configured to request the NE to send status information of fewer than all fields of a standard X1 GetAllDetailsResponse message (paragraph [0581], “Referring to FIG. 44 , an Extended Request element may include an element ID field, a length field, an Element ID extension field, a Requested Element ID field, and/or a Requested Element IDs Extensions field. The element ID field and the length field may be configured similarly as the element ID field and the length field of FIG. 43 . The Element ID extension field may be combined with the Element ID field, so as to configure the Extended Element ID.”; paragraph [0633], “The Requested Element ID field contains one of the Element IDs used to indicate an extended element. The Requested Element ID Extensions field contains a list of 1-octet element ID extension values that, combined with the value of the Requested Element ID field, identify elements that arc requested to be included in the Probe Response or Information Response frame. The values in this field are listed in increasing order. The requested elements within an Extended Request element transmitted in a Probe Request frame do not identify an element that will be included in the Probe Response frame even in the absence of the Request element, or will be excluded from the Probe Response frame even in the presence of the Extended Request element.”).
This part of Kim et al. is applicable to the system of Surana et al. as they both share characteristics and capabilities, namely, they are directed to communications messaging systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the GetAllDetailsResponse requests of Surana et al. to include the limited status request messaging as taught by Kim et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Surana et al. in order to allow for specific information to be requested (see the paragraph [0581] of Kim et al.).
With regards to claim 46, Surana et al. teaches
sending, by an LI administration function (ADMF) to a network element (NE) (paragraph [0082], “The X1 interface can be based on communication between two entities: a controlling function (e.g., a CSP ADMF) and a controlled function (e.g., a network element or network function).”), an X1 request message configured to request the NE to send, to the LI ADMF, status information of …. a standard X1 GetAllDetailsResponse message (paragraph [0083], “An X1 transaction can include a request followed by a response. A request can be sent in either direction. In other words, either the ADMF or the network element can initiate the request. The side initiating the request may be referred to as the requester. The other side (which receives and responds to the request) may be referred to as the responder. An ADMF can send a request in order to distribute information and/or request status from a network element. A network element can send a request in order to deliver fault reports or other information.”);
receiving, by the NE, the X1 request message from the LI ADMF (paragraph [0083], “An X1 transaction can include a request followed by a response. A request can be sent in either direction. In other words, either the ADMF or the network element can initiate the request. The side initiating the request may be referred to as the requester. The other side (which receives and responds to the request) may be referred to as the responder. An ADMF can send a request in order to distribute information and/or request status from a network element. A network element can send a request in order to deliver fault reports or other information.”);
obtaining, by the NE, said the requested status information from a data store of the NE (paragraph [0087], “A network element can report faults when responding to a status-getting message. A network element can also indicate when a fault has been cleared.”); and
sending, by the NE to the LI ADMF, an X1 response message including the requested status information obtained from the data store (paragraph [0087], “An issue report can be sent at the start of a fault. A network element can report faults when responding to a status-getting message. A network element can also indicate when a fault has been cleared.”; paragraph [0088], “Messages sent via the X1 interface can include the following information: an ADMF ID that identifies the ADMF to the network element, a network element identifier that identifies the network element to the ADMF, a message timestamp indicating the time the message was sent by the requester, a version identifier indicating the version of ETSI TS 103 221-1 that was used for encoding the message, and an X1 transaction identifier that is used to correlate a request and a response. In addition to the information just described, a request message sent via the X1 interface can indicate the type of request being made and contain the appropriate request parameters for that type of request.”); and
receiving, by the LI ADMF from the NE, the X1 response message including the requested status information (paragraph [0087], “An issue report can be sent at the start of a fault. A network element can report faults when responding to a status-getting message. A network element can also indicate when a fault has been cleared.”; paragraph [0088], “Messages sent via the X1 interface can include the following information: an ADMF ID that identifies the ADMF to the network element, a network element identifier that identifies the network element to the ADMF, a message timestamp indicating the time the message was sent by the requester, a version identifier indicating the version of ETSI TS 103 221-1 that was used for encoding the message, and an X1 transaction identifier that is used to correlate a request and a response. In addition to the information just described, a request message sent via the X1 interface can indicate the type of request being made and contain the appropriate request parameters for that type of request.”), but fails to explicitly teach a request message configured to request status information of fewer than all fields of a standard X1 GetAllDetailsResponse message.
However Kim et al. teaches send, to a network element (NE), an .. request message configured to request the NE to send, to the … status information of fewer than all fields of a standard X1 GetAllDetailsResponse message (paragraph [0581], “Referring to FIG. 44 , an Extended Request element may include an element ID field, a length field, an Element ID extension field, a Requested Element ID field, and/or a Requested Element IDs Extensions field. The element ID field and the length field may be configured similarly as the element ID field and the length field of FIG. 43 . The Element ID extension field may be combined with the Element ID field, so as to configure the Extended Element ID.”; paragraph [0633], “The Requested Element ID field contains one of the Element IDs used to indicate an extended element. The Requested Element ID Extensions field contains a list of 1-octet element ID extension values that, combined with the value of the Requested Element ID field, identify elements that arc requested to be included in the Probe Response or Information Response frame. The values in this field are listed in increasing order. The requested elements within an Extended Request element transmitted in a Probe Request frame do not identify an element that will be included in the Probe Response frame even in the absence of the Request element, or will be excluded from the Probe Response frame even in the presence of the Extended Request element.”).
This part of Kim et al. is applicable to the system of Surana et al. as they both share characteristics and capabilities, namely, they are directed to communications messaging systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the GetAllDetailsResponse requests of Surana et al. to include the limited status request messaging as taught by Kim et al. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Surana et al. in order to allow for specific information to be requested (see the paragraph [0581] of Kim et al.).
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 Joshua D Schneider whose telephone number is (571)270-7120. The examiner can normally be reached on Monday - Friday, 9am-5pm.
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, Jessica Lemieux can be reached on (571)270-3445. 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.
/J.D.S./Examiner, Art Unit 3626
/JESSICA LEMIEUX/Supervisory Patent Examiner, Art Unit 3626
Prosecution Insights