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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-11 and 13-14 filed on 02/13/2026 have been considered but are not persuasive.
Applicant’s arguments: (Summary of pages 1 – 7, 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”
Response:
Examiner respectfully disagrees.
See updated rejection of amended claim 1.
In particular, Khalid, figs. 1,2B,3,4,6 & 7, [0026;0036 -0037] discloses that 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 application. 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. Apparatus 302 then transmits data 310 encapsulated in SCTP to other network endpoints based on the particular port number (second identifier) associated with the classification as indicated the header the encapsulated packet.
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).
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 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;0036 -0037] a User Datagram Protocol data is received at apparatus 302, where the access port to the apparatus is common to different classifications of data. The apparatus includes a transport optimization proxy 304 in communication with an optimized edge routing module 306, classifies the received data, where the 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 destination port identifier common (the identifier of the access port to apparatus 302 is common to all data type classifications) to plurality of applications (email, video or voice) and the second identifier (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 (Khalid, figs. 1,2B,3,4,6 & 7, [0026;0036 -0038] 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 application. 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. Apparatus 302 then transmits data 310 encapsulated in SCTP to other network endpoints based on the particular port number (second identifier) 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 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 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, [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, 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 packet with a first 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;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
transmitting the parameterized 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 destination port identifier (the identifier of the access port to apparatus 302 is common to all data type classifications) 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 destination port identifier common to the plurality of applications (the identifier of the access port to apparatus 302 is common to all data type classifications) and the second identifier specific to the application (port number for an email) that are received (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 (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, 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 destination port identifier, common to a plurality of applications (the identifier of the access port to apparatus 302 is common to all data type classifications) 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 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 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 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 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 destination port identifier is a port identifier dedicated (port 140) to the switching method (Schmieder, fig. 1A, port 140 is a static port dedicated to receiving packets from plurality of client devices 145 and 150 dedicated to classifying, switch and transmitting the packets using appropriate socket numbers (115 and 120) corresponding to different applications).
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 destination port identifier is a port identifier (port 140, which is commonly reserved for applications 115and 120) already allocated for the TCPMux protocol (Schmieder, fig. 1A, port 140 is a static port dedicated to receiving packets from plurality of client devices 145 and 150 dedicated to classifying, switch and transmitting the packets using appropriate socket numbers (115 and 120) corresponding to different applications).
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 destination port identifier is a port identifier allocated for an application based on the Stream Control Transmission protocol (Schmieder, fig. 2B [0024] At network endpoints, the TCP sessions between devices 24 and 30 are proxied and locally terminated. The network endpoints can further encapsulate the TCP data in SCTP. SCTP can transport multiple data streams and the TCP sessions can therefore be tunneled into a single SCTP session. A network endpoint can access exit path information and encapsulate the TCP data in SCTP based on the exit path information).
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
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 DIXON F DABIPI whose telephone number is (571)270-3673. The examiner can normally be reached on Monday – Friday from 9:00 am to 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