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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/14/2026 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-11 and 13-14 filed on 04/23/2026 have been considered but are not persuasive.
Applicant’s arguments: (Summary of pages 6 – 8, Examiner emphasis – Bold).
… Applicant argues that Khalid, at least does not disclose “determining the application on the basis of the first destination port identifier common to the plurality of applications and the second identifier specific to the application that are received”.
Response:
Examiner respectfully disagrees.
See updated rejection of amended claim 1.
In particular, Khalid discloses techniques for selecting a communication path for forwarding received data packets, where the data is associated with the classification type and encapsulated in Stream Control Transmission Protocol (SCTP) based on an exit path information. The exit path information is associated with the classification type that is also associated with the received data packet. In [0026 and 0032] email and video applications are disclosed as examples of classification types that may be extracted from the classification information inserted in an SCTP header at step 602 and encapsulated in a data chunk or segment in step 604. In fig. 6, to encapsulate the data in SCTP, the network layer address is inserted into an SCTP header at 602. For example, the source port IP address and the destination port address, which define a communication path, can be inserted into an SCTP header. It should be noted that one or more packets of data may be encapsulated in an SCTP data chunk, and multiple SCTP data chunks may be bundled together to form an SCTP packet. Each classification type is associated with a particular port number. That is, the email application may use a particular port number. Thus, the classification type can be a port number associated with the data. The port number can be used to identify the association of data to the email application. Furthermore, consistent with applicant’s disclosure in figs. 1-3, nodes 410, 110 and 310 store applications/classifications, thus, sharing a common port id. Similarly, in fig. 2B, each of nodes 24 and server 30 store applications/classifications sharing a common port id. In fig. 5, steps 502 -508, after receiving a packet at common port (first port identifier) that is common to the applications stored at the node/server, the packet received is classified to determine the particular port number that is associated with received packet and responsible for transporting the identified class of data. Based on identified classification/port number responsible for transporting the received data packet, at step 702, select a queue with the particular port id (second port id) and store the data in the particular queue (704) for transporting the identified application/classification. Therefore, Khalid discloses a first and second port identifiers encapsulated in an SCTP header as required by the amended independent claims.
Furthermore, Schmieder also discloses the claimed limitation of “determining the application on the basis of the first destination port identifier common to plurality of applications and the second identifier specific to the application that are received.” As shown in [0024] and [0023], multiple applications may communicate through the same static port (the claimed “first destination port identifier common to plurality of applications”). The reference further discloses that each application or instance registers a unique connection identifier (e.g., username, email, or a randomly generated ID) ([0022], [0025]), which is a “second identifier specific to the application.” The port listener is described as receiving client connections on the shared port and listening for the unique connection IDs carried in those connections ([0022], [0025]). Upon recognition of the unique connection ID, the port listener directs the socket to the corresponding application ([0022], [0025]), demonstrating that the application is determined by using the shared port together with the application‑specific identifier. Thus, Schmieder teaches determining the application on the basis of first destination port identifier common (Fig. 1A, port 140 – common port for application 115 and 120) to plurality of applications (applications 115 and 120)) and the second identifier (Socket 190 and 195 are port identifiers for applications 115 and 120, respectively) specific to the application (Socket 190 is a port identifier specific to application 115) that are received (Schmieder, fig, 1a -3, [0024-0025], illustrates that applications 115 and 120 each communicate through the same static port 140 with corresponding different clients 145, 150. Applications 115 and 120 are each able to do this at least in part since each application is associated with a separate, corresponding network communication socket 190, 195, respectively. Communication sockets 190, 195 are associated with unique connection identifiers ("IDs", also referred to herein as "unique IDs"), both of which are registered for use with the same static port 14. that are received).
Applicant’s arguments: (Summary of pages 8-10, Examiner emphasis – Bold).
Applicant argued that Schmieder does not disclose, "determining the application on the basis of the first SCTP destination port identifier of the SCTP header, common to the plurality of applications, and the second identifier of the SCTP data fragment specific to the application that are received in the packet of the Stream Control Transmission Protocol."
Response:
Examiner respectfully disagrees.
See updated rejection of amended claim 1 and detailed response to argument 1.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1,8,10-11 and 13-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Khalid et al. (US 2009/0052466 A1) in view of Schmieder et al. (US 2007/0061434 A1).
Regarding claim 1, Khalid discloses a switching method (a path selection method) comprising (Khalid [Abstract;0018] discloses a method for selecting/switching a communication path based on a table with a packet classification type and exit path information provided):
switching (path selection/routing; [0018]) a datum (data packets) relating to an application (Voice/video/email) transported in a Stream Control Transmission Protocol (SCTP) data fragment of a packet of a Stream Control Transmission Protocol (Khalid [0020-0021] data packet received at a network endpoint such as router 12,14,16,18 20 or 22 is processed or analyzed to classification type (voice/video/email/text) associated with the received data packet. The data packet is encapsulated in Stream Control Transmission Protocol (SCTP) and a data path is selected based on the classification of the received data and exit path information provided for each data type classification),
implemented by a multiplexing device (Fig. 1, Routers 12-20) able to transfer data (data packet) relating to a plurality of applications (voice/video/email/text) to processing entities (fig. 1, endpoints – laptop/computer (24), voIP telephone (26), mobile telephone (28), server (30), the switching (path selection/routing) (Khalid, fig. 1, [0019-0021] data packets received at a routers 12-20 related to a plurality of applications (voice/video/email) may be routed through a selected path to processing entities/endpoints such as laptop/computer (24), voIP telephone (26), mobile telephone (28), server (30)), comprising:
receiving, from a terminal device (figs. 1& 4, laptop/computer (24), voIP telephone (26), mobile telephone (28), server (30)), the packet of the Stream Control Transmission Protocol comprising an SCTP header (figs. 2B & 6) containing a first SCTP destination port identifier (figs. 3 & 6, Network Layer Address (602)/access port to apparatus 302) common to the plurality of applications (voice/video/email/text) (Khalid, figs. 1,2B,3,4,6 & 7, [0026;0035 -0037] in fig. 2B, each of nodes 24 and server 30 store applications with different classifications sharing a first destination port id common to all the applications stored at each node. That is, to encapsulate the data in SCTP, the source IP address and the destination address, which define a communication path, can be inserted into an SCTP header at 602. The packet is received at apparatus 302, where a transport optimization proxy 304 in communication with an optimized edge routing module 306, classifies the received data. Each classification is associated with a particular port. Apparatus 302 then transmits data 310 encapsulated in SCTP to other network endpoints based on the particular port associated with the classification as indicated the header the encapsulated packet), and
the SCTP data fragment comprising a second identifier (particular port number associated with a classification type) specific to the application (video/voice or email/text stream) (Khalid, figs. 3-5, steps 402 -410, steps 502-508 [0026;0032] SCTP data packets received by the Transport Optimization Proxy 304 are encapsulated in the header with a classification type of the received packet. In [0026] the classification of the received data is associated with a particular process executed on a computing device. A process can be an email application which may use a particular port number. Thus, in an example, the classification type encapsulated in the STCP packet can be a port number associated with the data. The port number can be used to identify the association of data to the email application and enable the use of the particular port for communication between the application and other terminal devices);
determining the application on the basis of the first SCTP destination port identifier of the header, common (the identifier of nodes 24 and 30 hosting multiple applications) to plurality of applications (email, video or voice) and the second identifier of the SCTP data fragment (particular port number associated with an application data based on data classification) specific to the application (Particular port associated with email application) that are received in the packet of the Stream Control Transmission Protocol (Khalid, figs. 1,2B,3,4,6 & 7, [0026;0035 -0038] in fig. 2B, each of nodes 24 and server 30 store applications with different classifications sharing a first destination port id common to all the applications stored at each node. That is, to encapsulate the data in SCTP, the source IP address and the destination address, which define a communication path, can be inserted into an SCTP header at 602. The packet is received at apparatus 302, where a transport optimization proxy 304 in communication with an optimized edge routing module 306, classifies the received data. Each classification is associated with a particular port. Apparatus 302 then transmits data 310 encapsulated in SCTP to other network endpoints based on the particular port associated with the classification as indicated the header the encapsulated packet), and
in response to the determining of the application being successful (figs. 3-5, [0026; step [502 -508] & fig. 7 steps 702-704 – successful determination of the classification of a received data) transmitting the datum (SCTP data packet) to an entity (endpoints - laptop/computer (24), voIP telephone (26), mobile telephone (28), server (30))) responsible for processing the datum (SCTP data packet) of the application (Video, voice or email/text) (Khalid, fig. 7, [0026;0036 -0037] the transport optimization proxy may include multiple queues, where each queue is associated with or assigned to a classification type. If there are three classification types, then the transport optimization proxy can include three queues, where each queue is associated with an individual classification type. The classification type may be associated with a communication path. For example, the classification type may provide a port number that corresponds to a communication path. Each queue can further be associated with or assigned to each exit path information. [0037] With a classification type, the transport optimization proxy can therefore select a queue that is associated with the classification type at 702 from multiple queues to transmit the packet to a destination device such as laptop/computer (24), voIP telephone (26), mobile telephone (28), server (30)). In [0026] the packet is classified as an email application and the particular port number associated with the email application is used to communication data between a device hosting the email application and other endpoints).
Khalid discloses most of the limitations of the claim 1, however, Schmieder more explicitly discloses determining the application on the basis of the first SCTP destination port identifier common (Fig. 1A, port 140 – common port for application 115 and 120) to plurality of applications (applications 115 and 120)) and the second identifier (Socket 190 and 195 are identifiers of application 115 and 120, respectively) specific to the application (Socket 190 is a port identifier for application 115) that are received.
Schmieder discloses determining the application on the basis of first SCTP destination port identifier of the SCTP header common (Fig. 1A, port 140 – common port for application 115 and 120) to plurality of applications (applications 115 and 120)) and the second identifier of the SCTP data fragment (Socket 190 and 195 are port identifiers for applications 115 and 120, respectively) specific to the application (Socket 190 is a port identifier specific to application 115) that are received in the packet of the Stream Control Transmission Protocol (Schmieder, fig, 1a -3, [0022-0025], illustrates that applications 115 and 120 each communicate through the same static port 140 with corresponding different clients 145, 150. Applications 115 and 120 are each able to do this at least in part since each application is associated with a separate, corresponding network communication socket 190, 195, respectively. Communication sockets 190, 195 are associated with unique connection identifiers ("IDs", also referred to herein as "unique IDs"), both of which are registered for use with the same static port 140) and
in response to the determining of the application being successful, transmitting the datum to an entity responsible for processing the datum of the application (Schmieder, fig, 1a -3, [0024-0025], when port 140 receives TCP communication from client 145 directed to application 115, a listener opened by port listening service (135, FIG. 1A) at port 140 can use the connection ID/port ID associated with TCP communication/packet to identify whether to direct that client communication to application 115 or to application 120 (or some other application, not shown). In response to that determination, the communication/packet is directed to the appropriate application (115 or 120) through the corresponding socket/port id(190 or 195).
One of ordinary skill in the art would have been motivated to combine Khalid and Schmieder because these teachings are from the same field of endeavor with respect to the disclosure of techniques for routing multiport network traffic.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Schmieder into the method by Khalid, enabling a port listening service to dispatch connection services for a single static port to multiple different application instances running in a session level, ensuring delivery of communication to different applications sharing a common initial communication port, Schmieder, [Abstract].
Regarding claim 8, Khalid discloses configuration method comprising (Khalid [Abstract;0018] discloses a method for selecting/switching a communication path based on a table with a packet classification type and exit path information provided):
configuring a packet of a Stream Control Transmission Protocol (SCTP), the packet comprising an SCTP header (figs. 2B & 6) and an SCTP data fragment (data chunk) (Khalid, Fig. 6, [0035;0037] At step 602, the system is configured to encapsulate an SCTP packet with a network layer address, the source IP address and the destination address, which define a communication path, into an SCTP header. At 604, the SCTP header is encapsulated with an SCTP data chunk),
the configuring being implemented by a terminal device (fig. 1, computers 24, Voice-over-IP (VoIP) telephone 26, mobile telephone 28, and servers 30) able to transmit a datum (SCTP data packet) relating to an application (voice, video, email/text) to a multiplexing device (routers 12-20) (Khalid, figs. 1, 2A-2B, [0019-22;0037-0038], the system 10 discloses an interconnection of devices including computers 24, Voice-over-IP (VoIP) telephone 26, mobile telephone 28, and servers 30 that are configured to be capable of transmitting an SCTP data packet which may include voice, video and text data to be transmitted to a router 12-20 that may bundle the SCTP data chunks into a single SCTPP packet for transmission along a communication path) comprising:
parameterizing the SCTP packet with a first SCTP destination port identifier (the identifier of the access port to apparatus 302 is common to all data type classifications) common to a plurality of applications in the SCTP header (encapsulated in the header of an SCTP header) and with a second identifier (port number for an email) specific to the application (email/text) in the SCTP data fragment (Khalid, figs. 1,2B,3,4,6 & 7, [0026;0035 -0038] in fig. 2B, each of nodes 24 and server 30 store applications with different classifications sharing a first destination port id common to all the applications stored at each node. That is, to encapsulate the data in SCTP, the source IP address and the destination address, which define a communication path, can be inserted into an SCTP header.at 602. The packet is received at apparatus 302, where a transport optimization proxy 304 in communication with an optimized edge routing module 306, classifies the received data. Each classification is associated with a particular port. Apparatus 302 then transmits data 310 encapsulated in SCTP to other network endpoints based on the particular port associated with the classification as indicated the header the encapsulated packet. Also, a process/application can be an email application that transmits and receives email data. The email application may use a particular port number. The classification type can be a port number associated with the data. The port number can be used to identify the association of data to the email application and encapsulated in the header of the SCTP packet header); and
transmitting the parameterized SCTP packet to the multiplexing device (Routers 12-20) (Khalid, [0021] the SCTP packet can be transmitted to a multiplexing device such as routers 12-20 based on the information encapsulated in the SCTP packet header and ultimately transmitted to an appropriated process/application through a port number corresponding to an appropriate classification of the received communication packet).
Khalid discloses most of the limitations of the claim 1, however, Schmieder more explicitly discloses parameterizing the packet with a first destination port identifier common to a plurality of applications in the SCTP header and with a second identifier specific to the application in the SCTP data fragment.
Schmieder discloses parameterizing the packet with a first destination port identifier common to a plurality of applications (Fig. 1A, port 140 – common port for application 115 and 120) in the SCTP header and with a second identifier specific to the application (Socket 190 and 195 are port identifiers for applications 115 and 120, respectively) in the SCTP data fragment (Schmieder, fig, 1a -3, [0022-0025], illustrates that applications 115 and 120 each communicate through the same static port 140 with corresponding different clients 145, 150. Applications 115 and 120 are each able to do this at least in part since each application is associated with a separate, corresponding network communication socket 190, 195, respectively. Communication sockets 190, 195 are associated with unique connection identifiers ("IDs", also referred to herein as "unique IDs"), both of which are registered for use with the same static port 140) and
transmitting the parameterized packet to the multiplexing device (Schmieder, fig, 1a -3, [0024-0025], when port 140 at a multiplexing device receives TCP communication from client 145 directed to application 115, a listener opened by port listening service (135, FIG. 1A) at port 140 can use the connection ID/port ID associated with TCP communication/packet to identify whether to direct that client communication to application 115 or to application 120 (or some other application, not shown). In response to that determination, the communication/packet is directed to the appropriate application (115 or 120) through the corresponding socket/port id (190 or 195).
The motivation to combine is similar to that of claim 1.
Regarding claim 10, Khalid discloses a switching device (Transport Optimization Proxy - 304) able to transfer data relating to a plurality of applications (voice, video and text) to processing entities (computers 24, Voice-over-IP (VoIP) telephone 26, mobile telephone 28, and servers 30) (Khalid, fig. 7,[0027;0036] the transport optimization proxy 304 uses classification information included in the SCTP packet header to identify a port number associated with the queue corresponds to a communication path for a particular application),
one of the data being transported in an SCTP data fragment of a packet of a Stream Control Transmission Protocol (Khalid, fig. 2B, [0024] discloses a SCTP data packet is transmitted between devices 24 and 30. SCTP can transport multiple data streams and the TCP sessions can therefore be tunneled into a single SCTP session), comprising:
a receiver (Routers 12-20) configured to receive, from a terminal device (computers 24, Voice-over-IP (VoIP) telephone 26, mobile telephone 28, and servers 30), the packet of the Stream Control Transmission Protocol comprising an SCTP header containing a first SCTP destination port identifier (the identifier of nodes 24 and 30 hosting multiple applications) common to the plurality of applications (voice/video/email/text) (Khalid, figs. 1&3, [0026-0027] Routers 12-20 is configured to receive SCTP data packet from terminal devices like computers 24, Voice-over-IP (VoIP) telephone 26, mobile telephone 28, and servers 30. The SCTP data packet is encapsulated with a packet header containing a network layer address associated with a router 12-20, where the address is common to all the applications (voice/video/email/text) served/processed by the associated router), and
the SCTP data fragment comprising a second identifier specific to the application (SCTP data packet classification type associated which may be a port number of a process/application) at least one processor (transport optimization proxy 304) configured a determine the application on the basis of the first SCTP destination port identifier of the SCTP header common to the plurality of applications ((the identifier of nodes 24 and 30 hosting multiple applications) and the second identifier SCTP data fragment specific to the application (port number for an email) that are received in the packet of the Stream Control Transmission Protocol (Khalid, figs. 1,2B,3,4,6 & 7, [0026;0035 -0037] (Khalid, figs. 1,2B,3,4,6 & 7, [0026;0035 -0038] in fig. 2B, each of nodes 24 and server 30 store applications with different classifications sharing a first destination port id common to all the applications stored at each node. That is, to encapsulate the data in SCTP, the source IP address and the destination address, which define a communication path, can be inserted into an SCTP header.at 602. The packet is received at apparatus 302, where a transport optimization proxy 304 in communication with an optimized edge routing module 306, classifies the received data. Each classification is associated with a particular port. Also, a process/application can be an email application that transmits and receives email data. The email application may use a particular port number. The classification type can be a port number associated with the data. The port number can be used to identify the association of data to the email application and encapsulated in the header of the SCTP packet header); and
a transmitter (transport optimization proxy) configured to transmit the datum (SCTP data packet) to an entity (laptop/computer (24), voIP telephone (26), mobile telephone (28), server (30)) responsible for processing the datum of the application if in response to the application is being determined (Khalid, fig. 7, [0021; 0036 -0037] the SCTP packet can be transmitted to a multiplexing device such as routers 12-20 based on the information encapsulated in the SCTP packet header and ultimately transmitted to an appropriated process/application through a port number corresponding to an appropriate classification of the received communication packet. The transport optimization proxy may include multiple queues, where each queue is associated with or assigned to a classification type. If there are three classification types, then the transport optimization proxy can include three queues, where each queue is associated with an individual classification type. The classification type may be associated with a communication path. For example, the classification type may provide a port number that corresponds to a communication path. [0037] With a classification type, the transport optimization proxy can therefore select a queue that is associated with the classification type (specific application) at 702 from multiple queues associated with multiple applications to transmit the packet to a destination device such as laptop/computer (24), voIP telephone (26), mobile telephone (28), server (30) for processing).
Khalid discloses most of the limitations of the claim 1, however, Schmieder more explicitly discloses at least one processor configured to determine the application on the basis of the first destination port identifier common to the plurality of applications and the second identifier specific to the application that are received.
Schmieder discloses at least one processor configured to determine the application on the basis of the first destination port identifier common to the plurality of applications and the second identifier specific to the application that are received (Schmieder, fig, 1a -3, [0022-0025], illustrates that applications 115 and 120 each communicate through the same static port 140 with corresponding different clients 145, 150. Applications 115 and 120 are each able to do this at least in part since each application is associated with a separate, corresponding network communication socket 190, 195, respectively. Communication sockets 190, 195 are associated with unique connection identifiers ("IDs", also referred to herein as "unique IDs"), both of which are registered for use with the same static port 140); and
a transmitter configured to transmit the datum to an entity responsible for processing the
datum of the application in response to the application being determined (Schmieder, fig, 1a -3, [0024-0025], when port 140 at a multiplexing device receives TCP communication from client 145 directed to application 115, a listener opened by port listening service (135, FIG. 1A) at port 140 can use the connection ID/port ID associated with TCP communication/packet to identify whether to direct that client communication to application 115 or to application 120 (or some other application, not shown). In response to that determination, the communication/packet is directed to the appropriate application (115 or 120) through the corresponding socket/port id (190 or 195).
The motivation to combine is similar to that of claim 1.
Regarding claim 11, Khalid discloses a device (laptop/computer (24), voIP telephone (26), mobile telephone (28), server (30)) for configuring a packet of a Stream Control Transmission Protocol (SCTP), the packet comprising a header and a data fragment, the device (laptop/computer (24), voIP telephone (26), mobile telephone (28), server (30)) (Khalid, figs. 1, 2A-2B & 6 [0019-22;0035-0038], the system 10 discloses an interconnection of devices including computers 24, Voice-over-IP (VoIP) telephone 26, mobile telephone 28, and servers 30 that are configured to transmit an SCTP data packet which is encapsulated with a header that port identifiers and data chunk) comprising:
at least one processor (laptop/computer (24), voIP telephone (26), mobile telephone (28), server (30)) configured a parameterize the packet with a first SCTP destination port identifier, common to a plurality of applications (the identifier of nodes 24 and 30 hosting multiple applications) in the SCTP header and with a second identifier (port number associated with a packet classification) specific to an application (voice, video/email/text) in the SCTP data fragment (Khalid, figs. 1,2B,3,4,6 & 7, [0026;0036 -0037] a data is received at apparatus 302 through a first port identifier that identifies an access port through which the apparatus 302 receives data for plurality of applications. That is, the access port to apparatus 302 is common to different applications. The apparatus 302 include a transport optimization proxy 304 which in communication with an optimized edge routing module 306, classifies the received data, where the classification is associated with a particular port number. Also, a process/application can be an email application that transmits and receives email data. The email application may use a particular port number. The classification type can be a port number associated with the data. The port number can be used to identify the association of data to the email application and encapsulated in the header of the SCTP packet header) and
a transmitter (laptop/computer (24), voIP telephone (26), mobile telephone (28) or server (30)), configured to transmit the parameterized SCTP packet to a multiplexing device (router 12-20) (Khalid, fig. 7, [0021; 0036 -0037] the SCTP packet can be transmitted to a multiplexing device such as routers 12-20 based on the information encapsulated in the SCTP packet header and ultimately transmitted to an appropriated process/application through a port number corresponding to an appropriate classification of the received communication packet. The transport optimization proxy may include multiple queues, where each queue is associated with or assigned to a classification type. If there are three classification types, then the transport optimization proxy can include three queues, where each queue is associated with an individual classification type. The classification type may be associated with a communication path. For example, the classification type may provide a port number that corresponds to a communication path. [0037] With a classification type, the transport optimization proxy can therefore select a queue that is associated with the classification type (specific application) at 702 from multiple queues associated with multiple applications to transmit the packet to a destination device such as laptop/computer (24), voIP telephone (26), mobile telephone (28), server (30) for processing).
Khalid discloses most of the limitations of the claim 1, however, Schmieder more explicitly discloses at least one processor configured a parameterize the packet with a first SCTP destination port identifier, common to a plurality of applications in the SCTP header and with a second identifier specific to an application in the SCTP data fragment.
Schmieder discloses at least one processor configured a parameterize the packet with a first SCTP destination port identifier, common to a plurality of applications in the SCTP header and with a second identifier specific to an application in the SCTP data fragment (Schmieder, fig, 1a -3, [0022-0025], illustrates that applications 115 and 120 each communicate through the same static port 140 with corresponding different clients 145, 150. Applications 115 and 120 are each able to do this at least in part since each application is associated with a separate, corresponding network communication socket 190, 195, respectively. Communication sockets 190, 195 are associated with unique connection identifiers ("IDs", also referred to herein as "unique IDs"), both of which are registered for use with the same static port 140);
a transmitter configured to transmit the parameterized SCTP packet to a multiplexing device (Schmieder, fig, 1a -3, [0024-0025], when port 140 at a multiplexing device receives TCP communication from client 145 directed to application 115, a listener opened by port listening service (135, FIG. 1A) at port 140 can use the connection ID/port ID associated with TCP communication/packet to identify whether to direct that client communication to application 115 or to application 120 (or some other application, not shown). In response to that determination, the communication/packet is directed to the appropriate application (115 or 120) through the corresponding socket/port id (190 or 195).
The motivation to combine is similar to that of claim 1.
Regarding claim 13, Khalid discloses at least one non-transitory computer-readable medium (fig. 10, (1004) computer program comprising instructions (fig. 10 1024) stored thereon for implementing a switching method when the program is executed by at least one processor (fig. 10, 1002) of a multiplexing device (Router 12-20) (Khalid, fig. 10, [0045-0046], computing system 1000 includes processor 1002 (e.g., a central processing unit (CPU)), main memory 1004 and static memory 1006, storing one or more sets of instructions and data structures (e.g., software 1024) used to communicate with each other):
The rest of the limitations of the claim 13 are rejected with rational similar to that of claim 10.
Regarding claim 14, Khalid discloses at least one non-transitory computer-readable medium (fig. 10, (1004) comprising instructions stored (fig. 10 1024) thereon for implementing a configuration method when the program is executed by at least one processor of a terminal device able (endpoints 10 and 15) to transmit a datum relating to an application to a multiplexing device (Router 12-20), wherein the configuration method comprises: (Khalid, fig. 10, [0045-0046], computing system 1000 includes processor 1002 (e.g., a central processing unit (CPU)), main memory 1004 and static memory 1006, storing one or more sets of instructions and data structures (e.g., software 1024) used to communicate with each other):
The rest of the limitations of the claim 13 are rejected with rational similar to that of claim 11.
Claim(s) 2, 4-7 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Khalid et al. (US 2009/0052466 A1) in view of Schmieder et al. (US 2007/0061434 A1), further in view of Lottor SRI-NIC M, TCP Port Service Multiplexer (TCPMUX), INTERNET ENGINEERING TASK FORCE, IETF: SWITZERLAND, 01 November 1988(1988-11-01).
Regarding claim 2, Khalid modified by Schmieder disclose the switching method as claimed in claim 1, but did not explicitly disclose in response to the determining of the application being unsuccessful, comprising transmitting an error message (negative reply) to the terminal device if an application is not determined.
Lottor discloses in response to the determining of the application being unsuccessful, comprising transmitting an error message to the terminal device if an application is not determined (Lottor, page 2, lines 9-12, discloses a port multiplexer returning a negative reply to a requested device when the multiplexer cannot find a requested service).
One of ordinary skill in the art would have been motivated to combine Khalid, Schmieder and Lottor because these teachings are from the same field of endeavor with respect to the disclosure of techniques for routing network traffic.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Lottor into the method by Khalid and Schmieder, enabling routing of network traffic based on a service name, Lottor, [Page 1, Title: Service name].
Regarding claim 4, Khalid, Schmieder and Lottor disclose the switching method as claimed in claim 2, wherein the error message comprises a cause of failure intended for the application implemented in the terminal device (Lottor, pages 1-2, discloses an RFC defining a protocol to contact multiple services on a single well-known TCP port and associating each port to a specific service name or application. That is, services are assigned distinct ports on a port multiplexer. The multiplexer typically returns an error or negative reply if it can’t find a requested service/application on a terminal device).
The motivation to combine is similar to that of claim 2.
Regarding claim 5, Khalid, Schmieder and Lottor disclose the switching method as claimed in claim 1, wherein the first SCTP destination port identifier is a port identifier dedicated (first port identifier at nodes 24 and 30 hosting multiple applications) to the switching method (Khalid, fig. 1, [0020-0021] data packet received at a network endpoint such as router 12,14,16,18 20 or 22 is processed or analyzed to classification type (voice/video/email/text) associated with the received data packet. The routers are dedicated to selecting and switching SCTP packet the appropriate ports based on a classification of a received packet. The data packet is encapsulated in Stream Control Transmission Protocol (SCTP) and a data path is selected based on the classification of the received data and exit path information provided for each data type classification).
The motivation to combine is similar to that of claim 2.
Regarding claim 6, Khalid, Schmieder and Lottor disclose the switching method as claimed in claim 1, wherein the first SCTP destination port identifier is a port identifier (first port identifier at nodes 24 and 30 hosting multiple applications) already allocated for the TCPMux protocol (Khalid, fig. 1, [0020-0021] data packet received at a network endpoint such as router 12,14,16,18 20 or 22 is processed or analyzed to classification type (voice/video/email/text) associated with the received data packet. The routers perform a TCPMUX protocol through a dedicated port by selecting and switching SCTP packet the appropriate ports based on a classification of a received packet. The data packet is encapsulated in Stream Control Transmission Protocol (SCTP) and a data path is selected based on the classification of the received data and exit path information provided for each data type classification).
The motivation to combine is similar to that of claim 2.
Regarding claim 7, Khalid, Schmieder and Lottor disclose the switching method as claimed in claim 1, wherein the first SCTP destination port identifier is a port identifier allocated for an application based on the Stream Control Transmission protocol (Khalid, figs. 1,2B,3,4,6 & 7, [0026;0035 -0037] in fig. 2B, each of nodes 24 and server 30 store applications with different classifications sharing a first destination port id common to all the applications stored at each node. That is, to encapsulate the data in SCTP, the source IP address and the destination address, which define a communication path, can be inserted into an SCTP header.at 602. The packet is received at apparatus 302, where a transport optimization proxy 304 in communication with an optimized edge routing module 306, classifies the received data. Each classification (email/video) is associated with a particular port. Apparatus 302 then transmits data 310 encapsulated in SCTP to other network endpoints based on the particular port associated with the classification as indicated the header the encapsulated packet).
The motivation to combine is similar to that of claim 2.
Regarding claim 9, the claim is rejected with rational similar to that of claim 2.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Khalid et al. (US 2009/0052466 A1), in view of Schmieder et al. (US 2007/0061434 A1), in view of Lottor SRI-NIC M, TCP Port Service Multiplexer (TCPMUX), INTERNET ENGINEERING TASK FORCE, IETF: SWITZERLAND, 01 November 1988(1988-11-01), further in view of Gunnarsson et al. (US 2014/0128086 A1).
Regarding claim 3, Khalid, Schmieder and Lottor disclose the switching method as claimed in claim 2, but did not explicitly disclose wherein the error message is a packet of the Stream Control Transmission Protocol comprising a fragment containing an Abort error code.
Gunnarsson discloses wherein the error message (unavailable port/base station) is a packet of the Stream Control Transmission Protocol comprising a fragment containing an Abort error code (Gunnarsson [0045;0067], discloses an INIT ACK chunk type message used to acknowledge an initiation of an SCTP connection (i.e., an SCTP association). The ABORT chunk type is used to immediately close, or terminate, the connection. The ABORT chunk may contain Cause Parameters to inform the recipient endpoint about the reason for the abort. A description of the causes is given below with respect to the ERROR chunk type. [0067] FIGS. 10A, 10B, and 11 illustrate an eNB 28 is notified of the unavailability of an HeNB 30 via the X2-GW 40. The abort message can be used by any base station to directly notify another base station of its unavailability).
One of ordinary skill in the art would have been motivated to combine Khalid, Schmieder, Lottor and Gunnarsson because these teachings are from the same field of endeavor with respect to the disclosure of techniques for establishing connection to different services.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Gunnarsson into the method by Khalid, Schmieder and Lottor therefore, providing a reason why a connection request is rejected and when requested service is unavailable, Gunnarsson, [Abstract].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following publications show the state of the art related to the use of a multiplexer to disperse multiprotocol traffic to appropriate ports associated to different applications.
Gilchrist et al. (US 2003/0231643 A1)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIXON F DABIPI whose telephone number is (571)270-3673. The examiner can normally be reached on Monday - Friday from9:00 am – 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher L Parry, can be reached at telephone number 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
/D.F.D/ Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Prosecution Insights